Există un anumit tip de optimism care ucide funcționalitățile bazate pe LLM. Promptul funcționează la a treia încercare, demoul iese bine la standup și cineva spune să-l lansăm. O săptămână mai târziu, inventează discret numere de cont în producție și nimeni nu poate spune când a început — pentru că nimeni nu măsura.
Un prompt nu este o specificație
Codul tradițional eșuează zgomotos: o eroare de tip, o excepție aruncată, un test roșu. Un model de limbaj eșuează discret. Returnează ceva fluent și plauzibil care se întâmplă să fie greșit și o face nedeterminist, astfel încât aceeași intrare poate trece luni și poate eșua joi. Un demo dovedește că funcționalitatea poate funcționa o dată. Nu spune nimic despre cât de des funcționează sau ce face la limite. A trata un demo reușit drept o garanție este modul în care echipele lansează zvonuri în loc de funcționalități.
Așa că inversăm ordinea. Înainte să scriem funcționalitatea, scriem evaluarea. Construim un set evaluat de intrări reale cu rezultate corecte cunoscute, definim un barem pe care un al doilea model — sau un om — îl poate aplica consecvent și abia apoi începem să iterăm pe prompt și pe pipeline-ul de regăsire. Evaluarea este specificația. Dacă nu putem descrie cum arată „bine” suficient de precis încât să-l notăm, înseamnă că încă nu înțelegem funcționalitatea suficient de bine ca să o construim.
Construiește setul din realitate
Seturile de evaluare bune provin din trafic real, nu din imaginație. Eșantionăm jurnalele de producție pentru cazurile care apar efectiv, apoi adăugăm deliberat și pe cele adversariale: întrebarea ambiguă, injecția de prompt, intrarea în limba greșită, cererea pe care modelul ar trebui să o refuze. Fiecare exemplu este etichetat o singură dată, cu grijă, și devine un punct fix. Suita completă rulează offline la fiecare modificare de prompt și de model, iar o versiune mai restrânsă rulează online pe traficul real, astfel încât să prindem derivele pe care setul de referință nu le-a anticipat niciodată.
O funcționalitate fără evaluare este un zvon. Susții că funcționează; doar că nu ai cum să știi.— Protocore · Inginerie AI
Odată ce suita există, devine o barieră. Fiecare modificare a unui prompt, a unei versiuni de model sau a unui index de regăsire rulează evaluarea completă în CI, iar noi ținem un buget de regresie așa cum alte echipe țin un buget de erori: o modificare care îmbunătățește o metrică în timp ce o degradează discret pe alta nu se integrează. Trecerea la un model mai nou și mai ieftin încetează să mai fie un act de credință și devine un diff pe care îl poți citi — aceste zece cazuri s-au îmbunătățit, aceste două s-au înrăutățit, iată compromisul.
Este mai lent la început și mult mai rapid după aceea. Pe un sistem de inteligență documentară pe care îl operăm, infrastructura de evaluare este ceea ce ne-a permis să atingem 92% procesare integrală automată și, mai important, să o menținem acolo de-a lungul a trei actualizări de model. Funcționalitățile par mai puțin magice construite astfel. De asemenea, încetează să ne mai surprindă în producție, ceea ce este întregul scop.
Ai un sistem de construit?
Spune-ne care e problema. Revenim cu o arhitectură și un plan.
Începe un proiect