如何构建能自己学习的AI系统？
当我们不再将LLM视为应用程序的整个智能，而是使其成为更大学习系统的一个组件时，会发生什么？
梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
在过去几个月里，我一直在构建一个具有三个优先事项的AI应用程序：
质量、稳健性、可访问性。
但我开始更加认真地考虑另一个约束条件：
我们如何让AI变得智能，而不会让每个请求都变得昂贵？
今天构建AI应用程序非常容易。
获取一个LLM API。
添加系统提示。
添加一些上下文。
连接一些工具。
围绕它构建一个UI。
你就有了一个AI应用程序。
这种方法完全没有问题。事实上，这就是许多有用的AI产品的构建方式。
但在构建自己的系统时，我开始思考一个不同的问题：
当我们不再将LLM视为应用程序的整个智能，而是使其成为更大学习系统的一个组件时，会发生什么？
这个问题引导我走向强化学习、决策策略、上下文选择、自适应路由，以及最重要的——学习如何智能地使用LLM。
1、AI包装器问题
让我们从经常被误解的事情开始。
AI包装器本身并不是坏的。
包装器可以通过将现有模型与以下内容结合来提供巨大价值：
- 更好的提示
- 检索
- API
- 工具
- 记忆
- 结构化输出
- 特定于应用程序的工作流程
- 良好的用户体验
问题不在于包装器本身。
问题在于假设在LLM周围添加更多层就意味着应用程序本身在学习。
考虑一个简单的架构：
用户
↓
提示
↓
上下文
↓
LLM
↓
响应
我们可以使这个架构变得更加复杂：
用户
↓
提示
↓
RAG
↓
向量数据库
↓
工具 / API
↓
LLM
↓
响应
现在我们有了一个强大的应用程序。
但问问自己：
如果同样的情况明天再次发生，会发生什么？
如果系统不记住结果或不根据反馈改变其决策策略，它基本上是在再次执行预定义的工作流程。
系统可能有记忆。
它可能有检索。
它可能有工具。
但这并不一定意味着它学习了。
2、提示 ≠ 学习
这种区别可能是我思考中最重要的一个。
通过提示，我们基本上告诉模型我们希望它做什么。
例如：
如果用户询问X，
从Y检索信息，
然后使用Z回答。
我们正在定义行为。
学习系统是不同的。
我们不是明确地定义每个决策，而是提供一种机制，系统可以通过它学习哪些决策能产生更好的结果。
概念上：
观察
↓
选择行动
↓
执行
↓
观察结果
↓
接收反馈
↓
更新策略
↓
下次选择更好的行动
区别很微妙但很重要。
一种方法主要说：
"遵循这些指令。"
另一种问：
"根据之前发生的事情，我现在应该更倾向于哪个行动？"
这是一个非常不同的工程问题。
3、微调 ≠ 强化学习
另一个值得区分的是微调和强化学习。
微调通常涉及使用额外的训练数据调整模型，使其行为更好地与特定任务、领域或风格对齐。
例如：
通用LLM
+
特定领域的示例
↓
微调后的模型
强化学习从另一个角度处理问题。
我们不是简单地说：
"这些是我想要的示例。"
而是可以定义一个目标并提供关于行动质量的反馈。
概念上：
状态
↓
策略
↓
行动
↓
环境
↓
奖励 / 反馈
↓
策略改进
这里的关键词是策略。
策略本质上是在给定特定状态或情况下选择行动的策略。
这就是我觉得强化学习对基于LLM的系统特别有趣的地方。
4、我们真的需要训练LLM吗？
这就是我想法改变的地方。
当人们听到"强化学习"时，他们通常立即想象：
"我们将训练整个LLM。"
但这不一定是我们需要的。
相反，我们可以将LLM视为更大决策系统内的一个组件。
例如：
┌───────────────┐
│ 用户 │
└───────┬───────┘
↓
┌─────────────────┐
│ 上下文 / 状态 │
└────────┬────────┘
↓
┌─────────────────┐
│ 决策策略 │
└────────┬────────┘
↓
┌──────────────┼──────────────┐
↓ ↓ ↓
检索 使用工具 调用LLM
│ │ │
└──────────────┼──────────────┘
↓
结果
↓
反馈
↓
策略更新
LLM不必每次都改变。
LLM周围的决策层可以学习。
这是一个更有趣且可能更实用的架构。
5、系统能学习什么？
这就是事情变得有趣的地方。
想象一个AI应用程序接收一个请求。
它有几个可能的行动：
行动1 → 直接回答
行动2 → 检索文档
行动3 → 调用外部工具
行动4 → 请求澄清
行动5 → 使用更强大的模型
行动6 → 执行更深入的推理
传统应用程序可能包含硬编码规则：
if question_is_complex:
use_big_model()
if question_is_about_documents:
use_rag()
if question_is_calculation:
use_calculator()
这些规则可以工作。
但它们最终会变得复杂。
如果系统遇到我们没有预料到的情况怎么办？
相反，我们可以允许策略学习哪些行动往往能产生更好的结果。
例如：
上下文A
→ 直接回答
→ 好的结果
→ 正向奖励
上下文B
→ 直接回答
→ 差的结果
→ 负向奖励
上下文B
→ 检索 + LLM
→ 好的结果
→ 正向奖励
随着时间的推移，策略可以学习某些状态使用检索比直接生成更好。
6、令牌效率
这是我对此方法感兴趣的主要原因之一。
AI开发中有一个常见的假设：
更多上下文 = 更好的答案。
这并不总是正确的。
假设一个应用程序有100条潜在相关信息。
我们真的需要将所有100条发送给模型吗？
也许只有10条重要。
其他90条增加：
- 输入令牌
- 延迟
- 成本
- 处理需求
- 潜在的干扰
- 上下文复杂性
所以不是：
检索所有内容
↓
将所有内容发送给LLM
↓
希望模型能弄清楚
我感兴趣的是：
检索候选内容
↓
评估相关性
↓
选择有用的上下文
↓
只发送重要的内容
↓
生成响应
最终，选择机制本身可以从反馈中改进。
7、更多令牌 ≠ 更多智能
这可能是我在构建AI应用程序时遇到的最大误解之一。
如果我们给模型大量的上下文，我们并不一定使系统更智能。
我们可能只是使它更昂贵。
考虑这两种方法。
方法A
100个文档
↓
50,000个令牌
↓
LLM
↓
答案
方法B
100个文档
↓
相关性选择
↓
8个有用的文档
↓
4,000个令牌
↓
LLM
↓
答案
如果方法B产生相同或更好的结果，那么额外的46,000个令牌不是智能。
它们是开销。
这就是为什么我认为令牌效率应该被视为工程目标，而不仅仅是计费问题。
8、LLM作为工具
这也改变了我对LLM的看法。
不是：
"LLM就是应用程序。"
我更喜欢：
"LLM是应用程序可用的工具之一。"
系统可以决定：
我需要在这里使用LLM吗？
如果需要：
哪个模型？
多少上下文？
我应该检索一些东西吗？
我应该调用工具吗？
我应该更深入地推理吗？
我应该使用更便宜的模型吗？
我应该升级到更强大的模型吗？
这创造了额外的智能层。
模型生成。
系统决定何时以及如何进行生成。
9、一个可能的架构
我有兴趣探索的系统看起来像这样：
用户
│
▼
┌─────────────────┐
│ 状态 / 上下文 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 决策策略 │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
检索 工具 模型
│ │ │
│ ┌────┴────┐ ┌───┴────┐
│ │ API │ │ 小型 │
│ │ 搜索 │ │ 大型 │
│ │ 数据库│ │ 专家 │
│ └─────────┘ └────────┘
│ │ │
└──────────────┼──────────────┘
▼
结果
│
▼
┌─────────────────┐
│ 反馈 / 评估 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 策略学习 │
└────────┬────────┘
│
└──────────► 更好的决策
有趣的部分不一定是单个组件。
我们已经有了LLM。
我们已经有了向量数据库。
我们已经有了API。
我们已经有了智能体和工具调用。
有趣的是连接它们的反馈循环。
10、强化学习适合的位置
强化学习可以潜在地应用于决策层。
例如，假设状态是：
用户查询
+
先前的对话
+
可用的上下文
+
系统状态
+
历史结果
策略选择：
行动 = 检索上下文
系统执行检索并生成答案。
然后我们评估结果。
也许用户接受答案。
也许他们再次询问同样的问题。
也许他们更正答案。
也许评估者给出高分。
也许任务失败。
这些信号可以贡献给奖励。
概念上：
状态
↓
策略
↓
行动
↓
结果
↓
奖励
↓
策略改进
目标不是完美地预测未来。
而是提高在未来情况下选择更好行动的概率。
11、强化学习不会"预知未来"
这种区别很重要。
有时关于AI学习的讨论使强化学习听起来几乎是神奇的。
它不是。
RL系统不会突然理解未来。
它从经验中学习。
如果一个行动在特定情况下反复产生好的结果，系统可以学习偏好该行动。
如果另一个行动始终表现不佳，策略可以学习避免它。
所以目标更接近：
过去的经验
↓
学习模式
↓
估计有用的行动
↓
做出更好的未来决策
而不是：
训练一次
↓
预知未来
因此，学习系统的质量在很大程度上取决于反馈和奖励设计的质量。
12、最困难的部分：奖励设计
这就是想法变得比简单地集成API困难得多的地方。
如果我告诉一个系统：
"最大化奖励。"
我仍然留下一个巨大的问题没有回答：
什么是好的结果？
假设系统生成一个答案。
我们应该奖励：
- 准确性？
- 用户满意度？
- 速度？
- 低令牌使用量？
- 低成本？
- 完整性？
- 安全性？
- 简洁性？
通常，答案是：
所有这些的某种组合。
例如，我们可以在概念上定义：
奖励 =
准确性
+ 用户满意度
+ 任务成功
- 令牌成本
- 延迟
显然，真正的系统需要更仔细的标准化、加权和评估。
但这说明了根本挑战。
如果你只优化令牌使用量，系统可能变得过于激进地避免计算。
如果你只优化答案质量，它可能为所有内容使用昂贵的模型和巨大的上下文。
真正的挑战是找到正确的平衡。
13、效率不应该破坏质量
这是我思考中的一个重要约束。
我不想要一个便宜但产生平庸结果的系统。
目标不是：
"不惜一切代价使用更少的令牌。"
目标是：
"在实际改善结果的地方花费计算。"
对于简单的请求：
小型模型
+
最小上下文
+
直接回答
对于复杂的请求：
检索
+
更多上下文
+
工具使用
+
更强大的模型
+
更深入的推理
系统应该理想地学习这种区别。
这比强制每个请求通过相同的管道更有趣。
14、自适应模型路由
这个想法也可以扩展到模型选择。
想象拥有：
小型 / 便宜的模型
中型模型
大型 / 昂贵的模型
专用模型
传统的实现可能总是使用最大的模型。
这可以工作，但很昂贵。
另一种实现可能总是使用最便宜的模型。
这节省了金钱但可能损害质量。
自适应系统可以潜在地学习：
简单任务
→ 小型模型
中等任务
→ 中型模型
复杂任务
→ 大型模型
专用任务
→ 专用模型
决策不一定基于手动编写的规则。
策略可以从结果中学习。
同样，目标不是消除昂贵的模型。
而是在它们真正值得成本时使用它们。
15、这改变了"AI应用程序"的定义
这可能是对我来说最大的概念转变。
我过去主要将AI应用程序视为：
应用程序
+
LLM
+
提示
+
工具
现在我越来越多地将它们视为：
应用程序
+
模型
+
工具
+
记忆
+
状态
+
决策策略
+
反馈
+
评估
+
学习
模型仍然极其重要。
但它成为整体智能的一部分。
系统本身负责决定如何使用这种智能。
16、是什么使这变得困难？
有几个问题使这比构建简单的LLM应用程序困难得多。
16.1 奖励设计
糟糕的奖励产生糟糕的行为。
如果系统因最小化令牌而获得奖励，它可能会牺牲质量。
如果它仅因用户满意度而获得奖励，它可能会过度使用昂贵的计算。
目标需要反映实际目标。
16.2 反馈质量
并非每个用户交互都提供有用的反馈。
用户离开应用程序并不一定意味着答案不好。
用户说"谢谢"并不一定意味着答案完美。
反馈需要仔细解释。
16.3 探索与利用
学习系统需要平衡：
利用： 使用已经有效的策略。
探索： 尝试可能更好的新策略。
过多的利用可能使系统陷入平庸的策略。
过多的探索可能使其变得不可预测。
16.4 评估
你不能简单地说：
"模型似乎更好。"
你需要可测量的评估。
例如：
任务成功率
答案质量
令牌使用量
延迟
每个成功任务的成本
工具准确性
检索精度
失败率
系统需要根据真正重要的指标进行改进。
16.5 安全性和约束
学习系统不应该被允许无边界地优化。
应该围绕以下方面设置约束：
- 安全性
- 隐私
- 工具访问
- 成本
- 数据使用
- 允许的行动
- 可靠性
学习不会消除工程规则。
它改变了某些决策发生的地方。
17、我不认为更大的模型是唯一的答案
AI行业可以理解地高度关注模型规模。
更大的模型。
更多的参数。
更大的上下文窗口。
更多的计算。
更好的推理。
这些改进极其重要。
但智能还有另一个维度：
我们如何有效地使用已有的智能？
想象两个系统。
系统A：
巨大的模型
+
巨大的上下文
+
每个工具
+
最大计算
系统B：
适当的模型
+
相关的上下文
+
相关的工具
+
自适应计算
+
反馈
系统B可能没有更多的原始智能。
但它可能是一个更好的系统。
这是我觉得有趣的方向。
18、未来：更大的模型还是更智能的系统？
我不认为答案必须是其中之一。
我们可能会继续构建能力越来越强的基础模型。
但我相信围绕这些模型构建的系统将变得同样重要。
下一代AI应用程序可能不会简单地问：
"我应该使用哪个LLM？"
他们可能会问：
"解决这个特定问题的最佳方式是什么？"
答案可能涉及：
检索？
推理？
使用工具？
询问用户？
使用小型模型？
使用大型模型？
使用更多上下文？
使用更少上下文？
再试一次？
停止？
这个决策本身可以成为一个学习问题。
19、我当前的观点
我并不是试图构建另一个仅仅将LLM放在漂亮UI后面的应用程序。
我有兴趣构建一个系统，其中LLM是更大架构的一个组件。
一个可以：
观察 → 决策 → 行动 → 评估 → 学习 → 改进
的系统。
重要的是，目标不仅仅是让AI更强大。
而是让它：
更具适应性。
更高效。
更稳健。
更易于访问。
如果AI系统可以学习它不需要20,000个令牌来解决只需要2,000个令牌的问题，那不仅仅是成本优化。
那是更好的工程。
如果它能学习工具何时真正有用，而不是每次都调用它，那是更好的决策。
如果它能学习更强大的模型何时值得额外成本，那是自适应智能。
如果它能根据真实结果改进这些决策，而不是要求我们手动编码每个可能的场景，那么我们就超越了简单地包装AI模型。
我们正在构建一个学习如何使用智能的系统。
20、最后的思考
也许AI的未来不仅仅是构建更大的模型。
也许也是构建知道何时、何地以及如何使用这些模型的系统。
模型提供能力。
架构提供控制。
反馈提供学习。
策略决定系统如何发展。
不仅仅是生成的AI。
学习如何做出更好决策的AI。
原文链接：Beyond AI Wrappers: Building AI Systems That Learn to Make Better Decisions
汇智网翻译整理，转载请标明出处
