双子座智能视频模式：架构设计与时标偏差问题
在中国题材电影上对Gemini的代理模式与静态视频模式进行的测试：模式设计如何影响时间戳的准确性、偏差、引用内容以及时间范围。
来源: Unlocking Gemini's Agentic Video Mode: Schema Design, Timestamp Drift, and Jay Chou's Secret
谷歌最近为 Gemini 推出了“智能体”视频理解功能，这为使用一个极具挑战性的测试案例进行实际实验提供了绝佳借口——那就是周杰伦于2007年拍摄的中文长片《秘密》。这些实验主要围绕一个问题展开：如果你让模型找出视频中关键情节出现的时刻，其时间戳的准确性如何？而输出格式的设计又会如何影响结果？
你需要一个 GOOGLE_API_KEY，AI Studio 提供了不错的免费套餐。相关设置细节见文末附录。
为何选择中文电影作为测试对象
这个想法最初源于一种学习工具，旨在帮助学生完成指定学习内容，不过好奇的成年人通过遇到未知的难题也能从中受益。在发现 Gemini Flash Lite 型号既能总结中文内容又能用中文回复后，将应用范围从教育扩展到娱乐便显得顺理成章。电影是个绝佳的选择，因为它是一部以钢琴音乐为特色的浪漫剧情片，配有令人难忘的配乐，而且女主角能够很好地诠释那些安静的时刻。
有剧透警告：以下内容会揭示影片的核心秘密。测试所用的视频来源是一段YouTube上的电影分析视频，它讲述了大约16:23之前的剧情，之后旁白开始分析剧情是如何受到周杰仔个人生活的启发的。尽管如此，这部电影依然值得观看，其音乐和女主角细腻的表情都很出色，Bilibili上至少有两个版本。
让这项测试真正具有难度的是语言问题。与英语视频相比，中文的自动字幕生成覆盖率要低得多，因此模型从一开始就处于不利地位，必须在没有这些辅助工具的情况下展现自身的能力。虽然不需要懂中文就能理解内容，但了解中文有助于更好地理解输出结果。
为何时间戳偏差很重要
无论是在学习还是娱乐场景中，人们都有一个共同的需求，那就是对时间戳进行本地化处理：能够直接跳转到关键时刻。学生这样做是为了重新查看某个概念的解释，而观众则希望找到隐藏内容并重温精彩的叙事。
在 Gemini 的音频转录功能中出现的渐进式时间戳偏差问题已在谷歌开发者论坛上被广泛报道。一种可靠的解决办法是使用较旧的非大语言模型，但这显然不是什么有趣的实验，因此人们期望代理模式能够表现得更好。
简而言之：它仍然会出现偏差。大约95%的情况下，误差都在1秒以内，但有些数据点的偏差会达到10到20秒。有趣的是，这些偏差总是集中在少数几个位置，这种程度对于日常使用来说已经足够好，不会让人感到困扰。如果能有带时间标记的文本记录，开发者还可以通过在该时间窗口内进行字符串匹配来过滤掉有问题的时间戳。
架构设计优于提示词设计
大语言模型的架构通常用JSON Schema来编写。Python中的Pydantic或TypeScript中的Zod等库允许你在应用层面定义这些架构，并在将其注入提示词之前自动转换为JSON Schema。仅从变量名和类型就能大致预测模型会输出什么结果。
实验者的观点很直接：提示工程之所以如此受追捧，而真正决定性能的却是模式工程，这实在奇怪。模式几乎编码了模型的全部行为。即便使用普通的提示，模型也能通过字段结构和名称推断出你的需求；而如果模式设计糟糕，就只能靠自己，寄希望于一个出色的提示来挽救局面。
这与数据工程中的数据建模有相似之处，不同之处在于大语言模型的输出模式更类似于 MongoDB 等 NoSQL 数据库的设计，而非 Postgres 等关系型数据库的设计。一个值得注意的决策是关于递归结构：它们可以被编码为扁平的、自引用的表格，通过 child_id 和 parent_id 实现无限级关联。不同服务提供商对于是否允许使用递归 JSON Schema 的态度各异，因此你可能不得不接受这样的选择。
阅读架构
与数据建模一样，基数也很重要。一部电影包含许多概念，这些概念以数组形式呈现。在教育领域，一个主题会有先决条件、应用场景、扩展内容、假设以及局限性。在电影中，则有情节发展、角色塑造、高潮以及结局。
一个概念对应多个时间戳。在教学过程中，这体现在引入多个概念后通过比较来培养高阶思维能力。在电影中，则表现为导演使用倒叙或打乱叙事顺序。
时间戳条目包含若干属性：
seconds用于标明该时刻出现的位置。description用于解释相关文字的含义，这有助于理解笑话或重新解读剧本。
quote是通过语音转文字功能逐字提取的脚本片段。visual用于标识该时刻是否可以可视化呈现。visualDescription是该时刻屏幕上内容的文字描述。此外还有检查点，每个检查点都包含conceptLabel、question和answer。在教育领域中，它们用于检测学习者的理解程度；在娱乐领域中，则能促使观众思考初次观看时忽略的内容，或从不同角度重新审视相关事件。该模型十分巧妙，能够将完全相同的文本同时用于conceptLabel以及concepts下的对应label，这是其内部一致性的一种细微但重要的体现。
哪些内容发生了变化
典型的运行时间约为20秒。有些测试在9秒内就完成了，可能是由于谷歌缓存了提示语并重复使用了结果。而在更改提示语后进行的测试则耗时50秒，那应该是还没有缓存存在的时候。
处理模式方面，智能模式与静态模式单独来看差异不大，两种模式下的大多数时间戳都在1秒以内。智能模式下的测试有时耗时会是原来的两倍（约40秒），有时则更短。脚本运行时间确实会影响质量：运行时间越长，每个概念对应的时间戳就越多，生成的描述和引文也会更长。
提示词中要求为每个概念标签找到至少三个时间戳。如果没有这一要求，模型通常每个概念只能找到一个时间戳；而加上这一要求后，时间戳的准确性似乎略有提升，目前的假设是提高搜索密度会对精确度产生一定影响。数值“三”可以尝试调整，看看会有什么不同结果。
附加请求要求模型找出某句特定中文台词出现的时刻，即电影的高潮部分——那时一个巨大的铁球朝主角飞来。这迫使模型需要将音频与精确的短语进行匹配，并确定该短语出现的时间。
第一轮：静态志愿者添加额外字段，智能体则省略这些字段
在首次尝试中，静态模式往往会添加模式规范中从未要求过的visual和visualDescription键。其添加方式并不一致，同一次处理中有时会为某些时间戳添加这些键，而为其他时间戳则省略。由于可以通过生成的字幕搜索关键时刻，visualDescription对于无障碍访问和填充搜索数据库非常有用，而且在所有测试案例中都保持准确。
只有quote键能始终以中文形式呈现。其他所有键则可能在不同运行中以中文或英文翻译出现，且无法预测。无论采用代理模式还是静态模式，时间戳在各个概念内部及相互之间都保持有序，这使得人工验证十分方便。
代理模式生成的引用时间更长，这一特征在第二次尝试时再次出现。同时，也有一个反复出现的场景首次出现：代理模式将某个时刻标记为10:41，但实际上视频中的该时刻是10:50。如果该输出中包含visualDescription，就能显示模型实际查看的是10:41还是10:50。
静态运行模式下某条记录的description仅重复了其标签内容（“时间旅行机制”），几乎没有提供额外信息，不过后续运行则显示出更有意义的差异。从积极的一面来看，静态模式在visualDescription中很好地识别出了旧钢琴书以及女主角闭眼的动作，甚至还正确辨认出了角色。而代理模式则完全忽略了那些可选的视觉描述信息。
第二次运行：静态模式准确识别出10:50的时刻
Static再次添加了可选的视觉按键，而agentic则没有。尽管第一次由agentic处理的尝试使用了正确的文本，Static仍准确找出了其错误标注的10:50这一时刻。Static将该时刻的visualDescription标记为“闪回场景”，这引发了一个问题：Gemini是如何判断这是闪回而非当前时间线的？
在两种模式下，每个标签内的时间戳都保持有序。在不同标签之间，Static将叙述者的分析内容依次呈现，而agentic则穿插着10:41、17:00、15:00和17:51等时间点。
Static在16:31给出的第一条评论使用了与屏幕上相同的中文书名号，这表明该模型是通过图像而非仅依赖音频来生成内容的。与之前一样，Static的评论仍保持较短长度。而Agentic的评论则被拉长，中间以省略号截断；它在15:00给出的评论实际上涵盖了15:01到15:38的时间段，17:51的评论则涵盖了17:54到19:56的时间段。
最后一个时间段尤为引人注目，因为17:54到19:56正好涵盖了这部电影四种结局的完整描述。这引发了一个问题：如果提示词同时要求提供结局的时间戳会怎样？这个疑问促使我们进行了下一次架构调整。
第三次测试：添加时间范围
原本`seconds`字段是字符串类型，因此需要重新设计。有两种方案可选，第一种是使用数组：
"seconds": {
"type": "array",
"description": "The start and end time range in HH:MM:SS or ISO format, structured as [start_time, end_time].",
"prefixItems": [
{
"type": "string",
"description": "Start time (e.g., '00:01:15' or ISO 8601 string)"
},
{
"type": "string",
"description": "End time (e.g., '00:02:30' or ISO 8601 string)"
}
],
"minItems": 2,
"maxItems": 2
}
第二个是一个对象：
"seconds": {
"type": "object",
"properties": {
"start_time": {"type": "string"},
"end_time": {"type": "string"}
},
"required": ["start_time", "end_time"]
}
该数组使用的标记更少，但需要繁琐的最小值和最大值限制来避免起始-结束逻辑出错，因此被用于下面的实验中。对象形式的键更清晰，但代码稍显复杂，不过它可以容纳额外的键，所以在实验之外是更推荐的选择。
引用内容不仅仅是音频
在代理模式下，其中一个时间范围是6:20到6:42，但实际上引用内容是从6:30开始的。description从6:20开始逐字对应音频内容，共八个词，之后才转为自己的释义。这就好像引用任务被分给了quote和description两者来完成。
在另一个时间区间8:13至9:00内，引语（大致为“目光对视”）始于8:21，而描述部分则写着“再次出现”，女主角确实在8:13左右出现。这表明时间区间的确定并非仅由音频决定。该引语在8:55结束，比时间区间结束早了5秒，且没有明显原因。
这意味着在解析视频时，音频应与屏幕内容紧密对应，否则时间戳定位就会出错。然而，目前并没有明显的机制来控制多模态模型在生成时间戳时会更侧重哪种模态的信息。这是一个真正的研究机会，通过更严格的对照实验（完整音视频对比、视频被遮蔽对比、视频音量被调低对比）可以明确这一问题。
两种新的故障模式
该重复场景的第三次测试又暴露出了新的问题。在静态模式下，14:49至15:02这段时间内出现的引文实际上来自10:49，出现了四分钟的误差。这与第二次测试中静态模式准确捕捉到的10:50时刻相同，而第一次测试中的智能模式却错误地将其标记为10:41。
也就是说，同一个真实时刻在两个不同架构版本中经过三次测试，第一次误差为九秒，第二次准确，第三次又出现四分钟的误差。如果这种偏差只是由于该场景本身难度过高所致，那么应该始终出现同样的错误，而不应是先出错、后正确、再更严重地出错。
第二个问题是：15:07至15:17这段时间内本应出现的静态引文（大致内容为“他会找到小雨”）在音频中根本不存在。模型似乎是自行进行了总结，而非进行转录。
静态模式在“大海捞针”测试中胜出
为判断是否能找到特定的引文，测试中加入了铁球撞击的节点作为参考。在采用时间范围筛选机制之前，“静态模型”找到的时间是15:22，而“智能模型”找到的时间是15:00。采用该机制后，“静态模型”准确找到了15:21这一时刻，甚至还延伸到了15:26，即铁球撞击建筑物、噪音消失的瞬间。“智能模型”的表现则较差，其找到的时间范围为15:00至15:37，范围宽得太多。在实际应用中，哪怕只有三秒的误差也会考验观众的耐心。
测试结果的意义
“静态模型”更擅长定位具体时刻，而“智能模型”更擅长总结在较长时间跨度内发生的事件。合理的结论并非非要选出优胜者，而应根据任务类型和内容长度来选择：对于需要精确检索或片段较短、成本差异无关紧要的场景，可使用“静态模型”；而对于像90分钟讲座这样的长内容，其令牌节省优势开始显现，此时则适合使用“智能模型”进行整合。
从时间戳切换到时间范围并未改变起始点，从搜索实验来看如此，因此最好同时获取结束时间，这能为应用程序的用户体验设计提供更多空间。这就好比在搜索系统中使用向量嵌入技术，但实际上并未嵌入任何内容。
如引文分离模式所示，时间范围可能受多种信息类型的影响，甚至在文本内部也会受到多个关键因素的制约。或许应该简化数据结构，避免模型产生混淆，或者明确说明派生字段与关联字段之间的关系，例如规定description必须基于quote生成，或是明确概念之间是相互独立的还是需要体现因果关系。
还有另一种模式值得提及。当用户请求指定时间范围后，静态生成工具便完全停止输出visual和visualDescription。一种假设是模型在处理请求时会专注于必填字段，从而忽略可选字段。将它们设为必填项或许能解决这个问题，但可能会影响其他方面的质量，因为用于处理这些字段的算力会相应减少。这类似于某些幻灯片生成工具：有时能一次生成高质量的幻灯片，而下次却退化为简单的火柴人风格设计，仿佛需要休息一样。
未来的发展方向
语言学习。在某些未公开的实验中，即便没有明确要求，让工具在同一行中同时显示英文和中文内容也是可行的。
视频制作。时间戳和时间范围能让ffmpeg等后续工具进行剪辑，确保核心内容首先呈现。在这一点上，大型语言模型存在信息损失，因此若要保留所有内容仅去除停顿填充音，使用Descript这类更专业的文字转录工具，或是谷歌最新的Gemini转录模型，会更为合适。
精准本地化能实现的功能：
- 直接跳转至特定片段。时间戳可作为定位锚点，将线性视频转化为可索引、可搜索的资源，从而取代手动拖动播放的功能。
- 自动生成精彩片段集。由于无需手动搜索即可找到特定片段，创作者可以整合多段视频中的场景，教育工作者则可以制作带有时间戳的互动课程。
既要考虑节点，也要考虑边
在当前的设计中，大部分信息都被密集地存储在节点中。如何对边进行建模以进一步提升用户体验？是否应该将部分信息从节点转移到边上，或者是否存在超越节点与边构成的图结构的其他知识表示方式？《像博学者一样学习》一书中的技巧或许可以应用：整体与部分、因果关系、事物与功能、问题与解决方案、事实与观点以及示例与类别。大型语言模型很可能已经能够生成这类类比，关键在于在恰当的时机提出恰当的问题，并以正确的方式呈现结果。
已有一款纯文本学习应用提供了类似功能，它能在对话过程中实时构建概念图。在该应用中，智能体会自行生成连接线。先询问关于唱歌的内容，稍后再询问声乐技巧，智能体无需被告知二者之间的关系，就能将它们聚类为相互关联的节点，同时通过颜色编码来标识主题、抽象概念、关联项和细节，这些颜色即作为连接线的信息。该架构中的checkpoints属性也有类似的实时功能，能够标记出对话中尚未解决的问题及可能的误解，而在对方表现出理解之后这些问题便会得到解决。
待进行的实验
这些实验具体到足以让任何人尝试，并且能揭示相应的结果。
模态冲突的消除方法。用四种方式播放同一视频：完整音频、视频加字幕；仅音频和视频且无字幕（包括已嵌入画面中的字幕）；仅音频的黑色视频；以及仅视觉内容的静音视频。如果仅音频版本中的偏差消失了，那就说明声音起主导作用，而嵌入的字幕干扰了结果。如果仅音频版本仍有偏差，但仅视觉版本则没有，那就更有证据表明时间戳确实是多模态的，而非仅仅是带有视觉噪声的音频。
缓存与温度对结果可重复性的影响。将提示词缓存与温度设置为零是否能在每次运行中产生完全相同的输出？如果温度为零时漂移现象消失，模型就会对某个时刻的位置保持一个稳定（尽管可能不完美）的认知，而不同运行之间的差异主要源于采样噪声。如果温度为零时漂移仍然存在，那就意味着该时刻根本不存在稳定的内部时间戳。
漂移是随内容变化还是位置变化？如果漂移取决于该时刻本身的特征，比如快速切换、互相打断的对话或渐强的音乐，那么无论该时刻出现在何处，这种问题都是与内容相关的、不受翻译影响的故障。如果在较长的视频中这种情况愈发严重，那可能是其他原因造成的，或许与“中间内容丢失”有关，即大语言模型在处理埋藏在上下文中间信息时的性能下降。
跨模式段记录关联。模型能否识别出在不同调用中生成或被较长上下文隔开的两个概念标签实际上指的是同一个现实世界概念？这就是经典的记录关联或实体解析问题，当其在同一轮处理中发生时则接近于共指解析问题。此前曾有过成功案例，即模型对conceptLabel和label使用了完全相同的文本，但尚未解决的问题是这种一致性能否在独立调用之间保持。
跨语言对齐。衡量Gemini在保持时间准确性的同时，将中文口语转换为英文模式字段的忠实度。
要测量，而非凭目测判断。 若能列出一份简短的表格，注明六次测试中各时间点的检测结果、中位数偏差、在一秒内的百分比范围以及最严重的异常值，就能将这些观察结果从“被注意到”提升为“已被测量”，而且所需的原始数据早已存在。
测试所需的visualDescription是否真的能提升质量。随着架构变得愈发复杂，该模型似乎开始舍弃一些可选的字段。
讲座、影片与记忆
讲座和电影对观众的诉求各不相同。讲座需要观众的注意力，而电影则需要观众的情感投入。故事中的角色并非像教科书中的概念那样是已解决的难题，而是被塑造得如同真实的人，其动机具有多种解读空间。通常不存在标准答案或简单的解决方案，只有各种权衡，以及从令人遗憾的处境中尽力挽救些许东西的努力，这些经历能带来超越特定主题的人生教训。
神经学家奥利弗·萨克斯曾描述过一位名叫克莱夫·韦林的病人，由于失忆症，他无法记住超过几秒钟的记忆，唯有音乐除外——他对音乐仍能完整地演奏、阅读和回忆。萨克斯这样描述：音乐的力量总会在人们毫无防备时悄然出现，如同一种赐予的恩惠。
这差不多就是大型语言模型未来可能为我们带来的作用：虽无法替代记忆功能，但能弥补我们现有记忆的缺陷，让我们重温那些重要的时刻，并在我们感到困惑或压力过大时将它们重新整理成条理清晰的脉络。
这种互动可能是双向的。我们可以通过优化框架来更好地发挥大型语言模型的优势，而大型语言模型则能重塑我们的世界观与能力，帮助我们更批判性地思考问题，同时通过理解角色的行为动机、探索各种可能性以及学习如何讲述精彩的故事来培养同理心与社交技能。这部电影的主角可以说有四种可能的结局，而大型语言模型同样可以为我们提供多种知识选择，让我们能够加速、减速、倒回时间并选择不同的发展路径。
一个相关的方向是研究能够与你一同观看讲座、应要求暂停，并基于暂停的准确时刻给出回答的智能代理。这正是此处所测试的同一时间戳定位问题，只不过是实时的且难度更大。如果在已完成的受控视频中，智能代理模式仍会存在数分钟的偏差，那么直播版本将面临更为严峻的同类问题。这些实验只是该理念的初步探索，并非对已发布产品的描述。
附录：实验设置与复现方法
从 AI Studio 获取 GOOGLE_API_KEY，然后在终端中导出它：
export GOOGLE_API_KEY=<your key>
为避免每次终端重启后都自动导出，可将该密钥放入 .env 文件中，并在脚本中添加以下内容：
from dotenv import load_dotenv
load_dotenv()
API使用中的困扰
不熟悉client.models.generate_content()是问题之一，而谷歌的产品介绍页面展示的是使用较新的Interactions API（client.interactions.create()）的代码，这让人以为旧的generate_content API不支持智能视频功能，直到文档中明确指出它确实支持。此外，也不清楚是否可以指定某些参数，比如思考总结内容，以及该如何指定。更麻烦的是，2026年5月Interactions API还发生了破坏性变更，再加上Gemini自身网页聊天的循环回复，使得入门过程耗费了数小时的尝试。
空的思考总结
不清楚是解析代码有误还是任务本身过于简单，但根本没有任何思考总结内容：用于存储思考结果的文件始终显示为空列表。