合规雷达 / 2-13
一个团队要给客服、知识检索和文档写作上大模型。产品同事先问「哪个模型最强」，采购同事接着问「哪个更便宜」，技术同事又问「能不能私有化」。三个问题都合理，却没有一个能单独决定答案。
模型选型不是从排行榜里挑一个名字，而是把业务目标、数据条件、部署方式、评价证据和风险处置连成一条路。 GB/Z 201—2026《人工智能 大模型选型和应用指南》正是为这条路提供了通用框架。
它是国家标准化指导性技术文件，不是强制性准入清单。它的价值不在于替企业指定某一款模型，而在于提醒团队，别把一次采购演示当成一次完整选型。
先回答一个问题，究竟要它完成什么工作
如果需求只是「上一个大模型」，后面的比较很容易失焦。更好的起点，是把真实工作说清：客服需要从哪些资料里回答，答案错了会带来什么后果，是否需要调用内部系统，峰值并发多少，哪些内容绝不能离开组织环境。
标准从策略规划、组织与人员保障、现状评估、初步模型选择开始，而不是直接进入模型参数。先把任务边界画出来，模型能力才有可以比较的坐标。
从业务目标到准备、数据、选型优化、部署应用、评价和风险的六步路线。
一个可操作的开场，是先留下一页「任务说明」：目标用户是谁，输入是什么，输出怎样才算正确，什么情况必须拒答或转人工，允许调用哪些系统，谁承担最终业务责任。这不是文书负担，它会决定后面测试题怎么设计、数据能不能用、部署放在哪里。
不要把参数量，当成唯一的判断
模型能力当然重要，但能力要落在同一道题上比较。让候选模型都处理同一批真实任务，并分别观察事实准确、领域理解、格式遵循、多轮稳定性、工具调用和异常处理。仅比较通用榜单，常常得不到业务答案。
标准把模型选择、训练和调优作为连续环节，也把数据准备单列出来。一个模型在公开测评上表现很好，不表示它能直接理解组织内部的术语、知识库和流程；相反，数据质量、检索设计、提示模板和人工复核，有时比更大的参数带来更明显的改进。
同一个任务要比较能力、数据、部署、成本与运维四组证据，不能只看参数。
可以把候选模型放到同一张核对表里：
· 能力证据：同一任务集的结果、失败样例、稳定性和人工复核结论。
· 数据证据：训练、微调或检索所需的数据范围、来源、质量和使用限制。
· 部署证据：云端、专有环境或本地部署的边界，接口、集成、访问控制和日志能力。
· 成本与运维证据：调用量、响应时延、算力、升级方式、供应保障和故障处理。
这里最容易漏掉的，是组织自己的准备程度。没有明确的数据责任人、没有可复现的测试任务、没有业务方参与验收，再强的模型也可能只是在演示里好看。
应用落地，选型之后才真正开始
第一个版本跑通，不等于可以不再管理。标准把部署模式、部署、集成、安全运维、模型评价、效益评价和风险管理放在应用阶段之后，形成闭环。
部署时要明确模型、数据、应用与调用方之间的边界。模型接入知识库、工单系统或代码仓库后，风险也从「回答错一句话」变成「可能读取、生成或触发一项动作」。这时需要把权限、日志、版本和人工介入点一起放进设计。
测试集、部署配置、运行记录、评估、风险处置组成持续回路，选中模型只是开始。
评价至少要分成两层。 一层看模型与系统能否完成任务，另一层看应用是否真的带来预期效益。前者可能关注准确、相关、鲁棒和安全边界，后者才是效率、体验、成本或业务指标。两层混在一起，团队很容易用「用户喜欢」掩盖错误，或用「准确率高」回避没有被采用的问题。
风险管理也不该留到事故以后。标准把组织能力、风险目标、风险识别与评价、风险应对作为独立部分。项目应提前约定哪些失败可接受，哪些必须停止服务或转人工；上线后新数据、新场景、模型版本变化，也要回到任务集重新评价。
一份可带进会议室的选型清单
在采购、立项或方案评审前，可以先逐项问：
· 任务、用户、允许和禁止的动作有没有写清？
· 是否用真实或等价任务，让候选模型接受同题测试？
· 数据、知识库和工具接口的使用边界有没有证据？
· 部署位置、权限、日志、版本更新和故障响应由谁负责？
· 上线后用什么指标验证能力与业务效果，多久复查一次？
这些问题不保证自动选出「最好的」模型，却能避免团队在错误的问题上做出精致的比较。
选模型，最后不是选一个分数最高的名字，而是选一条组织能够长期承担的应用路径。
GB/Z 201—2026给出的正是这条从准备到持续评价的路径。它的局限也要看清：它不是某一行业的性能基准，也不会替项目给出统一的阈值。医疗、金融、政务或涉及个人信息的场景，仍要叠加适用的专门规则和安全要求。
