企业官网建设流程全解析

• 文档
• 教程
• 知识库

选择合适的 LLM 是 AI 应用开发中最关键也最容易出错的一步。本文基于 developer-roadmap 仓库中 ai-engineer 学习路径的「Choosing the Right Model」章节，系统拆解模型选型的核心决策维度——任务复杂度、预算、准确率、速度与泛化能力，并结合仓库内 fine-tuning、RAG vs Fine-tuning、self-hosted-models 等相关章节，给出一套可落地的选型方法。读完本文，你将掌握从需求分析、候选模型对比到成本与性能权衡的完整选型流程。

为什么「选对模型」是 AI 工程的核心决策

在 ai-engineer 学习路径 中，「Choosing the Right Model」被列为独立主题，因为它直接决定应用的性能上限、单位成本和用户体验。选型没有绝对正确的答案，只有「在当前约束下最合适」的答案。决策需要同时权衡以下几类因素：

• 任务复杂度：简单任务用小模型即可胜任，复杂任务需要更大容量的模型；
• 预算（cost）：更大的模型通常需要更多计算资源，成本随之上升；
• 性能（performance）：准确率（accuracy）、速度（speed）与泛化能力（generalization）三者往往此消彼长；
• 定制化需求：当通用能力不满足特定领域要求时，需要考虑在自有数据集上对现有模型做微调（fine-tuning）。

仓库同时将该主题与 Open vs Closed Source Models、Pricing of Common Models 等主题编排在一起，共同构成选型的完整知识闭环：先选开源/闭源路线，再对比具体模型，最后核算成本。

按任务复杂度匹配模型规模

选型的第一步是评估任务复杂度，而不是直接比较模型榜单。仓库文档给出的原则非常明确：

更简单的任务可能只需要更小、更高效的模型，而更复杂的问题则需要容量更大的模型。

可以按以下分层思路快速定位：

「模型容量」并不等同于「参数越多越好」。评估时应以任务本身的需求为准：如果应用是高频低风险的轻量调用（例如大量日志分类），选择超大模型会带来不必要的延迟与成本；只有任务确实需要深层推理或多步规划时，大模型的容量优势才能转化为业务价值。

成本是硬约束：理解算力与定价的关系

成本是选型中最容易被低估的约束。文档明确指出：

成本也是一个关键因素，因为更大的模型通常需要更多的计算资源。

这里的「成本」包含两个层面：

1. API 调用成本：按 token 计费。不同提供方对每百万输入/输出 token 的费率差异很大，且模型规模、能力档位之间价格相差悬殊。仓库在 Pricing of Common Models 章节中强调：供应商会频繁发布新模型、价格变动很快，不能凭记忆假设价格，必须对照最新的官方价目表（rate card）核算。
2. 自托管算力成本：如果选择自托管路线，需要为 GPU/内存等基础设施买单。仓库在 Self-Hosted AI Models 章节指出，自托管意味着自己掌控硬件、软件与数据，可以获得更强的定制性、安全性与数据控制，但从长期成本看是否划算，取决于具体的需求规模与使用量——低频使用下自托管硬件闲置成本反而更高。

一个务实的成本策略是：先估算生产环境的 token 用量与任务调用频率，再结合价目表计算不同模型的月度成本，最后用成本上限反推可选模型集合，而不是先选模型再被动接受账单。

同时评估准确率、速度与泛化能力

选型不是单一指标的最优解，而是多维指标的平衡。文档要求开发者评估模型的三个核心能力：

• 准确率（accuracy）：在目标任务上的正确率，直接决定业务质量。应使用贴近生产环境的评测集验证，而非依赖宣传性的基准分数。
• 速度（speed）：影响用户体验与吞吐量。大模型推理更慢，若应用对延迟敏感（如实时助手、在线客服），小模型或经过优化的推理部署往往更合适。
• 泛化能力（generalization）：模型面对训练时未见过的新数据、新场景的表现。泛化能力强的模型更适合输入分布多变的开放场景；而输入模式固定、分布稳定的场景则不需要过强的泛化冗余。

这三者常常互为代价：更大的模型通常准确率与泛化更强，但速度更慢、成本更高。选型的本质就是在三者之间做面向业务目标的权衡。建议为每个候选模型在同一评测集上记录「准确率 / 延迟 / 单次调用成本」三组数据，形成对比表后再决策，避免凭「感觉」（vibes）选型。

什么时候需要微调（Fine-tuning）

当通用模型在特定领域上的表现不达预期时，文档给出的下一选项是：

如果需要在特定性能上获得专门表现，可以考虑在自有数据集上微调现有模型。

微调（fine-tuning）的定位在仓库的 Fine-tuning 章节中有更完整的阐述：它是在预训练模型基础上，用较小的任务专属数据集做继续训练，让模型在特定任务或领域上表现更好。但文档同时给出了重要提醒——微调并非总是最优解：

• 微调是资源密集型的，需要算力、数据与工程投入；
• 在某些场景下，提示工程（prompt engineering）、检索增强生成（RAG）或使用更小的专用模型，能以更低的计算开销和数据需求达到相近甚至更好的效果。

因此正确的决策顺序是：先尝试成本最低的手段（提示工程）→ 再用 RAG 引入动态外部知识 → 最后才考虑微调。关于 RAG 与微调的差异，仓库在 RAG vs Fine-tuning 章节做了清晰对比：

微调适合「知识范围固定、需要稳定专业行为」的领域（如特定文风、私有术语体系）；RAG 适合「知识持续更新、需要引用事实依据」的场景（如企业知识库问答）。把二者结合使用也常见：微调负责行为与格式，RAG 负责知识供给。

结合开源/闭源路线与本地部署做整体决策

模型选型不仅发生在「用哪个 API」，还涉及「用哪条技术路线」。仓库将 Open vs Closed Source Models 列为相邻主题，其核心权衡是：

• 开源模型：可自由定制与协作，透明、灵活，可自托管、可微调，适合对数据主权和成本控制要求高的团队；
• 闭源模型：专有、开箱即用，开发效率高，但修改能力与透明度受限，长期成本受供应商定价影响。

如果选择开源路线并本地部署，可借助 Ollama 这类工具在本地设备上直接运行模型，实现离线推理、低延迟与数据不出域；部署形态上，本地服务器监听127.0.0.1:8000这类地址适合快速测试与私有实验（详见 Connect to Local Server），但其吞吐受本机硬件限制。整体决策链可归纳为：

需求与任务复杂度评估 ├─ 需要实时/事实性知识？→ 考虑 RAG ├─ 需要专用行为与风格？→ 考虑微调 ├─ 需要数据主权与长期成本可控？→ 考虑开源 + 自托管 └─ 追求开发效率与极致能力？→ 考虑闭源 API 最终：结合价目表与评测数据完成对比选型

一套可执行的选型清单

将文档要点整理为可直接照做的决策清单：

1. 明确任务复杂度：区分简单、中等、复杂任务，锁定模型规模区间；
2. 定义性能基线：确定可接受的准确率、延迟与泛化要求，并建立评测集；
3. 核算成本上限：预估 token 用量，对照最新价目表计算候选模型的月度成本，划掉超出预算的选项；
4. 对比候选模型：在同一评测集上记录准确率 / 延迟 / 成本三项数据；
5. 先尝试低成本手段：按「提示工程 → RAG → 微调」的顺序优化，只有前两者无法达标时再引入微调；
6. 决定部署路线：根据数据主权、隐私与长期成本选择开源自托管或闭源 API；
7. 持续复盘：新模型发布、价格变动后重新评估，选型不是一次性决定。

这套流程覆盖了 developer-roadmap 中「Choosing the Right Model」章节的全部核心维度——任务复杂度、预算、准确率、速度、泛化能力与微调策略，并与其他相关章节相互印证，可作为 AI 应用立项时的标准选型参考。

• 文档
• 教程
• 知识库