📄 Omni-Life：日常实时助手何时该说话、何时该沉默
英文题目：Omni-Life: Benchmarking Omnimodal Real-Time AI Assistants in People’s Daily Lives
评分：6.1/10 | 创新 1.3/2 | 技术严谨 1/1.5 | 实验充分 1.2/1.5 | 清晰度 0.8/1 | 影响力 0.5/1.5 | 开源 0/1.5 | 可复现 0.3/0.5 | 工程/实践 1/1.5
👥 作者与机构
- Mengze Hong：机构信息未能在本次解析中与作者逐人可靠绑定
- Ziwei Shang：机构信息未能在本次解析中与作者逐人可靠绑定
- Di Liang：机构信息未能在本次解析中与作者逐人可靠绑定
- Zijian Li：机构信息未能在本次解析中与作者逐人可靠绑定
- Liang Zhu：机构信息未能在本次解析中与作者逐人可靠绑定
- Hongyu Shan：机构信息未能在本次解析中与作者逐人可靠绑定
- Robin Zhou：机构信息未能在本次解析中与作者逐人可靠绑定
- Minlong Peng：机构信息未能在本次解析中与作者逐人可靠绑定
- Zhiqiang Kou：机构信息未能在本次解析中与作者逐人可靠绑定
- Jia Wang：机构信息未能在本次解析中与作者逐人可靠绑定
- Di Jiang：机构信息未能在本次解析中与作者逐人可靠绑定
- Chen Jason Zhang：机构信息未能在本次解析中与作者逐人可靠绑定
📌 核心摘要
日常实时助手面对连续视听流，输入为站在固定或移动设备视角的视频与环境声加一条常驻任务说明，输出为是否在当前时刻发声以及发声内容，难点是干预条件散落在时间中且多数时间要求保持静默。论文先把求助需要整理为感知、认知、行动、交流相关四类，再为每个生活场景指定判断依据与五种期望行为，依据是否可从画面证据得出决定标注干预或静默。随后用受控合成复现危险与边界情形并配对改变关键条件，用真实视频补充自然变化，两类来源共用同一时间标注协议。流式评测要求模型边看边决定开口时机，问答评测则在给定截断点考查内容与时机选择，两者分离知道答案与持续履职的差距。相对只测流式问答或原子交互能力的已有基准，关键差异是把人群、场景、设备与时间窗口绑在一起，并把完全静默视频作为必测项。与12组主流实时全模态配置比较，在400个视频流式评测的290个需干预视频上，流式评测指标Full Correct方面MOSS-VL为4.48%，高于Gemini 3.8 Live的3.79%。结论只适用于所收录的任务分布与标注窗口，合成显性事件、单次短时评测与客户端接收时间计量都限制向长期部署的推广。原文未披露训练、推理或部署成本。
🔗 开源与复现资源
第三方资源：https://github.com/todayai-labs/omni-life — 暂时无法访问
第三方资源：https://seed.bytedance.com/en/models — 暂时无法访问
第三方资源：https://deepmind.google/models/model-cards/gemini-3-8-audio — 暂时无法访问
可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
助手要解决的是什么日常问题
这篇论文关心的不是看懂视频，而是持续陪伴中的助手该不该开口。输入是一段连续的音视频流加一个常驻任务，比如帮小学生盯作业、提醒盲人避障、看护婴儿。输出不是一次回答，而是在整个时间线上决定每个时刻说不说、说什么。必须保留的信息包括当前画面和声音、任务要求、以及之前发生过什么；丢掉时间就会把短暂看手机当成持续分心，或把已有人处理的危险再报一遍。
下面这张示意图把 3 种典型情况并排展示，帮你先建立何时干预、何时沉默的直觉，之后再看基准如何把这种直觉变成可打分的标注。
看图路径： 1. 先看三行各自的用户需求和右上角的行为要求；2. 再对比中间帧的变化与底部灰虚线上的干预点；3. 注意第三行照料者在场时为何要求保持沉默
论文图 1。原论文 Figure 1:：“Illustration of real-life use cases for omnimodal real-time AI assistants.”。
图中有三行：第一行孩子从写作业到短暂看手机再到持续分心，只有最后一段才需要纠正；第二行盲人拄杖接近水坑，在危险可见窗口内要告警；第三行婴儿身边已有照料者行动，全程要求沉默。它说明同样是看到人、手机或水坑，能否开口取决于任务、对象状态和时机，而不是看到就说。
已有评测为什么还不够
此前的流式评测多考查看视频答题、时间戳推理或打断处理，视频多来自网上剪辑，任务是预设的观察题。另一类应用评测看的是办公软件操作或智能家居执行，属于回合制输入输出。它们都缺少日常陪伴的关键维度：在哪里发生、为谁服务、设备能看到什么、何时帮才有用。
Omni-Life 把两者拼起来：既保留主动回应和时间窗打分，也引入真实服务场景、人群和设备视角。论文用一张对比表说明只有它同时覆盖主动回应、回应时机、用户群体、危险告警和纯沉默视频。已有工作要么没有人群区分，要么没有全程沉默的对照，因此无法发现多说打扰与少说漏助之间的权衡。
为什么及时又克制的帮助很难
实时助手的失败不只是认错物体。第一是该说时没说或说晚了，错过避险窗口；第二是不该说时说了，打断学习或休息；第三是说了但内容不对，比如把保温杯认成吉他，或把已完成的动作说成未完成。更隐蔽的是说了相关的话却没完成任务，例如只说客人已招呼却没有真的招呼请坐。
这些失败都和时间耦合：早 1 秒是打扰，晚 1 秒是失职。模型必须在流变化中持续判断事件是否成立、条件是否还有效、之前是否已处理过。单点答对不能保证整段可靠，这正是论文要同时测覆盖、内容、时机和沉默的原因。
论文如何把需求变成可测任务
论文把期望行为写成人群、场景、设备的函数，场景描述发生什么，人群说明为谁，设备决定能观察到什么视角和证据。组织上先分感知、认知、行动、沟通四大支持类别，再细化到具体支持需求和生活场景，例如从行动支持落到浴室防滑、从感知支持落到识别手中物体。
\[f:(P,S,D)\rightarrow A,\]这个式子不是神经网络，而是一种任务定义：给定人群 P、场景 S、设备 D，输出应有的助手行为 A。它强调同一人群在不同情境下需要不同行为，视障用户有时需要播报、有时需要答疑、有时需要告警、有时需要沉默。构建时先过滤人群、行为、视角不兼容的组合，再展开成可拍摄的规格，避免把场景类别直接当成允许说话的理由。
从机制分工看，左栏把支持类别、支持需求、生活场景逐层收敛，并结合人群×场景×设备与可观察证据推导出期望行为，区分 warn、inform、feedback、answer 与 wait；中栏把同一规格分流为合成与真实两路，合成路用场景规格与定时事件脚本经生成模型渲染，真实路做场景任务匹配与片段截取；右栏统一做时间标注与问答构建，记录何时回应、做什么、说什么，并由参考区间派生正确选项。
下段图展示了这一整条流水线的三栏构成，阅读时可先把握从左到右的因果顺序，再对照正文中的过滤与质检环节理解每一步的输入输出。
看图路径： 1. 看左栏四类支持如何经支持需求落到生活场景与期望行为；2. 看中栏合成生成与真实取材两路各保留哪些场景与证据；3. 看右栏时间轴上 wait 与 inform 窗口划分及问答派生关系
论文图 3。原论文 Figure 3:：“Construction pipeline of Omni-Life. Support needs guide scenario design and video sourcing through controlled synthesis or selection from public real-world sources.”。
如图 3 所示，左栏从感知、认知、行动、沟通 4 类出发落到生活场景并明确参考与证据，中栏并列合成视频与真实视频的取材与生成过程，右栏用 wait 与 inform 交替的时间轴示例定义回应窗口与行为标签，并由此派生内容问答与时机问答经抽样复核后成题。
合成侧保留地点、人物外观、关键物体、相机视点与事件描述，问题触发类保留原声提问而不配回答语音、解说或字幕，以防答案泄露；真实侧在截取后的时间轴上重标窗口。所有视频共 400 段，其中 277 段合成、123 段真实，标注 555 个必要干预节点与 685 个沉默区间，窗口采用半开区间[s,e) 形式，与问答正确选项保持同一参考。
场景 × 人群 × 设备： 场景说明正在发生什么事，人群说明这次要帮的是谁，设备决定助手能看到什么视角。三者组合才构成一个具体服务任务：同一种跌倒对独居老人和有看护在场婴儿的意义不同，近景能认物体却看不到全场，只有三者一起才能判定该不该开口。
五种行为标签各管什么
每个视频配一个常驻任务和一段段的时间区间。区间用半开区间记录起止秒数，标上行为和中英文参考回答。4 个需回应标签是告警、告知、反馈、回答，第五个是等待，要求零输出。告知报告状态或结果，反馈纠正动作本身；当错误动作带来即时危险时，反馈升级为告警。回答只用于用户明确提问，轮到别人说话或没被点名时必须等待。
举例来说，数杯子报总数属于告知，指出玩具车手臂装反属于反馈，提醒前方水坑属于告警，孩子问单词意思后解释属于回答。配对设计故意让相似画面走向不同标签：危险已被他人排除就保持沉默，否则就告警，这样模型不能靠认场景蒙混。
warn × inform × wait： warn 是发现紧迫风险时告警，inform 是主动报告状态或结果，wait 是明确要求保持沉默。三者不是语气差别，而是对证据和紧迫程度的不同判断：有即时危险用 warn，只需让用户知道情况用 inform，条件不满足就用 wait 压住输出。
feedback × answer： feedback 是评价或纠正用户刚才的动作，answer 是回答用户明确提出的问题。前者由助手判断时机主动给出，后者必须等用户开口；把两者分开，才能测出模型是乱抢答还是真的在回应提问。
视频从哪里来，时间标注怎么做
数据集共 400 段视频，其中 277 段合成、123 段真实。合成用视频生成模型按人物、地点、物件、机位和分步事件脚本渲染，危险和边缘情况可控且避免真人涉险；真实视频从公开来源挑选，带来自然的人体动作、镜头抖动和事件进程。两类视频之后用同一套行为和时间框架标注，保证可比。
标注把事件进展写成有序序列，每个事件是可观察的状态变化。计数任务要求动作可区分、暂停可辨；提问触发的任务保留原声提问但不允许答案旁白或字幕泄露。质检只看决策证据是否可见、时间是否一致、有无泄题，合成额外检查物理合理和人物一致。
下表概括视频与标注规模，干预视频与纯沉默视频、干预点与沉默区间的计数单位不同，需要分开理解。
| 视频与标注 | 合成 | 真实 | 合计 |
|---|---|---|---|
| 视频总数 | 277 | 123 | 400 |
| 需干预视频 | 184 | 106 | 290 |
| 全程沉默视频 | 93 | 17 | 110 |
| 干预点 | 255 | 300 | 555 |
| 其中告知/告警/反馈/回答 | 139/92/11/13 | 223/57/18/2 | 362/149/29/15 |
表中合成占比高但真实贡献了更多干预点，告知是大头而回答很少。这种不均衡是任务自然分布，不是刻意配平。解读召回时要记得小类分母很小，一两个点的得失就会大幅摆动百分比。
每段视频还派生两道选择题，一道考在某时刻该说什么，一道考何时该说，共 800 题。正确选项来自标注，错误内容选项由模型生成同场景干扰项，错误时间选项用规则错开窗口。人工抽查措辞和重复选项，但并未逐条验证全部标注。
这篇论文训练了什么，没有训练什么
这是 1 篇基准论文，没有训练新的助手模型，也没有更新任何被测模型的权重。它的构造工作是场景设计、视频合成与筛选、时间标注和问答生成。被测的 12 个配置都是现成系统，包括 8 个本地部署的开源权重系统和 4 个云端实时接口，原样拿来做流式和问答测试。
实际执行的是推理与记录流程：给每个会话发中文基准说明、书面任务和源视频，不给参考答案和窗口；按约 1 帧每秒送画面、16 千赫单声道送音频；部分不直接处理音频的配置改用语音识别转写文本再输入。解码、切块、延迟收集等参数按各家接口保留原样，目的是测真实部署形态，而不是统一成同一种解码器再比大小。
流式打分与问答打分如何判定对错
流式要求模型在视频播放中随时输出带标签的文本，Gemini 返回音频再转写。内容对错由统一的语言模型判分，只看是否传达该点最少必要信息，措辞不同可接受，缺关键信息或有实质矛盾则判错，不看标签写得对不对，也不看视频。时间要求输出起点落在原参考窗口内，迟到早到都不给分。匹配是 1 对一、保序的最大基数匹配，保证每个参考点和每条输出至多用一次。
\[c_{ij}=1\quad\text{and}\quad s_{i}\leq t_{j}Intervention Recall × Silence Success： Intervention Recall 统计 555 个必须干预点中有多少被又及时又说对，Silence Success 统计 110 个全程该沉默视频中有多少真的零输出。前者看有没有漏掉该帮的，后者看有没有乱打扰，只看其一都会误判，多说的人前者高、少说的人后者高。
Full Correct × Intervention F1： Intervention F1 兼顾查全和查准，用匹配数同时除以参考点和模型输出数；Full Correct 更严，要求 290 个需帮助视频中每个点都匹配、且没有多余输出蹭进沉默区。F1 高不代表整段视频可用，Full Correct 才接近整段托管是否成立。
主结果：能答题不等于能持续帮忙
主结果同时报告流式干预和回合问答。下表摘出关键列，方向都是越高越好，流式看整段执行，问答看单点选择。人类基线由 4 名标注者独立完成，用于标定任务难度而非比较人与模型。
| 配置 | 全对% | 干预召回% | 干预 F1% | 沉默成功% | 问答联合% | 内容% | 时机% |
|---|---|---|---|---|---|---|---|
| 人类基线 | 53.10 | 62.34 | 64.49 | 91.82 | 60.38 | 82.13 | 66.13 |
| MOSS-VL | 4.48 | 5.77 | 7.06 | 82.73 | 5.75 | 18.50 | 35.00 |
| Gemini 3.8 Live | 3.79 | 3.42 | 5.45 | 93.64 | 42.25 | 78.25 | 51.25 |
| Qwen3.5 Flash | 3.10 | 4.14 | 5.39 | 80.91 | 17.25 | 48.50 | 30.25 |
| JoyAI | 0.00 | 20.00 | 1.67 | 0.00 | 13.25 | 63.00 | 19.00 |
| Gander | 2.07 | 1.08 | 2.05 | 99.09 | 3.50 | 34.00 | 12.00 |
最好的全对只有 MOSS-VL 的 4.48%，其次是 Gemini 的 3.79%。JoyAI 召回最高到 20.00% 但 F1 只有 1.67% 且全对为零，说明说了很多但大多不在点上；Gander 沉默成功高达 99.09% 但召回只有 1.08%，说明靠少说保沉默。Gemini 问答内容准确率 78.25% 很高，流式召回却只有 3.42%，证明会选题不等于会在任务进行中主动发起帮助。所有 65 次整视频全对都发生在单干预点视频，需要多次干预的 97 个视频无一被任何配置完全拿下。
看图路径： 1. 对比 A 的计数错误与 B 的处置建议错误；2. 注意红点都落在绿色窗口内但内容仍判错；3. 看期望回答与模型回答的关键差别词
论文图 4。原论文 Figure 4:：“Two on-time failures in cup counting (A) and post-fall assistance in a synthetic video (B), shown with source frames, condensed references, and translated outputs.”。
图 A 数杯子任务期望报 3 杯，JoyAI 准时报出 12 杯，属于时间对但数量错；图 B 老人浴室跌倒期望避免贸然搬动并求助，MiniCPM 虽准时识别跌倒却建议擦水扶起，与参考处置相反。2 例都说明准时且相关仍可能判错，任务完成度要看建议是否真正满足求助目标。
失败集中在哪里，不同模型有何短板
论文把 4800 个会话的人工复核归纳为 5 类可观察失败，允许 1 会话多类并存。下表是总体占比，分母是 4674 个成功完成的会话，另有 126 个执行失败仍计入主指标分母。
| 失败类型 | 可观察行为 | 会话占比% |
|---|---|---|
| 干预控制 | 漏助、错过窗口或不该说时说 | 68.96 |
| 情景 grounding | 认错当前物体属性位置风险 | 3.17 |
| 时间追踪 | 数错累计数、顺序或完成状态 | 4.69 |
| 任务完成 | 说了相关话但没办成请求的事 | 9.63 |
| 不可用输出 | 只输出时间戳空标签或缺关键句 | 22.76 |
干预控制最普遍，达 68.96%，其中 1720 个干预会话全程零输出。情景与追踪错误比例不高但性质不同：前者是当下看错，如把窒息当成吃笑；后者是累积算错，如把 3 杯数成 12 杯。任务完成失败如只说已迎宾却没真的迎宾请坐。不可用输出如在漏水窗口只吐出时间戳字符串，不能算帮忙。
分模型看，JoyAI 干预控制失败 97.50% 且多类错误都高，AURA 与 MOSS Preview 各有 385 个会话出现不可用输出。少说的模型内容错误率低是因为输出少，例如 Gander 和 MiniCPM 各自仅约 0.25% 会话出现 grounding 错误，但分别有 260 和 245 个干预会话零输出。因此低内容错误必须结合召回和沉默一起读，不能单独当成质量好。
反复提醒能换回多少覆盖，代价是什么
论文固定视频和判分，只改任务文本的呈现方式，比较结构化改写、每秒或每 5 秒重发全任务、每秒发通用提醒。下表是 5 个模型的及时正确率与每分钟沉默区内的不必要输出数，前者越高越好，后者越低越好。
| 策略 | MiniCPM 召回% | MOSS-VL 召回% | Venus 召回% | Gemini 召回% | Qwen3.5 Flash 召回% |
|---|---|---|---|---|---|
| 原任务文本 | 1.44 | 5.77 | 1.98 | 3.42 | 4.14 |
| 每秒重发全任务 | 5.41 | 6.85 | 13.51 | 12.43 | 3.42 |
| 每 5 秒重发全任务 | 1.80 | 14.05 | 10.27 | 20.54 | 3.42 |
| 原任务文本（每分钟沉默误响应数） | 0.14 | 1.41 | 0.48 | 0.57 | 1.34 |
| 每秒重发全任务（每分钟沉默误响应数） | 0.64 | 5.13 | 21.68 | 4.96 | 1.29 |
| 每 5 秒重发全任务（每分钟沉默误响应数） | 0.20 | 4.48 | 7.58 | 5.16 | 1.29 |
结构化改写只有小幅混合变化，周期提醒对 4 个模型提升明显，最优间隔因模型而异，Qwen 无提升。Gemini 用 5 秒提醒从 3.42% 升到 20.54%，但打扰从 0.57 升到 5.16 每分钟；Venus 用 1 秒提醒到 13.51%，打扰高达 21.68 每分钟。论文据此提出应把任务状态与生成分开，用持久的事件条件和已处理标记做更新，而不是靠反复发消息去激活回应，但该接口设想尚未验证。
任务改成语音播报的对照也没有一致增益：MOSS-VL 召回升但全对降，输出变多而准时且正确的占比从 9.12% 降到 7.22%，10 秒后的打扰从 202 增到 378 条。这说明多说不等于整段更好，语音带来的启动效应可能同时制造开头抢答和后续唠叨。
把截止时间放宽后还有多少能捡回来
另一项离线消融不重跑模型，只把每个窗口右端延长 1、2、5、10 秒重算匹配，看已录输出中有多少是迟到但内容对的。下图按 10 秒增量排序，右侧条形是百分点增量。
看图路径： 1. 先看 Original 列各模型的起点高低；2. 再向右看 +10s 列增量条的长短排序；3. 注意增量最大者绝对值仍未超过 24%
论文图 6。原论文 Figure 6:：“Intervention Recall (%) as reference-window ends are extended. Rows are ordered by the gain at Δ=10 s, shown in percentage points (pp) by the right-hand bars.”。
图中可见 AURA 增量最大，从 12.61% 到 18.56% 增加 5.95 个百分点，JoyAI 从 20.00% 到 23.96% 增加 3.96 个百分点，其余更小，所有模型仍低于 24%。按 missed 中被挽回的比例算，最多只有 6.80% 被捡回，至少 93.20% 仍不匹配。这说明欠账主要不是慢，而是没说或说错。放宽窗口还可能把本想回应后一事件的迟答算给前一事件，且收集时长限制了可观察的迟到上限，因此不能把该增量理解为加速推理就能获得的收益。
这些结论在什么条件下才成立
结论依赖有限录像、预设任务和人工窗口，不能推广到长期部署、自适应交互或偏好变化。合成片段偏向明确动作，真实分布未必如此；人群与场景比较受任务和机位混杂影响，不能解读为某类人群本质更难，也不能当公平性证据。
系统比较受接口和输入链路影响，起点计时是客户端收到而非喇叭播放；参考答案的自动判分可能漏掉任务完成度的细微差别；4 人基线和抽查不能代表全部标注质量。提醒频率和放宽窗口都是事后重算或固定频率试探，不是可部署的最优策略，选型必须在同时包含干预和安静段的独立验证视频上重测。
要复现和验证应从哪一步做起
复现先固定 400 视频、555 干预点、290 干预视频和 110 纯沉默视频的划分，保留失败会话在分母中。用约 1 帧每秒画面和 16 千赫单声道音频按源时间推送，不添加额外音轨；无源音频的 30 段不补音。给模型发中文基准说明和书面任务，不给参考和窗口，按各家原生切块保留调度和分组，记录输出起点、文本、延迟和失败。判分用同一内容标准和原窗口做 1 对一保序匹配，再算召回、F1、全对和沉默成功。
值得尝试的场景是需要持续监测但容忍一定打扰的任务，例如老人跌倒监测或课堂分心提醒。先在验证集上试每 5 秒提醒与通用提醒的差别，同时监测沉默区打扰率；再对迟到但内容对的样本做输入到输出的时间拆解，区分是模型启动慢还是根本没发起。项目页给出的仓库链接在论文中列为第三方链接，本次核验为可访问，但是否长期可用、权重是否公开、服务能否运行是三件不同的事，需分别确认。
一句话总结与下一步验证
Omni-Life 表明现有实时多模态助手在日常陪伴中既容易漏掉该帮的，也容易在该沉默时开口，问答好不代表流式好，提醒和放宽时限只能换回小部分。下一步应把任务条件做成持久状态并与生成解耦，单独考核持续追踪、选择性发起和按时完成三件事。
初学者易误解的是把召回高当成整体好、把沉默成功高当成谨慎好、把窗口放宽后的提升当成加速就能得到。正确读法是三者同看：召回看覆盖，F1 和全对看整段可用性，沉默指标看打扰代价；任何只动一端的改法都要在含干预和安静的验证集上重估，并补上未评测的多干预长视频和真实部署延迟的测量。
📎 论文与评分元数据
排名：前50% | 文档类型：数据集与基准 | arXiv 原文
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
评分规则：type-aware-v1
评分模型：muse-spark-1.3-contributor
评分请求协议：openai_responses