一个落地项目实际长什么样

一个知识问答项目做到演示时，十个精心准备的问题都答得很好；上线后员工问的是简称、旧制度和跨部门例外，答案立刻混乱。团队开始轮流怪模型、怪文档、怪提问者，直到验收日才发现：从来没人约定哪些问题必须答、引用错了怎么算、资料由谁更新。落地项目真正费力的部分，是把模糊业务整理成稳定输入、明确流程和可以共同签字的测试结果。

先给答案

一个可交付的 AI 项目应依次完成：定义任务与基线、整理并授权数据、做小样本原型、冻结测试集、盲测验收、灰度上线。验收必须同时看质量、效率、严重错误和人工接管，不能只看回答是否“像人”。

第一段：先定边界，再整理数据

启动会上先写一页任务说明：谁使用、处理哪类输入、系统输出什么、不处理什么、谁对最终结果负责。例如“根据现行售后制度为内部坐席生成回复草稿；不自动发送，不处理赔偿裁决和法律争议”。同时抽取一批代表性任务测人工基线：每笔耗时、一次通过率、返工次数和现有错误率。若暂无历史数据，可从 30 笔开始探索，再按任务差异与风险扩大；没有基线，就无法证明新系统是否改善。

数据整理通常会占掉大量时间，因为“文件存在”不等于“可用于回答”。先建立资料清单，逐份记录所有者、版本、生效日、适用范围、保密等级和更新人。删除重复与失效版本，把扫描件转成可检索文字，统一产品名和部门简称。OCR 抽查比例要按扫描质量、版式复杂度和错误后果确定；低风险探索可以先抽查每 100 页中的 10 页，再根据发现的错误扩大，而不能把 10% 当成通用标准。

若项目使用检索增强生成，要分别验“找得对”和“写得对”。也就是说，先检查系统是否检索到正确制度原文，再检查模型是否依据原文回答。两步混在一起，只看到最终答错，无法判断该修资料切分、搜索规则还是回答要求。

第二段：小样本原型要暴露失败，不是证明成功

原型应使用真实且脱敏的问题，至少包含五类：常见问题、表达含糊、跨文档、资料缺失、明确不应回答。缺少历史数据时，可以先用 20 至 50 个样本暴露明显失败，但这个数量只是探索起点，不足以证明上线质量；每类数量应按真实业务比例与风险分层确定。项目组要主动收集引用与结论不一致、把旧制度当现行制度、资料没有仍然编答，以及该转人工时继续回答等失败模式。

每发现一种失败，先规定系统行为，再决定技术修改。资料缺失时应回答“现有资料无法确认”并给转人工入口；涉及赔偿裁决时直接停止；多个版本冲突时展示版本和日期。不要只靠不断加长提示词，因为权限、版本过滤、输出字段和转人工规则更适合由程序强制。

原型阶段还要做运行记录：每次使用的模型版本、资料版本、检索片段、回答、耗时、费用和评审结果。模型或资料一更新，就用同一测试集回归。否则一次升级修好引用，却悄悄降低拒答率，团队无法追查。

第三段：把验收写成可重复的评分表

验收前冻结一批未参与调试的测试集，并按真实业务比例和高风险边界分层。100 条可以作为低风险场景的示例起点，不是通用最低值；样本量应根据类别数量、允许误差、严重事件稀有程度和决策后果校准。评审人不知道答案来自人工流程还是 AI 流程。每条按四项打分：

事实与引用，0 至 2 分： 0 分为关键事实错或无依据；1 分为基本正确但引用不完整；2 分为事实正确且引用可定位。
任务完成，0 至 2 分： 0 分为未解决或答非所问；1 分为需较多补改；2 分为可直接使用或只需轻微修改。
边界处理，0 至 2 分： 0 分为不该回答却编答；1 分为提示风险但未正确转交；2 分为正确拒答、澄清或转人工。
表达，0 至 2 分： 0 分为难以理解；1 分为可读但冗长；2 分为清楚并符合规定格式。

每条满分 8 分，但平均分不能掩盖严重错误。下面只是一组可校准写法：“测试集平均至少 7 分；事实与引用项 2 分率至少 95%；测试集中观察到的错误付款、敏感信息泄露、错误对外承诺为 0；中位处理时间比人工基线下降 25%；至少 90% 的低分结果能按规则转人工。”这些数字不是行业标准；项目必须记录各阈值对应的历史基线、业务后果、样本覆盖和批准人，高风险场景还要扩大边界样本并采用更严门槛。测试中未观察到严重错误，也不能证明真实运行永远为零。

上线应先做小范围灰度，保留原流程和一键反馈，每周复查随机样本与全部严重投诉。10% 用户、连续两周可以作为起始示例，实际比例和观察期要按流量、风险与事件频率校准；一旦触发预先定义的严重错误条件，立即切回人工并保留日志。资料负责人按生效日更新，项目负责人按固定测试集回归，这两项都应写进长期职责。

自己试一下

拿一段包含一个日期和三条规则的公开说明，先写五个问题：两道原文可直接回答，一道要合并两处信息，一道原文没有答案，一道超出适用范围。让聊天模型逐题回答、引用原句，并在证据不足时拒答。按上面的四项各打 0 至 2 分，再请另一位同事独立评分；若同一项相差 2 分，就把评分规则补得更具体。

本实验于 2026-08-27 用 deepseek-v4-flash 生成回答，再由同一模型在两个独立上下文中评分。两次逐项评分都为 40/40，但其中一次把总分误写成 10/10。它说明分项总分应由程序重算；同一模型的两次评分也不能替代独立人工评审。你试的时候结果可能不同，重点是观察评分能否复现，以及失败能否归到明确类型。

常见误解

“模型选好了，项目就完成一半。” 模型只是一个环节。资料权属、版本治理、测试样本、系统集成、人员培训和上线监测，往往决定最终能否使用。

“平均准确率 90% 就能上线。” 如果剩下 10% 包含泄露信息或错误付款，一次也不可接受。验收必须把严重错误单列为硬门槛，并验证系统会正确转人工。

三句话总结

落地先定义任务和人工基线，数据要有版本、权限、适用范围与维护人。
原型的目标是覆盖失败模式，并把检索、生成、拒答和转人工分别验证。
验收要用冻结测试集、盲评、分项评分和严重错误硬门槛，上线后继续抽查回归。

如果你要做决定

签项目合同前，把测试集构成、评分表、严重错误定义、通过阈值、人工基线、灰度比例、回退条件和资料维护责任写入验收附件。凡是只承诺“准确率”却不给样本、口径和失败处理的方法，都不能作为可执行的验收标准。