A base de conhecimento, e o limite do prompt

No MVP, o conhecimento do agente cabia num campo de texto. Funcionou até o terceiro cliente.

Uma imobiliária tem centenas de imóveis, cada um com metragem, valor, condomínio e condição. Uma clínica tem dezenas de procedimentos, cada um com preparo, duração, contraindicação e valor por convênio. Um e-commerce tem catálogo, política de troca, prazo por região e regra de frete.

Isso não cabe em prompt. E o problema não é só de tamanho.

Por que empilhar tudo no prompt falha

Custo. Contexto é cobrado por token, a cada mensagem. Mandar o catálogo inteiro em toda pergunta é pagar mil vezes por informação que o cliente usou uma.

Qualidade. Modelo de linguagem não trata todo o contexto com o mesmo peso. Enterrar a informação relevante no meio de vinte páginas piora a resposta em comparação a mandar só o parágrafo certo. Mais contexto não é melhor contexto.

Limite físico. Toda janela tem fim, e catálogo grande simplesmente não entra.

Atualização. Preço mudou, produto saiu de linha. Se o conhecimento está colado no prompt, atualizar significa reconfigurar o agente.

O que a gente construiu

A base de conhecimento virou um módulo próprio, onde o cliente insere conteúdo em vários formatos:

• Texto livre — política, procedimento, instrução
• Perguntas e respostas — o FAQ que o time já respondia manualmente
• Produtos e serviços — estruturados, com preço, descrição e atributos
• Informações da empresa — horário, unidade, forma de pagamento, área de atendimento
• Documentos — material que a empresa já tinha pronto

Cada item é indexado. Na hora da conversa, a plataforma recupera só o que é relevante para aquela pergunta e monta o contexto do modelo com isso.

  cliente pergunta
        │
        ▼
  ┌─────────────────────────────────────────────┐
  │ recuperação                                 │
  │  · busca no conhecimento vinculado ao agente│
  │  · filtra por conta e por canal             │
  │  · devolve os N trechos mais relevantes     │
  └───────────────────┬─────────────────────────┘
                      ▼
  ┌─────────────────────────────────────────────┐
  │ montagem do contexto                        │
  │  · configuração do agente (tom, limites)    │
  │  · trechos recuperados                      │
  │  · histórico recente da conversa            │
  └───────────────────┬─────────────────────────┘
                      ▼
                  modelo → resposta

É o padrão que ficou conhecido como RAG, e ele resolve os quatro problemas de uma vez: manda pouco contexto (barato), manda o contexto certo (qualidade), não esbarra em limite, e atualizar conteúdo não mexe no agente.

As decisões que custaram mais

Isolamento por conta é requisito de segurança, não de organização

Cada busca é filtrada por conta antes de qualquer coisa. Vazamento de conhecimento entre clientes numa plataforma multi-tenant não é bug de funcionalidade — é incidente de segurança. Isso está no nível da consulta, não numa camada de aplicação que alguém pode esquecer de chamar.

Conhecimento é vinculado ao agente, não à conta

Veio direto do construtor de agentes. Um cliente pode ter um agente de vendas que enxerga o catálogo e um de suporte que enxerga as políticas de troca. Se todo agente visse tudo, o de suporte começaria a vender.

Granularidade do conteúdo

O erro inicial foi tratar cada documento como uma unidade. Um documento de política com quinze cláusulas era recuperado inteiro, e o modelo recebia catorze cláusulas irrelevantes junto com a certa.

Fatiar o conteúdo em pedaços menores e coerentes melhorou a resposta de forma perceptível — pelo mesmo motivo que empilhar tudo no prompt falhava, só que numa escala menor. A qualidade da recuperação decide a qualidade da resposta, e nenhum modelo melhor compensa recuperação ruim.

Conteúdo estruturado não é texto

Produto tem preço, e preço é número. Tratar catálogo como texto corrido significava não conseguir responder “quanto custa o modelo X” com precisão nem filtrar por faixa de valor.

Produtos e serviços viraram entidade estruturada, com o texto servindo para encontrar e os campos servindo para responder.

Onde isso encaixou na arquitetura

A base de conhecimento é mais um módulo, consumido pelo worker no momento de montar o contexto. O app é onde o cliente cadastra; o worker é onde é usado; os microsserviços de canal continuam sem saber que ela existe.

É o terceiro módulo grande que entrou sem tocar no núcleo. A essa altura ficou claro que a decisão de dezembro tinha sido a certa.