提升 LLM 可靠性：构建高可靠性代理的 5 种创新技术

来源：Eric Broda

简介

随着 LLM 能力的提升，软件和用户期望也随之扩展，以充分利用这些优势。

但在我们不断前进的过程中，存在着一个持续的平衡——每一次新的大型语言模型 (LLM) 都会带来可靠性（不准确性和我们称之为幻觉）的增加，但我们要求的更多，而可靠性也必然会下降。周而复始。

但有没有更好的方法呢？

我相信，今天我们对 LLM 的要求太高了。当我们获得一个新的、更好的 LLM 时，我们很快就会要求它们做更多的事情，然后我们又一次面临错误和不准确性。正如我所说，周而复始！

问题的核心在于：LLM 是概率性的，但概率会成倍增长——有时会灾难性地增长。因此，当被要求做小事时，LLM 非常可靠和准确。但当我们要求它们做大事时，我们会将小错误级联成指数级增长的错误。从某种意义上说，小即是好。

但我们如何才能让它为我们所用呢？如今，诸如“思维链”和“反思”之类的技术被用来将更大的提示分解成更小的块。然而，核心问题在于，一个提示部分依赖于整个提示流中前一步的输出。正是这种依赖性造成了“乘法”误差——不准确性在提示流中成倍增加——在足够大的提示流中，可能导致非常大的错误。

本文的目的是为这个问题提供一个解决方案——一个可以显著减少错误并提高 LLM 可靠性的解决方案。我们的解决方案结合了几种技术：

• 将提示分解成更小的任务：任务被分解成一个“任务计划”，将一个大的请求转换成一系列非常小且高度可靠的 LLM 请求。
• 确定性编排：基于 LLM 的分支逻辑和工具使用——计划执行——被委托给确定性和 100% 可靠的编排引擎。
• 专业 LLM：随着性能的提高，加上成本的大幅降低，为专家 LLM 的新时代奠定了基础，这些专家 LLM 擅长特定领域，这将大大减少错误。
• 独立执行：每个任务步骤——已经是一个较小的提示——被打包成一个自包含的工作，并传递给一个独立的专业 LLM（这消除了乘法级联错误的问题）
• 代理作为部署工具：代理将所有这些功能捆绑到一个统一的架构中。

问题陈述

任何使用过 LLM 的人都知道它们会生成不准确的信息和幻觉。对于简单、简洁的任务，这种倾向似乎是可以控制的，在这种情况下，模型的响应通常既可靠、可重复又准确，但随着请求（或提供）更多内容，这种倾向会明显降低。

让我们把它变成现实：考虑一下 LLM 赋能的软件开发，这恰好是当今 LLM 最常见和最实际的用例之一。使用这些模型的开发人员发现，短程序或单函数脚本可以可靠地生成（例如，通过运行而无需修改），并且错误很少。然而，当模型被要求生成更复杂的东西时——例如，一个多文件软件项目，或者一个更大更复杂的组件——它的可靠性和准确性会急剧下降。在许多情况下，这些更长的代码输出要么在第一次尝试时无法运行，要么需要手动重新设计和修复。

这种性能差距使得大规模部署变得不切实际，并且在某些情况下，对于需要高度正确性的项目来说是站不住脚的。特别是受监管的行业面临着更大的挑战，例如金融、医疗保健或保险等行业受到严格的指导方针的约束，这些指导方针几乎没有给 LLM 引入的那些事实错误或语义错误留下余地。

事实上，最近的一项研究（Li et al., 2023）观察到当前 LLM 能力方面的问题，强调了更长、上下文丰富的输入如何超出大多数模型在不增加早期不准确性的情况下可以处理的范围。当前 LLM 处理和理解长、上下文丰富的序列的能力存在“显着差距[并且]长上下文的理解和推理对于现有 LLM 来说仍然是一项具有挑战性的任务”。

这个问题强化了这样的观点，即尽管 LLM 很有前景，但它们在高度精确至关重要或高度复杂的情况下，可能仍然达不到要求。毫不奇怪的是，组织意识到潜在的代价高昂的错误和法律影响，通常不愿意整合一种在面对复杂需求时表现出不可预测性的技术。不幸的是，除非解决这些缺点，否则一些最具吸引力的市场机会将无法实现，尤其是在需要严格合规的行业（如银行业、医疗保健、政府）中。

根本原因

LLM 依赖于概率方法而不是固定规则（它们是非确定性的），这解释了为什么它们有时会生成不正确或相互矛盾的响应。每个输出 token 都是根据前一个 token 以及从大量训练数据中学习到的可能性来选择的，这意味着不能保证最终序列不会出错。而且，更棘手的是，即使输入和环境条件相同，运行之间的输出也可能有所不同。这种行为与确定性系统形成对比，对于给定的输入，该系统每次都会产生准确（或至少可验证的准确）且相同的输出。

这种行为的根本原因就是我所说的“选择的组合爆炸”。当模型处理一个短提示时，从开始到结束的路径很短，出错的机会仍然很低；然而，处理一个更长、更复杂的提示涉及更多的分支可能性。选择越多，出错的机会就越大，而且由于错误会成倍增加并级联，它们会呈指数增长！

简而言之，由于每个 token 都依赖于前一个 token，一个小的错误（尤其是在处理早期发生的错误）可能会贯穿文本的其余部分，从而导致潜在的灾难性（或至少不可靠、不可重复和不准确）的结果。

图 1 所示的简化计算演示了错误率的级联。虽然对于实际编码 LLM，错误率要低得多，但为了说明选择的组合爆炸背后的数学原理，我们假设每个 token 的准确率为 99%：

• 100 个 token：37% 的准确率（0.99¹⁰⁰ 约为 0.37）
• 1,000 个 token：0.004% 的准确率（0.99¹⁰⁰⁰ 约为 0.00004）
• 10,000 个 token：非常非常低的准确率！

图 1，选择的组合爆炸

这可能强调了为什么一些最理想的 LLM 机会——那些需要大规模输出或复杂推理的机会——会带来最大的错误风险。今天，这种权衡是确定在哪里应用 LLM 的重要考虑因素。

潜在解决方案

一些从业者试图通过迭代改进来解决准确性和可靠性差距。他们从第一次尝试开始，然后审查任何不一致之处，并将这些错误反馈给模型。这种方法对于较小的输出（包括短代码片段或简洁的叙述）效果很好，并且通过承认模型最初的缺陷并系统地纠正它们，开发人员设法提取了更好的最终结果。

图 2，潜在解决方案

一个类似的想法是提示模型逐步阐明其逻辑，有时称为链式思考推理。这种方法试图通过迫使 LLM 概述问题和答案之间的中间步骤来减少不准确性和幻觉。这种技术可以防止模型跳到未经证实的结论，尤其是在复杂的推理场景中，并且已被证明可以减少游离或不相关输出的数量。然而，当响应变长时，它并没有消除复合错误的基本问题。

底线是：随着新项目在规模或复杂性上扩展，LLM 预测的底层机制会导致不准确性复合，从而限制了即使是最佳提示或改进技术的有效性。

更好的 LLM 呢？我们经常相信更新、更先进的 LLM 是解决准确性和可靠性挑战的直接方法。最近发布的版本推动了模型大小、训练数据和复杂性的发展，使它们能够处理更长的输入提示并产生更复杂的答案，而不会立即达到使用变得不切实际的错误阈值。这种扩展的功能扩展了不准确性开始变得有意义的阈值，这意味着用户可以在响应质量下降之前请求更大的细节或广度。

然而，这种改进只是推迟了不可避免的情况。一旦组织采用了这些更高容量的模型，他们很快就会意识到对更广泛输出的需求也会随之增长。例如，在适度复杂的任务中取得的早期成功可能会鼓励团队争取更长或更细致的交付成果。最终，同样的错误指数增长——选择的组合爆炸问题——再次出现，让我们回到了与较小模型相同的循环中（尽管规模更大）。

例如，当 ChatGPT 推出 GPT3.5 时，我们对自然语言交互感到惊讶，但很快不准确性和可靠性就变得非常明显。很快 GPT4 就发布了，修复了一些错误，但随后我们发现了一组新的事情可以在我们达到错误阈值之前完成。但我们仍然要求更多，很快音频和视频就被添加到更新的 LLM 中，而且我们仍然发现了错误。

根本问题是，公司，尤其是那些依赖于高度准确结果的受监管行业的公司，有时会发现，当请求超出一定范围时，他们新增强的能力仍然不足。尽管可靠性能的窗口已经扩大，但每个添加的 token 都会增加出错的机会，并且底层的概率性质保持不变，因此一旦任务超过了这种改进但有限的容量，同样的错误级联就会再次发生。

不幸的是，这突出了仅仅依靠 LLM 扩展的局限性。即使有了更好的模型，选择的组合爆炸及其产生的问题仍然挥之不去。

LLM 专科化

LLM 日益增长的复杂性和能力与它们成本的惊人下降相匹配，甚至可能超过了成本的下降。这为更多专业化应用创造了机会，这些应用不依赖于单一的、包罗万象的模型。公司不再需要等待一个通用系统发展，现在可以负担得起部署多个、更小的模型，这些模型针对特定的任务进行了调整和优化。事实上，向专家 LLM 迈进的步伐似乎不仅在加速，而且是不可避免的。

图 3，LLM 专科化

这种专业化反映了其他行业中出现的趋势。在半导体制造业中，公司曾经试图自己制造整个芯片，但很快意识到外包专业组件更有效，并且随着时间的推移，高度专业化的制造工厂出现了，降低了成本并提高了质量。类似的模式也出现在供应链网络中，每个参与者都发展出特定的能力。逻辑很简单：当参与者专注于他们最擅长的事情时，整个系统都会受益。

经济学家有时将此称为比较优势理论，该理论指出，如果各方专注于其具有明显优势的活动，则总体生产力会提高。应用于 LLM 时，这表明没有单一模型会主导每个用例。相反，多个专业模型可以蓬勃发展，每个模型都经过专门训练，用于更窄的领域。

在实践中，专业化意味着用户不必依赖一个庞大的 LLM。他们可以立即实施更小、专用的 LLM，涵盖不同的领域，而不会影响性能。

专业化 LLM 的编排

一些组织已经开始编排多个语言模型，将通用 LLM 与一个或多个专业模型相结合。每个 LLM 处理复杂任务的不同部分，确保没有单个模型因整个问题而超载。其目的是利用通用模型的通用性，同时利用在狭窄领域中表现出色的更小、更专注的 LLM 的深厚专业知识。

这种方法通常依赖于一个“编排器”LLM 来解析和解释初始请求。这个编排器，可以是一个通用 LLM（或专门从事任务规划的 LLM），确定需要做什么——一个包含多个步骤的任务计划——然后扫描可用的 LLM 列表，并将特定的任务步骤分配给最适合它们的专业模型。

通过将更大的请求分解为一系列较小的离散步骤，编排器保持每个步骤的提示和范围简短且定义明确。这些专业化的 LLM 独立运行，很少需要超出其特定功能所需的上下文。编排器协调 LLM 的执行，并收集最终输出，并将它们组合成一个连贯的结果。

这种设计导致了任务的独立性。正是任务独立性——任务规划和任务执行由不同的 LLM 独立处理的事实——导致了较低的总体错误率。一个领域的错误不会级联到整个解决方案中，因为每个步骤都有自己的边界，并且不必依赖于单个执行线程的逐个 token 路径。

专业化的一个有趣的副产品是，它还将 LLM 所需的数据范围减少到完成任务所需的数据。组织可以限制对专业模型的访问，这些模型被明确授权处理某些类型的信息，而不是与通用 LLM 共享每一条数据。处理交易数据的金融 LLM 将与编写营销文案的模型分开，从而降低不必要的数据泄露风险。

此外，这种类型的编排还提供了相当大的部署灵活性。团队可以根据需要插入新的专业模型，对其进行训练或使其可用，并淘汰过时的旧模型。一切都围绕着编排器为每种情况选择最佳资源的能力，从而创建一个动态环境，该环境不断发展，而无需对端到端架构进行全面改革。

Agent：LLM 编排器

Agent 明确设计了规划能力，通常由专门的或通用的 LLM 实现，以确定每个请求所需的适当步骤和资源。一旦建立了计划，Agent 就会转变为执行角色，调用相关的工具或其他 Agent 来独立地完成它们的工作。每个组件都以最小的重叠运行，从而保持可靠性并降低错误在任务之间迁移的可能性。

图 4，Agent：专家 LLM 编排器

在这种方法中，Agent 首先查阅可用 LLM 和工具的清单。然后，它决定哪个资源应该处理计划的每个步骤，无论是专业模型（可能是特定于领域的模型）还是通用模型。Agent 将请求分解为小的、定义明确的操作，确保没有单个阶段变得笨拙或容易出错。一旦一个步骤完成，Agent 就会聚合输出并根据任何约束或验收标准进行验证。如果需要，它可以提示工具或模型重试给定的操作或纠正错误，然后再进行下一步。

这种基于 Agent 的方法也可以作为一系列微服务集成到企业基础设施中。每个微服务都可以根据组织的要求进行保护、监控和扩展。运营商受益于稳定的环境，因为架构限制了任何给定故障的范围，并避免了单个 LLM 试图端到端处理每个细节时出现的组合爆炸。微服务模型同样简化了发现和部署，从而更容易推出具有专业 LLM 的新 Agent，而不会中断更广泛的管道。

一类新的可解问题

让我们总结一下我们是如何走到这一步的。

首先，多个 LLM 的组合通过将特定任务委托给最适合它们的模型来解决组合爆炸问题。将通用模型与专业模型相结合，确保没有单个系统承担生成长、相互依赖的输出的负担，从而降低了级联错误的风险。这种转变为开发人员提供了一种方法，可以利用每个模型的优势，而不会过度扩展任何单个引擎或要求它处理它从未设计过的任务。

其次，我们将代理视为实现这种协调的机制。通过充当编排者，代理设计和执行任务计划，将子任务路由到最合适的模型或工具。作为微服务实施，这些代理继承了成熟的企业解决方案，用于安全性、监控和高可用性。团队可以调整主流 DevOps 实践来维护性能和可靠性，而不是在单体 LLM 环境中重新发明每个功能。

结果是一个框架，其中组合挑战被最小化，但新的问题出现了。

例如，随着时间的推移管理冗长的对话，更多地是关于结构化和持续跨多个会话的状态，而不是生成连续的 token 流。同样重要的是，建立一种标准的处理人类反馈或干预的方法。可能需要在关键时刻整合来自领域专家的关注和指导，因此，提供一个一致的用于手动输入接口至关重要。

状态管理也带来了障碍。虽然单一 LLM 方法可能将所有内容保存在一个上下文窗口中，但基于代理的架构在不同的模块之间传递数据，每个模块都有自己的内存和检查点方案。但是，存在良好的工程模式来解决这个问题，包括事件流、分布式缓存和定义明确的 API 用于交换。其优势在于，这些是来自数十年来分布式系统设计的熟悉解决方案，允许建立一个稳定且可扩展的设置，而不会完全依赖于 prompt engineering。

当然，这些额外的复杂性需要仔细的规划，但它们是已知的量。我们已经了解了如何保护微服务、审计日志以及管理跨不同组件的数据流，并且采用模块化方法可能需要协调，但它确实消除了单个 LLM 超出其限制的瓶颈。

结论

LLM 将继续变得更好，但它们的不确定性设计以及它产生的“选择的组合爆炸”问题意味着我们仍然会受到它们的错误、不准确和幻觉的影响。

因此，我们可以等待下一个 LLM，但还有其他选择。增强的功能与降低的成本相结合，正导致专业化，新的编排技术允许我们把这些更大的问题变成更小、更易处理的部分，同时减少错误和不准确性。当我们在代理架构中实现这些技术时，特别是一个建立在微服务之上的架构时，例如，我们可以利用数十年的安全性、可观察性和可操作性经验来应对新方法的挑战。

正是这种新方法将一个“永远”的问题——不确定的 LLM 和“选择的组合爆炸”——转化为一个分解问题，基于可解决、经过长期研究和充分理解的解决方案，减少错误和不准确性。