Dacă ai încercat să adaptezi un model AI după feedback uman, probabil ai întâlnit o problemă foarte practică: ai exemple marcate ca „bune” și „rele”, dar nu ai perechi complete de tipul „răspunsul A este mai bun decât răspunsul B pentru aceeași întrebare”. În multe proiecte reale, feedbackul nu vine ordonat frumos pentru antrenare. Vine din tichete, revizuiri, formulare interne, moderare, audituri sau observații punctuale.
Aici intră în discuție KTO, prescurtare de la Kahneman-Tversky Optimization. Metoda este prezentată în lucrarea „KTO: Model Alignment as Prospect Theoretic Optimization”, publicată pe arXiv în 2024. Ideea centrală este utilă pentru echipele care au semnal binar: un răspuns este dezirabil sau indezirabil, dar nu există neapărat o comparație directă între două răspunsuri.
De ce nu ajunge mereu DPO
DPO, adică Direct Preference Optimization, este una dintre metodele cunoscute pentru alinierea modelelor lingvistice. Lucrarea DPO pornește de la date de preferință: pentru același prompt există, de regulă, un răspuns ales și unul respins. Asta face metoda atractivă când ai perechi curate de tip „chosen” și „rejected”.
Problema este că multe organizații nu colectează feedbackul așa. Un specialist poate marca un răspuns drept acceptabil. Altul poate marca un răspuns drept problematic. Dar asta nu înseamnă că există automat o pereche comparabilă pentru fiecare caz. Dacă forțezi datele într-un format de preferință fără acoperire reală, riști să introduci zgomot în antrenare.
KTO încearcă să rezolve exact această situație. În loc să ceară comparații complete, folosește exemple etichetate ca bune sau rele. În termenii documentației Hugging Face TRL, KTOTrainer lucrează cu ideea de răspunsuri dezirabile și indezirabile, ceea ce îl face mai potrivit pentru seturi de date unde feedbackul este binar.
Cum arată un caz realist
Să spunem că ai un asistent AI intern pentru suport tehnic, documentație sau securitate digitală. Echipa ta revizuiește răspunsurile și marchează câteva categorii simple: „corect”, „util”, „refuz justificat”, „prea vag”, „inventează informații”, „nu cere context când ar trebui” sau „oferă recomandări riscante”.
Nu ai nevoie, în primul pas, să compari fiecare răspuns bun cu unul rău pentru același prompt. Poți construi un set de exemple în care fiecare intrare are un semnal clar: dezirabil sau indezirabil. KTO poate folosi acest tip de feedback pentru a împinge modelul spre comportamente mai utile și mai sigure.
Atenție însă: eticheta „bun” nu trebuie să însemne doar „sună frumos”. Pentru un model folosit într-un context sensibil, un răspuns bun ar trebui să fie corect, prudent, clar, să nu inventeze informații și să nu ofere instrucțiuni periculoase. Un răspuns rău nu este doar unul nepoliticos; poate fi și unul prea sigur pe o afirmație neverificată.
Pașii practici pentru un flux defensiv
Primul pas este definirea criteriilor. Înainte să marchezi exemple, stabilește ce înseamnă „bun” și „rău” pentru cazul tău: acuratețe, ton, refuzuri corecte, protecția datelor, evitarea sfaturilor riscante și recunoașterea incertitudinii.
Al doilea pas este curățarea datelor. Nu introduce conversații cu date personale, parole, tokenuri, informații comerciale sensibile sau detalii confidențiale. Dacă folosești loguri reale, acestea trebuie anonimizate și verificate din punct de vedere legal și operațional.
Al treilea pas este separarea datelor de antrenare de cele de evaluare. Dacă testezi modelul doar pe exemple pe care le-a văzut deja, nu afli dacă s-a îmbunătățit cu adevărat. Ai nevoie de prompturi noi: întrebări obișnuite, cazuri ambigue, cereri imposibile, solicitări care trebuie refuzate și exemple în care modelul trebuie să spună clar că nu știe.
Al patrulea pas este comparația cu modelul inițial. Nu este suficient să vezi că procesul de antrenare s-a terminat. Trebuie să verifici dacă modelul adaptat răspunde mai bine, fără să devină mai încrezător în răspunsuri false și fără să piardă comportamente utile.
Unde poate greși KTO
KTO nu repară automat date slabe. Dacă etichetele sunt inconsistente, modelul poate învăța inconsistența. Dacă exemplele negative conțin conținut riscant prea detaliat, trebuie tratate cu grijă, pentru ca procesul de adaptare să nu întărească exact comportamentele pe care vrei să le reduci.
De asemenea, KTO nu înlocuiește evaluarea umană. În domenii precum securitate cibernetică, protecția datelor, suport financiar sau juridic, rezultatele trebuie verificate de oameni competenți. Modelul poate deveni mai bine aliniat la feedbackul primit, dar nu devine automat autoritate factuală.
Când merită ales
Regula practică este simplă: DPO este potrivit când ai perechi clare de preferințe, iar KTO merită analizat când ai feedback binar de tip „acceptabil/inacceptabil”, „bun/rău” sau „dezirabil/indezirabil”.
Pentru multe echipe, aceasta este varianta mai apropiată de realitate. Feedbackul nu apare într-un laborator perfect, ci în fluxuri de lucru imperfecte. KTO oferă o metodă tehnică prin care acel semnal poate fi folosit pentru adaptarea unui model, cu o condiție importantă: datele, criteriile și evaluarea trebuie tratate serios. Altfel, modelul nu învață calitate, ci doar zgomot organizat.
