Cerebras内部知识库上线3个月，日均处理15000次提问。
不是靠强迫员工把每句话写进统一平台，而是靠一套“数据在哪我去哪”的混搭检索系统。它用向量搜索、全文匹配、时间衰减和LLM重排，把Slack闲聊、代码仓库、故障报告全塞进同一张Postgres表，让新人不再追着老人问“这个找谁那个在哪”。
本文拆解它怎么绕过“单点真相”陷阱，以及为什么搜索变成一场精心设计的“分赃会议”。
那个“把所有信息放一个地方”的梦，怎么就成了职场最大的笑话
每过三个月，公司里就会冒出一个聪明人，拍着桌子说咱们搞个统一平台吧，所有文档、聊天、代码、故障记录全塞进去，以后找东西再也不用翻十个网页了。这个提议听起来特别对，特别合理，特别像能解决问题。但它每次都死在同一个地方：Slack里讨论到一半的紧急故障，谁有空去平台里再写一遍；代码仓库里的提交记录，自动生成就完了，手动同步根本做不到；Jira里的状态变更，每五分钟一次，人工录入能把团队累到辞职。
真实世界的运作逻辑是，信息在哪产生，人就在哪干活。工程师在Slack里贴报错日志，不是因为他们懒，是因为最快。开发者在GitHub里改代码，顺手写注释，是因为界面顺手。你非要让他们多一个步骤，把东西再贴到别处，那信息直接就断了，断了还不如没有。这就是为什么所有统一平台最终都变成坟场，刚上线时热火朝天，三个月后只剩运维一个人往里发通告。
Cerebras团队踩过这个坑之后，做了一个特别反直觉的决定：不改造人，改造管道。数据不动，检索动。不管你是Slack里的废话文学，还是代码仓库里几十G的史前遗留，系统直接去原地抓，抓完统一处理，统一建索引，统一可查询。用户不需要改变任何习惯，该在哪儿吵还在哪儿吵，系统自己跟在屁股后面捡。这才是知识库该有的姿态——你不是要当所有人的爹，你是要当所有人的保姆。
为什么“语义理解”在Slack里经常被一句话干翻
大多数人以为有了向量搜索，机器就能像人一样读懂意思。但Slack这地方专治各种AI理想主义。你搜“restore hangs after manifest load”，向量搜索会把“checkpoint stalls on the NFS mount”翻出来，因为它知道这俩词差不多意思。这很厉害，对吧？但向量搜索也会把“sounds good, thanks!”排在前面，因为这句话在数学空间里离很多问句都近。你看，它识字，但它不分轻重。
更尴尬的是长度问题。一条详细的技术分析，三百字，跟一句“嗯，我也遇到了”放在一起比，后者因为词少，向量距离反而更近，排名更靠前。这叫什么事儿。你辛辛苦苦写了篇小作文，结果被一个“俺也一样”干翻了。
Cerebras的解法是搞了个检索界的“分赃会议”。全文搜索先上，把报错里那些稀奇古怪的flag名、主机名逮住，这种词只有精确匹配才靠谱，语义理解在这时候就是添乱。然后向量搜索上场，负责抓那些“话不一样但问的是同一件事”的帖子。紧接着IDF来泼冷水：一句话里全是罕见词，那就是干货，加分；全是“好的收到谢谢”，减分。最后再给时间加个权重，半年前的解决方案，哪怕再精确，也输给上周刚更新的答案。
四种算法各自列出一份排名，然后用RRF把它们熔在一起。RRF的规则特别简单：你在越多榜单里出现，而且名次越靠前，最终得分就越高。这不就是民主投票吗？每个检索器都是选民，每个文档都是候选人，最后谁赢取决于共识，而不取决于某一个选民在发疯。这种“不信任任何单一信号”的态度，放在企业内部搜索里就是生存法则。
你以为把代码扔进去就能搜？太天真了
Cerebras一开始也没打算给代码建向量索引。内部争论的时候，有人说“有grep就够了，搞什么花里胡哨的”。确实，命令行一把梭，搜字符串谁不会。但随着仓库膨胀到40G以上，光靠grep就像用鱼竿钓鲸鱼，能钓，但你得钓到明年。
他们后来学乖了，上了CocoIndex这个开源框架。它干的事不是整个文件一锅端，而是按语言的语法边界来切分。先试着按类切，太大了就按方法切，再大就继续往下切。一个文件可能产生好几条向量记录，有的代表整个文件的主旨，有的代表某个函数的细节。这样你搜“模块加载逻辑”时，能命中文件级摘要；搜“某个私有函数”时，又能命中更细的粒度。
但真正让这套东西能跑起来的，是增量更新机制。每次代码提交，系统只重新处理那些变动的文件块，而不是把整个仓库从头到尾重新嵌一遍。因为嵌入状态和存储都在同一张Postgres表里，同步变得异常简单。这就好比打扫房间，你不需要每天把家具全搬出去擦一遍地板，哪里脏了擦哪里就好。
那个最初喊着“grep就够了”的人，后来自己也悄悄用上了语义搜索，因为他的“grep”只能搜到字符串，而向量搜索能搜到“我记得有个地方处理过类似问题但我忘了具体报错是什么了”这种模糊记忆。语言和记忆的本质就是模糊的，你用精确工具去对付模糊问题，从一开始就输了。
MCP和Web UI：同一个工具箱，两种完全不同的打开方式
Cerebras给MCP暴露的不是一个“你问问题我回答”的黑盒子，而是一堆独立的检索工具。search_slack、search_code、who_knows，每个工具只干一件事，输入输出都简单到令人发指。这样做的好处是，Claude Code或者其他任何MCP客户端可以自己当导演，决定先调哪个工具再看结果，自己编排搜索流程。
而在Web UI里，同一个工具箱，系统帮你把导演的活干了。它先跑一个轻量级的Planner，判断你问的东西跟哪个项目有关，然后决定调哪几个工具，同时并发执行，把结果归一化成同一种证据格式，最后喂给一个合成模型，输出带引用的答案。
这两种模式背后是两种完全不同的哲学。MCP默认用户知道自己要什么，所以给你武器，你自己打猎。Web UI默认用户懒得动脑子，所以替你扣扳机，你把肉拿走就行。哪个更高级？没有更高级，只有更合适。Cerebras故意把MCP工具设计得“尽量不带LLM”，因为一旦带了大模型，响应延迟和成本就上去了。对于Agent来说，每次调工具都要多等两秒，体验就是灾难。所以他们在MCP上坚持轻量、稳定、结构化，把重推理留给客户端自己决定。这个取舍，体现了对“延迟”这个东西的尊重，很多团队做产品是不尊重延迟的，什么都想往里塞，最后做成一个又慢又重的怪物。
项目范围：当你全都能搜到的时候，你就什么都搜不到
搜索系统做到后期，都会碰到同一个鬼打墙的问题——数据太多了。编译器团队的人搜“报错”，结果排第一的是数据中心机柜温度告警。运维搜“电压”，结果翻出来的是芯片设计里的功耗模型。全公司共享一个检索池，就像所有人共用一根水管，一开龙头，出来的全是浑水。
Cerebras的解法是“项目”这个概念。每个项目是一堆数据源的组合，包括特定的Slack频道、代码仓库、文档空间。比如编译器项目，绑的是编译器团队的Slack、编译器仓库、以及相关的设计文档。平台项目绑的是平台仓库、故障频道、云服务手册。同一个故障频道可以被多个项目引用，数据不需要复制，只做引用关系。
新人入职选一个默认项目，之后所有的搜索自动限定在这个范围内。不需要先学会“公司有哪些部门哪些频道哪些缩写”才能开始找东西，系统默认就把噪音滤掉了。这跟互联网搜索不一样，互联网是越大越好，因为信息过剩但多样化。企业内部搜索是越精准越好，因为信息过剩但同质化严重。你不需要知道所有事，你只需要知道跟你有关的事。
这种设计背后藏着一个认知：知识的价值不在于“获取全部”，而在于“屏蔽无关”。一个好的搜索系统，不是让你找到更多，而是让你漏掉更少但更对的东西。很多人做产品搞反了，拼命扩充召回，结果精准度塌方，用户反而觉得系统变笨了。
总结：那些被当成“功能”的东西，其实都是妥协
本文谈到是在日均15000次提问背后：Cerebras知识库把Slack闲聊变成可查资产，这样别再让员工追着问“这个找谁”，这是一个内部搜索的混合检索实战手册。
解决的痛点：越全的搜索越没用，Cerebras靠“项目范围”干掉99%的无关噪音。
这套系统没有一个地方是“炫技”的。RRF是为了弥补单点检索的偏见，蒸馏是为了把闲聊变成可查的文档，项目是为了拦截无关噪音，MCP的轻量化是为了让Agent不至于等死。每一个看似巧妙的设计，背后都是一个活生生的失败案例。因为Slack消息太水，所以做了蒸馏；因为向量搜索被短消息干翻，所以加了全文和IDF；因为全公司搜太乱，所以分了项目。整个系统就是一部“被现实毒打后的妥协史”，而它居然还很好用。
这给所有想抄作业的人一个提醒：别去复制别人的架构图，去复制别人挨过的打。你只有知道你会在哪里翻车，你才会在那些地方提前铺好缓冲垫。而大多数团队的知识库项目，都死在“自以为不会翻车”的那个瞬间。