想象一下，你现在是一名 80 年代初的程序员，刚发现了一种与其他编程语言略有不同的新语言。你不需要使用 if-else 语句和 for 循环来编写算法。相反，你只需要描述你期望的输出数据集，底层系统（即数据库）会为你将查询重写为算法，执行它，并给你所需的结果集。但是，要有效使用它，你需要对关系模型有基本的了解，起初这似乎有些反直觉，但几天后，你会觉得很自然。

然后，有一天，来自未来的同事走了过来，开始告诉你如何使用 ORM！它们让一切变得很轻松，甚至为你生成 SQL 代码。唯一的小问题是：你必须学习它们的概念，思考对象，让它们为你进行关系思考。你使用了几个星期，起初它们看起来对你很有帮助，但每当你偏离它们的示例时，它们的帮助就不那么明显了。不久，你接受了人们对 ORM 的各种批评，尽管在一个新兴时代你还在使用它们。你变得越来越沮丧，决定抛弃它们，自己编写查询。

这就是我今天对 LLM 框架的感觉。它们是过于自信的复杂性制造者，也是尚未成熟的领域的信心破坏者。它们不仅因抽象而导致死亡，最重要的是，禁止你真正了解这个崭新的领域。

以 RAG 为例。检索增强生成！听起来既科学又聪明，对吧？你一定听说过它，听起来像 LLM 时代的 SVM：一种强大且通用的算法，你根本无法自己实现，只能使用框架。

如果你揭开其神秘面纱，研究其逻辑，它其实简单明了：你像你奶奶一样使用聊天模型，但不是干巴巴地提问，而是提供一些上下文。“上下文” 也并不那么科学。你从内部数据库抓取了一些相关数据，以引导 LLM 生成针对你的回应。你将这与用户提供的查询结合起来，使用典型的字符串操作，并发送给模型。

RAG 的核心是为通用 LLM 提供特定上下文。框架试图创建通用模板，以提供帮助通用模型所需的特定上下文。看到那里的逻辑谬误了吗？是的，RAG 还有更复杂的实现，但我怀疑大多数公司还没有获取那些易于获得的成果。这句谚语依然成立：过早的优化是万恶之源。

同样的推理适用于向量嵌入、相似性评分等其他术语：从 API 用户的角度看，它们的数学基础相当简单 —— 标准的大学数学。发生巨大变化的是它们在 LLM 世界中的语义。如果你掌握了这些语义，你就能更有效地使用它们。

不过，问题是什么？难道这些不是简单的技巧吗？毕竟，天下没有免费的午餐。

的确，没有免费的午餐。但由于 LLM 如今几乎是商品，我们往往会忘记开胃菜和主菜在训练阶段就已经支付过。我们所要做的就是礼貌提问，并为合适的葡萄酒和甜点支付费用，以搭配我们的菜肴。这虽然不容易，但也不是什么难事。

看起来难的阶段是 LLM 的训练阶段，普通用户不需要担心。用户应该尽可能多地帮助 LLM 处理他们特定的用例。这就是秘诀。

混合这个秘诀与任何其他每隔几年就会委托的数据密集型项目并无太大区别。它需要规划和实验，遵循标准的最佳实践，并了解你在做什么。

在切换 LLM 时，不必过于担心可重用性和维护性。它们都有相同的 API，而且你也不会经常更换它们。你不需要为此进行类继承。当一个模型更适合你的语言时，你就会知道！你不需要为此使用框架。你当然也不希望任何版本冲突阻止你的任何步骤。

尽管框架宣扬和推销可用性和可重用组件，但它们却导致了 Java 化或 Python 化。你想要一根香蕉吗？你首先应该创造宇宙和丛林，然后使用依赖注入为每棵树提供一根香蕉，然后生成猴子来抓取和吃掉香蕉。

可重用性和解耦组件很好，但你可以通过遵循标准编程最佳实践自己做到这一点。尝试不同的模板，将它们存储在 Python 字典或甚至数据库表中，并轮换它们以查看哪种效果更好。在我与模型之间层级越多，我对进行更改的信心就越低，就更容易放弃并结束这项工作。

不过，对我来说，最关键的方面是可见性。你应该亲眼看到浮点数的嵌入数组和相似性评分的变化，以了解事物的运作方式。就像你需要运行 EXPLAIN SELECT 以弄清楚数据库优化器的工作一样。

与 LLM 相关的工作领域既不成熟又强大，有限的可见性和过多的抽象使得培养一代高级用户变得极具挑战性。