Haystack — Production-RAG auf Sovereign-Stack

Wir haben Haystack 2.x als RAG-Pipeline auf unseren 13-File-DSGVO/AI-Act-Korpus geschaltet, mit Embedding und Generation komplett im Bunker. Ergebnis: vollwertige Document-Retrieval-Pipeline mit Quellen-Zitation — ohne eine Zeile US-Cloud im Pfad.

Live-Demo öffnen ↗ Code-Einsicht anfragen

Framework

Haystack 2.7+

Lizenz

Apache-2.0

Embedder

bge-m3-bunker

Generator

qwen3.6-27b-bunker

Vector-Store

InMemoryDocStore

Hosting

Sovereign-Container im Bunker

Was wir damit gebaut haben

Eine vollständige RAG-Pipeline mit zwei Haystack-Graphen:

Indexing-Pipeline beim Service-Start: DocumentSplitter (passage-based für unsere Markdown-Sections) → OpenAIDocumentEmbedder gegen LiteLLM-Bunker → InMemoryDocumentStore.
Query-Pipeline pro Frage: OpenAITextEmbedder → InMemoryEmbeddingRetriever (top_k=5) → PromptBuilder (Jinja-Template mit Quellen-Anweisung) → OpenAIGenerator.

Resultat: 569 Chunks im Store nach Index-Run, Antworten in 2-4 Sekunden mit strukturierter Quellen-Zitation. Probier es selbst: Live-Demo → „Welche TOMs setzt Qognio um?" oder „Wie ist unsere Position zum AI-Act?"

Was Haystack uns liefert (gegenüber Eigenbau)

Aspekt	NanoClaw `kb_search`	Haystack
Retrieval	BM25 in PocketBase	Embedding-Retrieval (hybrid möglich)
Pipeline-Modell	Tool-Loop, max 3 Runden	Expliziter Graph mit `connect()`
Reranking	ein/aus per Skill	als Komponente einsteckbar
Eval	ad-hoc	Haystack Evaluators eingebaut
Reife	für KMU-Bots ausreichend	für komplexe RAG-Korpora skalierbar

Architektur

Browser
  │  /  /api/*
  ▼
Edge-Reverse-Proxy
  ▼
Sovereign-Container
 ├─ nginx (TLS-Terminierung, statische UI)
 └─ FastAPI/uvicorn → main.py
       ├─ Index-Pipeline → InMemoryDocStore
       └─ Query-Pipeline → bge-m3-bunker + qwen3.6-27b-bunker

Lessons-Learned

1) Telemetry rausnehmen ist Pflicht

Haystack triggert beim Import ein mkdir /root/.haystack für Telemetry. Mit ProtectHome=yes in systemd → Crash. Lösung: HAYSTACK_TELEMETRY_ENABLED=False. Bonus: Sovereign-Stack will eh kein Phone-Home.

2) DocumentSplitter `split_by="sentence"` braucht NLTK

Optionale dependency, nicht in haystack-ai drin. Für Markdown-Section-Docs ist split_by="passage" sowieso natürlicher — Leerzeilen-Splits matchen unsere Section-Struktur 1:1.

3) LiteLLM ist drop-in für Embedder UND Generator

Wir konnten OpenAIDocumentEmbedder + OpenAIGenerator beide mit api_base_url=<Bunker> verkabeln. Kein Custom-Component nötig. Embedder und Generator kommen über denselben LiteLLM-Proxy-Endpoint.

4) InMemoryDocStore reicht überraschend lange

569 Chunks aus 13 Files = ~6 MB RAM. Für POCs und kleine Korpora kein Qdrant nötig. Skaliert linear, ab ~10k Chunks wird Hybrid mit Qdrant sinnvoll.

Wann macht Haystack für euch Sinn?

Wenn ihr eine RAG-Lösung braucht, die ein Datenkorpus mit klarer Struktur hat (Verträge, Wissensbasis, FAQs, Compliance-Dokumente) und ihr Quellen-Zitation, Reranking, oder RAG-Evaluation als Production-Feature braucht. Für einfache Chat-Bots ohne Daten-Backend reicht unser NanoClaw mit kb_search.

Sovereign-Bonus: Haystack arbeitet mit OpenAI-API-kompatiblen Endpoints — unser LiteLLM-Bunker-Proxy ist drop-in. Kein US-Cloud-Call im RAG-Pfad, vollständig DSGVO-konform.

📦 Als Addon buchbar

ab 2.500 € pauschal

Wir setzen den Haystack-Sovereign-Stack auch bei euch on-prem auf — vergleichbar mit unserem Pilot hier:

LXC-/Container-Setup mit Haystack 2.x + LiteLLM-Backend (oder gegen euren existierenden LLM)
Indexing-Pipeline für eure Doku-Quelle (Markdown, PDF, Confluence, SharePoint)
Query-API + schlanke Web-UI im Branding
Smoke-Monitoring + Doku
2-3 Personentage je nach Korpus-Komplexität

Termin vereinbaren →