Como Construir um Agente de IA que Realmente Aprende com Especialistas (Sem Retreinar o Modelo)

Olha só o problema real

Toda empresa grande tem o mesmo gargalo: o conhecimento mais valioso mora na cabeça das pessoas. Revisões de compliance levam dias, as mesmas perguntas aparecem em centenas de avaliações de produto, e a inconsistência entre especialistas gera risco de verdade.

A solução instintiva — fazer fine-tuning do modelo com dados dos experts — é caro, opaco e lento. Uma abordagem melhor trata a base de conhecimento como código-fonte e o modelo como compilador: mantenha a complexidade em arquivos de texto legíveis por humanos e agentes, não nos pesos do modelo.

A arquitetura abaixo vem de um sistema em produção num domínio de compliance, mas o padrão se generaliza para finanças, segurança e revisão de padrões de engenharia.

Quatro camadas, cada uma resolvendo um problema

Tire qualquer camada e as outras degradam. Esse é o insight que a maioria dos sistemas RAG perde: retrieval sozinho não captura raciocínio.

A camada de conhecimento: arquivos acima de embeddings

Em vez de jogar documentos num vector store e torcer pra busca semântica achar o chunk certo, pré-extraia o conhecimento numa taxonomia estrita de 200+ arquivos:

• Arquivos de posição — posturas organizacionais autoritativas com restrições e implicações de roteamento acionáveis por máquina
• Arquivos de taxonomia / vocabulário — fonte única de verdade para tipos de entidade e níveis de classificação
• Índices de roteamento — mapeamento determinístico de características de entrada para posições aplicáveis
• Arquivos de gateway — testes de limiar que o agente precisa passar antes de entrar num domínio

Cada arquivo declara suas dependências em frontmatter YAML:

# position_file.yaml
id: pos-2024-compliance-marketing-claims
version: 3.2
depends_on:
  - taxonomy/entity-types.yaml
  - vocabulary/claim-categories.yaml
referenced_by:
  - recipes/assess-marketing-claim.yaml
  - routing/index-marketing.yaml
constraints:
  - "Aplica-se apenas a claims voltados ao consumidor"
  - "Substitui pos-2023-marketing-claims"

Isso forma um grafo de dependências bidirecional. Quando um arquivo muda, você rastreia exatamente o que quebra — e é isso que torna a edição automatizada viável.

Particionamento por densidade

Nem tudo pertence à wiki. Divida por densidade de informação × frequência de uso:

• Alta densidade + alta frequência → wiki (consultado quase toda rodada)
• Esparso + situacional → retrieval RAG (profundo mas raramente necessário)

O raciocínio central do agente fica ancorado em conhecimento refinado e atual, mas ainda alcança evidências de apoio quando o cenário exige.

Receitas: separando o 'o quê' do 'como'

Arquivos de conhecimento são declarativos. Receitas são imperativas. Uma receita prescreve um workflow analítico multi-etapa — o que examinar primeiro, qual conhecimento carregar em cada passo, quais procedimentos de decisão seguir.

A escolha crítica de design: receitas referenciam arquivos de conhecimento mas não contêm fatos de domínio; arquivos de conhecimento declaram posições mas não prescrevem procedimentos.

Isso te dá atribuição limpa de falhas:

• Conclusão errada apesar de materiais-fonte corretos → problema de receita
• Procedimento correto mas fatos faltando → lacuna de conhecimento
• Especialistas discordam da resposta → ambiguidade, escale para humano

Divulgação progressiva corta tokens em ~80%

Versões iniciais carregavam um arquivo plano de instruções com tudo via busca semântica. Depois de reestruturar em estágios guiados por receita, cada query toca só um subconjunto pequeno e direcionado. Context windows são finitas e a atenção degrada com volume — entregar as instruções certas na hora certa melhora direto a qualidade do raciocínio.

O flywheel de auto-aprimoramento

Essa é a parte que a maioria dos times pula. O loop tem quatro fases:

1. Diagnosticar — extraia sinais dos traces de conversa com especialistas, depois aplique um único teste de atribuição: O agente poderia ter chegado à conclusão correta a partir dos materiais-fonte?
2. Compilar — sub-agentes analisam impacto em paralelo (referências cruzadas, conflitos, orçamento de tokens, cobertura de testes). Um revisor adversarial independente roda em contexto novo, sem saber da justificativa — ele só vê os diffs propostos.
3. Avaliar — replay direcionado no cenário original (com juiz cego) + testes de regressão no benchmark do domínio.
4. Aterrissar — um humano revisa uma correção comprovada, não uma falha crua. O cenário que falhava é adicionado à suíte de regressão permanentemente.

Cada correção eleva a barra para mudanças futuras. O esforço do especialista compõe.

Limitações e cuidados

• O custo inicial é real. Construir 200+ arquivos estruturados com grafo de dependências leva semanas. Só compensa se o domínio tem perguntas recorrentes e de alto risco.
• Não é para criatividade aberta. Esse padrão serve domínios governados por texto recuperável e posições estáveis. Vai brigar com você em trabalho criativo que muda rápido.
• Checkpoints humanos são inegociáveis. O sistema acelera especialistas; não substitui a autoridade deles. Calibre os checkpoints à tolerância a risco do domínio.
• Revisão adversarial pode ser burlada. Se o agente revisor compartilha qualquer contexto com o proponente, pontos cegos se propagam. Mantenha contextos estritamente isolados.

Para onde ir agora

Se você está avaliando isso pra sua empresa, comece pelo teste de atribuição — é a menor unidade útil. Pegue uma correção recorrente de especialista e pergunte: foi lacuna de conhecimento, falha de receita ou ambiguidade genuína? Essa única pergunta vai te dizer se seu sistema precisa de camada de conhecimento, camada de raciocínio ou caminho de escalação humana.

Para uma perspectiva complementar sobre os limites de LLMs em contextos de avaliação, veja nossa análise de a suposição de surrogacy em testes A/B com LLM. E se você está acompanhando onde features nativas de plataforma substituem camadas de tooling, CSS @function está silenciosamente fazendo com Sass o que essa arquitetura faz com fine-tuning.

근거자료: Meta Engineering — Organizational Second Brain

A conclusão

O princípio profundo é simples: mantenha a complexidade em arquivos de texto legíveis por humanos e agentes, não em pesos de modelo fine-tunado. Cada melhoria é um diff que um especialista de domínio revisa em 30 segundos. Cada mudança é versionada, diffável, reversível.

O pipeline de compilação é sofisticado, mas as saídas são sempre transparentes. Esse é o trade: complexidade de engenharia no pipeline, simplicidade radical nos artefatos.

Se sua empresa tem conhecimento tribal que fica saindo pela porta, essa arquitetura merece uma olhada séria.