HEDL и структурирани данни без JSON раздуване
Фактурата, скрита във вашите скоби
JSON спечели, защото е скучен точно по правилния начин. Хората могат да го четат. Машините могат да го анализират. Всеки език има библиотека за него. Ако две системи трябва да обменят обект и никой не иска среща за стандарти, JSON обикновено е мястото, където разговорът приключва. Добре. Има и по-лоши компромиси. Много от тях имат „enterprise“ в името си.
Проблемът не е JSON като уеб формат. Проблемът е какво се случва, когато го вкараме в работни потоци с езикови модели и се преструваме, че цената е безплатна. Моделът не вижда подреден обект така, както го вижда парсерът на приложение. Той вижда токени. Чете едни и същи ключове отново и отново. Изразходва контекст за пунктуация, повтарящи се имена на полета, обвивки, вложени структури и напомняния за формата, които са били известни още преди първия запис да пристигне.
Това разхищение някога беше леко дразнещо. При AI системите то се превръща в продуктов проблем. Всеки повторен ключ се конкурира с доказателства, инструкции, примери, цитати и реално потребителско съдържание. Всеки излишен структурен токен е малък данък върху полезната работа. Фактурата не казва „ненужни скоби“, защото на фактурите им липсва поезия. Тя казва „токени“.
HEDL започва от едно просто наблюдение: когато схемата е известна, повтарянето ѝ във всеки запис е глупаво. Декларирайте структурата веднъж. Кодирайте записите позиционно. Запазете семантиката точна. Конвертирайте обратно към форматите, които съществуващите системи вече очакват. Това не е анти-JSON идеология. Това е отказ да плащаме на модела, за да препрочита един и същ пътен знак на всеки десет метра.
Това има значение, защото структурираната AI работа не е просто чат. Тя включва извличане, класификация, извиквания на инструменти, трансформация на данни, пакети за преглед, снопове от доказателства, MCP повиквания, работни потоци и агенти, които си предават обекти по цял ден. Колкото по-сериозна става системата, толкова повече структура ѝ трябва. Ако структурата е изразена по възможно най-многословния начин, системата плаща за собствената си дисциплина.
JSON не е злодеят
Би било лесно и мързеливо да напишем това като оплакване от JSON. JSON има реални силни страни. Той е повсеместен, лесен за отстраняване на грешки, лесен за прекарване през съществуващи инструменти и е достатъчно добър за огромно количество приложна работа. Въпросът не е, че JSON е лош. Въпросът е, че JSON често се използва на места, където приемащата страна вече знае формата, и там повторението престава да бъде яснота и започва да бъде баласт.
Помислете за задача за структурирано извличане. Схемата казва, че всеки отговор има име, източник, стойност, увереност и обосновка. Сега си представете, че изпращате стотици редове на модел или получавате стотици редове обратно от него. JSON повтаря тези имена на полета за всеки обект. Парсерът на приложението не възразява. Контекстът на модела възразява. Прозорецът на контекста се превръща в камион за доставка, пълен с етикети, вместо със стоки.
HEDL третира схемата като договор. Той именува полетата и типовете веднъж. След това записите носят стойностите в ред. Това звучи очевидно, защото е очевидно. Много ефективни формати са правили подобни компромиси от десетилетия. Разликата е, че HEDL е насочен към структурирани работни потоци, ориентирани към LLM, където човешката възможност за отстраняване на грешки, конвертирането и съвместимостта с инструменти все още имат значение. Той не е двоичен блок, хвърлен през стена с бележка „успех“.
Реализацията на HEDL включва поддръжка на Rust библиотека, CLI употреба, MCP сървър и прокси повърхности, WASM, FFI и обвързвания, както и преобразуване към и от често срещани формати. Тази комбинация е важна. Един формат за AI работни потоци не може да бъде само компактен. Той трябва да навлиза и да излиза от сложния реален свят, без да се превръща в частен култ. Съществуващите API-та все още искат JSON. Хората все още проверяват данни. Инструментите все още се нуждаят от двупосочни преобразувания. Форматът трябва да е плътен, без да става необщителен.
Структурата като договор
Повечето AI провали около структурирани данни не са драматични. Те са дребнави, което ги прави по-трудни за уважение, докато не струват реални пари. Едно поле се отклонява. Стойност се поставя под грешен ключ. Моделът генерира правдоподобен обект с липсващо незадължително поле. Парсерът приема форма, която е трябвало да отхвърли. Инструмент надолу по веригата получава почти правилното нещо, най-опасния вид нещо в софтуера.
Подходът на HEDL, ориентиран към схемата, е полезен, защото прави структурата изрична, преди записите да започнат да се движат. Схемата не е свободно предложение в подкана. Тя е нещото, което казва на читателя как да интерпретира стойностите. Записът е компактен, защото не трябва да се описва многократно. Околните инструменти все още могат да валидират, преобразуват и подават данни на системи, които предпочитат JSON, YAML, XML, CSV или други конвенционални форми.
Двупосочните преобразувания са тестът дали един формат е полезен или просто умен. Ако JSON влезе, HEDL премине през работния поток и JSON излезе със същата семантика, системата печели плътност, без да губи съвместимост. Ако смисълът се загуби мълчаливо, форматът се е провалил. Правилното поведение под напрежение не е да свиеш рамене и да предадеш обекта надолу по веригата. То е да блокираш, да докладваш и да изведеш двусмислието наяве.
Тук HEDL стои добре до останалата част от стека Dweve. Ledger се грижи оперативните събития да останат проверими. AION се грижи доказателствата за решения да могат да бъдат проверявани. Trace се грижи изчисленията да могат да бъдат възпроизвеждани. HEDL се грижи структурираните данни да могат да бъдат представени плътно и възстановени точно. Тези задачи се докосват, но не са една и съща задача. Отново: по-малко размити думи, повече полезни граници.
Бенчмаркът не е декорация
Твърденията за производителност около AI инфраструктурата често са написани като рибарски истории. Числото става по-голямо всеки път, когато се преразказва. HEDL има конкретно бенчмарк твърдение: 571 структурирани задачи за извличане в седем набора от данни, 56 процента по-малко токени от JSON и 10.3 процентни пункта подобрение на точността спрямо JSON.
Тези числа трябва да се четат като бенчмарк твърдение, а не като универсален закон на физиката. Те описват бенчмарк среда. Те не означават, че всеки работен поток магически получава същия резултат. Но те обясняват защо форматът съществува. Броят на токените не е бележка под линия в имплементацията на LLM системите. Той е част от интерфейса. Ако две представяния носят едно и също значение и едното изгаря много повече контекст, по-тежкото не е неутрално.
Увеличението на точността е особено интересно. То подсказва, че ползата не е само в по-евтините подсказки. По-чистото представяне може също така да улесни задачата за модела. Това не бива да е изненада. Ако моделът отделя по-малко внимание на повтарящия се синтактичен шум, той има повече място за стойности и връзки. Това е същата причина, поради която добрите формуляри побеждават разхвърляните в човешката работа. Човекът може да е умен, но не му давайте данъчна декларация, написана от принтер с трудно детство.
Тук има по-широк урок за дизайна. AI интерфейсите не трябва да се оценяват само по това дали моделът може да се справи. Моделите могат да се справят с много лоши интерфейси. Хората също могат да носят мебели по стълби с лош захват и без план. Това не го прави архитектура. Един добър AI интерфейс намалява излишната работа, разкрива структурата, запазва смисъла и се проваля шумно, когато структурата е грешна.
Защо прокси повърхностите имат значение
Един формат рядко печели, защото е чист. Той печели, като се вписва в грозния компромис. MCP и прокси повърхностите на HEDL имат значение, защото повечето организации не могат просто да обявят, че всичко вече говори на ново представяне. Те имат съществуващи API-та, хранилища за данни, правила за валидация, табла, тетрадки и формати за експорт. Да замените всичко това, за да спестите токени, би било героичен начин да загубите приятели.
Прокси моделът е по-практичен. Оставете моделите и инструментите да се възползват от плътното структурирано представяне там, където има значение. Преобразувайте на границата. Валидирайте, преди данните да напуснат контролирания път. Запазете съвместимостта с JSON надолу по веригата. Оставете системите, които очакват JSON, да получават JSON, но спрете да принуждавате модела да влачи цялата JSON форма през всяка вътрешна стъпка.
Тук също така навлиза управлението, тихо и полезно. Ако проксито валидира структурата, то може да отхвърли неправилно оформени обекти, преди те да станат бизнес факти. Ако то запазва беззагубен цикъл, може да докаже, че преобразуването не е променило смисъла. Ако запазва съвместимост със съществуващите системи, то може да бъде прието, без всяка интеграция да се превръща в миграционна програма. Ние сме европейци. Имаме достатъчно миграционни програми. Някои от тях все още имат управителни комитети от 2014 г.
За агентните системи проксито е още по-важно. Агентите предават структурирани повиквания и резултати през границите. Те извикват инструменти, получават резултати, актуализират паметта, създават артефакти и предават състояние на други агенти. Плътното представяне с валидация прави тези предавания по-малко разточителни и по-малко двусмислени. То не прави агента мъдър. То прави плика по-малко глупав. Това е уважаван инженерен резултат.
Къде HEDL не трябва да се използва
Всеки полезен инструмент има място, където не трябва да се използва. HEDL не е замяна за всеки JSON файл на земята. Ако малък конфигурационен файл се чете веднъж от човек и се редактира два пъти годишно, JSON или TOML ще преживеят трагедията. Ако публичен API изисква максимално познаване и полезните натоварвания са малки, JSON е подходящ. Ако схемата е наистина неизвестна и ad hoc, кодирането веднъж със схема не е правилната начална предпоставка.
HEDL става интересен, когато структурата се повтаря, обемите са значими, контекстът на модела е скъп, циклите имат значение и инструментите се нуждаят от съвместимост по краищата. Ето защо LLM работните потоци са толкова подходящи. Те се намират точно в пресечната точка на структурираното намерение и токен икономиката. Те също така са склонни да преминат от прототип към производство по-бързо, отколкото някой е планирал, защото очевидно никой не е научил този урок, въпреки че цялата история на софтуера изглежда леко обидена в ъгъла.
Практичният път на внедряване следователно трябва да е тесен. Не преустройвайте организацията. Изберете структуриран работен процес за извличане. Изберете път за извикване на инструменти от агента. Изберете граница на MCP прокси. Измервайте използването на токени, процента на грешките, резултатите от валидацията и точността на преобразуването. Ако числата се задържат, разширявайте. Ако не се задържат, запазете скучното нещо. Целта не е да се преклонявате пред даден формат. Целта е да спрете да плащате за предотвратима структура.
Урокът
Урокът от HEDL е, че структурата не е безплатна само защото е полезна. В обикновения софтуер повтарящите се ключове са най-вече досада. В работните процеси с ИИ те са контекст, пари, внимание и повърхност за грешки. Ако схемата е известна, повтарянето ѝ във всеки запис често е най-неизобретателният наличен вариант.
HEDL прави прост размен: декларирайте структурата веднъж, кодирайте записите плътно, запазете семантиката, преобразувайте обратно, когато е нужно, и валидирайте на границата на проксито. То не е замяна на JSON като общ език на мрежата. То е по-добър вътрешен формат за структурирана работа с ИИ, където моделът трябва да харчи контекста си за смисъл, а не да чете едни и същи имена на полета до топлинната смърт на бюджета.
Това е полезният стандарт за ИИ инфраструктура. Не умничене заради самото умничене. Не данък за новост. Не формат, който изисква всички останали да страдат. Добрият слой премахва отпадъците, поддържа договора изричен и позволява на останалата част от системата да продължи да работи. HEDL заслужава мястото си, когато обектът стане по-малък, без смисълът да стане по-размит.
JSON може да си остане. То не е направило нищо лошо. Може дори да изпие едно кафе. Просто не е нужно да стои във всяко извикване на модела, носейки същия набор от ключове, като човек, който се мести с по една лъжица наведнъж.