LLM 三角原则解析：简化大模型应用开发的核心指南

在构建基于大语言模型（LLM）的应用时，许多开发者容易陷入过度关注模型本身的误区。实际上，10% 的复杂度来自于模型本身，而 90% 的工作在于以数据为驱动的工程化作业。将 LLM 应用到实际产品中，不仅需要代码功底，更需要工程上的精磨细打。

1、LLM 三角原则概念

LLM 三角原则是一套构建高效 LLM 本地应用的基本指南，由'3+1'个基础组成，即三个核心要素加一个范式。这套原则为开发者提供了清晰的框架和方向，帮助打造出既健壮又可靠的 LLM 应用。

1.1 关键点

该原则包含三个重要维度：模型、工程集成和上下文数据，并通过**标准操作程序（SOP）**进行精细调整。简单来说，把这三部分通过 SOP 进行标准化处理，就是打造高效强大 LLM 应用的秘诀。

2、标准操作程序（SOP）

标准操作程序（SOP）是确保工作质量一致性的关键。在构建 LLM 应用时，我们将模型视为新手，通过 SOP 指导它像专家一样完成任务。

'没有 SOP，再厉害的 LLM 也难以保持一贯的高质量。'

2.1 认知建模

制定 SOP 的第一步是观察业务专家的工作方式。我们需要模仿他们的思考过程，记录每一步操作，形成详尽的操作指南。

隐性认知过程挖掘

隐性认知过程往往难以察觉，但对结果影响巨大。例如'业务特定定义'，不同人员对同一术语的理解可能截然不同。我们可以通过访谈来明确这些定义：

当需要分析业务问题时，通常遵循什么流程？
如何确保解决方案完全符合需求？
是否存在特定的判断标准或阈值？

将这些隐性知识显性化后，可以绘制流程图。特别是当流程包含条件选择和分支时，图表能更直观地展示环节，确保执行者理解无误。

2.2 SOP 实施建议

在设计初期，不必过多关注实现细节，应先对整个流程进行模拟。随着对问题理解的深入，可根据新认识调整模型。与其他原则不同，认知建模是一个独立的过程，建议在动手编写代码之前完成。

3、工程集成

工程集成是实施 SOP 并最大化模型效用的关键。我们需要思考哪些技术工具能帮助执行和完善 SOP，确保模型有效满足需求。

3.1 LLM 应用架构设计

LLM 应用架构描述了任务完成的各个流程。每个步骤独立承担特定任务，有些依靠固定代码，有些依赖 LLM（Agents）。

在设计架构时，需明确以下关键属性：

输入和输出：每一步需要什么输入？Agent 的输出格式是什么？
质量保证：什么样的响应算'足够好'？是否需要人工介入检查？
自主级别：对模型独立工作的信任程度是多少？
触发器：决定下一步行动的条件是什么？
非功能性要求：响应时间、业务监控需求等。
故障转移控制：应对系统性和代理性故障的措施。
状态管理：是否需要持久化存储？如何检索或保存状态？

3.2 代理（Agents）与工具集

LLM Agents 是调用 LLM 的独立组件。根据是否使用工具，可分为自主 Agent 和非自主 Agent。

工具调用示例

一些 LLM Agents 可以利用预定义的工具执行计算或搜索。以下是一个简单的工具调用 Prompt 模板示例：

prompt = """
你扮演的是一个助手，可以使用以下工具：

- calculate(expression: str) -> str - 用于计算数学表达式
- search(query: str) -> str - 用于在库存中搜索项目

接到一个输入后，你需要以 YAML 格式回应，其中包括以下键：`func`(字符串类型) 和 `arguments`(映射类型) 或 `message`(字符串类型)。

给定输入：{user_input}
"""

自主 Agent 拥有决定是否采取行动及其具体行动的权力。相比之下，非自主代理只是简单地'处理'请求，由确定性代码执行具体动作。虽然自主 Agent 看似更智能，但在生产环境中，其调试难度较大且响应质量不稳定。经验表明，在 SOP 中的特定区域限定 Agent 的任务范围，特别是需要创造力的环节，能提高成果质量。

4、模型选择

选用的模型是项目成功的关键因素。GPT-4 或 Claude Opus 等大模型虽能提供优质结果，但成本高昂。较小的模型有助于控制预算，且在特定领域能达到预期效果。

4.1 权衡因素

在选择模型时，需根据可接受的权衡来评估：

任务复杂度：简单任务如摘要生成可用小模型，复杂推理需大模型。
推理基础设施：云端还是端侧运行？设备性能限制。
定价：结合业务影响和使用频率评估投入产出比。
延迟：模型越大，处理速度可能越慢。
标注数据：是否有足够数据丰富模型？

4.2 模型微调策略

在对模型进行微调前，必须考虑隐私、法律合规、更新延迟及成本。LLMs 作为'上下文学习者'的能力已大大简化了应用实现，因此建议仅在必要时才采用微调。

对于特定任务（如生成结构化 JSON）或特定领域应用，微调小模型可能更高效。如果手头没有标注数据，可先使用大模型收集数据，再通过少样本学习或微调提升性能，但需注意合规风险。

5、上下文数据

LLMs 是上下文学习的高手。提供相关任务的具体信息，Agent 便能在不经过特殊训练的情况下完成任务。

5.1 上下文类型

构建有效的上下文通常采用两种类型：

嵌入上下文：直接嵌入到 prompt 文本中。
附件上下文：在 prompt 开头或结尾附加信息片段。

使用模板引擎（如 jinja2、mustache）可以优雅地构建提示内容。

5.2 少样本学习

少样本学习通过在 prompt 中加入准备好的示例，教会 LLMs 新技能。确保示例全面，覆盖各种情况，有助于模型理解复杂场景和细微差异。动态少样本学习可根据特定输入选择最相关的示例，提高性能。

5.3 RAG（检索增强生成）

RAG 技术在 LLM 生成回答前先查找相关文档，提供更准确的上下文信息。这对于需要最新数据或专门知识的任务特别有效。

部署 RAG 时需关注：

检索机制：关键词搜索或向量相似度搜索。
索引数据结构：预处理文档以提高搜索结果质量。
元数据：保留与查询相关的元数据以辅助筛选。

5.4 上下文相关性

提供信息时要把握度。过多的无关信息会让模型不堪重负，导致混淆。应保证信息的相关性，减少计算负担，提高任务执行质量。在 RAG 应用中，提取问题和答案并提供给 Agent，或使用算法对检索文档重新排序，都能优化输出结果。

6、总结与最佳实践

LLM 三角原则提供了一个基础框架，帮助我们在开发产品时发挥 LLMs 的功能。该框架基于三个主要元素：模型、工程集成、上下文数据，以及一套详细的操作步骤（SOP）。

6.1 关键要点

从明确的操作步骤开始：先模拟专家思考和操作，制定详细指南。
选择合适的模型：平衡性能和成本，必要时使用微调小模型。
利用工程技术：建立架构，巧妙利用代理，试验不同的提示技术。
提供相关上下文：合理利用 RAG，避免提供过多无关信息。
不断迭代和实验：找到最佳解决方案需要不断的测试和调整。

6.2 工程落地建议

在实际落地过程中，除了理论框架，还需注意以下工程细节：

监控与日志：建立完善的监控系统，记录每次调用的输入、输出及耗时，便于后续分析和优化。
缓存策略：对于重复的请求，利用缓存机制减少 API 调用次数，降低成本并提升响应速度。
错误处理：设计健壮的异常处理机制，确保在模型返回错误或超时情况下，系统仍能给出友好提示或降级方案。
安全过滤：对用户输入和模型输出进行敏感词过滤和内容安全检测，防止违规内容传播。

通过上述方法，组织不仅能超越基本的概念验证阶段，还能开发出强大、准备好上线的 LLM 应用，最大限度地发挥这项技术的潜力。