Калі цытаты выглядаюць ідэальная, а колькасць участнікаў яшчэ не такая.
RAG выкарыстоўваў правы PDF, але ўсё равна лічыў дванаццаць працавнікаў як аднаго. Гібрыдны пошук у Qdrant, стысненне з урахоўваннем табелей і трэйсы пайплайна выправілі гэту проблему.
Крыніцы: My RAG App Said There Was One Employee. There Were Twelve.
Пытанне пра заробную плату должна быць банальным. Калі запытацца, сколькі чалавек указаны ў рэўістары заробной платы за красавец 2025 года, чакаешся простага паведамлення з колькасцю, апошнім падзеўкам і нічога цікавага. Сістэма вернула апрацоўаны абдзек: адны работнік, назва PDF-файла, падпіс на сторанцы. У рэўістары было зазначана дванаццаць.
Самэ гэта явішча прычыняе, чаму тэхналогія генеравання з дапамогою запытак ёсць небяпечной у практыцы. Працэс не выклікаў краху; лог-файлы засталіся тыхімі. Адпаведзь выглядала як усе правільныя адпаведзі з таго ж тыжня. Мяккі крах з прымечаннем горшы за жорсткі крах, таму што ніхто не будзе паднімаць на вышэйшы ранг просты абдзек.
У этамае паказана схема, якая створыла брэхню, методы дыягнастыкі, якія ўбачылі яе, а таксама конкрэтныя змены, якія вярнулі колькасць да дванаццаці. Склад чыннікаў ўсёлякі: pdfplumber для працы з тэкстам PDF, які врачоўвае макет, LangChain для раздзелення тэксту на часткі, MiniLM для стварэння эмбедынгаў, Qdrant для працы з вектарамі, гібрыдны метод пошуку на аснове ўшчэльненых даных і BM25, крос-кодэр для пераранжавання рэзультатаў, а таксама кампрэсар, які мяў на меце скараты обсяг кантэксту перад запускам генератора. Жодны з эых выбораў не быў экзотычным. Проблемы выклікалася ў спосабе іх взаімадзейства з тэбламі і ідэнтыфікаторамі.
Одна раз прыймаецца, а ўсё час адпавядаецца
Дакументы прыходзяць толькі раз. Запіты ж прыходзяць стала. Разлікаванне гэтых шляхоў мае значэнне пад час дыбаггіну, таму што некарэктны адпаведзень можа выйсці з застарэлых вектараў, паслабленых фільтраў або генератора, які так і не побачыў правільных радоў.
Процэс абрабаткі пераглядае кожны PDF, выкарыстоўваючы інформацыю пра макет, выдзяляе тэкст, дзеліць яго на перакрываючыся часткі, ушыроўвае іх і адправляе ў Qdrant разам з метаданымі, якія пазней можна будзе выкарыстоўваць для фільтраў:
PDF → extract text per page → cut into chunks
→ convert each chunk to 384 numbers → store in a vector database
Адпаведзенне на запыт — гэта аблака іншага тыпу. Ушыроўваецца запыт, выкарыстоўваюцься кандыдаты на адпаведзенне, за неабходнасці спалучаюцца рэзультаты пошуку па ключоўых словах, адбываецца пераранжаванне, стысненне, пасля чаго да модэлю задаецца запыт з прыўязанымі цытатамі:
question → search → rerank → compress → ask the LLM → cited answer
↓ ↓ ↓
5 chunks 3 chunks ~600 chars
На паперы такі алгорытм ёсць стандартным. Аднак у практычных умовах такія стандартныя прыпускі не працуюць з рэўістрамі працавнікаў, таблікамі рахункоў-фактур і будзь-якімі дасягамі, дзе адпаведзенне мае структураваны характэр, а не ў віглядзе простага слогана.
Чаму кожны элемент займае свое месца
pdfplumber не ўзьміцейшая бібліятэка для працы з PDF. Гэта адна з некалькіх, якія захоўваюць достатню колькасць інфармацыі пра макет, ўнаследке чаго радкі з данымі пра заробную плату не сплываюць у аднаго большога параграфа. Быстрэйшыя інструменты для выкарыстання дакументаў, якіе ператвараюць таблыцы на сплошныя рэчэнні, робяць пазнейшыя запітанні на кшталт «сколькі працавальнікаў?» практычна немагчымымі, адтаколькі мадэль ніколі не бачыць меж радкаў.
Для гэтага праекту быў выкарыстан LangChain-овы рэкурсывны сапраўднік сімвалаў, а не іншыя элементы гэтай платформы. Метаю былі прагнозаваныя размеры «вікнаў» з перакрыццем, а не стварэнне конкрэтнага ланцуга RAG. Пасля короткай пераборы быў выбран код all-MiniLM-L6-v2 для стварэння эмбеддынгаў: меньшыя мадэлі не фіксавалі токены-ідэнтыфікаторы; большыя мадэлі збільшвалі час адпаведзення, не выправляючы ключовых проблем. Qdrant павярнуў перамогу за можлівасць безперашкоднага перавода дакументаў з локальных сэрвераў у хмару і фільтраў пакетаў дадзеных, якія паспелі да спосабу, якім прыложэнне ужо аналізавала тыпы дакументаў.
Гібрыдны рэшук смяшваў семантычную падобнасць з адлікам ключоўых слоў у стыле BM25 працаваў з практычна 0,65 / 0,35. Чыста семантычны рэшук быў выключна эфектывны для запытання «Што такое політыка адпачынку для бацькоў» і вельмі неэфектывны для STL/2025-26/003. Пераранжаванне за дапамою крос-кодэра падмыла спіс кандыдатаў. Компрэсія мела на мету заставіць толькі рэчы з высокай яскравасцю сэнтэнцый пры вызове LLM. Самэ ў гэтым последнім этапе пачалася історыя пра тое, як з дванаццаці засталася адна.
Упэўнены неправільны адказ
Для запытання пра заробную плату была знайдзена правдападобная стораніца, якая была ацэнена, але падрахунак выйшаў недастатковы. Аналіз чыстых адлікаў знайдзення паказаў першыя проблемы: семантычныя «суседзі» здаваліся «дастатнька блізкімі», тады як рэчы з точным фарматам паслаба ўпораліся з наратыўным тэкстам канпуса.
0.781 Invoice_INV2025001_Arvind.pdf <- returned
0.779 Invoice_INV2025002_Trident.pdf
0.776 Invoice_INV2025003_Welspun.pdf <- actually wanted
Тое значыць, алгорытм сэродненасці не можа выконваць точную працу з токенамі. Ададзеўшы параметр BM25 і сумаваючы балы, была зменена класафікацыя, вэські ідэнтыфікатораў і частак з табламі падняліся:
0.854 Invoice_INV2025003_Welspun.pdf <- correct
0.549 Invoice_INV2025001_Arvind.pdf
0.545 Invoice_INV2025002_Trident.pdf
Толькі гэта не вярнуло пачатковыя показнікі. Гэта толькі дазволіла правам дакументу браты удзел. Наступныя проблемы былі ў самам дакуменце.
Ідэнтыфікаторы працавальнікаў як эксперымент з выжывання
Уместо таго, каб спарчвацца пра атмасферу, ідэнтыфікаторы працавальнікаў ST001 да ST012 былі пераглянуты на кожным этапе: выкарыстоўванне, разбіўка на часткі, адзыскванне, параднай класафікацыя, стысненне і завершальная компанавання запіта.
retrieved chunk ST001 ST002 ST003 ST004 ST005 ... ST012 (12 present)
after rerank ST001 ST002 ST003 ST004 ST005 ... ST012 (12 present)
after compression ST001 ST002 (2 present)
prompt sent ST001 ST002 (2 present)
Некалькі ID зніклі межы стадзіяй кампрэсавання і обработкі мадэллю. Кампрэсар выкарыстоўваў фіксаваны ліміт „галоўных запаведзянняў“. Адна рэчка ў таблі лічыцца як запаведзенне. Калі таблі з зарплатамі мае вялікі розмер, ліміт спалюецца ў першыя рэчкі, а пазнейшыя рэчкі — а таксама тэкст, які іх пояснюе — ніколі не патрапляюць у запрошэнне да мадэлі. Мадэль тады чыста аддае інфармацыю пра тое, што ўсё-такі змогла побачыць.
# before — keep the top N
best = scored[:40]
# after — keep the best until the character budget runs out
budget = MAX_CONTEXT_CHARS // TOP_K_AFTER_RERANK
for sentence, score in ranked:
if best and len(sentence) + 2 > budget:
continue
best.append(sentence)
budget -= len(sentence) + 2
Калі кампрэсаванне перасортавала і скраціла рэчкі, таблі з зарплатамі сталае сяродком, як колода картак, распаўнутая без правільнага парадку. Кожная цыфра можа існаваць гдзе-небудзь у вікнах кантэксту, але структура, неабходная для підрахунку разных працавнікаў, з’явілася. Підрахунак людзей у таблі, якую хтось разрэзаў на часткі, — гэта іншая задача, чым проста чытанне таблі.
Рэйтынгі рэранкераў, якія здаваліся нормальнымі, але ўсё раве нашкодзілі
Рэйтынгі крос-кодувальніка для радоў, якія ўзьязначаюць крытычныя элементы, выглядзелі «разумнымі». Разумны не значыць тое ж, што і зберэжчыце цэлую табліцу.
0.446 keep ST001 Rajesh Kumar M CFO 75,000 ...
0.323 keep ST002 Priya Sundaram Finance Mgr 45,000 ...
0.420 keep ST003 Murugan K Sr Accountant 28,000 ...
0.259 DROP ST005 Selvam R Production Mgr 38,000 ... ← below 0.30
0.422 keep ST006 Karthik P Supervisor 18,000 ...
# pick the best by score…
chosen = set(id(p) for p in best)
# …then put them back in document order before joining
best = [p for p in scored if id(p) in chosen]
Метод аднарэгування не заключаўся у падышчы прагрызу ў всіх месцах. Цэль была выкрываць лініі, сэродзеўныя табліцы, і адстаўляць іх ад агрэсівнага стыснення. Практычны метод: калі лінія мае чатыры або больш цыфраў і знаходзіцца сярод прынеймна трох падобных ліняй у той жа фрагменце, яе трэба спрацавляць як рад табліцы і зберагчы, незалежна ад рэйтынгу выраза.
ROW_MIN_NUMBERS = 4
TABULAR_MIN_ROWS = 3
def is_row(sentence):
return len(NUMBER_RE.findall(sentence)) >= ROW_MIN_NUMBERSif looks_tabular(sentences):
survivors = [p for p in scored if is_row(p[0]) or p[1] >= threshold]
else:
survivors = [p for p in scored if p[1] >= threshold]
Пасля таго, як рады табліцы былі адстаўлены, усе дванаццаць ID засталіся ў запытэ на наступным запуске. Генератор нарэшце меў структуру, якую мог ўрахоўваць.
Маленькія практычныя змены, якія усунулі іншыя проблемы
Калі шлях да таблыцы быў ачыты, калькі суседнія проблемы патрапілі пад аднае і тое жа адносленне: порожнія зменныя сераўысу, якія таямніча заменялі запланаваныя стандартныя значэння, фільтры тыпу дакумента, якія працавалі інакш адносна локальнага Qdrant і Qdrant Cloud, а таксама пакеты даных з адказамі, якія вярталі толькі прозу, калі аператары патрабавалі трэс-даных працэсу апрацоўкі.
# the context cap must be at least CHUNK_SIZE × TOP_K_AFTER_RERANK
MAX_CONTEXT_CHARS = 5000 # was 2000 while 1200 × 3 = 3600
Цяпер кожны адказ вяртае не толькі фінальную фразу, але і весь працэс апрацоўкі — зявлены ID-ы, рэйтынгі, рашэнні ўзьмоцкання дакументаў і фільтры — тады наступныя некарэктныя підрахункі можна будзе аналізаваць без згадак.
{
"answer": "12 employees are listed...",
"citations": [{"doc": "Salary_Register_April_2025.pdf", "page": 1}],
"pipeline": {
"retrieved": 5,
"after_rerank": 3,
"chars_before_compression": 3847,
"chars_after_compression": 2103
}
}
Фільтраўванне па тыпе дакумента працавала з локальным экземплярам Qdrant і таксама не вяршылася ў Qdrant Cloud, пакуль індэксы пакета даных і фарматы фільтраў не сталі адпаведнымі таму, што фактычна індэксавалася у версіі для воблака.
500 — Index required but not found for "doc_type"
Спаднія версіі функцыі Python: os.getenv("KEY", "default") вяртае порожню строчку, калі зменная існуюць, але ў яе няма значэння. Гэта не ёсць стандартным станом. Калі трэба, каб пад час відсутнасці значэння было выкарыстоўвацца іншае, лепей вжыты or:
QDRANT_URL = os.getenv("QDRANT_URL") or "http://localhost:6333"
Дзе завершылася обработка
Пасля гібрыднага выявлення, сціскання з урахоўваннем структуры таблы і явной аналізу пацекі, запіт пра рэўістры квітня даў дванаццаць рэзультатаў з цітатамі, якія вказывалі на радкі, якія падтрымвалі гэты лік.
Retrieval: hybrid, 0.65 semantic + 0.35 BM25
Reranking: cross-encoder, 5 in → 3 out
Compression: sentence-level, table-aware, ~35% reduction
Grounding: prompt + threshold + temperature 0.0
Evaluation: 13/15 on the golden set, refusals tested
Latency: ~4s end to end
Cost: ~$0.003 per fifteen-question run
Для всьго гэтага не была патрэбна новая мадэль. Патрэбна была трактаванне RAG як пацекі дадзеных з можлывасцю вімеравання шансаў на зберыганне значэнняў важлівых токенав. У навучальных матэрыялах працуе ідэя «вбудоўваць, выявляць, генераваць». У прымэнным варыянце главнае — «падтвердзіць, што радкі дасяглі запіту».
Практычныя прыемы, якія забезпечваюць правдзівасць ліку
Зберагаеце набор золатых запітоў, які включае прынеймна адны запіт на точную гутароўку па таблыце, адну вышукванне за точным ідэнтыфікаторам і адна запітанне, касаючыся семантычнай палітры. Якшто працуюць толькі семантычныя запітанні, значы дэманстрацыя каламуўляе ўжо па канцэпцыі гатовнасці.
Фіксуйце ID частак праз стысненне. Якшо ID, яны ўжо былі пасля вышуквання, з’яўляюцца без яго пасля стыснення, гэта ўлом, нават якшо канечны адказ сёння вярны.
Для корпусаў, якія сумешчаюць прозу і разныя стылі, лепш выкарыстоўваць явныя гібрыды. Толькі інтэнсывнае вышукванне будзе эфектыва для эсэ, але не для кодаў.
Вважайце цітаты неабходнымі, але недастатнімі. Нумар сторанкі пад блыскучай гутароўкай залякуе застаецца блыскучай гутароўкой.
Калі пераходзіце з локальнага Qdrant у хмару, праконтролюйце знову індэксы паданых дадзенняў і прыемлівасць фільтраў за дапамогою тых сабе наладак. Сумяшаннасць API не значыць ідэнтычных стандартаў індэксавання.
Бюджэтныя налагодкі прыменяюцца да структуры, а не толькі да „важлівых рэчэй“. Табелі ёсць часткаю структуры. Якшто скупляць іх як параграфы блогу, тады дванаццаць ператвараецца ў адзін.
Чаму мяккія неудачы заслуговуюць на строгейшыя крэты
Команды часта разрахоўваюць можлівасць запуску RAG на адпаведнасці з крэтам, калі „адказы выглядаюць добра ў табліцах з запрошэннямі па стандартным шляху“. Гэты крэт не берае ў расчыт тых неудач, якія маюць значэнне для расчыту заробкай, запасоў і са адпаведнасцю правілам: неправільныя падрахунакі. Неабходна дадаць автаматызаваныя перакрычанні, якія будуць пераканвалівацца, чы рэзультаты выкарыстоўвання выдлучаных сутнасцей застаюцца ў запрошэнні для вядомых элементаў. Заблокаваць працэс стварэння, калі пасля скуплення ST001–ST012 не будуць усі прысутныя ў элеменце заробкай.
Той самы крэт можа пераканвалівацца, чы вагі гібрыднага сумешання дзе-правда ўвімкнутыя ў дзейную конфігурацыю, а не толькі ў докуменце README. Разлік межа эксперыментаў у ноутбуце і конфігурацыі службы — частая прычына, чаму алгорытм BM25 „зніквае“ пасля рэфакторынгу.
У канцы, трэба навучыць аператароў не даваць веры прываблівым цытатаў. Інтэрфейс продукту павінен паказваць даныя пра працэсы пошуку і сціскання празрачна, разам з адпаведнымі адказамі для внутршняях корыстувачаў, пакуль «золаты» стан за цыкл выдання застаецца зеленым. Внешнія корыстувачы можаць застаўляць чыстыя параграфы; внутршняях корыстувачаў патрабуецца спецыяльны набор для аналізу.
Заключанне
У рэўістры ніколі не было напісана, што ёсць адзін працавальнік. Пайплайн так напісаў, пасля таго як таямна адхіліў радкі, якія моглі бы гэта пацвердзіць. Для выправлення гэтага быў неабходны гібрыдны пошук ідэнтыфікатораў, сціскання з урахоўваннем структуры табелі, а таксама адказы, якія несу свою сабеўласную доказовую лінію. Калі гэтыя элементы былі ужо на месцы, дванаццаць засталося дванаццаць — і наступная впэўненая цітата мела рэальную падставу.
Гэта той стандарт, які трэба падтрымваць: не тое, чы можа мадэль звучаць впэўнена, а тое, чы можа сістэма падтвердзіць факты, якія правергаюць гэю впэўненасць.
Большэйшыя дэталі пра практычнае выкарыстоўванне гібрыднага методу ацэнкі
Метод густага выкарыстоўвання дадзеных кодуе запыт і кожны фрагмент у аднаковы вектарны прастор і ранжуе іх па косай або скалярной добутку. Гэты падход працуе, калі мова карыстальніка збагачваецца з мовай дакумента: права на адпачынак за выхаванне дзецей, компенсацыя за звалічэнне, правілы удаленай працы. Ён не працуе, калі карыстальніка вставляе незрозумелы токен, які практычна не з’являецца ў дадзеных для навчання і рэдка супакоўваецца з суседнімі словамі ў вектарным прасторы. Коды спаведамлень, номеры рахункоў-фактур і ID контрактаў якраз належаць да такіх токенаў.
BM25 і супаўзвязаныя методы ацэнкі лексычных показнікаў ператвараюць проблему. Яны фокусуюцца на тым, чыры развіваецца токен, насколькі ён рэдкі ў корпусе і як часта ён з’являецца ў кандыдатскай частцы тэксту. Ім не важна, што “STL/2025-26/003” сэмантычна ні з чым не асоціюецца. Спалучэнне гэтых двух показнікаў не ёсць філасофскім рашэнням; гэта проста узнакомленне з тым, што корпусы з данымі пра адплатаў магуць міткаваць як тэксты на кшталт эсэ, так і табелі на кшталт рэестраў.
Співвяшчанне 0,65 / 0,35, якое вжываецца тут, ёсць толькі пачатковай точкай, а не законам навукі. Корпусы, якія маюць багато кодаў, можаць патрабаваць большай вагі лексычных показнікаў, тады як корпусы, якія маюць багато наратыву, можаць патрабаваць меншай вагі. Гэта, што мае значэння, — гэта вімеры обох класаў запітаў у “золатай” калекцыі і адмова ад выдачы спалучання, якое працюе толькі з наратывнымі запітамі.
Пры выкананні сумешчання неабяжна нормалізаваць рэйтынгі пры ўжыванні іх у сумешчанні. Чыстыя показатры ўзаемнае сэроднечы і чыстыя рэйтынгі BM25 маюць разныя шкалы. Команды, якія включаюць ненормалізаваныя цыфры, часта адкрываюць, што які-небудзь канал віпадкова становіць домінуючы. Методы мін-макс або злучэння па рангу (RRF) ўсе якія ёсць прыемлімымі, калі іх тэставаць на дадзеныях з точнымі ID.
Компрэсія як адыянтны кодак для таблей
Компрэсія кантэксту існуе таму, што мадэлі маюць скончаныя окна і таму, што нерэлевантныя рэчы зменшаюць увагу. Стандартны падход: оценіць рэчы за ўзаемную сэроднечнасцю, заставіць топ-k і адмовіцца ад рэшты. Што гэты падход прыпускае, што рэчы ёсць взаімназаменнымі елементамі значэння. Аднак радкі ў табле не ёсць взаімназаменнымі елементамі значэння. 7-й радок без радкаў 1–6 — гэта не проста табле з нейкімі недакладнасцямі; гэта зламана табле.
Хіюрыстыка абяцэнкі — большая колькасць цыфр у адной лініі, калькі такіх ліній поблізу — ўмышлена простая. Яна захавае дзеякія не-таблічныя радкі, які выглядаюць цыфрамі, і гэта прыемна. Хвалёныя рашэнні коштаюць токенав. Неправыя негатывныя рашэнні коштаюць правільнасці. Для расчытку заробкай і інвентара правільнасць мае прыорытэт.
Болей складныя дэтэктары можаць выкарыстоўваць структуру PDF з pdfplumber: рамкі клетак, выравняныя столбцы, павтараючыся x-коордынаты. Гэтыя сігналы ўзяцься за прыемныя, калі яны ёсць. Хіюрыстыка абяцэнкі застаецца корыстной як запасны варыянт, калі тэкст ужэ быў ператворэны ў markdown або звычны тэкст пры выкананні сціскання.
Іншы спосаб абэрэння — перасортаванне. Нават якшо всі радкі застаюцца, іх пераранжаванне па рэйтынгу значэння можа знішчыць сумы і колькасці. Для радкам табліц, якія абэрнуцься, лепей выкарыстоўваць стабільны парадак документа. Прозу можна ранжаваць свабодна; табліцы трэба заставляць у парадку чытання.
Цітаты, якія падтрымліваюць неправядзівую адпаведзь
Citation UX частаюць адзначаць PDF-файл і сторанку, які запярэдзілі большую частку атрыманага фрагмента. Калі пазней стысненне зменшае розмер табліцы напалову, гэтая прызначэнне як і раней вядома ў правільным файле. Пользоватары спрыягаюць гэта як падтверджэння. Дызайн продукту павінен або паказваць конкрэтныя радкі, якія былі вікорыстаны ў фінальным запіце, або прадставляць следы атрымання дадзеных. У працоўных случаях інтэрфейс становіцца спадчыннікам проблемы.
Для домэнаў, якія належаць да рэгульюемых катэгорыяў, трэба зберагаць точны хеш кантэксту запіта разам з адпаведной адпаведзю. Калі аўдытар запытае, чаму сістэма сказала «адзін працавальнік», можна праказаць скорачаную табліцу і паказаць баг, замест таго каб спарчвацца пра характэрыстыкі мадэлі.
Локальныя проты воблаковых баз дадзеных вектараў
Фільтр тыпу дакумента, які працав локальна і не працав у Qdrant Cloud, ўсвідамляе, што «той самы API» не значыць «тая ж самая настройка індэкса». Індэксы палоуда, фільтры ключоў і апрацоўка значэння null разлічаюцца ў разных рэжымах развяртання. Тэсты фіксатуў должны працаваць з тым самым рэжымам развяртання, які вы вікорыстоўваеце у працэсе распрацоўкі. Зелены локальны набор тэстаў праз аднойчы ружовы фільтр у воблаку — гэта тое, як адбываюцца безрэзультатныя запыткі.
Пустыя зменныя сераўісу таксама выклікаюць падозру. Сістэмы настройк, якія экспортуюць порожнія строкі для ненастаўленых секрэтных даных, будуць ігнораваць стандартныя значэння ў тых мовах, дзе порожній стан счытаецца правдападобным. Нормалізавайце настройкі пачатком процэса: спрацоўвайце порожнія значэння як відсутныя, пасля чаго застосавайце стандартныя настройкі, а якшо неабходныя ключы все ўсё недаступны, то выклікайце памылку.
Аналіз выжывання, а не атмасферы
Эксперымент з выжыванням ID працавіка ўтварае шаблон. Выберыце элементы, якія павінны быць прысутныя для правільнай адпаведзі. Пераканаецеся, што яны існуюць пасля выкарыстоўвання, пасля разбівкі на часткі, пасля адзыскання, пасля пераранжавання і пасля сціскання. Запісуйце спады якосці. Першы спад зазвычай ўказвае на бяг.
Распрастарыце гэю ідэю на чысловыя агрэгаты. Калі запітанне стосуецца сумы, пераканаецеся, што кожны элемент, які берэцца ў суму, быў прыняты. Калі запітанне стосуецца післяледовычнага ліку, пераканаецеся, што набор ключоў ёсць цэлым. Гэтыя перакананні ёсць дэшавымі у пораўнанні з інцыдэтамі пад час працы.
Што не трэба перш за ўсё крытыкаваць
Калічыцца падсчэт, і хочацеся зваліваць віну на LLM. Інодзе мадэль сапраўды не можа падсчыць. Частае явішчэнне — мадэль ніколі не отрымала структуру, якая можна падсчыць. Зменшайце мадэль толькі пасля таго, як графік выжыцтва стане зеленым. Аднакоў, так вы «вылечыце» баг у падсчыцці, перэйшоўшы на большую мадэль, якая створыць халюцынацію па жаданай вам цыфрэ — пакуль не прыйдзе наступны рэўістар.
Таксама не трэба адмовляцца ад усіго фрэймворку толькі таму, што адны з компрэсараў паспелаў некалькі. Аддзержыце тую частку, дадзіце аўтаматычнае выключэнне, дадзіце тэст і працуйце даўжэй. Масовыя перапісвы здаюцца продуктыўнымі, але часта знову прыносяць тыя ж багі пад новымі назвамі.
Мінімальны чыртак для змяцнення
- Ключовыя запітанні: падсчэт столаў, точны ID, семантычная політыка.
- Гібрыдны спосаб выкарыстоўвання дадзеных з нормалізаваным сумешаннем або RRF.
- Компрэсія, якая врачуе структуру столаў, з стабільным порадкам рэчэй.
- Хроніка прабегу працэса для кожнай внутраней адпаведзі.
Заўсёды пераканайцеся, што выпалоўваецца гэты спіс пераканаў, прычымляючы RAG для расчысцоў “завершана”. Рэжыстр за красавец не будзе апошнім дакументам, які выглядае проста і вялікодушна паспяшаецца.
Наследкі для каманды
Калі стабілізаваўся адпаведны рэшчык з дванаццацьім працавнікамі, тая ж самая тэлеметрыя выявіла два менш згледныя багі: застарэлы псевданім калекцыі пасля перагружэння і тайма-аут ранкера, які пераводзіў на гібрыдныя рэшчыкі без ранкіраўнення, не пазначаючы рэшчык як прызнак заніжання якосці. Оба багі засталіся бы непазначанымі, якбы API вяртаў толькі строку. Вяртанне структуры — рэйтынгі, часы, альтэрнатывы — ператворыла асістэнта на ўстройства, якімі аператары моглі давераць настацькі, каб дыбагаваць ў 2 гадзі ночы.
Гэта і ёсць справжній урок з продукту. Сістэмы RAG — гэта не проста адаптацыя PDF-файлаў пад фармат чата. Гэта канектары даных, якія выражаюць інфармацыю у вачэннях. Ставіцеся да іх як да канектароў: вімеравайце падышкі, зберагаюце структуру і ніколі не дазволяйце цытатам заменяць сабою падтверджэння.
Ішоў раз перагляд асаліднай некорэктной адпаведзі
Паўтарэнне паказвання некорэктной адпаведзі з дадатковымі відлікамі робіць сітуацыю майжэ нудной. Сістэма пошуку практычна знайшла правы PDF-файл. Гібрыдны метод ацэнкі завершыў гэту працу. Пасля чаго сістэма стыснення выкарыстала свой ліміт на першыя чысловыя радкі і адкінула рэшту. Мадэль падрахавала тое, што засталося, і цітавала файл. Кожны этап сам па сабе рабіў ўсё, што можна было абяцаць, і разам яны стварылі вярасць.
Іменна прычына таго, чаму метрыкі на стэжы ўводзяць у глухае калішча. Значэнне Retrieval@k можа здавацца нормальным, але компрэсія знішчае правільную адпаведнасць. Метрыка, якая праблэматызуе шкоду для корыстніка, — гэта выжыванне аб’екта з начала да канца. Яе трэба застосавляць якомога раней, асабліво калі дакументы ў фармаце PDF яўляюцься справамі, структураванымі як табліцы.
Калі вы не захаваеце нічога іншага з гэтага інцыдэнту з дванаццацьма працавальнікамі, захавайце гэта: няпраўільныя працы сістэмы RAG лічуюцца багамі паляны, пакуль не будзе дазволена іншая версія. Неабходна контралюваць весь палян, захішчаць структуру і пераканацца, што сістэма правільна працуе, перш чым паверыць ў яе рэзультаты. Няпраўільныя працы выклікаюць патрэбу ў строгіх контрольных механізмах, паўтарных пераглядах і аператарах, якія можуць бачыць кожную дробязь, перш чым корыстнікі знову паверыць у наводныя даны.
Выжыванне аб’екта пасля компрэсіі застаецца простэйшым і найболей адказным крытэрыям для корпусаў, дзе пераважаюць табліцы.
Калі прыйдзе наступны дакумент, паўтарна аналізуйце графік выжывання ID, перш чым паверыць у новыя наводныя даны.