要点一：检索决定上限
模型只能基于检索到的片段作答，检索不到的内容，再强的模型也只能编。因此评估 RAG 要先看召回：同一批问题里有多少能命中正确段落。命中率低时，改提示词几乎没有意义，应先修索引与切分，如何判断优先级就看召回名次分布。
要点二：切分与元数据
按条款、章节与表格结构切分，比按固定字数切分更容易命中完整语义；每段还要带上来源、版本、生效日期与可见范围。元数据缺失时，系统无法判断哪一版有效，也无法按用户权限过滤，答案很容易过期或越权，事后怎么补都补不回来。
要点三：混合检索与重排
关键词检索擅长精确匹配编号与专有名词，向量检索擅长同义表达，两者结合再加重排，效果通常比单一路径稳。只用向量时，用户问一个条款号往往召回一堆语义相近但不对的段落，如何取舍要看实际问法的分布。
要点四：引用与拒答
答案要带出处，让业务能点回原文核对；检索置信度低或没有命中时，应明确说没有找到，而不是给一个看似合理的答案。拒答率是重要指标，长期为零通常意味着系统在编，而不是它什么都会，边界就在这里。
要点五：更新与权限
制度、价格与产品资料都在变，索引必须支持增量更新与失效标记，否则三个月后答案就不可信。权限要在检索层过滤：用户看不到的文档，不能因为语义相近就进入上下文，这是最容易出合规问题的地方，也是审计最先查的一层，边界必须划在检索层。
适用与不适用
适合谁
- 制度、产品与技术文档量大且更新频繁的企业
- 客服与技术支持需要引用原文的团队
- 已有文档管理系统与权限体系的组织
不适合谁
- 知识几乎不变、问题只需模型常识的场景
- 文档没有结构、也没有权限体系的环境
典型场景
某制造企业的售后服务团队把维修手册、故障案例与备件目录接入检索，工程师提问后系统返回三段原文与出处，答案下方标注适用的设备型号。命中不到时直接提示转技术支援，不再强行生成，上线后最常见的改进是补切分规则与同义词表。
可执行步骤
- 先盘点语料的来源、版本与可见范围，逐类标出可以进入索引的部分
- 按条款与章节结构切分，每段保留出处、版本号与生效日期，并打上权限标签
- 关键词与向量检索同时开启，再叠加一层重排，用同一批问题比较命中率变化
- 为答案加上引用与拒答规则，置信度低时明确说明没有找到依据，并给出转人工入口
- 建立一套固定的问答评测集，按月复查召回率、拒答率与引用准确率
常见坑
- 只接一个向量库就上线，检索命中率低，模型开始编造条款，业务很快就不再信任这套系统。
- 按固定字数机械切分，条款被切成两半，答案永远缺一半前提，复核时很难发现，只能整段重查。
- 不做权限过滤，员工通过提问就能看到不该看的文档内容，事后也无法完整追溯与解释清楚。
- 不做增量更新，制度改版后系统仍在引用旧条款，客服照着回答，客户投诉随之增加且很难澄清。
自检与验收清单
- 语料来源、授权范围与可见范围是否都已经清楚
- 切分是否按文档结构进行，而不是按固定字数
- 是否同时启用关键词检索与向量检索，并做重排
- 答案是否带出处，能否点回原文逐条核对确认
- 是否设了拒答规则，并明确置信度的判定阈值
常见问题
RAG 能解决模型胡说的问题吗？
能减少但不能根除。RAG 让答案有据可查，但检索错、切分错或模型误读片段时仍会出错。要靠引用、拒答与抽检把风险压下来，而不是假设接上检索就不会错，也不能把抽检省掉。
一定要用向量数据库吗？
不一定。语料规模不大、查询以编号与专有名词为主时，关键词检索加结构化过滤已经够用。向量检索解决的是同义与口语化表达，是否引入要按实际问法与召回效果决定。
文档多久更新一次索引？
按文档变更频率定：制度与价格类建议每日或随变更触发，技术手册可按周。关键是建立失效标记，旧版本要能立刻下线，否则用户会拿到过期答案却以为是最新的，这类投诉最难解释。