并非一切都应以代币计费：确定性人工智能的案例 我最近与一个团队交谈，他们为一个简单的任务接入了一个代理：每天早上调用一个指标 API，重新格式化 JSON，然后将结果放入一个表格中。这个想法很好。第一天它就成功了。然后，发票来了。每天早上，这个 “简单” 的工作都在加载几千个原始 JSON 代币到上下文窗口，让一个语言模型重新格式化这些不需要推理的数据，却要为此付费。重新格式化有时也会出错，因为一个概率模型在做一个五行脚本每次都能做到的事情。上下文窗口被陈旧的数据填满，导致代理本应进行的实际推理变得更糟。这一陷阱现在几乎捕捉了每一个团队。团队将语言模型视作一个通用的运行环境。只要你能用一句话描述一个任务，你就可以提示它。但模型并不是定时任务，也不是数据库。它是一个你按代币租用的推理引擎，而最容易让你的账单迅速膨胀、输出下降的方式就是让它做一些根本不需要脑力的工作。值得学习的技能是知道什么不应该被转换为代币。 为什么“一切都是提示”的感觉很对却花费如此之多 吸引人的原因显而易见。提示是快速的。你跳过了模式设计、端点、部署。你只需询问。对于一次性任务，这确实是正确的选择。当一次性任务变成经常性工作时，问题就显现出来了。你通过模型传递的每个确定性任务都继承了三个不该具备的特性：它变得不确定，变得缓慢，变得按量计费。你现在要为每次运行支付费用，而一个定时函数本可以免费完成这些工作，并且从不出错。随后有两个症状出现，并相互加重。第一个是与错误事物成比例的成本。你的代币支出应该跟踪你所请求的判断价值。相反，它跟踪你通过模型强行推进的机械工作量。如果你每天拉取十个 API 而不是一个，你的账单就会增长十倍，即便这些拉取根本不需要智能。第二个是上下文膨胀。为了“处理”数据，团队将数据读入上下文窗口。但是，上下文窗口是有限的，而推理正是在这里发生。填充原始记录会挤出模型真正擅长的东西。质量下降，并且由于大多数服务供应商对输入代币进行计费，长上下文的成本也在同时上升。你花更多的钱却得到更差的答案。这一部分让人感到刺痛。解决此问题的分界：概率性工作与确定性工作 这里是我不断回归的思维模型。在你决定任务的运行位置之前，将每个任务分成两个桶。属于代理（概率性） 属于应用（确定性） 判断和解释 定时和经常性的任务 起草、总结、分类 API 调用和数据转换 决定该做什么以及某事是否重要 存储、检索和查询数据 处理模糊和边缘案例 必须每次运行都准确和可重复的任何事情 这个界限很简单。如果一个任务需要判断，它就应该由代理处理。如果它需要精确且可重复，它就应该在应用中。确定性是一种特性，而不是局限性。每天早上以相同方式运行的定时工作是你希望其平淡和可预测的事情。这里是整个理念的基石：你用代币构建应用一次，然后每次运行时就不再支付代币。智能集中在创建机器上。机器本身是不收费的。“学会什么不该用代币计费”是你在每个任务中都应当实践的一个纪律，而不是你一次开关的设置。 每个人都容易犯的错误：将记忆笔记作为数据库 有一种特定的错误值得单独指出，因为我看到聪明的人不断犯这个错误。人们将代理的记忆或笔记作为数据库使用。他们开始将结构化数据放入笔记中：记录、指标、管道阶段、客户名单、库存计数。这样做感觉自然，因为笔记就在那，代理已经读取了。但是，笔记并不是处理结构化数据的合适工具，原因很快就堆积起来。没有模式，因此没有东西强制一致性。没有查询，因此代理每次需要一个字段时都会读取整个备忘录到上下文中，这既慢又计费。同时，笔记随着增多而退化，因为一墙半结构化文本恰恰是一个真正的表存在的原因。现在这里是“只需使用数据库”建议中被忽略的部分，而这很重要：记忆笔记并不是问题。使用它们来完成错误的工作才是。笔记实际上是处理一整类没有干净模式且永远不会有的上下文的合适工具。偏好、语气和声音、代理所学的模式、决定及其背后的推理、塑造代理如何思考的“这是我们如何处理事务”的知识。