RAG trynimo koncepcija DI pokalbių robotams: turinio pašalinimas iš indekso, podėlio ir atsakymų

Kainoraščio galiojimas pasibaigė, saugos instrukcija buvo atšaukta arba klientas reikalauja pašalinti asmens duomenis. Šaltinio sistemoje atitinkamas failas ištrinamas greitai. Nepaisant to, svetainės pokalbių robotas dar minutėmis, valandomis ar net ilgiau gali remtis senuoju turiniu: kopija gali likti importavimo zonoje, failas buvo suskaidytas į kelias teksto atkarpas, kurių įterpiniai (embeddings) guli vektorių indekse, o atsakymų podėlis (cache) laiko jau suformuluotą teiginį. Todėl patikima RAG trynimo koncepcija apima ne tik pradinį failą, bet ir visą išvestinę grandinę.

Trynimo tikslas nėra aklai viską iškart sunaikinti. Reikalingas kontroliuojamas procesas, kuris pasenusį ar atšauktą turinį nedelsiant pašalina iš aktyvaus atsakymų srauto, atsižvelgia į teisinius bei veiklos saugojimo įsipareigojimus ir vėliau įrodo, kad paieška (retrieval) bei atsakymai šio turinio nebenaudoja. Būtent šis įrodymas atskiria paprastą trynimo veiksmą nuo patikimos eksploatavimo procedūros.

Kodėl trynimas RAG sistemoje yra daugiapakopis

Retrieval-Augmented Generation sujungia kalbos modelį su išorinėmis žiniomis. Tarp originalaus šaltinio ir atsakymo yra keli techniniai būviai: paieškos robotas (crawler) arba įkėlimas, normalizuotas failas, teksto atpažinimas, tekstyno fragmentai (chunks), metaduomenys, įterpiniai (embeddings), vektorių ir viso teksto indeksas, užklausų podėlis, pasirinktos radimvietės ir iš jų sugeneruotas atsakymas. Kai kurios sistemos papildomai išsaugo sesijų istoriją, kokybės pavyzdžius ar spartažymius (traces). Jei pašalinamas tik pirmasis būvis, žemiau esančios kopijos gali likti surandamos.

Prie to prisideda ir laiko problema. Trynimas gali būti apdorojamas asinchroniškai, kol lygiagrečiai gaunamos naujos užklausos. Naktinio perindeksavimo tuomet nepakanka: iki jo atlikimo pokalbių robotas ir toliau gali teikti atšauktą informaciją. Ir priešingai – vėlesnis importas neturi atsitiktinai atkurti šaltinio. Todėl kiekvienam trynimui reikia tiek greito blokavimo užklausos kelyje, tiek visiško išvalymo fone.

Iš anksto aiškiai apibrėžti trynimo apimtį

Pradžioje reikalinga stabili šaltinio tapatybė. Vien failo pavadinimo ar URL dažnai nepakanka, nes jie gali keistis arba kartotis. Naudinga naudoti vidinį šaltinio ID, versiją, tenantą, kalbą, prieigos sritį ir importuoto turinio maišos kodą (hash). Kiekvienas tekstyno fragmentas ir indeksuotas įrašas turi būti atsekamas iki šios tapatybės. Tik tada galima patikimai nustatyti, kurios išvestinės priklauso konkrečiam šaltiniui.

Po to nustatoma, ką konkrečiu atveju reiškia „ištrinta“. Pasenusiai produkto informacijai gali pakakti ją išjungti aktyvioje žinių bazėje ir pakeisti nauja versija. Atšaukimo, duomenų apsaugos užklausos ar licencijos pabaigos atveju gali būti taikomi griežtesni terminai ir papildomos saugojimo vietos. Atsarginėms kopijoms, saugumo protokolams ir teisiškai reikalaujamiems įrodymams dažnai galioja atskiros taisyklės. Todėl sprendime turėtų dalyvauti už duomenis atsakingi asmenys, operacijų komanda, o asmens duomenų ar reglamentuojamo turinio atveju – ir duomenų apsaugos bei teisės specialistai.

Saugus trynimo procesas per septynerius žingsnius

1. Užregistruoti ir patikrinti užklausą: Užfiksuokite šaltinio ID, versiją, priežastį, prašomą terminą, paveiktus tenantus ir asmenį ar vaidmenį, kuris davė leidimą. Jautrių trynimų atveju leidimai turi būti patikrinti prieš keičiant duomenis.
2. Nustatyti Tombstone: Iškart pažymėkite šaltinį kaip užblokuotą. Paieškos (retrieval) filtrai turi atsižvelgti į šią būseną, kad susiję tekstyno fragmentai nepatektų į naujus atsakymus, net jei fizinis valymas dar vyksta.
3. Išspręsti priklausomybes: Nustatykite neapdorotas kopijas, parserio rezultatus, tekstyno fragmentus, įterpinius, pilno teksto dokumentus, podėlius, iš anksto sugeneruotus atsakymų blokus ir, jei reikia, testavimo duomenų rinkinius. Šaltinio ID tarnauja kaip bendras raktas.
4. Išvalyti aktyvius indeksus: Ištrinkite arba išjunkite visus susijusius duomenų įrašus vektorių ir raktažodžių indekse. Patikrinkite atitinkamos tarnybos atsakymus; priimta užduotis dar nėra užbaigto trynimo įrodymas.
5. Panaikinti podėlių galiojimą (invalidate): Tikslingai išvalykite paieškos, užklausų ir atsakymų podėlius. Jei atrankinis galiojimo panaikinimas neįmanomas, padeda versijų raktai arba nauja vardų erdvė (namespace), kad seni įrašai nebūtų pasiekiami.
6. Atlikti patikrinimus: Pateikite užklausas su žinomomis formuluotėmis, dokumentų pavadinimais, retais terminais ir semantiškai panašiais variantais. Tiesioginė paieška pagal šaltinio ID ir imtis pokalbių robote neturi duoti jokių rezultatų.
7. Užbaigti procedūrą: Išsaugokite trumpą trynimo protokolą su laiku, apimtimi, sistemų atsakymais, patikrinimo rezultatu ir likusiais saugojimo terminais. Protokolas turi įrodyti procedūrą, bet bereikalingai nekopijuoti ištrinto turinio.

Kodėl „Tombstone“ žyma eina prieš fizinį trynimą

Ši tvarka apsaugo nuo dviejų tipinių klaidų. Pirma, paieškos robotas (crawler) ne visada gali tvarkingai priskirti ištrintą pradinį failą esamam indekso įrašui. Kai kurie indeksuotojai tikisi „Soft-Delete“ signalo, kol šaltinis dar yra atpažįstamas. Antra, vykdomos užduotys tarp šaltinio ištrynimo ir indekso išvalymo gali vėl įrašyti duomenis. Centrinė „Tombstone“ žyma blokuoja šį pakartotinį įtraukimą. Ji turėtų išlikti net ir tada, kai patys naudingieji duomenys jau pašalinti – tačiau tik su minimaliai būtinais metaduomenimis ir aiškiu saugojimo terminu.

Versijavimas padeda valdyti podėlio valymą

Podėliai yra itin neatsparūs klaidoms, jei raktai susideda tik iš vartotojo klausimo. Geresnis sprendimas – raktas, kuriame papildomai yra žinių bazės versija, tenantas, kalba ir teisių kontekstas. Po trynimo versija padidinama. Net jei pavienis podėlio įrašas techniškai dar egzistuoja iki jo galiojimo pabaigos, aktyvi programa jo pasiekti nebepajėgs. Tai nepakeičia tikslinio galiojimo panaikinimo kiekvienu atveju, tačiau sumažina riziką, kad vėl pasirodys seni atsakymai.

HTTP podėliai vadovaujasi savomis taisyklėmis. Standartas RFC 9111 aprašo, kada išsaugoti atsakymai yra švieži, pasenę arba naikintino galiojimo. RAG programoms iš to išplaukia: CDN, API ir taikomosios programos podėlius reikia vertinti atskirai. Vien tik nauja duomenų bazės versija neišvalo atsakymų podėlio, pateikiamo tinklo pakraštyje (edge service).

Konkretus pavyzdys: atšaukta montavimo instrukcija

Tarkime, gamintojas atšaukia montavimo instrukcijos 3 versiją, nes buvo pakeistas darbo žingsnis. 4 versija jau patvirtinta. Sistema šaltiniui V3 iškart nustato „Tombstone“ žymą ir publikuoja V4 su nauju versijos ID. Paieškos sistema (retriever) filtruoja tik patvirtintus šaltinius ir teikia pirmenybę esamai versijai. Lygiagrečiai fono procesas (worker) pašalina visus V3 tekstyno fragmentus iš vektorių bei pilno teksto indekso ir panaikina podėlių, kurių priklausomybių sąraše yra šis šaltinio ID, galiojimą.

Kokybės užtikrinimo komanda dabar užduoda ne tik klausimą „Kaip sumontuoti šią detalę?“. Ji taip pat naudoja būdingą formuluotę iš V3, parafrazuotą klausimą bei klausimą, į kurį anksčiau buvo galima atsakyti tik pagal V3. Tikimasi arba pagrįsto atsakymo iš V4, arba aiškios nuorodos, kad patvirtintos informacijos nėra. Nuoroda į V3 šaltinį, pažodinis fragmentas arba atsakymas be aktualios radimvietės laikomi klaida. Kaip šaltiniai atvaizduojami atsakingai, paaiškinta straipsnyje Kaip pagrįsti pokalbių roboto atsakymus šaltiniais.

Patikrinimas, ar trynimas iš tiesų veikia

Žalios API būsenos nepakanka. Patikrinimas turėtų vykti keliuose lygmenyse. Saugyklos lygmeniu ieškoma pagal šaltinio ID, tekstyno fragmentų ID ir žinomas maišas. Paieškos (retrieval) lygmeniu vykdomi testiniai klausimai ir tikrinamos grąžintos radimvietės. Atsakymų lygmeniu tikrinama, ar senasis teiginys dar neatsiranda pažodžiui ar pagal prasmę. Galiausiai reikalingas pakartotinio paleidimo testas: po paieškos roboto darbo, indekso perstatymo ar atsarginės kopijos atkūrimo šaltinis neturi sugrįžti.

Kiekvienai svarbiai žinių klasei išsaugokite nedidelį „Golden Set“ iš teigiamų ir neigiamų atvejų. Teigiami atvejai įrodo, kad pakaitinis šaltinis randamas teisingai; neigiami atvejai rodo, kad užblokuota informacija daugiau nebepasirodo. Ši procedūra papildo einamąjį procesą DI pokalbių roboto žinių bazės aktualumo kokybės užtikrinimą. Atliekant didesnius indekso pakeitimus, taip pat padeda lygiagretus naujas perstatymas su kontroliuojamu perjungimu, kaip aprašyta vadove apie RAG įterpinių modelio keitimą.

Kasdienės veiklos kontrolinis sąrašas

• Kiekvienas šaltinis turi stabilų ID, versiją, kilmę, kalbą ir atsakingą savininką.
• Tekstyno fragmentai, įterpiniai, indekso dokumentai ir podėliai yra atsekami iki šio šaltinio ID.
• „Tombstone“ žyma iškart užblokuoja šaltinį paieškoje ir neleidžia jo importuoti pakartotinai.
• Trynimo užduotis veikia idempotentiškai: pakartojimas nesukuria nei klaidų, nei naujų įrašų.
• Fono procesai (workers) praneša ne tik „priimta“, bet ir užbaigtą būseną su klaidų detalėmis.
• Paieškos ir atsakymų podėlių galiojimą galima panaikinti atrankiniu būdu arba atskirti per versijas.
• Tiesioginė paieška, semantinė paieška, atsakymų testas ir pakartotinio paleidimo testas yra dokumentuoti.
• Atsarginėms kopijoms ir žurnalams nustatyti apibrėžti saugojimo terminai bei vėlesnio atkūrimo procesas.
• Trynimo protokole yra tik būtini metaduomenys ir nėra bereikalingos pašalinto turinio kopijos.
• Atsakomybė, eskalavimas ir maksimalus apdorojimo laikas yra nustatyti ir reguliariai išbandomi.

Nemaišyti valdymo (governance) ir duomenų apsaugos

Techninė trynimo koncepcija atsako į klausimą, kaip šaltinis saugiai pašalinamas iš aktyvios RAG grandinės. Ar ir kada jis turi būti ištrintas – kitas klausimas. Bendrojo duomenų apsaugos reglamento 17 straipsnyje numatyta teisė būti pamirštam tam tikromis sąlygomis, taip pat ir išimtys. Todėl bendras pareiškimas, pavyzdžiui, „kiekviena užklausa iškart ištrina kiekvieną atsarginę kopiją“, būtų toks pat rizikingas, kaip ir neribotas saugojimas be tikslo. Taikytinas teisinis pagrindas ir terminas turi būti nustatyti konkrečiam naudojimo atvejui; oficialų reglamento tekstą galima rasti per EUR-Lex.

Organizaciniu požiūriu ši procedūra priklauso turinio valdymui (Content Governance): kas gali atšaukti turinį? Kas patvirtina išvalymą? Kas nutinka, jei išorinė vektorių tarnyba nepasiekiama? Straipsnis DI pokalbių roboto turinio valdymas rodo, kaip sąveikauja savininkai, patvirtinimai ir pokyčių kontrolė (Change Control). Didelės rizikos atvejais rekomenduojamas keturių akių principas; įprastiems atnaujinimams gali pakakti automatizuotos, visiškai protokoluojamos darbo eigos.

Oficialūs šaltiniai ir techninės nuorodos

• Microsoft Learn: Pakeistų ir ištrintų objektų (blobs) atpažinimas „Azure AI Search“
• Microsoft Learn: Documents API skirtas „Azure AI Search“
• Google Cloud: Failų ir korpusų valdymas „Vertex AI RAG Engine“
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Bendrasis duomenų apsaugos reglamentas

Išvada: Galimybė ištrinti yra kokybės funkcija

RAG žinių bazė yra patikima tik tada, kai turinį galima ne tik įtraukti, bet ir kontroliuojamai atšaukti. Stabilūs šaltinių ID, „Tombstone“ žymos, priklausomybių sąrašai, versijuojami podėliai ir atkartojami testai paverčia nesaugią vienkartinę akciją valdomu procesu. Tie, kurie čia sujungia profesinį patvirtinimą, techninį išvalymą ir įrodomą kokybės užtikrinimą (QA), sumažina pasenusių atsakymų kiekį ir sukuria pagrindą pokalbių robotui, kurio žinias galima sąmoningai valdyti.