Создание самообучающихся налоговых агентов с Codex

Как Thrive Holdings и OpenAI совместно разработали Tax AI для бухгалтеров Crete, объединив экспертизу специалистов с циклом на базе Codex

Реальные системы ведут себя в промышленной эксплуатации иначе, чем в лабораторных условиях, и выдают ошибки, которые практически невозможно спрогнозировать до развертывания. Команды обычно выявляют эти сбои уже после релиза, после чего тратят недели на разбор редких сценариев, корректировку промптов и адаптацию полученных логов в устойчивые улучшения продукта. Этот процесс обратной связи выстроен вручную, занимает много времени и прогрессирует лишь за счет усилий инженеров. Однако сегодня, используя продуманную архитектуру автоматической оценки (evals), прямой контакт с практиками и реальной средой, а также передовой агентский потенциал модели 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, дополнительные графики (schedules) и более запутанные пограничные случаи. Каждая новая функция экономила больше времени на одну декларацию, чем предыдущая, поскольку задачи, за которые брался ИИ, были сложнее и требовали огромных усилий при ручной обработке. И этот прогресс продолжается по сей день.

Ниже мы рассмотрим, как в результате совместной инженерной работы наших команд система Tax AI получила возможность самосовершенствования благодаря трем ключевым компонентам: 1) отзывам профильных специалистов, 2) логам промышленной эксплуатации (production traces — структурированной истории преобразования данных от входа до выхода) и 3) итерационному циклу под управлением Codex на основе специализированных метрик оценки (эвалов) для ускорения непрерывной разработки продукта. Мы надеемся, что наш опыт окажется полезным для создателей систем в тех доменах, где человеческая экспертиза критически важна для обеспечения качества работы комплекса и циркулирующих в нем данных.

Когда мы перешли к более сложным этапам подготовки отчетности (формам K-1, приложениям по аренде недвижимости и налоговым формам, где данные нужно было сопоставлять между несколькими исходными файлами), стало очевидно: главная проблема заключалась в том, способна ли система делать сложные сбои в продакшене видимыми, понятными и устранимыми.

На ранних этапах продукта большая часть исправлений выполнялась вручную. Специалисты могли исправлять ошибки системы, но продукт не фиксировал полный контекст: изменённое значение до подачи могло отражать реальный пропуск при извлечении, проблему сопоставления, отсутствие поддержки в продукте или ожидаемый шум рабочего процесса. Разбор этих случаев по-прежнему требовал последующей работы инженерной команды. Инженеры могли использовать кодирующих агентов, но система ещё не была спроектирована так, чтобы осмысленно использовать ИИ внутри цикла улучшения. У нас просто не было четкого сигнала, чтобы понять, на какую гору нам нужно взбираться.

Это привело нас к созданию системы, основанной на трех главных «столпах»:

1. Быть ближе к экспертам: люди, которые выполняют работу, должны направлять процесс обучения продукта. Их интуиция и опыт помогают понять, какие ошибки критичны, а на каких этапах рабочего процесса стоит сосредоточиться в первую очередь.
2. Спроектировать продукт так, чтобы эксплуатация создавала данные (evidence): продукт должен фиксировать не просто входные и выходные данные. Ему нужно собирать весь путь целиком: от первоисточника до извлеченных полей, истории их происхождения, финальной отправки в налоговый модуль и правок, внесенных экспертом.
3. Создать цикл улучшений на базе Codex: как только проблемы из продакшна становятся видимыми и структурированными, они превращаются в инсайты, кастомные эвалы и конкретные технические задачи. После этого Codex помогает исследовать проблему, предлагать изменения, валидировать их на целевых тестах и регрессионных эвалах, двигая продукт вперед гораздо быстрее, чем при полностью ручном цикле итераций.

Приведенный ниже пример с арендой жилья наглядно демонстрирует работу этого цикла: вы увидите, как ручная правка специалиста превращается в структурированный вывод, затем становится целью для эвалов и, в итоге, трансформируется в изолированную инженерную задачу для Codex.

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

Разница между значением, предсказанным агентом, и фактическим значением из поданной налоговой декларации может отражать реальный пропуск при извлечении, но также может быть предпочтением специалиста, значением, перенесённым из декларации за прошлый год в налоговый движок, или значением, введённым либо изменённым в другом месте процесса подачи. Специалисты помогли нам различать такие случаи, чтобы мы могли определить, какие действия требовали исправления специалистом или блокировали подачу.

Поскольку мы могли детально видеть эти исправления, мы превратили процесс проверки из финального шага после сбоя в непрерывный цикл обучения. Мы спроектировали рабочий процесс так, чтобы фиксировать действия экспертов как структурированные данные. Теперь каждое вмешательство подпитывает цикл улучшения продукта, фиксируя, что именно предложил Tax AI, что изменил специалист и что в итоге вошло в поданную декларацию.

Для таких сложных рабочих процессов, как учет аренды недвижимости, система должна сохранять всё, что происходит на пути от исходных файлов до готовой налоговой декларации. На этом этапе документы упорядочиваются, разделяются и классифицируются; поля данных по аренде извлекаются с привязкой к первоисточникам; затем эти значения маппятся в налоговый движок, а эксперты всё еще могут скорректировать их перед отправкой. Именно такие трейсы на уровне продукта позволяют детально расследовать, где именно произошел сбой. Чтобы превратить исправления специалистов в полезные цели для эвалов, система обрабатывает их в три шага:

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

Третий столп архитектуры — создание инженерного цикла, способного отрабатывать эти новые эвалы. Именно на этом этапе Codex начинает играть центральную роль.

Допустим, конвейер эвалов сигнализирует о том, что Tax AI систематически игнорирует поле «дни справедливой аренды», тогда как верификаторы гарантированно вносят эти данные. Благодаря тому, что эта аномалия уже была инкапсулирована в профильный датасет эвалов, содержащий репрезентативные первичные документы и эталонные выходные значения, Codex имеет возможность локализовать первопричину сбоя непосредственно внутри тестового каркаса (scaffold) платформы.

Codex работает не только с некачественным финальным результатом. Он совместно анализирует трейс, эвал, репозиторий и навыки:

• Анализ конвейера обработки: проверить исходные пакеты, схемы извлечения, поведение маппера и пути кода, чтобы определить, является ли проблема неподдерживаемым полем, пропущенным паттерном извлечения, проблемой выбора источника, пробелом в маппере или проблемой grader.
• Реализация точечных исправлений: Расширить схему извлечения, улучшить выбор источников для документов по арендной недвижимости, обновить маппер налогового движка или доработать грейдер, если ожидаемый шум рабочего процесса засчитывается как сбой.
• Проверка и предложения: повторно запустить целевой эвал, выполнить более широкие регрессионные наборы и показать кандидатный pull request для инженерной проверки.
• Замыкание цикла: превратить повторяющееся исправление специалиста в измеримую инженерную задачу. Если свидетельства неоднозначны или автоматизация небезопасна, случай возвращается продуктовой команде, а не принудительно проводится через цикл.

Пример с арендой недвижимости наглядно иллюстрирует более масштабный переиспользуемый паттерн: применение артефактов и трейсов продакшна для прокачки возможностей агента. Получая на вход верифицированные инсайты (findings) из реальной эксплуатации, исходные трейсы, ожидаемые результаты из налогового движка, релевантные примеры кода и команды для запуска эвалов, Codex способен существенно повысить производительность и точность системы на дистанции в недели и месяцы. Этот подход развивает принципы, описанные в наших работах по harness engineering (инженерии тестовых сред) и Symphony. В них подробно рассказывается о том, как делать задачи прозрачными для Codex, предоставлять ему изолированный контекст и инструменты, а также сохранять валидацию и ревью человеком как неотъемлемую часть рабочей среды. 

Эти свидетельства не становятся задачей для Codex автоматически. Исправление специалиста может отражать пропуск при извлечении, проблему сопоставления, неподдерживаемое поведение продукта, налоговое суждение или ожидаемый шум рабочего процесса. Только после того как повторяющиеся различия проверены и сгруппированы в пригодную к действию находку, система превращает их в ограниченную задачу с ясным условием успеха.

Мы применяем эту автоматизацию к ограниченному слою продукта. Этот слой выполняет извлечение и сопоставляет исходные документы с налоговыми рабочими процессами. Инженеры по-прежнему отвечают за архитектуру, продуктовые решения и выпуск. Специалисты направляют цикл улучшения через уже выполняемую ими работу: исправление извлечённых значений, проверку деклараций и утверждение финальных подач.

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

Этот же цикл применим и далеко за пределами учета аренды недвижимости. Чтобы довести точность и полноту до 90% на примере с арендой, потребовалось около шести недель и серьезный контроль со стороны инженеров. Однако эта работа позволила создать переиспользуемые абстракции, артефакты проверки, стандарты эвалов и паттерны реализации. Благодаря им поддержка аналогичных по сложности форм — таких как Schedule C и Schedule A — далась гораздо проще.

Tax AI открывает путь к созданию самосовершенствующихся агентов. Оказывая услуги, специалисты формируют высокоценные сигналы обратной связи. Продуктовые рабочие процессы сохраняют эти сигналы как структурированные свидетельства. Затем инженерные системы на основе автоматических оценок (evals) верифицируют улучшения перед их релизом, а замкнутый цикл под управлением ИИ-агента поддерживает систему в режиме постоянного саморазвития. 

Структура Thrive Holdings позволяет нам воспроизводить эту среду в конкретных отраслях. Holdings выступает и владельцем, и оператором, поэтому наши объединённые инженерные команды могут напрямую работать со специалистами и производственными данными внутри таких бизнесов, как Crete, не как поставщик, а как партнёры. Это означает, что технология, продукт и услуга находятся под одной крышей, помогая нам двигаться быстрее и создавать выдающиеся продукты.

Один старший бухгалтер, потративший в прошлом году 180 часов на подготовку налогов, в этом году потратил на это всего 15 часов. Часть этого времени она направила на звонки каждому своему клиенту и разбор с ними их деклараций — уровень персонального сервиса, который год назад был невозможен. Оставшееся время она использовала, чтобы взять новых клиентов и расширить набор услуг.

Сегодня наши команды используют ту же трехкомпонентную архитектуру из Tax AI как готовый шаблон для создания рабочих процессов в других подразделениях Thrive Holdings⁠(открывается в новом окне). Это касается как бухгалтерских задач (таких как ведение учета и аудит), так и операционных процессов — например, автоматизации ИТ-службы поддержки. Независимо от сферы и индустрии, концепция самообучающихся агентов доказывает свою жизнеспособность. Лучшие агенты — это те, которыми управляют люди, помогая им со временем становиться эффективнее, надежнее и полезнее для бизнеса.

Чтобы узнать больше о команде OpenAI, работавшей над этим проектом, свяжитесь с нами.