Von NotebookLM bis zum eigenen RAG-Stack – ohne Enterprise-Budget
SerieRAG – Vom Konzept zum Wissenssystem
Teil 3 von 6
Nicht jedes RAG-System braucht Kubernetes, Pipelines und ein Data-Team. In der Praxis gibt es drei sinnvolle Einstiegspunkte — je nach Anspruch.
Die meisten steigen zu früh zu hoch ein.
Stufe 1 — Managed Tools
Der schnellste Weg zu einem funktionierenden Wissenssystem: bestehende Tools nutzen, kein Setup, kein Code.
Google NotebookLM
Der aktuell pragmatischste Einstieg. Dokumente hochladen — PDFs, Google Docs, Websites — und direkt damit arbeiten.
Was gut funktioniert:
- Antworten strikt auf Basis der eigenen Quellen
- Quellen werden sauber referenziert
- Gute Zusammenfassungen (inkl. Audio-Podcasts)
- Sehr schnell im Setup
Wo es hakt:
- Keine echte API oder Integration
- Kaum Automatisierung möglich
- Begrenzte Kontrolle über Retrieval
- Daten liegen bei Google
Perfekt, um zu verstehen, wie RAG in der Praxis wirkt — bevor man eigene Infrastruktur baut.
ChatGPT (Custom GPTs / Knowledge)
Solider Mittelweg, aber weniger transparent als NotebookLM.
Stärken: Schnell eingerichtet, kombinierbar mit Tools und Actions, gute UX.
Schwächen: Retrieval nicht kontrollierbar, keine saubere Debugbarkeit, bei größeren Datenmengen schnell unpräzise.
Claude (Projects)
Gerade für längere, technische Inhalte interessant durch das große Kontextfenster. Allerdings kein echtes RAG im engeren Sinne — eher “Context Stuffing” als gezieltes Retrieval. Die Stärke liegt in der Verarbeitung komplexer Dokumente, nicht in der skalierbaren Suche.
Wann Stufe 1 reicht
- Persönliche Wissensarbeit und Recherche
- Kleine Teams mit überschaubarer Dokumentenbasis
- Validierung eines Use-Cases: Funktioniert RAG hier überhaupt?
Wenn hier kein klarer Mehrwert erkennbar ist, braucht man keinen eigenen Stack.
Stufe 2 — Low-Code RAG
Sobald Kontrolle nötig wird — API-Zugriff, Automatisierung, Integration in bestehende Systeme — reicht Stufe 1 nicht mehr.
Frameworks: LangChain und LlamaIndex
Beide Frameworks abstrahieren die klassische RAG-Pipeline in Python: Dokumente laden, chunken, Embeddings erzeugen, Vektorsuche, Prompting.
loader = DirectoryLoader("./docs", glob="**/*.md")
documents = loader.load()
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(documents, embeddings)
qa = RetrievalQA.from_chain_type(
llm=OpenAI(),
retriever=vectorstore.as_retriever()
)
qa.run("Wie ist unsere Pricing-Strategie?")
Das ist ein Minimalbeispiel. In der Realität kommen dazu:
- Chunking-Strategien — wie Dokumente zerteilt werden, bestimmt die Antwortqualität
- Reranking (z.B. Cross-Encoder) — sortiert die gefundenen Chunks nach tatsächlicher Relevanz
- Prompt-Templates — strukturieren den Kontext für das LLM
- Evaluation — wird oft vergessen, ist aber entscheidend: Precision und Recall messen
Vektordatenbanken (Cloud)
- Pinecone — stabil und bewährt, aber teuer bei Skalierung
- Weaviate Cloud — flexibel, Open-Source-Basis, gute Hybrid-Search
- Qdrant Cloud — aktuell oft bestes Preis-Leistungs-Verhältnis
Was sich 2026 verändert hat
RAG ist nicht mehr “nur Retrieval”. Drei Entwicklungen, die den Alltag verändern:
Reranking ist Standard. Ein einfacher Cosine-Similarity-Vergleich reicht nicht mehr. Cross-Encoder-basiertes Reranking nach der ersten Suche ist 2026 die Norm, nicht die Ausnahme.
Hybrid Search wird häufiger genutzt. Die Kombination aus klassischer Keyword-Suche (BM25) und Embedding-basierter Suche liefert bessere Ergebnisse als jede Methode für sich.
Evaluation wird wichtiger als das Modell. Welches LLM man nutzt, ist weniger entscheidend als die Frage, ob die richtigen Chunks gefunden werden. Precision und Recall der Retrieval-Pipeline bestimmen die Antwortqualität.
Wann Stufe 2 reicht
- Automatisierte Ingestion (Cron, Webhooks, CI/CD)
- Integration in bestehende Systeme
- Mittelgroße Datenmengen (hunderte bis tausende Dokumente)
- Teams mit Python-Grundlagen
Für viele produktive Anwendungen ist das bereits das Zielniveau.
Stufe 3 — Eigener Stack
Volle Kontrolle, kein Vendor Lock-in, maximale Flexibilität. Aber auch: maximaler Aufwand. Wer hier einsteigt, baut Infrastruktur — nicht nur Features.
Vektordatenbanken (lokal / self-hosted)
- ChromaDB — simpel, embedded, gut für kleine Setups und Prototypen
- Qdrant — performant, Rust-basiert, produktionsfähig
- pgvector — sinnvoll, wenn PostgreSQL eh vorhanden ist
Embedding-Modelle ohne API
Nicht jedes Embedding braucht einen API-Call:
- sentence-transformers — Standard für viele Use-Cases, breite Modellauswahl
- BGE (BAAI) — stark bei Multilingualität, aktuell unter den besten Open-Source-Embeddings
- nomic-embed-text — effizient, gute Qualität bei geringem Ressourcenverbrauch
Chunking ist entscheidend
Hier passieren die meisten Fehler. Wie Dokumente zerteilt werden, beeinflusst die Antwortqualität mehr als die Wahl des LLMs.
| Strategie | Vorteil | Nachteil |
|---|---|---|
| Fixed-size | Einfach, vorhersagbar | Kontextverlust an den Grenzen |
| Sentence-based | Natürliche Grenzen | Ungleichmäßige Chunk-Größen |
| Semantic | Beste Qualität | Rechenintensiv, langsamer |
| Recursive | Guter Kompromiss | Konfigurationsaufwand |
Typische Architektur
Wann sich Stufe 3 lohnt
- Datenschutz: alles lokal oder on-prem
- Große Datenmengen (zehntausende Dokumente)
- Spezialisierte Anforderungen (eigene Chunking-Logik, domänenspezifische Embeddings)
- Langfristige Systeme, die gewartet und weiterentwickelt werden
Der nächste Schritt: RAG + Agenten
2026 verschiebt sich der Fokus. RAG ist nicht mehr das Endprodukt — es wird zum Baustein.
Ein Agent kann:
- entscheiden, wann Retrieval überhaupt nötig ist
- mehrere Wissensquellen kombinieren
- Ergebnisse prüfen und bei Bedarf nachrecherchieren (Self-Verification)
- Antworten strukturieren und für den jeweiligen Kontext aufbereiten
Das führt zu neuen Patterns: LLM + Tools + Retrieval + Execution. RAG wird eine Fähigkeit des Agenten, nicht ein eigenständiges System.
Kosten realistisch betrachtet
| Stufe | Kosten pro Monat | Know-how |
|---|---|---|
| Managed Tools | 0-20 Euro | Keines |
| Low-Code RAG | 20-150 Euro | Python |
| Eigener Stack | 50-300 Euro+ | Backend + DevOps |
Wer RAG systematisch aufbauen möchte – von den Grundlagen bis zur eigenen Retrieval-Pipeline – findet auf learn.casoon.dev einen strukturierten Kurs dazu.