Галоўная / Артыкулы

Агентны пошук і дастатковы кантэкст: калі RAG ведае недастаткова

Стандартны RAG часта адказвае зарана. Агентны пошук плануе запыты, выбірае крыніцы, ацэньвае доказы і шукае зноў, пакуль кантэксту сапраўды не стане дастаткова.

Выдавец: REACTAPP.TOP9 хв чытання2114 слоў

Крыніцы: When RAG Doesn’t Know Enough: Why Agentic Retrieval Needs Sufficient Context

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

Класычны патэрн — адна пераглядка:

User question → embed query → retrieve top-k chunks → send to LLM → generate answer

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

Прэматырныя адпаведзі

Багато сістэм RAG зламваюцца тыха. Яны ніколі не кажуць, што недастаткова падставы. Яны даюць адпаведзь — выразную, структураваную і пераважна правдопадобную, але некорэктную.

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

Што значыць достатній кантэкст

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

З top-k да пошуку доказаў

Стандартны RAG спрыягае адзысквання інформацыі як адзін крок: адзыскваеце раз і даеце адпаведзь. Агентны метод адзысквання спрыягае гэты працэс як частыну рабочага працэсу:

Retrieve once → answer
Plan → retrieve → inspect → judge evidence → retrieve again → answer

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

Чаму агенты падвышаюць рызык

Чат-бот адпавядае на запытанне. Агент прымечае рашэнні: выбірае інструменты, вызывае API, апдэйтуе запісі, стварае заявкі, рэкамендуе дзеянні, прасіць прызнацію або продовжвае праз многа крокі. Непূরны кантэкст тады распространяецца далей:

Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action

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

Куды прымкнэць агентскі метод адзыскання

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

Адзысканне між корпусамі

Знанні падчорткі не знаходзяцца ў аднай апрантай базе дадзеных. Яны распадзяліцца між Google Drive, Confluence, Notion, Slack, Jira, GitHub, складамі, заявкамі на падтрымку, панелямі мэтрык, внутрашнімі API, документацыяй да продуктав і PDF-інструкцыямі. Хорашая сістэма павінна вярнуцца, дзе спачатку шукаць. Сістэма аналізу запітоў можа класіфікацыяваць запіт як правіла, поведзенне продукту, спецыфічнае для кліента, інцыдэнт, фінансавыя мэтрыкі або тэхнічную залежнасць, і направляць яго адпаведна. Пошук у всім ёсць дорогі, а пошук у неправільным месцы — ўсё горш.

Аналіз запітоў як інструменты

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

search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)

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

Пераследаванне графа знаёмых

Векторны пошук знаходзіць семантычна падобны тэкст, тады калі багатыя практычныя запыты базуюцца на адносах. Калькі кліентаў паўтараецца гэтыяя служба? Калькі продуктов залежыць ад гэтага API? Калькі правіла прыменяецца ў гэтым рэгіоне? Калькі размешчэнне спрычыніла гэты інцыдэнт? Гэтыя ўсе ўпыты прыналежаць да катэгорыі запытоў, якія выкарыстоўваюць кантэкст, а не толькі падобнасць. Граф можа безпасяродна з’яўляць зв’язкі між аб’ектамі:

Customer → Workspace → Feature Flag → Service → Incident → Release Note

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

Оцэнка достатковасці доказаў

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

Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source

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

Графы кантэксту і памяць агента

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

User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch

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

Мультымадальны і дакумент-спрамованы RAG

Большая частка корпаратыўных знанняяў не ў вобразе звычайнага тэксту. Яны знаходзяцца ў PDF-файлах, табліцах, скрыншотах, дыяграмах, формулách, сканах, графіках, прэзентацыях і формах. Звычная сегментацыя псуе структуру: табліцы ператвараюцца на хаотычны тэкст, формулы тырадзяюць свой кантэкст, дыяграмы стаюць рэзультатамі OCR, а часткі аддзеляюцца ад пісьменаў, якія іх апісваюць. Дакумент-спрамованы прайсепт разумее тэкст, табліцы, рысункі, макет, іерархію заглаваў, пісьменаў, поля форм і спосаб, як візуальны матэрыялы адносяцца да прозы. Фінансы, охорона здароў’я, промышленасць, права, страхаванне і тэхнічная дакументацыя найбольш завісяць ад яго.

Бюджэты інструментаў і кантэксту

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

Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window

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

Архітэктура для практычнага выкарыстоўвання

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

User Question
   ↓
Intent + Risk Classifier
   ↓
Retrieval Planner
   ↓
Source Router
   ├── Enterprise Search
   ├── Vector Search
   ├── Keyword Search
   ├── Knowledge Graph
   ├── Structured Data
   ├── Document Parser
   └── Agent Memory
   ↓
Evidence Inspector
   ↓
Sufficiency Gate
   ├── If insufficient → refine query / follow graph / open document
   └── If sufficient → generate answer
   ↓
Answer with Evidence Trace

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

Справа Acme, ад пачатку да канца

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

  1. Шукае ў документах падтрымкі інформацыю пра проблемы з экспортом.
  2. Шукае ў прыметках па выданні змяны, якія з’явіліся пасля міграцыі рабочага прастору.
  3. Ачынае настройкі абліквента.
  4. Пераканальваецца ў статусе фічар-флага.
  5. Шукае історыю інцыдэтаў.
  6. Следуе за графам залежнасцяў ад службы экспорту да службы прав.
  7. Выявляе, чыяму доказы цяпер достатнія.
  8. Пішае адпаведзь з апавяданнямі.

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

Што стварыць перша

Калі у вас вялікі сістэма RAG, не трэба перствараць усё занова. Выконайце этыя крокі па парадку:

  1. Дадзіце перакананне ў достатку. Перш чым генераваць, запытайцеся, чы хутка знайдзеныя доказы достатнія для гэтага конкрэтнага запітання, і калі ні, то або адбейце ўтрохтуючы запыт, або задайце корыстніку дапаможнае запытанне.
  2. Дадзіце можлівасць кэрування выхадным маршрутаўваннем. Пошук у кожны раз у кожным выхадным джэрэле — губліванне часу. Спачатку класіфікуйце запіт: запытанні, якія стосуюцца правіл, падаюць у дакументы з правіламі, проблемы кліентаў — у тыкеты разам з статусам абліквату, тэхнічныя нештаткі — у дакументы, логі і граф сэрвіса, а запытанні, якія стосуюцца метрык, — у сэмантычны слой.
  3. Дадзіце інструменты для адналёгчэння пошуку, такія як search, open, find, summarize, follow_entity_relation і query_structured_record, каб працэс адналёгчэння стаў ітэратыўным.
  4. Дадзіце можлівасць пераходу па графе, калі адпаведзі залежаць ад прыналежнасці, залежнасцяў, лініяй прыналежнасці, каузальнасці, іерархіі, канектаў з калькамі пераходаў аб выключэнняў з правіл.
  5. Зберагачыце структуру дакумента. Для PDF-аў, атласаў, слайдоў, табэлей і дыяграмаў выкорыстоўвайце парсінг, які браць у ўвагу структуру дакумента, і зберагачыце яе, а не проста дзеляйце на часткі.
  6. Зберагаеце следы доказаў, якія фіксуюць шуканыя істочнікі, адкрываныя дакументы, прынятыя факты, знайдзеныя прасоціны і прычыну, чырвону сістэма вырашыла, што ў ёй ўсё ўстаткі. Самэ гэтыя запісы ствараюць довер'е да агентнага падходу RAG.

Чаго не трэба перэабарачваць

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

Змены

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

Vector DB → top-k chunks → LLM

і ўсё такое ж:

Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer

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

plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded

Гэта пераход адз чыстага RAG да агентнага адзысквання. Гэта не таму, што RAG знік. Продакшн-агенты должны розпізнаваць, калі у ўсіх недастатнька інформацыя.

Супаўязаныя матэрыялы

  • Chroma Context-1: 20B-мадэль-падчынны агент для шукання, якая дапамагае стварыць дышэчыя RAG-сістэмы за няжыцей і з вышэй якосцю — як Chroma Context-1 выступае як падчынны агент, які выконвае толькі функцыю адзыскання і сам адсакае свой кантэкст, як яго навучалі, што не хватайце без дапамогі гэтага агента, і ў чым яго слабасці.
  • Agentic RAG: Калі LLM сам адначытае, калі і дзе адзыскваць інфармацыю — чаму статычныя RAG-сістэмы не справляюцца з запытамі, якія выклікаюць кальцыяцыю роўнаў і ў якіх важліва часовая складовая, і як агент LangGraph керуе процэсам адзыскання інфармацыі між Qdrant і веб-шуканнем, урахоўваючы практычныя абмежэнні.
  • Практычныя прытамулы: Даны, Кантэкст і кераванне ляйнэйджам RAG для корпаратыўскага AI — Паследовыя інструкцыі па вікорыстоўванні Практычных прытамулов: Даны, Кантэкст і кераванне ляйнэйджам RAG для корпаратыўскага AI: контракты, перакананні і шаблоны коду для команд, якія рэалізуюць гэты патэрн.
  • Інжынерыя кантэкста для прыкладненняў на асобых большых мовах: структураваныя выходы, інструменты і меры для агентаў — Як правільна ствараць вхідныя даны для мадэлі: выбір кантэкста, шаблоны запытанняў, схемы JSON, обмежаная дэкадавання, вызов інструментаў, цыклы агентаў і меры автонаміі.