AI 原理学习笔记（二十六）：行业场景、POC 与方案交付

返回系列导读 · 先修：应用评估、综合案例

1. 先把业务语言翻译成任务

“我们想做一个智能系统”不是足够具体的需求。至少问清：

谁使用？在什么流程里？输入来自哪里？现在怎样做？输出交给谁？什么错误最贵？哪些步骤需要人工？什么结果算成功？

例如“合同审核”可能包含识别扫描文字、抽取字段、对照条款、标注风险、生成意见与法务复核。不同子任务适用不同方法，不能用一个聊天框替代全部责任。

2. 行业会改变数据与验收

这是任务拆解示例，不是对行业效果的承诺。实际要求要由具体业务与相关责任人员确定。

3. 怎样判断大模型是否合适

输入是否主要是非结构化语言或媒体？输出是否存在表达弹性？是否能提供可验证证据？允许的错误率和人工复核成本是什么？

如果问题是“按固定公式计算税额”或“精确查询库存”，规则程序与数据库可能更直接；模型可以帮助理解用户问题，但确定计算和事实查询应交给适合的工具。

如果没有合适数据、没有办法评价正确性，也没有容纳错误的流程，贸然自动化很难交付。

4. Demo 与 POC 的区别

Demo 展示某条预先准备好的路径。POC，Proof of Concept，概念验证，要回答关键技术假设在真实约束下能否成立。

例如要验证“带权限过滤的 RAG 能回答公司制度问题”，就应使用代表性数据、冻结题集、定义评分规则，并记录失败，而不只展示三道提前调好的题。

POC 不一定证明未来大规模运行的全部指标。样本量、并发、数据范围与环境差异要写进结论。

5. 一份 POC 计划应该包含什么

题集有开发集与保留测试集。可以用开发集调方案，但不能反复拿保留集改到满意后仍称其独立。

6. 怎样写可验收的需求

“系统要智能、稳定、准确”太抽象，可以改写为：

在约定文档快照和题集上，按确认的评分规则记录正确性、证据支持与拒答；在约定输入输出长度与并发下测量端到端延迟，并检查无权限题不泄漏数据。

具体阈值由双方按业务和风险确定。重点是测量条件、分母和失败处理有共同定义。

对于性能，写清是平均、P95、TTFT 还是总完成时间；对于成功率，写清是否包含工具故障与人工补救。

7. 方案文档的主线

从问题到交付可以这样组织：

1. 当前流程与痛点。
2. 目标、范围和不在本期的需求。
3. 数据与权限边界。
4. 任务流程与技术架构。
5. 模型、检索、工具的选择依据。
6. 评估与验收方法。
7. 容量、成本与运维计划。
8. 风险、依赖、里程碑与责任。

架构图里的每条箭头都应该能解释传什么、谁有权传、失败怎么办。堆满产品 Logo 的图不等于架构已经设计清楚。

8. 招投标与交付中的证据

如果需要响应技术要求，建立“要求 → 实现方式 → 证明材料 → 验收方法”的对应关系。没有实际验证的能力应说明验证计划和限制，不能把未来设想写成已完成能力。

交付包括配置、部署、数据更新、权限管理、培训、监控、回滚、维护职责与文档，不只是交一个模型文件。

承诺效果时区分教学算例、实验数据与真实项目记录，避免把未经验证的收益写成已实现事实。

9. 反例：POC 看起来成功却不能上线

只用管理员账号测试，忽略权限；只用短文件，真实数据多是扫描长表格；只测一人，真实需要高并发；只测现行数据，没测撤销与冲突；只看成功回答，没记录工具失败。

这些并不是模型层一个更高分数能自动解决的。POC 要覆盖决定交付成败的关键约束。

复习卡片与自测

• 行业名称不是技术方案，具体任务才是。
• Demo 展示路径，POC 验证假设。
• 验收写条件、口径、分母与失败处理。
• 交付包含数据、权限、运维与责任。

1. 三道演示题全部答对，能否推断整体准确率？

2. 为什么要保留基线？

3. 行业相同就能直接复制方案吗？

原文定位

依据：原资料 第十五、十六篇、10.13、19.3—19.4。