企业数据散落在Slack、GitHub与Jira之间时，知识库该如何真正可用？

在一家每年新增数百名工程师的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才会被写入向量表包含跨语料的罕见tokenIDF ≥ 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相关最近PRsubsystem_index文件级LLM摘要规划器输出工具列表后并行执行归一化成统一证据格式再用RRF 小模型重排序最后由合成LLM生成带引用和 caveats 的答案。为了让不同团队的搜索默认就相关他们引入了**项目Project**概念。每个项目是一组数据源的轻量绑定特定Slack频道 代码仓库 文档空间。新员工入职时选择默认项目后续所有查询自动带上作用域编译器团队不会被数据中心runbook干扰反之亦然。MCP为Agent而生的检索原语除了Web UI他们还把检索能力拆成MCPModel Context Protocol工具直接暴露给Claude Code等兼容Agent。每个工具对应一个底层原语search_slack、search_code、who_knows等输入输出窄而稳定Agent自己决定调用顺序和如何组装证据。这让知识库从“给人用的问答系统”自然进化成“给Agent用的上下文工程基础设施”。单平台集中 vs 就地提取的真实权衡维度单平台集中式方案就地提取 混合检索方案实际生产影响员工行为变更成本高需迁移习惯极低几乎零感知采用率决定生死数据新鲜度依赖人工同步滞后严重实时/近实时从源头拉取工程讨论时效性极高检索精度与召回初期可能高后期噪声大多技术互补 RRF 重排序长期更稳避免“看起来相关其实无关”长期维护负担平台本身成为新瓶颈各源独立演进知识库只负责连接团队能持续自助接入对Agent的友好度通常是黑箱端点暴露细粒度原语MCPAgent可精确编排未来Agent工作流的基础领域噪声控制全局搜索极易串领域项目作用域 默认过滤不同团队搜索体验差异巨大系统判断这套 方案不是短期补丁而是随组织成长而自然演进的架构当公司还在几十人规模时Slack搜索 人工问人就够了。一旦跨团队协作成为常态信息自然分布在最 ergonomic 的工具里任何试图“收编一切”的努力都会遇到阻力。Cerebras的实践证明知识库的核心任务不是搬运信息而是用最小的摩擦把已有信息连接起来并为未来的Agent提供可组合的检索原语。这背后的逻辑其实很简单——生产力工具的演进方向永远是让人在最舒服的地方继续工作同时让机器去承担“找到并合成”的重活。在你所在的团队或公司里知识最常散落在哪几个工具之间如果你要试点类似系统会优先从哪个高频场景比如某个incident channel或核心代码仓库开始构建混合检索 pipeline欢迎在评论区分享你的真实卡点我们一起讨论边界条件。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。