做RAG检索的人，最怕听到一句话：“这个政策明明写了，你这边怎么没答出来？”尤其是政策文档场景，丢一个关键点，轻则答非所问，重则给用户错误指引。我自己前前后后做过几套政策问答系统，踩过的坑比写过的代码还多，今天就把“漏关键点”这件事从头到尾拆一遍：为什么会漏、怎么从检索链路堵漏、上线之后怎么排查，全部用实操经验说话。
RAG政策文档检索的目标很简单：用户问一个问题，系统能从政策原文里找到所有相关条款，再交给大模型组织成回答。但“所有相关条款”这五个字，恰恰是最难做到的。政策文档不像新闻或技术博客，它的信息密度极高，一条补贴政策里可能同时包含适用对象、申报条件、材料清单、审核流程、不予受理情形，这些信息分散在不同章节，还互相引用。通用RAG方案按固定窗口切一切、向量检索召回Top5，漏关键点几乎是必然结果。这篇内容适合正在做政策问答、制度问答、合同条款检索这类高精度文档场景的开发者，也适合被“RAG效果不稳定”折磨过的朋友，看完可以直接照搬思路去改自己的系统。
1. 政策文档检索“漏关键点”的病根分析
很多团队遇到漏检，第一反应是换更强的模型、加大语言模型的推理能力，但折腾一圈发现效果提升有限。我个人的结论是：政策文档场景的漏检，问题出在“检索”这一层，而不是“生成”那一层。模型再聪明，如果关键条款根本没进上下文，它就没有办法凭空答出来。
1.1 通用RAG方案在政策文档上为什么容易翻车
先看通用方案最典型的三个做法：固定字数切片、向量检索、TopK召回。这三步单独看都没问题，组合在政策文档上就处处别扭。
固定字数切片是最典型的隐患。政策文档的条款是结构化单位，一个“条”内部往往是一个完整的语义单元，从“申报单位应具备以下条件”到“存在以下情况之一的，不予受理”，中间可能隔着三四百字，但它们是强相关的整体。按512字或1000字硬切，很可能会把“条件”和“不予受理情形”切成两段，检索时只命中了条件部分，负面清单就丢了。用户问“我们公司能不能申请”，模型看到条件都满足就回答可以，实际上还有一条“近两年内发生重大安全事故的不予受理”没被召回，结论完全错误。
向量检索对政策文本的语义理解也有局限。政策语言里大量使用否定表达：“不得”“除外”“以下情形不适用”“但经批准的除外”。这些词的语义权重很高，但通用向量模型在预训练时并没有针对这类文本做过专门优化，语义上“不得享受补贴”和“享受补贴”可能距离很近，TopK召回时模型倾向于找到字面上相似的内容，真正的否定条款经常排不到前面。更隐蔽的是条款编号和交叉引用，比如“补贴标准按照第六条执行”“参照第三章有关规定”，这类引用型句子很短、语义很弱，向量模型很难从“参照第六条”这几个字里理解它指向什么内容。
还有召回数量的问题。固定TopK=3或TopK=5，在开放域问答里够用，在政策场景里远远不够。一份政策文件可能同时涉及多个维度的规则，用户问题稍微复杂一点，需要的关键条款可能分散在七八个不同的段落里，Top5的上限天然就会截断尾部信息。我见过不少团队把top_k从5调到3，理由是“减少噪声提升准确率”，结果漏检更严重了。
1.2 政策文档的文本特征到底特殊在哪
想解决漏检，得先建立对政策文档文本特征的清晰认知。它和普通文本最大的区别在于高度结构化、强约束性、多层级关联。
结构化体现在“章—节—条—款—项”的层级体系上，每个条款有唯一的编号，条款之间的逻辑关系是树状的。强约束性体现在几乎每个关键点都伴随前提条件、适用范围、例外情形，这些约束条件共同决定了一个结论是否成立。多层级关联体现在条款之间经常互相引用，主条款只是给出方向，真正的细则藏在被引用的其他条款里。
具体到文本层面，有几个非常明显的特征：
- 条款编号密集，如“第一条”“第七条”“（二）”等，这些编号本身承载了定位信息，是检索的重要锚点；
- 数值型阈值多，如“注册资本不低于500万元”“经营年限满三年”“补贴比例不超过20%”，用户问题里经常只有模糊化表达，比如“刚成立的公司”，需要检索系统能对应到具体的数值条款；
- 例外条款多，政策文本几乎都有“但书”条款，即“原则上……但……除外”或“以下情形不适用”，这类条款恰恰是最容易漏的；
- 长文档居多，一份管理办法动辄三五千字，多数政策问答系统是以一个文件为知识源，内部检索的精度要求远高于互联网搜索。
1.3 漏检的关键点到底是怎么“漏”掉的
我拆一个真实场景的例子，这是我在某次项目里复现过的典型问题。一份产业扶持资金管理办法，共六章四十条，其中一个章节规定支持对象为“在本市注册、具有独立法人资格的企业”，另一个章节规定申报条件包括“持续经营满三年”“近两年无重大违法违规记录”。用户问：“我们公司去年刚注册，可以申请这个扶持资金吗？”
通用RAG系统的处理链路大致是这样：把文档按1000字切块，向量化建索引，用户问题向量化后在库内做相似度检索，召回相似度最高的5个块，拼接后交给LLM生成回答。实测结果是什么？召回结果里确实包含了“支持对象为企业法人”那段，模型顺着这段话分析后给出“符合基本条件，可以申请”的回答。
但政策原文里最关键的“持续经营满三年”这个条件，因为距离“支持对象”段落较远、且被切到了另一个文本块中，完全没有被召回。这不是模型的问题，是检索阶段就把决定结论的关键约束弄丢了。这个案例很清楚地说明：漏关键点，通常不是单纯漏掉了某一个paragraph，而是漏掉了决定答案“边界”的约束条件，尤其是条件、例外、时限这一类的限定信息。
2. 检索链路改造：从切片到召回逐层堵漏
既然病根在检索链路，就先从链路最底层的切片和召回开始改。这里的每一条我都实际验证过，不是理论推导。
2.1 切片策略：以条款为单位切，保留结构元信息
固定字数切片的替代方案是按文档结构切分，也就是解析出“章—节—条—款—项”的层级，以“条”为基本单位进行切片。实现思路是先用正则或规则解析文档中的条款编号，比如匹配“第[一二三四五六七八九十百]+条”这样的模式，将每个“条”作为一个独立的分块单元。条文特别长（超过模型窗口）时，再在条内部按“款”或“项”二次切分，并在块与块之间保留重叠窗口。
这样做的好处是保证了语义完整性：“一条”内部的“适用范围—条件—例外”被作为一个整体保存，不会被拦腰截断。同时，每个分块需要附带结构元信息，包括所属章节、条款编号、条款标题等，这些元信息后续既可以用于检索过滤，也可以拼进上下文提示模型“你现在看到的是第几条”。
我在实际项目中还加了一个细节：对分块做“段首摘要”。也就是用语言模型为每个切片生成一句不超过20字的内容摘要，放在块首，检索时把摘要和正文一起参与匹配。这个做法能明显提升长条文里“问题对应正确条款”的命中率，成本是一次性的离线处理，很值。
2.2 混合检索：向量召回和关键词召回并行
向量检索能理解语义，但政策文档里恰恰有很多东西是“语义弱、字面强”的，比如条款编号、金额数字、日期、专业名词。用户直接问“根据第三条怎么办理”，向量模型大概率是懵的，但关键词可以精准命中。反过来，用户说“我们公司去年成立，有没有资格”，关键词匹配不到“成立满三年”这个条件，但向量可以找到语义相近的表述。两种检索方式在政策文档里是互补的，缺一个都会漏。
实操中我是这样配置的：同时跑一路向量召回和一路BM25（稀疏关键词）召回，两边都取Top50，然后做融合。融合策略上，最简单有效的是RRF（Reciprocal Rank Fusion），公式是：
RRF分数 = Σ 1 / (k + rank_i)
其中rank_i是文档在第i路召回中的排序位置，k是一个平滑常数，通常取60。这个公式的好处是不需要归一化不同检索系统的分数，直接用排序位置计算，稳定且实现成本低。融合后取分数最高的N个结果作为候选集。
如果项目预算充足，也可以给向量检索和关键词检索分别设置权重，比如交权0.7、关键词0.3，通过小规模测试集去调。但在我自己的项目里，RRF和加权融合的差距并不大，RRF因为免调参反而更实用。另外，如果解析文档时拿到了条款编号元信息，还可以增加一路“编号匹配”检索：正则匹配用户问题中的“第X条”字样，直接定位对应切片，强制加入候选集。在政策咨询场景里，用户直接报条文编号问问题的情况远比想象中多，这一路召回经常能捞回前面两路都没搜到的关键条款。
2.3 重排序：从“大致相关”到“精确相关”
混合检索的候选集通常比较杂，尤其是向量召回，前50个结果里真正对回答问题有帮助的可能只有十几个。直接把50个块全部塞给大模型不现实，这时需要重排序。
重排序和初排的区别在于：初排（向量检索、BM25）追求的是“快速找到可能相关的候选”，使用双塔模型或稀疏索引，计算速度快但精度有限；重排序则对每一对“查询-文档”做深度交互计算，精度高但速度慢，所以只对少量候选做。我的标准做法是：混合检索召回Top50，重排序模型精排后取前5到前8。
在技术选型上，有两种路线。一种是使用专门的Rerank模型，比如基于交叉编码器的中文重排序模型，它的原理是把“问题+文档片段”作为一个整体输入模型，输出一个相关性分数，效果比初排高一个档次。另一种是使用LLM做Listwise重排，把候选片段和问题一起交给大模型，让它按相关性排序。LLM重排的效果通常更好，但会引入额外的推理成本和延迟，适合对实时性要求不高的场景。我自己在政策问答场景里优先用专门的Rerank模型，因为它每小时可以处理大量请求，成本稳定；如果遇到特别难的问题，再加一个LLM复核兜底。
重排序阶段还有一个操作容易忽略：过滤阈值。很多重排序模型输出的分数在0到1之间，但0.3分以下的基本就是不相关内容。设定一个得分阈值（比如0.35），低于阈值的候选直接丢弃，宁可少给也不要硬凑。给大模型硬塞低质量片段，它可能真的会把不相关的内容编织进回答里，这比漏检更麻烦。
2.4 召回数量与上下文扩展：别让上限成为漏检元凶
前面提到TopK固定5会漏，那是不是把TopK调成50就解决问题了？不是。TopK太大，噪声太多，大模型容易被无关信息带偏。正确思路是分级扩招：初排阶段开放召回上限（50到100），重排序精筛出少数高质量片段（5到8个），再对选中片段做上下文扩展。
上下文扩展的意思是：如果某一条款被命中，它所在的章节上下文可能包含更完整的信息，比如同一章节里的“申报条件”和“申报流程”虽然是不同分块，但被命中时通常都值得一起提供给模型。我常用的扩展规则有三类：
- 相邻扩展：命中块的前后各扩展一个块；
- 同章扩展：同一章节内的其他块按序追加；
- 引用扩展：从命中块中提取出“参照第X条”“按第X条规定”等引用信息，把被引用的条款也捞出来。
扩展后还需要控制总长度。政策问答任务的上下文总长度，我一般控制在2500到4000字之间，太短了信息不够，太长了模型会迷失重点。具体长度和模型窗口有关，需要根据实际效果微调。
3. 关键点补全：多轮检索、查询改写与验证机制
改完检索链路后，召回质量会有明显提升，但依然会漏。原因在于政策文档的复杂性超出了“一查一答”的能力范围，一次检索很难覆盖一个复杂问题的所有约束维度。这一层，需要在检索策略和提示词策略上做进一步的设计。
3.1 查询改写：把口语化问题翻译成检索友好的表达
用户提问往往和文档表述存在“词汇鸿沟”。用户说“刚开的公司”，文档里写“新设企业”；用户说“被罚过还能申请吗”，文档里写“近三年存在行政处罚记录的不予受理”。直接用原问题去检索，向量模型可能会在某些词上产生偏移。
一个低成本高收益的做法是加一个查询改写模块：先用大模型把用户问题改写成两个版本，一个偏“关键词提取”，一个偏“语义泛化”。比如原问题“去年注册的公司能不能申请扶持资金”，改写后得到：
- 关键词版：新设企业 申请 扶持资金 条件 成立时间
- 语义版：哪些企业符合申请条件，成立未满一年是否有资格申报
然后这两个改写后的查询分别进入混合检索链路，召回结果合并去重。实测下来，这个操作能把关键条款的召回率提升几个百分点。代价是多一次LLM调用，如果并发量高，可以用小模型或缓存处理高频问题。
3.2 多跳检索：沿着条款引用关系追下去
政策文本中交叉引用是常态，主条款只说“按下条规定执行”，真正的核心信息在另一条。单轮检索很难应对这种情况，因为检索系统并不知道“第八条”的内容是什么，需要主动解析引用关系。
我的做法是在检索返回结果之后加一个“引用追踪”步骤：用正则或小模型从已经召回的Block中提取所有“第X条”形式的引用，将这些引用编号作为新查询去知识库里定向检索，取回对应的条款内容，再合并进上下文。这个过程可以迭代一到两轮，但要注意控制轮次，防止上下文爆炸。
举一个实际案例。某项目扶持办法的奖励标准条款写了“固定资产投资奖励按本细则第十一条执行”，而第十一条是关于“补贴基数和比例的详细说明”。单轮检索如果只命中了奖励标准那条，回答里会缺失具体的补贴比例，用户拿到的是不完整的信息。加上引用追踪后，系统自动追查第十一条，回答的完整度就正常了。引用追踪这一步其实就是把人的阅读习惯搬给机器：人看到“按第X条执行”会往后翻，机器也该这样。
3.3 候选验证：让模型先列“答题所需清单”再检查
这是我认为最有效的一个补救措施，也是在几次项目里拯救过效果的关键手段。原理很简单：在拼接好检索上下文后，不是直接让模型回答问题，而是让它先做两步推理。
第一步：基于用户问题，列出回答这个问题“可能需要的关键信息点清单”。比如用户问“我们公司能申请这个补贴吗”，模型需要列出“适用对象”“硬性申报条件”“负面清单/不予受理情形”“所需材料”等若干信息维度。
第二步：逐项检查当前上下文里是否包含每个维度的信息。如果某个维度的信息缺失，就触发补充检索，针对缺失维度生成补充查询再去检索一轮。两轮之后如果仍然缺失，允许模型在回答中明确标注“该部分需进一步核实”。
这个“候选—验证—补检”的流程相当于在回答之前加了一道质量关卡，把“检索给什么就答什么”的被动模式，变成了“按逻辑检查盲区”的主动模式。实现成本主要在提示词设计上，几乎不需要额外的系统架构，但收益非常直接。我在一次政策问答评测里的数据是：加入验证机制后，关键点覆盖率从70%左右提升到了接近85%。
3.4 输出约束：提示词里强制“先条件后结论”
最后一个关键点不在检索链路，而在生成链路。政策问答和普通问答最大的区别是，政策回答的结论依赖于前置条件的逐项比对，不能直接跳结论。所以提示词里必须做硬性约束。
我常用的提示词规则是：要求模型先逐条列出用户情况与政策条件之间的对应关系，明确指出哪些条件满足、哪些不满足、哪些无法确认，最后再给出结论。同时要求模型在信息不足时明确表示“根据现有材料无法判断”，而不是强行给出一个貌似合理的回答。另外还要加上一条防幻觉约束：模型只能基于提供的政策条款回答，不得引用未提供的其他政策文件。
这一步不能省。否则即使检索把关键点都找齐了，模型依然可能因为摘要习惯或推理偏差而漏掉某个例外条款的表述。生成阶段的规则约束，和检索阶段的链路优化是配套的，少了哪一个都会出现“找得到但说不好”的问题。
4. 实操案例：一个政策问答系统的改进实录
前面把原理拆得差不多了，这里分享一个模拟项目的完整改造过程。这个项目是“某市产业扶持资金政策问答系统”，知识源是一份约2万字的实施细则，共六章四十条。用户咨询类型主要是“我的企业情况是否符合申请条件”“补贴标准是多少”“申报材料需要哪些”。
4.1 建立评测集：没有评测集，一切优化都是自我感觉
动手改系统前做的第一件事，是建立一套针对性的评测集。我从业务方收集了过去半年内最常见的30个真实咨询问题，逐一人工标注了“完整回答每个问题必须覆盖的关键点”。比如“公司成立未满一年能否申请”，标注的关键点是“支持对象为企业法人”“申报条件包含成立满三年”“成立未满一年属于不符合条件”。每个问题标注2到5个关键点，总计标注了约90个关键点。
评测指标用两个：关键点覆盖率（模型回答中命中的关键点数/标注关键点总数）和准确性（回答中事实性错误的数量）。关键点覆盖率是政策问答场景最核心的指标，比“回答是否流畅”重要得多。我见过很多系统演示时回答得很溜，一查关键点覆盖率只有60%，这种系统上线就是在给用户挖坑。
4.2 基线结果与逐级改造的效果对比
基线方案采用通用做法：固定1000字窗口切片、向量检索Top5、直接把上下文交给大模型。在这个评测集上的结果是：关键点覆盖率约58%，30个问题里有7个出现了直接误导性结论，比如把“不予补贴”的情形说成可以申请。
第一轮改造：把切片策略从固定窗口改成按条款切分，同时切片附带章节编号和条款编号元信息。仅这一步，关键点覆盖率提升到了约69%。原因很简单，按条切分后，“适用对象”和“不予受理情形”被保留在同一个语义单元里，检索命中一个就能连带拿到另一个。
第二轮改造：加入BM25关键词召回和RRF融合，召回Top50再重排序取前6。这一步把覆盖率提升到了约78%。发挥作用的场景主要是用户提到“成立不满一年”“有处罚记录”这类与文档词汇不一致的表述，向量单独召回容易漏，关键词语义互补后就能捞回来。
第三轮改造：加入引用追踪和候选验证流程。覆盖率从78%提升到了约86%，误导性结论从7个减少到2个。引用追踪解决了“按第X条执行”导致的信息断层；候选验证则兜住了那些“模型以为答完了、但其实漏了一个关键维度”的情况。
第四轮优化：调整提示词规则，强制模型“先逐条比对条件再给结论、信息不足时如实说明”。这一步没有再显著提升覆盖率，但把误导性结论从2个降到了接近0。至此，这套系统的关键点覆盖率稳定在86%左右，已经具备上线条件。
4.3 参数配置参考
整套系统里比较关键的一组参数配置如下，供参考：
- 切片方式：按“条”切分，条款过长时在“款”层级二次切分，块内保留章节、条款编号元信息；
- 块长度控制：单个条款切片不超过1200字，超出部分按“款”拆开，并留100字重叠窗口；
- 召回策略：向量检索Top50，BM25检索Top50，RRF融合后再取Top50作为重排输入；
- 重排序：交叉编码器Rerank模型，取前6，得分阈值0.35，低于阈值的丢弃；
- 上下文组织：命中块 + 同章前序块 + 引用条款块，总长度控制在4000字以内；
- 验证补检：最多两轮，第二轮补检仍未覆盖的信息维度，在回答中标注“需进一步确认”。
需要强调一点：这些参数是“手感值”，不是“标准值”。不同的政策文档、不同的问题类型，最优参数会有差异，但大致的调整方向可以复用。
4.4 实现要点：一个补充检索的代码骨架
补充检索是整个链路里最有“工程感”的一部分，我用伪代码梳理一下思路：
def verify_and_complete(question, context_blocks, retriever, llm): # 第一步：让模型基于当前上下文列回答所需信息维度 check_list = llm.extract_info_needs(question, context_blocks) final_blocks = context_blocks.copy() for need in check_list: # 第二步：检查当前上下文是否覆盖该维度 covered = llm.check_coverage(need, question, final_blocks) if not covered: # 第三步：针对缺失维度补充检索 sub_query = llm.generate_sub_query(need, question) extra_blocks = retriever.search(sub_query, top_k=5) final_blocks.extend(extra_blocks) # 第四步：限制上下文总长度 final_blocks = deduplicate_and_truncate(final_blocks, max_len=4000) answer = llm.answer_with_constraints(question, final_blocks) return answer这个流程看起来简单，但每一步都需要仔细打磨提示词。尤其是“检查是否覆盖”，模型容易偷懒，必须要求它“如果缺少具体数值、条件或例外条款，必须判定为未覆盖”。项目里最费时间的不是写代码，而是调试这些提示词的边界情况。
4.5 上线后的监控与持续优化
系统上线只是第一步，后续的监控优化同样重要。我在每次检索时都会记录检索候选、重排序得分、最终进入上下文的块ID，以及用户的反馈（有帮助/无帮助）。每隔一段时间，就把“无帮助”的问答样本捞出来，对比用户问题和检索日志，看看模型没答好是因为检索没召回，还是召回了但模型没用对。
这种日志化的监控方式价值很大。多数RAG系统的优化瓶颈根本不在参数，而在“不知道错在哪”。有了日志，你可以快速判断：是切片切碎了？是向量没召回？是重排序把关键内容排掉了？是提示词让模型忽略了例外条款？定位准确后再做针对性的调整，比盲目换模型、调TopK有效得多。
5. 常见问题与排查技巧实录
最后整理一份高频问题速查表，都是实际项目里反复出现过的场景。如果你也在做政策或制度类文档的RAG，大概率能在这里找到你正在头疼的问题。
| 常见症状 | 可能原因 | 对应解法 |
|---|---|---|
| 用户问“能不能申请”，回答只讲了条件符合，漏了例外情形 | 切片切碎了负面清单；或检索阶段没召回“不予受理”条款 | 改按条款切分；检查“不予”“除外”“不得”条款是否进入候选 |
| 用户说“刚成立一年”，系统没匹配到“成立满三年” | 用户表述与文档词汇差异大，纯向量召回命中不了 | 增加BM25关键词检索；增加查询改写模块 |
| 回答涉及“按第X条执行”时内容缺失 | 没有做交叉引用追踪 | 增加引用条款定向检索逻辑 |
| 模型回答流畅但关键条款一条都没提 | 重排序把真正相关的条款排掉了 | 检查重排序阈值；检查候选集里是否根本没有关键条款 |
| 多文档场景下引用了错误文件的内容 | 检索没有限定文档范围，跨文档相似内容互相干扰 | 增加文档级过滤元数据，先定位文档再定位条款 |
| 部分问题需要“不予补贴”结论，模型不敢下 | 提示词里缺少约束条件逐项比对的指令 | 调整提示词，强制“先条件后结论” |
| 系统刚上线效果好，一周后效果变差 | 知识库或文档有更新，旧索引缓存过期 | 检查索引是否重建，建立文档版本管理 |
5.1 关于“负面条款”的补充排查
政策文档里“不予”“不得”“除外”这三类词值得单拎出来说。我统计过自己的数据，政策问答中一半以上的误导性回答，都源于模型看到了支持条款、没看到限制条款。排查时可以直接在检索日志里过滤包含“不予”“不得”的块，看它们有多少比例进入了最终上下文。如果这些块几乎从不进入上下文，说明切片、召回或重排序的某个环节在系统性排斥它们。
一个有效的补救是：在切片阶段，把包含负面关键词的块打上“约束条款”标签，在检索融合阶段对带此标签的块做加权，保证负面条款至少有一两条进入候选集。
5.2 关于“格式、表格和政策附件”
政策文档经常包含表格、流程图和附件，这类内容在纯文本解析时很容易被忽略或破坏。补贴标准表、申请材料清单、审核流程图，以表格呈现时信息结构非常紧凑，一旦在切片时被截断，检索效果会急剧下降。针对这类内容，建议单独走一条“表格解析”管线，将表格转为Markdown或JSON结构化数据后再切片建索引。表格的检索模式通常不太一样，用户会问“补贴比例是多少”“需要哪些材料”，这种查询用关键词或列头匹配效果比向量检索更好。
5.3 关于“先建评测集还是先改系统”的争论
我个人强烈建议先花时间建评测集再动系统。没有评测集的RAG优化，本质上就是凭感觉调参，很难判断某一项改动是真的变好了，还是只是运气好。政策文档场景尤其如此，因为它的正确性判断标准很硬：关键点有没有覆盖，结论对不对。搭建一套20到30个问题的评测集，标注关键点，一两天就能完成，带来的收益却贯穿整个项目周期。每改一处，跑一遍评测，看覆盖率数字的变化，优化方向就会非常清晰。
5.4 一个容易被忽视的细节：回答中的“置信度表达”
政策问题不是所有情况都能用规则直接判定，很多咨询场景里用户提供的信息不完整，比如只说了公司成立时间、没有提供是否有处罚记录的信息。这种情况下，回答里必须明确区分“已满足的条件”“未确认的条件”“不满足的条件”。我见过一些模型为了迎合用户，把“未确认”偷换成“默认满足”，这是政策问答里最危险的行为。提示词里加一条硬约束：未提供的信息一律标注“需进一步核实”，宁可看起来保守，不能看起来错误。
这个内容后续还可以扩展的方向，一个是把政策问答从一个文件扩展到多级政策体系（上位政策、实施办法、申报指南），解决跨文档的条款冲突与引用关联；另一个是引入结构化知识库，将政策关键点抽取成“条件—规则—结论”的三元组，做规则引擎兜底检索。但现阶段能把单文档的关键点覆盖率做到85%以上，系统就比大多数通用RAG方案可靠得多了。我自己在几次项目中的体会是：政策文档RAG的成败，七成在检索和数据结构设计，三成在生成策略，模型本身的强弱反而没有想象中那么关键。先花力气把切片、召回、验证这几个环节做扎实，远比换个更贵的模型值得。
