Reparar la salida JSON de un LLM: manejar el casi-JSON de la IA

Los LLM suelen devolver JSON envuelto en vallas ```json, con comillas simples, literales de Python o claves sin comillas. Repara la sintaxis, valida de forma estricta y luego deriva tipos de TypeScript de la salida limpia.

Cuando llegas aquí

Un LLM devolvió JSON que JSON.parse rechaza. Los culpables más comunes son las vallas de código markdown que envuelven el documento, las comillas simples, las claves sin comillas, los literales de Python como True/None y los objetos serializados. Repara la sintaxis y luego valida de forma estricta antes de entregar el resultado a tu app.

El flujo de reparación para la salida de un LLM

Ejecuta primero la reparación: tolera vallas, comillas simples, claves sin comillas, literales de Python y comas finales. Valida en segundo lugar para confirmar que el texto limpio va y vuelve. Usa el árbol limpio para derivar tipos o alimentar tu app.

Una vez que analiza, deriva tipos

Después de que la salida del LLM se valide, deriva interfaces de TypeScript o un JSON Schema para que la siguiente llamada tenga un contrato contra el que validar. Esa es la diferencia entre reparar una vez y reparar para siempre.

Lo que viene en los estándares

Dos próximas propuestas de JavaScript importan para los flujos de JSON de los LLM: el acceso a la fuente en JSON.parse (leer errores con el texto original junto al valor) y JSON.parseImmutable. Reducen la cantidad de código de reparación a medida que vive en cada app.

Ruta recomendada

Pega la salida del LLM, límpiala, tipifícala.

    1. Herramienta: / — pega la salida de la IA, haz clic en «Reparar y formatear».
    1. Guía: /guides/repair-llm-json-output — maneja vallas, comillas, literales de Python.
    1. Blog: /blog/repair-broken-json-in-javascript — el mismo flujo en código.
    1. Referencia: /news/json-parse-source-access-baseline-2025 — qué soporte estándar está llegando.