Pregunta de entrevista sobre IA 2: Cómo garantizar que los modelos de lenguaje grandes (LLM) llamen a herramientas de manera confiable

Cómo asegurar que un modelo de lenguaje grande (LLM) funcione de manera confiable y controlable al llamar a herramientas, sin depender únicamente de indicaciones para "convencer" al modelo. Se necesita un marco de restricción de múltiples niveles de manera sistemática.

Por ejemplo, en el caso de consultar el clima, hay tres comportamientos comunes de "inventar" del modelo al llamar a herramientas:
1. No llamar a la herramienta y directamente inventar una respuesta.
2. Pasar parámetros con formato incorrecto al llamar a la herramienta (por ejemplo, la herramienta no admite "pasado mañana", pero se pasa el parámetro date="pasado mañana").
3. Convertir arbitrariamente el formato de los parámetros (por ejemplo, convertir "pasado mañana" en una fecha específica sin autorización), incluso si la herramienta no lo requiere.

La raíz del problema es que la salida del modelo es esencialmente probabilística, y las indicaciones solo imponen una "restricción suave" sobre la distribución de probabilidad, no un mecanismo obligatorio que garantice que el modelo cumpla estrictamente. En escenarios complejos, esta "restricción suave" falla fácilmente.

Para resolver este problema, se necesita una solución de ingeniería de múltiples niveles:

1. Primer nivel: Optimizar las indicaciones (restricción suave)
2. Se posiciona como el punto de partida del sistema de restricciones, pero no es el final.
3. Las indicaciones deben considerarse como un "contrato operativo", explicando claramente el propósito de la herramienta, el tipo de cada parámetro, los límites, y enumerando ejemplos de valores no válidos.

4. Se deben incluir ejemplos Few-shot, mostrando ejemplos de "entrada correcta → llamada correcta" para anclar el patrón de comportamiento del modelo mediante el aprendizaje contextual.

5. Segundo nivel: Introducir JSON Schema (restricción dura)

6. Este es un paso clave de "razonar" a "poner barreras".
7. Reemplazar la descripción de parámetros en lenguaje natural con una definición estructurada legible y verificable por máquina (JSON Schema). Puede definir estrictamente el tipo de campo, si es obligatorio, el rango de valores enumerados, y prohibir que el modelo genere cualquier campo no definido estableciendo additionalProperties: false.

8. Las principales plataformas API admiten esta restricción de salida estructurada en la etapa de decodificación del modelo, evitando violaciones de formato desde el origen de la generación.

9. Tercer nivel: Establecer un bucle cerrado de verificación-reparación-reintento (respaldo de ejecución)

10. Incluso con Schema, aún es necesario realizar una verificación de sintaxis y Schema después de obtener la salida del modelo.

11. Cuando la verificación falla, se debe diseñar un mecanismo automático de limpieza y reintento (con límite), devolviendo la información de error al modelo para corregir la salida. Después de exceder el número de reintentos, se necesita un plan de degradación o manejo manual.

12. Nivel de arquitectura: Separación de responsabilidades

13. Se debe separar la decisión de la ejecución, formando una arquitectura de tres capas:
    • Capa del modelo: Solo responsable de la decisión (determinar qué herramienta llamar, qué parámetros generar).
    • Capa del framework: Responsable del marco de ejecución, incluyendo verificación de Schema, llamada a herramientas, manejo de reintentos e integración de resultados. Esto asegura que los errores del modelo no afecten directamente la seguridad de la herramienta, y los cambios en las herramientas no requieran ajustes frecuentes en las indicaciones.
    • Capa de herramientas: Implementación de capacidades comerciales específicas.
14. Frameworks como LangChain y LlamaIndex están haciendo precisamente este trabajo.

Limitaciones de la solución actual: Maneja bien el problema del formato de parámetros, pero la cobertura de verificación de la semántica de parámetros (por ejemplo, la equivalencia entre "Shanghái" y "Hu") sigue siendo insuficiente. Este será un desafío de ingeniería a enfrentar en el futuro.

Conclusión central: Hacer que los LLM llamen a herramientas de manera confiable es esencialmente un problema de ingeniería de software, que requiere establecer una solución de ingeniería sistemática que vaya desde restricciones suaves, restricciones duras, respaldo de ejecución hasta diseño arquitectónico, en lugar de depender únicamente de optimizar las indicaciones.