Como a Cerebras construiu sua base de conhecimento interna

• A Cerebras criou a Cerebras Knowledge, que coleta diretamente de Slack/repositórios de código/documentos/bancos de dados internos em seus locais originais, e em 3 meses após o lançamento já processava mais de 15.000 perguntas por dia de funcionários/automação/agentes
• Em vez de mover todos os dados para uma única ferramenta, ela os conecta a uma tabela de embeddings no Postgres com esquema comum, separando as camadas de ingestão/consulta/autenticação·permissões·auditoria·análises para facilitar a adição de novas fontes de dados
• A busca no Slack não era suficiente apenas com embeddings do texto original, então usa em conjunto busca full-text/busca por embeddings/frequência inversa de documentos/decaimento temporal, além de embutir separadamente resumos de threads e grupos importantes de mensagens individuais
• Para cada consulta, o LLM primeiro planeja quais ferramentas de busca vai usar, depois coleta os resultados em paralelo e os integra com RRF e um modelo de reranking; no MCP, a mesma funcionalidade de busca é exposta diretamente como ferramentas primitivas pequenas e estáveis
• Em vez de sempre buscar em toda a organização, define por padrão um escopo de busca por projeto que agrupa canais do Slack/repositórios/espaços de documentos etc., entregando resultados mais relevantes para cada equipe

---

Coleta direta onde a informação é gerada

• Nas equipes de operações de data center/design de chips/hardware/treinamento/inferência/plataforma de nuvem da Cerebras, com a entrada de centenas de pessoas novas por ano, perguntas como “onde está X”, “quem é especialista em Y” e “o que é Z” se repetiam
• Concluíram que a abordagem de registrar todas as informações em uma plataforma única não funcionava bem no trabalho real
  • Informações como revisão de propostas em documentos, threads no Slack, referências de código no GitHub e metadados de status no Jira são geradas na ferramenta mais adequada para cada tarefa
  • Como cada plataforma foi otimizada para sua área específica ao longo de anos de desenvolvimento de produto e análises, decidiram não forçar uma mudança na forma como as pessoas trabalham
• Na etapa de ingestão, conectaram-se diretamente a cada plataforma para minimizar mudanças no comportamento de trabalho existente

Arquitetura centrada em uma tabela comum de embeddings

• A base de conhecimento é composta por três camadas
  • Plataforma que coleta e armazena dados internos
  • Plataforma que consulta os dados armazenados
  • Camada que aplica autenticação/autorização/auditoria/análises
• No centro há uma única tabela no Postgres que armazena embeddings/resumos do texto original/metadados de várias fontes
• Threads do Slack, repositórios de código, sistemas de documentos, netlists e bancos de dados personalizados usam a mesma interface de linha de embedding
• Cada fonte de dados define os dados, a forma de conexão e a frequência de ingestão, e assim que é registrada na tabela comum, já pode ser consultada pela mesma interface de busca
• A interface de dados foi mantida intencionalmente simples para que desenvolvedores da Cerebras possam criar conectores separados

Busca híbrida necessária para o Slack

• O Slack era a fonte de dados mais importante, onde aconteciam as discussões de engenharia mais recentes
• Só a busca vetorial com embeddings simples sobre o texto original não conseguia localizar todas as informações relevantes
  • Mensagens curtas como “sim, ok” e explicações detalhadas de kernel eram armazenadas na mesma unidade de mensagem
  • Muitas vezes, mensagens curtas ficavam à frente de mensagens mais longas e detalhadas na similaridade de cosseno
  • O significado de uma mensagem individual dependia da conversa ao redor
• Cada thread do Slack é pesquisada simultaneamente de quatro formas
  • A busca full-text encontra tokens exatos como strings de erro/nomes de flags/nomes de host, que ficam diluídos em embeddings
  • A busca por embeddings conecta perguntas e respostas expressas com vocabulários diferentes, como “a restauração para depois do manifest para” e “o checkpoint trava no mount NFS”
  • A frequência inversa de documentos (IDF) eleva o ranking de mensagens curtas com flags de configuração raras e reduz a pontuação de frases reativas comuns
  • O decaimento temporal prioriza threads mais recentes, em vez de threads antigas que podem descrever infraestrutura desatualizada, entre respostas com relevância semelhante
• Em vez de confiar em uma única pontuação, as listas de ranking geradas por cada mecanismo de busca são combinadas no momento da consulta

Ingestão em tempo real baseada em Socket Mode

• Instalaram um bot do Slack no workspace e recebem todos os eventos de mensagens por uma conexão WebSocket persistente do Socket Mode
• Isso permite atualização em tempo real sem repetir chamadas à Web API e reduz o consumo do limite de taxa de requisições
• Quando um evento chega, respondem imediatamente, removem duplicatas com IDs de evento estáveis e o marcam para processamento por um consumidor de ingestão
• Em vez de armazenar a nova mensagem isoladamente, buscam novamente a thread completa à qual ela pertence
  • A mensagem pai e todas as respostas são armazenadas em uma única linha
  • Quando uma resposta é adicionada a uma thread existente, mensagem pai/respostas irmãs/lista de participantes/horário da última atividade são todos atualizados para o estado mais recente
• Cada canal do Slack pode ter uma fonte de dados separada, permitindo configurar ciclos de ingestão mais curtos para canais com mudanças frequentes, como canais de resposta a incidentes

Destilação e estruturação de threads

• O texto bruto do Slack fica disponível para busca por palavras-chave logo após o armazenamento via índice full-text GIN do Postgres
• Para os dados usados na busca vetorial, o LLM extrai da thread inteira os seguintes itens
  • Uma pergunta de uma linha que um engenheiro realmente faria numa busca
  • Um resumo curto
  • A solução
  • Sistemas relacionados e referências de código
• Os itens extraídos são embutidos e armazenados na tabela comum; o diálogo original em si não é embutido diretamente
• Nos experimentos, a precisão aumentou muito quando a thread foi normalizada em um formato consistente, e os metadados adicionais também forneceram sinais mais úteis para a busca semântica

Bursting para preservar mensagens individuais em threads longas

• Só o resumo no nível da thread ainda deixava escapar mensagens importantes em conversas longas
• Mensagens enviadas em sequência pelo mesmo autor são combinadas em um grupo contínuo de enunciados (burst), e o tópico da thread é adicionado no início como contexto para ser embutido separadamente
• Assim, respostas de conversas paralelas que não aparecem no resumo da thread também podem ser encontradas de forma independente
• Para evitar que enunciados com pouco sinal entrem no banco de dados, calculam sinais ponderados e armazenam apenas grupos que passam por um limiar
  • Contêm tokens raros com IDF de 4,0 ou mais em todo o corpus
  • O comprimento do enunciado combinado é de no mínimo 200 caracteres
  • Pelo menos uma mensagem tem emoji de reação, recebendo peso social
• Os grupos que cumprem as condições são armazenados na tabela comum de embeddings junto com os registros no nível da thread

Embeddings incrementais para grandes repositórios de código

• Com a popularização de ferramentas de linha de comando como Claude Code, consideraram que para código o grep poderia bastar, mas após conversar com pessoas do setor e revisar os resultados de busca semântica em grandes codebases do Cursor, adotaram embeddings de código
• Alguns repositórios internos passam de 40 GB, e o custo de reembutir continuamente tudo era um desafio central
• Depois de vários experimentos, escolheram o framework open source de embeddings de documentos CocoIndex, especializado em vetorização de codebases
• O código é dividido aplicando limites por regex específicos da linguagem, do maior nível para o menor
  • Primeiro usam limites superiores, como classes
  • Se o chunk for grande demais, descem para limites de métodos e blocos menores
  • Um único arquivo pode gerar vários embeddings com granularidades diferentes, como nível de arquivo e nível de função
• O CocoIndex mantém metadados de sincronização no Postgres para reembutir e exportar apenas os chunks de código alterados a cada commit
• Conforme o número de repositórios aumentou, o onboarding passou a usar arquivos de configuração que as próprias equipes podem enviar, com suporte a listas de permissão/bloqueio por caminho de arquivo

Conectando fontes de dados personalizadas

• Algumas equipes queriam usar a mesma interface de busca sem mover informações de bancos de dados existentes para o Slack ou para sistemas de documentos
• Fontes personalizadas são tratadas como scripts de plugin
  • A equipe envia, via pull request, um pequeno módulo Python que lê o sistema existente e exporta linhas no formato da tabela comum de embeddings
  • Junto com isso, adiciona também a configuração correspondente da fonte de dados
• Basta gravar no banco de dados compartilhado com o esquema comum para que passe a ser pesquisável junto com Slack/código/documentos, sem tratamento adicional no restante do sistema

Planejamento de consultas e execução paralela de ferramentas

• Para cada pergunta, o LLM primeiro executa uma etapa curta de planejamento para decidir quais ferramentas e fontes de dados usar
• As principais ferramentas são as seguintes
  • subsystem_index: resumos por arquivo gerados por LLM
  • search: busca vetorial que integra índices de Slack/wiki/código/outros e faz mesclagem·reranking internamente
  • search_slack: busca direta no Slack
  • search_code: ripgrep sobre repositórios de código-fonte
  • recent_prs: pull requests recentes relacionados à pergunta
  • who_knows: busca por pessoas que realmente demonstraram expertise em um determinado tema
• O planejador usa descrições compactadas com a lista de projetos/fontes de dados por projeto/e os tipos de perguntas para os quais cada fonte é boa em responder
• O executor chama as ferramentas selecionadas em paralelo, normaliza os resultados em um formato comum de evidência e depois os envia ao LLM final de síntese

RRF e reranking

• Como documentos que só compartilham a consulta e o vocabulário, mas na prática respondem a outra pergunta, podem aparecer no topo, foi criada uma etapa separada de reranking
• As listas de ranking de diferentes mecanismos de busca são combinadas com Reciprocal Rank Fusion (RRF)
  • Para cada lista em que um documento aparece, soma-se weight / (60 + rank)
  • O peso padrão é 1,0, e a constante de suavização é 60
  • Um documento que aparece consistentemente no topo em vários mecanismos pode superar outro que ficou em 1º lugar apenas em um único mecanismo
• Chunks duplicados são reunidos pela unidade original e o número de resultados por arquivo é limitado para formar um conjunto diverso dos 20 principais candidatos
• Um pequeno modelo de reranking atribui de 0 a 10 pontos a cada documento com base na pergunta original e mantém os 10 melhores
• No resultado final, o contexto ao redor é adicionado novamente
  • Se uma seção da wiki corresponde, as duas seções vizinhas também são recuperadas para que título/pré-requisitos/cuidados não se percam por causa da divisão em chunks
• Os resultados de busca são retornados como um pacote de evidências que passou por combinação de vários mecanismos/deduplicação por unidade original/reranking baseado na pergunta/expansão do contexto ao redor

Divisão de papéis entre MCP e a interface web

• No MCP, em vez de um endpoint único de “responder à pergunta”, as funções básicas de busca como search_slack, search_code, search e who_knows são expostas como ferramentas separadas
• Para que as ferramentas possam ser chamadas de forma rápida e barata, a dependência de LLM é removida o máximo possível
  • O escopo de entrada e saída é mantido estreito, estruturado e estável
  • Regras leves de pontuação são aplicadas a pipelines únicos, como busca vetorial/busca lexical/ripgrep, retornando linhas brutas de evidência
• Agentes compatíveis com MCP, incluindo o Claude Code, tornam-se o mecanismo de orquestração que decide quais ferramentas chamar/em que ordem/como combinar os resultados
• Na interface web, as mesmas ferramentas são encadeadas em um pipeline completo de consulta
  • O planejador analisa a pergunta e o projeto ativo para escolher quais ferramentas de busca chamar
  • O executor processa as chamadas em paralelo e as converte para um esquema comum de evidência com pontuação/recência/dicas de origem
  • O sintetizador gera a resposta com a pergunta e o pacote de evidências, incluindo citações/cuidados/integração entre fontes
• O usuário simplesmente faz a pergunta e recebe a resposta, mas internamente roda o fluxo planejador → executor → sintetizador

Escopo de busca por projeto

• À medida que o corpus cresceu, a relevância caiu rapidamente quando a busca sempre abrangia a organização inteira
  • A equipe de compiladores não queria ver procedimentos operacionais de infraestrutura nos resultados, e o contrário também era verdadeiro
• Foi introduzido o projeto como espaço de trabalho padrão em que a consulta é executada
  • Agrupa canais específicos do Slack/repositórios de código/bancos de dados internos/espaços de documentos por equipe ou iniciativa
  • Um canal compartilhado de incidentes ou um repositório central de plataforma pode ser referenciado por vários projetos sem duplicar dados
• No onboarding, a pessoa escolhe ou cria projetos padrão adequados ao trabalho, como infraestrutura de treinamento de ML/Compiler/Data Center Operations
• O projeto padrão é salvo no perfil do usuário e limita automaticamente o escopo de todas as consultas, permitindo que até engenheiros novos comecem a buscar sem antes conhecer todos os canais e repositórios relevantes

Uma base de conhecimento que preserva as ferramentas existentes

• O princípio de funcionamento da base de conhecimento é não mover a informação para um sistema único e rígido, mas coletá-la diretamente onde ela já é gerada
• Ao combinar vários métodos de busca, a estrutura encontra evidências rapidamente, acomoda a diversidade dos dados corporativos reais e mantém a utilidade mesmo com o crescimento da organização