Daten & Wissen
Start › 7 · Daten & Wissen
Daten & Wissen – wie KI an dein Wissen kommt
Ein Modell kennt nur, was es im Training gesehen hat – dein Firmenwissen gehört nicht dazu. Diese Seite zeigt die Kette, mit der eigenes Wissen nutzbar wird: Datenablage → Embeddings → Vektor-Datenbank → RAG.
RAG Retrieval-Augmented Generation Antworten mit Nachschlagen
Die wichtigste Technik, um KI mit eigenem Wissen zu versorgen: passende Textstellen suchen (Retrieval), in den Prompt legen (Augmented), dann antworten lassen (Generation) – siehe Schaubild 8.
Vorteile
- Eigenes, aktuelles Wissen nutzbar
- Weniger Halluzinationen, Quellen zitierbar
- Änderungen ohne Neutraining
Nachteile
- Datenbasis muss gepflegt werden
- Qualität steht & fällt mit der Suche
- Mehr Tokens pro Anfrage
RAG — Retrieval-Augmented Generation — Antworten mit Nachschlagen: dein Wissen in die KI, ohne Training
1Begriff
RAG = Retrieval-Augmented Generation, sinngemäß „Erzeugung, angereichert durch Abruf“: erst passende Textstellen suchen, dann mit ihnen antworten.
2Bedeutung
Die wichtigste Unternehmens-KI-Technik überhaupt: Sie verbindet ein generisches Modell mit deinem aktuellen Wissen (Verträge, Wiki, Support-Fälle) – nachvollziehbar mit Quellenangabe.
3Funktionsweise
Zwei Phasen (Schaubild 8): Indexierung – Dokumente zerlegen (Chunking) → Embeddings berechnen → in Vektor-DB speichern. Abfrage – Frage einbetten → ähnlichste Chunks holen (Retrieval) → optional neu bewerten (Reranking) → dem LLM als Kontext mitgeben → Antwort mit Zitaten.
4Hintergrund
Qualität entscheidet sich fast immer im Retrieval, nicht im LLM: schlechtes Chunking/Suche → schlechte Antworten („garbage in“). Moderne Muster: Hybrid-Suche (Vektor + Stichwort), Agentic RAG (Agent sucht iterativ, formuliert Suchanfragen um), GraphRAG (Wissensgraphen für BeziehungFragen). Frameworks: LlamaIndex, LangChain, Haystack.
5Alternativen
| Ansatz | Wann besser |
|---|---|
| Alles ins Kontextfenster | wenige, kleine Dokumente – einfachste Lösung |
| Fine-Tuning | Verhalten/Stil statt Faktenwissen |
| Websuche-Tool | öffentliches, aktuelles Wissen |
| Klassische Suche (nur Retrieval) | wenn Nutzer selbst lesen wollen |
6Vor- & Nachteile
- + Aktuell & änderbar ohne Training, Quellen zitierbar, weniger Halluzination, Zugriffsrechte abbildbar.
- − Pipeline muss gebaut & gepflegt werden; Qualität = Datenqualität; mehr Tokens/Latenz pro Anfrage; Evaluation nötig.
7Kosten
Klein anfangen ist billig: Embeddings sind spottbillig (~0,01–0,1 €/Mio. Tokens), OSS-Vektor-DB gratis – ein Abteilungs-Wiki-RAG läuft ab wenigen €/Monat. Enterprise-Suiten (fertige „Chat mit deinen Daten“-Produkte) kosten je Nutzer/Monat zweistellig.
8Empfehlung
Der richtige erste Firmen-Use-Case: klein starten (ein Dokumentenbestand, z.B. via Open WebUI oder AnythingLLM), Antworten mit Quellen erzwingen, echte Nutzerfragen sammeln – und erst dann in professionelles Chunking/Reranking investieren. Merksatz: Wissen → RAG, Verhalten → LoRA.
Embedding Bedeutung als Zahlen-Vektor
Die Übersetzung von Text (oder Bildern) in einen Zahlen-Vektor, der die Bedeutung einfängt: Ähnliche Inhalte bekommen ähnliche Vektoren. „Urlaubsantrag“ und „Ferien beantragen“ landen nah beieinander – obwohl kein Wort übereinstimmt.
Embedding — Bedeutung als Zahlen-Vektor — die Grundlage semantischer Suche
1Begriff
Embedding („Einbettung“): Darstellung von Text/Bild als Zahlen-Vektor (typisch 384–3072 Dimensionen), bei der ähnliche Bedeutung = ähnliche Vektoren gilt.
2Bedeutung
Macht Bedeutung berechenbar: „Urlaubsantrag“ und „Ferien beantragen“ liegen nah beieinander, obwohl kein Wort übereinstimmt. Fundament von RAG, semantischer Suche, Empfehlungen, Duplikat- und Anomalie-Erkennung.
3Funktionsweise
Ein spezialisiertes Embedding-Modell (nicht der Chat-LLM!) verwandelt Text in einen Vektor; Ähnlichkeit wird als Winkel gemessen (Kosinus-Ähnlichkeit). Wichtig: Anfrage und Dokumente immer mit demselben Modell einbetten – Vektoren verschiedener Modelle sind inkompatibel.
4Hintergrund
Konzeptgeschichte: word2vec (2013, „König − Mann + Frau ≈ Königin“) → heutige kontextuelle Satz-/Dokument-Embeddings. Auch LLM-intern regieren Embeddings: der Latent Space („Bedeutungsraum“). Modellwahl-Hilfe: MTEB-Leaderboard; starke offene Familien: BGE, GTE, Qwen-Embedding, E5; API-Klassiker: OpenAI text-embedding-3, Cohere, Voyage.
5Alternativen
- Stichwortsuche (BM25): exakte Begriffe/IDs – schlägt Vektoren bei Artikelnummern & Namen; ideal: hybrid kombinieren.
- Reranker: Zweitmodell, das Trefferlisten präzisiert.
- Wissensgraphen: für explizite Beziehungen.
6Vor- & Nachteile
- + Findet Sinn statt nur Wortlaut; sprachübergreifend; billig & schnell.
- − Exakte Codes/Zahlen sind Schwäche; „ähnlich“ ≠ „relevant“; Modellwechsel = alles neu einbetten.
7Kosten
Winzig: API-Embeddings ~0,01–0,15 €/Mio. Tokens; offene Modelle laufen auf CPU/kleiner GPU gratis. Ein ganzes Firmen-Wiki einzubetten kostet meist unter 10 €.
8Empfehlung
Nicht überdenken: ein aktuelles Modell aus den MTEB-Top-10 (offen: BGE/GTE-Klasse) reicht fast immer. Wichtiger als das Modell: sauberes Chunking und Hybrid-Suche. Embedding-Modell einmal wählen, dokumentieren, dabei bleiben.
Vektor-Datenbank Vector Database Ähnlichkeits-Speicher
Eine Datenbank, die auf das Speichern und blitzschnelle Durchsuchen von Embeddings spezialisiert ist: „Gib mir die 5 ähnlichsten Einträge zu diesem Vektor“ – über Millionen Dokumente in Millisekunden.
Vektor-Datenbank — Der Ähnlichkeits-Speicher hinter RAG & Co.
1Begriff
Vektor-Datenbank (vector database/store): Datenbank, spezialisiert auf Speichern und Ähnlichkeits-Durchsuchen von Embeddings („nächste-Nachbarn-Suche“).
2Bedeutung
Das Langzeitgedächtnis vieler KI-Systeme: Sie beantwortet in Millisekunden „Welche der Millionen Textstellen ähneln dieser Frage am meisten?“ – die Kernoperation von RAG, Empfehlungen und Memory-Funktionen.
3Funktionsweise
Exakter Vergleich mit Millionen Vektoren wäre zu langsam → ANN-Indizes (Approximate Nearest Neighbor, z.B. HNSW-Graphen): minimal ungenauer, dafür tausendfach schneller. Gespeichert wird Vektor + Originaltext + Metadaten (Quelle, Datum, Rechte) – Filter wie „nur HR-Dokumente ab 2025“ kombinierbar mit Ähnlichkeit.
4Hintergrund
2023 gehypte Spezial-Kategorie; inzwischen Konsolidierung: Klassische Datenbanken (Postgres, Elasticsearch, MongoDB, SQLite) haben Vektorsuche eingebaut – oft reicht das völlig.
5Alternativen / Auswahl
| Lösung | Art | Ideal für |
|---|---|---|
| pgvector (Postgres) | DB-Erweiterung | Pragmatiker: Vektoren neben Bestandsdaten |
| Chroma | OSS, leichtgewichtig | Prototypen, lokale Projekte |
| Qdrant / Weaviate / Milvus | OSS-Server (+Cloud) | ernsthafte selbstgehostete Systeme |
| Pinecone | Managed Cloud | null Betrieb, Skalierung auf Knopfdruck |
| Elasticsearch/OpenSearch | Suche+Vektor | wo es schon im Haus läuft; Hybrid-Suche stark |
6Vor- & Nachteile der Spezial-DBs
- + Optimale Performance/Features (Quantisierung, Multi-Tenant, Filter) bei großen Mengen.
- − Noch eine Infrastruktur-Komponente; bei <100k Vektoren meist unnötig (pgvector/Chroma reicht).
7Kosten
OSS: gratis + Serverchen. Managed: Einstieg ~0–50 €/Monat, wächst mit Volumen. Speicherbedarf grob: 1 Mio. Chunks ≈ wenige GB.
8Empfehlung
Standard-Pfad: Prototyp mit Chroma → Produktion mit pgvector, wenn ohnehin Postgres läuft → Spezial-DB (Qdrant & Co.) erst ab Millionen Vektoren oder besonderen Anforderungen. Nicht die DB, sondern Chunking + Hybrid-Suche entscheiden über Qualität.
Data Lake · Warehouse · Lakehouse Die großen Datenspeicher
Wo Unternehmensdaten wohnen, bevor KI sie nutzt: Der Data Lake („Datensee“) sammelt alles roh und unsortiert; das Data Warehouse („Datenlager“) hält geprüfte, strukturierte Daten für Auswertungen; das Lakehouse kombiniert beides.
Data Lake · Data Warehouse · Lakehouse — Wo Unternehmensdaten wohnen, bevor KI sie nutzt
1Begriff
Data Lake („Datensee“) = Rohdaten-Sammelbecken jeder Art. Data Warehouse („Datenlager“) = geprüfte, strukturierte Daten für Auswertungen. Lakehouse = moderne Kombination beider Ideen. (Dein „datahouse“ meint i.d.R. Warehouse/Lakehouse.)
2Bedeutung
KI ist nur so gut wie ihre Datenbasis: Trainingsdaten, RAG-Wissensbasen und Auswertungen speisen sich aus diesen Speichern. „KI-Strategie“ beginnt fast immer als Datenstrategie.
3Funktionsweise
Lake: billiger Objektspeicher (S3 & Co.), alles rein im Rohformat – „Schema beim Lesen“. Warehouse: Daten werden per ETL/ELT (Extract–Transform–Load) gesäubert und in Tabellen gegossen – „Schema beim Schreiben“, schnell & verlässlich für Berichte. Lakehouse: offener Tabellen-Layer (Delta Lake, Apache Iceberg) direkt auf dem Lake – ein Speicher für Analytics und KI.
4Hintergrund
Typische Produkte: Lake = AWS S3, Azure Data Lake · Warehouse = Snowflake, BigQuery, Redshift · Lakehouse = Databricks, Iceberg-Stacks. Warnbegriff „Data Swamp“: ein Lake ohne Katalog/Pflege wird zum Sumpf, in dem niemand mehr etwas findet – Governance (Katalog, Qualität, Zugriffsrechte) ist Pflicht.
5Alternativen (für den kleineren Maßstab)
- Klassische Datenbank (Postgres): reicht KMUs oft völlig.
- DMS/Wiki + RAG: für Dokumentenwissen braucht es kein Data-Lakehouse.
- DuckDB: „Warehouse im Kleinformat“ auf dem Laptop – unterschätzt.
6Vor- & Nachteile
- Lake + billig, flexibel, KI-freundlich (Rohdaten!) / − Sumpf-Gefahr, langsamere Abfragen.
- Warehouse + schnell, verlässlich, BI-Standard / − teurer, starrer, Rohdaten fehlen.
- Lakehouse + ein Speicher für alles, offene Formate / − jüngeres Paradigma, Plattform-Bindungsrisiko.
7Kosten
Objektspeicher ~0,02 €/GB/Monat (Lake ist billig); Warehouse/Lakehouse rechnen nach Rechenzeit – von Hunderten bis Zehntausenden €/Monat je nach Nutzung. Größter versteckter Posten: Daten-Engineering-Arbeitszeit.
8Empfehlung
Für KI-Vorhaben gilt: Erst klären, welche Daten die KI wirklich braucht – für Dokumenten-Chat reicht ein sauberer Dokumentenbestand + RAG; ein Lakehouse lohnt, wenn Analytics + ML + KI dieselbe große Datenbasis teilen sollen. Neue Infrastruktur nie „für die KI“ allein bauen.