1. 项目概述当大语言模型遇上巴西劳动法最近在折腾一个挺有意思的项目起因是团队里负责海外业务的同事经常被巴西当地复杂的劳动法问题搞得焦头烂额。巴西的劳动法规体系Consolidação das Leis do Trabalho, CLT以详尽和复杂著称条款多如牛毛还经常有地方性补充规定。直接去问ChatGPT或Claude这类通用大模型得到的回答要么过于笼统要么就是“根据巴西法律…”缺乏具体的条款引用和上下文依据根本不敢拿来用。于是我们就想能不能用现在火热的LLM智能体Agents技术构建一个专门针对巴西劳动法的问答系统不是简单地把法规文档扔给一个模型而是让多个各司其职的智能体协同工作像一支专业的法律顾问团队一样来确保回答的准确性、相关性和可追溯性。这就是“HR-Agents”项目的核心想法利用基于大语言模型的多智能体系统来提升关于巴西劳动法问答的质量和可靠性。这个项目本质上是一个智能体驱动的检索增强生成Agentic RAG应用。它超越了传统的“检索-生成”两步走RAG通过引入具有不同角色的智能体如调度员、检索专家、验证员、合成员让整个问答流程变得更加可控、可解释并且能处理更复杂的多步推理任务。对于HR、法务或者任何需要处理巴西雇佣关系的人来说这样一个工具的价值在于它能提供一个比简单搜索更智能、比咨询律师更快捷的“第一道防线”尤其是在处理日常、高频的合规性问题时。2. 核心架构与智能体分工设计传统的RAG管道通常是一个线性流程用户提问 - 检索相关文档片段 - 将片段和问题一起交给LLM生成答案。这个流程简单有效但在面对专业、严谨的法律领域时就显得有些力不从心。问题可能不清晰检索可能不精准生成的答案可能“幻觉”出不存在的规定。HR-Agents的设计哲学是将这个线性流程“打散”赋予不同的子任务给专门的智能体形成一个协作网络。我们主要借鉴了CrewAI这类多智能体框架的思想但根据法律领域的特殊性进行了定制。整个系统的核心由四个主要智能体构成它们通过一个中央调度器Orchestrator来协调。2.1 智能体角色定义与协作流程1. 问题分析与调度智能体 (Query Analyst Dispatcher)这是用户交互的第一站。它的任务不是直接回答问题而是充当“前台接待”和“项目经理”。职责意图识别与澄清分析用户的原始问题。例如用户问“员工休假怎么算”这个智能体会尝试与用户交互澄清是年假Férias、病假Licença Médica还是其他特定假期。问题分解与规划将复杂问题拆解成一系列子问题。比如“在圣保罗解雇一名有10年工龄的正式员工需要支付哪些费用”这个问题可以分解为解雇赔偿计算基数、工龄工资FGTS的罚金、未休假期折算、提前通知期等子问题。任务派发根据子问题的性质创建任务并分配给后续的检索智能体。它会为每个任务附上清晰的指令和上下文。技术实现要点这个智能体需要一个强大的LLM作为核心如GPT-4、Claude 3并配备精心设计的系统提示词System Prompt引导其进行逻辑分解和规划。提示词中会明确其角色、职责以及可用的工具即调用其他智能体的能力。2. 精准检索智能体 (Precision Retrieval Agent)这是系统的“图书管理员”和“研究员”。它的目标不是返回尽可能多的文档而是找到最相关、最权威的片段。职责多路召回与混合检索接收来自调度器的具体子问题。它不会只依赖一种检索方式。通常我们会部署密集向量检索使用如text-embedding-ada-002或开源模型如BGE、GTE将问题和法规文档库编码成向量进行语义相似度搜索。这是主体。关键词稀疏检索如BM25作为补充确保不遗漏那些包含关键术语如法律条款编号“Art. 7º”但表述方式不同的文档。元数据过滤根据问题中可能隐含的筛选条件如法规的生效日期、适用的州/城市进行过滤。相关性重排序将多路召回的结果混合后使用一个轻量级的“重排序模型”或直接让LLM对片段进行相关性打分和排序只保留Top-K个最相关的片段。技术实现要点这个智能体背后连接着向量数据库如Milvus, Pinecone, Weaviate和全文搜索引擎。它的提示词强调“精确性”和“引用来源”要求其返回的每个文档片段都必须带有出处如法规名称、条款号、章节。3. 事实核查与验证智能体 (Fact-Check Validation Agent)这是系统的“质检员”。法律回答容不得半点虚构这个智能体的存在就是为了最大限度地减少“幻觉”。职责一致性校验对比检索智能体返回的不同文档片段检查它们之间是否存在矛盾。例如关于加班费计算的两个片段是否表述一致。答案支撑性验证针对后续合成智能体生成的初步答案逐条核查其声称的事实是否都能在提供的检索片段中找到确切的依据。它会标记出哪些部分有强支撑哪些部分是模型的推断需要明确说明哪些部分缺乏依据。冲突解决当发现信息冲突时可能源于法规更新或不同解释它能根据预设的优先级规则如联邦法优先于州法新法优先于旧法进行判断或直接将冲突提交给调度器触发更复杂的处理流程如人工审核标记。技术实现要点这个智能体需要极强的逻辑推理和文本比对能力。我们通常使用能力最强的LLM来担任此角色。它的工作严重依赖于检索智能体提供的、带有清晰出处的源文本。4. 答案合成与格式化智能体 (Answer Synthesis Formatter)这是系统的“撰稿人”和“律师”负责生成最终面向用户的回答。职责信息整合与推理接收所有经过验证的子问题答案和相关文档片段。它的任务不是复述而是整合信息进行必要的法律推理形成一个连贯、完整、直接回答用户核心问题的叙述。结构化与可读性将答案组织成易于理解的结构。例如先给出结论摘要然后分点阐述法律依据、计算方式、例外情况等。引用标注在答案的每一处关键陈述后以脚注或括号的形式清晰标注所引用的具体法律条款如“依据CLT Art. 130…”确保答案的可追溯性。语气与免责声明采用专业、中立、谨慎的语气。自动在答案末尾附加免责声明提示此信息不构成正式法律意见建议在重要决策前咨询持证律师。技术实现要点这个智能体的提示词模板至关重要它定义了答案的格式、语气、引用规范和结构。我们通常会提供几个高质量的示例Few-shot Learning让模型学会我们想要的回答风格。注意智能体间的通信是异步且基于消息的。调度器是中枢它维护着整个对话的上下文并将任务和上下文传递给其他智能体。每个智能体完成任务后将结果返回给调度器由调度器决定下一步是继续派发新任务还是将结果传递给下一个智能体抑或是合成最终答案。2.2 工具与记忆模块设计每个智能体除了LLM核心都配备了一套“工具”和“记忆”模块。工具对检索智能体来说工具就是“搜索向量数据库”、“执行关键词查询”。对验证智能体来说工具可能是“比较两段文本”、“提取法律条款号”。工具以函数的形式封装智能体通过LLM决定在何时调用何种工具。记忆分为短期记忆本次对话的上下文和长期记忆。对于HR-Agents长期记忆尤为重要。我们可以为每个智能体设计特定的记忆调度器记忆用户的历史会话轮廓和问题偏好。检索器记忆高频检索的法规领域优化索引策略。验证器记忆历史上常见的“幻觉”模式或矛盾点提高校验效率。合成器记忆备受用户好评的答案格式和表述方式。3. 技术栈选型与核心模块实现构建这样一个多智能体系统技术选型需要平衡能力、成本、可控性和开发效率。以下是我们在HR-Agents项目中采用的核心技术栈及背后的考量。3.1 LLM选型核心引擎的权衡智能体的“大脑”是LLM。我们采用了分层和混合的策略调度与复杂推理智能体选用能力最强的闭源模型如GPT-4 Turbo或Claude 3 Opus。因为问题分解、规划、复杂验证需要最高的逻辑推理、上下文理解和指令遵循能力。这部分调用量相对较少但至关重要值得投入。检索与格式化智能体可以选用性价比更高的模型。例如检索中的重排序rerank可以使用专门的小模型如Cohere的rerank API或开源的BGE-reranker。答案合成可以选用Claude 3 Sonnet或GPT-3.5 Turbo它们在遵循格式指令和进行中等复杂度文本生成上表现足够好成本更低。开源模型备选为了数据隐私和成本控制我们也评估了本地部署的开源模型。例如使用Llama 3 70B或Qwen 2.5 72B作为调度和合成核心用MXBAI Embedding模型进行向量化。这需要强大的GPU基础设施但提供了完全的数据控制权。实操心得LLM API的稳定性与降级策略。在实际运行中必须为每个LLM调用设置重试、超时和降级机制。例如当GPT-4调用失败时自动降级到Claude 3 Sonnet如果所有主用API都不可用则触发本地开源模型的备用通道。这能显著提升系统的鲁棒性。3.2 智能体框架CrewAI vs 自研我们选择了CrewAI作为多智能体协作框架的起点而非完全从零自研。原因如下快速原型CrewAI提供了清晰的角色Agent、任务Task、流程Process抽象能让我们在几小时内搭建起智能体协作的基本骨架。它的after_llm_call等装饰器可以方便地注入日志、监控逻辑。流程内置它支持顺序sequential、分层hierarchical等协作流程与我们的设计匹配。灵活性虽然CrewAI提供了高级抽象但它并未完全封死底层。我们可以自定义每个智能体的工具、重写任务执行逻辑并将其集成到我们已有的系统中。当然CrewAI也有其局限例如对复杂自定义记忆管理的支持较弱异步处理大规模任务流时需要额外优化。对于生产级系统我们在其基础上进行了深度封装实现了更精细化的任务队列使用Celery或Redis Queue、智能体状态管理和跨会话记忆存储。3.3 知识库构建RAG的基石智能体再聪明也需要准确的知识来源。巴西劳动法知识库的构建是另一个重头戏其质量直接决定最终答案的上限。1. 文档获取与清洗来源巴西官方政府门户如www.planalto.gov.br发布的CLT全文及其修正案、各州/市的补充条例、官方劳工部Ministério do Trabalho的说明性文件、权威法律评论网站的解读文章需获得授权或标注来源。清洗使用Python的pdfplumber、pypdf解析PDF用BeautifulSoup抓取网页。清洗工作包括去除页眉页脚、水印、无关的广告和导航栏将全角字符统一为半角纠正明显的OCR错误识别并标准化法律引用格式如将“art. 7o”统一为“Art. 7º”。2. 文本切片策略法律文本结构严谨盲目按固定长度切片会割裂条款的完整性。我们采用混合切片策略语义切片优先按照文档的自然结构进行切分如“篇、章、节、条、款”。每个法律条款Artigo及其下的段落Parágrafo通常作为一个独立的语义单元。这是最理想的切片。递归切片对于较长的条款或说明性文章在语义切片的基础上使用递归字符文本分割器如LangChain的RecursiveCharacterTextSplitter设置较大的块大小如1000字符和较小的重叠区200字符确保上下文连贯。元数据附加为每一个切片附加丰富的元数据doc_id文档ID、article_number条款号、law_name法律名称、effective_date生效日期、jurisdiction管辖范围如联邦/圣保罗州等。这些元数据是后续精准过滤的关键。3. 向量化与索引嵌入模型我们测试了多种嵌入模型最终选择了在多语言法律文本上表现优异的text-embedding-3-large。对于纯葡萄牙语场景开源的jina-embeddings-v2和BGE-M3也是极佳的选择且可本地部署。向量数据库选用Milvus或Qdrant。它们支持高性能的稠密向量检索同时具备强大的元数据过滤能力。例如我们可以执行这样的查询“查找关于‘解雇赔偿’语义向量相似且适用于‘圣保罗州’元数据过滤且‘生效日期在2023年以后’元数据过滤的文档片段”。混合检索层在向量数据库之上我们构建了一个检索抽象层。当检索智能体被调用时该层会并行执行向量检索和基于Elasticsearch的关键词检索BM25然后通过重排序模型如BAAI/bge-reranker-large对合并结果进行排序返回最相关的3-5个片段。4. 系统集成与全流程实操演练下面我将以一个完整的用户问题处理流程为例串联起各个模块展示HR-Agents是如何工作的。我们假设用户提问“我公司在米纳斯吉拉斯州有一个正式员工月薪8000雷亚尔工龄3年。如果他主动辞职公司需要支付哪些法定款项”4.1 流程步骤拆解步骤一用户请求接入与调度用户通过Web界面或API发送问题。请求首先到达调度智能体。该智能体的LLMGPT-4分析问题识别出关键实体地点米纳斯吉拉斯州、雇员类型正式员工、薪资8000 BRL/月、工龄3年、离职类型主动辞职。调度智能体进行规划这是一个关于“主动辞职时公司义务”的查询可能涉及未付工资、工龄保障基金FGTS提取、假期折算等子问题。它创建以下任务任务A检索查找巴西CLT中关于员工主动辞职Pedido de Demissão时雇主法定义务的通用条款。任务B检索查找米纳斯吉拉斯州是否有关于此事项的特别地方规定。任务C检索查找关于工龄保障基金FGTS在主动辞职情况下的提取规则。任务D检索查找关于年假Férias和十三薪13º Salário在离职时的结算规则。调度器将这四个检索任务并行派发给精准检索智能体。步骤二并行检索与结果聚合精准检索智能体收到四个任务。对于每个任务它调用检索工具层。工具层执行混合检索。以任务A为例向量检索将“主动辞职 雇主 义务 CLT”的嵌入向量在Milvus中搜索。关键词检索在Elasticsearch中用“pedido de demissão obrigação empregador”进行搜索。元数据过滤限定法律类型为“联邦立法”。重排序将两组结果合并用重排序模型打分返回Top 3片段。例如可能返回CLT Art. 7º, Art. 143等关于离职结算的条款。四个检索任务各自返回结果集。调度器收集所有结果。步骤三答案草拟与初步验证调度器将原始问题和所有检索到的相关片段附带出处一起交给答案合成智能体使用Claude 3 Sonnet。合成智能体阅读这些片段开始起草答案。它可能会生成“根据CLT员工主动辞职时公司需结清截至离职日的未付工资、按比例支付的十三薪、以及折算未休年假。此外员工可以申请提取FGTS账户中的余额。米纳斯吉拉斯州无额外规定。”这份草稿连同其引用的源片段被提交给事实核查智能体使用GPT-4。核查智能体逐句检查“结清未付工资” - 在CLT Art. 7º中找到依据通过。“按比例支付十三薪” - 在CLT Art. 7º中找到依据通过。“折算未休年假” - 在CLT Art. 130中找到依据通过。“员工可提取FGTS” - 在Lei 8.036/90FGTS法中找到依据通过。“米纳斯吉拉斯州无额外规定” - 核查智能体发现检索结果中确实没有找到该州的特别规定但为了严谨它可能会建议添加一句“基于当前知识库未发现米纳斯吉拉斯州在此事项上的特别规定”。标记为“需注明限定条件”。步骤四最终合成与交付核查结果返回给调度器。调度器将带有验证标记的草稿和核查意见再次发回给答案合成智能体进行修订。合成智能体根据意见修订答案完善表述并结构化输出**针对您的问题米纳斯吉拉斯州月薪8000 BRL工龄3年主动辞职公司的法定支付义务如下** 1. **工资结算**支付从上一发薪日至离职日的全部未付工资。 * *依据CLT Art. 7º.* 2. **十三薪13º Salário按比例结算**支付该年度已工作月份的十三薪按比例部分。 * *计算示例(3/12) * 8000 BRL 2000 BRL。* * *依据CLT Art. 7º.* 3. **未休年假折算**支付全部已获得但未休的年假对应工资并附加1/3的假期补贴。 * *计算逻辑需根据员工具体的年假 accrual 情况计算。假设每年30天假期3年工龄且未休假则需折算90天工资 (90天工资 * 1/3)。* * *依据CLT Art. 130, Art. 7º.* 4. **其他可能款项**结清可能的加班费、佣金等。 **关于工龄保障基金FGTS**公司**无义务**在主动辞职情况下支付任何FGTS相关罚金。员工有权向FGTS基金管理机构申请提取其个人账户中的全部余额。 * *依据Lei 8.036/90.* **地方规定**基于当前知识库未发现米纳斯吉拉斯州对此情形有额外的强制性支付规定。 **重要提示**此计算仅为基于通用条款的估算。实际支付可能涉及个人所得税、社保扣除等具体细节。建议与公司财务或法律顾问最终确认。本回复不构成正式法律意见。最终答案通过API或界面返回给用户。4.2 系统监控与评估这样一个复杂系统必须要有完善的监控。性能指标记录每个智能体的响应时间、LLM的Token消耗、检索的召回率与准确率。质量评估自动评估针对一批有标准答案的测试问题使用RAGAS等框架评估答案的忠实度Faithfulness是否基于给定上下文、答案相关性Answer Relevance和上下文相关性Context Relevance。人工评估定期抽样由懂巴西劳动法的专家从准确性、完整性和清晰度三个维度打分。日志与追溯每一次问答的全链路日志都被保存包括每个智能体的输入、输出、调用的工具和检索的源片段。这为调试和优化提供了黄金数据。5. 挑战、优化与未来方向在实际开发和调优HR-Agents的过程中我们遇到了不少挑战也总结出一些关键的优化方向。5.1 核心挑战与应对策略1. 幻觉与事实准确性这是法律领域AI应用的生命线。多智能体架构本身特别是验证智能体是主要防线。此外我们还采取了以下措施提示词工程在所有智能体的系统提示词中反复强调“仅使用提供的信息”、“引用具体条款”、“如果信息不足请明确说明”。检索增强不仅用RAG为生成提供上下文在验证阶段我们也让验证智能体有权发起“二次检索”当它对某个点存疑时可以命令检索智能体针对该点进行更精确的搜索。输出约束使用LLM的JSON模式或结构化输出功能强制答案合成智能体按照{“结论”: “”, “依据”: [“条款1”, “条款2”], “计算过程”: “”, “免责声明”: “”}这样的格式输出便于程序化校验。2. 处理法律冲突与更新法律条文会修订不同法规间可能存在冲突。我们的策略是元数据为王为每个知识库文档片段精确标记生效日期和修订版本。检索时优先返回最新版本。建立优先级规则在系统配置中内置规则例如“联邦法 州法 市政法”、“新法 旧法”。验证智能体在发现冲突时应用这些规则。变更监控管道建立自动化流程定期从官方源抓取法律文本与知识库进行差分比较自动或半自动地更新向量索引并标记已变更的条款。3. 复杂、多轮与假设性提问用户的问题不总是简单的“是什么”。例如“如果员工在休假期间生病假期该如何处理”假设性或是一连串相关问题的对话。会话记忆调度智能体维护整个会话的上下文将历史问答摘要传递给后续的智能体使它们能理解指代和上下文。假设性场景处理在提示词中训练调度和合成智能体识别“如果…那么…”这类模式。检索时不仅检索直接相关的法条也检索与之相关的原则性条款或类似案例解释供模型进行类比推理。同时在答案中明确标明“这是一个基于相关法律原则的推论”。5.2 性能与成本优化多智能体意味着多次LLM调用成本是必须考虑的问题。智能缓存对于常见、确定性的问题如“最低工资标准是多少”在调度器层面设置缓存直接返回缓存答案无需启动整个智能体流程。轻量级模型分流能用小模型完成的任务绝不用大模型。例如初步的意图分类、简单的文本格式化可以尝试使用GPT-3.5 Turbo甚至更小的开源模型。异步与流式处理将智能体任务放入异步队列避免用户请求阻塞。对于长答案可以采用流式输出Streaming让用户先看到部分结果。检索优化优化向量索引如使用HNSW算法、对高频查询进行预计算、使用更高效的嵌入模型都能减少延迟和计算开销。5.3 未来演进方向HR-Agents目前还是一个专注于问答的系统但它的架构为更多可能性奠定了基础。从问答到分析与起草让智能体不仅能回答“是什么”还能进行简单的合规性分析“我公司的这份雇佣合同范本有哪些潜在风险”甚至辅助起草法律文书如解雇通知书的要点。多模态输入支持用户上传扫描的劳动合同、工资单或政府通知通过视觉智能体VLM提取关键信息如日期、金额、条款再结合法律知识库进行分析。持续学习与反馈闭环建立用户反馈机制“这个答案有帮助吗”。将用户修正或专家审核后的正确答案经过处理后作为高质量数据反哺知识库或用于微调合成智能体让系统越用越聪明。个性化与情境化结合用户公司的基本信息所在州、行业、规模在检索和推理时自动加入这些情境过滤器提供更具针对性的建议。构建HR-Agents的过程是一个将前沿LLM智能体技术与垂直领域深度需求相结合的过程。它告诉我们解决专业问题单靠一个强大的模型往往不够更需要一个设计精巧的“团队”让每个成员智能体发挥其专长并通过严谨的流程协作机制确保最终输出的质量。对于巴西劳动法这样复杂且动态的领域这样一个系统虽然不是万能的但它确实能成为专业人士手中一件高效、可靠的辅助工具将人从海量信息检索和初步分析中解放出来专注于更高价值的判断和决策。