Bygge selvforbedrende skatteagenter med Codex

Hvordan Thrive Holdings og OpenAI utviklet Tax AI sammen for Crete-regnskapsførere ved å forene praktikerkompetanse med en Codex-drevet sløyfe

Systemer i den virkelige verden oppfører seg annerledes i produksjon enn i et laboratorium, og feiler på måter som er vanskelige å forutse før utrulling. Team oppdager ofte disse feilene etter lansering, og bruker deretter uker på å undersøke kanttilfeller, justere prompter og oversette tilbakemeldinger fra produksjon til varige produktforbedringer. Tilbakemeldingssløyfen er manuell og treg, og forbedres bare når en ingeniør driver den fremover. Men i dag, med gjennomtenkt evalueringsinfrastruktur, direkte tilgang til praktikere og virkelige miljøer, og de fremste agentiske evnene i Codex, kan du bygge agenter som forbedrer seg selv.

I dette innlegget skal vi forklare hvordan vi brukte Codex til å bygge denne typen agent. De siste seks månedene har OpenAIs utsendte ingeniører og forskere, sammen med ingeniørene i Thrive Holdings, samarbeidet om å bygge Tax AI sammen med og for nettverket til Crete⁠(åpnes i et nytt vindu) med over 30 regnskapsfirmaer for å hjelpe til med å utarbeide stadig mer komplekse skattemeldinger. I stedet for å være avhengig av at ingeniører finner og retter hver enkelt feil, bruker Tax AI Codex til å gjøre bruk i produksjon om til strukturerte signaler som driver autonom forbedring.

Crete-praktikere utarbeider titusenvis av skattemeldinger hver sesong, noe som krever arbeid med millioner av underliggende dokumenter. For innleveringer med middels til høy kompleksitet kan bare dataregistrering ta åtte timer per skattemelding, ofte med rotete datakilder, dokumenter fra tidligere år og manuell ekstraksjon og beregning. De pekte på skatteforberedelse som en betydelig flaskehals i den travleste delen av skattesesongen.

For å løse dette problemet behandlet Tax AI 7 000 skattemeldinger på tvers av Crete-firmaene som deltok i piloten denne skattesesongen. Systemet automatiserer mye av den tidkrevende prosessen med å utarbeide skattemeldinger 1040 og 1041, men enda mer overbevisende enn effektivitetsgevinstene er at selve systemet er målbart bedre enn versjonen som først ble rullet ut for tre måneder siden.

I Tax AI laster praktikere opp kildefiler sammen med eventuelle kundespesifikke notater. Tax AI oppretter deretter en innsending til skattesystemet, klar for gjennomgang. Det sparer praktikere for omtrent en tredel av tiden de bruker på skatteforberedelse, utarbeider skattemeldinger med opptil 97 % nøyaktighet og øker gjennomstrømmingen med rundt 50 %, noe som gir mer rom for å bruke tid med kunder. 

Vi kan kvantifisere denne forbedringen ved å forstå hvor nøyaktig Tax AI kan fullføre en skattemelding uten å trenge korreksjon senere. Vi måler nøyaktighet ved å sjekke hvor stor andel av skattemeldingene som når 75 %, 90 % eller 100 % korrekt feltfullføring. Ved lansering var bare en fjerdedel av skattemeldingene på 75 % korrekt feltfullføring, men innen seks uker nådde 86 % dette nivået. Systemet viste enda raskere vekst på nivåene 90 % og 100 % korrekt feltfullføring. Disse tersklene gir oss et praktisk bilde av hvor mye oppfølging fra praktikere ulike skattemeldinger fortsatt krever. 

Tidlig håndterte Tax AI enklere arbeid, som W-2-er og 1099-er. Etter hvert som sesongen gikk, gikk det over til mer komplekse skattemeldinger med K-1-er, skjemaer og vanskeligere kanttilfeller. Hver nye evne sparte mer tid per skattemelding enn den forrige, fordi oppgavene det tok på seg var vanskeligere og mer tidkrevende å gjøre manuelt. Vi ser fortsatt løpende fremgang i dag.

Deretter går vi gjennom hvordan teamene våre utviklet Tax AI sammen for å gjøre det selvforbedrende ved å lene seg på tre kritiske søyler: 1) tilbakemeldinger fra ekspertpraktikere, 2) produksjonsspor (en strukturert historikk fra inndata til endelig utdata), og 3) en Codex-drevet iterasjonssløyfe basert på skreddersydde evalueringer for å muliggjøre kontinuerlig og raskere produktutvikling. Vi håper erfaringene våre vil være nyttige for andre byggere i domener der praktikerkompetanse er nøkkelen til å forme kvaliteten på det overordnede systemet og dataene som går gjennom det.

Da vi gikk løs på vanskeligere deler av skatteforberedelse (K-1-er, skjemaer for utleieeiendom og skatteformularer der verdier måtte avstemmes på tvers av flere kildefiler), ble det tydelig at den virkelige utfordringen var om produktet kunne gjøre komplekse produksjonsfeil synlige, forståelige og handlingsbare.

I produktets tidlige dager var det meste av korreksjonen manuell. Praktikere kunne korrigere systemfeil, men produktet fanget ikke hele konteksten: en endret verdi før innlevering kunne gjenspeile en reell ekstraksjonsfeil, et mappeproblem, manglende produktstøtte eller forventet støy i arbeidsflyten. Å sortere disse tilfellene krevde fortsatt oppfølging fra ingeniørteamet. Ingeniører kunne bruke kodeagenter, men systemet var ennå ikke utformet for å bruke AI på en meningsfull måte i en forbedringssløyfe. Vi hadde ikke signalet som trengtes for å identifisere den riktige bakken å bestige.

Det fikk oss til å utforme systemet rundt tre søyler:

1. Hold deg tett på praktikere: Folkene som gjør arbeidet, må styre hva produktet lærer. Intuisjonen og forståelsen deres avdekker hvilke feil som betyr noe og bidrar til å informere hvilke deler av arbeidsflyten det er verdt å fokusere på videre.
2. Bygg produktet slik at produksjon skaper bevis: Produktet må fange mer enn bare inndata og utdata; det må fange hele veien fra kildemateriale, til ekstraherte felt og proveniens, til nedstrøms innsending og ekspertkorreksjon.
3. Lag en Codex-drevet forbedringssløyfe: Når produksjonsproblemer er synlige og strukturerte, kan de bli til funn, skreddersydde evalueringer og avgrensede ingeniøroppgaver. Codex kan deretter hjelpe med å undersøke, foreslå endringer, validere dem mot målrettede evalueringer og regresjonsevalueringer, og flytte produktet fremover raskere enn en rent manuell iterasjonssyklus. 

Eksempelet med utleieeiendom nedenfor viser hvordan denne sløyfen fungerer i praksis, og går gjennom hvordan en korreksjon fra en praktiker blir til et strukturert funn, deretter et evalueringsmål, og til slutt en Codex-avgrenset ingeniøroppgave.

Inntekt fra utleieeiendom rapporteres på Schedule E i en personlig skattemelding. Fra et ingeniørperspektiv er oppgaven med å trekke den ut enkel å beskrive, men vanskelig å gjøre godt. Systemet må lese rotete kildemateriale (håndskrevne notater, e-poster, regneark og andre klientfiler), trekke ut feltene for utleieeiendom som systemet trygt kan mappe til skattesystemet, og bevare nok bevis til at en praktiker kan godkjenne eller korrigere resultatet. Det forenklede eksempelet nedenfor viser hvordan disse kildefilene og ekstraherte utdataene kan se ut.

En forskjell mellom verdien agenten forutså og den faktiske verdien i den innsendte skattemeldingen kan gjenspeile en reell ekstraksjonsfeil, men den kan også være en preferanse hos praktikeren, en verdi videreført fra fjorårets skattemelding i skattesystemet, eller en verdi som ble lagt til eller endret et annet sted i innleveringsflyten. Praktikere hjalp oss med å skille disse tilfellene, slik at vi kunne identifisere hvilke handlinger som krevde en korreksjon fra en praktiker eller blokkerte en innsending.

Fordi vi kunne se disse korreksjonene i detalj, forvandlet vi gjennomgangsprosessen fra et avsluttende steg etter feil til en kontinuerlig læringssyklus. Vi utformet arbeidsflyten for å fange eksperthandlinger som strukturerte data. Nå mater hvert inngrep produktets forbedringssløyfe ved å registrere nøyaktig hva Tax AI foreslo, hva praktikeren endret, og hva som til slutt gikk inn i den innsendte skattemeldingen.

For en kompleks arbeidsflyt som utleieeiendommer må systemet bevare det som skjer mellom kildefilene og den innsendte skattemeldingen. Langs denne veien blir dokumenter organisert, delt opp og klassifisert; felt for utleieeiendom trekkes ut med henvisninger tilbake til kildematerialet; disse verdiene mappes inn i skattesystemet; og praktikere kan fortsatt korrigere dem før innlevering. Disse produktsporene gjør det mulig å undersøke hvor en feil oppsto. For å gjøre korreksjoner fra praktikere om til nyttige evalueringsmål, behandler systemet dem i tre trinn:

• Fang forskjellen: Utdataene fra Tax AI sammenlignes med den innsendte skattemeldingen for å lage gjennomgangsrader på feltnivå som fanger opp forventet verdi, predikert verdi og om forskjellen ser ut til å være handlingsbar.
• Grupperelaterte feil: Lignende gjennomgangsrader grupperes for å skille tilbakevendende produktfeil fra forventet støy i arbeidsflyten. For eksempel kan gjentatte korreksjoner fra praktikere vise at Tax AI ofte overser felt for «fair rental days», håndterer «andre utgifter» feil, eller forveksler flere utleieeiendommer i samme kildepakke.
• Gjør gjentatte mønstre om til evalueringsmål: Når de er gjennomgått og målt, blir gjentatte funn tydelige evalueringsmål som Codex kan forbedre.

Den tredje søylen er å skape en ingeniørsløyfe som kan handle på grunnlag av disse nye evalueringene. Det er her Codex blir sentral.

Anta at evalueringspipelinen vår flagger at Tax AI konsekvent overser feltet «fair rental days», mens praktikere pålitelig fyller det inn. Fordi dette funnet allerede er pakket inn i et målrettet evalueringssett, med representative kildepakker og forventede utdata, kan Codex undersøke rotårsaken direkte i produktets rammeverk.

Codex arbeider ikke bare med et sluttresultat av lav kvalitet. Det undersøker sporet, evalueringen, lageret og ferdighetene samlet:

• Undersøk pipelinen: Undersøk kildepakker, ekstraksjonsskjemaer, mapperatferd og kodebaner for å avgjøre om problemet er et felt som ikke støttes, et oversett ekstraksjonsmønster, et problem med kildevalg, et hull i mapperen eller et problem med vurdereren.
• Implementer målrettede rettinger: Utvid ekstraksjonsskjemaet, forbedre kildevalg for dokumenter om utleieeiendom, oppdater mapperen for skattesystemet, eller finjuster vurdereren hvis forventet støy i arbeidsflyten blir telt som en feil.
• Valider og foreslå: Kjør den målrettede evalueringen på nytt, kjør bredere regresjonssuiter, og vis en kandidat-pull-forespørsel for teknisk gjennomgang.
• Lukk sløyfen: Gjør en tilbakevendende korreksjon fra en praktiker om til en målbar ingeniøroppgave. Hvis bevisene er tvetydige eller ikke trygt kan automatiseres, sendes saken tilbake til produktteamet i stedet for å tvinges gjennom sløyfen.

Eksempelet med utleieeiendom er typisk for et bredere gjenbrukbart mønster: å bruke produksjonsartefakter og spor til å forbedre evnene til en agent. Gitt gjennomgåtte funn fra produksjonsdata, kildespor, forventet utdata fra skattesystemet, relevante kodeeksempler og evalueringskommandoer som et sett med inndata, kan Codex forbedre ytelse og nøyaktighet vesentlig over uker og måneder. Dette bygger på prinsippene beskrevet i arbeidet vårt om harness engineering og Symphony, som går gjennom hvordan man gjør oppgaver forståelige for Codex, gir avgrenset kontekst og verktøy, og holder validering og menneskelig gjennomgang som en del av miljøet. 

Dette bevismaterialet blir ikke automatisk en Codex-oppgave. En korreksjon fra en praktiker kan gjenspeile en ekstraksjonsfeil, et mappeproblem, produktatferd som ikke støttes, skattefaglig skjønn eller forventet støy i arbeidsflyten. Først etter at gjentatte forskjeller er gjennomgått og gruppert til et handlingsbart funn, gjør systemet dem om til en avgrenset oppgave med en tydelig suksessbetingelse.

Vi bruker denne automatiseringen på et avgrenset lag av produktet. Dette laget utfører ekstraksjon og mapper kildedokumenter inn i skattearbeidsflyter. Ingeniører har fortsatt ansvar for arkitektur, produktbeslutninger og lansering. Praktikere styrer forbedringssløyfen gjennom arbeidet de allerede gjør: korrigerer ekstraherte verdier, gjennomgår skattemeldinger og godkjenner endelige innleveringer.

For Codex er resultatet ikke et vagt varsel, men en avgrenset ingeniøroppgave med bevis, redigerbare produktoverflater og eksplisitte valideringsporter. Konteksten for en representativ oppgave om utleieeiendom kan oppsummeres slik:

Den samme sløyfen gjelder utover utleieeiendommer. Utleieeiendommer tok omtrent seks uker og betydelig teknisk oppfølging for å nå 90 % presisjon og tilbakekalling, men dette arbeidet ga gjenbrukbare abstraksjoner, gjennomgangsartefakter, evalueringskonvensjoner og implementeringsmønstre som gjorde det lettere å støtte tilsvarende komplekse skjemaer som Schedule C og Schedule A.

Tax AI viser en vei til å bygge selvforbedrende agenter. Praktikere genererer tilbakemeldingssignaler med høy verdi ved å levere tjenesten. Produktarbeidsflyter bevarer disse signalene som strukturerte bevis. Ingeniørsystemer støttet av evalueringer validerer forbedringer før de når produksjon, og en agentdrevet sløyfe holder systemet i en kontinuerlig selvforbedrende flyt. 

Strukturen i Thrive Holdings gjør det mulig for oss å gjenskape dette miljøet i spesifikke bransjer. Holdings er både eier og operator, så de samlede ingeniørteamene våre kan arbeide direkte med praktikere og produksjonsdata fra innsiden av virksomheter som Crete, ikke som leverandør, men som partnere. Dette betyr at teknologien, produktet og tjenesten alle er samlet under ett tak for å hjelpe oss med å bevege oss raskere og bygge eksepsjonelle produkter.

En seniorregnskapsfører som brukte 180 timer på skatteforberedelser i fjor, brukte bare 15 timer på det i år. Hun brukte noe av den tiden på å ringe hver eneste kunde og gå gjennom skattemeldingene deres med dem, et nivå av tett oppfølging som ikke var mulig for ett år siden. Resten av tiden brukte hun på å ta inn nye kunder og utvide til nye tjenestetilbud.

Sammen bruker teamene våre nå det samme tredelte designet fra Tax AI som en plan for å bygge arbeidsflyter i andre domener på tvers av Thrive Holdings⁠(åpnes i et nytt vindu); regnskapsarbeidsflyter som bokføring og revisjon, og operative arbeidsflyter som automatisering av IT-helpdesk. På tvers av domener og bransjer består det bredere løftet om selvforbedrende agenter. De beste agentene styres av mennesker for å lære å bli mer kapable, mer pålitelige og mer verdifulle over tid.

Hvis du vil vite mer om OpenAI-teamet som jobbet med dette prosjektet, ta kontakt.