De
En
Fr
It
Es
Uk
Was ist RAG-Entwicklung und wann braucht Ihr Unternehmen sie?
RAG-Entwicklung ist die Engineering-Arbeit, ein großes Sprachmodell so mit Ihrem eigenen Wissen zu verbinden, dass die Antworten aus Ihren Dokumenten stammen und nicht aus dem, was das Modell im Training auswendig gelernt hat. Ein Unternehmen braucht RAG, wenn immer wieder Fragen gestellt werden, deren Antworten intern bereits irgendwo existieren: Support-Textbausteine, Produkthandbücher, Verträge, Richtlinien, alte Tickets, ein Wiki, das niemand durchsuchen kann. Statt ein Modell neu zu trainieren, ruft ein RAG-System für jede Frage die wenigen relevanten Passagen ab und übergibt sie dem Modell mit der Anweisung, daraus zu antworten und sie zu zitieren.
Typische RAG-Implementierungen, nach denen wir gefragt werden:
- Ein interner Assistent, der Fragen von Mitarbeitern aus Richtlinien, SOPs und dem Wiki beantwortet.
- Ein Kundensupport-Assistent auf Basis von Help-Center-Artikeln und gelösten Tickets (siehe KI-Chatbot entwickeln lassen).
- Suche und Fragebeantwortung über Verträge, Spezifikationen oder technische Dokumentation.
- Eine "Gedächtnis"-Schicht für ein KI-Produkt, damit sich der Assistent Fakten über einen bestimmten Nutzer oder ein Konto merkt.
Wie funktioniert eine produktive RAG-Pipeline?
Eine produktive RAG-Pipeline hat zwei Hälften: eine Offline-Ingestion-Seite, die Ihr Wissen aufbereitet, und eine Online-Abfrageseite, die Fragen beantwortet. Die meisten Genauigkeitsprobleme stammen von der Ingestion-Seite, deshalb investieren wir dort echte Engineering-Zeit, statt sie als einmaliges Skript zu behandeln.
| Stufe | Was passiert | Wo es meist schiefgeht |
|---|---|---|
| 1. Ingestion | Konnektoren holen Inhalte aus Dateien, Confluence, Google Drive, Notion, Datenbanken, Ticketing-Tools oder APIs | Fehlende Quellen, keine inkrementelle Synchronisierung, veraltete Kopien |
| 2. Bereinigung und Parsing | Text, Tabellen und Überschriften werden extrahiert; Duplikate und Standardtexte entfernt; gescannte PDFs per OCR verarbeitet | Tabellen werden zu Rauschen plattgedrückt, Kopf- und Fußzeilen wiederholen sich in jedem Chunk |
| 3. Chunking | Dokumente werden in Passagen mit Metadaten (Quelle, Abschnitt, Datum, Zugriffsstufe) zerlegt | Chunks enden mitten im Satz oder sind zu groß, um spezifisch zu sein |
| 4. Embeddings | Jeder Chunk wird mit einem Embedding-Modell in einen Vektor umgewandelt | Modell passt nicht zu Sprache oder Fachgebiet |
| 5. Speicherung | Vektoren und Metadaten werden in einer Vektordatenbank gespeichert | Keine Filterung nach Berechtigung oder Datum |
| 6. Retrieval | Hybride Suche (Vektor plus Stichwort), danach Reranking der Top-Ergebnisse | Die richtige Antwort existiert, landet aber auf Platz 15 |
| 7. Generierung | Das LLM antwortet aus den abgerufenen Passagen, mit Quellenangaben | Modell ignoriert den Kontext oder mischt externes Wissen hinein |
| 8. Evaluation und Monitoring | Ein Testdatensatz und Live-Feedback messen die Genauigkeit über die Zeit | Niemand bemerkt, dass die Qualität nach einer Datenänderung sinkt |
Wie sollten Dokumente für RAG in Chunks zerlegt werden?
Das Chunking sollte der Struktur Ihrer Dokumente folgen, nicht einer festen Zeichenzahl. Ein guter Standard ist, nach Überschriften und Absätzen in Passagen von einigen hundert Tokens zu teilen, eine kleine Überlappung zu behalten und jedem Chunk Metadaten mitzugeben: Dokumenttitel, Abschnittspfad, Datum, Sprache und wer ihn sehen darf. Der Überschriftenpfad ist wichtig, denn ein Chunk mit dem Satz "die Frist beträgt 30 Tage" ist nutzlos, wenn man nicht weiß, dass er aus "Erstattungen > EU-Kunden" stammt.
Bestimmte Inhaltstypen brauchen eine eigene Behandlung. Tabellen bleiben vollständig erhalten oder werden in Aussagen pro Zeile umgewandelt. FAQs werden mit einer Frage pro Chunk zerlegt. Lange Verträge werden nach Klauseln aufgeteilt, wobei die Klauselnummer erhalten bleibt. Chatverläufe und Tickets werden nach Gespräch gruppiert, nicht nach Zeile. Wir testen zwei oder drei Chunking-Strategien gegen denselben Evaluationsdatensatz und behalten diejenige, die am häufigsten die richtige Passage findet, statt zu raten.
Welche Embeddings und welche Vektordatenbank sollten Sie verwenden?
Embedding-Modell und Vektordatenbank sollten nach Datenvolumen, Sprachen und Hosting-Vorgaben gewählt werden, und beide sollten später austauschbar sein. Wir kapseln sie im Code hinter einer kleinen Schnittstelle, sodass ein Anbieterwechsel eine Neuindexierung ist und kein Neubau.
| Option | Passt gut für | Abwägungen |
|---|---|---|
| pgvector (PostgreSQL) | Teams, die bereits PostgreSQL nutzen, bis zu einigen Millionen Chunks, Berechtigungen in derselben Datenbank | Bei größerem Umfang Tuning nötig; weniger eingebaute Suchfunktionen |
| Qdrant | Größere Sammlungen, umfangreiche Metadatenfilter, Self-Hosting in Ihrer eigenen Cloud | Ein weiterer Dienst im Betrieb |
| Weaviate oder Milvus | Sehr große Sammlungen, eingebaute hybride Suche | Höherer Betriebsaufwand |
| Pinecone (managed) | Teams, die keinerlei Datenbankbetrieb wollen | Anbieterabhängigkeit, Daten verlassen Ihre Infrastruktur |
| OpenSearch oder Elasticsearch mit Vektoren | Unternehmen, die es bereits für die Stichwortsuche betreiben | Vektorfunktionen weniger ausgereift als bei spezialisierten Engines |
Für Embeddings sind gehostete Modelle von OpenAI und ähnlichen Anbietern der schnellste Einstieg. Offene Embedding-Modelle laufen auf Ihren eigenen Servern, wenn Daten Ihre Umgebung nicht verlassen dürfen. Mehrsprachige Inhalte (zum Beispiel Englisch plus Französisch oder Ukrainisch) brauchen ein Modell, das auf diesen Sprachen getestet ist, was wir in der Evaluation prüfen, statt es vorauszusetzen.
Wie messen Sie die Genauigkeit von RAG?
Die Genauigkeit von RAG wird mit einem festen Evaluationsdatensatz gemessen: 50 bis 200 echte Fragen Ihrer Nutzer, jeweils mit der erwarteten Antwort und der Quelle, aus der sie stammen sollte. Ohne diesen Datensatz ist jede Qualitätsdiskussion Meinung. Mit ihm erhält jede Änderung an Chunking, Prompts, Modellen oder Daten einen vergleichbaren Wert.
Wir verfolgen vier Kennzahlen:
- Retrieval-Trefferquote: Ist die richtige Passage unter den Top-Ergebnissen?
- Faithfulness: Sagt die Antwort nur das aus, was die abgerufenen Passagen enthalten?
- Antwortkorrektheit: Stimmt die Antwort mit der erwarteten überein, beurteilt von einem Prüfer oder einem LLM-Bewerter, der gegen menschliche Stichproben abgeglichen wird?
- Qualität der Ablehnung: Wenn die Antwort nicht in der Wissensbasis steht, sagt das System das, statt eine zu erfinden?
In Produktion ergänzen wir Nutzerfeedback (Daumen hoch oder runter mit Begründung), die Protokollierung der abgerufenen Quellen pro Antwort, Kosten pro Anfrage und Latenz. Der Evaluationsdatensatz läuft vor jedem Release automatisch, genau wie Unit-Tests.
Was ist mit Datenschutz, Berechtigungen und Modellwahl?
Ein RAG-System darf einem Nutzer niemals eine Passage zeigen, die er in der Originalquelle nicht öffnen könnte. Wir speichern Zugriffsregeln als Chunk-Metadaten und filtern beim Retrieval, sodass Berechtigungen durchgesetzt werden, bevor das Modell irgendetwas sieht. Sensible Daten können bei der Aufnahme verschlüsselt werden; in unserem Projekt AI Grief Companion wird jede Nachricht einzeln mit AES-256-GCM unter einem KMS-Envelope-Key verschlüsselt, und ein Nutzer kann mit einem Klick alles löschen.
Für den Generierungsschritt arbeiten wir mit den APIs von OpenAI und Anthropic Claude sowie mit offenen Modellen, die auf Ihrer eigenen Infrastruktur laufen (dasselbe Projekt betreibt Qwen2.5-7B-Adapter über vLLM). Die Wahl hängt von Datenvorgaben, Sprachen, Latenz und Kosten pro Antwort ab. Prompts liegen, wo es hilft, mit Versionshistorie in der Datenbank, sodass Tonalität und Anweisungen ohne Code-Release angepasst werden können.
Was kostet RAG-Entwicklung?
Die Kosten der RAG-Entwicklung hängen vor allem davon ab, wie viele Quellen Sie anbinden, wie unaufgeräumt sie sind und wie streng die Anforderungen an Genauigkeit und Berechtigungen sind. Ein Proof of Concept auf einer Quelle mit Evaluationsdatensatz dauert typischerweise 3 bis 6 Wochen, ein produktiver Assistent mit mehreren Quellen, Berechtigungen und UI 2 bis 4 Monate, RAG auf Plattformebene über mehrere Produkte mit eigenen Modellen länger.
Die laufenden Kosten kommen hinzu: Modell-Tokens pro Antwort, Embedding-Kosten bei jeder Neuindexierung und das Hosting der Vektordatenbank. Wir schätzen die Kosten pro 1.000 Fragen bereits im Proof of Concept, damit es keine Überraschungen gibt, und nennen nach einem kurzen Scoping-Gespräch einen Festpreis für die vereinbarten Meilensteine. Ein RAG-Assistent über Ihr Wissen beginnt bei uns ab 5.000 USD; unser Leitfaden zu den Kosten der KI-Agenten-Entwicklung zeigt größere Umfänge.
Wo haben wir RAG- und LLM-Systeme gebaut?
Unsere umfassendste Retrieval-Arbeit ist der AI Grief Companion für ein US-Startup: Ein Ingestion-Gateway in Python verarbeitet zehn Chat-Exportformate zu einer einheitlichen, normalisierten Nachrichtentabelle, und eine ML-Pipeline erstellt ein Persönlichkeitsprofil, einen Faktengraphen in Neo4j, RAG-Gedächtnis und LoRA-Adapter. Der Chat nutzt immer die jeweils fertige Stufe, sodass Nutzer mit dem System sprechen können, bevor das Training abgeschlossen ist.
Auf Produktseite nutzt AI Resume Master, unser eigener Lebenslauf-Builder, LLMs, um Lebensläufe und Anschreiben zu erzeugen, umzuschreiben und zu verbessern, und erreichte 50.000 monatlich aktive Nutzer. Für das Gesamtbild, wie man LLM-Funktionen in ein bestehendes Produkt einbaut, siehe KI-Integration und unseren Leitfaden zur RAG-Implementierung.
Wie wir in RAG-Projekten arbeiten
Wir beginnen mit einem kurzen Scoping-Gespräch und einer Discovery: Wir sehen uns Ihre Quellen an, sammeln echte Fragen und bauen gemeinsam mit Ihrem Team den Evaluationsdatensatz. Dann liefern wir einen Proof of Concept auf einer Quelle mit gemessener Genauigkeit und skalieren erst danach auf weitere Quellen, Berechtigungen und eine produktive Oberfläche. Senior-Engineers verantworten die Architektur; intern nutzen wir KI-Coding-Agenten, um bei der Infrastrukturarbeit schneller voranzukommen.
Wenn Sie eine Wissensbasis haben, zu der immer wieder dieselben Fragen gestellt werden, buchen Sie ein Scoping-Gespräch und bringen Sie fünf Beispielfragen mit. Wir sagen Ihnen ehrlich, ob RAG das richtige Werkzeug ist.
