Pregunta d'entrevista AI 2: Com assegurar que la crida d'eines d'un model de llenguatge gran (LLM) sigui fiable

Com assegurar que un model de llenguatge gran (LLM) treballi de manera fiable i controlable en la crida d'eines, sense dependre únicament de les indicacions per "convèncer" el model. Cal proporcionar sistemàticament un marc de restriccions de múltiples nivells.

Per exemple, en el cas de consultar el temps, el model pot tenir tres comportaments comuns d'"inventar" en la crida d'eines:
1. No cridar l'eina i inventar directament la resposta.
2. Cridar l'eina amb paràmetres de format incorrecte (per exemple, l'eina no admet "demà passat", però es passa el paràmetre date="demà passat").
3. Convertir el format dels paràmetres per iniciativa pròpia (per exemple, convertir "demà passat" a una data específica), fins i tot si l'eina no ho requereix.

L'arrel del problema és que la sortida del model és essencialment probabilística; les indicacions només imposen una "restricció suau" sobre la distribució de probabilitats, no un mecanisme obligatori que garanteixi que el model segueixi estrictament. En escenaris complexos, aquesta "restricció suau" falla fàcilment.

Per resoldre aquest problema, cal una solució d'enginyeria de múltiples nivells:

1. Primer nivell: Optimitzar les indicacions (restricció suau)

   • És el punt de partida del sistema de restriccions, però no el final.
   • Les indicacions s'han de tractar com un "contracte operatiu", explicant clarament la finalitat de l'eina, el tipus de cada paràmetre, els límits, i proporcionant exemples de valors il·legals.
   • S'han d'incloure exemples Few-shot, mostrant exemples de "entrada correcta → crida correcta" per ancorar el patró de comportament del model mitjançant l'aprenentatge contextual.

2. Segon nivell: Introduir JSON Schema (restricció dura)

   • Aquest és el pas clau de "raonar" a "posar baranes".
   • Utilitzar una definició estructurada llegible per màquina i verificable (JSON Schema) en lloc de descripcions en llenguatge natural dels paràmetres. Pot definir estrictament el tipus de camp, si és obligatori, el rang de valors d'enumeració, i pot prohibir que el model generi qualsevol camp no definit mitjançant additionalProperties: false.
   • Les plataformes API principals admeten aquesta restricció de sortida estructurada durant la fase de descodificació del model, evitant violacions de format des de l'origen de la generació.

3. Tercer nivell: Establir un bucle de validació-reparació-reintent (execució de contingència)

   • Fins i tot amb Schema, cal realitzar una validació de sintaxi i Schema després d'obtenir la sortida del model.
   • Quan la validació falla, s'ha de dissenyar un mecanisme automàtic de neteja i reintent (amb límit), retornant la informació d'error al model per corregir la sortida. Després d'excedir el nombre de reintents, cal un pla de degradació o intervenció manual.

4. Nivell d'arquitectura: Separació de responsabilitats

   • Cal separar la decisió de l'execució, formant una arquitectura de tres capes:
     • Capa de model: Només s'encarrega de la decisió (determinar quina eina cridar, quins paràmetres generar).
     • Capa de framework: S'encarrega del marc d'execució, incloent la validació de Schema, la crida d'eines, la gestió de reintents i la integració de resultats. Això assegura que els errors del model no afectin directament la seguretat de les eines, i que els canvis en les eines no requereixin ajustos freqüents de les indicacions.
     • Capa d'eines: Implementació de les capacitats de negoci específiques.
   • Frameworks com LangChain, LlamaIndex fan exactament aquesta feina.

Limitacions de la solució actual: Pot gestionar bé el format dels paràmetres, però la cobertura de validació de la semàntica dels paràmetres (per exemple, l'equivalència entre "Shanghai" i "Hu") encara és insuficient. Aquest serà un repte d'enginyeria futur.

Conclusió principal: Fer que un LLM cridi eines de manera fiable és essencialment un problema d'enginyeria de programari, que requereix establir un pla d'enginyeria sistemàtic des de restriccions suaus, restriccions dures, execució de contingència fins a disseny d'arquitectura, en lloc de dependre únicament de l'optimització de les indicacions.