多LLM协同架构在AI法律调解系统中的应用与实践

1. 项目概述：当AI成为“和事佬”

最近在做一个挺有意思的项目，我们内部称之为“AI调解员”。核心想法很简单：当两个人或两家公司发生法律纠纷时，与其立刻对簿公堂，不如先让一个更理性、更懂规则的“中间人”来帮忙梳理一下。这个“中间人”不是真人律师，而是一套由多个大语言模型协同工作的智能系统。它的目标不是给出具有法律约束力的判决，而是通过分析争议双方的陈述、相关证据和适用的法律原则，生成一份结构化的争议分析报告、潜在的和解方案建议，甚至模拟不同解决方案可能带来的后果。

这个项目的出发点源于一个普遍的痛点：很多商业合同纠纷或民事争议，其核心矛盾并非不可调和，而是缺乏一个高效、低成本、情绪中立的沟通与评估渠道。传统调解耗时耗力，而诉讼更是最后的无奈之选。我们就在想，能否利用当前LLM在文本理解、逻辑推理和生成方面的能力，构建一个数字化的“第一道防线”？它能够7x24小时待命，快速消化上百页的合同和邮件往来，从海量信息中提取关键争议点，并以一种双方都能理解的、非对抗性的语言呈现出来。这不仅能节省大量前期咨询成本，更能为后续无论是调解、仲裁还是诉讼，提供一个清晰、客观的事实与法律焦点梳理。

2. 系统架构设计与核心思路

构建这样一个系统，远不是接上一个ChatGPT的API那么简单。法律文本的严谨性、推理过程的可靠性、结论的可解释性，都要求我们必须采用一个更为审慎和结构化的多模型架构。我们的核心设计思路是“分工协作，交叉验证”，让不同的LLM各司其职，共同完成从信息处理到报告生成的全流程。

2.1 为什么选择多LLM架构而非单一模型？

单一LLM，无论能力多强，在处理复杂、高风险的领域时都存在固有风险：它可能“一本正经地胡说八道”，即产生看似合理实则错误的“幻觉”；它的推理过程是个黑箱，难以追溯和验证；此外，不同模型在不同任务上表现各异，有的擅长总结，有的擅长逻辑链推理，有的则在特定领域知识上更专业。

因此，我们采用了管道式多LLM架构，将调解流程分解为多个子任务，并为每个任务匹配合适的“专家”模型。这样做有几个关键优势：

1. 风险隔离：一个环节的失误不会直接污染最终输出，后续环节可以起到校验作用。
2. 能力专精：我们可以为“法律条文检索与理解”选择在大量法律文本上微调过的模型，为“中立语言生成”选择更擅长对话和共情的模型。
3. 成本与性能平衡：不需要全程使用最庞大、最昂贵的模型。可以在关键推理环节用强模型，在信息提取、格式化工序上用轻量级或性价比更高的模型。

2.2 核心四阶段管道设计

我们的系统主要分为四个顺序执行的阶段，每个阶段由一个或多个LLM驱动，并设有质量检查节点。

第一阶段：信息提取与结构化用户（通常是双方或调解发起方）上传争议材料：合同文本、往来邮件、聊天记录、票据扫描件（需经OCR处理）等。这些非结构化文本首先被送入一个“信息提取专员”模型。这个模型的任务不是理解争议，而是像一位高效的书记员，从文本中识别并提取关键实体和事实陈述。

• 关键实体：合同双方名称、关键日期（签约日、履约截止日、违约发生日）、金额、货物/服务描述、违约责任条款编号等。
• 事实陈述：甲方声称“已于X日交付”，乙方声称“收到货物存在Y问题”。系统会以“（陈述方， 陈述内容， 出处）”的三元组形式进行提取和记录。 这个阶段的目标是将杂乱的“故事”转化为结构化的“事实清单”，为后续分析打下基础。我们通常会选用在NER（命名实体识别）和文本分类任务上表现稳定的模型，不一定需要最强的生成能力。

注意：此阶段必须严格区分“事实提取”和“事实认定”。模型只记录各方“声称”了什么，绝不在此阶段判断谁真谁假。所有提取出的陈述都会关联其原始出处（如文档ID、页码），确保可追溯。

第二阶段：争议焦点归纳与法律条文关联拿到结构化的“事实清单”后，系统进入“法律分析助理”环节。这个阶段由两个子步骤构成：

1. 争议焦点归纳：一个LLM会分析双方对立的事实陈述，自动归纳出核心的争议点。例如，从“甲方称已付款”和“乙方称未收到”的陈述中，归纳出“付款是否完成”的争议焦点；从“乙方称货物有瑕疵”和“甲方称符合标准”中，归纳出“货物质量是否符合约定”的焦点。每个焦点都会清晰列出双方的主张。
2. 法律条文关联与要件分析：针对归纳出的每一个争议焦点，系统会查询内嵌的法律知识库（基于本地向量数据库，存储相关法律法规、判例摘要），找到可能适用的法律原则或合同条款。然后，另一个LLM（或同一模型的不同调用）会执行“要件分析”。例如，针对“是否构成违约”这个焦点，模型会列出法律上认定违约的一般要件（如合同有效、义务存在、未履行或不当履行、无免责事由），并将第一阶段提取的事实尝试与每个要件进行比对，初步判断各方主张在哪些要件上存在证据支持或缺失。

第三阶段：多视角分析与方案模拟这是系统的“大脑”，也是最核心的推理环节。我们引入了“委员会评审”机制，即让多个同级别或不同级别的LLM，基于前两个阶段产出的结构化信息（事实清单、争议焦点、相关法条），进行独立并行分析。

• 模型A（保守型分析）：可能更侧重于合同文本的严格字面解释，倾向于保护守约方，生成的解决方案偏向于严格履行原合同或赔偿。
• 模型B（衡平型分析）：可能更注重商业关系的延续和实质公平，会考虑履约背景、交易习惯，提出的方案可能包含折扣、分期履行、附加服务等柔性措施。
• 模型C（成本效益分析）：侧重于模拟不同解决方案（如立即赔偿、继续履行、解除合同）对双方可能产生的直接成本、间接商誉损失、时间成本等。 每个模型都会输出自己的分析摘要和1-3个建议方案。系统随后会用一个“元评审”模型来对比、总结这些不同视角的输出，识别共识点（如“乙方延迟交付事实清晰”）和分歧点（如“赔偿金额计算方式”），并生成一份《多视角分析综述》。

第四阶段：报告生成与语言调和最后阶段是“输出与表达”。系统根据《多视角分析综述》，生成最终交付给用户的《争议解决建议报告》。这份报告由专门优化过生成风格的LLM撰写，需满足：

• 结构化：包含摘要、背景事实、争议焦点、法律分析、风险评估、和解方案建议（附利弊分析）等部分。
• 中立客观：语言必须不偏不倚，避免使用带有情感倾向或指责性的词汇。陈述双方主张时使用“甲方陈述…”、“乙方认为…”这样的客观句式。
• 可读性：将法律术语转化为通俗易懂的商业语言，并解释关键推理步骤。例如，不仅说“根据合同法第X条”，还会解释“该条文的核心原则是…，适用于本案是因为…”。
• 明确免责：报告开头和结尾必须显著声明，本报告仅为基于输入信息的自动化分析建议，不构成正式法律意见，不取代专业律师咨询。

3. 关键技术细节与实操要点

3.1 法律知识库的构建与检索增强生成

系统的可靠性很大程度上依赖于一个高质量的法律知识库。我们并非让LLM死记硬背法律条文，而是采用“检索增强生成”技术。

1. 知识源：我们收集了合同法、民法典相关编、以及特定行业（如买卖合同、技术服务合同）的司法解释、示范性判例摘要。所有文本都经过清洗，去除无关信息。
2. 向量化：使用文本嵌入模型将法律条文和判例摘要转化为高维向量，存入向量数据库（如Chroma、Weaviate）。
3. 检索：当系统在第二阶段需要进行“法律条文关联”时，会将当前争议焦点的描述（例如“关于货物质量标准的争议”）转化为查询向量，在向量数据库中搜索语义最相关的法条和判例。
4. 生成：将检索到的相关法律条文片段，连同争议焦点描述、事实清单一起，作为上下文输入给“法律分析助理”LLM，指令其“基于以下相关法律规定，对下述争议进行分析”。这样，模型的分析就有了坚实的依据，减少了胡编乱造法条的风险，也提高了输出的可解释性——我们可以在报告中注明“参考了【具体法条编号】”。

实操心得：法律知识库的构建质量至关重要。我们踩过一个坑：初期直接将整部法律文档切片存入，导致检索结果过于宽泛。后来改为按“法条-适用情形-核心要件”的结构化片段进行存储和向量化，检索精度大幅提升。例如，不是存整个《合同法》第107条，而是存“《合同法》第107条：违约救济-继续履行/补救/赔偿损失-适用于一般违约情形”。

3.2 提示工程与智能体角色设定

在多LLM架构中，如何给每个模型“下达清晰的指令”是成败关键。我们为每个阶段的模型设计了高度结构化和角色化的系统提示词。

• 对信息提取模型：“你是一名严谨的法庭书记员。你的任务是从以下文本中，精确提取所有可能与合同履行争议相关的事实陈述和关键实体。对于任何事实，只记录其被声称的内容和声称方，不做任何真实性判断。输出必须为严格的JSON格式，包含‘claims’和‘entities’两个列表…”
• 对法律分析模型：“你是一名经验丰富的非诉律师助理。基于提供的事实清单和相关法律条文，你的任务是：1. 归纳核心争议焦点；2. 对每个焦点，分析双方主张的法律依据强弱；3. 指出证据链的缺失环节。请保持分析的中立性和专业性。”
• 对报告生成模型：“你是一名专业的争议调解员，负责撰写一份给争议双方阅读的调解建议报告。报告语言需平和、建设性、易于理解。你的目标是帮助双方看清问题本质，探索解决方案，而不是判定对错。报告结构应包括：…（省略）”

通过这种精细的角色和任务设定，我们能够更好地约束模型的行为，使其输出更符合预期格式和风格。

3.3 评估与迭代循环

如何评估这个“AI调解员”的好坏？我们不能只看它生成的报告是否“看起来专业”。我们建立了一套多维度的评估体系：

1. 事实提取准确率：人工核对模型提取的事实陈述是否完整、无扭曲、出处正确。
2. 争议焦点归纳的覆盖度与准确性：专家判断系统归纳的焦点是否抓住了真实矛盾，有无遗漏或偏差。
3. 法律关联的相关性：检索出的法条是否真正适用于当前争议点。
4. 分析报告的有用性与安全性：这是最综合的评估。我们邀请法律专业人士和商业人士阅读报告，评估：a) 信息是否准确？b) 推理逻辑是否清晰？c) 建议是否具有实操性？d)最关键的是，是否存在严重的误导性或可能导致局势恶化的建议？基于这些评估结果，我们会持续迭代：调整提示词、优化知识库检索策略、甚至更换或微调某个环节的模型。

4. 核心工作流程与实现解析

让我们跟随一个简化的模拟案例，走一遍系统的完整工作流。假设案例：甲方（软件开发商）与乙方（客户）就一个定制软件项目发生争议，甲方声称已完成开发并交付，要求支付尾款；乙方声称软件存在多处漏洞，未达到合同约定的验收标准，拒绝付款。

4.1 第一阶段实操：原始材料的消化

双方上传了《软件开发合同》、为期三个月的邮件沟通记录、一份甲方提交的《交付清单》、以及乙方整理的《测试问题列表》。 系统首先调用OCR服务处理所有扫描件，将其转为文本。然后，将所有文本合并，送入“信息提取专员”模型。模型运行后，输出结构化的JSON数据，例如：

{ "entities": [ {"type": "Party", "name": "智软科技", "role": "甲方"}, {"type": "Party", "name": "卓越商贸", "role": "乙方"}, {"type": "Date", "value": "2023-10-01", "context": "合同签订日期"}, {"type": "Clause", "id": "Section 4.3", "content": "软件需通过乙方组织的验收测试，标准详见附件一。"}, {"type": "Monetary", "value": "150000", "currency": "CNY", "context": "合同总金额"} ], "claims": [ {"party": "甲方", "content": "我方已于2024-1-20将软件V1.0部署至乙方指定服务器，并发送交付通知。", "source": "交付清单"}, {"party": "甲方", "content": "截至2024-2-10，乙方未按合同约定支付尾款75000元。", "source": "邮件_20240210"}, {"party": "乙方", "content": "软件存在数据导出功能崩溃、报表生成速度低于约定标准等5项严重问题。", "source": "测试问题列表"}, {"party": "乙方", "content": "甲方未在约定时间内修复上述问题，导致我方业务受阻。", "source": "邮件_20240215"} ] }

这个结构化的输出，已经将散落在各处的信息进行了初步的“案情梳理”。

4.2 第二阶段实操：焦点归纳与法律匹配

“法律分析助理”模型接收上述事实清单。它首先进行焦点归纳：

1. 焦点一：软件是否已完成符合合同标准的交付？
   • 甲方主张：已按时交付。
   • 乙方主张：存在未解决的严重问题，未达到验收标准。
2. 焦点二：乙方是否有权拒付尾款？
   • 甲方主张：乙方无正当理由逾期付款，构成违约。
   • 乙方主张：因软件质量不合格，行使先履行抗辩权或同时履行抗辩权。

接着，系统针对“焦点一”，在向量知识库中检索。查询词可能是“软件 交付 验收 标准 不符合 质量”。检索结果返回《民法典》第781条关于承揽合同工作成果交付验收的规定，以及《合同法》相关司法解释中关于“质量不符合约定”的认定标准。模型将这些法条片段作为上下文，进行分析：“根据相关法律规定，承揽人交付的工作成果应符合质量要求。定作人有权进行检验。若不符合约定，定作人可以要求承揽人承担修理、重作、减少报酬、赔偿损失等违约责任。本案中，合同约定的验收标准（附件一）是判断是否符合质量要求的关键依据。”

4.3 第三阶段实操：委员会式推理模拟

系统将结构化信息（事实、焦点、相关法条）同时发送给三个配置不同的分析模型。

• 模型A（保守分析）输出：“合同明确约定了验收标准和流程。乙方提交的《测试问题列表》若属实，可视为对质量异议的初步证据。甲方未能证明已解决这些问题或这些问题不构成对验收标准的违反。因此，在完成符合标准的交付前，乙方付款条件未成就。建议：甲方先行修复问题，双方重新验收。”
• 模型B（衡平分析）输出：“项目已进行到交付阶段，双方投入了大量资源。软件问题可能部分属于可修复的瑕疵。立即认定交付失败可能导致项目完全破裂，损失扩大。建议：双方立即召开技术会议，对问题清单进行分级（关键阻塞性问题 vs. 一般优化性问题）。就关键问题设定明确的修复时限和验收节点，并可将部分尾款（如30%）作为履约保证金，待所有问题修复后支付。”
• 模型C（成本分析）输出：“模拟方案1：诉讼。预计耗时6-12个月，双方需支付律师费、诉讼费，且商业关系破裂。甲方可能收回尾款但损失客户；乙方可能无需支付尾款但需寻找新开发商，业务中断。总成本高。模拟方案2：采用模型B的建议。预计额外耗时2-4周，甲方投入开发资源修复，乙方暂扣部分款项。总成本较低，商业关系得以维持。”

“元评审”模型总结道：“三个模型均认为乙方提出的质量问题需要被严肃对待，这是当前争议的核心。分歧在于解决方案的刚性程度。共识是建议双方就具体技术问题进行对接，而非立即诉诸法律对抗。”

4.4 第四阶段实操：最终报告的雕琢

“报告生成”模型根据以上所有信息，撰写一份约5页的《软件项目交付争议解决建议报告》。报告会以平实的语言复述项目背景和双方核心主张，然后呈现系统归纳的争议焦点。在法律分析部分，它会解释“先履行抗辩权”在本案中可能的适用条件，并引用检索到的相关法条精神。最重要的部分是“和解方案建议”，它会将委员会模拟出的几种方案及其利弊分析清晰地列出来：

• 方案A（快速修复与部分支付）：内容、预计步骤、对甲方的利弊、对乙方的利弊。
• 方案B（第三方技术评估）：内容、预计步骤、成本、对双方的利弊。
• 方案C（终止合作与清算）：内容、步骤、风险提示。 报告最后会强调，所有分析基于已提交材料，并建议双方在后续沟通中补充哪些关键证据（如详细的验收标准文档、问题修复的沟通记录等），以利于进一步评估。

5. 常见挑战与实战避坑指南

在实际开发和测试中，我们遇到了不少典型问题，以下是其中一些及其解决方案。

5.1 模型“幻觉”与事实扭曲

这是法律场景下最致命的风险。模型可能会“脑补”出不存在的事实或错误引用法律。

• 问题表现：在报告中出现双方都未提及的“事实”，或对合同条款做出明显错误的解释。
• 排查与解决：
  1. 强化事实锚定：在给分析模型的提示词中强制要求“所有分析必须严格基于提供的事实清单，清单之外的事实不予考虑”。并在输出格式中要求模型注明其每一个推断所依据的原始事实编号。
  2. 引入一致性检查：在管道末端，增加一个轻量级的“事实核对”步骤。用一个模型快速扫描最终报告，将其中的事实陈述反向与第一阶段提取的事实清单进行匹配，标记出任何无法匹配或存在明显矛盾的点，并触发人工审核。
  3. 使用低“幻觉”倾向模型：在关键的事实关联和法律推理环节，优先选择那些在基准测试中“幻觉”率较低的模型，即使其创造性可能稍差。

5.2 对模糊语言与隐含前提的处理不足

法律合同和商业沟通中充满模糊表述（如“合理期限”、“重大瑕疵”）和双方心照不宣的隐含前提。

• 问题表现：系统机械地处理文本，无法理解“合理”一词在具体语境中的含义，或者忽略了一些行业惯例。
• 排查与解决：
  1. 上下文扩充：在输入给分析模型时，不仅提供争议材料，还提供一些相关的“背景知识”，例如该行业的常见实践、技术术语解释等。这可以通过在知识库中增加行业词条来实现。
  2. 设置敏感点提示：在系统中内置一个“模糊条款检测器”，当识别到“合理”、“及时”、“重大”、“满意”等主观性词汇时，在内部工作流中标记，并提示分析模型：“注意，以下条款包含主观标准，请结合合同目的、交易习惯和双方后续行为进行综合解释。”
  3. 明确系统边界：在报告中和用户界面向用户明确说明：“系统对涉及主观判断的条款分析仅供参考，该等条款的解释最终取决于双方协商或裁判机构的认定。”

5.3 对情绪化与对抗性语言的放大

争议双方的原始材料往往充满情绪化语言。如果系统不加处理地吸收并模仿，生成的报告可能会火上浇油。

• 问题表现：报告中使用“甲方无理拖延”、“乙方恶意挑剔”等带有强烈感情色彩的词句。
• 排查与解决：
  1. 输入净化：在信息提取阶段后，对提取出的“事实陈述”进行一轮语言净化处理，将情绪化表达转化为中性陈述。例如，将“乙方的要求简直是吹毛求疵”转化为“乙方提出了超出合同明确约定范围的修改要求”。
  2. 风格约束强化：对报告生成模型的提示词进行严格训练和约束，反复强调“中立、平和、建设性”的语态，并提供大量中性化表述的示例。
  3. 人工审核环节：对于高价值或高冲突风险的案件，系统输出报告后，设置一个必要的人工审核环节，专门检查并修正语言语调，确保其起到降温而非激化的作用。

5.4 性能、成本与响应时间的平衡

多模型管道调用意味着更高的API成本和更长的响应延迟。

• 问题表现：处理一个复杂案件耗时数分钟，成本达数美元，难以规模化。
• 排查与解决：
  1. 异步处理与缓存：将整个流程设计为异步任务。用户提交材料后即刻返回“已接收，正在处理”，后台顺序执行各阶段。对法律知识库的检索结果进行缓存，相同或相似的争议焦点查询直接返回缓存结果。
  2. 模型分级调用：并非所有案件都需要启动完整的“委员会模拟”。可以设计一个简单的“争议复杂度分类器”（一个小型模型或基于规则的系统），根据争议焦点数量、材料长度、涉及金额等，将案件分为“简单”、“中等”、“复杂”等级别。对于简单案件，只使用核心的分析和报告生成模型，跳过多模型模拟环节。
  3. 优化提示词与输出长度：精确设计提示词，让模型输出简练、聚焦的内容，避免生成冗长的无关论述。限制各环节模型的输出token数量，在满足需求的前提下控制成本。

构建这样一个AI调解系统，最大的体会是技术实现只是基础，更重要的是对应用场景的深度理解和对边界风险的清醒认知。它不是一个替代律师的“判决机器”，而是一个提升信息处理效率、辅助理性决策的“增强智能”工具。它的价值在于快速厘清事实、梳理法律关系、提供结构化视角，将人类从繁杂的信息整理和初步分析中解放出来，从而更专注于谈判策略、价值判断和关系维护这些更核心的工作。在实际部署中，我们始终将它的角色定位为“辅助者”而非“决策者”，所有输出都带有明确的免责声明，并引导用户将其作为专业咨询的输入材料之一。这个定位让我们既能大胆探索技术可能性，又能稳妥地控制应用风险。