提示链与提示填充：使用 Gemini 2.0 Flash 优化 Llm 性能的 5 个重要见解
我以为我在“提示链”这个想法上很牛逼。
为我辩护的话，过去这曾是个必要的做法。如果你试图让一个主提示做所有事情，它会彻底失败。使用 GPT-3 时，如果你没有通过提示链构建一个深度嵌套的复杂 JavaScript对象表示法 对象，你根本就没有构建它。
GPT 3.5-Turbo 的上下文长度为 4,097，无法处理复杂提示。
但是，在我连续第五天从 OpenRouter 收到超过 $100 的费用后，我意识到我发明的独特“最先进”的提示技术现在只是一种浪费数百美元以换取更差的 LLM 准确度的方式。
我本周多天的 OpenRouter 账单高达数百美元。
提示链在 Gemini 2.0 Flash 发布后正式死去。
什么是提示链？
提示链是一种技术，其中一个大型语言模型的输出被用作另一个大型语言模型的输入。在低上下文窗口的时代，这使我们能够构建高度复杂、深度嵌套的JavaScript对象表示法。
例如，假设我们想用一个大型语言模型创建一个“投资组合”对象。
export interface IPortfolio {
name: string;
initialValue: number;
positions: IPosition[];
strategies: IStrategy[];
createdAt?: Date;
}
export interface IStrategy {
_id: string;
name: string;
action: TargetAction;
condition?: AbstractCondition;
createdAt?: string;
}
- 一个大型语言模型的提示会生成名称、初始值、头寸和策略的描述
- 另一个大型语言模型会获取策略的描述并生成名称、动作和条件的描述
- 另一个大型语言模型会生成完整的条件对象
绘制“提示链”
最终结果是尽管上下文窗口较低，仍然创建了一个深度嵌套的JavaScript对象表示法。
即使在今天，这种提示链技术仍然有一些好处，包括：
- 专业化：对于极其复杂的任务，你可以让一个大型语言模型专注于一个非常具体的任务，并解决常见的边缘情况
- 更好的抽象：提示集中在嵌套对象的特定领域是有意义的（尤其是当该字段在其他地方使用时）
然而，即使在最初，它也有缺点。维护起来要困难得多，并且需要代码来“粘合”复杂对象的不同部分。
但是，如果替代方案是完全无法创建复杂对象，那么这是你学会容忍的事情。事实上，我围绕这个建立了整个系统，并写了几十篇文章描述提示链的奇迹。
然而，在过去几天里，我注意到我的大型语言模型提供商的账单高得离谱。在调试了几个小时并查看了我这个130,000多个庞大项目的每一个角落后，我意识到罪魁祸首是我心爱的提示链技术。
一个荒谬的高API账单
我本周的Google Gemini API账单高达数百美元
在过去几周，我在NexusTrade的新用户注册激增。
我每天的用户增长
NexusTrade是一个由AI驱动的自动投资平台。它利用大型语言模型帮助人们创建算法交易策略。这是我们之前介绍的深度嵌套的投资组合对象。
随着用户的增加，活动也随之激增。人们兴奋地使用自然语言创建他们的交易策略！
使用自然语言创建交易策略
然而，我的费用随着OpenRouter的使用而飙升。在审计了整个代码库后，我终于注意到了我与OpenRouter的活动。
我对OpenRouter的日志显示了每个请求的费用和令牌数量
我们会有几十个请求，每个请求大约费用为$0.02。你知道是什么导致这些请求被创建的吗？
你猜对了。
我在代码中如何工作的提示链的图片
投资组合中的每个策略都被转发到一个创建其条件的提示。每个条件随后被转发到至少两个创建指标的提示。然后将最终结果组合在一起。
这导致可能有数百个API调用。虽然Google Gemini API以其便宜而闻名，但这个系统却导致了“千刀万剐”的情况。
解决方案就是将策略的所有上下文都放入一个单一的提示中。
“填充”创建策略的提示
通过这样做，虽然我们失去了一些可重用性和可扩展性，但我们在速度和成本上显著节省，因为我们不必不断调用大型语言模型来创建嵌套对象字段。
但我能节省多少呢？根据我的估算：
- 旧系统： 创建策略 + 创建条件 + 2次创建指标（每个策略） = 至少4个API调用
- 新系统： 创建策略 = 1个最大API调用
通过这个改变，我预计我将节省至少80%的API调用！如果平均投资组合包含2个或更多策略，我们可能会节省更多。虽然现在宣布确切的节省还为时尚早，但我强烈感觉这将非常显著，尤其是当我以同样的方式重构我的其他提示时。
简直令人难以置信。
结论思考
当我第一次实现提示链时，它是革命性的，因为它使得在有限的上下文窗口内构建深度嵌套的复杂 JavaScript对象表示法 成为可能。
这种限制不再存在。
随着现代大型语言模型拥有128,000+的上下文窗口，选择“提示填充”而不是“提示链”变得越来越合理，特别是在尝试构建深度嵌套的 JavaScript对象表示法 时。
这只是表明人工智能领域正在以惊人的速度发展。几个月前被视为“最佳实践”的东西现在已经完全过时，并且需要快速重构，以免成本激增。
人工智能竞争很激烈。保持领先，或者被抛在后面。哎呀！
