在 LLM（大型语言模型）蓬勃发展的今天，各种声称能让开发者“几分钟搭建 AI 应用”的 LLM 框架层出不穷，如 LangChain、LlamaIndex、CrewAI 等。这些框架承诺将链（Chains）、智能体（Agents）、检索器（Retrievers）、工具（Tools）和数据库无缝连接，让开发者无需深入底层细节即可快速构建应用。然而，这种看似便捷的“捷径”背后，却隐藏着巨大的风险。本文将深入探讨为什么不应该过度依赖 LLM 框架，以及如何通过掌握核心技术，构建真正可用的 LLM 应用。
抽象的代价：失去掌控
抽象是软件开发中常见的概念，旨在简化复杂性，提高开发效率。然而，过度 抽象 会导致开发者对底层机制的理解不足，最终失去对系统的控制力。在使用 LLM 框架时，开发者通常只需要调用一个 .run() 函数就能得到结果，却无法得知背后实际使用了哪些提示词（Prompts）、工具是如何排序的，以及采用了何种记忆策略。甚至连最基础的问题，例如检索时如何分块、如何嵌入，都变得扑朔迷离。
例如，假设你使用 LangChain 框架构建一个文档问答系统。你只需要简单配置几个组件，就能让系统回答用户提出的问题。但是，当系统出现错误，例如无法正确理解用户的意图，或者检索到的信息不准确时，你很难定位问题的根源。是因为提示词设计不合理？还是因为检索策略存在缺陷？由于框架的 抽象 屏蔽了底层细节，你就像一个在黑暗中摸索的盲人，难以找到问题的症结所在。
更糟糕的是，当 LLM 框架 出现 bug，或者需要进行性能优化时，你几乎无能为力。你只能等待框架的维护者修复问题，或者尝试更换其他框架，这无疑会严重影响开发效率和产品质量。
忽视核心技术：空中楼阁
LLM 框架 的另一个主要问题是，它让开发者忽视了真正让 LLM 应用工作的 核心技术。要构建一个高效、可靠的 LLM 应用，需要深入理解 token 限制、上下文窗口、提示词设计、控制流、嵌入策略、检索逻辑、缓存、并行处理和错误处理等诸多方面。
以提示词设计为例，一个好的提示词能够引导 LLM 产生期望的输出，而一个糟糕的提示词则可能导致 LLM 产生错误或无意义的结果。例如，如果你想让 LLM 总结一篇新闻报道，你可以使用以下提示词：
请总结以下新闻报道：
[新闻报道内容]
这是一个比较简单的提示词，但它并没有明确告诉 LLM 你希望它以何种方式进行总结。为了提高总结的质量，你可以添加更多信息，例如：
请总结以下新闻报道，并提取出最重要的三个要点：
[新闻报道内容]
通过明确告诉 LLM 你希望它提取最重要的三个要点，你可以引导它更加关注关键信息，从而生成更准确、更有价值的总结。
然而，如果你使用了 LLM 框架，你可能只需要简单调用一个 summarize() 函数就能得到结果，而无需深入了解提示词设计的细节。这会导致你对 LLM 的工作原理缺乏理解，无法根据实际需求调整提示词，最终构建出无法满足用户需求的 LLM 应用。
臃肿与延迟：性能瓶颈
LLM 框架 通常引入多层 抽象，这使得追踪和调试代码变得异常困难。这些框架的架构往往混乱，并且会引入大量的依赖项，每个依赖项都可能带来额外的负担。原本可以用几个干净、专注的函数完成的任务，最终变成了一个由间接调用和配置文件组成的迷宫，需要花费更多的时间来解读，甚至比直接编写核心逻辑还要耗时。
例如，某些 LLM 框架 为了实现通用性，会引入大量的中间件和插件，这些组件可能会对系统的性能产生负面影响。想象一下，你使用一个 LLM 框架 构建一个实时聊天机器人，当用户发送消息时，框架需要经过多层处理才能将消息传递给 LLM，这无疑会增加延迟，降低用户体验。
此外，大量的依赖项也增加了系统的复杂性，使得维护和升级变得更加困难。当某个依赖项出现问题时，你可能需要花费大量的时间来定位和修复问题，甚至需要重写部分代码。
依赖风险：质量与安全
每个依赖项都是质量的一个潜在风险点。你可能会继承你并不需要的 bug、架构决策和破坏性更改。在使用 LLM 框架 时，你实际上是将一部分控制权交给了框架的维护者。你需要信任他们能够及时修复 bug，并做出合理的架构决策。然而，如果框架的维护者不够负责，或者他们的架构决策与你的需求不符，你的产品质量就会受到影响。
更严重的是，LLM 框架 也可能引入安全漏洞，使得你的应用容易受到攻击。例如，某些框架可能会将用户的敏感数据存储在不安全的地方，或者允许恶意用户执行任意代码。
因此，在使用 LLM 框架 时，你需要仔细评估框架的质量和安全性，并采取必要的安全措施来保护你的应用。
升级地狱：难以维护
LLM 生态系统发展迅速。当你自己构建一切时，你可以根据需要更新组件。但是，使用 LLM 框架 时，每次 升级 都变成一场赌博。更新一个依赖项通常会破坏另一个依赖项。更新框架本身可能会引发一连串你无法控制的破坏性更改。你最终会被阻止，等待修复，或者重写一半的堆栈才能保持最新。
例如，某个 LLM 框架 可能会频繁发布新版本，每个版本都包含一些新功能和 bug 修复。然而，如果你使用的 LLM 应用依赖于框架的某些旧功能，那么在 升级 到新版本后，这些功能可能会失效，导致你的应用无法正常工作。
为了解决这个问题，你可能需要重写部分代码，或者寻找替代方案。然而，这无疑会增加开发成本和时间。
演示陷阱：无法生产
当然，你可以一天内构建一些东西。但是它能处理真实的流量吗？能优雅地降级吗？能提供适当的日志记录和跟踪吗？能以足够快的速度为真实用户运行吗？可能不会。这些框架通常是为通用目的而设计的。但是生产应用程序需要特定的、紧密的、健壮的系统。这与通用的 抽象 层不兼容。
很多人喜欢在社交媒体上炫耀自己使用 LLM 框架 在 10 分钟内构建了一个 AI 应用。但实际上，这些应用无法供真实用户使用，无法扩展，并且他们无法解释它是如何工作的。这不是真正的工程，也不是前沿技术。这只是伪装成创新的营销。
自欺欺人：缺乏深度
每个人都在争先恐后地在社交媒体上发布“看看我用 AI 构建了什么”。他们没有告诉你的是，它在真实用户面前会崩溃，在负载下会失败，大部分是别人编写的样板代码，并且他们无法解释它是如何工作的。
结果呢？大量华而不实的 演示 看起来令人印象深刻，但在审查下却会崩溃。 LLM 框架 让你很容易看起来很有成效，同时跳过真正重要的困难部分。
替代方案：掌握核心技术
那么，我们应该如何避免 LLM 框架 的陷阱，构建真正可用的 LLM 应用呢？答案是：编写干净、简洁的代码，直接与 LLM 交互，并使用 FastAPI、VectorDBs 和 Pydantic 等基础工具。我们需要手动处理摄取、分块、嵌入、查询、记忆、推理和行动循环，并像对待任何严肃的后端系统一样，对代码进行调试、分析和优化。
具体来说，可以采取以下步骤：
- 选择合适的 LLM: 根据应用的需求选择合适的 LLM，例如 OpenAI 的 GPT 系列、Google 的 PaLM 系列或开源的 LLM。
- 设计合理的提示词: 编写清晰、简洁的提示词，引导 LLM 产生期望的输出。
- 构建高效的检索系统: 使用向量数据库存储和检索相关信息，例如 FAISS、Milvus 或 Chroma。
- 实现灵活的控制流: 使用 Python 等编程语言实现灵活的控制流，控制 LLM 的行为。
- 优化性能: 使用缓存、并行处理等技术优化应用的性能。
- 监控和调试: 使用日志记录和跟踪工具监控应用的运行状况，并及时发现和修复问题。
当然，这种方法需要花费更多的时间和精力，但它带来的回报是巨大的。你可以更好地理解 LLM 的工作原理，更好地控制系统的行为，并构建出更加高效、可靠的 LLM 应用。
谁应该使用 LLM 框架？
需要明确的是，我并不是说 LLM 框架 没有任何用途。 LLM 框架 可以帮助初学者入门，使黑客能够构建快速 演示，并允许团队对想法进行原型设计。
但是这些框架使得发布看起来功能正常但未经战斗测试的东西变得非常容易。这就是为什么这么多 LLM 应用在 演示 后消失的原因。
如果你正在构建一个生产级、延迟敏感、可扩展的系统，那么请跳过框架。自己编写它。了解你在构建什么。
最终思考
不要将 演示 软件与生产软件混淆。如果你不了解堆栈，你就无法控制结果。如果你真的想构建真实的 LLM 系统，请帮自己一个忙：跳过捷径，自己编写，并拥有你的堆栈。