HEDL ja strukturoitu data ilman JSON-turvotusta
Kihdin piilossa oleva lasku
JSON voitti, koska se on tylsä juuri oikealla tavalla. Ihmiset voivat lukea sitä. Koneet voivat jäsentää sen. Jokaiselle kielelle löytyy kirjasto sille. Jos kahden järjestelmän pitää vaihtaa objekti eikä kukaan halua standardointikokousta, JSON on yleensä se paikka, jossa keskustelu päättyy. Hyvä on. On olemassa huonompiakin kompromisseja. Monella niistä on nimi, jossa esiintyy sana enterprise.
Ongelma ei ole JSON verkkomuotona. Ongelma on se, mitä tapahtuu, kun työnnämme JSONin kielimallityönkulkuihin ja teeskentelemme, että hinta on ilmainen. Malli ei näe siistiä objektia samalla tavalla kuin sovellusjäsennin. Se näkee tokeneita. Se lukee samoja avaimia uudestaan ja uudestaan. Se käyttää kontekstia välimerkkeihin, toistuviin kenttänimiin, kääreisiin, sisäkkäisiin rakenteisiin ja muotomuistutuksiin, jotka olivat jo tiedossa ennen ensimmäistäkään tietuetta.
Tämä hukka oli ennen lievästi ärsyttävää. AI-järjestelmien kanssa siitä tulee tuoteongelma. Jokainen toistuva avain kilpailee todisteiden, ohjeiden, esimerkkien, viitteiden ja varsinaisen käyttäjäsisällön kanssa. Jokainen tarpeeton rakenteellinen token on pieni vero hyödylliselle työlle. Lasku ei sano tarpeettomat aaltosulkeet, koska laskuista puuttuu runollisuus. Se sanoo tokenit.
HEDL lähtee yksinkertaisesta havainnosta: kun skeema tunnetaan, skeeman toistaminen jokaisen tietueen sisällä on typerää. Määrittele rakenne kerran. Koodaa tietueet paikkakohtaisesti. Pidä semantiikka tarkkana. Muunna takaisin muotoihin, joita olemassa olevat järjestelmät jo odottavat. Tämä ei ole anti-JSON-ideologiaa. Se on kieltäytymistä maksamasta mallille siitä, että se lukee saman tienviitan uudelleen joka kymmenes metri.
Tämä on tärkeää, koska rakenteellinen AI-työ ei ole pelkkää chattia. Se on poimintaa, luokittelua, työkalujen kutsuja, datan muunnoksia, tarkistuspaketteja, todistepaketteja, MCP-kutsuja, työnkulkuja ja agentteja, jotka välittävät objekteja toisilleen koko päivän. Mitä vakavampi järjestelmä on, sitä enemmän rakennetta se tarvitsee. Jos rakenne ilmaistaan mahdollisimman monisanaisesti, järjestelmä maksaa omasta kurinalaisuudestaan.
JSON ei ole konna
Olisi helppoa ja laiskaa kirjoittaa tämä JSON-valitukseksi. JSONilla on todellisia vahvuuksia. Se on kaikkialla läsnä, helposti virheenjäljityskelpoinen, helppo putkittaa olemassa olevien työkalujen läpi ja riittävän hyvä valtavaan määrään sovellustyötä. Pointti ei ole se, että JSON olisi huono. Pointti on se, että JSONia käytetään usein paikoissa, joissa vastaanottava puoli tietää jo muodon, ja siellä toisto lakkaa olemasta selkeyttä ja alkaa olla taakkaa.
Ajatellaan rakenteellista poimintatehtävää. Skeema sanoo, että jokaisella vastauksella on nimi, lähde, arvo, luottamus ja perustelu. Kuvittele nyt lähettäväsi satoja rivejä mallille tai vastaanottavasi satoja rivejä takaisin yhdeltä. JSON toistaa nämä kenttänimet jokaisen objektin kohdalla. Sovellusjäsennin ei välitä. Mallin konteksti välittää. Konteksti-ikkunasta tulee toimitusauto täynnä tarroja tavaroiden sijaan.
HEDL kohtelee skeemaa sopimuksena. Se nimeää kentät ja tyypit kerran. Tietueet kuljettavat sitten arvot järjestyksessä. Se kuulostaa itsestäänselvyydeltä, koska se on sitä. Monet tehokkaat formaatit ovat tehneet samanlaisia kompromisseja vuosikymmeniä. Ero on siinä, että HEDL on suunnattu LLM-kohtaamisiin rakenteellisiin työnkulkuihin, joissa ihmisen virheenjäljityskyky, muunnokset ja työkaluyhteensopivuus ovat edelleen tärkeitä. Se ei ole binäärinen möykky, joka heitetään seinän yli lappu mukanaan: onnea matkaan.
HEDL-toteutus sisältää Rust-kirjastotuen, CLI-käytön, MCP-palvelimen ja välityspinnat, WASM:n, FFI:n ja sidokset sekä muunnokset yleisiin formaatteihin ja niistä pois. Tämä yhdistelmä on tärkeä. AI-työnkulkujen formaatti ei voi olla pelkästään tiivis. Sen on mentävä sisään ja ulos sekavasta maailmasta tulematta yksityiseksi kultiksi. Olemassa olevat rajapinnat haluavat edelleen JSON:ia. Ihmiset tarkastelevat edelleen dataa. Työkalut tarvitsevat edelleen edestakaisia siirtoja. Formaatin on oltava tiivis tulematta epäsosiaaliseksi.
Rakenne sopimuksena
Useimmat AI:n epäonnistumiset strukturoidun datan kanssa eivät ole dramaattisia. Ne ovat pikkumaisia, minkä vuoksi niitä on vaikeampi ottaa vakavasti ennen kuin ne maksavat oikeaa rahaa. Kenttä ajautuu harhaan. Arvo asetetaan väärän avaimen alle. Malli tuottaa uskottavan objektin, josta puuttuu valinnainen kenttä. Jäsennin hyväksyy muodon, joka sen olisi pitänyt hylätä. Jatkotyökalu vastaanottaa melkein oikean asian, mikä on ohjelmistossa vaarallisin asia.
HEDL:n skeema-ensimmäinen lähestymistapa on hyödyllinen, koska se tekee rakenteesta eksplisiittisen ennen kuin tietueet alkavat liikkua. Skeema ei ole löyhä kehote-ehdotus. Se on se, joka kertoo lukijalle, miten arvot tulkitaan. Tietue on tiivis, koska sen ei tarvitse kertoa itseään toistuvasti. Ympäröivä työkalusto voi silti validoida, muuntaa ja välittää dataa järjestelmiin, jotka suosivat JSON:ia, YAML:ia, XML:ää, CSV:tä tai muita tavanomaisia muotoja.
Edestakaiset siirrot ovat testi sille, onko formaatti hyödyllinen vai pelkästään nokkela. Jos JSON menee sisään, HEDL kulkee työnkulun läpi ja JSON tulee ulos samoilla semantiikoilla, järjestelmä saa tiiviyttä menettämättä yhteensopivuutta. Jos merkitys katoaa hiljaa, formaatti on epäonnistunut. Oikea käytös paineen alla ei ole kohauttaa olkiaan ja välittää objekti eteenpäin. Se on pysäyttää, raportoida ja pakottaa epäselvyys avoimeksi.
Tässä HEDL asettuu hyvin Dweve-pinon rinnalle. Ledger huolehtii siitä, että operatiiviset tapahtumat pysyvät tarkasteltavina. AION huolehtii siitä, että päätöstodisteet voidaan tarkistaa. Trace huolehtii siitä, että laskenta voidaan toistaa. HEDL huolehtii siitä, että strukturoitu data voidaan esittää tiiviisti ja palauttaa tarkasti. Nämä tehtävät sivuavat toisiaan, mutta ne eivät ole sama tehtävä. Jälleen: vähemmän lämpimiä sanoja, enemmän hyödyllisiä rajoja.
Vertailuarvo ei ole koriste
Suorituskykyväitteet AI-infrastruktuurin ympärillä kirjoitetaan usein kuin kalastustarinat. Luku kasvaa joka kerta, kun se kerrotaan uudelleen. HEDL:llä on konkreettinen vertailuarvo: 571 strukturoitua poimintatehtävää seitsemässä tietoaineistossa, 56 prosenttia vähemmän tokeneita kuin JSON ja 10,3 prosenttiyksikön tarkkuusparannus JSON:iin verrattuna.
Nämä luvut tulisi lukea vertailuarvoväitteenä, ei universaalina fysiikan lakina. Ne kuvaavat vertailuasetelmaa. Ne eivät tarkoita, että jokainen työnkulku saa maagisesti saman tuloksen. Mutta ne selittävät, miksi formaatti on olemassa. Tokenimäärä ei ole toteutuksen alaviite LLM-järjestelmissä. Se on osa rajapintaa. Jos kaksi esitystapaa kantavat saman merkityksen ja toinen kuluttaa huomattavasti enemmän kontekstia, raskaampi ei ole neutraali.
Tarkkuuden parannus on erityisen kiinnostava. Se viittaa siihen, että hyöty ei ole vain halvemmissa kehotteissa. Puhtaampi esitystapa voi myös helpottaa mallin tehtävää. Tämän ei pitäisi olla yllätys. Jos malli käyttää vähemmän huomiota toistuvaan syntaktiseen sotkuun, sille jää enemmän tilaa arvoille ja suhteille. Tämä on sama syy, miksi hyvät lomakkeet päihittävät sekavat lomakkeet ihmisten työssä. Ihminen voi olla älykäs, mutta älä anna hänelle verolomaketta, jonka on kirjoittanut tulostin, jolla on ollut vaikea lapsuus.
Tässä on laajempi suunnittelun opetus. Tekoälyrajapintoja ei pitäisi arvioida vain sen perusteella, pystyykö malli selviytymään. Mallit selviytyvät monista huonoista rajapinnoista. Ihmisetkin pystyvät kantamaan huonekaluja portaita ylös huonolla otteella ja ilman suunnitelmaa. Se ei tee siitä arkkitehtuuria. Hyvä tekoälyrajapinta vähentää vältettävissä olevaa työtä, tuo rakenteen näkyväksi, säilyttää merkityksen ja epäonnistuu äänekkäästi, kun rakenne on väärä.
Miksi välityspintakerrokset ovat tärkeitä
Muoto harvoin voittaa olemalla puhdas. Se voittaa sopimalla rumaan keskiväliin. HEDL:n MCP- ja välityspintakerrokset ovat tärkeitä, koska useimmat organisaatiot eivät voi yksinkertaisesti ilmoittaa, että kaikki puhuu nyt uutta esitystapaa. Niillä on olemassa olevia rajapintoja, tietovarastoja, validointisääntöjä, kojelautoja, muistikirjoja ja vientimuotoja. Kaiken sen korvaaminen tokenien säästämiseksi olisi sankarillinen tapa menettää ystäviä.
Välityspintakuvio on käytännöllisempi. Anna mallien ja työkalujen hyötyä tiiviistä rakenteellisesta esitystavasta siellä, missä sillä on merkitystä. Muunna rajapinnassa. Validoi ennen kuin data poistuu hallitulta polulta. Säilytä alavirran JSON-yhteensopivuus. Anna järjestelmien, jotka odottavat JSONia, vastaanottaa JSONia, mutta lopeta sen pakottaminen, että malli raahaa koko JSON-muodon läpi jokaisen sisäisen vaiheen.
Tässä kohtaa hallinto astuu mukaan, hiljaa ja hyödyllisesti. Jos välityspinta validoi rakenteen, se voi hylätä virheelliset objektit ennen kuin niistä tulee liiketoiminnan tosiasioita. Jos se säilyttää häviöttömän edestakaisen matkan, se voi todistaa, että muunnos ei muuttanut merkitystä. Jos se säilyttää yhteensopivuuden olemassa olevien järjestelmien kanssa, se voidaan ottaa käyttöön muuttamatta jokaista integraatiota migraatio-ohjelmaksi. Olemme eurooppalaisia. Meillä on riittävästi migraatio-ohjelmia. Joillakin niistä on edelleen ohjauskomiteoita vuodelta 2014.
Agenttijärjestelmille välityspinta on vielä tärkeämpi. Agentit välittävät rakenteellisia kutsuja ja tuloksia rajojen yli. Ne kutsuvat työkaluja, vastaanottavat tulosteita, päivittävät muistia, tuottavat artefakteja ja siirtävät tilaa muille agenteille. Tiivis esitystapa validointineen pitää nämä luovutukset vähemmän tuhlaavina ja vähemmän monitulkintaisina. Se ei tee agentista viisasta. Se tekee kirjekuoresta vähemmän tyhmän. Se on kunnioitettava insinöörityön tulos.
Missä HEDL:ää ei pitäisi käyttää
Jokaisella hyödyllisellä työkalulla on paikka, jossa sitä ei pitäisi käyttää. HEDL ei ole korvaaja jokaiselle maailman JSON-tiedostolle. Jos pieni konfiguraatiotiedosto luetaan kerran ihmisen toimesta ja sitä muokataan kahdesti vuodessa, JSON tai TOML selviää tragediasta. Jos julkisen rajapinnan on oltava mahdollisimman tuttu ja hyötykuormat ovat pieniä, JSON on hyvä. Jos skeema on aidosti tuntematon ja ad hoc, skeeman kerran koodaava esitystapa ei ole oikea alkuoletus.
HEDL:stä tulee kiinnostava, kun rakenne toistuu, volyymit ovat merkittäviä, mallin konteksti on kallista, edestakaiset matkat ovat tärkeitä ja työkalut tarvitsevat yhteensopivuutta reunoilla. Siksi LLM-työnkulut sopivat niin hyvin. Ne istuvat täsmälleen rakenteellisen tarkoituksen ja tokenitalouden risteyksessä. Ne myös kasvavat prototyypistä tuotantoon nopeammin kuin kukaan suunnitteli, koska ilmeisesti kukaan ei ole oppinut tätä läksyä, vaikka koko ohjelmistokehityksen historia näyttää lievästi loukkaantuneelta nurkassa.
Käytännön käyttöönoton polun tulisi siis olla kapea. Älä kirjoita organisaatiota uusiksi. Valitse jäsennelty tiedonpoiminnan työnkulku. Valitse agentin työkalujen kutsupolku. Valitse MCP-välityspalvelimen raja. Mittaa tunnusten kulutusta, epäonnistumisastetta, validointituloksia ja edestakaisen siirron tarkkuutta. Jos luvut pitävät, laajenna. Jos eivät, pidä tylsä ratkaisu. Tavoitteena ei ole palvoa formaattia. Tavoitteena on lopettaa maksaminen vältettävissä olevasta rakenteesta.
Opetus
HEDL:n opetus on, että rakenne ei ole ilmainen vain siksi, että se on hyödyllinen. Tavallisessa ohjelmistossa toistuvat avaimet ovat enimmäkseen harmi. Tekoälytyönkuluissa ne ovat kontekstia, rahaa, huomiota ja epäonnistumispinta. Jos skeema tunnetaan, sen toistaminen jokaisessa tietueessa on usein vähiten mielikuvituksellinen vaihtoehto.
HEDL tekee yksinkertaisen kaupan: rakenne julistetaan kerran, tietueet koodataan tiiviisti, semantiikka säilytetään, muunnos takaisin tehdään tarvittaessa ja validointi tehdään välityspalvelimen rajalla. Se ei korvaa JSON:ia verkon yhteisenä kielenä. Se on parempi sisäinen kirjekuori jäsennellylle tekoälytyölle, jossa mallin pitäisi käyttää kontekstinsa merkitykseen, ei samojen kenttänimien lukemiseen budjetin lämpökuolemaan asti.
Se on hyödyllinen standardi tekoälyinfrastruktuurille. Ei oveluutta oman itsensä vuoksi. Ei uutuusveroa. Ei formaattia, joka vaatii kaikkien muiden kärsivän. Hyvä kerros poistaa hukkaa, pitää sopimuksen yksiselitteisenä ja antaa muun järjestelmän jatkaa toimintaansa. HEDL ansaitsee paikkansa, kun objekti pienenee ilman, että merkitys pehmenee.
JSON voi jäädä. Se ei ole tehnyt mitään väärää. Se voi jopa juoda kupin kahvia. Sen ei vain tarvitse istua jokaisessa mallikutsussa kantamassa samoja avaimia kuin mies, joka muuttaa taloa yksi lusikka kerrallaan.