AI生成VLOOKUP嵌套SUMIFS，复杂多步公式准确率到底几成，错了谁兜底？

一、背景与问题定义：为什么“能写出来”不等于“能用”

1.1 从“公式补全”到“多步公式合成”的能力跃迁

电子表格公式生成并不是新问题。早期的公式补全依赖语法模板与函数签名匹配，本质是“检索+填空”。大语言模型介入后，任务形态发生了变化：用户用自然语言描述业务意图，模型需要完成意图解析、表结构理解、函数选择、引用构造、嵌套组织五个步骤。VLOOKUP嵌套SUMIFS之所以成为典型难点，是因为它同时触发了引用构造（查找区域与返回列）、条件聚合（多条件区域对齐）和嵌套求值顺序三个高风险环节。

笔者在工程实践中观察到一个稳定现象：单函数公式（如=SUM(A2:A10)）的可用率远高于多函数嵌套公式，而嵌套层级每增加一层，用户实际“改一改就能用”的比例就明显下降。这不是模型能力线性衰减，而是错误来源从“语法不确定”转向“语义与结构耦合不确定”。

1.2 问题定义：把“准确率”拆成可测量的量

讨论准确率之前，必须先定义“对”。在表格公式场景中，至少存在四种不同的“对”：

本文评述：公开报道中“准确率九成以上”的说法，多数对应“语法正确”或“结构等价”口径，而用户真正关心的是“执行正确”与“业务可用”。口径不统一，是AI公式能力被高估的主要认知偏差来源。笔者认为，任何声称准确率的结论，都必须同时声明口径、数据集与评测脚本版本，否则不可比较。

1.3 为什么VLOOKUP+SUMIFS是“压力测试样本”

VLOOKUP的第四个参数（近似/精确匹配）、查找列必须位于返回列左侧的约束、SUMIFS多条件区域必须同尺寸的约束，三者叠加会形成大量“看起来对、跑起来错”的组合。更关键的是，这类公式的期望结果往往依赖具体数据分布：近似匹配在有序数据上可能碰巧正确，在乱序数据上则系统性错误。这意味着仅靠静态检查无法判定正确性，必须引入执行验证。

工程提示：把“VLOOKUP嵌套SUMIFS”作为回归测试的固定样本集，比追求单次生成的惊艳效果更有价值。样本集应覆盖：查找列在右、条件区域错位、文本型数字、空值与错误值传播四类边界。

二、三层可验证性：语义、结构、执行的失败模式拆解

2.1 语义层：用户意图的欠定与歧义

语义层失败指的是“公式没错，但不是用户要的”。典型场景：用户说“按产品汇总销售额”，但未说明是“精确匹配产品名”还是“按产品编码前缀匹配”；未说明空值应计为0还是排除；未说明是否去重。模型在信息缺失时会做默认假设，而默认假设与用户心智模型不一致，就产生语义层错误。

笔者认为，语义层的根本矛盾在于：自然语言描述的信息量天然低于公式所需的信息量。解决路径不是让模型“更聪明地猜”，而是在生成前主动补齐约束——通过结构化追问或表结构自动推断，把欠定问题转化为确定问题。这一步在工程上应前置到提示词工程之外，作为独立的“意图澄清”模块。

2.2 结构层：引用、嵌套与函数约束的自洽性

结构层失败是当前最容易被自动化检测的一类。常见模式包括：SUMIFS的求和区域与条件区域行数不一致；VLOOKUP的table_array未锁定导致填充时漂移；嵌套时内层返回数组而外层期望标量；跨工作表引用缺少工作表名。这类错误可以通过解析公式为抽象语法树（AST），再做区域尺寸一致性、引用完整性、函数参数类型三类静态规则检查来拦截。

# 结构层静态检查的伪代码示意（模拟逻辑，非真实库调用）
def check_structure(ast):
    rules = [
        check_range_size_consistency,   # SUMIFS 各区域同尺寸
        check_lookup_column_order,      # VLOOKUP 查找列在返回列左侧
        check_absolute_reference,       # 填充场景下的 $ 锁定
        check_cross_sheet_qualifier,    # 跨表引用带表名
        check_nested_return_type,       # 嵌套返回值类型匹配
    ]
    return [r(ast) for r in rules]

本文评述：结构层检查的性价比最高，因为它不依赖数据、可离线批量执行、误报率可控。但必须清醒认识到，结构层全通过不等于执行正确——它只是把“低级错误”挡在门外，不能替代执行验证。

2.3 执行层：数据分布与边界条件的真实检验

执行层失败指公式在真实数据上算出错误结果。它最隐蔽，也最危险。典型诱因：文本型数字与数值型数字混排导致SUMIFS漏计；VLOOKUP近似匹配在未排序数据上返回错误行；错误值（#N/A）在嵌套中向上传播污染聚合结果；浮点精度导致相等判断失效。

执行层验证的唯一可靠方式是“沙箱执行+断言”。工程上应准备一组带期望输出的样本数据，把候选公式放入隔离的表格引擎（如本地LibreOffice Calc、Python的formulas库或云端表格API）执行，比对结果。需要注意：不同表格引擎对近似匹配、空值、错误值的处理存在细微差异，评测环境应与目标生产环境一致。

三、准确率到底几成：公开基准与工程口径的对照

3.1 公开基准能告诉我们什么

近年来表格智能评测逐步体系化。SpreadsheetBench（Ma等，2024）面向真实Excel操作任务，强调在真实工作簿上执行并校验结果；TableBench（Wu等，2024）侧重表格问答与推理；WikiTableQuestions、TabFact等更早的基准则聚焦表格理解而非公式合成。需要说明的是，这些基准的任务分布与“VLOOKUP嵌套SUMIFS”并不完全重合，直接引用其总分来推断公式生成准确率是不严谨的。

笔者综合公开文献与工程实测（模拟数据，基于内部构造的200条多步公式任务集，覆盖单函数、双函数嵌套、三函数嵌套三档）观察到一条趋势：单函数任务的结构等价率通常在较高区间，而三函数嵌套任务在“执行正确”口径下会明显下探。由于不同模型、提示策略、表结构复杂度差异巨大，任何单一百分比都不具备跨场景外推能力。下表为笔者整理的“口径—典型区间”对照，区间为模拟整合数据，仅用于说明量级关系，不作为任何模型的性能承诺。

本文评述：这张表最重要的信息不是具体数字，而是三条口径之间的落差随复杂度扩大而扩大。这意味着“语法正确率高”对复杂任务几乎没有安慰作用。工程决策应以“执行正确”为唯一验收口径。

3.2 为什么“几成”这个问题本身需要限定条件

准确率至少受五个变量影响：模型规模与训练数据覆盖、提示中是否提供表头与样例数据、是否允许模型反问澄清、是否启用工具调用（如代码解释器执行验证）、任务本身的歧义程度。脱离这五个变量谈“几成”，在方法论上不成立。笔者建议团队在内部评测报告中固定记录这五个变量，形成可比较的评测卡片。

可验证的评测卡片应包含：模型版本、提示模板版本、是否提供表结构、是否允许澄清、执行引擎版本、样本集哈希、口径定义。缺任一项，结论不可复现。

四、可落地的校验管线：从提示词到执行沙箱

4.1 管线总览：五道闸门

笔者建议把公式生成做成一条五道闸门的管线，而不是一次性的“提问—回答”。五道闸门依次为：意图澄清、表结构注入、候选生成、静态结构校验、沙箱执行校验。任何一道闸门不通过，都不进入下一道，且失败信息回灌给模型做一次受限重试。

用户意图
  │
  ├─[闸门1] 意图澄清：补齐匹配方式/空值策略/去重规则
  │
  ├─[闸门2] 表结构注入：表头、区域范围、数据类型、样例行
  │
  ├─[闸门3] 候选生成：要求输出公式 + 自然语言解释 + 假设清单
  │
  ├─[闸门4] 静态结构校验：AST规则集（区域尺寸/引用锁定/类型）
  │
  └─[闸门5] 沙箱执行校验：样本数据执行 + 期望值断言
        │
        └─ 通过 → 交付（附解释与假设）
           失败 → 受限重试（最多N次）→ 仍失败则转人工兜底

4.2 闸门1与闸门2：把欠定问题变成确定问题

意图澄清不必做成多轮对话，可以用结构化选项一次性呈现：匹配方式（精确/近似）、空值处理（计0/排除）、重复值处理（全部计入/仅首次）、金额单位（元/万元）。表结构注入则应包含表头文本、数据区域地址、每列推断类型、3至5行脱敏样例。实践表明，提供样例数据对执行正确率的提升，通常大于单纯增大模型规模。

笔者认为，闸门2的价值常被低估。模型对“列名”的理解高度依赖字面语义，而真实表头往往缩写、混用中英文、含单位后缀。把表头原文与类型显式注入，本质是把模型不擅长的“猜表结构”替换为“读表结构”。

4.3 闸门3：要求模型输出“可审计的候选”

不要只让模型输出一行公式。要求它同时输出：公式本身、逐段自然语言解释、所做假设清单、以及“如果假设不成立会怎样”的说明。这三项附加输出是后续人工兜底的关键依据，也迫使模型显式暴露其语义假设，便于闸门1回查。

4.4 闸门4与闸门5：静态规则与执行断言

静态规则集应保持精简高置信，宁可漏报不可误报，避免把正确公式拦下。执行断言则应覆盖：正常样本、边界样本（空值、文本型数字、错误值）、反例样本（应返回0或#N/A的场景）。执行引擎建议与生产环境一致；若生产是Excel，评测也应尽量在Excel兼容引擎上跑，减少引擎差异带来的假阴性。

拓展阅读可参考微软官方关于VLOOKUP与SUMIFS的函数文档，以及LibreOffice Calc的函数说明，二者对边界行为的描述差异值得对照：VLOOKUP 函数（Microsoft Support）、SUMIFS 函数（Microsoft Support）、LibreOffice Calc 函数参考。

五、兜底架构：错了谁负责，责任如何分层

5.1 责任分层的三条原则

“错了谁兜底”不是道德问题，而是架构问题。笔者提出三条原则：第一，谁引入不确定性，谁承担可验证义务——模型引入语义不确定性，就应输出假设清单；第二，谁掌握验证能力，谁承担拦截责任——平台掌握沙箱，就应在交付前拦截执行错误；第三，最终业务决策权不可外包——涉及金额、合规的公式，必须有人工确认环节。

本文评述：把兜底责任全部推给“用户自己检查”，在工程上是不可持续的，因为用户缺乏验证工具与验证动机；把责任全部推给模型厂商，也不现实，因为厂商无法获知用户的真实数据分布。合理的做法是三方分责：模型负责暴露假设，平台负责可执行的校验，用户负责业务语义的最终确认。

5.2 兜底机制的四级降级

L2的“辅助列分步方案”值得展开。当单条嵌套公式反复失败时，把VLOOKUP与SUMIFS拆成两列中间结果，虽然牺牲了紧凑性，但大幅提升了可审计性与可调试性。笔者认为，在可靠性优先的场景中，“拆开写”不是退步，而是正确的工程取舍。

5.3 可观测性：把失败变成资产

兜底架构必须配套日志：记录每次生成的提示、候选、校验结果、用户是否采纳、采纳后是否修改。这些日志构成内部评测集的持续来源。没有可观测性，兜底就只是被动救火；有了可观测性，兜底才能反哺提示模板与规则集，形成闭环。

六、对比与局限：不同技术路线的边界条件

6.1 三条技术路线的对比

当前主流路线可归为三类：纯提示词生成、检索增强（RAG）生成、工具调用（代码解释器/表格API）生成。三者在复杂多步公式上的表现差异，本质是“是否具备执行反馈”的差异。

本文评述：工具调用路线并非“更高级所以更好”，它的收益高度依赖样本数据质量与沙箱保真度。若沙箱引擎与生产引擎行为不一致，执行验证反而会制造虚假信心。因此，选择路线时应先评估“验证基础设施成熟度”，再决定是否上工具调用。

6.2 局限与未解问题

第一，语义层澄清的交互成本与用户体验存在张力，过度追问会劝退用户。第二，执行验证依赖样本数据，而用户往往不愿提供真实数据，脱敏样本的分布偏移可能导致漏检。第三，不同表格引擎的边界行为差异尚无统一规范，跨引擎可移植性差。第四，公开基准与真实业务任务的分布差距仍然显著，基准分数不能直接映射到业务可用率。

笔者认为，短期内最务实的改进不是追求“一次生成即正确”，而是把交互设计成“生成—验证—修正”的短循环，让用户在低成本下完成最终确认。这比任何单点准确率提升都更能改善实际体验。

七、结论与展望：把“生成”降级为“候选”，把“验证”升级为基础设施

回到标题的问题：复杂多步公式准确率到底几成？严谨的回答是——在未声明口径、数据集与验证条件的前提下，这个问题没有可比较的答案；在“执行正确”口径下，三函数嵌套任务的准确率显著低于单函数任务，且对表结构注入与执行反馈高度敏感。错了谁兜底？答案是分层兜底：模型暴露假设、平台执行校验、用户确认语义，高风险场景强制人工复核。

展望未来，笔者认为三个方向值得投入：其一，公式生成的“可验证中间表示”（如规范化AST+区域约束）有望成为行业通用接口；其二，表格引擎的沙箱标准化将降低执行验证的工程成本；其三，面向公式任务的细粒度基准需要补充“多步嵌套+真实表结构”的分布，以纠正当前评测的乐观偏差。

对从业者的操作建议可以浓缩为四步：先建样本集与评测卡片，再上静态校验，然后接执行沙箱，最后设计分级兜底与日志闭环。顺序不要颠倒——没有评测口径的“准确率优化”，只是在优化一个无法验证的数字。

主要参考文献

1. Ma Y, et al. SpreadsheetBench: Towards Challenging Real-World Spreadsheet Manipulation Tasks. 2024.（arXiv 预印本，任务定义与评测协议）
2. Wu Z, et al. TableBench: A Comprehensive and Challenging Benchmark for Table Question Answering. 2024.
3. Microsoft. VLOOKUP 函数官方文档. Microsoft Support, 2024.
4. Microsoft. SUMIFS 函数官方文档. Microsoft Support, 2024.
5. The Document Foundation. LibreOffice Calc 函数参考. 2024.
6. Chen W, et al. Program-of-Thoughts Prompting for Numerical Reasoning. 2023.（工具调用与执行反馈相关方法）
7. Gao L, et al. Retrieval-Augmented Generation for Large Language Models: A Survey. 2023.
8. 笔者整理. 多步公式任务内部评测集（模拟数据，200条，含单/双/三函数嵌套三档，预处理：脱敏表头、统一区域地址、标注期望输出）. 2025.
9. 笔者整理. 公式生成校验管线工程笔记（含静态规则集与沙箱断言设计）. 2025.

说明：文中涉及的内部评测数据均为模拟整合数据，用于说明量级与趋势，不代表任何具体模型的性能承诺。公开基准的引用请以原始论文与官方仓库为准。