1000+ PDFs lokal chatten: RAG-Skalierung über Demo-Beispiele

Warum Standard-RAG über 1.000 Dokumente hinaus scheitert

• Index-außerhalb-RAM: LanceDB, ChromaDB und FAISS starten alle speicherresident. Wenn der Index das verfügbare RAM überschreitet (normalerweise 5-8 GB Vektoren auf einem 16-GB-Laptop), greifen sie auf Festplattenzugriffe zurück und die p95-Abfragelatenz springt von ~300 ms auf 1-3 Sekunden.
• Cosinus-Only scheitert bei seltenen Begriffen: Dichte Embeddings untergewichten ungewöhnliche Eigennamen, Medikamentennamen, Statutennummern und Code-Identifizierer. Eine Abfrage für „Section 230(c)(1)" ruft Chunks über „Section 9" ab, weil das Embedding numerische Spezifität nicht unterscheiden kann. BM25 erfasst dies; reine Cosinus-Suche verfehlt sie.
• Top-K von 4 ist zu eng im großen Maßstab: Bei 1.000 Chunks hat Top-4 eine anständige Genauigkeit. Bei 50.000 Chunks liegt der wirklich beste Chunk oft bei Rang 12-30 – außerhalb des Top-4-Fensters. Der Abruf scheint zu funktionieren (die Antworten sind plausibel), basiert aber stillschweigend auf den falschen Passagen.
• Keine Metadaten-Filterung verschwendet den Index: Die Frage „Was sagte Smith über X" auf einem 10.000-Dokument-Bestand durchsucht jeden Chunk im Index, während das System zuerst zu „Dokumenten von Smith" vor-filtern sollte. Naives RAG kennt kein Konzept der Metadaten-Vor-Filterung.
• Standard-Chunk-Größe von 512/0 fragmentiert lange Kontexte: PDF-Absätze und Rechtsbereiche passen selten in 512 Token. Die Überlappung von 0 verliert Bedeutung über Grenzen hinweg. Die Optimierung von 1.000/200 behebt dies für mittlere Bestände; hierarchisches Chunking ist über 5.000 Dokumenten erforderlich.
• Embedding-Drift bei Update: Wenn Sie 1.000 neue PDFs drei Monate nach dem ursprünglichen Index hinzufügen, können sich Sentence-Transformer-Modellversionen geändert haben. Das Mischen von Embeddings aus zwei Modellversionen in einem Index verschlechtert den Abruf stillschweigend – jede Architektur erzwingt eine vollständige Re-Indexierung bei Embedding-Modell-Wechsel.

Architektur-Entscheidungsbaum: Zuerst nach Bestandsgröße wählen

• Unter 1.000 Dokumenten (unter ~5.000 Chunks): AnythingLLM Desktop mit Chunk-Größe 1.000 / Überlappung 200 und nomic-embed-text-v1.5 als Embedding-Modell. Kein benutzerdefinierter Code. Siehe die 30-Minuten-Schritt-für-Schritt-Anleitung für Setup.
• 1.000-5.000 Dokumente (5k-25k Chunks): LlamaIndex Lokalmodus mit hierarchischen Indizes (DocumentSummaryIndex + VectorStoreIndex), Ollama als LLM-Provider, nomic-embed-text-v1.5 als Embedding-Modell, LanceDB oder ChromaDB als Vektor-Store. ~150 Zeilen Python, läuft als langlebiger Prozess.
• 5.000-10.000 Dokumente (25k-50k Chunks): Benutzerdefinierter Stack mit Ollama, ChromaDB, BM25 Hybrid-Suche über Whoosh oder Tantivy und BGE-reranker-v2-m3 Reranker-Pass über Top-50-Kandidaten. ~300-400 Zeilen Python. Der Reranker ist nicht verhandelbar in diesem Umfang.
• 10.000+ Dokumente (50k+ Chunks): Ollama + Qdrant im Single-Node-Modus mit Payload-basierter Metadaten-Filterung, Hybrid-Suche mit nativen Sparse-Vektoren von Qdrant, BGE-reranker-v2-m3 und hierarchischen Summary-Index nach Dokument-IDs. Produktionsreife Single-User-Setup.
• Multi-User (jeder Umfang): Open WebUI vor einem beliebigen der obigen, ODER einen kleinen FastAPI-Wrapper um das gleiche Qdrant + Ollama Backend. Multi-User verändert die operationale Geschichte (Auth, Isolation, Rate Limiting), aber nicht die Abruf-Architektur.

Architektur-Vergleichstabelle

Option 1: AnythingLLM optimiert (100-1.000 Dokumente)

• LLM: Llama 3.3 8B Q4_K_M über Ollama (5 GB RAM während Inferenz). Auf 24-GB+-Systemen verbessert Qwen 2.5 14B Q4 die Synthese deutlich.
• Embedding-Modell: Wechsel vom Standard von AnythingLLM zu nomic-embed-text-v1.5 über Ollama. Das Standard-Embedding-Modell ist der einzige größte Grund für „AnythingLLM skaliert nicht"-Berichte.
• Chunking: 1.000 Token mit 200-Token-Überlappung, pro Workspace unter Vector Database-Einstellungen eingestellt. Das Standard 512/0 ist falsch für jeden Bestand größer als ein paar Dutzend Dokumente.
• Top-K: von Standard 4 auf 6-8 erhöhen. Bei 1.000 Dokumenten liegt der wirklich beste Chunk oft bei Rang 5-7, und der LLM kann schwache Chunks besser ignorieren als fehlende erfinden.
• Workspace-Partitionierung: einen Workspace pro Dokumentkategorie erstellen (Papiere, Verträge, Notizen). Jeder Workspace ist ein separat indexierter LanceDB; Workspaces übergreifende Abfragen werden nicht unterstützt, aber Pro-Workspace-Genauigkeit ist viel höher als in einem großen Pool.

Option 2: LlamaIndex lokal (1.000-5.000 Dokumente)

• Stack: Ollama + LlamaIndex + LanceDB (oder ChromaDB) + nomic-embed-text-v1.5 über den OllamaEmbedding-Adapter. Persistiert auf Festplatte; läuft als langlebiger Python-Prozess, mit dem Sie über CLI oder kleinen FastAPI-Wrapper kommunizieren.
• DocumentSummaryIndex über VectorStoreIndex: LlamaIndex erstellt bei der Indexierung eine Pro-Dokument-Zusammenfassung, dann wählt der Abruf zuerst relevante Dokumente (Summary-Suche) und durchsucht nur dann Chunks innerhalb dieser Dokumente. Das ist das günstigste hierarchische Abruf-Muster.
• Abfrage-Routing: RouterQueryEngine schickt Faktenabruf-Abfragen zum Chunk-Index und Syntheseabfragen zum Summary-Index. ~30 Zeilen Code; verdoppelt die Antwortqualität auf langen Dokumenten-Beständen.
• Sentence-Window-Abruf: ein optionaler zweiter Index, der einen Zieldsatz plus N umgebende Sätze abruft. Nützlich für Rechts- und akademische Bestände, wo die Antwort ein Satz ist, aber seine Bedeutung vom umgebenden Absatz abhängt.
• Persistenz: index.storage_context.persist(persist_dir=...) speichert alles. Ladezeit auf einem 5.000-Dokument-Index liegt auf NVMe SSD bei 10-30 Sekunden.

# Minimales LlamaIndex lokales RAG mit hierarchischen Indizes (~30 Zeilen)
from llama_index.core import VectorStoreIndex, DocumentSummaryIndex, SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.llm = Ollama(model="llama3.3:8b-instruct-q4_K_M", request_timeout=120)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text:latest")
Settings.chunk_size = 1000
Settings.chunk_overlap = 200

docs = SimpleDirectoryReader("./pdfs").load_data()

# Summary-Index zum Routing + Chunk-Index zum Abruf
summary_index = DocumentSummaryIndex.from_documents(docs)
chunk_index = VectorStoreIndex.from_documents(docs)

summary_index.storage_context.persist("./storage/summary")
chunk_index.storage_context.persist("./storage/chunks")

# Bei Abfrage-Zeit, nach Abfragetyp routen
response = chunk_index.as_query_engine(similarity_top_k=8).query(
    "What sample size did Smith et al. use?"
)
print(response)

Option 3: Benutzerdefiniert Ollama + ChromaDB (5.000-10.000 Dokumente)

• Stack: Ollama + ChromaDB (Server-Modus) + Whoosh oder Tantivy für BM25 + BGE-reranker-v2-m3 (~570 MB, läuft auf CPU bei 50-100 Kandidaten/sec). Gehostet als einzelner Python-Prozess oder aufgeteilt in Ingest + Abfrage-Worker.
• Hybrid-Suche bei Abruf-Zeit: BM25 und dichte Vektor-Abruf parallel laufen, Top-25 von jedem nehmen, deduplizieren, dann Top-50 mit dem Cross-Encoder reranken. Final Top-K von 6-8 geht zum LLM.
• ChromaDB-Metadaten-Felder: füllen Sie source_filename, page_number, document_type, author, year auf jedem Chunk bei Index-Zeit. Filterung bei Abfrage-Zeit (where={"document_type": "contract"}) schneidet Abruf-Suchraum um 5-10x ohne Qualitätsverlust.
• Batch-Indexierung: ChromaDB embeddet in Batches von 32-128 Chunks. Auf einer RTX 4070 ist BGE-Reranker der Engpass (50-100 Kandidaten/sec auf CPU; 400+/sec auf GPU).
• Persistenz: ChromaDB schreibt zu SQLite + Parquet-Verzeichnis. Ein 50.000-Chunk-Index auf Festplatte ist ~3-5 GB. Sicherung ist ein Verzeichnis-Kopie.

Option 4: Ollama + Qdrant (10.000+ Dokumente)

• Stack: Ollama + Qdrant (Docker, Single-Node) + native Sparse-Vektoren (BM25-äquivalent in Qdrant 1.10+ eingebaut) + BGE-reranker-v2-m3 + kleine Python-Orchestrierungs-Schicht.
• Native Hybrid: Qdrant unterstützt dichte + Sparse-Vektoren in einer Sammlung, mit gewichteter Fusion bei Abfrage-Zeit. Kein separater BM25-Prozess zu Wartung.
• HNSW-Tuning: bei 50.000+ Vektoren ef_construct auf 200 und m auf 32 für den Index-Bau erhöhen, und ef=128 bei Abfrage-Zeit verwenden. Standardwerte funktionieren, aber tauschen ~10% Genauigkeit gegen Build-Geschwindigkeit.
• Payload-Schemata zur Filterung: Qdrant behandelt Payloads als First-Class. Indexieren Sie author, document_type, year und tags als Keyword-Payloads, um Sub-Millisekunden-Vor-Filterung zu ermöglichen.
• Hierarchischer Abruf: zwei Sammlungen beibehalten – summaries (ein Vektor pro Dokument) und chunks (die übliche). Abfragen durch die Summary-Sammlung zuerst routen, dann Chunk-Suche innerhalb der abgestimmten Dokument-IDs.
• Persistenz: Qdrant schreibt zu einem einzigen eingebundenen Volume. Eine 100.000-Chunk-Sammlung ist je nach Payload-Größe und HNSW-Einstellungen ~6-12 GB auf Festplatte.

# Qdrant-Sammlung mit dichte + Sparse-Vektoren und Metadaten-Filterung
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, SparseVectorParams, SparseIndexParams
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config={
        "dense": VectorParams(size=768, distance=Distance.COSINE),  # nomic-embed-text-v1.5
    },
    sparse_vectors_config={
        "bm25": SparseVectorParams(index=SparseIndexParams(on_disk=False)),
    },
)

# Abfrage: Hybrid-Suche + Payload-Filter, kein separater BM25-Prozess erforderlich
from qdrant_client.models import Filter, FieldCondition, MatchValue, Prefetch

results = client.query_points(
    collection_name="docs",
    query=dense_vec,
    using="dense",
    prefetch=[
        Prefetch(query=sparse_vec, using="bm25", limit=25),
        Prefetch(query=dense_vec, using="dense", limit=25),
    ],
    query_filter=Filter(
        must=[FieldCondition(key="document_type", match=MatchValue(value="contract"))]
    ),
    limit=50,  # vor Rerank
)

Hybrid-Suche: BM25 + Vektor schlägt eine alleine

• Warum Dense alleine scheitert: Embeddings untergewichten seltene Token. Abfragen wie „RFC 9110 Abschnitt 7.4" oder „MNDA-2024-0143" werden nahe generischen IETF / Vertrags-Chunks eingebettet. BM25 erfasst den genauen Identifizierer; reine Cosinus-Suche verfehlt ihn.
• Warum BM25 alleine scheitert: Lexikalische Übereinstimmung verfehlt Paraphrasen. Eine Abfrage „Wie stornieren wir?" gegen einen Chunk mit Titel „Kündigungs-Verfahren" passt im dichten Raum, aber erzielt 0 in BM25.
• Reciprocal Rank Fusion (RRF) ist der Standard-Kombiner: für jeden Chunk, der in beiden Ergebnis-Listen erscheint, ihm eine Punktzahl geben als 1/(60+rank_dense) + 1/(60+rank_bm25). Absteigend sortieren. Die 60 ist eine Glättungs-Konstante; Werte 30-100 funktionieren praktisch.
• Praktisches Rezept: Top-25 von jeder Methode abrufen, über RRF kombinieren, Top-50 nehmen, zum Reranker schicken, dann Top-6-8 zum LLM. Das ist die Standard-Produktions-Pipeline in jedem Umfang über 1.000 Dokumenten.
• Speicherkosten: BM25-Indizes sind klein (~50-150 MB pro 10.000 Dokumente) im Vergleich zu dichten Indizes (~500 MB-2 GB im gleichen Umfang). Hinzufügen von BM25 zu einem existierenden dichten Store ist billig.

Reranking: Der Top-N-Verfeinerungspass

• BGE-reranker-v2-m3 (~570 MB, mehrsprachig, Apache 2.0) ist die Standard-Wahl im Mai 2026. Läuft mit 50-100 Kandidaten/sec auf einer modernen CPU; 400+ /sec auf GPU. Latenzkost für Top-50-Reranking ist ~200-500 ms auf CPU, ~80-150 ms auf GPU.
• Warum Cross-Encoder beim Abruf gewinnen: Dichte Embeddings kodieren Abfrage und Dokument unabhängig, daher sieht das Modell sie niemals zusammen. Ein Cross-Encoder liest `[CLS] abfrage [SEP] kandidat [SEP]` gemeinsam und bewertet das Paar direkt. Recall@5 springt typisch um 15-25 Punkte.
• Wo man den Reranker injiziert: nach Hybrid-Suche, vorher der LLM. Top-50 von Hybrid nehmen, auf Top-6-8 reranken, die zum LLM als Kontext schicken.
• Alternative – Cohere Rerank API: höhere Qualität, aber erfordert einen Cloud-Aufruf. Für vollständig-lokale Stacks ist BGE-reranker-v2-m3 der praktische Standard. mxbai-rerank-base-v2 ist ein starker Runner-up.
• Den Reranker unter 1.000 Dokumenten zu überspringen ist fein: Der Qualitäts-Gewinn rechtfertigt nicht die Latenzkost. Über 5.000 Dokumenten, ihn zu überspringen lässt ~15-25% der Antworten auf den falschen Chunks verankert.

Metadaten-Filterung: Verengen Sie vorher den Suchraum

• Universelle Payload-Felder zum Füllen bei Index-Zeit: source_filename, page_number, document_type (Papier / Vertrag / Notiz / Wiki), author, year, language, plus domain-spezifische Tags (z.B. case_number, project_id, client_id).
• Vor-Filter bei Abfrage-Zeit: „Was sagten die Q3-2024-Vorstandsprotokolle über Preise?" → filter document_type=board_minutes AND year=2024 AND quarter=3 zuerst, dann Vektor-Suche innerhalb ~12 Dokumente statt aller 10.000.
• Vektor-Store-Unterstützung: Qdrant-Payloads, Weaviate-Properties, ChromaDB-Metadaten und LanceDB-Schema-Spalten unterstützen alle Filterung. Leistung variiert – Qdrant-Payload-Filterung auf indizierten Feldern ist Sub-Millisekunde; ChromaDB-Metadaten-Filterung auf >100k Chunks kann 50-150 ms hinzufügen.
• Auto-Extraktion von Metadaten: für Rechts-Bestände, ein kleiner LLM-Pass bei Index-Zeit kann Fallenummern, Daten und Partei-Namen pro Dokument extrahieren. Kostet ~30 Sekunden pro Dokument auf Llama 3.3 8B; läuft einmal pro Ingest.
• Mit Hybrid-Suche kombinieren: Payload-Filter verengt das Universum → BM25 + dichte Abruf innerhalb des gefilterten Sets → Rerank. Der Payload-Filter ist die billigste 5-10x-Speedup in jedem großen RAG-System.

Hierarchischer Abruf: Summary zuerst, Chunks zweiter

• Pro-Dokument-Zusammenfassungen: bei Index-Zeit, fordert man den LLM auf, eine 100-200 Token-Zusammenfassung von jedem Dokument zu schreiben. Diese Zusammenfassungen in eine separate summaries-Sammlung einbetten. Kosten ~30-90 Sekunden pro Dokument auf Llama 3.3 8B.
• Zwei-Stufen-Abruf: (1) Abfrage einbetten, summaries durchsuchen, Top-5-Dokumente nehmen; (2) innerhalb dieser 5 Dokumente, Top-8-Chunks über Hybrid-Suche abrufen; (3) bei Bedarf reranken; (4) zum LLM schicken.
• Wann es am meisten hilft: Synthese und Multi-Dokument-Abfragen („vergleichen Sie, wie diese Papiere X handhaben"). Faktenabruf („welchen Wert berichtete Smith?") ist fein im Chunk-Index alleine – der Summary-Detour fügt Latenz ohne Qualitäts-Gewinn hinzu.
• Kosten-Tradeoff: verdoppelt Index-Speicher (Zusammenfassungen sind klein, aber der Index selbst ist duplizierte Infrastruktur). Verdoppelt Latenz für nicht-geroutete Abfragen. Der Gewinn ist Rausch-Reduktion bei 10.000+ Dokumenten.
• LlamaIndex baut dies in: DocumentSummaryIndex plus RouterQueryEngine ist eine 30-Zeilen-Implementierung. Benutzerdefiniertes Python mit ChromaDB oder Qdrant ist ~80-120 Zeilen.

Gemessene Benchmarks bei 100, 1.000 und 10.000 Dokumenten

Speichergröße und Hardware-Anforderungen

• Roh-Text pro 1.000 PDFs (~12 Seiten jede): ~50-150 MB extrahierter Text. Hochgradig variabel je nach Dichte.
• Vektoren bei 1.000 Dokumenten: ~300-400 MB auf der Festplatte einschließlich HNSW-Index-Overhead. ~120-180 MB, wenn Sie den HNSW-Index überspringen und Brute-Force-Suche verwenden (akzeptabel unter 5.000 Dokumenten).
• Vektoren bei 10.000 Dokumenten: ~3-5 GB auf der Festplatte. HNSW-Bau nimmt 10-30 Minuten auf einer modernen CPU.
• Vektoren bei 50.000 Dokumenten: ~15-25 GB auf der Festplatte. Index-Build-Zeit ist der Engpass – planen Sie 2-4 Stunden einmaliger CPU-Arbeit.
• RAM während Abfrage: dichte Abruf benötigt ~30-50% des Index in arbeitendem Speicher für Abfragen mit niedriger Latenz. Ein 5-GB-Index fragt bequem in 8-16 GB RAM mit HNSW ab; Brute-Force benötigt den vollständigen Index resident.
• RAM während Indexierung: spitzt sich auf 2-3x die Embedding-Modell-Größe (~600 MB für nomic-embed-text) plus Pro-Batch-Text. 8 GB frei RAM ist ausreichend für den Indexierungs-Pass.
• GPU vs. CPU: Embedding-Durchsatz ist auf einer diskreten GPU oder Apple Silicon 4-8x schneller. Für 10.000+ Dokumente One-Shot-Indexierung spart die GPU 1-3 Stunden. Bei Query-Zeit-Embedding (eine Abfrage auf einmal) ist CPU fein.
• Festplatte-Typ zählt: NVMe SSD ist der praktische Boden bei 5.000+ Dokumenten. SATA SSD fügt 30-100% zu kalter Abfrage-Latenz hinzu; Spindel-Festplatte ist über ~2.000 Dokumenten nicht zu verwenden.

Inkrementelle Indexierung und Deduplizierung

• Hash-basierte exakte Dedup bei Ingest: SHA-256 der rohen Datei-Bytes. Dateien überspringen, deren Hash bereits im Index ist. Billig, erfasst identische Dateien, aber verfehlt Quasi-Duplikate (verschiedene OCR-Passes vom gleichen Scan, Format-Konversionen).
• Content-Hash-Dedup: SHA-256 des extrahierten Klartextes nach Whitespace-Normalisierung. Erfasst das gleiche Dokument in verschiedenen Dateiformaten. Fügt ~5 ms pro Datei beim Ingest hinzu.
• MinHash für Quasi-Duplikate: für Rechts- und akademische Bestände, wo mehrere Entwürfe des gleichen Dokuments sich ansammeln, berechnen Sie eine MinHash-Signatur (~128 Bytes pro Dokument) und überspringen Sie Dateien innerhalb eines Jaccard-Ähnlichkeits-Schwellwerts eines vorhandenen Eintrags.
• Dokument-IDs sind für immer: niemals eine Dokument-ID nach Löschen wiederverwenden. Vektor-Stores halten oft verwaiste Vektoren kurz; ID-Wiederverwendung verursacht stillschweigende Verwirrung. Verwenden Sie UUIDs oder Hash-basierte IDs.
• Re-Embedding bei Embedding-Modell-Wechsel: jede Architektur erzwingt eine komplette Neuindexierung, wenn Sie das Embedding-Modell wechseln. Planen Sie eine Embedding-Wahl, zu der Sie sich für mindestens ein Jahr vor Indexierung von 10.000 Dokumenten verpflichten.
• Löscht: ChromaDB und Qdrant unterstützen Punkt-Löschung nach ID. LanceDB erfordert einen Kompaktions-Pass zum Freigeben von Speicherplatz – planen Sie wöchentlich, wenn Sie mehr als ~5% des Bestands pro Monat löschen.

Überwachung der RAG-Qualität im großen Maßstab

• Bauen Sie einen kleinen Gold-Set: 30-50 Abfragen, zu denen Sie die richtige Antwort kennen, gezogen aus echter Nutzung. Schließen Sie Faktenabruf (5-10), Synthese (5-10), Cross-Dokument (5-10), Grenzfälle (5-10) und bekannte-Miss-Abfragen (5-10) ein, wo die Antwort nicht im Bestand ist.
• Verfolgen Sie drei Metriken pro Abfrage: Abruf-Genauigkeit (erschien der richtige Chunk in Top-K?), Generierungs-Treue (passt die Antwort zum Chunk?) und Verweigerungs-Rate (sagt das System richtig „nicht im Bestand" für bekannte-Miss-Abfragen?).
• Laufen Sie auf jede bedeutsame Änderung erneut: neue Ingest-Batches, Embedding-Modell-Tausch, Chunk-Größen-Tausch, Prompt-Tweaks. Unterschied-Ergebnisse gegen den vorherigen Lauf; flaggen Sie jede Abfrage, deren Abruf-Genauigkeit oder Antwort sich änderte.
• Trulens oder RAGAS für automatisierte Eval-Frameworks. Beide laufen lokal und integrieren mit LlamaIndex. Manuelle Bewertung von 30-50 Abfragen ist auch fein und oft genauer.
• Latenz-Budgets: verfolgen Sie p50 und p95 Abfrage-Latenz über Zeit. Ein 50% Sprung in p95 bedeutet typisch, der Index ist aus RAM herausgewachsen – das früh-Signal, dass Sie zum nächsten Architektur-Tier upgraden müssen.

Häufig gestellte Fragen

Weiterführende Literatur

• AnythingLLM vs. PrivateGPT vs. Open WebUI: Best Local RAG in 2026 – Basis-Kontext zum Wählen der Desktop-RAG-Plattform vor Skalierung.
• Best Embedding Models for Local RAG in 2026 – Embedding-Wahl ist die einzelne wichtigste Entscheidung vor Indexierung von 10.000 Dokumenten.
• Local RAG for Private Business Data – natürliche Eskalation, wenn persönliche-Skalen-RAG Enterprise-Compliance-Anforderungen trifft.
• Build Local RAG on Your PDFs in 30 Minutes (Ollama + AnythingLLM) – das Eintritts-Level-Setup, bevor Sie die Skalierungs-Klippe treffen.
• RAG Explained: How to Ground AI Answers in Real Data (2026) – Konzept-Autorität auf was RAG ist und warum jede Abruf-Komponente zählt.
• Local LLM Hardware Guide 2026 – Hardware-Großen-Referenz für 10.000+ Dokument-Bestände.
• Power Local LLM Hub – vollständiger Leitfaden-Bibliothek für den Cluster.