Intent recognition: clasificare cu NLP și când îți merită LLM-ul

Intent recognition este procesul prin care un sistem de chatbot identifică intenția din spatele unui mesaj al utilizatorului și o mapează la o acțiune predefinită. Mesajul „vreau să știu unde e comanda mea" devine intenția verifică_stare_comandă, iar sistemul știe ce API să apeleze sau ce răspuns să compună.

Implementările productive merg de la regex simplu până la LLM-uri generative. Decizia între ele este mai mult despre cost, volum și predictibilitate decât despre calitate absolută.

Ce înseamnă intent recognition în context chatbot?

Intent recognition, sau intent classification, transformă textul liber al utilizatorului într-un identificator de intenție ales dintr-un set fix. Setul este definit în avans: „verifică_stoc", „modifică_adresă", „deconectează_cont", „anulează_comandă". Structura unui mesaj procesat arată astfel:

• Input. Textul brut: „bună, aș vrea să anulez ultima comandă".
• Intenție detectată. Identificatorul ales: anulează_comandă, cu un confidence score (ex. 0,91).
• Entități extrase (opțional). Valori specifice: „ultima" → entitate referință_comandă: LAST.
• Acțiune. Ce face sistemul: apelează API-ul, cere confirmare sau escaladează la un operator.

Intent recognition este clasificare de text pe clase finite, nu generare de răspuns. Această distincție determină ce tip de model este potrivit.

Care sunt abordările (rule-based, ML classifier, LLM)?

• Rule-based (regex și keyword matching). Fiecare intenție este definită printr-o listă de cuvinte-cheie sau expresii regulate. Rapid, fără cost de infrastructură, deterministic. Limitarea: nu generalizează la formulări noi pe care regulile nu le acoperă. Funcționează bine pentru bots cu 5–10 intenții simple și utilizatori cu mesaje predictibile.
• ML classifier. Model antrenat pe exemple etichetate. Arhitecturi comune: SVM clasic (seturi mici), BERT fine-tuned (acuratețe înaltă), Rasa NLU și spaCy (pipelines complete cu extragere de entități). Generalizează la variații din datele de antrenament. Cere minimum 100 de exemple per intent, un pas de antrenament și unul de evaluare. Outputul este deterministic la inferență.
• LLM (GPT-4, Claude). Identifică intenția via prompt, fără date de antrenament. Acoperă formulări ambigue sau neobișnuite. Dezavantajele: cost de 10–100 de ori mai mare per cerere față de un classifier, latență de ordinul secundelor, output mai puțin deterministic.

Abordările nu se exclud. Un pattern util în producție: classifier ML pentru mesajele cu confidence score mare, LLM pentru mesajele sub un prag de încredere sau pentru intenții de tip „out of scope".

Cât de multe date îți trebuie pentru fiecare abordare?

• Rule-based. Zero date de antrenament. Cere timp pentru a scrie și menține regulile; dacă utilizatorii reformulează mult, regulile devin repede incomplete.
• ML classifier simplu (SVM, logistic regression pe embeddings). 100–300 de exemple per intent sunt suficiente pe intenții clar separate. Sub 100 de exemple, modelul overfittează și performanța în producție scade semnificativ față de setul de validare.
• BERT fine-tuned sau modele similare. 500–1.000 de exemple per intent pentru rezultate stabile. Preantrenarea pe corpora mari compensează parțial, dar fine-tuning-ul pe prea puține exemple generalizează slab la formulări noi.
• LLM zero-shot. Fără date de antrenament. Performanța pe intenții foarte specifice domeniului poate fi inferioară unui classifier antrenat pe date din acel domeniu.

Regula practică: dacă nu poți aduna 100 de mesaje reale sau realistice per intent, lista de intenții este probabil prea granulară. Două intenții cu sub 50 de exemple fiecare produc de obicei un model mai slab decât o singură intenție unificată cu 100+ de exemple.

Cum măsori precision și recall în producție?

Metricile standard pentru clasificare sunt adaptate direct la intent recognition:

• Precision per intent. Din toate mesajele clasificate ca „verifică_stoc", ce procent chiar era „verifică_stoc"? O precision scăzută înseamnă că modelul activează intenția când nu ar trebui.
• Recall per intent. Din toate mesajele care erau „verifică_stoc", ce procent a fost corect identificat? Un recall scăzut înseamnă că modelul ratează mesaje care ar trebui să activeze intenția.
• F1 score. Media armonică dintre precision și recall. Mai relevantă decât accuracy globală când setul de intenții este dezechilibrat (o intenție dominantă cu 70% din trafic distorsionează accuracy).
• Confusion matrix per pereche de intenții. Cel mai util instrument de depanare. Arată exact care perechi de intenții se confundă cel mai mult. Dacă „verifică_stoc" și „verifică_disponibilitate" se confundă în 30% din cazuri, fie definițiile se suprapun, fie ai prea puține exemple de diferențiere.

În producție, metricile nu se calculează doar la lansare, ci continuu. Un sistem matur colectează mesajele cu confidence score sub un prag (ex. 0,7) și le trimite la revizuire umană. Etichetele corectate devin date noi de antrenament. Fără acest ciclu, un classifier se degradează pe măsură ce utilizatorii schimbă modul în care formulează mesajele.

Testarea A/B între două versiuni ale modelului se face prin rutarea unui subset din trafic la fiecare versiune și compararea ratei de escaladare la operator, a mesajelor nerecunoscute și a duratei medii a conversației. Un model cu F1 înalt poate produce experiențe proaste dacă intențiile definite nu corespund nevoilor reale ale utilizatorilor. Pentru orchestrarea acestor fluxuri de colectare și reantrenare, echipele care folosesc deja n8n îl pot integra direct în ciclul de revizuire a etichetelor.

Un stack de observabilitate cu logging structurat pe fiecare clasificare (intenție, confidence score, rezultat) este condiția de bază pentru ca aceste metrici să fie disponibile. Fără logging la nivel de mesaj, depanarea unui classifier în producție se reduce la presupuneri.

Când LLM-ul este supradimensionat?

Un LLM este supradimensionat pentru intent recognition în mai multe scenarii tipice:

• Intenții simple și mesaje predictibile. Dacă botul tău are 8 intenții clare și utilizatorii scriu mesaje directe, un SVM sau un model BERT mic antrenat pe 200 de exemple per intent atinge aceeași performanță la 1% din costul per cerere al unui LLM.
• Latența contează. Un classifier rulat local sau pe un server dedicat răspunde în câteva zeci de milisecunde. Apelul la un LLM via API adaugă latența rețelei și timpul de generare, care poate depăși o secundă. Dacă botul tău trebuie să răspundă rapid (sub 500 ms total), un LLM pentru intent este un blocaj.
• Volumul este mare. La mii de mesaje pe zi, diferența de cost dintre un classifier și un LLM devine semnificativă. Un classifier găzduit pe un server existent adaugă cost neglijabil per cerere față de costul infrastructurii existente. Un LLM via API adaugă un cost direct per token care se acumulează linear cu volumul.
• Predictibilitatea outputului contează. Dacă intenția detectată declanșează automat o acțiune cu consecințe (trimiterea unui e-mail, anularea unei comenzi, inițierea unui ramburs), comportamentul nedeterminist al unui LLM este un risc operațional. Un classifier returnează același output pentru același input; un LLM poate varia.

Cazurile unde un LLM are sens direct sunt cele unde datele de antrenament sunt inexistente, intenția este ambiguă prin natură, sau botul gestionează intenții care se extind frecvent fără un ciclu de antrenare. Chiar și acolo, pattern-ul classifier + LLM fallback reduce costul față de un LLM pur: classifierul gestionează 80–90% din traficul cu intenții comune, LLM-ul este apelat doar pentru restul. Limitarea ratei de cereri pe apelurile LLM este un mecanism de protecție util pentru a evita spikes de cost la volume neașteptate.

La alegerea arhitecturii, SLA-ul de răspuns al botului este un criteriu direct: dacă P95 trebuie să fie sub 500 ms, un LLM via API extern este rareori compatibil. Alegerea platformei de mesagerie, documentată în intrarea despre bot framework-uri, influențează și ea decizia: pe o platformă unde fiecare mesaj al utilizatorului declanșează un webhook sincron, latența de clasificare se adaugă direct la latența percepută de utilizator.