Codex eval в продакшене: как петля самообучающегося агента OpenAI превращает traces в eval-цели

Разрыв между прототипом агента и агентом, который улучшается в продакшене сам по себе, определяется не выбором модели — а тем, что система фиксирует во время работы и как эти данные возвращаются в цикл улучшения. 27 мая инженерная команда OpenAI опубликовала подробный разбор того, как они замкнули эту петлю для Tax AI от Thrive Holdings — Codex-агента, обработавшего 7 000 налоговых деклараций за прошедший сезон. Архитектурный урок выходит далеко за рамки налогового ПО: любая команда, запускающая агентов через API-gateway, должна ответить на один и тот же вопрос, который этот кейс ставит прямо — ваша production-инфраструктура спроектирована генерировать «доказательства» или только «результаты»?

Что произошло

Команда OpenAI совместно с Thrive Holdings построила Tax AI для сети из 30+ бухгалтерских фирм Crete: система автоматизирует подготовку деклараций формы 1040 и 1041. После запуска система — в отличие от большинства агентных развёртываний — стала измеримо улучшаться автономно.

На старте лишь 25% деклараций достигали 75% корректного заполнения полей. За шесть недель показатель вырос до 86%. Система последовательно брала на себя всё более сложные декларации — сначала W-2, затем K-1, арендные графики, мультидокументную сверку — и каждый шаг расширения управлялся структурированной обратной связью из предыдущего, а не ручным разбором инженерами.

Трёхуровневая архитектура, которая это обеспечила:

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

2. Production traces, сохраняющие полный контекст. Система фиксировала весь путь — от исходного файла через извлечение полей с цитированием источников, маппинг в движок налогового учёта до исправления бухгалтером. Это ключевое архитектурное решение: trace, записывающий только вход и выход, не позволяет определить, на каком этапе пайплайна возник сбой. Trace с промежуточным провенансом — позволяет.

3. Итерационный цикл на базе Codex. Структурированные находки становились нацеленными eval-таргетами. Codex использовал их как «холм для восхождения» — исследовал сбои, предлагал изменения кода, валидировал против регрессионных тестов и выпускал улучшения быстрее ручного цикла. Coding agent здесь не продукт — это оператор инфраструктуры качества самого продукта.

Почему это важно для AI-инженерных команд

Большинство продакшен-развёртываний агентов ломаются именно на обратной связи, а не на модели. Паттерн отказа одинаков во всех доменах: оператор, специалист поддержки или конечный пользователь исправляет ответ агента; исправление попадает в тикет или таблицу; инженер просматривает его через несколько недель и, может быть, обновляет промпт. Агент ничему не учится из продакшена, пока кто-то вручную не передаст сигнал наверх.

Архитектура Tax AI ломает это в двух точках. Во-первых, продакшен спроектирован генерировать доказательства — каждое взаимодействие структурировано как инспектируемое, а не просто залогированное. Во-вторых, coding agent ускоряет инженерную сторону цикла: время от «паттерн обнаружен в продакшене» до «фикс задеплоен и прошёл регрессию» сокращается с недель до дней.

Стратегия нацеливания eval-ов тоже заслуживает внимания. Команда не запускала обобщённый eval-набор — они группировали сбои по паттернам (повторяющиеся ошибки в полях fair-rental days; путаница между несколькими объектами недвижимости в одном пакете документов), превращали паттерны в конкретные eval-цели и направляли Codex карабкаться на каждый «холм». Точность здесь критична: широкий eval на совокупную точность может улучшаться глобально, пока конкретный класс сбоев деградирует. Точечные eval-ы улавливают регрессии, скрытые агрегированными метриками.

Взгляд с позиции router/operator

Для команд, прогоняющих агентов через API-gateway, паттерн самообучения обнажает два инфраструктурных решения, которые часто недооцениваются.

Дизайн trace — ответственность оператора, а не послесловие. Если gateway пишет только вход и выход модели, вы можете измерить точность, но не можете отладить, на каком шаге многоступенчатого агентного пайплайна возник сбой. Production-grade трассировка агента означает фиксацию промежуточных состояний: вызовы инструментов, извлечённые документы, промежуточные шаги рассуждения, структурированные извлечения полей с цитированием источников. Это вопрос наблюдаемости пайплайна, а не модели. Gateway-слой — место, где такая запись либо собирается, либо теряется.

Eval-инфраструктура меняет политику маршрутизации моделей. Когда есть точечные eval-ы по конкретным срезам возможностей — точность извлечения данных об аренде, точность полей K-1, мультидокументная сверка — можно маршрутизировать разные шаги пайплайна на разные модели, опираясь на измеренное качество по задаче, а не на позицию в общем рейтинге. Модель, лидирующая в coding-бенчмарках, может оказаться неоптимальной для конкретной задачи извлечения — как только у вас появятся eval-данные для измерения. Это переход от «маршрутизировать по стоимости» к «маршрутизировать по измеренному качеству задачи».

Практический чеклист для команд, внедряющих этот паттерн:

• Логировать промежуточные состояния, не только I/O. Каждый вызов инструмента, шаг ретривала, извлечения и валидации должен быть частью trace. Заложить хранилище для этого.
• Классифицировать исправления до сохранения. Сырое исправление оператора — шум. Исправление с тегом категории сбоя (пропуск при извлечении, пробел промпта, неоднозначный ввод) — сигнал.
• Строить точечные eval-ы до того, как они понадобятся. Команда Tax AI имела eval-инфраструктуру до запуска петли самообучения. Команды, которые добавляют eval-ы в ответ на сбои, всегда позади.
• Использовать coding agent как оператора, а не только как продукт. Codex-класс агентов умеет писать и запускать eval-скрипты, открывать PR с фиксами и валидировать против регрессионных наборов. Этот цикл быстрее ручного — при условии, что production traces дают ему конкретный «холм для восхождения».
• Следить за политикой маршрутизации при смене моделей. Замена провайдера или обновление версии модели может выявить регрессии в конкретных срезах возможностей, которые агрегированные бенчмарки скрывают.

Что попробовать пользователям TheRouter

Команды, маршрутизирующие агентные workflow через TheRouter, могут добавить слой захвата trace на уровне gateway — без изменения кода приложения. Логирование на уровне запроса в API вместе со структурированными ответами на вызовы инструментов от модели формирует основу для захвата промежуточных состояний.

Паттерн самообучения также усиливает аргумент в пользу маршрутизации как решения, принимаемого по задаче на основе eval-данных, а не статичного выбора модели. Когда есть точечные eval-результаты по срезам возможностей, шаги извлечения документов можно маршрутизировать иначе, чем шаги рассуждения — и обновлять политику маршрутизации по мере накопления eval-свидетельств из продакшена.

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