Când o firmă primește sute sau mii de tichete pe lună, problema nu mai este doar volumul. Provocarea reală este să înțelegi rapid de ce apar acele solicitări: eroare de facturare, instrucțiuni neclare în aplicație, pași de onboarding confuzi, bug într-o versiune nouă sau întrebări repetitive despre aceeași funcție. Aici poate ajuta AI-ul, dar nu în forma spectaculoasă din reclame. O abordare mai realistă și mai utilă este folosirea embeddings-urilor și a clusteringului semantic pentru a grupa tichetele după sens, nu doar după cuvinte identice.
Pe scurt, embeddings înseamnă transformarea textului în vectori numerici care păstrează relațiile de sens. Documentația OpenAI descrie embeddings ca o metodă de a transforma textul în numere pentru cazuri de utilizare precum căutare și clustering. Asta contează în suport clienți fiindcă două tichete pot descrie aceeași problemă în moduri diferite: „nu merge plata cu cardul”, „tranzacția e respinsă” sau „checkout-ul se blochează la confirmare”. Un sistem bazat doar pe cuvinte-cheie poate rata legătura dintre ele. Un sistem semantic are șanse mai bune să le vadă ca fiind apropiate.
Primul pas sănătos nu este modelul, ci pregătirea datelor. Înainte să generezi embeddings, tichetele trebuie curățate minim: eliminarea duplicatelor evidente, separarea mesajelor automate, normalizarea câmpurilor utile și mascarea datelor personale care nu sunt necesare pentru analiză. Dacă în ticket apar nume, adrese, telefoane sau alte informații sensibile, e mai sigur să le reduci sau să le anonimizezi înainte de procesare. Pentru firmele din România, acest pas ține și de bună practică în protecția datelor, nu doar de calitatea rezultatelor.
Al doilea pas este alegerea unității de analiză. În multe cazuri, nu vrei să trimiți tot firul conversației ca un singur bloc. Mai util poate fi să extragi rezumatul inițial al problemei, categoria deja selectată de agent, produsul afectat, versiunea aplicației și eventual primul răspuns relevant. Scopul nu este să obții text mai lung, ci text mai clar. Dacă intrarea este zgomotoasă, și cluster-ele vor fi zgomotoase.
După ce ai vectorii, urmează partea care face diferența: clusteringul. Documentația scikit-learn explică faptul că algoritmii de clustering grupează date neetichetate, iar alegerea algoritmului schimbă mult rezultatul. Dacă știi dinainte câte familii de probleme vrei să urmărești, poți porni cu K-Means. Dacă nu știi numărul de grupuri, metodele aglomerative pot fi mai potrivite. Documentația Sentence Transformers notează explicit că Agglomerative Clustering este util când numărul de clustere este necunoscut și că pragul ales controlează dacă obții grupuri mai fine sau mai grosiere.
Pentru volume mari, lucrurile trebuie gândite pragmatic. Aceeași documentație Sentence Transformers avertizează că clusteringul aglomerativ devine lent pe seturi mari și propune variante rapide pentru seturi extinse, bazate pe comunități de propoziții foarte similare. Cu alte cuvinte, pentru câteva mii de tichete poți testa mai multe metode, dar pentru zeci de mii trebuie să urmărești și costul de calcul, nu doar calitatea grupării.
Important este și ce înseamnă „cauza reală”. Un cluster nu este automat root cause. El arată că mai multe tichete par să vorbească despre aceeași situație. De aici începe verificarea umană. O echipă bună de suport sau produs va lua fiecare cluster important și îl va valida: este o problemă de UX, o eroare tehnică, o confuzie în documentație, un incident temporar sau doar mai multe întrebări asemănătoare? Fără această etapă, riști să confunzi simptomele cu explicația reală.
În practică, o implementare utilă pentru firme arată așa: colectezi tichetele dintr-o perioadă clară, elimini datele inutile, generezi embeddings, aplici clustering, apoi pui etichete umane pe grupurile rezultate. La final, dashboard-ul nu trebuie să afișeze doar „topicuri”, ci lucruri acționabile: cele mai mari 10 cauze probabile, impactul lor în volum, produsele afectate și exemple reprezentative. Așa poți decide dacă rezolvi un bug, rescrii un email de onboarding, actualizezi baza de cunoștințe sau schimbi fluxul din aplicație.
Merită spus și ce nu face această metodă. Nu înlocuiește complet echipa de suport, nu garantează adevărul absolut și nu repară date prost colectate. Dacă etichetele interne sunt inconsistente, dacă tichetele sunt prea scurte sau dacă limba folosită diferă mult între canale, rezultatele vor avea limite. De aceea, firmele ar trebui să trateze clusteringul semantic ca instrument de triere și descoperire de patternuri, nu ca verdict final.
Pentru companiile care vor să înceapă fără proiecte complicate, pilotul ideal este mic: un singur produs, o singură lună de tichete și o verificare manuală a clusterelor cele mai mari. Dacă rezultatele ajută echipa să vadă mai repede problemele recurente, atunci AI-ul și-a făcut treaba corect: nu a promis magie, ci a redus timpul dintre plângerea clientului și înțelegerea cauzei reale.
