Cerebras 内部知识库的实战构建 混合检索如何驯服企业信息洪流

在 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 才会被保留包含全库稀有 tokenIDF ≥ 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_codewho_knows识别领域专家recent_prs 等多个 retriever 的结果先用Reciprocal Rank Fusion (RRF)融合再交给一个小重排序模型打 0-10 分保留 top 10。RRF 的平滑常数让“多个列表都靠前”的文档胜过“只在一个列表里排第一”的文档。最终结果还会把上下文补回来——匹配到 wiki 某段时同时拉前后两段避免 chunking 切断前提条件和注意事项。MCP 与 Web UI 的双轨设计他们把检索原语暴露为 MCPModel Context Protocol工具search_slack、search_code、who_knows 等都保持简单、结构化、尽量不依赖 LLM。Claude Code 这类 Agent 可以自己决定调用顺序和组合结果检索层不把编排逻辑硬编码进去。Web UI 则走完整 pipelinePlanner → Executor → Synthesis对用户呈现为“直接问问题就行”。项目 scoping让默认搜索就高相关随着语料增长“搜遍一切”很快失效。编译器团队不想看到运维 runbook反之亦然。他们引入Project概念把相关 Slack 频道、代码仓库、文档空间打包成一个轻量 bundle。同一个数据源可以被多个 project 引用。新员工 onboarding 时选择或创建默认 project后续查询自动限定在高信号范围内。不同检索信号的权衡对比检索技术核心优势主要局限典型适用场景Cerebras 融合方式Full-text (GIN)精确匹配错误字符串、flag 名无法处理同义表述直接复制报错日志基础必备信号Vector Embedding捕捉 paraphrase 和语义意图短消息偏好、忽略稀有 token问题与答案用不同词汇蒸馏后使用IDF 加权突出稀有高价值信号对常见词惩罚过重obscure 配置 flagBurst 过滤阈值Age Decay优先新鲜、未过时的信息可能错过经典但仍有效的方案基础设施快速迭代场景最终排序加权RRF 小模型重排序多源共识 单一强信号增加少量计算延迟复杂跨源问题最终 top 10 筛选这套混合方案的本质是把多个不完美的检索器变成一个鲁棒的“证据包”。为什么这套系统能长期有效信息不会因为你想统一它而移动它只会待在最舒服的地方。Cerebras 的做法是承认这个事实然后在不改变开发者工作流的前提下建立了一层能同时理解“精确词汇”“语义意图”“信号稀有度”和“时效性”的智能索引。当 AI Agent 开始大规模参与内部流程时这种“原生多源、混合检索、可被 Agent 直接调用”的知识层会成为比任何单一平台更重要的基础设施。如果你正在设计类似系统你会如何在 full-text 和 semantic 之间设置初始权重或者在你的团队里信息检索最大的瓶颈目前是 Slack 线程太长还是代码搜索不够语义化欢迎在评论区分享你的真实场景。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。