一个面向化工企业异常工况处置场景的规程智能问答系统，从基线到生产可用的调优全过程记录。核心思路只有一句话：先建立可信的评测集，再坚持"单一变量、逐轮留档"的迭代纪律。
一、场景：这不是一个普通的知识库问答
这个项目服务于化工制造企业的异常工况处置场景：反应釜超温怎么办、某条管线检修按哪个版本的规程执行、新旧规程混用时以哪个为准。这类场景对问答系统的要求和普通企业知识库完全不同：
- 容错率极低：一个错误答案可能比不回答更危险，"胡说八道"在工业场景里就是事故隐患；
- 可追溯是刚需：答案必须标明出自哪份规程、哪个章节、哪个版本，方便操作人员核对原文；
- 规程版本频繁更新：版本管理混乱（新旧规程混用）本身就是这个行业的痛点，知识库必须跟上版本迭代的节奏；
- 响应窗口短：异常工况处置分秒必争，系统不能"想一下再说"。
因此我们给自己定了一个核心优化目标：忠实度（Faithfulness）——答案中的每一个论断，都必须能在检索到的规程原文中找到依据。最终在生产评测集上，我们把 RAGAS 忠实度从基线 0.85 提升到 0.95，端到端 P95 响应时间压到 3.1 秒，SSE 流式首 Token 延迟小于 0.9 秒。
下面是完整过程。
二、第一步：先建评测集，再谈优化
很多 RAG 项目调优效果差，根因不在技术选型，而在没有建立可信的评测闭环就盲目改参数。我们的原则是：没有评测集，不许动任何检索/生成参数。
评测集怎么来
我们基于真实业务问题构建评测集，来源有三个：
- 一线操作人员和管理人员的真实提问记录（脱敏后）；
- 梳理异常工况处置的高频场景，人工构造的问题；
- 针对已知"老大难"问题（口语化提问、国标编号精确查询、跨文档综合问题）刻意设计的对抗样本。
每条评测样本包含：问题、标准答案要点、该问题命中的规程文档及段落（ground truth）。这个 ground truth 是后续计算 Context Recall 等指标的基础，标注质量直接决定评测是否可信——这部分我们投入了相当多的人工核对时间。
用 RAGAS 做端到端指标
我们跟踪四个核心指标：
| 指标 | 含义 | 我们的关注点 |
|---|---|---|
| Context Precision | 检索回来的内容里，有用的占比 | 排序质量，喂给 LLM 的上下文是否"干净" |
| Context Recall | 正确内容是否被检索回来 | 召回完整性，这是忠实度的上游 |
| Faithfulness | 答案是否有检索依据，无幻觉 | 我们的北极星指标 |
| Response Relevancy | 答案是否切题 | 兜底指标，防止答非所问 |
关键纪律：单一变量原则。 每一轮迭代只改一个环节（切片策略、召回方式、重排策略、Prompt 等），跑完整套评测集，把结果完整留档。哪一轮变好、哪一轮变差、变差的具体是哪些样本，全部可追溯。RAG 链路环节太多，不这么约束，很容易出现"改了三处、整体变好但说不清是哪一处起作用、下次不知道往哪走"的混乱局面。
三、基线系统：先把链路跑通
基线系统的完整链路：
多格式规程文档 → MinerU 解析清洗 → 切分向量化(BGE-M3) → Milvus 向量库
↓
用户提问 → 向量召回 Top-K → LLM 生成(Qwen) → 返回答案
技术选型说明：
- MinerU：规程文档是 PDF、Word、扫描图片混杂，且大量表格、编号条款。MinerU 在多格式解析、尤其是表格和版式还原上的表现，是整条链路的起点——解析错了，后面全错；
- BGE-M3：稠密向量 + 支持多语言、长短文本，工业术语的表征效果不错；
- Qwen 系列：中文工业语料表现稳定，配合阿里云部署在企业内网落地。
基线跑完：Faithfulness 0.85。乍看还行，但在工业场景意味着每 20 个答案里就有 1 个查无实据——不可接受。诊断发现主要问题集中在三类：
- 召回缺漏：口语化提问（"超温了怎么处理" vs 规程原文"反应器温度异常升高处置程序"）和国标编号精确查询（"GB XXXXX 第 X 条"）这两类问题，纯向量召回效果差；
- 排序不准：Top-K 里混入了相关但不精确的段落，LLM 被干扰；
- 生成失控：部分问题即使检索正确，LLM 仍会"自由发挥"补充常识性内容。
这三个问题正好对应三个优化方向：召回 → 重排 → 生成约束。
四、第一轮：混合检索 + RRF，解决"查不到"
纯向量召回对口语化提问表现尚可，但对国标编号、规程条款号这类精确匹配天然乏力；反过来 BM25 关键词检索恰好擅长这个，但对语义改写能力为零。两者融合是业界验证过的标准解法。
具体做法
- 稠密检索：BGE-M3 向量召回，语义覆盖；
- 稀疏检索：BM25，覆盖编号、条款号、专业术语精确匹配；
- RRF（Reciprocal Rank Fusion）融合：多路召回结果按排名倒数加权融合，不需要校准两路的分数量纲，实现简单且稳定。
单一变量验证后：Context Recall 明显提升，尤其是编号类问题，之前漏检的样本基本被 BM25 路补齐。但 Faithfulness 的提升有限——因为召回变多之后，噪声也变多了。
五、第二轮：两阶段重排 + 阈值过滤，解决"排不对"
召回环节解决"查得到"，接下来要解决"排得准"。我们引入两阶段检索：
Milvus 混合召回 Top-K(较大, 如 50) → bge-reranker-Large 精排 → 取 Top-N(较小, 如 5~8) 送入 LLM
粗召回求"全"，精排求"准"。Reranker 基于交叉编码器（Cross-Encoder）对"问题-文档"对做精细相关性打分，排序质量远好于双塔向量。
关键细节：Rerank 阈值过滤
精排之后，我们没有直接把 Top-N 全部送进生成，而是加了一个相关性阈值过滤——分数低于阈值的段落直接丢弃。这一步对忠实度的提升超出预期，原因很直接：被丢弃的边缘相关段落，正是诱导 LLM 幻觉的主要来源。宁可少给上下文，不给脏上下文。
这一轮下来，Faithfulness 从 0.85 提升到 0.93。Context Precision 同步改善，验证了"排序质量是忠实度上游"的判断。
六、第三轮：生成层防护，解决"管不住"
即使检索和排序都做到位，LLM 本身仍是概率模型，约束必须加到生成层。我们设计了三层防护机制：
1. Prompt 强约束
系统 Prompt 中明确规则：
- 仅依据给定的规程片段作答，片段中没有的信息明确回答"规程中未找到相关依据"；
- 每个论断后必须标注引用来源（文档名 + 章节/条款号 + 版本号）；
- 多个片段内容冲突时，不得自行裁决，必须并列呈现并提示人工确认。
2. 置信门控 + 兜底转人工
对检索结果质量和生成过程做置信度评估，低置信问题不硬答，直接转人工。在工业场景，"我不知道，请找值班工程师"永远比"我觉得可能是……"正确。这条机制上线后，产线使用方的信任度明显提升——大家知道系统不会不懂装懂。
3. 审计层
所有问答留痕：问题、检索片段、生成答案、引用来源、置信度评分、用户反馈。既满足工业合规的可审计要求，也为我们持续构造评测样本提供了真实语料来源——评测集不是一次性的，而是随系统运行不断生长的。
成果
第三轮之后，Faithfulness 最终稳定在 0.95。剩下的约 5% 的失分样本，逐个人工归因后确认：大部分是 ground truth 标注边界问题或确实超出规程覆盖范围的提问，属于系统能力边界内的合理损耗。
七、容易被忽略的两件事
1. 知识库的"保鲜"能力
规程版本迭代频繁，如果每次更新都要全量重建索引，检索服务就得中断，这在生产环境不可接受。我们做了两件事：
- 增量索引：文件更新采用"先删后增"策略，只重建受影响文档的索引，检索服务全程不中断；
- 三级 UID 设计："文件-文档-块名"三级唯一标识，从根上解决删除文件后向量库残留"孤儿块"的问题（这个问题在调试期真实出现过：已废止的旧版规程内容被召回，答案引用了失效版本，极其隐蔽且危险）。
2. 高频问题的缓存层
基于 Redis 搭建 FAQ 缓存，高频问题直接返回缓存答案，不重复调用大模型。收益不仅是降低模型调用开销，更重要的是高频问题的响应延迟从秒级降到毫秒级——处置人员问同一个问题的第三次，应该快得飞起。
八、复盘：这次调优真正做对的三件事
- 先评测、后优化，全程单一变量、逐轮留档。 RAG 调优最怕"凭感觉改参数"，没有评测闭环的优化都是玄学。评测集质量决定一切，我们在 ground truth 标注上的投入，比任何单次算法调整都值钱。
- 顺着链路逐环节归因，不跳跃。 召回（查不到）→ 重排（排不准）→ 生成（管不住），每个环节的优化都建立在上一环节评测数据的基础上，Faithfulness 的每一次提升都可解释、可复现。
- 把"不回答"设计进系统。 置信门控 + 转人工 + 拒答机制，在容错率低的场景里，系统的可信度比系统的"聪明程度"重要得多。0.95 的忠实度 + 明确的兜底策略，比 0.97 的忠实度 + 沉默的自信，在生产环境更有价值。
九、后续方向
- Query Rewriting：对口语化、多轮指代的问题做改写后再检索，目前这类问题仍有一定失分；
- 多模态规程：现场照片、流程图的规程内容纳入解析链路；
- 评测集自动化生长：结合审计层的用户反馈数据，把评测集的构建从"人工驱动"升级为"半自动驱动"。
文中指标均为固定评测集下的 RAGAS 评测结果，具体业务数据已脱敏。如果你的场景也在做工业/合规类 RAG，欢迎在评论区交流。
