Дзесяць ціхіх памылак пошуку ў прадакшн-RAG і як выправіць кожную
Ад памеру і перакрыцця фрагментаў да гібрыднага пошуку, RRF, пераранжавання, выбару эмбедынгаў і ацэнак у CI: дзесяць памылак пошуку за няправільнымі адказамі RAG і іх выпраўленні.
Адміністратыўны чат-бот аднажды, па-вышэпіснаму, поясніў некорэктную політыку вярнення грошаў. Сістэма знайшла аблакат, у якім слова „вярненне грошаў“ было выкарыстоўваўце чатыры разы. Ён быў тэматычна блізкі і опісваў прыпыненую лінію продуктам. Штучны інтэлект зрабіў тое, што яму было сказана — адпаведзець з апэксам на даны, якія былі даны. Ніхто не сказаў яму, што даны былі некарэктныя.
Так выглядае большасць неудач у тэхналогіях RAG, якія завершаюцца сесіямі дыбаггінгу. Команда пасвячае два тыяжы, змінюючы мадэль, перапісваючы інструкціі для сістэмы і дадаючы паўтарэнне „адпавядаць толькі на аснове даных“, а рэшта не зменшыцца. Проблема ніколі не была у генераванні. Мадэль правільна вырашвала задачы на аснове вясні, якія ўжо былі некарэктныя з самага пачатку.
Дзесяць конкрэтных памылак пагародзяць якасць выкарыстоўвання інфармацыі ў практычных рашэннях на адной базе дадзеных. Яны зазвычай выяўляюцца ў фіксаванай последовасці: спачатку памылкі падзелу на часткі, калі ўжо ўсё інша залежыць ад яго, потым прыборкі процэсу выкарыстоўвання інфармацыі, далей выбор спосаба пераранжавання і укладання дадзеных, і нарэшце прычыны недастатку метрык, якія не дазволяюць пазначыць усіяя памылкі. Кожны раздзіл ніжэй пояснюе, чаму выходзяць такія памылкі, якія ўскладнення яны вызываюць і што трэба змяніць, а таксама там, дзе доследжэння супераслігаюцца, прычыны такіх суперасліганняў паказаны адкрыта.
Чаму самэ выкарыстоўвання інфармацыі ёсць местам, дзе RAG не функцыонуе
Аналізы спецыялістаў па прыемле RAG у 2026 годзе застаюцца на адной і той жа дыягнозе: большасць паспялых адказоў вынікае з проблем у процэсе выкарыстоўвання дакументаў. Вярнуцца некалькі неправільных дакументаў, або ж пропускаюцца правільныя, або ж яны знаходзяцца занадта нізка ў рангаванні і не можуць быць выкарыстаны. Сярэдні показнік станаві ад 70% і вышэй. Гэты показнік змініцца залежна ад атласу і сферы, таму ён ёсць толькі апрыксамай індыкацыяй, але незалежныя джэрэлы падтрымліваюць адноснае направленне. Калі сістэма RAG дапускае памылку, найбольш правядзімая прычына — гэта тое, што LLM ніколі не бачыў правільных доказаў, таму першы крок — пераглянуць, што вернуў механізм выкарыстоўвання дакументаў, перш чым праверкіць запіт.
Дзесяць памылак падзеленыя на чатыры групы паэтапна. Чыслы з 1 да 4 ствараюць пахаванні ў тым, што падае ў сховішча вектараў. Чыслы з 5 да 7 стосуюцца архітэктуры выкарыстоўвання дакументаў. Чыслы 8 і 9 адносуюцца да этапы рангавання і стварэння вектараў. Чысло 10 — гэта тое, што нічога з гэтага не вымерваецца.
Тэрміны, які вжываюцца ніжэй
- Чанкінг — гэта разбіўка выхідных дакументаў на фрагменты перад індэксаваннем. Мадэлі занурэння і вікна кантэксту працуюць лепшая з короткімі, сфокусаванымі елементамі, чым з цэлымі файламі.
- Жыццёздатнае аднаходжэнне (вектарны пошук) размешчае запіты і фрагменты ў аднам просторэ занурэння і вяртае найбліжэйшыя суседні элементы. Ён эфектыўны для парафразаў, але слабкі для буквальных стрэлок.
- Розрэджанае аднаходжэнне, такое як BM25, ранжуе фрагменты за спільнымі словамі запіту, даючы большую вагу рэдкім словам. Коды, імены і жарганы добра падходзяць для такога аднаходжэння, а сінонімы — ні.
- Гібрыдны пошук запускае оба методы аднаходжэння паралельна і з’едынае два спіскі з рангамі, часта за дапамою Reciprocal Rank Fusion (RRF). RRF выкарыстоўвае пазіцыі рангу заместо чыстых балав, што рашае проблему таго, што значэнні BM25 і косай схожасці не ўзаемна пораўнаныя.
- Перыякораванне параднавае спіс кандыдаў, як правіла, з 20 да 100 элементаў, за дапамогою крос-кодэра, які адначасова чытае запіт і тэкст, у працоўнае становішча, а не аддзельна іх укладае. Рэзультатам яе ёсць значна болей чыстыя рангі перад тым, як фінальны спіс з колькасцю k элементаў будзе перэданы LLM.
Чатыры аблыкі ў разбіванні на часткі
1. Выбіранне разбівання фіксаванага размеру як стандартнага і непрыняцце іншых варыянтаў
Разбіванне кожнага дакумента на фрагменты по 500 токэнаў, незалежна ад ўмесцу, — гэта тое, што спачатку вікорыстоўваюць у навучальных матэрыялах. Гэта займае пяць хвілін, працюе дастатньна добра для дэманстрацыі, і команды вікорыстоўваюць гэты падход без перагляду.
У гэтам пытанні існуюць суперсчытаннія, і адказ на іх ёсць корыстнейшы, чым выдаванне міфу пра едзінакавасць думак. Некалькі аналізаў 2026 года прадкладаюць фіксаваное або рэкурсыўнае раздзелэнне токэнаў працоўней, чым семантычнае часткаванне. У аднам з велікіх тэстаў, у якім пераглянутыя розныя стратэгіі, рэкурсыўнае раздзелэнне на 512 токэнаў павялічылася, часткова таму, што семантычнае часткаванне стварала фрагменты за сярэднім розмерам 43 токэна, што занадта мало для зберагчэння кантэксту. Іншыя доследжэнні паказваюць працоўныя рэзультаты: у ацэнцы падтрымкі клінічных рашэнняў, пераглянутай экспертамі, была зафіксавана тачнасць 87% для адаптываўанага, прыцягнутага да тэмы часткавання проты 50% для фіксаванага базовага падходу (p = 0,001). У трэцім аналізе было выявлена, што добра налаштаваны фіксаваны розмер можа даганяць або перавышаць эфекты семантычнага раздзелэння на рэальных наборах дадзеных, што адпавядае фіксаваным параграфам на 100 слоў, выкарыстоўваным у перваснай студзіі RAG.
Няма стратэгіі, якая бы паводзілася ў всіх сітуаціях. Усі джэрагі згодны ў тым, што прычына проблемы — не выбір розбівкі фіксаванага размеру, а выбір будзь-яяе стратэгіі без перапрацоўкі альтэрнатыўы на рэальным корпусе даных.
Практычны спосаб — меркаванне замест тэорызавання. Склікайце 20–50 рэпрэзентатыўных пар пытання-адказ, створыце індэксы таго ж корпуса пад двума-трыма кандыдатскімі стратэгіямі і парабяльце показнікі recall@5 і кантэкстную тачнасць. Тэксты з вбудованай структурой, такімі як документы API, прававыя дакументы і фінансавыя звясткі, зазвычай паводзяцца лепей, калі ўпершыне разбіваць іх па гэтай структуры, адколькі гэтыя елементы вялікай меры ўжо ўзаемна сувязаны:
from langchain_text_splitters import RecursiveCharacterTextSplitter
# Recursive splitting respects structure first, falls back to
# character boundaries only when a section is still too large.
splitter = RecursiveCharacterTextSplitter(
chunk_size=512, # tokens, not characters, if you swap in a token-aware splitter
chunk_overlap=75, # ~15% overlap, a reasonable starting point
separators=["\n## ", "\n### ", "\n\n", "\n", ". ", " "],
)
chunks = splitter.split_text(document_text)
2. Адзін розмер фрагмента для кожнага тыпу дакумента
Размер выбіраецца з самага пачатку на адміністратыўны прыем, а пасля прыменяецца да сумешанага калекцыі. Кансэкты API, дугія дакументы з правіламі і транскрыпціі чатоў усе атрымоўваюць аднаковы розмер фрагмента.
Занадта вялікія фрагменты зменшаюць значыцьцю інформацыі. Фрагмент з 2 000 токенамі, які охопляе пяць тэм, стварае вектар, які ўсё ў той жа час ўсе ўзятыя тэмы, і не падходзіць нідзе належна. Занадта маленькія фрагменты втрачаюць кантэкст, неабходны чытальніку — напрыклад, падпіс функцыі без апісаў параметраў або клаза без часткі, якую яна мяніць.
Размер павінен адаптавацца да залежыць ад ўтрамбоўкі контэнту. Тэхнічная дакументацыя зазвычай складаецца з 256 да 512 токэнаў, што дапамагае сфокусавацца на адным паняйме. Наратыўны чы абмовны тэкст зазвычай патрабуе 1,024 да 2,048 токэнаў, каб захаваць абаковы кантэкст. Гэтыя значэнні ёсць вачнікамі для пераканання, таму што правільная цыфра залежыць ад модэлі інкапсулявання і ад таго, як корыстувальнікі формулююць запытанні.
3. Занедбаўка перакрыцця
Перакрыцце насталяваецца раз і забываецца, або праігноруецца, таму што яго ўважаюць вітратай месца на збероўку. Без яго рэчы, якія пераходзяць межу частак, дзелююцца на два часткі. Адна частка заканчваецца пачатком, а другая — заканчэннем, і ніякая з іх не можа быць выявлена як цэлыя думкі. Гэта ўзнакома і абоўсюдна можна адваротная прычына скаргі, што адказ знаходзіцца гдзісь тут, але модэль не можа яго знайсці.
10–20% перакрыцце размеру чанка ўважаецца разумным стандартным значэннем: 50–100 токэнаў для чанка з 500 токэнаў, што ёсць дасканальным паўстановлень у пораўнанні з проблемамі, якія гэта запобегае. Большая кантроль не завжды значыць лепшае рашэння. Занадта вялікае перакрыцце зазвычай прыносіць толькі дапамогу ў зберогчыцы і додатковы шум; пры тым, ажнае сістэматычнае аналіза 2026 года, якае выконвалася з вікорыстаннем метода SPLADE, не паказала жадных значымых выгод ад такога перакрыцця ў данай схеме. Ідэальны варыянт павінен быць выбраны самастойна, а не на адной стандартнай базе.
4. Ігнораванне сэрцаўскай структуры дакумента
Прытрымлівацца ідэі, што кожны файл ёсць адной цэлай ентытнасцю, прыемнае рашэнне, незалежна ад таго, чы хоць гэта будзе кансэпт Markdown API, даговор з нумераванымі пунктамі чы фінансавы атлас, наполнены табліцамі; але розбівка без увагі да структуры часта прыводзіць да таго, што загалоўка апынваецца не ў сваёй частцы тэксту, а табліца — не ў параграфе, які яе апісвае. Найчастае наследкі такога падходу — апісанне функцыі, якае аддзеляецца ад спісу яе параметраў, таму запыт пра такую функцыю дае толькі частку адпаведзі.
Рашэннем яе ў першую чаргу раздзеліць па структуры — па загалоўніках, раздзелах, спісах і табліцах, а раздзеленне па размерэ выкорыстоўваць толькі ў тых раздзелах, якія застаюцца занадта вялікімі. До серэдзіны 2026 года большасць працэсаў чанкінгу для працы з дадзенням являюцься гібрыднымі самэ прычынай гэтага: спачатку структура, семантычнае раздзеленне ў дужа дзейнструктураваных частках, фіксаваны размер як апошняя мера, і жаданага адзінага методу не навязваецца над мішаным корпусам.
Тры аблыкі ў архітэктурэ адзысквання
5. Адправка толькі вектарнага пошуку
Шаблоны для пачатківаўцоў стандартна выкарыстоўваюць вектарны пошук. Гэта адна вызовка API, і ён выглядае чымраз лепей у дэманстрацыях, дзе тэставыя запыткі ў форме дыялогавых парафраз, што якраз і ёсць сферай максімальных можаўсцей ўшчэльненых эмбеддынгаў.
Рэальны трафік не падобаецца дэмавым трафіку. Пользоватары вводзяць коды продуктав, строкі з адказамі на адказы, назвы флагаў, номеры квітак і іменаваныя сушчэствы, якія ўособліваяцца короткімі буквальнымі токенамі. Адносна ўжо трэнаваныя мадэлі, якія трэнуюцца на кластэруванні значэнняў, часта плутаюць іх з супараднімі, але некорэктнымі элементамі. Бенчмаркі разлічна паказваюць гэтыя разлікі: настраўленая гібрыдная схема перамагала як адзін з методаў, так і іншыя методы ў тэстах ранжыравання электронной торгавлі, а бенчмарк практыкаў паказаў, што метод, які выкарыстоўвае толькі вектары, атрымвае горшыя рэзультаты па показніку recall@10 у пораўнанні з належна сынтэзаванай гібрыдной схемай, галоўная прычына — пропуск точных ідэнтыфікатораў. Цыфры разлічная ў разных корпусах даных, але направленне застаецца тым самым у всіх тэстах. Калі запыткі сумішваюць стыль размовы і стыль точнага падбору, што бывае практычна завжды, гібрыдны метод выграўшы.
Змянайа заключаецца у дадзенні індэкса BM25 або SPLADE паляўкі ўжо праз індэкс вектараў. Weaviate, Elasticsearch, OpenSearch, Qdrant і Milvus зараз усе падтрымляюць натыўныя гібрыдныя запыты, а LangChain і LlamaIndex прыносяць рэтрыверы з спалучэнням, якія іх абгружаюць:
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
bm25_retriever = BM25Retriever.from_texts(chunk_texts)
bm25_retriever.k = 20
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# weights are a starting point for RRF-style blending; tune against your eval set
hybrid_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.4, 0.6],
)
results = hybrid_retriever.invoke(user_query)
6. Спаўліванне з ваговым сярэднім, а не RRF
Пасля дадавання BM25 інтуітыўным крокам являецца нормалізацыя обох спісаў балав у дыяпазон 0 да 1 і ўзаўмна ўзаўжджэнне іх за дапамогою ваг. Гэта выглядае разумна ў электроннай табліцы. Але балы BM25 і косай схожасці выходзяць з необмежаных, рознакаляваных па форме распадаў, і нормалізацыя тыпу min-max ёсць кранічна чулай. Адзін документ-аномалія, які павтарае тэрмін запіту дзесяткі разоў, пасля нормалізацыі можа прытыснуць усе іншыя балы BM25 да нуля, спакалюючы сумаваны рангінг такім чынам, што гэта важка зазначыць без спецыяльнага аналізу.
Фюзыя взаімных рангоў узбегае ад гэтай проблемы, выкарыстоўваючы ранговую пазіцыю кожнага дакумента ў кожным спісе і зяўсе ігнаруючы значэнні балав. Самэ гэтая прычына змушвае выбіраць RRF, а не ваговае сярэднечнае значэнне, як стандарт у практычна кожнай гібрыдной рэалізацыі, упомянутай у інжынерскіх аналізах 2026 года. Стандартная формула дае кожнаму дакументу суму 1 / (k + rank) за ўсімі спісамі, у якіх ён прысутны, пры чым k=60 ёсць стандартным значэннем, якое зменшае вплыв якога-небудзь экстрэмальнага ранга.
7. Однае k для кожнага этапу
Top-k зазвычай являецца адной глобальной сталяй, якая вікорыстоўваецца пад час першага этапа пошуку, пад час фузыі даных і для фінальнага запіту. Калі на першым этапе запрашваецца толькі тыя часткі даных, якія можа размясціць запіт, спроможнасць адзыскання інформацыі ужо знікае, прычым рэранкер не можа нічага парадражыць: частка даных, якая у пошуку за вектарамі займае 14-е месца, ніколі не доходзіць да запіту. Апошнія памылка — гэта перэдача сотняў кандыдатаў рэранкеру без пазнейшага сортавання, што коштуе часу і грошаў, а таксама заполняе запіт слабкімі данымі. Адзыначэнне LLM пад такім навантажэннем падупае (эфект „загубленага посерэдыне“), і ён тыха анулюее выгоды, якія даў рэранкінг.
Узьмім к як воронку. На першым этапе выберыце шырокія групы — ад 20 да 100 кандыдатаў, каб алгорытм перэранківання меў можлівасць выправіць пачатковыя помылкі у ранжыраванні, а пасля застосавіце маленькія групы з прыблізна 3 да 8 елементаў для фінальнага аналізу. Кожны параметр k на адным з этапаў трэба налаштаваць окрэма, адпрацоўваючы яго на наборы дадзеных для ацэнкі, адтак як адна цыфра не можа падходзіць для обох цэлей.
Две помылкі ў ранжыраванні і эмбедынгах
8. Ігнораванне перэранківання
Перэранківання выклікае дадатковыя запыты да сеткі чыста для аналізу, што прыносіць затрымкі, а ў разе послуг на хостынгу — дапамогу ў рачынку. Пад тым пясцем часу гэта перша рашынка, якая адбываецца, і ранжыраванне на першым этапе спрыяецца як фінальнае.
Пошук за вектарамі першага стадыя выкарыстоўвае бі-кодэраў, якія спакоююць тэкст у адны фіксаваны вектар яшчэ до таго, як будзе створэны запіт. Гэта і ўрабляе ўпоркі ў вялікіх масштабах, але таксама обмежвае ўжоўточнасць, таму што знікае дзеякі тонкі аднос ад запіту да тэксту. Крос-кодэраў восстанавляюць гэты аднос, чытаючы як запіт, так і тэкст адразу. Незалежныя адчыты з 2026 года паказваюць, што перэранківанне за дапамою крос-кодэраў ёсць найкрашчы спосаб пры дадаўанні да існуючага працэсу пошуку з прыемным рэзультатам першага этапу: зазвычай адзірваныя каніктуі ў ужоўточнасці чы рэшэнні NDCG станавяць калькіляўна калькіляўна 20 пунктав, а ў дадаткова складных з пунктуазнай точказы ўзорках — і больш, пры чым додатковы час адпаведзення залічваецца меншым за 200 мс пры разумных розмерах базы дадзеных. Адзін з кліентаў адзначыў, што перэранківанне дапамогле падняць ужоўточнасць на 23 пункты ў яго праекце, што больш, чым будзь-якія змены у фармаце вкладзенняў чы розмерэ фрагментаў тэксту. Калі гібрыдны пошук вучыцца працаваць, гэта ўжо наступны крок, які варта спробаваць.
Змянайа заключаецца у дадзенні ўтрамбавання на стадыю пераранжавання між фюзыяй і фінальным запітам. Для самастаўлення без плата за кожны вызов, bge-reranker-v2-m3 ўсё чашча выбіраецца як адкрытыя крос-кодэры з хорашым падтрымкам калькі мов. API Rerank ад Cohere ўважаецца стандартным альтэрнатыўным рашэннем, калі не патрэбна інфраструктура GPU. І тэ, і іншае інтэгруюцца з LangChain і LlamaIndex:
from FlagEmbedding import FlagReranker
reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True)
def rerank(query: str, candidates: list[str], top_k: int = 5) -> list[str]:
pairs = [[query, c] for c in candidates]
scores = reranker.compute_score(pairs, normalize=True)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [text for text, _ in ranked[:top_k]]
final_context = rerank(user_query, fused_candidates, top_k=5)
9. Абстрактны мадэль на спецыязычным корпусе
Мадэль абстракцыі, якая ўключаецца ў фрэймворк, часта вжываецца безпосерэдна на юрыдычным, медычным чыяў фінансовым корпусе, пры чым яе падтрымка апарачаецца калькамі ручных перапрацоўкаў. Модулі загальнага назначэння выучаюцца з шырокіх тэкстаў з Інтэрнэту і энцыклапедыяў, таму яны менш чыста аддзеляюць спецыялістычны жаргон, чым модулі, трэнаваныя на матэрыяле конкрэтнай галіны. Гэты недастатак стварае проблемы там, дзе рызыкі ў высокім ступені. У рэгулююцыях сферах непаштоўны выбар, напрыклад, упомінанне стандартной процедуры заместо конкрэтнага адступнення, пра якое запытвалі, дае адпаведзь, якая здаецца правдопадобной, але на самай працоўнай, што ўжо горша, чым явная памылка.
Перш чым прымкнуць, запрацавайце прынеймнейша адаптаваныя па домэне або настроеныя алгорытмы умяшчэння проты стандартных настройкаў на «золатай» кантэнце. Калі настроўка алгорытма умяшчэння немагчыма, крос-кодэр, які перэранжуе даныя і які навучаны на малай колькасці пазначаных запыткаў домэна, часта можа быстрэй і дышэўш заўмерзнуць большасць прычын проблемы, адколі ён выправляе бяглыя памылкі без павторнага умяшчэння всіх дадзеных.
Памылка, якая маскіе іншыя
10. Распрацоўка на адображэннях
Інфраструктура адміністрування выглядае як зайвая навантажэння паляглы ўжо над стварэннем функцыйяў, і, калі дэманстрацыя выглядае добра, здаецца, што дасыць проста паглядзець на калькі рэзультатаў. Аднак самэ гэта прыносіць самыя вялікія додатковыя затраты, адтым што хавае іншыя дзевяць проблем. Галюцынацыі, якія тэхнічна базуюцца на запрашаным кантэксце, дакументы, якія падаюць у неправіловым парадку, і фрагменты, якія пераканчваюцца самэ не там, нельга надзеясніваць, проста чытаючы рэзультаты, і калі корыстувальнікі пра гэта паведамляюць, ўсё гэта ужо ў эксплуатацыі.
Раёнам ёсць золаты набор з 50 да 200 парадных пар пытання-адказ, які пакрываюць крайнія случаі, такія як неясна формуліровка, пытанні, які вымагаюць двух дакументаў, і адварсальныя перафразаванні. Яго оцэнююць за стандартным крытэрамі, раздзеленымі на два ўзелі. Раёнер ацэнюецца за тачнасцю і вярнасцю кантэксту, тады як гэнератор — за адданасцю і ступенем рэлевантнасці адказа. У гэтым направленні домінуюць два фрэймворкі, і команды часта ўжоўваюць іх разам. Ragas — гэта стандартны інструмент для аналізу метрык, а яго сінтэтычны гэнератор можа стварыць золаты набор на адной з баз дадзенаў, каб чалавек могаў яго дапрацаваць. DeepEval, створаны на базе pytest, ёсць стандартны спосаб прыродзіць ацэнку ў частыну працэсу CI. Часта выкарыстоўваецца падзел: Ragas для аналізу і стварэння дадзенаў, DeepEval для пераканання ў правільнасці кожнага pull request.
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, ContextualPrecisionMetric
from deepeval.test_case import LLMTestCase
def test_refund_policy_query():
test_case = LLMTestCase(
input="What is the refund window for the Pro plan?",
actual_output=rag_pipeline.run("What is the refund window for the Pro plan?"),
retrieval_context=rag_pipeline.last_retrieved_chunks,
expected_output="Pro plan purchases can be refunded within 14 days of purchase.",
)
faithfulness = FaithfulnessMetric(threshold=0.8)
precision = ContextualPrecisionMetric(threshold=0.7)
assert_test(test_case, [faithfulness, precision])
Установіце такі рашты в CI, каб праблемы з разбіваннем тэксту, заменайомствам элементаў аб апдэйту базы знанняяў, якія пагаршуюць працэс пошуку, зупінілі працэс стварэння продукту раней, чым гэта пашкодзіць дзень кліента.
Як разлічаюцца праблемы залежна ад налашоўкі
- Внутршній пошук у корпорацыі і адпаведзенні на запытанні ў дакументах, які ўжоўцаваецца найчым чашчэ, сільна залежыць ад гібрыднага методу пошуку. Спецыялісты прыкладзяюць номеры заявок, коды правілаў і SKU-ы разам з запытаннямі на простай мове, але пошук, які фокусуецца толькі на сэнсе, працуе некорэктна, не беручы ў расчыт буквальную частку запытання.
- Боты падтрымкі для кліентаў найбольш выгадваюць ад пераранжавання рэзультатаў пошуку. Некорэктнае, але зрозумелае адпаведзенне тут ператвараецца на заявку аб втрату акаунта, а не проста на ігнораванне з боку колегі.
Выбір наступнага крока
У фазе падчынення або калі яшчэ тэстуецца, чы рэшэння RAG ўзагалі прыемна, найкрашчы пачатак — гэта пошук толькі на аднаковасці вектараў: яго лёгка стварыць, і на адзін дзень можна адпаведзець на пытанні пра архітэктуру. Калі з’являюцца рэальныя запіты корыстувачаў, трэба пераглядаць лог-файлы на шуканне точных патэранаў, такіх як коды продуктав, ідэнтыфікаторы квітакоў і значэнні налаштаванняў. Як толькі такія элементы з’явяюцца, спачатку трэба дадаць метод BM25 у поўнай сувязі з RRF, адтуды ўжо і іншыя заходы, адтаколькі джэрагі часта адзначаюць, што гэта самая значныя паэфектыўнасць у працэсе выкарыстоўвання дадзеных. Пасля гэтага прыходзіць практыка пераранжавання, калі гібрыдны пошук працуе і мета — тэчнасць адпаведзей, а не проста ўсеохопленне. Гэты падход ёсць дышэўны за сваімі рэзультатамі і не выклікае патрэбы перзбудавы індэкса. SPLADE чы іншыя адпрацоўваныя эмбедынгі трэба застаўіць на пазнейшы момент для команд, у якіх ўжо ёсць развітыя методы ацэнкі, якія паказалі, што гібрыдны падход у поўнай сувязі з перэранкінгам застаецца лепшым, адтаколькі ў ягох больш зусілляў і трыбутоў, і ўжо без базовых показнікаў яго важка апрацаваць.
Колькасць працаваючых і бюджэт зменяюць адпаведную адпаведнае рашэнне. З двума інжынерамі, API для керавання пераранжаваннем (Cohere зазвычай выбіраецца) ёсць лепшым варыянтам, чым аператыванне крос-кодэра самастойна: пры незначным трафіку кашты здаюцца мінімальнымі у пораўнанні з часам, які спрацоўваюць серверы GPU. Калі ўжо ёсць персонал для MLOps і GPU-апаратура, або трафік настолькі велікі, што аблікаванне за кожны запіт стае значным статэм, тады болей логічна ўстановка адкрытага модэлю, такога як bge-reranker-v2-m3.
Скількі все ж такі коштуе хорашы пайплайн
RAG не ўсунець усіх проблем. Яго галоўная перавага — апоўненне інформацыяй з зовнішніх джэраў: адпаведзі можна падкрэпіць цітатамі з адзысканых істочнікаў, а не толькі на тым, што запамятаў мадэль, а базу знання можна апдэйтаваць без паўторнага навчання. Аднак дадатковыя механізмы дзейсна збільшуююць тэхнічную складнасць. Патрэбны два індэксы, каб усё заставалася супараднам, механізм пераранжавання для выяўлення адхылэнняў, працэс ацэнкі, каб рэзультаты заставаліся высокай якосці, і схема разбівання на часткі, якую трэба перапрацавваць, калі змініваецца склад дакументаў.
RAG таксама не усувае галюцынацый. Ён зменшае колькасць вымыслу, які вынікае з нехваткі знанняў, але не вплывае на сітуацыі, калі LLM неправяльна адыграўчыць або застосоўвае кантэкст, які яму быў правільна даўжаны. Існуюць паметры адданасці, таму што «апоўненне кантэкстам з зовнішніх джэраў» і «правільнасць» — гэта разныя характэрыстыкі, і розвіты працэс ацэнкі вімервае як адно, так і другое.
Гатовнасць да прыменення
- Ацэнка ў CI. Адрабатываць паруванне Ragas і DeepEval для кожнага запіту, змены алгорытма аднаходжэння інфармацыі чыста базы знанняяў, а не толькі адзін раз пад час запуску.
- Сінхронізацыя індэксаў. Адкорэктаваць індэксы BM25 і вектарныя індэксы адночасна або за аднаковым графікам. Калі застарэлы індэкс працюе разам з новымі вектарамі, працэс аднаходжэння інфармацыі пачынае паказваць абэранціі, якія важка ўловіць.
- Візуабільнасць. Фіксаваць часткі інфармацыі, якія былі аднаходзены для кожнага запіту, а не толькі фінальную адпаведзь. Гэта дазволяе без прыпускаў выявіць, чыя прычына — проблемы з аднаходжэнням інфармацыі чы стварэнням адпаведзі.
- Кранты доступу. Хаваць канты для пераранжавання і генеравання вектараў за межамі рэпазітарыя і зміняць іх праз стандартны манеджэр секрэтных дадзеных.
Короткі урок
Паглядзіце, што вернуў пошукавы алгорытм, прычым не змінюючы запіту чыра модэлю. Дзевяць з дзесяці прычын абэронацый (некалькасна разбівка дадзеных, відсутная гібрыдная пашуковая стратэгія, наўмовістная фузія даных, некарэктны розмер кандыдатаў, прычыненая пропускам пераранжавання, неконтрольваны модэль укладкі даных) ўсе ў спектрэ проблем пошуку, якія можна вырашыць за дапамогою відпаведных рашэнняў. Дзесятая прычына — відсутнае ацэнкавання — і ёсць прычыной таго, чаму першыя дзевяць прычын так часта застаюцца непазначанымі.
Ніякі з рашэнакоў не трэбуеяць команды дакладных даследжэнняў. Дадаць BM25 праза існуючыя сховышчы вектараў, заменіць спосаб сумавання балав на RRF або адмовіцца ад пераранжавання між фюзыяй і генераваннем — гэта больш супамінаеся з канцэптуальнымі змянамі, чым з перадзялом, і кожны з гэтых падходаў мае стабільную падтрымку з незалежных джэрэл, нават калі цыфры разлічаюцца. Практычны пачатак: зберыце запыткі рэальных корыстнікаў за два тыдні, пасчытайце, скількі з іх маюць точныя ідэнтыфікаторы, якія вектарны пошук мог бы затуманіць, і створыце набор з 50 запыткаў на адлік з ужо існуючых няудач. Гэта менш, чым можа здавацца, і гэта пакажае, які з дзесяці помылак каштуе больш за ўсе.
Супаўязаныя матэрыялы
- Выкліканне прычын тыхаех абэранцэй RAG: адзысканне, чанкаванне, фільтры і ацэнкі — Адказы RAG могу здавацца правільнымі, але ўсё ж быць некорэктнымі. Практычны пакет інструкцыйяў для Python, прызначанных для аналізу процэса адзыскання даных, чанкавання, фільтраў метадаў, ацэнкі, гібрыднага пошуку і іншых аспектаў.
- Гібрыдны RAG для правовых тэкстаў: чанкаванне, BM25, BGE і перэранкаванне — Практычны пакет для правовых даследжэнняў на адной з статэй Констытуцыі Індыі: чанкаванне на родныя групы, адзысканне даных за дапамойкай BM25 і BGE, злучэнне рангаў, перэранкаванне за дапамойкой крос-кодэраў і пашырэнне запыту, перапрацавана на тэстовых датасэтах.