RAG 不是魔法：检索增强生成的工程实践
让模型回答“它真正知道的内容”，关键在于把检索链路做好，而不是盲目换一个更大的模型。
先把问题拆开
知识库问答失败时，很多人第一反应是修改 Prompt。实际上，一个答案需要经过“问题理解 → 文档召回 → 片段重排 → 上下文拼装 → 模型生成”五个环节。任何一个环节出错，最后看起来都像是模型在胡说。
一条可靠的检索链路
- 切分：优先按标题、段落和语义切分，保留文档名、章节、更新时间等来源信息。
- 召回：向量检索负责语义相似，关键词检索负责精确命中；混合召回通常比单一方式更稳。
- 重排：用更精细的模型对候选片段重新排序，避免把相似但不相关的内容塞进上下文。
- 生成：要求模型只依据上下文回答，并在答案中带出引用片段或文档来源。
切分不是越细越好
切得太细，片段失去语境；切得太大，又会浪费上下文窗口。一个比较实用的起点是按标题分组，再以 300～800 字作为软限制，并给相邻片段留少量重叠。最终仍然要用真实问题验证，而不是迷信固定数字。
给答案加上证据
Prompt 可以明确三条规则：上下文没有答案时直接说“不确定”；每个结论尽量对应来源；不要把推测写成事实。程序侧再检查引用是否存在、答案是否超出权限范围，才能让系统真正可用。
用数据而不是感觉评估
准备一组真实问题，分别观察召回命中率、答案忠实度和回答完整度。每次调整切分大小、Top-K 或提示词，都应该用这组问题回归。RAG 是一条数据管道，不是一个开关。
先让证据可靠，再让表达自然。一个可解释的普通答案，通常比一个漂亮但无法追溯的答案更有价值。
把概念变成能力：一套可复用的练习方法
很多人读完一篇 AI 文章，会觉得“我已经懂了”，但真正开始做事时仍然不知道从哪里下手。原因通常不是知识不够，而是没有把概念翻译成任务。一个可靠的学习方式是先选一个自己每周都会遇到的问题，再把它拆成输入、判断、行动和验收四个部分。输入是模型能看到的资料，判断是希望它帮你完成的推理，行动是输出之后要执行的步骤，验收则是你如何确认结果值得使用。只要这四块写清楚，模型名称反而不再是最重要的变量。
以日常工作为例，先不要追求“一次生成最终答案”。可以让模型先复述目标，再列出缺失信息，接着给出两个方案和各自的风险，最后才生成可复制的结果。这个顺序看起来慢一些，却能显著减少答非所问。对于需要引用资料的任务，还要要求模型在每个结论后标注来源位置；对于需要调用工具的任务，则要明确哪些操作只读、哪些操作必须经过确认。把这些要求写成固定模板后，你就拥有了一项可重复的能力，而不是偶尔碰巧得到一段漂亮文字。
从小任务开始，建立自己的评测集
不要用“感觉不错”评价 AI。建议建立一个只有 10 到 20 条的个人评测集，内容来自真实工作：一封难写的邮件、一次复杂的资料整理、一个经常出错的代码片段、一个需要多轮追问的客户问题。每条任务都写下理想结果、不可接受的错误和人工修改时间。换模型或修改提示词后，用同一批任务重跑，记录正确率、耗时、成本和最终修改量。这样做的价值在于，你比较的是模型对你有用的程度，而不是网上榜单上的抽象分数。
评测时要区分“事实错误”和“表达不合口味”。前者需要补充数据、检索、工具或人工审核；后者可以通过示例、语气约束和格式模板解决。还可以增加一个“拒答是否合理”的指标：安全边界过松会带来风险，过紧又会影响效率。对于 Agent 或自动化流程，除了答案质量，还要统计调用了多少次工具、失败后能否恢复、是否产生越权写入。只有把这些指标放在一起，才知道一项优化到底是在变聪明，还是只是在变得更会说。
一套适合新手的 7 天实践路线
- 第 1 天：记录问题。把一周里最重复、最耗时间的三件事写下来，不急着问模型。
- 第 2 天：描述上下文。为其中一件事准备背景、目标、受众、限制和一个合格示例。
- 第 3 天：对比提示词。分别尝试直接提问、角色加约束、分步骤提问，保存输出差异。
- 第 4 天：加入资料。观察模型能否区分原文事实、你的要求和它自己的推断。
- 第 5 天：设计验收。给结果增加清单、格式、引用、测试或人工确认点。
- 第 6 天：做一次自动化。把输入和输出接入表格、脚本、知识库或一个简单工具。
- 第 7 天：复盘成本。记录节省的时间、产生的错误，以及下周要改的一个环节。
常见误区：为什么看似高级却没有效果
第一个误区是堆砌术语。把“你是专家、请深度思考、一步一步来”全部放进提示词，并不会自动带来更好的结果；模型需要的是具体目标、可用资料和可检查的输出。第二个误区是把上下文窗口当成数据库。把几百页资料一次性塞进去，既增加成本，也让关键内容被淹没；应该先整理目录，再用检索找到最相关的片段。第三个误区是忽略失败路径。真实系统一定会遇到空结果、超时、权限不足和用户说法不清，流程必须允许模型停下来提问或交回人工。
第四个误区是只优化模型，不优化流程。一个普通模型配合清晰的输入表单、可复用的工具和严格的验收，往往比一个更强模型配合混乱流程更可靠。第五个误区是把自动化范围开得太大。涉及付款、删除、发送外部消息、修改生产数据的动作，都应当先做预览，再让人确认。所谓高级应用，不是让模型拥有更多权力，而是让每一步都可追踪、可解释、可回滚。
最后的检查清单
- 我是否明确写出了任务目标，而不是只写了主题？
- 模型拿到的资料是否来自可信来源，是否需要标注引用？
- 输出是否有固定结构，别人能否快速检查？
- 失败时会发生什么，是否有重试、降级和人工接管？
- 是否记录 token、延迟、错误率、修改量和实际成本？
- 涉及隐私、权限或外部副作用时，是否经过最小权限和确认设计？
学习 AI 的终点不是记住更多模型名字，而是形成一套面对新问题也能复用的方法：先定义问题，再准备上下文；先让模型给方案，再让它执行；最后用数据和反馈验证结果。沿着这条路径练习，你会发现所谓高级应用，其实就是把一次聊天变成稳定的工作流程。
进阶案例：从一次回答到一条稳定链路
假设你要把本文主题应用到一个真实项目，第一步不是立刻购买最贵的模型，而是写出一张“任务卡”。任务卡包括目标用户、输入来源、成功标准、不能做的事情、允许调用的工具、异常时的处理方式，以及谁来为结果负责。比如资料问答的成功标准可以是“回答必须引用原文段落，找不到时明确说不知道”；代码助手的成功标准可以是“通过现有测试，不修改密钥和部署配置”；内容助手的成功标准则可以是“符合品牌语气，并保留事实出处”。标准越具体，后续越容易自动检查。
第二步是准备最小可用版本。只选择一个模型、一个数据源和一个输出格式，先让流程跑通。第三步才是增加复杂度：接入第二个模型做复核，加入检索或工具调用，增加缓存和异步任务，最后再考虑多 Agent。每增加一个组件，都要回答一个问题：它解决了什么已被观察到的问题？如果只是因为“大家都在用”，就先不要加。复杂不是高级，稳定地解决问题才是高级。
第三步是设计观测。给每次请求生成唯一编号，记录输入摘要、使用的模型、耗时、token、工具调用、错误类型和最终状态；涉及隐私时只保留脱敏后的必要信息。每周抽样阅读失败案例，把失败分成理解错误、资料缺失、工具失败、权限问题、格式问题和用户目标变化六类。分类之后，修复动作就会清晰很多：理解错误改提示词，资料缺失改知识库，工具失败改超时和重试，权限问题改服务端校验，格式问题改结构化输出，目标变化则需要让用户确认。
如何判断自己真的学会了
你可以用三个问题自测。第一，面对一个完全陌生的模型，你能否在半小时内查清它的输入模态、上下文、工具能力、价格和数据政策？第二，面对一个不稳定的 AI 流程，你能否用 10 条真实样本定位问题，而不是凭感觉换模型？第三，面对一个可能造成损失的自动化动作，你能否设计预览、确认、审计和回滚？如果三个问题都能回答，说明你学到的已经不是某个产品的按钮，而是一套可以迁移的 AI 工程方法。
还要记住，AI 领域变化很快，模型名称、价格和接口都会更新。把重要知识写成带日期的笔记，给链接标注官方来源，给代码锁定版本；每隔一段时间重新跑一次评测集。这样即使模型换代，你也能快速判断变化对自己的工作意味着什么，而不会被宣传语牵着走。
把结果交给别人之前
最后再做一次人工复核：删掉没有依据的确定语气，检查数字、日期、专有名词和链接，确认输出没有把示例当成事实。对于团队协作，把最终版本、使用的资料、模型设置和验收结果一起保存，别人才能复现你的结论。AI 可以帮你加速探索，但责任仍然需要由清楚的人、清楚的流程来承担。把这一步坚持下来，模型越强，你的工作质量才会越稳定。