memory graphrag sqlite exploration

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

Question

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

Current resolution

未採用（探索のみ、2026-06-14 sandbox experiment/sqlite-memory-graphrag で実測）。データ相性は抜群だが、採用を正当化する差別化が無い。採用判断は出していない。

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]] + 型付きエッジ（supersede/depend/conflict）の authored グラフで、GraphRAG が世間で詰まる「テキストからグラフ抽出」の高コスト工程を構造的にスキップしている。

制約（実測結論）

1. 速度は非問題: memory 規模で純 Python dict BFS が 3-hop 0.008ms、SQLite 索引付き(0.05-0.1ms)より約6-10倍速い。索引付き k-hop はコーパス比例せず近傍サイズ比例（1k〜500k で ~0.07ms 不変）。
2. graph traversal は SQLite 不要・純コードで markdown 透明性を保てる。
3. SQLite/sqlite-vec が要るのはベクトル半分 + 永続 + RAM 超の規模だけ = install 壁もそこに局在（「衝動の芯=graph」と「忌諱=install」は重ならない）。
4. 未測の本丸 = recall の質。eval harness が要る。

結論

• 採用: なし（透明性／差別化ゼロ／install のトレードオフ）。この話題が再燃したら再探索せず本結論から入る。speed 議論に逸れたら「速度は解決済み・本丸は質」に引き戻す。
• sandbox は local throwaway ゆえ結論を本 entry に保存。

関連

• sandbox: experiment/sqlite-memory-graphrag（2026-06-14、local throwaway）