夜雨聆风用户的问题明明都搜到相关文档了，系统却给不出答案。我们把这个问题当成一个项目来拆，每一步都能直接落地。
用户在系统里问了一句话，在北京分公司工作满一年的员工，母亲住院需要陪护，能不能申请护理假？
系统搜出来三篇文档，员工休假制度、北京分公司福利细则、劳动合同管理办法。单看每一篇都和问题有关，但没有一篇直接写答案。
如果直接让模型总结，它大概率会给你编一个看着很合理的结论。
说真的，这种问题做检索增强生成的人迟早会碰到。
我们换一个做法，把这个问题当成一个项目来拆。下面每一步都写清楚我们要做什么、具体怎么做、怎么算做完。你去跑一遍就知道问题卡在哪。
先记住整条链路
拆条件 → 改查询 → 对证据 → 查推理 → 判能不能答 → 给三种回答 → 写日志 → 回知识库。
🔍 第一步 拆问题，先列条件
我们要做什么
用户问题进来以后，先不检索。先把问题拆成一张条件清单，每个条件都要能在问题原文里找到出处。
举个例子，用户问「在北京分公司工作满一年的员工，母亲住院需要陪护，能不能申请护理假？」
我们至少拆出这些条件
员工在职且工作满一年 亲属关系是母亲 场景是住院陪护 假期类型是护理假 适用北京规定还是合同约定 需要什么证明材料
具体怎么做
让模型输出结构化字段，每条条件必须带上问题原文。找不到原文就重新拆。
提示词可以这样写
请把用户问题拆成条件清单。每条条件包含条件名、问题原文、是否关键。只使用问题里出现的信息，不要补充业务假设，不要给最终结论。
怎么算做完
同一个问题拆两遍，结果要一致。业务方看过以后，确认没有漏掉关键条件。
🔁 第二步 改查询，别只拿原问题去搜
我们要做什么
原问题太长，直接检索容易漏。我们给关键条件分别生成查询，再补两三个组合查询。
比如可以生成
员工工作满一年怎么界定 母亲住院能不能申请护理假 北京分公司护理假标准 劳动合同有没有约定护理假天数
具体怎么做
把所有查询结果合并，去掉重复片段，再按条件归堆。一个条件对不上证据，就标缺失，不硬凑。
怎么算做完
每个关键条件都有候选证据，或者被明确标成缺失。检索结果里没有明显重复。
🧩 第三步 对证据，做一张覆盖表
我们要做什么
把候选证据逐条贴到条件上，给每个条件标状态
直接命中，文档里有明确句子 间接可推，需要组合推理 缺失，没有任何证据 冲突，文档之间说法不一致
护理假的例子可以标成这样
在职员工，直接命中，证据是员工休假制度 直系亲属患病可申请，直接命中，证据是员工休假制度 母亲属于直系亲属，间接可推，要看当地定义 北京地区护理假标准，缺失 劳动合同特殊约定，缺失
具体怎么做
每条证据都要有来源和编号。后面引用必须写编号，不能只说系统查到。状态不能留空。
怎么算做完
每个条件都有状态和依据。缺失清单可以直接交给知识库的人。
⚖️ 第四步 查推理链，不许拼结论
我们要做什么
需要多段证据组合的结论，先校验，再生成。
具体顺序
列出候选结论 列出支持结论的证据 让校验模型判断够不够 不够就记下缺失前提
护理假的例子
员工休假制度说「直系亲属患病可申请陪护假」。
北京分公司福利细则说「护理假标准按当地规定执行」。
劳动合同管理办法说「具体假期以劳动合同约定为准」。
这三句凑不出「母亲住院能申请、能休几天」。
缺的是两个前提。一个是北京规定有没有把父母算进直系亲属，一个是劳动合同有没有写护理假天数。
提示词可以这样写
基于以下证据，判断结论是否成立。只使用证据内容，不要补充常识。推不出来就列出缺失前提和证据编号。输出判定结果，分成成立、不成立、部分成立。
具体怎么做
判定结果不是成立，就不能当确定结论。每次校验都要留记录，写清楚结论、证据编号、判定结果、缺失前提。
怎么算做完
不存在判定成立但证据链是空的记录。每个多跳结论都能查到校验过程。
✅ 第五步 判能不能答，用规则
我们要做什么
把覆盖表和校验结果合到一起，按规则走
关键条件全部直接命中，直接回答 有关键条件缺失，澄清或拒答 条件冲突，先消解，消解不了就说明分歧 只能间接推，回答里写需要确认
具体怎么做
判定结果要可解释，能说清为什么能答、为什么不能答。建议用规则实现，不靠模型感觉。
怎么算做完
同一个问题跑三遍，结果一致。缺失条件列表和覆盖表一致。
💬 第六步 回答、澄清、拒答
我们要做什么
根据判定结果走三个出口
直接回答，给确定结论和引用 需要确认，给可推断信息，标出待确认条件 澄清或拒答，说明缺什么，请用户提供材料，不编答案
护理假的例子可以这样回
根据现有制度，直系亲属患病可以申请陪护假。当前没有检索到北京护理假是否覆盖父母、具体天数，也没有查到劳动合同的特殊约定。需要先核对当地规定和合同条款，才能确认能不能申请、能休几天。
具体怎么做
生成模型只能照着判定结果写话。确定结论后面必须挂证据编号。出现「应该可以」「大概」这类词，就归到需要确认。
怎么算做完
每条确定结论都有证据编号。缺失条件不会在回答里被悄悄补上。
📋 第七步 写日志，回知识库
我们要做什么
每个问题存一条记录，包含问题、条件清单、证据覆盖表、判定结果、缺失条件、最终回答、用户反馈、人工复核。
定期做两件事
把「相关但不可答」单独归档 把缺失条件汇总成补录工单
具体怎么做
每条不可答样本都要能说清缺哪块证据。工单里写清楚缺什么规则，比如缺身份规则、缺地区规则、缺合同条款、缺适用关系。
怎么算做完
每周至少有一份缺失汇总。每条不可答样本都有缺失条件，不允许为空。
📊 第八步 上线前评估
我们要做什么
建三类测试集
可直接回答 相关但不可答 可间接回答但需要确认
每类几十条真实问题，上线前后各跑一遍。
重点看四个数
判定准确率，判定结果和人工结论一不一样 缺失条件命中率，系统列的缺失有没有覆盖人工列的 引用准确率，确定结论有没有挂对证据 不编造率，不可答的问题有没有被正确拒掉或降级
具体怎么做
把「相关但不可答」单独标出来，不要和普通成功样本混在一起。
怎么算做完
三类样本都有记录。上线后，「相关但不可答」没有被当成普通成功样本。
这套流程不用一次全上。
先把前四步跑通，再补日志和回写。
每一步都能单独验收，我们不用靠猜。
下次系统再遇到相关但不可答的问题，就知道自己是缺证据，而不是硬编一个答案。
反正我们现在做检索增强生成，第一件事不是把召回调得更准，而是先让系统学会说我不知道。
