Day 5：模型选择与模型路由
学习目标
今天要解决的是一个很实际的问题：面对市面上几十个大模型，你怎么选？
这个问题比它看起来复杂得多。不是选”最强的”就行——最强的模型最贵、最慢，而且不是所有任务都需要最强能力。也不是选”最便宜的”就行——最便宜的模型可能无法完成复杂任务，输出的质量达不到要求。
你需要学会的是：根据任务的需求，选择最合适的模型。有时候需要大模型做复杂的推理，有时候小模型就够完成简单的分类，有时候需要专门的模型做特定的工作（比如 Embedding、Rerank、语音识别）。在同一个应用中，不同的环节可能使用不同的模型。
更进一步，你需要学会”模型路由”——设计一套机制，让系统自动根据任务类型选择合适的模型，在成本和效果之间找到最佳平衡。
完成今天的学习后，你应该能说明不同模型的适用场景，能根据任务选择模型组合，能理解模型选择不是越强越好。
核心概念
一、通用对话模型
通用对话模型是大模型中的”全能选手”，能处理各种类型的任务——问答、写作、翻译、分析、编程等。
代表性模型包括 GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro、LLaMA 3 等。它们都有很大的参数量、广泛的训练数据、经过指令微调和 RLHF 对齐。
通用对话模型的特点：
能力全面。一个模型能处理多种任务，不需要为每种任务训练专门的模型。这降低了系统复杂度。
使用简单。只需要发送文本消息，不需要特殊的输入格式。
适应性强。通过不同的 Prompt，同一个模型可以扮演不同角色、完成不同任务。
但也有局限性：
不是所有任务都做得一样好。通用模型在某些领域（比如代码、数学）可能不如专门优化的模型。
成本较高。大参数量意味着每次推理需要更多计算资源，调用费用较高。
速度有限。生成速度受模型大小限制，对于需要快速响应的场景可能不够快。
在企业应用中，通用对话模型通常承担核心的文本理解和生成任务——理解用户意图、分析业务数据、生成报告内容、设计解决方案等。
二、推理模型
推理模型是专门针对复杂推理任务优化的模型。
代表性模型包括 OpenAI 的 o1、o3 系列，以及 DeepSeek-R1 等。它们的特点是在回答之前会进行一段”内部思考”——模型会先分析问题、拆解步骤、验证推理过程，然后再给出最终答案。
推理模型适合以下场景：
数学和逻辑推理。需要多步推理的数学问题、逻辑谜题、复杂计算。
复杂规划。需要考虑多个变量和约束条件的任务规划。
科学分析。需要基于已知条件推导结论的科学问题。
代码调试。需要分析代码逻辑、定位 bug 原因的场景。
推理模型和通用模型的区别在于：通用模型倾向于快速给出答案（有时候是”快但错”），推理模型倾向于慢慢想清楚再回答（“慢但对”）。
在企业应用中，推理模型适合处理需要深度思考的任务。但要注意，推理模型的调用成本通常远高于通用模型，因为”内部思考”也消耗 Token。不适合用于简单任务。
三、代码模型
代码模型是专门在大量代码数据上训练的模型，擅长代码生成、代码理解、代码调试、代码解释等任务。
代表性模型包括 GPT-4 的代码能力、Claude 的代码能力、Codex、DeepSeek-Coder、CodeLlama 等。
代码模型的特点：
理解编程语言语法和语义。不只是把代码当成普通文本，而是理解代码的逻辑结构。
能生成可运行的代码。输出的代码通常语法正确、逻辑合理。
能理解和解释代码。能读懂已有代码并解释其功能。
能发现代码中的 bug。通过分析代码逻辑找到潜在问题。
在企业应用中，代码模型的应用场景包括：AI 辅助编程工具、代码审查自动化、技术文档生成、脚本自动生成等。但要注意，对于你的核心业务逻辑（比如行业分析、岗位拆解），代码模型帮不上忙——这些是通用对话模型的工作。
四、Embedding 模型
Embedding 模型是专门做文本向量化的模型。
代表性模型包括 OpenAI 的 text-embedding-ada-002 和 text-embedding-3 系列、BGE 系列、E5 系列、GTE 系列等。
Embedding 模型的核心功能是把一段文本转换成一个固定维度的数学向量。这个向量捕捉了文本的语义信息——语义相近的文本，向量也相近。
Embedding 模型不能用来生成文本，它只做一件事：把文本变成向量。但这一件事是 RAG 系统的基础——没有 Embedding，就无法做语义检索。
选择 Embedding 模型时要考虑的维度：
向量维度。维度越高，语义信息越丰富，但存储和计算成本也越高。常见的维度有 768、1024、1536、3072 等。
多语言支持。如果需要处理中文，要选择对中文支持好的模型。不是所有 Embedding 模型都能很好地处理中文。
语义捕捉能力。不同模型在语义理解上的精度不同。通常通过基准测试（比如 MTEB 排行榜）来比较。
处理速度和成本。Embedding 操作在 RAG 系统中会频繁调用（每次用户提问都需要做一次），所以速度和成本很重要。
在企业应用中，Embedding 模型主要用于 RAG 系统的文档向量化和查询向量化。它是 RAG 的基础设施，选对了能让检索质量显著提升。
五、Reranker 模型
Reranker 模型是对检索结果进行重新排序的模型。
在 RAG 系统中，初始检索（通过向量相似度）可能返回很多结果，其中一些虽然和查询在语义上相近，但并不真正相关。Reranker 模型会对这些结果做更精确的相关性判断，然后重新排序，把最相关的结果排到前面。
Reranker 模型的工作方式和 Embedding 不同。Embedding 是把文本独立地转成向量，然后比较向量的距离。Reranker 是把查询和候选文档放在一起，直接判断它们之间的相关性。这种”放在一起判断”的方式更精确，但也更慢、更贵。
代表性 Reranker 模型包括 Cohere Rerank、BGE-Reranker、bce-reranker 等。
在 RAG 系统中，Reranker 通常放在初始检索之后：先用向量检索召回一批候选（比如 top-20），然后用 Reranker 对这批候选重新排序（选出 top-5），最后把排好序的结果传给大模型。这种两阶段检索策略兼顾了效率（向量检索快）和精度（Reranker 准）。
六、多模态模型
多模态模型能同时处理文本、图片、音频、视频等多种类型的数据。
代表性模型包括 GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro 等最新一代模型，它们都支持图文混合输入。
多模态模型的应用场景：
图片理解。识别图片中的内容、读取图片中的文字、分析图表数据。
文档解析。直接把 PDF 页面作为图片传给模型，让它读取内容，比传统的 PDF 解析更灵活。
视觉问答。用户上传图片并提问，模型基于图片内容回答。
在企业应用中，多模态模型特别适合处理非结构化数据——扫描件、照片、图表、复杂排版的文档等。传统方法需要 OCR + 文本处理的场景，多模态模型可以一步搞定。
但多模态模型的调用成本通常高于纯文本模型（因为图片需要更多的处理），而且对图片的理解能力仍有局限（复杂图表可能理解错误）。
七、语音模型
语音模型分为两类：语音识别（把语音转文字，ASR）和语音合成（把文字转语音，TTS）。
代表性产品包括 OpenAI 的 Whisper（语音识别）和 TTS API（语音合成）、 ElevenLabs（高质量语音合成）等。
语音模型在企业应用中的场景：
客服系统。用户通过语音提问，系统转成文字后交给大模型处理，再把回答转成语音返回。
会议记录。自动把会议录音转成文字，然后用大模型做总结和分析。
语音助手。类似 Siri 但更强大的语音交互系统。
语音模型本身不做”智能”，它只是完成语音和文字之间的转换。真正的”智能”仍然来自大语言模型。但语音模型是连接语音交互和文本处理的桥梁。
八、图像模型
图像模型是生成或编辑图片的模型。
代表性模型包括 DALL-E 3、Midjourney、Stable Diffusion、Flux 等。
图像模型在企业应用中的场景：
营销素材生成。自动生成广告图、社交媒体配图。
产品设计辅助。快速生成设计概念图。
报告配图。给分析报告添加可视化图表或示意图。
图像模型和大语言模型是两个不同的技术方向，但它们可以在应用层面协同工作。比如大语言模型根据用户需求生成一段图像描述提示词，然后图像模型根据提示词生成图片。
九、本地模型与云模型
模型部署方式有两种：调用云端的 API（云模型）和在本地服务器上运行（本地模型）。
云模型的代表是 OpenAI API、Anthropic API、Google AI API 等。你不需要自己部署模型，只需要调用 API。优点是使用简单、模型能力强、不需要管理基础设施。缺点是数据要发送到第三方（可能有隐私合规问题）、按调用量计费（大量使用时成本高）、依赖网络（断网不可用）。
本地模型的代表是 LLaMA、Qwen、ChatGLM、Mistral 等开源模型。你需要自己的 GPU 服务器来运行模型。优点是数据不出本地（隐私安全）、不按调用量计费（只有硬件和电费）、可以离线使用。缺点是需要 GPU 硬件（成本不低）、开源模型能力通常不如顶级商业模型、需要自己维护和更新。
在企业应用中，选择本地还是云模型通常取决于以下因素：
数据敏感度。如果涉及高度敏感的数据（比如医疗、金融），可能要求数据不能离开企业网络，只能用本地模型。
使用量。如果调用量很大（每天几万次以上），本地模型的总成本可能低于云模型。如果调用量小，云模型更划算。
性能要求。顶级商业模型（GPT-4、Claude）的能力目前仍优于最好的开源模型。如果对输出质量要求很高，云模型是更好的选择。
团队技术能力。运行本地模型需要 GPU 运维、模型部署、性能调优等技术能力。
在很多时候，企业会选择混合方案：核心敏感任务用本地模型，一般任务用云模型。这也就是后面要讲的”模型路由”。
十、模型选择决策树
模型选择不是一个拍脑袋的决定，它应该有一个清晰的决策过程。
第一步：明确任务类型。是文本理解和生成？是代码相关？是需要深度推理？是做向量化？是做重排序？是处理图片？是处理语音？不同的任务类型对应不同的模型类别。
第二步：确定质量要求。输出需要多高的准确率？允许偶尔的格式错误吗？用户对等待时间有多大的容忍度？质量要求决定了你是否需要最贵的模型。
第三步：评估成本约束。每次调用的预算是多少？每天的总预算是多少？成本约束决定了你能用什么级别的模型。
第四步：考虑数据敏感性。数据能发送到第三方吗？是否需要本地部署？数据敏感性决定了你能用云模型还是本地模型。
第五步：考虑延迟要求。用户能等多久？毫秒级响应还是秒级响应就可以？延迟要求决定了你能用多大的模型。
第六步：做出选择并验证。选定模型后，用实际数据测试效果。如果效果不达标，调整选择或者调整 Prompt。
十一、模型路由策略
模型路由是指在一个应用中，根据任务的特征自动选择合适的模型。
为什么需要模型路由？因为在实际应用中，不是所有任务都需要最贵最强的模型。一个行业分析系统可能同时处理以下任务：
简单分类（判断用户输入属于哪种类型）——可以用小模型，成本是 GPT-4 的十分之一，速度也更快。
文本生成（生成行业分析报告）——需要大模型的深度理解能力，必须用 GPT-4 级别的模型。
向量化（把文档转成向量）——需要专门的 Embedding 模型，不是通用大模型的工作。
重排序（对检索结果重新排序）——需要专门的 Reranker 模型。
如果所有任务都用最贵的模型，成本会非常高。模型路由的目标是让每个任务都用到最合适的模型，在不牺牲关键质量的前提下最小化成本。
常见的模型路由策略：
基于任务类型路由。根据任务类型（分类、生成、检索等）选择对应的模型。这是最简单也最常见的策略。
基于复杂度路由。评估任务的复杂程度，复杂任务用大模型，简单任务用小模型。复杂度可以通过输入长度、任务类型、历史数据等来判断。
基于成本路由。设置成本预算，优先选择成本最低的模型，只有当低成本模型无法满足要求时才升级到更贵的模型。
基于延迟路由。对延迟敏感的任务用轻量模型（响应快），对延迟不敏感的任务用重量模型（质量高）。
动态路由。根据实时的模型负载、成本预算、质量指标等动态调整路由策略。
十二、成本与效果权衡
模型选择的核心问题就是成本与效果的权衡。
一个简单的成本模型：每次模型调用的成本等于输入 Token 单价乘以输入 Token 数量加上输出 Token 单价乘以输出 Token 数量。
以 GPT-4o 为例，输入大约每百万 Token 2.5 美元，输出大约每百万 Token 10 美元。一次典型的行业分析调用（输入 2000 Token、输出 3000 Token）成本大约是 0.035 美元，约合人民币 0.25 元。看起来不多，但如果每天有 1000 次调用，一个月就是 7500 元。如果每次分析需要调用 5 次模型（多次处理），成本就变成了 37500 元/月。
这就是为什么需要认真考虑成本优化：
用小模型处理简单任务。一个分类任务用 GPT-4o-mini 可能只要 0.002 美元，用 GPT-4o 要 0.035 美元，差了 17 倍。
设计缓存机制。相似的问题不重复调用模型，直接返回缓存的结果。
批量处理。把多个小任务合并成一次调用，减少调用次数。
控制输出长度。在 Prompt 中明确限制输出长度，避免模型生成过长的内容浪费 Token。
选择合适的模型级别。不是所有场景都需要最好的模型。用 A/B 测试来找到”够用”的模型级别。
概念关系图
模型选择全景图
+----------------------------------------------------------+
| 任务类型 |
| |
| +----------+ +----------+ +----------+ +----------+ |
| | 文本生成 | | 深度推理 | | 代码生成 | | 向量化 | |
| +----+-----+ +----+-----+ +----+-----+ +----+-----+ |
| | | | | |
| v v v v |
| +----------+ +----------+ +----------+ +----------+ |
| | GPT-4o | | o1/o3 | | Claude | | Embedding| |
| | Claude | | DeepSeek | | CodeLlama| | BGE/E5 | |
| | Gemini | | R1 | | | | | |
| +----------+ +----------+ +----------+ +----------+ |
| |
| +----------+ +----------+ +----------+ +----------+ |
| | 重排序 | | 图片理解 | | 语音识别 | | 图像生成 | |
| +----+-----+ +----+-----+ +----+-----+ +----+-----+ |
| | | | | |
| v v v v |
| +----------+ +----------+ +----------+ +----------+ |
| | Cohere | | GPT-4o | | Whisper | | DALL-E | |
| | BGE-Re | | Claude | | | | Flux | |
| +----------+ +----------+ +----------+ +----------+ |
+----------------------------------------------------------+
模型路由策略
+----------------------------------------------------------+
| |
| 用户请求 |
| | |
| v |
| +--------+ |
| | 任务 | |
| | 分析器 | |
| +---+----+ |
| | |
| +-------+--------+---------+---------+ |
| | | | | | |
| v v v v v |
| +------+ +------+ +------+ +------+ +------+ |
| | 小模型| | 大模型| | 推理 | | 嵌入 | | 重排 | |
| | 分类 | | 生成 | | 模型 | | 模型 | | 模型 | |
| +------+ +------+ +------+ +------+ +------+ |
| | | | | | |
| +-------+--------+---------+---------+ |
| | |
| v |
| +-----------+ |
| | 结果整合 | |
| +-----------+ |
+----------------------------------------------------------+
成本与效果权衡
+----------------------------------------------------------+
| |
| 效果高 |
| ^ |
| | * GPT-4o |
| | * Claude 3.5 |
| | * GPT-4o-mini |
| | * 小模型 |
| +-----------------------------------------> 成本高 |
| |
| 目标：在满足效果要求的前提下，选择成本最低的模型 |
+----------------------------------------------------------+
实战分析
做模型选择决策树
决策树应该覆盖所有常见的任务类型。从任务类型开始分支，每个分支考虑质量要求、成本约束、数据敏感性、延迟要求，最终指向具体的模型推荐。
为 20 个 AI 应用场景选择模型
这 20 个场景应该覆盖不同的任务类型和复杂度。每个场景的分析应该包含：场景描述、任务类型、质量要求、推荐的模型、推荐理由、预计成本。
设计低成本模式和高质量模式
同一个应用可以有两种运行模式。低成本模式用小模型 + 简单流程，牺牲一些质量来换取低成本和快速响应。高质量模式用大模型 + 完整流程，追求最高质量。两种模式的对比应该包含：使用的模型、调用的步骤、预计成本、预计效果、适用场景。
分析半导体 AI 场景需要哪些模型
半导体 AI 场景涉及多种任务：工艺文档检索（Embedding + Reranker + 通用模型）、良率数据分析（推理模型）、报告生成（通用模型）、设备异常图片识别（多模态模型）。每个场景需要哪些模型，它们怎么组合，成本大概多少。
当日产物说明
《模型选择决策树》
一张清晰的决策流程图，从任务类型出发，经过质量、成本、数据、延迟等维度的判断，最终指向具体的模型推荐。质量标准：覆盖所有主要任务类型，决策逻辑清晰，非技术人员也能跟着做选择。
《20 个场景模型选择表》
一个详细的表格，包含 20 个 AI 应用场景的模型选择分析。每个场景包括：场景描述、任务类型、输入输出特征、推荐模型、推荐理由、预计成本估算。质量标准：场景覆盖面广，从简单到复杂都有，模型选择合理有据。
《模型路由策略草案》
一份描述如何在应用中实现模型路由的文档。包含：路由决策逻辑、模型配置表、成本控制策略、降级策略。质量标准：路由逻辑清晰可执行，覆盖主要的任务类型和异常情况。
《低成本版 / 高质量版模型方案》
同一应用在两种模式下的模型配置对比。包含：每个步骤用什么模型、每次调用的成本、完整流程的总成本、效果对比、适用场景说明。质量标准：两种模式的差异清晰，成本估算合理，能帮助客户根据预算做出选择。
常见误区与避坑
误区一：所有任务都用最贵的模型
这是最浪费的做法。很多任务（分类、提取、格式化）用便宜的小模型就足够了。把 GPT-4 级别的模型用来做”判断这段文字是正面还是负面”这种简单任务，就像用大炮打蚊子。学会区分任务的复杂度，按需选模型。
误区二：过度追求开源免费
开源模型免费但不是没有成本。运行开源模型需要 GPU 服务器，一块 A100 GPU 的月租费可能就要几万元。加上运维人力、模型更新、性能调优的成本，总拥有成本可能比调用商业 API 还高。要算总账，不要只看表面价格。
误区三：忽视模型组合的价值
很多人只关注选哪个”主模型”，忽视了 Embedding 模型、Reranker 模型等专业模型的价值。在 RAG 系统中，一个好的 Embedding 模型 + 一个好的 Reranker 模型，对最终效果的影响可能比换一个更好的主模型更大。
误区四：不关注模型的实际成本
很多人在设计系统时不计算成本，等到上线后才发现调用费用远超预算。在设计阶段就要做成本估算——每个功能的模型调用次数、每次调用的 Token 量、对应的费用。这能帮你在设计阶段就做出合理的取舍。
误区五：模型选好后就不变了
模型的性价比在不断变化。新的模型发布、价格调整、能力提升都可能影响你的选择。应该定期重新评估模型选择，看看有没有更好的方案。
延伸思考
今天的模型选择和路由策略为后续的成本优化（Week 5）打下了基础。在 Week 5 中，你会深入学习如何精细化地管理模型调用成本——缓存策略、Token 优化、批量处理、动态路由等。
从架构角度看，模型路由是 AI 应用架构设计中的重要一环。一个好的模型路由层应该把模型选择的复杂性封装起来，让上层业务代码只需要说”我要做什么”，而不需要关心”用哪个模型”。这种解耦让系统更灵活——当有新模型发布时，只需要调整路由层的配置，不需要修改业务代码。
从商业角度看，理解模型成本能帮你做出更准确的报价。一个 AI 应用的运行成本中，模型调用费用通常占大头。如果你不知道成本结构，报价就只能是拍脑袋。如果你能精确计算出每个功能模块的模型调用成本，就能做出既合理又有利润的报价。
自测问题
-
通用对话模型和推理模型的核心区别是什么？各适合什么场景？
-
Embedding 模型在 RAG 系统中扮演什么角色？选择 Embedding 模型要考虑哪些因素？
-
Reranker 模型和向量检索有什么区别？为什么 RAG 系统通常两者都用？
-
云模型和本地模型各有什么优缺点？什么情况下应该选择本地模型？
-
什么是模型路由？为什么一个应用需要使用多个模型？
-
设计模型选择决策树时，需要考虑哪些维度？
-
如果一个企业 AI 应用的月度模型调用预算是 5000 元，你会怎么分配？
-
为什么说”模型选择不是越强越好”？请从成本、速度、适用性三个角度分析。
-
一个 RAG 系统通常需要哪些类型的模型？它们各自负责什么？
-
多模态模型在企业应用中的价值是什么？举两个具体场景。
关键词
- 通用对话模型：能处理多种任务的通用大语言模型
- 推理模型：专门优化复杂推理能力的模型，如 o1、DeepSeek-R1
- 代码模型：专门在代码数据上训练的模型
- Embedding 模型：专门做文本向量化的模型
- Reranker 模型：对检索结果重新排序的模型
- 多模态模型：能同时处理文本、图片等多种数据类型的模型
- 语音模型：处理语音识别和语音合成的模型
- 图像模型：生成或编辑图片的模型
- 本地模型：在自有服务器上部署的开源模型
- 云模型：通过 API 调用的商业模型服务
- 模型路由：根据任务特征自动选择合适模型的机制
- 成本与效果权衡：在输出质量和调用成本之间找到最佳平衡点