Budowanie samodoskonalących się agentów podatkowych z Codex

Jak Thrive Holdings i OpenAI wspólnie opracowały Tax AI dla księgowych Crete, łącząc wiedzę praktyków z pętlą napędzaną przez Codex

Systemy działające w rzeczywistym świecie zachowują się w produkcji inaczej niż w laboratorium, psując się w sposób trudny do przewidzenia przed wdrożeniem. Zespoły często odkrywają te błędy po uruchomieniu, a następnie spędzają tygodnie na analizie przypadków brzegowych, dostosowywaniu poleceń i przekładaniu informacji zwrotnych z produkcji na trwałe ulepszenia produktu. Pętla informacji zwrotnej jest ręczna i powolna, a poprawia się tylko wtedy, gdy posuwa ją naprzód inżynier. Ale dziś, dzięki przemyślanie zaprojektowanej infrastrukturze testów, bezpośredniemu dostępowi do praktyków i rzeczywistych środowisk oraz najnowocześniejszym agentowym możliwościom Codex, można budować agenty, które samodzielnie się doskonalą.

W tym wpisie pokażemy, jak użyliśmy Codex do zbudowania takiego agenta. W ciągu ostatnich sześciu miesięcy inżynierowie i badacze OpenAI wdrożeni bezpośrednio do pracy wraz z inżynierami Thrive Holdings współpracowali nad budową Tax AI obok i dla sieci ponad 30 firm księgowych Crete⁠(otwiera nowe okno), aby pomagać w przygotowywaniu coraz bardziej złożonych zeznań podatkowych. Zamiast polegać na inżynierach przy znajdowaniu i naprawianiu każdego błędu, Tax AI używa Codex, aby zamieniać użycie produkcyjne w ustrukturyzowane sygnały napędzające autonomiczne doskonalenie.

Praktycy Crete przygotowują w każdym sezonie dziesiątki tysięcy zeznań podatkowych, co wymaga pracy z milionami dokumentów źródłowych. W przypadku deklaracji o średnim i wysokim stopniu złożoności samo wprowadzanie danych może zająć osiem godzin na jedno zeznanie, często obejmując nieuporządkowane źródła danych, dokumenty z poprzedniego roku oraz ręczną ekstrakcję i obliczenia. Wskazali nam przygotowanie podatków jako istotne wąskie gardło w najbardziej intensywnym okresie sezonu podatkowego.

Aby rozwiązać ten problem, Tax AI przetworzył w tym sezonie podatkowym 7 000 zeznań podatkowych w firmach Crete uczestniczących w pilotażu. System automatyzuje znaczną część czasochłonnego procesu przygotowywania zeznań podatkowych 1040 i 1041, ale jeszcze bardziej przekonujące niż wzrost efektywności jest to, że sam system jest mierzalnie lepszy niż wersja wdrożona po raz pierwszy trzy miesiące temu.

W Tax AI praktycy przesyłają pliki źródłowe wraz z wszelkimi notatkami specyficznymi dla klienta. Tax AI następnie tworzy zgłoszenie do silnika podatkowego, gotowe do przeglądu. Oszczędza to praktykom około jednej trzeciej czasu poświęcanego na przygotowanie podatków, tworzy projekty zeznań z dokładnością do 97% i zwiększa przepustowość o około 50%, dając im więcej przestrzeni na spędzanie czasu z klientami. 

Możemy ilościowo określić tę poprawę, rozumiejąc, jak dokładnie Tax AI potrafi ukończyć zeznanie bez potrzeby późniejszej korekty. Dokładność mierzymy, sprawdzając, jaki odsetek zeznań osiąga 75%, 90% lub 100% poprawnie uzupełnionych pól. W momencie uruchomienia tylko jedna czwarta zeznań osiągała 75% poprawnie uzupełnionych pól, ale w ciągu sześciu tygodni wskaźnik ten wzrósł do 86%. System wykazał jeszcze szybszy wzrost na poziomach 90% i 100% poprawnie uzupełnionych pól. Te progi dają nam praktyczny obraz tego, ile dalszych działań praktyka nadal wymagają różne zeznania. 

Na początku Tax AI obsługiwał prostsze zadania, takie jak W-2 i 1099. W miarę trwania sezonu przeszedł do bardziej złożonych zeznań z K-1, załącznikami i trudniejszymi przypadkami brzegowymi. Każda nowa możliwość oszczędzała więcej czasu na jedno zeznanie niż poprzednia, ponieważ zadania, które przejmowała, były trudniejsze i bardziej czasochłonne do wykonania ręcznie. Nadal obserwujemy postęp także dziś.

Następnie pokażemy, jak nasze zespoły wspólnie zaprojektowały Tax AI tak, by sam się doskonalił, opierając się na trzech kluczowych filarach: 1) informacji zwrotnej od ekspertów-praktyków, 2) śladach produkcyjnych (ustrukturyzowanej historii od wejść po wynik końcowy) oraz 3) pętli iteracyjnej napędzanej przez Codex i opartej na dopasowanych testach, umożliwiającej ciągły i szybszy rozwój produktu. Mamy nadzieję, że nasze doświadczenia okażą się przydatne dla innych twórców w dziedzinach, w których wiedza praktyków jest kluczowa dla kształtowania jakości całego systemu i przepływających przez niego danych.

Gdy wchodziliśmy w trudniejsze obszary przygotowania podatków (K-1, harmonogramy nieruchomości na wynajem i formularze podatkowe, w których wartości trzeba było uzgadniać między wieloma plikami źródłowymi), stało się jasne, że prawdziwym wyzwaniem jest to, czy produkt potrafi uczynić złożone błędy produkcyjne widocznymi, zrozumiałymi i możliwymi do wykorzystania.

Na wczesnym etapie stosowania produktu większość korekt była wykonywana ręcznie. Praktycy mogli korygować błędy systemu, ale produkt nie przechwytywał pełnego kontekstu: zmieniona wartość przed złożeniem mogła odzwierciedlać rzeczywiste przeoczenie przy ekstrakcji, problem z mapowaniem, brak obsługi w produkcie albo oczekiwany szum przepływu pracy. Uporządkowanie tych przypadków nadal wymagało dalszych działań ze strony zespołu inżynieryjnego. Inżynierowie mogli korzystać z agentów kodujących, ale system nie był jeszcze zaprojektowany tak, by sensownie wykorzystywać AI wewnątrz pętli doskonalenia. Nie mieliśmy sygnału, który pozwalałby wskazać właściwy cel do realizacji.

To doprowadziło nas do zaprojektowania systemu wokół trzech filarów:

1. Pozostań blisko praktyków: Osoby wykonujące pracę muszą kierować tym, czego uczy się produkt. Ich intuicja i zrozumienie ujawniają, które błędy mają znaczenie, i pomagają określić, na których częściach przepływu pracy warto skupić się w następnej kolejności.
2. Buduj produkt tak, by produkcja tworzyła dowody: Produkt musi przechwytywać więcej niż tylko wejścia i wyjścia; musi rejestrować pełną ścieżkę od materiału źródłowego, przez wyodrębnione pola i ich pochodzenie, po zgłoszenie downstream i korektę eksperta.
3. Stwórz pętlę doskonalenia napędzaną przez Codex: Gdy problemy produkcyjne są widoczne i ustrukturyzowane, mogą stać się ustaleniami, dopasowanymi testami i ograniczonymi zadaniami inżynieryjnymi. Codex może następnie pomóc w badaniu, proponowaniu zmian, weryfikowaniu ich względem ukierunkowanych i regresyjnych testów oraz rozwijaniu produktu szybciej niż w czysto ręcznym cyklu iteracji. 

Poniższy przykład nieruchomości na wynajem pokazuje, jak ta pętla działa w praktyce, prowadząc przez to, jak korekta praktyka staje się ustrukturyzowanym ustaleniem, potem celem ewaluacji, a na końcu ograniczonym zadaniem inżynieryjnym dla Codex.

Dochód z nieruchomości na wynajem jest wykazywany w Schedule E indywidualnego zeznania podatkowego. Z perspektywy inżynieryjnej zadanie jego ekstrakcji jest proste do opisania, ale trudne do dobrego wykonania. System musi odczytać nieuporządkowany materiał źródłowy (odręczne notatki, e-maile, arkusze kalkulacyjne i inne pliki klienta), wyodrębnić pola dotyczące nieruchomości na wynajem, które system może z pewnością odwzorować do silnika podatkowego, oraz zachować wystarczającą ilość dowodów, aby praktyk mógł zatwierdzić wynik lub go skorygować. Poniższy uproszczony przykład pokazuje, jak mogą wyglądać te pliki źródłowe i wyodrębnione wyniki.

Różnica między wartością przewidzianą przez agenta a rzeczywistą wartością ze złożonego zeznania podatkowego może odzwierciedlać rzeczywiste przeoczenie przy ekstrakcji, ale może też wynikać z preferencji praktyka, wartości przeniesionej z zeznania z poprzedniego roku w silniku podatkowym albo wartości wprowadzonej lub zmienionej gdzie indziej w procesie składania deklaracji. Praktycy pomogli nam rozróżnić te przypadki, abyśmy mogli ustalić, które działania wymagały korekty przez praktyka lub blokowały złożenie.

Ponieważ mogliśmy szczegółowo obserwować te korekty, przekształciliśmy proces przeglądu z końcowego etapu po błędzie w ciągły cykl uczenia się. Zaprojektowaliśmy ten przepływ pracy tak, aby rejestrować działania ekspertów jako dane strukturalne. Teraz każda interwencja zasila pętlę doskonalenia produktu, zapisując dokładnie to, co zaproponował Tax AI, co zmodyfikował praktyk i co ostatecznie trafiło do złożonego zeznania.

W złożonym przepływie pracy, takim jak nieruchomości na wynajem, system musi zachować to, co dzieje się między plikami źródłowymi a złożonym zeznaniem. Na tej drodze dokumenty są porządkowane, dzielone i klasyfikowane; pola dotyczące nieruchomości na wynajem są wyodrębniane wraz z cytatami odsyłającymi do materiału źródłowego; te wartości są mapowane do silnika podatkowego; a praktycy mogą je jeszcze skorygować przed złożeniem. Te ślady na poziomie produktu umożliwiają zbadanie, gdzie wystąpił błąd. Aby zamienić korekty praktyków w użyteczne cele ewaluacji, system przetwarza je w trzech krokach:

• Uchwycenie różnicy: Wynik Tax AI jest porównywany ze złożonym zeznaniem, aby utworzyć wiersze przeglądu na poziomie pól, które zapisują oczekiwaną wartość, przewidywaną wartość oraz to, czy różnica wydaje się możliwa do wykorzystania.
• Grupowanie powiązanych błędów: Podobne wiersze przeglądu są grupowane, aby oddzielić powtarzające się błędy produktu od oczekiwanego szumu przepływu pracy. Na przykład powtarzające się korekty praktyków mogą pokazać, że Tax AI często pomija pola „fair rental days”, błędnie obsługuje „other expenses” albo myli wiele nieruchomości na wynajem w obrębie tego samego pakietu źródłowego.
• Zamiana powtarzających się wzorców w cele ewaluacji: Po przeglądzie i pomiarze powtarzające się ustalenia stają się jasnymi celami ewaluacji do poprawy przez Codex.

Trzecim filarem jest stworzenie pętli inżynieryjnej zdolnej działać na podstawie tych nowych testów. To właśnie tutaj Codex staje się kluczowy.

Załóżmy, że nasz potok ewaluacji sygnalizuje, iż Tax AI konsekwentnie pomija pole „fair rental days”, podczas gdy praktycy je uzupełniają. Ponieważ to ustalenie zostało już spakowane do ukierunkowanego zestawu ewaluacyjnego, z reprezentatywnymi pakietami źródłowymi i oczekiwanymi wynikami, Codex może bezpośrednio zbadać przyczynę źródłową w szkielecie produktu.

Codex nie pracuje wyłącznie z niedoskonałym wynikiem końcowym. Analizuje ślad, testy, repozytorium i umiejętności:

• Zbadanie potoku: Analiza pakietów źródłowych, schematów ekstrakcji, zachowania mapera i ścieżek kodu, aby ustalić, czy problemem jest nieobsługiwane pole, pominięty wzorzec ekstrakcji, problem z wyborem źródła, luka w maperze czy problem z graderem.
• Wdrożenie ukierunkowanych poprawek: Rozszerzenie schematu ekstrakcji, poprawa wyboru źródła dla dokumentów dotyczących nieruchomości na wynajem, aktualizacja mapera silnika podatkowego lub dopracowanie gradera, jeśli oczekiwany szum przepływu pracy jest liczony jako błąd.
• Walidacja i propozycja: Ponowne uruchomienie ukierunkowanej ewaluacji, uruchomienie szerszych zestawów regresyjnych i przedstawienie kandydującego żądania pull request do przeglądu inżynieryjnego.
• Zamknięcie pętli: Zamiana powtarzającej się korekty praktyka w mierzalne zadanie inżynieryjne. Jeśli dowody są niejednoznaczne lub nie da się ich bezpiecznie zautomatyzować, przypadek wraca do zespołu produktowego zamiast być na siłę przepychany przez pętlę.

Przykład nieruchomości na wynajem jest doskonałym przykładem szerszego, wielokrotnie stosowanego wzorca: wykorzystywania artefaktów i śladów z produkcji do poprawy możliwości agenta. Mając jako zestaw wejść przejrzane ustalenia z danych produkcyjnych, ślady źródłowe, oczekiwany wynik silnika podatkowego, odpowiednie przykłady kodu i polecenia ewaluacyjne, Codex może istotnie poprawiać wydajność i dokładność na przestrzeni tygodni i miesięcy. To rozwija zasady opisane w naszej pracy o inżynierii środowisk testowych i Symphony, które pokazują, jak uczynić zadania czytelnymi dla Codex, zapewnić ograniczony kontekst i narzędzia oraz zachować walidację i weryfikację wykonywaną przez człowieka jako część środowiska. 

Te dowody nie stają się zadaniem dla Codex automatycznie. Korekta praktyka może odzwierciedlać przeoczenie przy ekstrakcji, problem z mapowaniem, nieobsługiwane zachowanie produktu, osąd podatkowy albo oczekiwany szum przepływu pracy. Dopiero po przejrzeniu powtarzających się różnic i zgrupowaniu ich w ustalenie nadające się do działania system zamienia je w ograniczone zadanie z jasnym warunkiem sukcesu.

Tę automatyzację stosujemy do ograniczonej warstwy produktu. Ta warstwa wykonuje ekstrakcję i mapuje dokumenty źródłowe do przepływów podatkowych. Inżynierowie nadal odpowiadają za architekturę, decyzje produktowe i wdrażanie. Praktycy kierują pętlą doskonalenia poprzez pracę, którą już wykonują: korygowanie wyodrębnionych wartości, przegląd zeznań i zatwierdzanie ostatecznych deklaracji.

Dla Codex rezultatem nie jest niejasny alert, lecz ograniczone zadanie inżynieryjne z dowodami, edytowalnymi powierzchniami produktu i jawnymi bramkami walidacji. Kontekst reprezentatywnego zadania dotyczącego nieruchomości na wynajem można podsumować następująco:

Ta sama pętla działa także poza nieruchomościami na wynajem. Dojście do 90% precyzji i czułości dla nieruchomości na wynajem zajęło około sześciu tygodni i wymagało znacznego nadzoru inżynieryjnego, ale ta praca stworzyła wielokrotnego użytku abstrakcje, artefakty przeglądu, konwencje ewaluacyjne i wzorce implementacyjne, które ułatwiły obsługę podobnie złożonych załączników, takich jak Schedule C i Schedule A.

Tax AI pokazuje drogę do budowy samodoskonalących się agentów. Praktycy generują sygnały zwrotne o wysokiej wartości, świadcząc usługę. Przepływy pracy produktu zachowują te sygnały jako ustrukturyzowane dowody. Systemy inżynieryjne oparte na testach weryfikują ulepszenia, zanim trafią do produkcji, a pętla napędzana przez agenta utrzymuje system w ciągłym przepływie samodoskonalenia. 

Struktura Thrive Holdings pozwala nam odtwarzać to środowisko w konkretnych branżach. Holdings jest jednocześnie właścicielem i operatorem, więc nasze połączone zespoły inżynieryjne mogą pracować bezpośrednio z praktykami i danymi produkcyjnymi wewnątrz firm takich jak Crete, nie jako dostawca, lecz jako partnerzy. Oznacza to, że technologia, produkt i usługa znajdują się pod jednym dachem, co pomaga nam działać szybciej i budować wyjątkowe produkty.

Jedna starsza księgowa, która w zeszłym roku poświęciła 180 godzin na przygotowanie podatków, w tym roku poświęciła na to tylko 15 godzin. Część tego czasu przeznaczyła na telefon do każdego ze swoich klientów i omówienie z nimi ich zeznań — poziom bardzo bliskiej obsługi, który rok temu nie był możliwy. Pozostały czas wykorzystała na pozyskiwanie nowych klientów i rozszerzanie oferty usług.

Nasze zespoły wspólnie wykorzystują teraz ten sam trzyczęściowy projekt z Tax AI jako plan budowy przepływów pracy w innych domenach w Thrive Holdings⁠(otwiera nowe okno); przepływów księgowych, takich jak księgowość i audyt, oraz operacyjnych, takich jak automatyzacja działu pomocy IT. W różnych domenach i branżach szersza obietnica samodoskonalących się agentów pozostaje aktualna. Najlepszymi agentami kierują ludzie, aby z czasem mogły być one bardziej zdolne, godne zaufania i wartościowe.

Aby dowiedzieć się więcej o zespole OpenAI, który pracował nad tym projektem, skontaktuj się z nami.