Files

94 lines
4.1 KiB
Markdown
Raw Permalink Normal View History

# ADR-009 决策故事:当 AI 识别不完美时,产品怎么设计
## 背景
ErrLens 的核心功能是:学生拍一张错题照片 → AI 识别题目内容 → 自动归类 → 分析错误原因 → 推荐同类练习。
这个流程看起来很美好,但它建立在一个脆弱的假设上:**AI 能准确识别每一张照片。**
现实是:中小学生的手写体,潦草起来连老师都看不懂。打印体 OCR 准确率可以到 95%+,但手写体的天花板大概在 70-80%。而且不只是 OCR——学科分类、知识点标注、错误类型诊断,每一步都可能出错。
第一个版本的 PRD 里,我完全没考虑这个问题。数据流画得很漂亮:「拍照 → AI 识别 → 入库 → 分析 → 推荐」,仿佛 AI 不会出错。
直到有人问我:「万一 AI 识别错了呢?」
---
## 问题:错误数据会污染整个系统
如果 AI 把「二次函数顶点坐标」错标成「一次函数斜率」,会发生什么?
1. 错题归到错误的知识点
2. 薄弱点分析显示「一次函数薄弱」,实际是二次函数有问题
3. 推荐系统给了 10 道一次函数的练习——和学生的真实弱项毫无关系
4. 学生发现推荐不准确 → 不信任产品 → 弃用
**一条错误数据进入分析管道,污染的是整个推荐飞轮。**
传统方案的思路是「提高 AI 准确率」——换更好的模型、加训练数据、调 prompt。但这条路的天花板很明显:手写体 OCR 准确率从 70% 提升到 85% 已经很难了,90% 在可见的将来都不现实。
而且,即使到了 90%,每 10 道错题就有 1 道是错的。100 道里有 10 道。对学生来说,10 次错误的推荐 = 再也不用了。
---
## 灵感:AI 做不好的事,让人来做
问题的本质是:**AI 做识别很强但不够完美,人做识别很准但太慢。**
那能不能结合起来?
我当时想到一个关键洞察:**学生本来就要看自己拍了什么。** 拍照录入的过程不是「拍完就完了」,用户本来就会确认「这张照片拍清楚了吗」「题目对吗」。这个「确认」动作,天然就是数据校验的机会。
于是设计了这样一个流程:
```
AI 识别结果不是「答案」,是「草稿」
每个字段带置信度(这条我有多确定)
高置信(>90%):绿色标记,用户看一眼就行
中置信(70%-90%):黄色提示,建议检查
低置信(<70%):红色高亮,请手动修正
用户确认/修正后 → 入库 → 进入分析管道
未经确认的数据 → 仅自己可见,不参与分析和推荐
```
核心设计原则:**AI 是草稿,用户是编辑。分析管道只吃「干净数据」。**
---
## 隐藏收益:每一次修正都是免费的标注数据
做到这一步后,我发现还有一个更大的收益。
用户修正时,系统记录两个值:
- `ai_value`:AI 的原始识别结果(比如标注为「二次函数顶点坐标」)
- `user_value`:用户修正后的值(实际是「二次函数图像性质」)
- `ai_confidence`:AI 当时对这个判断的置信度(0.72)
这条修正记录(CorrectionLog)就是一条**完美的标注数据**:
- 有原始模型输出(ai_value
- 有人工标注结果(user_value
- 有模型当时的置信度(可用于误差分析)
传统 AI 训练需要花钱请人标注数据。ErrLens 的标注员是用户——而且他们免费标注,甚至感谢你给了他们一个「修正」的功能。
P02 阶段(自研模型),这些 CorrectionLog 就是核心训练数据。产品用得越多,修正记录越多,模型越强——这是真正的数据飞轮。
---
## 结果
- error_items 表新增 `verification_status`raw→reviewed→corrected→stale)和 `ai_confidence`JSONB
- 新增 `correction_logs` 表,记录每一条人机修正
- 分析/推荐查询强制加 `WHERE verification_status != 'raw'`
- 前端 UI 设计绿/黄/红三级置信度指示
---
## 一句话总结
**AI 的弱点不一定是产品的弱点——如果你能设计一个把「AI 错误」变成「用户价值」的闭环。**