Arhitectura unui sistem RAG: componente, fluxuri, decizii

Ai citit despre chunking, embeddings, semantic search, grounding și alegerea modelului de generare. Fiecare piesă are logica ei și se poate învăța separat. Ce lipsește e vederea de ansamblu — arhitectura unui sistem RAG, adică felul în care piesele se leagă între ele. Problema apare exact acolo.

Un sistem RAG care merge în demo și cade în producție are, aproape întotdeauna, piesele corecte și cusăturile greșite. Retrieval-ul întoarce chunk-uri rezonabile, dar orchestratorul nu știe ce să facă cu scorurile. Ingest-ul rulează, dar nu propagă ștergerile. Modelul răspunde curat, dar nu poți reconstitui de unde a luat informația când cineva contestă răspunsul.

Aici tratezi RAG ca sistem, nu ca listă de tehnici: ce componente există, ce contract are fiecare cu vecinele ei, unde trec granițele între ingest și query, ce decizii le iei o singură dată și ce amâni onest până când datele îți cer altceva. Definiția și lanțul conceptual stau în pillarul despre ce este RAG — de acolo pornim, nu le reluăm.

Ce înseamnă „arhitectură” la un sistem RAG

Arhitectura nu e diagrama cu cinci cutii și săgeți între ele. Diagrama aia o desenează oricine în zece minute și nu răspunde la nicio întrebare care contează.

Arhitectura e mulțimea de răspunsuri la trei întrebări: ce contract are fiecare componentă (ce primește, ce garantează, ce returnează când eșuează), cine deține ce stare (unde e sursa de adevăr pentru un document, cine are voie să o modifice) și ce se schimbă des versus ce se schimbă o singură dată.

A treia întrebare e cea care separă un sistem întreținut de unul rescris. Prompt-ul de generare îl schimbi săptămânal. Schema chunk-ului o schimbi o dată și plătești fiecare schimbare ulterioară în ore de reindexare și în retrieval degradat între timp.

De la lanț liniar la componente înlocuibile

Literatura de specialitate a formalizat exact această tranziție. Survey-ul lui Gao și colab. despre RAG pentru LLM-uri descrie trei paradigme succesive: Naive RAG (indexează, caută, citește — lanț fix), Advanced RAG (adaugă pre- și post-procesare în jurul retrieval-ului) și Modular RAG, în care pipeline-ul se descompune în componente independente care pot fi înlocuite, reordonate sau ocolite fără rescrierea sistemului.

Diferența practică nu e academică. Într-un lanț fix, schimbarea strategiei de retrieval înseamnă atingerea codului de generare. Într-o arhitectură modulară, retrieval-ul e un serviciu care respectă un contract, iar generarea nu știe și nu-i pasă dacă în spate rulează căutare densă, hibridă sau o interogare SQL.

Cine deține sursa de adevăr

Regula de care depinde tot restul: indexul vectorial nu e sursa de adevăr, e o proiecție a ei.

Sistemul de origine — CRM-ul, wiki-ul intern, bucket-ul de PDF-uri, baza de date operațională — rămâne autoritatea. Indexul e o vedere derivată, reconstruibilă, care poate fi ștearsă și refăcută fără pierdere de date. Dacă la un moment dat singurul loc în care există un fragment de informație e indexul vectorial, ai o problemă de arhitectură pe care nicio îmbunătățire de retrieval nu o repară.

Consecința e liniștitoare: orice decizie de indexare devine reversibilă cu suficient timp de calcul. Consecința incomodă: trebuie să poți reconstrui indexul de la zero, deci pipeline-ul de ingest trebuie să fie repetabil, nu un script rulat manual acum patru luni.

Harta de componente: ce există într-un sistem RAG complet

Cel mai util mod de a citi un sistem RAG e pe planuri, nu pe pași. Fiecare plan are propriul ritm, propriile moduri de eșec și, de obicei, propriul owner.

Planul de surse și ingest

Conectori către sistemele de origine, parsare, normalizare, segmentare, calculul embedding-urilor, scriere în index. Rulează asincron, în batch sau declanșat de evenimente. Nu are utilizator în fața lui, deci poate fi lent — dar trebuie să fie corect și repetabil.

Aici se decid lucrurile pe care le explorează în detaliu articolul despre pregătirea documentelor pentru o bază de cunoștințe și cel despre strategii de chunking. Din perspectivă arhitecturală, ce contează e că ingest-ul produce artefacte cu identitate stabilă, nu doar „vectori în bază”.

Planul de index și storage

Depozitul de vectori, indexul lexical (dacă ai unul), store-ul de metadate și, separat, textul original al chunk-urilor. Trei observații care se ratează frecvent:

• Textul chunk-ului trebuie păstrat, nu doar vectorul. Fără el nu poți construi contextul și nu poți cita.
• Metadatele sunt parte din index, nu accesoriu. Filtrarea după sursă, dată, tenant sau permisiuni se face în același query cu căutarea vectorială.
• Motorul e o decizie de infrastructură, nu de arhitectură. Comparația între opțiuni stă în analiza pgvector vs Pinecone vs Qdrant vs Weaviate; ce contează aici e că interfața pe care o expui în sus rămâne aceeași indiferent de motor.

Planul de orchestrare a interogării

Componenta care primește întrebarea utilizatorului și decide ce se întâmplă: normalizare și eventual rescriere a interogării, aplicarea filtrelor de autorizare, apelul de căutare, reordonarea rezultatelor, selecția și împachetarea contextului.

E singura componentă care are voie să știe despre toate celelalte. Dacă orchestrarea se împrăștie în trei locuri diferite — puțin în frontend, puțin în handler-ul de API, puțin în wrapper-ul peste baza vectorială — sistemul devine imposibil de depanat exact în momentul în care ai nevoie să-l depanezi.

Planul de generare

Modelul, prompt-ul de sistem, formatul cerut, regulile de citare, gestiunea cazului „nu am găsit destul context”. Criteriile de selecție a modelului le tratează articolul despre cum alegi modelul de generare; în arhitectură, modelul e o componentă cu un contract clar, nu inima sistemului.

Testul e simplu: dacă schimbarea modelului îți sparge altceva decât prompt-ul și parserul de răspuns, granița e prost trasată.

Planul de observabilitate și evaluare

Trace-uri pe fiecare interogare, log-uri structurate pe fiecare rulare de ingest, seturi de evaluare offline, metrici de retrieval și de fidelitate. Nu e „monitorizare”, e capacitatea de a răspunde la întrebarea „de ce a spus asta?” pentru un răspuns emis acum trei săptămâni.

Revenim la el la final, pentru că e planul cel mai des amânat și cel mai scump de adăugat retroactiv.

Ce e obligatoriu și ce nu, la primul release

Lista scurtă de „obligatoriu” e mai lungă decât ți-ar plăcea, dar fiecare rând din ea e acolo pentru că adăugarea lui ulterioară cere migrare de date sau retroactivitate imposibilă. Restul sunt optimizări pe care le adaugi când ai măsurători care le justifică.

Contractele dintre componente

O componentă fără contract explicit e o componentă pe care nu o poți înlocui. Contractele dintr-un sistem RAG sunt patru și merită scrise, nu deduse din cod.

Contractul chunk-ului

Cea mai importantă structură de date din sistem. Un chunk minim viabil are: identificator stabil, identificatorul documentului sursă, poziția în document, textul, vectorul, versiunea parserului, versiunea modelului de embedding, marcaje de permisiune și un timestamp de indexare.

Fiecare câmp de acolo rezolvă o problemă concretă. Poziția îți permite să reconstitui ordinea și să extinzi contextul cu vecini. Versiunea parserului îți spune ce chunk-uri trebuie refăcute când repari parsarea de PDF. Marcajele de permisiune fac posibilă filtrarea la retrieval. Timestamp-ul îți dă prospețimea.

Un chunk care are doar {text, vector} funcționează în demo și te blochează în lună a treia.

Contractul de retrieval

Ce primește orchestratorul înapoi de la căutare, indiferent de motor: lista de chunk-uri, scorul fiecăruia, strategia care l-a produs (dens, lexical, fuziune), sursa citabilă și un motiv explicit când lista e goală.

Ultimul punct e cel ignorat. „Zero rezultate” și „rezultate sub pragul de relevanță” sunt situații diferite, cu răspunsuri diferite către utilizator. Dacă retrieval-ul le colapsează în aceeași listă goală, generarea nu are cum să reacționeze inteligent.

Contractul de context

Ce ajunge efectiv la model: fragmentele selectate, în ce ordine, cu ce etichete de sursă, în ce buget de tokeni. Selecția e o decizie separată de căutare — poți primi douăzeci de chunk-uri și trimite șase.

Bugetul se planifică, nu se descoperă la runtime. Detaliile stau în articolul despre fereastra de context la LLM; arhitectural, ce contează e ca împachetarea contextului să fie o funcție pură, testabilă, nu string concatenat în mijlocul unui handler.

Contractul de răspuns

Textul, citările cu referință la chunk-urile efectiv folosite, un semnal de încredere și starea „context insuficient”. Forma răspunsului o tratează în detaliu articolul despre cum arată un răspuns bun de RAG.

Contractul contează pentru că interfața consumatoare — chat, widget, API — se construiește peste el. Dacă citările sunt text liber în răspuns și nu structură separată, nu poți face niciodată linkuri clicabile fără să parsezi limbaj natural.

Pipeline de ingest versus path de query: două sisteme diferite

Cea mai frecventă eroare de proiectare e tratarea RAG-ului ca un singur flux. Sunt două sisteme cu obiective opuse, care se ating într-un singur punct.

Ingest: corectitudine peste latență

Rulează offline. Poate dura ore. Poate fi reluat. Trebuie să fie idempotent — a doua rulare pe aceleași date produce exact același index, nu duplicate.

Modurile lui de eșec sunt tăcute: un job care crapă la jumătate lasă indexul într-o stare parțială, iar căutarea continuă să funcționeze, doar cu rezultate mai proaste. Nimeni nu primește o alertă, pentru că nimic nu a returnat 500.

Query: latență peste completitudine

Rulează online, sub un buget de câteva sute de milisecunde până la primul token. Nu poate aștepta reindexarea, nu poate repara date proaste, nu are voie să eșueze silențios.

Modurile lui de eșec sunt vizibile, dar prost atribuite: utilizatorul vede un răspuns slab și nu are cum să știe dacă a fost retrieval, selecție de context sau model. De asta trasarea nu e opțională.

Ce le leagă

Singurul punct de contact e indexul. Dacă path-ul de query cheamă vreodată direct un parser sau un conector, ai lipit cele două sisteme și ai importat latența ingest-ului în experiența utilizatorului.

Cazurile în care cusătura asta cedează sunt catalogate în articolul despre de ce eșuează un sistem RAG în producție. Aici ne interesează deciziile de proiectare care le previn.

Deciziile care te costă scump dacă le schimbi

Nu toate deciziile sunt egale. Unele se schimbă cu un deploy, altele cu o migrare de date și o fereastră de calitate degradată. Pe astea din urmă merită să le gândești înainte.

Identificatorii stabili și schema chunk-ului

Regula, formulată explicit în ghidul Unstructured despre problemele de RAG în producție: fiecare chunk are un identificator determinist, derivat din id-ul documentului și din poziția în el, astfel încât un update să înlocuiască exact ce trebuie. Aceeași sursă tratează indexarea incrementală ca cerință de corectitudine, nu ca optimizare de performanță.

Practica din sistemele publicate merge în aceeași direcție: o constrângere de unicitate pe perechea (id document, index chunk) face reluările sigure, iar o sarcină periodică de curățare elimină vectorii rămași orfani.

Fără identificatori stabili apare ce analiza Oracle despre index drift numește divergență între sursă și index: sursa s-a schimbat, chunk-urile nu. Rezultatul e evidență expirată, embedding-uri orfane, chunk-uri duplicate care concurează între ele în retrieval și citări către documente care nu mai există.

Ștergerea e partea cea mai neplăcută. În indexurile de tip HNSW, ștergerea marchează de obicei vectorul ca tombstone, fără eliminare reală până la o reconstrucție de index — deci „am șters documentul din sursă” și „documentul nu mai poate fi returnat” sunt două afirmații diferite până demonstrezi contrariul.

Modelul de embedding și strategia de reindexare

Un vector produs de modelul v1 și unul produs de v2 pentru același text trăiesc în spații diferite. Nu există transformare în loc care să facă vectorii vechi valabili, iar amestecarea celor două generații în același index produce vecini din vecinătăți greșite — cu atât mai periculos când cele două modele au aceeași dimensionalitate, pentru că nimic nu crapă, doar rezultatele devin tăcut greșite.

Documentația Qdrant descrie migrarea recomandată ca operațiune blue-green: colecție nouă configurată pentru modelul nou, scriere dublă pe ambele, re-embedding în fundal, apoi comutare. Aceeași documentație menționează și varianta cu vectori numiți, disponibilă în versiuni recente, care evită copierea datelor și face rollback-ul trivial.

Consecința arhitecturală, indiferent de motor: aplicația nu trebuie să cunoască niciodată numele fizic al indexului. Referă un alias sau un pointer de configurare, ca înlocuirea să fie o comutare atomică, nu un deploy.

Și pune versiunea modelului de embedding în metadatele fiecărui chunk. E singurul mod de a detecta programatic că ai două generații în același index.

Unde stă granița de autorizare

Dacă datele au permisiuni, ai o singură decizie corectă și e ireversibilă în practică: filtrul de autorizare se aplică înainte de căutare, nu după.

Tiparul greșit — cauți top-k fără filtre, apoi arunci ce nu are voie utilizatorul să vadă — pare rezonabil și e problematic din două motive. Chunk-urile neautorizate au influențat deja scorul și ordinea, deci utilizatorul primește un top-k sărăcit fără să știe. Și datele au fost deja aduse în memorie, deci granița de securitate a fost trecută înainte de verificare.

Documentația Cerbos pe control de acces pentru RAG descrie alternativa: politicile se traduc în filtre native ale bazei vectoriale, aplicate înainte ca datele să fie aduse. Beneficiul secundar e auditabilitatea — poți loga ce date au fost expuse, cui și sub ce politică.

Implicațiile de conformitate le tratează articolul despre RAG și GDPR. Decizia arhitecturală e mai simplă și mai devreme: marcajele de permisiune fac parte din schema chunk-ului, nu dintr-un strat adăugat ulterior. Retroactivarea lor înseamnă reindexare completă.

Cum arată filtrul concret în fiecare motor, ce faci cu ACL-uri prea complexe pentru un câmp de metadate și ce se întâmplă când un drept e revocat după indexare sunt tratate în controlul accesului în RAG.

Granularitatea sursei citabile

O decizie subtilă cu efecte lungi: ce citezi — documentul, secțiunea sau chunk-ul? Alegerea determină ce metadate păstrezi la ingest, cum arată interfața și cât de verificabil e răspunsul.

Citarea la nivel de document e ieftină și aproape inutilă pentru un manual de 400 de pagini. Citarea la nivel de chunk e verificabilă, dar cere ancore stabile către poziția din documentul original. Alegerea o faci înainte de a indexa, pentru că ancorele se produc la parsare.

MVP onest versus arhitectură matură

Un MVP onest nu e o versiune stricată a sistemului final. E sistemul final cu componentele opționale absente și cu granițele deja trasate corect.

Ce livrezi în primul release

Un singur tip de sursă. O singură strategie de chunking. Căutare densă, fără hibrid. Fără reranker. Un singur model de generare. Citare la nivel de chunk. Trace-uri complete. Un set de evaluare mic, dar real — douăzeci până la cincizeci de întrebări cu răspunsuri așteptate, scrise de cineva care cunoaște domeniul.

Ce nu tai niciodată: identificatorii stabili, filtrul de autorizare, trace-urile și setul de evaluare. Astea patru sunt scumpe retroactiv și ieftine de la început.

Ce adaugi și când

Fiecare rând cere o măsurătoare, nu o intuiție. Motivele pentru care căutarea hibridă și reordonarea ajută sunt detaliate în articolul despre hybrid search și reranking; ce contează arhitectural e că le adaugi în interiorul contractului de retrieval, fără ca generarea să afle. Descompunerea multi-hop e cazul aparte din tabel: nu mai e un adaos în interiorul unui pas, ci un al doilea pas de căutare decis la runtime — mecanica ei, bugetul de pași și costul buclei sunt tratate în articolul despre agentic RAG și multi-hop.

Semnalul că ai sărit peste o etapă

Dacă adaugi un reranker fără să poți arăta că recall-ul e bun și precizia slabă, nu optimizezi — ghicești. Ordinea corectă e: măsoară, izolează componenta responsabilă, schimbă un lucru, măsoară din nou.

Asta presupune că poți măsura. Ceea ce ne duce la ultimul plan.

Observabilitatea ca parte din arhitectură

Observabilitatea într-un sistem RAG nu înseamnă un dashboard cu latențe. Înseamnă capacitatea de a răspunde, pentru un răspuns emis oricând în trecut, la întrebarea: ce a căutat sistemul, ce a găsit, ce a ales să trimită modelului și ce a răspuns modelul.

Ce trebuie să poți reconstitui

Pentru fiecare interogare: textul întrebării după normalizare, filtrele aplicate, identificatorii chunk-urilor returnate cu scorurile lor, care dintre ele au intrat efectiv în context, versiunea prompt-ului, modelul și parametrii, răspunsul și citările.

Cu setul ăsta poți răspunde la orice reclamație. Fără el, singura opțiune e să reproduci interogarea acum — pe un index care s-a schimbat între timp.

Convenții, nu invenții proprii

Merită să te aliniezi la un vocabular comun în loc să inventezi nume de atribute. Convențiile semantice GenAI din OpenTelemetry definesc deja o operațiune retrieval pentru pasul de căutare dintr-un pipeline RAG, alături de chat, embeddings, execute_tool și invoke_agent.

Două precizări oneste. Convențiile sunt marcate ca fiind în stadiul Development — nu au ajuns la stabilitate, iar numele se pot schimba între versiuni. Iar mutarea atributelor gen_ai.* într-un repository dedicat, odată cu versiunea 1.42.0 din iunie 2026, e o schimbare organizațională de cadență, nu o promovare la stable.

Postura practică: adoptă forma acum, fixează versiunea față de care construiești și izolează numele de atribute după un strat subțire de mapare în codul tău. Câștigi standardizarea fără să pariezi pe nume care încă se pot mișca.

Evaluarea offline face parte din pipeline

Un set de evaluare care rulează la fiecare schimbare de chunking, de model sau de prompt e diferența dintre „am îmbunătățit ceva” și „cred că am îmbunătățit ceva”. Metricile concrete și modul de construire a setului le tratează articolul despre cum evaluezi un sistem RAG.

Arhitectural, ce contează e că evaluarea are nevoie de aceleași contracte ca producția. Dacă poți apela retrieval-ul și împachetarea contextului ca funcții separate, evaluarea e ușoară. Dacă totul trăiește într-un singur handler HTTP, evaluarea devine testare end-to-end lentă și nediagnostică.

De la arhitectură la implementare

Toate deciziile de până acum sunt agnostice de stack. Sunt valabile indiferent dacă rulezi pe Postgres cu pgvector, pe un serviciu gestionat sau pe ceva self-hosted.

Traducerea lor într-o implementare concretă — rute, streaming, gestiunea stării, apeluri către modele — e subiectul articolului despre construirea unui sistem RAG cu Next.js și Vercel AI SDK. Ordinea recomandată e exact asta: întâi granițele și contractele, apoi codul. Invers se poate, dar se plătește la prima reindexare.

Restul clusterului, cu fiecare componentă tratată separat, stă în Fundamentele RAG, iar contextul de serviciu în AI & RAG.

Întrebări frecvente

Câte componente sunt strict obligatorii într-un sistem RAG?

Șase: ingest cu identificatori stabili, index vectorial cu metadate, store pentru textul chunk-urilor, orchestrator de interogare, generare cu citare și trasare per interogare. Dacă datele au permisiuni, filtrul de autorizare la retrieval devine al șaptelea. Restul — hibrid, reranking, rescriere de interogare, cache, routing — sunt adaosuri pe care le justifici cu măsurători.

Pot să adaug căutarea hibridă mai târziu fără să rescriu sistemul?

Da, dacă retrieval-ul are un contract explicit. Fuziunea între căutarea densă și cea lexicală se întâmplă în interiorul componentei de retrieval, iar orchestratorul primește aceeași structură de rezultate ca înainte. Dacă în schimb generarea apelează direct baza vectorială, adaosul devine refactorizare.

Cât de scumpă e schimbarea modelului de embedding după lansare?

Costul e re-embedding-ul întregului corpus plus fereastra de migrare. Vectorii vechi nu pot fi convertiți — spațiile sunt incompatibile. Tiparul sigur e blue-green: index nou în paralel, scriere dublă, validare, comutare atomică prin alias. Dacă aplicația referă indexul după nume fizic, adaugi și un deploy riscant peste migrare.

Unde pun granița între ce indexez și ce interoghez live?

Documentele beneficiază de indexare; rândurile operaționale care se schimbă des, de obicei nu. Un preț, un stoc sau un status de comandă se citesc live din sistemul de origine și se injectează în context ca date structurate. Re-embedding-ul unei valori care se schimbă la fiecare cinci minute e efort irosit și sursă de răspunsuri expirate.

Ce înseamnă concret „observabilitate” pentru un sistem RAG?

Pentru fiecare răspuns emis, capacitatea de a reconstitui interogarea normalizată, filtrele aplicate, chunk-urile returnate cu scoruri, cele intrate efectiv în context, versiunea prompt-ului, modelul și răspunsul. Un dashboard de latențe nu răspunde la niciuna dintre întrebările care apar când cineva contestă un răspuns.

Cum arată un MVP care nu blochează evoluția?

Un tip de sursă, o strategie de chunking, căutare densă, un model, fără reranker — dar cu identificatori stabili, marcaje de permisiune în schema chunk-ului, trace-uri complete și un set de evaluare de câteva zeci de întrebări reale. Componentele lipsă se adaugă ușor; cele patru din urmă se retroactivează greu.

Dacă ai deja un sistem RAG în producție și nu poți răspunde la „de unde a venit propoziția asta?” pentru un răspuns de acum trei săptămâni, problema nu e retrieval-ul — e că observabilitatea a rămas în afara arhitecturii. Începe de acolo, înainte de orice optimizare.