在没有基准测试的情况下如何测试 AI 智能体 — Nathanael Weill,加拿大航空

원제 · How to Test AI Agents When No Benchmark Exists — Nathanael Weill, Air Canada

19:503분 읽기AI Engineer2026. 10. 22.컴퓨터/소프트웨어 · 경영/리더십

핵심 요약

通过将传统流程倒置并利用自动化代码检查来生成测试集,开发团队无需依赖领域专家或公开基准测试,即可实现高频评估并持续提升人工智能智能体的准确率。

하이라이트

  • 构建电信问答系统和加拿大航空的供应商合同分析智能体时,团队均面临无法接触领域专家以及缺乏公开基准测试的核心痛点。

  • 将检索增强生成(RAG)的流程倒过来,即先从页面生成问题,再让智能体寻找答案并与原始页面对比,能用代码进行自动化评分。

  • 采用基于代码的评分机制后,评估频率从每周一次大幅提升至每天几十次,使团队能够快速推进并清晰观察到准确率的上升轨迹。

  • 在供应商合同分析项目中,团队尝试了五种测试技术,包括利用模板填充生成合同、刻意破坏已签署合同来检测缺失条款等。

  • 相比于引入大模型作为裁判带来的测试噪音,依赖精确匹配和代码检查的评估方式速度更快且更具可靠性。

타임라인

  1. 缺乏基准测试与专家资源的痛点

    加拿大航空的业务领域庞大,运营、企业、商业和常客计划等细分领域各自面临独特的挑战。构建人工智能智能体时,由于缺乏公开基准测试,加之领域专家时间宝贵且接触有限,导致无法对智能体进行有效的评分。在之前的电信项目开发中,团队由于预算限制,每周只能组织一次由专家面对面评判聊天机器人表现的会议,这使得试验周期极长,无法支撑快速迭代。

    • 团队在交付人工智能解决方案时,往往缺乏可依赖的公开基准测试。
    • 数据科学家和人工智能工程师并非领域专家,且很难频繁接触到忙于自身业务的领域专家。
    • 在早期电信问答系统项目中,虽然成功交付了解决方案,但每周仅能通过专家会议进行一次评估的低效率限制了开发速度。
  2. 倒置问题与自动化代码评分的建立

    为了打破每周只能测试一次的僵局,团队改变了常规思路。系统首先从一个页面开始,利用大语言模型针对该页面生成一个简单的问题,随后让智能体去寻找对应答案,并将找到的内容与原始页面进行代码级别的对比。这种方法绕过了主观的人工意见,实现了评估的自动化。随着评估频次的增加,团队得以专注于调整嵌入模型、分块方式和BM25参数等真正起作用的核心环节,从而稳步提升系统的准确率。

    • 通过从页面出发让大语言模型编写问题,再用智能体寻找答案,实现了用代码进行评分的自动化评估。
    • 评估频率从每周一次跃升至每天几十次,准确率随着开发迭代不断上升。
    • 如果没有能力对智能体进行评分,就无法推动其持续优化和改进。
  3. 供应商合同分析智能体的五种测试技术

    面对加拿大航空复杂的供应商合同分析项目,由于缺乏成对的历史合同版本控制,团队无法直接使用历史决策进行对比。为此,团队尝试了五种替代技术。第一种是利用规则生成合同来测试违规情况;第二种是拿一份完好的已签署合同刻意移除部分条款,以此检测智能体是否能敏锐识别出缺少的内容;第三种是通过改变供应商名称或重排条款顺序等无关因素来验证输出的稳定性;第四种则是复用专家手头的模板并为其填充不同的值数组以生成海量测试用例。这些方法大多可以通过纯代码进行检查,无需引入大模型裁判。

    • 加拿大航空的供应商合同分析任务包含识别条款、寻找支持文档、编写修改案和分类等多个步骤。
    • 团队开发了五种不同的测试技术,包括利用历史决策对比、基于已知规则生成合同、破坏已签署合同、改变无关变量以及利用模板生成测试数据。
    • 其中将已签署合同移除条款并让智能体检测缺失的方法,成为了最强大的测试基准之一。
  4. 避免大模型裁判并利用反馈优化测试

    在对比了多种评分类别后,团队发现精确匹配和代码检查的运行速度极快且稳定。相比之下,大模型裁判带来了比智能体自身更多的噪音,其调试成本极其高昂。最终的闭环逻辑在于:利用生成的测试来驱动智能体改进,并从真实反馈中提炼出更好的测试和提示词,形成持续演进的循环。测试的意义不仅在于决定产品是否能够发布,更在于为开发者提供全方位的支持工具。

    • 使用大模型作为裁判会引入大量噪音,其解决难度甚至不亚于正确解决任务本身。
    • 真实的专家反馈不应用于直接修复智能体,而应用于生成更好的测试用例和提示词。
    • 生成的测试不仅是产品发布的把关标准,更是支持开发者持续迭代的底层工具。

설명

Nathanael Weill leads a team building AI agents at Air Canada, where tasks are so specific there's no public benchmark and domain experts have little time to grade results. His fix is to write the answer first: start from a known answer, generate the input from it, and check whether the agent finds its way back. He shows how that took a past RAG project from one expert-graded test a week to dozens of automated tests a day, then applies it to a supplier-contract review agent with five ways to build a test set: past decisions, planted rule violations, removed clauses, changes that shouldn't matter, and contract templates with filled-in blanks. He also explains why he avoids LLM judges whenever code can check the answer. Chapters: - 00:00 Intro - 00:47 No benchmark, no experts - 01:41 A lesson from a telecom RAG project - 04:43 Weekly expert reviews were too slow - 05:38 Flip it: write the answer first - 06:33 From one test a week to dozens a day - 07:30 Supplier contract review - 10:08 How the contract agent works - 10:39 Five ways to build a test set - 12:31 Planting rule violations - 13:39 Removing clauses - 14:42 Changes that shouldn't matter - 15:38 Templates with blanks - 16:39 Avoid LLM judges when code can check - 18:07 Use expert feedback to build better tests Nathanael Weill, Air Canada: https://www.aircanada.com Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!

이 영상에 대해 글쓰기