Agentic RAG și multi-hop: când un pas de retrieval nu ajunge

Ai un sistem RAG care merge. Documentele sunt indexate, retrieval-ul întoarce pasaje relevante, răspunsurile citează sursele. Apoi cineva întreabă: „care furnizor a crescut cel mai mult prețul față de contractul de anul trecut și ce clauză permite renegocierea?” Sistemul întoarce ceva plauzibil. Și greșit.

Nu e o problemă de chunking, nici de reranking, nici de model. E o problemă de formă. Întrebarea are trei salturi — găsește contractele, compară creșterile, caută clauza din contractul câștigător — iar pipeline-ul are un singur pas de căutare. Un pas nu poate returna un lanț de dovezi despre care nu știe încă că îl caută.

Aici e granița de sus a RAG-ului clasic. Dincolo de ea începe agentic RAG: retrieval cu buclă de decizie, în care modelul hotărăște dacă mai caută, ce caută și când se oprește. Articolul explică ce clase de întrebări cer bucla, cum funcționează mecanic multi-hop-ul, ce aduce tool use, cât costă totul în latență și predictibilitate, și cum decizi onest dacă ai nevoie — în loc s-o adopți fiindcă e la modă.

Unde se oprește retrieval-ul într-un singur pas

RAG-ul clasic e o funcție cu o direcție: primești întrebarea, o transformi în vector, cauți, pui pasajele în prompt, generezi. Un pas, un cost, o latență previzibilă. Pentru majoritatea întrebărilor dintr-o bază de cunoștințe, exact asta trebuie.

Problema apare când răspunsul nu există într-un singur loc și nici măcar nu poate fi găsit dintr-o singură interogare, fiindcă a doua căutare depinde de rezultatul primeia.

Cele cinci forme care nu încap într-un pas

Compoziționale (multi-hop propriu-zis). „Cine a semnat contractul cu furnizorul care ne livrează componenta X?” Ca să cauți semnatarul, trebuie mai întâi să știi furnizorul. Literatura de multi-hop QA numește asta chaining: fapte intermediare înlănțuite până la răspunsul final.

Comparative și de agregare. „Care dintre cele patru politici de retur e cea mai permisivă?” Nu există un pasaj care conține comparația. Există patru pasaje care trebuie găsite separat și puse cap la cap.

Temporale și de versiune. „Ce s-a schimbat în procedura de onboarding față de anul trecut?” Cere două stări ale aceluiași document și o diferență între ele.

Vagi sau ambigue. „De ce ne merge prost pe zona de retenție?” Prima interogare nu are ce să găsească, fiindcă întrebarea nu conține încă termenii care contează. Are nevoie de un pas de explorare înainte de un pas de precizie.

Pe date structurate. „Câte comenzi peste 5.000 EUR au fost anulate luna trecută?” Răspunsul nu e într-un document, e într-o bază de date. Similaritatea semantică nu are ce să caute.

De ce „mai mult top-k” nu rezolvă

Reflexul e să crești k. Dacă un pasaj nu e suficient, adu douăzeci. Nu merge, din două motive.

Primul: la întrebările compoziționale, pasajul care conține al doilea salt nu e similar semantic cu întrebarea inițială. Nu e pe locul 20, nu e nici pe locul 200 — nu apare deloc în topul candidaților, fiindcă întrebarea nu conține entitatea de care depinde.

Al doilea: contextul plin taxează raționamentul. Un studiu din 2026 pe sarcini agentice de reparare de cod a măsurat exact asta: traiectoriile reușite rămân în general sub 20.000–30.000 de tokeni, iar contextele acumulate mai lungi corelează cu rate de succes mai mici. Autorii concluzionează că succesul vine din descompunerea sarcinii în pași cu context scurt, nu din raționamentul pe context lung. Aceeași dinamică pe care o discută fereastra de context la LLM se aplică și aici.

Merită separat un lucru: dacă întrebarea are un singur salt și tot iese prost, nu ai o problemă de arhitectură, ai o problemă de calitate a retrieval-ului. Acolo lucrează hybrid search și reranking — fuziune între căutare lexicală și semantică, apoi reordonare. Rezolvă un pas, mai bine. Nu adaugă un al doilea.

Bucla de decizie: ce înseamnă să dai modelului controlul

Arhitectura unui sistem RAG tratează descompunerea multi-hop ca pe un adaos declanșat de un semnal. Aici intri în mecanica lui.

Diferența nu e că apar mai mulți pași. Diferența e cine decide câți. Într-un pipeline clasic, numărul de pași e fix și scris de tine. Într-o buclă, modelul îl alege la runtime.

Cele trei decizii

Bucla mută trei decizii din cod în model:

1. Dacă să caute. Nu orice întrebare are nevoie de retrieval. „Rezumă ce mi-ai spus mai sus” nu are. O căutare inutilă adaugă zgomot și cost.
2. Ce să caute. Modelul reformulează întrebarea, o descompune în sub-întrebări sau alege sursa: documente, bază de date, API.
3. Dacă să mai caute. După fiecare pas, evaluează dovezile strânse: sunt suficiente pentru un răspuns onest sau lipsește ceva anume?

A treia e cea care contează și cea mai prost implementată. O evaluare de forma „mai am nevoie de informații” nu ajută la nimic — următoarea căutare va fi identică cu precedenta. O evaluare utilă numește golul: „am prețul din contractul A și B, îmi lipsește data de reînnoire pentru B”.

Anatomia unei iterații

O iterație are patru momente, în ordine:

• Plan — ce vreau să aflu în pasul ăsta, exprimat ca interogare, nu ca intenție.
• Retrieve — apelul propriu-zis, cu parametrii aleși de model.
• Judecă — ce am strâns până acum, ce lipsește, e suficient?
• Decide — răspund, mai caut, sau mă opresc și spun că nu știu.

Al patrulea moment e produsul. Un sistem care nu are ramura „mă opresc și spun că nu știu” nu are o buclă, are o spirală.

Unde e granița cu agenții autonomi

Aici e ușor să aluneci. Agentic RAG înseamnă că modelul controlează retrieval-ul: caută, citește, decide, caută din nou. Rezultatul e un răspuns cu surse.

Un agent AI autonom merge mai departe: execută acțiuni în sisteme externe — creează un tichet, trimite un email, modifică o înregistrare. Rezultatul e o schimbare de stare undeva în afara conversației.

Granița practică e simplă: dacă cel mai rău lucru pe care îl poate face bucla e să dea un răspuns prost, ești în agentic RAG. Dacă poate strica ceva ireversibil, ești în teritoriu de agent și ai nevoie de alt set de garanții — permisiuni, confirmări, audit.

Tool use: retrieval-ul ca unul dintre mai multe instrumente

Odată ce modelul poate apela căutarea de mai multe ori, apare o extindere naturală: dacă poate apela un instrument, poate apela mai multe. Sinteza pe surse eterogene devine posibilă.

Survey-ul despre agentic RAG publicat de Singh și colegii în 2025 pune tool use printre tiparele de bază ale paradigmei, alături de reflecție, planificare și colaborare între agenți.

Instrumentele care chiar câștigă un loc

În practică, patru tipuri de tool acoperă majoritatea cazurilor:

Un studiu din 2026 pe baze de cunoștințe enterprise a raportat că factorul cel mai important din ablații a fost chiar trecerea de la retrieval într-un pas la tool use iterativ, nu rafinările din interiorul stack-ului de căutare.

Text-to-SQL: unde tool use devine periculos

Datele structurate sunt cazul cel mai tentant și cel mai înșelător. Întrebarea „câte comenzi au fost anulate luna trecută” e trivială pentru SQL și imposibilă pentru similaritate vectorială. Deci dai modelului un tool care scrie SQL.

Aici numerele cer prudență. Pe Spider 1.0, benchmark-ul academic clasic, acuratețea raportată trece de 90%. Pe Spider 2.0 — construit special ca să semene cu realitatea enterprise, cu scheme de peste 1.000 de coloane și dialecte multiple — autorii raportează 21,3% pentru un framework agentic de tip code agent, față de 91,2% pe Spider 1.0 și 73,0% pe BIRD. Autorii benchmark-urilor avertizează explicit că cifrele nu sunt direct comparabile între seturi, fiindcă metricile și protocoalele diferă.

Concluzia practică nu e „nu folosi text-to-SQL”. E: pe o schemă mică, curată și documentată, merge bine; pe un warehouse real, tratează-l ca pe un draft care are nevoie de validare, nu ca pe un răspuns.

Contractul unui tool

Un tool prost descris strică bucla mai rău decât lipsa lui. Trei lucruri contează:

• Descrierea — spune ce face și, mai ales, ce nu face. „Caută în documentația tehnică” e altceva decât „caută în tot intranetul”.
• Parametrii — puțini și tipizați. Fiecare parametru liber e o ocazie de a-l apela greșit.
• Eroarea — ce întoarce când nu găsește nimic. Un rezultat gol tăcut arată identic cu un rezultat gol legitim, iar modelul nu poate distinge.

Tool use presupune un model care suportă nativ apelarea de funcții și o face fiabil sub presiune. Asta e o precondiție de selecție, tratată în cum alegi modelul de generare, nu un detaliu de implementare.

Bugetul de pași: ce cumperi și ce plătești

Aici se decide dacă sistemul e utilizabil sau doar impresionant în demo.

Câți pași cumpără de fapt calitate

Un studiu de ablație publicat pe arXiv în 2026 a rulat opt configurații controlate pe 5.000 de întrebări din setul HotpotQA (varianta cu distractori), cu un model local de 7B. Pipeline-ul complet a obținut EM 53,2% și F1 61,6%, față de 43,1% / 54,0% pentru retrieval dens într-un singur pas.

Câștigul e real. Dar detaliul care contează pentru arhitectură e altul: două iterații de retrieval au capturat 95% din câștigul a cinci iterații, fără beneficiu semnificativ de la bucle mai adânci. În plus, rutarea adaptivă bazată pe reguli a ieșit sub retrieval-ul hibrid fix, fiindcă euristica se declanșa pe entități prezente în aproape toate sub-întrebările.

Concluzia autorilor: pe un buget fix, alegerile simple și fixe sunt competitive sau mai bune decât variantele adaptive, iar cea mai mare parte a câștigului vine din faptul că bucla există și e scurtă, nu din adâncimea ei.

Un studiu din 2026 pe reparare agentică de configurații de rețea a găsit un tipar similar în altă direcție: câștigurile cele mai vizibile apar în primele 10–20 de iterații, cu randament descrescător după.

Condiții de oprire, în ordinea în care le scrii

1. Suficiență — modelul declară că are dovezile necesare. Semnalul de calitate, dar cel mai puțin de încredere.
2. Plafon dur de iterații — un număr fix, nenegociabil. Sursele practice recomandă în general 3 iterații de retrieval ca prag de siguranță.
3. Plafon de apeluri de tool — separat de iterații, fiindcă un pas poate apela mai multe instrumente.
4. Plafon de context — raportat la fereastra utilă, nu la cea declarată.
5. Timebox pe ceas — indiferent ce se întâmplă, la N secunde răspunzi cu ce ai.

Primul e o preferință. Celelalte patru sunt siguranțe. Le scrii pe toate.

Ce faci când bugetul se termină

Degradare grațioasă, nu tăcere. Când o limită se declanșează, răspunsul corect e explicit: ce s-a găsit, ce nu s-a găsit, ce ar debloca răspunsul. Un „nu am găsit suficiente informații despre X” e un rezultat util. Un răspuns sintetizat din dovezi incomplete, fără avertisment, e o halucinație cu pași în plus.

Până aici, partea pe care o cumperi. Urmează partea pe care o plătești.

Fiecare iterație e un apel de model în plus, plus tokeni de context care se acumulează. Costul nu crește liniar cu numărul de pași — crește mai repede, fiindcă fiecare pas cară cu el ce s-a strâns înainte.

Multiplicatorul de cost

Sursele practicienilor converg pe un ordin de mărime de aproximativ 3–10× mai mulți tokeni față de RAG-ul într-un pas, cu latență de câteva ori mai mare. Sunt estimări de practică, nu măsurători controlate — tratează-le ca interval, nu ca valoare.

Măsurătorile publicate pe sarcini agentice apropiate dau ceva mai multă textură. Pe repararea de configurații de rețea, cu buget de 30 de pași, costul pe sarcină a crescut de aproximativ 4–5× față de varianta monolitică, în funcție de model. Domeniul e altul, dar ordinul de mărime se potrivește.

Pentru cum se compun costurile pe restul stivei, cât costă un sistem RAG tratează build-ul și operarea separat.

Latența nu mai e o constantă

Asta e schimbarea de care produsul se lovește primul. Într-un pipeline fix, latența are o distribuție îngustă: aproape toate răspunsurile vin în aceeași fereastră de timp.

Cu o buclă, distribuția are coadă. O întrebare simplă se rezolvă într-o iterație, una grea în patru. Media rămâne acceptabilă, iar p95 se dublează sau mai rău. Dacă interfața nu comunică nimic în timpul ăsta, utilizatorul crede că sistemul a murit — motiv pentru care produsele care fac asta bine arată pașii în timp real.

Nedeterminism: același input, alt traseu

Într-un pipeline clasic, aceeași întrebare produce același set de pasaje. Reproducibilitate, cache, debugging previzibil.

Cu buclă, două rulări identice pot lua trasee diferite. Consecințele sunt operaționale, nu teoretice:

• Cache-ul devine parțial. Poți memora rezultatele de retrieval, nu traiectoria.
• Bugetul devine o distribuție. Nu mai poți spune „un răspuns costă X”, ci „un răspuns costă între X și 5X”.
• Un bug se reproduce greu. Fără trace pe fiecare pas, ai doar răspunsul final și nicio idee unde s-a rupt lanțul.

Modurile de eșec pe care le introduce bucla

Modurile clasice de eșec ale RAG-ului — chunking prost, retrieval slab, context prea plin — rămân toate valabile. Bucla adaugă peste ele trei tipare proprii.

Retrieval thrash

Agentul optimizează local. La fiecare pas întreabă „am destul?”, iar când nu e sigur, comportamentul implicit e „mai caută”. Fără reguli dure de oprire, asta devine o spirală: interogări aproape identice, termeni care oscilează între general și specific, calitate a răspunsului plată de la o iterație la alta.

Nu e o problemă ipotetică. Analizele din 2026 pe tiparele de eșec ale sistemelor agentice notează că până și tutorialul oficial de agentic RAG al unui framework popular avea exact acest bug: o buclă de retrieval fără sfârșit, rezolvată prin adăugarea unui contor de rescrieri. Iar un survey de RAG semnalează comportamentele repetitive drept problemă de fiabilitate cu remedii cunoscute: criterii ferme de terminare, detectoare de buclă, politici de fallback.

Semnalul în trace: numărul de iterații crește, calitatea răspunsului stă pe loc.

Context bloat

Pasajele se acumulează de la o iterație la alta. La a treia rundă, contextul conține de câteva ori mai mult material decât ar fi trebuit, mult din el redundant. Atenția modelului se subțiază exact când raționamentul e mai greu.

Remediile sunt mecanice: deduplicare între iterații, păstrarea unui top-K restrâns pe rundă, comprimarea dovezilor vechi în rezumate. Semnalul: tokenii de context cresc, iar respectarea instrucțiunilor se degradează.

Drift de raționament

Cel mai insidios. O ipoteză greșită la pasul doi orientează căutarea de la pasul trei, iar dovezile găsite o confirmă — fiindcă au fost căutate ca s-o confirme. Eroarea nu se corectează, se acumulează. La final ai un răspuns coerent, cu surse, construit pe o premisă falsă.

Un detaliu interesant: cercetarea de securitate din 2026 arată că bucla taie în ambele sensuri. Atacurile prin injectare de documente otrăvite, eficiente pe RAG-ul într-un pas, funcționează mai prost pe sistemele cu buclă, fiindcă dovada otrăvită poate fi ignorată sau suprascrisă de pașii următori. Atacurile care reușesc sunt cele care manipulează susținut lanțul de raționament — adică exact drift-ul, provocat intenționat.

Ce se schimbă la evaluare

Metricile de evaluare a unui sistem RAG rămân valabile: context precision, recall, faithfulness, relevanța răspunsului. Definițiile nu se schimbă. Se schimbă ce mai trebuie măsurat pe lângă ele.

Răspunsul nu mai e singurul artefact

Într-un pipeline fix, ai o intrare și o ieșire. Evaluezi ieșirea.

Într-o buclă, între intrare și ieșire există o traiectorie: ce a căutat, în ce ordine, ce a decis la fiecare pas. Două sisteme pot da același răspuns corect, unul în două iterații și altul în șapte. Al doilea costă de trei ori mai mult și e mult mai fragil, iar metricile de răspuns nu văd nicio diferență.

Metrici de traiectorie

Practica de evaluare a sistemelor agentice a convertit asta în măsurători concrete:

• Eficiența pașilor — raportul dintre pașii așteptați și pașii efectivi. Sub 1 înseamnă ocolișuri, peste 1 înseamnă scurtături care pot fi bune sau riscante.
• Calitatea traiectoriei — un judecător care evaluează dacă traseul avea sens pentru întrebarea pusă, nu doar dacă era scurt. Unele întrebări chiar merită șapte pași.
• Corectitudinea apelurilor de tool — a ales instrumentul potrivit, cu parametrii potriviți?
• Rata de oprire pe plafon — ce procent din răspunsuri au ieșit din buclă prin timeout sau limită, nu prin suficiență. E indicatorul de sănătate cel mai direct.

Bugetul devine metrică de produs

Trei numere merită să stea pe același dashboard cu acuratețea: cost mediu pe răspuns, pași mediani pe răspuns și latența la p95. Fără ele, o regresie de calitate arată identic cu o regresie de cost, iar cauza reală rămâne invizibilă până la factură.

Un detaliu de metodă: setul de evaluare trebuie să conțină explicit întrebări simple, nu doar grele. Altfel nu poți detecta cel mai frecvent eșec de proiectare — bucla care se declanșează pe întrebări care nu aveau nevoie de ea.

Ai nevoie de agentic RAG?

Criteriul nu e „e la modă”. Nu e nici „e mai avansat”. E dacă întrebările reale ale utilizatorilor tăi au forma care cere mai mult de un pas.

Trei semnale că da

• Distribuția întrebărilor. Iei un eșantion real de o sută de întrebări din log-uri și numeri câte au două sau mai multe salturi. Dacă trec de un sfert, ai un caz.
• Eșecul e de formă, nu de calitate. Ai încercat deja hybrid search, reranking, chunking mai bun. Întrebările simple s-au îmbunătățit, cele compuse au rămas la fel de proaste. Ăsta e semnalul cel mai clar.
• Surse eterogene. Răspunsul corect are nevoie de documente și de o interogare pe baza de date, în aceeași conversație.

Trei semnale că nu

• Volum mare, întrebări simple. Un asistent de FAQ sau de căutare în documentație plătește multiplicatorul de cost fără să câștige nimic.
• Latența e constrângere de produs. Dacă răspunsul trebuie să vină sub două secunde, o buclă cu patru iterații nu încape, oricât ai optimiza.
• Nu ai încă evaluare. Fără un set de test și metrici de bază, adaugi nedeterminism peste un sistem pe care nu-l poți măsura. Ordinea corectă e invers.

Calea de mijloc

Cel mai rezonabil tipar în producție nu e „totul agentic”, ci rutare pe complexitate: un clasificator ieftin separă întrebările simple de cele compuse și trimite doar minoritatea pe traseul cu buclă. Costul rămâne mărginit, calitatea crește exact unde era problema.

Ordinea de construcție care funcționează:

1. Construiește RAG-ul într-un pas și instrumentează-l.
2. Identifică formele de întrebare unde eșuează sistematic.
3. Adaugă bucla doar pentru acele forme, cu buget de pași și condiții de oprire de la început.
4. Măsoară traiectoria, nu doar răspunsul.

Un studiu comparativ din 2026 arată de ce ordinea contează: descompunerea interogării a adus câștiguri consistente pe un domeniu structurat, dar a degradat precizia ordonării pe un benchmark de multi-hop, iar mecanismul de reflecție a îmbunătățit acuratețea citărilor cu un cost substanțial în latență. Aceeași tehnică, rezultate opuse, în funcție de date. Nu poți ști dinainte care se aplică la tine — poți doar să măsori.

Întrebări frecvente

Care e diferența dintre agentic RAG și un agent AI?

Agentic RAG dă modelului control asupra retrieval-ului: decide dacă, ce și de câte ori caută, iar rezultatul e un răspuns cu surse. Un agent AI execută acțiuni în sisteme externe și schimbă stare — creează tichete, trimite mesaje, modifică înregistrări. Prima categorie riscă un răspuns prost, a doua riscă o operație greșită.

Câte iterații de retrieval sunt suficiente?

Datele publicate sugerează că majoritatea câștigului apare în primele două iterații, cu randament rapid descrescător după. Un plafon dur de trei iterații e un punct de plecare rezonabil, ajustat apoi pe datele tale — cu observația că plafonul e o siguranță, nu o țintă.

Multi-hop se poate rezolva fără buclă?

Parțial. Descompunerea interogării în sub-întrebări generate dinainte, urmată de retrieval paralel, acoperă cazurile în care sub-întrebările sunt independente. Când a doua căutare depinde de rezultatul primeia, ai nevoie de secvențialitate — adică de buclă.

Cum împiedici bucla să ruleze la nesfârșit?

Cu limite care nu depind de judecata modelului: plafon de iterații, plafon de apeluri de tool, plafon de context și timebox pe ceas. Declararea de suficiență a modelului e un semnal util, dar nu o garanție. Când o limită se declanșează, sistemul răspunde cu ce are și spune explicit ce lipsește.

Merită agentic RAG pentru un chatbot intern de documentație?

De obicei nu. Întrebările de documentație au majoritar un singur salt, iar volumul mare face multiplicatorul de cost dureros. Investește întâi în calitatea retrieval-ului într-un pas și adaugă bucla doar dacă log-urile arată o categorie clară de întrebări compuse care eșuează sistematic.

Ce model îți trebuie pentru tool use?

Unul care suportă nativ apelarea de funcții și rămâne fiabil pe mai multe runde, nu doar la primul apel. Modelele mici gestionează prost deciziile de oprire și tind să supra-apeleze instrumentele. Selecția e o precondiție a arhitecturii, nu un detaliu ulterior.

De unde începi

Nu de la framework. De la o listă.

Ia zece până la douăzeci de întrebări reale la care sistemul actual răspunde prost și clasifică-le: câte au un singur salt și câte au mai multe? Dacă majoritatea au unul singur, banii sunt mai bine investiți în retrieval mai bun pe un pas. Dacă o treime au două sau mai multe, ai justificarea pentru buclă — și, odată cu ea, obligația de a-i pune buget și condiții de oprire înainte de prima linie de cod.

Restul stivei e acoperit pas cu pas în Fundamentele RAG, iar contextul de implementare, în serviciul AI & RAG.