Siirry pääsisältöön
OpenAI

27. toukokuuta 2026

Tekniikka

Itseään parantavien veroagenttien rakentaminen Codexilla

Kirjoittajat, Technical Staffin jäsenet: Aravind Srinivasan ja Samay Shamdasani (Thrive Holdings), Arthur Fernandes Araujo ja John de Wasseige (OpenAI)

Ladataan...

Miten Thrive Holdings ja OpenAI kehittivät yhdessä Tax AI:n Creten kirjanpitäjille yhdistämällä asiantuntijaosaamisen Codex-vetoiseen silmukkaan

Todellisen maailman järjestelmät käyttäytyvät tuotannossa eri tavoin kuin laboratoriossa ja rikkoutuvat tavoilla, joita on vaikea ennakoida ennen käyttöönottoa. Tiimit löytävät nämä virheet usein julkaisun jälkeen ja käyttävät sitten viikkoja reunatapausten tutkimiseen, kehotteiden säätämiseen ja tuotantopalautteen muuttamiseen kestäviksi tuoteparannuksiksi. Palautesilmukka on manuaalinen ja hidas, ja paranee vain, kun insinööri vie sitä eteenpäin. Mutta nykyään voit harkitusti suunnitellun arviointiinfrastruktuurin, suoran pääsyn asiantuntijoihin ja todellisiin ympäristöihin sekä Codexin huippuluokan agenttikyvykkyyksien avulla rakentaa agentteja, jotka parantavat itseään.

Tässä kirjoituksessa avaamme, miten käytimme Codexia tämän tyyppisen agentin rakentamiseen. Viimeisten kuuden kuukauden aikana OpenAI:n kentälle sijoitetut insinöörit ja tutkijat sekä Thrive Holdingsin insinöörit tekivät yhteistyötä rakentaakseen Tax AI:n Creten(avautuu uudessa ikkunassa) yli 30 tilitoimiston verkoston rinnalla ja sitä varten auttamaan yhä monimutkaisempien veroilmoitusten valmistelussa. Sen sijaan, että Tax AI luottaisi insinööreihin jokaisen virheen löytämisessä ja korjaamisessa, se käyttää Codexia muuttaakseen tuotantokäytön rakenteisiksi signaaleiksi, jotka ruokkivat autonomista parantumista.

Creten asiantuntijat laativat joka kausi kymmeniä tuhansia veroilmoituksia, mikä edellyttää miljoonien tausta-asiakirjojen läpikäyntiä. Keskivaikeissa ja suurissa ilmoituksissa pelkkä tietojen syöttö voi viedä kahdeksan tuntia ilmoitusta kohden, ja siihen liittyy usein sotkuisia tietolähteitä, edellisvuoden asiakirjoja sekä manuaalista poimintaa ja laskentaa. He osoittivat meille veroilmoitusten valmistelun merkittäväksi pullonkaulaksi verokauden kiireisimmän jakson aikana.

Tämän ongelman ratkaisemiseksi Tax AI käsitteli tällä verokaudella 7 000 veroilmoitusta Creten pilottiin osallistuneissa toimistoissa. Järjestelmä automatisoi suuren osan 1040- ja 1041-veroilmoitusten valmistelun aikaa vievästä prosessista, mutta tehokkuushyötyjäkin vakuuttavampaa on se, että järjestelmä on mitattavasti parempi kuin versio, joka otettiin käyttöön ensimmäisen kerran kolme kuukautta sitten.

Mitattava itseparannus

Tax AI:ssa asiantuntijat lataavat lähdetiedostot sekä mahdolliset asiakaskohtaiset muistiinpanot. Tax AI luo sitten veromoottoriin lähetyksen, joka on valmis tarkistettavaksi. Se säästää asiantuntijoilta noin kolmanneksen veroilmoitusten valmisteluun kuluvasta ajasta, laatii ilmoitusluonnoksia jopa 97 %:n tarkkuudella ja kasvattaa suoritustehoa noin 50 %, jolloin heille jää enemmän aikaa asiakkaiden kanssa työskentelyyn. 

Voimme kvantifioida tämän parannuksen ymmärtämällä, kuinka tarkasti Tax AI pystyy täyttämään veroilmoituksen ilman myöhempiä korjauksia. Mittaamme tarkkuutta tarkistamalla, kuinka suuri osuus veroilmoituksista saavuttaa 75 %, 90 % tai 100 % oikein täytetyistä kentistä. Julkaisun aikaan vain neljännes veroilmoituksista saavutti 75 % oikein täytetyistä kentistä, mutta kuuden viikon kuluessa 86 % saavutti tämän tason. Järjestelmä kasvoi vielä nopeammin 90 %:n ja 100 %:n oikein täytettyjen kenttien tasoilla. Nämä kynnykset antavat meille käytännöllisen kuvan siitä, kuinka paljon asiantuntijoiden jatkotyötä eri veroilmoitukset vielä vaativat. 

Aluksi Tax AI hoiti yksinkertaisempia tehtäviä, kuten W-2- ja 1099-lomakkeita. Kauden edetessä se siirtyi monimutkaisempiin veroilmoituksiin, joissa oli K-1-lomakkeita, liitteitä ja vaikeampia reunatapauksia. Jokainen uusi kyvykkyys säästi enemmän aikaa veroilmoitusta kohden kuin edellinen, koska sen hoitamat tehtävät olivat vaikeampia ja manuaalisesti tehtyinä aikaa vievämpiä. Näemme jatkuvaa edistystä edelleen tänäkin päivänä.

Seuraavaksi käymme läpi, miten tiimimme suunnittelivat Tax AI:n yhdessä itseään parantavaksi tukeutuen kolmeen kriittiseen pilariin: 1) asiantuntijoiden palaute, 2) tuotantojäljet (rakenteinen historia syötteistä lopulliseen tulokseen) ja 3) räätälöityihin arviointeihin perustuva Codex-vetoinen iteraatiosilmukka, joka mahdollistaa jatkuvan ja nopeamman tuotekehityksen. Toivomme, että kokemuksestamme on hyötyä muille rakentajille aloilla, joilla asiantuntijaosaaminen on keskeistä koko järjestelmän ja sen läpi kulkevan datan laadun muovaamisessa.

Kun Tax AI laajeni monimutkaisempiin ilmoituksiin, 75 %, 90 % ja täyden valmistumisasteen saavuttaneiden pisteytettyjen veroilmoitusten osuus jatkoi kasvuaan verokauden aikana.

Ongelma

Kun etenimme veroilmoitusten valmistelun vaikeampiin osiin (K-1:t, vuokrakiinteistöjen liitteet ja verolomakkeet, joissa arvoja piti täsmäyttää useiden lähdetiedostojen välillä), kävi ilmeiseksi, että todellinen haaste oli se, pystyikö tuote tekemään monimutkaisista tuotantovirheistä näkyviä, ymmärrettäviä ja toimintakelpoisia.

Tuotteen alkuvaiheessa suurin osa korjauksista tehtiin manuaalisesti. Asiantuntijat pystyivät korjaamaan järjestelmän virheitä, mutta tuote ei tallentanut koko kontekstia: ennen jättämistä muutettu arvo saattoi heijastaa todellista poimintavirhettä, kartoitusongelmaa, puuttuvaa tuotetukea tai odotettua työnkulkukohinaa. Näiden tapausten selvittäminen vaati silti insinööritiimin jatkotoimia. Insinöörit saattoivat käyttää koodausagentteja, mutta järjestelmää ei ollut vielä suunniteltu käyttämään tekoälyä mielekkäästi parannussilmukan sisällä. Meillä ei ollut signaalia, jonka avulla olisimme voineet tunnistaa oikean haasteen.

Lähestymistapamme: kolmiosainen silmukka

Tämä johti siihen, että suunnittelimme järjestelmän kolmen pilarin varaan:

  1. Pysy lähellä asiantuntijoita: Työtä tekevien ihmisten on ohjattava sitä, mitä tuote oppii. Heidän intuitionsa ja ymmärryksensä paljastavat, mitkä virheet ovat tärkeitä, ja auttavat määrittämään, mihin työnkulun osiin kannattaa keskittyä seuraavaksi.
  2. Rakenna tuote niin, että tuotanto luo näyttöä: Tuotteen on tallennettava enemmän kuin vain syötteet ja tulosteet; sen on tallennettava koko polku lähdemateriaalista poimittuihin kenttiin ja niiden alkuperään sekä edelleen jatkolähetykseen ja asiantuntijan korjaukseen.
  3. Luo Codex-vetoinen parannussilmukka: Kun tuotanto-ongelmat ovat näkyviä ja rakenteisia, niistä voi tulla havaintoja, räätälöityjä arviointeja ja rajattuja insinööritehtäviä. Codex voi sitten auttaa tutkimaan, ehdottamaan muutoksia, validoimaan ne kohdennettuja ja regressioarviointeja vasten ja viemään tuotetta eteenpäin nopeammin kuin puhtaasti manuaalinen iteraatiosykli. 

Alla oleva vuokrakiinteistöesimerkki näyttää, miten tämä silmukka toimii käytännössä, ja käy läpi, miten asiantuntijan korjauksesta tulee rakenteinen havainto, sitten arviointikohde ja lopulta Codexille rajattu insinööritehtävä.

Vuokrakiinteistöesimerkki

Vuokrakiinteistötulot ilmoitetaan yksityishenkilön veroilmoituksen Schedule E:ssä. Insinöörin näkökulmasta sen poimintatehtävä on helppo kuvata mutta vaikea tehdä hyvin. Järjestelmän on luettava sotkuista lähdemateriaalia (käsinkirjoitettuja muistiinpanoja, sähköposteja, taulukoita ja muita asiakastiedostoja), poimittava vuokrakiinteistökentät, jotka järjestelmä voi luotettavasti kartoittaa veromoottoriin, ja säilytettävä riittävästi näyttöä, jotta asiantuntija voi hyväksyä tai korjata tuloksen. Alla oleva yksinkertaistettu esimerkki näyttää, miltä nämä lähdetiedostot ja poimitut tulokset voivat näyttää.

””

Vuokrakiinteistön lähdepaketti normalisoidaan viitatuiksi kentiksi ennen kuin ne kartoitetaan veromoottorin jatkokäsitteisiin.

1. Asiantuntijan korjaus paljastaa virheen

Agentin ennustaman arvon ja jätetyn veroilmoituksen todellisen arvon välinen ero voi kuvastaa todellista poimintavirhettä, mutta se voi myös olla asiantuntijan mieltymys, veromoottorissa edellisvuoden ilmoituksesta siirtynyt arvo tai muualla ilmoitusprosessissa lisätty tai muutettu arvo. Asiantuntijat auttoivat meitä erottamaan nämä tapaukset, jotta pystyimme tunnistamaan, mitkä toimet vaativat asiantuntijan korjauksen tai estivät lähetyksen.

Koska pystyimme näkemään nämä korjaukset yksityiskohtaisesti, muutimme tarkistusprosessin lopullisesta, epäonnistumisen jälkeisestä vaiheesta jatkuvaksi oppimissykliksi. Suunnittelimme työnkulun tallentamaan asiantuntijoiden toimet rakenteisena datana. Nyt jokainen puuttuminen syöttää tuotteen parannussilmukkaa kirjaamalla tarkasti, mitä Tax AI ehdotti, mitä asiantuntija muokkasi ja mitä lopulta päätyi jätettyyn veroilmoitukseen.

2. Tuotejäljet muuttavat korjaukset arvioinneiksi

Vuokrakiinteistöjen kaltaisessa monimutkaisessa työnkulussa järjestelmän on säilytettävä se, mitä tapahtuu lähdetiedostojen ja jätetyn veroilmoituksen välillä. Tällä polulla asiakirjat järjestetään, jaetaan ja luokitellaan; vuokrakiinteistökentät poimitaan viittauksin takaisin lähdemateriaaliin; nämä arvot kartoitetaan veromoottoriin; ja asiantuntijat voivat vielä korjata niitä ennen jättämistä. Nämä tuotetason jäljet mahdollistavat sen tutkimisen, missä virhe tapahtui. Jotta asiantuntijoiden korjaukset voidaan muuttaa hyödyllisiksi arviointikohteiksi, järjestelmä käsittelee ne kolmessa vaiheessa:

  • Tallenna ero: Tax AI:n tulosta verrataan jätettyyn veroilmoitukseen, jotta saadaan kenttätason tarkistusrivejä, jotka tallentavat odotetun arvon, ennustetun arvon ja sen, vaikuttaako ero toimintakelpoiselta.
  • Ryhmittele liittyvät virheet: Samankaltaiset tarkastusrivit ryhmitellään, jotta toistuvat tuotevirheet voidaan erottaa työnkulun odotettavissa olevista vaihteluista. Esimerkiksi toistuvat korjaukset voivat osoittaa, että Tax AI jättää usein täyttämättä ”kohtuulliset vuokrapäivät” -kentät, käsittelee ”muut kulut” virheellisesti tai sekoittaa saman lähdepaketin sisältämät useat vuokrakiinteistöt keskenään.
  • Muunna toistuvat kuviot arviointikohteiksi: Kun havainnot on tarkistettu ja mitattu, niistä tulee selkeitä arviointikohteita, joita Codex voi parantaa.
””

Vuokra-asuntojen arviointiprosessissa erotellaan toistuvat tuoteviat odotettavissa olevista vaihteluista, minkä jälkeen korjaustoimenpiteitä vaativat tapaukset määritetään arviointikohteiksi, jotka asettavat Codexille haasteen.

3. Havainnosta tulee Codexille haaste

Kolmas pilari on luoda insinöörisilmukka, joka pystyy toimimaan näiden uusien arviointien pohjalta. Tässä Codexista tulee keskeinen.

Oletetaan, että arviointiprosessimme havaitsee, että Tax AI jättää jatkuvasti täyttämättä ”kohtuulliset vuokrapäivät” -kentän, kun taas alan ammattilaiset täyttävät sen luotettavasti. Koska tämä havainto on jo koottu kohdennettuun arviointijoukkoon, joka sisältää edustavat lähdepaketit ja odotetut tulokset, Codex voi selvittää ongelman perussyyn suoraan tuotteen kehysrakenteessa.

Codex ei työskentele vain heikkolaatuisen lopputuloksen kanssa. Se tarkastelee jälkeä, arviointia, repositoriota ja taitoja yhdessä:

  • Tutki putkea: Tarkasta lähdepaketit, poimintaskeemat, kartoituksen toiminta ja koodipolut selvittääksesi, onko ongelma tukematon kenttä, ohitettu poimintakuvio, lähdevalintaongelma, kartoituksen puute vai arviointijärjestelmän ongelma.
  • Toteuta kohdennetut korjaukset: Laajenna poimintaskeemaa, paranna vuokrakiinteistöasiakirjojen lähdevalintaa, päivitä veromoottorin kartoitinta tai tarkenna luokittelijaa, jos odotettua työnkulkukohinaa lasketaan virheeksi.
  • Validoi ja ehdota: Aja kohdennettu arviointi uudelleen, suorita laajemmat regressiopaketit ja tuo esiin ehdokasmuutospyyntö insinööritarkastusta varten.
  • Sulje silmukka: Muunna toistuva asiantuntijakorjaus mitattavaksi insinööritehtäväksi. Jos näyttö on epäselvää tai sitä ei voi automatisoida turvallisesti, tapaus ohjataan takaisin tuotetiimille sen sijaan, että se pakotettaisiin silmukan läpi.
””

Kokonaisvaltainen itsensä kehittämisen kierto: tuotantotiedot paljastavat toistuvia korjauksia kenttätasolla, joista muodostuu vikailmoituksia, joita Codex voi tarkastella yhdessä jäljitystietojen, arviointien, repositorion ja taitojen kanssa. Käytännön toimenpiteisiin johtavat mallit muotoutuvat rajatuiksi arvioinneiksi ja tuotemuutosehdotuksiksi; epäselvät tapaukset ohjataan takaisin insinööreille tarkasteltaviksi. Jokainen käyttöönotettu parannus luo uutta tuotantotietoa seuraavaa kierrosta varten.

Näin käytät Codexia tämän silmukan rakentamiseen

Vuokrakiinteistöesimerkki kuvastaa laajempaa uudelleenkäytettävää mallia: tuotantoartefaktien ja jälkien käyttöä agentin kyvykkyyksien parantamiseen. Kun syötteinä annetaan tuotantodatan tarkistetut havainnot, lähdejäljet, odotettu veromoottorin tulos, olennaiset koodiesimerkit ja arviointikomennot, Codex voi parantaa suorituskykyä ja tarkkuutta merkittävästi viikkojen ja kuukausien aikana. Tämä rakentuu harness engineering -työstämme ja Symphony-järjestelmästä kuvattujen periaatteiden varaan; niissä käydään läpi, miten tehtävät tehdään Codexille luettaviksi, miten tarjotaan rajattu konteksti ja työkalut sekä miten validointi ja ihmistarkastus pidetään osana ympäristöä. 

Tuo näyttö ei muutu Codex-tehtäväksi automaattisesti. Asiantuntijan korjaus voi heijastaa poimintavirhettä, kartoitusongelmaa, tukematonta tuotetoimintaa, verotuksellista harkintaa tai odotettua työnkulkukohinaa. Vasta kun toistuvat erot on tarkistettu ja ryhmitelty toimintakelpoiseksi havainnoksi, järjestelmä muuttaa ne rajatuksi tehtäväksi, jolla on selkeä onnistumisehto.

Sovellamme tätä automaatiota tuotteen rajattuun kerrokseen. Tämä kerros suorittaa poiminnan ja kartoittaa lähdeasiakirjat verotyönkulkuihin. Insinöörit vastaavat edelleen arkkitehtuurista, tuotepäätöksistä ja julkaisemisesta. Asiantuntijat ohjaavat parannussilmukkaa työn kautta, jota he jo tekevät: poimittujen arvojen korjaaminen, veroilmoitusten tarkistaminen ja lopullisten ilmoitusten hyväksyminen.

Codexille tulos ei ole epämääräinen hälytys vaan rajattu insinööritehtävä, jossa on näyttöä, muokattavia tuotepintoja ja eksplisiittiset validointiportit. Edustavan vuokrakiinteistötehtävän konteksti voidaan tiivistää seuraavasti:

Ilmiteksti

1
/candidates/FIND-RENTAL-0042/
2
3
├── repo/ [1]
4
│ └── branch: codex/fix-rental-0042
5
│ │
6
│ ├── AGENTS.md
7
│ │
8
│ ├── tasks/FIND-RENTAL-0042/
9
│ │ ├── task.yaml
10
│ │ ├── EXEC_PLAN.md
11
│ │ └── RESULTS.md
12
│ │
13
│ ├── app/tax-ai/rental-income/ [2]
14
│ │ ├── agent.ts
15
│ │ ├── schema.ts
16
│ │ ├── provenance.ts
17
│ │ └── mapper.ts
18
│ │
19
│ ├── evals/ [3]
20
│ │ ├── datasets/fair-rental-days.yaml
21
│ │ ├── suites/fair-rental-days.yaml
22
│ │ ├── suites/rental-income-regression.yaml
23
│ │ └── graders/rental-income.yaml
24
│ │
25
│ ├── skills/ [4]
26
│ │ ├── eval-runner/
27
│ │ └── tax-field-docs/
28
│ │
29
│ └── docs/ [4]
30
│ ├── architecture/
31
│ └── task-environments/
32
33
└── scoped-tools/ [5]
34
├── production-trace
35
├── source-artifacts
36
└── tax-engine-docs

Rajattu Codex-tehtäväympäristö erottaa kirjoitettavan työpuun [1] vain luku -tuotantokontekstista [5]. Työpuu sisältää rajatun tuotepinnan, jota Codex voi tarkastella tai muokata [2], kohdennetut ja regressioarvioinnit, jotka määrittävät onnistumisen [3], sekä uudelleenkäytettävät taidot/dokumentit, jotka koodaavat, miten tehtävä suoritetaan ja aiempia päätöksiä kunnioitetaan [4]. Vain luku -konteksti tarjoaa tuotantojäljen, lähdeasiakirjat, Tax AI:n ennusteen, viimeistellyn veroilmoituksen ja veromoottorin kenttädokumentaation, jotta Codex voi tutkia virhettä muuttamatta taustalla olevaa näyttöä.

Laajentuminen uusiin alueisiin

Sama silmukka toimii myös vuokrakiinteistöjen ulkopuolella. Vuokrakiinteistöjen kohdalla noin 90 %:n tarkkuuden ja palautusasteen saavuttaminen vei noin kuusi viikkoa ja vaati merkittävää insinööriylivalvontaa, mutta työ tuotti uudelleenkäytettäviä abstraktioita, tarkistusartefakteja, arviointikäytäntöjä ja toteutusmalleja, jotka helpottivat vastaavan monimutkaisten liitteiden, kuten Liite C:n ja Liite A:n, tukemista.

Tax AI osoittaa polun itseään parantavien agenttien rakentamiseen. Asiantuntijat tuottavat palvelua toimittaessaan arvokkaita palautesignaaleja. Tuotetyönkulut säilyttävät nämä signaalit rakenteisena näyttönä. Arviointien tukemat insinöörijärjestelmät validoivat parannukset ennen kuin ne päätyvät tuotantoon, ja agenttivetoinen silmukka pitää järjestelmän jatkuvassa itseään parantavassa prosessissa. 

Thrive Holdingsin rakenne antaa meille mahdollisuuden toistaa tämän ympäristön tietyillä toimialoilla. Holdings on sekä omistaja että operaattori, joten yhdistetyt insinööritiimimme voivat työskennellä suoraan asiantuntijoiden ja tuotantodatan kanssa Creten kaltaisissa yrityksissä, eivät toimittajana vaan kumppaneina. Tämä tarkoittaa, että teknologia, tuote ja palvelu ovat kaikki saman katon alla, mikä auttaa meitä liikkumaan nopeammin ja rakentamaan poikkeuksellisia tuotteita.

Eräs kokenut kirjanpitäjä, joka käytti viime vuonna 180 tuntia veroilmoitusten valmisteluun, käytti siihen tänä vuonna vain 15 tuntia. Hän käytti osan tästä ajasta soittaakseen jokaiselle asiakkaalleen ja käydäkseen heidän veroilmoituksensa läpi heidän kanssaan — näin henkilökohtaista palvelua ei ollut mahdollista tarjota vuosi sitten. Lopun ajasta hän käytti uusien asiakkaiden hankkimiseen ja uusien palvelutarjontojen laajentamiseen.

Tiimimme käyttävät nyt yhdessä samaa Tax AI:n kolmiosaista mallia suunnitelmana työnkulkujen rakentamiseen muilla Thrive Holdingsin(avautuu uudessa ikkunassa) alueilla; kirjanpidon ja tilintarkastuksen kaltaisissa taloushallinnon työnkuluissa sekä IT-helpdeskin automaation kaltaisissa operatiivisissa työnkuluissa. Toimialoista ja aloista riippumatta itseään parantavien agenttien laajempi lupaus pitää paikkansa. Parhaita agentteja ohjaavat ihmiset, jotta ne oppivat ajan myötä kyvykkäämmiksi, luotettavammiksi ja arvokkaammiksi.

Jos haluat lisätietoja OpenAI-tiimistä, joka työskenteli tämän projektin parissa, ota yhteyttä.

Tekijä

Aravind Srinivasan, Samay Shamdasani, Arthur Fernandes Araujo ja John de Wasseige