論文解説: VoiceMem — 音声対話に「左脳と右脳」の記憶を、遅延ゼロで

リアルタイム音声対話に記憶を持たせるVoiceMemを1から解説。事実を扱う「左脳」と人柄・感情を扱う「右脳」を並列に置き、VADが待つ無音の中に検索を隠すことで、top-5という極小の予算のまま精度を上げる仕組みを読み解く。

VoiceMem: Streaming Dual-Brain Memory for Real-Time Interaction

毎朝「はじめまして」になる相棒

行きつけの喫茶店のマスターは、あなたが来た瞬間に「いつもの?」と言います。それは前回何を頼んだかを覚えているからだけではありません。先週あなたが仕事の話をするとき少し声が硬かったこと、猫の話になると急に饒舌になること——そういう人柄の側の記憶も同時に持っているからです。

いまの音声アシスタントは、この二つをどちらも持っていません。その場の会話は驚くほど自然にこなすのに、電源を切れば全部忘れる。毎朝が「はじめまして」です。

論文 VoiceMem は、この欠落を「魂がない (lack ... as their soul)」と表現します (§1)。そして解決策として、事実を扱う左脳と感情・人柄を扱う右脳を並列に置き、その検索を会話の沈黙の中に隠すというアーキテクチャを提案しました。以下、前提知識ゼロから順に追っていきます。

なぜ「記憶を足すだけ」では済まないのか

テキストのAIエージェントに長期記憶を持たせる仕組みは、すでにいくつもあります。Mem0、Zep、LangMem、A-MEM、MemOS、MemoryBank、EverMemOS——論文はこれら10システムを比較対象に並べています (§5.1)。ではそれを音声アシスタントに繋げば終わりかというと、そうはいきません。論文は3つの障害を挙げます (§1)。

(O1) 情報と感情を1つの構造で扱えない。 リアルタイム対話では「何があったか」と同じくらい「この人はどういう人か」が効きます。しかし既存の記憶システムは情報中心で、感情はせいぜい検索の重み付けに混ぜられる程度でした (Appendix A)。

(O2) 遅延ゼロで情報密度を上げる必要がある。 ここが一番きつい制約です。既存の記憶システムは検索に2〜3秒かかりますが、自然な会話が許す追加遅延は100〜200ミリ秒しかありません (§3.1)。しかも、テキストエージェントで一般的な「上位100件を取ってきて後段に丸投げ」は、文脈長の限られた音声言語モデル (SLM) には入りません。上位5件のまま精度を出す必要がある、というのが論文の出発点です。

(O3) 土台が動き続ける。 記憶手法も音声対話モデルも進化が速い。特定のバックエンドと密結合すると、翌月にはもう古くなります。

直感: 「よく探す」より「探す場所を狭める」

検索の話から入ります。従来のRAG（検索拡張生成）は、質問と記憶を同じベクトル空間に埋め込み、似ているものを上から $K$ 件取ってきます。

式(1)を日本語に言い換えると「時刻 $t$ の質問 $q_t$ を埋め込みモデル $f_\theta$ でベクトルに変え、記憶ストア $\mathcal{M}_t$ の中の全記憶 $m_i$ と似ている度合いを測り、上位 $K$ 件を返す」です。$\operatorname{sim}$ は内積やコサイン類似度、$\mathcal{R}$ は返ってきた記憶の集合を指します。仕組みとしてはこれだけで、Mem0 や Zep はこの上に「書き込み」「更新」を足したものだと論文は整理しています (§2)。

問題は、$K=5$ に絞った瞬間に何が起きるかです。論文の指摘はこうです (§3.1)。

検索予算が上位5件のように小さいとき、性能を決めるのは候補空間の意味的な密度であって、ランキングの巧妙さではない。

たとえば「猫」という同じ実体に紐づく記憶が、無関係な文脈のものまで含めて何十件もストアにあると、それだけで上位5枠が埋まってしまいます。似ているけれど役に立たない記憶が席を占領するわけです。だから VoiceMem は、ランキングを改良するのではなく、ランキングにかける前に候補プールを絞るという方向に進みました。

下の図で、この「上位k件の顔ぶれは何で決まるか」を手で動かして確かめてみてください。クエリを動かすと、距離の測り方ひとつで返ってくる文書が入れ替わります。候補プールが濁っていると、どんな測り方をしても上位5件が埋まってしまう感覚が掴めるはずです。

左脳: スキーマと実体の二層インデックス

VoiceMem の左脳は、記憶の実体（本体）を持ちません。記憶そのものはバックエンド（実装では Mem0）に置いたまま、その上に軽量な意味インデックスだけを載せます (§3.1)。

インデックスは二層です。上がスキーマ (schema)、下が実体 (entity)。

式(2)を言い換えます。$\mathcal{S}$ がスキーマの集合、$\mathcal{V}$ が実体の集合、$\mathcal{E}$ が辺（つながり）の集合。実体 $v$ は「テキストの説明 $d_v$」「近い実体へのリンク $\mathcal{N}^{\mathrm{micro}}_v$」「バックエンドの記憶項目への索引 $\mathcal{I}_v$」の3つ組です。スキーマ $s$ も同様に、説明・近いスキーマへのリンク・所属する実体の集合を持ちます。実体はちょうど1つのスキーマに属すると決めてあり、スキーマと実体を結ぶ辺をわざわざ張りません。再帰的にグラフを辿らずに済み、検索が短く終わるからです。

日常語に落とすと、スキーマは「日常生活」「仕事」「健康」「人間関係」といった棚、実体は棚に並ぶ「猫のミケ」「転職の面接」といった背表紙、そして背表紙から実際の本（記憶項目）へ索引が伸びている、という構造です。

検索はこう進みます。ユーザーがまだ喋っている最中に、部分的な書き起こしから該当しそうな棚と背表紙を拾い、そこから1ホップだけ広げます。

式(3)は「一致した実体 $\mathcal{V}_t$、一致したスキーマに属する実体 $\mathcal{V}_{\mathcal{S}_t}$、そしてそれらから強いリンク・弱いリンクで1歩隣にある実体、これらを全部合わせたものが拡張後の候補実体集合 $\mathcal{Z}_t$ である」と言っています。$\mathcal{N}_1$ の添字1が「1ホップまで」の意味です。あとは $\mathcal{Z}_t$ に紐づく記憶項目だけを集めて、その中で普通のベクトル検索をかけます。全記憶 $\mathcal{M}$ は探しません。

擬似コードにすると、やっていることはこれだけです。

hit_v, hit_s = match(partial_transcript, entities, schemas)  # 発話中に随時
zone = hit_v | entities_of(hit_s)                            # 棚の中身を回収
zone |= hop1(zone, "strong") | hop1(zone, "weak")            # 1ホップだけ拡張
pool = union(index_of(z) for z in zone)                      # 候補プール
top5 = mem_search(query_embed, pool, K=5)                    # ここで初めて類似度

更新は会話の裏側（クリティカルパスの外）で非同期に走り、新しい事実を近くの記憶と突き合わせて add / update / delete / keep のいずれかに落とします (§3.1)。なお論文本文は、この更新器の詳細を付録に送ると書いていますが、公開されている付録は別の2つのアブレーションで占められており、更新器の実装詳細はこの論文からは読み取れません。