48 篇博文 含有标签「RAG」

大多数构建 LLM 应用的团队都将隐私视为一个模型问题。他们担心模型知道什么——它的训练数据、它的记忆——却在模型周围的流水线中留下了巨大的漏洞。令人尴尬的事实是，生产环境 LLM 系统中绝大多数的数据泄露根本不是来自模型。它们来自你未经脱敏就索引的 RAG 分块、你逐字写入磁盘的提示词日志、包含数据库凭据的系统提示词，以及被投毒文档劫持以窃取知识库中所有内容的检索步骤。

Gartner 估计，到 2025 年底，30% 的生成式 AI 项目将因为风险控制不足而被放弃。这些失败中的大多数并不是因为模型幻觉——而是源于工程师本以为在掌控之中的系统隐私和合规性故障。

当 Gemini 1.5 Pro 发布并具备 1M token 的上下文窗口时，一波工程师宣布 RAG 已死。这种论点看似无懈可击：既然你可以把整个知识库直接丢进提示词（Prompt）中让模型自己去处理，为什么还要构建一个包含分块器（chunkers）、嵌入（embeddings）、向量数据库和重排序器（re-rankers）的检索流水线呢？

这种论点在生产负载下会分崩离析。Gemini 1.5 Pro 在“大海捞针”（needle in a haystack）基准测试（即隐藏在文档中的单个事实）中实现了 99.7% 的召回率。但在现实的多事实检索场景中，平均召回率在 60% 左右。这 40% 的遗漏率并非基准测试的偏差；而是你的系统在静默状态下未能向用户展示的事实。而且，一个 1M token 请求的延迟比 RAG 流水线慢 30–60 倍，而单次查询成本约为其 1,250 倍。

长上下文模型是强大的工具。它们只是不适合大多数生产环境的检索工作负载。

大多数 RAG 系统在部署时都配备了向量数据库、几千个 embeddings，并假设语义相似度已经足够接近正确性。事实并非如此。这种“语义相似”与“实际正确”之间的差距，正是 73% 的 RAG 系统在生产环境中失败的原因，而且几乎所有这些失败都发生在检索阶段 —— 甚至在 LLM 生成任何文字之前。

“对文档进行嵌入、使用余弦相似度查询、将 top-k 传递给 LLM”的 standard playbook 在演示中有效，是因为演示查询是经过设计的。生产环境的查询则不然。用户搜索的是产品 ID、发票号码、监管代码、拼错的竞争对手名称，以及单个 embedding 向量在几何上无法满足的多重约束问题。稠密向量搜索并没有错 —— 只是它并不完整。构建一个在生产环境中真正起作用的检索栈，需要理解其中的原因，并层层加入能够弥补这些缺陷的组件。

一个自信地推荐已经缺货六个月产品的智能体；一个告诉用户查不到 20 分钟前下单记录的客服机器人；一个针对两年前已废弃的库 API 生成可正常运行代码的编程助手。这些并不是传统意义上的“幻觉”——模型只是在回忆曾经准确的信息。这是一种完全不同的失效模式，而且大多数团队还没有准备好如何检测或防御它。

这种区分至关重要，因为缓解措施根本不同。你无法通过提示词工程解决时效性问题。你也无法通过微调来解决——对过时的知识进行微调只会让问题变得更糟，而不是更好，因为模型会以更高的权威感表达过时的信息。随着模型在表达上变得越来越流利和自信，它们那些自信且错误的陈旧答案对用户来说变得更难察觉，而不是更简单。

2024 年，90% 的智能体 RAG（Agentic RAG）项目在生产环境中失败了。原因并非技术本身存在缺陷，而是工程师们仅仅将向量搜索、提示词（prompt）和大语言模型（LLM）组合在一起，称之为检索管道并直接发布——却忽略了从查询到回答之间每一层累积的失败成本。

经典的 RAG 是一个确定性函数：嵌入查询 → 向量搜索 → 填充上下文 → 生成。它单向运行一次，没有反馈循环。当查询是针对分块良好的语料库进行简单的单步查找时，这种方式很有效。但当用户询问“比较这五份合同中的责任条款”或“总结自第三季度事故以来我们的基础设施配置发生了哪些变化”，或者任何需要先综合多份文档中的证据才能形成答案的问题时，它就会惨遭失败。

大多数将生成式 AI 技术栈视为模型集成项目的团队，最终都会发现他们实际上构建了——或需要构建——一个平台。模型是最简单的部分。难点在于它周围的一切：将查询路由到正确的模型、可靠地检索上下文、过滤不安全的输出、缓存冗余调用、在由五个 LLM 调用组成的链条中追踪出错原因，以及随着使用规模扩大，防止成本逐月翻倍。

本文讨论的就是这个平台层。不是模型权重，也不是提示词——而是将一个可行的原型与一个你可以放心交付给百万用户的系统区分开来的基础设施。

大多数 LLM 质量问题并非提示词（Prompt）问题。它们是上下文（Context）问题。

你花了数小时打磨完美的系统提示词。你添加了 XML 标签、思维链指令和精细的人设定义。你在一些输入上进行了测试，效果看起来很棒。然后你上线了产品。两周后，你盯着一个工单发呆：智能体一本正经地告诉用户错误的账户余额 —— 因为它检索到了前一个用户的交易记录。模型完美理解了指令，它只是拿到了错误的输入。

这就是提示词工程（Prompt Engineering）与上下文工程（Context Engineering）之间的核心区别。提示词工程问的是：“我该如何措辞？”上下文工程问的是：“模型现在需要知道什么，以及我如何确保它准确获得这些信息？”前者是文案写作，后者是系统架构。

如今大多数使用 LLM 构建产品的团队都在重复别人一年前犯过的错误。最代价昂贵的错误就是将模型误认为是产品。

在 LLM 驱动的系统（代码生成工具、文档处理器、面向客户的助手、内部知识系统）上线生产环境一年后，从业者积累了一系列辛苦换来的知识，这些知识与炒作周期所暗示的大相径庭。这些教训不在于选择哪个基础模型，或者 RAG 是否优于微调，而在于构建可靠系统的那些枯燥工作：如何评估输出、如何构建工作流、何时投资于基础设施、何时继续迭代提示词，以及如何思考差异化。

这是对这些实战经验的总结。

大多数团队将 RAG 上线并称之为检索策略。他们将文档分块、嵌入、存储向量，并在查询时运行最近邻搜索。这在演示中效果足够好。然而在生产环境中，用户开始报告系统找不到他们知道存在的文章、遗漏文档中字面意义上的错误代码，或者返回语义相似但事实错误的内容。

问题不在于 RAG。问题在于将检索视为一个一维问题，而它实际上一直都是多维的。

大多数使用 LLM 构建产品的工程师都经历过相同的轨迹：两天内跑通 demo，六周后生产环境一片混乱。这项技术在真实负载、真实用户和真实数据下的表现截然不同。从中得出的教训不是哲学层面的，而是操作层面的。

在观察了众多公司的团队发布（有时也放弃）LLM 驱动产品之后，一些规律反复出现。这些不是边缘案例，而是普遍经历。

演示总是有效的。用精选的例子提示模型，获得清晰的输出，将截图发给利益相关者。六周后，系统面对真实用户，而演示中的例子却一个都没有出现在生产流量中。

这是每个LLM产品团队最终都会遇到的鸿沟：从“它在我的输入上有效”到“它在我未曾预料的输入上都有效”的飞跃。弥合这一鸿沟的模式并非关于模型选择或提示词的巧妙，而是关于系统设计。七种模式解释了功能原型与可靠生产系统之间的大部分差异。

大多数生成式 AI 项目都以失败告终——并非因为模型本身不好，而是因为团队在技术栈的每个层面都犯了相同且可预测的错误。一项 2025 年的行业分析发现，42% 的公司放弃了他们大部分的 AI 计划，而 95% 的生成式 AI 试点项目未能产生可衡量的业务影响。这些并非模型故障，而是团队本可以避免的工程和产品失败。

本文将列举那些最容易导致 AI 项目失败的陷阱——从问题选择到评估——并结合生产系统中的具体案例进行阐述。