HEDL ir struktūriniai duomenys be JSON išpūtimo
Sąskaita, pasislėpusi jūsų skliausteliuose
JSON laimėjo, nes yra nuobodus lygiai taip, kaip reikia. Žmonės gali jį perskaityti. Mašinos gali jį išanalizuoti. Kiekviena kalba turi jam biblioteką. Jei dvi sistemos turi apsikeisti objektu ir niekas nenori standartų susirinkimo, JSON paprastai yra vieta, kur pokalbis baigiasi. Gerai. Yra blogesnių kompromisų. Daugelis jų pavadinime turi žodį enterprise.
Problema ne JSON kaip žiniatinklio formatas. Problema yra tai, kas nutinka, kai įstumiame JSON į kalbos modelių darbo eigas ir apsimetame, kad kaina yra nemokama. Modelis nemato tvarkingo objekto taip, kaip jį mato programos analizatorius. Jis mato žetonus. Jis vėl ir vėl skaito tuos pačius raktus. Jis eikvoja kontekstą skyrybai, pasikartojantiems laukų pavadinimams, įvyniokliams, įdėtiems pastoliams ir formos priminimams, kurie buvo žinomi dar prieš atkeliaujant pirmam įrašui.
Tos atliekos anksčiau buvo šiek tiek erzinančios. Su dirbtinio intelekto sistemomis tai tampa produkto problema. Kiekvienas pasikartojantis raktas konkuruoja su įrodymais, instrukcijomis, pavyzdžiais, citatomis ir tikru vartotojo turiniu. Kiekvienas perteklinis struktūros žetonas yra mažas mokestis už naudingą darbą. Sąskaita nesako nereikalingi skliausteliai, nes sąskaitos neturi poezijos. Ji sako žetonai.
HEDL prasideda nuo paprasto pastebėjimo: kai schema yra žinoma, kartoti schemą kiekviename įraše yra kvaila. Paskelbkite struktūrą vieną kartą. Užkoduokite įrašus poziciškai. Išlaikykite semantiką tikslią. Konvertuokite atgal į formatus, kurių jau tikisi esamos sistemos. Tai ne anti-JSON ideologija. Tai atsisakymas mokėti modeliui, kad jis kas dešimt metrų perskaitytų tą patį kelio ženklą.
Tai svarbu, nes struktūrizuotas dirbtinio intelekto darbas nėra tik pokalbis. Tai duomenų išgavimas, klasifikavimas, įrankių iškvietimai, duomenų transformavimas, peržiūros paketai, įrodymų rinkiniai, MCP iškvietimai, darbo eigos ir agentai, visą dieną perduodantys vieni kitiems objektus. Kuo rimtesnė sistema, tuo daugiau struktūros jai reikia. Jei struktūra išreiškiama kuo išsamesniu būdu, sistema moka už savo paties discipliną.
JSON nėra piktadarys
Būtų lengva ir tinginiauti rašyti tai kaip skundą dėl JSON. JSON turi realių pranašumų. Jis yra visur paplitęs, lengvai derinamas, lengvai perduodamas per esamus įrankius ir pakankamai geras didžiulei daliai programų darbo. Esmė ne ta, kad JSON yra blogas. Esmė ta, kad JSON dažnai naudojamas ten, kur gaunančioji pusė jau žino formą, ir ten pasikartojimas nustoja būti aiškumu ir tampa našta.
Apsvarstykite struktūrizuoto duomenų išgavimo užduotį. Schema sako, kad kiekvienas atsakymas turi pavadinimą, šaltinį, reikšmę, pasitikėjimo lygį ir pagrindimą. Dabar įsivaizduokite, kad siunčiate modeliui šimtus eilučių arba gaunate iš jo šimtus eilučių atgal. JSON kartoja tuos laukų pavadinimus kiekvienam objektui. Programos analizatorius tam neprieštarauja. Modelio kontekstas prieštarauja. Konteksto langas tampa pristatymo furgonu, pilnu etikečių, o ne prekių.
HEDL traktuoja schemą kaip susitarimą. Jis įvardija laukus ir tipus vieną kartą. Tada įrašai neša reikšmes eilės tvarka. Tai skamba akivaizdžiai, nes taip ir yra. Daugelis efektyvių formatų dešimtmečius darė panašius kompromisus. Skirtumas tas, kad HEDL yra skirtas į kalbos modelius orientuotoms struktūrizuotoms darbo eigoms, kuriose žmogaus derinamumas, konversija ir įrankių suderinamumas vis dar svarbūs. Tai ne dvejetainis failas, permestas per sieną su rašteliu „sėkmės“.
HEDL diegimas apima Rust bibliotekos palaikymą, CLI naudojimą, MCP serverio ir tarpinio serverio sąsajas, WASM, FFI ir susiejimus, taip pat konversiją į įprastus formatus ir iš jų. Šis derinys yra svarbus. AI darbo eigų formatas negali būti tik kompaktiškas. Jis turi įeiti į sudėtingą pasaulį ir iš jo išeiti netapdamas privačiu kultu. Esamos API vis dar nori JSON. Žmonės vis dar tikrina duomenis. Įrankiams vis dar reikia apvaliųjų kelionių. Formatas turi būti tankus, bet neatsiribojantis.
Struktūra kaip sutartis
Dauguma AI nesėkmių, susijusių su struktūriniais duomenimis, nėra dramatiškos. Jos yra smulkmeniškos, todėl į jas sunkiau atsižvelgti, kol jos nekainuoja tikrų pinigų. Laukas nukrypsta. Reikšmė įdedama po neteisingu raktu. Modelis pateikia tikėtiną objektą su trūkstamu pasirenkamu lauku. Analizatorius priima formą, kurią turėjo atmesti. Tolesnis įrankis gauna beveik teisingą dalyką, pavojingiausią dalyką programinėje įrangoje.
HEDL schema-pirmas metodas yra naudingas, nes jis padaro struktūrą aiškią prieš pradedant judėti įrašams. Schema nėra laisvas raginimas. Tai dalykas, kuris pasako skaitytojui, kaip interpretuoti reikšmes. Įrašas yra kompaktiškas, nes jam nereikia nuolat pasakoti apie save. Aplinkinė įranga vis tiek gali patikrinti, konvertuoti ir perduoti duomenis sistemoms, kurios teikia pirmenybę JSON, YAML, XML, CSV ar kitoms įprastoms formoms.
Apvaliosios kelionės yra testas, ar formatas yra naudingas, ar tik sumanus. Jei JSON įeina, HEDL juda per darbo eigą, o JSON išeina su ta pačia semantika, sistema įgyja tankumą neprarasdama suderinamumo. Jei prasmė tyliai prarandama, formatas žlugo. Teisingas elgesys spaudžiant nėra gūžčioti pečiais ir perduoti objektą toliau. Tai blokuoti, pranešti ir priversti dviprasmybę iškilti į paviršių.
Čia HEDL puikiai dera šalia likusios Dweve krūvos. Ledger rūpinasi, kad operaciniai įvykiai liktų patikrinami. AION rūpinasi, kad sprendimų įrodymus būtų galima patikrinti. Trace rūpinasi, kad skaičiavimus būtų galima atkurti. HEDL rūpinasi, kad struktūriniai duomenys galėtų būti pateikiami tankiai ir atkuriami tiksliai. Šios užduotys liečiasi, bet jos nėra ta pati užduotis. Vėlgi: mažiau šiltos sriubos žodžių, daugiau naudingų ribų.
Etalonas nėra puošmena
Veikimo teiginiai apie AI infrastruktūrą dažnai rašomi kaip žvejybos istorijos. Skaičius didėja kiekvieną kartą, kai jis perpasakojamas. HEDL turi konkretų etalono teiginį: 571 struktūrizuotos ištraukimo užduotys per septynis duomenų rinkinius, 56 procentais mažiau žetonų nei JSON ir 10,3 procentinio punkto tikslumo padidėjimas, palyginti su JSON.
Tuos skaičius reikia skaityti kaip etalono teiginį, o ne kaip visuotinį fizikos dėsnį. Jie apibūdina etalono sąranką. Jie nereiškia, kad kiekviena darbo eiga stebuklingai gauna tą patį rezultatą. Bet jie paaiškina, kodėl formatas egzistuoja. Žetonų skaičius nėra įgyvendinimo išnaša LLM sistemose. Tai yra sąsajos dalis. Jei dvi reprezentacijos turi tą pačią reikšmę ir viena sudegina kur kas daugiau konteksto, sunkesnė nėra neutrali.
The accuracy gain is especially interesting. It suggests the benefit is not only cheaper prompts. A cleaner representation can also make the task easier for the model. That should not be surprising. If the model spends less attention on repeated syntactic clutter, it has more room for values and relations. This is the same reason good forms beat messy forms in human work. The human may be smart, but do not hand them a tax form written by a printer having a difficult childhood.
There is a broader design lesson here. AI interfaces should not be judged only by whether the model can cope. Models can cope with many bad interfaces. People can also carry furniture up stairs with poor grip and no plan. That does not make it architecture. A good AI interface reduces avoidable work, exposes structure, preserves meaning, and fails loudly when the structure is wrong.
Why proxy surfaces matter
A format rarely wins by being pure. It wins by fitting the ugly middle. HEDL's MCP and proxysurfaces matter because most organisations cannot simply announce that everything now speaks a new representation. They have existing APIs, data stores, validation rules, dashboards, notebooks, and export formats. Replacing all of that to save tokens would be aheroic way to lose friends.
The proxy pattern is more practical. Let models and tools benefit from dense structured representation where it matters. Convert at the boundary. Validate before data leaves the controlled path. Keep downstream JSON compatibility. Let systems that expect JSON receive JSON, but stop forcing the model to haul the full JSON shape through every internal step.
This is also where governance enters, quietly and usefully. If the proxy validates structure, it can reject malformed objects before they become business facts. If it preserves a lossless round trip, it can prove that conversion did not change the meaning. If it keeps compatibility with existingsystems, it can be adopted without turning every integration into a migration programme. We are European. We have enough migration programmes. Some of them still have steering committees from 2014.
For agent systems, the proxy is even more important. Agents pass structured calls and results across boundaries. They call tools, receive outputs, update memory, produce artifacts, and hand state to other agents. A dense representation with validation keeps those handoffs less wasteful and less ambiguous. It does not make the agent wise. It makes the envelope less stupid. That is a respectable engineering outcome.
Where HEDL should not be used
Every useful tool has a place where it should not be used. HEDL is not a replacement for every JSON file on earth. If asmall config file is read once by a human and edited twice a year, JSON or TOML will survive the tragedy. If a public API needs maximum familiarity and the payloads are tiny, JSON is fine. If the schema is genuinely unknown and ad hoc, schema-once encoding is not the right starting assumption.
HEDL becomes interesting when structure is repeated, volumes are meaningful, model context is expensive, round trips matter, and tools need compatibility at the edges. That is why LLM workflows are such a good fit. They sit precisely at the intersection of structured intent and token economics. They also tend to grow from prototype to production faster than anyone planned, because apparently nobody has learned this lesson despite the entire history of software looking mildly offended in the corner.
The practical adoption path should therefore be narrow. Do not rewrite the organisation. Pick a structured extraction workflow. Pick an agent tool-call path. Pick an MCP proxy boundary. Measure token use, failure rate, validation outcomes, and round-trip fidelity. If the numbers hold, expand. If they do not, keep the boring thing. The goal is not to worship a format. The goal is to stop paying for avoidable structure.
The lesson
The lesson of HEDL is that structure is not free just because it is useful. In ordinary software, repeated keys are mostly an annoyance. In AI workflows, they are context, money, attention, and failure surface. If the schema is known, repeating it in every record is often the least imaginative option available.
HEDL makes a simple trade: declare structure once, encode records densely, preserve semantics, convert back when needed, and validate at the proxy boundary. It is not a replacement for JSON as the common language of the web. It is a better internal envelope for structured AI work where the model should be spending its context on meaning, not on reading the same field names until the heat death of the budget.
That is the useful standard for AI infrastructure. Not cleverness for its own sake. Not novelty tax.Not a format that requires everyone else to suffer. A good layer removes waste, keeps the contract explicit, and lets the rest of the system keep working. HEDL earns its place when the object becomes smaller without the meaning becoming softer.
JSON can stay. It has done nothing wrong. It can even have a cup of coffee. It just does not need to sit inside every model call carrying the same set of keys like a man moving house one spoon at a time.