PoC与运营：让AI导入成功的推进方法

PoC验证的不只是技术能否运行

PoC是导入前的实证工程，用于确认构想在实际条件下是否成立。对于AI而言，即便演示中出现了自然流畅的回答，也不能保证能够应对日常业务文档、实际用户数量和例外情况。在开始之前，需确定验证什么内容、达到什么结果才能推进下一步。

NIST的AI风险管理框架也涵盖了不仅限于AI设计和开发，还包括使用和评估在内的风险管理。不是导入时的一次性判定，而是在使用过程中持续审视的视角值得参考。

企业PoC中，需将目标具体化为"缩短这项业务中这个确认步骤的时间"。事先测量当前所需时间和修改量，就能以相同基准评估AI导入后的变化。目的是创造判断是否继续的素材，而不仅仅是确认预期。

从六个维度预先确定合格条件

本构想从机密信息漏检、处理目标分配、响应性能、接近实际的负荷、审计等业务效果，以及运营和安全六个方面进行确认。这是为了避免仅凭GPU利用率判断成功的整理框架。

机密漏检不仅要看"正确拦截了多少件"，还要评估误发到外部时的影响。过度拦截正常信息会阻碍工作推进，因此误报及其确认负担也需一并记录。准备已知正确答案的评估数据，按机密类型分别确认结果，可以发现具体问题。

响应性能除平均值外，还需确认慢速响应的发生频率。p95是指测量值中95%低于该值的参考指标。需明确是仅判定时间还是包含检索和生成的时间，避免将不同测量内容合并为单一数值进行比较。

不只测试正常请求，还要测试困难场景

验证内容应包括简短问题、长文档、附件、图片、多轮对话和用户无权查阅的资料。仅用少量熟悉的问题测试，会遗漏正式运营中遇到的困难条件。准备与开发时使用的示例不同的评估数据也很重要。

故障测试也是必要的。确认在外部API无响应、判定功能停止、无法连接检索目标、用户权限变更等情况下，信息处理和界面显示如何变化。即便因安全原因停止，也需确定现场应采取的替代措施。

测试结果不仅记录成功和失败件数，还要保留条件和设置版本。当模型或检索对象更新时，如果能重新运行相同测试，就能确认是否比之前更差。PoC记录也将成为正式运营的验证流程。

从同一张表查看从购买到运营的全部费用

仅凭设备价格无法判断导入费用的全貌。需分别确认以下各项：设备、初期构建、数据整理、与认证和业务系统的集成、运营维护、外部API、电力和冷却，以及硬件维护。费用因配置和条件而异，请个别咨询。

将云端和本地AI结合使用时，也不能简单得出哪个更便宜的结论，需对齐使用量、高峰、处理长度和运营人员负担进行比较。仅将总额除以员工数，难以看清实际利用率和管理工作量。

签约时，需确认哪些属于初期对应范围、哪些会产生追加费用，以及故障时联系谁。将模型更新、资料追加、权限变更和评估重新实施等导入后反复进行的工作纳入估算范围，可以减少运营开始后的认知偏差。

明确责任分工，在各阶段设置判断节点

AI基础设施涉及业务判断者、软件负责人、认证和网络管理员，以及设备和设施维护人员。不事先确定最终审批人，出现问题时应对就会停滞。

即便在涉及WOODMAN的构想中，也需分别整理计算/液浸设备、AI应用程序和业务评估的角色。具体提供范围和责任需按项目确认，不能将构想中的角色图直接视为已确定的合同。

推进方式分为三个阶段：小范围目标的PoC、限定用户的试行，以及扩展到正式运营范围。每个阶段设置推进条件和审视条件。不是因为预定日期到了就扩展，而是在确认评估结果和应对体制齐备后再做判断。

将未通过的项目连接到下一个判断

PoC结果可能未达预期。此时，与其将整体构想评判为成功或失败，不如分别梳理在哪些条件下遇到了什么困难。原因是文档更新、检索质量、模型回答质量还是用户操作，决定了下一步所需的工作内容。

涉及机密信息处理的重大问题，需在扩大范围前确认应对措施。响应较慢时，在追加设备之前，先审视输入量、检索范围、并发处理和队列管理。改善措施的效果需通过对齐条件的重新测试来验证。

合格条件不仅包括数值，还包括能否运营。联系方式是否已确定？负责人能否执行流程？维护停机时能否通知现场？让日常管理负责人参与试行，可以发现设计阶段未能预见的负担。

如果费用和效果不匹配，缩小目标业务范围、更换配置或决定不导入都是合理选择。不要将实施PoC与必须购买挂钩，而应将其定位为收集判断所需素材的工程。

报告书应涵盖目标业务、使用数据、配置、评估结果、遗留问题和下一位负责人。将技术说明与业务影响一并记录，导入后也能传承判断依据。

正式运营后，保持可审视的状态

参考1 NIST AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework