【译】LLM三角原则：构建可靠的人工智能应用程序

• 介绍LLM三角原则
  • 关键顶点
• 1. 标准操作程序 (SOP)
  • 1.1. 认知建模
• 2. 工程技术
  • 2.1. LLM-原生架构（又称流工程或链）
  • 2.2. 什么是代理？
    • 2.2.1. 带工具的代理
• 3. 模型
  • 3.1. 微调模型
• 4. 上下文数据
  • 4.1. 少样本学习
  • 4.2. 检索增强生成
  • 4.3. 提供相关上下文
• 结论与影响
• 关键要点

软件设计原则，用于深思熟虑地设计可靠、高性能的LLM应用。一个弥合潜力与生产级性能之间差距的框架。

大型语言模型（LLMs）具有巨大的潜力，但开发可靠的生产级应用仍然具有挑战性。在构建了数十个LLM系统之后，我将成功的公式提炼为任何团队都可以应用的3+1个基本原则。

“LLM原生应用是10%的复杂模型和90%的实验性数据驱动工程工作。”

构建生产就绪的LLM应用需要 谨慎的工程实践。当用户无法与LLM 直接 互动时，提示必须经过精心编写，以涵盖所有细微差别，因为 迭代用户反馈可能不可用。

介绍LLM三角原则

LLM三角原则概括了构建有效LLM原生应用的基本指南。它们提供了一个坚实的概念框架，指导开发人员构建强大且可靠的LLM原生应用，并提供方向和支持。

通过SOP的视角优化这三个显著原则，可以实现最佳的LLM使用。（图片由作者提供）

关键顶点

LLM三角原则引入了四个编程原则，以帮助您设计和构建LLM原生应用。

第一个原则是_标准操作程序（SOP）。SOP指导我们三角形的三个顶点：模型、工程技术 和 上下文数据。

通过 SOP的视角优化这三个顶点原则 是 确保高性能 LLM原生应用的关键。

1. 标准操作程序 (SOP)

S tandard O perating P rocedure (SOP) 是工业界一个众所周知的术语。它是一套由大型组织编制的逐步指令，旨在帮助员工在执行日常操作时保持高质量和相似的结果。这实际上将没有经验或技能较低的员工转变为专家，通过编写详细的指令。

LLM 三角原则借鉴了 SOP 范式，并鼓励您 将模型视为一个没有经验/技能的员工。通过“教导”模型如何像专家一样执行此任务，我们可以确保更高质量的结果。

SOP 指导 原则。 (图片由作者提供)

“没有 SOP，即使是最强大的 LLM 也无法持续提供高质量的结果。”

在考虑 SOP 指导 原则 时，我们应该确定哪些技术将帮助我们最有效地实施 SOP。

1.1. 认知建模

要创建 SOP，我们需要选取表现最佳的员工（领域专家），建模他们如何思考和工作以实现相同的结果，并记录下他们所做的一切。

在编辑和正式化后，我们将拥有详细的指令，以帮助每位没有经验或技能较低的员工成功并产生优秀的工作。

像人类一样，减少任务的认知负担 是至关重要的，通过简化或拆分任务来实现。遵循简单的逐步指令比冗长复杂的程序更为直接。

在此过程中，我们识别出隐藏的 隐性认知 “跳跃” — 专家所采取的小而无意识的步骤，这些步骤对结果有显著影响。这些微妙的、无意识的、通常未被言明的假设或决策可以显著影响最终结果。

“隐性认知跳跃”的一个例子。（作者提供的图片）

例如，假设我们想要建模一个 SQL 分析师。我们将通过采访他们开始，并问他们几个问题，例如：

• 当被要求分析一个商业问题时，你会怎么做？
• 你如何确保你的解决方案满足请求？
• <将我们理解的过程反映给受访者>
• 这准确地捕捉到你的过程吗？<获取更正>
• 等等。

分析师所做的认知过程的一个例子，以及如何建模它。（作者提供的图片）

隐性认知过程有多种形式；一个典型的例子是“特定领域的定义”。例如，“畅销书”可能是我们领域专家的一个显著术语，但对其他人来说却不是。

扩展我们 SQL 分析师示例中的隐性认知过程。（作者提供的图片）

最终，我们将拥有一个完整的 SOP “配方”，使我们能够模拟我们表现最好的分析师。

在绘制这些复杂过程时，将其可视化为图形可能会很有帮助。这在过程细致且涉及多个步骤、条件和分支时尤其有用。

“SQL 分析师 SOP”包括所有所需的技术步骤，以图形形式可视化。（作者提供的图片）

我们的最终解决方案应模仿 SOP 中定义的步骤。在这个阶段，尽量忽略实现——稍后，你可以在我们的解决方案中的一个或多个步骤/链中实现它。

与其他原则不同，认知建模（SOP 编写）是 唯一独立的过程。强烈建议在编写代码之前先建模你的过程。也就是说，在实现过程中，你可能会根据获得的新见解或理解回过头来进行更改。

现在我们理解了创建一个良好定义的 SOP 的重要性，它指导我们对问题的 商业理解，让我们探索如何有效地使用各种工程技术来实现它。

2. 工程技术

工程技术 帮助您实际实施您的标准操作程序（SOP），并充分利用模型。在考虑 工程技术原则 时，我们应该考虑工具箱中哪些工具（技术）可以帮助我们实施和塑造我们的 SOP，并协助模型与我们良好沟通。

工程技术原则。（作者提供的图片）

一些工程技术仅在提示层中实施，而许多则需要软件层才能有效，有些则结合了这两层。

工程技术层。（作者提供的图片）

虽然每天都有许多小细微差别和技术被发现，但我将介绍两种主要技术：工作流/链和代理。

2.1. LLM-原生架构（又称流工程或链）

LLM-原生架构描述了您的应用程序在执行任务结果时所经历的代理流。

我们流中的每一步都是一个独立的过程，必须发生以实现我们的任务。有些步骤将仅通过确定性代码执行；对于某些步骤，我们将使用 LLM（代理）。

为此，我们可以反思我们绘制的标准操作程序（SOP），并思考：

1. 哪些 SOP 步骤应该粘合在同一个代理上？哪些步骤应该分开作为不同的代理？
2. 哪些 SOP 步骤应该以独立的方式执行（但它们可能会从之前的步骤中获取信息）？
3. 哪些 SOP 步骤可以通过确定性代码执行？
4. 等等。

基于给定 SOP 的“维基百科作者”的 LLM-原生架构示例。（作者提供的图片）

在导航到我们架构/图中的下一步之前，我们应该定义其关键属性：

• 输入和输出 — 这一步的签名是什么？在我们采取行动之前需要什么？（这也可以作为代理的输出格式）
• 质量保证 — 什么使得响应“足够好”？是否有需要人工干预的情况？我们可以配置哪些类型的断言？
• 自主级别 — 我们对结果质量的控制需要多少？这个阶段可以处理哪些范围的用例？换句话说，我们在这一点上可以多大程度上信任模型独立工作？
• 触发器 — 下一步是什么？什么定义了下一步？
• 非功能性 — 需要什么样的延迟？我们需要在这里进行特殊的业务监控吗？
• 故障转移控制 — 可能发生什么类型的故障（系统性和代理性）？我们的后备方案是什么？
• 状态管理 — 我们需要特殊的状态管理机制吗？我们如何检索/保存状态（定义索引键）？我们需要持久存储吗？这个状态的不同用途是什么（例如，缓存、日志等）？
• 等等。

2.2. 什么是代理？

LLM 代理是 LLM-Native 架构的一个独立组件，涉及调用 LLM。

它是 LLM 使用的一个实例，提示包含上下文。并非所有代理都是相同的——有些会使用“工具”，有些则不会；有些可能在流程中“仅使用一次”，而其他则可以递归调用或多次调用，携带先前的输入和输出。

2.2.1. 带工具的代理

一些 LLM 代理可以使用“工具”——用于计算或网络搜索等任务的预定义函数。代理输出指令，指定工具和输入，应用程序执行这些指令，并将结果返回给代理。

为了理解这个概念，让我们看一个简单的工具调用提示实现。这甚至可以在未经过原生训练以调用工具的模型上工作：

You are an assistant with access to these tools:

- calculate(expression: str) -> str - calculate a mathematical expression
- search(query: str) -> str - search for an item in the inventory

Given an input, Respond with a YAML with keys: `func`(str) and `arguments`(map) or `message`(str).Given input

重要的是要区分使用工具的代理（因此称为 自主代理）和其输出可以导致执行某个动作的代理。

“自主代理是指能够生成完成任务的方法的代理。”

自主代理被 赋予权利 来 决定 是否应该采取行动以及采取何种行动。相比之下，一个（非自主）代理只是“处理”我们的请求（例如，分类），并根据这个过程，我们的确定性代码执行一个动作，而模型对此没有控制权。

自主代理与触发动作的代理。（作者提供的图片）

随着我们在规划和执行任务中增加代理的自主性，我们增强了其决策能力，但可能会降低对输出质量的控制。尽管这看起来像是一个使其更“智能”或“先进”的神奇解决方案，但这也带来了失去对质量控制的代价。

自主代理的权衡。（作者提供的图片）

要警惕完全自主代理的诱惑。虽然它们的架构看起来吸引人且更简单，但将其用于所有事情（或作为初始的 PoC）可能会在“真实生产”案例中非常具有误导性。自主代理难以调试且不可预测（响应质量不稳定），这使得它们在生产中不可用。

目前，代理（没有隐式指导）在规划复杂过程方面并不是很好，通常会跳过关键步骤。例如，在我们的“维基百科写作者”用例中，它们会直接开始写作并跳过系统的过程。这使得代理（尤其是自主代理）仅仅和模型一样好，或者更准确地说——仅仅和它们相对于你的任务所训练的数据一样好。

与其让代理（或一群代理）自由地端到端执行所有操作，不如尝试将它们的任务限制在你流程/SOP 中需要这种灵活性或创造性的特定区域。这可以产生更高质量的结果，因为你可以享受两全其美的效果。

一个优秀的例子是 AlphaCodium: 通过将结构化流程与不同的代理（包括一个迭代编写和测试代码的新代理）相结合，他们将 GPT-4 在 CodeContests 上的准确率 (pass@5) 从 19% 提高到了 44%。

AlphaCodium 的 LLM 架构。（图片由 Codium.ai 提供）

虽然工程技术为实施我们的 SOP 和优化 LLM 原生应用奠定了基础，但我们还必须仔细考虑 LLM 三角形的另一个关键组成部分：模型本身。

3. 模型

我们选择的模型是我们项目成功的关键组成部分——一个大型模型（如 GPT-4 或 Claude Opus）可能会产生更好的结果，但在规模上可能会非常昂贵，而一个较小的模型可能不那么“智能”，但有助于预算。在考虑 模型原则 时，我们应该旨在识别我们的限制和目标，以及什么样的模型可以帮助我们实现这些目标。

模型原则。（作者提供的图片）

“并非所有 LLM 都是平等的。将模型与任务匹配。”

事实是，我们并不总是需要最大的模型；这取决于任务。为了找到合适的匹配，我们必须有一个 实验过程 并尝试我们解决方案的多个变体。

考虑我们的“缺乏经验的工人”类比——一个非常“聪明”的工人拥有许多学术资历，可能会轻松完成某些任务。然而，他们可能对这份工作过于合格，雇佣一个“更便宜”的候选人将更具成本效益。

在考虑模型时，我们应该根据我们愿意接受的权衡来定义和比较解决方案：

• 任务复杂性 — 较简单的任务（如摘要）更容易用较小的模型完成，而推理通常需要较大的模型。
• 推理基础设施 — 应该在云端还是边缘设备上运行？模型大小可能会影响小型手机，但在云服务中可以容忍。
• 定价 — 我们能接受什么价格？考虑到业务影响和预测使用，这是否具有成本效益？
• 延迟 — 随着模型变得更大，延迟也会增加。
• 标记数据 — 我们是否有可以立即使用的数据，以用示例或未经过训练的相关信息来丰富模型？

在许多情况下，直到你拥有“内部专业知识”，支付额外费用雇佣一位经验丰富的工作人员是有帮助的——这同样适用于LLMs。

如果你没有 标记数据，可以从一个更强（更大）的模型开始，收集数据，然后利用这些数据通过少量示例或微调来增强模型。

3.1. 微调模型

在决定微调模型之前，有几个方面需要考虑：

• 隐私 — 你的数据可能包含必须对模型保密的私人信息。如果你的数据包含私人信息，你必须对其进行匿名处理，以避免法律责任。
• 法律、合规性和数据权利 — 在训练模型时可能会出现一些法律问题。例如，OpenAI的使用条款政策禁止你在没有OpenAI使用生成的响应的情况下训练模型。另一个典型的例子是遵守GDPR法律，该法律要求“撤回权”，用户可以要求公司从系统中删除信息。这引发了关于模型是否应该重新训练的法律问题。
• 更新延迟 — 训练模型时的延迟或数据截止时间要高得多。与通过上下文嵌入新信息（见下文“4. 上下文数据”部分）提供即时延迟不同，训练模型是一个耗时的长过程。因此，模型的重新训练频率较低。
• 开发和运营 — 实施一个可重复、可扩展且可监控的微调管道至关重要，同时需要持续评估结果的性能。这个复杂的过程需要不断的维护。
• 成本 — 由于其复杂性和每次训练所需的高强度资源（GPU），重新训练被认为是昂贵的。

LLMs作为 上下文学习者 的能力，以及新模型支持更大上下文窗口的事实，显著简化了我们的实现，并且即使没有微调也能提供出色的结果。由于微调的复杂性，建议将其作为最后的手段或完全跳过。

相反，为特定任务（例如，结构化 JSON 输出）或特定领域语言微调模型可以非常高效。一个小型的、任务特定的模型在推理时可以比大型 LLM 更有效且成本更低。明智地选择你的解决方案，并在升级到 LLM 训练之前评估所有相关考虑因素。

“即使是最强大的模型也需要相关且结构良好的上下文数据才能发挥作用。”

4. 上下文数据

LLMs 是上下文学习者. 这意味着通过提供特定任务的信息，LLM 代理可以帮助我们在 没有 特殊训练或微调的情况下执行该任务。这使我们能够轻松“教授”新知识或技能。在考虑 上下文数据原则 时，我们应该旨在组织和建模可用数据以及如何在我们的提示中组合它。

上下文数据原则。（作者提供的图片）

为了构建我们的上下文，我们在发送给 LLM 的提示中包含相关（上下文）信息。我们可以使用两种类型的上下文：

• 嵌入上下文 — 作为提示一部分提供的嵌入信息片段。

You are the helpful assistant of <name>, a <role> at <company>

• 附件上下文 — 一系列通过提示的开始/结束粘合的信息片段

Summarize the provided emails while keeping a friendly tone.
---

<email_0>
<email_1>

上下文通常使用“提示模板”实现（例如 jinja2 或 mustache 或简单的本地 格式化字面字符串）；通过这种方式，我们可以优雅地组合它们，同时保持提示的本质：

# Embedded context with an attachment context
prompt = f"""
You are the helpful assistant of {name}. {name} is a {role} at {company}.

Help me write a {tone} response to the attached email.
Always sign your email with:
{signature}

---

{email}
"""

4.1. 少样本学习

少样本学习是一种强大的“教学”方式，通过示例来“教”大型语言模型（LLMs），而无需进行广泛的微调。在提示中提供几个代表性的示例可以指导模型理解所需的格式、风格或任务。

例如，如果我们希望LLM生成电子邮件回复，我们可以在提示中包含几个写得好的回复示例。这有助于模型学习首选的结构和语气。

我们可以使用多样的示例来帮助模型捕捉不同的边缘案例或细微差别并从中学习。因此，包含覆盖应用程序可能遇到的各种场景的多种示例是至关重要的。

随着您的应用程序的发展，您可能会考虑实施“动态少样本”，这涉及程序性地为每个输入选择最相关的示例。虽然这增加了您的实现复杂性，但它确保模型为每种情况提供最合适的指导，从而显著提高在广泛任务中的性能，而无需昂贵的微调。

4.2. 检索增强生成

检索增强生成（RAG）是一种在生成响应之前检索相关文档以获取额外上下文的技术。这就像给LLM快速浏览特定参考材料，以帮助其回答。这使得响应保持最新和真实，而无需重新训练模型。

例如，在支持聊天机器人应用程序中，RAG可以提取相关的帮助台维基页面，以告知LLM的答案。

这种方法帮助LLMs 保持最新 并且 减少幻觉，通过将响应基于检索到的事实来实现。RAG对于需要更新或专业知识而无需重新训练整个模型的任务特别方便。

例如，假设我们正在为我们的产品构建一个支持聊天。在这种情况下，我们可以使用RAG从我们的帮助台维基中检索相关文档，然后将其提供给LLM代理，并要求其根据问题撰写答案并提供文档。

在实施 RAG 时，有三个关键点需要关注：

• 检索机制 — 虽然 RAG 的传统实现涉及使用向量相似性搜索来检索相关文档，但有时使用更简单的方法，如基于关键字的搜索（如 BM-25），可能更好或更便宜。
• 索引数据结构 — 天真地对整个文档进行索引而不进行预处理，可能会限制检索过程的有效性。有时，我们希望添加数据准备步骤，例如根据文档准备问题和答案列表。
• 元数据 — 存储相关的元数据可以更有效地引用和过滤信息（例如，将维基页面缩小到仅与用户特定产品查询相关的页面）。这一额外的数据层简化了检索过程。

4.3. 提供相关上下文

与您的代理相关的上下文信息可能会有所不同。尽管提供过多信息给模型（如“无技能工人”）似乎有益，但这可能会让人感到不知所措且与任务无关。从理论上讲，这会导致模型学习无关的信息（或标记连接），从而导致困惑和 幻觉。

当 Gemini 1.5 发布并被介绍为可以处理多达 10M 标记的 LLM 时，一些从业者质疑上下文是否仍然是一个问题。尽管这是一个了不起的成就，尤其是对于某些用例（如与 PDF 的聊天），但在对各种文档进行推理时，它仍然有限。

压缩提示并仅向 LLM 代理提供相关信息至关重要。这减少了模型在无关标记上投入的处理能力，提高了质量，优化了延迟，并降低了成本。

有许多技巧可以提高提供的上下文的相关性，其中大多数与您如何存储和编目数据有关。
对于 RAG 应用程序，添加数据准备以塑造您存储的信息（例如，基于文档的问题和答案，然后仅向 LLM 代理提供答案；这样，代理获得了一个总结和更短的上下文）是很方便的，并在检索到的文档上使用重新排序算法来优化结果。

“数据为LLM原生应用的引擎提供动力。上下文数据的战略设计释放了它们的真正潜力。”

结论与影响

LLM三角原则提供了一种结构化的方法来开发高质量的LLM原生应用，解决了LLM巨大的潜力与现实世界实施挑战之间的差距。开发者可以通过关注3+1个关键原则——模型、工程技术 和 上下文数据——在一个明确的 SOP 指导下，创建更可靠和有效的LLM驱动解决方案。

LLM三角原则。（作者提供的图片）

关键要点

1. 从明确的SOP开始: 模拟专家的认知过程，为您的LLM应用创建逐步指南。在考虑其他原则时，将其作为指导。
2. 选择合适的模型: 在能力与成本之间取得平衡，考虑先从较大的模型开始，然后再可能转向较小的、经过微调的模型。
3. 利用工程技术: 实施LLM原生架构，并战略性地使用代理以优化性能并保持控制。尝试不同的提示技术，以找到最有效的提示。
4. 提供相关上下文: 在适当时使用上下文学习，包括RAG，但要小心不要用无关信息淹没模型。
5. 迭代与实验: 找到正确的解决方案通常需要测试和完善您的工作。我建议阅读并实施“构建LLM应用：清晰的逐步指南”中的提示，以获取详细的LLM原生开发过程指南。

通过应用LLM三角原则，组织可以超越简单的概念验证，开发出强大、生产就绪的LLM应用，真正利用这一变革性技术的力量。

Source: https://towardsdatascience.com/the-llm-triangle-principles-to-architect-reliable-ai-apps-d3753dd8542e