{"id":93976,"topic":"ai","source":"搜狐网","title":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 - 搜狐网","url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","url_hash":"8abbcda22e6ec76618706b7cffc24dc5517688a0","author":"","summary":"<a href=\"https://news.google.com/rss/articles/CBMiiAFBVV95cUxNaVdSYTFVbXliYnJsTDVoeDdxd3NkYzVyT0N1M1htX3RiTmxiLW9iY3I2ajFubHptaHZpMTR2emJxS3JCV3g5N1hUMndxbHAxX1Iybm1JOTVGc3I3dFQ4LXJUamNpUDRFQzhaSWxrTzh1blRCTkRyejlnV3RaUklHdVZCZzJRekMt?oc=5\" target=\"_blank\">视频大模型三方反馈范式上线，面向真实直播建模持续决策</a>&nbsp;&nbsp;<font color=\"#6f6f6f\">搜狐网</font>","content":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：把后续可能有用的线索写入记忆。 \n- [task]... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","image_url":"https://q5.itc.cn/q_70/images03/20261001/0d9db14d4620451998c743be748382b2.png","lang":"zh","published_at":"2026-10-01T04:00:00+00:00","fetched_at":"2026-10-01T05:15:08+00:00","status":"read","starred":0,"extract_state":"ok","summary_auto":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","cluster_id":null,"extract_retries":0,"extract_error":null,"contract_version":"news_item.v1","format_contract_version":"news_item_formats.v1","dedup_url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 4575 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":4575,"summary_length":4545,"usable_text_length":4575,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":4575,"summary_length":4545}},"news_item":{"id":93976,"canonical_url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","source_url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","title":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 - 搜狐网","source_name":"搜狐网","author":null,"published_at":"2026-10-01T04:00:00+00:00","locale":"zh","topic":"ai","tags":[],"rss_summary":"<a href=\"https://news.google.com/rss/articles/CBMiiAFBVV95cUxNaVdSYTFVbXliYnJsTDVoeDdxd3NkYzVyT0N1M1htX3RiTmxiLW9iY3I2ajFubHptaHZpMTR2emJxS3JCV3g5N1hUMndxbHAxX1Iybm1JOTVGc3I3dFQ4LXJUamNpUDRFQzhaSWxrTzh1blRCTkRyejlnV3RaUklHdVZCZzJRekMt?oc=5\" target=\"_blank\">视频大模型三方反馈范式上线，面向真实直播建模持续决策</a>&nbsp;&nbsp;<font color=\"#6f6f6f\">搜狐网</font>","full_text":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：把后续可能有用的线索写入记忆。 \n- [task]... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","excerpt":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","extraction":{"state":"ok","confidence":0.9,"error":null,"explanation":"High confidence: full text extraction produced 4575 characters.","diagnostics_url":"/api/diagnose?url=https%3A//m.sohu.com/a/1083053238_610300%3Fscm%3D10001.325_13-325_13.0.0-0-0-0-0.5_1334","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 4575 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":4575,"summary_length":4545,"usable_text_length":4575,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":4575,"summary_length":4545}}},"display_formats":["compact","card","full","digest_section","json"]},"daily_stack_record":{"title":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 - 搜狐网","url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","summary":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","source":"搜狐网","date":"2026-10-01T04:00:00+00:00","content":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：把后续可能有用的线索写入记忆。 \n- [task]... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","confidence":0.9,"diagnostics_url":"/api/diagnose?url=https%3A//m.sohu.com/a/1083053238_610300%3Fscm%3D10001.325_13-325_13.0.0-0-0-0-0.5_1334","quality_bucket":"high","failure_kind":"none","retryable":false,"quality_reason":"High confidence: full text extraction produced 4575 characters.","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 4575 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":4575,"summary_length":4545,"usable_text_length":4575,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":4575,"summary_length":4545}},"tags":[]},"fallback_formats":["markdown","json","html"],"actions":{"read":"/item/93976","export_markdown":"/api/items/93976/export?format=markdown","export_json":"/api/items/93976/export?format=json","diagnose":"/api/diagnose?url=https%3A//m.sohu.com/a/1083053238_610300%3Fscm%3D10001.325_13-325_13.0.0-0-0-0-0.5_1334"},"formats":{"full":{"id":93976,"title":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 - 搜狐网","url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","source":"搜狐网","author":null,"published_at":"2026-10-01T04:00:00+00:00","locale":"zh","topic":"ai","tags":[],"excerpt":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","full_text":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：把后续可能有用的线索写入记忆。 \n- [task]... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","reading_time_min":1,"extraction":{"state":"ok","confidence":0.9,"error":null,"explanation":"High confidence: full text extraction produced 4575 characters.","diagnostics_url":"/api/diagnose?url=https%3A//m.sohu.com/a/1083053238_610300%3Fscm%3D10001.325_13-325_13.0.0-0-0-0-0.5_1334","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 4575 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":4575,"summary_length":4545,"usable_text_length":4575,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":4575,"summary_length":4545}}},"quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 4575 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":4575,"summary_length":4545,"usable_text_length":4575,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":4575,"summary_length":4545}},"actions":{"read":"/item/93976","export_markdown":"/api/items/93976/export?format=markdown","export_json":"/api/items/93976/export?format=json","diagnose":"/api/diagnose?url=https%3A//m.sohu.com/a/1083053238_610300%3Fscm%3D10001.325_13-325_13.0.0-0-0-0-0.5_1334"}},"digest":{"id":93976,"title":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 - 搜狐网","url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","source":"搜狐网","topic":"ai","published_at":"2026-10-01T04:00:00+00:00","excerpt":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 Live Assistant团队 投稿 量子位 | 公众号QbitAI 直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。 在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。 针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content…","quality_bucket":"high","quality_reason":"High confidence: full text extraction produced 4575 characters.","reading_time_min":1,"cluster_id":null},"card":{"display_title":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 - 搜狐网","subtitle":"搜狐网 · 2026-10-01","summary":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 Live Assistant团队 投稿 量子位 | 公众号QbitAI 直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。 在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。…","badges":["quality:high"],"links":{"read":"/item/93976","original":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","diagnose":"/api/diagnose?url=https%3A//m.sohu.com/a/1083053238_610300%3Fscm%3D10001.325_13-325_13.0.0-0-0-0-0.5_1334"},"quality_warning":null},"export":{"title":"视频大模型三方反馈范式上线，面向真实直播建模持续决策 - 搜狐网","url":"https://m.sohu.com/a/1083053238_610300?scm=10001.325_13-325_13.0.0-0-0-0-0.5_1334","summary":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","source":"搜狐网","date":"2026-10-01T04:00:00+00:00","content":"视频大模型三方反馈范式上线，面向真实直播建模持续决策\nLive Assistant团队 投稿\n量子位 | 公众号QbitAI\n直播大模型，最难的可能不是“看见了什么”，而是知道什么时候该闭嘴，什么时候该记住，以及该把话说给谁。\n在真实直播间里，模型面对的是一个持续变化、信号异构、反馈对象多元的现场。可现有的视频大模型，大多还停留在“边看边解说”或“你问我答”的阶段，默认了一个隐含前提：模型的任务就是不停地说。\n针对这一现状，复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合发布Live Assistant，面向真实直播场景提出了一套基于内容理解的三方反馈范式。\n该不该说、说给谁、说什么类型——这三个问题，构成了Live Assistant的全部行动语法。\n现有视频大模型，卡在了哪儿\n过去的视频理解模型大多处理两类问题：一种是离线长视频问答，模型先看完整视频，再回答用户问题；另一种是在线逐片段解说，模型按时间片生成实时描述。\n近两年也出现了一批直播/在线视频理解工作：有的强调用户query驱动的在线问答，有的把视频流切成连续片段做实时解说，有的重点优化长视频记忆，让模型在更长时间范围内保留上下文。\n这些方向解决了“模型如何边看边理解视频”的问题，但距离真实直播间仍有三道坎：\n第一，直播被简化成了“视频帧+文本”。很多live理解工作仍把直播当作“图像帧+文本问题”，或者把音频先转成ASR文本再输入模型。可真实直播里的主播语气、背景音、弹幕密度、礼物事件、在线人数变化、房间meta信息和平台规则，并不是附属信息，而是会共同改变模型判断的原生信号。\n第二，反馈对象太单一。现有系统要么回答用户问题，要么给观众生成解说。但直播助手真正服务的是多方：观众需要解释和recap，主播需要评论区问题、节奏变化和关键事件提醒，平台/审核侧需要风险线索和待复核片段。\n第三，“不说话”没有被当成一个动作。很多在线模型仍由用户问题或固定时间片驱动，到了一个片段就输出一段话。但在真实直播里，“沉默”本身就是一个重要且合法的动作。模型必须基于内容理解判断：当前是继续观察，还是写入记忆，还是在关键事件、高光、评论爆发、节奏异常或安全风险出现时主动反馈。\n这也引出了Live Assistant的核心问题定义：真实直播本质上是一个异构、长时、多方互动、混合驱动的多模态信号流。Live Assistant要建模的不是单次回答，而是直播过程中的持续状态决策。\n六层设计：从多模态信号到长程行动策略\nLive Assistant的技术设计可以拆成六层：Omni原生多模态直播信号、内容理解驱动状态机与多方反馈、多轮SFT、多轮RL、长程推理框架，以及贯穿数据、SFT、RL的训推一致性设计。\n下面这张图先给出整体的“决策骨架”——直播信号进来后，模型如何一步步走到“该不该说、说给谁、说什么”：\n△=沉默也是合法输出；=记住，而不是重复说；=说，但要说给对的人、说对的类型。虚线表示状态会回流到下一片段的内容理解，构成持续的状态决策循环。Omni原生多模态直播信号\n区别于一些只使用视觉帧和文本query、或先把音频转成ASR文本再送入模型的方案，团队基于Omni原生多模态底座，直接建模视频、音频、文本以及直播间外部信号。\n这样做的意义在于，直播里的很多关键状态并不只存在于画面里：主播语气变化、背景音、弹幕密度、礼物事件、实时人数波动，都可能共同决定模型是否应该输出。\n换句话说，Live Assistant不是把直播简化成“长视频+文字问题”，而是把真实直播看作一个持续到来的多模态信号流。\n内容理解驱动状态机×多方反馈\n团队将每个直播片段的输出压缩成三个核心动作：\n- ：当前继续观察，不打扰直播节奏。 \n- ... ：把后续可能有用的线索写入记忆。 \n- [task]... ：面向观众或主播输出具体反馈；安全和审核相关任务可通过task标签进入平台侧工作流。 \n其中task可以覆盖narration、key event、highlight moment、viewer QA、entity pinning、pacing alert、newcomer recap、FAQ gap、safety alert等直播任务。这个状态机让模型不再只是“生成一段描述”，而是在学习直播助手的行动策略。\n它对应真实直播里的三个问题：该不该说、说给谁、说什么类型。\n而多方反馈不是简单的后处理路由，而是状态机的一部分。比如同样是“评论区大量询问尺码”，对观众侧可能是FAQ回答，对主播侧可能是提醒主播补充说明；同样是“直播节奏突然冷场”，对观众侧不一定需要输出，但对主播侧可能需要pacing alert。\n多轮SFT：让模型先学会直播行为语法\n在SFT阶段，团队采用多轮直播SFT：一个训练样本包含多个连续直播片段，模型在前后文中学习每一轮应该观察、记忆还是开口。\n为了让模型更敏感地学会关键决策，团队对“状态、对象、任务”三类标记引入额外的候选标记损失。也就是说，除了普通语言模型loss，训练还会显式强化\n这一步解决的是直播助手最基础、却最容易被忽略的问题：模型不能只学会“说得像”，还要学会什么时候不说、什么时候先记、什么时候对正确的人说。\n同时，SFT只监督助手输出位置，用户输入、媒体内容和外部信号只作为上下文。这让模型学习的是直播行动本身，而不是复读输入内容。\n多轮RL：优化直播行动策略\n仅靠SFT可以学到格式和常见行为，但直播里的关键问题往往是策略问题：什么时候该说，什么时候不该说，说给谁，说成什么类型。\n因此，团队进一步构建了多轮RL训练链路，从SFT模型继续优化。训练过程中，模型按直播片段连续采样动作，再根据整条直播轨迹的收益进行更新。\nRL reward直接围绕直播状态机定义：模型必须输出一个合法状态，非法格式直接惩罚；如果是\n更关键的是，多轮直播不是单turn任务。团队同时建模turn-level credit和trajectory-level credit：当前轮的输出承担当前动作的责任，而一整条直播轨迹的收益会影响长程策略。这样模型学到的不是“每轮都多说一点”，而是“在长期直播效果最好的时间点，说对的话”。\n这使得Live Assistant的训练目标更接近真实使用方式：模型不是为了每秒都说一句话，而是为了在长时间直播中做出少而准、可解释、对多方有用的反馈。\n面向长时直播的长程推理框架\n真实直播往往持续几十分钟甚至数小时。如果每轮都把完整历史重放给模型，成本和延迟都会迅速失控。\n因此，团队把推理侧定位成一个长程流式推理框架：模型按片段增量读取新的视频、音频、文本和直播信号，同时保留一套可持续更新的历史记忆，用于跨事件、跨问答、跨直播节奏变化的推理。\n技术上，团队把历史分成两级：近期窗口保留高密度原始上下文，更早历史进入压缩记忆。这样模型不需要每轮重放完整直播历史，也能保留跨片段推理所需的关键线索。\n更重要的是，记忆按直播轮次对齐，而不是随意切开视频、音频和文本。直播中的一个事件往往由画面、声音和弹幕共同构成；如果三种模态在历史裁剪时被打散，模型看到的就不再是同一个事件。按轮次对齐的记忆，正是为了减少这种语义错位。\n训推一致性：从数据标注到在线采样链路\n流式直播训练最容易出现的问题是训推不一致：训练时模型看到完整拼接上下文，推理时却只能看到增量片段和被保留下来的历史记忆；训练时像普通长文本，推理时像一个持续行动的助手。\n- 数据标注阶段，不把不同片段当成相互独立的短视频。团队会把前一个片段的边界状态、历史记忆和关键外部信号传给下一个片段，让标注模型感知直播状态的连续变化。这样生成的监督信号不是“每段单独描述”，而是一条逐步演化的状态序列。 \n- SFT阶段，样本以多轮因果语言建模形式组织：前序用户/助手轮次作为后续轮次的上下文，只有助手输出位置参与训练loss。历史内容会被展开成记忆轮次，再进入当前片段的多轮交互；额外标记损失继续强化状态、对象、任务三类关键决策标记。 \n- RL阶段，在线采样链路和最终推理链路保持一致，而不是另写一套离线生成逻辑。模型同样按直播片段增量推进，同样使用长程记忆，同样在每一轮输出/ / 状态。 \n当前稳定基线中，采样结果只用于优化当前轮动作，下一轮历史先使用标注状态，避免RL初期因为错误历史快速漂移；后续可逐步过渡到混合历史和模型自生成历史，进一步逼近真实在线推理。\n一个基模能力之外的新任务\n结果展示：\n团队定义了一个直播流视频理解场景下的新任务，这个任务是base model的参数分布之外的，所以未经过训练的base模型甚至无法做到指令跟随，如表格所示，指标均为0。团队的递进式训练策略，包含多轮sft和多轮rl，都实现了稳定有效的提升。\ncase展示：\n不是更会说，而是更知道何时说\nLive Assistant的价值，不在于把某个视频benchmark的分数又刷高了几个点，而在于它把视频大模型真正推进到了真实直播场景——一个持续、异构、多方在场的现场。\n它服务的从来不是一个人，而是一整个直播现场里的所有角色：\n- 对观众，它可以做实时讲解、背景补全、新人recap和高光提示； \n- 对主播，它可以提醒评论区问题、节奏变化、商品/游戏关键节点和观众反馈； \n- 对审核人员，它可以在长时直播中标注潜在风险、异常事件和需要复核的片段。 \n更重要的是，这套范式把直播理解从“被动回答”推进到了“内容驱动的主动协同”。模型既能看见多模态现场，也能理解弹幕、礼物、人数这些外部信号，还能判断——此刻是否应该打断当前直播节奏，以及这句话到底该说给谁听。\n这背后其实是一个更大的判断：AI与人、与真实世界的交互潜力，远没有被发掘完。当模型不再只是“回答提问”，而是开始主动决定“向谁、在何时、发出哪一类反馈”时，它才真正从一个“会看视频的模型”，变成一个“能参与现场协作的助手”。\n而这，可能正是直播大模型走向真实生产系统时必须补上的一环：不是更会说，而是更知道何时该说、该对谁说。\n论文、开源与合作团队\n作者团队简介：本项目由复旦大学可信具身智能研究院、Bytedance International Live Content AI团队与上海创智学院联合完成。学校负责人为吴祖煊、姜育刚老师；团队负责人为周鹏豪、王庆磊。这个工作也得到了杨雨辰、严佳媚的支持。\n项目面向真实Bytedance直播场景，使用真实直播数据，探索真实世界直播理解、记忆与反馈建模。\n论文链接：https://arxiv.org/abs/2609.27303\nGitHub：https://github.com/Daryl-GSJ/LiveAssistant\nHuggingFace：https://huggingface.co/collections/Yah-daryl/live-assistant\n项目页/博客：https://daryl-gsj.github.io/LiveAssistant/","confidence":0.9,"diagnostics_url":"/api/diagnose?url=https%3A//m.sohu.com/a/1083053238_610300%3Fscm%3D10001.325_13-325_13.0.0-0-0-0-0.5_1334","quality_bucket":"high","failure_kind":"none","retryable":false,"quality_reason":"High confidence: full text extraction produced 4575 characters.","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 4575 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":4575,"summary_length":4545,"usable_text_length":4575,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":4575,"summary_length":4545}},"tags":[],"format_contract_version":"news_item_formats.v1"}}}