随着大模型(LLM)的快速发展,我们面临的不再是如何构建最先进的模型,而是如何在现有的大量模型中找到最适合特定用例的模型。与其盲目追求排行榜首位的模型,不如制定一套切实可行的决策流程。本文将提供一个结构化的框架,帮助你有效地进行LLM选型,确保选择的模型能够满足你的产品目标,并在成本、性能和合规性之间取得最佳平衡。

明确用例与任务:一切选型的基础

LLM选型的旅程中,首要任务是清晰地定义你的用例和任务。你需要详细描述用户旅程,明确你的产品旨在解决什么问题,以及大模型在哪些环节与用户互动。进一步地,你需要明确所需的关键能力:

  • 推理:用于决策支持或链式思考的场景。例如,一个医疗诊断助手需要能够根据症状和检查结果进行推理,给出可能的诊断结果。
  • 检索增强问答 (RAG): 在特定知识库中搜索信息并回答问题的能力。例如,一个企业内部知识库的问答系统,需要能够从海量的文档中检索相关信息,并用简洁明了的语言回答员工的提问。
  • 内容生成:生成文本、代码、图像或音频等内容。例如,一个营销文案生成器需要能够根据产品特点和目标受众,生成吸引人的广告语。
  • 工具使用 / 代码执行:利用外部工具或执行代码来完成任务。例如,一个智能家居控制系统需要能够调用各种API来控制灯光、温度等设备。
  • 分类 / 信息提取:对文本进行分类或提取关键信息。例如,一个新闻分析系统需要能够将新闻文章分类到不同的主题类别,并提取出关键人物、事件和地点。

此外,你还需要确定输入的模态(文本、图像、语音或视频)以及领域的专业性(通用、法律、金融、医疗等)。例如,如果你的应用需要处理法律领域的文本,那么你需要选择一个在法律领域有良好表现的大模型

设定最低性能要求:量化你的期望

LLM选型过程中,仅仅了解模型的功能是不够的,还需要设定明确的性能要求。这需要你选择合适的指标来衡量任务性能,并为这些指标设定明确的阈值

选择1-2个用例相关的指标,例如:

  • 准确率F1 ScoreBLEUROUGE:用于评估生成内容的质量。
  • 幻觉容忍度格式错误容忍度毒性容忍度有用性容忍度:用于评估生成内容的可靠性和安全性。

同时,选择2-3个与系统相关的指标,例如:

  • 忠实性答案相关性上下文相关性:用于评估 RAG 系统的性能。
  • 工具正确性:用于评估基于代理的系统的性能。

避免同时评估过多的指标,这会分散注意力,降低评估结果的有效性。例如,对于一个金融领域的问答机器人,你需要关注其在回答金融问题时的准确率忠实性,同时也要关注其是否会产生幻觉,给出错误的信息。如果一个模型在金融知识问答方面表现出色,但在其他方面(例如,生成诗歌)表现一般,这可能并不重要,因为你更关注其在金融领域的专业性。

明确限制条件:资源约束下的选型

在选择大模型时,必须充分考虑现有的资源和限制条件。如果选择的模型超出了可用资源的范围,那么它可能无法按预期运行。需要明确以下限制:

  • 成本上限:每月API使用预算、每千个 token 的成本、硬件租赁成本。 例如,你可能需要将每月的 API 使用预算限制在1000美元以内,并寻找每千个 token 的成本低于0.001美元的模型。
  • 控制级别:需要选择专有解决方案还是开源解决方案。
  • 隐私和合规性:需要满足 GDPR、HIPAA 等法规的要求。
  • 许可限制:对商业使用或署名有何要求。
  • 延迟目标:最大可接受的响应时间(例如,P95 延迟)。
  • 语言能力:如果需要英语以外的语言,请验证模型是否支持这些语言。
  • 上下文窗口:需要的最小 token 数量;是否需要流式响应。

对于边缘设备上的部署,还需要评估:

  • 硬件限制:边缘设备的 RAM、可用 GPU(这将影响模型的大小)。

例如,如果你的应用需要在欧盟地区运行,并且需要满足 GDPR 的要求,那么你需要选择一个提供欧盟数据驻留选项的大模型,或者选择一个开源模型并将其部署在欧盟境内。

专有模型 vs 开源模型:权衡利弊

上述限制条件将帮助你选择专有 API 或开源模型。如果仍不确定,请考虑以下标准:

  • 数据沿袭:预训练中使用的数据的透明度至关重要。如果细节不足,可能会引起版权问题,并引入隐藏的偏见,这对于依赖自身知识产权的组织来说是一个关键问题。
  • 功能:评估可扩展性,以确保模型能够处理预期的流量,支持必要的功能(如函数调用、结构化输出),并包含必要的输出保护措施。专有模型通常集成了这些功能,而开源替代方案可能需要大量的工程工作,这可能具有挑战性且耗时。

例如,如果你需要使用函数调用功能,并且不希望花费大量时间进行工程开发,那么选择一个提供函数调用功能的专有模型可能是一个更好的选择。

自托管开源模型:云端 vs 本地

如果选择了开源模型并且不希望使用外部 API,则必须在云端或本地进行部署。

通常,云部署设置速度更快,操作更简单,适合大多数现代工作负载。

当严格的数据控制或法规要求超过更高的运营开销时,本地部署就变得有吸引力。

成本:开源模型避免了按 token 许可费,但仍会产生 GPU 基础设施以及配置、优化和持续维护所需的工程资源费用。

注意:如果法规要求数据保留在设备上或极低的延迟至关重要,请考虑直接在设备上部署模型(边缘部署)。

| 特性 | 专有模型 (大型) | 专有模型 (小型) | 开源模型 (大型) | 开源模型 (小型) |
| ————- | ————— | ————— | ————— | ————— |
| 易于使用 | 非常高 | 高 | 低 | 中 |
| 成本 | 中等-高 | 低-中 | 高 | 中 |
| 控制 | 低 | 低 | 高 | 高 |
| 定制化 | 低 | 低 | 中-高 | 高 |
| 部署 | 简单 | 简单 | 复杂 | 中等 |
| 可扩展性 | 高 | 中等 | 中等 | 低 |
| 延迟 | 中等 | 低 | 高 | 中等 |
| 安全性 & 隐私 | 取决于供应商 | 取决于供应商 | 取决于基础设施 | 取决于基础设施 |

候选模型列表:缩小选择范围

首先创建一个全面的列表(例如,来自模型目录或 HuggingFace Hub),然后根据先前定义的约束进行过滤。然后对过滤后的模型进行排名,并选择排名最高的候选模型以进行进一步评估。

例如,你可以在 HuggingFace Hub 上搜索在金融领域表现良好的开源大模型,并根据你的成本预算、上下文窗口大小和语言支持要求进行过滤。

排名与评估:找到最佳匹配

谨慎使用公共排行榜

在参考汇总排行榜(例如,LMSYS Chatbot Arena、HuggingFace Open LLM Leaderboard)时,请考虑:

  • 基准相关性:选择与特定用例相关的基准。一个专注于数学问答的机器人从 GSM-8K 中获得的收益大于翻译任务。定期审查新的基准,因为旧的基准可能会变得饱和。
  • 基准权重:相等的权重会掩盖关键任务中的弱点。根据业务相关性分配权重(例如,60% 编码,40% 推理)。
  • 数据污染:注意潜在的数据重叠,其中基准可能出现在训练数据集中,从而扭曲模型性能得分。

并非所有模型都具有所需基准的公开可用分数。

公共基准非常适合过滤掉明显表现不佳的模型。但是,要找到最适合特定用例的模型,运行私有评估非常重要。

私有评估流程

一个好的起点是将先前定义的性能指标与相关的业务目标对齐。这种对齐有助于确定优化领域。

然后,选择一种评估方法,例如人工评估、基于 AI 的评分(大模型作为评委)或混合方法。

理想情况下,应该构建和注释一个来自真实生产数据并针对特定用例定制的自定义评估数据集。这通常是一项繁琐且耗时的任务,因此在某些情况下,可以合成生成数据集。

确保评估流程可靠。重新运行相同的评估应产生一致的结果。

虽然这听起来很简单,但构建强大的评估流程会增加开发过程的成本和复杂性。有些团队选择跳过它,而是依赖用户反馈。虽然这在某些领域是可以接受的,但在法律或医学等领域,对模型和整个系统进行严格评估至关重要。

例如,你可以使用你的产品中的真实用户数据创建一个自定义的评估数据集,并使用大模型作为评委来评估候选模型在这些数据上的表现。

生产监控:持续优化

部署后,模型的下一个篇章将实时展开。建立反馈循环和漂移检测机制对于保护模型可靠性非常重要。

如果在内部评估期间两个表现最佳的模型获得相似的分数,请在生产环境中进行 A/B 测试,以比较它们在实时数据上的性能。

为了保持 GDPR 合规性,请匿名化所有请求数据,并且仅记录汇总的性能指标。

实例:金融知识助手

以下是一个选择适用于金融知识助手的大模型的示例:

  1. 定义用例和任务

    用例侧重于基于聊天的知识助手,旨在通过回答与经济和个人理财相关的问题来支持终身学习者。主题包括储蓄、投资、通货膨胀和基本税收。

    该助手的主要能力是具有轻微推理的检索增强问答,使其能够解释关键概念并执行简单的计算。

    该系统通过文本输入和输出运行,涵盖金融和经济内容作为其主要领域。

    • 用户交互方式:

      用户通过键入自然语言问题进行交互。助手生成带来源的响应并支持后续查询,以促进更深入的理解。

  2. 最低性能要求

    • 用例相关的:
      • 幻觉率:每 200 个响应中不超过 1 个幻觉
    • 系统相关的:
      • 忠实性:至少 95% 的响应必须包含来自权威来源的引文。
      • 上下文相关性:至少 95% 的情况下,检索到的上下文必须与用户的查询相关,这可以通过检索质量指标或手动审查来衡量。
  3. 重要限制

    • 硬件:仅云推理;
    • 预算:≤ 4 千美元/月,30 万次请求;目标 < 0.01 美元/答案。
    • 合规性:GDPR;必须将日志保存在欧盟境内;不得在用户 PII 上进行训练。
    • 语言:英语 + 德语支持。
    • 许可:允许商业使用的许可或付费 API。
    • 上下文窗口:32k token 上下文,需要长论文。
  4. 模型 API 和自托管

    | 特性 | API | 自托管 |
    | ————————– | —————————————- | —————————————— |
    | 欧盟数据驻留 | * API:一些供应商提供基于欧盟的部署选项 ✔ | * 自托管:完全控制数据位置 ✔ |
    | 延迟和扩展 | * API:随供应商基础设施自动扩展 ✔ | * 自托管:需要专门的 DevOps 和基础设施团队进行扩展 ✖ |
    | 30 万次请求的成本 | * API:每次调用约 0.008 美元,约 2.4 千美元/月 ✔ | * GPU 租赁约 1.7 千美元 + 运营成本约 1 千美元/月 ✔ |
    | 功能完整性 | * API:包括嵌入和内置保护措施 ✔ | * 自托管:需要构建和维护自定义基础设施 ✖ |
    | 决策 | 从托管 API 开始。当使用量超过 X 美元或每月 X 次调用时,重新评估自托管。 | |

  5. 候选模型简表

    • Mistral Large (v24.11)
      • 上下文窗口:128k tokens
      • 定价:输入 2 美元/M,输出 6 美元/M;每 1k token 响应约 0.008 美元
      • 数据驻留:位于巴黎;默认情况下,数据和流量保留在欧盟基础设施内
      • 语言:英语和德语的母语流利程度
    • OpenAI GPT-4o mini
      • 上下文窗口:128k tokens
      • 定价:输入 0.15 美元/M,输出 0.60 美元/M;每 1k token 响应约 0.0007 美元
      • 数据驻留:可通过 Azure 获得欧盟数据驻留选项
      • 语言:支持英语和德语等语言
    • Anthropic Claude 3 Haiku
      • 上下文窗口:200k tokens
      • 定价:输入 0.80 美元/M,输出 4 美元/M;每 1k token 响应约 0.0024 美元
      • 数据驻留:可通过 AWS Bedrock 在多个欧盟地区获得
      • 语言:支持英语和德语等语言
    • Google Gemini 2.0 Flash
      • 上下文窗口:1M tokens
      • 定价:输入 0.10 美元/M,输出 0.40 美元/M;每 1k token 响应约 0.0004 美元
      • 数据驻留:完全在所选区域内运行,包括法兰克福等欧盟多区域端点
      • 语言:强大的德语处理能力
    • Cohere Command R+
      • 上下文窗口:128k tokens
      • 定价:输入 2.50 美元/M,输出 10 美元/M;每 1k token 响应约 0.00625 美元
      • 数据驻留:GDPR 优先平台,具有明确的欧盟托管部署
      • 语言支持:支持英语和德语;针对 RAG 风格的任务进行了优化
  6. 排名和评估

    为了评估语言模型在经济学和推理密集型任务中的性能,选择了两个基准:

    • MMLU-Pro (经济学子集):大规模多任务语言理解基准的精简版本,旨在评估各种具有挑战性的任务中的高级语言理解。
    • Multilingual GSM (MGSM):一个专注于多语言问答的数据集,需要多步推理。

    对于最终得分,MMLU-Pro 结果的权重为 60%,反映了领域知识和事实准确性的重要性。MGSM 分数的权重为 40%,强调逻辑推理能力。

    Cohere Command R+ 只有公开可用的总体 MMLU-Pro 分数,并且未在 MGSM 基准或专门的经济学子集中进行评估。因此,它被排除在最终排名之外。

    MGSM 分数取自 vals.ai

    • 私有评估流程

      Gemini 2.0 Flash 和 Mistral Large 已进入下一个评估阶段。对于针对特定用例量身定制的私有评估,可以应用 LLM-as-a-judge 方法,或者通过设计自定义提示,或者通过使用可用的评估框架之一。此阶段应评估步骤 2(最低性能要求)中定义的三个关键指标。

  7. 生产监控计划

    无论选择哪种模型,持续监控对于维持系统可靠性都至关重要。可以自动化私有评估流程,以实时跟踪实时生产数据上的性能指标,从而能够及早发现降级或故障。

总结:找到适合你的模型

LLM选型并非盲目追求排行榜上的桂冠,而是找到最适合你的问题、预算和预定义限制的模型。本文概述的七步框架引导你从用例定义和约束映射到实时监控。将每个决策都建立在具体的指标、领域要求和成本上限之上,可以最大限度地降低技术风险,控制支出,并使开发团队专注于交付价值而不是调整模型。

经验教训

  • 更少的指标,更清晰的重点:两三个关键业务衡量指标胜过一堆无意义的得分。
  • 资源限制等于设计限制:GPU 配额、延迟上限或合规性规则删除的候选模型比准确性差异更多。
  • 公共排行榜充当过滤器,而不是终点线:内部数据提供关于适用性的决定性判断。
  • API 购买速度,自托管购买控制:当流量或数据驻留需求发生变化时,应重新检查平衡。

通过遵循本文的LLM选型指南,你将能够更有效地进行决策,选择最适合你的用例大模型,并在成本、性能和合规性之间取得最佳平衡。记住,最重要的不是选择最先进的模型,而是选择最适合你的模型的。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注