Prospețime, ștergeri și reindexare într-un sistem RAG

Un sistem RAG lansat acum trei luni răspunde azi greșit la o treime din întrebări. Nimeni nu a schimbat modelul. Nimeni nu a atins prompt-ul. Scorurile de similaritate arată la fel de sănătoase ca în prima zi.

S-a schimbat lumea din afara indexului, iar indexul nu a aflat.

Ăsta e modul de eșec despre care se scrie cel mai puțin, fiindcă nu produce erori. Nu apare nicio excepție în log-uri, nu crește latența, nu se declanșează nicio alertă. Documentul expirat e regăsit cu aceeași încredere ca cel corect, iar modelul răspunde din el la fel de coerent.

Articolul tratează dimensiunea temporală a unui sistem RAG: ce înseamnă concret prospețimea, de ce ștergerea e cea mai grea operație dintr-un index vectorial, cum detectezi ce s-a schimbat, ce indexezi față de ce citești live și cât te costă să ții totul la zi. Identificatorii stabili și schema chunk-ului sunt tratate ca dat — pe ele le fixează arhitectura sistemului.

Prospețimea e o promisiune de produs, nu o setare de infrastructură

Prima întrebare nu e „cât de des reindexez”. E „cât de vechi are voie să fie un răspuns, pentru fiecare tip de conținut”.

Sunt două întrebări diferite. A doua se răspunde cu cineva din business, nu din echipa de infrastructură.

Ce înseamnă concret „la zi”

Prospețimea unui răspuns are trei componente, iar ele se pot degrada separat:

• Vechimea conținutului la sursă — de când nu a mai fost revizuit documentul original.
• Decalajul de indexare — de cât timp s-a schimbat sursa fără ca indexul să reflecte schimbarea.
• Valabilitatea afirmației — dacă informația mai e adevărată, indiferent când a fost scrisă.

A treia nu se rezolvă tehnic. Un document nemodificat de doi ani poate fi perfect valabil sau complet expirat, iar sistemul nu are cum să distingă fără ca cineva să marcheze asta.

SLA-ul se scrie pe clase de conținut, nu pe corpus

O singură cadență pentru tot corpusul e fie prea scumpă, fie prea lentă. Împarte pe clase și dă fiecăreia un prag:

Tabelul e un punct de plecare, nu un standard. Ce contează e ca fiecare document indexat să aparțină unei clase cu prag declarat, fiindcă altfel nu ai cum să spui dacă sistemul respectă ceva.

Pragul devine metrică operațională

Odată ce clasele există, poți măsura: câte documente depășesc pragul clasei lor, care e vechimea mediană pe fiecare clasă, care e cea mai veche intrare care încă poate fi returnată. Trei numere care nu apar în niciun dashboard standard și care prezic degradarea cu săptămâni înainte să ajungă în reclamații.

De ce un index expirat nu dă niciun semnal

Aici e mecanismul, și merită înțeles exact, fiindcă din el decurg toate deciziile de mai jos.

Similaritatea semantică nu are dimensiune temporală

Un embedding codifică sensul unui text. Nu codifică data, versiunea sau valabilitatea lui. Vectorul unei proceduri abrogate anul trecut e la fel de aproape de întrebarea utilizatorului ca vectorul procedurii în vigoare — pentru că amândouă vorbesc despre același lucru.

Retriever-ul nu ignoră prospețimea. E structural orb la ea. Nu are cum să o vadă, oricât ai regla k, pragurile de scor sau reranker-ul.

Consecința practică e neplăcută: fiecare mecanism pe care te bazezi ca să prinzi retrieval prost — scoruri mici, rezultate goale, praguri de relevanță — e inutil aici. Documentul greșit are scor mare. Sistemul e convins că a reușit.

Cazul celor două versiuni

Cel mai frecvent tipar în practică nu e documentul lipsă, ci documentul dublat.

Procedura veche a rămas în index. Procedura nouă a fost adăugată. Amândouă sunt acum candidate pentru aceeași întrebare, iar câștigătoarea se decide pe potriviri de vocabular, nu pe dată. Uneori câștigă versiunea veche tocmai pentru că folosea exact termenii pe care îi folosește și utilizatorul — termeni pe care versiunea nouă i-a înlocuit fiindcă s-au schimbat.

Rezultatul: un răspuns detaliat, cu citare, complet greșit. Analizele de practică din 2026 pe tiparul ăsta descriu exact scenariul — un ghid de configurare depășit de peste un an, rămas în index alături de cel curent și returnat în locul lui.

De ce evaluarea clasică nu prinde asta

Metricile standard de evaluare — context precision, context recall, faithfulness, relevanța răspunsului — au toate o presupunere nescrisă: documentele regăsite sunt adevărate în momentul evaluării.

Faithfulness măsoară dacă răspunsul e susținut de contextul regăsit. Un scor perfect înseamnă că fiecare afirmație se ancorează într-un document. Nu spune nimic despre dacă acel document mai e valabil.

De aici decurge capcana: un set de evaluare construit când documentele erau proaspete continuă să treacă în timp ce ele expiră. Retriever-ul returnează în continuare conținut semantic apropiat, modelul generează în continuare răspunsuri fidele acelui conținut, iar suita verde îți spune că totul e în regulă.

Remediul nu e o metrică nouă, e o intrare nouă în setul de evaluare: întrebări la care răspunsul corect s-a schimbat de la construirea setului. Fără ele nu evaluezi prospețimea, evaluezi coerența.

Detecția schimbărilor: pull, push și ce cade printre ele

Ca să actualizezi, trebuie mai întâi să afli. Sunt trei mecanisme, cu compromisuri diferite.

Polling pe timestamp

Interoghezi periodic sursa și ceri tot ce s-a modificat după ultima rulare. Simplu, funcționează cu orice sursă care expune o dată de modificare, nu cere nimic de la sistemul de origine.

Are două găuri, amândouă tăcute:

• Ștergerile nu apar. Un document șters nu se mai întoarce în nicio listă de „modificate după”. Din perspectiva pollerului, el pur și simplu nu mai există — ceea ce arată identic cu „nu s-a schimbat”.
• Timestamp-urile mint. Multe sisteme actualizează data de modificare la operații care nu ating conținutul, iar unele nu o actualizează deloc la modificări făcute prin API sau import în masă.

Push: webhooks și change data capture

Sursa te anunță. Un webhook la salvarea documentului, un flux de change data capture pe baza de date, un eveniment din bus-ul intern.

Avantajul real nu e latența mică, ci că ștergerea există ca eveniment. Ghidurile de arhitectură pe pipeline-uri de ingest din 2026 formulează diferența exact așa: modelul pull e mai simplu, dar push e ce vrei pentru orice sursă care îl suportă, tocmai fiindcă îți dă actualizări incrementale și tratarea corectă a ștergerilor.

Costul: fiecare sursă cere integrare separată, evenimentele se pot pierde, iar ordinea nu e garantată. Un push fără reconciliere periodică diverge în tăcere.

Amprenta de conținut, ca plasă de siguranță

Peste oricare dintre cele două, ține un hash al conținutului fiecărui document indexat. La fiecare ciclu compari hash-ul curent cu cel stocat.

Costă o citire, nu un re-embedding, și prinde ambele găuri ale pollingului: modificările fără timestamp actualizat și cele care au declanșat un eveniment pierdut. Un sistem experimental de indexare incrementală bazat pe hashing raportează un ciclu de reverificare de ordinul zecimilor de secundă pe un corpus mic, față de secunde pentru ingestia completă. Magnitudinea depinde de corpus, dar direcția e clară: verificarea e ieftină, re-embedding-ul nu.

Combinația care funcționează în producție: push acolo unde sursa îl oferă, polling ca fallback, hash ca reconciliere periodică. Niciunul singur nu e suficient.

Ștergerea, operația pe care o crezi rezolvată

Adăugarea și actualizarea sunt simple. Ștergerea nu e, din trei motive care se compun.

Ștergerea funcțională nu e ștergere la nivel de storage

Majoritatea indexurilor vectoriale implementează ștergerea ca marcaj: înregistrarea e semnalată ca ștearsă și nu mai apare în rezultate, dar vectorul rămâne fizic pe disc până la o reconstrucție de index. E o decizie de performanță — reconstruirea unui graf HNSW la fiecare ștergere ar fi prohibitivă.

O lucrare publicată pe arXiv în iunie 2026 a testat consecința pe trei implementări HNSW: vectorii marcați ca șterși rămân recuperabili accesând direct fișierele de index la nivel de storage, ocolind complet API-ul. Folosind un model de inversiune fără ajustare pe domeniu, autorii au reconstruit informație personală din vectorii „șterși” — pe înregistrări clinice sintetice cu abrevieri și greșeli de scriere, ratele raportate merg de la 73,4% pentru gen și 65,0% pentru prenume până la 6,2% pentru numele medicului.

Cifrele vin dintr-un set construit pentru experiment, nu dintr-un audit de producție. Concluzia arhitecturală rămâne însă valabilă indiferent de ele: un API care nu mai returnează înregistrarea nu demonstrează că datele au dispărut.

Practica de operare pentru Postgres cu pgvector merge în aceeași direcție din motive de performanță: pe tabele cu reindexare frecventă, tombstone-urile se acumulează, iar o reconstrucție periodică a indexului devine sarcină de întreținere, nu opțiune. Ce diferă între motoare — momentul reconstrucției, costul ei, garanțiile oferite — ține de alegerea de infrastructură, tratată în comparația între motoare vectoriale.

Ștergerile care nu ajung niciodată la index

Înainte de problema de storage e una mai banală și mai frecventă: ștergerea de la sursă nu se propagă deloc.

Documentul e mutat în coșul wiki-ului, fișierul e șters din bucket, rândul e marcat inactiv în CRM. Pipeline-ul de ingest, construit să caute „ce s-a adăugat sau modificat”, nu are cum să afle. Chunk-urile rămân în index și continuă să fie returnate.

Asta e diferența dintre modul de eșec „conținut lipsă” catalogat printre cauzele clasice de eșec în producție și cazul de aici: conținutul nu lipsește, ci e prezent și nu ar trebui să fie.

Există și un caz înrudit, dar distinct: permisiunea revocată. Documentul rămâne valid și neschimbat — doar audiența lui se restrânge, iar niciunul dintre mecanismele de detecție de aici nu îl prinde, fiindcă nu există nicio modificare de conținut de detectat. E tratat separat în controlul accesului în RAG.

Ce înseamnă pentru dreptul la ștergere

Când datele indexate conțin informații personale, distincția de mai sus încetează să fie o subtilitate tehnică. Aceeași lucrare notează că ghidurile europene în materie cer ca ștergerea să fie verificabilă și ireversibilă, iar simpla suprimare din rezultatele interogărilor nu îndeplinește cerința.

Există și un al doilea strat, de care depinde tot raționamentul: un embedding derivat din date personale nu e o anonimizare. Cercetarea din 2026 pe inversiunea embedding-urilor arată că vectorii pot fi folosiți pentru a reconstrui text sursă, ceea ce înseamnă că indexul vectorial trebuie tratat cu aceeași rigoare ca depozitul de documente din care provine.

Implicațiile de conformitate — temei legal, minimizare, transferuri — sunt tratate separat în articolul despre RAG și GDPR. Ce reții aici e operațional: pune în plan o cale de ștergere testată capăt la capăt, care include reconstrucția indexului, nu doar apelul de delete. Și testeaz-o periodic, așa cum testezi restaurarea unui backup.

Indexarea incrementală ca cerință de corectitudine

Reindexarea completă e ușor de raționat și imposibil de susținut. Indexarea incrementală e greu de făcut corect și singura care scalează. Nu e o optimizare de performanță — e ce te ține sincronizat cu realitatea.

Upsert la nivel de document, nu de chunk

Operația corectă la o modificare nu e „actualizează chunk-urile schimbate”. E: șterge toate chunk-urile documentului, resegmentează, recalculează embedding-urile, inserează.

Motivul e că granițele chunk-urilor se mută. Dacă un paragraf a fost adăugat la începutul documentului, chunk-ul 3 vechi și chunk-ul 3 nou nu conțin același text, iar o actualizare „pe poziție” produce un amestec între versiuni. Ghidul de sisteme agentice publicat pe arXiv în 2026 formulează regula direct: ștergerea completă a chunk-urilor documentului înainte de reinserare e ce garantează că nu rămân fragmente vechi.

Regula presupune că poți enumera toate chunk-urile unui document. De aceea identificatorul de document e câmp obligatoriu în schema chunk-ului, nu metadată opțională — decizia se ia la proiectarea arhitecturii, înainte de prima indexare.

De unde vin fragmentele orfane

Un fragment orfan e un chunk care nu mai corespunde niciunui document viu. Apar din patru locuri, toate previzibile:

• Un ciclu de ingest care a crăpat între ștergere și reinserare.
• O schimbare de strategie de chunking aplicată doar documentelor noi.
• O ștergere la sursă care nu s-a propagat.
• Un identificator de document schimbat între rulări, care face vechile chunk-uri de negăsit.

Remediul nu e prevenirea perfectă, e reconcilierea. O sarcină periodică ce compară mulțimea de identificatori din index cu cea din sursă și raportează diferența în ambele direcții. Rulează-o săptămânal și tratează rezultatul ca pe un test care poate pica, nu ca pe un raport informativ.

Lag-ul de indexare și consistența eventuală

În indexurile distribuite, un vector inserat nu devine imediat căutabil. Intervalul e de obicei de ordinul secundelor sau minutelor, dar nu e zero, iar pipeline-ul trebuie să-l tolereze.

Consecința apare la scenariile „salvează și întreabă imediat”: utilizatorul actualizează un document, pune o întrebare despre el și primește versiunea veche. Nu e un bug de retrieval, e o fereastră de consistență. Fie o comunici în interfață, fie citești live sursa pentru documentele modificate recent.

Indexat sau live: criteriul

Nu tot ce ajunge în răspuns trebuie să treacă prin index. Cea mai ieftină soluție la prospețime e să nu indexezi ce se schimbă des.

Ce merită indexat

Conținut la care întrebarea e semantică — „cum se procedează”, „ce spune politica despre”, „unde e descris”. Documente, proceduri, articole, tichete rezolvate, specificații. Valoarea vine din regăsirea prin sens, iar rata de schimbare se măsoară în zile sau săptămâni. Ce intră aici și cum se pregătește tratează articolul despre pregătirea documentelor.

Ce se citește live

Valori la care întrebarea e factuală și punctuală — un preț, un stoc, un sold, statusul unei comenzi, o dată de expirare. Aici similaritatea semantică nu aduce nimic: știi exact ce câmp vrei, dintr-un sistem care îl are.

Tiparul corect e să tratezi sursa structurată ca pe un instrument pe care sistemul îl apelează la nevoie, nu ca pe conținut de indexat. E aceeași extindere a retrieval-ului discutată la agentic RAG și tool use, aplicată aici din motive de prospețime, nu de complexitate a întrebării.

Regula practică

Compară două numere: de câte ori pe lună se schimbă valoarea și de câte ori pe lună e cerută. Dacă se schimbă mai des decât e cerută, indexarea ei e efort irosit care produce răspunsuri expirate. Recalcularea unui embedding pentru un preț care se mișcă la fiecare cinci minute e cea mai scumpă formă de a greși.

Cazul mixt e cel mai frecvent și merită numit: documentul rămâne indexat, iar valorile volatile din el sunt înlocuite cu referințe pe care sistemul le rezolvă live la momentul răspunsului. Contractul rămâne text căutabil semantic; suma din el vine din baza de date.

Cât costă să ții la zi

Costul are două forme foarte diferite, iar confuzia dintre ele explică majoritatea surprizelor de pe factură.

Reindexarea completă se plătește pe corpus

Costul unei reindexări complete scalează cu dimensiunea corpusului, indiferent cât s-a schimbat. Aritmetica e simplă și se uită ușor: la un tarif de ordinul a 0,02 USD per milion de tokeni pentru un model de embedding uzual, un corpus de 500.000 de documente a câte aproximativ 400 de cuvinte ajunge la ordinul a 200 de milioane de tokeni per rulare completă.

Suma per rulare e mică. Problema apare la cadență: rulată în fiecare noapte pe un corpus în care se schimbă 1% din documente, plătești de aproximativ o sută de ori mai mult decât ar fi necesar. Iar tokenii de embedding sunt doar o parte — timpul de calcul, reconstrucția indexului și fereastra de calitate degradată în timpul migrării se adaugă peste.

Ce declanșează o reindexare completă

Trei lucruri, și merită știute dinainte, fiindcă sunt exact deciziile pe care le iei devreme și le regreți târziu:

1. Schimbarea strategiei de chunking — invalidează toate chunk-urile existente.
2. Schimbarea modelului de embedding — vectorii vechi și cei noi trăiesc în spații incompatibile. Tiparul de migrare e tratat în arhitectura sistemului.
3. Restructurarea schemei de metadate — dacă adaugi un câmp care trebuie populat retroactiv din conținut.

Analizele de cost pe proiecte de producție notează că aproape orice sistem RAG trece prin cel puțin o reindexare completă în primele luni de la lansare. Nu e semn de proiectare proastă; e consecința faptului că primele decizii se iau înainte de a avea date reale. Merită bugetată de la început, nu tratată ca incident.

Indexarea incrementală se plătește pe schimbare

Un pipeline incremental plătește proporțional cu ce s-a modificat efectiv. Diferența de ordin de mărime între cele două modele e argumentul principal pentru care reindexarea nocturnă completă a încetat să fie un default rezonabil.

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

O notă despre cifrele de degradare

Vei găsi frecvent afirmația că embedding-urile expirate reduc acuratețea retrieval-ului cu un anumit procent. Sursele care o repetă nu converg: unele vorbesc de o degradare de până la o cincime, altele de căderi mult mai mari, iar niciuna nu trimite la un studiu controlat verificabil.

Direcția e bine atestată și mecanic explicabilă. Magnitudinea nu e. Tratează cifrele publicate ca ilustrare, nu ca țintă, și măsoară degradarea pe corpusul tău — cu un set de evaluare care conține întrebări la care răspunsul s-a schimbat.

Întrebări frecvente

Cât de des trebuie reindexat un sistem RAG?

Nu există o cadență unică. Împarte corpusul pe clase de conținut, dă fiecăreia un prag de decalaj acceptabil, apoi alege mecanismul care îl respectă: push pentru ce se schimbă des și contează, polling pentru restul, plus o reconciliere periodică prin hash. Reindexarea completă rămâne pentru schimbări de chunking, de model de embedding sau de schemă.

De ce nu observ că indexul e expirat?

Pentru că similaritatea semantică nu codifică timpul. Un document expirat obține un scor la fel de mare ca cel curent, deci niciun prag de relevanță și niciun mecanism de detectare a retrieval-ului slab nu se declanșează. Degradarea e distribuită pe multe interogări, nu concentrată într-un eșec vizibil.

Ștergerea unui document din index îl elimină complet?

De obicei nu imediat. Majoritatea indexurilor marchează înregistrarea ca ștearsă și elimină fizic vectorul abia la o reconstrucție de index. Pentru date obișnuite e acceptabil; pentru date personale, distincția contează, iar calea de ștergere trebuie să includă reconstrucția și să fie testată capăt la capăt.

Cum detectez ștergerile de la sursă?

Pollingul pe timestamp nu le vede, fiindcă un document șters nu mai apare în nicio listă de modificări. Ai nevoie fie de evenimente de ștergere din sursă, fie de o reconciliere periodică ce compară mulțimea de identificatori din index cu cea din sursă și tratează diferența ca eroare.

Ce fac cu datele care se schimbă la fiecare câteva minute?

Nu le indexa. Citește-le live din sistemul de origine la momentul răspunsului și injectează-le în context ca date structurate. Indexarea are sens când întrebarea e semantică; pentru o valoare punctuală dintr-o bază de date, e efort irosit și sursă garantată de răspunsuri expirate.

Setul meu de evaluare trece, dar utilizatorii se plâng. De ce?

Probabil pentru că setul a fost construit când documentele erau proaspete și verifică fidelitatea față de context, nu valabilitatea contextului. Adaugă întrebări la care răspunsul corect s-a schimbat între timp — sunt singurele care detectează expirarea.

De unde începi

Cu un inventar, nu cu un pipeline.

Ia lista documentelor indexate și răspunde la trei întrebări pentru fiecare: din ce clasă de prospețime face parte, prin ce mecanism ar afla sistemul că s-a schimbat și prin ce mecanism ar afla că a fost șters. Dacă a treia coloană e goală pentru majoritatea rândurilor, ai găsit cea mai mare gaură din sistem — și aproape sigur cea care produce răspunsurile despre care utilizatorii spun că sună bine, dar nu mai sunt adevărate.

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