Search vs Discovery

很多公司在搞 RAG（检索增强生成）或者内部知识库时有个巨大的误区：觉得只要把文档全部喂给大模型，或者把搜索准确率提高到 99%，问题就解决了。但作为一名在各种屎山代码和破碎文档里摸爬滚打的云架构师，我得说：搜到东西 $\neq$ 搞懂问题。

前阵子我处理一个线上 Bug，得查为什么某个服务能绕过 API 网关校验。我当时开了五个标签页：一个 ADR（架构决策记录）、一个 Jira 单子、一段 Slack 聊天记录、一份 Runbook 和一个配置文件。

诡异的是，搜索功能完全没失效，它精准地把这五个相关文档全推给了我。但没有任何一个文档能直接告诉我“为什么”。我得像个侦探一样，把这五个碎片拼在一起，才发现是因为几个月前有个安全审核，为了不让生产环境崩溃，给某个老服务开了个临时特例，然后这个特例就成了没人记录的“潜规则”。

这就涉及到一个核心技术痛点：Search（搜索）和 Discovery（发现）完全是两码事。

Search（搜索）： 它是检索碎片。比如“API 文档在哪？”，搜到那个 PDF 就完事了。

Discovery（发现）： 它是重建逻辑。比如“这系统为什么这么设计？”，答案并不在任何一个单一文档里，而是在文档 A、聊天记录 B 和代码提交 C 之间的关系中。

现在的很多大模型检索方案，底层逻辑还是“寻找最相似的文档片段（Top-k）”。这在查事实类问题时很猛，但在面对组织记忆时就抓瞎了。因为真实的知识往往是散落在各处的：设计评审在文档里，实现细节在 Commit 里，而真正的“坑”在 Slack 的吐槽里。

如果我们只衡量检索质量是否返回了“正确文档”，那就太天真了。很多时候，根本不存在所谓的“正确文档”，答案就隐藏在文档之间的连接线里。

这让我意识到，以后在搭建 AI Agent 或知识库工作流时，不能只盯着 Embedding 的相似度。真正的挑战在于如何让 AI 具备这种“碎片拼图”的能力，而不是让它做一个简单的搬运工。毕竟，最可怕的不是文档丢失，而是文档都在，但连接它们的逻辑断了。