WEBVTT
Kind: captions
Language: zh

00:00:00.166 --> 00:00:02.266
Deepseek把V4家族的视觉

00:00:02.266 --> 00:00:04.066
实验模型开放出来了

00:00:04.133 --> 00:00:05.400
它开始把图片里的

00:00:05.400 --> 00:00:07.100
信息带进任务处理

00:00:07.166 --> 00:00:09.466
在官方公布的部分测试中

00:00:09.500 --> 00:00:11.266
超过OPPO4.8

00:00:11.300 --> 00:00:13.266
也有项目明显落后

00:00:13.300 --> 00:00:15.500
这次发布最值得追问的

00:00:15.866 --> 00:00:17.333
是开放的视觉能力

00:00:17.333 --> 00:00:19.500
能不能真正进入工作流程

00:00:19.933 --> 00:00:22.133
让更多人不必只靠少数

00:00:22.133 --> 00:00:24.000
平台来处理自己的资料

00:00:24.300 --> 00:00:25.733
模型的完整名字叫

00:00:25.733 --> 00:00:28.700
Deepseek V4 Flash vision EXP

00:00:28.966 --> 00:00:29.800
名字很长

00:00:29.800 --> 00:00:32.200
但最后那个EXP尤其重要

00:00:32.266 --> 00:00:33.600
它代表实验性质

00:00:34.000 --> 00:00:35.966
截至2026年9月1日

00:00:36.133 --> 00:00:38.766
官方hugging face仓库已经公开

00:00:38.933 --> 00:00:40.366
模型说明之外

00:00:40.466 --> 00:00:42.733
还提供了权重相关文件

00:00:42.866 --> 00:00:45.000
配置和参考推理代码

00:00:45.300 --> 00:00:46.866
发布本身有据可查

00:00:47.000 --> 00:00:49.666
实际表现仍要按测试条件判断

00:00:49.800 --> 00:00:52.400
官方把它称为Deepseek v四

00:00:52.400 --> 00:00:54.966
家族首个实验性多模态模型

00:00:55.066 --> 00:00:57.600
这里的首个限定在V4家族

00:00:57.966 --> 00:00:59.666
不能扩写成Deepseek

00:00:59.966 --> 00:01:01.866
此前完全没有视觉研究

00:01:02.200 --> 00:01:03.800
早在Janus系列中

00:01:03.866 --> 00:01:06.966
Deepseek就探索过多模态理解与生成

00:01:07.333 --> 00:01:10.066
这次值得注意的进展是视觉模块

00:01:10.066 --> 00:01:12.900
进入了v四flash这一条模型路线

00:01:13.066 --> 00:01:14.566
按照模型卡的介绍

00:01:14.733 --> 00:01:17.300
它建立在V4Flash架构之上

00:01:17.300 --> 00:01:19.766
加入视觉模块并继续训练

00:01:20.100 --> 00:01:21.933
以获得视觉理解能力

00:01:22.066 --> 00:01:23.933
图片与文字一起输入

00:01:23.933 --> 00:01:26.500
再围绕内容回答或处理任务

00:01:26.533 --> 00:01:29.100
是目前资料支持的核心方向

00:01:29.200 --> 00:01:31.066
不能因为名字里出现vision

00:01:31.666 --> 00:01:34.500
就把实时视频语音对话和

00:01:34.500 --> 00:01:37.333
图片生成全都自动算进来

00:01:37.333 --> 00:01:39.100
这项变化为什么重要

00:01:39.266 --> 00:01:41.966
因为现实工作里有大量信息

00:01:41.966 --> 00:01:43.966
并不是一段整理好的文字

00:01:43.966 --> 00:01:45.200
一份报告的关键

00:01:45.200 --> 00:01:47.100
限制可能放在图注里

00:01:47.566 --> 00:01:49.666
错误提示可能只有截图

00:01:50.366 --> 00:01:51.766
页面布局决定哪个

00:01:51.766 --> 00:01:53.366
数字对应哪个项目

00:01:53.566 --> 00:01:55.766
模型如果只能接收文字

00:01:55.933 --> 00:01:58.933
就需要有人先把这些内容解释一遍

00:01:59.066 --> 00:02:00.200
人在做的

00:02:00.200 --> 00:02:03.066
常常正是机器难以看清的那一段

00:02:03.133 --> 00:02:05.000
以一张经营图表为例

00:02:05.166 --> 00:02:07.733
只把上面的数字抄出来还不够

00:02:08.500 --> 00:02:10.000
纵轴使用什么单位

00:02:10.266 --> 00:02:12.133
两条线代表哪些对象

00:02:12.300 --> 00:02:13.733
哪一段是预测值

00:02:13.733 --> 00:02:15.066
都会影响结论

00:02:15.333 --> 00:02:17.933
文字识别可以提供字和数字

00:02:18.400 --> 00:02:20.900
视觉理解还得处理位置与关系

00:02:21.100 --> 00:02:22.466
省掉这层判断

00:02:22.900 --> 00:02:25.100
很容易得到一份文字流畅

00:02:25.566 --> 00:02:27.800
却把事实关系讲反的分析

00:02:28.000 --> 00:02:29.733
视觉模型提供了一条

00:02:29.733 --> 00:02:32.166
减少这种信息损失的路线

00:02:32.400 --> 00:02:34.566
不过看得见也有不同层次

00:02:34.766 --> 00:02:36.466
识别一张图里有表格

00:02:36.666 --> 00:02:38.133
读出其中几个值

00:02:38.500 --> 00:02:40.866
判断这些值为什么发生变化

00:02:40.933 --> 00:02:42.966
是逐步增加难度的任务

00:02:43.300 --> 00:02:46.400
Deepseek这次发布能否改变实际使用

00:02:46.400 --> 00:02:48.266
必须落到这些具体能力

00:02:48.333 --> 00:02:51.066
不能靠会看图三个字一次带过

00:02:51.166 --> 00:02:53.933
官方测试表给出了值得关注的信号

00:02:54.800 --> 00:02:57.066
apexbench的pass AT1成绩

00:02:57.333 --> 00:03:03.133
视觉实验版是36.5V4Flash0731是26.2

00:03:03.266 --> 00:03:06.766
作为对照的Opus4.8是39.4

00:03:06.866 --> 00:03:10.000
新版本比旧版本高10.3个百分点

00:03:10.200 --> 00:03:12.900
但这组比较有一个不能略过的脚注

00:03:13.400 --> 00:03:15.466
否则很容易把进步解释错

00:03:15.600 --> 00:03:16.666
脚注写明

00:03:16.766 --> 00:03:21.066
0731在apexbench和agents last exam两项测试

00:03:21.066 --> 00:03:23.566
中忽略了输入里的多模态元素

00:03:24.200 --> 00:03:25.166
也就是说

00:03:25.400 --> 00:03:26.966
旧模型没有按同样

00:03:26.966 --> 00:03:28.766
方式利用图像信息

00:03:28.900 --> 00:03:31.566
新增视觉后成绩改善确实

00:03:31.566 --> 00:03:33.866
说明开放这类输入有意义

00:03:34.400 --> 00:03:36.700
但不能把全部差距解释成

00:03:36.700 --> 00:03:39.166
在完全相同的信息条件下

00:03:39.366 --> 00:03:41.366
纯推理能力提高了多少

00:03:41.766 --> 00:03:43.566
这就像处理同一份材料

00:03:43.700 --> 00:03:45.466
一个系统拿到了图文

00:03:45.533 --> 00:03:47.500
另一个只处理其中的文字

00:03:47.766 --> 00:03:48.933
结果可以比较

00:03:48.933 --> 00:03:51.000
但比较回答的问题变了

00:03:51.066 --> 00:03:53.100
它更接近完整系统获得

00:03:53.100 --> 00:03:55.100
新输入后的表现变化

00:03:55.266 --> 00:03:57.000
若要单独证明视觉

00:03:57.000 --> 00:03:59.100
推理本身比某个模型强

00:03:59.533 --> 00:04:01.133
还需要让参照对象

00:04:01.133 --> 00:04:02.800
都能拿到相同资料

00:04:02.800 --> 00:04:04.766
并控制其他测试条件

00:04:04.933 --> 00:04:07.466
另一项agents last exam中

00:04:07.600 --> 00:04:12.000
视觉实验版是27.30731 是25.2

00:04:12.333 --> 00:04:14.900
Opus4.8是25.7

00:04:14.900 --> 00:04:16.600
这里新模型在公布的

00:04:16.600 --> 00:04:18.866
表格里领先了对照模型

00:04:19.066 --> 00:04:21.866
但幅度不能被包装成压倒性胜利

00:04:22.100 --> 00:04:24.966
模型卡提供的是这些条件下的成绩

00:04:25.066 --> 00:04:27.200
不是每一家公司的所有任务

00:04:27.566 --> 00:04:29.866
也不是未来应用的收益保证

00:04:29.966 --> 00:04:32.600
更接近专业工作的一项是Chartography

00:04:33.300 --> 00:04:36.066
Deepseek公布的成绩为64.3

00:04:36.100 --> 00:04:39.100
对照的Opus4.8是65.0

00:04:39.366 --> 00:04:40.566
两者很接近

00:04:40.733 --> 00:04:43.600
这个基准关注专业图表理解

00:04:44.200 --> 00:04:46.100
研究者强调不同领域的

00:04:46.100 --> 00:04:48.200
图表有各自的表达习惯

00:04:48.466 --> 00:04:50.566
读错一个少标注的坐标

00:04:50.600 --> 00:04:52.333
或误解几何关系

00:04:52.466 --> 00:04:53.800
就可能让后面的

00:04:53.800 --> 00:04:55.966
推理从起点发生偏差

00:04:56.100 --> 00:04:58.200
这种测试比让模型给

00:04:58.200 --> 00:05:00.300
一张日常图片起标题

00:05:00.300 --> 00:05:02.200
更能触及业务难点

00:05:02.500 --> 00:05:05.066
专业用户需要从图里做出判断

00:05:05.166 --> 00:05:07.500
光认出颜色和形状没有用

00:05:07.600 --> 00:05:11.066
但专业图表基准的成绩也不能直接

00:05:11.066 --> 00:05:13.766
当做某个行业的自动审批通过率

00:05:13.900 --> 00:05:15.166
任务分布不同

00:05:15.466 --> 00:05:16.900
允许的错误不同

00:05:17.500 --> 00:05:19.466
实际系统还可能涉及额外

00:05:19.466 --> 00:05:21.466
的数据处理和验证步骤

00:05:21.933 --> 00:05:23.966
0bench又提出另一层限制

00:05:24.200 --> 00:05:26.966
官方模型卡列的是RDNA5

00:05:27.500 --> 00:05:29.466
视觉实验版35.0

00:05:29.666 --> 00:05:31.566
对照模型34.0

00:05:31.600 --> 00:05:33.566
这种指标考察多次尝试

00:05:33.566 --> 00:05:35.566
中至少成功一次的情况

00:05:35.733 --> 00:05:37.200
和一次作答的pass

00:05:37.766 --> 00:05:39.333
艾特一不能混读

00:05:39.366 --> 00:05:41.866
5次里能找到一次正确结果

00:05:42.066 --> 00:05:44.000
并不代表部署时系统会

00:05:44.000 --> 00:05:46.300
自动知道哪次才是正确的

00:05:46.366 --> 00:05:48.300
实际用户付钱买结果

00:05:48.333 --> 00:05:50.200
通常不希望收到5份相互

00:05:50.200 --> 00:05:51.900
矛盾的答案再自行选

00:05:51.933 --> 00:05:54.533
如果重试能够由验证程序筛选

00:05:54.566 --> 00:05:56.100
就可能有实际价值

00:05:56.533 --> 00:05:59.066
要靠专家重新检查每份答案

00:05:59.166 --> 00:06:01.000
成本就会转移到人工

00:06:01.133 --> 00:06:03.600
看榜单时忽略尝试次数

00:06:03.900 --> 00:06:06.133
最容易把一个有研究意义的

00:06:06.133 --> 00:06:09.500
进步误读成现成可靠的生产力

00:06:09.600 --> 00:06:11.166
视觉能力加进去后

00:06:11.166 --> 00:06:12.400
文字任务有没有受

00:06:12.400 --> 00:06:14.266
影响也必须一起看

00:06:14.700 --> 00:06:16.066
在Deepseek上

00:06:16.066 --> 00:06:19.700
新模型是59.30731

00:06:19.700 --> 00:06:23.666
是54.4 OPPO4.8是58.0

00:06:23.666 --> 00:06:25.100
这项公布结果支持

00:06:25.100 --> 00:06:26.966
一个有限但积极的判断

00:06:27.466 --> 00:06:28.666
新增视觉后

00:06:28.733 --> 00:06:30.400
它在这组任务上没有因为

00:06:30.400 --> 00:06:32.766
功能扩展而牺牲原有表现

00:06:33.000 --> 00:06:34.900
反而高于两个对照分数

00:06:34.900 --> 00:06:37.733
但cybergame的结果没有延续这个方向

00:06:38.000 --> 00:06:42.700
视觉实验版75.30731为76.7

00:06:42.900 --> 00:06:45.200
OPPO 4.8为78.3

00:06:45.300 --> 00:06:47.000
新模型低于旧版

00:06:47.066 --> 00:06:48.133
也低于对照

00:06:48.266 --> 00:06:49.900
这里不需要编造原因

00:06:50.266 --> 00:06:51.666
现有材料并没有证明

00:06:51.666 --> 00:06:53.700
是视觉模块造成下降

00:06:53.766 --> 00:06:55.000
他提醒的是

00:06:55.166 --> 00:06:57.200
能力变化存在不同方向

00:06:57.466 --> 00:07:00.700
不能选完上涨项目就宣布全面升级

00:07:00.900 --> 00:07:03.566
NL to Repo的差距更值得保留

00:07:04.133 --> 00:07:06.400
视觉实验版是57.7

00:07:06.600 --> 00:07:09.066
OPPO4.8是69.7

00:07:09.133 --> 00:07:10.933
相差12个百分点

00:07:11.200 --> 00:07:12.600
只要这一行还在

00:07:12.600 --> 00:07:14.533
就很难把整张表讲成

00:07:14.533 --> 00:07:16.500
闭源模型已经失去优势

00:07:16.766 --> 00:07:19.400
采购模型的人真正关心的是

00:07:19.400 --> 00:07:21.666
自己的主要任务落在哪一类

00:07:21.933 --> 00:07:24.166
如果恰好是差距明显的那类

00:07:24.300 --> 00:07:27.500
其他项目领先并不能补偿交付损失

00:07:27.766 --> 00:07:29.900
官方还披露文字代理测试

00:07:29.900 --> 00:07:32.400
使用Deepseek Harness的minimal模式

00:07:32.566 --> 00:07:35.466
并为Deepseek设置最高档推理强度

00:07:35.666 --> 00:07:37.200
采样温度为1.0

00:07:37.300 --> 00:07:38.966
top p为0.95

00:07:39.166 --> 00:07:41.766
这些条件提醒使用者成绩

00:07:41.766 --> 00:07:44.400
来自模型与运行框架的组合

00:07:44.566 --> 00:07:46.066
换成不同工具配置

00:07:46.066 --> 00:07:47.666
或更短的思考预算

00:07:47.700 --> 00:07:50.266
不能直接假定还能拿到同样分数

00:07:50.866 --> 00:07:52.533
所以这张表更适合

00:07:52.533 --> 00:07:54.333
用来建立候选名单

00:07:54.466 --> 00:07:55.766
而不是直接发出

00:07:55.766 --> 00:07:57.733
全面替换的采购命令

00:07:57.900 --> 00:07:59.966
它表明视觉实验版已经

00:07:59.966 --> 00:08:02.066
有值得认真验证的能力

00:08:02.066 --> 00:08:03.766
也明确留下了差距

00:08:03.966 --> 00:08:06.500
下一步应当拿真实工作去复核

00:08:06.866 --> 00:08:08.100
把进步说清楚

00:08:08.133 --> 00:08:10.000
再把适用范围划清楚

00:08:10.300 --> 00:08:11.900
远比把一个模型捧成

00:08:11.900 --> 00:08:13.700
万能答案更有判断力

00:08:13.800 --> 00:08:14.766
除了分数

00:08:15.100 --> 00:08:17.133
发布内容本身也有分量

00:08:17.300 --> 00:08:19.766
官方仓库使用MIT许可证

00:08:19.966 --> 00:08:22.966
并公开了提示编码和最小推理实现

00:08:23.166 --> 00:08:26.000
开发者获得的是检查和改造的基础

00:08:26.400 --> 00:08:28.000
不只是一扇只能提交

00:08:28.000 --> 00:08:30.066
问题等待结果的接口

00:08:30.200 --> 00:08:31.900
模型如何接收图像

00:08:32.300 --> 00:08:33.766
输入怎样编码

00:08:33.966 --> 00:08:36.366
可以沿着公开文件继续研究

00:08:36.500 --> 00:08:39.200
但这里的开放范围需要准确描述

00:08:39.600 --> 00:08:41.733
仓库有权重和相关代码

00:08:41.800 --> 00:08:44.200
不等于训练使用的全部数据

00:08:44.600 --> 00:08:46.200
清洗过程和每一次

00:08:46.200 --> 00:08:48.000
实验都已完整公开

00:08:48.166 --> 00:08:50.933
模型可下载与训练全过程可

00:08:50.933 --> 00:08:53.133
复现不是同一级别的承诺

00:08:53.333 --> 00:08:54.900
商业应用还要处理

00:08:54.900 --> 00:08:57.000
自身数据的授权与隐私

00:08:57.166 --> 00:08:59.566
不能把模型许可证当成所有

00:08:59.566 --> 00:09:01.866
素材都能任意使用的通行证

00:09:02.300 --> 00:09:04.366
MIT许可证提供了使用和

00:09:04.366 --> 00:09:06.133
修改等方面的许可

00:09:06.566 --> 00:09:08.800
同时保留相应通知要求

00:09:08.800 --> 00:09:10.666
并按现状提供软件

00:09:10.666 --> 00:09:12.100
不做质量担保

00:09:12.200 --> 00:09:14.266
开源用户得到更多主动权

00:09:14.266 --> 00:09:15.866
也要承担验证责任

00:09:16.600 --> 00:09:19.333
模型能进入自家系统是一个开始

00:09:19.900 --> 00:09:21.600
出了错误由谁处理

00:09:21.666 --> 00:09:22.800
服务怎么维护

00:09:22.800 --> 00:09:25.700
并不会在下载完成那一刻自动解决

00:09:25.966 --> 00:09:26.933
从结构上看

00:09:26.933 --> 00:09:28.700
这次公开的实现包含

00:09:28.700 --> 00:09:31.000
视觉编码器与对齐模块

00:09:31.266 --> 00:09:33.066
前者处理图像信息

00:09:33.166 --> 00:09:35.400
后者参与把视觉表示接到

00:09:35.400 --> 00:09:37.800
语言模型所能利用的形式里

00:09:37.933 --> 00:09:40.566
普通用户不需要记住每个技术名字

00:09:40.766 --> 00:09:43.333
但这个结构说明会看图

00:09:43.333 --> 00:09:45.133
依赖具体的处理链路

00:09:45.600 --> 00:09:47.100
不是给文字模型换

00:09:47.100 --> 00:09:49.066
一个产品标签就能完成

00:09:49.133 --> 00:09:52.066
这条链路的前端尤其容易被低估

00:09:52.566 --> 00:09:54.133
图片进入模型之前

00:09:54.133 --> 00:09:56.733
通常要经过尺寸和像素处理

00:09:56.900 --> 00:09:58.400
假如一张密集报表被

00:09:58.400 --> 00:10:00.200
处理的细节难以辨认

00:10:00.333 --> 00:10:02.166
后面再强的推理也不能

00:10:02.166 --> 00:10:05.133
保证恢复原来那几个小字所以

00:10:05.366 --> 00:10:08.500
评估视觉模型要把输入处理算进去

00:10:08.600 --> 00:10:11.400
不能只检查生成回答的最后一段

00:10:11.800 --> 00:10:12.866
官方单独公开了

00:10:12.866 --> 00:10:14.700
图文提示的编码参考

00:10:14.966 --> 00:10:17.366
支持图像与文字交错出现

00:10:17.466 --> 00:10:19.400
文档还用两种输入写法

00:10:19.400 --> 00:10:21.266
表达同一个双图问题

00:10:21.400 --> 00:10:23.000
并检查它们得到相同

00:10:23.000 --> 00:10:24.800
的提示与输入序列

00:10:25.000 --> 00:10:27.066
这个设计看起来很工程化

00:10:27.100 --> 00:10:29.266
却触及一个常见错误来源

00:10:29.666 --> 00:10:31.066
第一张图和第二张图

00:10:31.066 --> 00:10:32.600
如果在传递中对调

00:10:32.933 --> 00:10:34.566
模型可能答得很流畅

00:10:34.733 --> 00:10:36.466
却始终在弹错对象

00:10:36.500 --> 00:10:39.366
比如需要比较修改前后的两份界面

00:10:39.533 --> 00:10:41.533
问题是哪个按钮消失了

00:10:41.900 --> 00:10:43.866
顺序就决定变化方向

00:10:44.166 --> 00:10:45.933
编码阶段保持图像

00:10:45.933 --> 00:10:47.666
与文字的对应关系

00:10:47.800 --> 00:10:49.400
才有资格继续讨论

00:10:49.400 --> 00:10:51.266
模型理解的是否正确

00:10:51.366 --> 00:10:53.700
这种基础设施做对之后

00:10:53.766 --> 00:10:55.666
开发者才不至于把输入

00:10:55.666 --> 00:10:58.000
错误误诊成模型智力不足

00:10:58.100 --> 00:11:00.700
或者不断改提示词却没有效果

00:11:01.133 --> 00:11:03.866
配置文件还保留了混合专家结构

00:11:04.100 --> 00:11:06.700
它列出256个路由专家

00:11:06.733 --> 00:11:08.500
每个词元选择6个

00:11:08.500 --> 00:11:10.066
并有共享专家

00:11:10.166 --> 00:11:12.333
这个结构试图让每次计算

00:11:12.333 --> 00:11:14.800
只动用模型的一部分能力

00:11:15.300 --> 00:11:17.200
但不能把它理解为只需要

00:11:17.200 --> 00:11:19.533
存储那几个被选中的专家

00:11:19.666 --> 00:11:21.200
实际部署仍要处理

00:11:21.200 --> 00:11:23.500
模型权重及运行时资源

00:11:23.866 --> 00:11:26.266
存得下和算得快是不同约束

00:11:26.400 --> 00:11:28.566
这也是为什么Flash三个字不能

00:11:28.566 --> 00:11:31.466
自动翻译成普通电脑轻松运行

00:11:32.366 --> 00:11:34.000
名字表达产品路线

00:11:34.000 --> 00:11:35.566
不是硬件配置单

00:11:35.700 --> 00:11:37.100
速度会受到硬件

00:11:37.100 --> 00:11:39.066
带宽和推理实现影响

00:11:39.200 --> 00:11:42.466
并发增加后还会出现新的资源压力

00:11:42.600 --> 00:11:44.900
缺少针对具体机器的测量

00:11:45.300 --> 00:11:48.066
就不应该承诺每秒生成多少字

00:11:48.366 --> 00:11:50.933
更不能仅凭名称推算成本

00:11:51.566 --> 00:11:54.100
配置中还能看到低精度相关设置

00:11:54.400 --> 00:11:56.466
包括专家权重的FP4

00:11:56.466 --> 00:11:58.600
设置和FP8量化信息

00:11:58.800 --> 00:12:00.766
低精度的目标之一是

00:12:00.766 --> 00:12:03.133
降低存储或计算负担

00:12:03.200 --> 00:12:06.166
但收益取决于实现与硬件支持

00:12:06.600 --> 00:12:08.400
精度变化也需要验证

00:12:08.500 --> 00:12:09.766
它是优化工具

00:12:09.766 --> 00:12:11.700
不是一个只赚不亏的按钮

00:12:11.900 --> 00:12:14.000
不同组件的精度还可能不同

00:12:14.366 --> 00:12:15.566
不能把整套模型

00:12:15.566 --> 00:12:17.366
简单描述成统一四维

00:12:17.566 --> 00:12:20.100
上下文上限也同样需要谨慎

00:12:20.500 --> 00:12:24.400
配置文件的最大位置数是1048576

00:12:24.466 --> 00:12:26.666
属于约百万词元的量级

00:12:27.000 --> 00:12:28.800
这是容量相关的设置

00:12:28.866 --> 00:12:30.600
不能直接读成百万字

00:12:30.966 --> 00:12:32.566
更不能保证塞进去的

00:12:32.566 --> 00:12:34.866
每一个细节都会被准确利用

00:12:35.066 --> 00:12:36.566
窗口能容纳多少

00:12:36.866 --> 00:12:39.466
与长材料中能找到多少有效证据

00:12:39.600 --> 00:12:41.000
需要分别测量

00:12:41.166 --> 00:12:44.366
图文场景会让长上下文问题更实际

00:12:44.600 --> 00:12:47.366
一份长报告可能包含多页图表

00:12:47.600 --> 00:12:50.333
同一指标在不同页面又有不同口径

00:12:50.700 --> 00:12:52.500
模型要找到正确位置

00:12:52.566 --> 00:12:55.300
还得保持单位与时间范围的一致

00:12:55.466 --> 00:12:57.500
多放一些内容进去

00:12:57.500 --> 00:12:59.133
只是给了更多材料

00:12:59.500 --> 00:13:02.000
如果材料之间的关系没有处理好

00:13:02.200 --> 00:13:04.866
更大的窗口也可能存在更多混淆

00:13:05.133 --> 00:13:06.366
参考推理文档对

00:13:06.366 --> 00:13:07.966
自身定位说的很清楚

00:13:08.300 --> 00:13:10.666
它是一份便于阅读的参考实现

00:13:10.733 --> 00:13:12.400
并非生产服务引擎

00:13:12.766 --> 00:13:15.333
代码包含Genspark相关前向路径

00:13:15.466 --> 00:13:17.066
但生成循环仍然是

00:13:17.066 --> 00:13:18.600
直接的自回归采样

00:13:18.700 --> 00:13:20.333
这意味着能在代码里

00:13:20.333 --> 00:13:22.566
找到某种能力的组成部分

00:13:23.100 --> 00:13:25.466
不等于配套服务已经把吞吐

00:13:25.466 --> 00:13:27.900
和调度都优化到成熟状态

00:13:28.000 --> 00:13:30.333
把参考实现接成长期服务

00:13:30.400 --> 00:13:31.966
还要处理请求排队

00:13:32.333 --> 00:13:34.000
资源分配和失败恢复

00:13:34.133 --> 00:13:36.333
单次测试跑通只能证明

00:13:36.333 --> 00:13:38.000
这一次流程可以执行

00:13:38.166 --> 00:13:39.900
客户同时上传资料

00:13:39.966 --> 00:13:41.400
某个请求过长

00:13:41.600 --> 00:13:43.466
机器资源暂时不足

00:13:43.566 --> 00:13:45.600
这些情况都会影响交付

00:13:46.000 --> 00:13:47.933
实验模型最容易被夸大的

00:13:47.933 --> 00:13:50.600
地方就是把能够运行写成

00:13:50.600 --> 00:13:52.866
已经适合任何生产环境

00:13:53.066 --> 00:13:54.533
文档里的并行示例也

00:13:54.533 --> 00:13:56.666
不能当成最低硬件要求

00:13:57.400 --> 00:13:59.600
示例展示了如何组织执行

00:13:59.600 --> 00:14:00.933
不等于已经测出

00:14:00.933 --> 00:14:02.666
所有部署组合的下限

00:14:02.900 --> 00:14:04.333
官方目前这些文件

00:14:04.333 --> 00:14:06.066
并没有给出足够依据

00:14:06.266 --> 00:14:08.533
让外界承诺某种消费级

00:14:08.533 --> 00:14:10.866
设备一定可以获得理想体验

00:14:11.133 --> 00:14:13.066
后续优化可能改变门槛

00:14:13.133 --> 00:14:14.566
但未验证的结果

00:14:14.566 --> 00:14:16.466
应当留在未来时态里

00:14:16.533 --> 00:14:17.700
经过这些限制

00:14:17.866 --> 00:14:20.133
开源的价值反而更具体了

00:14:20.533 --> 00:14:21.866
一个企业如果只通过

00:14:21.866 --> 00:14:23.600
外部接口使用模型

00:14:24.000 --> 00:14:27.066
很多前处理和服务细节由别人决定

00:14:27.166 --> 00:14:28.800
获得权重和代码后

00:14:28.866 --> 00:14:30.333
它至少能够针对自己

00:14:30.333 --> 00:14:32.100
的资料格式做调整

00:14:32.366 --> 00:14:34.766
固定版本并保留测试环境

00:14:35.366 --> 00:14:38.166
这种可控制性对长期工作有意义

00:14:38.400 --> 00:14:40.700
即使它不自动带来最低成本

00:14:40.800 --> 00:14:42.600
最容易进入试验的场景

00:14:42.866 --> 00:14:44.400
是视觉信息与明确

00:14:44.400 --> 00:14:46.266
规则同时存在的工作

00:14:46.466 --> 00:14:48.133
比如报销单据处理

00:14:48.333 --> 00:14:50.166
模型先提取候选字段

00:14:50.533 --> 00:14:53.000
再由程序核对总额和日期格式

00:14:53.333 --> 00:14:54.900
异常部分交给人

00:14:54.900 --> 00:14:56.300
这个流程把模型用于

00:14:56.300 --> 00:14:57.933
难以标准化的识别

00:14:57.933 --> 00:15:00.766
把容易验证的条件交给确定规则

00:15:01.066 --> 00:15:02.733
它是一种应用设计思路

00:15:02.900 --> 00:15:05.900
不是本次发布已经证明的客户案例

00:15:06.000 --> 00:15:07.733
这样的组合还有一个优势

00:15:07.933 --> 00:15:09.300
错误更容易定位

00:15:09.700 --> 00:15:10.566
金额看错了

00:15:10.566 --> 00:15:12.000
可以回到对应图像

00:15:12.133 --> 00:15:14.533
加总不一致可以检查计算

00:15:14.800 --> 00:15:17.566
审批未通过则应当有业务原因

00:15:17.666 --> 00:15:19.366
若把所有工作都塞进

00:15:19.366 --> 00:15:21.133
一句处理完这份报销

00:15:21.366 --> 00:15:22.766
得到一个总判断

00:15:22.933 --> 00:15:25.000
后续复查就会困难得多

00:15:25.300 --> 00:15:28.066
开放模型给了拆分这些环节的条件

00:15:28.300 --> 00:15:30.600
系统设计仍需要认真完成

00:15:30.766 --> 00:15:32.866
文档整理也有类似机会

00:15:33.133 --> 00:15:34.866
扫描件可能排版复杂

00:15:35.333 --> 00:15:36.266
表格跨页

00:15:36.500 --> 00:15:38.100
图注夹在正文里

00:15:38.133 --> 00:15:40.066
一个能利用图像的模型

00:15:40.266 --> 00:15:42.200
有机会减少先转成纯

00:15:42.200 --> 00:15:43.866
文字时的结构丢失

00:15:44.066 --> 00:15:46.166
但有机会不等于已经准确

00:15:46.300 --> 00:15:49.400
实际验收应当保留页码与证据位置

00:15:49.666 --> 00:15:52.100
让使用者能回到材料核对

00:15:52.100 --> 00:15:54.766
而不是只得到一份无法追溯的摘要

00:15:55.133 --> 00:15:57.300
网页任务则要求模型把

00:15:57.300 --> 00:15:59.100
画面与动作对应起来

00:15:59.266 --> 00:16:00.700
识别按钮在哪里

00:16:00.766 --> 00:16:02.066
仅仅是起点

00:16:02.200 --> 00:16:03.566
按钮能否点击

00:16:03.866 --> 00:16:05.566
点击后是否成功

00:16:05.800 --> 00:16:08.300
页面有没有出现新的确认步骤

00:16:08.900 --> 00:16:11.100
都要由执行系统继续观察

00:16:11.366 --> 00:16:14.100
视觉模型可以参与判断屏幕内容

00:16:14.466 --> 00:16:17.066
但它不会因为看见一个付款按钮

00:16:17.366 --> 00:16:19.333
就自动获得付款权限

00:16:19.766 --> 00:16:22.066
也不应被赋予这种默认权利

00:16:22.133 --> 00:16:23.600
做界面测试时

00:16:23.600 --> 00:16:25.133
视觉能力有机会发现

00:16:25.133 --> 00:16:27.200
文字日志里不明显的问题

00:16:27.366 --> 00:16:29.000
比如内容是否被遮挡

00:16:29.566 --> 00:16:31.500
某个组件的位置是否异常

00:16:31.766 --> 00:16:34.100
但这类判断也需要明确标准

00:16:34.333 --> 00:16:36.100
页面有两种合理布局

00:16:36.533 --> 00:16:38.100
模型偏好其中一种

00:16:38.100 --> 00:16:40.133
不代表另一种就是错误

00:16:40.300 --> 00:16:42.166
真正可以自动验收的

00:16:42.166 --> 00:16:45.100
应当是可描述可复查的要求

00:16:45.200 --> 00:16:47.400
而不是一句看起来不够好

00:16:47.400 --> 00:16:48.866
这些例子共同指向

00:16:48.866 --> 00:16:51.000
一个更有用的竞争标准

00:16:51.366 --> 00:16:54.166
模型的价值应该落在某个环节

00:16:54.166 --> 00:16:55.866
少了多少人工搬运

00:16:56.066 --> 00:16:58.300
又增加了多少检查成本

00:16:58.400 --> 00:17:01.200
一个专业流程可能不需要全能模型

00:17:01.500 --> 00:17:04.500
只需要它稳定处理少数关键输入

00:17:04.733 --> 00:17:06.600
只要这些输入足够频繁

00:17:07.100 --> 00:17:09.333
局部可靠的能力就能有价值

00:17:09.533 --> 00:17:12.800
不必等所有基准都拿第一反过来

00:17:12.966 --> 00:17:15.933
模型在困难基准上的平均成绩提高

00:17:16.266 --> 00:17:17.333
也不意味着可以

00:17:17.333 --> 00:17:19.200
接手风险最高的决策

00:17:19.533 --> 00:17:22.500
医疗图像重要工程判断和

00:17:22.500 --> 00:17:25.066
敏感财务操作都有远超过

00:17:25.066 --> 00:17:26.900
一次问答的责任要求

00:17:27.000 --> 00:17:29.133
此处讨论的专业图表表现

00:17:29.133 --> 00:17:31.333
只能提供研究和选型线索

00:17:31.733 --> 00:17:33.333
不能替代领域验证

00:17:33.366 --> 00:17:35.266
更不能被包装成取消

00:17:35.266 --> 00:17:37.000
专业人员审核的理由

00:17:37.200 --> 00:17:38.700
模型能够读图之后

00:17:38.700 --> 00:17:41.133
还会扩大需要保护的数据范围

00:17:41.400 --> 00:17:43.533
截图中可能包含账号个人

00:17:43.533 --> 00:17:46.100
身份信息或内部系统界面

00:17:46.900 --> 00:17:49.200
资料原本只在某人的屏幕上

00:17:49.300 --> 00:17:51.600
上传之后就进入新的处理链

00:17:51.866 --> 00:17:53.300
企业部署前需要

00:17:53.300 --> 00:17:55.333
弄清楚图像去了哪里

00:17:55.466 --> 00:17:57.000
哪些记录被保留

00:17:57.100 --> 00:17:58.566
以及故障排查时

00:17:58.566 --> 00:18:00.700
会不会再次复制这些资料

00:18:01.000 --> 00:18:02.400
自行部署给了更多

00:18:02.400 --> 00:18:04.266
控制数据流向的机会

00:18:04.300 --> 00:18:06.333
却不自动等于数据安全

00:18:06.466 --> 00:18:08.566
如果服务暴露范围过大

00:18:08.666 --> 00:18:10.566
日志记录了敏感图片

00:18:10.566 --> 00:18:12.666
或者管理权限没有分开

00:18:12.733 --> 00:18:15.200
本地机器一样可能形成风险

00:18:15.300 --> 00:18:16.933
更合理的判断是

00:18:16.933 --> 00:18:18.900
开放权重允许使用者

00:18:18.900 --> 00:18:20.600
自己安排保护措施

00:18:21.000 --> 00:18:23.266
同时也要求使用者有能力

00:18:23.266 --> 00:18:25.733
把这些措施真正执行下去

00:18:25.966 --> 00:18:27.533
视觉输入还存在与

00:18:27.533 --> 00:18:29.466
文字类似的信任问题

00:18:30.100 --> 00:18:31.300
图片里的文字可能

00:18:31.300 --> 00:18:32.900
是需要分析的内容

00:18:32.933 --> 00:18:35.733
也可能夹带试图改变任务的指令

00:18:36.100 --> 00:18:38.466
系统应该分清材料和授权

00:18:38.533 --> 00:18:41.133
不能因为模型能够读到某一句话

00:18:41.133 --> 00:18:42.900
就把它当成新的命令

00:18:43.000 --> 00:18:45.266
让模型接触更多信息

00:18:45.500 --> 00:18:47.533
同时也意味着要更清楚的

00:18:47.533 --> 00:18:49.800
约束它能用这些信息做什么

00:18:50.066 --> 00:18:51.100
这些安全要求

00:18:51.100 --> 00:18:53.066
并没有否定发布的意义

00:18:53.500 --> 00:18:56.066
相反他们解释了为什么开放

00:18:56.066 --> 00:18:58.366
模型会吸引一部分开发者

00:18:58.533 --> 00:19:00.366
某些团队希望自行定义

00:19:00.366 --> 00:19:02.800
审核环节和数据保留策略

00:19:02.966 --> 00:19:04.733
也希望固定一个版本

00:19:05.500 --> 00:19:07.766
不必跟着外部服务每次调整

00:19:07.966 --> 00:19:10.500
模型能力只要达到业务所需

00:19:10.600 --> 00:19:12.466
更多控制权本身就能

00:19:12.466 --> 00:19:14.166
构成选择它的理由

00:19:14.266 --> 00:19:16.600
不过固定版本也有代价

00:19:16.933 --> 00:19:18.400
没有自动跟随更新

00:19:18.400 --> 00:19:20.466
就需要主动评估新版本

00:19:20.600 --> 00:19:22.666
决定是否修补或替换

00:19:22.866 --> 00:19:25.666
维护人员需要保留测试样本

00:19:25.666 --> 00:19:27.966
知道这次升级改善了什么

00:19:28.066 --> 00:19:29.400
又损害了什么

00:19:29.500 --> 00:19:32.133
否则所谓稳定版本可能只是

00:19:32.133 --> 00:19:34.166
很久没有被检查的旧版本

00:19:34.933 --> 00:19:36.366
控制权只有配上维护

00:19:36.366 --> 00:19:38.366
能力才会变成可靠性

00:19:38.600 --> 00:19:40.000
成本同样不能只看

00:19:40.000 --> 00:19:41.466
有没有许可证费用

00:19:41.900 --> 00:19:44.100
自建服务要承担计算资源

00:19:44.566 --> 00:19:46.966
还要有人负责接入和日常运维

00:19:47.166 --> 00:19:48.966
任务量少的时候机器

00:19:48.966 --> 00:19:50.800
空闲也可能产生费用

00:19:51.266 --> 00:19:53.966
任务突然增加又可能需要扩容

00:19:54.366 --> 00:19:55.400
使用接口则有

00:19:55.400 --> 00:19:57.200
另一种计费与服务依赖

00:19:57.566 --> 00:19:59.866
两者应该按相同业务量比较

00:19:59.966 --> 00:20:01.466
不能把免费的权重

00:20:01.466 --> 00:20:03.066
写成免费的生产力

00:20:03.166 --> 00:20:05.366
视觉工作还会改变成本结构

00:20:05.500 --> 00:20:07.133
一张图要怎样缩放

00:20:07.266 --> 00:20:08.900
是否需要重新裁切

00:20:09.400 --> 00:20:11.166
失败后要重试几次

00:20:11.400 --> 00:20:13.333
都会影响实际处理过程

00:20:13.466 --> 00:20:16.166
只比较文字输出的单位价格

00:20:16.700 --> 00:20:18.400
可能忽略大部分成本

00:20:18.533 --> 00:20:20.933
真正有参考价值的指标是

00:20:20.933 --> 00:20:23.200
处理完一份达到要求的资料

00:20:23.366 --> 00:20:25.900
总共花了多少资源和人工时间

00:20:25.966 --> 00:20:28.133
一个便宜模型反复答错

00:20:28.133 --> 00:20:30.400
再让昂贵模型或专家补救

00:20:30.533 --> 00:20:32.066
未必比一开始就选择

00:20:32.066 --> 00:20:34.466
更合适的方案省钱相反

00:20:34.866 --> 00:20:37.366
先用低成本办法处理简单任务

00:20:37.700 --> 00:20:40.133
再把疑难部分交给更强系统

00:20:40.166 --> 00:20:41.333
也可能有效

00:20:41.466 --> 00:20:44.800
关键是难度分类和失败识别要可靠

00:20:44.966 --> 00:20:47.200
不能在不知道对错的情况下

00:20:47.200 --> 00:20:49.866
只按价格把任务自动往下分

00:20:50.100 --> 00:20:51.500
开源路线因此可能

00:20:51.500 --> 00:20:53.400
推动更细的产品分工

00:20:53.533 --> 00:20:55.666
有团队专门改善推理

00:20:55.666 --> 00:20:58.800
有团队针对行业资料设计验证

00:20:58.866 --> 00:21:01.966
还有团队负责把能力放进业务软件

00:21:02.166 --> 00:21:04.866
他们不必都从训练基础模型开始

00:21:05.133 --> 00:21:06.400
但这是开放条件

00:21:06.400 --> 00:21:08.266
可能带来的发展方向

00:21:08.400 --> 00:21:11.666
不代表这些环节今天已经全部成熟

00:21:11.933 --> 00:21:13.466
更不代表任何创业

00:21:13.466 --> 00:21:15.266
项目都能因此盈利

00:21:15.533 --> 00:21:17.266
闭源服务也不会因为一个

00:21:17.266 --> 00:21:19.533
开放模型出现就失去价值

00:21:20.133 --> 00:21:21.700
用户可能继续为稳定

00:21:21.700 --> 00:21:23.600
服务和配套工具付费

00:21:23.933 --> 00:21:26.666
也可能需要供应商承担运维责任

00:21:27.200 --> 00:21:29.566
开源竞争提高的是替代可能性

00:21:29.700 --> 00:21:32.666
只有替代方案在实际任务上跑得通

00:21:32.666 --> 00:21:35.366
用户才有更多谈价和迁移空间

00:21:35.533 --> 00:21:37.733
而不是在宣布开放的那一刻

00:21:37.733 --> 00:21:39.566
所有价格就必然下降

00:21:39.733 --> 00:21:41.266
这次发布对Deepseek

00:21:41.366 --> 00:21:42.933
自身也提出了要求

00:21:43.800 --> 00:21:46.066
模型卡能吸引开发者过来

00:21:46.133 --> 00:21:47.933
清晰的文档和可运行

00:21:47.933 --> 00:21:49.733
实现才能让他们留下

00:21:49.866 --> 00:21:51.533
发现结果差异之后

00:21:51.666 --> 00:21:54.366
能不能定位到版本和输入处理

00:21:54.500 --> 00:21:56.933
决定社区是否有办法一起改进

00:21:57.266 --> 00:21:58.933
开放生态的效率来自可

00:21:58.933 --> 00:22:01.700
检查的问题和可复用的修复

00:22:01.866 --> 00:22:03.866
不能只用下载量来代替

00:22:04.000 --> 00:22:05.166
读懂这个逻辑

00:22:05.400 --> 00:22:08.300
就能理解为什么实验版也值得报道

00:22:08.733 --> 00:22:10.300
他把一部分原本只能

00:22:10.300 --> 00:22:12.466
通过最终回答观察的能力

00:22:12.600 --> 00:22:15.866
变成可检查和可接入的技术材料

00:22:16.133 --> 00:22:17.733
研究者可以发现边界

00:22:17.900 --> 00:22:20.300
开发者可以试自己的工作流程

00:22:20.600 --> 00:22:22.933
价值发生在这些具体动作里

00:22:22.966 --> 00:22:24.566
未必需要先获得一个

00:22:24.566 --> 00:22:26.300
全世界最强的称号

00:22:26.800 --> 00:22:29.766
但开源社区的反馈也要分层看

00:22:29.800 --> 00:22:31.733
一条成功运行的分享

00:22:31.866 --> 00:22:33.566
只能代表那个人的环境

00:22:34.100 --> 00:22:36.566
一条失败报告也不能直接

00:22:36.566 --> 00:22:39.333
证明模型对所有人都不可用

00:22:39.400 --> 00:22:41.500
真正能积累成证据的

00:22:41.500 --> 00:22:44.900
是清楚的版本硬件条件和输入

00:22:45.000 --> 00:22:47.166
以及可以重复得到的结果

00:22:47.466 --> 00:22:49.566
省略这些背景讨论

00:22:49.566 --> 00:22:51.366
很容易变成立场对撞

00:22:51.600 --> 00:22:53.600
选择是否采用这款模型

00:22:54.000 --> 00:22:55.333
一个实际的起点是

00:22:55.333 --> 00:22:57.066
保留自己的工作样本

00:22:57.333 --> 00:22:59.866
样本不能只有清晰漂亮的图片

00:23:00.000 --> 00:23:02.066
还应包含日常真的会遇到

00:23:02.066 --> 00:23:04.100
的模糊内容和排版变化

00:23:04.500 --> 00:23:06.766
测试要覆盖重要的失败类型

00:23:06.933 --> 00:23:09.366
而不是专门挑模型擅长的题

00:23:09.566 --> 00:23:12.500
否则上线之前看到的准确率

00:23:12.533 --> 00:23:15.200
可能只是对精心整理的材料负责

00:23:15.333 --> 00:23:18.333
中文使用场景尤其需要单独验证

00:23:18.733 --> 00:23:20.933
这次模型卡的成绩表并没有

00:23:20.933 --> 00:23:23.900
逐项披露简体中文票据繁体字

00:23:23.900 --> 00:23:26.800
截图或中英混排文件的专项结果

00:23:26.933 --> 00:23:29.133
同一页里既有中文项目名

00:23:29.133 --> 00:23:31.400
又有英文缩写和数字单位

00:23:31.566 --> 00:23:33.466
错误可能发生在字符

00:23:33.766 --> 00:23:35.666
也可能发生在对应关系

00:23:35.866 --> 00:23:38.000
面向中文业务的开发者不能用

00:23:38.000 --> 00:23:40.900
一组纵合层级替代本地材料测试

00:23:41.200 --> 00:23:44.133
样本还应区分错误的严重程度

00:23:44.300 --> 00:23:45.766
图标题多了一个字

00:23:46.000 --> 00:23:48.200
与把金额的小数点看错

00:23:48.566 --> 00:23:50.300
不应该获得同样评价

00:23:50.500 --> 00:23:51.866
哪怕整体正确

00:23:51.966 --> 00:23:52.966
数量相近

00:23:53.200 --> 00:23:55.666
业务后果也可能完全不同

00:23:55.800 --> 00:23:58.466
模型选型需要把损失放进考核

00:23:58.700 --> 00:24:01.400
才能知道哪些任务可以自动通过

00:24:01.566 --> 00:24:03.766
哪些必须停下来让人确认

00:24:04.466 --> 00:24:05.700
比较模型时

00:24:05.766 --> 00:24:08.766
输入质量和可用工具也要尽量一致

00:24:08.966 --> 00:24:10.366
一个系统可以放大

00:24:10.366 --> 00:24:12.266
图像并调用计算工具

00:24:12.700 --> 00:24:14.666
另一个只能看一次压缩图

00:24:14.733 --> 00:24:16.000
结果反映的就是

00:24:16.000 --> 00:24:18.100
不同系统的综合表现

00:24:18.266 --> 00:24:19.966
这样的比较仍然有用

00:24:20.066 --> 00:24:23.200
但需要讲清楚买到的是哪一套能力

00:24:23.333 --> 00:24:24.966
不能把所有优势都

00:24:24.966 --> 00:24:26.766
归到模型权重本身

00:24:26.933 --> 00:24:29.566
运行时间也应与结果一起记录

00:24:30.266 --> 00:24:32.466
一个任务等很久才答对

00:24:32.566 --> 00:24:35.200
和一个交互场景要求及时反馈

00:24:36.066 --> 00:24:37.333
适用条件不同

00:24:37.866 --> 00:24:40.300
有些离线批处理可以接受等待

00:24:40.700 --> 00:24:42.400
有些现场操作不行

00:24:42.533 --> 00:24:44.466
最高推理强度下的分数

00:24:44.466 --> 00:24:46.200
提供能力上限的线索

00:24:46.500 --> 00:24:48.733
日常产品还要找到准确率

00:24:48.733 --> 00:24:50.766
与等待之间合适的位置

00:24:51.100 --> 00:24:52.266
最后还要检查系统

00:24:52.266 --> 00:24:54.166
会不会承认无法确定

00:24:54.333 --> 00:24:56.933
一张关键区域模糊的图片

00:24:57.166 --> 00:24:58.366
硬给一个答案

00:24:58.400 --> 00:25:01.566
可能比明确请求更清晰的材料更糟

00:25:01.966 --> 00:25:04.000
合理的流程应该允许暂停

00:25:04.066 --> 00:25:05.100
保留证据

00:25:05.100 --> 00:25:06.266
再安排复核

00:25:06.366 --> 00:25:07.466
多模态进步

00:25:07.466 --> 00:25:10.900
如果只让错误回答看起来更自信

00:25:11.266 --> 00:25:13.933
而没有改善这种不确定性的处理

00:25:14.100 --> 00:25:16.133
商业价值会受到限制

00:25:16.300 --> 00:25:20.366
所以Deepseek v四flash vision exp的发布

00:25:20.466 --> 00:25:23.700
最扎实的意义是让V4路线补上了

00:25:23.700 --> 00:25:26.166
可公开研究的视觉理解能力

00:25:26.566 --> 00:25:28.100
并给出了能够讨论

00:25:28.100 --> 00:25:29.866
优劣的测试与实现

00:25:30.066 --> 00:25:32.133
部分项目已经显示竞争力

00:25:32.266 --> 00:25:33.900
其他项目仍有差距

00:25:34.100 --> 00:25:36.300
实验状态部署成本和业务

00:25:36.300 --> 00:25:39.533
可靠性都应当留在同一张判断表里

00:25:39.600 --> 00:25:42.200
生态接入已经出现了一个具体信号

00:25:42.766 --> 00:25:47.500
Openclaw2.0的发布说明把Deepseek V4 Flash vision

00:25:47.600 --> 00:25:50.100
实验模型列进了模型发现更新

00:25:50.133 --> 00:25:51.866
这个条目说明周边

00:25:51.866 --> 00:25:53.900
工具开始识别相关模型

00:25:54.066 --> 00:25:56.566
但只是发现与接入层面的信息

00:25:56.766 --> 00:25:58.300
不能当成所有图像

00:25:58.300 --> 00:25:59.800
任务都已测试通过

00:26:00.133 --> 00:26:01.333
目录里找得到

00:26:01.666 --> 00:26:03.533
和接上之后持续交付

00:26:03.966 --> 00:26:06.133
是需要分别验收的两步

00:26:06.133 --> 00:26:07.533
这也给后续进展

00:26:07.533 --> 00:26:09.333
提供了可观察的方向

00:26:09.666 --> 00:26:10.966
模型发布以后

00:26:11.133 --> 00:26:14.333
值得跟踪的不只是又出现多少演示

00:26:14.533 --> 00:26:17.666
还包括不同工具是否正确传递图像

00:26:18.100 --> 00:26:20.366
服务实现能否稳定运行

00:26:20.733 --> 00:26:22.266
以及真实任务的失败

00:26:22.266 --> 00:26:23.933
案例有没有得到修复

00:26:24.066 --> 00:26:26.100
这几类改进会相互影响

00:26:26.333 --> 00:26:28.766
最终决定开放的能力能不能以普通

00:26:28.766 --> 00:26:31.733
用户用得起用得明白的方式出现

00:26:31.900 --> 00:26:33.800
它能否继续扩大影响

00:26:33.866 --> 00:26:36.600
要看接下来的复现与工程工作

00:26:36.733 --> 00:26:39.700
能不能把模型成绩变成稳定交付

00:26:40.100 --> 00:26:41.200
对用户而言

00:26:41.333 --> 00:26:44.533
值得期待的是更多可验证的选择

00:26:44.600 --> 00:26:47.500
一个模型不需要在所有问题上获胜

00:26:47.566 --> 00:26:50.266
才有机会改变某一类工作的成本

00:26:50.533 --> 00:26:53.566
但只有真正把那一类工作做可靠了

00:26:53.566 --> 00:26:55.866
开源发布才算兑现了价值