DigitalCube AI
FALE CONOSCO
Voltar ao blog

Como criar um clone digital da sua Knowledge Base interna com n8n, Notion e um bot de Slack com IA

Angel Blancas - DigitalCube.AI

23 de julho de 2026

10 min de leitura

ES
EN
PT
n8n
AI Agent
Como criar um clone digital da sua Knowledge Base interna com n8n, Notion e um bot de Slack com IA

Toda a informação da sua empresa, acessível para qualquer funcionário em 2 segundos pelo Slack.

Com pressa? Não leia o artigo. Se você sabe usar o n8n, copie você mesmo nos seus servidores.

Baixar o JSON deste workflow (grátis)

Prefiro que a DigitalCube implemente por mim

O problema: sua documentação existe, mas ninguém encontra

Quase todas as empresas com que trabalhamos apresentam o mesmo padrão. A documentação interna existe: políticas de férias, manuais de onboarding, processos de compras, diretrizes de segurança. Vive no Notion, no Google Drive, em algum wiki que alguém montou com boa intenção. E mesmo assim, as mesmas perguntas se repetem toda semana no Slack: quantos dias de férias eu tenho, como peço um notebook, o que faço se perder o celular da empresa.

O custo não é só o tempo de quem pergunta. É o de quem responde: normalmente as duas ou três pessoas de People, TI ou Operações que funcionam como buscadores humanos da organização. Cada interrupção é uma troca de contexto, e a resposta dada de memória nem sempre coincide com a versão vigente do documento.

A busca nativa dessas ferramentas não resolve o problema, porque exige saber quais palavras exatas o autor do documento usou. Um funcionário que pergunta "perdi meu notebook, o que faço?" nunca vai encontrar uma página chamada "Diretrizes de segurança e acessos". A busca por palavra-chave falha justamente onde é mais necessária: quando a pergunta e o documento não compartilham vocabulário.

O que segue é a receita completa do workflow que resolve isso. Não uma descrição de alto nível: o passo a passo com as decisões técnicas justificadas, o prompt exato de produção e o JSON para você importar no seu n8n ainda hoje.

A arquitetura: RAG sobre a sua própria documentação

O sistema é uma implementação de RAG (Retrieval-Augmented Generation) com duas ramificações independentes dentro de um mesmo workflow do n8n:

Ramo 1, a ingestão. Toda noite, o workflow lê todas as páginas da database do Notion onde vive a documentação, extrai o conteúdo em texto, divide em fragmentos e os converte em vetores numéricos (embeddings) armazenados em um banco de dados vetorial: Pinecone na nossa versão, embora Qdrant ou Supabase com pgvector funcionem com mudanças mínimas.

Imagen

Ramo 2, o bot. Quando um funcionário escreve em um canal específico do Slack, um agente de IA converte a pergunta em vetor, busca os fragmentos semanticamente mais próximos no banco vetorial, redige uma resposta usando apenas esse contexto e a publica na thread da mensagem, citando o documento do Notion de origem com link direto.

Imagen

A palavra-chave é "semanticamente". Embeddings capturam significado, não palavras. "Perdi meu notebook" e "em caso de roubo ou extravio de dispositivos corporativos" ficam próximos no espaço vetorial mesmo sem compartilhar um único termo. Esse é o salto qualitativo em relação à busca do Notion.

A segunda decisão de design importante: o bot sempre cita a fonte. Cada resposta termina com um link para a página exata do Notion de onde saiu a informação. Isso transforma o bot de oráculo opaco em índice verificável, e é o que faz o time confiar nele.

O passo a passo, sem omitir nada

1. A sincronização noturna. Um Schedule Trigger executa a ingestão às 02:00, quando ninguém está perguntando e o time já terminou de editar a documentação. Um nó do Notion recupera todas as páginas da database da Knowledge Base, e um segundo nó do Notion baixa os blocos de conteúdo de cada página, incluindo os aninhados. Pré-requisito que custa uma tarde a quem não sabe: a integração do Notion não enxerga nenhuma página por padrão; é preciso compartilhar a database com ela explicitamente no menu de conexões.

2. A preparação dos documentos. Um nó Code agrupa os blocos por página e monta um documento para cada uma, anexando metadados: título, URL do Notion e data da última edição. Esses metadados são a peça mais importante do sistema, porque são o que depois permite citar a fonte exata. Um pipeline RAG sem metadados de origem produz respostas impossíveis de auditar.

3. Fragmentação e vetorização. Um text splitter recursivo divide cada documento em fragmentos de 1.000 caracteres com 200 de sobreposição. Testamos 500 e o modelo perdia contexto em manuais longos; com 2.000, as respostas arrastavam conteúdo irrelevante. Os fragmentos são vetorizados com o text-embedding-3-small da OpenAI (dimensão 1536, custo marginal) e inseridos em um namespace dedicado do índice do Pinecone. Esvaziamos o namespace a cada sincronização: preferimos reconstruir o índice toda noite a arrastar fragmentos de documentos já apagados. Sincronização incremental é uma otimização que só compensa em grandes volumes.

4. O gatilho do bot. Um Slack Trigger escuta as mensagens de um único canal designado, por exemplo #ajuda-kb. Restringir a um canal é decisão deliberada: um bot que opina em todas as conversas da empresa é um bot que acaba silenciado.

5. O nó mais importante do workflow. Um IF descarta qualquer mensagem que tenha bot_id ou subtype. Sem esse filtro, o bot lê a própria resposta como se fosse uma pergunta nova e entra em loop infinito de autorrespostas. É o erro clássico dessa arquitetura e o primeiro a prevenir. Relacionado: a credencial do Slack deve usar o token de bot (xoxb), não o de usuário (xoxp); com o token de usuário as respostas saem publicadas em seu nome e podem não carregar bot_id, enfraquecendo justamente esse filtro.

6. O agente e sua ferramenta. Um AI Agent recebe a pergunta, rodando GPT-4o com temperatura 0.2. O banco vetorial é conectado como ferramenta em modo retrieve-as-tool com topK 5: com 3 fragmentos faltava informação, com 10 o contexto enchia de ruído. Detalhe que não gera erro mas quebra tudo em silêncio: o modelo de embeddings da consulta precisa ser exatamente o mesmo da ingestão. Se forem diferentes, a busca retorna resultados ruins sem nenhum aviso.

7. O prompt. Transparência completa: este é o system prompt que usamos no agente, exatamente como está em produção.

Você é o assistente da Knowledge Base interna da empresa. Sua única
fonte de verdade é a ferramenta `knowledge_base`, que busca na
documentação interna vetorizada (Notion: manuais de onboarding,
processos, políticas, guias).

Regras:
1. SEMPRE use a ferramenta `knowledge_base` antes de responder. Nunca
   responda de memória.
2. Responda no mesmo idioma da pergunta, de forma clara e concisa.
3. CITE SEMPRE a fonte exata: cada resultado da ferramenta inclui os
   metadados `source_title` e `source_url`. Termine sua resposta com
   uma seção `Fontes:` listando cada documento usado como link do
   Slack no formato <URL|Título>.
4. Se a informação não estiver na base de conhecimento, diga
   honestamente: "Não encontrei isso na documentação interna" e sugira
   a quem perguntar. NÃO invente respostas.
5. Formate para o Slack: use *negrito*, listas com marcadores e blocos
   de código quando aplicável. Não use headers de Markdown (#).
6. Se a pergunta for ambígua, responda da melhor forma possível com o
   que foi encontrado e indique que detalhe ajudaria a refinar a busca.

A regra 4 é o que separa um assistente útil de um gerador de problemas. Um bot interno que inventa uma política de despesas é pior do que não ter bot. Proibir respostas de memória e obrigar a admitir ignorância são as duas instruções menos negociáveis do prompt.

8. A resposta. O agente publica na thread da mensagem original, nunca no canal principal. O canal permanece legível e cada pergunta fica com sua resposta e suas fontes em um contexto autocontido.

O que mais pode ser conectado

A mesma arquitetura aceita fontes adicionais sem tocar no ramo do bot. Para o Google Drive, duplica-se o ramo de ingestão com o nó do Drive e um extrator de texto apontando para o mesmo índice vetorial. Manuais de onboarding em PDF, atas de reunião, documentação técnica: tudo o que puder virar texto com uma URL de origem pode entrar na base de conhecimento. O agente não distingue de onde veio cada fragmento; só enxerga texto e metadados.

Também funciona na direção oposta: o mesmo padrão de agente com busca vetorial serve para suporte a clientes sobre documentação de produto, para o time comercial consultar especificações técnicas, ou como camada de consulta sobre o ERP se a documentação de processos for vetorizada.

Benefícios que dá para medir

Não vamos prometer porcentagens inventadas. O que você pode medir na sua própria organização, antes e depois:

  • Volume de perguntas repetitivas que chegam a People, TI e Operações por mensagem direta, e quantas o canal do bot absorve.
  • Tempo até a primeira resposta: de minutos ou horas dependendo da disponibilidade de alguém, para segundos.
  • Rastreabilidade: cada resposta linka o documento vigente, eliminando a deriva entre "o que se responde de memória" e "o que a política atual diz".
  • Detecção de lacunas: as perguntas que o bot não consegue responder são uma lista priorizada da documentação que falta escrever. É o efeito colateral mais valioso do sistema.
  • Escalabilidade do onboarding: cada pessoa nova tem um canal onde perguntar sem a fricção de interromper ninguém.

Riscos e considerações antes de colocar em produção

Segurança e escopo do índice. Tudo o que for vetorizado fica acessível a qualquer pessoa com acesso ao canal. Não indexe documentação com informação salarial, dados pessoais ou material restrito, ou segmente por namespaces com canais separados por nível de acesso. Revise também qual provedor processa os textos: os fragmentos trafegam para a API do modelo de embeddings e do LLM.

Qualidade dos dados. O bot é tão bom quanto a documentação que indexa. Páginas desatualizadas produzem respostas desatualizadas com total segurança no tom. A reconstrução completa noturna mitiga o problema, mas não substitui a revisão periódica do conteúdo.

Supervisão humana. Nas primeiras semanas, convém que alguém do time revise as respostas no canal. O prompt reduz alucinações, não as elimina: é um sistema probabilístico e deve ser tratado como tal.

Manutenção e dependências. O sistema depende de quatro serviços externos: Notion, Slack, OpenAI e o banco vetorial. Qualquer mudança de API ou de esquema no Notion (algo tão simples quanto renomear a propriedade do título) pode degradar a ingestão. Orce manutenção, não apenas construção.

Custo operacional. Com uma KB de tamanho típico, o custo dominante é o LLM das respostas, não os embeddings. Vale monitorar o consumo por pergunta antes de abrir o canal para toda a empresa.

Agora é seu

O JSON para download contém o workflow completo: os dois ramos, o filtro anti-loop, o prompt e as anotações de configuração em cada nó. Se você tem um n8n rodando e uma tarde livre, não precisa de nós.

Se preferir que funcione de primeira, adaptado às suas fontes reais, com a segmentação de permissões bem resolvida e sem descobrir os erros silenciosos pelo caminho, é exatamente isso que fazemos na DigitalCube.ai: automação com IA sobre os sistemas que você já usa. Escreva para a gente e montamos juntos.


Etiquetas:
#n8n
#RAG
#Notion
#Slack

Artigos relacionados

Você também pode se interessar...

Carregando artigos relacionados...