スーパーローカルメモリ（SuperLocalMemory V3）紹介レポート

makokon

スーパーローカルメモリ（SuperLocalMemory V3）紹介レポート

こんにちは、makokonです。
記憶検索といえばコサイン類似度、記憶忘却管理といえば半減期、メモリはたくさん残しておくほうがいい。そんな当たり前とされていた記憶設計の問題を取り上げます。
このレポートは、数値ベンチマークの優劣を語る資料ではなく、
「長期運用で劣化しがちな“記憶”を、どう作り替えるか」 を、実装イメージと理論イメージの両面から掴めることを目的にします。

記事では、次の“ありがちな設計”を出発点に、SuperLocalMemory（以下 SLM）が何を変えたのかに焦点を当てます。

（読み返していたら論文リンクがなかったので追加。申し訳ありません。）


1. 問題意識：エンジニアリングの「単一文化」が生む劣化

多くのメモリ/検索設計が、暗黙に次の前提で作られています。

  • 記憶検索 = コサイン類似度

  • 忘却/寿命 = 半減期（指数減衰）や TTL

  • 記憶 = 基本は公平に残す（重要度の差別化が弱い）

しかしこの設計だと、長期運用で以下が起こります。

  • 記憶が増えるほど検索精度が下がる（近傍が混雑しノイズが増える）

  • 役立つ情報も役に立たない情報も同じ重み（重要度の学習/構造化が弱い）

  • 矛盾に気づけない（更新された事実と古い事実を同列に返す）

結果として、メモリは「使うほど役に立たないデータ湖」になりがちです。

SLM V3 はこの状況を、数学的な道具で“構造から”直すことを狙っています。

2. SuperLocalMemory V3 のコアアイデア（3本柱 + 4チャネル）

SLM の設計はシンプルに言うと、次の合成です。

  1. 単一検索手段を捨て、4チャネル検索して融合する（Semantic / BM25 / Entity Graph / Temporal）

  2. その上で、長期運用で効いてくる3つの数学レイヤで「劣化」を抑える

    • Fisher–Rao（情報幾何）: “確からしさ”で類似度を重みづけ

    • Sheaf（層コホモロジー）: 矛盾を代数的に検出

    • Langevin（リーマン多様体上の確率力学）: 寿命を半減期ではなく力学系で管理

2.1 全体像


3. 4チャネル検索：検索精度を「単一スコア」から救い出す

SLM は recall 時に 4つの独立チャネルで候補を作り、融合（RRF） します。
この４つのアプローチによって、ベクトル検索の取りこぼしを保管します。


3.1 Retrieval Pipeline

3.2 実装の勘所（開発者目線）

「まず候補を取りこぼさない」 のがチャネル分割の価値です。

  • ベクター検索だけだと、設定値/固有名詞を落とす → BM25 で補う

  • BM25だけだと、言い換えで落とす → Semantic で補う

  • 「誰が何を承認した？」のような関係質問を落とす → Entity Graph で補う

  • 「いつ決めた？」を落とす → Temporal で補う

このあとに数学レイヤが効いてきます。

数学レイヤ

ここでは数学レイヤにおける意味を説明します。詳細な理論、数式には踏み込まないつもりです。

4. 数学レイヤ 1: Fisher–Rao（情報幾何）で「確からしさ」を類似度に入れる

コサイン類似度によるベクトル距離だけでは、情報の重要度が区別できません。このベクトルを点ではなく各リブ分布とすることで、確度の高い情報の検索を可能にします。

4.1 何が問題？（コサイン類似度の盲点）

コサイン類似度は、埋め込みベクトルの各次元を 等価に扱うため、
次が表現できません。

  • 「この記憶は何度も再利用され、確度が高い」

  • 「この記憶は一度だけ入ってきた、未検証の情報」

4.2 SLM の考え方（“ベクトル点”ではなく“確率分布”として見る）

SLM は、記憶の埋め込みを 対角ガウス N(μ, diag(σ²)) として扱い、
次元ごとの分散（不確実性） を持たせます。

  • 重要/安定な次元 = 分散が小さい（確度が高い）

  • ノイズっぽい次元 = 分散が大きい（確度が低い）

このとき Fisher 情報（情報幾何の計量）に基づく距離（Fisher–Rao）が、
「不確実性に応じた距離」を作ります（論文 Theorem 6.1）。

4.3 開発者に効く直感（同点の混雑をほどく）

コサインだと同点になりがちな候補でも、
「確度の高い次元で近い方」を上げることで、
長期運用でのノイズ混入を抑えます。

4.4 擬似コード（Fisher重みつき類似度）

def fisher_weighted_similarity(mu_q, mu_m, sigma2_m, T=1.0):
    """論文の実装近似: exp(- sum((dq^2)/sigma2)/T )"""
    # dq = query embedding - memory embedding
    dq = mu_q - mu_m
    # sigma2_m: 記憶ごとの次元分散（小さいほど確度が高い）
    dist = (dq * dq / (sigma2_m + 1e-9)).sum()
    return math.exp(-dist / T)


def effective_similarity(mu_q, mem):
    # cold start: アクセス履歴が少ない間は cosine を混ぜる（graduated ramp）
    alpha = min(mem.n_access / 10.0, 1.0)
    return (1 - alpha) * cosine(mu_q, mem.mu) + alpha * fisher_weighted_similarity(mu_q, mem.mu, mem.sigma2)

5. 数学レイヤ 2: Sheaf（層コホモロジー）で「矛盾」を検出する

コサイン類似度の世界では、新しい情報と古い情報の区別がつきません。
そして、現実の実装では、必ず新しい情報と古い情報が矛盾する状況が発生します。
コモホロジーでは、層を利用して、矛盾した記憶を検知すると、最新の真実を返すようにする機能を実現します。

5.1 何が問題？（矛盾は“必ず”溜まる）

実運用では、次のような矛盾が必ず発生します。

  • 仕様変更: 「DBはPostgreSQL」→「MySQLへ移行した」

  • 人の嗜好変更: 「AさんはXが好き」→「今はY」

  • 情報源衝突: Slackの発言 vs チケットの正式決定

コサイン検索だけの世界では、矛盾が検出されず、
「たまたま上位に来た方」が真実として使われることが起きます。

5.2 SLM の要点（局所整合の“貼り合わせ失敗”を検出する）

SLM はコンテキスト（プロジェクト/トピック）を頂点、共有関係を辺にしたグラフ上で、
記憶の主張を“層（sheaf）”として配置し、
H¹ ≠ 0 を矛盾の代数的サインとして扱います。

実装的には、

  • エンティティ共有などで候補を絞り（スパースにする）

  • しきい値超えの矛盾を検出したら SUPERSEDES（上書き） 関係を張る

ことで、Recall 時に古い情報を自動的に降格できます。

5.3 矛盾→上書きの流れ


5.4 擬似コード（矛盾検知の実装イメージ）

def consistency_check(new_fact, candidate_facts):
    """実装イメージ: 実コードは sheaf.py に相当。ここでは概念化。"""
    # 1) エンティティ共有/同一topicで候補を絞る（O(n^2)回避）
    related = [f for f in candidate_facts if share_entities(new_fact, f)]

    # 2) 局所整合→グローバル整合の失敗量 κ を計算（coboundary norm）
    kappa = coboundary_norm(new_fact, related) / (section_norm(new_fact, related) + 1e-9)

    # 3) しきい値超えなら上書き関係を付与
    if kappa > 0.45:
        for old in related:
            if is_contradiction(new_fact, old):
                create_edge(type="SUPERSEDES", src=new_fact.id, dst=old.id)
        return {"status": "contradiction", "kappa": kappa}
    return {"status": "ok", "kappa": kappa}

6. 数学レイヤ 3: Langevin（確率力学）で「忘却」を半減期から解放する

記憶を無限に蓄えることは現実的ではありません。そして、多くのメモリシステムでは、これを時間によって減衰する半減期モデルで実現しています。しかし、情報の寿命は、情報の種類によって変化するために、手動で調整する必要があります。ここでは、記憶の価値に応じて寿命を動的に管理するアプローチを説明します。

6.1 何が問題？（半減期/TTLは運用が破綻しやすい）

半減期は分かりやすい一方で、

  • プロジェクトごと・情報種別ごとの“寿命”を人が決め続ける必要がある

  • 記憶の価値（頻度・再利用・信頼度）に追随できない

という運用問題に直面します。

6.2 SLM の要点（「アクセスされるものは中心へ、されないものは外へ」）

論文では、Poincaré ball 上でのリーマン的 Langevin Dynamics を使い、
確率微分方程式が 定常分布に収束する（Theorem 6.3）ことを示しています。

実装の感覚としては、（ありがちなイメージですが）

  • よく使われる記憶: Active/Warm に居続ける

  • 使われない記憶: ノイズに押され Cold/Archived 側へ自然に流れる

という“自己組織化”です。

6.3 ライフサイクル状態機械


6.4 擬似コード（Langevin更新の実装イメージ）

def langevin_step(xi, access_count, recency, relevance, dt=0.01, T=1.0):
    """概念化: 実装は langevin.py / fisher_langevin_coupling.py に相当"""
    # potential U: 重要度（アクセス頻度/関連度/最近度）を“エネルギー”にする
    U = alpha * (xi.norm() ** 2) - beta * access_count - gamma * relevance + delta * recency_penalty(recency)
    gradU = grad(U, xi)

    # ざっくり: xi <- xi - gradU*dt + noise
    xi_next = xi - gradU * dt + math.sqrt(2 * T * dt) * randn_like(xi)

    return project_to_ball(xi_next)  # ||xi|| < 1 に投影

7. Ingestion（記憶の取り込み）: “公平に残す”ではなく“価値を選別して残す”

SLM は、remember/auto-capture したテキストを 11ステップで処理し、
複数インデックスへ同時に格納します（docs/ARCHITECTURE.md）。

7.1 Ingestion Pipeline

ノイズ、依存関係、矛盾などを選別し、適切な記憶を構造化して記録することが大切です。
この部分が放置されると、短期的には使えますが、長期運用すると必ず不具合が発生します。

7.2 擬似コード（store の全体像）

def store_memory(content, metadata):
    # 1) embed
    mu = embed(content)

    # 2) extract structured signals
    entities = extract_entities(content)
    facts = extract_facts(content)
    temporal = parse_temporal(content, metadata)

    # 3) build indexes
    bm25_tokens = tokenize_for_bm25(content)
    graph_edges = wire_graph(entities, facts)

    # 4) math layers state
    sigma2 = estimate_uncertainty(mu)  # Fisher layer state
    xi = init_lifecycle_state()         # Langevin layer state

    # 5) consistency
    contradictions = consistency_check(facts, lookup_related_facts(entities))

    # 6) entropy gate（価値が低ければ保存しない）
    if information_value(content, facts, entities) < CAPTURE_THRESHOLD:
        return None

    # 7) persist to SQLite (WAL)
    memory_id = db.insert_memory(content, mu=mu, sigma2=sigma2, xi=xi, metadata=metadata)
    db.insert_entities(memory_id, entities)
    db.insert_facts(memory_id, facts)
    db.insert_bm25(memory_id, bm25_tokens)
    db.insert_temporal(memory_id, temporal)
    db.insert_graph_edges(graph_edges)
    db.insert_contradiction_edges(contradictions)
    db.append_audit("store", memory_id)

    return memory_id

8. データモデル（SQLite）: “ベクタストアだけ”ではない

SLM は SQLite 1本に、検索と運用のための状態をまとめます。
（docs/ARCHITECTURE.md ではテーブル群のカテゴリが言及されています）
このシステムによって外部のベクタストアへの依存を排除し、マルチインデックスによるデータの統合、ポータビリティを実現することができます。

8.1 データモデル概略

ポイント:

  • “検索”と“運用”（監査、保持、プロファイル隔離、矛盾解消）を、同じ永続層で扱う

  • ベクター類似だけでなく、BM25/グラフ/時系列も同居

ＳＬＭの評価結果

SLM（SuperLocalMemory）V3の評価結果について、LoCoMoベンチマークに基づいた主な成果を定性的に簡潔に説明します。

  • 従来手法を上回る検索精度: SLM V3は、コサイン類似度や単純な指数減衰といった従来のエンジニアリング手法のみを用いたベースラインと比較して、検索の質が大幅に向上しています。

  • 数学的レイヤの有効性: 情報幾何（Fisher情報量）、代数トポロジー（層コホモロジー）、確率力学（Langevin力学）を導入した数学的基盤が、精度の向上に直接的に寄与していることが確認されました。

  • 困難な課題での高い優位性: 単純な事実確認よりも、記憶が疎に点在する複雑な対話や推論が必要な場面において、数学的アプローチによる改善効果がより顕著に現れる傾向があります。

  • ローカル動作での競争力: クラウドLLMに依存しない完全ローカル構成（Mode A）であっても、クラウドを利用する既存の主要なメモリシステムを凌駕する検索精度を達成しています。

  • 特定カテゴリでの強み: 特にオープンドメインの質問や、時間の経過を考慮した推論が必要なタスクにおいて、極めて高い性能を示しています。

  • 実用性と法適合性の両立: 高い検索性能を維持しながら、データがデバイス外に出ない設計を実現しており、EU AI法などの厳格な規制要件を満たせることが実証されました。

ＳＬＭのコンプライアンス対応と３つの運用モード

SuperLocalMemory V3（SLM）のコンプライアンス対応と3つの運用モードについて、ソースに基づき簡潔に説明します。

1. コンプライアンスへの対応

SLMは、特に**EU AI法（Regulation (EU) 2024/1689）やGDPR（一般データ保護規則）**を遵守するように設計されています。

  • データ主権の確保: ローカル動作（Mode A/B）では、個人データがユーザーのデバイス外に出ない「アーキテクチャ上の設計」により、強力なデータ主権を実現しています。

  • 規制への適合性: 2026年8月から全面施行されるEU AI法のデータガバナンス要件（第10条）や、GDPRの消去権（第17条）に対応する機能を備えています。

  • 監査と透明性: 改ざん防止のためのSHA-256ハッシュチェーンによる監査トレイルや、データの出所を追跡するプロバンス（由来）トラッキング機能を内蔵しています。

2. 3つの運用モード

SLMは、プライバシー保護と処理能力のバランスに応じて、以下の3つのモードを提供しています。


Mode AおよびBは、ネットワーク接続がない環境（エアギャップ環境）や、厳格なプライバシーが求められる企業利用に適しており、クラウドLLMに依存せずに高い検索精度を維持できる点が最大の特徴です。

9. 実装・導入の最短ルート（CLI/MCP/Python）

9.1 CLI（5分で動かす）

npm install -g superlocalmemory
slm setup

slm remember "The project uses PostgreSQL 16 on port 5433"
slm recall "database port"
slm status


9.2 MCP設定（IDE側）

{
  "mcpServers": {
    "superlocalmemory": {
      "command": "slm",
      "args": ["mcp"]
    }
  }
}

9.3 開発者が便利なコマンド

  • slm trace "..." : チャネル別の寄与を見る（デバッグに重要）

  • slm health : Fisher/Sheaf/Langevin の状態を診断

  • slm consistency : 矛盾検査を明示実行

  • --json : agent-native envelope で機械処理しやすい

10. どんなチーム/プロダクトに刺さるか（実装の現場の観点）

10.1 向いている

  • IDE常駐型のAI支援（「決定」「バグ原因」「環境」「手順」を覚える）

  • 規制/監査がある現場（EU AI Act / GDPR / HIPAA等の要件で “データを出せない”）

  • 長期のプロジェクト（数ヶ月〜年単位で“決定の履歴”が効く）

10.2 導入時の設計チェックリスト

  • どこまでローカル完結が必要？ → Mode A/B/C の選択

  • プロファイル設計（顧客/案件/環境）をどう切る？

  • retention（保持期間）をどう定義する？

  • 「矛盾の扱い」を運用でどう回す？（警告/自動上書き/人手レビュー）

  • trace を使って、検索ノイズの原因を特定できる体制か？

11. まとめ：SLM が“メモリ”をメモリらしくする点

コサイン類似度 + 半減期 + 公平保存という単一文化から抜け出し、

  1. 検索は1本にしない（4チャネル + 融合）

  2. 確からしさ（不確実性）をランキングに入れる（Fisher）

  3. 矛盾を放置しない（Sheaf → SUPERSEDES）

  4. 忘却を“定数”で決めない（Langevin）

という設計へ振り切っている点が、SLM の本質です。

付録A: 資料管理用 日本語ハッシュタグ（重要キーワード）

#スーパーローカルメモリ #SuperLocalMemory #エージェントメモリ #長期記憶 #永続メモリ #情報幾何 #FisherRao #不確実性推定 #類似検索 #コサイン類似度限界 #層コホモロジー #SheafTheory #矛盾検知 #一貫性管理 #知識グラフ #LangevinDynamics #忘却設計 #ライフサイクル管理 #EntropyGate #RRF #BM25 #ハイブリッド検索 #MCP #CLIツール #SQLite #WAL #プロファイル分離 #GDPR #EUAIAct #監査ログ #データ主権 #ローカルファースト

付録B: 参照ファイル（リポジトリ内）

  • docs/ARCHITECTURE.md

  • docs/getting-started.md

  • docs/cli-reference.md

  • docs/mcp-tools.md

  • wiki-content/V3-Mathematical-Foundations.md

  • src/superlocalmemory/math/fisher.py

  • src/superlocalmemory/math/sheaf.py

  • src/superlocalmemory/math/langevin.py


いいなと思ったら応援しよう！