Калі бот RAG цытуе некалькуючы суму страховага выкарыстання

Усё, што напісана ніжэй, — гэта складаная наратыва для навчання. Назвы компаній, імены людзей і сумы ў долерах ёсць вымышленымі; спосабы парадків ўзгадваюцься як тые, з якімі на практыцы сталкаюцца сістэмы RAG у сферах рэгулюемага страхавання і іншых сферах з высокім рызыкам.

У пазнюю частку вівторка керавучы аддзёнам заяваў пра проблему інжынерам: асістэнт паведаміў кліента, што сума страховага выключэння за повеню станавіць 500 долераў, хаця у полісе было зазначана 5 000 долераў. Бот, распрацоўваючы інформацыю з дапамогою тэхналогій адзысквання дадзеных — „Atlas“ — працаваў вясьмі дзён, располагаючы базай вектароў, модэлем укладання дадзеных, супэрна скарым LLM і прыемным інтэрфейсам. Аднак у яго не было эфектывай стратэгіі часткавання дадзеных.

Адзысканы фрагмент выглядаў так:

...applies to all covered perils. Deductible: $5
00 for flood events in Zone A, $500 for wind events, and $1,0

Пракцэс выкарыстоўвання PDF спыніў розбіўку цыфры на разныя лініі. Пасля таго часткавач фіксаванага размеру роздзяліў тэкст на часткі по 500 сімвалаў па самой гэтай межы. Модуль укладання дадзеных створыў індэкс фрагмента, у якім было зазначана „5 долераў“ і „500 долераў“. Модэль з упэўненасцю, але неправа, дала адпаведзь.

Наступна часць паказвае, як была перабудована сістэма апрацоўкі: адна стадыя парсінгу, якая встановляе максымальны ліміт, а потым чатыры рэвеню фрагментавання, якія падыходзяць да гэтага ліміту з растучымі вітрамі.

Адна модэль структуравання дапамагае застаць чыстасць эконамічных расчыткаў: па-большайшай часткі вартасць фрагментавання — цэ хутчысінькі вычысленны індэкс. Ён запускаецца офлайн, да таго часу, калі не прыйшла жаданне ад корыстніка. Џедыныя віткі, якія паўтараюцца ў показніку query p95 і якія стосуюцца фрагментавання, — цэ сама модэль імбеддынгу. Тое, што называецца «дорогім» для вышэйшых рэвеню, означае дорогі вычысленні адна раз на дакумент, а не за кожны запіт.

Стадыя 0: Вы не можэце фрагментаваць структуру, якую знішчылі пад час парсінгу

Першым інстынктам ёсць вікорыстанне болей розумнага інструмента для разбівання на часткі. Лепшы першы вопыт: паказваць тэкст, які разбіваецца, а не PDF-файл. У пачатковым варыянты Atlas тэкст складаўся з масы сімвалоў; заголовкі ператварыліся на звычны тэкст, а табелі — у сплетаны тэкст, у яком значэння з розных радоў стаялі ўзаўсёды адночасна. Тэкст на сторанцы (“Policy Form HO-3 — Page 14 of 62”) павтарыўся кожныя калькі сімвалоў.

Жаданы інструмент для разбівання не можа вярнуць межы, якія ўжо былі знішчаны парсерам. Калі заголовкі зніклі, інструмент для роздзелення заголовкаў у фармаце Markdown не мае чаго роздзеляць. Калі табелі растаялі, нічога не захоўвае рады ў цэласці.

Падберыце кожны тып вхідных даных пад парсер, які генеруе структуру, яку можа вікорыстаць інструмент для разбівання:

Аўтэнтныя PDF-файлы і DOCX (формы для заповнення, падтверджэнні, кераванні). Лепш выбіраць парсэры, якія разумеюць макет — LlamaParse, Unstructured.io, Docling, Azure Document Intelligence — замест простых выкарыстоўванняя тэксту. Неабходнае ўжыццё markdown з апісаннем тыпаў элементаў (загалоўкі, таблыцы, спісы), а не простаў шматка тэксту.

Сканаваныя PDF-файлы, з’еўрэбнікі і факсы. Неабходнае выкарыстоўвання тэхналогій OCR (Tesseract ёсць найслабейшы; PaddleOCR, Textract, Document AI, Azure — аднаковае лепшыя). Неабходны тэкст, блокі макету і ранг паверыльнасці для кожнага блаку. Ранг паверыльнасці пазней дапамагае візначыць, чы “гэтае значэнне ёсць неняснае — не трэба на яго адпаведзаць ў чысцэнні дэдактыў”.

HTML і внутранія вікі. Неабходнае адзьмянэнне непатрэбных элементаў і выдача чыстага markdown з сохраненымі загалоўкамі.

Прэзентацыі і табліцы. Неабходнае сохранэнне меж слайдоў чы сярожкі, каб жаданы фрагмент ніколі не супакоўваў несвязаныя слайды.

Аудыё і відэа (тэлефанныя размовы, вебінары). Сервісы Whisper, Deepgram чыста AssemblyAI должны ствараць транскрыпцію, у якой будуць пазначэны тыя, хто гаворыў, і калі. Калі спікеры не аддзельваны, протыярысныя заявы ад рэгулятора і кліента могу злучыцца ў аднаго вводзячага ў глухое цікавасць параграфа.

Пасля перапарсавання з урахоўваннем структуры, раздзіл з паказванням сумы, якая можа быць выключэна з выплат, выглядаў так:

## Section 4 — Deductibles

### 4.2 Peril-specific deductibles

| Peril          | Zone A  | Zone B  |
|----------------|---------|---------|
| Flood          | $5,000  | $2,500  |
| Wind / hail    | $500    | $500    |
| Named storm    | $1,000  | $1,000  |

Табліца была вярнутая. Дрэво заголовкаў таксама было вярнутая. “$5,000” знову стала адным токенам. Код для разбівання на часткі яшчэ не змяніўся, і працэс выкарыстоўвання дадзеных стаў болей безпечным.

Рэжым 1: Сінтаксічнае разбівання — дышэўка, шырока, і тут вам трэба пачаць

Фіксаваныя размеры: пратотып, які выйшаў праз адпадковасць

Раздзеляйце кожныя N сімвалоў або токенаў (CharacterTextSplitter, tiktoken). Кост ад індэксавання ўжо блізу нуля. Годна для тымчасовых сітуацый; катастрофічна ў прыменэнні у рэальных умовах. Гэта спрычынае перэрывы серэд рэчэнняў, табелей, цыфр — адносна точна такія ж сітуацыі, якія выкалучаюць можлівасць аналізу. Правіла пасля той ночы: фармат з фіксаваным размахам ніколі не можа выкарыстоўвацца ў дзяржавым рэестрэ.

Команды знову і знову адкрываюць той самы патэран: корпус дамаў з короткімі пасоўкамі на блогах вытрымае раздзелэнне на сімвалы, але як толькі з’являецца першы PDF у калькулярнай фарматазе або документ, перакананы OCR, якасць адпаведзей рэзкаа падупала. Спрыяйце фіксаваным окнам як каркасу для локальных эксперыментаў, пры чым неабходна ўключыць явны пункт у чартку контролю для іх замены пры першай жа можлівасці, перад тым як пачнёцца праца з зовнішнімі корыстувальнікамі.

Перакрыцча: рэгулятор, а не стратэгія

chunk_overlap павтарае заканчэнне чака N у пачатку чака N+1. Часта значэньне — 10–15 процэнтаў (на прыклад, 50 з 500 токэнаў у чаке). Адзінакаванне ёсць недорогы спосаб захоплення для рангаў 1–2; ён не выправляе паслабленых граней — ён іх толькі павтарае. Калі адпаведнае рашэнне знаходзіцца ў зоне адзінакавання, колькасць вектараў і падобных рашэнняў у методзе top-k зростае прыблізна на 10%.

Калі ў спісе суседніх рашэнняў домінуюць павтарэння, інструменты пераранжавання і большыя мовныя модулі вітрачаюць рэсурсы кантэкстнага вікна на адной і той жа рэчы два разы. Адзінакаванне па ідэнтыфікаторы або па хеш-значэннях тэксту, якія ў большай меры ідэнтычны, пасля абрання даных, ёсць недорогым спосабам смягчэння проблемы, калі з іншых прычынаў адзінакаванне павінна застацца высокай.

Рэчы/парараграфы: сягледзяць граматыку, ігнораваць дакумент

Збір цэлых рэчэнакоў у адзін бюджэт (NLTK, spaCy, LlamaIndex SentenceSplitter). Ніколі не розрывае рэчэнак унутры — іначы бы гэта завадзіла розбівцы на новыя лініі — але ён не ведае пра загалоўкі, табелі чыстыя спісакі выключэння. Чудова працюе з транскрыпціямі калі ўсё праходзіць па плану; сяродняя — з структураванымі формамі політык.

Рэкурсыўны сімвал: стандартны варыянт, які вы выкарыстоўвайце першы

RecursiveCharacterTextSplitter пробуе разлініювачы па прыорытэце — порожняя лінія, новая лінія, рэчэнак, слова — і пераходзіць да іншага варыянта толькі тады, калі фрагмент заўсёды занадта вялік, пасля чаго з’еднае маленькія фрагменты да значэння chunk_size. Частае базовае значэнне — 500 токенав з 50% перакрыццю:

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
)
chunks = splitter.split_text(policy_markdown)

У перапрацаванай частцы з пунктамі, якія можна выключыць з расчыткаў, было залучана ўсё з 4.2 — укладзеныя там табліцы таксама, адтакуль што порожнія лініі стварылі сама сабою адзіную елементацыйную едыніцу, якая не перакрочвала 500 токенав. Баг знік. Неабяжна выдаты recursive-500/50 як базовую памерную базу, а не як готавы дызайн.

Запісаце гэты базовы рэйтынг на дошку і адмовіцеся ад прыемаў «болей розумных» срэдстваў для раздзелення тэксту, якія не можаць пераканаць яго ў тых сабе ж праблемных запытаннях. Багато дорогіх ідэй здаюцца чароўнымі, пакуль іх не пораўняюць з простым рэкурсывным срэдствам для раздзелення тэксту ў чыстым фармаце Markdown.

Рэгіон 2: Раздзеленне тэксту з урахоўваннем структуры — раздзеляйце там, дзе ў дакуменце вялікі ўжо пунктыр

За дапамогою набору з ~80 рэальных запытанняў recursive-500/50 даў рэзультат ~71%. Неудачы выклікаліся у дужа дзяўгіх частках тэксту, а таксама у адпаведзеннях, дзе модэль не могаў візначыць, канкрэтна якая політыка чы ўражок выйшла з каго.

Раздзеленне загалоўкаў у фарматах Markdown / HTML

MarkdownHeaderTextSplitter / HTMLHeaderTextSplitter дзеляць тэкст на часты па іерархіі загалоў і перадае шлях загалау ў метаданы:

from langchain_text_splitters import MarkdownHeaderTextSplitter

header_splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=[("#", "h1"), ("##", "h2"), ("###", "h3")]
)
sections = header_splitter.split_text(policy_markdown)
# then apply the recursive splitter inside each section

Кожны фрагмент, вырваны з падраздэла 4.2, павінен мець „сюдзінную нітку“, напрыклад: форма HO-3 → ставкі → таблыця, прызначаная для конкрэтнага рызыку. Штоў такую „сюдзінную нітку“ да тэксту пры ўключэнні, каб вектар кодаваў не толькі цыфры, але і месца. З-за проблем з пытанням „Калькі раздзел?“ такія варыянты адхоўляюцца; у цітатах можна напісаць „згодна з раздэлам 4.2“. Кост застаецца майжэ нулявым — але толькі якшо на этапы 0 быў выданы справжні маркдаун. Разгледзены тэкст бесшумна стае адным вялікім фрагментам. Лепшае выкарыстоўванне на вікі, тэхнічных дакументах і документах з загаламі.

Поле метаданых таксама должна перавозіцца разам з вектаром: ідэнтыфікатор аднойчынага дакумента, шлях раздэлу, дата набрання чыннасці і юрысдыкцыя, якшо правілы разніцаюцца па штатах. Гэтыя поля дазволяюць вікорыстоўваць фільтры („толькі HO-3, чынны пасля 2024-01-01“), якія чыстая пошук за сэмантычнаю схожасцю не можа рэалізаваць.

Урахоўвае макет / by_title

Неструктураваны метод chunk_by_title (і аналогічныя у LlamaParse/Docling) прыменяе граніцы элементаў парсера: таблі застаюцца цэлымі, загалоўкі пачынаюць часткі, спісы зберагаюць свое вступнае рэчэнне. Ідэальны інструмент для дагавораў і складных PDF-файлаў. API для парсавання коштаюць грошы толькі праз раз, пад час стварэння індэксу. Дышучы парсер зніжвае цэну — не купуйце розкішную калектры для автомабіля без двагуна.

Урахоўвае код (AST)

Нерэлевантны для корпусаў правіла, абавязковы для Terraform/Python RAG. Разлікванне лінак паводзіцца да аддзелення падпісаў ад тэлу. tree-sitter чы ўрахоўваючы мову рэкурзівныя супарцелювальнікі адбываюць розлікванне на вузлах функцый/класаў. Яе выбіраюць, калі корпус складаецца з рэпозытарыяў чы IaC-коду.

Спалучэнне правіл прозы і кансультацыйкага коду ў аднам індэксе без разлічэння сапраўдзачых элементаў зазвычай дае найгоршыя наследкі: функцыі перэрываюцца ў серэдзіне, а табелі правіл руйнуюцца пад вплывам гэўрыстык, спрамаваных на складкі.

Рэгламент 3: Фрагментаванне на аднойчыні — плата за прыняттыя рашэнні толькі тады, калі структура знікла

У 84% прыкладаў з «золатага» набору з’явілася новая катэгорыя абэранцэй: неструктураваныя транскрыпты калёсаў без заголовкаў. Рэкурсывныя блакі з 500 токэнаў паводзіліся на пераходы між тэмамі — спачатку заява пра компенсацыю, потым адрэса для падачы — таму эмбедынгі выказвалі две тэмы і не падходзілі ні да одной з яых.

Семантычнае фрагментаванне

Умяшчайце тэкст па абзацах; здыяўляйце перэрыв таму, дзе спад косінай падобнасці паспелі за паказаныя значэння (SemanticChunker, будзь-які адпаведны інструмент для умяшчэння). Адзін працэс умяшчэння за час аналізу індэкса. Метод прымае учынак на мову; паказаныя значэння залежнаць ад конкрэтнага корпусу. Паказаны порог для тэлефонных размов ператворыў ўжо складны тэкст правілаў на маленькія фрагменты — таму выкарыстоўвайце семантычнае раздзелэнне толькі для неструктураванай мовы, а правілы залучайце да другага рэвю.

Распад па класах дакументаў — мова, формы, вікі — ёсць лепшым рашэнням, чым пошук аднаўсенага універсальнага інструмента для раздзелэння. Косць арганізацыі — гэта класыфікатор чы простая змяна тыпу файла пад час запрацоўкі; выгода — меншай кантэнт з нечыстымі данымі.

Раздзелэнне на прыказы / атамарныя факты

Маленькі LLM перапісваюць абзацы у самастоятэльныя тэксты («Сума за страхаванне ад паводка для зоны А па полісе HO-3 становіць 5 000 долераў»). Точнасць вырастае, таму што кожны элемент — гэта адна фактаза з кантэкстам, які ўключаны безпосерэдна. Кошт складаецца з адной выкліканні LLM на абзац — што ўсуне проблемы для невялікіх, але высокаточных корпусаў дакументаў, такіх як 40-сторонній FAQ. Аднак існуе рызык: тэксты можаць адхіляцца ад первіснага формулювання. Калі кляўцы спрачоўваюць адпаведзі, болей правільна будзе вжыванне точнага цытатавання, а не парафраз. Тэксты трэба выкарыстоўваць толькі як дапамогу для пошуку, а для цытатавання неабходна вярнуць самы адначасовы абзац.

Організацыі, якія займаюцца супакоўкамі і прыемамі кляўчых заяваў, зрэшты патрабаваць буду картынку сторонікі або PDF-файл з выдзеламі частак пад кожной адпаведзю. З самага пачатку трэба стварыць ідэнтыфікаторы для цытатаў, каб індэксы тэкстаў заставаліся толькі інструментам прышвартавання, а не основай для зберагаўання дакументаў.

Агентны чанкінг

Практычна ўстановка — даць цэлы дакумент флагманскаму мадэлю для выбору меж. Аднак ёё працэздатнась і масштабаванне ўжо з самага пачатку слабкія: выкалыкі расту лінейна заўсёды, калі росце размер корпусу дакументаў, тады калі ж значэнне не расце. Годная для каля колькісці некалькох сотэй важлівых дакументаў; не падходзіць для мільйонаў.

Ранг 4: Разбівка на часткі пад час пошуку — шуканне малых елементаў, вярненне большых

У рангах 1–3 прыпускаецца, што елемент, які індэксуецца, ёсць тым самым елементам, які вяртаецца. Гэта вымушвае робіць неправільны компроміс: малыя часткі дазволяюць чыстае стварэнне эмбедынгаў, але не даюць LLM достатнько кантэксту; большыя часткі даюць кантэкст, але паслабляюць якасць эмбедынгаў. Настоўкі параметра chunk_size ніколі не дазволяюць знайсці універсальнае оптымальнае рашэння.

У рангу 4 ролі раздзеляюцца: элемент для пошуку, які падбіраецца па параметрам да стварэння эмбедынгаў, і элемент для вярнення, які падбіраецца па параметрамам LLM. Крытэрыя для адгукнення: калі вам патрэбна другая база дакументаў (docstore, карта-родзіч, дрэва), значыць вы знаходзіцеся у рангу 4.

Родзічны дакумент / ад малага да большага

Індэкс маленькіх дзецей (150–200 токенав). Пры падборэ неабяжна вярнуць большыя элементы-родзічы (весь раздзел 4.2 або падраздзел дыяв ~1,500 токенав):

from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import InMemoryStore

parent_splitter = RecursiveCharacterTextSplitter(chunk_size=1500)
child_splitter = RecursiveCharacterTextSplitter(chunk_size=200)

retriever = ParentDocumentRetriever(
    vectorstore=vectorstore,
    docstore=InMemoryStore(),     # the "second store"
    child_splitter=child_splitter,
    parent_splitter=parent_splitter,
)
retriever.add_documents(policy_docs)

LlamaIndex AutoMergingRetriever працуе за аднаковай іерархіяй. Дапаможныя затраты на індэксаванне практычна равны нулю — тыя ж тэксты размешчаюцца ў меншых частках. У „золатай” калекцыі сама гэта змяна падняла рэзультат Atlas з ~84% да ~91%; запіт „what’s my flood deductible“ падаў на точную строчку табелі, тады калі LLM яшчэ бачыў суседзяючыя прыміткі (вакол таго, як вядома зона A). Аперацыйныя затраты: сховішча дакументаў, ключаваная па ID родзіча, якая застаецца сінхронай праз абнаўленні.

Тут важнае значэнне мае выдаленне і версіяванне: калі пераглядаецца раздзел 4.2, дзеці і родзічы павінны апдэйтавацца разам, іначы сістэма будзе выкарыстоўваць точны дзецінскі элемент, які адкрывае застарэлы родзіч. Працэс уваходжэння дакументаў трэба спрыятаць як транзакцыйную публікацыю родзіча, дзецей і ўсіх асоцыяваных дадзенняў — а не як тры незалежныя задачы.

Кантэкстуальнае выкарыстоўванне дадзенняў

Перад умяшчэнням запытайце міні-LLM пра адзін чырво сэнтэнцы, якія будуць паводлай сітуацыі, і дадзіце іх на пачатак; адушыце іх з BM25. Фрагменты на кшталт “Зона А: $5,000 / Зона Б: $2,500” стануць доступнымі для адзыскання. Коштавасць — адна вызова LLM на кожны чанк; без кэшавання праграматы вылічэння ўжо, а з кэшаванням прыфікс дакумента застаецца “тэплым”, і вызовы на кожны чанк застаюцца дэшавымі.

Пазнелейкое чанкуванне

Умяшціце весь дакумент за дапамою інструмента для умяшчэння з дзяўным кантэкстам, а пасля вырахавайце сярэдніе векторы токенав у межах кожнага чанка. Векторы чанкаў несу кантэкст дакумента без неабходнасці вызова LLM на кожны чанк. Гэта конкуруець з методамі адзыскання на адваротнае падставе кантэксту, але прымушвае вас выкарыстоўваць мадэлі умяшчэння з дзяўным кантэкстам.

Хіерархічнае чанкуванне / RAPTOR

Аграгуець фрагментаў, стварае падсумкі, занова аграгуець гэтыя падсумкі ў дрэво; стварае індэкс для кожнага рэвэру. Шырокія запіты атрымваюць адпаведныя падсумкі; конкрэтныя запіты атрымваюць адпаведныя рэзультаты на найніжшых рэвэрах. Высокія віткі на 4-му рэвэрэ ўскладнююць працę, калі змянююцца дакументы — перзбудова ў такіх случаях ёсць дужа дорогай. Квартальныя абнаўленні правіл зробілі RAPTOR прыдатным выборам для Atlas.

Статычныя базы знанняў — внутрашні энцыклапедыі, якія зміняюцца ў кожны год — можу прымкнуць перзбудову дрэва. Аднак жывыя формы страхавання гэтага не можу. Выбірайце іерархічныя методы толькі тады, калі шточна заданыя рэт кароткага змены і бюджэт на перзбудову.

Што гаворыць перзбудованы план дзеяння

Чырвоў што пасля трэнінгу з адпаведнасці Slack, Atlas пасягнуў майжэ 93% у тэставанні з аптавам наборам запытаў, які налічваў або-такі 300 запытаў. Короткая версія плану дзеяння:

Пачніце з рэкурзыўнага раздзелення сімвалоў плюс рэзакоў, якія уважна ставяцца да структуры, пры аб’ёме прыблізна 500 токенаў і 50% перакрыцця — гэта практычна нічога не коштуе і дае можлівасць абліковаць базовы показнік. Спачатку апградуйце сістэму да выкарыстоўвання галоўнага дакумента, каб размеры паспадобленаў і выданых дакументаў моглі разніцявацца. Ліш тады інвестуйце ў кантэкстуальнае выкарыстоўвання дакументаў, калі ў наборы для ацэнкі все ўсё ж такі проблемы з вярнамасцю дакументаў.

Нічыя з вышэйзгаданых мераў не можа вярнуць правільную структуру дакумента. Спачатку паспрабуйце выправіць працэс выкарыстоўвання дакументаў, перш чым налаштовваць прыборы для ўскладнення структуры.

Версія на адной сторонцы

Этап 0 — Аналіз структуры. Падберыце прыборы для аналізу структуры па тыпу вхідных дакументаў: структураваны markdown для натывных докумэнтаў; тэкст + макет + ранг надзеі OCR для сканаваных дакументаў; чысты markdown з заголовкамі для HTML-дакумэнтаў; межы слайдоў/аркушаў для прэзентацый; транскрыпціі аудыядакументаў. Гэта встановлівае верхнюю межу для налаштавання.

У рангу 1 — сынтаксічны. Фіксаваныя размеры толькі для пратэтынаў. Надакладанне — гэта дыялектар (10–15%), які калічыць дублікаты па прынцыпе top-k. Раздзеленыя рэчы паследаваюць граматыку, ігнаруючы логіку дакумента. Рэкурсыўны падход 500/50 ёсць стандартным базовым параметрам, а не канечной метай.

У рангу 2 — з урахоўваннем структуры. Раздзелы загалоўкаў несу шляхі раздэлаў; ўсё залежыць ад якосці парсера. Распаўненне by_title заходзіць на цэлыя табелі; дэшавыя парсеры губяць гэты эфект. Раздзелы у фармаце AST выкарыстоўваюцца для хранення коду.

У рангу 3 — на адной з модэляў. Семантычныя раздзелы залежнаць ад ступеня сэмантычнай падобнасці; налажванне ведзецца па кожнам корпусе. Прыпоزыціі падвышаюць точнасць у малых корпусах, але выклікаюць адхыленні ў формулюваннях. Агентныя методы рэдка калі есць эфектывнымі у масштабных задачах.

У рангу 4 — часы выкарыстоўвання. Падход за дапамой малых елементаў; доставка большых. Гэты варыянт ёсць найболей эфектывным з точкі зору адзычных вялікасцей. Для кантэкстуальнага выкарыстоўвання неабходна кэшаванне. Разбіўка на часткі пазней ёсць дышэўней, але мае обмежэнняя з боку прыстрою для вбудоввання. RAPTOR стае застарэлым пасля апдэйтаў. Калі трэба другі істочнік дадзеных, то гэта ў рангу 4.

Проблема, якая выклікала споры, на самай працоўнай час не стосавалася выбору між LangChain і LlamaIndex. Йа стосавалася неабходнасці адзначэння структуры дакумента раней за вырахункі, апранавання інструментаў для разбівкі на часткі на рэальныя запытанні клёўянтаў, а таксама вадзібнасці не даваць модэлю фрагменты, якія немаглі бы зместыць цэлы чысловы факт.

Ствараць «золаты» набор на адказах, які ужо спантавалі продукт — некарэктныя сумы страховых выкарыстанняў, нехватка абставінаў, плутаныя рэкамендаціі — а не на сінтэтычных фактах. Адзельна оценяць правільнасць адказаў і адпаведнасць цітатаў, каб некарэктны адказ ніколі не выглядаў як паводзінне. Калі з’являецца новы элемент, трэба, каб ён перавыпануў базовы показнік па обох метрыках, прычаму ён толькі пачне працаваць з рэальным трафікам.

На заканчыце, трэба застаўляць механізм абароны: калі рэверэнція OCR для чысловага фрагмента нізкая, або калі версіі-роды і-дзеці не згаджаюцца, асістэнт павінен адмовіць у адпаведзе на пытанне пра страховыя выкарыстанняў і перадаць яго вышэй, а не выдумваць рэверэнцію. Карыстувальнікі набагато шчыльнае прыменяюць адмову «не можна паўнаста пераканацца на адваротнае на падставе заполненага формуляра», чым віпадкова некарэктны адказ на суму пяцісот долераў. Такі шлях адмовы павінен быць часткай тэхнічных вакуфнаў продукту, а не толькі часткай прэzentацыі пасля аналізу наследкав.