AI项目怎么做？从问题定义、数据评测到上线监控

一句话答案：构建 AI 项目，不应从“选哪个模型”开始，而应从用户任务、失败成本和不用 AI 的基线开始。先写清输入、输出、禁止事项与责任人，再冻结一批能代表真实业务的评测样本；选择规则、检索、现成 API、RAG、微调或自训练中最简单且能达标的路线；离线评测通过后依次做影子运行、人工确认和小流量发布，最后用质量、业务、成本与风险四组指标决定扩量、回滚或停止。

先判断：这个问题是否真的需要 AI

AI 适合处理规则难以穷举、输入存在变化、可以从样本或上下文中提取模式、且错误能够检测和处置的任务。若答案可以由确定规则、数据库查询或全文检索稳定得到，先做非 AI 方案通常更快、更便宜，也更容易解释。NIST AI RMF Playbook 的 Manage 1.1 明确要求判断 AI 系统是否实现预期目的，以及开发或部署是否应继续；“能调用模型”不是继续项目的充分理由。

为同一个任务保留一个最简单基线。例如客服问答可用“关键词搜索 + 人工回复”，文档分类可用规则或轻量模型，摘要任务可用人工模板。以后任何 AI 版本都必须在相同样本、相同时间窗口和相同护栏下与基线比较，而不是只与“什么都不做”比较。

基线还负责保留退出路线：当模型供应商故障、成本越线、数据不再适用或严重错误触发停止条件时，团队能够切回一个已知、可运行且责任明确的流程。没有可用基线的项目，通常也没有可信的回滚方案。

第一步：写一页 AI 项目契约

项目契约不是立项口号，而是开发、评测和停止的共同输入。目标应写成“谁在什么场景下完成什么任务”，而不是“接入大模型”“准确率达到 95%”或“提高效率”。NIST AI RMF 将 Govern、Map、Measure、Manage 作为贯穿生命周期的函数，其中 Map 首先要求理解预期用途、用户、场景、正负影响和假设边界。

对付款、医疗、法律、人事、未成年人、账号权限或公开发布等高影响场景，应把人工批准、申诉和回滚写入契约，而不是上线前补一句免责声明。可结合站内的 AI 智能体权限与自动化治理指南定义副作用动作边界。

第二步：选择最简单能达标的技术路线

“大模型、RAG、微调、自训练”不是成熟度阶梯，也不是越靠后越先进。路线由事实来源、数据量、更新速度、延迟、隐私、解释需求和错误成本共同决定。Google 的《Rules of Machine Learning》建议先保证端到端管道稳定并使用合理目标，复杂度会增加未来发布和维护成本。

生成式项目尤其要区分“知识问题”和“行为问题”：需要引用最新政策时优先改善文档与检索；需要稳定输出字段、语气或分类边界时，模板、结构化输出或微调才可能有价值。关于模型输出无法由证据支持的情况，可先阅读 AI 幻觉核验指南。

第三步：建立数据契约，而不是只下载一个数据集

数据量大不等于适用。每个数据源都应记录来源、许可、采集目的、时间范围、字段定义、缺失方式、代表人群、敏感性、保存期限和负责人。训练数据、检索文档、测试样本和线上日志的使用边界不同，不能因为“系统里已有”就默认可以用于训练。

训练集、验证集和测试集怎样切分

随机切分只适用于样本近似独立且分布稳定的情况。用户、设备、同一文档片段或同一事件跨集合出现，会制造数据泄漏。预测未来时应采用时间切分；评估新用户时应按用户或实体分组；RAG 应避免把同一原文的相邻切片同时放入开发集和测试集。测试集一旦频繁用于调提示或选模型，就已经变成开发集，需要另建真正未见集。

第四步：先设计评测，再开发原型

评测集应覆盖常见任务、重要边界、无答案、输入冲突、格式错误、恶意输入和高影响失败。每个样本记录输入、期望、可接受变体、证据、严重级别和人工裁决规则。单一平均分会掩盖少数但严重的错误，因此要同时报告总体结果、困难切片和最坏群体。

分类准确率、F1 或生成式评审分数不能自动代表业务价值。高召回可能增加误报成本，短回答可能降低延迟却遗漏限制条件，模型评审器也会误判。先用人工校准样本验证自动评审器，再把自动评审用于扩展，而不是反过来。多模态项目还要分别检查文字、图像、音频及其相互一致性，参见 多模态证据链设计。

第五步：构建可复现原型，而不是一次性 Notebook

原型至少要固定代码、依赖、模型或 API 版本、提示模板、检索索引、数据快照、参数、随机种子（适用时）和评测结果。把提示词、规则和工具定义放进版本库；不要只保留聊天记录或截图。Google 的生产 ML 指南强调训练与服务管道应尽量复用处理逻辑，以减少训练—服务偏差。

工具选择要从任务与约束倒推，不能因为教程多就默认采用某个框架。可用 AI 工具选型方法比较锁定成本、可观测性、数据驻留、模型替换、速率限制与退出路线。

第六步：生成式 AI 项目要额外控制检索、提示和工具

LLM 应用并不只是模型调用。真实链路还包括系统提示、用户输入、检索文档、上下文拼接、结构化输出、工具调用、权限和后处理。任意一层都可能引入错误。OWASP 在 2026 年发布的 LLMSVS v2.0 提供了可用于架构、开发、测试和采购的 LLM 安全验证要求，覆盖配置维护、模型生命周期、检索、工具与连接器等环节；它是社区维护的开放验证标准，不是法律法规，也不能代替行业合规和针对具体系统的威胁建模。

任何发送、付款、退款、删除、权限修改和对外发布，都应具备明确参数、预览、批准、限额、幂等键和撤销方式。复杂工作流可进一步参考 AI 工作流编排与治理。

第七步：用五阶段发布替代“一次上线”

1. 离线原型：只处理脱敏或批准样本，不接生产写权限。
2. 影子运行：读取真实输入并生成候选，但不影响用户；与现有流程比较。
3. 人工确认：每个结果由责任人批准，记录修改和拒绝原因。
4. 小流量灰度：限定用户、场景和时间，保留快速停用与旧流程。
5. 分阶段扩量：只有质量、业务、成本和风险护栏同时通过才增加范围。

Microsoft HAX Guidelines 将人机交互分为初次交互、正常使用、系统出错和长期使用等阶段。产品必须告诉用户系统能做什么、当前为何给出结果、错了怎样修正，以及用户反馈如何影响未来体验；不能只设计“成功演示”。

第八步：上线后监控系统，而不只是监控服务器

生产 AI 会因输入分布、知识库、供应商模型、提示、工具、政策和用户行为变化而退化。Google 的 ML pipelines 指南强调，生产目标是持续的数据、训练、验证、部署和服务管道，而不是部署一个永远不变的模型文件。对于调用外部基础模型的系统，即使不自行训练，也应保存供应商版本、提示、评测和回归记录。

怎样定义回滚和退役

回滚应明确谁有权触发、切换到哪个稳定版本、怎样处理进行中任务、怎样通知用户、日志保留多久以及修复后如何重新评测。若项目长期达不到基线、无法获得合法数据、人工审核成本超过收益、供应商变化导致关键能力不可用，或风险无法降低到可接受范围，应缩小用途或退役，而不是继续增加提示词和模型。

把供应商、开源组件和外部模型纳入同一条责任链

使用第三方 API、开源模型、向量数据库或托管平台，并不会把责任整体转移给供应商。项目需要记录组件名称、版本、许可证、数据流向、服务地区、保留策略、子处理者、可用性依赖、替换方案和退出成本。NIST AI RMF Core 的 Manage 3 要求持续管理第三方资源的风险与收益，并把预训练模型纳入日常监控维护。CISA 与英国 NCSC 发布的安全 AI 系统开发指南也强调从设计、开发、部署到运行全周期落实 Secure by Design，而不是把安全留给上线后的补丁。

对开源组件至少保留来源仓库、提交或版本、许可证、依赖清单和构建方法；对外部模型保留当日文档、评测指纹与已知限制。不要把“开源”理解为自动安全，也不要把“企业版”理解为自动符合自己的数据制度。

隐私控制要从数据流开始，而不是只做脱敏

先画清数据从用户、前端、日志、检索、模型、工具到第三方服务的流向，再决定每一处是否真的需要该字段。数据最小化不仅是删除姓名：自由文本、定位、设备标识、对话上下文和模型推断出的属性也可能指向个人。NIST 对 AI 风险特征的说明指出，AI 还可能通过属性推断、数据重建、提示注入或成员推断带来新的隐私风险；因此“输入前去掉手机号”不能覆盖完整风险。

若无法说明一个字段为何被收集、由谁使用、保存多久和如何删除，就不应让它进入通用提示、检索索引或训练集。不同地区和行业的法律要求不同，项目应由真实的数据负责人和适用的专业意见确认，而不是把模型生成的合规清单当成批准。

预先写好事故卡：出现错误时先做什么

事故响应不能在事故发生后临时讨论。NIST AI RMF 的 Manage Playbook建议建立持续监控、负面影响反馈、停用、备份流程、根因分析、证据保全和退役标准。每个项目至少为严重错答、隐私泄露、越权动作、供应商故障、成本失控和数据漂移准备一张事故卡。

停用能力必须真实演练：确认旧流程仍可用、队列中的任务不会重复执行、回滚不会丢失审计记录。一次事故修复还应转化为新的回归样本和监控规则，否则团队只修了当次表现，没有提高系统的长期可靠性。

AI 项目成本怎样算

不要只计算 token、GPU 或订阅费。总成本包括数据获取与清洗、标注、检索、存储、网络、评测、人工审核、集成、监控、值班、事故、失败重试和退出迁移。分母应是“通过质量门槛的有效任务数”，不是总调用次数。若便宜模型产生更多返工和投诉，它可能拥有更高的实际单次成本。

若项目接近交易、客服、内容发布等业务流程，可参考 电商 AI 六层落地方法中的事实源、权限和试点指标；方法同样适用于非电商场景。

可复制的最小项目清单

常见问题

初学者必须先训练自己的模型吗？

不必。先用规则、检索、现成 API 或基础模型验证任务和评测方法。只有基线无法满足、训练数据与长期维护能力充分时，才考虑微调或自训练。

准确率达到多少才能上线？

没有通用数字。阈值取决于失败类型、人工接管、群体差异和业务后果。应分别定义普通错误和严重错误；某些高影响错误可能要求零容忍并强制人工批准。

做一个演示版通常需要多久？

无法脱离任务、数据、集成和风险给出固定周期。更可靠的估算方式是分别计算项目契约、数据许可、评测集、基线、原型、集成、安全与上线验证，不把“模型能回答”当成完成。

RAG 与微调应该怎样选？

需要最新或私有事实及引用时，先做 RAG；需要稳定行为、格式或领域表达且有高质量样本时，微调可能有用。两者可以组合，但必须分别评测检索和生成，不能用最终流畅度掩盖检索失败。

开源模型一定比 API 更保护隐私吗？

不一定。隐私取决于部署位置、日志、访问控制、数据保留、运维人员和供应链。自托管减少某些外部传输，也增加补丁、监控、密钥和基础设施责任；应根据完整数据流而不是“开源/闭源”标签判断。

来源、适用范围与纠错记录

本文依据 NIST AI RMF Core、NIST AI RMF Playbook、Google 的 Rules of Machine Learning、ML pipelines 与 Productionization、Microsoft HAX Guidelines、OWASP MLSVS 与 LLMSVS v2.0、CISA/NCSC 安全 AI 系统开发指南整理，资料复核日期为 2026 年 7 月 18 日。NIST AI RMF 1.0 正在更新；MLSVS 与 LLMSVS 属于开放社区验证标准，不是法律法规或自动认证，正式项目仍须遵守所在行业、地区和组织制度。