大模型让"问答系统"的门槛骤降——一句 prompt 加一个知识库，似乎就能跑起来。但真正在企业里落地的领域问答系统，要解决的远不止"问一句答一句"。它要能识别用户到底想问什么，要在多轮对话里维护上下文，要在知识不足时坦诚拒答，还要能被量化评测和持续迭代。本文按 mrgr.cn AI 组的真实项目，复盘一个领域问答系统的搭建全流程。

一、先分清：问答系统的三种形态

不是所有"问答"都是同一回事。动手前先对齐形态，否则方向跑偏。

• FAQ 问答：问什么就匹配标准问题，返回预设答案。适合高频、封闭场景，准确率高但覆盖窄。
• 知识库问答（KBQA/RAG）：从知识库检索相关片段，让模型基于片段生成答案。覆盖广，是当下主流。
• 推理型问答：需要多步推理、计算、跨文档关联才能作答，难度最高，准确率最难保证。

本文聚焦第二种——基于 RAG 的领域知识问答。它平衡了覆盖度与准确率，是企业落地性价比最高的形态。但它不是"接个向量库"那么简单，而是一条含意图识别、改写、检索、合成、评测的完整链路。

二、知识库构建：问答系统的地基

问答系统的上限由知识库质量决定。垃圾进、垃圾出，再强的模型也救不回糟糕的知识库。知识库构建要解决三件事：知识从哪来、怎么结构化、怎么保鲜。

2.1 知识来源与清洗

• 来源：产品手册、内部 wiki、历史工单、FAQ、API 文档。
• 清洗：去重、去噪、统一格式、敏感信息脱敏。
• 结构化：尽量保留标题层级，让切分能沿语义边界走，而非粗暴按字数切。

2.2 知识的"问法扩展"

光有标准答案不够，还要为每条知识补充"用户可能怎么问"。对一条知识生成多个问法变体，既可用于检索增强（让检索更鲁棒），也可作为评测集。用大模型批量生成问法，再人工筛，是高效做法。

# 用大模型为一条知识生成问法变体
prompt = f"""基于以下知识，生成 5 个用户可能提出的不同问法，
要求表达方式多样、口语化、覆盖不同提问角度。

【知识】{chunk_text}

输出 JSON 数组，每项一个问法。"""

三、意图识别：先听懂用户想问什么

用户输入往往是模糊、口语化、甚至带错别字的。"我要退订"和"怎么取消订单"是同一意图，"退款多久到账"是另一个意图。意图识别决定后续走哪条检索路径、用哪个知识库、套哪个回复模板。

• 意图分类：把用户 query 分到预定义意图（如售前咨询、售后退订、使用帮助、闲聊）。
• 槽位抽取：从 query 里抽取关键参数（订单号、产品名、时间范围），用于精确检索或接口调用。
• 兜底意图：识别不出意图时，走通用 RAG 或转人工，避免硬答。

小规模意图用小模型或规则即可；意图多、边界模糊时，用大模型做 few-shot 分类效果更稳。关键是意图体系要"MECE"（互斥且穷尽），否则分类会摇摆。

四、多轮改写：把对话历史压缩进 query

多轮对话里，用户当前 query 常依赖上下文。"那它支持吗"——"它"指什么？必须结合历史把当前 query 改写成可独立检索的完整 query，再去检索，否则检索召回率会塌掉。

# 多轮 query 改写
history = [
    ("用户", "你们有 markdown 编辑器吗？"),
    ("助手", "有的，我们的编辑器支持 markdown。"),
]
current = "那它支持表格吗？"

rewrite_prompt = f"""根据对话历史，把用户当前问题改写为可独立理解的完整问题。
只输出改写后的问题，不要解释。

【历史】{history}
【当前问题】{current}
【改写后】"""

# 期望输出：你们编辑器的 markdown 支持表格吗？

多轮改写是问答系统从"单轮 demo"走向"可用产品"的分水岭。mrgr.cn 的实测显示，引入 query 改写后，多轮场景的检索召回率提升约 25%，"答非所问"的比例显著下降。

五、检索与答案合成

改写后的 query 进入检索。这里复用 RAG 的标准链路：混合检索（向量 + BM25）→ RRF 融合 → Rerank 精排 → 取 Top-K 片段送入生成。生成阶段的关键是答案合成的可控性：要求模型基于片段作答、标注引用、不确定时拒答。

5.1 答案合成的工程要点

• 引用追溯：答案每条论断后标注来源片段编号，前端可点击核查。
• 拒答策略：检索分数都低或片段无关时，明确回复"未在知识库找到"，不强行编造。
• 结构化输出：需要列表/步骤时，要求模型按固定格式输出，便于前端渲染。
• 安全兜底：对涉及交易、金额、政策的答案，加规则校验或人工审核。

六、评测：让问答质量可量化

没有评测的问答系统就是黑盒。上线前必须构建评测集、定义指标、做回归测试。mrgr.cn AI 组把评测分成"检索层"与"生成层"两部分，分别定位问题。

• 检索层：Recall@K（正确片段是否在 Top-K）、MRR（正确片段排名）、命中率。
• 生成层：答案准确率（人工或 LLM-as-Judge）、引用准确性、拒答合理性。
• 端到端：用户满意度（点踩率）、解决率、转人工率。

# LLM-as-Judge：让大模型给答案打分
judge_prompt = f"""你是一个严格的评测员。请判断【答案】是否正确回答了【问题】，
且仅基于【参考资料】。输出 JSON：{{"correct": bool, "reason": "..."}}。

【问题】{question}
【参考资料】{references}
【答案】{answer}"""

评测集要随业务迭代持续扩充——把线上真实问法、bad case 沉淀进评测集，每次模型或知识库调整后回归，确保不退步。这是问答系统长期可维护的根本。

七、上线与持续运营

• 灰度发布：先小流量验证，监控 bad case，再逐步放量。
• 反馈闭环：每条答案配"有用/无用"按钮，差评进 bad case 池。
• 知识库保鲜：定期同步业务变更，下线过期知识，避免误导。
• 转人工：低置信度、敏感意图自动转人工，兜底体验。
• 监控：召回分数分布、拒答率、响应耗时、转人工率告警。

问答系统不是"上线即完成"，而是"上线即开始运营"。真正决定它好不好用的，不是上线时的模型，而是上线后持续吸收 bad case、迭代知识库与 prompt 的运营节奏。把反馈闭环跑通，比换更强的模型更重要。

结语

从零搭建一个领域问答系统，远不止"接大模型"——知识库是地基，意图识别是耳朵，多轮改写是记忆，检索与合成是大脑，评测是镜子。mrgr.cn AI 组在这个项目里最大的体会是：决定成败的往往不是模型多强，而是知识库多干净、反馈闭环多顺畅、评测多严格。把这几件事做扎实，再普通的模型也能答得靠谱。欢迎在问答社区交流你的问答系统落地经验。