HEDL e dati strutturati senza gonfiore JSON
La fattura nascosta nelle tue parentesi graffe
JSON ha vinto perché è noioso esattamente nel modo giusto. Gli esseri umani possono leggerlo. Le macchine possono analizzarlo. Ogni linguaggio ha una libreria per esso. Se due sistemi devono scambiare un oggetto e nessuno vuole una riunione sugli standard, JSON è di solito il punto in cui la conversazione finisce. Va bene. Ci sono compromessi peggiori. Molti hanno "enterprise" nel nome.
Il problema non è JSON come formato web. Il problema è ciò che accade quando spingiamo JSON nei flussi di lavoro dei modelli linguistici e fingiamo che il costo sia gratuito. Un modello non vede un oggetto ordinato nel modo in cui lo vede un parser applicativo. Vede token. Legge le stesse chiavi ancora e ancora. Spende contesto per punteggiatura, nomi di campi ripetuti, wrapper, impalcature annidate e promemoria di forma che erano già noti prima dell'arrivo del primo record.
Questo spreco una volta era leggermente irritante. Con i sistemi di IA, diventa un problema di prodotto. Ogni chiave ripetuta compete con prove, istruzioni, esempi, citazioni e contenuto utente reale. Ogni token strutturale ridondante è una piccola tassa sul lavoro utile. La fattura non dice "parentesi graffe superflue", perché le fatture mancano di poesia. Dice "token".
HEDL parte da un'osservazione semplice: quando lo schema è noto, ripetere lo schema dentro ogni record è sciocco. Dichiara la struttura una volta. Codifica i record in modo posizionale. Mantieni la semantica esatta. Converti di nuovo nei formati che i sistemi esistenti già si aspettano. Questa non è ideologia anti-JSON. È un rifiuto di pagare il modello per rileggere lo stesso cartello stradale ogni dieci metri.
Questo è importante perché il lavoro strutturato con l'IA non è solo chat. È estrazione, classificazione, chiamate a strumenti, trasformazione di dati, pacchetti di revisione, fasci di prove, chiamate MCP, flussi di lavoro e agenti che si passano oggetti tutto il giorno. Più il sistema diventa serio, più struttura richiede. Se la struttura è espressa nel modo più verboso possibile, il sistema paga per la propria disciplina.
JSON non è il cattivo
Sarebbe facile, e pigro, scrivere questo come una lamentela su JSON. JSON ha punti di forza reali. È onnipresente, debuggabile, facile da convogliare attraverso gli strumenti esistenti e abbastanza buono per una grande quantità di lavoro applicativo. Il punto non è che JSON sia cattivo. Il punto è che JSON è spesso usato in luoghi dove il lato ricevente conosce già la forma, e lì la ripetizione smette di essere chiarezza e inizia a essere zavorra.
Considera un compito di estrazione strutturata. Lo schema dice che ogni risposta ha un nome, una fonte, un valore, una confidenza e una motivazione. Ora immagina di inviare centinaia di righe a un modello o di riceverne centinaia indietro. JSON ripete quei nomi di campo per ogni oggetto. Il parser applicativo non se ne cura. Il contesto del modello sì. La finestra di contesto diventa un furgone pieno di etichette invece che di merci.
HEDL tratta lo schema come un contratto. Nomina i campi e i tipi una volta. I record poi trasportano i valori in ordine. Sembra ovvio perché lo è. Molti formati efficienti hanno fatto compromessi simili per decenni. La differenza è che HEDL è pensato per flussi di lavoro strutturati orientati agli LLM dove la debuggabilità umana, la conversione e la compatibilità con gli strumenti contano ancora. Non è un blob binario lanciato oltre un muro con un biglietto che dice "in bocca al lupo".
L'implementazione di HEDL include il supporto della libreria Rust, l'uso da riga di comando, il server MCP e le superfici proxy, WASM, FFI e bindings, oltre alla conversione da e verso i formati comuni. Questa combinazione è importante. Un formato per i flussi di lavoro dell'IA non può essere solo compatto. Deve entrare e uscire dal mondo reale senza diventare un culto privato. Le API esistenti vogliono ancora JSON. Le persone ispezionano ancora i dati. Gli strumenti hanno ancora bisogno di viaggi di andata e ritorno. Il formato deve essere denso senza diventare antisociale.
La struttura come contratto
La maggior parte dei fallimenti dell'IA con i dati strutturati non è drammatica. Sono meschini, il che li rende più difficili da prendere sul serio finché non costano denaro reale. Un campo devia. Un valore viene inserito sotto la chiave sbagliata. Un modello emette un oggetto plausibile con un campo opzionale mancante. Un parser accetta una forma che avrebbe dovuto rifiutare. Uno strumento a valle riceve quasi la cosa giusta, il tipo di cosa più pericoloso nel software.
L'approccio schema-first di HEDL è utile perché rende la struttura esplicita prima che i record inizino a muoversi. Lo schema non è un vago suggerimento di prompt. È la cosa che dice al lettore come interpretare i valori. Il record è compatto perché non ha bisogno di raccontarsi ripetutamente. Il tooling circostante può comunque validare, convertire e passare i dati a sistemi che preferiscono JSON, YAML, XML, CSV o altre forme convenzionali.
I viaggi di andata e ritorno sono il test per capire se un formato è utile o solo ingegnoso. Se il JSON entra, HEDL si muove attraverso il flusso di lavoro e il JSON esce con la stessa semantica, il sistema guadagna densità senza perdere compatibilità. Se il significato viene perso in silenzio, il formato ha fallito. Il comportamento giusto sotto pressione non è alzare le spalle e passare l'oggetto a valle. È bloccare, segnalare e forzare l'ambiguità allo scoperto.
È qui che HEDL si colloca bene accanto al resto dello stack Dweve. Ledger si preoccupa che gli eventi operativi rimangano ispezionabili. AION si preoccupa che le prove delle decisioni possano essere verificate. Trace si preoccupa che il calcolo possa essere riprodotto. HEDL si preoccupa che i dati strutturati possano essere rappresentati in modo denso e ripristinati esattamente. Questi compiti si toccano, ma non sono lo stesso compito. Ancora una volta: meno parole vaghe, più confini utili.
Il benchmark non è decorazione
Le affermazioni sulle prestazioni nell'infrastruttura dell'IA sono spesso scritte come storie di pesca. Il numero diventa più grande ogni volta che viene raccontato. HEDL ha un'affermazione di benchmark concreta: 571 attività di estrazione strutturata su sette dataset, 56 percento in meno di token rispetto a JSON e un guadagno di accuratezza di 10,3 punti percentuali rispetto a JSON.
Quei numeri dovrebbero essere letti come un'affermazione di benchmark, non come una legge universale della fisica. Descrivono una configurazione di benchmark. Non significano che ogni flusso di lavoro ottenga magicamente lo stesso risultato. Ma spiegano perché il formato esiste. Il conteggio dei token non è una nota a piè di pagina nell'implementazione dei sistemi LLM. È parte dell'interfaccia. Se due rappresentazioni portano lo stesso significato e una brucia molto più contesto, quella più pesante non è neutrale.
Il guadagno in accuratezza è particolarmente interessante. Suggerisce che il beneficio non sia solo quello di prompt più economici. Una rappresentazione più pulita può anche rendere il compito più facile per il modello. Non dovrebbe sorprendere. Se il modello dedica meno attenzione a ripetuti ingombri sintattici, ha più spazio per valori e relazioni. È lo stesso motivo per cui nei lavori umani i moduli ben fatti battono quelli disordinati. L'essere umano può anche essere intelligente, ma non consegnategli un modulo fiscale scritto da una stampante che ha avuto un'infanzia difficile.
C'è qui una lezione di design più ampia. Le interfacce AI non dovrebbero essere giudicate solo in base alla capacità del modello di farcela. I modelli possono farcela con molte interfacce pessime. Le persone possono anche portare mobili su per le scale con una presa debole e senza un piano. Questo non lo rende architettura. Una buona interfaccia AI riduce il lavoro evitabile, espone la struttura, preserva il significato e fallisce in modo rumoroso quando la struttura è sbagliata.
Perché le superfici proxy contano
Un formato raramente vince essendo puro. Vince adattandosi al brutto mezzo. Le superfici MCP e proxy di HEDL contano perché la maggior parte delle organizzazioni non può semplicemente annunciare che tutto ora parla una nuova rappresentazione. Hanno API esistenti, archivi di dati, regole di validazione, dashboard, notebook e formati di esportazione. Sostituire tutto questo per risparmiare token sarebbe un modo eroico di farsi dei nemici.
Il pattern proxy è più pratico. Lascia che modelli e strumenti traggano beneficio da una rappresentazione strutturata e densa dove conta. Converti al confine. Valida prima che i dati lascino il percorso controllato. Mantieni la compatibilità JSON a valle. Lascia che i sistemi che si aspettano JSON ricevano JSON, ma smetti di costringere il modello a trascinare l'intera forma JSON attraverso ogni passaggio interno.
È anche qui che entra in gioco la governance, in modo silenzioso e utile. Se il proxy valida la struttura, può rifiutare oggetti malformati prima che diventino fatti aziendali. Se preserva un round trip senza perdite, può dimostrare che la conversione non ha cambiato il significato. Se mantiene la compatibilità con i sistemi esistenti, può essere adottato senza trasformare ogni integrazione in un programma di migrazione. Siamo europei. Abbiamo abbastanza programmi di migrazione. Alcuni hanno ancora comitati direttivi del 2014.
Per i sistemi agente, il proxy è ancora più importante. Gli agenti passano chiamate e risultati strutturati attraverso i confini. Chiamano strumenti, ricevono output, aggiornano la memoria, producono artefatti e passano lo stato ad altri agenti. Una rappresentazione densa con validazione rende questi passaggi di mano meno dispendiosi e meno ambigui. Non rende l'agente saggio. Rende la busta meno stupida. È un risultato ingegneristico rispettabile.
Dove HEDL non dovrebbe essere usato
Ogni strumento utile ha un posto dove non dovrebbe essere usato. HEDL non è un sostituto per ogni file JSON sulla terra. Se un piccolo file di configurazione viene letto una volta da un essere umano e modificato due volte l'anno, JSON o TOML sopravvivranno alla tragedia. Se un'API pubblica ha bisogno della massima familiarità e i payload sono minuscoli, JSON va bene. Se lo schema è genuinamente sconosciuto e ad hoc, la codifica schema-once non è l'assunto di partenza giusto.
HEDL diventa interessante quando la struttura è ripetuta, i volumi sono significativi, il contesto del modello è costoso, i round trip contano e gli strumenti hanno bisogno di compatibilità ai bordi. È per questo che i flussi di lavoro LLM sono una scelta così azzeccata. Si trovano esattamente all'intersezione tra intento strutturato ed economia dei token. Tendono anche a crescere dal prototipo alla produzione più velocemente di quanto chiunque avesse pianificato, perché a quanto pare nessuno ha imparato questa lezione nonostante l'intera storia del software che guarda leggermente offeso dall'angolo.
Il percorso di adozione pratica dovrebbe quindi essere ristretto. Non riscrivere l'organizzazione. Scegli un flusso di lavoro di estrazione strutturata. Scegli un percorso di chiamata agli strumenti dell'agente. Scegli un confine proxy MCP. Misura l'uso dei token, il tasso di errore, i risultati di validazione e la fedeltà del round-trip. Se i numeri reggono, espandi. Se non reggono, tieni la cosa noiosa. L'obiettivo non è venerare un formato. L'obiettivo è smettere di pagare per una struttura evitabile.
La lezione
La lezione di HEDL è che la struttura non è gratuita solo perché è utile. Nel software ordinario, le chiavi ripetute sono per lo più una seccatura. Nei flussi di lavoro AI, sono contesto, denaro, attenzione e superficie di errore. Se lo schema è noto, ripeterlo in ogni record è spesso l'opzione meno fantasiosa disponibile.
HEDL fa un semplice scambio: dichiara la struttura una volta, codifica i record in modo denso, preserva la semantica, riconverti quando serve e valida al confine del proxy. Non è un sostituto di JSON come linguaggio comune del web. È una busta interna migliore per il lavoro AI strutturato, dove il modello dovrebbe spendere il suo contesto sul significato, non sulla lettura degli stessi nomi di campo fino alla morte termica del budget.
Questo è lo standard utile per l'infrastruttura AI. Non l'ingegno fine a se stesso. Non la tassa della novità. Non un formato che richiede a tutti gli altri di soffrire. Un buon livello rimuove gli sprechi, mantiene esplicito il contratto e lascia che il resto del sistema continui a funzionare. HEDL si guadagna il suo posto quando l'oggetto diventa più piccolo senza che il significato diventi più vago.
JSON può restare. Non ha fatto nulla di male. Può anche prendersi un caffè. Solo che non deve sedersi dentro ogni chiamata del modello portando lo stesso set di chiavi, come un uomo che trasloca portando un cucchiaio alla volta.