大型语言模型 （LLMs） 具有巨大的潜力，但开发可靠的生产级应用程序仍然具有挑战性。在构建了几十LLM个系统之后，这里把成功的公式提炼成任何团队都可以应用的 3+1 基本原则。
LLM-原生应用程序是 10% 的复杂模型，90% 是数据驱动的工程工作实验。
LLM 三角原则
LLM 三角原则概括了构建有效的 LLM 原生应用程序的基本准则。它们提供了坚实的概念框架，指导开发人员构建强大而可靠的 LLM 原生应用程序，并提供指导和支持。
通过 SOP 的视角优化三个突出的原则，可以实现 LLM 的最佳利用
关键点
LLM 三角原则介绍了四个编程原则来帮助您设计和构建 LLM-Native 应用程序。
第一个原则是标准操作程序（SOP）。SOP指导我们三角形的三个顶点：模型、工程技术和上下文数据。
通过 SOP的视角优化三个顶点原则是确保LLM 原生应用程序高性能的关键。
2.1 标准操作程序（SOP）
标准操作程序(SOP)是工业界的一个著名术语。它是大型组织编制的一套分步说明，旨在帮助其工人执行常规操作，同时保持高质量和每次操作结果相似。
LLM 三角原则借用了 SOP 范式，可以通过“教”模型专家如何执行此任务来确保更高质量的结果。
SOP指导原则
如果没有 SOP，即使是最强大的 LLM 也无法持续提供高质量的结果。
2.1.1 认知建模
为了创建 SOP，需要选出表现最好的员工（领域专家），模拟他们的思维方式和工作方式以实现相同的结果，并记录下他们所做的一切。
经过编辑和正式化后，我们将提供详细的说明，帮助每一位缺乏经验或技术水平较低的员工取得成功并取得出色的工作。
和人类一样，通过简化或拆分任务来减少认知负荷至关重要。遵循简单的分步说明比冗长复杂的程序更直接。
在此过程中，识别出隐藏的隐性认知“跳跃” ——专家采取的细微、无意识的步骤会对结果产生重大影响。这些微妙、无意识、通常不言而喻的假设或决定可能会对最终结果产生重大影响。
“内隐认知跳跃”的一个例子
例如，假设我们想要建模一名 SQL 分析师。我们将首先采访他们并问他们几个问题，例如：
● 当你被要求分析一个业务问题时，你会怎么做？
● 您如何确保您的解决方案满足要求？
● <向受访者反映我们所理解的过程>
● 这是否准确地捕捉到了你的流程？<获取更正>
分析师的认知过程及其建模方法的示例
隐性认知过程有多种形式；一个典型的例子是“特定领域的定义”。例如，“畅销书”可能是我们领域专家的一个突出术语，但对其他人来说并非如此。
在我们的 SQL 分析师示例中扩展隐性认知过程
最终，我们将拥有完整的 SOP“方案”，使我们能够模仿表现最佳的分析师。
在规划这些复杂流程时，将它们可视化为图表会很有帮助。当流程很细致且涉及许多步骤、条件和分工时，这尤其有用。
“SQL 分析师 SOP” 包括所有必需的技术步骤，以图表形式呈现
与其他原则不同，认知建模（SOP 编写）是唯一独立的过程。强烈建议您在编写代码之前对流程进行建模。话虽如此，在实施过程中，您可能会根据获得的新见解或理解回头进行更改。
现在我们了解了创建明确定义的 SOP 的重要性，它可以指导我们对问题的业务理解，让我们探索如何使用各种工程技术有效地实现它。
2.2 工程技术
工程技术可帮助实际实施 SOP 并充分利用模型。在思考工程技术原则时，我们应该考虑工具箱中的哪些工具（技术）可以帮助我们实施和塑造 SOP，并帮助模型与我们进行良好的沟通。
工程技术原理
有些工程技术仅在提示层实现，而许多工程技术则需要软件层才能有效，有些则结合了两个层。
工程技术层
这里将介绍两种主要技术：工作流/链和代理。
2.2.1 LLM-Native 架构（又称流程工程或链）
LLM-Native 架构描述了您的应用程序执行任务结果所经历的代理流程。
我们流程中的每个步骤都是一个独立的过程，必须完成才能完成我们的任务。有些步骤将仅通过确定性代码执行；对于某些步骤，我们将使用 LLM（代理）。
为此，我们可以反思一下我们制定的标准操作程序（SOP）并思考：
● 哪些 SOP 步骤应该合并到同一个代理？哪些步骤应该拆分为不同的代理？
● 哪些 SOP 步骤应该以独立的方式执行（但它们可能会从前面的步骤中获得信息）？
● 我们可以在确定性代码中执行哪些 SOP 步骤？
基于给定 SOP 的“维基百科作者”的 LLM-Native Architecture 示例
在进入架构/图表的下一步之前，我们应该定义它的关键属性：
● 输入和输出——这一步的签名是什么？采取行动之前需要什么？（这也可以作为代理的输出格式）
● 质量保证——什么使得响应“足够好”？是否存在需要人工干预的情况？我们可以配置哪些类型的断言？
● 自主水平——我们需要对结果的质量进行多少控制？这个阶段可以处理哪些范围的用例？换句话说，我们在多大程度上可以相信模型在这一点上能够独立工作？
● 触发因素— 下一步是什么？下一步的定义是什么？
● 非功能性— 所需的延迟是多少？我们是否需要特殊的业务监控？
● 故障转移控制— 可能发生哪些类型的故障（系统性和代理性）？我们的后备方案是什么？
● 状态管理
我们是否需要一种特殊的状态管理机制？
我们如何检索/保存状态（定义索引键）？
我们需要持久存储吗？
这种状态有哪些不同的用途（例如，缓存、日志记录等）？
2.2.1 什么是代理？
LLM 代理是 LLM-Native 架构的独立组件，涉及调用 LLM。
这是 LLM 用法的一个实例，提示包含上下文。并非所有代理都相同 — 有些会使用“工具”，有些则不会；有些可能在流程中“仅使用一次”，而其他代理可以递归调用或多次调用，并携带先前的输入和输出。
带工具的代理
一些 LLM 代理可以使用“工具”——用于计算或网络搜索等任务的预定义函数。代理输出指定工具和输入的指令，应用程序执行这些指令，并将结果返回给代理。
为了理解这个概念，让我们看一个用于工具调用的简单提示实现。即使模型本身没有经过调用工具的训练，这也可以发挥作用：
您是可以使用以下工具的助手：
● 计算（表达式：str）-> str - 计算数学表达式
● -搜索（查询：str）-> str - 在库存中搜索物品
给定输入，使用带有键的 YAML 进行响应：func（str）和arguments（map）或message（str）。给定输入
区分具有工具的代理（因此是自主代理）和其输出可以导致执行操作的代理非常重要。
“自主代理是有能力生成完成任务的方法的代理。”
自主代理有权决定是否应采取行动以及采取何种行动。相比之下，（非自主）代理只是“处理”我们的请求（例如分类），并根据此过程，我们的确定性代码执行操作，而模型对此没有任何控制权。
自主代理 VS 触发动作的代理
随着我们提高智能体在规划和执行任务方面的自主性，我们增强了它的决策能力，但可能会减少对输出质量的控制。虽然这看起来像是一个让它更“智能”或“先进”的神奇解决方案，但它的代价是失去对质量的控制。
自主代理的权衡
小心完全自主代理的诱惑。虽然它们的架构可能看起来很有吸引力且更简单，但将其用于一切（或作为初始 PoC）可能会与“实际生产”情况非常不同。自主代理很难调试且不可预测（响应质量不稳定），这使得它们无法用于生产。
目前，代理（没有隐性指导）不太擅长规划复杂流程，通常会跳过必要的步骤。例如，在我们的“维基百科作家”用例中，它们会直接开始写作，跳过系统化流程。这使得代理（尤其是自主代理）的表现只能与模型一样好，或者更准确地说——只能与它们相对于你的任务所训练的数据一样好。
不要让代理（或一群代理）自由地完成所有端到端的工作，而是尝试将他们的任务限制在需要这种灵活性或创造力的流程/SOP 的特定区域。这可以产生更高质量的结果，因为您可以同时享受两个世界。
一个很好的例子就是AlphaCodium：通过将结构化流程与不同的代理（包括一个迭代编写和测试代码的新型代理）相结合，他们将 CodeContests 上的 GPT-4 准确率（pass@5）从 19% 提高到了 44%。
AlphaCodium 的 LLM 架构
虽然工程技术为实现我们的 SOP 和优化 LLM 原生应用程序奠定了基础，但我们还必须仔细考虑 LLM 三角的另一个关键组成部分：模型本身。
2.3 模型
我们选择的模型是项目成功的关键因素——大型模型（例如 GPT-4 或 Claude Opus）可能会产生更好的结果，但规模化成本相当高，而较小的模型可能不那么“智能”，但有助于节省预算。在思考模型原则时，我们应该确定我们的约束和目标，以及哪种模型可以帮助我们实现它们。
模型原理
事实上，我们并不总是需要最大的模型；这取决于任务。为了找到正确的匹配，我们必须有一个实验过程并尝试解决方案的多种变体。
看看我们的“缺乏经验的员工”类比会有所帮助——一个拥有许多学术资格的“聪明”员工可能会轻松完成某些任务。不过，他们可能资历过高，而雇佣“更便宜”的候选人会更具成本效益。
在考虑一个模型时，我们应该根据我们愿意采取的权衡来定义和比较解决方案：
● 任务复杂性——简单的任务（例如总结）更容易用较小的模型完成，而推理通常需要更大的模型。
● 推理基础设施——应该在云端还是边缘设备上运行？模型大小可能会影响小型手机，但对于云服务来说可以接受。
● 定价——我们可以接受什么价格？考虑到业务影响和预期使用情况，它是否具有成本效益？
● 延迟——随着模型变大，延迟也会增加。
● 标记数据——我们是否有可以立即使用的数据，以便用未经训练的示例或相关信息来丰富模型？
在很多情况下，除非你拥有“内部专业知识”，否则多花一点钱聘请一位经验丰富的员工是有帮助的——这同样适用于LLM。
如果您没有标记数据，请从更强大（更大）的模型开始，收集数据，然后利用它来通过少量或微调来增强模型。
2.3.1 微调模型
在对模型进行微调之前，必须考虑以下几个方面：
● 隐私
您的数据可能包含一些必须对模型保密的私人信息。您必须对数据进行匿名化处理，以避免在数据包含私人信息时承担法律责任。
● 法律、合规性和数据权利
在训练模型时可能会引发一些法律问题。例如，OpenAI 使用条款政策禁止您在没有 OpenAI 的情况下使用生成的响应来训练模型。另一个典型的例子是遵守 GDPR 的法律，该法律要求“撤销权”，用户可以要求公司从系统中删除信息。这引发了关于是否应该重新训练模型的法律问题。
● 更新延迟
训练模型时，延迟或数据截断要高得多。与通过上下文嵌入新信息（请参阅下面的“4. 上下文数据”部分）不同，后者可提供即时延迟，而训练模型是一个漫长的过程，需要花费时间。因此，模型重新训练的次数较少。
● 开发和运营
在持续评估结果性能的同时，实施可重复、可扩展且可监控的微调流程至关重要。这个复杂的过程需要不断维护。
● 成本
由于再训练的复杂性以及每次训练所需的高度密集的资源（GPU），因此被认为是昂贵的。
LLM 能够充当上下文学习器，而且新模型支持更大的上下文窗口，这大大简化了我们的实现，即使没有微调也能提供出色的结果。由于微调的复杂性，建议将其作为最后的手段或完全跳过它。
相反，针对特定任务（例如结构化 JSON 输出）或领域特定语言进行微调的模型可以非常高效。小型、特定任务的模型在推理方面比大型 LLM 更有效且成本更低。明智地选择您的解决方案，并在升级到 LLM 培训之前评估所有相关考虑因素。
“即使是最强大的模型也需要相关且结构良好的上下文数据才能发挥作用。”
2.4 上下文数据
LLM 是情境学习者。这意味着通过提供特定于任务的信息，LLM 代理可以帮助我们执行任务而无需特殊训练或微调。这使我们能够轻松地“教授”新知识或技能。在考虑情境数据原则时，我们应该致力于组织和建模可用数据以及如何在我们的提示中编写它。
情境数据原则
为了编写上下文，我们在发送给 LLM 的提示中包含了相关（上下文）信息。我们可以使用两种类型的上下文：
● 嵌入式上下文——作为提示的一部分提供的嵌入式信息片段。
您是< company >中< role >的< name >的得力助手
● 附件上下文——提示开头/结尾处粘贴的信息片段列表
上下文通常使用“提示模板”（例如jinja2或mustache或简单的本机格式化文字字符串）来实现；这样，我们可以优雅地编写它们，同时保留提示的本质：
# 带有附件的嵌入式上下文 context
prompt = f'''您是{name}
的得力助手。{name}是{company}的{role}。帮我写一封{tone}回复附件邮件。务必使用以下方式签署您的电子邮件：{signature} --- {email} '''
2.4.1 小样本学习
少量学习是一种通过示例“教授” LLM 的有效方法，无需进行大量微调。在提示中提供一些代表性示例可以指导模型理解所需的格式、风格或任务。
例如，如果我们希望 LLM 生成电子邮件回复，我们可以在提示中包含一些写得很好的回复示例。这有助于模型学习首选的结构和语气。
我们可以使用不同的示例来帮助模型捕捉不同的极端情况或细微差别并从中学习。因此，包含各种示例以涵盖您的应用程序可能遇到的各种场景至关重要。
随着应用程序的发展，您可以考虑实施“动态小样本”，即以编程方式为每个输入选择最相关的示例。虽然这会增加实施的复杂性，但它可以确保模型针对每种情况获得最合适的指导，从而显著提高各种任务的性能，而无需进行昂贵的微调。
2.4.2 检索增强生成
检索增强生成 (RAG)是一种在生成响应之前检索相关文档以获取更多背景信息的技术。这就像让 LLM 快速浏览特定参考资料以帮助其提供答案。这可以让响应保持最新和真实，而无需重新训练模型。
例如，在支持聊天机器人应用程序上，RAG 可以提取相关的帮助台 wiki 页面来提供 LLM 的答案。
这种方法有助于 LLM保持最新状态，并通过将响应建立在检索到的事实基础之上来减少幻觉。RAG 对于需要更新或专业知识而无需重新训练整个模型的任务特别有用。
例如，假设我们正在为我们的产品构建支持聊天。在这种情况下，我们可以使用 RAG 从我们的帮助台 wiki 中检索相关文档，然后将其提供给 LLM 代理并要求其根据问题撰写答案并提供文档。
实施 RAG 时需要考虑三个关键部分：
● 检索机制 虽然 RAG 的传统实现涉及使用向量相似性搜索来检索相关文档，但有时使用更简单的方法（例如基于关键字的搜索（如BM-25））会更好或更便宜。
● 索引数据结构 未经预处理就直接索引整个文档可能会限制检索过程的有效性。有时，我们希望添加数据准备步骤，例如根据文档准备问题和答案列表。
● 元数据 存储相关元数据可以更有效地引用和过滤信息（例如，将 wiki 页面缩小到仅与用户特定产品查询相关的页面）。这个额外的数据层简化了检索过程。
2.4.3 提供相关背景
与您的代理相关的上下文信息可能会有所不同。虽然这看起来很有用，但向模型（如“非熟练工人”）提供过多的信息可能会让人不知所措，并且与任务无关。从理论上讲，这会导致模型学习不相关的信息（或标记连接），从而导致混乱和幻觉。
当 Gemini 1.5 发布并作为可以处理多达 10M 个 token 的 LLM 引入时，一些从业者质疑上下文是否仍然是一个问题。虽然这是一项了不起的成就，特别是对于某些用例（例如与 PDF 聊天），但它仍然有限，特别是在对各种文档进行推理时。
压缩提示并仅向 LLM 代理提供相关信息至关重要。这可以减少模型在无关标记上投入的处理能力、提高质量、优化延迟并降低成本。
有许多技巧可以提高所提供上下文的相关性，其中大部分与如何存储和编目数据有关。对于 RAG 应用程序，添加数据准备来塑造您存储的信息（例如，基于文档的问题和答案，然后仅向 LLM 代理提供答案；这样，代理就会获得一个总结和简短的上下文），并在检索到的文档上使用重新排名算法来优化结果，这很方便。
“数据为 LLM 本土应用提供了动力。背景数据的战略设计释放了其真正的潜力。”
结论与启示
LLM 三角原则提供了一种结构化的方法来开发高质量的 LLM 原生应用程序，解决了 LLM 的巨大潜力与现实世界实施挑战之间的差距。开发人员可以通过关注 3+1 个关键原则（模型、工程技术和上下文数据）来创建更可靠、更有效的 LLM 驱动解决方案，所有这些都由明确定义的SOP指导。
LLM 三角原则
关键要点
1）从清晰的 SOP 开始： 模拟专家的认知过程，为您的 LLM 申请创建分步指南。在考虑其他原则时，将其用作指南。
2）选择正确的模型： 平衡功能和成本，并考虑从较大的模型开始，然后再转向较小的、经过微调的模型。
3）利用工程技术： 实施 LLM 原生架构并战略性地使用代理来优化性能并保持控制。尝试不同的提示技术，以找到最适合您案例的提示。
4）提供相关背景： 在适当的情况下使用上下文学习，包括 RAG，但要小心不要让不相关的信息淹没模型。
5）迭代和实验： 找到正确的解决方案通常需要测试和改进您的工作。我建议阅读并实施“构建 LLM 应用程序：清晰的分步指南”提示，以获得详细的 LLM-Native 开发流程指南。
通过应用 LLM 三角原则，组织可以超越简单的概念验证，开发出真正利用这种变革性技术力量的强大且可投入生产的 LLM 应用程序。
如何学习大模型
现在社会上大模型越来越普及了，已经有很多人都想往这里面扎，但是却找不到适合的方法去学习。
作为一名资深码农，初入大模型时也吃了很多亏，踩了无数坑。现在我想把我的经验和知识分享给你们，帮助你们学习AI大模型，能够解决你们学习中的困难。
我已将重要的AI大模型资料包括市面上AI大模型各大白皮书、AGI大模型系统学习路线、AI大模型视频教程、实战学习，等录播视频免费分享出来，需要的小伙伴可以扫取。
一、AGI大模型系统学习路线
很多人学习大模型的时候没有方向，东学一点西学一点，像只无头苍蝇乱撞，我下面分享的这个学习路线希望能够帮助到你们学习AI大模型。
二、AI大模型视频教程
三、AI大模型各大学习书籍
四、AI大模型各大场景实战案例
五、结束语
学习AI大模型是当前科技发展的趋势，它不仅能够为我们提供更多的机会和挑战，还能够让我们更好地理解和应用人工智能技术。通过学习AI大模型，我们可以深入了解深度学习、神经网络等核心概念，并将其应用于自然语言处理、计算机视觉、语音识别等领域。同时，掌握AI大模型还能够为我们的职业发展增添竞争力，成为未来技术领域的领导者。
再者，学习AI大模型也能为我们自己创造更多的价值，提供更多的岗位以及副业创收，让自己的生活更上一层楼。
因此，学习AI大模型是一项有前景且值得投入的时间和精力的重要选择。
文章评论