尽快摆脱 LLM 的束缚：不要让它承担核心业务逻辑
尽快摆脱 LLM 的束缚
2025年4月1日
不要让 LLM 做出决策或实现业务逻辑：它们在这方面很糟糕。我为一款在线游戏构建 NPC，经常有人问我“你是如何让 ChatGPT 做到这一点的？” 答案总是不变：“我没有，而且你也不应该这样做”。
在大多数应用中，LLM 应该只是用户和应用程序逻辑 API 之间的用户界面。LLM 不应实现任何逻辑。尽快摆脱 LLM 的束缚，并尽可能长时间地保持这种状态。
为什么？
用一个虚构的例子可以最好地说明这一点：你想编写一个可以通过 WhatsApp 访问的下棋机器人。用户发送他们想要做什么的描述（“用我的主教吃掉骑士”），机器人与他们对战。
你能让 LLM 负责维护棋盘状态并令人信服地进行游戏吗？ 可能，也许。 你会这样做吗？ 当然不会，原因如下：
- 性能：LLM 能够下棋已经令人印象深刻了，但它们在这方面很糟糕（截至 2025-04-01）。 专门的象棋引擎始终会是更快、更好、更便宜的棋手。 即使是像 Stockfish 这样集成了神经网络的现代象棋引擎，仍然是具有明确定义的输入和评估函数的专用系统，而不是试图通过文本来维护游戏状态的通用语言模型。
- 调试和调整：不可能推理和调试 LLM 为什么 做出某个决定，这意味着如果你需要调整它们，就很难改变 它们如何 做出这些决定。 你不理解它在多维语义空间中到达答案的旅程，而且它也很难解释。 即使是像象棋引擎中那样的专用神经网络，在可观察性方面也可能具有挑战性，而通用的 LLM 简直是一场噩梦，尽管 Anthropic 在这方面取得了巨大进展
- 以及其他…：测试 LLM 的输出比单元测试已知的代码路径困难得多； LLM 在数学方面比你的 CPU 差得多； LLM 在选择随机数方面不够好； 版本控制和审计变得更加困难； 监控和可观察性变得很痛苦； 通过自然语言进行状态管理是脆弱的； 你受制于 API 速率限制和成本； 当一切都通过提示流动时，安全边界变得模糊。
例子
象棋的例子说明了将 LLM 用于核心应用逻辑的根本问题，但这一原则远远超出了游戏范围。 在任何精度、可靠性和效率都很重要的领域，都应遵循相同的方法：
- 用户说他们想用他们的 vorpal sword 攻击玩家 X？ LLM 不应该是确定用户是否拥有 vorpal sword 或结果会是什么的系统：LLM 负责将用户提供的自由文本转换为 仅此而已 的 API 调用，并将结果转换为用户的文本
- 你正在构建一个应该响应用户报价的谈判代理？ LLM 不负责谈判，只负责打包它，将其传递给谈判引擎，并告诉用户结果
- 你需要随机选择如何响应用户？ LLM 不能选择
提醒 LLM 擅长什么
虽然我专注于 LLM 不应该做什么，但同样重要的是要了解它们的优势，以便你可以适当地利用它们：
LLM 擅长转换和分类，并且对“世界如何运作”有很好的基础，这正是你应该在流程中部署它们的地方。
LLM 擅长将“用我的剑击中兽人”转换为 attack(target="orc", weapon="sword")。 或者将 {"error": "insufficient_funds"} 转换为 “你没有足够的金币来购买它”。
LLM 擅长弄清楚用户想要做什么，并将其路由到系统的正确部分。 这是战斗命令吗？ 库存检查？ 请求帮助？
最后，LLM 擅长了解人类的概念，并且知道 “blade” 可能是一把剑，而 “smash” 可能意味着攻击。
请注意，所有这些优势都涉及转换、解释或交流——而不是复杂的决策或维护关键的应用程序状态。 通过将 LLM 限制在这些角色中，你可以在获得它们优势的同时避免前面描述的陷阱。
未来
LLM 能做什么和不能做什么一直在变化，让我想起了“God of the gaps”。 这是神学中的一个术语，其中每个神秘现象都曾经用神圣干预来解释——直到科学填补了这一空白。 同样，人们不断识别新的“仅限人类”的任务，声称 LLM 不是真正的智能或有能力的。 然后，仅仅几个月后，出现了一个新的模型，可以很好地处理这些任务，迫使每个人再次移动目标，passim 的例子。 这是一个不断变化的目标，今天看起来遥不可及的东西可能会比我们预期的更快得到解决。
因此，就像我们的象棋例子一样，我们可能很快就会得到可以相当好地处理我们上面所有例子的 LLM。 然而，我怀疑大多数缺点不会消失：你传递给它的非 LLM 逻辑将更容易推理、更容易维护、运行成本更低、并且更容易进行版本控制。
即使 LLM 继续改进，基本的架构原则仍然存在：将 LLM 用于它们最擅长的领域——接口层——并依靠专用系统来实现你的核心逻辑。