RAG: Eigenes Firmenwissen für KI nutzbar machen

Von Sascha Huber 14. September 2026

Ein großes Sprachmodell wie Claude oder GPT kennt erstaunlich viel über die Welt, aber nichts über Ihr Unternehmen. Es kennt weder Ihre internen Prozesse noch Ihre Produktdokumentation, weder Ihre Verträge noch die Antworten Ihres Support-Teams. Genau hier setzt Retrieval Augmented Generation an, kurz RAG. Diese Architektur verbindet ein Sprachmodell mit Ihrer eigenen Wissensbasis und liefert Antworten, die auf Ihren tatsächlichen Dokumenten beruhen. In diesem Artikel zeige ich Ihnen, wie RAG funktioniert, welche Bausteine dazugehören und worauf es bei einer professionellen Umsetzung im Unternehmen wirklich ankommt.

Warum ein Sprachmodell allein nicht ausreicht

Wenn Sie ein Sprachmodell direkt nach internen Informationen fragen, stoßen Sie schnell an drei grundlegende Grenzen. Diese Grenzen sind keine Schwächen einzelner Modelle, sondern systembedingt. Wer sie versteht, versteht auch, warum RAG zur Standardarchitektur für unternehmensinterne KI-Anwendungen geworden ist.

Halluzinationen

Ein Sprachmodell ist darauf trainiert, plausibel klingende Texte zu erzeugen. Wenn es eine Antwort nicht kennt, erfindet es im Zweifel eine, die überzeugend wirkt. In einem Kundengespräch oder einer rechtlichen Auskunft ist das fatal. Ohne eine verlässliche Quelle haben Sie keine Möglichkeit zu prüfen, ob die Antwort stimmt. RAG begegnet diesem Problem, indem das Modell seine Antwort auf konkrete, abrufbare Textstellen stützt.

Veraltetes Modellwissen

Jedes Modell hat einen Wissensstichtag. Was nach dem Training passiert ist, kennt es nicht. Ihre neue Preisliste, die aktualisierte Verfahrensanweisung von letzter Woche oder das Protokoll des gestrigen Meetings sind dem Modell schlicht unbekannt. RAG löst dieses Problem elegant: Sie aktualisieren einfach Ihre Wissensbasis, ohne das Modell neu trainieren zu müssen. Die Antwort stützt sich immer auf den aktuellen Stand Ihrer Dokumente.

Begrenztes Kontextfenster

Man könnte einwenden: Moderne Modelle haben doch riesige Kontextfenster. Claude Opus und vergleichbare Modelle verarbeiten inzwischen bis zu einer Million Token oder mehr in einem einzigen Aufruf. Warum also nicht einfach die komplette Wissensbasis in jeden Prompt packen? Das scheitert in der Praxis aus mehreren Gründen. Ein durchschnittliches Unternehmen hat weit mehr Dokumente, als selbst in das größte Kontextfenster passen. Jeder Aufruf mit einem vollen Kontext kostet zudem viel Geld und Zeit. Und es ist bekannt, dass die Antwortqualität sinkt, wenn das Modell relevante Informationen aus einem riesigen Kontext herausfiltern muss. RAG liefert dem Modell stattdessen gezielt nur die wenigen Textstellen, die zur Frage tatsächlich passen.

Hinweis: Große Kontextfenster und RAG schließen sich nicht aus. Im Gegenteil: Ein größeres Kontextfenster erlaubt es, mehr und längere abgerufene Textstellen mitzugeben und so die Antwortqualität zu verbessern. RAG bleibt aber das Verfahren, das überhaupt erst die richtigen Stellen auswählt.

Was ist RAG?

Retrieval Augmented Generation bedeutet sinngemäß „durch Abruf erweiterte Generierung“. Das Prinzip ist im Kern einfach: Bevor das Sprachmodell eine Antwort formuliert, sucht das System in Ihrer Wissensbasis nach den passenden Informationen und reicht diese gemeinsam mit der Frage an das Modell weiter. Das Modell antwortet also nicht aus dem Gedächtnis, sondern auf Basis der bereitgestellten Quellen.

Die Analogie zu einem Menschen ist treffend: Stellen Sie sich einen kompetenten Mitarbeiter vor, der zwar klug und sprachgewandt ist, Ihr Unternehmen aber nicht kennt. Geben Sie ihm vor jeder Antwort die relevanten Aktenordner in die Hand, antwortet er fundiert und mit Quellenangabe. Genau diese Rolle übernimmt der Retrieval-Schritt bei RAG. Das Modell bleibt das gleiche, aber es bekommt zur richtigen Zeit die richtigen Unterlagen vorgelegt.

Der große Vorteil gegenüber anderen Ansätzen liegt in der Trennung von Wissen und Modell. Ihr Firmenwissen bleibt in einer eigenen Datenbank, die Sie jederzeit aktualisieren, korrigieren oder löschen können. Das Modell selbst muss dafür nicht angefasst werden. Diese saubere Trennung ist nicht nur technisch praktisch, sondern auch für den Datenschutz von großer Bedeutung, wie Sie weiter unten sehen werden.

Die RAG-Pipeline Schritt für Schritt

Eine RAG-Anwendung besteht aus zwei Phasen. In der ersten, der Aufbereitungsphase, wird Ihr Firmenwissen einmalig vorbereitet und gespeichert. Diese Phase läuft im Hintergrund, immer wenn neue Dokumente hinzukommen. In der zweiten Phase, der Abfragephase, wird zur Laufzeit jede einzelne Nutzerfrage beantwortet. Schauen wir uns beide Phasen im Detail an.

Schritt 1: Dokumente sammeln und aufbereiten

Am Anfang steht Ihr Firmenwissen in all seinen Formen: PDF-Handbücher, Word-Dokumente, Wiki-Seiten, Confluence-Artikel, E-Mails, Datenbankeinträge oder Webseiten. Diese Quellen müssen eingelesen und in reinen Text umgewandelt werden. Schon hier entscheidet sich viel über die spätere Qualität, denn ein sauber extrahierter Text mit erhaltener Struktur liefert deutlich bessere Ergebnisse als eine wirre Zeichenwüste aus einem schlecht eingescannten PDF.

Schritt 2: Chunking

Lange Dokumente werden in kleinere, handhabbare Abschnitte zerlegt, die sogenannten Chunks. Das ist notwendig, weil das System später gezielt einzelne Textabschnitte abrufen soll und nicht ganze Bücher. Die Kunst dabei ist, semantisch sinnvolle Einheiten zu bilden. Ein guter Chunk beantwortet idealerweise eine Frage für sich allein und reißt keinen Gedanken mitten im Satz auseinander. In der Praxis ist das Chunking die Stelle, an der die meisten RAG-Systeme leise scheitern. Wer hier zu grob oder zu fein schneidet, ruiniert die Retrieval-Qualität, bevor das Modell überhaupt ins Spiel kommt.

Schritt 3: Embeddings erzeugen

Jeder Chunk wird durch ein Embedding-Modell in einen Vektor umgewandelt, also in eine lange Liste von Zahlen. Dieser Vektor ist eine mathematische Repräsentation der Bedeutung des Textes. Texte mit ähnlicher Bedeutung erhalten ähnliche Vektoren, auch wenn sie unterschiedliche Wörter verwenden. So liegen „Wie kündige ich mein Abonnement?“ und „Vertragsbeendigung durch den Kunden“ im Vektorraum nahe beieinander, obwohl sie kaum ein gemeinsames Wort haben. Genau diese Fähigkeit macht die spätere Suche so leistungsfähig.

Schritt 4: Speicherung in der Vektordatenbank

Die erzeugten Vektoren werden zusammen mit dem ursprünglichen Text und Metadaten in einer Vektordatenbank abgelegt. Zu den Metadaten gehören typischerweise das Quelldokument, die Seitenzahl, das Kapitel oder das Datum. Diese Zusatzinformationen sind später Gold wert, denn sie ermöglichen Quellenangaben und das Filtern nach Berechtigungen oder Aktualität. Damit ist die Aufbereitungsphase abgeschlossen, und Ihre Wissensbasis ist durchsuchbar.

Schritt 5: Retrieval bei der Nutzerfrage

Jetzt beginnt die Abfragephase. Stellt ein Nutzer eine Frage, wird diese Frage mit demselben Embedding-Modell ebenfalls in einen Vektor umgewandelt. Die Vektordatenbank sucht anschließend die Chunks, deren Vektoren der Frage am ähnlichsten sind. Üblicherweise werden die besten drei bis zehn Treffer ausgewählt, das sogenannte Top-K-Retrieval. Diese Treffer sind die Textstellen, die mit hoher Wahrscheinlichkeit die Antwort enthalten.

Schritt 6: Prompt-Augmentierung und Antwort

Die gefundenen Textstellen werden nun zusammen mit der ursprünglichen Frage und einer Anweisung in einen Prompt für das Sprachmodell gepackt. Diese Anweisung lautet sinngemäß: „Beantworte die folgende Frage ausschließlich auf Basis der bereitgestellten Quellen und gib an, woher die Information stammt.“ Das Modell formuliert daraufhin eine natürlichsprachliche Antwort, die auf Ihren Dokumenten beruht und idealerweise die Quelle nennt. Dieser letzte Schritt, das Zusammenfügen und Anreichern des Prompts, gibt dem Verfahren seinen Namen: augmented generation.

Praxis-Tipp: Bestehen Sie im System-Prompt explizit darauf, dass das Modell antwortet „Diese Information liegt mir nicht vor“, wenn die abgerufenen Quellen keine Antwort enthalten. Ohne diese Anweisung neigt das Modell dazu, Lücken kreativ zu füllen. Genau dieser eine Satz im Prompt reduziert Halluzinationen in der Praxis erheblich.

Embeddings und Vektordatenbanken verständlich erklärt

Embeddings und Vektordatenbanken sind das Herzstück jeder RAG-Anwendung. Beide Begriffe klingen technisch, das dahinterliegende Konzept lässt sich aber gut greifen. Wenn Sie diese beiden Bausteine verstehen, verstehen Sie auch, warum RAG mehr kann als eine klassische Stichwortsuche.

Was Embeddings leisten

Ein Embedding bildet die Bedeutung eines Textes als Punkt in einem hochdimensionalen Raum ab. Während wir uns nur drei Dimensionen vorstellen können, arbeiten moderne Embedding-Modelle mit Hunderten oder Tausenden Dimensionen. Texte, die inhaltlich verwandt sind, landen in diesem Raum nahe beieinander. Die Suche nach passenden Inhalten wird damit zu einer geometrischen Aufgabe: Man sucht die Punkte, die dem Frage-Punkt am nächsten liegen. Dieser Ansatz erkennt inhaltliche Verwandtschaft auch dann, wenn keine Wörter übereinstimmen, was die klassische Volltextsuche nicht kann.

Die Wahl des Embedding-Modells hat großen Einfluss auf die Qualität. Für deutschsprachige Inhalte ist das besonders relevant, weil nicht jedes Modell mehrsprachige Texte gleich gut versteht. Verbreitete Optionen sind text-embedding-3 von OpenAI als solider Allrounder, Cohere embed-v4 mit starker Mehrsprachigkeit sowie quelloffene Modelle wie BGE-M3 oder die Qwen3-Embedding-Reihe, die sich selbst hosten lassen und bei mehrsprachigen Aufgaben mittlerweile mit kommerziellen APIs mithalten oder sie übertreffen.

Wofür die Vektordatenbank zuständig ist

Eine Vektordatenbank ist darauf spezialisiert, in Millionen von Vektoren blitzschnell die ähnlichsten zu finden. Eine herkömmliche relationale Datenbank ist dafür nicht gebaut. Vektordatenbanken nutzen spezielle Indexstrukturen, um die Ähnlichkeitssuche auch bei riesigen Datenmengen in Millisekunden zu beantworten. Viele moderne Systeme bieten zusätzlich eine sogenannte Hybrid-Suche an, die die semantische Vektorsuche mit einer klassischen Stichwortsuche kombiniert. Das ist wichtig, damit exakte Begriffe wie Artikelnummern, Normen oder Eigennamen nicht übersehen werden, die eine reine Bedeutungssuche manchmal verfehlt.

Vektordatenbanken im Überblick

Der Markt für Vektordatenbanken hat sich konsolidiert. Die folgende Übersicht stellt die wichtigsten Optionen gegenüber. Welche Lösung die richtige ist, hängt vor allem von der Datenmenge, Ihren Datenschutzanforderungen und Ihrer bestehenden Infrastruktur ab.

Lösung	Typ	Stärken	Geeignet für
pgvector	PostgreSQL-Erweiterung	Keine neue Infrastruktur, Vektoren neben relationalen Daten, volle Datenkontrolle	Teams mit bestehender PostgreSQL-Datenbank, bis einige Millionen Vektoren
Chroma	Open Source	Zero-Config, lokal lauffähig, Standard in vielen Tutorials	Prototypen, Proof of Concept, kleinere Datensätze
Qdrant	Open Source	Sehr gutes Preis-Leistungs-Verhältnis, hohe Geschwindigkeit, selbst hostbar	Produktivbetrieb mit Kostenfokus und EU-Hosting
Weaviate	Open Source / Cloud	Hybrid-Suche, integrierte Vektorisierung, enterprise-tauglich	Mittlere bis große Wissensbasen, Enterprise-Umfeld
Pinecone	Managed SaaS	Maximale Betriebseinfachheit, serverlos, skaliert sehr weit	Große Datenmengen ohne eigenen Betriebsaufwand

Eine grobe Faustregel zur Orientierung: Unter einer Million Vektoren reichen Chroma oder pgvector völlig aus. Im Bereich von einer bis fünfzig Millionen Vektoren spielen Qdrant, Weaviate und Pinecone ihre Stärken aus. Bei sehr großen Datenmengen jenseits dieser Marke sind managed Lösungen wie Pinecone oft die pragmatischste Wahl. Wenn Datenschutz oberste Priorität hat, sind selbst gehostete Optionen wie Qdrant, Weaviate oder pgvector im EU-Rechenzentrum die naheliegende Wahl.

RAG oder Fine-Tuning: Was ist der Unterschied?

Wenn es darum geht, ein Modell an die eigenen Bedürfnisse anzupassen, fällt neben RAG häufig der Begriff Fine-Tuning. Beide Ansätze werden oft als Alternativen dargestellt, lösen aber unterschiedliche Probleme. Eine prägnante Formel hat sich durchgesetzt: RAG löst ein Wissensproblem, Fine-Tuning löst ein Verhaltensproblem.

Beim Fine-Tuning wird das Modell mit eigenen Beispieldaten nachtrainiert. Das verändert das Verhalten des Modells dauerhaft, etwa den Schreibstil, das Antwortformat oder das Beherrschen einer Fachsprache. Neues, sich ständig änderndes Faktenwissen lässt sich damit jedoch schlecht abbilden, weil jede Aktualisierung ein erneutes Training erfordert. Bei RAG bleibt das Modell unverändert, und das Wissen liegt extern in der Vektordatenbank. Aktualisierungen sind so trivial, und jede Antwort lässt sich mit einer Quelle belegen.

Kriterium	RAG	Fine-Tuning
Löst primär	Wissensproblem	Verhaltensproblem
Aktualität des Wissens	Jederzeit aktualisierbar	Stand des Trainings
Quellenangaben	Möglich und üblich	Nicht möglich
Datenschutz	Daten bleiben getrennt und löschbar	Daten fließen ins Modell ein
Time-to-Deploy	Schnell	Langsamer, Trainingsaufwand
Stärke bei	Großem, dynamischem Wissen	Stil, Format, Fachsprache

In der Praxis ist die Entscheidung selten ein Entweder-oder. Für die meisten unternehmensinternen Wissensanwendungen ist RAG der schnellere und wirtschaftlichere Einstieg mit der besseren Nachvollziehbarkeit. Anspruchsvolle Setups kombinieren beides: Ein kleineres Modell wird auf das gewünschte Verhalten und die Fachsprache feinjustiert und anschließend mit einer RAG-Pipeline für das aktuelle Wissen verbunden. Wenn Sie tiefer in die Anbindung von Sprachmodellen einsteigen möchten, finden Sie weitere Hintergründe in meinem Beitrag zur KI-API-Integration.

Anwendungsfälle im Unternehmen

RAG ist keine Spielerei, sondern löst konkrete Probleme im Arbeitsalltag. Überall dort, wo Mitarbeiter oder Kunden in einem Wust von Dokumenten nach Antworten suchen, kann eine gut gebaute RAG-Anwendung enorm Zeit sparen. Die folgenden Szenarien sehe ich in der Praxis am häufigsten.

Interner Wissensassistent: Mitarbeiter fragen in natürlicher Sprache nach Prozessen, Richtlinien oder technischer Dokumentation und erhalten Antworten samt Verweis auf das Originaldokument.
Kundensupport: Ein Chatbot beantwortet Kundenanfragen auf Basis Ihrer FAQ, Handbücher und Support-Historie, statt generische Floskeln zu liefern.
Dokumentensuche und Recherche: Juristen, Berater oder technische Fachkräfte durchsuchen umfangreiche Bestände nach relevanten Passagen, ohne jedes Dokument einzeln zu öffnen.
Onboarding neuer Mitarbeiter: Neue Kollegen finden Antworten auf typische Einstiegsfragen selbstständig, ohne erfahrene Kollegen ständig zu unterbrechen.
Vertriebsunterstützung: Das Vertriebsteam erhält auf Knopfdruck passende Produktinformationen, Referenzen und Antworten auf Ausschreibungsfragen.

Diese Anwendungsfälle reihen sich in den größeren Trend ein, generative KI sinnvoll in Geschäftsprozesse zu integrieren. Wie Unternehmen das strategisch angehen, beschreibe ich ausführlicher im Beitrag über generative KI im Unternehmen. RAG ist dabei in den meisten Fällen die technische Grundlage für einen persönlichen KI-Assistenten im Unternehmen, wo ich die verschiedenen Umsetzungswege von der SaaS-Lösung bis zur Eigenentwicklung gegenüberstelle.

Qualität und typische Stolperfallen

Eine RAG-Anwendung ist schnell als Prototyp gebaut. Der Sprung zu einem System, dem Anwender wirklich vertrauen, ist deutlich größer. Branchenanalysen zeigen, dass beim Versagen einer RAG-Anwendung der Fehler überwiegend im Retrieval liegt, nicht in der Generierung. Mit anderen Worten: Wenn das System die falschen Textstellen findet, kann auch das beste Sprachmodell keine gute Antwort liefern. Auf diese Punkte sollten Sie besonders achten.

Die Chunking-Strategie entscheidet

Zu große Chunks verwässern die Bedeutung und liefern dem Modell viel irrelevanten Ballast. Zu kleine Chunks reißen den Zusammenhang auseinander, sodass eine Antwort über mehrere Fragmente verstreut ist. Bewährt hat sich ein semantisches Chunking, das an natürlichen Grenzen wie Absätzen oder Überschriften schneidet, kombiniert mit einer leichten Überlappung benachbarter Chunks. So geht kein Kontext an den Schnittstellen verloren.

Retrieval-Qualität messen und verbessern

Verlassen Sie sich nicht auf ein gutes Gefühl. Bauen Sie einen Testdatensatz aus typischen Fragen mit bekannten richtigen Antworten und messen Sie, ob das Retrieval die passenden Stellen findet. Eine reine Vektorsuche lässt sich oft durch eine Hybrid-Suche und durch ein nachgelagertes Re-Ranking verbessern, bei dem die ersten Treffer noch einmal feiner sortiert werden. Erst diese Messbarkeit macht aus einem Bauchgefühl ein verlässliches System.

Quellenangaben sind Pflicht

Eine Antwort ohne Quelle ist im Unternehmenskontext nur die halbe Miete. Sorgen Sie dafür, dass jede Antwort die verwendeten Dokumente, Seiten oder Abschnitte benennt. Das schafft Vertrauen, ermöglicht eine schnelle Überprüfung und deckt Fehler im System frühzeitig auf. Die dafür nötigen Metadaten sollten Sie bereits beim Befüllen der Datenbank konsequent mitspeichern, denn nachträglich lässt sich das nur schwer ergänzen.

Hinweis: Eine viel zitierte Gartner-Prognose geht davon aus, dass ein Großteil der unternehmensinternen RAG-Projekte an mangelnder Datenqualität scheitert. Die wichtigste Lehre daraus: Investieren Sie Zeit in saubere, gut strukturierte und aktuelle Quelldaten, bevor Sie an Modellen und Datenbanken feilen.

Datenschutz und DSGVO bei Firmenwissen

Sobald Sie Firmenwissen in eine KI-Anwendung geben, betreten Sie datenschutzrechtlich sensibles Terrain. Häufig enthalten interne Dokumente personenbezogene Daten, etwa Namen in E-Mails, Kundendaten in Support-Tickets oder Mitarbeiterinformationen in Prozessbeschreibungen. Die gute Nachricht ist, dass die Architektur von RAG dem Datenschutz entgegenkommt.

Weil das Wissen getrennt vom Modell in Ihrer eigenen Datenbank liegt, behalten Sie die volle Kontrolle über die Daten. Sie können Einträge jederzeit korrigieren oder löschen. Damit lassen sich zentrale DSGVO-Vorgaben wie Auskunft, Berichtigung und Löschung umsetzen, was bei einem fest in das Modell eintrainierten Wissen kaum möglich wäre. Die Datenschutzkonferenz hat sich dieses Themas inzwischen angenommen und sieht RAG-Architekturen als grundsätzlich geeigneten Baustein für datenschutzkonforme KI.

Wichtig ist allerdings: RAG ist nicht automatisch DSGVO-konform. Sie benötigen weiterhin eine Rechtsgrundlage, gegebenenfalls eine Datenschutzfolgenabschätzung und angemessene technische Schutzmaßnahmen. Besonders kritisch ist die Frage, wohin die abgerufenen Textstellen für die Antwortgenerierung übertragen werden. Wenn Sie ein Sprachmodell über eine API in einem Drittland nutzen, verlassen Ihre Daten unter Umständen den EU-Raum. Am sichersten sind ein in der EU gehostetes oder ein lokal betriebenes Sprachmodell sowie eine Vektordatenbank im EU-Rechenzentrum. Lokal lauffähige Modelle, etwa über Werkzeuge wie Ollama, ermöglichen einen vollständig internen Betrieb, bei dem keine Daten das Haus verlassen.

Praxis-Tipp: Ergänzen Sie Ihre Pipeline um eine Berechtigungsprüfung. Nicht jeder Mitarbeiter darf jedes Dokument sehen. Indem Sie Zugriffsrechte in den Metadaten hinterlegen und beim Retrieval danach filtern, stellen Sie sicher, dass die KI nur Quellen heranzieht, die der jeweilige Nutzer auch tatsächlich einsehen darf.

Meine Praxis-Empfehlung für den Einstieg

Wenn Sie über eine RAG-Anwendung nachdenken, rate ich zu einem pragmatischen, schrittweisen Vorgehen. Starten Sie nicht mit der maximalen Lösung, sondern mit einem klar umrissenen Anwendungsfall, der echten Nutzen stiftet und sich gut messen lässt.

Klein anfangen: Wählen Sie einen abgegrenzten Wissensbereich mit überschaubarer Dokumentenzahl und einem konkreten Nutzerkreis.
Datenqualität zuerst: Sorgen Sie für saubere, aktuelle und gut strukturierte Quelldokumente, bevor Sie an der Technik feilen.
Bestehende Infrastruktur nutzen: Wer schon PostgreSQL betreibt, kann mit pgvector ohne neue Systeme starten und später migrieren.
Quellen und Messbarkeit einbauen: Quellenangaben und ein Testdatensatz gehören von Anfang an dazu, nicht erst nachträglich.
Datenschutz früh klären: Entscheiden Sie zu Beginn, wo Modell und Daten gehostet werden, statt es am Ende nachzurüsten.

Fazit

RAG ist der derzeit pragmatischste Weg, ein Sprachmodell mit Ihrem eigenen Firmenwissen zu verbinden. Die Architektur löst gleich drei zentrale Schwächen reiner Sprachmodelle: Sie reduziert Halluzinationen durch belegbare Quellen, hält das Wissen jederzeit aktuell und umgeht die Grenzen des Kontextfensters durch gezielten Abruf. Der entscheidende Vorteil gegenüber dem Fine-Tuning liegt in der sauberen Trennung von Wissen und Modell, die nicht nur die Pflege erleichtert, sondern auch dem Datenschutz entgegenkommt.

Der Erfolg einer RAG-Anwendung entscheidet sich weniger an der Wahl des Sprachmodells als an den unscheinbaren Details: einer durchdachten Chunking-Strategie, sauberen Quelldaten, einem belastbaren Retrieval und konsequenten Quellenangaben. Wer hier sorgfältig arbeitet und klein anfängt, baut ein System, dem die Anwender tatsächlich vertrauen. Genau das ist der Unterschied zwischen einer netten Demo und einem Werkzeug, das im Arbeitsalltag wirklich hilft.

Firmenwissen für KI nutzbar machen?

Sie möchten Ihr Firmenwissen über eine RAG-Anwendung für KI nutzbar machen? Ich unterstütze Sie von der Konzeption über die Wahl der passenden Tools bis zur datenschutzkonformen Umsetzung. Kontaktieren Sie mich für ein unverbindliches Gespräch.