Headlines y datos estructurados sin inflar el JSON
La factura oculta entre tus llaves
JSON triunfó porque es aburrido exactamente de la manera correcta. Los humanos pueden leerlo. Las máquinas pueden analizarlo. Todos los lenguajes tienen una biblioteca para él. Si dos sistemas necesitan intercambiar un objeto y nadie quiere una reunión de estándares, JSON suele ser donde termina la conversación. Bien. Hay compromisos peores. Muchos de ellos llevan "enterprise" en el nombre.
El problema no es JSON como formato web. El problema es lo que ocurre cuando lo introducimos en flujos de trabajo con modelos de lenguaje y pretendemos que el coste es gratis. Un modelo no ve un objeto ordenado como lo ve un analizador de aplicaciones. Ve tokens. Lee las mismas claves una y otra vez. Gasta contexto en puntuación, nombres de campos repetidos, envoltorios, andamiajes anidados y recordatorios de forma que ya se conocían antes de que llegara el primer registro.
Ese desperdicio solía ser levemente irritante. Con los sistemas de IA, se convierte en un problema de producto. Cada clave repetida compite con evidencia, instrucciones, ejemplos, citas y contenido real del usuario. Cada token estructural redundante es un pequeño impuesto sobre el trabajo útil. La factura no dice llaves innecesarias, porque las facturas carecen de poesía. Dice tokens.
HEDL parte de una observación sencilla: cuando el esquema se conoce, repetir el esquema dentro de cada registro es una tontería. Declara la estructura una vez. Codifica los registros de forma posicional. Mantén la semántica exacta. Convierte de vuelta a los formatos que los sistemas existentes ya esperan. Eso no es ideología anti-JSON. Es negarse a pagar al modelo para que relea la misma señal de tráfico cada diez metros.
Esto importa porque el trabajo estructurado con IA no es solo chat. Es extracción, clasificación, llamadas a herramientas, transformación de datos, paquetes de revisión, paquetes de evidencia, llamadas MCP, flujos de trabajo y agentes que se pasan objetos entre sí todo el día. Cuanto más serio se vuelve el sistema, más estructura necesita. Si la estructura se expresa de la manera más verbosa posible, el sistema paga por su propia disciplina.
JSON no es el villano
Sería fácil, y perezoso, escribir esto como una queja sobre JSON. JSON tiene fortalezas reales. Es ubicuo, depurable, fácil de canalizar a través de herramientas existentes y suficientemente bueno para una gran cantidad de trabajo de aplicaciones. El punto no es que JSON sea malo. El punto es que JSON se usa a menudo en lugares donde el lado receptor ya conoce la forma, y allí la repetición deja de ser claridad y empieza a ser carga.
Considera una tarea de extracción estructurada. El esquema dice que cada respuesta tiene un nombre, una fuente, un valor, una confianza y una justificación. Ahora imagina enviar cientos de filas a un modelo o recibir cientos de filas de uno. JSON repite esos nombres de campo para cada objeto. El analizador de aplicaciones no lo nota. El contexto del modelo sí. La ventana de contexto se convierte en una furgoneta de reparto llena de etiquetas en lugar de mercancía.
HEDL trata el esquema como un contrato. Nombra los campos y tipos una sola vez. Los registros llevan entonces los valores en orden. Eso suena obvio porque lo es. Muchos formatos eficientes han hecho concesiones similares durante décadas. La diferencia es que HEDL está dirigido a flujos de trabajo estructurados orientados a LLM donde la depurabilidad humana, la conversión y la compatibilidad con herramientas siguen importando. No es un blob binario lanzado por encima de un muro con una nota que dice buena suerte.
La implementación de HEDL incluye soporte de biblioteca en Rust, uso desde la línea de comandos, superficies de servidor MCP y proxy, WASM, FFI y enlaces, además de conversión hacia y desde formatos comunes. Esa combinación es importante. Un formato para flujos de trabajo de IA no puede ser solo compacto. Tiene que entrar y salir del mundo real sin convertirse en un culto privado. Las APIs existentes siguen queriendo JSON. La gente sigue inspeccionando datos. Las herramientas siguen necesitando idas y vueltas. El formato tiene que ser denso sin volverse antisocial.
La estructura como contrato
La mayoría de los fallos de IA con datos estructurados no son dramáticos. Son mezquinos, lo que hace más difícil respetarlos hasta que cuestan dinero de verdad. Un campo se desvía. Un valor se coloca bajo la clave equivocada. Un modelo emite un objeto plausible al que le falta un campo opcional. Un analizador acepta una forma que debería haber rechazado. Una herramienta posterior recibe casi lo correcto, el tipo de cosa más peligrosa en el software.
El enfoque de HEDL basado en esquemas es útil porque hace explícita la estructura antes de que los registros empiecen a moverse. El esquema no es una sugerencia suelta en un prompt. Es lo que le dice al lector cómo interpretar los valores. El registro es compacto porque no necesita narrarse a sí mismo repetidamente. Las herramientas circundantes aún pueden validar, convertir y entregar datos a sistemas que prefieren JSON, YAML, XML, CSV u otras formas convencionales.
Los viajes de ida y vuelta son la prueba de si un formato es útil o meramente ingenioso. Si entra JSON, HEDL se mueve por el flujo de trabajo y sale JSON con la misma semántica, el sistema gana densidad sin perder compatibilidad. Si el significado se pierde en silencio, el formato ha fallado. El comportamiento correcto bajo presión no es encogerse de hombros y pasar el objeto corriente abajo. Es bloquear, informar y forzar la ambigüedad a la luz.
Aquí es donde HEDL encaja bien junto al resto del stack de Dweve. Ledger se preocupa de que los eventos operativos sigan siendo inspeccionables. AION se preocupa de que las pruebas de decisión puedan verificarse. Trace se preocupa de que la computación pueda reproducirse. HEDL se preocupa de que los datos estructurados puedan representarse densamente y restaurarse exactamente. Estos trabajos se tocan, pero no son el mismo trabajo. Otra vez: menos palabras de sopa tibia, más límites útiles.
El benchmark no es decoración
Las afirmaciones de rendimiento en torno a la infraestructura de IA a menudo se escriben como historias de pesca. El número crece cada vez que se vuelve a contar. HEDL tiene una afirmación de benchmark concreta: 571 tareas de extracción estructurada en siete conjuntos de datos, 56 por ciento menos tokens que JSON y una mejora de precisión de 10,3 puntos porcentuales sobre JSON.
Esos números deben leerse como una afirmación de benchmark, no como una ley universal de la física. Describen una configuración de benchmark. No significan que cada flujo de trabajo obtenga mágicamente el mismo resultado. Pero sí explican por qué existe el formato. El recuento de tokens no es una nota a pie de página de implementación en los sistemas de LLM. Es parte de la interfaz. Si dos representaciones transmiten el mismo significado y una quema mucho más contexto, la más pesada no es neutral.
La mejora en precisión resulta especialmente interesante. Sugiere que el beneficio no es solo tener indicaciones más baratas. Una representación más limpia también puede facilitar la tarea al modelo. Eso no debería sorprender. Si el modelo dedica menos atención a la repetición de ruido sintáctico, tiene más espacio para valores y relaciones. Esta es la misma razón por la que los buenos formularios superan a los desordenados en el trabajo humano. El humano puede ser inteligente, pero no le entregues un formulario de impuestos escrito por una impresora que tuvo una infancia difícil.
Aquí hay una lección de diseño más amplia. Las interfaces de IA no deberían juzgarse solo por si el modelo puede arreglárselas. Los modelos pueden arreglárselas con muchas interfaces malas. Las personas también pueden subir muebles por escaleras con mal agarre y sin plan. Eso no lo convierte en arquitectura. Una buena interfaz de IA reduce el trabajo evitable, expone la estructura, preserva el significado y falla de forma ruidosa cuando la estructura es incorrecta.
Por qué importan las superficies proxy
Un formato rara vez gana por ser puro. Gana por encajar en el incómodo término medio. Las superficies MCP y proxy de HEDL importan porque la mayoría de las organizaciones no pueden simplemente anunciar que todo ahora habla una nueva representación. Tienen APIs existentes, almacenes de datos, reglas de validación, paneles, cuadernos y formatos de exportación. Reemplazar todo eso para ahorrar tokens sería una forma heroica de perder amigos.
El patrón proxy es más práctico. Permite que los modelos y las herramientas se beneficien de una representación estructurada densa donde importa. Convierte en el límite. Valida antes de que los datos salgan de la ruta controlada. Mantén la compatibilidad JSON posterior. Permite que los sistemas que esperan JSON reciban JSON, pero deja de obligar al modelo a arrastrar la forma JSON completa a través de cada paso interno.
Aquí es también donde entra la gobernanza, de forma silenciosa y útil. Si el proxy valida la estructura, puede rechazar objetos malformados antes de que se conviertan en hechos de negocio. Si preserva un viaje de ida y vuelta sin pérdidas, puede demostrar que la conversión no cambió el significado. Si mantiene la compatibilidad con los sistemas existentes, se puede adoptar sin convertir cada integración en un programa de migración. Somos europeos. Ya tenemos suficientes programas de migración. Algunos todavía tienen comités directivos de 2014.
Para los sistemas de agentes, el proxy es aún más importante. Los agentes pasan llamadas y resultados estructurados a través de los límites. Llaman a herramientas, reciben resultados, actualizan la memoria, producen artefactos y entregan el estado a otros agentes. Una representación densa con validación hace que estos traspasos sean menos derrochadores y menos ambiguos. No hace sabio al agente. Hace el sobre menos estúpido. Ese es un resultado de ingeniería respetable.
Dónde no se debe usar HEDL
Toda herramienta útil tiene un lugar donde no debería usarse. HEDL no es un reemplazo para cada archivo JSON en la tierra. Si un archivo de configuración pequeño es leído una vez por un humano y editado dos veces al año, JSON o TOML sobrevivirán a la tragedia. Si una API pública necesita máxima familiaridad y las cargas útiles son diminutas, JSON está bien. Si el esquema es genuinamente desconocido y ad hoc, la codificación de esquema una vez no es la suposición inicial correcta.
HEDL se vuelve interesante cuando la estructura se repite, los volúmenes son significativos, el contexto del modelo es caro, los viajes de ida y vuelta importan y las herramientas necesitan compatibilidad en los bordes. Es por eso que los flujos de trabajo LLM encajan tan bien. Se sitúan precisamente en la intersección de la intención estructurada y la economía de tokens. También tienden a crecer de prototipo a producción más rápido de lo que nadie planeó, porque aparentemente nadie ha aprendido esta lección a pesar de que toda la historia del software parece levemente ofendida en la esquina.
La vía de adopción práctica debe ser, por tanto, estrecha. No reescriba la organización. Elija un flujo de trabajo de extracción estructurada. Elija una ruta de llamada a herramientas del agente. Elija un límite de proxy MCP. Mida el uso de tokens, la tasa de fallos, los resultados de validación y la fidelidad de ida y vuelta. Si las cifras se mantienen, amplíe. Si no, quédese con lo aburrido. El objetivo no es adorar un formato. El objetivo es dejar de pagar por estructura evitable.
La lección
La lección de HEDL es que la estructura no es gratis solo porque sea útil. En el software ordinario, las claves repetidas son sobre todo una molestia. En los flujos de trabajo de IA, son contexto, dinero, atención y superficie de fallo. Si se conoce el esquema, repetirlo en cada registro suele ser la opción menos imaginativa disponible.
HEDL hace un intercambio sencillo: declarar la estructura una vez, codificar los registros de forma densa, preservar la semántica, convertir de vuelta cuando sea necesario y validar en el límite del proxy. No sustituye a JSON como lenguaje común de la web. Es un sobre interno mejor para el trabajo estructurado de IA, donde el modelo debería gastar su contexto en el significado, no en leer los mismos nombres de campo hasta la muerte térmica del presupuesto.
Ese es el estándar útil para la infraestructura de IA. No es ingenio por el ingenio. No es un impuesto a la novedad. No es un formato que obligue a todos los demás a sufrir. Una buena capa elimina el desperdicio, mantiene el contrato explícito y deja que el resto del sistema siga funcionando. HEDL se gana su lugar cuando el objeto se hace más pequeño sin que el significado se vuelva más difuso.
JSON puede quedarse. No ha hecho nada malo. Incluso puede tomarse un café. Simplemente no necesita estar dentro de cada llamada al modelo cargando el mismo conjunto de claves como un hombre que se muda con una cuchara cada vez.