一、项目启动会上最容易被跳过的一页

私有化大模型的试点，通常以"先做个小范围验证"开场。这句话在合同里很好写，在验收时很难用。多数项目在启动会上会把硬件清单、交付周期、培训场次逐条对齐，唯独跳过一个字段：什么结果算通过。

这个字段缺失的代价，会在三个月后集中出现。业务方给出的是主观印象，交付方给出的是技术指标，两套语言之间没有换算关系，讨论无法收敛。

二、演示与试点不是同一种交付

• 演示：由供给方选取问题集，问题经过筛选，路径经过调优，目标是证明能力上限。
• 试点：由业务方提供真实问题流，包含歧义、错别字、跨文档指代与历史遗留表述，目标是暴露能力边界。

两者在预算表上的科目名称往往完全一致，在结论的可信度上完全不同。把演示结果直接当作试点结论，是后续扩容阶段返工的主要来源之一。

三、场景收敛：从全域问答退到单一场景

试点阶段建议只保留一个场景。筛选可从三个维度判断：

1. 频次：该问题在业务中一周出现数次以上，低频场景无法在试点周期内积累足够样本。
2. 可判定性：业务方能对单条回答给出对/错判断，而非满意度评分。
3. 错误代价：答错后的处置成本可控，可重问、可人工接管，不直接触达外部。

反例是把"企业全域知识问答"作为试点场景。场景过宽导致单条回答无法判定对错，验收方式会被动退回到满意度打分，而满意度评分在样本量有限时区分度极低。

四、样本分层：三档结构

试点题库建议按三档构造，比例可按业务实际情况调整：

• 常见问题档：覆盖日常高频问法，用于观察基本可用性。
• 边缘问题档：包含跨文档、多跳推理、表述歧义等问题，用于观察稳定性。
• 无答案档：问题在语料中确实不存在对应内容，用于观察模型是否会产生听起来合理、却没有依据的回答。

第三档在实践中经常缺失，它同时是权限设计与内容风控的输入。缺少这一档，上线后暴露的问题往往比试点期间更严重。

五、四条判定标准

这四条需要在系统开机前形成书面约定：

六、交付物与隐性成本

试点结束时建议交付三份材料：含未通过项的问题清单、按四条标准逐项打分的评估表、下一阶段建议（是否扩容、优先扩容哪个场景、尚缺哪些条件）。只提交一份定性结论的汇报材料，无法支撑后续决策。

另有两项成本需在试点期内确认：

• 模型可迁移性：提示词体系与评测题库是否与特定模型绑定，切换模型的返工范围有多大。
• 运维归属：告警响应责任方、响应时限、是否写入合同条款。

七、结论的表述边界

试点样本量有限，结论应表述为条件性判断：在何种数据规模、并发量、权限结构下成立，而非直接给出可推广结论。并发上升后检索质量与权限边界的表现，通常与试点期存在差异，需要在扩容前单独设计验证环节。

把这些写进启动会纪要，比写进结项报告更有用。