Önfejlesztő adóügynökök építése Codexszel

Hogyan fejlesztette együtt a Thrive Holdings és az OpenAI a Tax AI-t a Crete könyvelői számára a szakértői tudás és egy Codex-vezérelt ciklus ötvözésével

A valós rendszerek éles környezetben másként viselkednek, mint laborban, és olyan módokon hibásodnak meg, amelyeket a bevezetés előtt nehéz előre látni. A csapatok gyakran csak az indulás után fedezik fel ezeket a hibákat, majd heteket töltenek szélső esetek vizsgálatával, utasítások igazításával és az éles visszajelzések tartós termékfejlesztéssé fordításával. A visszacsatolási ciklus kézi és lassú, és csak akkor javul, ha egy mérnök előreviszi. Ma azonban átgondoltan megtervezett eval-infrastruktúrával, közvetlen hozzáféréssel a szakértőkhöz és a valós környezetekhez, valamint a Codex élvonalbeli ügynöki képességeivel önfejlesztő ügynököket lehet építeni.

Ebben a bejegyzésben bemutatjuk, hogyan használtuk a Codexet ilyen típusú ügynök felépítésére. Az elmúlt hat hónapban az OpenAI kihelyezett mérnökei és kutatói, valamint a Thrive Holdings mérnökei együttműködve építették a Tax AI-t a Crete⁠(új ablakban nyílik meg) több mint 30 könyvelőirodából álló hálózatával és számára, hogy segítsenek az egyre összetettebb adóbevallások elkészítésében. Ahelyett, hogy a mérnökökre támaszkodna minden egyes hiba megtalálásában és kijavításában, a Tax AI a Codexet használja arra, hogy az éles használatot strukturált jelekké alakítsa, amelyek az autonóm fejlődést táplálják.

A Crete szakértői minden szezonban adóbevallások tízezreit készítik el, ami több millió mögöttes dokumentum feldolgozását igényli. Közepes és nagy összetettségű bevallásoknál már önmagában az adatrögzítés is nyolc órát vehet igénybe bevallásonként, gyakran rendezetlen adatforrásokkal, előző évi dokumentumokkal, valamint kézi kinyeréssel és számítással. Rámutattak, hogy az adóelőkészítés jelentős szűk keresztmetszet a szezon legforgalmasabb időszakában.

A probléma megoldására a Tax AI ebben az adószezonban 7000 adóbevallást dolgozott fel a pilotban részt vevő Crete-irodákban. A rendszer automatizálja az 1040-es és 1041-es adóbevallások elkészítésének időigényes folyamatának nagy részét, de a hatékonyságnövekedésnél is meggyőzőbb, hogy maga a rendszer mérhetően jobb, mint a három hónappal ezelőtt először bevezetett változat.

A Tax AI-ban a szakértők feltöltik a forrásfájlokat az ügyfélspecifikus megjegyzésekkel együtt. A Tax AI ezután létrehoz egy adómotorhoz benyújtható csomagot, amely készen áll a felülvizsgálatra. Körülbelül a harmadával csökkenti a szakértők adóelőkészítésre fordított idejét, akár 97%-os pontossággal készít bevallástervezeteket, és mintegy 50%-kal növeli az adatátviteli egységet, így több idejük marad az ügyfelekre. 

Ezt a fejlődést úgy tudjuk számszerűsíteni, hogy megértjük, a Tax AI milyen pontossággal tud egy bevallást későbbi javítás nélkül kitölteni. A pontosságot úgy mérjük, hogy megnézzük, a bevallások mekkora része éri el a mezők 75%-os, 90%-os vagy 100%-os helyes kitöltését. Induláskor a bevallásoknak csak a negyede érte el a mezők 75%-os helyes kitöltését, de hat héten belül ez az arány 86%-ra nőtt. A rendszer még gyorsabb növekedést mutatott a 90%-os és 100%-os helyes mezőkitöltési szinteken. Ezek a küszöbök gyakorlati képet adnak arról, hogy a különböző bevallások mennyi utólagos szakértői munkát igényelnek még. 

Kezdetben a Tax AI egyszerűbb feladatokat kezelt, például W-2-ket és 1099-eseket. Ahogy telt a szezon, összetettebb bevallásokra tért át K-1-ekkel, mellékletekkel és nehezebb szélső esetekkel. Minden új képesség több időt takarított meg bevallásonként, mint az előző, mert az átvett feladatok nehezebbek és kézzel időigényesebbek voltak. Ma is folyamatos előrelépést látunk.

Ezután bemutatjuk, hogyan tervezték közösen csapataink a Tax AI-t önfejlesztővé három kritikus pillérre támaszkodva: 1) szakértői visszajelzés, 2) éles nyomok (strukturált előzmény a bemenetektől a végső kimenetig), és 3) egy Codex-vezérelt iterációs ciklus testre szabott evalokkal a folyamatos és gyorsabb termékfejlesztés érdekében. Reméljük, hogy tapasztalataink hasznosak lesznek más építők számára is olyan területeken, ahol a szakértői tudás kulcsfontosságú az átfogó rendszer és a benne futó adatok minőségének alakításában.

Ahogy az adóelőkészítés nehezebb részei felé haladtunk (K-1-ek, bérbeadott ingatlanok mellékletei és olyan adóűrlapok, ahol az értékeket több forrásfájl között kellett egyeztetni), nyilvánvalóvá vált, hogy az igazi kihívás az, képes-e a termék láthatóvá, érthetővé és kezelhetővé tenni az összetett éles hibákat.

A termék korai időszakában a javítások többsége kézi volt. A szakértők kijavíthatták a rendszer hibáit, de a termék nem rögzítette a teljes kontextust: a benyújtás előtti módosított érték tükrözhetett valódi kinyerési hibát, leképezési problémát, hiányzó terméktámogatást vagy várható munkafolyamat-zajt. Ezeknek az eseteknek a szétválogatása továbbra is a mérnöki csapat utókövetését igényelte. A mérnökök használhattak kódoló ügynököket, de a rendszert még nem úgy terveztük, hogy az MI-t érdemben használja egy fejlesztési cikluson belül. Nem volt meg a jelünk ahhoz, hogy azonosítsuk a megfelelő megmászandó hegyet.

Ez arra vezetett minket, hogy a rendszert három pillér köré tervezzük:

1. Maradjunk közel a szakértőkhöz: Azoknak kell irányítaniuk, mit tanul a termék, akik a munkát végzik. Az intuíciójuk és megértésük feltárja, mely hibák számítanak, és segít meghatározni, a munkafolyamat mely részeire érdemes legközelebb összpontosítani.
2. Úgy építsük fel a terméket, hogy az éles használat bizonyítékot hozzon létre: A terméknek nemcsak a bemeneteket és kimeneteket kell rögzítenie; a teljes utat is meg kell őriznie a forrásanyagtól a kinyert mezőkön és eredetükön át a későbbi benyújtásig és szakértői javításig.
3. Hozzunk létre Codex-vezérelt fejlesztési ciklust: Ha az éles problémák láthatóvá és strukturálttá válnak, megállapításokká, testre szabott evalokká és körülhatárolt mérnöki feladatokká alakíthatók. A Codex ezután segíthet a vizsgálatban, változtatások javaslatában, ezek célzott és regressziós evalokkal való validálásában, és gyorsabban viheti előre a terméket, mint egy tisztán kézi iterációs ciklus. 

Az alábbi bérbeadott ingatlanos példa megmutatja, hogyan működik ez a ciklus a gyakorlatban: végigvezet azon, miként lesz egy szakértői javításból strukturált megállapítás, majd eval-cél, végül pedig a Codex számára körülhatárolt mérnöki feladat.

A bérbeadott ingatlanból származó jövedelmet az egyéni adóbevallás Schedule E mellékletén jelentik. Mérnöki szempontból a kinyerés feladata egyszerűen leírható, de nehéz jól megvalósítani. A rendszernek rendezetlen forrásanyagot kell olvasnia (kézzel írt jegyzeteket, e-maileket, táblázatokat és más ügyfélfájlokat), ki kell nyernie azokat a bérbeadott ingatlanos mezőket, amelyeket a rendszer magabiztosan le tud képezni az adómotorra, és elegendő bizonyítékot kell megőriznie ahhoz, hogy egy szakértő jóváhagyhassa vagy kijavíthassa az eredményt. Az alábbi egyszerűsített példa megmutatja, hogyan nézhetnek ki ezek a forrásfájlok és kinyert kimenetek.

Az ügynök által előre jelzett érték és a benyújtott adóbevallás tényleges értéke közötti eltérés valódi kinyerési hibát jelezhet, de lehet szakértői preferencia, az adómotorban az előző évi bevallásból áthozott érték, vagy a bevallási folyamat más pontján bevezetett vagy módosított érték is. A szakértők segítettek megkülönböztetni ezeket az eseteket, hogy azonosíthassuk, mely műveletek igényeltek szakértői javítást vagy akadályozták a benyújtást.

Mivel ezeket a javításokat részletesen láthattuk, a felülvizsgálati folyamatot egy végső, hiba utáni lépésből folyamatos tanulási ciklussá alakítottuk. A munkafolyamatot úgy terveztük meg, hogy a szakértői műveleteket strukturált adatként rögzítse. Most minden beavatkozás táplálja a termék fejlesztési ciklusát azzal, hogy pontosan rögzíti, mit javasolt a Tax AI, mit módosított a szakértő, és mi került végül a benyújtott bevallásba.

Egy összetett munkafolyamatnál, mint a bérbeadott ingatlanoké, a rendszernek meg kell őriznie, mi történik a forrásfájlok és a benyújtott bevallás között. Ezen az úton a dokumentumokat rendszerezi, felosztja és osztályozza; a bérbeadott ingatlanok mezőit a forrásanyagokra visszamutató hivatkozásokkal nyeri ki; ezeket az értékeket az adómotorba képezi le; és a szakértők még a benyújtás előtt is javíthatják őket. Ezek a termékszintű nyomok lehetővé teszik annak vizsgálatát, hol történt a hiba. Ahhoz, hogy a szakértői javításokból hasznos értékelési célok legyenek, a rendszer három lépésben dolgozza fel őket:

• Az eltérés rögzítése: A Tax AI kimenetét összevetjük a benyújtott bevallással, hogy mezőszintű felülvizsgálati sorok jöjjenek létre, amelyek rögzítik a várt értéket, az előre jelzett értéket, és azt, hogy az eltérés hasznosíthatónak tűnik-e.
• Kapcsolódó hibák csoportosítása: A hasonló felülvizsgálati sorokat csoportosítjuk, hogy elkülönítsük a visszatérő termékhibákat a várható munkafolyamat-zajtól. Például az ismétlődő szakértői javítások azt mutathatják, hogy a Tax AI gyakran kihagyja a „fair rental days” mezőket, rosszul kezeli az „other expenses” kategóriát, vagy összekever több bérbeadott ingatlant ugyanazon forráscsomagon belül.
• Az ismétlődő minták értékelési célokká alakítása: Miután felülvizsgáltuk és mértük őket, az ismétlődő megállapítások egyértelmű eval-célokká válnak, amelyeken a Codex javíthat.

A harmadik pillér egy olyan mérnöki ciklus létrehozása, amely képes cselekedni ezekre az új evalokra. Itt válik a Codex központi elemmé.

Tegyük fel, hogy az eval-folyamatunk azt jelzi, hogy a Tax AI következetesen kihagyja a „fair rental days” mezőt, miközben a szakértők megbízhatóan kitöltik azt. Mivel ezt a megállapítást már célzott evalkészletbe csomagoltuk, reprezentatív forráscsomagokkal és elvárt kimenetekkel, a Codex közvetlenül a termék vázán belül vizsgálhatja a kiváltó okot.

A Codex nem csupán egy gyenge végső kimenettel dolgozik. Együtt vizsgálja a nyomvonalat, az evalt, az adattárat és a készségeket:

• A folyamat vizsgálata: A forráscsomagok, a kinyerési sémák, a leképező viselkedése és a kódútvonalak vizsgálata annak megállapítására, hogy a probléma nem támogatott mező, kihagyott kinyerési minta, forráskiválasztási gond, leképezési hiányosság vagy értékelői hiba-e.
• Célzott javítások megvalósítása: A kinyerési séma bővítése, a bérbeadott ingatlanok dokumentumainak jobb forráskiválasztása, az adómotor-leképező frissítése, vagy az értékelő finomítása, ha a várható munkafolyamat-zajt hibaként számolja.
• Érvényesítés és javaslattétel: A célzott eval újbóli futtatása, szélesebb regressziós csomagok futtatása, és egy lehetséges lekéréses kérelem előterjesztése mérnöki felülvizsgálatra.
• A ciklus lezárása: Egy visszatérő szakértői javítás mérhető mérnöki feladattá alakítása. Ha a bizonyíték kétértelmű vagy nem automatizálható biztonságosan, az eset visszakerül a termékcsapathoz ahelyett, hogy erőltetve végigvinnénk a cikluson.

A bérbeadott ingatlanos példa egy tágabb, újrahasznosítható mintát testesít meg: termelési artefaktumok és nyomok használatát egy ügynök képességeinek javítására. Ha a bemenetek között szerepelnek az éles adatokból felülvizsgált megállapítások, a forrásnyomok, az elvárt adómotor-kimenet, a releváns kódpéldák és az eval-parancsok, a Codex hetek és hónapok alatt érdemben javíthatja a teljesítményt és a pontosságot. Ez a harness engineeringről és a Symphonyról szóló munkánkban leírt elvekre épül, amelyek bemutatják, hogyan lehet a feladatokat a Codex számára olvashatóvá tenni, körülhatárolt kontextust és eszközöket adni, valamint a validációt és az emberi felülvizsgálatot a környezet részévé tenni. 

Ez a bizonyíték nem válik automatikusan Codex-feladattá. Egy szakértői javítás tükrözhet kinyerési hibát, leképezési problémát, nem támogatott termékviselkedést, adózási megítélést vagy várható munkafolyamat-zajt. Csak azután alakítja a rendszer ezeket körülhatárolt feladattá világos sikerfeltétellel, hogy az ismétlődő eltéréseket felülvizsgálták és hasznosítható megállapítássá csoportosították.

Ezt az automatizálást a termék egy körülhatárolt rétegére alkalmazzuk. Ez a réteg végzi a kinyerést, és a forrásdokumentumokat adózási munkafolyamatokba képezi le. A mérnökök továbbra is felelősek az architektúráért, a termékdöntésekért és a szállításért. A szakértők az általuk már most is végzett munkán keresztül irányítják a fejlesztési ciklust: a kinyert értékek javításával, a bevallások felülvizsgálatával és a végleges benyújtások jóváhagyásával.

A Codex számára az eredmény nem egy homályos riasztás, hanem egy körülhatárolt mérnöki feladat bizonyítékokkal, szerkeszthető termékfelületekkel és kifejezett validációs kapukkal. Egy reprezentatív bérbeadott ingatlanos feladat kontextusa a következőképpen foglalható össze:

Ugyanez a ciklus a bérbeadott ingatlanokon túl is alkalmazható. A bérbeadott ingatlanoknál körülbelül hat hétre és jelentős mérnöki felügyeletre volt szükség a 90%-os precizitás és visszahívás eléréséhez, de ez a munka újrahasznosítható absztrakciókat, felülvizsgálati artefaktumokat, eval-konvenciókat és megvalósítási mintákat hozott létre, amelyek megkönnyítették a hasonlóan összetett mellékletek, például a Schedule C és a Schedule A támogatását.

A Tax AI megmutatja az önfejlesztő ügynökök építésének útját. A szakértők a szolgáltatás nyújtása közben nagy értékű visszajelzési jeleket hoznak létre. A termék munkafolyamatai ezeket a jeleket strukturált bizonyítékként őrzik meg. Az evalokkal alátámasztott mérnöki rendszerek még azelőtt validálják a fejlesztéseket, hogy azok élesbe kerülnének, és egy ügynök által hajtott ciklus folyamatos önfejlesztő működésben tartja a rendszert. 

A Thrive Holdings felépítése lehetővé teszi számunkra, hogy ezt a környezetet meghatározott iparágakban is megismételjük. A Holdings egyszerre tulajdonos és operátor, így egyesített mérnöki csapataink közvetlenül dolgozhatnak szakértőkkel és éles adatokkal olyan vállalkozásokon belül, mint a Crete, nem beszállítóként, hanem partnerként. Ez azt jelenti, hogy a technológia, a termék és a szolgáltatás egy fedél alatt van, ami segít gyorsabban haladni és kivételes termékeket építeni.

Egy vezető könyvelő, aki tavaly 180 órát töltött adóelőkészítéssel, idén már csak 15 órát fordított rá. Ennek az időnek egy részét arra fordította, hogy minden ügyfelét felhívja, és végigvezesse őket a bevallásukon — ilyen szintű személyes szolgáltatás egy évvel ezelőtt még nem volt lehetséges. A fennmaradó időt új ügyfelek vállalására és új szolgáltatások bevezetésére használta.

Csapataink most együtt ugyanazt a háromrészes Tax AI-tervet használják mintaként más területek munkafolyamatainak kialakításához a Thrive Holdingsnál⁠(új ablakban nyílik meg); ilyenek a számviteli munkafolyamatok, például a könyvelés és audit, valamint az operatív munkafolyamatok, például az IT help desk automatizálása. Területeken és iparágakon átívelően az önfejlesztő ügynökök tágabb ígérete érvényes marad. A legjobb ügynököket emberek irányítják, hogy idővel egyre képesebbé, megbízhatóbbá és értékesebbé váljanak.

Ha többet szeretnél megtudni az OpenAI csapatáról, amely ezen a projekten dolgozott, vedd fel velünk a kapcsolatot.