[{"data":1,"prerenderedAt":374},["ShallowReactive",2],{"content-\u002Fcontents\u002Fstructmem-memory":3,"surroundPost-\u002Fcontents\u002Fstructmem-memory":365},{"id":4,"title":5,"body":6,"createdAt":348,"description":349,"draft":350,"extension":351,"meta":352,"navigation":353,"path":354,"seo":355,"stem":356,"tags":357,"thumbnail":363,"updatedAt":348,"__hash__":364},"contents\u002Fcontents\u002Fstructmem-memory.md","StructMem Paper Summary",{"type":7,"value":8,"toc":307},"minimark",[9,13,17,20,23,26,29,32,35,38,41,46,49,53,56,59,63,66,70,73,76,79,82,85,88,91,94,97,100,103,106,109,112,115,118,121,124,127,130,133,136,140,143,146,165,168,185,188,205,209,213,216,220,223,227,230,234,237,241,244,248,251,255,258,262,265,269,272,276,279,283,286,290,293,297,300,304],[10,11,12],"h2",{"id":12},"どんな論文か",[14,15,16],"p",{},"StructMem の問題意識は、長期会話エージェントの記憶を、単なる事実の保存庫として扱うだけでは足りないというところにある。長い対話では、誰が何を言ったかだけでなく、いつ変わったのか、なぜそうなったのか、どの出来事が別の出来事に影響したのかを扱う必要がある。",[14,18,19],{},"既存のフラット記憶は軽いが、履歴を命題の袋として保存するため、出来事どうしの因果、時間依存、人間関係が薄くなる。一方でグラフ記憶は関係を扱えるが、実体抽出、関係抽出、重複除去、更新が重く、抽出ミスが構造ノイズとして残りやすい。",[14,21,22],{},"StructMem はこの間を取る。各発話から、事実の記録と関係の記録を自然言語で抽出し、同じ時刻に結びつける。さらに一定量たまった直近の出来事を、過去の近い出来事と照合し、出来事をまたぐ関係を合成する。",[14,24,25],{},"評価では LoCoMo で Overall 76.82 を示し、特に Temporal は 81.62 と高い。構築コストも 1.937M tokens、1056 calls に抑えられており、グラフ系の重さに対する軽量な構造化記憶として読める。",[14,27,28],{},"ただし、抽出と統合はプロンプト品質に依存する。また論文自身も、矛盾解決や記憶更新の明示的な仕組みは未解決だと述べる。長期運用へ持ち込むなら、StructMem の構造化に加えて、現在有効な状態をどう更新するかを別に設計する必要がある。",[14,30,31],{},"StructMem は、長期会話エージェント向けの記憶システムである。中心の主張は、会話記憶の基本単位を、孤立した事実や厳密なグラフ三つ組ではなく、時間に結びついた関係つきの出来事として扱うべきだというもの。",[14,33,34],{},"この設計では、記憶は単に検索されるテキストではない。あとで検索に引っかかった断片から、同じ時刻の記録をまとめて復元し、さらに出来事をまたぐ統合済みの関係も使えるようにする。",[14,36,37],{},"論文は、フラット記憶の軽さとグラフ記憶の関係表現のどちらかを選ぶのではなく、自然言語の記録項目、時刻、周期的な統合で中間的な構造を作る。",[10,39,40],{"id":40},"課題と貢献",[42,43,45],"h3",{"id":44},"第一の貢献はevent-level-binding-である","第一の貢献は、event-level binding である",[14,47,48],{},"各発話から factual entries と relational entries を抽出し、同じ timestamp に結びつけることで、事実と関係を同じ出来事として扱う。",[42,50,52],{"id":51},"第二の貢献はcross-event-consolidation-である","第二の貢献は、cross-event consolidation である",[14,54,55],{},"直近にたまった記録をまとめて検索クエリにし、過去の近い記録を seed として取り出し、同じ時刻の記録も含めて出来事を復元する。",[14,57,58],{},"第三の貢献は、復元した直近出来事と過去出来事から、出来事をまたぐ関係仮説を LLM で合成すること。これは単なる圧縮要約ではなく、個別記録には明示されない関係を補う層として働く。",[42,60,62],{"id":61},"第四の貢献はグラフ構築を避けた効率性である","第四の貢献は、グラフ構築を避けた効率性である",[14,64,65],{},"実体解決や関係重複除去を連続的に行わず、周期的なバッチ統合にすることで、トークン、API 呼び出し、実行時間を抑える。",[42,67,69],{"id":68},"第五の貢献はlocomo-での比較と切り分けである","第五の貢献は、LoCoMo での比較と切り分けである",[14,71,72],{},"StructMem は複数段質問、単発質問、時間推論で一貫して改善し、単に検索件数を増やすだけでは性能が頭打ちになることも示す。",[10,74,75],{"id":75},"手法のしくみ",[14,77,78],{},"発話を入力にする。各 utterance から LLM により、出来事の内容を表す factual entries と、人間関係、因果、時間依存を表す relational entries を抽出する。",[14,80,81],{},"抽出された記録項目を、元発話の timestamp に結びつける。同じ時刻を持つ記録は同じ出来事に属するため、あとで一部が検索されたときに、出来事全体を復元できる。",[14,83,84],{},"新しく増えた記録項目はすぐに大きく統合せず、buffer にためる。これにより、毎発話ごとの重い処理を避け、近い時間内にまとまった出来事を一括で扱える。",[14,86,87],{},"buffer が一定量を超えると、直近の記録をまとめて embedding query にし、過去の記録から semantically similar な seed entries を top-K で取り出す。",[14,89,90],{},"seed entry だけを見るのではなく、同じ timestamp を持つ全記録を取り出す。これにより、過去の出来事を、事実と関係のまとまりとして復元する。",[14,92,93],{},"直近の出来事と復元した過去の出来事を LLM に渡し、cross-event relational hypotheses を合成する。ここで、複数出来事をまたいだ因果、変化、関係を新しい記録項目として追加する。",[14,95,96],{},"回答時には、通常の出来事レベル記録と、出来事をまたいで作られた統合済み記録を使う。これにより、単発の事実想起だけでなく、時間推論や複数段推論に効く。",[10,98,99],{"id":99},"検証結果",[42,101,102],{"id":102},"総合性能",[14,104,105],{},"LoCoMo の Overall で StructMem は 76.82 を達成し、表中で最高値として報告されている。",[42,107,108],{"id":108},"時間推論",[14,110,111],{},"Temporal は 81.62 で、Zep の 67.71 や Mem0g の 58.13 を上回る。時刻つき出来事と cross-event consolidation が効く領域で強い。",[42,113,114],{"id":114},"構築コスト",[14,116,117],{},"Build Tokens は 1.501M in、0.436M out、合計 1.937M。API calls は 1056、Time は 22854 秒である。",[42,119,120],{"id":120},"グラフ系との比較",[14,122,123],{},"Mem0g は 35.825M tokens、53514 calls、115670 秒であり、StructMem は関係を扱いながら構築コストを大きく抑えている。",[42,125,126],{"id":126},"切り分け",[14,128,129],{},"Flat Memory、Graph Memory、w\u002Fo Cross-Event、StructMem を比べると、StructMem は Multi、Single、Temp で一貫して改善する。",[42,131,132],{"id":132},"検索件数分析",[14,134,135],{},"flat retrieval は検索 entries を増やすと一定点で性能が頭打ちになる。ボトルネックは coverage だけではなく、断片をどう関係づけるかに移る。",[42,137,139],{"id":138},"seed-数分析","seed 数分析",[14,141,142],{},"K=0 では flat retrieval の plateau に近いが、cross-event synthesis を入れると性能が上がる。個別記録には存在しない関係を、統合で作ることが効いている。",[10,144,145],{"id":145},"限界と読みどころ",[147,148,149,153,156,159,162],"ul",{},[150,151,152],"li",{},"dual-perspective extraction の品質は instruction prompt に強く依存する。事実記録や関係記録の抽出が弱ければ、その上の統合も弱くなる。",[150,154,155],{},"StructMem は memory expansion と synthesis を扱うが、conflict resolution と memory updating の明示的な仕組みはまだない。ユーザーの事実や好みが変わる長期運用では不整合が残りうる。",[150,157,158],{},"評価は LoCoMo が中心で、個人アシスタント、coding agent、研究エージェント、複数エージェント協調で同じように効くかは追加検証が必要である。",[150,160,161],{},"自然言語の関係記録は柔軟だが、厳密な検証や差分更新には弱い可能性がある。構造を軽くするぶん、どの関係が現在も有効かを別途管理したくなる。",[150,163,164],{},"構築時間や API 呼び出し回数は実装依存がある。モデル、embedding、バッチ処理、保存基盤を変えると、効率比較の見え方も変わりうる。",[10,166,167],{"id":167},"読みながら見る図表や節",[147,169,170,173,176,179,182],{},[150,171,172],{},"Figure 1 は、Flat Memory、Graph Memory、StructMem の3方式を比較する。StructMem は、事実の袋でも重いグラフでもなく、時刻に束ねた出来事と横断統合で関係を扱う中間案として位置づく。",[150,174,175],{},"Figure 2 は、StructMem の処理フローである。Event-Level Binding と Cross-Event Consolidation の2段階で読むと分かりやすい。",[150,177,178],{},"Table 1 は、LoCoMo での性能と構築コストの比較である。Overall、Temporal、Build Tokens、Calls、Time を一緒に見ると、精度だけでなく軽さが主張の一部だと分かる。",[150,180,181],{},"Table 2 は、パラダイム比較と ablation である。cross-event structure が temporal reasoning を押し上げる、という論文の中心主張を確認する表。",[150,183,184],{},"Figure 3 は、効率と内部分析である。グラフ構築のトークン増加、検索件数の頭打ち、semantic retrieval seed の効果をまとめて見るための図である。",[10,186,187],{"id":187},"次に読むなら",[147,189,190,193,196,199,202],{},[150,191,192],{},"Memanto と並べると、StructMem の『関係を事前に統合する』方向と、Memanto の『型と高再現率検索で広めに読ませる』方向の違いが見える。",[150,194,195],{},"OCR-Memory と並べると、構造化で落ちる情報をどう元ログへ戻すか、という別の問題が見える。",[150,197,198],{},"STALE と並べると、StructMem が弱い conflict resolution や現在状態判定を補う視点が得られる。",[150,200,201],{},"EvolveMem と並べると、記憶構造そのものを固定せず、失敗ログから検索や統合の方針を育てる方向へ広げられる。",[150,203,204],{},"実務に引くなら、まず『出来事単位で保存するもの』と『週次や月次で統合するもの』を分け、さらに現在有効な状態を別レイヤーで管理するのが入口になる。",[10,206,208],{"id":207},"読後qa","読後Q&A",[42,210,212],{"id":211},"この論文の中心問いは","この論文の中心問いは？",[14,214,215],{},"長期会話エージェントの記憶を、軽いフラット記憶と重いグラフ記憶のどちらかではなく、出来事単位の構造として作れないか、という問いである。",[42,217,219],{"id":218},"structmem-は何を提案している","StructMem は何を提案している？",[14,221,222],{},"発話から事実記録と関係記録を抽出し、同じ時刻に束ね、さらに過去の近い出来事と統合して、出来事をまたぐ関係記録を作る階層的な記憶フレームワークである。",[42,224,226],{"id":225},"フラット記憶の弱点は","フラット記憶の弱点は？",[14,228,229],{},"軽く保存できる一方で、履歴を独立した事実の集合として扱うため、時間依存、因果、人間関係、複数段推論に必要な文脈が薄くなる。",[42,231,233],{"id":232},"グラフ記憶の弱点は","グラフ記憶の弱点は？",[14,235,236],{},"関係を表現できるが、実体抽出、関係抽出、重複除去、更新が重い。さらに抽出ミスがグラフ構造のノイズとして残りやすい。",[42,238,240],{"id":239},"何が構造化なの","何が『構造化』なの？",[14,242,243],{},"グラフデータベースのノードとエッジを作ることではない。事実記録と関係記録を同じ時刻に束ね、出来事どうしをあとから統合することが、この論文での構造化である。",[42,245,247],{"id":246},"event-level-binding-とは","event-level binding とは？",[14,249,250],{},"各発話から抽出した factual entries と relational entries を、元発話の timestamp に結びつけること。同じ時刻の記録をまとめて復元できるようにする。",[42,252,254],{"id":253},"cross-event-consolidation-とは","cross-event consolidation とは？",[14,256,257],{},"直近にたまった記録をまとめて検索クエリにし、過去の近い出来事を復元し、直近出来事と過去出来事の間にある関係を LLM で合成すること。",[42,259,261],{"id":260},"単なる要約と何が違う","単なる要約と何が違う？",[14,263,264],{},"逐次テキストを圧縮するのではなく、意味的に関連する出来事クラスターを復元してから、出来事間の関係仮説を作る。元の episodic memory も残す点が違う。",[42,266,268],{"id":267},"評価では何が良かった","評価では何が良かった？",[14,270,271],{},"LoCoMo で Overall 76.82、Temporal 81.62 を達成し、特に時間推論で強い。構築トークンや API 呼び出しもグラフ系よりかなり少ない。",[42,273,275],{"id":274},"なぜ検索件数を増やすだけでは足りない","なぜ検索件数を増やすだけでは足りない？",[14,277,278],{},"flat retrieval は一定件数を超えると性能が頭打ちになる。必要なのは断片の量だけではなく、断片どうしをどう関係づけるかだからである。",[42,280,282],{"id":281},"一番の限界は","一番の限界は？",[14,284,285],{},"記録抽出と統合がプロンプト品質に依存すること。また、古い情報と新しい情報がぶつかった時の矛盾解決や記憶更新は明示的には扱われていない。",[42,287,289],{"id":288},"個人アシスタント運用に持ち込むなら","個人アシスタント運用に持ち込むなら？",[14,291,292],{},"日々の作業や読書推薦を出来事単位で残し、週次で関連出来事を統合すると効きそう。ただし、現在有効な状態や古くなった前提は別レイヤーで管理する必要がある。",[42,294,296],{"id":295},"memanto-と比べると","Memanto と比べると？",[14,298,299],{},"StructMem は出来事間の関係を事前に合成する方向。Memanto は型つき記憶と高再現率検索で広めに取り出し、強いモデルに読ませる方向である。",[42,301,303],{"id":302},"一言でいうと","一言でいうと？",[14,305,306],{},"memory は、似たメモを探す倉庫ではなく、後で出来事の関係ごと復元できるように作ると強い。",{"title":308,"searchDepth":309,"depth":309,"links":310},"",2,[311,312,319,320,329,330,331,332],{"id":12,"depth":309,"text":12},{"id":40,"depth":309,"text":40,"children":313},[314,316,317,318],{"id":44,"depth":315,"text":45},3,{"id":51,"depth":315,"text":52},{"id":61,"depth":315,"text":62},{"id":68,"depth":315,"text":69},{"id":75,"depth":309,"text":75},{"id":99,"depth":309,"text":99,"children":321},[322,323,324,325,326,327,328],{"id":102,"depth":315,"text":102},{"id":108,"depth":315,"text":108},{"id":114,"depth":315,"text":114},{"id":120,"depth":315,"text":120},{"id":126,"depth":315,"text":126},{"id":132,"depth":315,"text":132},{"id":138,"depth":315,"text":139},{"id":145,"depth":309,"text":145},{"id":167,"depth":309,"text":167},{"id":187,"depth":309,"text":187},{"id":207,"depth":309,"text":208,"children":333},[334,335,336,337,338,339,340,341,342,343,344,345,346,347],{"id":211,"depth":315,"text":212},{"id":218,"depth":315,"text":219},{"id":225,"depth":315,"text":226},{"id":232,"depth":315,"text":233},{"id":239,"depth":315,"text":240},{"id":246,"depth":315,"text":247},{"id":253,"depth":315,"text":254},{"id":260,"depth":315,"text":261},{"id":267,"depth":315,"text":268},{"id":274,"depth":315,"text":275},{"id":281,"depth":315,"text":282},{"id":288,"depth":315,"text":289},{"id":295,"depth":315,"text":296},{"id":302,"depth":315,"text":303},"2026-05-19","この論文は、長期会話エージェントの記憶を、孤立した事実のメモではなく、時刻つきの出来事と出来事どうしの関係として構造化する。フラット記憶とグラフ記憶の間で、関係つきの長期記憶を軽く作るための一本。",false,"md",{},true,"\u002Fcontents\u002Fstructmem-memory",{"title":5,"description":349},"contents\u002Fstructmem-memory",[358,359,360,361,362],"論文まとめ","ACL 2026 main","agent memory","event-level binding","cross-event consolidation","\u002Farticle-pages\u002Fdocs\u002Fassets\u002Fgraphic-recordings\u002Fstructmem-memory.png","sgQadvsluYpurrbgnvVjSzQRgJMsIgYkwLLCzZzj-Uw",[366,370],{"title":367,"path":368,"stem":369,"children":-1},"Streamlit 入門: 表示、インプット、複数ページの構成方法","\u002Fcontents\u002Fstramlit","contents\u002Fstramlit",{"title":371,"path":372,"stem":373,"children":-1},"TAHOE: Text-to-SQL with Automated Hint Optimization from Experience","\u002Fcontents\u002Ftahoe-text-to-sql-hint-optimization","contents\u002Ftahoe-text-to-sql-hint-optimization",1782055099033]