1. 项目背景
某公司法务部门在内部部署了一套 RAG 制度问答助手，首批上线了《劳动合同管理办法》《员工考勤制度》《差旅报销规定》等 15 份制度文档。系统运行一周后，业务同事的反馈邮件接踵而至。
HR 小王在群里直接发问："我问’试用期最长多久’，系统回答’一般不超过六个月’，但这是《劳动合同法》的规定还是我们公司自己的规定？回答里一个字都没提来源文件，我哪敢直接用？"财务部的小陈更焦虑：“我问差旅住宿标准，系统第一次说 500 元/晚，第二次说 450 元/晚，第三次又变成 600 元/晚——三次查出来三个答案，这让我怎么报销？”
更麻烦的是，当答案明显有误时，开发团队完全无力排查——日志里只看到一个模糊的问题和一个最终回答，中间环节到底是检索时漏了关键文档，还是 LLM 合成时自由发挥了，毫无线索。法务总监用一句话总结了困境：“一段没有出处的法律意见书，你敢提交给仲裁庭吗？”
痛点一：答案无引用来源 → 用户无法验证可信度 → 幻觉和脑补不可控 痛点二：回答不稳定 → 相同检索结果每次合成不同 → 缺乏一致性 痛点三：调试不可见 → 检索与合成黑盒 → 排障靠猜默认的index.as_query_engine()一行代码确实能跑通，但它就像一个只会背答案但从不标注出处的实习生——能力有，但不专业、不可信、不可控。本章将剖析 QueryEngine 从检索到合成的完整链路，并实战构建一个每次回答都附带引用文件与条款号的制度问答助手。
2. 项目设计
场景：团队会议
