问题一：是否需要理解语言
如果任务可以用字段与规则表达，用模型属于过度设计；如果输入是自由文本、格式多变、需要归纳，模型的价值才明显。判断标准是输入的自由度，而不是行业的先进程度。
问题二：准确率与容错
关键字段要求近乎无误时，需要模型加规则加人工抽检三层；允许草稿级输出的场景可以放宽。把两类场景混在一起评估，结论一定失真，也无法设定统一验收线。
问题三：数据能否使用
训练与检索都需要数据授权。涉及个人信息、客户资料与商业秘密时，要先确定处理位置与脱敏方式，否则方案在技术上行得通，在合规上却走不通。
问题四：有无运维能力
模型服务需要监控、额度管理、版本更新与故障处理。缺少运维能力时，宁可选择托管服务，也不要在内网自建高可用推理集群，否则故障无人接、恢复靠运气。
问题五：能否长期评测
评测不是一次性工作。业务变化会让旧评测集失效，需要有节奏地补充样本。没有评测机制，投入很难持续产生价值，也无法回答现在比半年前好在哪里。
适用与不适用
适合谁
- 正在评估自建还是采购的企业
- 需要在多个技术路线间取舍的架构师
- 准备向决策层提交方案的技术负责人
不适合谁
- 任务完全可用规则表达的场景
- 没有数据授权路径且无法脱敏的项目
典型场景
某集团评估是否自建推理服务。核对五个问题后发现：任务可用通用模型、数据敏感需本地处理、运维团队只有两人。最终选择小规模私有化部署加托管备份，而不是全量自建。
可执行步骤
- 判断任务是否需要语言理解能力
- 按字段重要性区分容错等级
- 确认数据授权与处理位置
- 评估现有运维人力与工具
- 制定评测补充节奏后再决策
常见坑
- 为技术先进性自建集群，算力闲置且无人维护。
- 把关键字段与一般字段混在一起评估，验收标准无法统一。
- 低估数据授权流程，项目在法务环节停滞数月。
- 上线后不再更新评测集，业务变化后指标失去意义。
自检与验收清单
- 任务是否确实需要语言理解
- 关键字段是否有三层校验设计
- 数据授权与脱敏是否落实
- 运维人力是否匹配部署形态
- 评测更新是否有节奏
常见问题
自建还是用接口？
看数据与规模。数据不能出内网或长期高频使用时自建更合适；否则接口调用上线快、维护轻，适合多数试点。
准确率多少才算够？
取决于业务。建议按字段设定不同门槛，并配套抽检比例，而不是追求一个统一的总体数字。
预算有限先做什么？
先做检索与评测，再考虑模型升级。多数效果问题来自知识缺失与评测缺失，而不是模型能力不足。
评估结论该由谁签字？
由业务负责人签字，技术负责人附证据。业务方对错误后果与容错线负责，技术方提供评测数据与部署方案，财务或管理层确认资源投入。只有技术团队单方结论，后续出现争议时无人对业务影响负责，项目也容易停在试点。