Калі цитаты выглядаюць ідеальная, а колькасць участнікаў яшчэ не такая.
RAG выкарыстоўваў правы PDF, але ўсё равна зменшыў колькісць дванаццаці працавнікаў, працаваючы з іх як з аднаго; гібрыдны пошук, стисненне з урахоўванням табелей і трэйсы працы канвею выправілі гэту проблему.
Пытанне пра заробную плату должна быць банальным. Якщо запытацца, сколькі чалавек указаны ў рэўістары заробной платы за красавец 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, перш чым паверыць у новыя наводныя даны.