AI výstup v JSON podle schématu. Co musí před importem ověřit aplikace

AI z textu servisního hlášení vytvoří objekt s pěti poli. Import proběhne bez chyby a na obrazovce se objeví nová objednávka. Teprve při kontrole si někdo všimne, že v poli pro sériové číslo je číslo jiné součástky. Formát byl správný. Obsah se přesto neměl zapsat. U strojově zpracovaných odpovědí potřebujete oddělit čitelnost dat pro program, jejich tvar a shodu se skutečným případem.

Schéma umožňuje popsat názvy polí, povinné hodnoty, typy a další pravidla. Výstup od modelu má projít kontrolou na straně přijímající aplikace. Po ní následuje věcná kontrola podle důvěryhodného zdroje a podle dopadu případné chyby. Níže najdete malý model servisního hlášení, typické chyby importu a příklady, co s nimi udělat.

Tři kontroly, které rozhodují o importu

První otázka zní, zda se text dá načíst jako JSON. Správně použité uvozovky, závorky a oddělovače umožní aplikaci převést text na datovou strukturu. Odpověď obalená vysvětlením nebo formátováním pro chat nemusí jít načíst bez dalšího zpracování. V integračním rozhraní oddělte samotnou datovou odpověď od lidského komentáře.

Druhá otázka se týká struktury. Představte si, že očekáváte objekt s identifikátorem případu, kategorií, datem, stavem kontroly a stručným popisem. Aplikace například vyžaduje identifikátor jako text a kategorii z uzavřeného seznamu. Pokud model pošle pole s třemi položkami nebo místo kategorie doplní volnou větu, může to být platný JSON, který se schématem nesouhlasí.

Třetí otázka zní, zda mají hodnoty správný význam a patří k danému případu. Identifikátor může být platný text ve správném formátu, a přesto označovat cizí záznam. Kategorie „výměna“ může být ve výčtu povolená a stále nemusí odpovídat popisu závady. Správný formát ani dodržení schématu nepotvrzují správnost údajů. U důležitých polí porovnávejte zdroj a ověřujte i vztahy mezi položkami.

Tři kontroly nad modelovým servisním hlášením Na mobilu lze tabulku posouvat do stran.

Podobná hranice existuje u vytěžování dokladů pomocí OCR a AI. Strukturovaná částka připravená k importu ještě nemá sama schválit výdaj. U servisního případu můžete nechat výstup vytvořit jako koncept, který ukáže nalezené údaje vedle originálního hlášení. Změnu skutečného případu povolí až navazující systém podle vlastních pravidel.

Jak rozlišit prázdnou hodnotu od chybějící informace

Představte si datum, které se ve zdroji vůbec nevyskytuje. Program může dostat chybějící klíč, hodnotu null, prázdný text nebo smyšlené datum. Čtyři tvary vypadají při ručním čtení skoro stejně, při zápisu mohou mít úplně odlišný dopad. Chybějící klíč může znamenat „pole se nemá měnit“. Výslovné null může v aktualizačním rozhraní znamenat „vymaž dřívější údaj“. Takový význam musí určit navazující aplikace, aby si ho každý článek řetězce nevykládal po svém.

U standardního JSON Schema položky uvedené v properties automaticky nepovinné pole nezmění na povinné. Pokud má klíč vždy přijít, uvedete ho mezi required. Jestli u něj současně povolíte hodnotu null, musí být ve výsledku přítomen, ale může nést výslovně označenou absenci údaje. Povinný klíč a povinně známá hodnota představují různé požadavky. Kde odlišujete chybějící, nečitelný a rozporný údaj, může pomoci samostatný stav kontroly.

Pro modelové hlášení lze zvolit jednoduchou dohodu. Datum se zapíše jen při ověření ve zdroji a jinak se použije null se stavem „ověřit“. Číslo případu přebírá aplikace z právě otevřeného záznamu. Model ho může pro lidské čtení zopakovat, ale nevytváří tím oprávnění vyhledat a přepsat jiný případ. Zprávu, která neobsahuje potřebnou podrobnost, může pracovník doplnit bez toho, aby přepsal dříve ověřenou informaci.

• Identifikátory ukládejte jako text, pokud mají význam počáteční nuly, písmena nebo oddělovače. Číslo pro výpočet a označení objednávky plní jiné role.
• Povolené hodnoty popište tak, aby bylo jasné, co dělat s případem mimo výčet. Zvažte stav pro předání člověku místo výběru nejbližší kategorie za každou cenu.
• Datum v kalendáři a přesný čas s časovým pásmem zapisujte jako různé pojmy. U neurčitého „příští pátek“ může být nutný časový kontext nebo dotaz na člověka.
• U textového pole určete, kde se zobrazí a jak se zachází s obsahem při vkládání do HTML, tabulky nebo dalšího systému. Platný řetězec sám o sobě nedává pokyn k vykonání jeho obsahu.

Jak využít strukturovaný režim modelu

Některá rozhraní nabízejí JSON režim, jiná umějí přijmout schéma a omezit podobu výsledku podle něj. Google Cloud ve své dokumentaci tyto možnosti rozlišuje. U režimu se schématem popisuje podporovaný výběr pravidel, odlišnosti od plného standardu a omezení složitosti. Na podpoře konkrétního pravidla záleží. Aplikace může očekávat odmítnutí nadbytečného pole, ale služba při generování zrovna toto omezení nepoužije.

Vlastní ověření aplikace má význam i s podporovaným schématem. Integrace musí zvládnout odpověď ukončenou limitem, výpadek nebo výsledek, který služba odmítla zpracovat. Před pokusem o načtení dat si proto ověřte stav dokončení odpovědi. U zvláštních typů odpovědí pokračujte podle jejich skutečného významu. Například při dočasném výpadku může být správné požadavek omezeně zopakovat. Při chybě vstupu je lepší ho doplnit.

Schéma používejte jako dohledatelnou dohodu. Zapište označení verze do konfigurace, ověřte několik typických vzorků a zkoušejte i nadbytečná a chybějící pole. Pokud výstup přijímají dvě aplikace, zkontrolujte obě. První může neznámý klíč zahodit, druhá na něm může skončit. U exportů do kancelářských nástrojů navíc zůstávají následné kontroly přepočtů a formátů, které ukazuje návod k práci s AI v Excelu a Sheets.

Připravte bezpečný průchod od návrhu k zápisu

Uvažujte modelový tým, který denně třídí servisní e-maily. Každý e-mail může získat návrh kategorie a popis. Aplikace zná identifikátor už ze své databáze. Z odpovědi modelu proto převezme jen pole určená pro návrh. Při potvrzení výstupu čte znovu skutečný stav případu. Pokud byl případ mezitím uzavřen nebo přesunut, nový výstup nepřepíše rozhodnutí kolegy.

1. Načtěte odpověď pomocí skutečného parseru. Ověřte stav dokončení, očekávaný formát a případná omezení velikosti. Duplicitní názvy v objektu mohou různé nástroje vyložit odlišně. Pokud na tom záleží, nastavte odmítnutí dřív, než parser některou hodnotu přepíše.
2. Použijte validátor pro dohodnutou verzi schématu. Dohledejte konkrétní pole, které neprošlo, a rozhodněte, zda jde o neplatnou strukturu nebo změnu dohody mezi systémy.
3. Prověřte hodnoty proti zdrojům a pravidlům aplikace. Ověřte existenci objektu, povolený přechod stavu a vazby mezi poli. Základní tvar hodnoty může kontrolovat schéma, aktuální stav zdroje musí posoudit aplikace.
4. Ponechte návrh bez zápisu, když potřebujete rozhodnutí člověka. Ukažte mu původní podklad i důvod, který zastavil automatický průchod.
5. Uložte potvrzení, které pole se opravdu zapsalo a do jakého případu. Při chybě v pozdější fázi se nejdřív přesvědčte, zda zápis už neproběhl.

U opakovaných úloh připravte testovací sadu pro změny AI. Přidejte vzorek, který projde formátem i schématem, ale má nesprávný identifikátor. Test má uspět právě tehdy, když zápis odmítne věcná kontrola. Zařaďte také případ, který je opravdu správný, aby kontrola pouze nevyloučila všechny návrhy.

Dva příklady se stejným schématem a opačným výsledkem

Servis přijme modelové hlášení k případu S-0042. V textu je uvedeno, že přístroj vykazuje závadu, ale chybí den, kdy se projevila poprvé. Na konci je stará přeposlaná zpráva o podobné závadě z případu S-0076. Přijímač požaduje přítomnost čtyř klíčů, krátký popis a datum buď jako řetězec, nebo jako null. Obě čísla odpovídají vzoru a lze je najít v interní evidenci. Právě proto se kontrola nesmí zastavit u existence záznamu.

První návrh použije S-0042, ponechá datum prázdné pomocí null a popis zachová v mezích nového hlášení. Aplikace ověří, že se identifikátor shoduje s aktuálním případem. Může uložit návrh, aniž by vymazala existující datum v potvrzeném záznamu. Pracovník si v rozhraní přečte, že údaj nebyl ve vstupu doložen, a rozhodne, zda má kontaktovat zákazníka.

Druhý návrh použije S-0076 a vyplní datum ze staré přeposlané zprávy. Hodnoty se do povolených typů vejdou, ale odkazují na jiný případ. Přijímač návrh odloží a u výsledku zobrazí, který údaj se neshoduje s právě otevřeným hlášením. Pokud se identifikátor přebírá přímo z evidence a model ho vůbec nevrací, stále musíte ověřit samotné datum a popis. Omezení odpovědi odstraní jednu cestu k chybě, zbývající hodnoty mohou přenos kontextu ze staré zprávy pořád ovlivnit.

Hodí se uchovat důkaz v malé podobě. Aplikace může evidovat identifikátor návrhu a odkaz na relevantní část zdroje místo plošného kopírování všech e-mailů do diagnostiky. Pokud model připojí citaci, porovnejte ji se skutečným vstupem. Text označený jako „citace“ může být vytvořený stejně jako ostatní hodnoty a sám nepotvrzuje, že se daná věta ve zdroji nachází.

Výsledek pro člověka může být čitelnější než interní JSON

Při ruční kontrole lidé obvykle potřebují rychle najít hodnotu a její původ. Pomáhá formulář, který vedle návrhu zobrazí příslušný zdroj, informaci o chybějícím údaji a stav, do kterého potvrzení případ posune. Když příjemce musí hledat ve velkém objektu plném technických polí, hůř rozezná nesprávnou hodnotu. Datový formát tedy nechte sloužit strojům a kontrolní rozhraní navrhněte podle práce člověka.

V automatizaci se stejným pravidlem můžete použít jednoduché rozlišení návrhu, odmítnutí a potvrzení. Do výsledku rozhraní vraťte srozumitelnou příčinu. Například rozpor identifikátoru má být odlišitelný od neplatného data nebo poruchy služby. V provozu pak snáz najdete nejčastější překážku a můžete změnit správnou část postupu. Při ladění nad reálnými záznamy držte stejné limity přístupu jako u jiných servisních podkladů.

Před zavedením přidejte krátkou zkoušku s jinak seřazenými klíči. Přijímač má používat jejich názvy. Pokud načítá pole podle pořadí v textu, může změna serializace při zachování stejného schématu přehodit význam údajů. Totéž platí pro mezery a odsazení, která mohou usnadnit čtení, ale nemají určovat obsah.

Kdy opravit vstup a kdy zastavit import

Jestliže model občas přidá vysvětlující větu mimo datovou odpověď, zkontrolujte způsob volání, nastavení formátu a způsob čtení odpovědi. Vyřezání první dvojice složených závorek z libovolného textu může náhodou vybrat ukázku z vysvětlení, i když správný objekt je až dál. U provozního importu potřebujete důvěryhodně vymezený obsah. Pokud jej nezískáte, evidujte neplatný výstup nebo zkuste omezené opakování čistého čtecího kroku.

Jestliže vstup skutečně neobsahuje datum, další pokus může náhodně vyrobit datum jiné. Chybějící podklad se vyřeší doplněním nebo předáním případu. U omezeného opakování držte pevně stanovený počet pokusů a uvažujte, co už mohlo proběhnout. Opakované vytvoření návrhu má jiné následky než opakovaný pokus uložit případ nebo odeslat zprávu. Identifikátor požadavku a skutečný stav zápisu pomáhají oddělit tyto kroky.

Sledujte, kde návrhy odpadají. Když z padesáti pokusů dva skončí poruchou, dalších pět neprojde schématem a osm potřebuje lidské rozhodnutí, samotný součet patnácti odchylek nepomůže určit, co upravit. V modelu by třicet pět pokusů prošlo všemi třemi body. Poruchy patří k dostupnosti služby, chyba tvaru k rozhraní a nejasné případy mohou být očekávanou součástí práce. Když stejnou skupinu evidujete zvlášť, poznáte, zda vylepšení skutečně odstranilo problém, který vás zajímal.

Co se děje při změně schématu

Zavedení nového pole může ovlivnit starší aplikaci, přestože nezmizelo žádné dosavadní pole. Přijímač například striktně odmítá dodatečné klíče. Změna povoleného výčtu zase může ovlivnit přehledy, které mají vlastní názvy kategorií. Před vydáním zjistěte, kdo výstup čte, a ověřte shodu na uložených vzorcích obou verzí. Při přechodu může být vhodné oddělit zpracování podle explicitního čísla schématu.

Mění se také čekající práce. Případ zahájený se starým zadáním může skončit v době, kdy už nový přijímač očekává jinou podobu dat. Zapište verzi při startu požadavku a zachovejte ji až do kontroly. V modelu s přechodem z jednoho pole pro popis na dvě pole pro závadu a očekávaný výsledek by nová aplikace měla rozhodnout, co udělá se starými položkami. Překlad mezi verzemi má smysl tam, kde význam opravdu zachová. Pokud původní text jednotlivé části nedokáže spolehlivě rozlišit, vyžádejte lidskou kontrolu.

Časté otázky

Stačí napsat modelu, aby odpověděl jen v JSON?

Může to zlepšit konzistenci, ale pořád potřebujete ověřit skutečný tvar odpovědi. Jestli rozhraní podporuje řízený výstup, použijte ho s doloženým schématem a ověřujte i výsledky na straně aplikace.

Můžu povinné pole vyplnit prázdným textem?

Záleží na dohodě. Typ text sám o sobě prázdný řetězec obvykle připouští, pokud nepřidáte další omezení. Je-li prázdnota smysluplná informace, definujte ji tak, aby ji přijímač nebral za potvrzený údaj.

Může schéma ověřit, že objednávka opravdu existuje?

Běžné schéma umí ověřit tvar identifikátoru. Existenci a přístup k aktuálnímu záznamu ověřujte proti vlastní evidenci. I existující objednávka může patřit k jinému požadavku.

Kdy povolit klíče navíc?

Při rozšiřování rozhraní mohou být užitečné, jestli je přijímač bezpečně ignoruje nebo zpracuje podle dohody. U zápisu dat je zpravidla důležitější jasně vybrat schválená pole a zvlášť řešit nečekané hodnoty.

Proč nenechat model opravit každý vadný výstup?

Oprava může pomoci u technické podoby návrhu. Nemůže spolehlivě dodat skutečnost, která ve zdroji chybí. U případu s dopadem na zákazníka musí pravidlo předání vycházet z podkladů a vlastního systému.

Jak ověřit, že se chybné údaje neuložily?

Zkontrolujte stav cílové evidence po dokončení požadavku. Evidence chyb v importu sama nestačí, pokud mohl dřívější krok některé položky změnit. V testu si předem připravte stav, který očekáváte po úspěchu i odmítnutí.