memory graphrag sqlite exploration - Liplus-Project/liplus-language GitHub Wiki

memory / Decision Structure の GraphRAG(SQLite) 化技術探索

Question

memory / Decision Structure を SQLite ベースの GraphRAG として実装するか。

Current resolution

未採用（探索のみ）。2026-06-14 sandbox experiment/sqlite-memory-graphrag で静的な GraphRAG / SQLite 化を実測し、2026-07-28 に動的連想メモリ（使用結果による結合強化、時間減衰、活性伝播）まで探索範囲を広げた。データ相性と実装可能性は高いが、現行規模では複雑性を正当化する必要性が立っていない。将来の再評価候補であり、却下ではない。

Edges

depends on: liplus-evaluation-criterion — 未測の本丸 = recall の質（top-k 単独 vs graph 近傍）。eval harness が要り、Li+ の評価自動化問題と同型
relates to: ace-context-engineering-non-adoption / dynamic-workflows-non-adoption — 外部技術の非採用 verdict 群

背景

データ相性が抜群な理由 = Li+ の知識は最初から [link](/Liplus-Project/liplus-language/wiki/link) + 型付きエッジ（supersede/depend/conflict）の authored グラフで、GraphRAG が世間で詰まる「テキストからグラフ抽出」の高コスト工程を構造的にスキップしている。

動的連想メモリ案では、検索ヒットそのものではなく、実際の使用と対話上の成否を別カウンタとして保持する。活性度だけを時間減衰させ、知識の確信度とは分離する。全件の日次更新は不要で、last_updated から検索時に実効強度を遅延計算できるため、最小実装は GNN を要せず重み付きグラフで成立する。

制約（実測結論）

速度は非問題: memory 規模で純 Python dict BFS が 3-hop 0.008ms、SQLite 索引付き(0.05-0.1ms)より約6-10倍速い。索引付き k-hop はコーパス比例せず近傍サイズ比例（1k〜500k で ~0.07ms 不変）。
graph traversal は SQLite 不要・純コードで markdown 透明性を保てる。
SQLite/sqlite-vec が要るのはベクトル半分 + 永続 + RAM 超の規模だけ = install 壁もそこに局在（「衝動の芯=graph」と「忌諱=install」は重ならない）。
未測の本丸 = recall の質。eval harness が要る。
retrieved と success を同一視すると、既に検索されやすい記憶が自己増幅する。強化信号には使用結果が必要。
減衰対象は recall 上の活性度であり、知識の正しさではない。検証済みだが低頻度な規則を時間だけで無効化しない。
実装可能であること自体は採用理由にならない。現行の markdown + RAG で観測可能な不全が出るまでは、動的状態・更新規則・評価面の追加コストが便益を上回る。

結論

採用: 現時点ではなし。静的 GraphRAG は透明性／差別化ゼロ／install のトレードオフ、動的連想メモリは必要性未成立を理由に保留する。
再評価条件: (a) 現行検索で同種の recall 失敗が反復する、(b) 複数ユーザー間の汎用層と個人層の分離が実運用課題になる、(c) flat な記憶の保守コストが観測される、(d) recall 品質を比較できる eval harness が成立する、のいずれか。
この話題が再燃したら再探索せず本結論から入る。speed 議論に逸れたら「速度は解決済み・本丸は質」に引き戻す。
sandbox は local throwaway ゆえ結論を本 entry に保存。