Створення податкових агентів, що самовдосконалюються, з Codex

Як Thrive Holdings і OpenAI спільно розробили Tax AI для бухгалтерів Crete, поєднавши експертизу фахівців із циклом на основі Codex

Реальні системи в продакшні поводяться інакше, ніж у лабораторії, і ламаються способами, які важко передбачити до розгортання. Команди часто виявляють такі збої після запуску, а потім тижнями досліджують крайові випадки, коригують запити та перетворюють виробничий зворотний зв’язок на стійкі покращення продукту. Цикл зворотного зв’язку є ручним і повільним та покращується лише тоді, коли його просуває інженер. Але сьогодні, завдяки продумано спроєктованій інфраструктурі eval, прямому доступу до фахівців і реальних середовищ та передовим агентним можливостям Codex, можна будувати агентів, що самовдосконалюються.

У цьому дописі ми розберемо, як використовували Codex для побудови такого типу агента. Протягом останніх шести місяців інженери та дослідники OpenAI, відряджені на місце, разом з інженерами Thrive Holdings співпрацювали над створенням Tax AI поруч із мережею Crete⁠(відкривається у новому вікні) з понад 30 бухгалтерських фірм і для неї, щоб допомогти готувати дедалі складніші податкові декларації. Замість того щоб покладатися на інженерів у пошуку та виправленні кожного збою, Tax AI використовує Codex, щоб перетворювати використання в продакшні на структуровані сигнали, які живлять автономне вдосконалення.

Фахівці Crete щосезону готують десятки тисяч податкових декларацій, що вимагає опрацювання мільйонів базових документів. Для подань середньої та високої складності лише введення даних може займати вісім годин на одну декларацію, часто з неохайними джерелами даних, документами за попередній рік і ручним вилученням та обчисленням. Вони вказали нам на підготовку податкових декларацій як на значне вузьке місце в найнапруженіший період податкового сезону.

Щоб розв’язати цю проблему, цього податкового сезону Tax AI обробив 7 000 податкових декларацій у фірмах Crete, які брали участь у пілотному проєкті. Система автоматизує значну частину трудомісткого процесу підготовки податкових декларацій 1040 і 1041, але ще переконливішим за приріст ефективності є те, що сама система вимірювано краща за версію, яку вперше розгорнули три місяці тому.

У Tax AI фахівці завантажують вихідні файли разом із будь-якими примітками, специфічними для клієнта. Потім Tax AI створює подання до податкового рушія, готове до перевірки. Він заощаджує фахівцям близько третини часу на підготовку податкових декларацій, створює чернетки декларацій із точністю до 97% і збільшує пропускну здатність приблизно на 50%, залишаючи більше часу на клієнтів. 

Ми можемо кількісно оцінити це покращення, розуміючи, наскільки точно Tax AI може завершити декларацію без потреби в подальших виправленнях. Ми вимірюємо точність, перевіряючи, яка частка декларацій досягає 75%, 90% або 100% правильного заповнення полів. На момент запуску лише чверть декларацій досягала 75% правильного заповнення полів, але вже за шість тижнів цього показника досягли 86%. Система показала ще швидше зростання на рівнях 90% і 100% правильного заповнення полів. Ці пороги дають нам практичне уявлення про те, скільки подальшої роботи фахівця ще потребують різні декларації. 

На початку Tax AI опрацьовував простіші завдання, як-от заповнення форм W-2 і 1099. У міру розвитку сезону він перейшов до складніших декларацій із K-1, планами і важчими крайовими випадками. Кожна нова можливість заощаджувала більше часу на декларацію, ніж попередня, бо завдання, які вона брала на себе, були складнішими й більш трудомісткими для ручного виконання. Ми й сьогодні продовжуємо бачити сталий прогрес.

Далі ми покажемо, як наші команди спільно спроєктували Tax AI так, щоб він самовдосконалювався, спираючись на три критично важливі опори: 1) зворотний зв’язок від експертів-фахівців, 2) виробничі траси (структуровану історію від входів до фінального виходу) і 3) цикл ітерацій на основі Codex, побудований на спеціально підібраних eval, щоб забезпечити безперервну й швидшу розробку продукту. Ми сподіваємося, що наш досвід буде корисним іншим розробникам у доменах, де експертиза фахівців є ключовою для формування якості всієї системи та даних, що через неї проходять.

Коли ми просувалися до складніших частин підготовки податкових декларацій (K-1, графіків орендної нерухомості та податкових форм, де значення треба було узгоджувати між кількома вихідними файлами), стало очевидно, що справжній виклик полягає в тому, чи може продукт зробити складні виробничі збої видимими, зрозумілими та придатними до дії.

На ранніх етапах продукту більшість виправлень виконувалася вручну. Фахівці могли виправляти помилки системи, але продукт не фіксував повний контекст: змінене значення перед поданням могло відображати справжній пропуск під час вилучення, проблему зіставлення, відсутню підтримку в продукті або очікуваний шум робочого процесу. Розібратися в цих випадках усе ще вимагало подальшої роботи інженерної команди. Інженери могли використовувати агентів для кодування, але система ще не була спроєктована так, щоб змістовно використовувати ШІ всередині циклу вдосконалення. У нас не було сигналу, щоб визначити правильну вершину для підкорення.

Це привело нас до проєктування системи навколо трьох опор:

1. Тримайтеся ближче до фахівців: люди, які виконують роботу, мають спрямовувати те, чого навчається продукт. Їхня інтуїція та розуміння показують, які помилки мають значення, і допомагають визначити, на яких частинах робочого процесу варто зосередитися далі.
2. Будуйте продукт так, щоб продакшн створював докази: продукт має фіксувати не лише введені та вихідні дані; він має фіксувати весь шлях від вихідного матеріалу до вилучених полів і їхнього походження, до подання нижче за потоком і експертного виправлення.
3. Створіть цикл удосконалення на основі Codex: коли виробничі проблеми стають видимими й структурованими, вони можуть перетворюватися на знахідки, спеціально підібрані eval і окреслені інженерні завдання. Потім Codex може допомогти дослідити їх, запропонувати зміни, перевірити їх на цільові й регресійні eval та просувати продукт швидше, ніж суто ручний цикл ітерацій. 

Наведений нижче приклад для орендної нерухомості показує, як цей цикл працює на практиці, проводячи вас через те, як виправлення фахівця стає структурованою знахідкою, потім ціллю eval і зрештою інженерним завданням у межах Codex.

Дохід від орендної нерухомості відображається в Schedule E індивідуальної податкової декларації. З інженерної точки зору завдання його вилучення легко описати, але важко добре виконати. Система має читати неохайні вихідні матеріали (рукописні нотатки, електронні листи, таблиці та інші файли клієнта), вилучати поля орендної нерухомості, які система може впевнено зіставити з податковим рушієм, і зберігати достатньо доказів, щоб фахівець міг затвердити або виправити результат. Спрощений приклад нижче показує, як можуть виглядати ці вихідні файли та вилучені результати.

Різниця між значенням, передбаченим агентом, і фактичним значенням із поданої податкової декларації може відображати справжній пропуск під час вилучення, але також може бути вподобанням фахівця, значенням, перенесеним із декларації за попередній рік у податковому рушії, або значенням, доданим чи зміненим деінде в процесі подання. Фахівці допомогли нам розрізняти такі випадки, щоб ми могли визначити, які дії потребували виправлення фахівцем або блокували подання.

Оскільки ми могли детально бачити ці виправлення, ми перетворили процес перевірки з кінцевого кроку після збою на безперервний цикл навчання. Ми спроєктували робочий процес так, щоб фіксувати дії експертів як структуровані дані. Тепер кожне втручання живить цикл удосконалення продукту, фіксуючи, що саме запропонував Tax AI, що змінив фахівець і що зрештою потрапило до поданої декларації.

Для складного робочого процесу, як-от орендна нерухомість, система має зберігати те, що відбувається між вихідними файлами та поданою декларацією. На цьому шляху документи впорядковуються, розділяються та класифікуються; поля орендної нерухомості вилучаються з посиланнями на вихідні матеріали; ці значення зіставляються з податковим рушієм; і фахівці все ще можуть виправляти їх перед поданням. Такі траси на рівні продукту дають змогу дослідити, де стався збій. Щоб перетворити виправлення фахівців на корисні цілі оцінювання, система обробляє їх у три кроки:

• Зафіксувати різницю: вихід Tax AI порівнюється з поданою декларацією, щоб створити рядки перевірки на рівні полів, які фіксують очікуване значення, передбачене значення та те, чи виглядає різниця практично значущою.
• Групувати пов’язані збої: подібні рядки перевірки групуються, щоб відокремити повторювані збої продукту від очікуваного шуму робочого процесу. Наприклад, повторні виправлення фахівців можуть показати, що Tax AI часто пропускає поля «дні справедливої оренди», неправильно обробляє «інші витрати» або плутає кілька об’єктів орендної нерухомості в межах одного вихідного пакета.
• Перетворити повторювані шаблони на цілі eval: після перевірки та вимірювання повторювані знахідки стають чіткими цілями eval для вдосконалення Codex.

Третя опора — створення інженерного циклу, здатного діяти на основі цих нових eval. Саме тут центром стає Codex.

Припустімо, наш конвеєр eval позначає, що Tax AI послідовно пропускає поле «дні справедливої вартості оренди», тоді як фахівці ретельно його заповнюють. Оскільки цю знахідку вже упаковано в цільовий набір eval із репрезентативними вихідними пакетами та очікуваними виходами, Codex може дослідити першопричину безпосередньо в каркасі продукту.

Codex працює не лише з посереднім фінальним результатом. Він разом перевіряє трасу, eval, репозиторій і навички:

• Дослідити конвеєр: перевірити вихідні пакети, схеми вилучення, поведінку мапера та шляхи коду, щоб визначити, чи є проблема непідтримуваним полем, пропущеним шаблоном вилучення, проблемою вибору джерела, прогалиною в мапері чи проблемою оцінювача.
• Упровадити цільові виправлення: розширити схему вилучення, покращити вибір джерел для документів орендної нерухомості, оновити мапер податкового рушія або уточнити оцінювач, якщо очікуваний шум робочого процесу зараховується як збій.
• Перевірити й запропонувати: повторно запустити цільовий eval, виконати ширші набори регресійних тестів і показати кандидатний запит на злиття для інженерної перевірки.
• Замкнути цикл: перетворити повторюване виправлення фахівця на вимірюване інженерне завдання. Якщо докази неоднозначні або автоматизація небезпечна, випадок повертається команді продукту, а не примусово проводиться через цикл.

Приклад орендної нерухомості є показовим для ширшого повторно використовуваного шаблону: використання виробничих артефактів і трас для покращення можливостей агента. Маючи як набір вхідних даних перевірені знахідки з виробничих даних, вихідні траси, очікуваний вихід податкового рушія, релевантні приклади коду та команди eval, Codex може відчутно покращувати продуктивність і точність протягом тижнів і місяців. Це спирається на принципи, описані в нашій роботі про інженерію harness та Symphony, де пояснюється, як зробити завдання зрозумілими для Codex, надати контекст і інструменти в заданих межах та зберегти перевірку й людський огляд як частину середовища. 

Ці докази не стають завданням для Codex автоматично. Виправлення фахівця може відображати пропуск під час вилучення, проблему зіставлення, непідтримувану поведінку продукту, податкове судження або очікуваний шум робочого процесу. Лише після того, як повторювані відмінності буде перевірено та згруповано в практичну знахідку, система перетворює їх на обмежене завдання з чіткою умовою успіху.

Ми застосовуємо цю автоматизацію до обмеженого шару продукту. Цей шар виконує вилучення та зіставляє вихідні документи з податковими робочими процесами. Інженери й надалі відповідають за архітектуру, продуктові рішення та випуск. Фахівці спрямовують цикл удосконалення через роботу, яку вони вже виконують: виправляють вилучені значення, перевіряють декларації та затверджують фінальні подання.

Для Codex результатом є не розмите сповіщення, а окреслене інженерне завдання з доказами, редагованими поверхнями продукту та явними воротами валідації. Контекст репрезентативного завдання щодо орендної нерухомості можна підсумувати так:

Той самий цикл застосовується й поза орендною нерухомістю. Орендна нерухомість потребувала близько шести тижнів і значного інженерного нагляду, щоб досягти 90% точності та повноти, але ця робота створила повторно використовувані абстракції, артефакти перевірки, угоди eval і шаблони реалізації, які полегшили підтримку подібно складних форм, як-от Schedule C і Schedule A.

Tax AI демонструє шлях до побудови агентів, що самовдосконалюються. Фахівці генерують цінні сигнали зворотного зв’язку, надаючи послугу. Робочі процеси продукту зберігають ці сигнали як структуровані докази. Інженерні системи, підкріплені eval, перевіряють покращення до того, як вони потраплять у продакшн, а цикл на основі агента підтримує систему в безперервному потоці самовдосконалення. 

Структура Thrive Holdings дає нам змогу відтворювати це середовище в конкретних галузях. Holdings є і власником, і оператором, тож наші об’єднані інженерні команди можуть безпосередньо працювати з фахівцями та виробничими даними всередині таких бізнесів, як Crete, не як постачальник, а як партнери. Це означає, що технологія, продукт і послуга зосереджені під одним дахом, що допомагає нам рухатися швидше й створювати виняткові продукти.

Одна старша бухгалтерка, яка торік витратила 180 годин на підготовку податків, цього року витратила лише 15 годин. Частину цього часу вона витратила на те, щоб зателефонувати кожному своєму клієнту й пройти з ним його декларацію, забезпечивши рівень персональної уваги, який рік тому був неможливим. Решту цього часу вона використала, щоб взяти нових клієнтів і розширити перелік послуг.

Разом наші команди тепер використовують той самий трискладовий дизайн із Tax AI як шаблон для побудови робочих процесів в інших доменах у Thrive Holdings⁠(відкривається у новому вікні); бухгалтерських процесах, як-от ведення бухгалтерії та аудит, і операційних процесах, як-от автоматизація ІТ-служби підтримки. У різних доменах і галузях ширша обіцянка агентів, що самовдосконалюються, зберігається. Найкращими агентами керують люди, щоб вони з часом ставали спроможнішими, надійнішими та ціннішими.

Щоб дізнатися більше про команду OpenAI, яка працювала над цим проєктом, зв’яжіться з нами.