你的 RAG 懂文档，但它不懂你的工程师所知道的。

你的企业刚刚部署了一个 RAG 系统。你索引了每个 Confluence 页面、每份运行手册（runbook）、每篇架构文档。六个月后，一位高级工程师离职了——就是那个知道为什么支付服务会有那种不寻常的重试模式、为什么你们从不把缓存扩容超过 80%，以及周五绝对不要给哪家供应商打电话的人。这些知识从未被记录下来。你的 RAG 系统根本不知道它的存在。

这就是隐性知识（tacit knowledge）问题。这也是为什么大多数企业 AI 系统表现不佳的原因——不是因为检索质量或幻觉，而是因为它们所需的知识从一开始就没被捕获。60% 的员工表示，很难甚至几乎不可能从同事那里获取关键信息。90% 的组织表示，员工离职会导致严重的知识流失。你的 RAG 能索引的文档只是冰山一角。

显性知识并不是难点

知识管理理论中有一个非常有用的区分：显性知识（explicit knowledge）是任何已经写下来的东西——文档、运行手册、API 规范、复盘报告。而隐性知识（implicit knowledge）则存在于人们的脑海中——那是多年来在系统上工作所积累的直觉、思维模型和判断。

RAG 系统擅长第一类，但对第二类视而不见。它们可以检索到“缓存 TTL 设置为 300 秒”，但检索不到“我们在 2023 年尝试过 600 秒，结果在流量高峰期间导致了连锁数据库超时”。它们可以展示服务契约，但无法展示团队之间维持的非正式协议，因为正式的 API 更改需要六周的协调时间。

显性知识也会按可预测的时间表衰减。技术文档的半衰期大约为 18 个月。面向客户的信息在六个月内就会降级。市场敏感数据的有效期只有几周。但隐性知识不会以同样的方式衰减——它只是在携带它的人离开时随之而走。

工程上的问题不在于如何更聪明地检索知识，而在于如何在日常工作流程中，在隐性知识消失之前，持续地将其转化为显性知识。

为什么索引对话无法解决问题

显而易见的第一步是将沟通渠道（如 Slack、Teams、邮件线程）与文档一起丢进向量数据库。但这无一例外地会让检索效果变得更糟。

对话的结构与文档有着本质的不同。一个 Slack 线程可能包含五个不同的主题、三个跑题的笑话、一个立即被取代的链接，以及一个埋在中间的真正有用的架构见解。当你将其分块并嵌入（embed）到向量数据库中时，嵌入捕获的是所有这些内容的平均表征。在查询时，有用的见解在语义上被稀释成了噪音。

规模问题加剧了这种情况。向量数据库会随着增长而显著退化。在 10,000 份文档左右，嵌入聚类开始重叠。在 50,000 份文档时，检索精度可能会下降近 87%。添加数万个低信号的对话块会加速这种崩溃。你最终得到的是一个能以高置信度分数检索出对话片段，却无法提供有用上下文的系统。

分块大小的选择让情况变得更糟。小分块会丢失使交流变得有意义的周围上下文——如果没有前面五条消息，一条写着“我们应该改用另一种方法”的消息就毫无用处。大分块将多个想法混合到一个嵌入中，导致它在所包含的所有主题上的检索精度都很低。而对话恰恰处于这两种失败模式的交汇点。

真正奏效的方法：提取，而非索引

正确的架构应该将沟通渠道视为信号源，而不是文档库。与其索引原始内容，不如从中提取结构化知识。

主动标记，而非被动摄取。 与其索引整个对话历史，不如构建让工程师能够在交流发生时标记重要内容的系统。一个表情符号回应或一个简单的机器人指令（“!capture this”）就能触发针对该特定线程的结构化提取过程。这从根本上保持了高信噪比。在摄取阶段，人类依然是相关性的过滤器，而 AI 则负责提取和结构化。

结构化提取优于原始存储。 当捕获到一个有意义的交流时——比如确定了 Bug 根本原因的线程、关于安全约束的代码审查讨论、事件解决方案——不要存储原始文本。通过结构化提取运行它，提取出五个到七个维度：问题是什么、诊断是什么、解决方案是什么、这为以后建立了哪些约束、涉及哪些系统。存储结构化输出，并将原始文本仅用作上下文。Zalando 的事件分析系统正是这样做的：LLM 从复盘文档中提取五个核心维度，并严格限制猜测——当信息不明确时，模型必须明确指出，而不是填补空白。

用于批量提取的 Map-reduce。 对于处理历史存档——数年的事件报告、已合并的代码审查线程、已完成的问答工单——使用 map-reduce 方法。Map 阶段跨文档并行运行提取，为每个文档生成结构化输出。Reduce 阶段将这些输出聚合为更高级别的摘要或实体图。这实现了提取（可以并行化并单独验证）与综合（需要全局视图）的分离。

你可能错过的四种信号源

不同类型的渠道需要不同的提取策略。这里有四个隐性知识密度最高的来源。

事故复盘（Incident postmortems）。 大多数团队写完复盘后就再也不读了。累积的复盘存档实际上是关于系统行为最丰富的组织知识库——哪些组件会同时发生故障，哪些故障模式会反复出现，凌晨 3 点什么样的干预措施有效。Zalando 对两年多复盘数据的分析揭示了数据存储事故、配置问题和容量问题的重复模式，这些模式在任何单一报告中都是不可见的。这里的工程投入在于构建提取流水线并针对存档运行，同时在编写新复盘时保持数据的新鲜度。

加载中…