Asana宣布，在对StackAI的浏览器操作自动化AI进行测试时，与此前的生产配置相比，估算模型成本降至原来的1/76，处理速度提升至5倍。采用GPT‑6.1 Sol并优化浏览历史管理后，单次处理平均耗资0.47美元，耗时约4分钟。
成本降至1/76，并非只靠更换模型
解读这组数据时，需要注意的是，比较的并非单个模型的性能，而是模型与处理机制相结合后的结果。浏览器代理是一种能够读取网页并执行信息收集、填写表单等任务的AI。Asana通过收购的StackAI提供这类工作自动化服务。
测试从公开演示目录中选取了32本书，每本书收集6项信息。研究人员使用4种模型和多种设置，共进行了144次测试。最初使用的模型B，每次处理的估算模型成本超过36.21美元；仅调整处理机制，成本就降至1.24美元。进一步采用GPT‑6.1 Sol的优化配置后，成本降至0.47美元。
也就是说，即使继续使用模型B，成本也能降至原来的约1/29。76分之1这一标题背后，模型选择之前的处理设计改进发挥了重要作用。
节省成本的关键，是传给AI的浏览历史
此前的配置会缓存固定指令等内容，但不断累积的网页正文和屏幕截图历史不在缓存范围内。缓存是一种重复利用已处理输入的机制。如果无法复用历史记录，每次调用AI时都得重新发送过去的信息，并为此付费。
此外，系统几乎每个步骤都会删除旧图像并缩短文本。由于历史记录频繁改动，仅仅引入缓存很难发挥作用。删除过多信息还可能导致系统再次访问已经读过的页面。
为此，团队将历史记录保留上限从12万字提高到48万字，并将浏览历史也纳入缓存范围。屏幕截图最多累积20张，然后只保留最新的一张。相比每次都整理，改为集中整理延长了历史记录在不被改动的情况下得以复用的时间。
保留更多信息，成本也能下降
减少传给AI的信息就能降低成本。此次结果表明，仅凭这一思路无法解释代理的成本。有时，保留并复用信息、减少不必要的重复确认，反而能降低整体处理成本。
在GPT‑6.1 Sol的测试中，将历史记录保留上限调高后，再优化缓存和图像管理，单次处理的估算模型成本便从1.97美元降至0.47美元。优化后，89%的输入来自缓存，而这部分的费用仅为不使用缓存时的5%。
历史记录的数量也会影响任务完成情况。使用GPT‑6.1 Sol生成回答时，在保留上限较低的条件下，18次运行中只有3次成功；上限较高时，18次运行全部成功。测试中，这18次运行的回答均正确。
测试改进方案的工作也使用了AI
除了实际操作浏览器的GPT‑6.1 Sol，团队还使用Codex中的GPT‑6 Astra开展调查和改进工作。它分析代码结构、查找历史记录管理方面的问题、为实验重组代码，并对多种设置进行并行测试。
这并不意味着没有人工参与。StackAI首席技术官Frank Hidalgo审查了建议，并选定了待验证的修改方案。实验记录和输出也在另一个模型会话中接受了审查，并保存在Asana的开发平台Command中。修改经过工单和拉取请求流程后，部署到了生产环境。
Hidalgo表示，一项他估计手动需要1至2个月的调查工作，约一周就完成了。这个时间差是与他的估算相比，并非通过仅由人类完成同一工作所进行的对照实验得出的结果。
评估是否引入时，应同时考量成本和完成率
此次的0.47美元是估算模型成本，不是包含人力和系统运营费用在内的总成本。此外，部分基准配置触及处理次数上限，未能完成任务，因此超过36.21美元、超过22.5分钟的数值只是下限。主要比较数据是各配置运行3次的平均值，不能认为所有网页任务都能达到同样的降幅。
在优化后的配置中，模型C的成本为0.66美元、耗时3.5分钟；GPT‑6.1 Sol的成本为0.47美元、耗时约4分钟。就这项任务而言，Sol成本更低，但模型C运行更快，因此成本和速度的排名并不相同。
Asana已将此次改动应用于StackAI的浏览器操作功能。今后，该公司计划将测试纳入平台的评估功能，让客户和内部团队能够比较不同配置的成本、运行时间和回答质量。
コメント