Căutare hibridă și reranking pentru chatboturi AI: rezultate RAG mai bune

Chatboturile pentru site-uri web eșuează rareori din cauză că o bază de cunoștințe nu conține deloc informații. Mai frecvent, pasul de preluare (retrieval) nu găsește pasajul care se potrivește întrebării și contextului specific. Vizitatorii folosesc nume de produse, mesaje de eroare și coduri de articole, dar formulează și liber: „De ce afișează chatbotul tariful greșit?” sau „Mai pot modifica o comandă deja expediată?” Pentru această combinație, nici căutarea bazată exclusiv pe cuvinte cheie, nici cea vectorială nu reprezintă un răspuns universal suficient. Căutarea hibridă (Hybrid Search) conectează ambele semnale, astfel încât un chatbot RAG să primească surse mai solide în contextul răspunsului său.

Căutarea după cuvinte cheie și căutarea vectorială îndeplinesc sarcini diferite

Căutarea după cuvinte cheie este puternică atunci când termenii trebuie să apară exact. Acest lucru este valabil pentru numere de comandă, denumiri de produse, mesaje de eroare concrete, nume de contracte sau o versiune precum „2.4”. Aceasta poate arăta clar de ce se potrivește un document: cuvântul căutat se află în titlu, într-un subtitlu sau în pasaj. Punctul ei slab apare la limbajul cotidian, sinonime și formulări incomplete. O întrebare a unui vizitator despre o „copie a facturii” nu va găsi neapărat o pagină care vorbește doar despre „descărcarea chitanței”.

Căutarea vectorială completează această lipsă. Ea reprezintă întrebarea și conținutul ca o proximitate semantică și poate găsi astfel solicitări similare, deși lipsesc aceiași termeni. Acest lucru ajută la întrebările de suport formulate natural, variantele multilingve și denumirile diferite pentru același proces. Totuși, proximitatea semantică singură nu este un cec în alb: un pasaj poate fi similar ca temă, dar se poate referi la o altă versiune de produs, o altă piață sau o regulă expirată. Tocmai de aceea, verificarea contextului aparține fluxului de preluare (retrieval pipeline) și nu doar modelului de limbaj.

De ce căutarea hibridă este un punct de plecare util

Microsoft descrie Hybrid Search ca pe o interogare comună formată dintr-o parte de text integral și o parte vectorială. Ambele interogări rulează în paralel, iar listele lor de rezultate sunt ulterior combinate. Acest lucru este atractiv pentru site-urile companiilor, deoarece termenii exacți sunt păstrați, permițând în același timp accesul la conținuturi conexe și bine formulate. Un chatbot nu trebuie să pună vizitatorii să aleagă între o căutare „tehnică” și una „semantică”. Selecția are loc în fundal și poate fi verificată pentru toate întrebările cu același proces de calitate.

Hybrid Search îmbunătățește setul de candidați; ea nu generează un adevăr absolut. Chatbotul are voie să folosească doar conținuturi care sunt aprobate pentru situația concretă. Paginile web publice, ciornele interne și datele protejate ale clienților nu trebuie să ajungă într-un context comun necontrolat. La fel de important este un comportament clar atunci când nu este disponibilă nicio sursă potrivită: o clarificare, un link către pagina de contact sau un Human Handoff sunt mai sigure decât o presupunere formulată fluent.

Pe înțelesul tuturor: fuzionarea clasamentelor cu RRF

Scorurile din căutarea de text integral și cea vectorială au semnificații și scări diferite. Adunarea lor directă sau inventarea unei limite fixe duce adesea la rezultate instabile. Reciprocal Rank Fusion, pe scurt RRF, lucrează de aceea cu poziția unui document în fiecare clasament. Un document care apare sus în ambele liste primește un semnal combinat puternic. Un document care este vizibil doar într-o singură listă poate fi luat în considerare, dar nu va înlocui automat tot restul.

RRF nu este o valoare standard magică și nici o formulă de înlocuire pentru testele de specialitate. Numărul de candidați din fiecare căutare care ajung în fuziune, filtrele aplicate în prealabil și momentul în care un rezultat este considerat util depind de conținut și de risc. Pentru întrebările frecvente despre produse, o fereastră mică și concentrată poate avea sens. Pentru instrucțiuni complexe sau diagnosticarea erorilor, ar putea fi necesari mai mulți candidați. Decisivă este compararea modificărilor cu întrebări reale pe un set de testare, în loc de preluarea unui parametru universal dintr-un exemplu.

Reranking-ul semantic ca a doua etapă, limitată

După o preselecție bună, un reranker poate evalua din nou setul restrâns de candidați în raport cu întreaga întrebare. Microsoft încadrează clasarea semantică ca o clasare secundară aplicată peste o listă de rezultate deja clasate. Amazon Bedrock descrie reranking-ul în mod similar, ca o evaluare a documentelor textuale privind relevanța lor pentru interogare. Această a doua etapă este potrivită pentru întrebări cu mai multe condiții: de exemplu, dacă o Schimbare de tarif este posibilă după ce o comandă a fost deja expediată și există un anumit tip de contract.

Reranking-ul ar trebui limitat cu atenție. Acesta adaugă latență suplimentară și, în funcție de serviciu, poate fi contra cost. Prin urmare, nu trimiteți întreaga bază de cunoștințe către un reranker, ci doar setul superior (Top) deja filtrat și fuzionat. Definiți un buget de timp și o opțiune de rezervă (fallback). Dacă bugetul este depășit, chatbotul poate afișa lista celor mai sigure surse, poate cere o clarificare sau poate transfera conversația către o echipă de suport. Un reranker nu repară conținuturile învechite, lipsă sau neaprobate.

Filtrele de metdate protejează contextul

Metadatele decid adesea mai mult asupra calității răspunsului decât o opțiune suplimentară a modelului. Mențineți pentru fiecare sursă cel puțin limba, produsul sau serviciul, versiunea, piața, grupul țintă și valabilitatea, în măsura în care aceste date sunt relevante pentru utilizare. Un filtru pe clientul (tenant) corect sau pe zona de autorizare trebuie să acționeze înainte de generarea răspunsului. Pe un site public, un chatbot poate prelua doar conținut public; pentru o zonă autentificată se aplică permisiuni suplimentare verificabile.

De asemenea, timpul este o problemă de metdate. Listele de prețuri, condițiile de livrare și ghidurile ar trebui să poarte o dată clară de actualizare sau un statut de valabilitate controlat. Dacă sursa nu mai este de încredere, ea trebuie eliminată din index sau mutată într-un flux separat de verificare. Filtrele trebuie să reflecte cerințe de înțeles pentru vizitatori, nu să manipuleze în secret ordinea rezultatelor. Documentați de aceea ce filtre se aplică pentru fiecare categorie de întrebări și cum verifică o echipă modificările.

Un flux concret de la interogare la context

1. Normalizarea întrebării: Identificați limba și contextul evident, fără a stoca sau modifica inutil datele cu caracter personal.
2. Verificarea accesului și a metadatelor: Determinați înainte de preluare ce surse sunt permise pentru produs, piață, rol și perioada de valabilitate.
3. Preluare paralelă: Executați căutarea de text integral și cea vectorială pe același set de surse permise.
4. Fuzionarea clasamentelor: Combinați listele folosind RRF și păstrați semnalele de origine pentru fiecare candidat în scop de debugging.
5. Reranking limitat: Executați evaluarea relevanței doar pe setul restrâns de top și măsurați latența.
6. Securizarea contextului: Verificați duplicatele, statutul surselor și o lungime adecvată înainte ca pasajele să meargă la modelul de răspuns.
7. Răspuns cu limite clare: Indicați sursele, marcați nesiguranța și folosiți la nevoie un transfer sigur către un operator uman.

Exemplu practic: statusul livrării și schimbarea tarifului

Să presupunem că un vizitator întreabă: „Mai pot schimba tariful deși pachetul este deja pe drum?” Căutarea după cuvinte cheie ar putea găsi o pagină despre „Schimbare tarif” și un articol de suport cu „Pachet pe drum”. Căutarea vectorială găsește un ghid care descrie procesul ca modificare după expediere. RRF aduce în față documente care combină ambele aspecte. Un reranker poate apoi verifica dacă pasajul relevant conține într-adevăr combinația dintre tarif și expediere.

Înainte de a răspunde, filtrați după piața vizată, linia de produse și statutul curent de valabilitate. Dacă sursele sunt contradictorii sau lipsesc detalii necesare, chatbotul nu ar trebui să tragă concluzii din cazuri similare. El poate spune transparent ce condiție este neclară și poate direcționa vizitatorul către o opțiune de contact potrivită și verificată. Astfel, conversația rămâne utilă, fără a inventa o promisiune acoperită de fapte.

Cazuri fără rezultate și debugging pe scoruri

Un rezultat lipsă (no-result) este adesea un semnal pentru o lipsă de cunoștințe, nu pentru o căutare defectă. De aceea, diferențiați cel puțin patru cazuri: nu există nicio sursă permisă, există surse dar niciun rezultat suficient de potrivit, întrebarea este ambiguă sau o eroare tehnică împiedică preluarea. Fiecare caz are nevoie de o reacție proprie și clară. „Nu găsesc un răspuns siguranță în informațiile aprobate pentru această temă” este mai onest decât o propoziție generică fără un pas următor.

Pentru debugging, scorurile finale nu sunt suficiente. Pentru fiecare întrebare de test, echipele ar trebui să poată vedea ce filtre au acționat, ce documente au provenit din căutarea după cuvinte cheie și cea vectorială, cum au fost fuzionate și dacă reranking-ul a schimbat ordinea. Salvați doar datele necesare pentru calitate, prelucrate cu economie de date. Căutați tipare: lipsesc anumite sinonime? O sursă veche acoperă conținutul nou? O anumită limbă/regiune iese din logica metadatelor? Doar cauza concretă decide dacă trebuie modificat chunking-ul, metadatele, administrarea surselor sau clasarea.

Set de testare, metrici și buget de costuri

Un set de bază (Golden Set) restrâns, de 30 până la 50 de întrebări realiste, este un început bun. Setați pentru fiecare întrebare sursele așteptate, sursele nepermise și reacția dorită în cazul lipsei de cunoștințe. Măsurați separat dacă o sursă corectă se află printre candidați, dacă este poziționată suficient de sus și dacă răspunsul final folosește doar informații dovedite. Adăugați intenționat greșeli de tipar, termeni exacți, formulări naturale, cazuri multilingve și cazuri negative critice.

Schimbați o singură variabilă la fiecare rulare de test: un filtru, numărul de candidați, adâncimea de reranking sau structura fragmentelor (chunks). De asemenea, notați timpul de răspuns și numărul de apeluri către modele externe. Un scor de relevanță mai mare poate fi inutilizabil dacă răspunsul vine prea târziu sau dacă costurile pentru întrebările standard frecvente cresc. Definiți de aceea un buget de latență și de costuri pentru fiecare categorie de întrebări. Răspunsurile standard rapide și bine documentate, alături de transferurile conservatoare, sunt mai valoroase pentru multe site-uri decât o clasare de o complexitate maximă.

Erori tipice la implementare

• Compararea directă a scorurilor brute de cuvinte cheie și vectoriale, deși scările lor nu sunt egale.
• Indexarea ciornelor, a listelor vechi de prețuri sau a conținuturilor protejate fără filtre de status și permisiuni.
• Aplicarea reranking-ului pe prea mulți candidați, pierzând astfel controlul asupra latenței și costurilor.
• Considerarea unui demo cu puține întrebări bune drept o dovadă suficientă de calitate.
• Generarea unui răspuns plauzibil în lipsa unei surse, în loc de a prevedea o nesiguranță, o întrebare de clarificare sau un transfer.
• Lipsa versiunilor pentru modificările aduse surselor, chunking-ului și clasării, ceea ce face imposibilă explicarea lor ulterioară.

Listă de verificare pentru implementare

• Stabilirea surselor permise și a limitelor de autorizare înainte de indexare.
• Menținerea metadatelor pentru limbă, produs, versiune, piață și valabilitate.
• Preluarea paralelă a textului integral și a căutării vectoriale, urmată de fuzionarea prin RRF.
• Utilizarea reranking-ului doar pentru un set mic și permis de candidați.
• Evaluarea linkurilor către surse, a răspunsurilor fără rezultat și a transferului către operatori umani în setul de testare.
• Măsurarea latenței, a costurilor și a răspunsurilor eronate critice la fiecare modificare.

Concluzie

Căutarea hibridă este un punct de plecare robust pentru chatboturile web confruntate cu diverse moduri de formulare a întrebărilor. Căutarea după cuvinte cheie păstrează semnalele exacte, căutarea vectorială identifică solicitările similare, RRF le fuzionează clasamentele, iar un reranker limitat poate îmbunătăți selecția restrânsă. Însă câștigul durabil de calitate provine din surse bine întreținute, metdate potrivite, teste transparente și o logică de răspuns care își asumă deschis limitele. Astfel, preluarea informațiilor devine verificabilă, nu doar impresionantă din punct de vedere tehnic.

Surse și indicații suplimentare

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Relevanță și RRF în Hybrid Search
• Microsoft Learn: Semantic Ranking
• Amazon Bedrock: Reranking
• ChatReact: RAG-Chunking pentru chatboturi AI
• ChatReact: Măsurarea calității răspunsurilor cu Golden Set
• ChatReact: Menținerea la zi a bazei de cunoștințe