RAG-Pilot in 7 Tagen: Von 50 PDFs zur funktionierenden Wissensbasis (Mai 2026)

Worum geht es hier?

Diese Anleitung führt ein Treuhand-, Anwalts- oder KMU-Team von null zur funktionierenden Retrieval-Augmented-Generation in genau 7 Werktagen. Sie sammeln 50 PDFs, setzen pgvector auf Postgres auf, embedden mit BGE-M3, routen LLM-Anfragen über LiteLLM zu Claude oder Mistral, bauen eine einfache Streamlit-UI, führen Eval mit Ragas durch und übergeben am siebten Tag eine lauffähige Demo an das Team.

Der Pilot ist bewusst klein geschnitten: 50 PDFs, eine UI, ein Use-Case. Ziel ist nicht ein produktives System, sondern ein vorzeigbares Ergebnis, das die Stakeholder-Entscheidung "weitermachen oder beerdigen" stützt. Der Budget-Rahmen liegt zwischen CHF 800 (mit OpenAI-Trial-Guthaben und Eigenleistung) und CHF 1.500 (mit Claude-API-Credits und externer Unterstützung in einzelnen Schritten).

Das Setup ist absichtlich konservativ gewählt: pgvector statt Qdrant (jede Postgres-Installation kann pgvector – keine zusätzliche Infrastruktur). BGE-M3 als Embedding-Modell (mehrsprachig DE/FR/IT/EN, lokal lauffähig, Mai 2026 State-of-the-Art). LiteLLM als Gateway (Provider austauschbar ohne Code-Änderung). Streamlit als UI (kein React-Knowhow nötig). Ragas für Eval (Faithfulness, Answer Relevance, Context Precision).

Warum dieser Pilot lohnt

Ohne Pilot bleibt RAG eine Präsentations-Folie. Mit einer einwoechigen Investition haben Sie konkrete Antworten auf die drei Fragen, an denen jedes RAG-Projekt scheitert oder gelingt: Sind die Dokumente sauber genug? Findet der Retriever die richtigen Stellen? Liefert das Modell glaubwürdige Antworten mit Quellenangabe?

Die Erfahrung aus rund 40 Pilotprojekten in der Schweiz zeigt: 60% der Probleme sitzen in der Dokumenten-Qualität (gescannte PDFs ohne OCR, schlechte Chunking-Boundaries), 25% im Retrieval (zu kleine k, fehlendes Reranking), 15% im Modell-Prompt (kein klares Refusal). Eine Pilot-Woche deckt alle drei Schwachstellen auf, bevor Budget für eine produktive Lösung freigegeben wird.

Das zweite Argument ist Lerngewinn im Team: nach 7 Tagen weiss das fachliche Team, was Chunking ist, warum 50 PDFs zu wenig sind und welche Fragen RAG zuverlässig beantwortet. Diese gemeinsame Sprache ist die Voraussetzung für jede weitere Investitionsentscheidung. Ein Stakeholder, der live gesehen hat, wie das System bei Frage X eine korrekte Antwort mit Quelle liefert und bei Frage Y "nicht im Material" sagt, entscheidet anders als jemand, der nur PowerPoints gesehen hat.

Wie der Pilot aufgebaut ist

Der 7-Tage-Plan folgt der klassischen RAG-Pipeline: Ingestion, Chunking, Embedding, Retrieval, Generation, Eval. Pro Tag eine Pipeline-Station, am siebten Tag die Übergabe.

Tag 1 ist Dokumenten-Tag: 50 PDFs aus dem Zielbereich sammeln. Bei einem Treuhand-Use-Case sind das 50 Wegleitungen, Merkblätter und interne SOPs. Wichtig: gemischte Qualität (text-PDFs, gescannte PDFs, Word-Exporte) – der Pilot soll die Realität abbilden, nicht eine saubere Demo-Welt.

Tag 2 ist Infrastruktur: pgvector auf Postgres 15+ installieren (Docker reicht), Tabellen-Schema für Chunks und Embeddings anlegen, Backup-Skript schreiben. pgvector unterstützt seit Version 0.7 HNSW-Indizes mit Sub-Sekunden-Suche bis mehrere Millionen Vektoren.

Tag 3 ist Embedding: BGE-M3 (BAAI, Hugging Face) liefert 1024-dimensionale mehrsprachige Embeddings mit dense+sparse-Hybrid-Mode. Chunking strukturbewusst: nach Absatz-Markern in PDFs (pdfplumber), 400 Tokens pro Chunk mit 80 Tokens Überlappung. Einbettung lokal via FlagEmbedding-Library oder via Ollama mit bge-m3 – beides funktioniert.

Tag 4 ist LLM-Anbindung: LiteLLM-Proxy startet auf Port 4100, ein Provider-Eintrag für Claude Haiku (gross, schnell, EU-Region in Bedrock) und einer für Mistral Large 2 (EU-Hosting). Test-Skript: Frage + Top-8-Chunks + System-Prompt mit Refusal-Instruktion an LiteLLM, JSON-Antwort mit citations.

Tag 5 ist UI: Streamlit-App in unter 100 Zeilen – Suchfeld oben, Antwort-Box mit Quellen-Karten unten. Nutzer kann auf Quelle klicken, sieht den exakten Chunk plus Dokument-Name und Seite. Deploy auf einem internen Server, intern via VPN/Tailscale erreichbar.

Tag 6 ist Eval: 30 Test-Fragen mit Gold-Antworten vom Fach-Team (1 Stunde Workshop). Ragas berechnet drei Scores: Faithfulness (haellt sich die Antwort an die Quellen?), Answer Relevance (passt die Antwort zur Frage?), Context Precision (sind die Top-Chunks relevant?). Zielmarke: Faithfulness > 0.85, andere > 0.70.

Tag 7 ist Übergabe: 90-Minuten-Session mit Stakeholdern, 15 vorbereitete Fragen live durchspielen, Eval-Report präsentieren, Entscheidungsvorlage übergeben.

RAG-Pilot in 7 Tagen

1. 01Tag 1 – 50 PDFs sammeln: Use-Case fixieren (z.B. "MWST-Wegleitungen für Mandanten-FAQ"). 50 PDFs in einem Ordner sammeln, mit Metadaten (Titel, Datum, Quelle) in einer CSV. Mix aus Text-PDFs (sauber) und Scans (verrauscht) – Realitäts-Check.
2. 02Tag 2 – pgvector aufsetzen: Docker `docker run -d --name pgvector -p 5432:5432 -e POSTGRES_PASSWORD=changeme -v pgdata:/var/lib/postgresql/data pgvector/pgvector:pg17`. Schema: `CREATE EXTENSION vector; CREATE TABLE chunks (id BIGSERIAL PRIMARY KEY, doc_id TEXT, page INT, content TEXT, embedding VECTOR(1024)); CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);`.
3. 03Tag 3 – Chunking und Embedding: Python-Skript: `pip install pdfplumber FlagEmbedding`. Pro PDF mit pdfplumber Text extrahieren, in 400-Token-Chunks mit 80-Token-Overlap schneiden. Embedding via `from FlagEmbedding import BGEM3FlagModel; model = BGEM3FlagModel("BAAI/bge-m3"); model.encode(chunks)`. INSERT in pgvector. Erwarte 4.000-8.000 Chunks für 50 PDFs, Embedding-Zeit ca. 15-30 Minuten auf CPU.
4. 04Tag 4 – LiteLLM und Retrieval: LiteLLM via Docker `docker run -d -p 4100:4000 -v $(pwd)/config.yaml:/app/config.yaml ghcr.io/berriai/litellm-stable --config /app/config.yaml`. config.yaml mit zwei Modellen (claude-3-haiku-eu, mistral-large-eu). Python-Retriever: Frage embedden, `SELECT content, doc_id, page FROM chunks ORDER BY embedding <=> $1 LIMIT 8` über pgvector. Top-8 als Kontext an LiteLLM mit System-Prompt "Antworte nur aus Quellen, zitiere [1]..[8], sonst sage `nicht im Material`".
5. 05Tag 5 – Streamlit-UI: `pip install streamlit`. App in app.py: `import streamlit as st; question = st.text_input("Frage"); if question: chunks = retrieve(question); answer = call_llm(question, chunks); st.write(answer); for i, c in enumerate(chunks): with st.expander(f"[{i+1}] {c.doc_id} p.{c.page}"): st.text(c.content)`. Start mit `streamlit run app.py --server.port 8501`. Intern via Tailscale freigeben.
6. 06Tag 6 – Eval mit Ragas: 1-Stunde-Workshop mit Fach-Team, 30 Fragen + Gold-Antworten in eval.csv. `pip install ragas datasets`. Skript: pro Frage Antwort aus System holen, in HuggingFace-Dataset packen, `evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_precision])`. Score-Report als Markdown. Ziel: Faithfulness > 0.85, andere > 0.70.
7. 07Tag 7 – Stakeholder-Demo: 90-Minuten-Termin. 15 vorbereitete Fragen live durchspielen (Mix aus "passt" und "nicht im Material"). Eval-Report präsentieren. Budget-Schätzung für Produktiv-System: kleine Variante CHF 8-15k (Setup) + CHF 200-400/Monat (Betrieb), mittlere CHF 20-40k + CHF 800-1500/Monat. Entscheidungsvorlage mit drei Optionen: weitermachen, anpassen, beerdigen.
8. 08Schritt 8 – Bonus, Phase 2 vorbereiten: Wenn weiterzumachen entschieden: Liste der bekannten Schwachstellen festhalten (OCR-Qualität, Chunk-Boundaries, fehlende Reranker, Refusal-Edge-Cases). Diese Liste ist der Backlog für Sprint 1 nach Pilot. Zusätzlich: Datenschutz-Check für Produktiv-Modus (TIA, ggf. EDÖB-Notiz).

Wann sich der Pilot lohnt

Der Pilot ist die richtige Wahl, wenn (a) Sie über RAG nachdenken aber noch nie eines gebaut haben, (b) das Team Klarheit braucht ob die eigenen Dokumente RAG-tauglich sind, oder (c) ein Budget-Entscheid ansteht und konkretes Material nötig ist.

Konkrete Trigger: Eine Treuhand-Geschäftsleitung diskutiert seit 6 Monaten "wir müssten KI machen" ohne Ergebnis. Eine Anwaltskanzlei hat 5 Jahre Mandanten-Korrespondenz und will wissen, ob ein durchsuchbarer KI-Assistent möglich ist. Ein KMU hat ein QM-Handbuch mit 800 Seiten und will einen Selbst-Service-Bot für Mitarbeiter.

Nach dem Pilot haben Sie drei klare Ergebnisse: (1) Funktionierende Demo mit echten Dokumenten, (2) Ragas-Score-Report mit messbarer Qualität, (3) Budget-Schätzung für Produktiv-System mit klaren Annahmen. Daraus lässt sich entweder ein Produktiv-Projekt starten oder das Vorhaben mit Daten beerdigen.

Wann der Pilot warten sollte

Der Pilot ist nicht der richtige Schritt, wenn (a) die Dokumentenbasis noch nicht digital vorliegt – dann zuerst OCR-Pilot, dann RAG-Pilot. (b) der Use-Case eigentlich generelle KI-Beratung erfordert, nicht Dokumentensuche – RAG ist falsch für "schreibe mir einen Vertrag von Grund auf". (c) das Stakeholder-Team noch nicht weiss, welche Frage sie eigentlich beantworten wollen – dann zuerst Discovery-Workshop, dann Pilot.

Ebenfalls falsch: Pilot mit gemischten Use-Cases ("wir wollen RAG für Mandanten-FAQ UND für Vertrags-Generierung UND für Lohnabrechnung"). Ein Pilot, ein Use-Case. Mehr verkommt zu Demo-Theater und liefert keine entscheidungsreifen Daten.

Weitere Falle: Pilot mit über 200 PDFs. Klingt nach mehr Realismus, kostet aber Tag 1 und Tag 2 statt 1 Stunde und 1 Tag. 50 PDFs sind das Minimum für brauchbare Eval-Scores und gleichzeitig wenig genug für einen 7-Tage-Sprint.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. pgvector – open-source vector extension for Postgres · 2026-05
2. BGE-M3 – multilingual multi-functional multi-granularity embedding (BAAI) · 2026-04
3. Ragas – evaluation framework for RAG pipelines · 2026-05
4. Streamlit documentation – fast Python UIs for ML demos · 2026-04
5. LiteLLM Proxy quick start · 2026-05