lab: rag-lab / retrieval / evals
Kontext: Ein LLM kann schön antworten, auch wenn es eigentlich nicht sicher sein darf. Deshalb beginnt RAG für mich nicht mit einem Index, sondern mit der Frage: Welche Antworten sind überprüfbar und welche Quellen müssen für Nutzer sichtbar sein?
Problem: Wenn man Dokumente nur schneidet und top-k an das Modell schickt, wird Qualität schnell zufällig. Schlechtes Chunking, verrauschte Treffer, fehlende Eval Cases und keine Erklärbarkeit machen das System zur Blackbox.
Ansatz: Ich trenne Ingestion, Retrieval, Rerank und Answer Synthesis. Für jede Schicht braucht man Logs: welches Dokument im Kontext gelandet ist, warum es gewählt wurde, welchen Teil der Antwort es stützt und wo das Modell die Quellen verlässt.
Fazit: RAG wird erst dann ein Production-Tool, wenn es ein kleines, aber lebendiges Eval-Set gibt. Es zeigt Regressionen nach Modell-, Prompt-, Chunking- oder Embedding-Wechsel.
Nächster Schritt: ein Qualitätsdashboard bauen: Hit Rate, Citation Coverage, Hallucination Flags und manuelle Prüfung strittiger Antworten.