惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
博客园 - Franky
T
Tailwind CSS Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
月光博客
月光博客
人人都是产品经理
人人都是产品经理
雷峰网
雷峰网
Hugging Face - Blog
Hugging Face - Blog
有赞技术团队
有赞技术团队
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
阮一峰的网络日志
阮一峰的网络日志
C
Check Point Blog
爱范儿
爱范儿
T
The Blog of Author Tim Ferriss
aimingoo的专栏
aimingoo的专栏
Stack Overflow Blog
Stack Overflow Blog
博客园 - 聂微东
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
L
LangChain Blog
云风的 BLOG
云风的 BLOG
MyScale Blog
MyScale Blog
Microsoft Security Blog
Microsoft Security Blog
The Cloudflare Blog
博客园 - 三生石上(FineUI控件)

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
当模型开始“看图回答”:多模态理解里,人到底在判断什么?
青蓝色的海 · 2025-12-27 · via 人人都是产品经理

多模态项目的关键拐点并非技术突破,而是认知校准的精细工程。当模型获得视觉理解能力后,真正的挑战在于如何定义‘正确’的标准——那些看似合理的答案背后,可能隐藏着致命的认知偏差。本文将深入拆解多模态理解阶段的人机协作本质,揭示从‘语法正确’到‘现实对齐’的认知鸿沟跨越之道。

在前面几篇里,我们已经走完了多模态项目的前半段:

  • 模型不再只看文字
  • 数据被严格筛选
  • 感觉被拆成标签和结构化描述

到这里,模型终于具备了一件看起来很厉害的能力:它可以“看图、看视频,然后回答问题”。

很多人会以为,这一步之后,人的工作就轻松了。但现实恰恰相反——这是多模态项目里最容易被低估、也最容易翻车的阶段。

多模态理解,不是“看懂了”,而是“回答对了”

在多模态理解任务中,最常见的一种数据形式是:

图片 / 视频 + 问题 + 模型回答

表面上看,这很像传统的问答任务。

但真正难的地方在于:判断模型“是否正确”,远比判断文本对错复杂得多。

因为这里的“对”,不只是语言层面的,而是对现实的理解是否成立

为什么多模态理解的判断,比你想象得难?

举个很常见的例子。

模型看了一张图片,回答了一个看起来“语法正确、语义通顺”的答案,但问题在于——它描述的内容,和画面并不完全一致。

可能是:

  • 忽略了画面中的关键人物
  • 把背景当成了主体
  • 推断了画面里根本不存在的信息
  • 情绪判断过度或不足

这些问题,在文本任务中往往很容易被发现;但在多模态场景中,“像对但不完全对”反而是最危险的状态

因为它会给模型一个错误信号:

这种理解方式,是可以被接受的。

在多模态理解里,人并不是在“挑错”,而是在“定边界”

很多新人在做多模态理解评估时,会不自觉地陷入一种心态:只要大概说对了,就算过。

但成熟的项目往往会非常克制,因为这里真正要做的,不是“宽容”,而是立边界

这条边界在问的是:

  • 模型是否基于画面本身回答
  • 是否引入了多余的臆测
  • 是否遗漏了问题真正关心的信息

换句话说,人在这一阶段做的,不是润色语言,而是判断:

这种理解方式,能不能被当成“正确范式”留下来训练模型。

为什么“改到正确即可”,反而是最难把握的尺度?

在多模态理解项目中,有一句看起来很简单,但极其重要的原则:修改到正确且相对完善即可。

这句话背后,其实隐含了三个克制:

第一,不追求文学表达。第二,不补模型没被要求的信息。第三,不替模型做“过度聪明”的推理。

很多人第一次做改写,会忍不住把答案写得“更完整、更高级、更像人”。但问题是——模型并不需要一个“更聪明的答案”,它需要的是一个“更对的答案”。

多模态理解的改写,本质上是在“矫正认知路径”

如果你从训练的角度去看这一阶段,会发现一个很关键的事实:

改写,并不是在纠错结果,而是在纠错模型的理解路径。

当模型把注意力放错地方,人通过改写,等于是在告诉它:“你应该看的是这里,而不是那里。”

当模型忽略了关键视觉信息,人通过补充描述,等于是在强化:“这个信息,在回答中是重要的。”

这也是为什么,多模态理解阶段的人类参与,具有极强的不可替代性

为什么说这是“人最接近模型思维”的地方?

在这一阶段,你会非常频繁地做一件事:站在模型视角,反推它为什么会这么答。

你不再只是看答案对不对,而是在思考:

  • 模型是看错了?
  • 看漏了?
  • 还是被问题引导歪了?

这种反向思考,会让你逐渐理解模型的“感知盲区”和“偏好路径”。

而一旦你能稳定判断这些问题,你在多模态项目中的角色,就已经不再是执行者,而是理解模型的人

多模态理解阶段,决定了模型“敢不敢被用在真实场景”

从产品角度看,这一阶段其实非常关键。

因为真实用户,并不会给模型打分,而是直接相信或放弃它。

如果模型在看图、看视频、听语音时:

  • 经常答非所问
  • 偶尔自信地胡说
  • 情绪判断不稳定

那产品层面,几乎不可能承受这种不确定性。

而多模态理解阶段的改写与判断,本质上是在提前替用户筛选风险

写在最后:这一阶段不是“修答案”,而是在“教理解”

如果说前面的工作是在教模型“看”和“听”,那么多模态理解阶段,就是在教它:什么时候,你真的懂了。

你给它通过什么答案,它就会认为这种理解方式是对的。你放过什么偏差,它就会反复复制这种偏差。

这也是为什么,这一阶段的人,承担的并不是“标注工作”,而是认知裁判的角色。

共勉!棒棒,你最棒!

本文由 @青蓝色的海 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自unsplash,基于CC0协议