[Paper] 工具感知规划在 Contact Center AI 中：通过血缘引导的查询分解评估 LLMs

Source: arXiv - 2602.14955v1

Overview

本文介绍了一套面向特定领域的基准，用于评估大型语言模型（LLM）在呼叫中心环境中生成工具感知执行计划的能力。通过将商业智能问题拆解为一系列调用结构化工具（例如 Snowflake 上的 Text‑to‑SQL）和非结构化工具（例如对通话记录进行检索增强生成）的具体步骤，作者揭示了当 LLM 充当自主代理时的当前优势与盲点。

关键贡献

• 基于参考的评估框架
  • 两种评估模式：一种是覆盖七个维度（工具‑提示对齐、查询遵循、步骤可执行性等）的度量逐项评分器，另一种是一次性的人类式匹配评估器。
• 迭代式数据整理流水线
  • 一个 评估器 → 优化器 循环，自动将原始 LLM 生成的计划精炼为高质量的计划谱系（有序修订），显著降低人工标注工作量。
• 大规模实证研究
  • 对 14 种 LLM（Claude、GPT‑4、Llama、Mistral 等）在不同模型规模和系列上进行基准测试，分别评估使用和不使用计划谱系提示的情况。
  • 发现系统性失效模式：复合查询以及超过四步的计划（大多数真实世界查询需要 5‑15 步）。
  • 综合指标最高得分：84.8 %（Claude‑3‑7‑Sonnet）。
  • 一次性 “A+” 匹配率最高：49.75 %（o3‑mini）。

方法论

1. 任务定义 – 目标使用场景是呼叫中心分析师提出数据驱动的问题（例如，“上个季度关于账单的来电客户的流失率是多少？”）。答案必须通过以下方式编排得到：
   • 结构化工具：针对 Snowflake 数据仓库运行的 Text‑to‑SQL 生成。
   • 非结构化工具：对通话记录嵌入进行 RAG（检索增强生成）。
2. 计划表示 – 计划是一系列步骤的列表，每一步都标注有：
   • 要调用的 工具，
   • 传递给该工具的 提示词（或查询），
   • 可选的 depends_on 链接，以实现并行执行。
3. 基于参考的评估 – 对于每个生成的计划，框架会在七个维度上与金标准参考进行比较：
   • 工具‑提示对齐（提示是否符合工具的预期输入？）
   • 查询遵循度（计划是否保持在主题上？）
   • 步骤完整性、顺序正确性、并行有效性、可执行性以及整体连贯性。
4. 计划血统创建 – 从原始 LLM 计划开始，评估器标记出缺陷；优化器（第二个 LLM 或基于规则的系统）重写计划。该循环重复，直至计划达到预设的质量阈值，形成血统的多次修订。
5. 实验设置 – 对 14 种 LLM 每种都进行两种提示方式的测试：
   • 零样本（不提供血统上下文）。
   • 血统感知（模型看到前一次修订并被要求改进）。
     性能按模型和各指标进行汇总，并在一次性评估中报告达到 “A+” 级别（极佳 / 很好）的情况。

结果与发现

• 复合查询很困难 – 当问题需要连接多个数据源或混合结构化和非结构化证据时，大型语言模型常常遗漏一步或误用工具。
• 计划长度很重要 – 第四步之后准确率急剧下降；大多数模型难以跟踪超出该点的依赖关系。
• 血统信息有选择性帮助 – 提供先前的修订可使表现最佳的模型（Claude、GPT‑4）的可执行性提升约5–7 %，但对较小模型的提升有限。
• 工具‑提示对齐是最薄弱的维度 – 即使是最好的模型也经常生成与下游工具预期模式不匹配的提示，导致运行时失败。

实际意义

1. Designing AI‑augmented contact‑center agents – Developers should limit plan depth (prefer 3–4 steps) or decompose long queries into multiple, smaller sub‑queries that can be solved independently.
   设计 AI 增强的呼叫中心代理 – 开发者应 限制计划深度（最好 3–4 步），或将长查询拆分为多个更小的子查询，以便独立解决。

2. Prompt engineering for tool use – Explicitly include tool schemas and example prompts in the system prompt; this mitigates mis‑alignment observed in the study.
   工具使用的提示工程 – 在系统提示中明确包含 工具模式 和 示例提示；这可以缓解研究中观察到的错位问题。

3. Leveraging plan lineage – When building a production pipeline, incorporate an iterative refinement loop (evaluator → optimizer) to automatically polish LLM‑generated plans before execution, especially for high‑value queries.
   利用计划血统 – 在构建生产流水线时，加入 迭代细化循环（评估器 → 优化器），在执行前自动打磨 LLM 生成的计划，尤其针对高价值查询。

4. Model selection – For mission‑critical analytics, opting for larger, instruction‑tuned models (Claude‑3, GPT‑4) yields better overall plan quality, but the cost‑benefit trade‑off must be weighed against the modest one‑shot success rates.
   模型选择 – 对于关键任务分析，选择更大、指令微调的模型（Claude‑3、GPT‑4）可获得更好的整体计划质量，但需权衡成本效益与相对有限的一次成功率。

5. Tool‑wrapper APIs – Expose a standardized “plan execution” API that validates each step’s prompt against the tool’s contract before dispatch, catching alignment errors early and providing feedback to the LLM for the next refinement pass.
   工具包装 API – 提供一个 标准化的“计划执行” API，在发送前将每一步的提示与工具契约进行验证，提前捕获对齐错误，并向 LLM 提供反馈以进行下一轮细化。

限制与未来工作

• 领域限制 – 基准聚焦于联络中心数据分析；结果可能无法直接迁移到其他领域（例如代码生成、医学问答）。
• 评估依赖参考计划 – 虽然度量评分器全面，但仍依赖人工制作的黄金参考，这可能带有偏见。
• 血统生成的可扩展性 – 优化器循环降低了人工工作量，但仍需额外计算；未来工作可探索能够内化评估者反馈的自我批评大模型。
• 工具多样性 – 仅研究了 Text‑to‑SQL 和 RAG；扩展到更异构的工具（例如仪表盘、外部 API）将检验框架的通用性。
• 实时约束 – 本研究未测量延迟；将计划验证和细化集成到低延迟生产系统仍是未解挑战。

底线：本文提供了一套具体且可复现的方法，用于衡量大模型在工具丰富的环境中充当自主规划者的能力。对于构建 AI 驱动的联络中心助手的开发者而言，研究结果强调 简短、结构良好的计划、明确的工具模式以及迭代式细化 的重要性，以弥合大模型推理与可靠工具执行之间的差距。

作者

• Varun Nathan
• Shreyas Guha
• Ayush Kumar

论文信息

• arXiv ID: 2602.14955v1
• 分类: cs.CL, cs.SE
• 出版时间: 2026年2月16日
• PDF: 下载 PDF