检索增强生成通常简称 RAG，它让语言模型在作答时获得经过挑选的信息。应用程序不只依赖模型训练中学到的模式，而是先搜索文档集合，把相关段落加入请求，再要求模型依据这些证据回答。
基本流程有三部分：检索负责找到候选段落；增强把这些段落连同指令和用户问题打包；生成则产出应当立足于所给材料的答案。当知识属于私有资料、更新频繁或需要引用时，这种模式尤其有用。
RAG 不会让模型天生变得真实可靠。它创建的是一条可检查、可改进的组件链路。检索器可能漏掉正确文件、选到过期版本，或返回关键词相近但含义不符的段落；提示词也可能没有要求依据来源回答。随后，模型便可能把有效摘录拼成一个没有依据的结论。
文档准备决定了很大一部分结果。文件需要稳定标识、有用的元数据、访问权限规则，以及能保留足够上下文含义的分块。块太大会浪费上下文并模糊相关性；块太小又可能把一项主张与它的定义、日期、例外条件或表格标题拆开。
检索可以使用关键词搜索、向量相似度、语义排序或混合方式。关键词搜索擅长姓名、代码和精确短语；向量搜索可以在措辞不同的情况下找到概念相关的段落。混合检索通常是更好的默认选择，因为它结合了两种信号，但仍需要拿真实问题来评估。
访问控制应当发生在检索阶段，而不是在生成后附上一句免责声明。用户绝不应拿到自己无权检索的段落。检索到的文件同样必须被视为不可信输入：文件中可能含有试图覆盖应用规则的指令。应保持系统策略独立，并限制下游工具可以执行的操作。
提示词应标明每个来源分块，要求事实主张附带引用，并定义证据不足时的处理方式。它还应规定如何面对分歧：带着日期和引用展示冲突版本，而不是悄悄挑一个。这些要求会让错误更容易诊断。
检索与生成应分开衡量。检索测试考察支撑答案的段落是否出现在靠前结果中；生成测试考察答案是否有依据、是否完整、引用是否正确，以及不确定性是否表达得恰当。精致的答案可能掩盖薄弱检索，而完美检索之后也仍可能出现糟糕的综合。
更多上下文并不总是更好。低相关度段落会消耗 token，并可能把回答从最有力的证据旁拉开。设置相关性阈值，去除重复内容，在新鲜度重要时优先当前版本，并为回答预留足够空间。复杂问题可能需要拆成几次聚焦检索。
当事实存在于不断变化或私有的语料库中时，RAG 是合适工具。如果目标是改变行为、风格或任务表现，而不是注入最新知识，微调通常更合适。若系统需要作为更大流程的一部分决定何时、何处检索，代理工具则可能发挥作用。
可信的 RAG 界面应展示来源，在语料库无法回答时坦诚说明，并允许更正。真正的产品不是生成出来的那段文字，而是那条让读者判断这段文字是否值得信任的证据路径。
我们会结合一手资料、产品文档与实际使用场景，帮助你更清楚地判断工具是否适合你的工作流。