Manual de salidas estructuradas para LLM

• Los modelos de lenguaje grandes (LLM) pueden producir inestabilidad al generar formatos estructurados como JSON, XML o código, y este es una guía práctica para desarrolladores para resolver ese problema
• Debido a su naturaleza probabilística, la salida puede romperse de forma no determinista, por lo que aborda técnicas deterministas de estructuración para compensarlo
• Cubre todo el proceso, incluyendo principios de funcionamiento internos, selección de herramientas y tecnologías, despliegue, escalado y optimización de costos, y mejora de la calidad de salida
• Integra la información más reciente de un campo de generación estructurada que cambia rápidamente en un documento que se actualiza continuamente
• Es una referencia esencial para desarrolladores que usan LLM de forma programática para extracción de datos, generación de código y llamadas a herramientas

---

Por qué se necesitan salidas estructuradas de LLM

• Los LLM suelen generar salidas sintácticamente válidas como JSON, XML o código, pero debido a su naturaleza probabilística pueden aparecer errores de formato o resultados incompletos
  • Esto provoca problemas en procesos automatizados como la extracción de datos, la generación de código o las llamadas a herramientas
• Para resolver estos problemas, se necesita un enfoque de salida estructurada determinista
• El manual cubre todo el conjunto de herramientas y técnicas para que los desarrolladores puedan implementar salidas estructuradas de forma estable

Contenido principal del manual

• Incluye temas orientados a la práctica como principios de funcionamiento internos, las mejores herramientas y tecnologías, criterios para elegir herramientas, cómo construir, desplegar y escalar sistemas, optimización de latencia y costos y mejora de la calidad de salida
• Cada apartado está organizado como un enfoque paso a paso aplicable directamente por desarrolladores
• Reúne en un solo documento la investigación más reciente y las herramientas open source relacionadas con salidas estructuradas

Vigencia y actualizaciones

• La tecnología de generación estructurada evoluciona muy rápido, por lo que el material existente queda desactualizado enseguida
• Este manual se mantiene como un living document que se actualiza regularmente
• Los desarrolladores pueden acceder a la información más reciente en un solo lugar sin tener que revisar múltiples papers, blogs y repositorios de GitHub

Cómo usarlo

• Se puede leer completo de forma secuencial o usar como una obra de consulta para encontrar de inmediato el tema necesario
• Su estructura, centrada en desarrolladores en la práctica, permite una referencia rápida al resolver problemas concretos

Creadores y comunidad

• El manual fue creado por el equipo de Nanonets
  • Ellos mantienen el modelo Nanonets-OCR y la biblioteca open source de procesamiento de documentos docstrange
• A través del newsletter de la comunidad de desarrolladores de LLM, comparten cada dos semanas los insights más recientes, avances y herramientas y técnicas útiles

[GN⁺]

Comentarios de Hacker News

• Es una guía realmente hermosa. Me gustaron especialmente las animaciones de cambio de pestaña en varias páginas.
  Pensaba que entendía bastante bien la generación con restricciones gramaticales (incluso hice algunas contribuciones a la implementación de grammar en llama.cpp), pero aun así obtuve ideas nuevas de esta guía.
  Creo que la salida estructurada es una de las funciones más subestimadas de los motores LLM. Gracias a las restricciones gramaticales, se puede usar un LLM de forma confiable como parte de un pipeline más grande (por ejemplo, un agente que llama herramientas).
  La salida puede estar mal semánticamente, pero gramaticalmente siempre será correcta. Esto es especialmente importante cuando se usan modelos locales.
  Por ejemplo, como en el ejemplo del filtro de spam de Jart basado en Raspberry Pi, si aplicas una grammar para que el modelo TinyLlama solo genere "yes" o "no", funciona de forma estable incluso en hardware pequeño.

  • Me pregunto qué pasa cuando el modelo quiere producir otra salida, y si es mejor manejarlo dentro de llamafile o en un wrapper externo. También me gustaría saber cómo se configuran los reintentos o la delimitación de JSON.

• Es una guía excelente. Investigué generación estructurada en mi doctorado, así que comparto algunos recursos para quienes estén interesados.
  Como bibliotecas están Outlines, Guidance y XGrammar.
  Como artículos recomiendo Efficient Guided Generation for Large Language Models, Automata-based constraints for language model decoding y Pitfalls, Subtleties, and Techniques in Automata-Based Subword-Level Constrained Generation.
  Y como entradas de blog están LLM Decoding with Regex Constraints y Coalescence: making LLM inference 5x faster.

  • No me queda claro cuál es exactamente el papel de Outlines dentro del stack. Me pregunto si se parece a las API de salida estructurada que ofrecen los grandes proveedores de modelos, o si se puede comparar con proyectos como BAML.
  • Da la impresión de que la parte de canonical filtering en el paper DFybOGeGDS no considera la pretokenización. Me gustaría saber si hay investigaciones sobre generación canónica que realmente incorporen regex de pretokenización.
  • Dicen “otros materiales de referencia”, pero parece que solo volvieron a enumerar la lista de bibliotecas que ya estaba en la guía.
  • Es realmente un tesoro. Las restricciones basadas en autómatas son un tema fascinante.

• Es una guía bien organizada. Si quieren saber más sobre la optimización de Guidance y llguidance, vale la pena consultar este artículo corto que escribimos.

  • Soy uno de los autores que leyó el artículo. Me impresionó especialmente la implementación de slicing para dense token mask.

• Esta guía cubre bien los dos enfoques que más suele usar la gente. Aun así, la generación restringida puede diferir de la distribución original del LLM.
  Por ejemplo, cuando un LLM genera un objeto estructurado largo, suele preferir patrones como ‘…’, pero la generación restringida puede forzarlo a corregir eso con comillas de cierre y similares, produciendo resultados incorrectos.
  En cambio, el resampling repite el proceso hasta obtener un resultado válido, así que puede ser más estable.
  Además, en vez de ir alargando el contexto añadiendo errores de esquema, me parece mejor simplemente reintentar por calidad y costo.

  • También es posible un enfoque híbrido: primero intentar generación no restringida (unconstrained) y, solo si falla, aplicar generación restringida (constrained).

• Me pregunto si los modelos SoTA (Opus, Gemini, etc.) todavía necesitan enforcement de esquema de salida.
  Hoy en día los modelos casi no cometen errores gramaticales al generar JSON o código, así que quisiera saber si internamente siguen haciendo validación de esquema.
  Entiendo que la generación estructurada sí es necesaria para modelos pequeños.

  • Cuanto más complejo es el esquema, más útil sigue siendo, porque los LLM siguen siendo débiles para contar. Aunque los modelos hayan mejorado, por su naturaleza probabilística no son perfectos.
  • Incluso los modelos más recientes a veces agregan tokens innecesarios como json\n, así que sigue siendo más seguro especificar un esquema de respuesta JSON.

• Forzar salidas estructuradas provoca una caída de rendimiento. En algunos casos puede ser 2 o 3 veces más lento. Hay que evaluar si ese costo vale la pena según la situación.

• Es una guía realmente sorprendente. Ojalá hubiera existido algo así hace un año. Definitivamente la voy a compartir con gente de mi entorno.

• Buena guía. Me gustó especialmente el diagrama de masked decoding.

  • Soy uno de los autores. Voy a revisar el problema del enlace. Como todos los proveedores de modelos comerciales están agregando funciones de salida estructurada, vamos a seguir actualizando la guía.

• Me pregunto si habrá algún formato de salida más confiable y más fácil de parsear que JSON. YAML o TOML tienen sus desventajas, pero quizá sean mejores en cantidad de tokens o costo.

  • Yo uso el formato TOON para ese propósito.
  • Así como a las personas también les da flojera escribir JSON, quizá para los LLM sea mejor generar resultados en forma de código como TypeScript. Eso sí, por seguridad hacen falta sandboxing y límites de recursos.
  • Estamos desarrollando un pipeline de transformación de contenido basado en Markdown + YAML front matter. Es cierto que el tooling de JSON se queda corto, pero validar no es difícil.
  • Yo fuerzo un esquema XML con expresiones regulares y luego decodifico con un parser XML. En particular, envuelvo los bloques de código en CDATA para dar más libertad. La salida estructurada con regex de la API de OpenAI se adapta mejor al código que JSON.
  • Lo ideal es hacer una evaluación por cuenta propia. En mis experimentos, XML siempre dio mejores resultados que JSON en tareas out-of-distribution.

• Me da curiosidad el stack técnico de la página de documentación/cookbook. No parece MkDocs ni GitBook; quisiera saber qué usaron.

  • Se usó Docusaurus.