RAG peste feedbackul clienților: ce poate sintetiza

Head of product-ul întreabă sistemul de feedback: „de ce pleacă clienții din segmentul mic?” Răspunsul vine în opt secunde, cu trei teme, formulare curată și cinci citate din tichete reale, fiecare cu link către sursă. Nimic inventat. Fiecare propoziție se verifică în documentul citat.

Și, cu toate astea, răspunsul e greșit. Nu pentru că sistemul ar fi halucinat, ci pentru că cele opt fragmente pe care le-a citit nu sunt clienții care pleacă. Sunt clienții care scriu. Iar cei doi termeni nu se suprapun aproape deloc.

Ăsta e primul caz din cluster în care întrebarea nu mai e un lookup. La support, la helpdesk intern sau la enablement de vânzări, răspunsul corect există undeva, într-un document, și problema e să-l găsești. Aici răspunsul corect nu există în niciun document. Trebuie calculat peste toate.

Ce se schimbă când corpusul e o populație, nu o bibliotecă

Mecanismul RAG rămâne același: tai, indexezi, cauți, generezi. Ce se schimbă e natura corpusului și, odată cu ea, natura întrebării.

Documente mici, multe și redundante

Un corpus de feedback e făcut din tichete de suport, recenzii publice, transcrieri de apeluri, răspunsuri libere la sondaje, mesaje de anulare, comentarii din in-app surveys. Fiecare are între douăzeci și trei sute de cuvinte. Sunt zeci sau sute de mii.

Redundanța e proprietatea lor definitorie, nu un defect. Aceeași nemulțumire apare de patru sute de ori, formulată de patru sute de ori diferit. Într-o bază de cunoștințe obișnuită, duplicatele sunt gunoi de curățat. Aici, numărul de repetări este informația. Dacă deduplici, ai șters exact ce voiai să afli.

Consecința asupra pregătirii documentelor: chunking-ul devine aproape irelevant, fiindcă documentul e deja mai mic decât un chunk tipic. În schimb, contează enorm ce metadate atașezi fiecărei bucăți — și revin la asta mai jos, fiindcă e piesa pe care majoritatea implementărilor o sar.

Întrebarea nu are un răspuns localizat

„Care e politica de retur?” are un răspuns care stă scris undeva. „Ce reclamă clienții despre onboarding?” nu are. Răspunsul corect e o proprietate a distribuției, nu a unui document.

Distincția asta schimbă ce înseamnă un retrieval bun. Când cauți politica de retur, succesul înseamnă să aduci documentul potrivit. Când întrebi ce reclamă oamenii, succesul ar însemna să aduci un eșantion reprezentativ — iar căutarea prin similaritate nu are noțiunea de eșantion. Nici nu încearcă.

Cum se raportează la celelalte cazuri din cluster

Ultima linie e cea care contează. La support, un răspuns greșit primește imediat un „nu, nu asta am întrebat”. O sinteză greșită despre ce vor clienții intră într-un roadmap și rămâne acolo un an. Restul cazurilor sunt în cazurile de utilizare enterprise din cluster.

De ce top-k e structural greșit pentru sinteză

Asta nu e o problemă de tuning. Nu se rezolvă cu k mai mare, cu embeddings mai bune sau cu reranking.

Relevanța nu e reprezentativitate

Retrievalul optimizează un singur lucru: similaritatea dintre întrebare și fragment. Când întrebi „de ce pleacă clienții”, cele mai similare opt fragmente sunt cele în care cineva a scris literal despre plecare — mesajele de anulare cu motiv explicit, tichetele în care apare cuvântul „reziliere”.

Clientul care a plecat fiindcă integrarea a durat trei luni și n-a mai scris nimic după săptămâna a doua nu e în top-8. Nu fiindcă retrievalul l-a ratat, ci fiindcă documentele lui nu seamănă cu întrebarea. Sistemul îți dă cea mai bună potrivire lexicală și semantică, iar tu citești rezultatul ca pe un eșantion. Nu e.

A doua problemă e redundanța. Dacă aceeași plângere apare de patru sute de ori, cele opt fragmente cele mai apropiate sunt, cu mare probabilitate, opt variante ale aceleiași plângeri. Diversificarea rezultatelor ajută parțial: îți dă opt lucruri diferite, dar tot nu-ți dă proporțiile dintre ele. Un răspuns care listează opt teme distincte fără să spună cât cântărește fiecare e o listă, nu o măsurătoare.

Ce arată cercetarea pe sinteză peste un corpus

Sarcina asta are un nume și un benchmark. SummHay (Summary of a Haystack), publicat de Laban și colegii la EMNLP 2024, construiește colecții sintetice de documente în care anumite idei se repetă intenționat, apoi cere sistemului să producă un rezumat care acoperă ideile relevante și citează corect sursele.

Rezultatele sunt instructive. Acoperirea ideilor variază de la 36,2% (retriever aleatoriu) până la 81,4% (retriever oracle, care știe dinainte ce documente sunt relevante). Chiar și cu semnalul oracle — un scenariu imposibil în producție — sistemele rămân la peste zece puncte sub performanța umană estimată de autori, situată la 56% pe scorul combinat. Fără retriever deloc, modelele long-context testate atunci coborau sub 20%.

Două precizări oneste, fiindcă cifrele astea circulă prost. Corpusurile sunt sintetice, construite ca să aibă un răspuns verificabil. Iar modelele evaluate sunt din 2024, deci numerele absolute sunt vechi — modelele de azi le depășesc. Ce nu s-a schimbat e forma problemei: acoperirea ideilor care se repetă într-o colecție e o sarcină distinctă de regăsire, iar calitatea retrievalului o influențează în ambele sensuri. Un retriever mai bun crește calitatea citării, dar restrânge ce vede modelul.

Ce faci în loc

Inversezi ordinea. În loc să cauți și apoi să sintetizezi, clasifici întâi tot corpusul, agregi etichetele și abia apoi folosești retrievalul ca să aduci exemple pentru concluzia deja calculată.

Diferența e că pasul de clasificare atinge fiecare document, nu opt. Costul e o rulare batch, previzibilă și amortizabilă, nu un apel per întrebare. Detaliile arhitecturii vin mai jos.

Capcana centrală: întrebările cantitative

Aici se pierd cele mai multe proiecte, și se pierd tăcut.

RAG nu numără

Nu e o slăbiciune de model, e o proprietate a arhitecturii. Retrievalul aduce câteva documente, iar modelul trebuie să facă orice calcul mental peste ele, într-o singură trecere.

Cifrele pe care merită să le ai în cap vin din benchmarkul TAG, publicat de Biswal și colegii la CIDR 2025 (UC Berkeley și Stanford). Autorii au luat 80 de întrebări peste baze de date reale și au evaluat mai multe abordări. Baseline-ul RAG — top-10 rânduri regăsite prin similaritate, plus un singur apel la model — a răspuns corect la zero întrebări. Adăugarea unui reranker l-a dus la 2%. Text2SQL simplu a ajuns la 17%. Un pipeline scris de om, care lasă baza de date să facă socoteala și modelul să facă raționamentul semantic, a ajuns la 55%.

Precizarea de rigoare: benchmarkul rulează peste tabele relaționale, nu peste un corpus de feedback, iar modelul folosit e din 2024. Nu poți transfera procentul. Poți transfera diagnosticul, pe care autorii îl formulează explicit: modelul RAG lasă sarcinile de calcul — numărare, filtrare, aritmetică — pe seama unei singure invocări a unui model care e prost la ele.

Un răspuns care sună cantitativ e mai periculos decât un refuz

Întreabă „câți clienți au reclamat lentoarea la export?” și un sistem naiv are trei ieșiri posibile. Poate număra fragmentele din context și răspunde „opt” — fals, e mărimea ferestrei de retrieval. Poate spune „mulți clienți” — inutil, dar inofensiv. Sau poate spune „aproximativ 15%” — și asta e varianta care ajunge în slide.

Ultima e periculoasă fiindcă are forma unei măsurători fără să fie una. Nimeni nu întreabă din ce numitor. Regula practică e brutală și merită impusă în prompt și în cod: orice răspuns care conține un număr trebuie să vină dintr-o interogare executată pe date structurate și trebuie să declare numitorul și fereastra de timp. Dacă interogarea nu există, sistemul refuză și spune ce ar fi nevoie ca să răspundă.

Refuzul explicit nu e o degradare a produsului. E singura formă în care un sistem de sinteză rămâne folosibil pentru decizii — principiul general e în cum arată un răspuns bun de RAG, iar aici se aplică în forma lui cea mai strictă.

Unde se termină retrievalul și începe agregarea

Granița e trasabilă cu o singură întrebare: răspunsul se schimbă dacă adaugi încă o mie de documente pe care sistemul nu le-a citit?

Dacă nu se schimbă — „ce a scris clientul X despre integrare?”, „dă-mi trei exemple de plângeri pe subiectul Y” — e teritoriu de retrieval. Dacă se schimbă — „câți”, „ce procent”, „a crescut sau a scăzut”, „care e cea mai frecventă” — e teritoriu de agregare, iar retrievalul nu poate răspunde onest.

Când majoritatea întrebărilor reale cad în partea dreaptă, ai un semnal clar că problema ta nu e de retrieval. Pragurile la care merită să te oprești înainte să construiești sunt în când nu folosești RAG.

Reprezentativitate: cine scrie feedback nu e cine folosește produsul

Presupunând că ai rezolvat agregarea, mai rămâne problema care nu se rezolvă cu inginerie: corpusul însuși e un eșantion părtinitor, iar sistemul nu are cum să știe asta.

Ce știm despre cine scrie

Literatura pe recenzii online e mai clară aici decât orice raport de industrie. Hu, Pavlou și Zhang documentează în MIS Quarterly (2017) două mecanisme separate de auto-selecție. Acquisition bias: cei care cumpără produsul sunt deja predispuși favorabil, deci populația care poate scrie e filtrată înainte de prima recenzie. Underreporting bias: cei cu opinii extreme, pozitive sau negative, scriu mult mai probabil decât cei cu opinii moderate.

Cele două produc împreună distribuția în formă de J, cunoscută oricui s-a uitat vreodată la histogramele de rating: mult 5, ceva 1, aproape nimic la mijloc. Concluzia autorilor e directă — media ratingurilor e un estimator părtinitor al calității reale a produsului.

În B2B se adaugă un filtru propriu. Cine scrie în portalul de suport e, de obicei, administratorul contului — persoana care are credențiale, nu persoana care folosește produsul opt ore pe zi. Feedbackul pe care îl citești e vocea unui rol, nu a bazei de utilizatori.

O rată de răspuns mare nu înseamnă un eșantion bun

Tentația e să compensezi cu volum: mai multe sondaje, mai multe remindere, mai multe canale. Cercetarea pe metodologia sondajelor arată de ce nu funcționează.

Holtom, Baruch, Aguinis și Ballinger analizează în Human Relations (2022) 1.014 sondaje din 703 articole publicate în 17 reviste între 2010 și 2020, și propun distincția dintre o rată de răspuns funcțională și una disfuncțională. Exemplul lor merită reținut ca atare: o populație împărțită 80/20 pe o caracteristică, cu o rată de răspuns de 90% în grupul majoritar și 10% în cel minoritar, dă o rată globală de 74% — un număr care ar trece drept excelent la orice benchmark. Iar rezultatul reprezintă foarte prost opiniile minorității.

Transferul în feedback e imediat. Zece mii de tichete nu îți garantează nimic despre reprezentativitate dacă nouă mii vin din același segment. Volumul e o proprietate a corpusului; reprezentativitatea e o proprietate a raportului dintre corpus și populație, iar al doilea termen nu e în index.

Metadate de segment, obligatorii

Singura reparație care funcționează e la ingestie. Fiecare document intră în index cu dimensiunile după care vei vrea să tai sinteza mai târziu: plan sau tier, mărimea contului, vechimea relației, industrie, rolul persoanei, canalul prin care a venit, limba, data.

Fără ele, orice sinteză e necalificată și deci neutilizabilă pentru o decizie. Cu ele, poți cel puțin să compari distribuția corpusului cu distribuția bazei de clienți și să spui unde ești supra- sau subreprezentat. Aceeași disciplină de marcare la ingestie apare peste tot în cluster; aici nu e o optimizare, e condiția de validitate.

Avertismentul intră în răspuns, nu în documentație

Un sistem serios își descrie eșantionul în corpul răspunsului, nu într-o notă de subsol pe care n-o citește nimeni. Forma minimă: „pe 312 tichete de la 74 de conturi, ultimele 90 de zile, 81% din planul Pro — conturile Enterprise sunt subreprezentate față de ponderea lor în venituri.” E o propoziție în plus și schimbă complet felul în care e citit restul răspunsului.

Arhitectura hibridă: clasificare offline, agregare în SQL, RAG pentru citate

Pipeline-ul care funcționează are trei straturi, cu responsabilități care nu se amestecă.

Stratul 1: clasificare exhaustivă, offline

Rulezi un model peste fiecare document și îi atașezi etichete dintr-o taxonomie definită de tine: subiect, sub-subiect, sentiment, severitate, dacă e cerere de funcționalitate sau defect. Rezultatul se scrie într-un tabel, alături de metadatele de segment.

Trei detalii care fac diferența. Taxonomia nu se inventează dintr-o singură ședință — pornește de la o rulare exploratorie pe câteva mii de documente, apoi o fixezi și o versionezi, fiindcă o sinteză peste două versiuni de taxonomie nu e comparabilă în timp. Curățarea de date personale se face înainte de clasificare, nu după, iar regimul e cel din RAG și GDPR: feedbackul liber e cel mai murdar corpus pe care îl vei indexa vreodată, fiindcă oamenii lipesc în el nume, adrese, numere de comandă și, ocazional, lucruri pe care nu ai voie să le stochezi. Și, în fine, un eșantion etichetat manual — două-trei sute de documente — rămâne singura cale prin care afli cât de bun e clasificatorul.

Stratul 2: agregarea, pe date structurate

Odată ce ai etichete, întrebările cantitative devin banale. „Câte conturi au reclamat lentoarea la export în ultimul trimestru, pe segmente” e o interogare SQL, nu o sarcină de limbaj natural.

1SELECT segment, COUNT(DISTINCT account_id) AS conturi, COUNT(*) AS documente
2FROM feedback_labels
3WHERE topic = 'export_performance'
4  AND created_at >= now() - interval '90 days'
5GROUP BY segment
6ORDER BY conturi DESC;

1SELECT segment, COUNT(DISTINCT account_id) AS conturi, COUNT(*) AS documente
2FROM feedback_labels
3WHERE topic = 'export_performance'
4  AND created_at >= now() - interval '90 days'
5GROUP BY segment
6ORDER BY conturi DESC;

Numitorul e vizibil, fereastra e explicită, iar rezultatul e reproductibil. Rulează de două ori și obții același număr — proprietate pe care o sinteză generată nu o are.

Stratul 3: RAG, pentru citate ilustrative

Abia acum intră retrievalul, și intră cu un rol strict: pentru fiecare temă deja cuantificată, adu două-trei citate reprezentative, filtrate pe eticheta respectivă și pe segmentul respectiv.

Rolul lui e ilustrativ, nu probatoriu. Citatul explică cum sună problema în cuvintele clientului; numărul de lângă el spune cât de mare e. Dacă inversezi rolurile — dacă citatul devine dovada mărimii — ai construit exact sistemul de la începutul articolului.

Fereastra temporală și prospețimea

O sinteză fără interval de timp nu spune nimic. Un subiect care a explodat acum opt luni și s-a rezolvat între timp apare la fel de proeminent ca unul care crește acum, dacă indexezi tot fără să tai.

Regula minimă: fiecare răspuns declară fereastra, iar comparația între ferestre e o funcție de primă clasă a sistemului, nu ceva ce faci punând două întrebări separate și comparând din ochi.

Riscul specific: decizia luată pe o sinteză nereprezentativă

Fiecare caz din cluster are un risc dominant. Aici nu e halucinația și nu e scurgerea de date. E o decizie de produs corectă ca formă și greșită ca fond.

De ce nu o prinde nimeni

La support, feedbackul e imediat: clientul răspunde că nu asta a întrebat. La onboarding, eroarea se prinde mai târziu, când cineva cu vechime aude o afirmație greșită și o corectează.

Aici nu există nici măcar mecanismul ăsta. Nu ai cu ce compara sinteza, fiindcă dacă ai fi avut, n-ai fi construit sistemul. Un răspuns coerent, citat corect și prezentat cu încredere trece direct în planificare. Costul se materializează peste două trimestre, sub forma unei funcționalități construite pentru o subpopulație vocală, și nimeni nu leagă cauza de efect.

Trei bariere, în ordinea eficacității

Numitorul și fereastra, obligatorii în orice răspuns cu cifre. E cea mai ieftină și cea mai eficace. Un număr fără numitor nu iese din sistem — se validează în cod, nu se speră de la model.

Sinteza doar peste corpus etichetat integral. Dacă stratul de clasificare n-a atins toate documentele din fereastră, sistemul spune ce acoperire are. „Etichetat 94% din documentele din interval” e o propoziție care schimbă încrederea corect.

Traseul înapoi spre populație. Fiecare afirmație agregată are un link către lista completă de documente care au produs-o, nu doar către cele trei citate afișate. Fără el, sinteza nu e auditabilă, iar ce nu se poate audita nu se poate contesta.

Granița față de un tool clasic de analiză de feedback

Există de mult produse dedicate care fac clasificare și dashboards peste feedback. Nu au dispărut și nu ar trebui să dispară.

Împărțeala onestă: un tool clasic e mai bun pe ce e recurent și definit — aceleași categorii, aceleași rapoarte, aceleași alerte, cu o interfață pe care o folosește și cineva care nu scrie SQL. Stratul de model își câștigă locul pe întrebările deschise, care n-au un dashboard pregătit dinainte, și pe partea narativă: cum sună problema, în ce context apare, ce leagă două teme aparent diferite.

Dacă întrebările tale sunt aceleași în fiecare lună, construiești un raport, nu un sistem RAG. Dacă întrebările se schimbă la fiecare ședință de roadmap, stratul de model plătește.

Ce măsori și ce cifre din piață nu merită încrederea

Patru indicatori care chiar spun ceva

Acoperirea corpusului. Ce procent din documentele din fereastră au primit etichete. Sub o acoperire mare, nicio agregare nu e validă, oricât de bine sună.

Precizia clasificatorului pe eșantion etichetat manual. Se măsoară pe două-trei sute de documente adnotate de oameni, se reia la fiecare schimbare de taxonomie sau de model. E metrica de sănătate a stratului 1, și e singura pe care nu o poți estima din interior.

Stabilitatea sintezei la reluare. Pune aceeași întrebare de trei ori. Dacă temele sau ponderile se schimbă vizibil, ai un generator de narațiuni, nu o măsurătoare. Un sistem bine construit e plictisitor de consistent aici, fiindcă cifrele vin din SQL.

Timpul până la răspuns pentru o întrebare nouă. Adică una pentru care nu există dashboard. Ăsta e câștigul real față de un tool clasic; dacă nu se vede, sistemul nu-și merită costul.

Setul de evaluare se construiește din întrebări reale puse de product și de CX, cu răspunsul corect stabilit prin numărare manuală pe un subcorpus. E muncă, dar e singura ancoră. Metricile de retrieval și de generare pe care le suprapui peste el sunt în cum evaluezi un sistem RAG.

Ce rezistă la verificare

Puțin, dar suficient ca să nu construiești pe presupuneri.

Pe partea de sinteză peste corpusuri mari, SummHay (Laban et al., EMNLP 2024) rămâne referința utilă: acoperirea ideilor variază între 36,2% și 81,4% în funcție de retriever, iar performanța umană estimată e la 56% pe scorul combinat. Pe partea de agregare, benchmarkul TAG (Biswal et al., CIDR 2025) arată un baseline RAG la 0% exact match pe 80 de întrebări peste baze de date, față de 55% pentru un pipeline care separă calculul de raționament. Pe partea de auto-selecție, Hu, Pavlou și Zhang (MIS Quarterly, 2017) documentează mecanismele care fac media ratingurilor un estimator părtinitor. Pe partea de reprezentativitate, Holtom și colegii (Human Relations, 2022) arată de ce o rată de răspuns mare nu garantează un eșantion bun.

Toate patru au metodologie publicată, an verificabil și numitor declarat. Nicio cifră de mai sus nu descrie direct un corpus de feedback B2B, și e important să nu pretinzi altceva.

Ce am omis intenționat

Două exemple, fiindcă mecanismul se repetă și merită să-l recunoști singur.

„80% din datele unei companii sunt nestructurate.” O găsești atribuită la Gartner, la IDC și, dacă mergi îndeajuns de departe pe lanț, la o notă Merrill Lynch din 1998 care spunea că „unele estimări ajung până la 80%”. Nimeni nu produce studiul, definiția „nestructurat” diferă de la sursă la sursă, iar procentul variază între 70% și 90% în funcție de cine îl citează. Nu e neapărat falsă. E doar nefolosibilă ca argument.

„96% dintre clienții nemulțumiți nu reclamă” și „pentru fiecare reclamație sunt 26 de clienți tăcuți.” Circulă de peste un deceniu, atribuite alternativ unei firme de training, unei firme de consultanță, unui studiu TARP din 1999 și, în unele variante, unor „cercetători de la Harvard”. Nu există un raport pe care să-l deschizi. E ironic într-un mod util: statisticile despre feedbackul clienților sunt ele însele un corpus care se citează pe sine, exact eșecul pe care articolul ăsta încearcă să-l prevină.

Regula de aplicat la orice cifră de CX: caută forma originală, verifică anul și verifică numitorul. Dacă lanțul se rupe după doi pași, nu o folosi.

Ce arăți în primele șase săptămâni

Un pilot onest e restrâns. Un singur canal — tichetele, de obicei — o fereastră de nouăzeci de zile, o taxonomie de cincisprezece până la douăzeci și cinci de subiecte construită din date, metadate de segment complete, clasificare pe tot intervalul și trei-patru întrebări la care product-ul chiar vrea răspuns.

Livrabilul nu e un chatbot. E un tabel de etichete în care ai încredere, plus capacitatea de a răspunde la o întrebare nouă în minute. Stratul conversațional se adaugă după, când numerele de dedesubt sunt deja corecte.

Întrebări frecvente

Pot să pun toate tichetele într-un model cu context lung și să-l întreb direct?

Pentru câteva sute de documente scurte, da, și e o variantă rezonabilă pentru un pilot. Peste asta, două probleme: costul crește liniar cu fiecare întrebare, iar acoperirea ideilor din mijlocul contextului rămâne inegală. Clasificarea offline plătește o dată și răspunde de o mie de ori.

Cât feedback trebuie să am ca să merite?

Contează mai puțin volumul absolut și mai mult numărul de întrebări distincte. Dacă echipa pune aceleași cinci întrebări în fiecare lună, un raport rezolvă problema mai ieftin. Dacă apar întrebări noi la fiecare ciclu de roadmap și răspunsul cere azi două zile de citit manual, sistemul își merită costul.

Cum împiedic sistemul să dea cifre inventate?

Nu prin prompt. Prin arhitectură: cifrele vin exclusiv din interogări pe date structurate, iar stratul de generare primește rezultatul numeric ca dat de intrare, nu îl produce. Un răspuns cu cifre care nu are o interogare în spate se blochează în cod.

Ce fac cu feedbackul în mai multe limbi?

Îl clasifici în limba lui, cu un model care chiar o acoperă, și păstrezi limba ca metadată. Traducerea automată înainte de clasificare pierde nuanța și, mai grav, deplasează sistematic sentimentul. Pentru română, testează pe tichete reale, nu pe exemple traduse din engleză.

E același lucru cu analiza de sentiment?

Nu. Sentimentul e o singură etichetă, de obicei prea grosieră ca să acționezi pe ea. Ce îți trebuie e subiectul, sub-subiectul și severitatea — „nemulțumit” nu îți spune ce să repari. Sentimentul e util doar ca dimensiune secundară, peste o taxonomie de subiecte care există deja.

Un RAG peste feedbackul clienților nu e un chatbot deasupra tichetelor. E o decizie despre unde se termină retrievalul și începe măsurătoarea. Clasificare peste tot corpusul, agregare pe date structurate cu numitor declarat, retrieval doar pentru citate, metadate de segment la ingestie și un refuz explicit când întrebarea cere o cifră pe care sistemul nu o poate calcula.

Dacă vrei să construiești unul — sau doar să afli dacă întrebările tale sunt de retrieval ori de agregare — scrie-ne. Restul cazurilor și al arhitecturilor sunt în secțiunea despre AI și RAG.