Neuron Graph RAG 統合プロトタイプ

Question

Li+ の判断履歴から必要な少数の原典を低コストで選ぶため、ハイブリッド検索・型付きグラフ・動的連想メモリをどの形で検証するか。

Current resolution

Neuron Graph RAG を独立した公開リポジトリで統合RAGエンジンとして試作する。既存の github-rag-mcp に動的グラフ層だけを追加するのではなく、dense / sparse 検索、型付き知識グラフ、活性伝播、成功フィードバックによる結合強化、時間減衰を一つの検索パイプラインとして設計する。

Li+ の現行 Wiki 周辺には RAG、グラフ、LLM Wiki の各コンセプトが別々の経路で実装されているが、Master の現行評価では一つの運用系として十分に機能しているとは言えない。Neuron Graph RAG はそのどれか一つへ機能を追加する改修ではなく、三つを共通のデータモデル・検索経路・フィードバックループとしてゼロから再構成する clean-sheet prototype と位置づける。

実装先は Liplus-Project/neuron-graph-rag、最初の縦切りMVPは Issue #1 で追跡する。

MCP 対応 AI との接続は、NGR core の必須依存ではなく、同一 repository 内の任意 adapter とする。先に search、record_source_use、record_outcome の transport-independent な意味を固定し、MCP server、認証、transport、remote deployment は後続判断に残す。

Edges

• depends on: memory-graphrag-sqlite-exploration — 静的GraphRAGと動的連想メモリの探索結果を実装可能な仮説へ進める
• depends on: liplus-judgment-learning-telos — GitHub上の判断履歴をAIが上流判断へ再利用する目的を検索側から支える
• depends on: liplus-structure-as-retrieval-surface — Li+ の構造を説明と判断の検索面として読む

Background

Li+ の履歴は Issue、PR、commit、Wiki に十分残っているが、1600件規模の履歴から現在の判断に必要な少数の原典を選ぶ読み出しコストが残る。ハイブリッドRAGは意味的に近い入口を見つけられる一方、語彙が変化した長期履歴の因果経路を単独では復元しにくい。静的な知識グラフは関係を保持できるが、実際に役立った探索経路を利用結果から学習しない。

この不足を、RAGによる入口ノードの発火、型付きグラフ上の活性伝播、成功した経路だけの結合強化として一体化して検証する。

LLM Wiki 側の役割は、raw source を AI が維持する相互リンク済み知識へコンパイルし続ける書き込み面にある。Neuron Graph RAG 側は、その知識からどの node と path を活性化し、実際に役立った経路を次回へどう残すかという読み出し・学習面を担う。既存実装は移植元ではなく、失敗を含む観測材料と比較対象として扱う。

Constraints

• 検索された回数と、実際に結果が利用され成功した回数を分離する
• 検索だけで結合を強化しない。人気ノードの自己増幅を防ぐ
• 時間減衰の対象は検索上の活性度であり、知識の正しさや確信度ではない
• GNNを初期要件にせず、透明で説明可能な重み付きグラフから始める
• github-rag-mcp と Graphify は比較対象・先行実装であり、初期コアの必須依存にしない
• 採用判断は実装可能性ではなく、通常のハイブリッド検索に対する recall、原典数、トークン量の比較で行う
• MCP adapter は core の public API だけに依存し、MCP SDK や transport 型を core へ持ち込まない
• source-use は retrieved -> selected -> validated -> used の順序で記録し、新規 used だけを即時 reinforcement に接続する
• corrected、rolled_back などの delayed outcome は別 ledger に記録し、初期契約では edge weight を自動変更しない

Success oracle

第一の success oracle は、検索結果を消費する AI 自身の downstream source-use とする。AI は retrieval trace の候補を見たあと、どの node を実際の判断材料として選び、source check を通し、最終回答・実装判断・レビュー判断へ使用したかを任意 adapter の record_source_use へ返せる。adapter は新しく used へ到達した node だけを NGR core の record_success へ接続する。

成功信号は「良さそう」という自己申告ではなく、後続行動に現れた段階で扱う。

1. retrieved: 候補に出た
2. selected: 詳細を読む対象に選んだ
3. validated: 原典確認を通った
4. used: 最終判断の根拠として実際に使った

used は直前に validated へ到達していることを必須とする。結合強化の対象は、この順序を通って新しく used へ到達した node と説明経路に限定する。候補に出ただけの結果、読んだが不適切と判断した結果、exact source を見つけられず fallback を要した検索は強化しない。失敗結果は即座に負の重みへ変換せず、retrieval failure として別に記録する。query や index 側の不全を知識 node の誤りとして罰する混同を避けるためである。

この AI 内生信号に、後から human correction、CI、merge、rollback、同種判断の再修正有無などの delayed outcome を record_outcome で別軸として重ねる。初期契約では confirmed、corrected、rolled_back、superseded を記録するだけで、即時の追加強化、負の重み、weight rollback へは変換しない。各検索ごとの human 承認を success oracle の必須条件にはしない。

2026-07-29 の設計対話では、RAG 検索が広い skill 文書を返し exact Decision Structure page を取れなかった結果を AI が不採用と判断し、直接取得した memory-graphrag-sqlite-exploration、liplus-structure-as-retrieval-surface、liplus-judgment-learning-telos、本 entry を判断根拠として使用した。これは consuming AI が同一 session 内で retrieval failure と successful source-use を分離できる実例である。

Conclusion

Li+ 本体や既存RAGへの即時統合は行わない。独立リポジトリでは「取り込み、検索、活性伝播、成功フィードバック、再検索」まで通る最小実装と比較evalが成立し、任意 MCP adapter の feedback interface 契約も Issue #5 で固定した。これは機構と接続境界の成立確認であり、Li+ の実運用でうまく機能することの証明ではない。次段は GitHub 履歴、Decision Structure、LLM Wiki 書き込み面を接続する adapter と、stage / outcome ledger を実装し、通常のハイブリッド検索に対する recall、原典数、トークン量、判断再利用の実績で採用を判断する。

Related

• Liplus-Project/neuron-graph-rag
• Neuron Graph RAG Issue #1
• Optional MCP Feedback Interface Issue #5