13.3 问答服务模块

问答服务模块是 RAG 系统中直接面向用户的交互层，负责接收问题、调度检索与生成环节、封装响应。它把底层的检索、提示构建、模型调用串联成一个完整的业务闭环，同时对客户端屏蔽内部复杂度。简单来说，没有这个模块，前面的所有准备（知识库、索引、检索策略）都只是散落的零件。

13.3.1 模块的核心职责

一个好的问答服务模块需要完成以下几项明确的工作：

请求接入与校验：接收用户 query，进行基础的清洗（去除无意义空白、截断超长输入），必要时判断 query 是否合法（如是否包含违规词、是否为空）。
上下文构建：调用检索模块获取相关文档片段，按照预设的提示模板将 {context} 和 {query} 组装成完整的 prompt。此步骤还可以加入历史对话记录、用户身份标签等额外信息。
模型调用与流控：将组装好的 prompt 发送给生成模型（本地部署或 API），管理超时、重试、并发度，确保服务稳定。
后处理与引用注入：对模型返回的原始回答进行清洗（去除多余的助手标记），并依据检索阶段保存的 source 元数据，将引用标注（如“来源：《员工手册》第3页”）附在回答末尾或内嵌在文本中。
日志与监控：记录每次问答的完整链路——用户问题、检索到的片段 ID、模型回答、耗时等，以便后续质量评估和问题排查。

13.3.2 接口设计参考

在实际工程中，问答服务通常暴露为 RESTful API 或 WebSocket 接口。一个典型的同步请求设计如下：

请求体（JSON）示例：

{
  "query": "年假如何折算成薪资？",
  "top_k": 5,
  "score_threshold": 0.6,
  "return_sources": true
}

query：必填，用户输入的问题。
top_k：本次检索返回的最大片段数，可由前端调节。
score_threshold：相关性阈值，低于此分数的片段不进入上下文，防止引入噪音。
return_sources：是否在响应中包含引用来源，默认开启。

响应体示例：

{
  "answer": "根据《福利政策》第 2.3 条，未休年假可按日工资的 250% 折算为薪酬。",
  "sources": [
    {
      "doc_name": "福利政策_v2025.pdf",
      "chunk_id": "chunk_037",
      "page": 4,
      "text_snippet": "未休年假的折算标准为日工资的250%..."
    }
  ],
  "processing_time_ms": 820
}

对于需要流式输出的场景，可采用 Server-Sent Events（SSE）逐 token 推送生成内容，引用来源可在流结束后的最后一条事件中统一给出。

13.3.3 关键实现细节

以下是几个在落地中容易被忽略但影响体验的要点：

智能空回答处理：当检索模块返回空结果，或所有片段的相关性分数都低于阈值时，不应将空 context 送入 LLM 任其“自由发挥”。此时应直接返回预设的兜底话术，例如：“抱歉，我目前的知识库中暂时没有找到相关信息，建议您联系人工客服。”并在日志中标记为无检索结果。

引用格式统一：在提示词中明确要求模型在回答中标记引用位置（例如 [1] 或 【来源1】），然后后处理阶段将占位符替换为可读的来源说明或超链接。这样做既能保持回答文本的整洁，又能保证溯源的真实性。

历史对话的管理：如果支持多轮对话，模块需要维护会话上下文。通常做法是将用户最近几轮问答作为 history 追加到 prompt 中，但需注意不要让 history 膨胀过大导致 prompt 超长。可以设定最大轮数（如保留最近 3 轮），或对历史进行摘要。

安全与权限控制：对于企业内部系统，同一个知识库中的不同文档可能对应不同权限。问答服务模块应当在检索阶段就对片段进行权限过滤，确保用户只能看到自己被授权访问的内容。这一步最好在检索时完成，而不是在生成后掩盖，因为上下文中的内容仍可能被模型“透露”。

13.3.4 与前后端系统的解耦

为了维护性和可扩展性，问答服务模块应通过标准化的内部协议与检索组件、模型组件通信。例如：

检索组件接口：接受 query 和参数，返回 List<Document>，每个 Document 包含文本、元数据和相关性分数。
模型组件接口：接受 prompt 和生成参数，返回生成的 text 或流。这样本地模型、云端 API 可以无缝切换。

通过这种分层，检索策略的优化（如切换嵌入模型、调整切块大小）或模型版本的升级都不会破坏问答服务本身的稳定性。

13.3.5 运维与可靠性建议

设置合理的超时：检索阶段通常应在毫秒级完成，生成时间取决于模型。总请求超时可设置为 15-30 秒，避免用户长时间等待。
流量高峰时的降级策略：当并发超过阈值，可启用轻量级 fallback 模型，或直接返回“系统繁忙，请稍后重试”，保证核心链路不被打垮。
答案质量监控：定期抽样问答日志，人工评估回答的准确性、完整性和引用正确性，形成质量报表，驱动系统持续改进。

问答服务模块的定位是 RAG 系统中的“调度中枢”，它本身不产生知识，也不做复杂推理，而是精准、高效地串联起检索和生成两大核心能力，为最终用户提供流畅、可信的回答体验。