Schimbarea modelului de embedding RAG: Migrarea chatbotului AI fără goluri de cunoștințe

Un model de embedding funcționează de obicei invizibil în fundalul unui chatbot RAG. Acesta traduce întrebările și modulele de cunoștințe în vectori numerici pentru a găsi conținutul potrivit din punct de vedere semantic. Tocmai pentru că această parte apare rareori într-o interfață de utilizator, schimbarea modelului pare la prima vedere o simplă modificare de configurare. Din punct de vedere tehnic, însă, se creează un nou spațiu de căutare. Vectorii de documente existenți, vectorii noilor întrebări și definiția indexului trebuie să se potrivească din nou între ei.

Cine dorește să schimbe embeddings RAG nu ar trebui, prin urmare, să înlocuiască pur și simplu numele modelului în pipeline-ul de interogare. O schimbare sigură tratează noul index ca pe o versiune de sine stătătoare: construită de mod reproductibil, verificată cu aceleași întrebări de test, rulată inițial în paralel și activată doar după o decizie deliberată de lansare. În acest fel, chatbotul de pe site rămâne accesibil, în timp ce echipa menține sub control calitatea, timpul de executare, costurile și calea de revenire.

De ce modelele de embedding nu sunt interschimbabile după bunul plac

Un vector are sens doar în cadrul spațiului în care a fost generat. Documentația oficială Azure AI Search privind crearea unui index vectorial descrie indexul ca pe un spațiu de embedding compus din vectori ai aceluiași model. De asemenea, aceasta subliniază că dimensiunea fiecărui vector trebuie să corespundă definiției câmpului. Un model nou poate avea o altă dimensiune, alte atuuri lingvistice sau o altă distribuție a distanțelor semantice.

La fel de importantă este partea de interogare (query). Conform documentației Microsoft privind configurarea vectorizer-ului, indexarea și interogarea trebuie să utilizeze același model de embedding. Dacă o echipă amestecă vectori de documente vechi cu întrebări provenite dintr-un model nou, scorurile de similaritate nu mai pot fi interpretate cu incredere. Chiar dacă dimensiunea este din întâmplare identică, acest lucru nu dovedește o compatibilitate semantică.

Definirea unui obiectiv măsurabil înainte de schimbare

„Mai nou” nu este un criteriu suficient de recepție. Înainte de prima reindexare, echipa are nevoie de un motiv concret pentru migrare. Ar trebui să crească calitatea rezultatelor în limbaj de specialitate? Sunt necesare limbi suplimentare? Modelul anterior este depreciat, prea lent sau prea scump? Sau ar trebui ca o dimensiune mai mică a vectorilor să economisească spațiu de stocare? Din obiectivul stabilit rezultă metricile de comparație.

• Calitate: surse relevante în top-k, ponderea întrebărilor la care se poate răspunde și calitatea răspunsului final.
• Operare: latența de recuperare (retrieval), rata de eroare, durata de indexare și comportamentul în caz de erori parțiale.
• Costuri: generarea vectorilor pentru întregul set de date, modificările curente, stocarea și interogările.
• Acoperire: documente, limbi, versiuni de produse și niveluri de permisiune în noul index.

Valorile de pornire trebuie incluse în același raport de evaluare ca și rezultatele candidatului. Cei care mențin deja un Golden Set pot folosi ca bază ghidul existent pentru măsurarea calității răspunsurilor chatbotului AI. Important este să nu se compare doar un scor mediu: întrebările critice de suport, termenii tehnici rari și cazurile fără rezultate (no-result) merită evaluări separate.

Doi indici în loc de modificări pe un sistem live

Standardul robust este un index paralel. Indexul anterior rămâne neschimbat și deservește traficul live. În paralel, se creează o nouă colecție sau un nou index cu propriul identificator de model, dimensiune, metrică de distanță și număr de versiune. Ambele sunt construite din aceeași versiune de sursă aprobată. Astfel, diferențele pot fi atribuite modelului sau configurației indexului, în loc să se compare simultan conținuturi în schimbare.

Ghidul oficial Weaviate pentru schimbarea unui vectorizer prezintă în acest scop colecții separate și un alias ca punct de comutare reversibil. Produsul concret poate varia; principiul rămâne valabil: izolați clar embeddings vechi și noi, direcționați accesul printr-un router sau alias controlat și păstrați starea veche pentru o perioadă limitată de rollback.

Identități stabile pentru fiecare modul de cunoștințe

Fiecare chunk are nevoie de un ID funcțional stabil, care nu depinde de vector. Este recomandată o combinație de ID sursă, versiune sursă, secțiune și versiune de chunk. În plus, fiecare set de date ar trebui să conțină numele modelului, versiunea modelului, dimensiunea, momentul creării și hash-ul textului integrat. Astfel, pipeline-ul poate identifica exact ce a fost deja procesat, ce trebuie re-vectorizat și ce erori sunt încă deschise.

Fixarea noului pipeline într-un mod reproductibil

Înainte de alimentarea masivă de date (backfill), o mică submulțime reprezentativă ar trebui să treacă prin noul pipeline. Extragerea, curățarea și segmentarea RAG (chunking) rămân inițial neschimbate. Dacă echipa modifică simultan modelul, limitele chunk-urilor, metadatele și clasarea (ranking), o diferență ulterioară de calitate va fi extrem de greu de explicat.

Configurația trebuie salvată ca un manifest versionat asociat rulării: modelul și furnizorul, dimensiunea, normalizarea, metrica de distanță, dimensiunea lotului (batch size), regulile de reîncercare, versiunea chunker-ului, limbile permise și metadatele necesare. Datele de acces nu au ce căuta acolo. Pentru fiecare lot sunt salvate doar ID-urile, contoarele, starea și un cod de eroare sigur. Astfel, o rulare întreruptă poate fi reluată fără a repeta costisitor integrările reușite.

Re-embedding controlat și demonstrarea completitudinii

O reindexare este completă doar atunci când stocul planificat coincide cu cel real. Un număr mare de documente nu este suficient. Pipeline-ul ar trebui să verifice pentru fiecare sursă dacă sunt prezente toate chunk-urile așteptate, dacă hash-urile lor de text corespund versiunii sursă aprobate și dacă au fost preluate toate metadatele obligatorii. Seturile de date eșuate ajung într-o coadă de reîncercare limitată; erorile permanente rămân vizibile împreună cu ID-ul lor și nu trebuie să dispară sub un statut general de succes.

1. Înghețați sau marcați clar stocul sursă și data de referință a versiunii.
2. Creați noua structură de index cu dimensiunea și metrica potrivite.
3. Generați embeddings și salvați chunk-urile în loturi limitate și idempotente.
4. Comparați numărul de documente, chunk-uri și metadata cu stocul țintă.
5. Verificați un eșantion pe baza hash-ului de text, ID-ului sursei și conținutului accesibil.

Compararea căutării (retrieval) folosind întrebări identice

Acum, aceleași întrebări de test sunt rulate pe ambii indici. Pe lângă rata de succes și poziția în clasament, echipa ar trebui să compare sursele returnate efectiv. A promovat noul index secțiuni similare semantic, dar incorecte din punct de vedere tehnic? Se pierd coduri exacte de produse? Sunt găsite mai bine cuvintele compuse sau întrebările multilingve? Un concept de Hybrid Search și Reranking existent trebuie configurat identic pentru ambii candidați, astfel încât comparația să fie echitabilă.

Documentația Azure privind relevanța vectorială și ranking-ul menționează căutarea exhaustivă k-nearest-neighbor ca posibilitate de a construi un set de referință (ground truth) pentru evaluarea Recall-ului unei proceduri aproximative ANN. Acesta nu este un prag universal, ci un test de control util: mai întâi referința exactă, apoi căutarea mai rapidă din producție. Pentru chatbot contează în plus dacă sursele găsite permit un răspuns corect și argumentat.

Verificarea răspunsului final, nu doar a rezultatelor

O poziție mai bună în căutare nu garantează încă un răspuns mai bun din partea chatbotului. De aceea, comparația ar trebui să includă și trimiterea la sursă, completitudinea, incertitudinea permisă și întreruperea sigură în cazul dovezilor insuficiente. În acest proces, modelul de răspuns, instrucțiunile de sistem și temperatura trebuie menținute cât mai constante posibil. Altfel, testul va măsura mai multe modificări în același timp.

Shadow Reads înainte de tranziția efectivă (cutover)

După testarea offline, o mică parte din interogările reale de căutare (tratate cu atenție privind protecția datelor) pot fi rulate în paralel și pe noul index, fără ca rezultatul să fie afișat utilizatorilor. Această citire de tip Shadow Read măsoară limbajul real, latența și comportamentul în caz de lipsă de rezultate. Conținutul privat, datele cu caracter personal și istoricul complet al conversațiilor nu trebuie incluse neevaluate în jurnalele de comparație. Adesea, sunt suficiente clase de interogări pseudonimizate, ID-uri de rezultate și metrici tehnice.

Procesul de cutover în sine este o modificare mică, ușor de observat: aliasul, destinația routerului sau un feature flag comută de la Index A la Index B. În prima fază, se aplică limite mai stricte de alertă pentru surse lipsă, erori de căutare, latență și rata de transfer către operatori umani (handoff). O trecere treptată are sens dacă arhitectura o permite fără a amesteca stările sesiunilor.

Testarea practică a planului de rollback înainte de comutare

Un plan de rollback este de încredere doar dacă vechiul index rămâne suficient de actualizat și calea de revenire a fost testată. În timpul fazei paralele, sursele noi sau modificate ar trebui să curgă controlat în ambele pipeline-uri. Alternativ, echipa poate documenta o scurtă pauză de modificări și o sincronizare ulterioară clară. Ghidul existent pentru Incident Response și Rollback ajută la stabilirea declanșatorilor și a responsabilităților.

Semnalele tipice pentru o revenire nu sunt doar erorile tehnice. O scădere semnificativă a rezultatelor relevante din top-k, noi goluri lingvistice, un număr neobișnuit de mare de întrebări fără răspuns sau filtre de acces aplicate greșit justifică, de asemenea, revenirea. Indexul vechi este eliminat doar după încheierea perioadei de monitorizare, când aprobarea de ștergere este documentată și nu mai există nicio diferență de calitate neclarificată.

Erori frecvente în migrarea embeddings

• Schimbarea doar pe partea de query: Noi vectori de întrebări sunt comparați cu un spațiu vechi de documente.
• Confundarea aceleiași dimensiuni cu compatibilitatea: Lungimea vectorului și spațiul semantic nu sunt același lucru.
• Modificarea mai multor variabile în același timp: Modelul, chunking-ul și ranking-ul se schimbă simultan; cauza unui efect rămâne neclară.
• Analizarea doar a valorilor medii: Întrebările rare, critice pentru afacere sau multilingve dispar în medie.
• Curățarea prea devreme: Indexul vechi este șters înainte ca sarcina reală și datele de calitate să arate o funcționare stabilă.
• Omiterea filtrelor: Limba, versiunea și drepturile de acces nu se aplică în noul index exact ca în cel vechi.

Listă de verificare practică pentru echipele web

• Obiectivul, linia de bază (baseline), criteriile de acceptare, persoana care aprobă și semnalul de rollback sunt documentate.
• Indexul vechi și cel nou rămân separate; modelul, dimensiunea și metrica sunt clar versionate.
• Amboii indici provin din aceeași versiune aprobată de sursă și de chunk-uri.
• Procesul de backfill este idempotent, poate fi reluat și este verificat față de stocul țintă.
• Golden Set-ul, întrebările critice, limbile, cazurile fără rezultat și filtrele de acces trec comparația.
• Procesele de Shadow Read înregistrează doar datele tehnice necesare.
• Cutover-ul și revenirea sunt schimbări mici, monitorizabile și testate practic.
• Stocul vechi este șters doar după perioada de monitorizare și aprobarea documentată.

Concluzie: Noul spațiu vectorial are nevoie de propriul proces de lansare

Schimbarea modelelor de embedding RAG este o migrare de date și calitate, nu un simplu buton de comutare a modelului. Cine construiește noul spațiu de căutare separat, generează complet noile embeddings, le compară folosind întrebări identice și activează totul printr-un punct de comutare reversibil reduce considerabil riscurile de indisponibilitate și scădere a calității. Pentru echipele web, merită pus în aplicare un proces scurt și reutilizabil: securizarea liniei de bază, construirea indexului paralel, verificarea recuperării și a răspunsurilor, observarea datelor shadow, comutarea controlată și menținerea deschisă a căii de revenire.

Dacă chatbotul dvs. AI folosește deja o bază de cunoștințe RAG, nu începeți cu migrarea, ci cu setul de date de testare. Între zece și douăzeci de clase de întrebări deosebit de importante, completate de cazuri dificile de limbă, produse și permisiuni, fac diferența între o schimbare plauzibilă de model și o lansare demonstrabil sigură.

Surse

• Microsoft Learn: Create a vector index in Azure AI Search
• Microsoft Learn: Configure a vectorizer in Azure AI Search
• Microsoft Learn: Relevance in vector search
• Weaviate Documentation: Switching vectorizers