首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >HN 故事会:Gemini 3 Pro 最新模型解决了 OCR 中 “手写识别”和“符号推理”两个老难题?

HN 故事会:Gemini 3 Pro 最新模型解决了 OCR 中 “手写识别”和“符号推理”两个老难题?

作者头像
萝卜要努力
发布2025-11-25 09:27:01
发布2025-11-25 09:27:01
1700
举报
文章被收录于专栏:萝卜要加油萝卜要加油

HN 今天讨论的是这篇 :《Has Google quietly solved two of AI’s oldest problems?》——一位搞历史的学者在 Google AI Studio 里碰到一个“神秘模型”,声称它几乎完美地识别手写文档,还展现出类似“符号推理”的能力,被不少人猜是待发布的 Gemini 3 Pro 的内部 A/B 测试版。(36K.EU)

起因:一个历史学家和 Google 神秘模型

原文作者是加拿大历史学者 Mark Humphries,他干的不是“写小说测 AI”,而是很“苦力”的工作: 用 AI 帮忙转录 18 世纪、19 世纪的账本、信件等手写档案。

Pasted image 20251115084657
Pasted image 20251115084657

(源:https://generativehistory.substack.com/p/has-google-quietly-solved-two-of)

几个关键背景:

  • 任务难度:这些文档
    • 手写潦草、墨迹模糊
    • 拼写混乱、语法不统一
    • 充满当时的货币单位、度量衡和行话 所以不只是 OCR 问题,还需要语言、历史背景 + 逻辑推理混在一起。(36K.EU)
  • 他之前用过 GPT-4、Gemini 2.5 等,准确率已经接近专业人工,但还有明显错误。
  • 在 Google AI Studio 里,他被随机分配到一个正在做 A/B 测试 的新模型,表现“明显不一样”。
Pasted image 20251115084836
Pasted image 20251115084836

(源:https://generativehistory.substack.com/p/has-google-quietly-solved-two-of)原文给出的指标是:这个新模型在复杂历史手稿上的 **字符错误率 CER ≈ 0.56%,词错误率 WER ≈ 1.22%**,基本接近甚至超出专家级人工抄写。

在 HN 里,有人一看就坐不住了,因为自己的需求跟他几乎一模一样:

  • 顶层评论里有人说,自己在研究 16 世纪征服者(Conquistadors)的西班牙手稿,手写 + 古西班牙语 + 各种错别字,几乎是“人类折磨机”,如果 AI 真能搞定,这就是刚需。(Hacker News)
  • 另一个网友则在 AI Studio 用 Gemini 模型,把亲戚 60 天的饮食手写记录全转成表格,并跟血糖、运动记录关联,称识别质量“明显好于 ChatGPT 5.1 和 Claude Sonnet”,只剩少数他自己都看不清的字会错。(Hacker News)
Pasted image 20251115084836
Pasted image 20251115084836

(源:https://generativehistory.substack.com/p/has-google-quietly-solved-two-of)

也就是说:“历史手稿 / 生活手写记录 + AI” 这条线,在现实中已经有人跑通了,只是之前体验还停留在“能用但费心纠错”的阶段。


焦点一:那个“糖锥账本”到底说明了什么?

原文里最吸睛的例子,是一页 1758 年纽约 Albany 商人的账本:

“To 1 loaf Sugar 145 @1/4 0 19 1”

大致意思是:买了一块糖锥(sugar loaf),单价 1 先令 4 便士,总价 0 英镑 19 先令 1 便士。问题是中间那个“145”写得极其模糊,看起来既像 145,也像 14.5,甚至 1.45。

Pasted image 20251115084906
Pasted image 20251115084906

普通模型容易犯的错包括:

  • 把它当成 145 磅,算出天价
  • 或者识别字符正确,但无法对上金额,仍然是“没看懂账”。

而 Humphries 声称,这个新模型做了几件“很不像传统 OCR 的事”:(36K.EU)

  1. 它先照常转录出账目。
  2. 发现“单价 × 数量 ≠ 总价”,于是自己开始反推
  3. 把“1 先令 4 便士”换算成 16 便士,
  4. 把 0£ 19s 1d 换算成 229 便士,
  5. 算出 229 ÷ 16 ≈ 14.3125,
  6. 再把这个结果转换成 “14 磅 5 盎司”,并用 “lb / oz” 标注出来。

换句话说,它不仅看懂了字,还:

  • 理解了当时的货币体系与度量衡;
  • 意识到账目“不平衡”;
  • 通过多步计算给出一个在历史语境里合理的解释。

这就是为什么原文会把这事上升到:

Google 可能同时在一个模型里 跨过了“手写识别”和“符号推理”两个老难题。(36K.EU)

焦点二:这是“推理”,还是更高级的模式匹配?

说回 HN,大家对“Google 是否解决了符号推理”这顶高帽,非常警惕。

1)“那只是更强的模式匹配”

一派认为,这依然可以理解为:

在超大训练语料 + 强模型容量下,统计模型近似出了一种“伪推理”行为,并不需要承认它“真正理解”了什么。 典型的观点包括:

  • “预测下一个词不需要理解,只需要大规模统计。”
  • “它能算对账,很可能是从类似账本里学来的套路,而不是在脑内真的建了会计模型。”(Hacker News)

他们会强调:

  • 理解(understanding) 这个词本身没有可操作定义;
  • 讨论“模型到底懂不懂”,意义不如讨论“它能不能稳定地帮我们干活”。

2)“只说‘下一个词预测’已经解释不完了”

另一派则反驳:

  • 要在长上下文中稳定地预测下一个词,模型被迫学习世界结构,比如时间顺序、因果、物理常识等;
  • 不少人提到经典例子: “把冰块放进杯子,杯子放进盒子,再放到厨房……现在冰块在哪?”——现代 LLM 一般能答对这种世界建模题,这已远超 Markov 链级别。(Hacker News)

有人援引 Ilya Sutskever 的类比:(Hacker News)

想象一本推理小说,结尾是一句“凶手是:X”。 如果模型只是“下一词预测机”,它是怎么把前面所有线索综合起来,给出正确的名字的?

在这个视角里,“下一个词预测”只是接口(interface),里面实际发生的是:

  • 对长序列进行高维建模;
  • 在内部形成了某种 “隐式符号结构”
  • 推理能力是这种结构在规模够大时的涌现特性

但这派人也未必乐观到接受“AGI 近在眼前”,更多是说:

“用纯统计的眼镜去否认一切‘理解’迹象,已经解释不动现在的模型了。”


焦点三:模型真的变强,还是我们越来越会讲故事?

另一条支线争论的是:

我们现在感受到的“模型越来越会推理”,到底是技术进步,还是人类的叙事升级

预览版“变态强”,正式版“被阉割”?

有开发者提到:(Hacker News)

  • 之前 Google 某个 2.5 Pro 预览版 是他用过最强的版本之一;
  • 正式上线后感觉“被削弱”了,很可能是为了成本、稳定性做了优化;
  • 所以这次神秘模型会不会又是一次“超强 preview,最终 nerf 掉”的循环?

评论区有人反驳说:“你每一代都说‘上个预览更强’,听起来更像认知偏差。” 也有人回击:

“推理模型跑得贵是真事,量化 / 蒸馏 / 限速同样是合理解释,不必都归因于错觉。”(Hacker News)

Cherry-pick 还是稳定提升?

还有人吐槽原文本身:

  • 写得太长、太煽情,“真正有料的例子淹没在一大堆形容词里”;(Hacker News)
  • “看完半天都搞不清到底是系统性测试结果,还是作者选了几段最惊艳的输出来讲故事。”

这反映了 HN 一贯的敏感点: AI 故事里,案例永远比系统性评测更容易走红,但工程师需要的是后者。


焦点四:从历史学到个人生活,AI 手写识别已经能做什么?

从一线经验看,这次讨论有几类很有代表性的“金矿”式用法:

  1. 历史档案研究
    • 手写档案遍布全球,各国都有大规模数字化扫描,但很少真正做完 OCR / HTR 和结构化整理。
    • 评论中有西班牙网友问“这些 16 世纪征服者档案你是在哪看的”,对方给出了 西班牙国家档案门户 PARES,说里面有 3500 万页数字化页面,难点就是没人标、没 OCR,全靠研究者自己去翻。(Hacker News)
    • 如果 AI 手写识别真能到专家级,历史学、家谱研究、档案学会被彻底改造。
  2. 个人健康记录 / 生活笔记
    • 有人用 AI Studio 的 Gemini 模型,把亲友 60 天的手写饮食日志识别成表格,关联血糖和运动,几乎是零成本做出一份个人“数字病历”。(Hacker News)
    • 这种“给 AI 一堆潦草照片 → 直接喂进数据分析流程”的体验,是很多人真正在意的改变。
  3. 研究助理工作流
    • 先识别并粗筛,
    • 再按兴趣点总结、翻译,
    • 变成一个“半自动研究助理”。(Hacker News)
    • 有开发者用 Claude + 自己写的 CLI / TUI,对扫描报纸、旧文本做管线:

也有人给泼冷水:

  • 一位网友说,他的太太每天泡在美国小镇档案馆里看 18 世纪文书,他兴冲冲拿这篇文章给她看,对方的反应是: “为他高兴,但我绝不会用聊天机器人来转录重要的历史文献。”
  • 背后其实是学术界的一个共识:“工具可以用,但不能把史料解释权交给黑箱。”(Hacker News)

焦点五:“新模型能写 OS / 模拟器”的夸张叙事

原文顺带提到一句:“有人说这个模型可以一口气写出 Windows / macOS 克隆、3D 设计软件、任天堂模拟器、效率套件……” 这段在 HN 被集体翻白眼。

几条典型吐槽:

  • 有人去看了引用的推文,觉得更像是“做了个很像操作系统 UI 的网页”,真正的内核、驱动、进程调度完全是另一回事。(Hacker News)
  • 有人用一个很形象的比喻: “你让他做蛋糕,他把所有面粉换成小苏打,再在上面抹厚厚一层糖霜。看起来像蛋糕,但根本不能吃。”(Hacker News)

更严肃一点的看法是:

  • 开源世界有成千上万的业余 OS、模拟器和各种轮子,
  • 大模型有可能在训练数据里见过不少,
  • 于是它可以生成一个“看上去很像”的系统,甚至不排除直接“拼接 / 偷用”已有项目的架构与代码片段。

这也是为什么有人质疑:“在现有 corpora 上 interpolate 出来的东西,到底算不算‘真正的创新(novel)’?” 底下还有一整串关于“什么叫新颖”的哲学扯皮。


这场讨论给我们的几个 takeaway

1. 手写识别这条线,确实在悄悄跨代升级。 从多个用户的实测来看,不管这个神秘模型是不是 Gemini 3,Google 在 AI Studio 里的 HTR 能力已经远超一年前的主流水平——至少在“看得清的前提下,识别几乎不出错”这一点上,已经非常实用。

2. “符号推理”可能正在以一种不那么“正统”的方式被解决。 没有专门的逻辑模块,没有规则引擎,纯 Transformer 堆出来的模型,开始在真实任务中表现出:

  • 发现矛盾
  • 内部建模
  • 多步计算
  • 给出解释

这是否等同于“理解”,可以吵很多年,但从工程角度,你能越来越多地把它当作“会自己查账的助手”。

3. 但我们很容易被“好故事”带跑。 一两段惊艳示例 + “也许是里程碑突破”的标题,非常适合在 X / Substack / 媒体传播,却不等于:

  • 大样本评估、
  • 系统性对比、
  • 长期稳定可复现。

HN 的集体本能是:先假定这是 cherry-pick,除非你拿出系统实验。

4. 对普通人和研究者,态度大概应是:大胆用,小心信。

  • 手写日记、账本、课堂笔记、健康记录,这类“自己看得懂、错了也知道”的场景,完全可以当生产力工具用起来;
  • 重要史料、关键数据,则要把它当“超强 OCR + 初稿助手”,但最后那道“理解与裁决”的关,仍然需要人类来守

如果 Humphries 看到的东西真的是 Gemini 3 的一角,那也许这篇 Substack 真不是在夸张:

我们可能见到的是 —— 机器从能“看懂人写的字”,走向开始“替人算账、查错、提解释”的那个转折点。

离“通用智能”还有多远没人知道,但至少有一个方向明确了: 只靠“这是下一个词预测机”这句口头禅,已经不够解释今天的模型了。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-11-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 萝卜要加油 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 起因:一个历史学家和 Google 神秘模型
  • 焦点一:那个“糖锥账本”到底说明了什么?
  • 焦点二:这是“推理”,还是更高级的模式匹配?
    • 1)“那只是更强的模式匹配”
    • 2)“只说‘下一个词预测’已经解释不完了”
  • 焦点三:模型真的变强,还是我们越来越会讲故事?
    • 预览版“变态强”,正式版“被阉割”?
    • Cherry-pick 还是稳定提升?
  • 焦点四:从历史学到个人生活,AI 手写识别已经能做什么?
  • 焦点五:“新模型能写 OS / 模拟器”的夸张叙事
  • 这场讨论给我们的几个 takeaway
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档