Criar agentes fiscais autoaperfeiçoáveis com Codex

Como a Thrive Holdings e a OpenAI codesenvolveram a Tax AI para os contabilistas da Crete, fundindo a experiência dos profissionais com um ciclo orientado pelo Codex

Os sistemas do mundo real comportam-se de forma diferente em produção do que num laboratório, falhando de maneiras difíceis de antecipar antes da implementação. As equipas descobrem frequentemente essas falhas após o lançamento e depois passam semanas a inspecionar casos limite, a ajustar prompts e a traduzir feedback de produção em melhorias duradouras do produto. O ciclo de feedback é manual e lento, e só melhora quando um engenheiro o faz avançar. Mas hoje, com uma infraestrutura de evals cuidadosamente concebida, acesso direto a profissionais e a ambientes do mundo real, e as capacidades agentic de fronteira do Codex, é possível criar agentes que se autoaperfeiçoam.

Neste artigo, vamos explicar como usámos o Codex para criar este tipo de agente. Nos últimos seis meses, engenheiros e investigadores destacados no terreno pela OpenAI, juntamente com os engenheiros da Thrive Holdings, colaboraram para construir a Tax AI com e para a rede de mais de 30 empresas de contabilidade da Crete⁠(abre numa nova janela), para ajudar a preparar declarações fiscais cada vez mais complexas. Em vez de depender de engenheiros para encontrar e corrigir cada falha, a Tax AI usa o Codex para transformar a utilização em produção em sinais estruturados que alimentam a melhoria autónoma.

Os profissionais da Crete preparam dezenas de milhares de declarações fiscais em cada época, o que exige trabalhar milhões de documentos subjacentes. Para submissões de complexidade média a elevada, só a introdução de dados pode demorar oito horas por declaração, envolvendo frequentemente fontes de dados desorganizadas, documentos do ano anterior e extração e cálculo manuais. Eles indicaram-nos a preparação fiscal como um estrangulamento significativo durante o período mais intenso da época fiscal.

Para resolver este problema, a Tax AI processou 7 000 declarações fiscais nas empresas da Crete que participaram no piloto nesta época fiscal. O sistema automatiza grande parte do processo moroso de preparação das declarações fiscais 1040 e 1041, mas ainda mais convincente do que os ganhos de eficiência é o facto de o próprio sistema ser mensuravelmente melhor do que a versão que foi implementada pela primeira vez há três meses.

Na Tax AI, os profissionais carregam ficheiros de origem juntamente com quaisquer notas específicas do cliente. A Tax AI cria então uma submissão para o motor fiscal, pronta para revisão. Poupa aos profissionais cerca de um terço do tempo de preparação fiscal, redige declarações com até 97% de precisão e aumenta a taxa de processamento em cerca de 50%, criando mais margem para passarem tempo com os clientes. 

Podemos quantificar esta melhoria ao perceber com que precisão a Tax AI consegue completar uma declaração sem precisar de correção posterior. Medimos a precisão verificando que percentagem de declarações atinge 75%, 90% ou 100% de preenchimento correto dos campos. No lançamento, apenas um quarto das declarações atingia 75% de preenchimento correto dos campos, mas em seis semanas 86% chegaram a esse nível. O sistema mostrou um crescimento ainda mais rápido nos níveis de 90% e 100% de preenchimento correto dos campos. Estes limiares dão-nos uma perspetiva prática de quanto acompanhamento dos profissionais diferentes declarações ainda exigem. 

No início, a Tax AI tratava trabalho mais simples, como W-2 e 1099. À medida que a época avançava, passou para declarações mais complexas com K-1, anexos e casos limite mais difíceis. Cada nova capacidade poupou mais tempo por declaração do que a anterior, porque as tarefas que assumia eram mais difíceis e mais demoradas de fazer manualmente. Continuamos a ver progressos contínuos ainda hoje.

De seguida, vamos mostrar como as nossas equipas codesenharam a Tax AI para se autoaperfeiçoar com base em três pilares críticos: 1) feedback de profissionais especialistas, 2) rastos de produção (um histórico estruturado desde as entradas até à saída final) e 3) um ciclo de iteração orientado pelo Codex com base em evals personalizados para permitir um desenvolvimento contínuo e mais rápido do produto. Esperamos que a nossa experiência seja útil para outros criadores em domínios onde a experiência dos profissionais é essencial para moldar a qualidade do sistema global e dos dados que o percorrem.

À medida que avançámos para partes mais difíceis da preparação fiscal (K-1, anexos de imóveis para arrendamento e formulários fiscais em que os valores tinham de ser reconciliados entre vários ficheiros de origem), tornou-se óbvio que o verdadeiro desafio era saber se o produto conseguia tornar falhas complexas de produção visíveis, compreensíveis e acionáveis.

Nos primeiros tempos do produto, a maior parte da correção era manual. Os profissionais podiam corrigir erros do sistema, mas o produto não captava o contexto completo: um valor alterado antes da submissão podia refletir uma falha real de extração, um problema de mapeamento, falta de suporte do produto ou ruído esperado do fluxo de trabalho. Continuava a ser necessário acompanhamento da equipa de engenharia para distinguir esses casos. Os engenheiros podiam usar agentes de programação, mas o sistema ainda não estava concebido para usar IA de forma significativa dentro de um ciclo de melhoria. Não tínhamos o sinal para identificar a meta certa a atingir.

Isso levou-nos a conceber o sistema em torno de três pilares:

1. Manter proximidade com os profissionais: As pessoas que fazem o trabalho precisam de orientar o que o produto aprende. A sua intuição e compreensão revelam quais os erros que importam e ajudam a informar em que partes do fluxo de trabalho vale a pena concentrar-nos a seguir.
2. Construir o produto para que a produção crie evidência: O produto tem de captar mais do que entradas e saídas; precisa de captar o percurso completo desde o material de origem, aos campos extraídos e respetiva proveniência, até à submissão a jusante e à correção por especialistas.
3. Criar um ciclo de melhoria orientado pelo Codex: Quando os problemas de produção são visíveis e estruturados, podem tornar-se resultados, evals personalizados e tarefas de engenharia delimitadas. O Codex pode então ajudar a investigar, propor alterações, validá-las com evals direcionados e de regressão e fazer o produto avançar mais depressa do que um ciclo de iteração puramente manual. 

O exemplo dos imóveis para arrendamento abaixo mostra como esse ciclo funciona na prática, explicando como uma correção do profissional se torna um resultado estruturado, depois um alvo de avaliação e, por fim, uma tarefa de engenharia delimitada para o Codex.

O rendimento de imóveis para arrendamento é declarado no Schedule E de uma declaração fiscal individual. Do ponto de vista da engenharia, a tarefa de o extrair é simples de descrever, mas difícil de executar bem. O sistema tem de ler material de origem desorganizado (notas manuscritas, emails, folhas de cálculo e outros ficheiros do cliente), extrair os campos de imóveis para arrendamento que consegue mapear com confiança para o motor fiscal e preservar evidência suficiente para que um profissional possa aprovar ou corrigir o resultado. O exemplo simplificado abaixo mostra o aspeto que esses ficheiros de origem e resultados extraídos podem ter.

Uma diferença entre o valor previsto pelo agente e o valor real da declaração fiscal submetida pode refletir uma falha real de extração, mas também pode ser uma preferência do profissional, um valor transitado de uma declaração do ano anterior no motor fiscal, ou um valor introduzido ou alterado noutro ponto do fluxo de submissão. Os profissionais ajudaram-nos a distinguir esses casos para podermos identificar quais as ações que exigiam uma correção do profissional ou bloqueavam uma submissão.

Como conseguíamos ver estas correções em detalhe, transformámos o processo de revisão de uma etapa terminal, pós-falha, num ciclo de aprendizagem contínua. Concebemos o fluxo de trabalho para captar as ações dos especialistas como dados estruturados. Agora, cada intervenção alimenta o ciclo de melhoria do produto ao registar exatamente o que a Tax AI propôs, o que o profissional alterou e o que acabou por constar da declaração submetida.

Num fluxo complexo como o dos imóveis para arrendamento, o sistema tem de preservar o que acontece entre os ficheiros de origem e a declaração submetida. Ao longo desse percurso, os documentos são organizados, divididos e classificados; os campos de imóveis para arrendamento são extraídos com citações que remetem para o material de origem; esses valores são mapeados para o motor fiscal; e os profissionais podem ainda corrigi-los antes da submissão. Esses rastos ao nível do produto tornam possível investigar onde ocorreu uma falha. Para transformar correções dos profissionais em alvos de avaliação úteis, o sistema processa-as em três passos:

• Captar a diferença: O resultado da Tax AI é comparado com a declaração submetida para produzir linhas de revisão ao nível do campo que captam o valor esperado, o valor previsto e se a diferença parece acionável.
• Agrupar falhas relacionadas: Linhas de revisão semelhantes são agrupadas para separar falhas recorrentes do produto do ruído esperado do fluxo de trabalho. Por exemplo, correções repetidas dos profissionais podem mostrar que a Tax AI falha frequentemente os campos de “dias de arrendamento justo”, trata mal “outras despesas” ou confunde vários imóveis para arrendamento no mesmo pacote de origem.
• Transformar padrões repetidos em alvos de avaliação: Depois de revistos e medidos, os resultados repetidos tornam-se alvos de avaliação claros para o Codex melhorar.

O terceiro pilar é criar um ciclo de engenharia capaz de atuar sobre estes novos evals. É aqui que o Codex se torna central.

Suponhamos que o nosso pipeline de evals assinala que a Tax AI falha sistematicamente o campo "fair rental days", enquanto os profissionais o preenchem de forma fiável. Como este resultado já foi empacotado num conjunto de avaliação direcionado, com pacotes de origem representativos e resultados esperados, o Codex pode investigar a causa raiz diretamente dentro da estrutura do produto.

O Codex não está a trabalhar apenas com um resultado final abaixo do ideal. Inspeciona em conjunto o rasto, o eval, o repositório e as skills:

• Investigar o pipeline: Inspecionar pacotes de origem, schemas de extração, comportamento do mapper e percursos de código para determinar se o problema é um campo não suportado, um padrão de extração falhado, um problema de seleção da origem, uma lacuna no mapper ou um problema no grader.
• Implementar correções direcionadas: Alargar o schema de extração, melhorar a seleção da origem para documentos de imóveis para arrendamento, atualizar o mapper do motor fiscal ou refinar o grader se o ruído esperado do fluxo de trabalho estiver a ser contado como falha.
• Validar e propor: Voltar a executar o eval direcionado, correr suites de regressão mais amplas e apresentar uma pull request candidata para revisão de engenharia.
• Fechar o ciclo: Transformar uma correção recorrente do profissional numa tarefa de engenharia mensurável. Se a evidência for ambígua ou não puder ser automatizada com segurança, o caso regressa à equipa de produto em vez de ser forçado através do ciclo.

O exemplo do imóvel para arrendamento é emblemático de um padrão reutilizável mais amplo: usar artefactos e rastos de produção para melhorar as capacidades de um agente. Dado um conjunto de entradas com resultados revistos a partir de dados de produção, rastos de origem, saída esperada do motor fiscal, exemplos de código relevantes e comandos de eval, o Codex pode melhorar materialmente o desempenho e a precisão ao longo de semanas e meses. Isto baseia-se nos princípios descritos no nosso trabalho sobre engenharia de harness e Symphony, que explicam como tornar as tarefas legíveis para o Codex, fornecer contexto e ferramentas delimitados e manter a validação e a revisão humana como parte do ambiente. 

Essa evidência não se torna automaticamente uma tarefa para o Codex. Uma correção do profissional pode refletir uma falha de extração, um problema de mapeamento, comportamento do produto não suportado, juízo fiscal ou ruído esperado do fluxo de trabalho. Só depois de diferenças repetidas terem sido revistas e agrupadas num resultado acionável é que o sistema as transforma numa tarefa delimitada com uma condição de sucesso clara.

Aplicamos esta automação a uma camada delimitada do produto. Esta camada executa a extração e mapeia documentos de origem para fluxos de trabalho fiscais. Os engenheiros continuam responsáveis pela arquitetura, pelas decisões de produto e pelo lançamento. Os profissionais orientam o ciclo de melhoria através do trabalho que já fazem: corrigir valores extraídos, rever declarações e aprovar submissões finais.

Para o Codex, o resultado não é um alerta vago, mas uma tarefa de engenharia delimitada com evidência, superfícies de produto editáveis e portas de validação explícitas. O contexto para uma tarefa representativa de imóvel para arrendamento pode resumir-se da seguinte forma:

O mesmo ciclo aplica-se para além dos imóveis para arrendamento. Os imóveis para arrendamento demoraram cerca de seis semanas e exigiram supervisão substancial de engenharia para atingir 90% de precisão e recall, mas esse trabalho produziu abstrações reutilizáveis, artefactos de revisão, convenções de eval e padrões de implementação que facilitaram o suporte a anexos de complexidade semelhante, como o Schedule C e o Schedule A.

A Tax AI prova um caminho para construir agentes que se autoaperfeiçoam. Os profissionais geram sinais de feedback de elevado valor ao prestar o serviço. Os fluxos de trabalho do produto preservam esses sinais como evidência estruturada. Sistemas de engenharia suportados por evals validam melhorias antes de chegarem à produção, e um ciclo impulsionado por agentes mantém o sistema num fluxo contínuo de autoaperfeiçoamento. 

A estrutura da Thrive Holdings permite-nos replicar este ambiente em setores específicos. A Holdings é simultaneamente proprietária e operadora, pelo que as nossas equipas de engenharia combinadas conseguem trabalhar diretamente com profissionais e dados de produção dentro de empresas como a Crete, não como fornecedor, mas como parceiras. Isto significa que a tecnologia, o produto e o serviço estão todos sob o mesmo teto para nos ajudar a avançar mais depressa e a criar produtos excecionais.

Uma contabilista sénior que no ano passado passou 180 horas na preparação fiscal passou apenas 15 horas nisso este ano. Ela dedicou parte desse tempo a telefonar a cada um dos seus clientes e a explicar-lhes as respetivas declarações, um nível de serviço altamente personalizado que não era possível há um ano. Usou o restante desse tempo para aceitar novos clientes e expandir para novas ofertas de serviço.

Em conjunto, as nossas equipas estão agora a usar o mesmo desenho em três partes da Tax AI como modelo para criar fluxos de trabalho noutros domínios em Thrive Holdings⁠(abre numa nova janela); fluxos de trabalho contabilísticos como escrituração e auditoria, e fluxos operacionais como a automatização do help desk de TI. Em todos os domínios e setores, mantém-se a promessa mais ampla dos agentes que se autoaperfeiçoam. Os melhores agentes são orientados por pessoas para aprenderem a tornar-se mais capazes, mais fiáveis e mais valiosos ao longo do tempo.

Para saber mais sobre a equipa da OpenAI que trabalhou neste projeto, entre em contacto.