Como Construi uma Secretária Executiva Virtual que Realmente Funciona

Principais conclusões

• Para dados determinísticos, tire o LLM do caminho — use SQL direto
• Nunca confie no prompt para proibir comportamentos — use código
• A ortografia é um sistema, não uma instrução — 300+ mapeamentos
• Deploy não é commit — o servidor precisa ser reiniciado

O problema: IA que inventa em vez de consultar

Tudo começou com uma pergunta simples no WhatsApp: “qual meu voo dia 25?”. A resposta que recebi foi “DADOS NAO ACESSIVEIS”. O problema: o voo LA3348 Recife-Brasília estava registrado no banco de dados SQLite, com horário, assento e companhia. O LLM simplesmente não consultou o banco. Preferiu confessar ignorância a fazer uma query.

Esse é o paradoxo central de assistentes baseados em LLM: eles são otimizados para gerar texto plausível, não para consultar fontes estruturadas. Quando você tem um DataHub com 243 fatos pessoais, 24 registros de viagem e 26 assinaturas ativas, a última coisa que você quer é que o modelo “imagine” a resposta.

A confabulação não é um bug — é o comportamento padrão do LLM. O bug estava na minha arquitetura, que delegava tudo ao modelo sem nenhuma camada de verificação.

A arquitetura que falhou

A primeira versão tinha uma arquitetura ingenuamente simples: mensagem chega no WhatsApp, vai para o LLM classificar a intenção, e o mesmo LLM gera a resposta. Tudo passava pelo modelo. Cada token consumido, cada milissegundo gasto, cada centavo cobrado.

O DataHub estava populado: 243 fatos determinísticos (CPF, endereços, dados bancários), 24 registros de viagem com voos e hotéis, 26 assinaturas de serviços com datas de renovação. Tudo em SQLite, indexado e pronto para consulta. Mas o LLM ignorava sistematicamente esses dados.

O modelo recebia o contexto completo no system prompt — e mesmo assim preferia gerar respostas genéricas. Em testes, 40% das perguntas sobre dados disponíveis no banco recebiam respostas inventadas ou evasivas. A confiança no sistema era zero.

A virada: dados determinísticos primeiro

A solução foi inverter a arquitetura. Em vez de “tudo passa pelo LLM”, adotei três camadas com prioridade clara: detecção por palavras-chave primeiro (menos de 100ms, custo zero), classificação por LLM em segundo lugar, e geração por LLM apenas como último recurso.

# Pipeline de 3 camadas
Mensagem recebida
  |
  v
[1] Keyword Detection (<100ms, $0)
    - "meu voo", "viagem", "hotel" -> SQL direto
    - "cpf", "endereco", "banco"   -> DataHub lookup
    - Match? -> Resposta imediata
  |
  v (sem match)
[2] LLM Classification (~500ms, ~$0.003)
    - Identifica intencao
    - Roteia para handler correto
  |
  v (necessita geracao)
[3] LLM Generation (~3s, ~$0.01)
    - Gera resposta contextualizada
    - Post-processing obrigatorio

Com essa mudança, 85% das consultas passaram a ser resolvidas na camada 1, diretamente no SQLite. O tempo de resposta caiu de 3-8 segundos para menos de 100 milissegundos nesses casos. O custo por consulta determinística: zero.

O LLM insiste em ser útil

Resolver o roteamento foi metade do problema. A outra metade: quando o LLM era acionado, ele insistia em “ajudar” de formas indesejadas. Respostas vinham com “PROTOCOLO ATUALIZADO”, emojis decorativos, e perguntas retoriças como “Quer que eu busque mais detalhes?”. Nenhuma dessas adições era solicitada.

A primeira tentativa foi ajustar o system prompt. Troquei “assistente pessoal” por “formatador de dados”. Adicionei regras explícitas: “nunca adicione emojis”, “nunca faça perguntas de follow-up”. Funcionou por 80% dos casos. Os outros 20% continuavam vazando comportamento indesejado.

A solução definitiva foi programática: 30+ padrões regex no pós-processamento. Qualquer “PROTOCOLO”, qualquer emoji Unicode, qualquer “Posso ajudar com mais alguma coisa?” é removido automaticamente antes de a mensagem ser enviada. Não se confia no prompt para proibir — usa-se código.

Ortografia como sistema

Um assistente executivo que escreve “nao” em vez de “não” ou “voce” em vez de “você” perde credibilidade imediatamente. LLMs em português frequentemente omitem acentos, especialmente em respostas curtas e rápidas.

Portei 300+ mapeamentos de acentuação do projeto curso-factory: de “informacao” para “informação”, de “producao” para “produção”, de “voce” para “você”. Além disso, 29 clichês banidos (“vamos lá”, “com certeza”) e um stripper de emojis Unicode.

O pipeline de pós-processamento opera em 4 etapas: primeiro remove emojis, depois aplica os mapeamentos de acentuação, em seguida remove clichês e frases banidas, e por fim valida o formato final. Cada mensagem passa por essas 4 etapas antes de ser enviada ao usuário. Ortografia não é uma instrução no prompt — é um sistema com código.

A armadilha do deploy

Durante duas semanas, fiz 15 correções no código. Todas passavam nos testes locais. Nenhuma aparecia em produção. O WhatsApp continuava respondendo com o comportamento antigo: emojis, confabulação, frases genéricas.

O problema era trivial e humilhante: o servidor não havia sido reiniciado. O processo antigo continuava rodando com o código da versão anterior. Commits estavam no repositório, mas o runtime estava congelado. Deploy não é commit. Deploy é o momento em que o novo código efetivamente serve requisições.

A lição levou à criação de um script de deploy que inclui reinicialização automática e health check pós-restart. Nunca mais um commit vai ficar invisivel em produção porque o servidor não foi reiniciado.

22 bugs em uma auditoria

Após estabilizar a arquitetura básica, realizei uma auditoria profunda do sistema. O resultado: 22 bugs identificados, sendo 4 críticos. O tipo de problema que só aparece quando você testa sistematicamente cada endpoint e cada fluxo.

Entre os críticos: o comando /criar aceitava números de telefone vazios e criava registros inválidos no banco. O módulo /viagem ainda lia um arquivo JSON depreciado em vez de consultar o SQLite. O leitor de email usava escopos OAuth incorretos, falhando silenciosamente sem nenhum log de erro.

A auditoria revelou um padrão: a maioria dos bugs não era de lógica, mas de integração. Cada módulo funcionava isoladamente. As falhas estavam nas fronteiras entre módulos — onde formatos de dados não batiam, onde validações estavam ausentes, onde migrações estavam incompletas.

Resultado: dados, não opiniões

Antes da refatoração, uma pergunta como “qual meu próximo voo?” retornava algo como “PROTOCOLO ATUALIZADO - Verificando dados de viagem... DADOS NAO ACESSIVEIS”. Após a refatoração, a mesma pergunta retorna: “Voo LA3457, assento 7A, Brasília para São Paulo, 28/04 às 14:30”. Dados concretos, sem decoração.

A diferença não é apenas estética. O sistema antigo gastava 3 a 8 segundos e US$ 0,01 por consulta para gerar uma resposta frequentemente errada. O sistema atual responde em menos de 100 milissegundos, com custo zero, e precisão de 100% — porque a resposta vem diretamente do SQL, não de uma geração probabilística.

Antes vs Depois: métricas da mudança

Lições para quem constrói assistentes com IA

1. Dados determinísticos nunca devem passar pelo LLM.Se a resposta existe num banco de dados, consulte o banco diretamente. O LLM só deve ser acionado quando não há dado estruturado disponível.
2. Prompts não são barreiras.Se você precisa garantir que algo nunca aconteça (emojis, clichês, perguntas retóricas), implemente em código com regex e pós-processamento.
3. Ortografia é infraestrutura.Mapeamentos de acentuação, listas de termos banidos e validação de formato devem ser sistemas, não instruções em prompts.
4. Teste as fronteiras, não os módulos.Bugs de integração são mais comuns e mais difíceis de detectar que bugs de lógica isolada.
5. Deploy inclui restart e health check.Código commitado que não está rodando em produção não existe. Automatize o ciclo completo.

Quer construir um assistente que responde com fatos?

Compartilho a arquitetura, os padrões de pós-processamento e as lições de 22 bugs corrigidos. Vamos conversar.

Leia também

• Newsletter GEO Report: versão expandida deste artigo no Substack
• Case: Sprint GEO em 20 Horas
• Guia Executivo: Alucinações de IA
• Governança de Dados e Confiança em IA
• Dicionário de Dados: 64 tabelas documentadas

Sobre o Autor

Alexandre Caramaschié CEO da Brasil GEO, ex-CMO da Semantix (Nasdaq) e cofundador da AI Brasil. Trabalha na interseção entre inteligência artificial, dados estruturados e automação de processos executivos. Este artigo documenta a construção de sua própria secretária executiva virtual no WhatsApp — com todas as falhas e lições do caminho.