首页 / 文章 / 利用LangChain与LangGraph构建面向生产场景的人力资源政策检索系统

利用LangChain与LangGraph构建面向生产场景的人力资源政策检索系统

用于人力资源政策助手的文本摄取、MMR技术、基于历史记录的重写功能、有依据的回答、约束机制、评估系统、引用功能以及图表编排功能。

1510 词

本文将详细介绍数据摄取、MMR检索、基于历史记录的查询、安全检查、评估钩子以及多轮对话用户体验等相关内容。

引言

对于企业人力资源领域而言,仅仅具备流畅的生成式回答能力是不够的。政策助手绝不能凭预训练数据自行制定休假规则,而应检索已批准的文档,并将所有主张都基于这些来源进行支撑。这正是检索增强生成(RAG)技术的作用所在。

一个模块化、面向实际应用的人力资源政策问答系统可整合 Python、LangChain、LangGraph、兼容 OpenAI 的聊天模型、ChromaDB、Streamlit、嵌入技术、MMR 检索机制、基于历史记录的查询重写功能、提示词设计、输入内容审核、提示词注入检测、检索结果评估、对话记忆功能、摘要生成以及 PDF 导出功能。其目标并非打造一个演示用聊天机器人,而是一个高度重视检索质量、对话上下文、安全性、评估标准及易用性的 RAG 系统。

1. 问题所在

当有人询问“允许请多少天病假?”时,普通的大型语言模型可能会编造答案。而人力资源助手则应:

  1. 理解问题含义
  2. 搜索企业内部的人力资源相关文档
  3. 找出最相关的部分
  4. 将这些部分传递给模型
  5. 基于这些内容生成答案
  • 请注明来源,以便员工核实。
  • 整体流程:HR文档 → 数据导入 → 分块处理及添加元数据 → 生成嵌入向量 → 存入ChromaDB → 使用检索工具 → 执行考虑历史记录的查询 → 获取相关文档 → 生成有依据的提示语 → 输出答案 → 注明引用来源。

    2. 文档导入

    原始政策文件会被拆分为可检索的片段。完整文档体积过大,无法全部纳入每个提示语中,否则会超出上下文限制。这些片段会携带文件名、路径、文件夹、文档类型以及来源标签等元数据,便于日后引用、调试及查看检索结果。

    3. 嵌入向量与向量存储

    每个片段都会被转换为一个嵌入向量:

    "Employees receive annual leave..."
                 ↓
           Embedding Model
                 ↓
          [0.12, -0.43, 0.87, ...]
    

    这些向量及元数据会被存储在ChromaDB中。用户问题也会以相同方式被转换为嵌入向量,这样即使表述不同(如“因病请假”与“病假权利”),语义相近的政策也能被准确检索出来。

    4. 使用MMR进行检索

    简单的top-k相似度算法可能会返回四个近乎重复的休假政策相关内容:

    Chunk 1 → Leave policy
    Chunk 2 → Leave policy
    Chunk 3 → Leave policy
    Chunk 4 → Leave policy
    

    最大边际相关性算法在相关性与多样性之间取得平衡。通过扩大fetch_k值以增加候选项数量,再利用MMR算法筛选出最终的k个结果,可以有效减少冗余内容:

    10,000 chunks
          ↓
    Similarity search
          ↓
    20 candidate chunks
          ↓
    MMR
          ↓
    4 diverse + relevant chunks
          ↓
    LLM
    

    5. 考虑历史记录的检索

    在得到年度休假相关答案后,若紧接着询问“那管理者呢?”,这样的问题本身含义模糊。通过考虑历史记录的步骤,可以在检索前根据对话历史重新构建查询语句:

    Conversation History
            +
    Current Question
            ↓
           LLM
            ↓
    Standalone Search Query
    

    这样就能将查询上下文理解(用户到底想表达什么?)与答案生成(根据文档应给出怎样的回复?)区分开来。

    6. 基于事实的答案生成

    检索到的内容会被用于生成提示词,告知模型仅使用人力资源相关文档、避免编造政策内容、明确列出排除项、保持简洁,并承认存在的不足。整体架构为:问题提出 → 背景信息补充 → 内容检索 → 文档获取 → 质量检查提示词生成 → 大语言模型处理 → 基于事实的答案输出。模型负责撰写文本,而语料库则提供事实依据。

    7. 为何选择 LangGraph

    随着流程环节的增多——验证、内容审核、注入检测、查询处理、检索、生成、记忆管理、总结等——线性结构会变得脆弱。LangGraph 将工作流程建模为状态与节点:

                    User Input
                        ↓
                   Validation
                        ↓
                  Guardrails
                    ↙     ↘
              Safe          Unsafe
               ↓               ↓
           RAG Workflow      Reject
               ↓
          Final Response
               ↓
           Conversation
            Management
    

    这种图结构比单一的巨型函数更易于扩展。

    8. 规则约束

    在应用 RAG 技术之前,需要对生产输入进行检查:

    • 内容审核——尽早拦截违反政策的内容
    • 提示词注入检测——拒绝“忽略之前的指令”之类的攻击手段

    顺序很重要:用户输入 → 安全检查 → RAG,而非用户输入直接进入原始大语言模型。

    9. 对话记忆与摘要生成

    多轮对话助手需要历史记录,但无限制的转录会消耗大量计算资源。对早期对话进行摘要可以在控制当前上下文量的同时保留关键信息——这是保存内容与成本之间的权衡。

    10. 检索评估

    即使检索失败,答案也可能看起来很流畅。应衡量是否有正确的段落被获取,而不仅仅是文本是否返回。需将检索质量、基于检索的生成内容以及应用行为作为独立层面进行评估。

    11. 来源引用

    相比空泛的陈述,最好采用“员工可享受20天年假(休假政策第3条)”这样的表述。当员工能够查看原始PDF时,引用能提升信任度、便于调试并实现追溯。

    12. PDF对话导出

    将对话导出为PDF格式,可使员工保留记录以供日后查阅。这一用户体验细节表明该系统是专为实际工作设计的,而非临时使用的聊天工具。

    总结

    一个具备生产级功能的HR RAG助手包含数据摄取、检索策略、对话重写、背景信息补充、图结构编排、约束规则设定、性能评估以及引用功能等环节。LangChain与LangGraph有助于整合这些流程;Chroma和MMR则决定模型能够访问的内容范围。不可动摇的产品原则是:所有答案都必须来自经过审批的文档,而非模型对互联网内容的记忆。

    实际应用中重要的设计考量

    分块大小与重叠度并非无关紧要的细节。过大的分块会削弱嵌入信号;过小的分块则会失去周围的策略约束。当规则跨越边界时,重叠度有助于处理这种情况。元数据并非可有可无的装饰——没有文件名和章节提示,引用就会变得模糊不清,评估集也难以判断。

    MMR参数(fetch_k、k、多样性lambda值)应基于带标签的问题集进行调整,而非凭直觉决定。候选池过小则无法获取多样化的段落;过大则会浪费处理时间。

    具备历史意识的重写系统绝不能编造事实。重写步骤应仅将代词及不完整的后续内容扩展为独立的搜索查询。如果重写模型开始直接作答,检索系统就永远无法得到清晰的查询语句。

    在检索之前就应设置防护机制。在模型已经看到隐私政策文本之后才进行的审核和注入检测为时已晚。一旦怀疑存在注入行为就应直接判定失败;只有当产品政策明确允许通过记录日志进行软性拦截时,才可允许继续处理。

    评估时应同时考量检索效果(预期文档ID的召回率@k)和生成质量(与检索到的文本的一致性)。即便答案表述优美但依据了错误的条款,仍属于失败。需保存相关痕迹:重写的查询语句、检索到的ID、最终答案以及引用列表。

    Streamlit(或任何轻量级用户界面)都应清晰展示引用信息及“未知”状态。相比那些编造宽松休假政策的系统,员工更信任那些能够承认自身缺陷的系统。

    导出为PDF是一项保留功能:人们会将政策相关答案粘贴到工单中。应将导出的文本视为潜在敏感信息,并采用与聊天会话相同的访问控制措施。

    最后,要确保图表中的标准流程一目了然。新工程师应能够直接看到“验证→重写→检索→生成→响应”这一流程,而无需在各种可选分支中摸索。那些可选分支(如摘要生成、数据导出)应连接到明确的节点上,而非嵌套在生成流程内部。

    这样的设计能让周末完成的RAG演示变成HR团队可以放心试用的工具,无需担心会出现无依据的政策错误。

    将各要素按时间顺序排列

                        HR DOCUMENTS
                             │
                             ▼
                    DOCUMENT INGESTION
                             │
                    Chunking + Metadata
                             │
                             ▼
                        EMBEDDINGS
                             │
                             ▼
                         CHROMADB
                             │
                             ▼
                        RETRIEVER
                        (MMR Search)
                             │
                             │
    USER ──→ GUARDRAILS ─────┤
                             │
                             ▼
                  HISTORY-AWARE QUERY
                      CONTEXTUALIZATION
                             │
                             ▼
                        RETRIEVAL
                             │
                             ▼
                    RELEVANT DOCUMENTS
                             │
                             ▼
                      QA PROMPT + LLM
                             │
                             ▼
                      GROUNDED ANSWER
                             │
                        ┌────┴────┐
                        ↓         ↓
                    Citations   Memory
                                  │
                                  ▼
                             Summarization
                                  │
                                  ▼
                             PDF Export
    

    第一阶段通常仅涉及“嵌入PDF文档和聊天功能”。从第二阶段到第十阶段,系统才真正展现出其实用价值:包括元数据架构设计、MMR参数调优、后续重写提示机制、内容审核接口、注入攻击识别器、评估表格、引用格式规范以及对话摘要功能。如果跳过这些步骤,系统在常规问题上表现良好,但在二次交互、对抗性提示或近似重复内容检索时就会失效。

    LangChain有助于连接模型与检索组件;LangGraph则能让控制流程更易于查看。但二者都无法替代关于哪些人力资源相关文件夹具有权威性、谁可以查询哪些政策,以及界面中“未知内容”应如何呈现等产品决策。这些决策应当与图表一起记录在设计文档中。

    当生产环境出现故障时,最快的调试路径通常是:检查重新编写的查询语句,列出获取的块编号,读取这些块,然后再读取对应的提示词。如果日志中缺少这些信息,在添加新模型之前先解决可观测性问题。