Budování sebezdokonalujících se daňových agentů s Codexem

Jak Thrive Holdings a OpenAI společně vyvinuly Tax AI pro účetní Crete propojením odborných znalostí praktiků se smyčkou řízenou Codexem

Systémy z reálného světa se v produkci chovají jinak než v laboratoři a selhávají způsoby, které je před nasazením těžké předvídat. Týmy tyto poruchy často objeví až po spuštění a pak tráví týdny zkoumáním okrajových případů, úpravami promptů a převáděním produkční zpětné vazby do trvalých zlepšení produktu. Smyčka zpětné vazby je ruční a pomalá a zlepšuje se jen tehdy, když ji posune inženýr. Dnes ale díky promyšleně navržené eval infrastruktuře, přímému přístupu k odborníkům a reálným prostředím a špičkovým agentním schopnostem Codexu můžete budovat agenty, kteří se sami zlepšují.

V tomto článku rozebereme, jak jsme pomocí Codexu tento typ agenta vytvořili. Během posledních šesti měsíců spolupracovali inženýři a výzkumníci OpenAI nasazení přímo v terénu spolu s inženýry Thrive Holdings na budování Tax AI vedle a pro síť více než 30 účetních firem Crete⁠(otevře se v novém okně), aby pomohli s přípravou stále složitějších daňových přiznání. Místo toho, aby se Tax AI spoléhala na inženýry při hledání a opravě každého selhání, používá Codex k tomu, aby produkční používání proměnila ve strukturované signály, které pohánějí autonomní zlepšování.

Odborníci v Crete každou sezónu připravují desítky tisíc daňových přiznání, což vyžaduje práci s miliony podkladových dokumentů. U přiznání se střední až vysokou složitostí může samotné zadávání dat zabrat osm hodin na jedno přiznání a často zahrnuje neuspořádané zdroje dat, dokumenty z předchozího roku a ruční extrakci i výpočty. Upozornili nás, že příprava daní je významným úzkým místem během nejvytíženější části daňové sezóny.

Aby tento problém vyřešila, zpracovala Tax AI v této daňové sezóně 7 000 daňových přiznání napříč firmami Crete, které se účastnily pilotu. Systém automatizuje velkou část časově náročného procesu přípravy daňových přiznání 1040 a 1041, ale ještě přesvědčivější než zisky v efektivitě je to, že samotný systém je měřitelně lepší než verze, která byla poprvé nasazena před třemi měsíci.

V Tax AI odborníci nahrávají zdrojové soubory spolu s případnými poznámkami specifickými pro klienta. Tax AI pak vytvoří podání do daňového enginu připravené ke kontrole. Šetří odborníkům asi třetinu času při přípravě daní, připravuje návrhy přiznání s přesností až 97 % a zvyšuje výkon asi o 50 %, čímž jim vytváří více prostoru trávit čas s klienty. 

Toto zlepšení můžeme kvantifikovat tím, že pochopíme, jak přesně dokáže Tax AI dokončit přiznání bez potřeby pozdější opravy. Přesnost měříme kontrolou, kolik z přiznání dosáhne 75 %, 90 % nebo 100 % správně vyplněných polí. Při spuštění dosahovala jen čtvrtina přiznání 75 % správně vyplněných polí, ale během šesti týdnů této hranice dosáhlo 86 %. Systém vykázal ještě rychlejší růst na úrovních 90 % a 100 % správně vyplněných polí. Tyto prahy nám dávají praktický pohled na to, kolik následné práce od odborníka různá přiznání ještě vyžadují. 

Zpočátku Tax AI zvládala jednodušší práci, jako jsou formuláře W-2 a 1099. Jak sezóna pokračovala, přesunula se ke složitějším přiznáním s formuláři K-1, přílohami a náročnějšími okrajovými případy. Každá nová schopnost ušetřila na jedno přiznání více času než ta předchozí, protože úkoly, které převzala, byly náročnější a časově nákladnější při ručním zpracování. Průběžný pokrok vidíme i dnes.

Dále si ukážeme, jak naše týmy společně navrhly Tax AI tak, aby se sama zlepšovala, a to opřením o tři klíčové pilíře: 1) zpětnou vazbu odborníků, 2) produkční stopy (strukturovanou historii od vstupů po finální výstup) a 3) iterační smyčku řízenou Codexem založenou na přizpůsobených evalech, která umožňuje průběžný a rychlejší vývoj produktu. Doufáme, že naše zkušenost bude užitečná i dalším tvůrcům v oblastech, kde jsou odborné znalosti praktiků klíčové pro utváření kvality celého systému i dat, která jím procházejí.

Když jsme se pustili do náročnějších částí přípravy daní (K-1, přehledy pronajímaných nemovitostí a daňové formuláře, kde bylo nutné hodnoty sladit napříč více zdrojovými soubory), ukázalo se, že skutečnou výzvou je, zda produkt dokáže složitá produkční selhání zviditelnit, učinit je srozumitelnými a využitelnými.

V počátcích produktu byla většina oprav ruční. Odborníci mohli chyby systému opravovat, ale produkt nezachycoval celý kontext: změněná hodnota před podáním mohla odrážet skutečné selhání extrakce, problém mapování, chybějící podporu produktu nebo očekávaný šum workflow. Roztřídění těchto případů stále vyžadovalo následnou práci inženýrského týmu. Inženýři mohli používat kódovací agenty, ale systém ještě nebyl navržen tak, aby AI smysluplně využíval uvnitř smyčky zlepšování. Neměli jsme signál, který by určil správný kopec k vystoupání.

To nás vedlo k návrhu systému kolem tří pilířů:

1. Zůstat blízko odborníkům: Lidé, kteří práci vykonávají, musí řídit, co se produkt učí. Jejich intuice a porozumění odhalují, které chyby jsou důležité, a pomáhají určit, na které části workflow má smysl se zaměřit příště.
2. Vybudovat produkt tak, aby produkce vytvářela důkazy: Produkt musí zachytit víc než jen vstupy a výstupy; musí zachytit celou cestu od zdrojového materiálu přes extrahovaná pole a jejich původ až po navazující podání a opravu odborníkem.
3. Vytvořit smyčku zlepšování řízenou Codexem: Jakmile jsou produkční problémy viditelné a strukturované, mohou se proměnit ve zjištění, přizpůsobené evaly a vymezené inženýrské úkoly. Codex pak může pomoci s vyšetřením, navržením změn, jejich ověřením vůči cíleným a regresním evalům a posouvat produkt kupředu rychleji než čistě ruční iterační cyklus. 

Níže uvedený příklad pronajímaných nemovitostí ukazuje, jak tato smyčka funguje v praxi, a provede vás tím, jak se oprava od odborníka stane strukturovaným zjištěním, pak cílem evaluace a nakonec vymezeným inženýrským úkolem pro Codex.

Příjem z pronajímané nemovitosti se vykazuje v Schedule E daňového přiznání fyzické osoby. Z inženýrského pohledu je úkol jeho extrakce snadné popsat, ale těžké dobře provést. Systém musí číst neuspořádané zdrojové materiály (ručně psané poznámky, e-maily, tabulky a další klientské soubory), extrahovat pole pro pronajímané nemovitosti, která může s jistotou mapovat do daňového enginu, a zachovat dostatek důkazů, aby odborník mohl výsledek schválit nebo opravit. Níže uvedený zjednodušený příklad ukazuje, jak mohou tyto zdrojové soubory a extrahované výstupy vypadat.

Rozdíl mezi hodnotou předpovězenou agentem a skutečnou hodnotou z podaného daňového přiznání může odrážet skutečné selhání extrakce, ale může jít také o preferenci odborníka, hodnotu vnesenou z přiznání za předchozí rok v daňovém enginu nebo hodnotu zavedenou či změněnou jinde v procesu podání. Odborníci nám pomohli tyto případy rozlišit, abychom mohli určit, které akce vyžadovaly opravu odborníkem nebo blokovaly podání.

Protože jsme tyto opravy mohli detailně sledovat, proměnili jsme proces kontroly z koncového kroku po selhání na průběžný cyklus učení. Navrhli jsme workflow tak, aby zachycovalo kroky expertů jako strukturovaná data. Každý zásah teď napájí smyčku zlepšování produktu tím, že zaznamenává přesně to, co Tax AI navrhla, co odborník upravil a co se nakonec dostalo do podaného přiznání.

U složitého workflow, jako jsou pronajímané nemovitosti, musí systém zachovat, co se děje mezi zdrojovými soubory a podaným přiznáním. Na této cestě se dokumenty organizují, rozdělují a klasifikují; pole pro pronajímané nemovitosti se extrahují s odkazy zpět na zdrojové materiály; tyto hodnoty se mapují do daňového enginu; a odborníci je mohou před podáním ještě opravit. Tyto stopy na úrovni produktu umožňují zkoumat, kde k selhání došlo. Aby se opravy od odborníků proměnily v užitečné cíle evaluace, systém je zpracovává ve třech krocích:

• Zachycení rozdílu: Výstup Tax AI se porovnává s podaným přiznáním, aby vznikly kontrolní řádky na úrovni polí, které zachycují očekávanou hodnotu, předpovězenou hodnotu a to, zda se rozdíl jeví jako využitelný.
• Seskupení souvisejících selhání: Podobné kontrolní řádky se seskupují, aby se oddělila opakující se selhání produktu od očekávaného šumu workflow. Například opakované opravy od odborníků mohou ukázat, že Tax AI často přehlíží pole „počet dnů pronájmu“, špatně zpracovává „ostatní výdaje“ nebo zaměňuje více pronajímaných nemovitostí v rámci stejného zdrojového balíčku.
• Převod opakovaných vzorců na cíle evaluace: Jakmile jsou opakovaná zjištění zkontrolována a změřena, stávají se z nich jasné cíle evaluace pro zlepšování Codexu.

Třetím pilířem je vytvoření inženýrské smyčky schopné na tato nová evaluace reagovat. Právě zde se Codex stává klíčovým.

Představme si, že naše eval pipeline označí, že Tax AI soustavně přehlíží pole „počet dnů pronájmu“, zatímco odborníci je spolehlivě doplňují. Protože toto zjištění už bylo zabaleno do cílené sady evaluací s reprezentativními zdrojovými balíčky a očekávanými výstupy, může Codex zkoumat hlavní příčinu přímo v rámci produktového scaffoldu.

Codex nepracuje jen s podprůměrným finálním výstupem. Zkoumá zároveň stopu, eval, úložiště a dovednosti:

• Prošetři pipeline: Prohlédni zdrojové balíčky, extrakční schémata, chování mapperu a cesty v kódu, abys mohl zjistit, zda je problém v nepodporovaném poli, přehlédnutém vzorci extrakce, zda je problém s výběrem zdroje, s mezerou v mapperu nebo v hodnoticím nástroji.
• Implementuj cílené opravy: Rozšiř extrakční schéma, zlepši výběr zdroje pro dokumenty k pronajímaným nemovitostem, aktualizujte mapper daňového enginu nebo zpřesni hodnoticí nástroj, pokud se očekávaný šum workflow počítá jako selhání.
• Ověř a navrhni: Znovu spusť cílený eval, spusť širší regresní sady a předlož kandidátní žádost o přijetí změn ke kontrole vývojářům.
• Uzavři smyčku: Proměň opakující se opravu od odborníka v měřitelný vývojářský úkol. Pokud jsou důkazy nejednoznačné nebo je nelze bezpečně automatizovat, případ se vrátí produktovému týmu místo toho, aby byl silou protlačen smyčkou.

Příklad pronajímané nemovitosti je příznačný pro širší, opakovaně použitelný vzorec: využití produkčních artefaktů a stop ke zlepšení schopností agenta. Dostane-li Codex jako vstupy zkontrolovaná zjištění z produkčních dat, zdrojové stopy, očekávaný výstup daňového enginu, relevantní příklady kódu a eval příkazy, může v průběhu týdnů a měsíců podstatně zlepšit výkon i přesnost. To navazuje na principy popsané v naší práci o harness engineeringu a Symphony, které ukazují, jak úkoly pro Codex zpřehlednit, jak poskytnout vymezený kontext a nástroje a zachovat validaci i lidskou kontrolu jako součást prostředí. 

Tyto důkazy se nestávají úkolem pro Codex automaticky. Oprava od odborníka může odrážet selhání extrakce, problém mapování, nepodporované chování produktu, daňový úsudek nebo očekávaný šum workflow. Teprve poté, co jsou opakované rozdíly zkontrolovány a seskupeny do využitelného zjištění, je systém promění v ohraničený úkol s jasnou podmínkou úspěchu.

Tuto automatizaci používáme na ohraničenou vrstvu produktu. Tato vrstva provádí extrakci a mapuje zdrojové dokumenty do daňových workflow. Inženýři nadále odpovídají za architekturu, produktová rozhodnutí a nasazování. Odborníci řídí smyčku zlepšování prostřednictvím práce, kterou už dělají: opravují extrahované hodnoty, kontrolují přiznání a schvalují finální podání.

Pro Codex není výsledkem vágní upozornění, ale vymezený inženýrský úkol s důkazy, upravitelnými plochami produktu a explicitními validačními branami. Kontext reprezentativního úkolu pro pronajímanou nemovitost lze shrnout takto:

Stejná smyčka platí i mimo pronajímané nemovitosti. Pronajímané nemovitosti vyžadovaly asi šest týdnů a značný inženýrský dohled, aby dosáhly 90% přesnosti a úplnosti, ale tato práce vytvořila znovu použitelná abstrakta, kontrolní artefakty, eval konvence a implementační vzory, které usnadnily podporu podobně složitých příloh, jako jsou Schedule C a Schedule A.

Tax AI ukazuje cestu k budování sebezdokonalujících se agentů. Odborníci vytvářejí vysoce hodnotné signály zpětné vazby tím, že službu poskytují. Produktová workflow tyto signály uchovávají jako strukturované důkazy. Inženýrské systémy podložené evaly ověřují zlepšení předtím, než se dostanou do produkce, a smyčka poháněná agentem udržuje systém v nepřetržitém toku sebezdokonalování. 

Struktura Thrive Holdings nám umožňuje toto prostředí replikovat v konkrétních odvětvích. Holdings je zároveň vlastník i operátor, takže naše spojené inženýrské týmy mohou pracovat přímo s odborníky a produkčními daty uvnitř firem, jako je Crete, nikoli jako dodavatel, ale jako partneři. To znamená, že technologie, produkt i služba jsou pod jednou střechou, což nám pomáhá postupovat rychleji a vytvářet výjimečné produkty.

Jedna seniorní účetní, která loni strávila přípravou daní 180 hodin, touto činností letos strávila jen 15 hodin. Část tohoto času využila k tomu, že zavolala každému ze svých klientů a prošla s ním jeho přiznání. Dodala tím svým službám velmi osobní nádech, což před rokem nebylo možné. Zbytek času využila k přibrání nových klientů a rozšíření nabídky služeb.

Naše týmy nyní společně používají stejný třídílný návrh z Tax AI jako plán pro budování workflow v dalších oblastech napříč Thrive Holdings⁠(otevře se v novém okně); v účetních workflow, jako je vedení účetnictví a audit, i v provozních workflow, jako je automatizace IT helpdesku. Napříč oblastmi a odvětvími se širší příslib sebezdokonalujících se agentů osvědčuje. Nejlepší agenti jsou vedeni lidmi tak, aby se postupně učili být schopnější, důvěryhodnější a hodnotnější.

Chcete-li se dozvědět více o týmu OpenAI, který na tomto projektu pracoval, ozvěte se nám.