RAG sau ajustare fină? Ce ne-au învățat proiectele reale cu clienții despre alegerea potrivită

Aproape orice discuție despre IA în mediul enterprise la care particip ajunge, în prima oră, la aceeași răscruce. Clientul are un model lingvistic de mari dimensiuni care impresionează în demonstrații, dar nu își cunoaște produsele, politicile sau stilul de redactare. Cineva din încăpere întreabă: ar trebui să ajustăm fin modelul folosind datele noastre sau să construim în jurul lui un sistem de generare augmentată prin recuperare (RAG)?

Răspunsul sincer este că, de obicei, întrebarea este formulată greșit. RAG și ajustarea fină rezolvă probleme diferite. Echipele care le tratează ca pe opțiuni concurente ajung adesea să petreacă luni întregi și să cheltuiască o mare parte din bugetul pentru GPU-uri încercând să rezolve problema greșită. Iată cum luăm decizia în practică și ce am văzut că funcționează și ce nu.

Începeți prin a identifica ce îi lipsește modelului

Când un model oferă un răspuns slab la o sarcină de business, îi lipsește unul dintre două lucruri.

Îi lipsesc cunoștințele. Nu cunoaște cea mai recentă listă de prețuri, clauza din contractul cu furnizorul din 2025 sau pașii de depanare pentru un produs lansat luna trecută. Aceasta este o problemă legată de fapte.

Îi lipsește comportamentul potrivit. Știe suficient, dar nu răspunde așa cum aveți nevoie. Ignoră formatul de ieșire cerut, folosește un ton nepotrivit, interpretează greșit codurile interne sau nu poate îndeplini o sarcină restrânsă și repetitivă, cum ar fi clasificarea tichetelor în cele 40 de categorii ale dumneavoastră. Aceasta este o problemă de competențe.

RAG este soluția pentru prima problemă. Ajustarea fină este soluția pentru a doua. Cea mai mare parte a confuziei pe care o întâlnesc vine din încercarea de a folosi ajustarea fină pentru a preda fapte.

De ce ajustarea fină este o metodă slabă de a adăuga cunoștințe

E tentant să credeți că, dacă antrenați un model pe documentele dumneavoastră, acesta le va „cunoaște”. În practică, modelul deprinde stilul acelor documente mult mai fiabil decât faptele pe care le conțin. Cercetătorii de la Microsoft au comparat direct cele două abordări pentru întrebări care necesită multe cunoștințe și au constatat că RAG a depășit în mod constant ajustarea fină nesupravegheată, atât în cazul faptelor întâlnite de model în timpul antrenării, cât și al celor complet noi.

Există și probleme practice. Faptele se schimbă. De fiecare dată când se modifică politica sau catalogul dumneavoastră, un model ajustat fin devine neactualizat până când îl antrenați din nou. În plus, pierdeți trasabilitatea: când un model ajustat fin indică o cifră, nu puteți arăta documentul din care provine. Pentru clienții din domeniile reglementate ale asigurărilor și sănătății, numai acest lucru este de obicei suficient pentru a încheia discuția.

RAG, descris pentru prima dată în lucrarea din 2020 a lui Lewis și a colaboratorilor săi, păstrează cunoștințele în afara modelului. La momentul întrebării, preluați pasajele relevante și le transmiteți modelului ca context. Pentru a actualiza cunoștințele, actualizați un index, nu reantrenați modelul. În plus, fiecare răspuns poate indica sursa.

Un client de-al nostru din domeniul logisticii este un exemplu grăitor. Clienții săi doreau răspunsuri imediate despre locul în care se aflau expedițiile lor și despre documentele care lipseau. Aceste informații se schimbă la câteva minute. Nicio cantitate de antrenare nu ar fi putut menține un model la zi, așa că asistentul pe care l-am construit răspunde la momentul întrebării pe baza datelor de urmărire în timp real și a datelor IoT, nu din memorie. Regăsirea informațiilor era singura soluție posibilă.

Când își dovedește utilitatea ajustarea fină

Ajustarea fină nu a dispărut. Pur și simplu, domeniul ei de aplicare este mai restrâns decât se așteaptă mulți. O folosim în trei situații:

• Formate de ieșire stricte și repetitive. Când un model trebuie să producă aceeași ieșire structurată de mii de ori pe zi, de exemplu, să extragă câmpuri din facturi într-o schemă JSON fixă, un model mic ajustat fin este adesea mai fiabil și mult mai ieftin decât să îi dai instrucțiuni unui model mare.
• Limbaj de specialitate. În unele domenii se folosesc abrevieri pe care modelul de bază le interpretează greșit. Codurile de stare din logistică, abrevierile clinice și codurile interne ale produselor sunt exemple obișnuite. O ajustare fină modestă poate rezolva problema.
• Costuri și latență la scară largă. După ce o sarcină este bine definită, un model mic ajustat fin poate înlocui un model general de mari dimensiuni. Metode precum LoRA fac acest lucru accesibil, deoarece antrenați un set mic de ponderi suplimentare, nu întregul model.

Observați că niciuna dintre aceste situații nu privește faptele. Este vorba despre a învăța un model cum să se comporte într-o sarcină pe care o înțelegeți deja bine.

Majoritatea problemelor RAG sunt probleme de regăsire

Când cineva dintr-o echipă îmi spune „am încercat RAG și n-a funcționat”, rareori modelul este problema. De obicei, problema ține de etapa de regăsire. Calitatea modelului nu poate depăși calitatea pasajelor pe care le primește.

Soluțiile nu sunt spectaculoase, dar sunt eficiente:

• Împărțiți textul în fragmente după sens, nu după numărul de caractere. Dacă împărțiți un contract la fiecare 500 de caractere, veți tăia clauzele în două. Împărțirea pe secțiuni și titluri păstrează contextul intact.
• Adăugați context fiecărui fragment. Un fragment care spune „limita este de 30 de zile” nu este util dacă nu știți cărei politici îi aparține. Anthropic a raportat că adăugarea unui scurt context din document la fiecare fragment înainte de indexare — o abordare pe care o numește regăsire contextuală — a redus eșecurile de regăsire cu 49%, iar combinarea acestei metode cu reordonarea rezultatelor le-a redus cu 67%.
• Combinați căutarea după cuvinte-cheie cu cea vectorială. Căutarea vectorială surprinde bine sensul, dar identifică mai greu termeni exacți, precum numerele de piesă. Căutarea hibridă le acoperă pe ambele.
• Testați separat procesul de recuperare. Alcătuiți un set de întrebări reale, cu pasaje-sursă corecte cunoscute, și măsurați dacă pasajul potrivit apare printre primele rezultate înainte de a evalua răspunsurile finale.

Când să le folosiți pe amândouă

În producție, cele mai performante sisteme le combină adesea pe amândouă. RAG furnizează informațiile. Un model ajustat fin într-o măsură redusă gestionează formatul, tonul și limbajul specific domeniului. Cercetarea avansează în aceeași direcție: abordarea RAFT de la UC Berkeley ajustează fin un model special pentru a folosi mai bine documentele recuperate și a le ignora pe cele irelevante.

Însă ordinea contează. Aproape întotdeauna începem prin a construi RAG, măsurăm unde nu se ridică la nivelul așteptărilor și abia apoi decidem dacă merită să recurgem la ajustarea fină. Dacă începi cu ajustarea fină, plătești pentru antrenare înainte să știi care este, de fapt, problema.

O listă simplă de verificare pentru luarea deciziei

1. Sarcina depinde de informații care se schimbă de mai multe ori pe trimestru? Folosiți RAG.
2. Au nevoie utilizatorii sau auditorii să vadă de unde provine un răspuns? Folosiți RAG.
3. Problema ține de formatul, tonul sau vocabularul răspunsurilor, nu de informațiile pe care le conțin? Luați în considerare ajustarea fină.
4. Este vorba despre o sarcină restrânsă, executată la scară mare, pentru care contează costul sau viteza? Luați în considerare ajustarea fină a unui model mai mic.
5. Ați măsurat separat calitatea procesului de recuperare? Dacă nu, faceți acest lucru înainte de orice altceva.

Concluzia

RAG și ajustarea fină nu sunt rivale. Una oferă modelului informațiile potrivite, cealaltă îi modelează comportamentul. Clarificați care este problema pe care o aveți de fapt, îmbunătățiți procesul de recuperare înainte să dați vina pe model și considerați ajustarea fină o optimizare pe care v-o puteți permite numai după ce sistemul funcționează, nu o scurtătură pentru a-l face să funcționeze.