Asana宣布，在对StackAI的浏览器操作自动化AI进行验证时，与此前的生产环境配置相比，估算模型成本降至原来的1/76，处理速度提升至5倍。在采用GPT‑6.1 Sol并优化浏览历史管理的配置下，单次处理平均耗时约4分钟，成本为0.47美元。
成本降至1/76，并非仅仅因为更换了模型
理解这组数据的关键在于，比较的并非模型本身的性能，而是模型与处理机制相结合后的结果。浏览器智能体是一种能够读取网页、开展信息收集、填写表单等工作的AI。Asana通过收购的StackAI提供此类业务自动化服务。
在验证中，团队从公开演示目录中收集了32本书各6项信息。他们使用4种模型和多种配置，共进行了144次测试。最初使用的模型B，单次估算模型成本为36.21美元以上；仅重新审视处理机制，就将成本降至1.24美元。进一步采用GPT‑6.1 Sol的优化配置后，成本降到了0.47美元。
也就是说，即使继续使用模型B，成本也能降至原来的约1/29。标题所说的降至1/76，背后发挥重要作用的，是先于模型选择进行的处理设计改进。
节省成本的关键，在于传给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的浏览器操作功能。今后，公司计划将验证功能整合进平台，让客户和内部团队能够比较不同配置的成本、运行时间和回答质量。
コメント