WEBVTT
Kind: captions
Language: zh

00:00:00.166 --> 00:00:02.866
谷歌发布了智能视频理解API

00:00:02.933 --> 00:00:04.733
一段3小时的课程里

00:00:04.933 --> 00:00:07.966
讲者可能只用2秒钟承认实验失败

00:00:08.500 --> 00:00:11.100
传统AI每秒抽取一张画面

00:00:11.266 --> 00:00:12.533
从头读到尾

00:00:12.733 --> 00:00:14.733
仍然可能错过那两秒

00:00:14.866 --> 00:00:16.733
谷歌新发布的智能视频

00:00:16.733 --> 00:00:19.200
理解API换了一种做法

00:00:19.366 --> 00:00:22.100
Gemini会先判断答案可能藏在哪里

00:00:22.466 --> 00:00:24.866
读取字幕并跳到对应时间

00:00:25.066 --> 00:00:26.733
再提高局部帧率

00:00:26.800 --> 00:00:28.500
必要时重新检查

00:00:28.766 --> 00:00:31.000
AI第一次不只是在看视频

00:00:31.066 --> 00:00:33.600
它开始决定该看什么看多久

00:00:33.700 --> 00:00:35.966
以及什么时候应该回头再看

00:00:36.066 --> 00:00:38.700
这项功能叫agentic video understanding

00:00:39.066 --> 00:00:41.500
也就是智能体式视频理解

00:00:41.866 --> 00:00:44.533
首批支持Gemini3.7Flash

00:00:44.733 --> 00:00:47.700
3.6Flash和3.5Flashlight

00:00:48.133 --> 00:00:50.600
开发者在API配置中把

00:00:50.600 --> 00:00:53.166
视频处理模式设成agentic

00:00:53.366 --> 00:00:55.966
就可以让模型动态浏览视频

00:00:56.133 --> 00:00:59.366
上传文件和公开Youtube连接都能使用

00:00:59.700 --> 00:01:02.300
Google AI studio与Gemini enterprise

00:01:02.300 --> 00:01:03.933
agent platform已经开放

00:01:04.200 --> 00:01:06.100
谷歌公布的数字很醒目

00:01:06.200 --> 00:01:08.800
与固定帧率的静态处理相比

00:01:08.900 --> 00:01:10.733
智能体模式在测试中

00:01:10.733 --> 00:01:13.766
最高减少88%的TOKEN消耗

00:01:13.966 --> 00:01:16.800
最高降低66%的分析成本

00:01:17.133 --> 00:01:19.666
回答质量最高提高7%

00:01:19.866 --> 00:01:21.500
三个最高必须保留

00:01:21.666 --> 00:01:24.533
因为它们来自不同任务和测试条件

00:01:24.933 --> 00:01:26.566
不能理解为所有视频

00:01:26.566 --> 00:01:28.666
都会同时达到这组结果

00:01:28.866 --> 00:01:31.666
短片和长客以及监控录像与

00:01:31.666 --> 00:01:34.100
体育素材的收益会有很大差别

00:01:34.400 --> 00:01:36.366
要理解这项更新的分量

00:01:36.500 --> 00:01:39.300
先要看传统视频AI怎样工作

00:01:40.200 --> 00:01:42.266
Gemini的默认静态模式通常

00:01:42.266 --> 00:01:45.066
按照每秒一帧读取画面音频

00:01:45.466 --> 00:01:47.000
按固定规格处理

00:01:47.166 --> 00:01:50.266
再把时间戳和媒体信息放入上下文

00:01:50.366 --> 00:01:51.900
低媒体分辨率下

00:01:51.900 --> 00:01:54.400
一秒视频大约消耗100个TOKEN

00:01:55.066 --> 00:01:57.400
高分辨率可接近300个TOKEN

00:01:57.733 --> 00:01:59.066
一小时内容大约

00:01:59.066 --> 00:02:01.933
对应36万到108万个TOKEN

00:02:02.266 --> 00:02:05.166
还没计算问题系统指令和输出

00:02:05.300 --> 00:02:07.366
固定抽帧有两个明显缺陷

00:02:07.666 --> 00:02:10.766
第一是成本跟时长近似线性增长

00:02:11.166 --> 00:02:13.366
视频从10分钟变成两小时

00:02:13.500 --> 00:02:16.166
系统即使只需要回答一个局部问题

00:02:16.166 --> 00:02:18.200
也要处理大量无关片段

00:02:18.333 --> 00:02:20.566
第二是精度被采样率限制

00:02:20.733 --> 00:02:23.133
一个快速手势仪表跳变

00:02:23.133 --> 00:02:25.500
或者剪辑点持续不到1秒

00:02:25.933 --> 00:02:27.500
固定的一帧可能刚好

00:02:27.500 --> 00:02:29.533
落在动作之前和之后

00:02:29.566 --> 00:02:31.100
中间最关键的状态

00:02:31.100 --> 00:02:32.966
没有进入模型上下文

00:02:33.100 --> 00:02:35.100
开发者以前可以自己解决

00:02:35.466 --> 00:02:37.133
他们先跑语音转录

00:02:37.366 --> 00:02:39.466
再用关键词定位时间段

00:02:39.666 --> 00:02:41.200
然后切割视频

00:02:41.266 --> 00:02:42.666
提高局部帧率

00:02:42.733 --> 00:02:45.133
最后把片段送入视觉模型

00:02:45.333 --> 00:02:48.100
遇到复杂问题还要写循环

00:02:48.100 --> 00:02:49.900
让模型重新查找

00:02:50.100 --> 00:02:51.400
工程上做得到

00:02:51.700 --> 00:02:53.766
代价是维护转录和检索

00:02:54.200 --> 00:02:56.466
还要处理切片与多模态推理

00:02:56.900 --> 00:02:58.200
每种视频格式

00:02:58.300 --> 00:03:00.900
每类问题都可能需要不同规则

00:03:01.166 --> 00:03:02.500
谷歌现在把这条

00:03:02.500 --> 00:03:04.366
流水线收进模型内部

00:03:04.733 --> 00:03:06.133
Gemini接到问题后

00:03:06.133 --> 00:03:08.166
可以先检查转录文字

00:03:08.333 --> 00:03:10.533
确定几个可能的时间窗口

00:03:10.866 --> 00:03:12.866
接着调用内部视频工具

00:03:12.866 --> 00:03:14.900
读取局部画面或音频

00:03:15.200 --> 00:03:16.366
证据不足时

00:03:16.366 --> 00:03:18.000
它会改变采样方式

00:03:18.333 --> 00:03:19.300
再看一次

00:03:19.666 --> 00:03:21.933
API响应中的Processing call和

00:03:21.933 --> 00:03:24.900
Processing result会记录这些加载步骤

00:03:24.900 --> 00:03:26.666
最后才生成答案

00:03:26.766 --> 00:03:29.166
这里的智能体没有神秘成分

00:03:29.766 --> 00:03:31.900
它代表模型拥有了一个循环

00:03:32.366 --> 00:03:34.066
先制定搜索方向

00:03:34.166 --> 00:03:36.600
调用工具取得局部证据

00:03:36.866 --> 00:03:38.766
判断证据是否够用

00:03:38.800 --> 00:03:40.133
再决定下一步

00:03:40.466 --> 00:03:43.466
过去的视频模型更像一次性读取器

00:03:43.666 --> 00:03:46.800
所有内容在回答前就被装进上下文

00:03:46.800 --> 00:03:49.866
新模式把视频当成可查询的数据源

00:03:50.166 --> 00:03:52.900
模型只在需要时取出相关部分

00:03:53.066 --> 00:03:54.600
这一变化首先解决

00:03:54.600 --> 00:03:56.333
长视频的经济问题

00:03:57.066 --> 00:03:58.900
用户询问一场90分钟

00:03:58.900 --> 00:04:00.866
发布会中的三个公告

00:04:01.566 --> 00:04:04.466
静态模式会为整场内容支付TOKEN

00:04:04.900 --> 00:04:05.900
智能体模式

00:04:06.066 --> 00:04:07.400
可能先看转录

00:04:07.533 --> 00:04:08.800
找到三处重点

00:04:08.800 --> 00:04:10.366
再加载附近画面

00:04:10.533 --> 00:04:12.800
核对产品名称和演示细节

00:04:12.933 --> 00:04:15.466
大量重复镜头停顿和

00:04:15.466 --> 00:04:16.900
与问题无关的内容

00:04:16.900 --> 00:04:18.400
无需进入上下文

00:04:18.466 --> 00:04:19.766
成本自然下降

00:04:19.933 --> 00:04:22.666
88%的TOKEN节省由此而来

00:04:22.900 --> 00:04:24.900
但它没有改变模型定价

00:04:25.000 --> 00:04:27.500
谷歌暂时不收取额外功能费

00:04:27.566 --> 00:04:30.733
输入和输出以及中间推理与工具

00:04:30.733 --> 00:04:33.733
加载内容仍按标准Gemini价格计算

00:04:33.966 --> 00:04:35.600
节省来自少读数据

00:04:35.700 --> 00:04:37.666
并非每个TOKEN变便宜

00:04:37.866 --> 00:04:39.000
问题越集中

00:04:39.100 --> 00:04:40.066
视频越长

00:04:40.066 --> 00:04:41.466
无关内容越多

00:04:41.866 --> 00:04:43.500
这种方式越划算

00:04:43.666 --> 00:04:46.666
反过来如果用户要求完整列出

00:04:46.666 --> 00:04:48.800
整场比赛每一次传球

00:04:49.000 --> 00:04:51.366
模型几乎要检查全部内容

00:04:52.133 --> 00:04:53.600
智能体模式能省下

00:04:53.600 --> 00:04:55.366
的TOKEN会明显减少

00:04:55.733 --> 00:04:58.866
反复规划还可能增加额外思考费用

00:04:59.066 --> 00:05:00.866
谷歌开发文档也提醒

00:05:01.266 --> 00:05:03.133
TOKEN消耗取决于内容

00:05:03.133 --> 00:05:04.866
复杂度和导航深度

00:05:05.300 --> 00:05:07.533
动态浏览是一种资源分配策略

00:05:07.533 --> 00:05:10.200
不是一台固定比例的视频压缩器

00:05:10.266 --> 00:05:11.966
第二个变化是模型可以

00:05:11.966 --> 00:05:13.966
在局部提高时间精度

00:05:14.266 --> 00:05:16.200
静态模式默认每秒一帧

00:05:16.500 --> 00:05:18.466
适合大多数缓慢场景

00:05:18.866 --> 00:05:20.200
智能体发现某个时间

00:05:20.200 --> 00:05:22.100
窗口存在快速动作后

00:05:22.166 --> 00:05:24.733
可以调整帧率并重复查看

00:05:24.900 --> 00:05:27.466
谷歌展示的方向包括精确计算

00:05:27.466 --> 00:05:30.266
重复动作和捕捉短暂状态变化

00:05:30.566 --> 00:05:32.800
还能寻找紧密剪辑边界

00:05:32.900 --> 00:05:35.466
以及检查高速运动中的异常

00:05:35.666 --> 00:05:37.133
以工厂质检为例

00:05:37.133 --> 00:05:39.266
一条传送带运行几个小时

00:05:39.466 --> 00:05:41.733
真正的机械卡顿可能只有半秒

00:05:41.766 --> 00:05:44.400
把所有画面都按高帧率送入模型

00:05:44.600 --> 00:05:46.400
账单和延迟都会很高

00:05:46.500 --> 00:05:49.800
先用低成本信号锁定异常窗口

00:05:50.100 --> 00:05:52.166
再对几秒内容密集采样

00:05:52.333 --> 00:05:54.700
才符合生产系统的资源逻辑

00:05:55.000 --> 00:05:56.400
模型的价值来自把

00:05:56.400 --> 00:05:58.333
算力集中到可疑位置

00:05:58.533 --> 00:06:00.366
体育分析也是同一套原理

00:06:00.700 --> 00:06:01.966
用户询问一名球员

00:06:01.966 --> 00:06:03.566
何时改变跑动方向

00:06:03.700 --> 00:06:05.266
字幕几乎没有帮助

00:06:05.366 --> 00:06:07.133
模型就需要依赖画面

00:06:07.200 --> 00:06:09.766
用户询问教练在暂停时说了什么

00:06:09.800 --> 00:06:11.533
转录和音频更重要

00:06:11.666 --> 00:06:13.666
过去多模态常被理解为

00:06:13.666 --> 00:06:15.866
把几种数据一起输入

00:06:16.466 --> 00:06:19.766
智能

00:06:29.533 --> 00:06:31.933
模型可以先依靠文本快速定位

00:06:32.000 --> 00:06:34.466
多人同时讲话口音复杂

00:06:34.500 --> 00:06:36.166
或者没有字幕的素材

00:06:36.333 --> 00:06:38.666
需要读取更多音频和画面

00:06:38.866 --> 00:06:40.733
TOKEN节省可能下降

00:06:40.933 --> 00:06:42.366
纯视觉任务又会把

00:06:42.366 --> 00:06:43.900
压力转到镜头理解

00:06:44.300 --> 00:06:45.500
厂商公布一个平均

00:06:45.500 --> 00:06:47.666
数字很难覆盖这些差异

00:06:47.866 --> 00:06:50.366
开发者最好按自己的语言和话值

00:06:50.500 --> 00:06:52.700
再按内容类型建立测试集

00:06:52.900 --> 00:06:55.966
同一个问题的写法也可能改变成本

00:06:56.333 --> 00:06:58.100
询问总结整场会议

00:06:58.466 --> 00:07:00.533
模型需要覆盖大量片段

00:07:00.733 --> 00:07:02.566
询问财务负责人在哪

00:07:02.566 --> 00:07:04.366
一段下调收入预期

00:07:04.666 --> 00:07:06.700
搜索范围明显更集中

00:07:06.933 --> 00:07:09.100
智能体模式会让提示词从

00:07:09.100 --> 00:07:11.733
表达习惯变成资源调度信号

00:07:11.866 --> 00:07:13.000
问题越明确

00:07:13.200 --> 00:07:15.966
模型越容易决定哪些内容无需加载

00:07:16.800 --> 00:07:18.366
模糊问题则可能触发

00:07:18.366 --> 00:07:20.966
更广泛的搜索和多轮复查

00:07:20.966 --> 00:07:23.500
这给产品设计提出了新要求

00:07:23.800 --> 00:07:25.966
界面不能只放一个输入框

00:07:26.600 --> 00:07:28.100
还应该让用户选择

00:07:28.100 --> 00:07:30.800
速度完整度和证据要求

00:07:30.933 --> 00:07:33.533
快速查找允许模型少看一些

00:07:33.733 --> 00:07:36.300
合规审查则要扩大覆盖范围

00:07:36.400 --> 00:07:37.866
并返回时间戳

00:07:37.966 --> 00:07:40.366
不同任务共用一个默认配置

00:07:40.533 --> 00:07:42.266
最终往往既不够快

00:07:42.266 --> 00:07:43.366
也不够可靠

00:07:44.166 --> 00:07:45.500
API提供能力

00:07:45.566 --> 00:07:48.133
体验仍然要由应用开发者完成

00:07:48.266 --> 00:07:51.700
这种选择带来最高7%的质量提升

00:07:51.766 --> 00:07:53.066
原因并不复杂

00:07:53.700 --> 00:07:55.400
静态模式为了控制成本

00:07:55.466 --> 00:07:57.400
只能降低整体采样率

00:07:57.533 --> 00:07:58.566
关键细节可能

00:07:58.566 --> 00:08:00.466
从一开始就没有被读取

00:08:00.666 --> 00:08:02.266
智能体模式先粗查

00:08:02.366 --> 00:08:04.733
再把有限TOKEN用在重要片段

00:08:04.966 --> 00:08:06.666
局部证据反而更多

00:08:07.133 --> 00:08:08.933
不过7%仍然是谷歌

00:08:08.933 --> 00:08:10.500
测试中的最佳提升

00:08:10.800 --> 00:08:12.200
不能推导成每项

00:08:12.200 --> 00:08:13.933
视频任务都会更准确

00:08:14.133 --> 00:08:17.100
长视频海里捞针是最直接的应用

00:08:17.466 --> 00:08:18.466
几小时会议中

00:08:18.466 --> 00:08:20.566
一名发言者提到某个数字

00:08:20.766 --> 00:08:21.966
教学录像里

00:08:22.000 --> 00:08:23.900
老师临时修正一个公式

00:08:24.166 --> 00:08:25.166
监控画面中

00:08:25.166 --> 00:08:27.533
一个物体短暂离开又返回

00:08:27.600 --> 00:08:29.533
传统语义检索依赖字幕

00:08:29.966 --> 00:08:32.800
遇到没有对白的视觉事件就会失效

00:08:33.133 --> 00:08:35.533
Gemini可以先用字幕缩小范围

00:08:35.566 --> 00:08:37.900
也能直接扫描画面和音频

00:08:37.933 --> 00:08:39.766
再对候选片段复查

00:08:40.066 --> 00:08:43.166
亚秒级时刻检索则会影响自动剪辑

00:08:43.700 --> 00:08:45.933
剪辑系统过去可以找到一段话

00:08:46.066 --> 00:08:47.866
却很难精确判断动作

00:08:47.866 --> 00:08:49.566
开始和结束的位置

00:08:49.733 --> 00:08:52.366
结果常常多切半秒或截断手势

00:08:52.866 --> 00:08:55.600
模型能从新采样局部画面后

00:08:55.600 --> 00:08:57.600
可以寻找更紧的切点

00:08:57.700 --> 00:09:00.266
它仍然需要人工检查节奏和叙事

00:09:00.333 --> 00:09:02.500
但粗剪镜头定位和

00:09:02.500 --> 00:09:04.600
素材筛选会快很多

00:09:04.766 --> 00:09:06.800
内容创作者面对的第一个

00:09:06.800 --> 00:09:10.166
变化是素材库开始真正可搜索

00:09:10.600 --> 00:09:13.766
大量频道保存着多年采访和发布会

00:09:13.866 --> 00:09:15.533
也留下不少录屏

00:09:15.800 --> 00:09:17.700
文件名无法描述其中

00:09:17.700 --> 00:09:19.500
每一分钟发生了什么

00:09:19.600 --> 00:09:21.866
智能视频API可以围绕

00:09:21.866 --> 00:09:24.100
具体问题查询这些素材

00:09:24.466 --> 00:09:26.366
比如找出某位嘉宾所有

00:09:26.366 --> 00:09:28.200
谈到芯片成本的片段

00:09:28.400 --> 00:09:29.966
或者定位产品界面

00:09:29.966 --> 00:09:31.866
第一次出现异常的位置

00:09:32.266 --> 00:09:35.266
过去被存进硬盘后很少再用的内容

00:09:35.900 --> 00:09:38.000
有机会重新变成生产资料

00:09:38.133 --> 00:09:40.200
第二个变化是核对流程

00:09:40.400 --> 00:09:42.366
脚本提到一个产品功能

00:09:42.600 --> 00:09:45.000
模型可以跳到相关演示片段

00:09:45.200 --> 00:09:48.133
检查画面是否真的支持这句描述

00:09:48.400 --> 00:09:49.666
剪辑完成后

00:09:49.700 --> 00:09:52.133
也可以核对旁白字幕和

00:09:52.133 --> 00:09:53.866
镜头有没有明显冲突

00:09:54.266 --> 00:09:57.100
AI不能替代编辑做最终事实判断

00:09:57.200 --> 00:09:59.200
但它能把需要人工检查的

00:09:59.200 --> 00:10:01.400
范围从两小时缩到几分钟

00:10:01.533 --> 00:10:04.100
第三个变化是长内容再利用

00:10:04.133 --> 00:10:06.100
一场访谈可以被拆成

00:10:06.100 --> 00:10:08.133
主题段落和短片候选

00:10:08.133 --> 00:10:09.666
同时生成时间轴

00:10:10.200 --> 00:10:12.533
课程可以自动生成章节索引

00:10:12.866 --> 00:10:15.533
企业培训录像可以按问题调用

00:10:15.733 --> 00:10:18.800
用户用自然语言直接进入某个时刻

00:10:18.900 --> 00:10:21.066
并看到支持答案的画面

00:10:21.066 --> 00:10:23.933
比再做一个摘要按钮更有价值

00:10:24.133 --> 00:10:25.666
谷歌自己拥有一个其他

00:10:25.666 --> 00:10:28.500
模型公司很难复制的优势YouTube

00:10:28.800 --> 00:10:31.666
官方计划在未来数月让智能体视频

00:10:31.666 --> 00:10:34.733
理解支持播放页面的ask YouTube功能

00:10:34.966 --> 00:10:36.766
并逐步进入Gemini应用

00:10:36.766 --> 00:10:38.966
的Flash和Flashlight模型

00:10:39.333 --> 00:10:40.800
Gemini一旦能够动态

00:10:40.800 --> 00:10:42.866
读取Youtube画面与字幕

00:10:42.933 --> 00:10:44.266
还能读取音频

00:10:44.333 --> 00:10:47.266
平台搜索的对象就会从标题与描述

00:10:47.300 --> 00:10:49.200
再从转录文字扩展到

00:10:49.200 --> 00:10:51.566
视频内部真正发生的动作

00:10:51.766 --> 00:10:54.700
传统搜索引擎主要索引网页文本

00:10:55.366 --> 00:10:56.933
视频搜索长期依赖

00:10:56.933 --> 00:10:59.266
创作者写标题和打标签

00:10:59.866 --> 00:11:01.533
也依赖上传字幕

00:11:02.266 --> 00:11:04.933
画面中的细节很难被准确索引

00:11:05.100 --> 00:11:06.466
智能体理解让

00:11:06.566 --> 00:11:09.333
哪一期评测里出现过这个接口

00:11:10.066 --> 00:11:12.500
哪场比赛发生过类似动作

00:11:12.600 --> 00:11:14.900
这样的查询更接近可用

00:11:15.066 --> 00:11:17.566
Youtube数十亿小时内容也会

00:11:17.566 --> 00:11:19.933
因此变成Google模型独有的

00:11:19.933 --> 00:11:22.733
训练和检索以及产品分发优势

00:11:23.066 --> 00:11:25.666
旧内容的价值也可能重新计算

00:11:26.366 --> 00:11:28.200
一段上传5年的教程

00:11:28.266 --> 00:11:31.000
标题早已不符合今天的搜索表达

00:11:31.200 --> 00:11:33.966
其中某个30秒演示仍然很有用

00:11:34.100 --> 00:11:35.766
平台能理解画面后

00:11:36.133 --> 00:11:38.766
这个片段有机会直接回答新问题

00:11:38.933 --> 00:11:40.666
长视频不必完全依赖

00:11:40.666 --> 00:11:43.000
发布日期和整体点击量

00:11:43.266 --> 00:11:46.066
它内部的具体知识可以被再次发现

00:11:46.366 --> 00:11:48.500
创作者过去积累的内容库

00:11:48.733 --> 00:11:51.133
可能成为持续被检索的资产

00:11:51.200 --> 00:11:53.066
这也会改变内容结构

00:11:53.400 --> 00:11:55.966
讲者如果清楚说出阶段结论

00:11:56.200 --> 00:11:58.400
画面与论点保持对应

00:11:58.933 --> 00:12:01.300
模型更容易建立可靠索引

00:12:01.500 --> 00:12:02.600
大量绕圈

00:12:02.733 --> 00:12:04.200
标题与内容脱节

00:12:04.200 --> 00:12:06.533
或者关键信息没有视觉证据

00:12:06.600 --> 00:12:08.566
会增加机器理解难度

00:12:08.733 --> 00:12:10.533
面向人类的好表达

00:12:10.600 --> 00:12:13.166
和面向AI的可检索性

00:12:13.500 --> 00:12:15.333
在很多地方其实一致

00:12:15.600 --> 00:12:16.700
主题明确

00:12:16.866 --> 00:12:18.366
信息有上下文

00:12:18.500 --> 00:12:20.366
结论能够被证据定位

00:12:20.366 --> 00:12:22.566
这套组合有很强的商业闭环

00:12:22.800 --> 00:12:24.800
Google提供模型和API

00:12:24.900 --> 00:12:27.966
也掌握云计算平台与视频内容入口

00:12:28.400 --> 00:12:30.700
开发者为动态分析支付TOKEN

00:12:31.000 --> 00:12:34.200
普通用户在Gemini和Youtube中使用结果

00:12:34.300 --> 00:12:35.766
技术提升带来的收益

00:12:35.766 --> 00:12:37.700
不止落在模型调用量

00:12:37.733 --> 00:12:39.333
还可能提高用户停留

00:12:39.333 --> 00:12:41.166
时间和搜索覆盖率

00:12:41.166 --> 00:12:43.966
也让旧内容再次获得分发机会

00:12:44.366 --> 00:12:46.166
创作者也要看到另一面

00:12:46.333 --> 00:12:48.600
平台能更细的理解画面后

00:12:48.700 --> 00:12:50.966
标题和封面与实际内容是否

00:12:50.966 --> 00:12:53.666
匹配会更容易被机器检查

00:12:53.766 --> 00:12:56.000
只靠夸张标题吸引点击

00:12:56.466 --> 00:12:58.666
正文长期不兑现承诺的内容

00:12:58.800 --> 00:13:00.800
可能更难获得稳定推荐

00:13:01.000 --> 00:13:04.200
相反结构清晰且画面证据充分

00:13:04.466 --> 00:13:06.900
每一段都有新信息的长内容

00:13:07.000 --> 00:13:09.933
更容易被系统拆解成可检索片段

00:13:10.000 --> 00:13:11.900
这并不代表算法已经公开

00:13:11.900 --> 00:13:14.133
承诺按照这种方式排名

00:13:14.366 --> 00:13:15.900
Google只确认智能体理

00:13:15.900 --> 00:13:17.566
解将用于ask YouTube

00:13:17.700 --> 00:13:20.133
没有宣布它直接改变推荐权重

00:13:20.700 --> 00:13:23.500
合理推测与已确认功能要分开

00:13:23.500 --> 00:13:24.700
可以确定的是

00:13:24.900 --> 00:13:27.566
平台理解内容的粒度正在提高

00:13:28.000 --> 00:13:30.800
至于它何时以什么方式影响分发

00:13:30.900 --> 00:13:33.000
仍要等待产品上线后的

00:13:33.000 --> 00:13:34.933
公开说明和实际数据

00:13:35.200 --> 00:13:37.166
企业市场的用途更广

00:13:37.400 --> 00:13:39.900
客服团队可以查询屏幕录制

00:13:40.366 --> 00:13:42.500
寻找用户在哪一步操作失败

00:13:43.000 --> 00:13:44.266
保险公司可以定位

00:13:44.266 --> 00:13:46.266
事故录像中的关键动作

00:13:46.533 --> 00:13:49.466
医疗培训可以按手术阶段检索片段

00:13:49.666 --> 00:13:52.100
零售系统可以统计特定事件

00:13:52.600 --> 00:13:54.366
安全团队则能从

00:13:54.366 --> 00:13:56.700
长时间监控中筛选异常

00:13:56.933 --> 00:13:59.566
每个场景都需要独立评估准确率

00:13:59.866 --> 00:14:01.166
不能因为通用榜单

00:14:01.166 --> 00:14:04.466
提高7%就省掉行业验证

00:14:04.566 --> 00:14:06.100
尤其是异常检测

00:14:06.200 --> 00:14:08.166
错误成本可能完全不同

00:14:08.366 --> 00:14:10.900
漏掉短暂故障会造成停机

00:14:11.100 --> 00:14:14.166
误报太多又会让工作人员失去耐心

00:14:14.466 --> 00:14:16.400
Gemini能够提高局部帧率

00:14:16.466 --> 00:14:18.866
并不等于它理解所有物理因果

00:14:19.000 --> 00:14:21.500
真实部署要保留阈值设计

00:14:21.700 --> 00:14:23.966
抽样复合和人工升级机制

00:14:24.166 --> 00:14:27.200
高风险决定不能只凭一句模型输出

00:14:27.333 --> 00:14:28.800
智能体模式还有一个

00:14:28.800 --> 00:14:30.300
容易被忽略的代价

00:14:30.533 --> 00:14:32.200
首次响应可能变慢

00:14:32.500 --> 00:14:33.900
5分钟以内的短片

00:14:33.900 --> 00:14:35.300
如果强调速度

00:14:35.566 --> 00:14:37.500
静态模式通常更合适

00:14:37.666 --> 00:14:40.533
智能体要先规划和调用内部工具

00:14:40.700 --> 00:14:43.400
等待片段返回后再生成答案

00:14:43.700 --> 00:14:45.533
它少处理了整体内容

00:14:45.600 --> 00:14:47.700
却增加了几轮内部操作

00:14:48.066 --> 00:14:50.333
成本和准确率以及首字

00:14:50.333 --> 00:14:52.366
延迟之间仍然需要取舍

00:14:52.666 --> 00:14:54.000
开发文档还保留了

00:14:54.000 --> 00:14:55.933
静态模式的自定义能力

00:14:56.066 --> 00:14:58.400
开发者可以指定视频起止时间

00:14:58.900 --> 00:15:00.533
也能设置固定帧率

00:15:00.800 --> 00:15:03.100
某些任务已经知道目标区间

00:15:03.100 --> 00:15:06.000
直接切片比让模型自行寻找更快

00:15:06.166 --> 00:15:08.766
逐帧检查法规要求完整覆盖

00:15:08.766 --> 00:15:10.866
或需要确定性处理的流程

00:15:11.166 --> 00:15:13.466
也不适合完全交给动态导航

00:15:13.600 --> 00:15:15.400
新功能扩充了工具箱

00:15:15.500 --> 00:15:17.200
没有让旧方法失效

00:15:17.333 --> 00:15:19.766
多轮对话同样存在工程细节

00:15:20.400 --> 00:15:22.166
使用有状态模式时

00:15:22.300 --> 00:15:24.533
服务器可以保留视频上下文

00:15:24.866 --> 00:15:26.966
无状态模式需要开发者把

00:15:26.966 --> 00:15:29.500
Processing call与Processing result等

00:15:29.500 --> 00:15:31.300
步骤带入下一次请求

00:15:31.466 --> 00:15:33.800
遗漏这些步骤不会立刻报错

00:15:34.133 --> 00:15:36.933
却会丢失已经建立的视频上下文

00:15:37.066 --> 00:15:39.566
后续回答质量可能明显下降

00:15:39.766 --> 00:15:41.466
产品体验是否可靠

00:15:41.533 --> 00:15:43.366
很大程度取决于开发者

00:15:43.366 --> 00:15:45.066
有没有正确管理状态

00:15:45.533 --> 00:15:48.166
隐私问题也会随能力增强而扩大

00:15:48.300 --> 00:15:50.766
视频常常包含人脸和声音

00:15:50.766 --> 00:15:53.600
也可能包含屏幕内容与地理位置

00:15:53.766 --> 00:15:56.500
比普通文本更容易暴露身份

00:15:56.933 --> 00:15:59.900
企业上传会议录像或监控资料前

00:15:59.966 --> 00:16:02.666
要确认数据保留和地区合规

00:16:02.766 --> 00:16:04.600
也要确认访问权限

00:16:05.066 --> 00:16:07.900
API能否理解视频与组织是否

00:16:07.900 --> 00:16:11.133
有权处理视频是两件不同的事

00:16:11.466 --> 00:16:13.600
版权风险也需要单独处理

00:16:13.733 --> 00:16:16.466
系统可以定位并总结公开视频

00:16:16.866 --> 00:16:18.600
还能切割相关片段

00:16:18.733 --> 00:16:20.666
不代表开发者自动拥有

00:16:20.666 --> 00:16:22.533
重新发布内容的权利

00:16:22.700 --> 00:16:25.133
公开视频链接只是输入方式

00:16:25.733 --> 00:16:27.666
版权仍然属于权利人

00:16:28.166 --> 00:16:30.466
创作者使用第三方片段时

00:16:30.733 --> 00:16:33.366
需要加入实质性的评论和分析

00:16:33.666 --> 00:16:35.200
或提供教育价值

00:16:35.366 --> 00:16:36.866
并确认素材使用

00:16:36.866 --> 00:16:38.700
符合法律与平台规则

00:16:39.200 --> 00:16:41.500
技术把复制和剪辑变容易后

00:16:41.500 --> 00:16:43.366
原创判断反而更重要

00:16:43.666 --> 00:16:46.400
Youtube当前的创作者规则没有

00:16:46.400 --> 00:16:49.166
禁止使用AI协助选题与脚本

00:16:49.200 --> 00:16:51.200
或者生成标题和字幕

00:16:51.566 --> 00:16:54.500
平台重点审查批量生产和内容重复

00:16:54.566 --> 00:16:57.166
也会看频道是否缺少原创判断

00:16:57.300 --> 00:16:59.066
能否看出实质改造

00:16:59.200 --> 00:17:01.566
如果智能视频API只是把大量

00:17:01.566 --> 00:17:04.300
内容自动摘要后重新上传

00:17:04.300 --> 00:17:05.966
仍可能被认定为低

00:17:05.966 --> 00:17:08.100
价值或非原创内容

00:17:08.466 --> 00:17:11.166
加入清楚的判断并重新组织事实

00:17:11.300 --> 00:17:12.966
还要提供独立分析

00:17:12.966 --> 00:17:15.300
才形成可识别的创作贡献

00:17:15.466 --> 00:17:17.400
如果成片使用AI生成的

00:17:17.400 --> 00:17:19.533
逼真人物或真实地点

00:17:20.000 --> 00:17:22.500
也包括并未发生的现实事件

00:17:22.500 --> 00:17:24.166
还要按照Youtube要求

00:17:24.166 --> 00:17:26.000
进行合成内容披露

00:17:26.333 --> 00:17:29.366
单纯用AI整理材料和辅助写作

00:17:29.466 --> 00:17:30.900
或者生成标题

00:17:31.066 --> 00:17:32.466
通常不需要披露

00:17:32.700 --> 00:17:35.500
智能视频理解本身属于分析工具

00:17:35.966 --> 00:17:38.566
是否需要标签取决于最终画面和

00:17:38.566 --> 00:17:41.400
声音有没有以逼真方式改变现实

00:17:41.700 --> 00:17:43.800
模型主动选择观看范围

00:17:44.066 --> 00:17:45.966
还会引入一种新错误

00:17:46.166 --> 00:17:48.800
静态模式至少能确认所有按固定

00:17:48.800 --> 00:17:51.666
间隔抽取的画面都进入了上下文

00:17:52.300 --> 00:17:53.566
智能体模式可能在

00:17:53.566 --> 00:17:55.533
搜索阶段判断错方向

00:17:55.766 --> 00:17:57.733
关键片段从未被加载

00:17:57.966 --> 00:17:59.866
随后给出逻辑流畅但

00:17:59.866 --> 00:18:01.300
证据不完整的答案

00:18:01.533 --> 00:18:04.500
TOKEN减少和证据覆盖之间存在张力

00:18:04.733 --> 00:18:06.133
开发者要能够检查

00:18:06.133 --> 00:18:08.000
模型到底看了哪些片段

00:18:08.166 --> 00:18:10.600
还有一种错误来自跨模态冲突

00:18:11.133 --> 00:18:12.500
字幕写着一个数字

00:18:12.700 --> 00:18:14.866
演示文稿显示另一个数字

00:18:14.966 --> 00:18:16.900
讲者随后又口头修正

00:18:17.133 --> 00:18:20.000
模型必须判断哪一项代表最终结论

00:18:20.133 --> 00:18:21.700
如果它只加载转录

00:18:21.800 --> 00:18:23.500
可能漏掉屏幕修订

00:18:23.533 --> 00:18:24.566
只看画面

00:18:24.566 --> 00:18:27.500
又可能不知道讲者已经否定旧数据

00:18:27.666 --> 00:18:30.000
智能体的优势来自灵活选择

00:18:30.566 --> 00:18:32.333
可靠性却要求它在存在

00:18:32.333 --> 00:18:34.800
冲突时主动读取第二种证据

00:18:35.000 --> 00:18:37.333
开发者可以设置一条简单规则

00:18:37.800 --> 00:18:40.766
重要结论至少有两类信号互相核对

00:18:40.900 --> 00:18:43.966
涉及数字时同时检查语音和画面

00:18:44.300 --> 00:18:45.300
涉及动作时

00:18:45.300 --> 00:18:47.466
查看动作前后完整区间

00:18:47.800 --> 00:18:49.166
涉及人物表态时

00:18:49.166 --> 00:18:50.666
保留足够上下文

00:18:50.666 --> 00:18:52.066
避免截取半句话

00:18:52.066 --> 00:18:53.500
这样会增加TOKEN

00:18:53.600 --> 00:18:56.366
却能降低断章取义和局部误判

00:18:57.133 --> 00:18:59.533
效率最高的答案不一定是业务

00:18:59.533 --> 00:19:02.566
风险最低的答案Processing call和

00:19:02.566 --> 00:19:06.333
Processing result为可观测性提供了入口

00:19:06.600 --> 00:19:08.266
但目前这些步骤不等于

00:19:08.266 --> 00:19:09.933
一份完整的审计报告

00:19:10.166 --> 00:19:11.766
高风险系统还需要

00:19:11.766 --> 00:19:14.066
记录查询和加载区间

00:19:14.266 --> 00:19:18.000
以及采样参数模型版本与最终依据

00:19:18.533 --> 00:19:19.966
只有结果可追踪

00:19:20.266 --> 00:19:23.500
团队才能区分模型看错还是漏看

00:19:23.666 --> 00:19:25.600
或者素材本身不清楚

00:19:25.966 --> 00:19:27.100
没有这层记录

00:19:27.266 --> 00:19:30.300
动态导航发生错误时会更难复盘

00:19:30.500 --> 00:19:32.200
谷歌这次更新代表多

00:19:32.200 --> 00:19:34.366
模态AI进入新的阶段

00:19:34.566 --> 00:19:37.266
早期模型解决能不能读懂一张图

00:19:37.600 --> 00:19:40.166
后来解决能不能接收一整段视频

00:19:40.300 --> 00:19:42.766
现在的问题变成能不能

00:19:42.766 --> 00:19:45.000
围绕目标管理自己的注意力

00:19:45.333 --> 00:19:47.366
视频长度继续增长之后

00:19:47.500 --> 00:19:49.166
知道哪一秒值得消耗

00:19:49.166 --> 00:19:51.800
更多算力会成为稀缺能力

00:19:51.966 --> 00:19:54.933
把所有内容塞进上下文只是基础

00:19:55.066 --> 00:19:56.933
这种注意力分配会影响

00:19:56.933 --> 00:19:58.933
模型架构和产品设计

00:19:59.766 --> 00:20:02.000
未来的视频应用可能先由便宜

00:20:02.000 --> 00:20:04.733
模型扫描字幕和低分辨率画面

00:20:04.800 --> 00:20:07.700
再调用更强模型检查少数片段

00:20:07.800 --> 00:20:10.133
不同工具负责检索和重采样

00:20:10.300 --> 00:20:11.966
以及识别验证

00:20:12.466 --> 00:20:14.666
最终由一个智能体组织流程

00:20:14.966 --> 00:20:16.566
用户只提出问题

00:20:16.700 --> 00:20:19.500
后台根据证据难度决定花多少钱

00:20:19.666 --> 00:20:22.300
模型公司也会从出售上下文

00:20:22.300 --> 00:20:25.066
窗口转向出售解决问题的路径

00:20:25.533 --> 00:20:28.100
过去大上下文越长越容易宣传

00:20:28.333 --> 00:20:31.200
开发者却要为大量无关输入付费

00:20:31.333 --> 00:20:33.100
动态视频理解显示

00:20:33.366 --> 00:20:34.966
窗口足够大之后

00:20:34.966 --> 00:20:37.266
下一轮竞争会转向检索

00:20:37.266 --> 00:20:39.866
效率工具调用和证据选择

00:20:40.200 --> 00:20:41.766
读的少还能答的准

00:20:41.866 --> 00:20:44.300
比单纯读的多更有商业价值

00:20:44.533 --> 00:20:46.600
云计算市场也会受到影响

00:20:46.766 --> 00:20:48.800
企业过去先用专门服务

00:20:48.800 --> 00:20:50.866
完成转录和视觉识别

00:20:50.900 --> 00:20:52.300
再做内容检索

00:20:52.466 --> 00:20:55.133
最后把结构化结果交给大模型

00:20:55.566 --> 00:20:58.133
Gemini把这些步骤合在一次交互中

00:20:58.333 --> 00:20:59.733
开发门槛下降

00:20:59.766 --> 00:21:02.000
调用也更集中到Google体系

00:21:02.266 --> 00:21:04.300
独立工具不会马上消失

00:21:04.566 --> 00:21:07.333
它们需要在行业精度和私有部署

00:21:07.533 --> 00:21:10.333
以及可审计性上证明自身价值

00:21:10.766 --> 00:21:12.733
API有时真正面对的竞争

00:21:12.733 --> 00:21:14.533
来自人工快进播放令

00:21:14.900 --> 00:21:16.966
一加模型反倒排在后面

00:21:17.066 --> 00:21:18.900
一个分析员花40分钟

00:21:18.900 --> 00:21:20.400
浏览两小时录像

00:21:20.400 --> 00:21:22.466
如果模型调用费用更高

00:21:22.466 --> 00:21:24.000
结果还要从头复核

00:21:24.200 --> 00:21:26.133
自动化就没有经济价值

00:21:26.300 --> 00:21:29.700
智能体模式要证明的是它能把人类

00:21:29.700 --> 00:21:32.566
复核压缩到几个带时间戳的片段

00:21:33.066 --> 00:21:35.466
并且总成本低于人工初筛

00:21:35.766 --> 00:21:37.666
这个标准比榜单提高

00:21:37.666 --> 00:21:39.333
几个百分点更严格

00:21:39.533 --> 00:21:42.333
Google给出的最高88%TOKEN

00:21:42.333 --> 00:21:44.933
节省和7%质量提升

00:21:45.100 --> 00:21:46.766
正好体现这条路线

00:21:47.066 --> 00:21:49.266
他们目前仍是厂商测试数字

00:21:49.533 --> 00:21:51.000
需要第三方在不同

00:21:51.000 --> 00:21:52.733
语言和不同画质下

00:21:52.766 --> 00:21:54.366
再按任务类型复现

00:21:54.600 --> 00:21:57.333
特别是字幕缺失和多人重叠说话

00:21:57.666 --> 00:21:58.800
再加上镜头快速

00:21:58.800 --> 00:22:00.733
切换与专业术语密集

00:22:01.000 --> 00:22:03.733
效果可能与标准测试相差很大

00:22:03.800 --> 00:22:06.200
判断这项API是否真正成功

00:22:06.200 --> 00:22:07.666
可以看三个指标

00:22:07.933 --> 00:22:09.566
第一个是长视频成本

00:22:09.566 --> 00:22:11.700
能否随着问题范围缩小

00:22:12.066 --> 00:22:14.766
而不是随着总时长线性上涨

00:22:14.866 --> 00:22:17.866
第二个是模型遗漏关键片段的概率

00:22:18.100 --> 00:22:20.366
不能只看最终平均准确率

00:22:20.466 --> 00:22:21.966
第三个是证据能否

00:22:21.966 --> 00:22:23.600
回到清楚的时间戳

00:22:24.100 --> 00:22:25.766
让用户快速核对

00:22:25.900 --> 00:22:27.800
只要这三点同时成立

00:22:28.066 --> 00:22:29.900
视频才会从难以利用的

00:22:29.900 --> 00:22:31.966
文件变成可靠的数据源

00:22:32.133 --> 00:22:33.333
对创作者而言

00:22:33.333 --> 00:22:35.600
最先落地的机会可能很朴素

00:22:35.733 --> 00:22:37.000
找素材更快

00:22:37.066 --> 00:22:38.100
切片更准

00:22:38.333 --> 00:22:40.000
核对事实也更容易

00:22:40.266 --> 00:22:41.266
对企业而言

00:22:41.500 --> 00:22:42.933
它可以减少人工浏览

00:22:42.933 --> 00:22:44.700
数小时录像的时间

00:22:44.733 --> 00:22:45.933
对Google而言

00:22:46.266 --> 00:22:47.300
意义更大

00:22:47.366 --> 00:22:49.766
Gemini终于能用一种成本可控

00:22:49.766 --> 00:22:52.666
的方式深入Youtube和企业视频

00:22:52.733 --> 00:22:54.900
让模型和云平台再与

00:22:54.900 --> 00:22:56.600
内容入口连接起来

00:22:56.866 --> 00:22:58.300
这场变化不会让人类

00:22:58.300 --> 00:23:00.566
编辑和分析人员立刻消失

00:23:00.766 --> 00:23:02.566
机器负责缩小范围

00:23:02.700 --> 00:23:04.933
人负责判断语境和版权

00:23:05.000 --> 00:23:06.800
也负责因果与表达

00:23:07.133 --> 00:23:08.800
模型越擅长寻找片段

00:23:08.966 --> 00:23:10.366
人类越应该把时间

00:23:10.366 --> 00:23:12.000
放在它不擅长的部分

00:23:12.133 --> 00:23:14.566
比如判断一句话是否断章取义

00:23:14.700 --> 00:23:16.900
一个画面是否具有代表性

00:23:17.000 --> 00:23:19.366
以及某个统计结果能不能推广

00:23:19.666 --> 00:23:21.766
谷歌发布了一项视频API

00:23:22.066 --> 00:23:25.200
底层改变的是AI获取信息的方法

00:23:25.300 --> 00:23:26.666
过去它被动接收

00:23:26.666 --> 00:23:28.566
开发者准备好的上下文

00:23:28.933 --> 00:23:30.600
现在它会自己搜索

00:23:30.666 --> 00:23:32.866
回看并改变采样策略

00:23:33.000 --> 00:23:35.600
模型开始管理自己的注意力以后

00:23:35.600 --> 00:23:37.400
视频理解的上限不再

00:23:37.400 --> 00:23:39.466
只由上下文长度决定

00:23:39.566 --> 00:23:42.133
也由它寻找证据的能力决定

00:23:42.266 --> 00:23:45.100
下一阶段的竞争会围绕谁能用

00:23:45.100 --> 00:23:47.600
更少TOKEN找到更关键的几秒

00:23:47.966 --> 00:23:50.933
谁能把答案绑定到可核查的画面

00:23:51.133 --> 00:23:53.166
谁又能在隐私和版权

00:23:53.166 --> 00:23:55.066
边界内处理海量内容

00:23:55.366 --> 00:23:57.266
Gemini的智能视频理解

00:23:57.266 --> 00:23:58.800
已经迈出第一步

00:23:58.900 --> 00:24:01.133
最高节省数字可以继续验证

00:24:01.266 --> 00:24:02.900
但方向已经很明确

00:24:03.333 --> 00:24:05.500
AI不需要看完整段内容

00:24:05.600 --> 00:24:07.666
才有可能真正看懂问题