Retrieval-ul în proces transformă RAG în memorie de lucru a agentului
Bazele de date vectoriale accesate prin rețea sunt bottleneck-ul silențios din interiorul fiecărui loop de agent lingvistic.
Retrieval-ul în proces transformă RAG în memorie de lucru a agentului
Bazele de date vectoriale accesate prin rețea sunt bottleneck-ul silențios din interiorul fiecărui loop de agent lingvistic. Un preprint nou pe arXiv, Memory in the Loop, susține că soluția este jenabil de fizică: mută indexul în același proces cu agentul. Store-ul lor în proces răspunde în aproximativ 100 de microsecunde — cu trei ordine de mărime mai rapid decât un apel de rețea — și împinge retrieval-ul în ciclul observe-reason-act, în loc să-l lase ca etapă de preprocesare offline.
Argumentul ingineresc este direct. Când retrieval-ul costă 80–200 ms per hop prin gRPC, agenții evită să întrebe. Când costă 100 µs, agentul poate interoga memoria între fiecare pas de raționament fără să simtă diferența. Asta schimbă ce înseamnă „context”: în loc de un singur retrieval masiv înainte de prompt, memoria devine ceva ce modelul consultă la cerere, așa cum un om consultă un caiet în mijlocul unei fraze.
Ce arată de fapt cifrele
Lucrarea raportează recall pe un task sintetic multi-hop crescând de la 0/5 la între 3,6 și 4,8 din 5 atunci când modele de clasă GPT-5 primesc acces in-loop la store-ul vectorial. Apelurile redundante de tool scad — agentul nu mai re-extrage ce are deja — pentru că prețul unui „lasă-mă să verific din nou” se prăbușește.
Noul cost dominant apare imediat: embedder-ul. Un apel de embedding API remote eclipsează acum retrieval-ul propriu-zis. Autorii atenuează asta asociind indexul în proces cu un embedder local mic, aducând ciclul complet embed-plus-search la circa 40 µs.
retrieval:
mode: in_process
index: hnsw
vectors: 2_400_000
dim: 384
embedder:
kind: local
model: bge-small-en-v1.5
device: cpu
p50_us: 38
p99_us: 71
store:
p50_us: 96
p99_us: 210Implicații arhitecturale pentru echipele de agenți
Două consecințe de design rezultă. Prima: runtime-ul agentului și indexul trebuie să împartă același spațiu de adrese, ceea ce exclude deployment-urile serverless FaaS unde amortizarea cold-start-ului ucide bugetul de µs. A doua: embedder-ul devine un SLO de latență de primă clasă — nu o componentă de tip „o schimbăm mai târziu”. Echipele care construiesc sisteme RAG de producție ar trebui să trateze rezidența embedder-ului așa cum bazele de date tratează dimensionarea buffer-pool-ului.
Există un unghi de securitate pe care lucrarea nu-l abordează. Un store în proces împarte domeniul de defecțiune cu agentul: un prompt injection care ajunge la stratul de retrieval poate acum să scrie, nu doar să citească. Guardrail-urile care presupuneau un hop de rețea între agent și memorie trebuie reexaminate în lumina modelelor de amenințare la nivel de retrieval documentate de peisajul de amenințări AI al ENISA și de AI Risk Management Framework al NIST.
Unde se poziționează CAI Technology
Construim runtime-uri de agenți pentru clienți reglementați din mid-market-ul românesc, sub obligațiile Directivei (UE) 2022/2555. Memoria în proces este mai rapidă, dar prăbușește granița de audit între „model” și „baza de cunoștințe” — o graniță care contează pentru auditorii NIS2. Poziția noastră: retrieval-ul in-loop este alegerea corectă din perspectiva latenței, dar necesită logging per apel de retrieval care supraviețuiește în afara procesului. Viteza fără audit trail este o vulnerabilitate, nu un avantaj. Dacă evaluați acest compromis pentru un agent live, discutați cu echipa noastră de inginerie RAG.