Cerebras

深夜三点，NFS 报错单还在滚 凌晨 3 点 17 分，#incidents-wafer-fab 频道里的红色告警还在刷。某座晶圆厂的 NFS 挂载点突然吐出 stale file handle，编译器团队的工程师盯着屏幕，手指悬在键盘上——要不要把这串报错贴到搜索框？要不要先在 Slack 里翻半小时历史？要不要直接 @ 某个大神？ 三个月前，这三个选项都是「赌运气」。现在，他在 Cerebras Knowledge 里敲下一行模糊查询：NFS stale handle wafer fab mount。两秒后，答案落地：一条 14 天前的 Slack 线程（已蒸馏为结构化问答）、一篇 Confluence runbook（自动展开相邻章节）、三个相关 PR（按合并时间倒序）、以及一行 who_knows 路由——「找 @marc，他是存储基建 owner」。 这不是演示，也不是 PPT 里的架构图。这是 Cerebras 内部上线三个月、日均 1.5 万次查询、覆盖芯片设计、编译器、数据中心运维、训练/推理框架、云服务全栈语料的 RAG 平台 Cerebras Knowledge 的日常。它没有把所有数据搬进一个向量库，而是选择了更难、也更务实的路：联邦而非迁移，数据留在原地，只在检索层做「窄腰带」融合。 一、 设计哲学：为什么赌「联邦」而不搞「大迁移」？ 大多数团队做内部知识库的第一反应是：把 Confluence、Slack、GitHub、Jira、Google Docs 全部倒进一个向量数据库，建统一索引，再套一层 RAG。听起来顺理成章，做起来却是噩梦——权限同步滞后、数据新鲜度失控、上游 Schema 变更连锁崩溃、摄入管道一堵塞全站不可用。 Cerebras 赌的是另一条路：federate（联邦）≠ migrate（迁移），meet data where it lives（在数据原地与它会面）。 具体落地为三层分离： 层 职责 关键决策 Collection（采集层） 每个源系统一个 Connector，只负责「拉增量、推标准行」 Connector 只写同一张 Postgres embeddings 表，Schema 固定：vector(3072) + metadata(jsonb) + source_id + acl Querying（检索层） 六大工具并行、RRF 融合、Cross-encoder 重排、上下文扩展、带引文综合 不关心数据从哪来，只认「证据行」统一契约 Auth & Audit（鉴权审计层） 源码级 ACL、项目范围过滤、查询审计日志、合成必带引文、冲突证据生成 caveat 横切所有层，查询前过滤、查询后留痕 这张「唯一的 embeddings 表」就是全平台的 窄腰带。Connector 可以是 Slack Socket Mode 推流、Confluence Webhook、GitHub Webhook、CocoIndex 增量 re-embed、甚至是某团队自建 PostgreSQL 的 SELECT ... 小脚本——只要吐出同结构的行，立刻被 search、planner、who_knows 全系工具感知，自动继承平台鉴权审计。不迁移数据，尊重作者在 Slack/Docs/Git 的原生写作习惯，才是让 15k 日查询跑稳的前提。 ...