政策问答系统实战：RAG架构与工程避坑

问题所在：政策文件在技术上公开，实际上难以阅读

公共部门发布大量政策信息——福利标准、申请条件、资格规则。这些信息在技术上都能在网上找到。但如果你不是专业人士，几乎没有一项是容易实际使用的。一个人只想知道"我能领多少"或"我需要准备什么材料"，结果得到的却是一份 30 页的政策文件，写给办事员看的，不是给普通市民看的。

结果可想而知：人们打热线电话去问一个早已在网上发布过答案的问题，或者干脆放弃、凭感觉猜。在我从事大型文档密集型数字化服务的过程中，我不断看到这个鸿沟——不是信息缺乏，而是缺乏一种真正能提问的方式。

所以我构建了 policy-qa-system——一个开源的 RAG（检索增强生成）聊天机器人，让人们可以用日常语言向公共政策提问，并获得基于实际源文档、有引用可查的回答。不是那种泛化的聊天机器人在瞎猜政策——而是一个只回答它真正被投喂过的文档内容的系统。

解决方案：检索、阅读、回答、引用

当有人提问时，系统会：

在已索引的政策文档库中搜索最相关的段落

将相关段落与问题一起提供给模型阅读

用通俗语言生成回答，而不是政策套话

精确标注来源，使回答可以被核查，而不只是被信任

最后这一步是大多数聊天机器人项目跳过的，也是这里最关键的一步。关于福利资格或申请条件的回答，只有在有人能够核实的情况下才有价值。因此每条回复都附有来源参考，而且系统被设计成在找不到相关内容时说"我不确定"，而不是瞎猜。

一个通俗语言的示例

问题："两个孩子每周能领多少？"

For 2 children: first child gets the standard rate, second child
gets the additional-child rate (combined weekly and yearly totals
shown together). An income-based charge may apply above a set
household income threshold.

Source: Official rates document, section on child payments

具体数字取决于加载哪个国家的政策文件——系统本身不绑定任何单一国家的规则。这是一套公民问答的模式，不是一个固定的数据集。

这里也没有用到什么 exotic 技术。真正运行这个系统的团队，只需要把自己的官方政策文档替换掉示例文档集，其余所有部分——检索、引用、通俗语言生成——都保持不变。

 User question
      │
      ▼
 React UI ──► Express API
      │
      ▼
 LangChain retrieval ──► PostgreSQL + pgvector (indexed policy docs)
      │
      ▼
 LLM answer generation (grounded in retrieved sections)
      │
      ▼
 Answer + citation + confidence score

置信度分数与回答本身同样重要。如果检索步骤没有找到与问题足够接近的内容，系统会被设计成直接告知用户，而不是让 LLM 用一个听起来合理但实际上是瞎编的答案来填补空白。

代码解读（有用的部分）

每条回答都必须附带来源，而不只是自由生成：

const response = await chain.invoke({
  question,
  context: retrievedChunks,
});

return {
  answer: response.answer,
  sources: retrievedChunks.map(c => ({
    document: c.metadata.document,
    section: c.metadata.section,
  })),
  confidence: response.confidence,
};

置信度阈值决定是回答还是说"未找到"：

if (topMatchScore < CONFIDENCE_THRESHOLD) {
  return {
    answer: "I couldn't find a reliable answer to that in the indexed documents.",
    sources: [],
  };
}

这一处检查在代码量上很小，但它是聊天机器人是否值得信任的分水岭——前者人们可以信任，后者只是听起来很有信心。

把引用变成每条回答的必选项而不是可选项，从一开始就倒逼了更好的检索质量——一旦你必须展示答案来自哪里，模糊的检索结果就立刻暴露了。

置信度阈值，即使是一个很简单的版本，也大幅减少了那种听起来很自信但实际上是错的回答。感觉像是一个小添加，却是对信任度影响最大的改动之一。

保持文档集可替换，意味着理论上同一套系统只需要重新索引不同的文档集，就能适用于完全不同的政策领域。

真正困难的地方

**在不丢失准确性的前提下翻译成通俗语言。**政策文件的精确性是有原因的——简化措辞但不遗漏重要条件（收入门槛、资格规则）需要真正用心，而且我认为这个问题还没有完全解决。

**决定什么时候说"我不知道"。**置信度阈值设得太低，系统就会回答它不该回答的问题；设得太高，系统又会拒绝它本来能好好回答的问题。最后我是对着一个小型的真实问题测试集手工调参的。

这是一个起点，不是一个成品、可以直接部署的系统。它需要一个真正的文档摄入管道、对示例回答的持续审查，以及在真实用户使用前针对边界情况进行充分测试。我会把它当作一个坚实的 base 来继续构建，而不是一个开箱即用的发布工具。

这在更大的图景中处于什么位置

这是我正在构建的一系列开源 AI 项目中的一个——文档问答 RAG 系统、AI 代码审查 agent、语音转敏捷用户故事工具。这些项目的共同点是：在真实的工作流问题上使用 LLM 编排（LangChain/LangGraph），并且强烈偏向于可核查的回答，而不是听起来正确的回答。

仓库是开源的，本地快速试用：

git clone https://github.com/Srameshgitnow/policy-qa-system.git
cd policy-qa-system
npm install
npm run dev

完整的安装步骤、环境变量以及如何加载自己的文档，都在 README 中。

如果你试用了，发现引用逻辑中有漏洞，或者对置信度阈值有想法，我很愿意听你说说——issues 和 pull requests 都开放。如果这个项目对你有用，在 repo 上点个 ⭐ 能帮助其他人发现它：

👉 github.com/Srameshgitnow/policy-qa-system

我是一名全栈/AI 工程师（React、Node.js、LangChain/LangGraph），有大规模数字化交付的背景。我写关于应用 AI 工程和开源工具的文章——关注我，获取这个系列的下一篇文章。