RAG（检索增强生成）的原理简单到一句话能讲完：先从你的资料里检索相关片段，再把片段和问题一起交给大模型作答。
正因为原理简单，Demo 门槛极低——但也正因如此，大量项目卡在了「Demo 很惊艳，一上真实场景就露馅」。差距不在模型，在下面这七个决策。
决策一：切分策略
按固定字数切分是最省事的做法，也是最容易出问题的。一个跨段落的完整答案被从中间切断，检索时只能拿到半截。
- 优先按语义边界切：标题层级、段落、列表项，而不是字符数
- 保留上下文头：每个片段带上它所属的章节标题，避免片段脱离语境
- 重叠窗口：相邻片段留一定重叠，降低边界切断的损失
- 表格单独处理：表格按行切会丢表头，通常需要整体保留或转成结构化描述
决策二：检索不能只靠向量
纯向量检索擅长语义相似，但对精确匹配很弱——用户问「XR-200 的保修期」，向量检索可能返回一堆讲保修政策但不涉及该型号的内容。
生产环境通常需要混合检索：向量召回负责语义，关键词检索（BM25）负责精确命中，两路结果合并后再重排序。型号、编号、专有名词多的场景，这一步的收益非常明显。
决策三：重排序值不值得加
召回阶段为了不漏，通常会取比较多的候选（比如 20 条），但直接把 20 条塞给模型既贵又容易干扰判断。重排序模型的作用是从这 20 条里精选出最相关的 3–5 条。
经验判断：知识库条目超过几千、或用户问法多样的场景，重排序几乎必加；小型 FAQ 场景可以省。
决策四：权限必须进检索层
这是最容易埋雷的一条：把权限过滤做在生成之后（让模型自己判断该不该说）是不可靠的。权限必须作为检索的硬性过滤条件，让不该被看到的内容根本不进候选集。
实现上通常在每个片段的元数据里带上可见范围，检索时按当前用户的角色做前置过滤。这一步做对了，才敢把知识库开放给全员。
决策五：答不出来时的行为
默认情况下，大模型倾向于「给个答案」而不是「说不知道」。这在企业场景里是危险的——一个编造的报价或保修条款可能带来真实的商业纠纷。
- 提示词里明确要求：检索结果不足以回答时，必须回答不知道并建议转人工
- 设置相关性阈值：检索得分低于阈值直接走兜底话术，不进入生成
- 强制引用：回答必须附带来源片段，无来源的结论不予输出
决策六：必须有评测集
没有评测集的 RAG 项目，每次调整提示词或换模型都是在赌。评测集不需要很大，但需要覆盖真实问法。
决策七：成本从一开始就要设计
把所有请求都发给最强的模型，效果确实最好，账单也最好看——朝着坏的方向。可控的做法：
这四条做下来，通常能把成本压到粗放调用的三分之一左右，而效果几乎不受影响。
小结
这七个决策没有一个涉及「用哪个模型」——因为模型选型恰恰是最容易改的部分。真正决定 RAG 项目成败的，是围绕模型的这一圈工程。