RO
English (English)
Un model lingvistic poate cunoaște multe despre lume, dar nu știe automat care este ultima versiune a procedurii tale interne, ce s-a decis într-o ședință, ce clauză se aplică unui client sau ce incident a afectat un anumit server. Chiar și un model foarte bun lucrează cu informația pe care a primit-o la antrenare și cu datele introduse în conversația curentă.
RAG, prescurtarea de la retrieval-augmented generation, este una dintre metodele prin care o aplicație AI poate căuta informații relevante înainte să formuleze răspunsul. În loc să îi cerem modelului să răspundă numai din cunoștințele sale generale, îi oferim fragmente selectate din documente, baze de date sau alte surse autorizate.
Ideea pare simplă: căutăm, adăugăm rezultatele în context, apoi generăm răspunsul. În practică, diferența dintre o demonstrație convingătoare și un sistem util este dată de calitatea documentelor, de modul în care sunt extrase și fragmentate, de metoda de căutare, de gestionarea permisiunilor și a actualizărilor, precum și de calitatea citărilor și a evaluării.
La 24 septembrie 2026, nu există o singură metodă RAG care să fie cea mai bună pentru orice organizație. Există însă un set de practici suficient de mature pentru producție și mai multe direcții avansate care merită folosite numai când problema le justifică.
RAG nu a apărut dintr-o singură inovație. Sisteme anterioare precum DrQA combinau căutarea cu înțelegerea textului, iar kNN-LM și REALM explorau folosirea unei memorii externe. Lucrarea publicată în 2020 de Patrick Lewis și colaboratorii săi a introdus denumirea RAG și o familie de modele generative care combinau un model secvență-la-secvență cu un index dens construit dintr-o versiune a enciclopediei Wikipedia.
Distincția rămâne utilă:
RAG este, așadar, o arhitectură, nu un produs și nici o bază de date. O implementare poate folosi un motor de căutare clasic, o bază vectorială, PostgreSQL, un knowledge graph, servicii administrate în cloud sau o combinație între ele.
Scopul nu este să încărcăm toate informațiile companiei în prompt. Scopul este să găsim un set mic de dovezi relevante, autorizate și suficient de actuale pentru solicitarea respectivă.
RAG este frecvent confundat cu memoria agentului, fereastra de context sau fine-tuningul. Aceste mecanisme rezolvă probleme diferite.
| Concept | Unde se află informația | Rolul principal |
| :--- | :--- | :--- |
| Cunoștințele modelului | În parametrii rezultați din antrenare | Cunoștințe generale și tipare învățate, greu de actualizat și de atribuit unor surse verificabile |
| Fereastra de context | În cererea curentă transmisă modelului | Spațiu temporar de lucru pentru instrucțiuni, mesaje și dovezi |
| Istoricul conversației | În mesajele și rezultatele păstrate de aplicație | Continuitate între replici și, uneori, între sesiuni |
| Memoria agentului | În înregistrări persistente despre preferințe, decizii sau evenimente | Personalizare și continuitate pe termen lung |
| RAG | În documente, indexuri și baze de cunoștințe externe | Aduce informații relevante, actualizabile și citabile în context |
| Fine-tuning | În parametrii modificați ai modelului | Ajustează comportamentul, stilul sau performanța pe o sarcină |
| Instrumentele agentului | În API-uri, baze de date și aplicații externe | Citesc starea curentă sau execută acțiuni |
RAG nu înseamnă că modelul a fost „antrenat pe documentele firmei”. Documentele rămân în afara modelului și sunt consultate la momentul întrebării.
RAG nu garantează că răspunsul este adevărat. Dacă sistemul găsește un document vechi, greșit sau compromis, răspunsul poate fi fidel acelei surse și totuși incorect. De aceea, groundedness, adică susținerea răspunsului de către contextul recuperat, nu este sinonim cu adevărul.
RAG nu înlocuiește un API sau o interogare SQL. Pentru stocul curent, valoarea unei facturi sau starea unei comenzi, sursa potrivită este adesea sistemul operațional. Un index de documente poate explica politica aplicabilă, dar nu ar trebui să inventeze starea unei tranzacții.
Procedurile, deciziile, manualele și lecțiile învățate pot deveni căutabile prin limbaj natural. Răspunsul trebuie să indice documentul, versiunea și data, iar utilizatorul trebuie să vadă numai informația la care are acces.
Documentația, politicile și ghidurile pot fi accesate prin RAG. Datele despre client, abonament și tichet sunt citite prin API. Modificările, rambursările și comunicările externe rămân acțiuni separate, cu autorizare.
Agentul poate găsi servicii, studii de caz și răspunsuri tehnice relevante, apoi poate pregăti o primă versiune a ofertei. Prețurile și condițiile actuale trebuie preluate din sursa comercială validă, nu dintr-un document vechi returnat de căutarea semantică.
Un sistem poate identifica clauze, compara versiuni și indica politici aplicabile. Decizia juridică finală nu trebuie delegată modelului, iar sursele trebuie să rămână verificabile.
Codul, documentația, tichetele, incidentele și runbook-urile pot fi căutate împreună. Căutarea lexicală rămâne importantă pentru erori și identificatori, în timp ce regăsirea semantică ajută când aceeași problemă este descrisă diferit.
Materialele de curs, manualele, bibliografia și activitățile pot fi interogate cu citarea paginii. Pentru tabele, hărți, diagrame și pagini scanate este necesară o strategie multimodală sau o extracție structurală bună.
RAG poate explica produse și politici, poate găsi alternative sau documentație și poate ajuta la comparare. Prețul, disponibilitatea, compatibilitatea și condițiile comerciale curente trebuie verificate în catalogul și sistemele operaționale.
Un agent poate căuta în rapoarte, documente interne și surse publice, poate grupa dovezile și poate genera un raport cu citări. Pentru concluzii importante este necesară verificarea umană a surselor și a afirmațiilor.
Un sistem complet are două fluxuri: pregătirea cunoștințelor și răspunsul la întrebări.
Sursele pot fi PDF-uri, documente Office, pagini web, e-mailuri, note de ședință, wiki-uri, tichete de suport, contracte, manuale, fișiere din Nextcloud, SharePoint sau Google Drive și, atunci când este potrivit, date din CRM, ERP sau baze relaționale.
O listă de fișiere încărcate o singură dată nu este încă o bază de cunoștințe. Sistemul trebuie să știe care este sursa originală, cine o deține, ce versiune este valabilă și când trebuie sincronizată sau eliminată.
Textul trebuie extras fără să pierdem structura care îi dă sens. Într-un document real, titlurile, secțiunile, notele de subsol, coloanele, tabelele, imaginile și legătura dintre pagini pot schimba interpretarea informației.
Pentru un PDF scanat este necesar, de regulă, OCR sau un flux multimodal care procesează direct imaginile paginilor. Pentru un manual sau un raport complex poate fi nevoie de analizarea structurii vizuale a paginii, extragerea separată a tabelelor și păstrarea coordonatelor paginii. În multe proiecte, calitatea acestei etape poate influența rezultatul mai mult decât schimbarea modelului lingvistic.
Documentele sunt împărțite în fragmente, numite frecvent chunks. Dimensiunea fixă și suprapunerea dintre fragmente sunt un punct de pornire, nu o regulă universală.
Pentru documentele unei companii este mai util să păstrăm:
Documentația Azure descrie atât fragmentarea semantică, cât și strategii generale de împărțire pentru căutare vectorială. Nu există o dimensiune optimă care să poată fi copiată de la un furnizor și aplicată oricărui corpus.
Fiecare fragment trebuie să poată fi evaluat pe baza metadatelor proprii sau a unei referințe sigure către metadatele documentului, astfel încât filtrarea și auditul să folosească:
Permisiunile se aplică înainte ca textul să fie transmis modelului. Un prompt care îi cere modelului să nu divulge documentele altui client nu este un control de acces. Motorul de căutare trebuie să excludă din rezultate fragmentele, documentele sau sursele pe care utilizatorul nu are dreptul să le vadă.
Fragmentele pot fi indexate în mai multe feluri:
Într-o conversație, întrebarea „dar pentru contractele din 2025?” nu poate fi căutată corect fără contextul mesajului anterior. Aplicația poate reformula solicitarea într-o interogare independentă, poate identifica limba, entitățile, intervalul de timp și sursa probabilă.
Întrebările complexe pot fi împărțite în subîntrebări. Această etapă ajută în cercetare și în scenarii multi-hop, dar adaugă latență, cost și posibilitatea ca sistemul să se îndepărteze de intenția utilizatorului.
Sistemul regăsește un set de candidați, poate combina rezultatele mai multor metode și poate folosi un model de reordonare pentru a selecta fragmentele care răspund cel mai bine întrebării.
Prima etapă urmărește să nu piardă dovezi importante. Reordonarea urmărește să elimine zgomotul înainte ca informația să ajungă în contextul modelului.
Modelul primește întrebarea, instrucțiunile și fragmentele selectate. Aplicația îi poate cere să răspundă numai din dovezi, să indice sursele și să spună explicit când informația nu este suficientă.
Într-o implementare verificabilă, citările ar trebui să conducă la cea mai precisă localizare permisă de platformă: fragment, pagină sau cel puțin documentul folosit, nu doar la pagina principală a unui website. Pentru documentele interne sunt utile versiunea, data, pagina și starea sursei.
Un sistem observabil ar trebui să păstreze traseul tehnic al întrebării: interogările generate, filtrele aplicate, documentele regăsite, scorurile, răspunsul, citările, costul și latența. Datele sensibile trebuie mascate înainte de jurnalizare sau păstrate conform unei politici clare, nu înregistrate integral în mod implicit.
Expresia second brain este utilă ca metaforă pentru o bază personală sau organizațională de cunoștințe, dar nu desemnează o tehnologie standard.
Un „al doilea creier” util nu este un chatbot în care au fost încărcate toate fișierele. Este un sistem administrat, format din:
De exemplu, „utilizatorul preferă rapoarte concise” este o informație potrivită pentru memoria personală a agentului. „Procedura de backup, versiunea 4.2” este o informație documentară care trebuie regăsită din sursa oficială. „Spațiul liber pe server acum” trebuie citit printr-un instrument de monitorizare.
RAG poate fi motorul de regăsire al unui sistem de tip second brain, dar nu reprezintă întregul sistem. Fără permisiuni, versiuni și reguli de actualizare, poate transforma dezordinea documentară într-un răspuns convingător, nu într-o sursă de cunoștințe de încredere.
Produse precum NotebookLM exemplifică un caiet de lucru bazat pe sursele alese de utilizator. Pentru implementări autogestionate există proiecte precum AnythingLLM, Khoj sau RAGFlow. Acestea pot accelera un prototip, dar alegerea unui produs nu rezolvă automat calitatea documentelor, permisiunile sau evaluarea.
Metode precum BM25 acordă importanță termenilor care apar în întrebare și în document. Sunt foarte utile pentru:
Căutarea lexicală nu trebuie tratată ca o tehnologie depășită. Studiul comparativ BEIR a arătat că BM25 rămâne un reper robust pentru domenii eterogene.
Un model de vectorizare semantică (embedding model) transformă întrebarea și fragmentele în reprezentări numerice. Motorul caută vectorii apropiați, ceea ce permite găsirea unei idei chiar dacă întrebarea folosește alte cuvinte decât documentul.
Dense Passage Retrieval a fost una dintre lucrările importante pentru această direcție. Căutarea densă este bună pentru parafraze și similaritate semantică, dar poate rata identificatori exacți și poate returna fragmente apropiate ca temă, fără să conțină răspunsul necesar.
Căutarea hibridă combină căutarea lexicală cu cea vectorială, apoi unește listele de rezultate. O metodă frecventă este Reciprocal Rank Fusion, care combină pozițiile documentelor fără a presupune că scorurile celor două sisteme sunt direct comparabile.
Pentru multe proiecte de producție, căutarea hibridă este un punct de plecare mai sigur decât folosirea exclusivă a vectorilor. Documentațiile Azure AI Search, Qdrant, Weaviate și OpenSearch descriu implementări ale acestui model.
Modele precum ColBERT păstrează reprezentări la nivel de token și compară mai fin întrebarea cu pasajul. Față de metodele care folosesc un singur vector pentru fiecare fragment, această familie poate îmbunătăți precizia, dar cere mai multă stocare și evaluarea unui număr mai mare de reprezentări. ColBERTv2 a redus semnificativ spațiul necesar față de prima generație a metodei.
Același principiu al reprezentărilor multiple poate fi folosit pentru câmpuri diferite, limbi diferite sau combinații între text și imagini.
Contextual Retrieval, descris de Anthropic în 2024, adaugă fiecărui fragment o scurtă explicație derivată din documentul complet înainte de indexare. Astfel, un pasaj care menționează „veniturile companiei au crescut cu 3%” poate păstra și informația despre companie, perioadă și raport.
În evaluarea proprie, Anthropic a raportat că contextual embeddings împreună cu contextual BM25 au redus relativ rata de eșec a regăsirii în primele 20 de fragmente de la 5,7% la 2,9%. După reordonarea a 150 de candidați și păstrarea primilor 20, rata a ajuns la 1,9%, o reducere relativă de 67%. Rezultatele provin din evaluarea furnizorului și nu reprezintă o garanție pentru orice corpus.
Sistemele mai avansate pot:
HyDE este o metodă de regăsire densă zero-shot, fără etichete de relevanță. Generează un document ipotetic, apoi folosește reprezentarea lui numai pentru a găsi documente reale apropiate. Textul ipotetic poate conține detalii false și nu trebuie folosit ca dovadă. Interogările multiple și descompunerea întrebării pot îmbunătăți acoperirea, însă pot mări costul și pot introduce rezultate în afara subiectului.
Aceste tehnici se activează după evaluare. Nu orice întrebare are nevoie de cinci reformulări și mai multe runde de căutare.
Un agent nu ar trebui să trimită fiecare solicitare către aceeași bază vectorială. El poate selecta instrumentul potrivit pentru tipul de informație cerut.
| Instrument | Potrivit pentru | Exemplu |
| :--- | :--- | :--- |
| Căutare lexicală | Identificatori și formulări exacte | Găsirea unui cod de eroare într-un runbook |
| Căutare vectorială | Concepte și parafraze | Găsirea unei proceduri descrise în alți termeni |
| Căutare hibridă și reordonare | Corpusuri mixte și întrebări reale | Documentație tehnică, politici și suport |
| SQL sau API operațional | Valori exacte și stare curentă | Stoc, facturi, comenzi sau metrici |
| Graf de cunoștințe | Relații și întrebări care cer mai multe etape | Legături între incidente, furnizori și componente |
| Căutare web | Informație publică recentă | Reguli, documentație și informații de piață |
| Sistem documentar sau stocare de obiecte | Documente și drepturile lor originale | Nextcloud, SharePoint, Drive sau S3 |
| Instrument multimodal | Pagini scanate, tabele și diagrame | Manuale, facturi și rapoarte complexe |
| Memorie persistentă | Preferințe și decizii selectate | Formatul preferat al rapoartelor |
| Instrument de acțiune | Modificarea unui sistem | Crearea unui tichet sau actualizarea unui CRM |
Când agentul caută politica de retur într-un manual, folosește regăsirea. Când verifică starea unei comenzi, folosește API-ul magazinului. Când inițiază rambursarea, execută o acțiune pentru care sunt necesare permisiuni, limite și, în funcție de risc, aprobare umană.
Model Context Protocol poate expune surse și instrumente într-un format comun. MCP nu este însă un motor RAG. El poate oferi agentului un instrument search, unul fetch, o interogare de bază de date sau o acțiune de business, iar aplicația decide cum sunt folosite.
Ferestrele de context tot mai mari nu elimină automat regăsirea. Introducerea unui număr mic de documente complete poate fi cea mai simplă soluție atunci când informația poate fi inclusă în context la un cost rezonabil și relațiile dintre secțiuni sunt importante.
Pentru colecții mari, actualizate frecvent sau cu permisiuni diferite, RAG păstrează avantaje clare: selectează informația, reduce volumul trimis modelului, permite filtrarea și poate lega răspunsul de sursă.
Studiul Lost in the Middle a arătat, pe sarcinile și modelele evaluate, că performanța scade frecvent atunci când informația relevantă se află în mijlocul unui context lung. Acest rezultat nu trebuie generalizat automat la orice model actual. LaRA, publicat la ICML 2025, a constatat că alegerea dintre context lung și RAG depinde de capabilitatea modelului, lungimea contextului, tipul sarcinii și calitatea regăsirii, ceea ce justifică evaluarea și rutarea între cele două abordări.
Abordarea pragmatică este să măsurăm trei variante: context direct, RAG și o soluție hibridă care direcționează întrebarea către metoda potrivită.
Un sistem agentic poate decide dacă are nevoie de regăsire, poate selecta sursa, poate descompune întrebarea, poate executa căutări în paralel, poate evalua relevanța rezultatelor și poate repeta căutarea.
Această flexibilitate este utilă pentru cercetare și întrebări care cer mai multe etape. Ea adaugă însă pași, latență, cost și noi puncte în care pot apărea erori. Sistemul trebuie să aibă limite pentru numărul de pași, sursele permise, buget și timp.
Conform documentației Azure AI Search pentru agentic retrieval, componenta extractivă este disponibilă general prin API-ul stabil 2026-04-01, iar planificarea cu LLM, sinteza și unele funcții pentru conversații în mai multe etape folosesc în continuare 2026-08-01-preview. Această separare este un exemplu bun pentru maturitatea inegală a componentelor.
Self-RAG antrenează modelul să decidă când să caute și folosește tokeni de reflecție pentru a evalua dovezile și propria generare. Corrective RAG folosește un evaluator al rezultatelor și poate declanșa pași de corecție, inclusiv căutare web. Adaptive-RAG folosește un clasificator al complexității pentru alegerea între răspuns fără regăsire, un singur pas și regăsire iterativă. Sunt direcții importante, dar implementările din lucrări nu trebuie confundate cu o opțiune universală care poate fi activată într-un produs.
RAG clasic găsește fragmente apropiate de întrebare. Unele întrebări cer însă o perspectivă asupra întregului corpus: teme recurente, relații dintre organizații și evenimente sau conexiuni între incidente, componente și furnizori.
GraphRAG, dezvoltat de Microsoft Research, extrage entități și relații, construiește comunități și generează rezumate ale acestora. Lucrarea originală evaluează în special întrebări globale despre teme și tipare la nivelul întregului corpus. Implementarea Microsoft documentează separat și metode de căutare locală. RAPTOR construiește o ierarhie de fragmente și rezumate recursive.
Aceste metode pot fi potrivite pentru investigații și analize transversale, mai ales în corpusuri în care relațiile sunt esențiale. Construirea și actualizarea structurii adaugă cost și complexitate. GraphRAG nu este o recomandare automată pentru un FAQ, un catalog sau găsirea unei clauze exacte.
Documentele reale conțin mai mult decât text: tabele, grafice, planșe, imagini, formule și structuri vizuale complexe. O abordare matură combină OCR, parsarea structurii și descrieri ale elementelor vizuale, păstrând legătura cu pagina originală.
O direcție nouă indexează direct imaginile paginilor. ColPali este un model de regăsire vizuală la nivel de pagină, bazat pe reprezentări multiple. VisRAG este un flux complet de indexare vizuală, regăsire și generare, fără a transforma mai întâi tot conținutul în text. Ambele lucrări au fost publicate la ICLR 2025.
Serviciile comerciale au început să includă parsare și regăsire multimodală. Amazon Bedrock Knowledge Bases documentează fluxuri multimodale pentru text, imagini, audio și video, iar Gemini API File Search a anunțat în 2026 procesare multimodală și citări la nivel de pagină.
Pentru o firmă, abordarea prudentă este să păstreze textul, structura și pagina, apoi să adauge regăsire vizuală acolo unde tabelele și imaginile schimbă răspunsul.
„Local” și „cloud” nu determină automat nivelul de securitate sau de calitate. Ele descriu distribuirea controlului și a responsabilității.
| Model de implementare | Avantaje | Responsabilități și compromisuri |
| :--- | :--- | :--- |
| În infrastructura proprie (on-premises) | Control direct asupra documentelor, indexurilor și jurnalelor; posibilitatea de a folosi modele locale | Echipa administrează autentificarea, actualizările, backupul, monitorizarea, scalarea și securitatea întregului ansamblu tehnic |
| Autogestionat în cloud privat | Control arhitectural și integrare bună cu infrastructura existentă | Necesită competențe operaționale și un model clar de cost și disponibilitate |
| Serviciu administrat extern | Implementarea pilotului și scalarea mai rapide; mai puțină infrastructură proprie | Trebuie verificate retenția, utilizarea datelor, regiunea, exportul, ștergerea, costurile și dependența de furnizor |
| Hibrid | Documentele și permisiunile pot rămâne în infrastructura proprie, iar modelului extern i se trimit numai fragmentele necesare | Arhitectură mai complexă; trebuie urmărit ce date traversează fiecare limită de încredere |
Un motor vectorial local nu are nevoie în mod obligatoriu de GPU. Resursele depind de volumul indexului, latența dorită și modelele folosite pentru vectorizare și reordonare. Generarea locală cu un model mare este o problemă separată de stocarea și căutarea vectorilor.
Produsele trebuie comparate în interiorul aceleiași categorii:
| Strat | Rol | Exemple |
| :--- | :--- | :--- |
| Motor de căutare și stocare | Index lexical, vectorial, filtre și clasare | pgvector, Qdrant, Weaviate, Milvus, Vespa, OpenSearch, Elasticsearch |
| Serviciu RAG administrat | Ingestie, indexare și regăsire gestionate de furnizor | OpenAI File Search, Azure AI Search, Bedrock Knowledge Bases, Google Agent Search și RAG Engine |
| Modele de vectorizare și reordonare | Reprezentarea semantică și reordonarea candidaților | Modele OpenAI, Cohere, Voyage, Jina și modele cu sursă deschisă |
| Cadru de orchestrare | Conectori, fluxuri, mecanisme de regăsire, agenți și evaluare | LlamaIndex, LangChain și LangGraph, Haystack |
| Interfață sau aplicație completă | Experiență pentru documente, chat și agenți | AnythingLLM, RAGFlow, Open WebUI, Dify, Khoj |
| Model generativ | Formularea răspunsului pe baza contextului | Modele locale sau servicii de la furnizori externi |
PostgreSQL cu pgvector este o alegere pragmatică atunci când firma folosește deja PostgreSQL și corpusul are o dimensiune moderată. Datele, metadatele, permisiunile și vectorii pot rămâne în aceeași bază. Ingestia, combinarea rezultatelor căutării hibride și reordonarea trebuie asamblate în jurul extensiei, în SQL și/sau în aplicație.
Qdrant este un motor dedicat pentru vectori denși, rari și reprezentări multiple, cu filtre și interogări hibride. Poate rula local sau ca serviciu administrat și este potrivit când regăsirea devine o componentă separată a arhitecturii.
Weaviate combină căutarea vectorială, BM25F și căutarea hibridă, oferind opțiuni pentru multitenancy și module de integrare. Este mai integrat, dar necesită administrarea atentă a colecțiilor și resurselor.
Milvus oferă variante Lite, Standalone și Distributed, plus serviciul Zilliz Cloud. Varianta distribuită este justificată, de regulă, de volume mari sau de cerințe de disponibilitate și scalare, nu ca alegere implicită pentru primul proiect al unui IMM.
OpenSearch și Elasticsearch sunt opțiuni firești când organizația folosește deja aceste ecosisteme pentru căutare și analiză. Ambele combină căutarea lexicală cu funcții vectoriale, dar operarea clusterului și reglarea relevanței cer experiență.
Vespa este potrivită când rankingul în mai multe etape și semnalele de business sunt funcții centrale ale produsului. Flexibilitatea vine cu o curbă de învățare mai mare.
OpenAI File Search este un instrument găzduit pentru Responses API, construit peste Vector Stores. Gestionează fișierele, fragmentarea, indexarea, căutarea semantică și lexicală, filtrele pe atributele fișierelor și citările la nivel de fișier. Este o cale scurtă către un pilot atunci când aplicația folosește deja ecosistemul OpenAI, cu mai puțin control asupra mecanismului intern decât într-o arhitectură proprie.
Azure AI Search oferă căutare full-text, vectorială și hibridă, semantic ranker, OCR și vectorizare integrată. Este relevant mai ales în ecosistemul Azure și Microsoft Entra. Integrarea directă cu SharePoint și propagarea listelor de control al accesului trebuie verificate separat, deoarece unele capabilități sunt încă în versiune preliminară. Același lucru este valabil pentru funcțiile agentice care nu au ajuns la disponibilitate generală.
Amazon Bedrock Knowledge Bases oferă Managed Knowledge Base, în care serviciul administrează ingestia, indexarea, stocarea și regăsirea, precum și Customer-managed Knowledge Base, în care clientul controlează fluxul de ingestie și baza vectorială. Unele funcții, inclusiv anumiți conectori terți și filtrarea după liste de control al accesului, sunt disponibile numai în varianta administrată. Fluxul RetrieveAndGenerate poate produce răspunsuri cu citări, în timp ce Retrieve returnează rezultatele regăsite. Disponibilitatea modelelor și funcțiilor depinde de regiune.
Agent Search on Gemini Enterprise Agent Platform, denumirea actuală pentru produsul cunoscut anterior ca Vertex AI Search, este orientat către căutare în website-uri și documente. RAG Engine on Gemini Enterprise Agent Platform este destinat aplicațiilor și agenților personalizați. Unele moduri și funcții au încă limitări de versiune preliminară sau regionale.
Pinecone este un motor administrat pentru căutare semantică și hibridă, cu filtre, namespaces, embeddings și reranking găzduite. Reduce munca de operare, dar nu înlocuiește ingestia, autorizarea și evaluarea aplicației.
Cohere oferă modele și API-uri pentru vectorizare semantică, reordonare și parsarea documentelor, dar nu este în primul rând o bază vectorială. Un model Cohere de reordonare poate fi folosit peste rezultatele obținute din pgvector, Qdrant, OpenSearch sau alte motoare.
LlamaIndex oferă conectori, ingestie, indexuri, mecanisme de regăsire, motoare de interogare, fluxuri și agenți. Platforma LlamaParse adaugă servicii găzduite pentru parsare și prelucrarea documentelor.
LangChain și LangGraph oferă componente și control pentru aplicații personalizate, inclusiv agenți care decid când și unde să caute. Numărul mare de integrări ajută, dar poate produce o arhitectură dificil de urmărit dacă nu sunt păstrate limite clare.
Haystack construiește fluxuri modulare din componente, depozite de documente, mecanisme de regăsire și reordonare, agenți și instrumente. Este potrivit când echipa dorește control explicit asupra etapelor și posibilitatea de a schimba furnizorii.
Un cadru software accelerează implementarea. Nu decide în locul echipei ce documente sunt autoritative, ce permisiuni se aplică sau ce nivel de calitate este acceptabil.
Un sistem RAG aduce documentele companiei într-un flux operațional în care un model interpretează limbaj natural. Această integrare trebuie tratată ca o nouă limită de securitate.
Un document, e-mail sau website poate conține instrucțiuni malițioase adresate modelului. OWASP descrie o injecție indirectă de prompt ca situația în care modelul primește conținut extern care îi poate modifica comportamentul.
Măsurile utile includ:
Delimitatoarele și prompturile de sistem reduc riscul, dar nu constituie singure un control de securitate.
Autorizarea trebuie aplicată în momentul regăsirii, la nivelul fragmentului, documentului sau al sursei autorizate. Cache-urile trebuie izolate sau indexate după întregul context de autorizare relevant, inclusiv tenant, utilizator, grupuri, roluri și versiunea listei de control al accesului. Sistemul trebuie supus unor teste deliberate de acces încrucișat.
Ștergerea documentului original trebuie propagată către fragmente, reprezentări vectoriale, indexuri secundare, cache-uri și rezultate generate în avans, conform politicii de retenție. Fiecare sursă are nevoie de un identificator stabil, versiune, dată de intrare în vigoare și stare.
Reprezentările vectoriale nu trebuie tratate ca o formă garantată de anonimizare. Cercetarea Text Embeddings Reveal (Almost) As Much As Text arată de ce simpla transformare a textului într-un vector nu elimină automat riscul de expunere. Se indexează numai datele necesare, iar informațiile personale și secretele se elimină sau pseudonimizează atunci când scopul permite.
În contractul cu un furnizor extern trebuie verificate retenția, utilizarea datelor pentru antrenare, regiunea de procesare, ștergerea, exportul și subcontractorii. „Datele nu sunt folosite la antrenare” nu înseamnă automat „retenție zero”.
O arhitectură hibridă poate păstra documentele, listele de control al accesului și regăsirea în infrastructura proprie, trimițând modelului extern doar fragmentele strict necesare și, unde este posibil, mascate.
OWASP RAG Security Cheat Sheet oferă o listă practică pentru ingestie, embeddings, acces, proveniență, cache, monitorizare și ștergere. Articolul dedicat prompt injection va detalia aceste riscuri separat.
O demonstrație nu este o evaluare. Pentru un pilot este necesar un set de întrebări reale, surse așteptate și condiții clare pentru situațiile în care informația lipsește.
Evaluarea se separă pe niveluri:
| Nivel | Întrebarea evaluată | Exemple de metrici |
| :--- | :--- | :--- |
| Regăsire | Găsește informația necesară? | Recall@k, Hit Rate@k |
| Clasare | Pune dovezile utile înaintea zgomotului? | Precision@k, MRR, nDCG@k |
| Generare | Răspunde corect și suficient de complet? | relevanță, corectitudine, completitudine |
| Fidelitate | Afirmațiile sunt susținute de context? | faithfulness, groundedness, verificare pe afirmații |
| Citări | Sursele susțin și acoperă afirmațiile importante? | citation correctness, citation completeness |
| Abținere | Refuză să inventeze când lipsesc dovezile? | rata refuzurilor corecte și rata răspunsurilor nejustificate |
| Operare | Este sustenabil în producție? | latență p50 și p95, cost, tokeni, rată de eroare |
| Securitate | Respectă accesul și rezistă conținutului ostil? | teste de izolare între organizații, de rezistență la prompt injection și de propagare a ștergerii |
Ragas și ARES oferă metode pentru evaluarea relevanței contextului, fidelității și calității răspunsului. RAGChecker descompune răspunsurile în afirmații și încearcă să diagnosticheze separat regăsirea și generarea.
Definițiile pentru faithfulness, groundedness și corectitudinea citărilor variază între cadrele de evaluare. Scorurile nu sunt direct comparabile dacă nu folosim aceeași rubrică, același set de teste și același tip de evaluator.
Evaluatorii bazați pe alte modele sunt utili pentru comparații rapide, dar trebuie calibrați prin exemple evaluate de oameni. Un scor automat nu înlocuiește revizuirea cazurilor importante.
Setul de testare al unui IMM ar trebui să includă:
Pentru fiecare caz păstrăm întrebarea, rolul, sursele așteptate, afirmațiile obligatorii, comportamentul acceptabil de abținere și severitatea unei erori.
RAG nu este o etapă obligatorie pentru orice aplicație AI.
Poate fi inutil sau disproporționat atunci când:
Uneori, primul proiect util nu este un chatbot RAG, ci ordonarea documentelor, eliminarea duplicatelor, stabilirea versiunii oficiale și introducerea drepturilor de acces.
Un prim pilot bun răspunde unui set clar de întrebări dintr-un corpus delimitat. De exemplu: proceduri interne aprobate, documentația unei familii de produse sau runbook-urile unui serviciu.
Identificăm proprietarul, versiunea și frecvența de actualizare. Documentele fără autoritate sau stare cunoscută nu intră automat în index.
Începem cu parsare structurală, metadate, căutare lexicală și vectorială, filtre, reordonarea rezultatelor și citări. Nu introducem GraphRAG sau bucle agentice până când nu identificăm, prin măsurători, o limită a variantei de bază.
Colectăm întrebări reale, răspunsuri așteptate și cazuri fără răspuns. Măsurăm regăsirea separat de formularea finală.
Verificăm izolarea rolurilor și tenanturilor, documentele expirate, ștergerea, prompt injection, sursele contradictorii și refuzul de a inventa.
Evaluăm cel puțin o variantă locală sau autogestionată și una administrată, folosind aceleași documente și întrebări. Decizia se bazează pe calitate, cost total, latență, control, operare și risc, nu pe numărul de funcții din prezentare.
Primii utilizatori văd sursele, pot marca răspunsurile greșite și au o cale clară de escaladare. Extindem corpusul și autonomia numai după ce măsurătorile arată că sistemul rămâne util și controlabil.
Primul pas nu este alegerea unei baze vectoriale, ci delimitarea unei probleme reale și a surselor care o pot rezolva. Putem analiza împreună ce date merită conectate, ce metodă de căutare este potrivită și dacă soluția ar trebui administrată în infrastructura proprie, prin servicii cloud sau într-o configurație hibridă. Apoi putem defini un proiect-pilot măsurabil, cu acces controlat și criterii clare de calitate.