模型怎么选：别从参数量开始比

模型选型的讨论常常从榜单开始，但榜单衡量的是通用能力，而企业场景里的任务往往很窄：把一段咨询归类、从合同里抽取几个字段、按模板改写一段话。这类任务不需要最强的模型，用最强的反而是在为用不到的能力付费。

四个判断维度

1. 任务难度：分类、抽取、改写这类结构化任务，中小档位模型通常足够；需要多步推理、跨文档综合判断的，才需要更强的；
2. 上下文长度：要一次喂进去多少材料。这一项是硬约束，不够就是不够，无法用其他方式弥补；
3. 时延要求：用户等待的场景与后台批处理的场景，可接受的响应时间差一个数量级；
4. 部署形态：数据能否出企业网络，决定了可选范围，这通常是最先要确认的一条。

同一个系统里可以用不同档位

一个常见且有效的做法是分层：简单任务走小模型，拿不准时再交给大模型。例如先用小模型判断用户问题属于哪一类，再决定走知识库检索、走表单还是转人工。这样大部分请求的成本很低，而质量瓶颈只集中在真正困难的那部分。

前提是分层逻辑本身要可靠。分错类的代价要评估：把复杂问题误判为简单问题并直接回答，比直接用大模型更糟。

成本怎么算

按请求量乘以平均输入输出长度估算，而不是看单价。企业场景里输入通常远长于输出 —— 一次检索召回几千字的材料、输出两百字的答案 —— 所以输入侧的用量往往是成本主项，压缩召回材料的收益大于压缩回答长度。

还要把重试和失败计入。生产环境里格式解析失败、超时重试都会产生额外调用，这部分在测试阶段容易被忽略。

控制切换成本

• 把模型调用封装在一层接口后面，业务代码不直接依赖某一家的 SDK；
• 提示词与模型解耦存放，换模型时只需调整提示词而不必改业务逻辑；
• 保留一份固定的评测问题集，换模型时跑一遍对比，而不是凭感觉判断；
• 避免深度依赖某一家独有的功能，除非该功能确实带来不可替代的价值。

国内可选的平台不少，各家接口大体兼容但联网检索、函数调用等细节各有差异，封装那一层就是为了把这些差异挡在业务之外。相关做法见AI 智能体解决方案与平台与系统开发。