Como construir uma camada de conhecimento canônica em 30 dias (a base de todo workflow de IA)

Todo time com que trabalho em infraestrutura de IA tem a mesma primeira pergunta: "O que devemos construir primeiro?" E quase todo time que trabalha sozinho responde errado — escolhe o workflow mais visível (chatbot voltado para cliente, agente de vendas) em vez da fundação da qual tudo o mais depende.

A fundação é a camada de conhecimento canônica. É a espinha. Se você constrói bem, todo agente downstream fica mais barato, rápido e preciso. Se não constrói, todo agente downstream falha do mesmo jeito — alucinando com confiança porque não tem verdade fundamental para consultar.

Esse é o plano de 30 dias que rodamos em engajamentos quando a camada de conhecimento é o primeiro sprint.

Por quê 30 dias

Timelines em aberto matam projetos de camada de conhecimento.

O plano é "vamos ingerir tudo, depois expor." Seis meses depois, o time ingeriu 60% das fontes, o schema mudou três vezes, e nenhum agente foi construído em cima. O projeto morre silencioso porque nunca produziu um output visível.

A cadência de 30 dias força o oposto: enviar uma espinha funcional com as 3 fontes principais, provar um agente contra ela, documentar, fazer handoff. Depois iterar. A espinha fica melhor a cada trimestre porque tem algo para melhorar. Planos em aberto pioram porque nada é load-bearing.

O que "canônica" significa aqui

Canônica = uma fonte de verdade por fato.

Se os termos de contrato de um cliente existem em três lugares (página no Notion, PDF no Drive, e-mail do seu jurídico), a camada de conhecimento canônica representa os termos uma vez, com proveniência apontando para as três fontes. O agente que recupera recebe uma resposta limpa mais uma citação que pode verificar.

Sem canonicalização, seu pipeline de retrieval acha três versões contraditórias do mesmo fato e o agente escolhe o resultado de maior similaridade — que pode ser o desatualizado. Essa é a causa-raiz da maioria das reclamações de "alucinação de IA" dentro de empresas que têm dados relevantes. Não é alucinação. É source-of-truth incoerente.

O trabalho da camada canônica: todo fato tem uma representação autoritativa, e updates nesse fato propagam no momento que acontecem.

A divisão dos 30 dias

Dias 0–3: Escope a superfície de conhecimento

Liste todo sistema que contém conteúdo durável do negócio. Qualquer coisa que não seja comunicação transitória (DMs de Slack, docs descartáveis) está em escopo:

• Drives compartilhados (Google Drive, Dropbox, OneDrive)
• Wikis e docs (Notion, Confluence, Coda, GitBook)
• CRMs (Salesforce, HubSpot, Pipedrive)
• Sistemas de suporte (Intercom, Zendesk, Front)
• Reuniões gravadas (Gong, Fathom, Otter)
• E-mail + calendário (filtrados para threads de alto sinal)
• Código + design (Linear, GitHub, Figma — para empresas product/eng-led)

Para cada um: etiquete por canonicidade (onde mora a verdade? Onde moram versões conflitantes?), padrão de acesso (quem lê? de onde?), e frequência de update (quão velha a versão indexada fica?).

Não é exercício de planejar-para-planejar. É o backlog de conectores. As 5 principais por alavancagem viram o trabalho dos próximos 25 dias.

Dias 4–10: Envie conector + pipeline de embedding para as 3 fontes principais

Escolha três fontes. Combinação vencedora comum: drive compartilhado + CRM + transcrições de reunião.

• Drive compartilhado tem políticas, contratos, especs de produto (alto sinal, updates de baixa frequência)
• CRM tem estado do cliente, contexto de deal, histórico de conversa (alto sinal, updates frequentes)
• Transcrições de reunião têm o conhecimento não-escrito (decisões, contexto, indivíduos nomeados) que não mora em lugar nenhum

Envie ingestão (backfill inicial + sync incremental), chunking (não fique discutindo — 800 tokens com 100 de overlap é ponto de partida defensável), embedding em um vector DB (pgvector no seu Postgres existente funciona; Pinecone ou Qdrant se ultrapassar depois).

Cuidado com: PDFs com extração de texto ruim (use OCR se necessário), fronteiras de permissão (não indexe documentos que o usuário do agente não deveria ver), e transcrições de reunião sem atribuição de speaker (mata qualidade de retrieval).

Dias 11–18: Construa pipeline de retrieval + conjunto de avaliação

Retrieval híbrido — combine busca semântica (vector) com keyword (BM25 ou similar). Adicione re-ranker em cima. A maioria dos times pula o re-ranker; você não deveria, porque é a diferença entre "o documento certo em algum lugar do top 20" e "o documento certo na posição 1."

Crítico: construa o conjunto de avaliação em paralelo. 30–50 casos de teste de retrieval curados à mão a partir de perguntas reais que seu time fez. Cada teste tem uma pergunta e o(s) documento(s) esperados que deveriam ser recuperados. A avaliação roda a cada mudança — todo tweak de chunking, todo swap de modelo de embedding, toda config de re-ranker.

Sem a suíte de avaliação, drift de qualidade de retrieval é invisível. Com ela, você troca qualquer componente e imediatamente vê o delta de qualidade.

Dias 19–25: Envie um agente end-to-end que usa a camada

Escolha um workflow repetitivo que seu time atualmente faz manual:

• Rascunho de proposta (recupera case studies + templates de contrato → rascunha seção por seção)
• Triagem de cliente (recupera contexto do cliente + casos passados similares → rascunha resposta com confiança)
• Relatório de status (recupera atividade de CRM da semana + notas de reunião → produz relatório estruturado)

Construa o agente end-to-end. O output do agente não é o entregável. O agente é a prova de que a camada de conhecimento é consultável para trabalho real. Se o agente funciona para um workflow, vai funcionar para mais dez — e adicionar os próximos dez é principalmente lógica de negócio, não infraestrutura.

Dias 26–30: Documentação, handoff, transferência de propriedade

O sistema tem que sobreviver ao engajamento. Isso significa:

• Doc de arquitetura de uma página: o que está onde, como conecta, o que falha se X quebra
• Runbook para adicionar fonte: como um engenheiro sênior adiciona um conector novo
• Doc da suíte de avaliação: como adicionar casos de teste, como interpretar o dashboard
• SLA com dono nomeado: quem está de plantão se retrieval cai abaixo de X precisão, quem renova as API keys, quem vigia o gasto de tokens

Se um engenheiro sênior consegue estender o sistema daqui a 90 dias sem nossa ajuda, o engajamento teve sucesso. Se não consegue, não teve — mesmo que a demo tenha sido linda.

O que você NÃO deve fazer nos primeiros 30 dias

• Não tente ingerir tudo. As 3 fontes principais cobrem 60–80% das queries de alta alavancagem. O resto é backlog, não pré-requisito.
• Não escolha o workflow mais visível como primeiro agente. Escolha o mais representativo. Chatbots voltados para cliente têm o modo de falha errado para o ciclo 1 (erros visíveis). Workflows internos te deixam falhar com segurança.
• Não over-arquitete a suíte de avaliação no dia um. 30–50 perguntas curadas à mão são suficientes para enviar o ciclo 1. Sofisticação do framework de avaliação compõe em ciclos depois, não na semana um.
• Não trave em um vector DB que você nunca operou. Use o que seu time consegue debugar. pgvector no Postgres existente é o default a não ser que tenha razão específica para não.

O que você pode construir em seguida, uma vez que a espinha existe

Uma vez que a camada de conhecimento está em produção com o primeiro agente em cima, você está equipado para enviar — em ordem que maximiza ROI:

• O 2º–4º agentes (cada um leva 5–10 dias agora, não 20)
• Profundidade da suíte de avaliação (saia de 50 casos para 200, automatize a curadoria)
• Camada de inteligência de cliente estruturada (extraindo JTBD, sentimento, gatilhos de switching de transcrições de reunião + casos de suporte)
• Camada de outbound (usando a inteligência de cliente para guiar sequências context-aware)
• Playbook de troca de modelo (sua suíte de avaliação agora está madura o suficiente para A/B upgrades de modelo)

Nenhuma delas funciona sem a espinha. Todas compõem em cima dela.

Como rodamos esse engajamento

Um sprint de camada de conhecimento de 30 dias é um engajamento Apex focado. Um operador sênior (eu) + um engenheiro sênior se o escopo justifica. Stand-ups diários, demo semanal, preço fixo. O output é o sistema + a documentação + o dono interno treinado. A gente faz handoff, você opera.

Se seu time já está tentando construir internamente e travando — a falha mais comum é a semana 2, quando ingestão expande mais rápido do que o schema consegue absorver — o sprint também funciona como missão de resgate para voltar para a espinha de 30 dias.

Esse é o primeiro sistema no inventário de 7 sistemas. É o sistema do qual tudo depende. Construa uma vez. Construa bem. O resto segue.