Platform Skeleton (Mini Palantir) erreicht: Lokales Graph-RAG + kognitive Middleware + Beginn externer Zusammenarbeit JAMES v0.3.0 (Open Source, alpha)

 (github.com/Hashevolution)
7 Punkte von skanxhakr12 6 일 전 | 1 Kommentare | Auf WhatsApp teilen

Kurzfassung

Eine 100 % lokale Graph-RAG-Wissens-Engine, die Sicherheit als Designprinzip behandelt.
Mit dem Erreichen von v0.3.0 Platform Skeleton (2026-05-17) ist die Schicht für kognitive Middleware
nicht mehr nur ein Entwurf, sondern als Code im Main-Branch gelandet.

  • GitHub: https://github.com/Hashevolution/James-RAG-Evol
  • Aktuelle Version: v0.3.0 (Foundation Hardening: 6/6 Achsen bestanden, Gate am 2026-05-13 freigegeben)
  • Lizenz: MIT
  • Externe Validierung: OpenSSF Best Practices passing Badge (Tiered 111 %, Projekt #12806)
  • Alias: "Mini Palantir" (Palantir ist eine Marke von Palantir Technologies und steht in keiner direkten Beziehung zu JAMES — nur eine Metapher, weil das Muster typed-graph + Erhalt von Audit-Spuren ähnlich ist)

[IMG] JAMES 3D-Ontologie-Visualisierung

v0.2 → v0.3: Was hat sich in 9 Tagen verändert?

  1. Phase 2 der kognitiven Middleware-Schicht ist im Main angekommen
    • verification engine (PR #290) / planner·task decomposition (PR #297) / tool router (PR #295)
    • Verifikation, Planung und Tool-Routing sind nicht länger Design-Dokumente, sondern importierbare Module
  2. Knowledge Cascade Phase A → E: Produktionsmigration von 213 Entities / 656 Relations abgeschlossen
  3. 3-stufige Sicherheits-Pipeline beibehalten: Eingabe pre_check → Retrieval-ABAC → Ausgabe post_filter + PII-Maskierung
  4. Audit-Log zur Selbstevolution: Alle Patches enthalten approver_username, Umgehung nicht möglich
  5. bcrypt-Passwörter + transparente SHA-256-Migration (PR #173), ruff-F-Class-Baseline + GitHub-Actions-Lint-Workflow (PR #205)

Was extern passiert ist (Beleg dafür, dass es nicht allein gebaut wurde)

  • Erste externe Zusammenarbeit mit Ali Afana (Provia-Gründer, dev.to Featured) läuft — 6 LinkedIn-DMs + dev.to-Kommentar-Thread
    • Gemeinsame Arbeit: Auslagerung einer 83-teiligen Injection-Regression-Suite, v0.3-Gemma-4-Varianten-Benchmarks (E4B / 26B MoE / 31B Dense)
    • Gemeinsames Ergebnis: injection-fixtures schema v1.1 (PR #311 → #317 → #322, Alis vorgeschlagene Normalisierungsinvarianten, expected_block_stage und catalog_context vollständig übernommen, Herkunft im Diff-Log vermerkt)
    • Vorab registriert: 3×3-Evaluierungsplan (3 Varianten × 3 Temperaturen × 1 Prompt-Struktur, 4 Hypothesen + Decision Matrix, per PR #315 gesperrt, bevor auch nur eine einzelne Zelle lief)
    • Berührungspunkt für externe Implementierer: LLM Provider contract (PR #316, 6 erforderliche Verhaltensweisen + reservierte kwargs/env vars, inklusive ~30 Zeilen Gemini-API-Backend-Skizze)
  • Zweiter Kandidat für Zusammenarbeit — Matija Fućek (@mfucek_, naumu.ai) antwortete auf den Tweet zur 3D-Visualisierung mit einer Demo seines eigenen Projekts (eine Plug-and-Play-Unternehmenshirn-App), wodurch ein Kollaborationskanal eröffnet wurde
  • Einreichungen für 2 Tracks der Gemma 4 Challenge abgeschlossen:

Ehrliche Grenzen (Alpha-Phase, nichts zu verbergen)

  • Phase 2 der kognitiven Middleware ist zwar im Main, aber Multi-User- und Hochlast-Validierung sind ein Gate für v0.4
  • Multimodal ist bis zu LLaVA, Whisper und ffmpeg verdrahtet (funktionierender Prototyp). Die Integration ins Retrieval kommt in v0.3.x ~ v0.4
  • Das Selbstevolutions-Scaffold ist in einer Single-User-Umgebung validiert, ein Workflow mit mehreren Approvern ist nicht validiert
  • Gemma 4 E4B lieferte in der kognitiven Phase 5 leere Antworten, und keine der 4 Hypothesen konnte bisher die Root Cause bestätigen (im Write-Track-Artikel unverändert offengelegt)

Wofür lässt es sich verwenden?

  • Wenn interne Wikis/Notizen ausschließlich lokal verarbeitet werden sollen, ohne sie an externe APIs zu senden
  • Für RAG-Demos/Forschung, bei denen der Inferenzpfad (typed graph_path in der Form A --[CAUSES]--> X --[REQUIRES]--> Y) zusammen mit der Antwort als Graph sichtbar sein muss
  • Als Referenz für sichere RAG-Patterns (3-stufige Pipeline, Instruction Isolation, bcrypt-Migration, ruff-Baseline — alles auf PR-Ebene offengelegt)
  • Für alle, die einen Plugin-Einstiegspunkt brauchen — der Loader JAMES_PLUGINS und das Backend Protocol werden in v0.3.x stabilisiert

Erste Schritte

git clone https://github.com/Hashevolution/James-RAG-Evol  
cp .env.example .env  
pip install -r requirements.txt  
ollama pull gemma2:2b      # Damit starten, wenn keine GPU vorhanden ist  
python server_llmwiki.py   # http://localhost:8000

Verwandte Beiträge

1 Kommentare

 
skanxhakr12 6 일 전

Hallo. Fragen sind jederzeit willkommen —

Unten finden Sie einen Vergleich auf Systemdesign-Niveau.

Die aktuelle Architektur von JAMES (v0.3.0) ist wie folgt.

  1. Keine formale Query-Language-Schicht — die hybride Suche in core/retrieval_engine.py verwendet eine 4-Wege-Score-Fusion aus dense embedding + BM25 + keyword + name und wandelt NL-Abfragen nicht in formale Sprachen wie SPARQL/RDF/SQL um. Embeddings und BM25-Scores werden direkt für die Auswahl der Kandidatenknoten verwendet.

  2. LLM-Antworten sind NL — in core/reasoning/modes/chat.py erhält das LLM NL-Prompts und erzeugt Antworten als NL-Text; es gibt keine Intermediate-Stufe in einer formalen Sprache.

  3. KG-Updates sind durch ein menschliches Freigabe-Gate getrennt — bereits im ersten Satz des Modul-Docstrings von core/change_request.py steht: "Every write inside JAMES becomes a proposal in this module first; only a separate reviewer's approval turns the proposal into a real write." Das heißt, es gibt im System selbst keinen Pfad, der auf Grundlage einer LLM-Antwort automatisch add/modify/remove in der KG ausführt. Auch wiki_edit hat ein Admin-Rechte-Gate und erzwingt den Ablauf von change_request mit propose → review → apply (siehe CLAUDE.md §3, ARCHITECTURE.md §5.6).

Bitte berücksichtigen Sie, dass sich JAMES in der nicht-kommerziellen Alpha-Phase befindet.

Wenn Sie zusätzlich eine tiefere Analyse wünschen, wäre es hilfreich, wenn wir uns das gemeinsam in einem GitHub Issue ansehen könnten.

Ich denke, vielfältiges Feedback ist das Wertvollste, weil es uns ermöglicht, die Designentscheidungen des Projekts ehrlich zu überprüfen. Vielen Dank.