Kaip su „Codex“ kurti save tobulinančius mokesčių agentus

Kaip „Thrive Holdings“ ir „OpenAI“ kartu sukūrė „Tax AI“ „Crete“ buhalteriams, sujungdami specialistų kompetenciją su „Codex“ valdomu ciklu

Realiame pasaulyje veikiančios sistemos gamyboje elgiasi kitaip nei laboratorijoje ir sugenda būdais, kuriuos prieš diegimą sunku numatyti. Komandos dažnai atranda šias nesėkmes po paleidimo, tada savaites praleidžia nagrinėdamos kraštinius atvejus, koreguodamos užklausas ir versdamos gamybinį grįžtamąjį ryšį ilgalaikiais produkto patobulinimais. Grįžtamojo ryšio ciklas – rankinis ir lėtas, o gerėja tik tada, kai jį pastumia inžinierius. Tačiau šiandien, turint apgalvotai sukurtą vertinimų infrastruktūrą, tiesioginę prieigą prie specialistų ir realių aplinkų bei pažangias „Codex“ agentines galimybes, galima kurti save tobulinančius agentus.

Šiame įraše paaiškinsime, kaip naudojome „Codex“ tokiam agentui sukurti. Per pastaruosius šešis mėnesius „OpenAI“ į klientų aplinką deleguoti inžinieriai ir tyrėjai kartu su „Thrive Holdings“ inžinieriais bendradarbiavo kurdami „Tax AI“, skirtą „Crete“⁠(atsidaro naujame lange) 30+ apskaitos įmonių tinklui ir vystomą kartu su juo, kad padėtų rengti vis sudėtingesnes mokesčių deklaracijas. Užuot pasikliovęs inžinieriais, kad šie rastų ir ištaisytų kiekvieną nesėkmę, „Tax AI“ naudoja „Codex“, kad gamybinį naudojimą paverstų struktūruotais signalais, skatinančiais autonominį tobulėjimą.

„Crete“ specialistai kiekvieną sezoną parengia dešimtis tūkstančių mokesčių deklaracijų, o tam reikia apdoroti milijonus pagrindinių dokumentų. Vidutinio ir didelio sudėtingumo pateikimuose vien duomenų įvedimas gali užtrukti aštuonias valandas vienai deklaracijai, dažnai apimdamas netvarkingus duomenų šaltinius, ankstesnių metų dokumentus ir rankinį ištraukimą bei skaičiavimą. Jie nurodė, kad mokesčių rengimas yra reikšminga kliūtis intensyviausiu mokesčių sezono laikotarpiu.

Siekdamas išspręsti šią problemą, „Tax AI“ šį mokesčių sezoną apdorojo 7 000 mokesčių deklaracijų „Crete“ įmonėse, dalyvavusiose bandomajame projekte. Sistema automatizuoja didelę dalį daug laiko reikalaujančio 1040 ir 1041 mokesčių deklaracijų rengimo proceso, tačiau dar įspūdingiau už efektyvumo prieaugį yra tai, kad pati sistema – išmatuojamai geresnė už versiją, kuri pirmą kartą buvo įdiegta prieš tris mėnesius.

„Tax AI“ sistemoje specialistai įkelia šaltinio failus kartu su bet kokiomis konkrečiam klientui skirtomis pastabomis. Tada „Tax AI“ sukuria mokesčių variklio pateikimą, paruoštą peržiūrai. Tai sutaupo specialistams apie trečdalį mokesčių rengimui skiriamo laiko, parengia deklaracijų juodraščius iki 97 % tikslumu ir padidina pralaidumą maždaug 50 %, suteikdamas daugiau galimybių skirti laiko klientams. 

Šį pagerėjimą galime kiekybiškai įvertinti suprasdami, kaip tiksliai „Tax AI“ gali užbaigti deklaraciją be vėliau reikalingų pataisų. Tikslumą matuojame tikrindami, kokia dalis deklaracijų pasiekia 75 %, 90 % arba 100 % teisingą laukų užpildymą. Paleidimo metu tik ketvirtadalis deklaracijų pasiekė 75 % teisingą laukų užpildymą, tačiau per šešias savaites šią ribą pasiekė 86 %. Sistema dar sparčiau augo 90 % ir 100 % teisingo laukų užpildymo lygiuose. Šios ribos suteikia praktinį vaizdą, kiek papildomo specialistų darbo dar reikia skirtingoms deklaracijoms. 

Iš pradžių „Tax AI“ tvarkė paprastesnį darbą, pavyzdžiui, W-2 ir 1099 formas. Sezonui tęsiantis, jis perėjo prie sudėtingesnių deklaracijų su K-1, priedais ir sunkesniais kraštiniais atvejais. Kiekviena nauja galimybė sutaupė daugiau laiko vienai deklaracijai nei ankstesnė, nes perimtos užduotys buvo sunkesnės ir rankiniu būdu užimdavo daugiau laiko. Ir šiandien toliau matome nuolatinę pažangą.

Toliau paaiškinsime, kaip mūsų komandos kartu kūrė „Tax AI“ taip, kad jis save tobulintų, remdamosi trimis esminiais ramsčiais: 1) ekspertų specialistų grįžtamuoju ryšiu, 2) gamybinėmis sekomis (struktūruota istorija nuo įvesčių iki galutinės išvesties) ir 3) „Codex“ valdomu iteracijų ciklu, paremtu pritaikytais vertinimais, kad būtų galima nuolat ir greičiau vystyti produktą. Tikimės, kad mūsų patirtis bus naudinga kitiems kūrėjams srityse, kur specialistų kompetencija yra svarbi formuojant visos sistemos ir per ją tekančių duomenų kokybę.

Kai ėmėmės sudėtingesnių mokesčių rengimo dalių (K-1, nuomojamo nekilnojamojo turto priedų ir mokesčių formų, kuriose reikėjo suderinti vertes iš kelių šaltinio failų), tapo akivaizdu, kad tikrasis iššūkis yra tai, ar produktas gali padaryti sudėtingas gamybines nesėkmes matomas, suprantamas ir paverčiamas veiksmais.

Produkto gyvavimo pradžioje didžioji dalis taisymų buvo atliekama rankiniu būdu. Specialistai galėjo taisyti sistemos klaidas, tačiau produktas nefiksavo viso konteksto: prieš pateikimą pakeista vertė galėjo reikšti tikrą ištraukimo klaidą, susiejimo problemą, trūkstamą produkto palaikymą arba tikėtiną darbo eigos triukšmą. Šių atvejų išrūšiavimui vis tiek reikėjo tolesnio inžinerinės komandos darbo. Inžinieriai galėjo naudoti kodavimo agentus, tačiau sistema dar nebuvo sukurta taip, kad prasmingai naudotų DI tobulinimo cikle. Neturėjome signalo, kuris padėtų nustatyti tinkamą įveikiamą tikslą.

Tai paskatino mus kurti sistemą remiantis trimis ramsčiais:

1. Glaudus ryšys su specialistais: žmonės, atliekantys darbą, turi nukreipti tai, ko produktas mokosi. Jų intuicija ir supratimas atskleidžia, kurios klaidos svarbios, ir padeda nuspręsti, į kurias darbo eigos dalis verta sutelkti dėmesį toliau.
2. Produkto kūrimas taip, kad gamyba kurtų įrodymus: produktas turi fiksuoti ne tik įvestis ir išvestis; jis turi fiksuoti visą kelią nuo šaltinio medžiagos iki ištrauktų laukų ir kilmės, iki paskesnio pateikimo ir eksperto pataisos.
3. „Codex“ valdomo tobulinimo ciklo sukūrimas: kai gamybinės problemos tampa matomos ir struktūruotos, jos gali virsti išvadomis, pritaikytais vertinimais ir aprėžtomis inžinerinėmis užduotimis. Tada „Codex“ gali padėti tirti, siūlyti pakeitimus, tikrinti juos pagal tikslinius ir regresinius vertinimus ir stumti produktą pirmyn greičiau nei vien rankinis iteracijų ciklas. 

Toliau pateiktas nuomojamo turto pavyzdys parodo, kaip šis ciklas veikia praktikoje, žingsnis po žingsnio paaiškindamas, kaip specialisto pataisa tampa struktūruota išvada, tada vertinimo tikslu ir galiausiai „Codex“ aprėžta inžinerine užduotimi.

Nuomojamo turto pajamos nurodomos individualios mokesčių deklaracijos „Schedule E“ formoje. Inžineriniu požiūriu jų ištraukimo užduotį paprasta apibūdinti, bet sunku gerai atlikti. Sistema turi perskaityti netvarkingą šaltinio medžiagą (rankraštines pastabas, el. laiškus, skaičiuokles ir kitus klientų failus), ištraukti nuomojamo turto laukus, kuriuos sistema gali užtikrintai susieti su mokesčių varikliu, ir išsaugoti pakankamai įrodymų, kad specialistas galėtų patvirtinti arba pataisyti rezultatą. Toliau pateiktas supaprastintas pavyzdys rodo, kaip gali atrodyti tie šaltinio failai ir ištrauktos išvestys.

Skirtumas tarp agento prognozuotos vertės ir faktinės pateiktos mokesčių deklaracijos vertės gali rodyti tikrą ištraukimo klaidą, bet taip pat gali būti specialisto pasirinkimas, iš ankstesnių metų deklaracijos mokesčių variklyje perkelta vertė arba kitur deklaravimo eigoje įvesta ar pakeista vertė. Specialistai padėjo mums atskirti šiuos atvejus, kad galėtume nustatyti, kuriems veiksmams reikėjo specialisto pataisos arba kurie blokavo pateikimą.

Kadangi galėjome detaliai matyti šias pataisas, peržiūros procesą pavertėme iš galutinio žingsnio po nesėkmės į nuolatinį mokymosi ciklą. Sukūrėme darbo eigą taip, kad ji fiksuotų ekspertų veiksmus kaip struktūruotus duomenis. Dabar kiekviena intervencija maitina produkto tobulinimo ciklą, tiksliai užfiksuodama, ką pasiūlė „Tax AI“, ką pakeitė specialistas ir kas galiausiai pateko į pateiktą deklaraciją.

Sudėtingoje darbo eigoje, tokioje kaip nuomojamas turtas, sistema turi išsaugoti tai, kas vyksta tarp šaltinio failų ir pateiktos deklaracijos. Šiame kelyje dokumentai organizuojami, skaidomi ir klasifikuojami; nuomojamo turto laukai ištraukiami su nuorodomis į šaltinio medžiagą; šios vertės susiejamos su mokesčių varikliu; o specialistai prieš pateikimą vis dar gali jas pataisyti. Šios produkto lygmens sekos leidžia ištirti, kur įvyko nesėkmė. Kad specialisto pataisas paverstų naudingais vertinimo tikslais, sistema jas apdoroja trimis žingsniais:

• Skirtumo fiksavimas: „Tax AI“ išvestis lyginama su pateikta deklaracija, kad būtų sukurtos laukų lygmens peržiūros eilutės, fiksuojančios tikėtiną vertę, prognozuotą vertę ir tai, ar pagal skirtumą galima imtis veiksmų.
• Susijusių nesėkmių grupavimas: panašios peržiūros eilutės grupuojamos, kad būtų atskirtos pasikartojančios produkto nesėkmės nuo tikėtino darbo eigos triukšmo. Pavyzdžiui, pasikartojančios specialistų pataisos gali parodyti, kad „Tax AI“ dažnai praleidžia „nuomos už rinkos kainą dienų“ laukus, netinkamai tvarko „kitas išlaidas“ arba painioja kelis nuomojamus objektus tame pačiame šaltinio pakete.
• Pasikartojančių dėsningumų pavertimas vertinimo tikslais: peržiūrėjus ir išmatavus, pasikartojančios išvados tampa aiškiais „Codex“ vertinimo tikslais tobulėjimui.

Trečiasis ramstis – sukurti inžinerinį ciklą, galintį veikti pagal šiuos naujus vertinimus. Čia „Codex“ tampa esminiu.

Tarkime, mūsų vertinimų konvejeris pažymi, kad „Tax AI“ nuosekliai praleidžia lauką „nuomos už rinkos kainą dienos“, o specialistai jį patikimai užpildo. Kadangi ši išvada jau supakuota į tikslinį vertinimų rinkinį su reprezentatyviais šaltinio paketais ir tikėtinomis išvestimis, „Codex“ gali tiesiogiai tirti pagrindinę priežastį produkto karkase.

„Codex“ nedirba vien tik su prasta galutine išvestimi. Jis kartu nagrinėja seką, vertinimą, saugyklą ir įgūdžius:

• Konvejerio tyrimas: patikrinti šaltinio paketus, ištraukimo schemas, susiejimo priemonės elgseną ir kodo kelius, kad būtų nustatyta, ar problema – nepalaikomas laukas, praleistas ištraukimo dėsningumas, šaltinio parinkimo problema, susiejimo priemonės spraga ar vertintojo problema.
• Tikslinių pataisų įgyvendinimas: išplėsti ištraukimo schemą, pagerinti nuomojamo turto dokumentų šaltinio parinkimą, atnaujinti mokesčių variklio susiejimo priemonę arba patobulinti vertintoją, jei tikėtinas darbo eigos triukšmas skaičiuojamas kaip nesėkmė.
• Patvirtinimas ir siūlymas: iš naujo paleisti tikslinį vertinimą, vykdyti platesnius regresijos rinkinius ir pateikti kandidatinę „pull request“ užklausą inžinerinei peržiūrai.
• Ciklo užbaigimas: paversti pasikartojančią specialisto pataisą išmatuojama inžinerine užduotimi. Jei įrodymai neaiškūs arba jų negalima saugiai automatizuoti, atvejis grąžinamas produkto komandai, o ne priverstinai stumiamas per ciklą.

Nuomojamo turto pavyzdys atspindi platesnį pakartotinai naudojamą dėsningumą: gamybinių artefaktų ir sekų naudojimą agento gebėjimams gerinti. Turėdamas peržiūrėtas išvadas iš gamybinių duomenų, šaltinio sekas, tikėtiną mokesčių variklio išvestį, susijusius kodo pavyzdžius ir vertinimų komandas kaip įvesčių rinkinį, „Codex“ gali per savaites ir mėnesius reikšmingai pagerinti našumą ir tikslumą. Tai remiasi principais, aprašytais mūsų darbuose apie testavimo karkaso inžineriją ir „Symphony“, kuriuose paaiškinama, kaip padaryti užduotis suprantamas „Codex“, pateikti aprėžtą kontekstą ir įrankius bei išlaikyti validavimą ir žmonių peržiūrą aplinkos dalimi. 

Šie įrodymai automatiškai netampa „Codex“ užduotimi. Specialisto pataisa gali atspindėti ištraukimo klaidą, susiejimo problemą, nepalaikomą produkto elgseną, mokestinį sprendimą arba tikėtiną darbo eigos triukšmą. Tik po to, kai pasikartojantys skirtumai peržiūrimi ir sugrupuojami į pritaikomą išvadą, sistema paverčia juos apribota užduotimi su aiškia sėkmės sąlyga.

Šią automatizaciją taikome apribotam produkto sluoksniui. Šis sluoksnis atlieka ištraukimą ir susieja šaltinio dokumentus su mokesčių darbo eigomis. Inžinieriai išlieka atsakingi už architektūrą, produkto sprendimus ir išleidimą. Specialistai nukreipia tobulinimo ciklą per jau atliekamą darbą: taisydami ištrauktas vertes, peržiūrėdami deklaracijas ir tvirtindami galutinius pateikimus.

„Codex“ atveju rezultatas – ne miglotas įspėjimas, o aprėžta inžinerinė užduotis su įrodymais, redaguojamais produkto paviršiais ir aiškiais validavimo vartais. Reprezentatyvios nuomojamo turto užduoties kontekstą galima apibendrinti taip:

Tas pats ciklas taikomas ir už nuomojamo turto ribų. Nuomojamam turtui pasiekti 90 % tikslumą ir išsamumą prireikė maždaug šešių savaičių ir reikšmingos inžinerinės priežiūros, tačiau šis darbas sukūrė pakartotinai naudojamas abstrakcijas, peržiūros artefaktus, vertinimų konvencijas ir įgyvendinimo dėsningumus, kurie palengvino panašiai sudėtingų formų, tokių kaip „Schedule C“ ir „Schedule A“, palaikymą.

„Tax AI“ parodo kelią kuriant save tobulinančius agentus. Specialistai, teikdami paslaugą, generuoja didelės vertės grįžtamojo ryšio signalus. Produkto darbo eigos išsaugo šiuos signalus kaip struktūruotus įrodymus. Vertinimais paremti inžineriniai sprendimai patvirtina patobulinimus prieš jiems pasiekiant gamybą, o agento valdomas ciklas palaiko sistemą nuolatiniame savęs tobulinimo sraute. 

„Thrive Holdings“ struktūra leidžia mums atkartoti šią aplinką konkrečiose pramonės šakose. „Holdings“ – ir savininkas, ir operatorius, todėl mūsų jungtinės inžinerinės komandos gali tiesiogiai dirbti su specialistais ir gamybiniais duomenimis tokių verslų kaip „Crete“ viduje ne kaip tiekėjai, o kaip partneriai. Tai reiškia, kad technologija, produktas ir paslauga – po vienu stogu, todėl galime judėti greičiau ir kurti išskirtinius produktus.

Viena vyresnioji buhalterė, kuri pernai mokesčių rengimui skyrė 180 valandų, šiemet tam skyrė tik 15 valandų. Dalį to laiko ji skyrė tam, kad paskambintų kiekvienam savo klientui ir kartu peržiūrėtų jų deklaracijas – tokio aukšto lygio asmeninis aptarnavimas prieš metus nebuvo įmanomas. Likusią to laiko dalį ji panaudojo naujiems klientams pritraukti ir naujiems paslaugų pasiūlymams plėsti.

Dabar mūsų komandos kartu naudoja tą patį trijų dalių „Tax AI“ dizainą kaip planą, skirtą kurti darbo eigoms kitose srityse visoje „Thrive Holdings“⁠(atsidaro naujame lange): apskaitos darbo eigoms (pvz., buhalterinei apskaitai ir auditui) bei operacinėms darbo eigoms (pvz., IT pagalbos tarnybos automatizavimui). Visose srityse ir pramonės šakose platesnis save tobulinančių agentų pažadas išlieka. Geriausi agentai yra žmonių nukreipiami mokytis ir laikui bėgant tapti pajėgesni, patikimesni ir vertingesni.

Norėdami sužinoti daugiau apie „OpenAI“ komandą, dirbusią prie šio projekto, susisiekite.