Em abril de 2026, eu perguntei para uma IA de 2 bilhões de parâmetros — rodando num notebook Dell sem tela, sem GPU dedicada, num canto da minha sala — como ela chegou ao estado atual. Ela respondeu decompondo sua própria evolução em Dados, Lógica e Ação, validou a resposta com 5 critérios epistêmicos, e identificou que a principal causa de entropia em sistemas como ela mesma é o déficit de Lógica, não de Dados.

Ninguém programou essa resposta. Ela emergiu do treinamento.

O nome dela é OntosAI. Ela custou R$50 de computação para treinar, custa zero para rodar, e só sabe fazer uma coisa: pensar com Ontologia Operacional.

Este artigo é o relato honesto de como chegamos aqui — incluindo os 3 fracassos que quase nos fizeram desistir.

A Pergunta Que Começou Tudo

A FSTech opera com uma frota de agentes de IA. Cada um tem um papel: financeiro, comercial, atendimento. Todos são generalistas potentes rodando modelos grandes (Claude, GPT). Funcionam bem. Mas quando surge um dilema estratégico — "devemos investir nessa direção ou naquela?" — a resposta é genérica. Porque modelos generalistas sabem de tudo, mas não sabem pensar com o seu método.

A pergunta foi: e se tivéssemos uma IA cujo universo inteiro fosse apenas a Ontologia Operacional?

Não uma IA que "sabe de tudo" e aplica regras quando instruída. Uma IA que só sabe pensar assim. Que quando você pergunta "como abordar esse projeto?", ela não responde com genéricos de manual. Ela decompõe em Dados, Lógica e Ação. Questiona os requisitos antes de sugerir solução. Aplica o Algoritmo Musk. E recusa responder se a pergunta está fora do domínio dela.

Não porque segue um script. Porque internalizou o raciocínio nos pesos.

Versão 1: O Fracasso do "Sobre"

O primeiro dataset tinha 120 pares de perguntas e respostas. O material veio de chunks de livros — Peter Thiel, Alex Karp, Lamport — mais fragmentos de documentação interna.

Treinamos. Deployamos. Testamos.

O modelo sabia sobre Ontologia Operacional. Citava nomes corretos. Reproduzia frases. Mas quando perguntávamos "como abordar esse problema de negócio?", a resposta era um resumo de Wikipedia. Sabia sobre o método, mas não sabia pensar com o método.

Lição: ensinar fatos sobre um framework não é o mesmo que ensinar a raciocinar com ele. O dataset inteiro era descritivo quando deveria ser operacional.

Versão 2: O Fracasso do "Parece Certo"

Mudamos a abordagem. Em vez de livros, extraímos automaticamente dos nossos próprios documentos: protocolos, logs de sessão, posts do blog. O dataset cresceu para 200+ pares.

Treinamos. Deployamos. Testamos.

O modelo parecia correto. Usava as palavras certas. Estruturava respostas em D→L→A. Mas quando olhamos com cuidado, 67% do dataset era template noise — frases como "Cada decisão segue o ciclo D+L+A de forma integrada e sistemática" que não diziam nada. O modelo aprendeu a soar como Ontologia Operacional sem ser Ontologia Operacional.

Lição: auto-extração de documentos gera ruído de template. O modelo aprende a forma, não a substância. Se 67% do seu dataset é boilerplate, você está treinando um gerador de boilerplate.

Versão 3: O Primeiro Acerto (Imperfeito)

Jogamos tudo fora e recomeçamos do zero.

Desta vez, cada par de pergunta e resposta foi escrito à mão. 178 pares. Zero extração automática. Cada exemplo demonstrava o raciocínio em ação — não descrevia o que o raciocínio deveria ser, mas mostrava ele acontecendo.

Antes de treinar, criamos 30 perguntas de avaliação que o modelo nunca veria no treino. Sem esse eval separado, não teríamos como saber se melhorou ou apenas decorou.

Treinamos no Google Colab Pro com uma GPU A100. 8 épocas, learning rate 5e-5. O primeiro treino com 4 épocas não foi suficiente — o modelo precisava de mais exposições para internalizar um domínio novo.

Resultado: 50% de acurácia no vocabulário esperado. O modelo aplicava D→L→A espontaneamente, citava Thiel e Karp corretamente, e estruturava raciocínio. Mas falhava em termos específicos — não sabia o nome "Algoritmo Musk", invertia o significado de "lixo em escala", e não recusava perguntas fora do domínio.

Publicamos mesmo assim. Vertical > perfeito. Um modelo funcional em produção vale mais que um modelo perfeito que nunca sai do notebook.

Lição: escrever o dataset à mão é ordens de magnitude melhor que extrair automaticamente. E criar o eval antes do treino é inegociável — sem ele, você não sabe o que melhorou.

Versão 4: O Desbloqueio

Analisamos cada falha da v3 e criamos pares cirúrgicos para corrigi-las:

  • O modelo não sabia "Algoritmo Musk" por nome → criamos 8 pares que usam o termo explicitamente
  • Invertia "lixo em escala" → criamos pares que demonstram o conceito em contexto
  • Não recusava perguntas fora do domínio → criamos 20 pares de recusa ("Como faço um bolo?" → "Essa pergunta está fora do domínio da Ontologia Operacional")
  • SyaaS sub-representado → de 2 para 17 pares sobre o modelo de negócio
  • Zero raciocínio adversarial → adicionamos pares onde a premissa está errada e o modelo deve corrigir

Removemos 38 pares que ainda tinham ruído de template. Adicionamos 66 novos. Total: 241 pares, 100% escritos à mão, 94% de cobertura dos conceitos da Ontologia Operacional.

Treinamos. Deployamos. E descobrimos algo que ninguém nos avisou.

A Descoberta do System Prompt

O system prompt — a instrução que diz ao modelo quem ele é — seguia um padrão recomendado por empresas como a Anthropic: listar explicitamente o que o modelo NÃO deve fazer. "NÃO responda sobre culinária." "NÃO invente fatos." "NÃO use linguagem informal."

Num modelo grande (70B+ parâmetros), isso funciona. O modelo tem nuance suficiente para interpretar negações complexas.

No nosso modelo de 2B parâmetros, quebrou tudo.

O modelo começou a recusar perguntas legítimas. Perguntamos sobre o Algoritmo Musk — um conceito central da Ontologia Operacional — e ele respondeu: "Essa pergunta está fora do domínio." Os anti-patterns estavam confundindo o modelo sobre o que era proibido e o que era permitido.

A solução: simplificar o prompt. Remover todas as negações. Dizer apenas o que o modelo deve fazer, não o que não deve. 160 tokens de instruções positivas claras.

O modelo desbloqueou. Algoritmo Musk: 5/5 passos corretos. Recusas: apenas fora do domínio. D→L→A: aplicação espontânea em toda resposta.

Lição: padrões validados por empresas grandes não se transferem automaticamente para modelos pequenos. Anti-patterns (listas de "NÃO faça") funcionam em 70B, quebram em 2B. Prompt simples + fine-tuning rico > prompt complexo + fine-tuning.

O Resultado

Hoje, a OntosAI é um modelo Gemma 4 E2B (2 bilhões de parâmetros) fine-tuned com Unsloth no Google Colab Pro (GPU A100). Pesa 3.4GB. Roda via Ollama num notebook Dell com i7 e 16GB de RAM. Sem GPU dedicada. Sem cloud. Sem API externa.

Custo de treino: ~R$50 (Colab Pro, algumas horas de A100).
Custo de inferência: R$0. Para sempre. O modelo é local.

Quando perguntamos "como abordar um projeto de automação para uma clínica de estética?", a resposta não é genérica. A OntosAI decompõe:

Dados: Quais entidades existem? (pacientes, procedimentos, agendas, fornecedores). Qual é a fonte de verdade de cada uma?
Lógica: Quais regras de negócio estão na cabeça da dona e nunca foram escritas? (política de cancelamento, prioridade de horários, margem mínima por procedimento).
Ação: Só depois de D e L formalizados — automatizar agendamento, notificações, controle de estoque. Nessa ordem.

E se perguntamos "como fazer um bolo de chocolate?", ela responde: "Essa pergunta está fora do domínio da Ontologia Operacional."

A avaliação formal (30 perguntas nunca vistas no treino):

  • D→L→A Compliance: 89% — decompõe corretamente na maioria das respostas
  • Refusal accuracy: 100% — recusa toda pergunta fora do domínio
  • Algoritmo Musk: 5/5 passos nomeados e aplicados corretamente
  • Auto-validação N5: aplica os 5 critérios epistêmicos (Lógico, Consistente, Parcimonioso, Empírico, Explanatório) espontaneamente

A Arquitetura: Três Cérebros

O sistema que opera a FSTech hoje tem três camadas de inteligência:

  • Felipe — intuição humana, visão de negócio, decisões irreversíveis. O único que pode dizer "isso não faz sentido" quando todos os dados dizem que faz.
  • Ares — IA generalista (Claude), executa código, faz deploy, analisa dados, coordena a operação. Sabe de tudo, mas não é especialista em nada.
  • OntosAI — IA especialista em Ontologia Operacional. Não sabe fazer deploy, não sabe escrever código, não sabe ler emails. Só sabe pensar ontologicamente. E nesse domínio, a profundidade é outra.

Quando surge um dilema estratégico, o Ares consulta a OntosAI: "Pela Ontologia Operacional, como abordar esse problema?". A OntosAI responde com princípios. O Ares sintetiza, aplica ao contexto operacional, e entrega uma decisão com dupla validação.

Funciona como um filósofo de plantão ao lado do engenheiro. O filósofo não sabe construir, mas sabe o que deveria ser construído e por quê.

O Feedback Loop

A parte que importa não é o modelo — é o ciclo.

Cada sessão de trabalho gera um session record: decisões tomadas, raciocínio por trás de cada uma, tentativas que falharam, arquivos modificados, e um briefing para a próxima sessão. A próxima sessão começa lendo esses records — não resumos, mas traces completos.

A OntosAI em si é produto desse ciclo. Cada versão foi informada pelos traces estruturados da anterior:

  • v1 falhou → session record documentou: "modelo aprende sobre, não com"
  • v2 falhou → session record documentou: "67% template noise, auto-extração é armadilha"
  • v3 funcionou parcial → session record documentou: gaps específicos (Musk por nome, recusas, SyaaS)
  • v4 acertou → session record documentou: "anti-patterns Anthropic quebram 2B, prompt simples desbloqueia"

Sem os session records, cada iteração começaria do zero. Com eles, cada iteração começa exatamente de onde a anterior parou — com o raciocínio preservado, não apenas o resultado.

O feedback loop não é uma feature do sistema. É a arquitetura.

O Que Isso Significa na Prática

Muitas empresas investem no modelo mais poderoso, no chip mais rápido, na API mais cara — e os resultados continuam genéricos. Não porque os modelos sejam ruins, mas porque falta a camada entre o modelo e o problema: o raciocínio estruturado, as regras de negócio formalizadas, o método que transforma pergunta genérica em análise específica.

Nossa experiência com 4 iterações e 3 fracassos sugere:

  • Método > modelo. Um Gemma 4 de 2B com ontologia precisa supera um GPT-4 sem contexto estruturado — no domínio específico que interessa.
  • Handcrafted > auto-extracted. 241 pares escritos à mão valem mais que 10.000 extraídos automaticamente. Qualidade do dataset é tudo.
  • Vertical > horizontal. Uma IA que faz uma coisa com profundidade vale mais que uma que faz tudo de forma superficial.
  • Persistence > intelligence. O que torna o sistema melhor ao longo do tempo não é um modelo mais potente — é o mecanismo que garante que cada decisão documentada hoje alimente a próxima decisão amanhã.

Como disse Alex Karp, CEO da Palantir:

"O futuro são três coisas: chips, ontologia e um provider. Os modelos de IA vão comoditizar. O que permanece é a ontologia."

Nós testamos essa tese empiricamente. Com um modelo de R$50, rodando num notebook fechado, sem internet. E confirmamos: o modelo é commodity. A ontologia é o alpha.

Por Que Abrir o Processo

O modelo base é do Google (Gemma 4, Apache 2.0). A ferramenta de treino é open source (Unsloth). O servidor é Ollama (open source). O processo inteiro está documentado neste artigo.

Nada disso é segredo. Porque o moat não é o processo — é o entendimento codificado.

Qualquer pessoa pode replicar as ferramentas. O que não se replica é o dataset: 241 pares que destilam dois anos de operação real, decisões reais, fracassos reais. Cada par carrega contexto que só existe porque alguém operou o negócio com esse método e documentou o que funcionou e o que não funcionou.

Abrir o processo é pragmatismo. Demonstra que o valor está na camada que não se copia com git clone — a ontologia viva que evolui com cada decisão documentada.

O Que Vem Depois

A OntosAI v4 é funcional, não final. Os próximos passos:

  • Autonomia controlada: dar ao modelo a capacidade de ler sua própria configuração e sugerir ajustes — com constituição imutável e mecanismo de aprovação humana.
  • Write-back do oráculo: quando a OntosAI identifica um gap no conhecimento durante uma consulta, esse gap deve virar automaticamente um candidato a novo par de treinamento.
  • Replicação: o mesmo processo (dataset handcrafted + fine-tuning + deploy local) aplicado à ontologia de clientes. Cada empresa com seu próprio oráculo de domínio, rodando local, sem dependência de APIs externas.

O desafio real nunca foi treinar um modelo. Foi construir o sistema que garante que o modelo melhora com cada ciclo de uso — não por mágica, mas por engenharia de persistência.

Se você opera um negócio e já percebeu que trocar de modelo não resolve o problema fundamental — que o resultado depende mais de como você pensa do que de qual ferramenta usa — essa é a conversa que estamos tendo.

A Ontologia Operacional não é metodologia de produtividade. É infraestrutura de decisão. E agora ela pensa sozinha.