多智能体协同验证：基于大语言模型的表格数据自动化核查系统

1. 项目概述：当表格数据遇上“多智能体”验证

最近在数据分析和信息核查领域，一个老问题正被新方法重新点燃：如何从海量的、结构化的表格文档中，自动验证一个给定的陈述或“主张”的真伪？这听起来像是数据科学家的日常工作，但实际操作起来却异常棘手。传统的规则引擎或单一模型在面对复杂表格、跨页引用、隐含计算逻辑时，往往力不从心。而“A Multi-Agent Approach for Claim Verification from Tabular Data Documents”这个项目，正是瞄准了这一痛点，提出用“多智能体”协同工作的思路来系统性地解决表格数据的主张验证问题。

简单来说，这个项目构建了一个由多个专业化“智能体”组成的虚拟团队，每个智能体都像一位专家，各司其职，共同完成从理解主张、定位数据、执行计算到最终裁决的完整验证链条。这背后离不开大语言模型能力的加持，但更重要的是如何将这些能力组织起来，形成一个稳定、可靠、可解释的协作系统。对于经常需要处理财报、统计报告、科研数据表格的分析师、审计员或研究人员而言，这套方法有望将繁琐的人工核对工作自动化，大幅提升效率和准确性。接下来，我将深入拆解这个项目的核心设计、实现细节以及我在模拟复现过程中的实战心得。

2. 核心架构与多智能体分工设计

项目的核心创新在于其“分而治之”的多智能体架构。它没有试图用一个“全能”的模型去解决所有问题，而是将复杂的验证任务分解为一系列子任务，并为每个子任务设计一个专用的智能体。这种设计思路借鉴了人类专家团队的协作模式，也符合当前AI智能体研究的主流方向。整个系统通常包含以下几个关键角色智能体：

2.1 主张解析智能体

这是整个流程的起点，它的任务是对用户输入的自然语言主张进行深度理解。这远不止是简单的关键词提取。例如，对于主张“公司A在2023年Q2的净利润同比增长率超过20%”，解析智能体需要识别出：

• 主体：公司A
• 时间：2023年第二季度
• 度量指标：净利润同比增长率
• 断言关系：> 20%
• 潜在计算需求：“同比增长率”意味着需要当前期和去年同期的数据来进行计算。

这个智能体通常由一个经过精调或通过精心设计提示词引导的LLM担任。它的输出是一份结构化的“任务工单”，明确了后续智能体需要寻找什么数据、进行何种操作。一个常见的陷阱是主张中可能存在歧义或隐含条件，比如“营收”可能指“总收入”或“净营收”，解析智能体需要结合领域知识进行消歧，或将其标注为需要后续智能体确认的模糊点。

2.2 表格定位与信息抽取智能体

拿到结构化工单后，这个智能体负责在目标文档（可能是包含多个表格的PDF、Excel或网页）中找到相关数据。对于简单的表格，直接进行表头匹配和行列查找即可。但现实中的表格往往很复杂：可能有合并单元格、多层表头、表格跨页、甚至数据以注释形式存在。

这个智能体的实现是技术难点之一。一种混合策略效果较好：

1. 视觉特征辅助定位：如果文档是PDF或图像，可以先用OCR或PDF解析库（如camelot、tabula）提取表格结构和文本，同时保留单元格的坐标信息。智能体可以学习理解“左侧”、“下方”、“右侧附表”等空间关系。
2. 语义检索增强：利用嵌入模型将表格的标题、表头、以及部分单元格内容转换为向量，与解析后的主张要素进行语义相似度匹配，从而找到最相关的表格区域，即使表述不完全一致（如“净利润”在表中可能叫“归属母公司净利润”）。
3. LLM上下文理解：将可疑的表格区域（以HTML或Markdown格式）连同任务工单一起提交给LLM，要求其提取出工单中指定的精确数据项。例如：“请从下方表格中，找到‘公司A’在‘2023年Q2’和‘2022年Q2’对应的‘净利润’数值。”

注意：信息抽取的准确性直接决定验证结果的正误。必须设计严格的校验机制，例如让智能体同时输出它做出判断所依据的原始文本片段，以备审计。

2.3 计算与推理智能体

数据找到后，并非所有主张都能直接比对。像前面提到的“同比增长率”，就需要进行计算。计算智能体接收抽取到的原始数据（如2023Q2净利润1.2亿，2022Q2净利润1.0亿）和计算指令。

这里的关键是可靠的计算。绝对不能让LLM直接进行数值计算，因为LLM在数学计算上并不可靠。正确的做法是：

• 让LLM根据主张，生成对应的计算逻辑（如公式(当期值 - 同期值) / 同期值 * 100%）。
• 系统后台使用可靠的Python数学库（如numpy、pandas）或符号计算库来执行这个公式。
• 计算智能体负责组装公式、调用计算引擎、并返回计算结果。

对于更复杂的推理，例如判断趋势（“利润持续增长”）、对比排名（“市场份额位列前三”），智能体需要结合多个数据点和简单的逻辑规则进行判断。

2.4 验证裁决智能体

这是做出最终判决的“法官”。它接收来自解析智能体的主张断言、来自计算智能体的结果，有时还需要参考原始数据片段。它的任务是将计算结果与主张中的断言进行比对。

例如，主张是“增长率超过20%”，计算结果是25%。那么裁决智能体需要执行逻辑判断：25% > 20%为真。对于模糊主张如“显著增长”，智能体可能需要参考历史数据波动范围来定义“显著”的阈值。

裁决智能体的输出不应只是一个简单的“真/假”，而应该是一个结构化的验证报告，至少包含：

• 验证结果：支持、反对、或信息不足无法判断。
• 置信度：系统对此次判断的信心水平（可以基于各环节智能体输出的质量、数据清晰度等来综合评估）。
• 证据链：引用了哪些表格、哪些单元格的数据，进行了何种计算。这是保证过程可追溯、可审计的关键。

2.5 协调智能体

上述所有智能体需要一个“指挥官”来调度，这就是协调智能体。它负责工作流的控制：先启动解析智能体，然后将其输出传递给定位抽取智能体，接着将抽取的数据传递给计算智能体，最后汇集所有信息给裁决智能体。它还负责处理异常，比如某个智能体返回“无法找到数据”，协调者可能需要尝试其他搜索策略，或直接判定为“信息不足”。

3. 关键技术实现与工具链选型

构建这样一个多智能体系统，技术选型至关重要。以下是我在模拟实现中认为比较合理的一套工具链和关键实现细节。

3.1 大语言模型选型与提示工程

LLM是整个系统的“大脑”。对于不同的智能体角色，对LLM的能力要求侧重点不同。

• 解析与裁决智能体：需要较强的逻辑理解和指令遵循能力。GPT-4、Claude 3系列或开源的DeepSeek-V2、Qwen2.5-72B是不错的选择。它们能更好地理解复杂主张和进行精细推理。
• 信息抽取智能体：需要强大的上下文处理能力和对结构化数据的理解。GPT-4 Turbo（128K上下文）或Claude 3.5 Sonnet在处理长文档和多表格时更有优势。
• 成本与效率考量：对于计算逻辑生成等简单任务，可以使用更轻量的模型如Qwen2.5-7B或Llama 3.1-8B，通过API或本地部署来降低成本。

提示工程是灵魂。每个智能体的提示词都必须精心设计。以解析智能体为例，一个有效的提示词模板应包含：

你是一个专业的财务数据分析助手。请将用户提出的主张分解为结构化要素。 主张：{user_claim} 请严格按照以下JSON格式输出： { "subject": "主张涉及的主体，如公司名、产品名", "time_period": "主张明确提及的时间，如‘2023年Q2’", "metric": "需要核查的度量指标，如‘净利润’、‘营收’", "calculation_required": ["是"或“否”，该指标是否需要计算（如增长率、占比等）], "calculation_type": "如果需要计算，是什么类型？如‘同比变化率’、‘求和’、‘平均值’", "assertion": "主张所断言的关系，如‘> 20%’、‘等于100万’、‘是最高的’", "potential_ambiguity": "指出主张中可能存在的歧义词，如‘营收’可能指‘总营收’或‘净营收’" }

这种结构化输出极大方便了后续智能体的处理。

3.2 表格数据处理与信息抽取实战

这是项目中最“脏”最累的环节。我的经验是采用分层处理管道：

1. 文档解析层：

   • PDF/扫描件：优先使用pdfplumber，它对表格结构的保持较好。对于复杂排版，camelot（基于Ghostscript）的lattice模式可以尝试，但速度较慢。Adobe PDF Extract API或Google Document AI等云服务准确率最高，但需考虑成本。
   • Excel/CSV：直接使用pandas.read_excel或read_csv，这是最理想的情况。
   • 网页表格：使用BeautifulSoup或Playwright进行抓取和解析。

2. 表格理解与标准化层： 解析出的表格数据往往是嵌套列表或DataFrame。需要编写函数来规范化表格，例如：展平多层表头、处理合并单元格（将值填充到所有对应单元格）、识别并分离表头和数据体。

3. 语义检索层： 将每个表格（或其子部分）的文本内容（如“2023年损益表 - 公司A”）通过嵌入模型（如text-embedding-3-small、BGE-M3）转换为向量，并存入向量数据库（如ChromaDB、Qdrant）。当主张解析智能体输出结构化要素后，可以将“主体”+“度量指标”+“时间”组合成查询语句，进行向量检索，快速定位相关表格。

4. 精确抽取层： 将检索到的候选表格，连同解析出的详细指令，发送给LLM进行精确抽取。这里的关键是格式化上下文。将表格数据转换为清晰的Markdown格式，并给出明确的抽取指令。

   以下是关于[公司A]的财务数据表格（Markdown格式）： | 期间 | 营业收入 | 净利润 | ... | |---|---|--|--| | 2023 Q1 | 500 | 120 | ... | | 2023 Q2 | 600 | 150 | ... | | 2022 Q2 | 550 | 125 | ... | 请严格根据指令提取数据： - 查找主体：[公司A] - 查找指标：[净利润] - 查找时间：[2023年第二季度] 和 [2022年第二季度] 请直接输出这两个时间点对应的净利润数值，格式为：`[150, 125]`

3.3 多智能体协作框架的实现

如何让这些智能体“活”起来并协同工作？我们不需要从零开始造轮子。现有的智能体框架可以大幅简化开发：

• LangChain / LangGraph：这是目前最流行的选择之一。LangGraph特别适合定义有状态、多步骤的工作流。我们可以将每个智能体定义为一个Node，用Edge来定义它们之间的流转条件（如“解析完成”则流向“定位抽取”）。LangGraph能清晰地管理整个对话状态。
• AutoGen：由微软推出，专为多智能体对话而设计。它内置了AssistantAgent、UserProxyAgent等角色，可以很方便地搭建一个智能体群聊，让它们通过对话来协作完成任务。对于需要反复沟通确认的场景（如抽取智能体向解析智能体澄清歧义）非常自然。
• CrewAI：一个更高层次的框架，直接引入了Agent、Task、Process和Crew的概念。你可以定义每个智能体的角色（Role）、目标（Goal）、背景（Backstory），然后为其分配任务（Task），最后让一个“机组”（Crew）按顺序或层级流程来执行。它的抽象层次更高，更贴近业务描述。

在我的模拟项目中，我选择了LangGraph，因为它对工作流控制的灵活性最强。下面是一个极度简化的核心流程代码示意：

from langgraph.graph import StateGraph, END from typing import TypedDict class AgentState(TypedDict): claim: str parsed_claim: dict extracted_data: list calculation_result: float verdict: dict error: str def parse_claim_node(state: AgentState): # 调用解析智能体LLM state[‘parsed_claim‘] = llm_invoke(claim_parser_prompt, state[‘claim‘]) return state def extract_data_node(state: AgentState): # 根据parsed_claim，检索并抽取数据 query = f"{state[‘parsed_claim‘][‘subject‘]} {state[‘parsed_claim‘][‘metric‘]}" relevant_tables = vector_db.search(query) state[‘extracted_data‘] = llm_invoke(data_extractor_prompt, relevant_tables, state[‘parsed_claim‘]) return state def calculate_node(state: AgentState): if state[‘parsed_claim‘][‘calculation_required‘] == ‘是‘: formula = llm_invoke(formula_generator_prompt, state[‘parsed_claim‘], state[‘extracted_data‘]) state[‘calculation_result‘] = safe_eval(formula, state[‘extracted_data‘]) # 安全计算 return state def verdict_node(state: AgentState): state[‘verdict‘] = llm_invoke(judge_prompt, state[‘parsed_claim‘], state[‘calculation_result‘], state[‘extracted_data‘]) return state # 构建图 workflow = StateGraph(AgentState) workflow.add_node(“parse”, parse_claim_node) workflow.add_node(“extract”, extract_data_node) workflow.add_node(“calculate”, calculate_node) workflow.add_node(“judge”, verdict_node) # 定义边 workflow.set_entry_point(“parse”) workflow.add_edge(“parse”, “extract”) workflow.add_edge(“extract”, “calculate”) workflow.add_conditional_edges( “calculate”, lambda x: “judge” if x[‘calculation_result‘] is not None else “error_handler” ) workflow.add_edge(“judge”, END) # 编译并运行 app = workflow.compile() final_state = app.invoke({“claim”: “公司A在2023年Q2的净利润同比增长率超过20%”})

4. 实战挑战、调优策略与避坑指南

在尝试复现和优化这类系统的过程中，我遇到了不少坑，也总结出一些有效的调优策略。

4.1 准确性挑战与缓解方案

1. 表格定位错误：

   • 问题：智能体找到了错误的表格，例如把“现金流量表”当成了“损益表”。
   • 对策：在向量检索时，不仅用主体和指标，也加入表格类型的描述（如“损益表”、“资产负债表”）作为查询增强。在给LLM的抽取指令中，明确说明表格的类型和所需数据的性质。

2. 数据抽取歧义：

   • 问题：表格中可能存在多个相似指标，如“净利润”、“归母净利润”、“扣非净利润”。
   • 对策：在解析主张阶段，就要求解析智能体明确指出可能存在的歧义。在抽取阶段，采用“投票”机制：让LLM同时执行两项任务——a) 直接抽取指定数据；b) 列出表格中所有与目标指标相关的数据项及其定义。如果两者不一致，则触发人工复核或让协调智能体发起多轮询问澄清。

3. 计算逻辑错误：

   • 问题：LLM生成的公式有误，例如增长率公式写反。
   • 对策：绝对不要信任LLM直接计算。采用“生成-验证-执行”三步法：a) LLM生成公式；b) 用一个简单的验证规则（如公式中应包含哪些变量）或另一个轻量级LLM检查公式的合理性；c) 使用隔离的、确定性的数学库（如pandas.eval或numexpr）执行计算。对于常见计算类型（增长率、占比、求和），可以预定义公式模板库，让LLM只是选择模板并填入参数。

4.2 性能与成本优化

多智能体系统意味着多次调用LLM，成本和时间开销是必须考虑的。

• 智能体轻量化：不是所有智能体都需要最强的模型。解析和裁决智能体用大模型保证质量；信息抽取和计算逻辑生成可以用7B-14B级别的优质开源模型，通过vLLM或TGI部署，实现高吞吐、低延迟的推理。
• 缓存策略：对于相同或相似的主张、相同的文档区域，其解析结果、抽取的数据是可以缓存的。可以使用Redis或Memcached缓存中间结果，特别是向量检索的结果和LLM对固定表格的抽取结果。
• 异步与并行：如果验证多个独立的主张，或者一个主张需要从多个不相关的表格中取数，可以设计并行执行流。LangGraph支持并发节点的执行。
• 上下文长度管理：表格文档可能很长。不要一次性将整个文档塞给LLM。通过向量检索先缩小范围，只将最相关的1-2个表格片段（确保包含上下文）送给LLM处理。

4.3 可解释性与审计追踪

对于验证系统，光给结果是不够的，必须提供“证据”。

• 结构化日志：系统每一步的输出，包括解析出的要素、检索到的表格ID、抽取的原始数据、生成的公式、计算过程、最终裁决理由，都应作为日志结构化存储。
• 可视化证据链：理想情况下，系统能生成一份报告，高亮显示在原始文档中定位到的数据单元格，并清晰列出计算步骤。这可以通过集成ReportLab生成PDF或输出带注释的HTML来实现。
• 置信度评分：为最终裁决附上一个置信度分数。这个分数可以综合以下因素：主张的清晰度、数据源的权威性和清晰度、计算逻辑的复杂性、各环节LLM自身输出的置信度（如果模型提供的话）。低置信度的结果应被标记，建议人工复核。

5. 典型应用场景与扩展思考

这套多智能体验证框架的应用场景非常广泛：

• 金融审计与风控：自动验证上市公司财报中的关键陈述，核对新闻稿中的数据是否与财报一致。
• 学术研究辅助：快速核查论文中引用的统计数据是否与原始数据表格匹配。
• 商业智能与报告自动化：自动生成数据简报，并验证简报中的结论是否得到底层数据的支持。
• 事实核查：核查社交媒体或新闻报道中引用的数据图表的真实性。

扩展思考：

1. 从“验证”到“发现”：当前系统是被动验证给定主张。一个自然的扩展是让其主动“阅读”表格文档，并自动总结关键发现或提出潜在的可验证主张。例如，“本季度毛利率相比上季度下降了5%，主要原因可能是销售成本上升”。
2. 多模态与图表理解：许多数据以图表形式呈现。可以引入视觉语言模型智能体，专门处理图表截图，提取其中的数据序列和趋势，再与其他智能体协作进行验证。
3. 动态知识库集成：智能体不仅可以查询当前文档，还可以连接外部知识库（如公司数据库、行业报告库）来获取背景信息，辅助理解。例如，验证“利润率低于行业平均水平”时，需要去查询当前的行业平均数据。
4. 人类在环：设计流畅的人机交互接口。当系统置信度低、或遇到无法处理的歧义时，能暂停流程，向人类操作者提出明确的问题，获取澄清后继续运行。

构建这样一个系统绝非一蹴而就，它需要数据工程、提示工程、软件架构和领域知识的紧密结合。最大的体会是，与其追求一个“万能”的智能体，不如精心设计一套让多个“专才”智能体稳定协作的机制。每个智能体职责单一，更容易调试和优化；通过清晰的接口和流程将它们串联，又能解决复杂问题。从简单的、定义明确的表格类型开始，逐步增加对复杂情况（如合并报表、附注）的处理能力，是实践中行之有效的迭代路径。在这个过程中，对业务逻辑的深度理解，往往比模型本身的微调更为重要。