Důvěřuj, ale prověřuj: Vynucení schématu, strukturované výstupy a evaluace agentů

Výstup agenta je užitečný jen natolik, nakolik ho dokáže zpracovat další krok. Pokud navazující systém očekává rozhodnutí, číslo nebo kategorii, a místo toho dostane odstavec dobře míněné, ale nestrukturované prózy, celý pipeline se zastaví. Přimět model, aby spolehlivě produkoval strojově zpracovatelný výstup, se ukazuje být vlastní inženýrskou disciplínou, odlišnou od toho přimět ho dobře uvažovat — a přichází se skutečným žebříčkem síly záruky, který stojí za to znát podle jména.

Žebříček, od nejslabšího po nejsilnější

Na nejslabší příčce stojí prompted JSON: prosté požádání modelu v přirozeném jazyce, aby "odpověděl pouze v JSON". To nenabízí žádné skutečné vynucení — model může pod tlakem stále sklouznout do prózy nebo vyprodukovat syntakticky rozbitý JSON. O stupeň výš je JSON mode, kde poskytovatel omezuje sampling tak, aby zaručil syntakticky platný JSON, i když nijak nezaručuje, že tvar skutečně odpovídá schématu, které potřebujete.

Další příčka, a praktický výchozí bod pro většinu produkčních systémů, je schéma nástroje nebo function-calling, kde je výstup vynucen do deklarovaného parametrového schématu nástroje a jeho typy jsou kontrolovány. Vedle toho stojí validační knihovny jako Instructor nebo Pydantic, které výstup naparsují do typovaného modelu a při selhání validace automaticky zopakují pokus, přičemž chybu vrátí zpět modelu, aby ji další pokus opravil. Úplně na vrcholu žebříčku stojí grammar-constrained decoding, kde je samotný proces samplingu omezen token po tokenu na definovanou gramatiku, takže neplatný výstup je strukturálně nemožné vůbec vyprodukovat — nejsilnější dostupná záruka, i když dnes napříč poskytovateli nejméně běžně podporovaná.

Strukturovaný výstup jako smlouva

Pomáhá myslet na deklarované schéma jako na smlouvu mezi agentem a čímkoliv, co jeho výstup spotřebovává — stejně jako je signatura funkce smlouvou mezi kusem kódu a jeho volajícím. Obchodní systém, který vydá strukturované rozhodnutí s pevnou sadou možných akcí a ohraničeným skóre jistoty, může navazující automatizace přímo použít k akci; systém, který vydá odstavec, byť sebelogičtějšího, uvažování, nelze použít k akci bez toho, aby ho nejdřív přečetl člověk.

Druhá, související disciplína: observabilita a evaluace

Strukturovaný výstup řeší problém zpracovatelnosti jedné jednotlivé odpovědi. Druhý, související problém se objeví, jakmile je agent dost autonomní na to, aby sám podnikl více kroků: potřebujete způsob, jak vidět trajektorii, kterou skutečně zvolil, a způsob, jak ohodnotit, zda byla tato trajektorie dobrá, ve velkém měřítku, bez toho, aby člověk ručně prohlížel každý běh. Observabilita je popisná — trasuje každé volání LLM, každé volání nástroje a každý přechod stavu a ke každému kroku připojuje latenci, náklady a stav chyby, takže lze celou trajektorii zpětně rekonstruovat. Evaluace jsou hodnotící — evaluace trajektorie se ptá, zda agent zvolil rozumnou cestu, ne jen zda dospěl ke správné konečné odpovědi, protože správná odpověď dosažená špatnou cestou je latentní selhání čekající na to, aby uštklo u dalšího, mírně odlišného vstupu.

Systém s výborným trasováním a bez evaluací vám dokáže přesně říct, jak agent dospěl ke špatné odpovědi, ale nikdy neoznačí, že odpověď byla špatná, pokud si toho náhodou nevšimne člověk. Systém se silnými evaluacemi a bez trasování dokáže označit, že se něco zhoršilo, ale nechá vás hádat proč. Produkční agentní systémy potřebují obě vrstvy, běžící nepřetržitě — stejným způsobem, jakým sada unit testů podmiňuje změnu kódu ještě před jejím nasazením.