2026-08-27·無料·論文·14分で読めます

論文解説: TLive-Omni — ライブ配信を「見て・聞いて・何分何秒かまで答える」オムニモーダルモデル

ECライブ配信に特化したオムニモーダル理解モデルTLive-Omniを、前提知識ゼロから解説。時刻つきで映像と音を隣に置くPer-vGrid、3段階SFT、思考の跡ではなく答えの忠実さに報酬を出すFaithful-RFTまでを、論文の数値だけを根拠に読み解く。

要点

TLive-Omniは画像・動画・音声・テキストを同じ表現空間で扱う、テキストのみを出力するオムニモーダル理解モデルである。
音声を外部ASRで文字にすると、音声と映像の時間的対応やパラ言語的な手がかりが消えるため、音声を一級の入力モダリティとして保つ。
Per-vGridは映像と音声を同じスパンに置き、先頭にテキストの時刻を書く。時刻は実際にサンプルされたフレーム番号から導く。
学習は3段階のSFTで、段ごとに凍結する部分が異なる。その後Faithful-RFTが思考トレースではなく答えの忠実さに報酬を与える。
ライブコマースASRのCERは9Bで6.46、4Bで6.66と、Qwen3-Omni(30B-A3B)の6.75を下回る。

#omni-modal #live-commerce #asr #video-understanding #grpo

対象image audioタスクgeneration

TLive-Omni: An Omni-Modal Understanding Model for E-Commerce Live Streaming

一次資料 — この記事の根拠

論文の発表 2026-08-21→この解説の公開 2026-08-27同月

TLive-Omni: An Omni-Modal Understanding Model for E-Commerce Live StreamingYibo Hu, Yu Qian, Mao Gu ほか · 2026-08-21 · v1arXiv:2608.20958論文ページ·PDF

原文の要旨（Abstract）を読む

E-commerce live streaming requires omni-modal understanding of noisy, temporally extended streams, where product facts are distributed across speech, video frames, product images, overlaid text, and user queries. We present TLive-Omni, an omni-modal understanding model tailored to live-commerce scenarios. It maps image, video, audio, and text inputs into a unified representation space. For long-form live streaming analysis, we introduce Per-vGrid, a timestamped token organization that groups each video grid with its temporally corresponding audio within explicit boundary tokens to facilitate temporal alignment. We design a three-stage supervised training recipe that progressively develops live-commerce understanding, from omni-modal perception to instruction-following responses. We then propose Faithful-RFT, a reinforcement fine-tuning stage that further improves answer faithfulness and expression quality while meeting real-time demands, scoring final responses directly with task-verifiable feedback rather than optimizing for reasoning-style exploration during rollout. Moreover, TLive-Omni is supported by a scenario-oriented atomic capability taxonomy and a compact data production engine that converts live-commerce audio, image, and video streams into training signals for speech recognition, speaker analysis, product visual grounding, text recognition, temporal grounding, video dense caption, and omni-modal QA, etc. For scalable training, a synchronized length-grouped sampler reduces padding while preserving comparable workloads across workers, while a lightweight dynamic sampling strategy regenerates rollout groups with near-zero reward variance to maintain meaningful relative advantages for GRPO. Experiments on e-commerce live streaming benchmarks demonstrate strong performance across live-commerce domain tasks, together with excellent generalization on general benchmarks.

深夜3時間の配信から「その一言」を探す

ライブコマース（配信しながら商品を売る番組）を思い浮かべてください。配信者が3時間しゃべり続け、机の上の商品は入れ替わり、画面の隅にクーポンの文字が出て、視聴者は「サイズ展開は?」とコメントを打ち込む。ここで「Lサイズの在庫に触れたのは何分何秒?」と聞かれたら、声（何を言ったか）・映像（そのとき何を持っていたか）・画面上の文字（値段やクーポン）・商品画像（カタログ側の正解）・視聴者の質問文を同時に扱わないと答えられません。しかも根拠は3時間のどこかに散らばっています。

TLive-Omni（Taobao & Tmall Group of Alibaba）は、この状況に特化したオムニモーダル理解モデルです。「オムニモーダル」とは、画像・動画・音声・テキストを同じ表現空間に写して1本の入力列として扱うこと。論文はこのモデルを「テキストのみを出力する理解モデル」と明記しています（§2.1）。喋り返す相棒ではなく、読み解いて答える装置だと思ってください。

論文が挙げる難所は2つです（§1）。1つは異種信号の同時解釈。音声と映像を別々に処理してから足し合わせるやり方では、「この発言はこの瞬間の映像に対応する」という関係が失われます。もう1つは長さで、根拠となる場面は数十分先にあるかもしれない。TLive-Omniは最大256Kトークンのマルチモーダル文脈を扱えるとしています（§1）。

素朴な回避策は「音声を外部のASR（自動音声認識）で文字にして、テキストだけをモデルに渡す」です。論文はこれを明確に否定します（§2.3）。文字にした瞬間に音声と映像の時間的対応が消え、さらに誰が話しているかといったパラ言語的な手がかりも落ちるからです。ライブ配信では商品の事実の多くが映像には映らず配信者の声にしか存在しない — だから音声を一級の入力モダリティとして保つ、というのが論文の立場です。

まず採点表を見る: 「聞き取り」は編集距離で測られる

このモデルの主戦場のひとつは配信音声の書き起こしです。論文の評価はCER（文字誤り率）を使い、正解と予測の双方から話者マーカー・括弧タグ・句読点・空白・語気助詞を取り除き、中国語は簡体字に統一したうえで次を計算します（付録B）。

\mathrm{CER}=\frac{S+D+I}{N}

(1)

つまりこれは「書き起こしの修理代」です。CERが0.05なら、100文字につき5文字ぶんの手直しがまだ残っている、ということ。長くしゃべった配信ほど分母 $N$ も大きくなるので、単に文字数が多いという理由で不利にはなりません。

$S$ は置換（別の文字に間違えた数）、 $D$ は脱落（言ったのに書かれていない数）、 $I$ は挿入（言っていないのに書かれた数）、 $N$ は正解の文字数です。ひとことで言えば「正解に直すには何文字いじる必要があるか」を、正解の長さで割った値。この「何文字いじるか」が編集距離で、動的計画法の表を1マスずつ埋めて求めます。下の図で、表がどう埋まるかを触ってみてください。

FIG 1編集距離のDP表。CERの分子 S+D+I は、この表が右下で到達する値そのもの

画面文字の認識（OCR）も同じ道具で測られます。論文は正規化編集距離 $d_{\mathrm{edit}}/\max(|p|,|g|)$ を使い、予測テキスト $p$ と正解 $g$ の長いほうで割って0〜1に収めています（付録B）。採点表を先に知っておくと、後で出てくる数字の意味がぶれません。

Per-vGrid: 映像と音を「隣に置く」

ここからが本題です。Per-vGridは、動画と音声を時刻つきの映像グリッドの列として並べます（§2.4）。ある時間区間の映像と、同じ区間を覆う音声を、明示的な境界トークンで囲った同じスパンに置き、その先頭にテキストの時刻を書く。字幕を別ファイルで持つのではなく、台本の各行の真横に対応する絵を貼っていくようなものです。Qwen3-Omniとの差は、時刻の明示・グリッド境界の明示・映像と音声のトークンを連続配置すること・隣接グリッドを列レベルで分けること、の4点だと論文は述べています。

なぜ「隣に置く」だけで効くのか。Transformerの入力は結局1本のトークン列で、モデルは位置の近さも手がかりに関係を推測します。映像を全部並べたあとに音声を全部並べる構成だと、対応する2つの証拠が数千トークン離れることもある。Per-vGridは対応するもの同士を必ず隣接させ、境界トークンで「どこからどこまでが同じ瞬間か」を明示します。対応関係を推測させるのではなく、入力列の形として見せてしまうのが設計の要点です。

先頭に書かれるテキストの時刻も、単なる飾りではありません。「何分何秒に何が起きたか」を答えるタスク（時間グラウンディング）では、モデルは最終的に秒数を文字として出力します。入力側に秒数が書いてあれば、出力すべき数字は入力のどこかからコピーしてくればよい。ここで入力に書いた秒数が実際の映像とずれていたら、モデルは正しくコピーしても間違えることになります。だから時刻の作り方が効いてきます。

肝は「要求FPS」ではなく「実効FPS」

Per-vGridは各グリッドの時刻と音声スパンを、実際にサンプルされたフレーム番号から導きます（§2.4）。ここに整数の丸めが効いてきます。

30FPSで119フレーム（約3.97秒）の動画に2FPSを要求すると、選ばれるのは $[0,20,39,59,79,98,118]$ の7枚。実効サンプリングレートは $7/119\times 30 \approx 1.76$ FPSであって、2FPSではありません。2フレームで1グリッドにまとめる（足りない末尾はパディングする）ので7枚は4グリッドになり、1グリッドが覆う時間は要求値どおりの1.0秒ではなく $2/1.76 \approx 1.13$ 秒。音声は毎秒およそ13トークンなので、1グリッド分の音声も13ではなく14〜15トークンになります。要求値のまま秒を振ると、この差がそのまま時刻のずれとして積み上がります。

音声エンコーダと、3段階の学習

背骨はQwen3.5に、Qwen3-OmniのAuT音声エンコーダを軽量なアライナで接ぎ木した構成です（§2.1）。AuTは2,000万時間の音声で一から訓練され、16kHzの128次元メルスペクトログラムを受け取って、音声を毎秒およそ13トークンに圧縮します（§2.3）。長い録音を文脈予算の中に収めるための圧縮です。

学習は3段階のSFT（教師ありファインチューニング）で、段ごとに何を凍結するかが違うのが肝です（§3.2）。

段	データ	学習するもの	凍結するもの
Stage 1	ASR 500万件	音声アライナのみ	言語モデル・音声エンコーダ
Stage 2	音声混合 2,600万件	音声エンコーダ＋アライナ	言語モデル
Stage 3	マルチモーダル 1,400万件	各アライナ＋言語モデル	音声・視覚エンコーダ

Stage 1は音響表現を言語モデルの埋め込み空間へ写すだけ。Stage 2で音声キャプションとQAを加え、書き起こしを超えて音・音楽・話者の手がかりまで届かせる。Stage 3で画像・動画・テキストと合流し、商品グラウンディングや時間グラウンディングを学びます。各段1エポックのみ、学習率は $1\times10^{-4}$ 、 $1\times10^{-5}$ 、 $4\times10^{-6}$ と1桁ずつ下がります（付録D.1）。

異種モダリティを混ぜるとバッチ内の長さがばらつき、パディングとワーカー間の負荷差が増えます。論文はモダリティごとに長さでソートし、全ワーカーが同じシードで同じグローバルバッチを選ぶ同期長さグループ化サンプラでこれを抑えました（§3.3）。

Faithful-RFT: 「考えた跡」ではなく「答えの忠実さ」に報酬を出す

SFTの尤度目的は、生成した応答へのタスク固有のフィードバックを取り込みません（§4）。ライブでは応答が証拠に忠実で、かつ間に合う必要がある。そこで論文は、Stage 3のモデルからコールドスタートSFTなしでGRPOを回すFaithful-RFTを置きます（§4.1）。特徴は思考トレースを報酬の対象にしないことです。推論の長さや可視のchain-of-thoughtには報酬を与えず、軽量な形式制約で不要なthinkタグを抑える（§4.2）。生成が長いほど本番で遅れるからです。

同じプロンプト $x_i$ に $G$ 個の候補を生成し、群の中での相対値でアドバンテージ（その候補がどれだけ良かったかの指標）を作ります。

\widehat{A}_{i,g}=\frac{R_{i,g}-\operatorname{mean}_{g'}(R_{i,g'})}{\operatorname{std}_{g'}(R_{i,g'})+\epsilon_s}

(2)

つまり、学習に使うのは報酬の絶対値ではなく同じ問題を解いた仲間内での相対的な立ち位置だけ、ということです。全員が高得点になる易しい問いでも、全員が低得点の難しい問いでも、同じ強さの信号を取り出せます。

$R_{i,g}$ は候補に付いたスカラー報酬、meanとstdは同じプロンプトから作った $G$ 個の報酬の平均と標準偏差、 $\epsilon_s$ はゼロ割りを避ける小さな定数です。「同じ問題に取り組んだ兄弟の中で、平均よりどれだけ良かったか」を偏差値のように測っている、と読めば十分です。

落とし穴は、 $G$ 個の報酬が全部同じだと分子がゼロになり学習信号が消えることです。論文は群ごとの報酬分散を見て、ほぼゼロの群だけ生成設定を変えるかプロンプトを書き換えて再生成します（生成はvLLM、§4.1）。動かすのは温度のような生成側のつまみです。

FIG 2温度を上げれば候補はばらけ、下げれば1つに尖る。報酬分散がほぼゼロの群を作り直すとき動かすのは、この側のつまみ

報酬はタスク条件付きルーティングで選ばれます（§4.2）。各報酬関数 $f_j$ は適用可能なタスク集合 $\mathcal{T}_j$ を宣言し、その例のタスクがそこに入るときだけ評価され、適用外は無効値として集約前に捨てられます。

v_{i,g,j}=\mathbf{1}\!\left[t_i\in\mathcal{T}_j\ \land\ \operatorname{valid}(r_{i,g,j})\right],\qquad R_{i,g}=\sum_{j:v_{i,g,j}=1}\widetilde{w}_{i,g,j}\,r_{i,g,j}

(3)

つまり、その例に当てはまらない採点基準は0点にするのではなく採点対象から外し、残った基準の重みだけで割り直して合計する、ということです。画面に文字が映っていない例にOCRの減点が飛んでいく、といった事故を防ぐ仕組みだと読めます。

$v$ は「この報酬をこの例に使ってよいか」の0/1の旗、 $r$ は各報酬関数のスコア、 $\widetilde{w}$ は有効な報酬だけで正規化し直した重みです。多肢選択・グラウンディング・OCRはルールベース、自由記述はLLM審判が担当します。

import numpy as np
R = np.array([0.9, 0.9, 0.9, 0.9])          # 同じ群の G=4 個の報酬
A = (R - R.mean()) / (R.std() + 1e-4)       # -> すべて 0。勾配が立たない
if R.std() < 1e-3:                          # 論文の動的リサンプリング
    R = regenerate_group(prompt)            # 生成設定を変えて作り直す

w     = np.array([1.0, 1.0, 0.5])           # 各報酬関数の設定重み
valid = np.array([1,   0,   1])             # このタスクに適用可能か
w_n   = w * valid / (w * valid).sum()       # 有効なものだけで正規化

設定は $G=8$ 、 $\epsilon_s=10^{-4}$ 、クリップ幅が下側 $0.2$ ／上側 $0.28$ 、KL係数 $0.1$ です（付録D.2）。

結果をどう読むか

評価は社内ライブコマース評価スイートと公開の一般ベンチマークの2軸です（§5）。社内評価（§5.1）では、ライブコマースASRのCERが9Bで6.46、4Bで6.66と、Qwen3-Omni（30B-A3B）の6.75を下回ります。話者付きASRのcpWERは9Bが12.27で、Qwen3-Omniの27.84とは大きく開きます（表1）。商品画像のグラウンディングAPは4Bで91.45ですが、ライブ映像側のAPはGemini 3.5 Flashの84.15が上です（4Bは82.85、表2）。動画では9BのTG mIoUが81.49、密キャプションの幻覚率が8.76でした（表3）。

一般ベンチマーク（§5.2）は全勝ではありません。表4の4BはMMMUが70.9で背骨のQwen3.5 4Bの72.1に負け、MathVistaも79.9対81.0。一方でDynaMath（72.5対69.6）やRealWorldQA（77.7対72.5）では上回ります。TimeLens-Bench（表7）では4Bが3ベンチとも9Bを上回っており、大きいほうが常に強いとは限りません。

付録Cの文脈内ASRは実務的です。キーワード候補リストを与えると、9Bはリストなしの recall 48.62 / CER 6.54 から、50語で 81.00 / 5.18 へ改善し、1000語でもCERは5.53にとどまります。比較対象のQwen3-ASR-Flashは1000語でCERが10.68まで悪化しており、長い辞書に足を引っ張られないことが差です（表9）。

論文が正直に書いている限界

論文自身が挙げるのは3点です（§6）。TLive-Omniは理解に絞っており、生成や全二重のリアルタイム対話は扱わない。公開ベンチマークでの評価範囲を広げたい。より長く雑音の多い配信への頑健性と、不完全・曖昧な入力下での時間的証拠の較正を強化したい。

読者側で足しておく注意も3つあります。ひとつ、評価スイートは社内構築のため（§5.1）、外部から同条件で再現できません。ふたつ、音声記述と密キャプションの精度・幻覚率は、生成文だけを読む別のLLM審判が多肢選択に答えて出す値で（付録B）、実務上は審判を変えれば数値も動くと考えるべきです。みっつ、Faithful-RFTのアブレーションは載っておらず、最終性能のうちRFTがどれだけ寄与したかは論文からは判定できません。

現場ではこう使う

想定される担当は、ECや配信基盤のマルチモーダル基盤チームと、モデレーションや商品情報抽出を回す運用側です。

音声を先に文字へ落としきらない。外部ASRの文字列だけを後段へ渡すと、時刻対応と話者の手がかりを捨てます（§2.3）。
見るべきは要求FPSではなく実効FPS。fps=2 と指定しても実効値は2になりません（§2.4の例では1.76）。実際に採ったフレーム番号から秒を逆算しないと、mIoUだけが理由もなく下がります。
文脈内ASRの辞書は「入れるほど良い」ではない。付録Cのとおり、モデルによっては1000語でCERが悪化します。実務上は、リスト長を振って CERとrecallの両方を見るA/Bを先に回すのが安全です。
群の報酬分散を監視する。GRPOを自前で回すなら、分散がほぼゼロの群の比率をダッシュボードに出す。ここが高止まりすると、学習は回っているのに勾配が立ちません。
設計レビューで問われる形: 「音声と映像をどう揃えるか」には、(1) 別々にエンコードして足す、(2) 交互に並べる、(3) 時刻つきグリッドで隣接させる、を並べ、長尺の証拠参照が要るなら(3)、と根拠つきで答える。

前提の埋め合わせには、Whisperはなぜ頑健なのか、動画理解を1から、Instruction Tuning と RLHF が近道です。

まとめ

主張を1行にすると、「モデル設計・データ構築・学習目的・評価プロトコルを、配置先のシナリオに合わせて揃えることが効く」です（§6）。派手な新アーキテクチャではなく、時刻の取り方、凍結の順番、報酬の当て方といった地味な整合を積み上げた論文だ、と読むのが正確でしょう。