办公自动化场景下大模型选型的综合评估方法

一、为什么批量办公场景需要单独评估

选型时，很多团队习惯参考榜单上的最高分。但批量办公任务的特点是数量大、重复性强、对单位成本敏感。一份合同可能要抽取二十个字段，一批截图要核对表格数据，一周内可能要处理几千条工单。这类任务不需要模型在最难的问题上拿满分，而需要它在大量常规样本上稳定、便宜、快速地完成。

因此，选型问题应从”能不能做”转向”完成一个业务任务的总成本是多少，成功率如何”。这个转变会改变评估指标的优先级，也会改变最终的模型组合方式。

二、评估维度拆解

1. 单位任务成本

单价只是成本的一部分。一次任务的实际花费由三部分决定：输入长度、输出长度，以及失败后的重试次数。两个单价相同的模型，如果其中一个需要更多轮次才能完成任务，它的实际成本就更高。评估时应以”完成一个业务任务的平均花费”为口径，而不是只比较每百万 Token 的价格。

2. 界面与视觉理解能力

办公自动化常涉及读取截图、识别表格、定位按钮、理解图表。评估时应把能力拆成三类分别测量：

• 静态图像识别：文字、表格、图表的读取准确率。
• 界面元素定位：按钮、输入框的位置与功能语义是否判断正确。
• 连续操作规划：多步骤操作中能否保持上下文状态，例如先填写表单、再提交、最后核对结果。

三类能力在同一模型上的表现可能差异很大。用一个综合分数代替三项指标，容易掩盖短板。

3. 推理强度与成本的权衡

多数模型服务允许调整推理强度。低强度响应快、费用低，适合规则明确的抽取和分类。高强度适合需要多步推导的任务，但耗时和费用都会增加。关键问题是：提高推理强度带来的准确率增益，能否覆盖增加的成本。

实践中，建议按任务类型分别设置推理档位，而不是全局统一。例如，格式化抽取用低档位，异常工单的根因分析用高档位。

4. 端到端延迟与吞吐

交互场景关注首字延迟，批处理场景关注整体吞吐。端到端耗时包括模型生成时间、工具调用时间、页面加载时间和排队时间。测速时应统计分位数，例如 P50 与 P95，而不是只看平均值。平均值会掩盖少量超长请求对整体进度的拖累。

5. 输出可靠性与错误率

错误大致分为两类：

• 格式错误：JSON 结构不合法、必填字段缺失、枚举值越界。
• 内容错误：事实、数值或判断结论不正确。

格式错误可以通过结构化输出约束和程序化校验显著降低。内容错误则需要抽样复核。错误率应按任务类型和字段分别统计，否则一个整体数字难以指导改进。

6. 能力边界

中档模型适合大批量、流程明确、容错可控的任务。涉及复杂推理、财务或法律结论、高风险操作的任务，应交由更强的配置或人工复核。明确边界比追求统一方案更重要。边界可以通过评测集中的失败样本来确定。

三、按单位成功任务计算成本

单次调用成本可按下式估算：

• 单次调用成本 = 输入 Token 数 × 输入单价 ÷ 1,000,000 + 输出 Token 数 × 输出单价 ÷ 1,000,000
• 单位成功任务成本 = 单次任务平均调用成本 × 平均调用次数 ÷ 任务成功率

分母中的成功率是关键。成功率低的配置，即使单价低，也可能因为反复重试而更贵。

下面的函数可以作为计算模板：

def cost_per_successful_task(
    input_tokens: int,
    output_tokens: int,
    input_price_per_m: float,
    output_price_per_m: float,
    success_rate: float,
    avg_calls_per_task: float = 1.0,
) -> float:
    """计算单位成功任务的成本，单位与单价保持一致。
    input_price_per_m、output_price_per_m：每百万 Token 的单价。
    success_rate：任务成功率，取值范围为 (0, 1]。
    avg_calls_per_task：单个任务平均调用次数，包含重试。
    """
    if not 0 < success_rate <= 1:
        raise ValueError("success_rate 必须在 (0, 1] 之间")
    per_call = (
        input_tokens * input_price_per_m + output_tokens * output_price_per_m
    ) / 1_000_000
    return per_call * avg_calls_per_task / success_rate

下面用示意数据说明该函数的用法。数值仅用于演示，不代表任何真实产品。

• 配置 A：输入 3000 Token，输出 500 Token，输入单价 0.5，输出单价 2，成功率 40%。
• 配置 B：输入 3000 Token，输出 500 Token，输入单价 1，输出单价 5，成功率 95%。

配置 A 的单次调用成本为 0.0025，单位成功任务成本约为 0.00625。配置 B 的单次调用成本为 0.0055，单位成功任务成本约为 0.00579。尽管 A 的单价更低，但由于成功率过低，它的实际成本反而更高。

四、搭建小型评测集

评测集是选型结论的依据。建议按以下步骤构建：

1. 从真实业务中抽取 200 至 500 条样本，覆盖常见类型和典型边缘情况。
2. 为每条样本定义可自动校验的判定标准，例如字段完全匹配、输出可被解析、界面操作后页面状态符合预期。
3. 固定提示词版本、模型版本与推理档位，并记录时间戳，保证结果可复现。
4. 对每个候选配置运行全部样本，统计成功率、平均 Token 用量、P50 与 P95 延迟，并计算单位成功任务成本。
5. 对失败样本归因，分为理解错误、定位错误、格式错误和超时四类，找出主要瓶颈。
6. 根据结果制定路由策略：简单样本走低成本配置，失败或高风险样本升级到更强配置或人工处理。

样本量也需要考虑。以 200 条样本为例，若成功率接近 50%，其 95% 置信区间的半宽约为 7 个百分点。两个配置的成功率差距小于这个范围时，不宜据此下结论，应扩大样本或增加重复运行次数。

五、落地架构建议

选型结论最终要落到系统设计中。以下是几个通用要点：

• 任务队列：批量任务先进入队列，再按优先级与并发上限消费，避免突发流量触发限流。
• 结构化输出与校验：约束输出结构，校验失败时自动重试一次，仍失败则转入人工处理队列。
• 分级路由：根据任务类型或置信度选择推理档位，简单任务和复杂任务分开处理。
• 日志服务与监控告警：记录每次请求的 Token 用量、耗时、错误码和成功与否，并对成本与错误率设置阈值告警。
• 回退策略：主配置超时或不可用时切换到备用配置，并记录切换原因，便于事后分析。
• 权限控制：界面操作类任务在受限环境中运行，使用最小权限的账号访问数据，涉及删除、发送、付款等操作时必须经过人工确认。

如果团队使用百度智能云的相关服务，可以直接复用其对象存储、消息队列和日志服务等通用能力，无需自行搭建同类组件。

六、常见误区

1. 用单价代替单位任务成本。忽略成功率与重试次数，会低估实际开销。
2. 用一次运行的结果代表稳定性。同一配置多次运行，结果可能有明显波动，应统计多次结果。
3. 全局统一推理强度。简单任务会浪费费用，复杂任务又可能准确率不足。
4. 忽略人工复核成本。只计算模型调用费用，会让方案看起来比实际便宜。
5. 只看平均延迟。少量超长请求会拖慢整个批次，应同时关注分位数指标。

七、总结

办公自动化场景的选型，核心是把任务拆开，按维度测量，再用单位成功任务成本做决策。中档配置在批量、流程明确的任务中通常有较好的性价比，但它能否胜任某类任务，应由团队自己的评测数据决定。先建立评测集，再确定路由策略和边界，最后才是选择具体配置。