Dateninfrastruktur für KI: Vektordatenbanken, ETL & Quality

Dateninfrastruktur für KI: Vektordatenbanken, ETL-Pipelines und Data Quality im Detail

Jedes KI-Projekt steht und fällt mit seinen Daten. Nicht mit dem Modell -- mit der Infrastruktur, die Daten bereitstellt, transformiert und qualitätssichert. Wer GPT-4 oder Claude an eine chaotische Datenbasis anschließt, bekommt chaotische Ergebnisse. Wer dagegen in saubere Pipelines, durchdachte Embedding-Strategien und messbare Datenqualität investiert, baut KI-Systeme, die in der Produktion bestehen.

Dieser Artikel richtet sich an CTOs, IT-Leiter und technische Entscheidungsträger, die ihre Dateninfrastruktur für KI-Anwendungen aufbauen oder modernisieren wollen. Wir behandeln die drei Säulen: Vektordatenbanken, ETL-Pipelines und Data Quality Frameworks -- mit konkreten Vergleichen, Architekturentscheidungen und Praxiserfahrungen aus unserer Projektarbeit bei IJONIS.

Warum Dateninfrastruktur der limitierende Faktor für KI ist

Die meisten KI-Projekte scheitern nicht an der Modellqualität. Sie scheitern an der Datengrundlage. Laut einer Studie von Gartner verbringen Data-Engineering-Teams bis zu 80 % ihrer Zeit mit Datenbereinigung und -integration -- bevor die erste KI-Komponente ins Spiel kommt.

Die Ursache: Unternehmensdaten sind fragmentiert. Sie liegen in ERP-Systemen, SharePoint-Ordnern, E-Mail-Postfächern, Legacy-Datenbanken und Excel-Dateien. Ohne eine dedizierte Infrastrukturschicht, die diese Quellen zusammenführt, bereinigt und in ein für KI-Modelle nutzbares Format bringt, bleibt jedes LLM-Projekt ein Experiment.

Drei Infrastrukturschichten sind entscheidend:

1. Speicherschicht -- Wo und wie werden Daten für KI-Zugriff vorgehalten? Hier kommen Vektordatenbanken ins Spiel.
2. Transformationsschicht -- Wie fließen Daten von Quellsystemen in die Speicherschicht? Das ist die Domäne von ETL-Pipelines.
3. Qualitätsschicht -- Woher wissen Sie, dass die Daten aktuell, vollständig und korrekt sind? Data Quality Frameworks liefern die Antwort.

Für KI-Agenten und RAG-Systeme ist diese Infrastruktur keine optionale Verbesserung -- sie ist die Voraussetzung für produktive Ergebnisse.

Vektordatenbanken: Das Rückgrat semantischer KI-Suche

Warum relationale Datenbanken nicht ausreichen

Klassische Datenbanken speichern Daten in Tabellen und beantworten exakte Abfragen: SELECT * FROM products WHERE name = 'Widget'. Das funktioniert für strukturierte Daten. Aber KI-Anwendungen stellen andere Fragen: Was ist das ähnlichste Dokument zu dieser Kundenanfrage? Welche internen Richtlinien sind für diesen Vertrag relevant?

Vektordatenbanken speichern Daten als hochdimensionale Vektoren -- numerische Repräsentationen (Embeddings), die semantische Bedeutung kodieren. Statt exakter Übereinstimmung liefern sie die nächsten Nachbarn im Vektorraum: Dokumente, die inhaltlich ähnlich sind, auch wenn sie andere Worte verwenden.

Architektur einer Vektordatenbank-Integration

Eine typische Integration in ein KI-System besteht aus vier Komponenten:

• Embedding-Modell: Wandelt Text, Bilder oder Code in Vektoren um (z.B. OpenAI text-embedding-3-large, Cohere Embed, oder Open-Source-Modelle wie e5-large-v2)
• Vektordatenbank: Speichert Vektoren und ermöglicht effiziente Nearest-Neighbor-Suche
• Indexierung: Algorithmus für schnelle Ähnlichkeitssuche (HNSW, IVF, PQ)
• Metadaten-Filterung: Kombination von semantischer Suche mit strukturierten Filtern (z.B. nach Abteilung, Datum, Dokumenttyp)

Vektordatenbank-Vergleich: Pinecone vs. pgvector vs. Qdrant vs. Weaviate

Die Wahl der Vektordatenbank hängt von Ihrem bestehenden Stack, Ihren Skalierungsanforderungen und Ihrem Betriebsmodell ab. Hier eine detaillierte Gegenüberstellung der vier relevantesten Optionen:

Unsere Empfehlung bei IJONIS

• Für den schnellen Einstieg: Pinecone. Kein Infrastruktur-Overhead, schnelle Integration, zuverlässiger Managed Service. Ideal, wenn Sie keine Ops-Kapazität haben und schnell Ergebnisse brauchen.
• Für bestehende PostgreSQL-Setups: pgvector. Keine neue Datenbank nötig, bewährtes Betriebsmodell, SQL-Kompatibilität. Für die meisten mittelständischen Unternehmen der pragmatischste Einstieg.
• Für maximale Kontrolle und Performance: Qdrant. Open Source, hervorragende Latenz, volle Daten-Souveränität bei Self-Hosting. Erste Wahl, wenn Sub-30ms-Latenz geschäftskritisch ist.
• Für hybride Suchszenarien: Weaviate. Native BM25-Integration, GraphQL-API und starke Multi-Tenancy-Fähigkeiten. Besonders geeignet, wenn Sie Vektor- und Keyword-Suche ohne separate Systeme kombinieren wollen.

Embedding-Strategien: Mehr als nur Text in Vektoren wandeln

Die Qualität Ihrer Vektordatenbank steht und fällt mit der Embedding-Strategie. Drei Aspekte sind kritisch:

1. Chunk-Größe und -Strategie

Große Dokumente müssen vor dem Embedding in Chunks aufgeteilt werden. Die Chunk-Größe beeinflusst direkt die Retrieval-Qualität:

• Zu kleine Chunks (< 200 Token): Verlieren Kontext, liefern fragmentierte Ergebnisse
• Zu große Chunks (> 1.000 Token): Verwässern die semantische Präzision
• Optimaler Bereich: 300--500 Token mit 50--100 Token Überlappung

Fortgeschrittene Strategien verwenden hierarchisches Chunking: Ein übergeordneter Chunk liefert Kontext, untergeordnete Chunks liefern Präzision. Das Parent-Document-Retrieval-Pattern ruft den kleinen Chunk zur Suche ab, liefert aber den größeren Kontext-Chunk an das LLM. Detaillierte Chunking-Strategien beschreiben wir in unserem Artikel zu RAG-Systemen.

2. Modellwahl

Nicht jedes Embedding-Modell eignet sich für jeden Use Case:

Für DSGVO-sensible Anwendungen ist Self-Hosting entscheidend. Modelle wie e5-large-v2 oder BGE-M3 laufen auf einer einzelnen GPU und liefern starke Ergebnisse für deutschsprachige Inhalte.

3. Metadaten-Anreicherung

Reine Vektor-Suche reicht selten aus. Metadaten ermöglichen hybride Abfragen:

• Dokumenttyp: Nur in Verträgen suchen, nicht in E-Mails
• Zeitstempel: Nur aktuelle Dokumente berücksichtigen
• Abteilung / Bereich: Zugriffskontrolle über Metadaten-Filter
• Sprache: DE/EN-Dokumente separat filtern

ETL-Pipelines: Datenflüsse für KI automatisieren

Warum manuelle Datenintegration nicht skaliert

Viele Unternehmen starten KI-Projekte mit manuellen Daten-Exporten: CSV-Dateien aus dem ERP, Copy-Paste aus SharePoint, Ad-hoc-Skripte, die Daten transformieren. Das funktioniert für den Prototyp. In der Produktion entstehen daraus drei Probleme:

1. Datenveraltung: Manuelle Exporte sind Momentaufnahmen. Ihre KI arbeitet mit veralteten Daten.
2. Fehleranfälligkeit: Jeder manuelle Schritt ist eine potenzielle Fehlerquelle.
3. Nicht reproduzierbar: Wenn der Kollege, der den Export gemacht hat, krank ist, steht die Pipeline.

ETL-Pipelines (Extract, Transform, Load) lösen diese Probleme: Sie automatisieren den Datenfluss von Quellsystemen in Ihre KI-Infrastruktur -- zuverlässig, nachvollziehbar und skalierbar.

Moderne ETL-Architektur für KI-Systeme

Eine produktionsreife ETL-Pipeline für KI-Anwendungen besteht aus vier Schichten:

Extract -- Daten aus Quellsystemen holen

• Datenbankanbindung (PostgreSQL, MySQL, MSSQL) via Change Data Capture (CDC)
• API-Integration für SaaS-Tools (Salesforce, HubSpot, SharePoint)
• Dateibasierte Extraktion (SFTP, S3, lokale Verzeichnisse)
• Web Scraping für öffentlich zugängliche Daten

Transform -- Daten für KI aufbereiten

• Textextraktion aus PDFs, Word-Dokumenten, E-Mails (Apache Tika, Unstructured.io)
• Sprachbereinigung: Encoding-Probleme, Sonderzeichen, Duplikate
• Strukturierung: Unstrukturierte Texte in definierte Formate überführen
• Embedding-Generierung: Text-Chunks in Vektoren wandeln

Load -- Daten in Zielsysteme schreiben

• Vektordatenbank (Pinecone, pgvector, Qdrant, Weaviate)
• Data Warehouse für analytische Abfragen (BigQuery, Snowflake)
• Knowledge Graph für Beziehungen (Neo4j)

Orchestrate -- Pipelines steuern und überwachen

• Scheduling: Wann laufen welche Pipelines?
• Abhängigkeiten: Pipeline B startet erst, wenn Pipeline A erfolgreich war
• Alerting: Benachrichtigung bei Fehlern
• Monitoring: Laufzeiten, Datenvolumen, Fehlerquoten

Tool-Vergleich: Airflow vs. dbt vs. Prefect

In der Praxis bei IJONIS kombinieren wir häufig Apache Airflow für die Orchestrierung mit dbt für SQL-Transformationen. Für kleinere Projekte oder rein Python-basierte Pipelines ist Prefect eine schlanke Alternative. Die Wahl hängt immer vom bestehenden Stack und den Teamkompetenzen ab.

ELT statt ETL: Der moderne Ansatz

Zunehmend setzt sich ELT (Extract, Load, Transform) durch: Rohdaten werden zuerst in ein Data Warehouse geladen, dann dort transformiert. Vorteile:

• Keine Datenverluste: Rohdaten bleiben erhalten, Transformationen sind wiederholbar
• Flexibilität: Neue Transformationen ohne erneute Extraktion
• Performance: Warehouses wie BigQuery oder Snowflake sind für Transformationen optimiert

Für KI-Pipelines empfehlen wir einen hybriden Ansatz: ELT für strukturierte Daten (Datenbank-Inhalte, CRM-Daten), klassisches ETL für unstrukturierte Daten (Dokumente, E-Mails), die vor dem Laden als Embeddings transformiert werden müssen.

Data Quality: Messbare Datenqualität als KI-Fundament

Warum Datenqualität für KI kritischer ist als für BI

Business-Intelligence-Systeme tolerieren gewisse Datenqualitätsprobleme -- ein fehlender Wert in einem Dashboard fällt auf und wird manuell korrigiert. KI-Systeme sind weniger fehlertolerant: Ein LLM, das auf veralteten oder widersprüchlichen Daten arbeitet, erzeugt halluzinierte Antworten, die plausibel klingen, aber falsch sind.

Das Risiko ist direkt proportional zum Automatisierungsgrad. Wenn ein KI-Agent automatisiert Entscheidungen trifft, wird Datenqualität zur Sicherheitsfrage.

Die fünf Dimensionen der Datenqualität

Ein robustes Data-Quality-Framework misst Qualität entlang standardisierter Dimensionen. Die folgenden fünf Dimensionen sind für KI-Systeme besonders kritisch:

Jede Dimension braucht messbare Schwellenwerte. Beispiel: Vollständigkeit > 95 %, Aktualität < 24 Stunden, Duplikat-Rate < 1 %. Ohne diese Schwellenwerte haben Sie keine Grundlage für Alerting und kein Kriterium für die Freigabe von Daten an KI-Systeme.

Data-Quality-Framework in der Praxis

Ein produktionsreifes Data-Quality-Framework umfasst drei Ebenen:

Ebene 1: Schema-Validierung (automatisch)

• Datentypen prüfen (String, Integer, Date)
• Pflichtfelder verifizieren
• Wertebereichsprüfung (z.B. Preise > 0)
• Format-Validierung (E-Mail, Telefonnummer, IBAN)

Ebene 2: Business-Regeln (konfigurierbar)

• Referenzielle Integrität (Kunden-ID existiert in Kundentabelle)
• Zeitliche Konsistenz (Lieferdatum nach Bestelldatum)
• Plausibilitätsprüfungen (Rechnungsbetrag < 1.000.000 EUR)
• Cross-Source-Validierung (ERP-Daten stimmen mit CRM überein)

Ebene 3: KI-spezifische Qualitätsmetriken

• Embedding-Qualität: Cosine-Similarity-Verteilung der Chunks
• Retrieval-Precision: Liefert die Suche relevante Ergebnisse?
• Chunk-Abdeckung: Sind alle relevanten Dokumente indexiert?
• Aktualitäts-SLA: Maximales Alter der Daten in der Vektordatenbank

Tools für Datenqualität

• Great Expectations: Open-Source-Framework für Datenvalidierung mit deklarativen Expectations. Integriert sich nahtlos in Airflow und dbt.
• dbt Tests: SQL-basierte Datentests, integriert in die Transformations-Pipeline. Ideal für referenzielle Integrität und Business-Regeln.
• Soda: Data-Quality-Checks als YAML-Konfiguration, SaaS oder Self-hosted. Einsteigerfreundlich mit guter Visualisierung.
• Monte Carlo: Data Observability Platform, erkennt Anomalien automatisch. Sinnvoll ab mittlerer Komplexität.

Data Governance: Organisatorische Rahmenbedingungen

Technik allein reicht nicht. Dateninfrastruktur braucht organisatorische Governance -- ohne sie entstehen Datensilos, Verantwortungslücken und Compliance-Risiken.

Data Ownership

Jeder Datensatz braucht einen verantwortlichen Owner -- nicht IT, sondern die Fachabteilung, die die Daten erzeugt und nutzt. Der Owner entscheidet über Qualitätsstandards, Zugriffsrechte und Löschfristen. Ohne klare Ownership werden Datenqualitätsprobleme zu Schuldzuweisungen statt zu Lösungen.

Data Catalog

Ein zentrales Verzeichnis aller Datenquellen, Schemas und Qualitätsmetriken. Tools wie DataHub, Atlan oder Amundsen machen Datenlandschaften durchsuchbar. Für KI-Systeme ist der Data Catalog der Ausgangspunkt jeder neuen Integration: Welche Daten existieren, wer ist verantwortlich, welche Qualität haben sie?

Zugriffssteuerung

Welcher KI-Agent darf auf welche Daten zugreifen? Row-Level-Security und Metadaten-basierte Filter verhindern, dass sensible Daten in die falschen Kontexte gelangen. Besonders relevant für RAG-Systeme, bei denen die Vektordatenbank den Zugriff auf Dokumentebene steuern muss.

Lineage-Tracking

Von der Quelle über ETL-Transformationen bis zum Embedding -- jede Veränderung muss nachvollziehbar sein. Das ist nicht nur Best Practice, sondern für den EU AI Act eine Pflicht. Wenn ein KI-System eine Entscheidung trifft, muss dokumentiert sein, welche Daten in welcher Qualität zur Grundlage dieser Entscheidung dienten.

Für Unternehmen, die Prozessautomatisierung mit KI einsetzen, ist Data Governance keine bürokratische Übung, sondern die Grundlage für Vertrauen in automatisierte Entscheidungen.

Architektur-Blueprint: Dateninfrastruktur für KI-Systeme

Zusammengefasst ergibt sich folgende Referenzarchitektur, die wir bei IJONIS als Ausgangspunkt für Kundenprojekte verwenden:

Schicht 1 -- Quellsysteme: ERP, CRM, SharePoint, E-Mail, Dateisysteme, APIs

Schicht 2 -- Ingestion: Change Data Capture, API-Konnektoren, Datei-Watcher, Web Scraper

Schicht 3 -- Transformation: dbt-Modelle (strukturiert), Unstructured.io + Embedding-Modell (unstrukturiert)

Schicht 4 -- Speicherung: Data Warehouse (strukturiert) + Vektordatenbank (Embeddings) + Knowledge Graph (Beziehungen)

Schicht 5 -- Zugriff: RAG-Pipeline, KI-Agenten, Dashboards, APIs

Schicht 6 -- Qualität & Governance: Great Expectations, Monitoring-Dashboards, Data Catalog, Lineage-Tracking

Dieser Blueprint ist kein starres Schema. Er wird für jedes Projekt an die bestehende IT-Landschaft, regulatorische Anforderungen und Skalierungsziele angepasst.

FAQ: Dateninfrastruktur für KI

Brauche ich eine Vektordatenbank, oder reicht meine bestehende PostgreSQL-Instanz?

Wenn Sie bereits PostgreSQL einsetzen, ist pgvector der einfachste Einstieg -- keine neue Datenbank, bewährtes Betriebsmodell. Für bis zu einige Millionen Vektoren liefert pgvector ausreichende Performance. Bei höheren Anforderungen an Latenz (< 30 ms), Skalierung (Milliarden Vektoren) oder erweiterte Filterfunktionen lohnt sich der Umstieg auf eine dedizierte Lösung wie Qdrant oder Weaviate. Pinecone ist die richtige Wahl, wenn Sie keinen Betriebsaufwand wollen.

Wie lange dauert der Aufbau einer KI-Dateninfrastruktur?

Rechnen Sie mit 4--8 Wochen für eine produktionsreife Grundinfrastruktur: Vektordatenbank, erste ETL-Pipelines und grundlegende Qualitäts-Checks. Komplexere Setups mit mehreren Quellsystemen, Data Governance und umfassendem Monitoring benötigen 3--6 Monate. Bei IJONIS starten wir mit einer Analysephase, die in 2 Wochen eine Roadmap liefert.

Welche Daten sollte ich zuerst in die Vektordatenbank laden?

Starten Sie mit den Daten, die den höchsten Geschäftswert für Ihren ersten KI-Use-Case haben. Typischerweise sind das interne Wissensdokumente (Handbücher, SOPs, Richtlinien), die als Grundlage für ein RAG-System dienen. Vermeiden Sie den Versuch, alles auf einmal zu indexieren -- beginnen Sie fokussiert und erweitern Sie iterativ.

Wie stelle ich sicher, dass meine Daten DSGVO-konform in der Vektordatenbank liegen?

Drei Maßnahmen sind entscheidend: Erstens, personenbezogene Daten vor dem Embedding anonymisieren oder pseudonymisieren. Zweitens, die Vektordatenbank in der EU hosten (Self-hosted oder EU-Cloud-Region). Drittens, ein Löschkonzept implementieren -- wenn ein Betroffener die Löschung seiner Daten verlangt, müssen auch die zugehörigen Vektoren gelöscht werden können. Beachten Sie: Vektoren sind nicht trivial rückverfolgbar, deshalb ist eine saubere Mapping-Tabelle zwischen Quelldaten und Vektor-IDs Pflicht.

Was kostet eine produktionsreife Dateninfrastruktur für KI?

Die Kosten variieren stark je nach Umfang. Ein Richtwert: Für ein mittelständisches Setup mit einer Vektordatenbank, ETL-Pipelines und grundlegendem Monitoring rechnen Sie mit 1.500--5.000 EUR/Monat an Infrastrukturkosten. Dazu kommen einmalige Aufbaukosten für Architektur, Implementierung und Integration. Der ROI ergibt sich aus der Qualität und Geschwindigkeit Ihrer KI-Anwendungen -- schlechte Dateninfrastruktur ist der teuerste Fehler, den Sie machen können.

Fazit: Dateninfrastruktur ist kein Overhead -- sie ist das Fundament

Die Versuchung ist groß, direkt mit dem LLM-Prototyp zu starten und die Dateninfrastruktur nachzuziehen. In der Praxis funktioniert das nicht. Ohne saubere ETL-Pipelines arbeitet Ihre KI mit veralteten Daten. Ohne durchdachte Embedding-Strategie liefert die semantische Suche irrelevante Ergebnisse. Ohne Qualitätsmetriken wissen Sie nicht, wann die Daten nicht mehr stimmen.

Dateninfrastruktur ist kein Kostenfaktor -- sie ist der Multiplikator für den ROI Ihrer gesamten KI-Strategie. Unternehmen, die hier investieren, skalieren ihre KI-Anwendungen. Unternehmen, die hier sparen, bauen ein KI-Projekt nach dem anderen, das nie über den Prototyp hinauskommt.

Bereit, Ihre Dateninfrastruktur für KI aufzubauen? Sprechen Sie mit unseren Experten -- wir analysieren Ihre Datenlandschaft und entwickeln eine Architektur, die Ihre KI-Systeme produktionsreif macht.

---

Wie bereit ist Ihr Unternehmen für KI? Erfahren Sie in unserem KI-Readiness-Check Guide, welche 6 Dimensionen entscheidend sind — oder starten Sie direkt den kostenlosen Check →