Actualitatea datelor RAG este capacitatea unui sistem de recuperare de a reflecta sursa aprobată curentă, inclusiv actualizările, ștergerile și schimbările de acces. Încărcarea regulată a documentelor noi este doar o parte a lucrării. Fragmentele vechi, răspunsurile din cache și traseele de ștergere eșuate pot continua să influențeze ce spune un asistent.
Definiți actualitatea ca un contract observabil de la sursă la răspuns, cu trasee deliberate pentru actualizări, retrageri și schimbări de permisiuni. Păstrați identitatea documentelor și dovezile versiunilor, reconciliați indexul cu sursa și testați că materialul retras nu mai apare. Un marcaj temporal recent al ingestiei nu stabilește singur un răspuns actual sau autorizat.
Imaginați-vă un asistent intern care răspunde despre o procedură de furnizor. Operațiunile au înlocuit documentul, dar asistentul recuperează un fragment din versiunea înlocuită. Răspunsul poate fi fluent și poate cita corect acel fragment vechi, îndrumând totuși personalul spre procesul greșit.
Acest ghid se concentrează pe întreținerea datelor de recuperare după prima implementare. Explicația noastră despre RAG introduce abordarea mai largă; decizia de aici este cum păstrați fiabil un flux existent de cunoștințe.
Definiți actualitatea datelor RAG pentru fiecare sursă
Întrebați ce schimbări contează și cât de repede trebuie reflectate pentru afacere. Un manual istoric, o înregistrare de stoc actuală și o politică retrasă nu au cerințe identice de actualizare. Definiți așteptări separate când consecința informației depășite diferă.
Identificați sursa autoritativă și cine o aprobă. Un director comun poate conține ciorne, duplicate și materiale arhivate. Ingestia tuturor lucrurilor schimbate recent nu stabilește ce versiune trebuie să urmeze personalul. Autoritatea conținutului necesită o regulă de afaceri înainte de a deveni regulă de indexare.
| Schimbarea sursei | Comportament necesar de definit | Dovezi de examinat |
|---|---|---|
| Revizie aprobată | Înlocuiți sau substituiți conținutul relevant indexat | Referințe ale versiunilor sursă și indexate |
| Retragerea documentului | Eliminați eligibilitatea sa pentru recuperare | Absența din teste controlate de recuperare |
| Schimbarea permisiunii | Aplicați noua limită de acces | Rezultate sub identitățile utilizatorilor afectați |
| Mutarea sau redenumirea fișierului | Păstrați sau schimbați deliberat identitatea documentului | Mapare stabilă și reconcilierea linkurilor |
| Eșecul ingestiei | Expuneți starea depășită sau indisponibilă | Alertă cu responsabil și ultima versiune confirmată |
Nu promiteți un interval universal de actualitate înainte de a înțelege API-ul sursei, procesul de indexare și cerința operațională. Propunerea furnizorului trebuie să precizeze ce este măsurabil, ce poate întârzia și ce face asistentul cât actualizarea este în așteptare.
Păstrați identitatea între documente și fragmente
Dați înregistrărilor sursă o identitate stabilă care supraviețuiește actualizărilor obișnuite, unde sursa permite. Păstrați versiunea, locația de recuperare și relația cu fragmentele. Numele fișierului singur poate fi insuficient când fișierele sunt redenumite, copiate sau înlocuite în același loc.
Prezentarea indexerilor Azure AI Search de la Microsoft descrie indexerii drept componente de ingestie din surse de date. Citiți comportamentul real de urmărire a schimbărilor al conectorului ales. O execuție programată este un mecanism, nu dovada detectării fiecărei operațiuni sursă.
Păstrați maparea sursă-fragment examinabilă. Când un paragraf se schimbă, sistemul trebuie să știe ce fragmente anterioare sunt înlocuite. Adăugarea fragmentelor noi fără retragerea celor vechi poate produce dovezi contradictorii chiar dacă fiecare embedding individual este valid tehnic.
Înregistrați cum au fost produse câmpurile derivate. Extragerea textului, normalizarea și fragmentarea pot schimba sensul indexat. Când un răspuns devine greșit după actualizarea pipelineului, operatorul trebuie să poată distinge revizia sursei de o schimbare a extragerii sau recuperării.
Tratați ștergerea ca un ciclu separat
Nu presupuneți că dispariția unui fișier din stocare elimină automat reprezentarea sa indexată. Ghidul Microsoft pentru detectarea schimbărilor și ștergerilor distinge explicit urmărirea actualizărilor de detectarea ștergerilor pentru indexerii săi de stocare și descrie strategiile acceptate de ștergere.
Detaliul implementării depinde de platformă, dar întrebarea de acceptare este generală: după o retragere aprobată, asistentul mai poate recupera materialul vechi? Testați indexul relevant, fragmentele derivate și cache-urile răspunsurilor, nu doar directorul sursă.
Reconciliați după o ștergere întreruptă
Păstrați evidența retragerilor până la confirmarea stării ulterioare. Dacă obiectul sursă este eliminat permanent înainte ca indexerul să observe marcajul ștergerii, sistemul poate pierde semnalul de care depindea. Folosiți ciclul acceptat de furnizorul ales și verificați starea finală.
Includeți transformările unu-la-mai-multe în proiectare. Un document poate crea mai multe fragmente sau înregistrări. Traseul ștergerii trebuie să țină cont de aceste obiecte derivate. Eliminarea unui rând părinte de metadate cu păstrarea copiilor recuperabile nu este o retragere acceptată.
Aplicați schimbările de permisiune la recuperare
Conținutul actual poate fi tot conținut greșit pentru utilizatorul solicitant. Identificați unde se impune autoritatea actuală a utilizatorului și organizației. Copierea o singură dată a permisiunii sursă în metadate nu dovedește că o schimbare ulterioară de apartenență ajunge la limita recuperării.
Ghidul OWASP privind autorizarea recomandă verificarea accesului la fiecare cerere. Aplicați principiul recuperării și linkurilor din răspuns. O citare nu trebuie să dezvăluie un titlu sau fragment de document pe care utilizatorul nu are voie să îl examineze.
| Nivel de recuperare | Schimbare de testat | Întrebare de acceptare |
|---|---|---|
| Conector sursă | Apartenența utilizatorului sau grupului se schimbă | Ingestia păstrează domeniul urmărit? |
| Interogare de căutare | Un utilizator pierde accesul la document | Documentul este exclus din rezultate? |
| Cache de răspunsuri | Un răspuns anterior conține text restricționat | O cerere ulterioară poate primi divulgarea din cache? |
| Link de citare | Locația sursei se schimbă | Utilizatorul ajunge la versiunea corectă permisă? |
Ghidul nostru pentru asistentul AI intern acoperă fluxul mai larg al angajaților. Întreținerea actualității trebuie să corespundă acelui model de permisiuni, nu să creeze un traseu separat de date cu autoritate mai largă.
Faceți dovezile depășite vizibile operatorilor
Înregistrați ultima versiune sursă confirmată și punctul atins de ingestie. Separați preluarea sursei, extragerea, indexarea și validarea recuperării. Un pipeline poate prelua cu succes, dar poate eșua la indexarea conținutului revizuit, astfel încât un singur marcaj al ultimei execuții poate induce în eroare.
Alegeți alertele după așteptarea convenită pentru sursă. Un document arhival neschimbat nu necesită alarmă doar fiindcă este vechi. O actualizare eșuată a unei proceduri operaționale poate necesita investigație chiar dacă indexul a fost actualizat cu succes puțin mai devreme.
Arătați utilizatorilor o stare adecvată de incertitudine când nu pot fi stabilite dovezi actuale. Poate fi o cerere de consultare a responsabilului sau refuzul de a răspunde dintr-o sursă retrasă. Evitați prezentarea sigură pe sine a textului vechi doar fiindcă există un rezultat de recuperare.
Păstrați jurnalizarea proporțională. Identificatorii sursă, versiunile și rezultatele pipelineului pot susține investigația fără copierea fiecărui document confidențial într-un sistem general de telemetrie. Conveniți separat accesul și păstrarea oricărui conținut capturat.
Testați întregul ciclu cu documente controlate
Creați un corpus mic controlat, cu afirmații recognoscibile și versiuni deliberat diferite. Puneți aceeași întrebare relevantă înainte și după actualizare, retragere sau schimbare de permisiune. Examinați dovezile recuperate, precum și răspunsul final.
Includeți procesarea eșuată și întârziată. Opriți o actualizare controlată între etape, apoi demonstrați reluarea și reconcilierea. Testați redenumirea, înlocuirea și sursele duplicate acceptate de conectorul urmărit. Păstrați documentată decizia așteptată de identitate.
Ghidul nostru de evaluare a agenților AI explică separarea unui răspuns util de dovada rezultatului acceptat. Aici acceptarea include retragerea materialelor de recuperare înlocuite și impunerea accesului actual al solicitantului, nu doar proză care sună mai recentă.
Păstrați documentele de test ale ciclului ca cazuri de regresie. Reverificați după schimbarea extragerii, fragmentării, indexării sau cache-ului. Un model nou de recuperare poate îmbunătăți relevanța răspunsului și totodată expune o problemă ascunsă de înregistrări vechi.
Comparați reparația cu înlocuirea pipelineului
Începeți prin localizarea rupturii din ciclu. Gestionarea lipsă a ștergerii, identitatea instabilă sau un cache delimitat incorect pot avea o reparație restrânsă. O bază vectorială nouă nu repară autoritatea neclară a sursei sau ingestia care nu înregistrează niciodată retragerile.
| Pachet de lucru | Livrabil | Factor de domeniu |
|---|---|---|
| Auditul ciclului | Identitate sursă-index și harta erorilor | Numărul și comportamentul conectorilor |
| Repararea actualizării și ștergerii | Schimbări repetabile ale stării ulterioare | Fragmente derivate și contracte ale furnizorilor |
| Verificarea permisiunilor | Dovezi actuale de recuperare delimitate pe utilizator | Apartenența la sursă și proiectarea cache-ului |
| Operațiuni | Reconciliere și alerte cu responsabil | Așteptările necesare de actualitate |
| Predare | Documente de test ale ciclului și documentație | Frecvența schimbărilor sursei și pipelineului |
Solicitați propuneri în GBP legate de aceste rezultate. Separați reparația inițială de costurile ingestiei, stocării, recuperării și întreținerii continue. Un preț bazat numai pe numărul documentelor poate omite partea dificilă: păstrarea documentelor potrivite actuale și autorizate.
Pilotul nostru de integrare AI cu domeniu definit poate începe cu un exemplu de răspuns depășit și sursa autoritativă. Trimiteți-ne actualizarea sau retragerea ratată de asistent pentru a discuta o investigație delimitată și o reparație acceptată a ciclului.
Întrebări frecvente
Ce este actualitatea datelor RAG? Este relația dintre materialul sursă aprobat curent și dovezile disponibile recuperării și răspunsurilor. Include actualizări, retrageri, schimbări de identitate și permisiuni, nu doar data ultimei execuții de ingestie.
Reindexarea elimină automat documentele șterse? Nu neapărat. Verificați comportamentul acceptat de ștergere al conectorului ales și verificați fragmentele derivate, precum și înregistrările părinte. Unele platforme necesită o strategie explicită de ștergere.
Trebuie să regenerăm embeddingurile fiecărui document la fiecare execuție? Nu este o cerință universală. Folosiți identitate sursă stabilă și urmărirea schimbărilor unde este potrivit, apoi reconciliați starea rezultată. Rezultatul important este o dovadă de recuperare actuală, completă și autorizată.
Cât de actual trebuie să fie sistemul? Definiți după sursă și consecință. O instrucțiune operațională retrasă poate necesita alt tratament decât o arhivă istorică. Precizați comportamentul așteptat de actualizare și alternativa când nu poate fi îndeplinit.
Cache-ul răspunsurilor poate crea rezultate depășite? Da. Un index actual nu invalidează automat un cache vechi de răspunsuri. Testați relația cache-ului cu versiunile sursă, retragerea și permisiunile utilizatorului, inclusiv după revocarea accesului.
De ce contează fișierele redenumite? Pot schimba identitatea sau locația folosită de conector. Altfel sistemul poate crea un duplicat sau pierde maparea la fragmentele anterioare. Definiți dacă redenumirea păstrează aceeași înregistrare sursă și testați comportamentul real al furnizorului.
Avem nevoie de o bază de date vectorială nouă? Nu automat. Localizați mai întâi defectul ciclului. O problemă delimitată de actualizare, ștergere sau cache poate fi reparabilă în pipelineul existent. Înlocuirea trebuie justificată după aceleași cerințe de actualitate și responsabilitate.
Ce trebuie să predea un furnizor de întreținere? Mapările sursă, regulile ciclului, instrucțiunile de reconciliere, documentele controlate de regresie și dovezile testelor de actualizare, retragere și permisiuni. Includeți limitările cunoscute ale conectorilor și responsabilul erorilor nerezolvate.