Toolformer: Uso de herramientas autosupervisado y sus límites para la IA financiera

Toolformer (Schick et al., 2023, Meta AI) es el artículo fundacional para enseñar a los modelos de lenguaje a llamar a APIs externas mediante entrenamiento autosupervisado. He estado posponiendo una lectura cuidadosa porque el "uso de herramientas" se ha convertido en una palabra tan de moda que las afirmaciones originales se confunden. Antes de diseñar cualquier agente de escritura (write-back) que llame a herramientas de contabilidad, necesito entender qué demostró realmente Toolformer y dónde falla silenciosamente.

El artículo

Timo Schick y siete coautores en Meta AI presentan un método para entrenar a un modelo de lenguaje para que decida cuándo llamar a APIs externas, qué argumentos pasar y cómo incorporar los resultados en sus propias predicciones, sin requerir datos de entrenamiento etiquetados manualmente para cada herramienta. El enfoque es autosupervisado: el modelo genera posibles llamadas a APIs en posiciones plausibles del texto, ejecuta esas llamadas y conserva solo los ejemplos donde el resultado de la API reduce genuinamente la perplejidad del modelo en los tokens circundantes. Ese conjunto de datos filtrado se utiliza luego para el ajuste fino (fine-tuning). Las herramientas probadas incluyen una calculadora, dos motores de búsqueda (recuperación BM25 y búsqueda en Wikipedia), un modelo de preguntas y respuestas (QA), un traductor y un calendario.

El modelo entrenado es un modelo basado en GPT-J de 6.700 millones de parámetros que llaman Toolformer. El artículo fue aceptado en NeurIPS 2023.

Ideas clave

• En problemas matemáticos de palabras (SVAMP), Toolformer 6.7B obtiene un 29,4%, en comparación con la línea base de GPT-J con un 5,2%, OPT 66B con un 4,9% y GPT-3 175B con un 10,0%. El uso de herramientas colapsa efectivamente la curva de escalado habitual para la aritmética.
• En ASDiv math, Toolformer alcanza el 40,4% frente al 7,5% de GPT-J y el 14,0% de GPT-3; en MAWPS, el 44,0% frente al 9,9% de GPT-J y el 19,8% de GPT-3.
• En tareas de QA fácticas la situación se invierte: GPT-3 sigue superando a Toolformer en los tres bancos de pruebas de QA (TriviaQA, WebQuestions, Natural Questions) a pesar de que Toolformer utiliza herramientas de búsqueda. Toolformer en TriviaQA: 53,5% frente a la línea base de GPT-J del 31,9%, pero GPT-3 sin herramientas es aún superior.
• El flujo de generación de datos autosupervisados produce ejemplos de entrenamiento donde el modelo aprende a no llamar a una API cuando no es útil; el paso de filtrado utiliza la mejora de la perplejidad como señal de "¿ayudó realmente esta llamada a la herramienta?".
• La capacidad de uso de herramientas solo surge a escala: los modelos por debajo de aproximadamente 775 millones de parámetros no aprenden de manera confiable cuándo invocar herramientas, incluso con la misma señal de entrenamiento.
• La herramienta de calendario se llama solo el 0,2% de las veces en tareas de razonamiento temporal; el modelo redirige predominantemente las preguntas temporales a la herramienta de búsqueda de Wikipedia en su lugar.

Qué se mantiene y qué no

El conocimiento central es duradero: el truco del filtrado basado en la perplejidad es elegante porque no requiere etiquetado humano ni un oráculo que sepa la respuesta correcta, solo si el resultado de la API insertado hizo que el texto circundante fuera más predecible. Esa es una contribución genuina, y los resultados matemáticos son sorprendentes. Que un modelo de 6.7B supere a GPT-3 en ASDiv no es un truco de evaluación; es una demostración clara de que la llamada a la herramienta adecuada vale aproximadamente 26 veces más parámetros en tareas aritméticas.

Lo que encuentro menos convincente es la historia de QA. El artículo presenta a Toolformer como una mejora amplia del rendimiento, pero los resultados de QA muestran que no supera a GPT-3, un modelo mucho más grande sin ninguna herramienta. Los autores lo reconocen, pero el marco narrativo ("a menudo competitivo con modelos mucho más grandes") subestima cuán selectiva es la victoria: el modelo gana en tareas que se descomponen limpiamente en una sola llamada a la calculadora o búsqueda, y pierde o empata en tareas que requieren un razonamiento genuino sobre el contenido recuperado.

El problema metodológico más profundo es que el flujo autosupervisado asume que el modelo ya es lo suficientemente bueno para generar llamadas a APIs plausibles antes de haber sido entrenado para hacerlo. Este es un problema de arranque (bootstrapping). Para herramientas bien estructuradas como una calculadora con un formato de entrada claro, funciona. Para herramientas con esquemas de argumentos más complejos —exactamente el tipo que se desearía para una API de escritura de libros contables del mundo real— la calidad de las llamadas muestreadas se degradaría rápidamente.

El artículo también evalúa cada herramienta de forma aislada, no en combinación. No hay demostración de un flujo de trabajo de varios pasos donde, por ejemplo, un resultado de búsqueda alimente a una calculadora. Los autores señalan esto como una limitación, pero es significativa: los flujos de trabajo contables reales casi siempre requieren llamadas a herramientas encadenadas.

Finalmente, la evaluación es zero-shot. No hay comparación con el prompting de pocos ejemplos (few-shot) de GPT-3 o GPT-4 con herramientas proporcionadas en el contexto, que se convirtió en el paradigma dominante a los pocos meses de este artículo. La fecha de publicación de NeurIPS 2023 significa que los experimentos son anteriores a la adopción generalizada de las APIs de llamada a funciones (function-calling), lo que hace que el conjunto de comparación esté algo anticuado para el momento de la publicación.

Por qué esto es importante para la IA financiera

El artículo de Toolformer responde a una pregunta que me importa para Bean Labs: ¿puede un modelo aprender a llamar a una API de escritura de forma confiable, y a qué costo? La respuesta de los resultados matemáticos es "sí, si la interfaz de la herramienta es limpia y la tarea se descompone en una sola llamada". Sin embargo, los modos de falla se asignan directamente a las partes más difíciles del problema de los libros contables.

Las acciones de escritura de Beancount —clasificar una transacción, inferir mapeos de cuentas, generar un asiento contable— no son llamadas de un solo paso a una calculadora. Implican recuperar contexto (asientos anteriores, plan de cuentas), aplicar reglas (reglas de registro, restricciones de moneda) y producir una salida estructurada que debe ser sintácticamente válida. Eso son al menos tres llamadas a herramientas encadenadas, y la arquitectura de Toolformer explícitamente no puede encadenar herramientas. La señal de entrenamiento basada en la perplejidad también sería difícil de aplicar aquí: no está claro qué significa "menor perplejidad en el texto del libro contable circundante" cuando la salida es un archivo .beancount estructurado en lugar de una continuación en lenguaje natural.

La lección más útil de Toolformer para nuestros propósitos es el espacio negativo: un agente de escritura no puede ser solo un modelo de lenguaje ajustado (fine-tuned) que ha memorizado cuándo llamar a la API contable. Necesita una capa de razonamiento explícita (ReAct o similar) que pueda planificar, ejecutar y verificar resultados intermedios antes de confirmar una escritura. Toolformer demuestra que el uso de herramientas funciona; no demuestra que funcione de manera segura en operaciones estructuradas con efectos secundarios.

Qué leer a continuación

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) — añade pasos de razonamiento explícitos de cadena de pensamiento entrelazados con llamadas a herramientas; la arquitectura que aborda la limitación de encadenamiento de Toolformer y es la base de la mayoría de los agentes modernos.
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — escala el uso de herramientas a más de 16.000 APIs reales a través del conjunto de datos ToolBench; lo más parecido a una prueba de esfuerzo de llamadas a herramientas al nivel de complejidad que enfrentaría un agente contable real.
• FinMaster (arXiv:2505.13533) — evalúa flujos de trabajo contables de extremo a extremo, incluyendo asientos contables y conciliación; mostrará si las ganancias que demostró Toolformer en aritmética se generalizan a las tareas de varios pasos y restringidas por esquemas que importan para Beancount.