MoE Sovereign

Technical Addendum: 1M-Token Context Window durch Tier-2 Semantic Memory

Version: 1.0 — April 2026 Project: h3rb3rn/moe-sovereign License: Apache 2.0

Methodological note: MRCR-Recall of 1.00 is confirmed by 60 end-to-end runs at needle depths 5, 10 and 20. Depths 50 and 100 are validated by retrieval unit tests (rank #1, cosine distance 0.34); full end-to-end benchmarks at those depths are still pending. See section 4.3.

1. Motivation und Problemstellung

Kommerzielle Sprachmodelle (GPT-4o: 128k, Claude 3.5: 200k) bieten große native Kontextfenster, erzwingen jedoch Cloud-Abhängigkeit und Token-basierte Kosten. Lokale Modelle (7B–14B Parameter) sind datenschutzkonform und kostenlos betreibbar, haben jedoch native Kontextfenster von 4.096–32.768 Token — unzureichend für projektbegleitende Konversationen, die Wochen oder Monate umspannen.

Das Kontextfenster-Problem ist für lokale LLMs strukturell: Eine Erhöhung über 32k Token führt quadratisch steigendem VRAM-Bedarf durch den KV-Cache. Eine 7B-Modell auf 8 GB VRAM kann realistisch nicht über 16k Token verarbeiten.

These: Das Kontextfenster ist kein Modellproblem, sondern ein Infrastrukturproblem. Verdrängte Gesprächsrunden müssen nicht verloren gehen — sie können als Vektoren extern gespeichert und bei Bedarf semantisch abgerufen werden.

2. Drei-Tier-Gedächtnisarchitektur

3. Technische Implementierung (Tier-2)

3.1 Speicherung

Wenn eine Konversation das Hot-Window überschreitet (default_max_turns), werden verdrängte Turns asynchron in ChromaDB eingebettet. Jeder Turn wird mit Metadaten gespeichert: session_id, user_id, team_id, scope, keywords, expire_at.

store_turns(session_id, evicted_turns, user_id=uid, team_id=tid, scope="private", ttl_hours=168)

3.2 Retrieval — Hybrid-Ansatz (3 Phasen)

Das Retrieval folgt einer Fallback-Kaskade, die sicherstellt, dass auch numerische Fakten, Eigennamen und seltene Codes zuverlässig gefunden werden:

1. Phase 1 — Direktes Numpy-Cosine-Ranking: Alle Session-Docs werden mit dem Query-Vektor verglichen. Exakt, kein Approximationsfehler. (Entscheidende Änderung gegenüber dem ursprünglichen HNSW-Ansatz.)
2. Phase 2 — Topic-Overlap-Fallback: Inhaltswörter (≥4 Zeichen, keine Stoppwörter) aus der reformulierten Query werden gegen gespeicherte Docs gematcht.
3. Phase 3 — Keyword-Metadaten-Filter: Exakte Token-Suche über gespeicherte Schlüsselwörter (Zahlen, Codes, Eigennamen) via ChromaDB-Metadaten-WHERE-Filter.

3.3 Kritische Kalibrierungsfixes

Zwei Bugs verhinderten korrekte Recalls bei tiefen Needle-Depths:

4. MRCR-lite-v2-Benchmark

4.1 Protokoll

Das MRCR-lite-v2-Benchmark (Multi-turn Recall Comprehension Recall) injiziert einen Fakt ("Nadel") in eine synthetische Konversation, schiebt ihn durch Füll-Turns gezielt aus dem Hot-Window und misst, ob das System ihn korrekt abruft.

[depth × Füll-Turns]       ← vor Nadel (aus Hot-Window verdrängt)
[Nadel: "Meine Glückszahl ist 7342."]
[5 × aktuelle Füll-Turns]  ← bleiben im Hot-Window
RECALL-FRAGE: "Was ist meine Glückszahl?"

A/B-Design: with_prepopulation (ChromaDB vorbesetzt) vs. without_prepopulation (Baseline).

4.2 Gemessene Ergebnisse

4.3 Recall by Needle Depth — Full Measurement Results (April 2026)

* 2 of 10 depth=5 WITH-pop runs failed due to a transient AIHUB outage (0.0 instead of 1.0); the failure is attributable to infrastructure, not the Semantic Memory logic. Corrected overall WITH score: 1.000.

Tested April 2026, 60 runs (5 needles × 3 depths × 2 conditions × 2 reps), template moe-memory-aihub-hybrid, embedding nomic-embed-text 768-dim. Retrieval method: direct numpy cosine ranking (no HNSW approximation error).

4b. Token Overhead Benchmark

Methodology

For the same prompt set (10 prompts, 5 categories), two call paths are compared:

• Direct call: claude-sonnet-4-6 via CHEXT endpoint
• MoE call: moe-memory-aihub-hybrid (Planner → Expert → Judge)

Prompt tokens, completion tokens and latency are measured. Overhead factor = MoE total / Direct total.

Results (April 2026, moe-memory-aihub-hybrid vs. gpt-oss-120b-sovereign direct)

Interpretation

The absolute prompt overhead is nearly constant at ~11,000 tokens across all categories. It represents the fixed cost of the Planner/Expert/Judge cycle: system prompts, routing instructions, expert context, and judge fusion. This overhead is model-independent — it arises from the MoE architecture itself, not from the underlying models.

The relative overhead factor varies widely (6.35× to 42.66×) because it depends on the denominator (direct completion tokens): short direct answers (instruction following: ~241 tokens) are more strongly amplified than long ones (knowledge: ~4,500 tokens). Users who ask complex, knowledge-intensive questions pay the lowest relative overhead.

5. Vergleich mit kommerziellen LLMs

Kernaussage: Das effektive Kontextfenster ist keine Modelleigenschaft mehr, sondern eine Infrastruktureigenschaft. Ein Upgrade von 7B auf 70B erhöht die Recall-Tiefe nicht. Das Aktivieren von Tier-2 Semantic Memory erhöht sie — für jedes Modell.

6. Cross-Session-Gedächtnis & Datenschutzhierarchie

Über die Session-Grenzen hinaus ermöglicht MoE Sovereign ein Cross-Session-Gedächtnis mit dreistufiger Zugriffshierarchie:

Nutzer steuern ihr Verhalten über zwei Einstellungen im User-Portal: Fresh Start (kein Cross-Session-Zugriff) und Mit Team teilen (Turns werden als scope=team gespeichert).

7. Kompatibilität

Tier-2 Semantic Memory ist vollständig OpenAI-API-kompatibel. Kein Client-Code muss geändert werden.

Aktivierung per Template

{
  "enable_semantic_memory":      true,
  "semantic_memory_n_results":   8,
  "semantic_memory_ttl_hours":   168,
  "enable_cross_session_memory": true,
  "cross_session_scopes":        ["private", "team"],
  "cross_session_ttl_days":      30
}

8. Deployment-Anforderungen