Întrebarea AI nr. 2: Cum să asigurăm fiabilitatea apelurilor de instrumente ale LLM-urilor

Cum să ne asigurăm că un model de limbaj de mari dimensiuni (LLM) funcționează fiabil și controlabil atunci când apelează instrumente, nu doar bazându-ne pe prompturi pentru a „convinge” modelul. Este nevoie de un cadru de constrângeri pe mai multe niveluri, oferit sistematic.

De exemplu, în cazul interogării vremii, există trei comportamente comune de „inventare” ale modelului în apelurile de instrumente:
1. Să nu apeleze instrumentul și să inventeze direct răspunsul.
2. Să transmită parametri cu format greșit la apelarea instrumentului (de exemplu, instrumentul nu suportă „poimâine”, dar transmite parametrul date="poimâine").
3. Să convertească pe cont propriu formatul parametrilor (de exemplu, să transforme „poimâine” într-o dată specifică), chiar dacă instrumentul nu solicită acest lucru.

Rădăcina problemei constă în faptul că ieșirea modelului este în esență probabilistă, iar prompturile aplică doar „constrângeri soft” asupra distribuției de probabilitate, nu un mecanism obligatoriu care să asigure respectarea strictă de către model. În scenarii complexe, aceste „constrângeri soft” eșuează ușor.

Pentru a rezolva această problemă, este necesară o soluție inginerească pe mai multe niveluri:

1. Primul nivel: Optimizarea prompturilor (constrângeri soft)

   • Poziționarea este punctul de plecare al sistemului de constrângeri, dar cu siguranță nu punctul final.
   • Prompturile ar trebui tratate ca un „contract operațional”, specificând clar scopul instrumentului, tipul fiecărui parametru, limitele și oferind exemple de valori invalide.
   • Ar trebui adăugate exemple Few-shot, care, prin prezentarea unor exemple de „intrare corectă → apel corect”, ancorează modelul de comportament prin învățare contextuală.

2. Al doilea nivel: Introducerea JSON Schema (constrângeri hard)

   • Acesta este pasul cheie de la „a argumenta” la „a pune balustrade”.
   • Înlocuiți descrierile parametrilor în limbaj natural cu definiții structurate, lizibile și verificabile de mașină (JSON Schema). Se pot defini strict tipurile de câmpuri, obligativitatea, domeniile de valori enumerate și se poate interzice modelului să producă orice câmp nedefinit prin setarea additionalProperties: false.
   • Platformele API principale acceptă astfel de constrângeri de ieșire structurate încă din faza de decodare a modelului, evitând încălcările de format de la sursă.

3. Al treilea nivel: Stabilirea unui ciclu de validare-corectare-reîncercare (plasă de siguranță)

   • Chiar și cu Schema, este necesară validarea sintactică și a Schemei după obținerea ieșirii modelului.
   • În caz de eșec al validării, trebuie proiectat un mecanism automat de curățare și reîncercare (cu limită superioară), care să trimită informațiile de eroare înapoi modelului pentru a corecta ieșirea. După depășirea numărului de reîncercări, trebuie să existe o soluție de degradare sau de intervenție manuală.

4. La nivel arhitectural: Separarea responsabilităților

   • Decizia trebuie separată de execuție, formând o arhitectură pe trei niveluri:
     • Stratul model: Responsabil doar de decizie (a stabili ce instrument să apeleze, ce parametri să genereze).
     • Stratul cadru: Responsabil de executarea cadrului, incluzând validarea Schemei, apelarea instrumentului, gestionarea reîncercărilor și integrarea rezultatelor. Acest lucru asigură că erorile modelului nu afectează direct siguranța instrumentului, iar modificările instrumentelor nu necesită ajustări frecvente ale prompturilor.
     • Stratul instrument: Implementarea capacităților specifice de business.
   • Cadre precum LangChain, LlamaIndex fac exact această muncă.

Limitările soluției actuale: Gestionează bine problemele de format al parametrilor, dar acoperirea validării semantice a parametrilor (de exemplu, echivalența dintre „Shanghai” și „沪”) este încă insuficientă. Aceasta va fi o provocare inginerească de abordat în viitor.

Concluzie centrală: Asigurarea fiabilității apelurilor de instrumente de către LLM este, în esență, o problemă de inginerie software, care necesită un plan sistemic de la constrângeri soft, constrângeri hard, plasă de siguranță până la proiectarea arhitecturală, nu doar optimizarea prompturilor.