Cómo Cerebras creó su base de conocimiento interna

• Construyeron Cerebras Knowledge, que recopila directamente desde Slack/repositorios de código/documentos/bases de datos internas en sus ubicaciones existentes, y a 3 meses del lanzamiento procesa más de 15,000 preguntas al día de empleados/automatizaciones/agentes
• En lugar de mover todos los datos a una sola herramienta, los conectaron a una tabla de embeddings en Postgres con un esquema común, y separaron las capas de ingesta/consulta/autenticación·permisos·auditoría·analítica para facilitar la incorporación de nuevas fuentes de datos
• Para Slack, los embeddings del texto original no bastaban, así que combinan búsqueda de texto completo/búsqueda por embeddings/frecuencia inversa de documentos/decaimiento temporal, y además embeben por separado resúmenes de hilos y grupos de intervenciones individuales importantes
• En cada consulta, un LLM primero planifica qué herramientas de búsqueda usará, recopila resultados en paralelo y luego los integra con RRF y un modelo de reranking; en MCP exponen directamente las mismas funciones de búsqueda como herramientas primitivas pequeñas y estables
• En vez de buscar siempre en toda la organización, definen por defecto alcances de búsqueda por proyecto que agrupan canales de Slack/repositorios/espacios de documentos, para ofrecer resultados más relevantes por equipo

---

Recopilación directa desde donde se genera la información

• En los equipos de operaciones de centros de datos/diseño de chips/hardware/entrenamiento/inferencia/plataforma cloud de Cerebras, con cientos de personas sumándose cada año, se repetían preguntas como “¿Dónde está X?”, “¿Quién es experto en Y?” o “¿Qué es Z?”
• Concluyeron que registrar toda la información en una única plataforma no funciona bien en el trabajo real
  • La información se genera en las herramientas adecuadas para cada tarea, como propuestas de edición en documentos, hilos de Slack, referencias de código en GitHub y metadatos de estado en Jira
  • Cada plataforma está optimizada para su dominio mediante años de desarrollo de producto y análisis, así que decidieron no obligar a cambiar la forma de uso
• En la etapa de ingesta se conectan directamente a cada plataforma para minimizar cambios en los hábitos de trabajo existentes

Arquitectura centrada en una tabla común de embeddings

• La base de conocimiento se compone de tres capas
  • Una plataforma que recopila y almacena datos internos
  • Una plataforma que consulta los datos almacenados
  • Una capa que aplica autenticación/autorización/auditoría/analítica
• En el centro hay una única tabla de Postgres que almacena embeddings/resúmenes del texto original/metadatos de múltiples fuentes
• Hilos de Slack, repositorios de código, sistemas de documentos, netlists y bases de datos personalizadas usan la misma interfaz de filas de embeddings
• Cada fuente de datos especifica la definición de los datos, el método de conexión y el ciclo de ingesta; en cuanto se registra en la tabla común, queda disponible para búsqueda desde la misma interfaz de consulta
• Mantuvieron intencionalmente simple la interfaz de datos para que los desarrolladores de Cerebras puedan crear conectores separados

Búsqueda híbrida necesaria para Slack

• Slack era la fuente de datos más importante donde ocurrían las discusiones de ingeniería más recientes
• La búsqueda vectorial aplicando embeddings simples al texto original no alcanzaba para encontrar toda la información relevante
  • Mensajes cortos como “sí, bien” y explicaciones detalladas sobre kernels se almacenaban con la misma unidad de mensaje
  • Los mensajes cortos a menudo superaban a mensajes más largos y detallados en similitud coseno
  • El significado de cada mensaje dependía de la conversación alrededor
• Cada hilo de Slack se busca simultáneamente de cuatro maneras
  • La búsqueda de texto completo encuentra tokens exactos que se diluyen en los embeddings, como cadenas de error/nombres de flags/nombres de hosts
  • La búsqueda por embeddings conecta preguntas y respuestas expresadas con vocabulario distinto, como “la restauración se queda trabada después del manifest” y “el checkpoint se detiene en el mount NFS”
  • La frecuencia inversa de documentos (IDF) sube el ranking de mensajes cortos que contienen flags de configuración raros y baja la puntuación de frases reactivas comunes
  • El decaimiento temporal prioriza hilos recientes sobre hilos antiguos que podrían describir infraestructura obsoleta, cuando las respuestas tienen la misma relevancia
• No confían en una sola puntuación; combinan en tiempo de consulta las listas de ranking producidas por cada buscador

Ingesta en tiempo real basada en Socket Mode

• Instalan un bot de Slack en el workspace y reciben todos los eventos de mensajes mediante una conexión WebSocket persistente de Socket Mode
• Actualizan en tiempo real sin repetir llamadas a la Web API y reducen el consumo de límites de velocidad de solicitudes
• Cuando llega un evento, responden de inmediato, eliminan duplicados con un ID de evento estable y lo marcan para que lo procese el consumidor de ingesta
• No almacenan un mensaje nuevo de forma independiente, sino que vuelven a obtener todo el hilo al que pertenece
  • El mensaje padre y todas las respuestas se almacenan como una sola fila
  • Cuando se agrega una respuesta a un hilo existente, se actualizan el padre/las respuestas hermanas/la lista de participantes/la hora de última actividad
• Tienen fuentes de datos separadas por canal de Slack, lo que permite configurar ciclos de ingesta más cortos para canales que cambian con frecuencia, como los de respuesta a incidentes

Destilación y estructuración de hilos

• El texto original de Slack queda disponible para búsqueda por palabras clave inmediatamente después de guardarse mediante un índice GIN de texto completo en Postgres
• Para la búsqueda vectorial, un LLM extrae de todo el hilo los siguientes elementos
  • Una pregunta de una línea que un ingeniero realmente podría buscar
  • Un resumen corto
  • Una solución
  • Sistemas relacionados y referencias de código
• Los elementos extraídos se embeben y se almacenan en la tabla común; la conversación original en sí no se embebe directamente
• En los experimentos, la precisión aumentó mucho al normalizar los hilos en un formato consistente, y los metadatos adicionales también ofrecieron señales más útiles para la búsqueda semántica

Bursting para preservar mensajes individuales en hilos largos

• Con solo resúmenes a nivel de hilo seguía el problema de que se omitían mensajes importantes dentro de conversaciones largas
• Combinan mensajes consecutivos del mismo autor en grupos de intervenciones consecutivas (burst), anteponen el tema del hilo como contexto y los embeben por separado
• Las respuestas de conversaciones secundarias no incluidas en el resumen del hilo también pueden buscarse de forma independiente
• Calculan señales ponderadas para que intervenciones de baja señal no entren en la base de datos, y solo almacenan los grupos que superan un umbral
  • Contienen tokens raros con IDF de 4.0 o más en todo el corpus
  • La longitud combinada de las intervenciones es de al menos 200 caracteres
  • Uno o más mensajes tienen emojis de reacción, lo que aporta peso social
• Los grupos que cumplen las condiciones se almacenan en la tabla común de embeddings junto con el registro a nivel de hilo

Embeddings incrementales para repositorios de código grandes

• Con la adopción de herramientas de línea de comandos como Claude Code, inicialmente pensaron que grep podía ser suficiente para el código, pero después de revisar resultados de búsqueda semántica en codebases grandes de actores de la industria y Cursor, incorporaron embeddings de código
• Algunos repositorios internos superan los 40 GB, por lo que volver a embeber todo continuamente era un gran desafío de costos
• Tras varios experimentos eligieron CocoIndex, un framework open source de embeddings de documentos especializado en vectorizar codebases
• Dividen el código aplicando límites de expresiones regulares por lenguaje, desde unidades grandes hacia unidades pequeñas
  • Primero usan límites de alto nivel como clases
  • Si el chunk es demasiado grande, bajan a métodos y límites de bloques más pequeños
  • En un solo archivo pueden generarse múltiples embeddings de distintas granularidades, como nivel de archivo/nivel de función
• CocoIndex mantiene metadatos de sincronización en Postgres, de modo que en cada commit solo vuelve a embeber y exportar los chunks de código modificados
• Después de que creciera el número de repositorios, pasaron el onboarding a un archivo de configuración que los equipos pueden enviar directamente y soportan listas de permitidos/bloqueados por ruta de archivo

Conexión de fuentes de datos personalizadas

• Algunos equipos quieren usar la misma interfaz de búsqueda sin mover información de sus bases de datos existentes a Slack o a sistemas de documentos
• Tratan las fuentes personalizadas como scripts plugin
  • El equipo envía mediante pull request un pequeño módulo de Python que lee el sistema existente y exporta filas con la forma de la tabla común de embeddings
  • También agrega la configuración de fuente de datos correspondiente
• Siempre que se escriba en la base de datos compartida con el esquema común, se busca junto con Slack/código/documentos, y el resto del sistema no requiere tratamiento especial

Planificación de consultas y ejecución paralela de herramientas

• Para cada pregunta, un LLM ejecuta primero una breve etapa de planificación para decidir qué herramientas y fuentes de datos usar
• Las herramientas principales son las siguientes
  • subsystem_index: resúmenes por archivo generados por un LLM
  • search: búsqueda vectorial que integra índices de Slack/wiki/código/otros y fusiona·reordena internamente
  • search_slack: búsqueda directa en Slack
  • search_code: ripgrep sobre repositorios fuente
  • recent_prs: pull requests recientes relacionados con la pregunta
  • who_knows: búsqueda de personas que realmente demostraron experiencia en un tema específico
• El planificador usa una lista de proyectos/fuentes de datos por proyecto/descripciones comprimidas de qué tipo de preguntas responde bien cada fuente
• El ejecutor llama en paralelo a las herramientas seleccionadas, normaliza los resultados en un formato común de evidencia y los pasa al LLM de síntesis final

RRF y reranking

• Como pueden aparecer arriba documentos que comparten vocabulario con la consulta pero en realidad responden otra pregunta, tienen una etapa separada de reranking
• Combinan las listas de ranking de distintos buscadores mediante fusión recíproca de rankings (RRF)
  • Por cada lista donde aparece un documento, suman weight / (60 + rank)
  • El peso predeterminado es 1.0 y la constante de suavizado es 60
  • Un documento que aparece de manera uniforme en posiciones altas en varios buscadores puede superar a uno que quedó primero en un solo buscador
• Unen chunks duplicados a nivel de fuente original y limitan la cantidad de resultados por archivo para crear 20 candidatos principales diversos
• Un modelo pequeño de reranking asigna de 0 a 10 puntos a cada documento según la pregunta original y conserva los 10 mejores
• Al resultado final le vuelven a agregar contexto cercano
  • Si coincide una sección de wiki, traen también las dos secciones adyacentes para que títulos/precondiciones/advertencias no desaparezcan por el chunking
• Los resultados de búsqueda se devuelven como un paquete de evidencias que pasó por combinación de varios buscadores/deduplicación a nivel de fuente original/reranking basado en la pregunta/expansión de contexto cercano

Reparto de roles entre MCP y la UI web

• En MCP, en lugar de un endpoint único de “responder una pregunta”, exponen funciones básicas de búsqueda como search_slack, search_code, search y who_knows como herramientas separadas
• Eliminan en lo posible la dependencia de LLMs para que las herramientas puedan llamarse rápido y barato
  • Mantienen entradas y salidas acotadas, estructuradas y estables
  • Aplican reglas ligeras de puntuación a pipelines únicos como búsqueda vectorial/búsqueda léxica/ripgrep y devuelven filas de evidencia sin procesar
• Agentes compatibles con MCP, incluido Claude Code, se vuelven el motor de orquestación que decide qué herramientas llamar, en qué orden y cómo combinar los resultados
• En la UI web conectan las mismas herramientas en un pipeline completo de consultas
  • El planificador examina la pregunta y el proyecto activo para elegir las herramientas de búsqueda que va a llamar
  • El ejecutor procesa las llamadas en paralelo y las convierte a un esquema común de evidencia con pistas de puntuación/recencia/fuente
  • El sintetizador genera una respuesta a partir de la pregunta y el paquete de evidencias, incluyendo citas/advertencias/integración entre fuentes
• El usuario simplemente pregunta y recibe una respuesta, pero internamente se ejecuta el flujo planificador → ejecutor → sintetizador

Alcance de búsqueda por proyecto

• A medida que creció el corpus, la relevancia de buscar siempre en toda la organización cayó drásticamente
  • El equipo de compiladores no quería que aparecieran procedimientos de operación de infraestructura en sus resultados, y lo contrario también ocurría
• Introdujeron proyectos como espacio de trabajo predeterminado donde se ejecutan las consultas
  • Agrupan canales de Slack/repositorios de código/bases de datos internas/espacios de documentos específicos por equipo o tarea
  • Un canal compartido de incidentes o un repositorio central de plataforma puede referenciarse desde varios proyectos sin replicar datos
• Durante el onboarding, permiten elegir o crear proyectos predeterminados adecuados al trabajo, como infraestructura de entrenamiento de ML/Compiler/Data Center Operations
• Guardan el proyecto predeterminado en el perfil de usuario y limitan automáticamente el alcance de todas las consultas, para que incluso ingenieros nuevos puedan empezar a buscar sin conocer primero los canales y repositorios relevantes

Una base de conocimiento que mantiene las herramientas existentes

• El principio operativo de la base de conocimiento es recopilar la información desde donde ya se genera, sin moverla a un sistema rígido único
• Al combinar varios métodos de búsqueda, encuentran evidencia rápidamente y a la vez acomodan la diversidad de los datos empresariales reales, con una estructura que mantiene su utilidad aunque la organización crezca