模型选择与参数调优

模型选择与参数调优，讨论的不是怎么训练出更强的模型，而是怎么在应用侧把模型用对。很多问题看上去像“模型不够聪明”，实际是模型选错了、参数开得太激进，或者本来就该靠 RAG 和流程去解决。

所以这篇文章更重要的，不是给你一个参数表，而是帮你建立取舍顺序。

先选模型，再谈参数

如果模型本身就不适合任务，后面怎么调都很吃力。选模型时，至少先看：

• 推理能力够不够。
• 工具调用和结构化输出稳不稳。
• 上下文长度够不够。
• 价格和速度是否能接受。

别一上来就问“Temperature 设多少最好”，那通常是顺序反了。

参数主要在控制什么

应用侧最常碰到的参数，本质上都在控制三个维度：

• 稳定性
• 发散度
• 成本与延迟

比如：

• Temperature 更高，创意更多，但复现性更差。
• max_tokens 更大，内容更完整，但费用和超时风险也更高。
• 上下文给得越多，不代表结果一定越好，反而可能稀释重点。

什么时候别急着怪参数

有几类问题，直觉上像调参，实际上不是：

• 知识过时：先看 RAG。
• 回答跑偏：先看 Prompt 边界。
• 工具乱调：先看 Schema 和服务端校验。
• 结果不稳定：先看任务是不是本来就太开放。

这也是为什么“调参”不该被理解成万能修复器。

什么时候后面才值得考虑微调

以当前知识库路线来说，大多数问题都优先通过模型选择、Prompt、RAG 和流程约束解决。只有当下面这些条件开始同时出现时，才值得认真考虑微调：

• 任务非常固定。
• 数据样本足够稳定。
• 纯 Prompt 很难继续提升。
• 业务价值足够大，值得承担训练和评测成本。

否则，微调很容易变成提前把复杂度引进来。

一句话先记住

真正有效的调优，不是把参数拧到某个神秘数值，而是让模型能力、任务边界和系统约束对齐。

继续阅读

• 03-prompt-engineering/001-what-is-prompt-engineering.md
• 04-rag/001-what-is-rag.md
• 09-ai-agent-engineering/003-token-cost.md