RAG pentru customer support: cum reduci timpul de răspuns

Echipa de customer support primește aceleași 50 de întrebări în fiecare săptămână. Răspunsurile există deja — în help center, în tichete vechi, în documentația de produs. Problema nu e că lipsește informația. E că un agent o caută manual, în cinci locuri diferite, de fiecare dată.

RAG (Retrieval-Augmented Generation) schimbă fix asta. În loc să generezi un răspuns din ce „știe” un model în general, conectezi modelul la baza ta de cunoștințe și îl pui să răspundă pe surse reale, cu citare. Clientul primește un răspuns corect, în secunde, fără să aștepte un agent liber.

Articolul arată unde pui RAG într-un flux de support, ce alegi pentru fiecare strat și ce capcane te costă bani dacă le ignori. Dacă pleci de la zero cu conceptul, citește întâi ce este RAG și cum funcționează.

Ce rezolvă RAG într-un flux de support

Patru lucruri concrete, măsurabile:

• Deflection. O parte din tichete se rezolvă singure, fără agent. Întrebările repetitive („cum resetez parola”, „care e politica de retur”) primesc răspuns instant. Tipic, 20–40% din volum e deflectabil dacă baza de cunoștințe e bună.
• First response time mai mic. Chiar și când tichetul ajunge la un om, agentul primește răspunsul propus și sursele lângă el. Nu mai caută; verifică și trimite.
• Consistență. Zece agenți dau același răspuns la aceeași întrebare. Nu mai depinde de cine prinde tichetul sau cât de nou e în echipă.
• Scalare fără headcount liniar. Volumul crește de Black Friday, echipa nu. RAG absoarbe vârful pe întrebările cunoscute.

Diferența față de un chatbot „cu reguli” clasic: ăla răspunde doar la ce ai scris explicit în arbore. RAG răspunde la formulări pe care nu le-ai anticipat, pentru că înțelege semantic întrebarea și caută în tot ce ai indexat.

Cele două locuri unde pui RAG-ul

Asta e decizia care contează cel mai mult, și mulți o sar. RAG într-un support are două forme, cu profil de risc complet diferit.

1. Copilot pentru agent (agent-assist). Sistemul propune răspunsul, agentul îl verifică și îl trimite. Omul rămâne în buclă. Riscul de răspuns greșit e mic — există un filtru uman înainte să ajungă la client. Adoptarea e rapidă, pentru că nu sperii pe nimeni.

2. Chatbot pentru client (customer-facing). Sistemul răspunde direct clientului, fără om la mijloc. Aici câștigi deflection real, dar și riscul e maxim: o halucinație ajunge direct la client. Un răspuns greșit despre politica de retur sau despre un pas tehnic te costă încredere, uneori bani.

Recomandarea pragmatică: pornește cu agent-assist. Strângi date despre ce întreabă lumea și cât de bune sunt răspunsurile, cu un om care prinde greșelile. După ce evaluarea arată acuratețe constantă, deschizi treptat partea customer-facing — întâi pe categoriile sigure (FAQ, status comandă), nu pe tot.

Vezi și alte cazuri enterprise de RAG dincolo de support — helpdesk intern, analiză de contracte, enablement de vânzări.

Cum arată sistemul, pas cu pas

Fluxul e același indiferent de stack:

1. Ingestion. Aduni sursele: articole din help center, tichete rezolvate, documentația de produs, politici interne.
2. Chunking. Tai documentele în bucăți de dimensiune potrivită — destul de mici cât să fie relevante, destul de mari cât să păstreze context.
3. Embeddings. Transformi fiecare bucată într-un vector. Aici contează un model multilingv, dacă baza ta e în română.
4. Stocare. Pui vectorii într-o bază vectorială, indexată pentru căutare rapidă.
5. Retrieval. La fiecare întrebare, cauți semantic bucățile cele mai apropiate și le dai modelului ca context.
6. Generare cu citare. Modelul răspunde doar pe baza contextului primit și indică sursa.
7. Escaladare. Când nu găsește răspuns sau încrederea e mică, predă tichetul unui om. Fără pasul ăsta, sistemul inventează.

Pasul 6 e cel care separă un sistem serios de o jucărie. Instrucțiunea către model nu e „răspunde”, ci „răspunde din context, iar dacă nu e acolo, spune că nu știi”:

1Răspunde la întrebarea clientului folosind DOAR informația din secțiunea CONTEXT.
2Dacă răspunsul nu se găsește în context, spune că nu ai informația și
3recomandă escaladarea către un agent. Nu inventa politici, prețuri sau pași.
4Citează articolul-sursă la final.

1Răspunde la întrebarea clientului folosind DOAR informația din secțiunea CONTEXT.
2Dacă răspunsul nu se găsește în context, spune că nu ai informația și
3recomandă escaladarea către un agent. Nu inventa politici, prețuri sau pași.
4Citează articolul-sursă la final.

Dacă vrei un exemplu concret de implementare cap la cap, cu cod, vezi cum construiești un sistem RAG cu Next.js.

De unde vin datele

Calitatea răspunsurilor e plafonată de calitatea surselor. „Garbage in, garbage out” e aici literal.

• Help center / KB. Sursa cea mai curată, deja scrisă pentru clienți.
• Tichete rezolvate. Aur, dar murdar. Conțin formulări reale și soluții care nu sunt nicăieri altundeva — dar și date personale (nume, emailuri, comenzi). Trebuie curățate de PII înainte de indexare.
• Documentația de produs. Pentru întrebări tehnice.
• Wiki intern (Notion, Confluence). Politici, proceduri, excepții.

Două reguli de aur. Una: prospețime. O bază de cunoștințe veche e mai periculoasă decât niciuna — dă răspunsuri vechi cu încredere. Stabilește un mecanism de refresh când conținutul-sursă se schimbă. Doi: nu indexa ce nu vrei să citeze. Dacă un document e confidențial sau depășit, scoate-l din index — nu te baza pe model să-l evite.

Ce alegi pentru fiecare strat

Nu există un stack „corect”. Alegi pe baza a ce ai deja, a constrângerilor de date și a echipei. Iată opțiunile reale, fără agendă.

Baza vectorială

• pgvector — dacă rulezi deja pe Postgres, ții vectorii lângă restul datelor, fără un serviciu nou. Cel mai simplu de operat când ești deja pe Postgres.
• Pinecone — managed, scalează fără bătaie de cap pe infra. Plătești pentru confort.
• Qdrant — open-source, self-host sau cloud, filtrare bună pe metadate.
• Weaviate — hybrid search (semantic + keyword) integrat, util când întrebările au și termeni exacți (coduri de eroare, SKU-uri).

Pentru volume mici-medii de support, oricare merge. Decizia reală e managed vs self-host, nu numele de pe cutie.

Modelul de limbaj

• Modele closed (OpenAI, Anthropic, Google) — cea mai bună calitate la răspuns și la română, integrare rapidă. Compromisul: datele pleacă către furnizor.
• Modele open self-hosted (Llama, Mistral) — le rulezi pe infrastructura ta, datele nu ies. Mai mult efort operațional, dar control total.

Pentru o companie din România sau UE, rezidența datelor și GDPR cântăresc des mai mult decât ultimul procent de calitate. Dacă tichetele conțin date sensibile, un model self-hosted sau un furnizor cu procesare în UE poate fi cerința, nu opțiunea.

Orchestrare Framework-uri ca LangChain sau LlamaIndex grăbesc startul, dar pentru un flux de support relativ simplu, cod propriu e adesea mai ușor de întreținut decât o abstracție în plus. Alege framework dacă îți accelerează echipa, nu pentru că „așa se face”.

Capcanele care te costă

• Halucinația ajunsă la client. Cel mai scump bug. Mitigare: grounding strict, fallback „nu știu”, citare obligatorie, escaladare.
• Bază de cunoștințe veche. Răspunsuri corecte acum șase luni, greșite azi. Refresh sau nimic.
• Lipsa unei căi de escaladare. Dacă sistemul nu poate spune „te predau unui om”, va inventa. Escaladarea nu e opțională.
• Zero evaluare. Dacă nu măsori acuratețea pe întrebări reale, nu știi dacă sistemul ajută sau strică.
• Româna tratată ca engleza. Embeddings și model care nu prind bine româna dau retrieval slab și răspunsuri stângace. Testează pe conținut real în română.
• „Set and forget”. Un support live se degradează dacă nu-l urmărești. E un produs, nu un proiect închis.

Cum măsori dacă funcționează

Înainte să-l lași pe clienți, fă-ți un set de evaluare: 50–100 de întrebări reale cu răspunsul corect cunoscut. Rulezi sistemul pe ele și măsori. Apoi, în producție, urmărești:

• Deflection rate — ce procent din tichete se rezolvă fără agent.
• First response time — cât de repede primește clientul primul răspuns util.
• Acuratețe / rata de halucinație — pe setul de evaluare, câte răspunsuri sunt corecte și pe surse.
• Escalation rate — cât de des predă către om. Prea mare = inutil; prea mic poate ascunde halucinații.
• CSAT — clienții sunt mulțumiți de răspunsurile automate?

Fără măsurare, restul sunt presupuneri. Setul de evaluare e primul lucru de construit, nu ultimul.

Întrebări frecvente

RAG înlocuiește agenții de support?

Nu. Preia întrebările repetitive și pregătește răspunsuri pentru cele complexe. Agenții se ocupă de cazurile care chiar cer judecată umană. Scopul e să muți efortul, nu să tai oameni.

Cât durează să pui în producție un RAG de support?

Un pilot de agent-assist pe o bază de cunoștințe existentă se poate ridica în câteva săptămâni. Partea customer-facing, cu evaluare serioasă și escaladare, cere mai mult — pentru că aici greșelile sunt vizibile.

Ce fac dacă răspunsul nu e în baza de cunoștințe?

Sistemul trebuie să spună „nu am informația” și să escaladeze, nu să inventeze. Lipsa de răspuns e un semnal util: arată ce articole îți lipsesc din KB.

Funcționează RAG pe conținut în română?

Da, dar alegerea modelelor contează. Folosește embeddings și un model de generare care performează bine pe română și testează pe tichete reale, nu pe exemple în engleză.

Cât costă un sistem RAG de support?

Depinde de volum, de modelul ales și de unde rulezi. Costul principal vine din apelurile la model și din stocarea vectorilor — îl detaliem separat, pe componente.

Pornești un RAG pentru supportul tău?

Un sistem de support pe RAG nu e un chatbot pe care îl pornești și uiți de el. E o arhitectură: surse curate, retrieval bun, grounding strict, escaladare și evaluare continuă. Pusă cap la cap corect, scade timpul de răspuns și ține clienții mulțumiți fără să umfli echipa.

Dacă vrei să construiești unul pentru produsul tău — de la primul pilot agent-assist până la deflection real în producție — discută cu o echipă care a făcut asta. Sau explorează toate articolele despre AI și RAG.