Na semana passada absorvemos 9 vídeos da Palantir DevCon 5 e identificamos 12 débitos técnicos no nosso sistema. Esta semana zeramos todos e, no processo, construímos algo que não planejávamos: um sistema que melhora a si mesmo.
Vou contar o que aconteceu porque acredito que o padrão se repete em qualquer empresa que opera com agentes IA. E porque o resultado prova uma tese que defendo desde o início: o gap não é o modelo, é o framework ao redor dele.
O Catalisador: Palantir DevCon 5
Na DevCon 5, o CTO da Palantir, Shyam Sankar, declarou publicamente algo que eu vinha construindo em paralelo: que o valor de um sistema de IA está na ontologia, não no modelo. Que modelos comoditizam, mas a estrutura que conecta dados, lógica e ação é o que gera vantagem competitiva real.
Assisti aos 9 vídeos do evento e mapeei onde nosso sistema (a Ontologia Operacional FSTech) convergia com o que a Palantir descreveu e onde divergia. Resultado: 12 itens de débito técnico priorizados em 3 tiers (P0, P1, P2).
Um desses itens mudou tudo.
A Primitiva: Loop de Otimização Autônomo
Entre os débitos, identifiquei um padrão recorrente: toda vez que otimizávamos algo no sistema, o processo era manual. Tenta, mede, decide se mantém ou descarta, repete. Com um cliente (EVUP), fizemos 6 iterações manuais em um dia para refinar o Lead Bot. Funciona, mas não escala.
Descobri o pi-autoresearch (David Barcelona, 3.800 stars no GitHub), que formaliza exatamente esse loop para o harness Pi. Portei o conceito para nossa Ontologia Operacional, adaptando ao que já tínhamos: Pin/Spec Protocol para persistência, JSONL para logs, Git para versionamento, aprovação humana obrigatória.
O resultado é uma primitiva com 3 operações:
- Inicializar — define a métrica alvo, cria o workspace isolado
- Executar — roda o benchmark, parseia resultados, calcula score de confiança via MAD (Median Absolute Deviation)
- Registrar — grava resultado no log. Se melhorou, mantém. Se piorou, reverte automaticamente para o estado anterior
Simples. O poder não está na complexidade da ferramenta, está no que ela encontra.
O Experimento: Search Engine Interno
Nosso sistema tem um search engine híbrido (FTS5 + Voyage AI) que indexa 3.003 documentos. Toda sessão de trabalho começa com buscas nesse engine. Se ele falha, tudo fica mais lento.
Criei 20 queries reais que usamos no dia a dia e medi a accuracy: quantas vezes o documento correto aparece nos top 5 resultados?
Baseline: 45%. Menos da metade das buscas acertavam.
12 Iterações, 3 Descobertas
Iterações 1-6: Tunando Parâmetros (sem resultado)
Tentei o óbvio primeiro. Aumentar peso de documentos canônicos (specs, pins). Aumentar o pool de candidatos do FTS5. Nada mudou. A accuracy continuava 45%.
Reduzir o threshold para ativar a busca semântica (Voyage AI) funcionou parcialmente: 45% → 55%. Primeiro ganho real.
Mas depois disso, platô. Nenhuma combinação de parâmetros movia a agulha além de 55%.
Iteração 7: O Bug Invisível
Na sétima iteração, o loop fez algo que eu provavelmente não faria manualmente: investigou por que os documentos corretos não apareciam, em vez de apenas tentar novos parâmetros.
Descoberta: o FTS5 encontrava os documentos corretos. Uma busca por "Francielli clínica proposta" retornava o arquivo certo no topo absoluto do ranking (score -19.287). Mas o resultado final mostrava um arquivo irrelevante.
Causa raiz: um JOIN no SQLite entre duas tabelas usava caminhos incompatíveis. Documentos longos são divididos em pedaços (chunks) para indexação, e o caminho de cada pedaço recebe um sufixo (:chunk_0, :chunk_1). O JOIN comparava esse caminho com sufixo contra a tabela de documentos que armazena o caminho sem sufixo. Resultado: 50% dos documentos eram silenciosamente excluídos de todo resultado de busca.
Sem erro. Sem log. Sem aviso. O engine simplesmente ignorava metade do índice.
Fix: 4 linhas de SQL. Impacto:
- Accuracy: 55% → 65%
- FTS-only accuracy: 15% → 55%
- Latência: 616ms → 2.2ms
Iterações 8-12: Pós-Fix
Com o bug corrigido, os parâmetros que antes não tinham efeito passaram a funcionar. Session records (que mencionam muitos projetos com alta densidade de palavras-chave) estavam dominando os resultados. Reduzir o peso deles de 1.3 para 0.8 permitiu que documentos canônicos subissem: 65% → 75%.
Um rebuild do índice (incorporando documentos criados recentemente) elevou para 95%. 19 de 20 queries acertando. O único "erro" restante era um problema de labeling no ground truth, não do engine.
O Número que Importa
| Métrica | Antes | Depois | Delta |
|---|---|---|---|
| Accuracy | 45% | 95% | +111% |
| Latência (p50) | 616ms | 1.6ms | -99.7% |
| Chamadas API semântica | 18/20 queries | 3/20 | -83% |
A busca semântica (Voyage AI) antes ativava em 90% das queries porque o FTS5 falhava. Agora ativa em 15%. O custo de API caiu proporcionalmente, e a latência despencou porque a maioria das buscas resolve localmente em menos de 2 milissegundos.
O Padrão Que Se Repete
Depois do fix no search engine, apliquei a mesma abordagem ao restante do débito técnico DevCon 5. Nove itens que eu estimava em "2 a 4 semanas" foram implementados em 2 horas:
- SQL layer sobre logs operacionais (DuckDB, 797 eventos indexados)
- 5 schemas formais documentando a estrutura do sistema
- Contratos de delegação para subagentes (contexto cirúrgico em vez de dump)
- Feedback estruturado com linking automático à sessão de trabalho
- Framework de avaliação para o canal WhatsApp comercial
- Skill de bootstrap de projetos em um comando
A eficiência não veio do modelo ser mais inteligente. Veio do framework ser mais estruturado. O agente sabe onde buscar (search engine otimizado), sabe o que já existe (toolkit consultado antes de improvisar), sabe o formato esperado (schemas formais), e sabe o que não fazer (16 feedbacks estruturados de erros anteriores).
Por Que Isso Importa Para Você
Se você opera com agentes IA, provavelmente tem bugs silenciosos equivalentes ao nosso JOIN. Coisas que funcionam "mais ou menos" porque ninguém mediu com rigor. Parâmetros default que ninguém questionou. Resultados que parecem razoáveis mas poderiam ser o dobro.
A diferença entre um sistema que funciona e um que se otimiza é uma: instrumentação. Se você não mede, não melhora. Se mede manualmente, melhora devagar. Se automatiza a medição com loop de feedback, o sistema encontra problemas que você nem sabia que existiam.
A Palantir chama isso de "ontologia como alpha". Nós chamamos de Ontologia Operacional. O nome é diferente, a tese é a mesma: o valor não está no modelo, está no que acontece ao redor dele.
Recursos
- Framework de Ontologia Operacional FSTech (CC BY 4.0, 14 seções)
- pi-autoresearch (David Barcelona, MIT, loop autônomo para o harness Pi)
- Palantir DevCon 5 (9 sessões, disponíveis no canal oficial)
- Meta-Harness (Stanford, Omar Khattab) para fundamentação de session traces
- FTS5 (SQLite) + Voyage AI como stack de search híbrido
