LLM 三角原则：简化大型模型应用开发流程与模型管理
不少开发者在构建 LLM 应用时，往往误以为核心在于复杂的模型本身。实际上，10% 是复杂的模型，而 90% 是实验性的、以数据为驱动的工程作业。将 LLM 应用到实际产品中，不仅需要代码功底，更需要工程上的精磨细打。
1. LLM 三角原则概念
LLM 三角原则是构建高效 LLM 本地应用的一套基本指南。它由'3+1'个基础组成（一范式三原则），适合任何团队实践。这套原则为开发者提供了清晰的框架，帮助打造出既健壮又可靠的 LLM 应用。
1.1 关键点
LLM 三角原则介绍了一个范式三大实用原则：模型、工程集成和上下文数据。通过标准操作程序（SOP）对这三部分进行精细调整，是打造高效强大 LLM 本地应用的秘诀。
2. 标准操作程序（SOP）
标准操作程序（SOP） 类似于操作手册，详细记录每一步怎么做，确保工作质量一致。在构建 LLM 应用时，我们将模型视为新手，通过 SOP 指导其像专家一样完成任务。
'没有 SOP，再厉害的 LLM 也难以保持一贯的高质量。'
2.1 认知建模
制定 SOP 前，需观察业务专家的工作方式，模仿他们的思考过程，并将每一步记录下来。将复杂任务分解成小步骤，有助于减轻认知负担。
例如，模拟数据分析工作流程时，可以通过访谈了解专家的具体步骤：
- 当需要分析一个业务问题时，你通常会怎么做？
- 你是如何确保你的解决方案完全符合需求的？
- 反馈理解的过程，确认流程覆盖是否完整。
隐性认知过程形式多样，如'业务特定定义'。对于'畅销书'等术语，专家有明确定义，而一般人可能不清楚。绘制流程图有助于清晰展示包含条件选择和分支的复杂环节。
最终解决方案应严格按照 SOP 定义的步骤执行。在设计初期不必过度关注实现细节，可先对整个流程进行模拟。
3. 工程集成
工程集成是实施 SOP 并最大化模型效用的关键。我们需要思考哪些技术工具能帮助我们执行和完善 SOP。
主要涉及两种重要技术：工作流/链路和 Agents。
3.1 LLM 应用架构设计（工作流或链路）
LLM 应用架构描述完成任务的各个流程。每个步骤独立承担特定任务，有些靠固定代码，有些用到 LLM（Agents）。
重新审视 SOP 时需考虑：
- 哪些 SOP 步骤应合并到同一个流程中？
- 哪些步骤应独立执行？
- 哪些步骤可通过固定步骤实现？
关键属性包括：
- 输入和输出：每一步需要什么输入？
- 质量保证：什么样的响应算'足够好'？是否需要人工介入？
- 自主级别：对结果的质量控制程度及信任度。
- 触发器：决定下一步行动的条件。
- 非功能性要求：响应时间、业务监控等。
- 故障转移控制：应对系统性和代理性故障的措施。
- 状态管理：是否需要持久化存储或缓存机制。
3.2 代理 (Agents) 是什么？
在 LLM 本地架构中，LLM Agents 是一个调用 LLM 的独立组件。每个 Agent 都是 LLM 的一个实例，其中 prompt 包含相应上下文。Agent 可以使用工具，也可以被递归调用。
3.2.1 Agents 与工具集
一些 LLM Agents 可以利用'工具'——预先定义好的功能，如数学计算或网络搜索。当 Agents 需要使用某个工具时，它会明确指出所需的工具及其输入参数。
# 工具调用示例
func: calculate
arguments:
expression: "1 + 2"
我们需要区分两种代理：带有工具的代理（自主 Agent）和非自主代理。自主 Agent 拥有决定是否采取行动及其具体行动的权力；非自主代理只是简单地处理请求，由确定性代码执行具体动作。
随着增加 Agent 的自主性，决策能力增强，但潜在风险是降低对最终输出质量的控制。自主 Agent 难以调试且响应质量不稳定，通常不适合在生产环境中直接使用。
与其让 Agent 自由完成所有环节，不如在 SOP 中的特定区域限定它们的任务，特别是需要创造力和灵活性的环节。结合 AlphaCodium 的经验，将固定流程与不同功能的 Agent 相结合，可显著提升任务执行效果。
4. 模型
选用的模型是项目成功的关键因素。大模型如 GPT-4 或 Claude Opus 提供优质结果但成本高；较小模型成本低，在某些领域能达到预期效果。
并非所有的 LLM 都是相同的。要使模型与任务相匹配。
选择模型时需权衡：
- 任务复杂度：简单任务可用小型模型，复杂推理需较大模型。
- 推理基础设施：云端还是端侧运行？
- 定价：预算限制与业务影响。
- 延迟：模型越大，处理速度可能越慢。
- 标注数据：是否有足够数据丰富模型。
如果手头没有标注数据，可先用更大模型收集数据，再通过少样本学习或微调提升性能，但需注意合规风险。
4.1 模型微调
微调前需考虑：
- 隐私：敏感信息需匿名化处理。
- 法律、合规性和数据权利：遵守使用条款及 GDPR 等法规。
- 更新延迟：重新训练通常需要更多时间。
- 开发和操作：建立可重复、可扩展的微调流程。
- 成本：资源需求高，代价昂贵。
LLMs 作为'上下文学习者'的能力已大大简化应用实现。建议只在必要时采用微调，或尽可能避免使用。对于特定任务（如生成结构化 JSON）或特定领域应用，微调可能更有效。
请注意，即使是最先进的模型，也需要依赖相关而且结构合理的上下文数据，才能充分发挥其潜力。
5. 上下文数据
LLMs 是上下文学习的高手。只要提供相关任务的具体信息，LLM Agent 便能在不经过特殊训练的情况下完成任务。
构建有效上下文需在 prompt 中包含相关信息，通常采用两种类型：
- 嵌入上下文：直接嵌入到 prompt 文本中。
- 附件上下文：在 prompt 开头或结尾附加信息片段。
# 带有附件上下文的嵌入上下文示例
prompt = f"""
你是{name}的得力助手，{name}在{company}担任{role}。
帮助我用{tone}语气回复附加的电子邮件。
始终以以下签名结尾：
{signature}
---
{email}
"""
5.1 少样本学习
少样本学习通过在 prompt 中加入准备好的示例，教会 LLMs 新技能。提供多种不同的示例，模型可以更好地理解各种复杂情况。动态少样本学习可根据特定输入选择最相关的示例。
5.2 RAG
检索增强生成（RAG）在 LLM 生成回答之前先查找相关文档，提供更多上下文信息。例如，聊天机器人利用 RAG 自动查找并提取相关的帮助台维基页面。
部署 RAG 时需关注：
- 检索机制：基于关键词或相似内容搜索。
- 索引数据结构：可能需要预处理数据，制作问答对列表。
- 元数据：保留与查询相关的元数据以筛选信息。
5.3 提供相关上下文
提供信息给 Agent 时要把握度。过多无关信息会让模型不堪重负，造成混淆。提高上下文信息的相关性，可加入准备数据的步骤，如从文档中提取问题和答案，只向 Agent 提供这些答案。
'数据是 LLM 应用的核心驱动力。好的上下文数据能最大限度地发挥出它的潜力。'
6. 总结
LLM 三角原则提供了一个基础框架，帮助我们在开发产品时发挥 LLMs 的功能。这个框架基于三个主要的元素：模型、工程集成、上下文数据，以及一套详细的操作步骤（SOP）。
6.1 关键要点
- 从明确的操作步骤开始：先模拟专家如何思考和操作，制定详细操作指南。
- 选择合适的模型：考虑到性能和成本之间的平衡，可从大模型开始，后续调整为微调的小模型。
- 利用工程技术：建立 LLM 本地架构，巧妙利用代理提升性能，同时确保能控制整个过程。
- 提供相关上下文：合理利用上下文信息来增强学习，比如使用检索增强生成（RAG），但要注意避免提供太多无关信息。
- 不断迭代和实验：找到最好的解决方案需要不断的测试和调整。