Brainbase 如何将竞品价格采集智能体的准确率从 41% 提升至 97%

我是 Brainbase 的技术团队成员 Milind Sunil Shah。我们帮助企业部署和管理内部智能体。我将介绍如何通过反复测量与迭代，为 Domino’s 改进一个后台智能体。

客户希望知道附近竞争对手的最低价格：既包括官网，也包括配送应用，并区分有无促销。此前分析师需要手动选择正确的门店、履约方式和优惠，再填写表格。任何一步出错，都可能让看似完整的单元格实际错误。

智能体需要完成相同流程、记录来源，并将不确定项交给分析师。根据我们的项目测量，第一版准确率为 41%，到第十一版达到 97%；每个来源的成本从 2 美元降至 1 美元，每次运行从 129 分钟降至 71 分钟。我们调整的是指令、技能和操作手册，而非模型。

我们的六步流程是：启动、定义术语、建立基准和评估、构建范围狭窄的首版智能体、迭代，以及交付。这让工作可以被测量，也使我们改进整个运行过程，而不是把首版当成最终产品。

启动时要与最终用户明确任务、人工签核内容、当前时间与成本、所需准确率、谁判断结果，以及智能体不能自行假设或执行什么。对于 Domino’s，目标是以可重复的方式采集本地竞品价格，同时保留对边缘情况的判断。

分析师此前每天约花两小时主动整理表格，每个单元格都要检查。我们的目标是在尽量降低来源成本和运行时间的同时保持高准确率，由分析师签核并处理标记出的情况。项目开始时，能否自动搜索折扣都还不确定。

术语体系定义智能体需要掌握的概念和规则：采集什么、答案来自哪里、写到哪里，以及无法核实时怎么办。没有定义的术语可能让智能体自行猜测。定义应反映实际分析师的工作方式。

我们提供一张目标表，列出商品、竞品、履约方式和来源。一个示例中的商品原价划线为 24 美元，促销价为 19 美元。规则要求记录客户结账时支付的价格。观察表保存选定价格、原价和来源，因此错误单元格可以追溯到页面和规则。

其他规则来自真实失败轨迹：定义大披萨或套餐的范围，区分配送与自取，计算百分比折扣，以及无法核实时记录缺口而不是猜测。这些定义成为工作系统的一部分。

建立基准时，应索取已有答案的历史案例，并确定哪些可以离线或在线评估。我们从分析师的历史表格出发，尝试用网页存档重建竞争对手网站。配送应用的工作方式不同，因此我们从第一版开始保存浏览器截图，构建内部基准环境。

我们用确定性代码检查 ID 是否替换、折扣计算是否正确，以及价格相对上次变化超过 20% 时是否标记。语言模型评判器检查轨迹中商品和促销的选择；智能体评判器通过多次工具调用调查标记价格，分析师再审阅最终例外。

先交付最小但有用、从第一天就能评分的任务范围。第一版的任务是接受测量，而不是表现优秀。我们先在一个城市、一个应用中处理一个商品，随后随着基准改善，加入汉堡、自取、另一个应用和更多网站。

迭代就是评分、修复、发布：改进术语体系、基准和评估，优先处理频繁或代价高的失败，并考虑修复是否增加时间或成本。尽可能一次改变一件事，在更换模型之前先修复指令。

有一次智能体沿链接直接找到大披萨，看见价格后就停止了。人工检查发现同一页面下方还有 21 美元的优惠。修复很简单：不要在链接定位的区域停下，而要检查整页的适用优惠。

另一次，促销价格藏在 26 张图片中。智能体第 13 分钟找到正确卡片，却继续放大，最终在第 15 分钟被人工停止。工程师检查轨迹和页面后，要求它先看 HTML DOM、图片标题和文本，并设定放大上限。

在这个案例中，该改动使图片读取次数降至三分之一，成本下降超过一半，并最终生成完整报告。自动评估能发现很多问题，但工程师仍需检查轨迹和浏览器工具调用，才能理解某些失败。

交付意味着交付整个改进循环：谁运行智能体、审阅输出、把修正转化为规则和基准案例，以及决定新版本何时发布。在 Domino’s，智能体按计划或邮件触发运行，分析师审阅例外，修正可加入基准。团队正将方法扩展到其他市场和工作。