四道防线：为「错一个数字都可能致命」的场景造一个宁可拒答、绝不编造的 RAG

今年上半年，我为某大型民航货运航司的 A330 货机机队做了一套飞行手册问答系统。痛点很具体：飞行员和机务要查一条放行条件或一个程序，得在 19 本手册、一万八千多页 PDF 里人工翻页。自然的想法是丢给大模型，但客户不敢用——通用大模型会编。编一个速度限制、编一条放行条件、编一个不存在的步骤，在别的行业是体验问题，在航空运行里是安全问题。

客户的要求可以压缩成一句话：宁可答不上来，也不能编。这篇文章是这套系统的工程复盘：四道防幻觉防线怎么搭、切分为什么比模型重要、评测怎么设计，以及一路踩过的坑。

为什么通用大模型在这里直接不可用

三个原因，缺一不可地把「直接调大模型」堵死了：

• LLM 的默认倾向是「尽量给出有帮助的回答」，不知道就用相近知识补全。这与手册问答的要求正好相反——手册没写的，答案就是「没有」。
• 手册问答的每个答案都有唯一出处。用户要的不是一段听起来对的话，而是「FCOM 第几页写了什么」，答案必须可追溯、可核对。模型内置知识给不了页码。
• 就算做了 RAG，检索不到时模型依然会拿语义相近的内容凑。凑出来的答案往往最像真的——这是比「不会答」危险得多的失败模式。

所以这个系统的设计目标不是「答对率最高」，而是把编造率 = 0 当作硬约束，在这条约束下尽量多答、答好。

单点可靠性是不存在的：检索会漏，阈值会误伤，模型会飘。与其指望某一层做到完美，不如搭四道相互独立的防线，每一道只负责接住上一道漏掉的。

用户提问
  ↓ ① Hybrid 检索：向量 + FTS5 关键词 → RRF 融合
  ↓ ② 复合拒答守卫：该拒的直接短路，不调 LLM
  ↓ ③ 生成层：严格 prompt + 低温 + 自拒多采样投票
  ↓ ④ 引用后处理校验：编造引用 → 整体重写为拒答
带页码引用的答案 ／ 明确拒答

第一道：Hybrid 检索，让对的内容先出现在候选里

向量检索（bge-m3，1024 维，存 sqlite-vec）负责语义相似。但手册问答里大量 query 是章节号、程序名、缩写——「MEL 32-42-09 是什么」这种三段式条目号，向量模型几乎无感。所以并行一路 SQLite FTS5 关键词检索，分词用 jieba 加航空缩写白名单：MEL、QRH、V1、CAT II 这些词整 token 保留，不许切碎。

两路各取 top 12，RRF 融合（k=60，向量路权重 1.0，关键词路 0.7）；只有关键词路命中的候选要过 core-token gate，防止碰瓷式匹配。融合后 top 8 进 LLM 上下文。

选型上没有用重型向量库：sqlite-vec + FTS5，整个知识库就是一个 SQLite 文件，检索全路径 100–200ms，私有化部署等于拷一个文件。对「数据不出内网」的 B 端场景，这比性能参数更有说服力。

第二道：复合拒答守卫，不调 LLM

防幻觉最可靠的一层，是不给模型开口的机会。检索结束后，一组守卫直接短路：

• off-domain 机型 guard：知识库只有 A330 的主资料，B737、B777 的问题直接拒；
• 相似度复合阈值：top1 向量相似度低于 0.50 拒答，高于 0.55 放行；灰区 [0.50, 0.55) 额外要求 query 含航空术语且 top1 命中该词才放行；
• 历史／事件类 intent guard：「上次出事故是什么时候」——手册里没有历史事件，拒。

守卫触发时完全不调 LLM，150ms 内返回明确拒答。附带的好处是所有该拒的请求零 token 成本，而这类请求在对抗场景下占比不低。

第三道：生成层禁编造，加一套自拒投票

放行到 LLM 的请求，用严格 system prompt 加 0.1 的低温约束：只能使用提供的资料，每个论断标注 [n] 引用编号，资料没有就明说没有。

严格约束带来一个反向问题：模型变得过分保守。检索明明给足了相关片段，它还是回「资料不足」——线上自拒率约 4–8%。解法是多采样投票：检测到自拒且检索充分时，并行两路重采样，选择器只接受「非自拒且带引用」的实质回答，两路全拒才走兜底拒答。安全阀不放松：重试指令里明确写着，若资料确实无关，保持拒答。

这里有个调试时的关键发现。最初的重试把首次拒答放进对话历史传回去，结果两路必定全拒——模型被自己的拒答锚定了。改成不携带失败历史的干净重采样后，单路成功率实测约 50%，两路联合把残余自拒率压到平方级。一致性偏差在这种「希望模型改主意」的场景里是敌人，不是朋友。

第四道：引用后处理校验

生成完成后，后处理逐一校验引用编号：如果答案里出现了越界引用——比如只给了 8 条检索结果，答案却引用了 [9]——说明模型在编造依据，整个回答直接重写为拒答。

前三道防的是「不该答的答了」，这一道防的是「答了，但依据是编的」。它是纯确定性代码，不依赖任何模型判断，所以是四道防线里最硬的兜底。

防线搭完，客户给了一个差评

四道防线保证的是不编造，不保证答得好。系统上线后，客户反馈了一条真实差评：问「如何使用 MEL」，系统答出来的是 MEL 手册的章节目录。

没编造、带引用、每条可溯源——但对一个想知道操作流程的人来说，是废话。用诊断脚本把全链路决策拉出来看，问题不在检索也不在模型，在切分：当时用的是 800 字滑窗加 150 字重叠，把手册当成均匀的字符流。可手册不是字符流，它有天然的语义原子——MEL 的一个放行条目、QRH 的一个完整程序、FCOM 的一个文档单元。滑窗恰好把「如何使用 MEL」的说明部分切到了目录附近的片段里，检索命中的全是目录。

顺着这个案例把数据层整个审计了一遍，挖出一个更大的问题：46.5% 的知识切片含重复页眉文本。每一页都印着手册名、机队标识、修订日期，滑窗把这些噪声均匀混进切片——于是任何提到「手册」的问题跟几乎所有页面都「相似」，之前一批查不出原因的伪命中全是它。

治理分两步。先治数据：在 PDF 解析层写了 34 条确定性的「零信息整行」删除模式，只删无信息量的重复行，正文和章节标题零损失。知识库体积从 278MB 降到 122MB，19 本手册全量重建索引 348 秒。有个意外收获：老系统一直拒答「如何修理咖啡机」，我原以为这是正确行为，去噪后才发现 MEL 里真有咖啡机的放行条目——噪声不仅制造伪命中，还会把真实可答的内容压制到检索不到。

再治结构。动手前先全量扫描 19 本手册验证前提，实测 96.5% 的页面量存在可靠结构锚点：FCOM/FCTM/QRH/MEL 有文档单元识别行，MEL/CDL 有三段式条目号，SOP 有小节号。按锚点切出 13,569 个父块（完整的条目、程序、小节），父块内部再切出 28,141 个不超过 600 字的子块，全库约 4.2 万个知识块。子块负责检索精度，命中后把完整父块交给 LLM——程序步骤、放行条件、表格从此不再碎片化。剩下 3.5% 没有锚点的小册子自动回退滑窗，不硬套。

最后叠一层 Contextual Retrieval（Anthropic 2024 年提出的方案）：入库时让 LLM 为每个子块生成一句不超过 60 字的定位说明——它属于哪本手册哪个章节、在讲什么——前置到向量化文本里，解决「片段脱离上下文语义不完整」的问题。这里有条不可让步的安全红线：LLM 生成的说明只参与检索相似度计算，永远不进入引用和答案依据链。否则就是亲手把幻觉写进索引。

重构后再问「如何使用 MEL」，答出来的是实操流程：设备失效后先做什么、如何记录、适用于哪个阶段。同一个问题，从「章节目录」到「操作流程」，中间隔着的不是更大的模型，而是切分单位与手册结构的对齐。

你说零编造，拿什么证明

自动生成的模板题测不出编造——模板题问的都是库里有的东西。所以我自建了一套对抗性评测：50 道题、10 个攻击维度，每道题都是设计来诱使系统犯错的：

另外四个维度是多跳组合、数值精确、章节号、模糊短词。结果：50 题 100% 通过，全程零编造。几个有代表性的行为：错误前提题，系统先纠正「A330 并非四发而是双发」，再引用双发相关条款；prompt 注入直接拒答；库里没有的内容，回「知识库仅包含手册已写明的程序与限制」。

比分数更重要的是判分纪律，两条：

第一，每条失败样本人工核对后才准下结论。有一轮 7 条「失败」里 5 条是判分脚本误伤——系统做了教科书级的正确行为（纠正错误前提、诚实的部分回答），被子串匹配判成失败。不核对就去调参，等于对着噪声做优化。

第二，同题同模型才有可比性。知识库一变，评测抽题会漂移；模型一换，分数整体平移。所有版本对比锁定同一份题目和同一个模型。这条原则救过我一次：一个「疑似回归」经差分实测证伪，避免了一次错误回滚。

最终成绩（同题同模型严格对比）：对抗评测 50 题 100% 零编造；综合评测 90% 提到 92.5%；结构专项——程序完整性、数值查询、深条目直达——从 70% 提到 90%。从 V1 基线到 V4，四代升级的评测与上线在一天内完成。

踩过的坑

挑几个值得写下来的：

• 后处理误杀部分回答。拒答检测最早用子串匹配，结果模型最有价值的回答形式——「未找到完整程序，但资料包含以下步骤 [5]……」——因为开头半句触发关键词，被整体丢弃改写成兜底文案。修复方案：含拒答词但同时给出超过 150 字带引用实质内容的，判定为部分回答放行。这个 bug 是拿原始 LLM 输出逐条比对定位的，修完之后两代系统的对抗评测同时到了 100%——此前的失分一半是它贡献的。
• 中文词盲区。灰区放行门最早只认英文航空缩写，「复飞」这种中文单词查询被稳定误拒。教训：防线每加一道，误伤面就多一分，每条守卫都需要配套的词表维护成本，这个成本在设计时就要算进去。
• reranker 的纪律。交叉编码器重排（bge-reranker-v2-m3）早就实现了，但默认关闭。开启条件写死成清单：真实失败样本中排序问题占比过半、PoC 实测命中率提升不少于 10% 且延迟 P95 增加不超过 1.5 秒、全套回归评测不退步、客户明确同意。四条同时满足才开。不让「看起来高级」的组件变成默认开销。
• 一次线上事故。升级中途 LLM 服务商账号余额耗尽，线上问答中断。因为 API 层做了兼容抽象，零代码改动切到备用兼容端点，10 分钟内恢复。教训写进了 runbook：余额也是可用性的一部分。

还有必须诚实交代的差距：距离满分剩余的 2–4% 来自生成层残余抖动——多采样把自拒率压到平方级，但不是零；个别数值表格类问题需要表格结构化解析才能根治。这些都记录在案，不假装已经解决。

现在的状态

系统已上线，真实客户对接中，处于验收阶段。这套「结构感知切分 + 父子两级索引 + 多层拒答守卫 + 对抗性评测」的方法论不只属于航空：船舶、铁路、医疗设备这类高结构化技术手册，只要场景要求「答案必须带原文出处、宁可拒答不可编造」，整条流水线都能复用。

我把方法论抽成了一个开源骨架（已脱敏，不含任何客户数据）：strict-rag。文中的四道防线、切分策略和对抗评测设计，仓库里都有对应实现。有问题欢迎邮件交流。