文章指出，提示工程、RAG和微调并非线性升级，而是解决不同问题的架构方法。成功的LLM系统需在数据隐私、延迟、控制、更新频率、部署目标和成本六个维度间权衡，建议采用混合架构以满足实际生产需求，而非盲目追求最先进技术。
译自：Prompting vs. RAG vs. fine-tuning: Why it’s not a ladder
作者：Ibrahim Kamal
团队在定制大型语言模型（LLMs）时，通常会认为从提示工程到检索增强生成（RAG），再到微调（阶梯的最后一级）是一个直接的进步过程。这是一种易于理解、经常重复的叙述，对某些开发者来说是正确的，但对于所有在生产环境中处理 LLM 的团队来说并非如此。
在真实的企业系统中，提示工程、RAG 和微调并非顺序升级。相反，它们代表了解决不同类型问题的不同架构方法，并引入了各自的局限性和故障模式。将它们视为线性进展会产生错误的叙述，可能导致系统脆弱，无法适应不断变化的需求。
为了评估 LLM 架构在生产环境中的成败，一个六维框架概述了影响 LLM 系统在生产中表现好坏的实际约束：数据隐私、延迟、控制程度、更新频率、部署目标和成本。
LLM 架构决策何时受到评判
大多数关于 LLM 的架构决策是基于假设而非评估做出的。通常只有在发布 LLM 应用程序后，团队才意识到架构未能达到预期目标。此时，团队可能面临关于已发布 LLM 性能的棘手问题：“为什么我们的响应时间不一致？”“为什么我们这周的成本增加了？”“敏感信息是如何出现在我们的日志中的？”
在识别出性能不佳的架构选择后，团队通常会用一些站不住脚的借口来为自己辩护，例如“我们选择了最先进的架构”，或者“我们正在做的事情和所有人一样”。这些借口没有提供足够的细节来帮助团队理解为什么架构未能达到预期。
一个好的架构会使其权衡取舍变得可见。一个好的架构允许团队阐明为什么选择了特定的方法，它提供了哪些好处，以及潜在的权衡取舍。因此，团队需要为其特定环境做出明智的选择。
LLM 线性阶梯模型的问题
定制大型语言模型的三种主要方法——提示工程、RAG 和微调——每一种都提供了一组不同的能力和/或约束。每一个都是结构性决策，将对团队未来如何与 LLM 交互产生重大影响。
许多团队收到的 LLM 系统构建建议都基于一个阶梯模型：从提示工程开始；如果不行，就转向 RAG；如果 RAG 不行，就转向微调。阶梯模型之所以吸引人，是因为它易于理解，为团队提供了方向和目标，并传达了一种进步感。
然而，阶梯模型未能考虑到这样一个现实：团队的评判标准并非其架构的复杂性；相反，他们被评判的是其架构是否违反了其环境的约束。团队被期望达到性能、安全性及可靠性标准。如果团队的架构阻止其 LLM 系统达到这些标准，那么团队是否使用了“最新最好”的方法来构建其应用程序都无关紧要。
许多与 LLM 相关的失败发生，是因为架构与问题域的需求不符。架构失败的例子包括：
- 团队遇到高响应延迟和不可预测的长尾时间。
- 团队遇到运营成本迅速增加的问题。
- 团队遇到数据隐私泄露和敏感信息风险。
- 系统难以更新而不会出现回归问题的团队。
这些失败都不能通过“更上一层楼”来解决。事实上，许多这些失败的发生正是因为团队遵循了阶梯模型而没有考虑其环境的约束。
生产中重要的 6 个维度
生产的成功由多个独立的限制而非单一的“质量”限制来定义。以下六个维度通常定义哪些架构是可行的。
这些维度之间没有等级之分。通常，改善一个维度会降低另一个维度。由于没有普遍最佳的配置，只有基于系统需求的有意权衡。
这六个维度——数据隐私、延迟、控制程度、更新频率、部署目标和成本——构成了 LLM 架构开发的约束。下图说明了这些维度如何相互作用而不会陷入“线性阶梯”陷阱。该图将这些维度分为初始可行性门槛（不可协商的障碍）、优化维度（可调整的权衡）以及可用作混合模型的架构构建块组合。
数据隐私：第一个可行性障碍
数据隐私通常是生产团队遇到的第一个严峻的限制，而且通常是不可协商的。问题不在于模型供应商是否“安全”。问题在于敏感数据是否可以离开组织的边界。
通常，提示工程会将整个提示，包括用户输入、上下文信息等，发送给外部推理提供商。即使是微调也可能产生更多隐私风险，因为训练数据或派生梯度需要发送到微调管道，从而提供比单次推理调用更长的访问时间。
RAG 改变了隐私面，它允许敏感数据保留在内部系统中，只有其片段被发送到模型。
在实践中，数据隐私由数据分类决定。如果应用程序处理受管制数据（例如个人健康信息或机密数据），那么除非模型是自托管或托管在受控环境中，否则许多架构可能很快变得不可行。另一方面，如果应用程序面向公众且不处理敏感数据，则外部 API 可能是可接受的。
关键点在于，数据隐私是一个障碍，而不是一个可调参数。一旦数据隐私被确定为使用外部推理服务的障碍，整个架构就会崩溃。
延迟：用户首先注意到的约束
一旦解决了数据隐私约束，延迟就成为用户注意到的约束。如果延迟过长或不可预测，用户会将系统视为不可靠。
模型之间延迟的主要差异是由于请求路径中的架构阶段数量，而不是模型的智能程度。例如，提示工程通常具有最低的延迟，因为请求只是单个推理调用。此外，RAG 引入了多个阶段（嵌入搜索、检索、重排序和块选择），这些阶段会增加延迟，并且在负载下也可能产生较高的长尾时间。微调通常通过消除对检索和嵌入的需求，并将其直接集成到模型中，从而产生快速推理路径。
将最快的架构作为选择架构的唯一依据是一种错误的方法。通常，正确的设通常是混合方法。一个例子是使用低延迟路由机制——一个小型、经过调优的模型识别用户意图，对查询进行分类，然后在需要知识基础时才启动高延迟的 RAG 管道。这种混合架构在保护用户体验的同时，能够在需要时提供高精度答案。
在生产中，延迟很少仅仅关乎平均响应时间，而是在并发工作负载下可预测的低尾部延迟问题。
控制程度：约束行为和知识
如果系统行为不稳定，则快速响应无关紧要。控制程度是第三个维度，它指的是架构师如何可靠地约束模型的行为、输出和知识边界。
提示工程主要在输出层约束模型的行为。虽然提示工程可以约束输出的结构（例如 JSON schema）、格式和可本地化行为，但基于提示的控制是脆弱的，因为它与模型先验、用户消息和长期上下文效应竞争。
RAG 在知识边界层面约束模型的知识边界。RAG 的主要用途并非使模型更智能。相反，RAG 用于约束模型在特定请求中被允许知道什么。因此，RAG 在监管环境中特别有用，因为它提供了透明、可治理的知识路径。
微调约束模型的行为，为每个请求提供一致的行为。微调定义了模型用于响应每个请求的语气、风格、推理模式、分类阈值和领域特定偏好。当所需的行为稳定且应嵌入到模型中，而不是在运行时插入时，它最有价值。
这里再次强调，控制程度并非一成不变。控制程度可以指：
- 控制输出结构
- 控制知识来源
- 控制行为一致性
这些技术中的每一种都约束了不同的层，这决定了可能发生何种类型的故障。
更新频率：保持系统最新的成本
控制通常会使事情变得僵化，随着时间的推移，架构的成本并非部署，而是更新。
更新频率描述了系统需要多久添加新信息或修改先前可接受的行为。提示工程对于快速更新很有用，因为修改提示很简单。但随着提示的扩展，维护变得困难，版本控制成为一场噩梦，同时还会出现提示相互作用时的问题。
RAG 对于快速、可扩展的更新很有用，因为知识库可以独立于模型进行更改。如果您的领域每周都在变化——例如政策变化、新产品文档、新 HR 程序——RAG 提供了一种清晰的机制来更新语料库而不是模型。
微调更新缓慢且成本高昂，因为它涉及训练和验证周期。只有当您拥有稳定、高价值的行为时，微调才值得。当您需要频繁更改底层知识时，微调将成为障碍。
这就是为什么您应该遵循这条通用规则：将所有随时间变化的信息保留在模型之外。将微调用于稳定的行为模式；将检索用于动态知识。
部署目标：模型运行的地方
尽管架构在纸面上看起来完美无缺，但部署约束可能会阻碍实施。云 API 部署可以最大限度地提高上市速度。然而，这些部署受到与隐私、法规遵从性和网络延迟相关的限制。
在虚拟私有云/本地环境中部署可以实现数据主权和内部控制，但会显著增加基础设施和操作的复杂性。边缘部署通常限制模型大小，并引导开发团队转向小型、经过调优的模型或专门的推理运行时。
工作负载部署的位置可能会限制可行性。例如，如果组织有数据主权要求且不允许外部推理，则通过公共 API 进行提示工程不再是选项。对于此类组织，无论哪种方法在“阶梯”上的位置如何，自托管 RAG 或微调都可能成为默认选择。
成本：淘汰“成功”试点项目的原因
大多数 LLM 项目不会在原型阶段失败。大多数 LLM 项目在成功采用后当流量增长时失败，此时成本变得非线性。
成本不仅仅是“模型每个 token 的成本是多少？”它可能受到以下因素的影响：
- 提示和检索到的上下文的长度
- 使用的类别/模型以及模型提供商的定价
- 并发/扩展策略
- 缓存效率
- 自托管部署的 GPU/CPU 资源利用率
- 维护检索管道所需的工程开销
虽然提示工程通常是最初成本最低的方法，但随着提示和上下文大小的增长，其成本可能会变得不可预测。RAG 增加了运营成本，因为检索管道必须始终运行——向量数据库、索引作业和重排序器——但它也可以通过允许使用较小的模型并减少 LLM 必须做的工作来填补幻觉，从而降低推理成本。
微调具有非常高的前期成本（训练和评估），但它也可以通过消除检索内容的需要或减少提示中所需的 token 数量来降低推理成本和延迟。
这里的主要区别在于成本的可预测性。最危险的系统是那些其成本会随着使用量的增加而增加的系统，例如那些频繁包含大型检索上下文或多步 LLM 调用而没有严格预算的系统。
在生产中，成本应从第一天起就被视为一个架构维度，而不是在发布后才发现的账单冲击。
将维度结合起来：一个决策框架
并非所有应用程序都有一个“正确”的解决方案。适当的架构将取决于六个维度的相对重要性。
在确定哪种方法最适合您的应用程序时，您可以按特定顺序使用这六个维度：
- 数据隐私：您是否允许敏感信息跨越应用程序边界？如果否，您需要消除任何外部 API 调用。
- 部署目标：您的应用程序是否会在所需平台上运行？消除任何不支持您的应用程序部署目标的方法。
- 延迟：您的架构能否在高负载期间提供必要的低延迟？您的架构能否在高负载情况下满足用户或客户的性能预期？
- 成本：您的架构在高生产流量负载下是否具有经济可行性？您的架构是否仍能保持经济可行性？
- 更新频率：随着客户期望随时间演变，调整您的架构有多困难？当由于不断变化的客户需求而发生变化时，更改您的架构的成本将有多高？
- 控制程度：您希望在多大程度上控制架构的潜在故障点，以最大程度地减少停机时间及相关的收入损失？
一旦您确定了每个维度的相对重要性，您应该创建一个由多个协同工作的机制组成的架构，而不是简单地选择一个“最佳”机制。
在真实的企业应用程序中，许多成功的架构都是混合的：
- 微调（或轻量级适配器）建立稳定的行为模式。
- RAG 提供可治理和定期更新的知识。
- 提示工程强制执行结构化输出和任务级运行时约束。
六维框架解释了为什么“提示 vs. RAG vs. 微调”是一个错误的问题。相反，问问自己：根据上面确定的约束，我应该在我的架构中包含哪些机制？
为了使这个决策过程更具体，以下流程图概述了一种评估您的 LLM 架构在六个维度上的实用方法。
结论
构建生产 LLM 系统的“阶梯”——提示工程 → RAG → 微调——可能看起来很有吸引力，因为它极大地简化了关于如何开发架构的决策过程。然而，现实是，生产 LLM 系统并非通过复杂性来开发。生产 LLM 系统是通过受约束来开发的。
一个六维框架有助于识别开发架构所涉及的权衡，并确保开发团队不会将技术选择视为意识形态问题。在开发架构时，团队可以使用这六个维度来确定要纳入哪些机制，并设计能够承受真实用户交互的混合系统。
不要试图追求最先进的技术。追求构建一个既安全又经济可行的应用程序。
