在一家每年新增数百名工程师的AI芯片公司里，Slack频道、GitHub仓库、Jira工单和内部文档每天都在产生海量信息。新员工入职后最常见的动作，就是在多个频道里反复提问：“这个错误码在哪份runbook里？”“NFS挂载相关的checkpoint逻辑谁最熟？”“上周的manifest变更影响了哪些子系统？”

这些问题不是没人知道答案，而是答案散落在最自然的讨论现场，却无法被需要的人快速触达。团队规模一扩大，重复提问就成了日常噪音。

很多人下意识的反应是：我们需要一个“单一真相源”，把所有信息强制搬到一个新平台上统一管理。但真实生产环境里，这种方案几乎总是以高维护成本和低采用率告终。信息产生的地方，往往就是最适合讨论它的地方——强行迁移只会破坏原本流畅的工作流。

Cerebras团队在过去三个月里，把这个认知转化成了一套日均处理超过1.5万次提问的内部知识系统。他们没有要求任何人改变现有行为，而是让系统去“就地提取”数据，再通过混合机制把信号找回来。

为什么纯向量搜索在Slack上会失效

Slack是公司里信息密度最高、更新最快的场域。一次内核调试线程可能有几十条消息，也可能混杂着“sounds good, thanks!”这样的低信号回复。

我起初以为直接对原始消息做embedding就够了，但实际跑通后发现问题远比想象复杂：短消息经常因为长度优势在余弦相似度上胜出，长而精准的解释反而被埋没；同一个问题的问法和答法常常完全不同词汇；六个月前的正确答案可能已经因为基础设施变更而失效。

他们最终采用的不是单一技术，而是四种互补机制同时作用：

• 全文本搜索（GIN索引）：精确匹配错误字符串、flag名称、主机名这类不会被embedding模糊掉的token。
• Embedding搜索：捕捉语义 paraphrase，让“restore hangs after manifest load”和“checkpoint stalls on the NFS mount”能互相找到。
• 逆文档频率（IDF）加权：给稀有token更高的权重，让“obscure config flag”这类关键信息不被大量“sounds good”淹没。
• 年龄衰减：在其他条件相近时，优先返回更新的线程。

没有哪一种打分器被单独信任。系统在查询时把多个检索器的结果用**Reciprocal Rank Fusion (RRF)**融合，再交给一个小模型做最终重排序（0-10分），只保留Top-10，并把相邻上下文补回来，避免chunk切碎后丢失前提条件和注意事项。

Slack线程的精细化处理

为了让重要信息不被线程级摘要淹没，他们引入了bursting机制：把同一作者连续发言视为一个burst，在前面加上线程主题作为上下文后单独embedding。只有同时满足以下条件的burst才会被写入向量表：

• 包含跨语料的罕见token（IDF ≥ 4.0）
• 总长度 ≥ 200字符
• 至少有一条消息获得reaction（社会信号加权）

同时，系统用Socket Mode实时接收Slack事件，收到回复后会完整重拉取整条线程，确保存储的参与者列表和最后活跃时间始终是最新的。蒸馏阶段由LLM把整条线程规范成“一句话问题 + 简短总结 + 解决办法 + 涉及的系统/代码引用”，再分别embedding，而不是直接嵌入原始对话。

这种“线程级 + burst级”双层结构，大幅提升了细粒度信息的可发现性。

代码仓库与自定义数据源的统一处理

最初有人质疑：现在有Claude Code和各种CLI工具，代码还需要embedding吗？“grep不就够了？”

但在大规模代码库（单个仓库超40GB）里，语义层面的问题远超词法匹配。他们最终采用开源的CocoIndex框架，按语言特性从粗到细切分（类 → 方法 → 代码块），生成多层级embedding。每次commit只增量重算变更chunk，状态和向量存在同一Postgres库里，极大降低了维护成本。

对已经有自己数据库的团队，他们提供极简插件机制：团队提交一个Python模块，按统一schema把数据写进共享的embeddings表即可。后续的规划、检索、重排序全部复用同一套逻辑，无需任何特殊处理。

查询侧的规划与重排序管线

每一次用户提问，系统先跑一个轻量规划LLM，判断当前作用域下哪些工具最可能有用：

• search：跨Slack、wiki、代码的统一向量管线
• search_slack / search_code：专项直达
• who_knows：根据历史贡献找领域专家
• recent_prs：相关最近PR
• subsystem_index：文件级LLM摘要

规划器输出工具列表后，并行执行，归一化成统一证据格式，再用RRF + 小模型重排序，最后由合成LLM生成带引用和 caveats 的答案。

为了让不同团队的搜索默认就相关，他们引入了**项目（Project）**概念。每个项目是一组数据源的轻量绑定（特定Slack频道 + 代码仓库 + 文档空间）。新员工入职时选择默认项目，后续所有查询自动带上作用域，编译器团队不会被数据中心runbook干扰，反之亦然。

MCP：为Agent而生的检索原语

除了Web UI，他们还把检索能力拆成MCP（Model Context Protocol）工具，直接暴露给Claude Code等兼容Agent。每个工具对应一个底层原语（search_slack、search_code、who_knows等），输入输出窄而稳定，Agent自己决定调用顺序和如何组装证据。

这让知识库从“给人用的问答系统”自然进化成“给Agent用的上下文工程基础设施”。

单平台集中 vs 就地提取的真实权衡

维度	单平台集中式方案	就地提取 + 混合检索方案	实际生产影响
员工行为变更成本	高（需迁移习惯）	极低（几乎零感知）	采用率决定生死
数据新鲜度	依赖人工同步，滞后严重	实时/近实时从源头拉取	工程讨论时效性极高
检索精度与召回	初期可能高，后期噪声大	多技术互补 + RRF + 重排序，长期更稳	避免“看起来相关其实无关”
长期维护负担	平台本身成为新瓶颈	各源独立演进，知识库只负责连接	团队能持续自助接入
对Agent的友好度	通常是黑箱端点	暴露细粒度原语（MCP），Agent可精确编排	未来Agent工作流的基础
领域噪声控制	全局搜索极易串领域	项目作用域 + 默认过滤	不同团队搜索体验差异巨大

系统判断：这套 方案不是短期补丁，而是随组织成长而自然演进的架构

当公司还在几十人规模时，Slack搜索 + 人工问人就够了。一旦跨团队协作成为常态，信息自然分布在最 ergonomic 的工具里，任何试图“收编一切”的努力都会遇到阻力。

Cerebras的实践证明：知识库的核心任务不是搬运信息，而是用最小的摩擦把已有信息连接起来，并为未来的Agent提供可组合的检索原语。

这背后的逻辑其实很简单——生产力工具的演进方向，永远是让人在最舒服的地方继续工作，同时让机器去承担“找到并合成”的重活。

---

在你所在的团队或公司里，知识最常散落在哪几个工具之间？如果你要试点类似系统，会优先从哪个高频场景（比如某个incident channel或核心代码仓库）开始构建混合检索 pipeline？欢迎在评论区分享你的真实卡点，我们一起讨论边界条件。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。