在 Cerebras 这家快速扩张的 AI 芯片公司，每天都有新同事加入。工程师们在 Slack、GitHub、Jira 等不同平台上反复遇到同样的问题：“这个 flag 在哪定义的？”“谁是这个 kernel 的专家？”“这个部署流程最新状态是什么？”
沟通渠道被重复提问堵塞，信息却始终散落在最适合它的地方——讨论线程、代码提交、状态元数据。强行把所有东西搬到一个“单一真相源”平台听起来很美，实际执行却总是失败，因为信息产生的地方永远比你规划的更方便、更专业。
Cerebras 团队没有对抗这个现实，而是构建了一套知识库系统，让数据留在原地，同时提供统一的、高精度的查询能力。上线三个月后，这套系统每天被人类、自动化流程和 AI Agent 提问超过 1.5 万次，成为公司采用率最高的内部工具之一。
这套系统的核心不是“把数据搬走”，而是最小侵入地采集 + 多信号融合检索。信息像水一样，总是流向阻力最小的容器；检索系统要做的是在不改变水流方向的前提下，建立一套能同时听懂“精确词汇”“语义意图”“信号强度”和“时效性”的智能索引。
Slack 线程为什么需要蒸馏 + bursting 两层处理
Slack 是公司最活跃的信息源，但直接对原始消息做 embedding 效果很差。消息长度差异极大，短消息（如“sounds good”）在余弦相似度中经常碾压长消息；一段关键的 kernel 解释可能只出现在长线程的某个 tangent 里；同一个问题的表述在不同人嘴里完全不同。
他们采取了混合策略，每种技术弥补其他技术的短板：
- 全文检索（Postgres GIN 索引）：精确匹配错误字符串、flag 名、主机名。当工程师直接粘贴报错日志时，词法匹配几乎总是最强证据。
- 蒸馏后的向量嵌入：用 LLM 把整个线程提炼成结构化数据——工程师会实际搜索的单行问题、简短摘要、解决方案、提到的系统和代码引用。再对这些结构化内容做 embedding，而不是原始 transcript。实验显示，规范化后准确率显著提升。
- Bursting（爆发片段）：把同一作者连续的消息作为一个 burst，用线程主题作为上下文前缀单独 embedding。只有满足以下条件的 burst 才会被保留：包含全库稀有 token（IDF ≥ 4.0）、总长度 ≥ 200 字符、至少有一个 reaction 提供社交信号。
这样既保留了线程整体语义，又不会让重要但孤立的 tangent 消息被淹没。
实时采集通过 Slack Bot 的 Socket Mode 实现。新消息到达后立即确认、去重，然后重新拉取整个线程（包括 parent 和所有回复），以一条记录的形式写入。这样存储的内容、参与者列表和最后活跃时间始终是完整的对话快照。
代码库与自定义数据源的统一处理
代码仓库最初被认为“grep 就够了”，但实际使用中发现，语义搜索在大型代码库中能找到 grep 漏掉的跨文件关联。他们采用 CocoIndex 框架，按语言特定规则做层级切分（先尝试类边界，再退化到方法、块），生成文件级和函数级多粒度 embedding。
关键是增量同步：CocoIndex 只在 commit 时重新处理变更的 chunk，同步状态和向量存储在同一 Postgres 库里，效率极高。团队甚至把仓库 onboarding 做成配置文件，支持路径级 allowlist/denylist。
对于已经有自己数据库的团队，不需要迁移数据。只要写一个小的 Python 插件脚本，按统一 schema 把数据写入 embeddings 表，就自动成为可查询的一部分。整个栈对新数据源零特殊处理。
查询侧的规划、重排序与上下文补全
单纯把所有 retriever 结果混在一起还不够。Cerebras 在查询时先跑一个轻量规划 LLM，根据问题和当前 project 决定调用哪些工具：
- subsystem_index（文件级 LLM 摘要）
- 统一向量搜索
- search_slack / search_code
- who_knows（识别领域专家）
- recent_prs 等
多个 retriever 的结果先用Reciprocal Rank Fusion (RRF)融合，再交给一个小重排序模型打 0-10 分，保留 top 10。RRF 的平滑常数让“多个列表都靠前”的文档胜过“只在一个列表里排第一”的文档。
最终结果还会把上下文补回来——匹配到 wiki 某段时，同时拉前后两段，避免 chunking 切断前提条件和注意事项。
MCP 与 Web UI 的双轨设计
他们把检索原语暴露为 MCP（Model Context Protocol）工具：search_slack、search_code、who_knows 等都保持简单、结构化、尽量不依赖 LLM。Claude Code 这类 Agent 可以自己决定调用顺序和组合结果，检索层不把编排逻辑硬编码进去。
Web UI 则走完整 pipeline（Planner → Executor → Synthesis），对用户呈现为“直接问问题就行”。
项目 scoping：让默认搜索就高相关
随着语料增长，“搜遍一切”很快失效。编译器团队不想看到运维 runbook，反之亦然。他们引入Project概念，把相关 Slack 频道、代码仓库、文档空间打包成一个轻量 bundle。同一个数据源可以被多个 project 引用。
新员工 onboarding 时选择或创建默认 project，后续查询自动限定在高信号范围内。
不同检索信号的权衡对比
| 检索技术 | 核心优势 | 主要局限 | 典型适用场景 | Cerebras 融合方式 |
|---|---|---|---|---|
| Full-text (GIN) | 精确匹配错误字符串、flag 名 | 无法处理同义表述 | 直接复制报错日志 | 基础必备信号 |
| Vector Embedding | 捕捉 paraphrase 和语义意图 | 短消息偏好、忽略稀有 token | 问题与答案用不同词汇 | 蒸馏后使用 |
| IDF 加权 | 突出稀有高价值信号 | 对常见词惩罚过重 | obscure 配置 flag | Burst 过滤阈值 |
| Age Decay | 优先新鲜、未过时的信息 | 可能错过经典但仍有效的方案 | 基础设施快速迭代场景 | 最终排序加权 |
| RRF + 小模型重排序 | 多源共识 > 单一强信号 | 增加少量计算延迟 | 复杂跨源问题 | 最终 top 10 筛选 |
这套混合方案的本质，是把多个不完美的检索器变成一个鲁棒的“证据包”。
为什么这套系统能长期有效
信息不会因为你想统一它而移动，它只会待在最舒服的地方。Cerebras 的做法是承认这个事实，然后在不改变开发者工作流的前提下，建立了一层能同时理解“精确词汇”“语义意图”“信号稀有度”和“时效性”的智能索引。
当 AI Agent 开始大规模参与内部流程时，这种“原生多源、混合检索、可被 Agent 直接调用”的知识层，会成为比任何单一平台更重要的基础设施。
如果你正在设计类似系统，你会如何在 full-text 和 semantic 之间设置初始权重？或者在你的团队里，信息检索最大的瓶颈目前是 Slack 线程太长，还是代码搜索不够语义化？欢迎在评论区分享你的真实场景。
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
