178 篇博文 含有标签「rag」

你将昂贵的 LLM 换成了更快、更便宜的蒸馏模型。延迟增加了，成本上升了，质量下降了。你感到困惑并回滚了版本，因为你刚刚花了三周时间做的优化工作反而让一切变得更糟。

这并非假设。这是生产环境 AI 系统中最常见的失败模式之一，它源于一个诱人但错误的心理模型：优化某个组件就能优化整个系统。

在一个运行时间足够长的 AI 项目中，几乎都会出现一种模式。团队构建了一个原型，演示效果看起来不错，但在生产环境中，输出结果不够一致。有人建议切换到最新的前沿模型——用 GPT-4o 代替 GPT-3.5，用 Claude Opus 代替 Sonnet，用 Gemini Ultra 代替 Pro。有时这会有所帮助，但最终这种方法会不再奏效。团队发现，他们为每次推理支付了 5-10 倍的费用，延迟增加了一倍，而任务准确率仍然停留在 78%，而不是他们需要的 90%。

这就是潜在能力上限（latent capability ceiling）：即你所使用的语言模型的原始规模不再是限制因素的临界点。这是一个有经验数据支持的真实现象，大多数团队在遇到它时却浑然不觉——因为“使用更大的模型”这一反射动作成本低、速度快，并且在项目早期往往非常有效。

你的新内部聊天机器人刚刚告诉一名实习生整个工程部门的薪资范围。HR 总监没有配置错任何东西。没有人分享了不该分享的链接。系统只是... 检索到了它，因为实习生询问了“工程师的薪酬预期”。

这是大多数团队预料不到的 RAG 隐私失效模式。它不是传统意义上的漏洞 —— 而是检索工作方式与访问控制预期方式之间的根本不匹配。

大多数工程师认为embedding是安全抽象的——一堆无法被逆向工程的浮点数。这个假设是错误的，而感知与现实之间的鸿沟正是用户数据泄露的地方。

最新研究仅凭文本embedding就实现了超过92%的精确token序列重建准确率——包括完整姓名、健康诊断和电子邮件地址——而无需访问原始编码器模型。这些不是理论攻击。可迁移的逆向技术在黑盒场景下同样有效：攻击者构建一个模仿你的embedding API的代理模型，就可以发动攻击。无论你使用的是专有模型还是开源模型，攻击面都存在。

本文涵盖embedding隐私风险的三个层面：逆向攻击的实际能力、检索管道中访问控制悄然失效的位置，以及能为用户提供适当控制权的架构模式——按用户命名空间、检索时权限过滤、审计日志和删除安全设计。

在一百万份干净文档中隐藏五份精心构造的恶意文档，就能对生产级RAG系统实现90%的攻击成功率。这不依赖零日漏洞或密码学破解——只需用纯文本指示模型以与运营者意图不同的方式运行。如果你的防御策略是"在内容到达LLM之前净化输入"，那你已经输了。

框架至关重要。将提示注入视为输入验证问题的团队会构建边界防御：正则过滤器、基于LLM的分类器、输出扫描器。这些有用但不足。真正的问题在于，现代AI系统是组件的组合——检索器、知识库、工具执行器、外部API——每个组件都是有自身攻击面的摄入点。这正是供应链漏洞的定义。

你的 RAG 系统评估看起来还不错。NDCG 尚可接受，演示也能运行。但有一类故障是单一指标评估无法捕捉的：那些你的检索器从未接近过的查询——持续如此，因为你的整个嵌入空间从一开始就没有能力处理它们。

这就是检索单一化。一个嵌入模型、一种相似度度量、一条检索路径——因此也是一套系统性盲点，这些盲点看起来像模型错误、幻觉或用户困惑，直到你真正检查检索层才会发现真相。

解决方法不是更大的模型或更多数据，而是理解不同的查询结构需要不同的检索机制，并构建一个能够停止将一切都路由到同一漏斗中的系统。

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

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

大多数团队在起步时都会选择向量数据库 (Vector Store)，因为它们上手简单，但随后会发现即使无论如何调整分块大小 (Chunk size) 或嵌入模型 (Embedding model)，某些类型的查询也完全无法生效。这并非调优问题 —— 而是架构上的不匹配。向量相似度与图遍历是两种根本不同的检索机制，随着查询复杂度的增加，这种差异会变得愈发关键。

这不是一篇推荐“两者兼顾”的文章。在实际应用中需要进行真正的权衡，选择失误会耗费数月的工程时间。以下是这种选择在实践中的真实面貌。

你的 RAG 流水线上线六个月后，某些东西悄然改变了。用户没有大声投诉，但对答案的信任度正在下降。反馈评分从 4.2 跌至 3.7，一些支持工单提到了"过时信息"。你的工程师检查日志，没有错误、没有超时、没有明显的回归。检索流水线在你配置的每一个指标上看起来都很健康。

但事实并非如此。它正在腐烂。

检索债务是向量索引中积累的技术性衰退：不再代表当前文档内容的过期嵌入、污染搜索结果的已删除记录产生的墓碑块，以及索引语料库时使用的编码器版本与当前计算查询嵌入的编码器版本之间的语义漂移。与代码腐烂不同，检索债务不会产生堆栈跟踪，它产生的是带有自信引用的微妙错误答案。

当工程师评估向量数据库时，他们通常会加载 ANN 基准测试，并选择在 recall-at-10 排行榜上名列前茅的产品。三个月后，他们就开始提交迁移工单了。这些基准测试是在单一客户端、静态且索引完美的索引数据集上测量查询吞吐量的。但生产环境完全不是这样。

本指南涵盖了预测向量数据库在实际工作负载下能否撑住的五个维度，以及一个将这些维度与你的技术栈进行匹配的决策框架。

一个合规承包商构建了一个 RAG 系统，旨在回答有关 400 页政策文档的问题。系统通过了内部 QA，针对单主题查询的检索表现正确。然而系统上线后，在处理涉及例外条款的任何问题时，它开始返回语气自信、结构严谨但错误百出的答案。

调试过程似曾相识：更换嵌入模型、调整相似度阈值、试验分块大小、添加重排序器。几周过去了，改进微乎其微。真正的症结在于，一个关键的例外条款在段落边界处被分割到了两个分块（chunks）中 —— 这并非由于分块策略，而是因为 PDF 提取器在误读排版时，悄无声息地将该段落一分为二。孤立来看，这两个分块都无法检索或解析。系统无法通过幻觉得到正确答案，因为正确的信息从未完整地进入索引。

这就是“提取天花板”：即当下游优化再多也无法弥补受损或缺失的输入数据时，系统所面临的瓶颈。

40% 到 60% 的企业 RAG 部署无法进入生产环境。罪魁祸首几乎从来不是检索算法——HNSW 索引运行正常，嵌入质量也不错，向量相似度搜索已是成熟技术。问题发生在上下游：没有文档所有权、查询时未执行访问控制、PII 裸露在向量索引中，以及检索语料库在上线数周内就与现实脱节。这些都是治理失败，而大多数工程团队将其视为别人的问题，直到合规团队、安全审计，或某个收到了其他租户数据的用户把这变成自己的问题为止。

本文是受控 RAG 知识库的组织与技术解剖——写给拥有管道的工程师，而不是批准预算的高管。