Platform Skeleton（Mini Palantir）到達: ローカル Graph-RAG + 認知ミドルウェア + 外部協業を開始した JAMES v0.3.0（オープンソース、alpha）

(github.com/Hashevolution)

7 ポイント投稿者 skanxhakr12 6 일 전 | 1件のコメント | WhatsAppで共有

一行要約

セキュリティを設計原則として扱う、100% ローカルの Graph-RAG 知識エンジン。
v0.3.0 Platform Skeleton（2026-05-17） に到達し、認知ミドルウェアレイヤーが
設計ではなく コードとして main に載った状態 です。

GitHub: https://github.com/Hashevolution/James-RAG-Evol
現在のバージョン: v0.3.0（Foundation Hardening 6/6 axes 通過、2026-05-13 ゲートクリア）
ライセンス: MIT
外部検証: OpenSSF Best Practices passing バッジ（Tiered 111%, project #12806）
別名: "Mini Palantir"（Palantir は Palantir Technologies の商標であり、JAMES と直接の関係はありません — ただし typed-graph + audit 痕跡保持 パターンが似ているという比喩）

[IMG] JAMES 3D オントロジー可視化

v0.2 → v0.3、この9日間で何が変わったか

認知ミドルウェアレイヤー Phase 2 が main に定着
- verification engine（PR #290）/ planner・task decomposition（PR #297）/ tool router（PR #295）
- 検証・計画・ツールルーティングは、もはや design doc ではなく import 可能なモジュール
Knowledge Cascade Phase A → E: 213 entities / 656 relations の本番マイグレーション完了
3-stage セキュリティパイプラインを維持: 入力 pre_check → 検索 ABAC → 出力 post_filter + PII mask
自己進化監査ログ: すべてのパッチが approver_username を保持し、回避不可能
bcrypt パスワード + SHA-256 透過的マイグレーション（PR #173）、ruff F-class baseline + GitHub Actions lint ワークフロー（PR #205）

外部で起きたこと（1人で作ったわけではない証拠）

Ali Afana（Provia 創業者、dev.to Featured）との最初の外部協業が進行中 — LinkedIn DM 6往復 + dev.to コメントスレッド
- 共同作業: 83-item injection regression スイート分離、v0.3 Gemma 4 バリアントベンチ（E4B / 26B MoE / 31B Dense）
- 共同成果物: injection-fixtures schema v1.1（PR #311 → #317 → #322、Ali 提案の normalization 不変条件・expected_block_stage・catalog_context をすべて反映し、diff-log に出典を明記）
- 事前登録: 3×3 評価計画（3 バリアント × 3 温度 × 1 プロンプト構造、4 仮説 + decision matrix、単一セルが回る前に PR #315 でロック）
- 外部実装者向け接点: LLM Provider contract（PR #316、6 required behaviors + reserved kwargs/env vars、約30行の Gemini API バックエンドスケッチを含む）
2人目の協業候補 — Matija Fućek（@mfucek_, naumu.ai）が 3D 可視化ツイートへの返信で自身のプロジェクト（plug-and-play 企業ブレインアプリ）のデモを共有し、協業チャネルが開設
Gemma 4 Challenge の2トラックへ提出完了:
- Build with Gemma 4: Building a Mini Palantir on gemma4:e4b
- Write with Gemma 4: 5 empty responses from gemma4:e4b. 4 hypotheses. 0 root cause. — fair-witness 形式で、失敗を加工せずそのまま報告

正直な限界（alpha 段階、隠すことはない）

認知ミドルウェア Phase 2 は main に載ったが、マルチユーザー・大規模負荷の検証は v0.4 ゲート
マルチモーダルは LLaVA・Whisper・ffmpeg まで配線済み（working prototype）。retrieval 統合は v0.3.x ～ v0.4
自己進化スキャフォールドは単一ユーザー環境で検証済み、複数承認者ワークフローは未検証
Gemma 4 E4B は認知段階で5回の空応答 を出し、4つの仮説いずれも root cause を確定できていない状態（Write トラック記事でそのまま公開）

どこに使えるか

社内 wiki / ノートを外部 API に送らず、ローカルでのみ扱いたいとき
推論経路（A --[CAUSES]--> X --[REQUIRES]--> Y 形式の typed graph_path）を 応答とともにグラフとして露出させる必要がある RAG デモ / 研究
セキュア RAG パターンのリファレンス（3-stage パイプライン、instruction isolation、bcrypt マイグレーション、ruff baseline をすべて PR 単位で公開）
Plugin エントリポイントが必要な人 — JAMES_PLUGINS ローダーと Backend Protocol は v0.3.x で安定化中

始め方

git clone https://github.com/Hashevolution/James-RAG-Evol  
cp .env.example .env  
pip install -r requirements.txt  
ollama pull gemma2:2b      # GPU がなければこれで開始  
python server_llmwiki.py   # http://localhost:8000

1件のコメント

skanxhakr12 6 일 전

こんにちは。ご質問はいつでも歓迎です —

以下はシステム設計レベルでの比較です。

JAMES (v0.3.0) の現在のアーキテクチャは次のとおりです。

Formal query language 層が不在 — core/retrieval_engine.py のハイブリッド検索は、dense embedding + BM25 + keyword + name の4-wayスコア融合であり、NLクエリをSPARQL/RDF/SQLのような形式言語に変換しません。埋め込みとBM25のスコアがそのまま候補ノード選択に使用されます。
LLMの応答はNL — core/reasoning/modes/chat.py では、LLMはNLプロンプトを受け取り、NLテキストで回答を生成します。formal-languageの中間段階はありません。
KG更新は人間の承認ゲートとして分離 — core/change_request.py のモジュールドックストリング冒頭に明記されています: "Every write inside JAMES becomes a proposal in this module first; only a separate reviewer's approval turns the proposal into a real write." つまり、LLMの応答に基づいて自動的にKGへadd/modify/removeする経路自体がシステムにありません。wiki_editにもadmin権限ゲートがあり、change_request の propose → review → apply フローを強制します（関連する CLAUDE.md §3、ARCHITECTURE.md §5.6 を参照）。

JAMESが非商用のalpha段階である点もご考慮ください。

さらに深い分析をご希望であれば、GitHub Issueで一緒に見ていただけると幸いです。

さまざまなフィードバックは、プロジェクトの設計上の選択を誠実に点検できる最も価値あるものだと考えています。ありがとうございます。