“Deja de pedirle al modelo que haga aritmética de cabeza. Dale una calculadora y deja que pulse las teclas.”
Qué significa realmente el «function calling»
Le describes al modelo un conjunto de funciones (sus nombres, qué hacen y sus parámetros). Cuando el modelo decide que necesita una, en vez de responder emite una petición estructurada: «llama a get_order_status con order_id=4471». Tu código ejecuta la función real, devuelve el resultado, y el modelo continúa con ese resultado en mano.
El modelo nunca ejecuta nada por sí mismo. Solo propone una llamada en forma estructurada; tu código decide si ejecutarla y cómo. Esa frontera es toda la historia de la seguridad, y nos apoyamos en ella con fuerza en el curso de seguridad.
Por qué las herramientas arreglan las peores debilidades del modelo
Recuerda las cosas en las que los modelos son malos: la aritmética, los datos actuales y cualquier cosa con una respuesta correcta determinista. Las herramientas arreglan las tres entregando el trabajo a sistemas que destacan en ellas.
- Calculadora / intérprete de código: el modelo deja de fabular números y los calcula.
- Consulta a base de datos / API: el modelo deja de alucinar datos y los obtiene.
- Búsqueda: el modelo deja de apoyarse en conocimiento de entrenamiento obsoleto y los consulta.
- Validadores (verificador de tipos, linter, esquema): el modelo puede comprobar su propia salida contra la verdad.
Diseñar buenas herramientas
El modelo usa una herramienta como un recién contratado usa una API desconocida: solo a partir del nombre y la descripción. Así que el diseño de herramientas es diseño de API para un lector que no va a leer el código fuente. Los nombres deben ser inequívocos, las descripciones deben decir cuándo usar la herramienta (no solo qué hace), y los parámetros deben ser difíciles de usar mal.
Devuelve errores sobre los que el modelo pueda actuar. «Error 400» es inútil; «order_id debe tener 6 dígitos; pasaste 4471 (4 dígitos)» permite que el modelo se corrija y reintente. Trata al modelo como el consumidor de tus mensajes de error, y escríbelos para ese lector.
Las herramientas de lectura y las de escritura son animales distintos
Una herramienta que lee (consultar un pedido, buscar en documentos) es de bajo riesgo: el peor caso es una respuesta equivocada. Una herramienta que escribe (enviar un correo, cobrar una tarjeta, borrar un registro) puede causar daños reales que el modelo no puede deshacer. Estas merecen un trato completamente distinto.
Haz idempotentes las herramientas de escritura cuando puedas, para que un reintento sea seguro. Pon un paso de aprobación humana delante de las acciones de alto riesgo. Dale al modelo un modo de simulación para que pueda probar antes de confirmar. Y registra cada llamada. El modelo acabará llamando a una herramienta de escritura con argumentos malos; diseña para que eso sea sobrevivible, no catastrófico.
Una línea por cada uno
- Function calling: el modelo propone una llamada estructurada; tu código ejecuta la herramienta real y devuelve el resultado.
- Las herramientas arreglan las peores debilidades del modelo (matemáticas, datos recientes, efectos secundarios) delegando en sistemas que destacan en ellas.
- El diseño de herramientas es diseño de API para un lector que no va a leer el código fuente: nombres claros, errores instructivos, salida compacta.
- Las herramientas de lectura son de bajo riesgo; las de escritura necesitan idempotencia, simulaciones, límites, puertas de aprobación y registro.
Adónde ir ahora