Ein RAG KI-Agent, der produktionsreif ist – kein Wochenend-Prototyp

Retrieval-Augmented Generation löste eines der fundamentalen Probleme großer Sprachmodelle: Sie halluzinieren. Fragen Sie ein LLM nach der Rückgaberichtlinie Ihres Unternehmens, und ohne Abruf generiert es eine plausibel klingende Antwort, die auf den Mustern basiert, die es während des Vortrainings gelernt hat – eine Antwort, die für Ihr spezifisches Geschäft völlig falsch sein kann. RAG behebt dies, indem es einen Abrufschritt zwischen Frage und Generierung einfügt: Bevor das LLM eine Antwort erzeugt, durchsucht das System einen Korpus Ihrer tatsächlichen Inhalte, zieht die relevantesten Passagen heraus und speist diese als Kontext in das Modell ein. Das LLM generiert seine Antwort gestützt auf diese Passagen und nicht auf sein parametrisches Gedächtnis. Das Ergebnis ist eine Antwort, die genau, spezifisch und auf eine Quelle zurückführbar ist. Das ist die Theorie. In der Praxis scheitern die meisten Teams daran, RAG in die Produktion zu bringen.

Die Architektur eines RAG-Systems sieht auf einem Whiteboard täuschend einfach aus. Die Abfrage kommt herein, Embeddings wandeln sie in einen Vektor um, die Vektorsuche findet die nächsten Chunks in einer Datenbank, diese Chunks gelangen in den LLM-Prompt, und das LLM generiert eine fundierte Antwort. Fünf Kästen, vier Pfeile, eine Skizze an einem Nachmittag. Aber jeder Kasten verbirgt eine Reihe von technischen Entscheidungen, die sich zu Wochen oder Monaten Arbeit summieren. Welches Embedding-Modell? OpenAIs ada-002, Cohere's embed-v3, ein Open-Source-Modell, das Sie selbst hosten? Wo speichern Sie die Vektoren? Pinecone für verwaltetes Hosting, Weaviate für Open Source, pgvector, wenn Sie bei Postgres bleiben möchten, Qdrant, wenn Sie Leistung im großen Maßstab wünschen? Wie chunken Sie die Inhalte? Feste Token-Fenster, rekursive Zeichenaufteilung, semantische Segmentierung basierend auf Überschriften, gleitende Fenster mit Überlappung? Wie viel Überlappung? Wie groß ist der Chunk? Jede Wahl interagiert mit jeder anderen Wahl, und die „richtige“ Antwort hängt von Ihren spezifischen Inhalten, Ihren Abfragemustern und Ihren Genauigkeitsanforderungen ab.

Asyntai existiert, weil die meisten Unternehmen, die RAG benötigen, diese Entscheidungen nicht treffen müssen. Sie benötigen das Ergebnis – einen KI-Agenten, der Fragen präzise anhand ihrer Inhalte beantwortet – ohne das Infrastrukturprojekt. Asyntai ist ein vollständig verwaltetes RAG-System. Es crawlt Ihre Website, verarbeitet hochgeladene Dokumente, chunkt Inhalte in semantisch kohärente Passagen, indiziert diese für den Abruf und ruft zur Abfragezeit die relevantesten Passagen ab, um die Antwort des LLM zu untermauern. Sie stellen keine Vektordatenbank bereit. Sie wählen kein Embedding-Modell. Sie schreiben keinen Chunking-Algorithmus. Sie fügen ein Skript-Tag auf Ihrer Website ein, und die Abruf-Pipeline läuft auf einer Infrastruktur, die Sie nie anfassen müssen.

Die Crawling-Schicht ist der Einstiegspunkt in die Pipeline. Wenn Sie eine Domain verbinden, folgt der Crawler von Asyntai den Links auf Ihrer Website, extrahiert Textinhalte von jeder Seite und speist diese in das Chunking-System ein. Er verarbeitet JavaScript-gerenderte Seiten, respektiert robots.txt und crawlt nach einem von Ihnen festgelegten Zeitplan erneut, damit Ihr Abrufindex aktuell bleibt, wenn sich Ihre Inhalte ändern. Sie können auch Dokumente direkt hochladen – PDFs, Word-Dokumente, Wissensdatenbank-Exporte – für Inhalte, die hinter einer Authentifizierung liegen oder nicht auf einer Website veröffentlicht sind. Der Crawler ist bewusst meinungsstark: Er extrahiert Text und Struktur, verwirft Navigations-Chrome und Boilerplate und erzeugt saubere Passagen, die für das Chunking bereit sind. Sie konfigurieren das Verhalten des Crawlers nicht, weil die Entscheidungen, die er trifft – was extrahiert wird, wie mit dynamischen Inhalten umgegangen wird, wann neu indexiert wird – für praktisch jeden Kunden gleich sind.

Das Chunking ist der Bereich, in dem benutzerdefinierte RAG-Implementierungen unverhältnismäßig viel Zeit verbringen und wo subtile Fehler die meisten Abruffehler verursachen. Der naive Ansatz – Text alle 500 Tokens aufteilen – erzeugt Chunks, die mitten im Absatz, mitten im Satz oder schlimmer noch, mitten im Konzept abbrechen. Eine Passage über Ihre Rückgaberichtlinie könnte in zwei Chunks aufgeteilt werden, wobei die Bedingungen in einem Chunk und der Zeitrahmen im anderen enthalten sind. Wenn ein Kunde fragt: „Wie lange habe ich Zeit, etwas zurückzusenden?“, zieht der Abrufschritt möglicherweise den Chunk mit den Bedingungen, verpasst aber den mit dem Zeitrahmen, und das LLM generiert eine unvollständige Antwort. Asyntai respektiert beim Chunking die Dokumentenstruktur: Überschriften, Absatzgrenzen, Listenelemente und logische Themenübergänge. Jeder Chunk ist eine in sich geschlossene Passage, die für sich allein Sinn ergibt – kein willkürlicher Textausschnitt. Das ist wichtiger, als die meisten Leute annehmen, wenn sie die RAG-Qualität bewerten, denn der Abruf kann nur so gut sein wie das, was abgerufen wird.

Der Abrufschritt selbst ist der Punkt, an dem das RAG-Akronym seinen Namen verdient. Wenn ein Besucher eine Frage stellt, wandelt das System diese in eine Vektordarstellung um und durchsucht den Index nach den semantisch ähnlichsten Passagen. Semantische Suche ist der entscheidende Unterschied zur Schlüsselwortsuche: Eine Frage wie „Was ist die Frist für die Rücksendung von Artikeln?“ ruft Passagen über „Rückgaberichtlinie“ und „30-tägiges Rückgabefenster“ ab, auch wenn keiner der exakten Wörter der Abfrage im Inhalt vorkommt. Dies berücksichtigt die Realität, wie Menschen Fragen stellen – sie verwenden nicht unbedingt die gleiche Terminologie wie Ihre Dokumentation. Die Abruf-Pipeline von Asyntai bewertet Kandidaten nach Relevanz und speist die Top-Passagen als Kontext für die Generierung in das LLM ein. Das Modell sieht nur diese Passagen, nicht den gesamten Index, was das Kontextfenster fokussiert hält und die Wahrscheinlichkeit verringert, dass das Modell eine tangential verwandte Passage auswählt, um eine falsche Antwort zu stützen.

Die Verankerung der Generierung (Grounding) ist der Mechanismus, der Halluzinationen verhindert. Das LLM wird angewiesen, Antworten basierend auf den abgerufenen Passagen zu geben und explizit anzuerkennen, wenn der abgerufene Inhalt keine Antwort enthält. Dies ist eine architektonische Einschränkung, kein Prompt-Trick – das System ist so konzipiert, dass das Modell auf abgerufenen Kontext arbeitet und sich nicht auf sein vortrainiertes Wissen über Ihr Unternehmen verlässt (das fast immer nicht vorhanden oder veraltet ist). Wenn ein Kunde nach einem Produkt fragt, das nicht in Ihrer Wissensbasis enthalten ist, teilt der Agent mit: „Ich habe keine Informationen zu diesem Produkt in meiner Wissensbasis“, anstatt Spezifikationen zu erfinden. Wenn jemand eine Frage stellt, deren Antwort sich über mehrere Themen erstreckt, synthetisiert der Agent über abgerufene Passagen hinweg, füllt aber keine Lücken mit generiertem Material. Dieses Verhalten macht RAG für den Einsatz beim Kunden vertrauenswürdig – die Grenze zwischen „Ich weiß das, weil es im Inhalt steht“ und „Ich rate“ wird vom System erzwungen und nicht dem Urteilsvermögen des Modells überlassen.

Aber hier trennt sich Asyntai von einer Lehrbuch-RAG-Implementierung: Das System stoppt nicht bei Abruf und Generierung. Die meisten realen Kundeninteraktionen erfordern Informationen, die in keinem Dokument stehen. Bestellstatus, Kontostände, Lagerbestände, Verfügbarkeit von Terminen, Abonnementdetails – diese Daten ändern sich minütlich und existieren in Ihren Geschäftssystemen, nicht in Ihrer Wissensbasis. Ein reiner RAG-Agent kann einem Kunden sagen, wie Ihre Rückgaberichtlinie lautet, aber er kann ihm nicht sagen, ob seine spezifische Bestellung berechtigt ist. Er kann Ihre Preisstufen erklären, aber er kann ihm nicht sagen, auf welchem Plan er sich befindet oder wie viele Nachrichten er diesen Monat verbraucht hat. Für diese Fragen muss der Agent Ihre APIs aufrufen – und genau das bieten benutzerdefinierte Tools.

Benutzerdefinierte Tools erweitern den RAG-Agenten um die Fähigkeit zum Tool-Aufruf. Sie definieren ein Tool in Ihrem Dashboard: einen Namen, eine Beschreibung, wann die KI es verwenden soll, Ihren API-Endpunkt und die Parameter, die die KI aus der Konversation extrahieren soll. Wenn die Frage eines Kunden Live-Daten erfordert, ruft der Agent Ihren Endpunkt auf, erhält die Antwort und kombiniert diese mit den abgerufenen Inhalten der Wissensbasis, um eine vollständige Antwort zu formulieren. Das Beispiel der Rückgabeberechtigung ist der kanonische Fall: Der Agent ruft Ihre Rückgaberichtlinie aus der Wissensbasis ab (RAG) und ruft Ihre Bestell-API (benutzerdefiniertes Tool) auf, um das Bestelldatum und die Artikeldetails abzurufen, und synthetisiert dann beides zu einer spezifischen Antwort – „Ihre Bestellung wurde vor 12 Tagen aufgegeben, und Ihr 30-tägiges Rückgabefenster ist noch offen.“ Weder RAG allein noch Tool-Aufrufe allein könnten diese Antwort liefern. Die Kombination macht den Agenten wirklich nützlich.

Diese RAG-plus-Tools-Architektur ist bedeutsam, weil sie die häufigste Kritik an RAG-Systemen adressiert: „Es kann allgemeine Fragen beantworten, aber es kann mir bei meiner spezifischen Situation nicht helfen.“ Diese Kritik ist für RAG-only-Implementierungen berechtigt. Eine Wissensbasis kann Ihnen sagen, wie die Rückerstattungsrichtlinie eines Unternehmens lautet, aber sie kann Ihnen nicht sagen, ob Sie dafür in Frage kommen. Benutzerdefinierte Tools schließen diese Lücke, indem sie den Agenten mit Live-Datenquellen verbinden. Die RAG-Schicht behandelt die Fragen „Was sind die Regeln?“. Die Tool-Schicht behandelt die Fragen „Wie ist meine Situation?“. Der Agent kümmert sich um die Synthese. Für den Kunden sieht alles wie eine einzige Konversation mit einem einzigen Agenten aus, der Ihre Richtlinien und Ihre Daten kennt.

Benutzerkontext fügt eine dritte Datenschicht hinzu, die einen verwalteten RAG-Agenten weiter von einer Eigenentwicklung unterscheidet. Über eine JavaScript-API übergeben Sie dem Widget bekannte Informationen über den angemeldeten Besucher – seinen Namen, seine E-Mail-Adresse, sein Kundensegment, seine Plan-Stufe, kürzliche Käufe –, bevor die Konversation beginnt. Der Agent nutzt diesen Kontext, um Antworten zu personalisieren und das Hin und Her des „Könnte ich bitte Ihre Bestellnummer haben?“ zu überspringen. Ein angemeldeter Kunde, der fragt: „Wann wird mein Plan verlängert?“, erhält sofort eine Antwort, da der Agent bereits seine Identität kennt und die richtige API aufrufen kann. Ohne Benutzerkontext müsste der Agent nach identifizierenden Informationen fragen, diese verifizieren und dann den Tool-Aufruf tätigen – was jede Interaktion verlangsamt. Mit dem Kontext fühlt sich der RAG-Agent an, als würde er den Kunden bereits kennen.

Die mehrsprachige Dimension von RAG ist ein weiterer Bereich, in dem ein verwaltetes System eine benutzerdefinierte Lösung erheblich übertrifft. Die Abruf-Pipeline von Asyntai unterstützt sprachübergreifendes Abgleich-Matching – eine auf Deutsch gestellte Frage ruft relevante Passagen aus einer englischen Wissensbasis ab, da die semantische Darstellung Bedeutung unabhängig von der Sprache erfasst. Die Generierungsschicht setzt dann die Antwort in der Sprache des Besuchers zusammen. Sie pflegen eine einzige Wissensbasis in Ihrer Hauptsprache, und der RAG-Agent bedient Besucher in 36 unterstützten Sprachen. Dies in einer benutzerdefinierten Pipeline zu implementieren, würde bedeuten, parallele Wissensbasen in jeder Sprache zu pflegen (teuer, fehleranfällig, immer nicht synchron) oder eine Übersetzungsschicht in die Abruf-Pipeline zu integrieren (komplex, latenzabhängig und ein weiterer Fehlerpunkt). Der verwaltete Ansatz kümmert sich einfach darum.

Intelligente Eskalation ist das Sicherheitsnetz, das einen RAG-Agenten für den Produktionseinsatz im Kundensupport geeignet macht. Kein Abrufsystem hat eine perfekte Abdeckung, und kein Satz von Tools deckt jedes Szenario ab. Wenn der Agent auf eine Frage stößt, die außerhalb seiner Wissensbasis und seiner Tools liegt – oder wenn er auf eine von Ihnen definierte Grenze stößt, wie „Genehmigen Sie niemals Rückerstattungen über 200 € ohne menschliche Überprüfung“ –, erfasst er die Kundeninformationen, den gesamten Konversationsverlauf und alle Daten, die er abgerufen hat, und leitet alles an Ihr Team weiter. Die Eskalation umfasst die abgerufenen Passagen und die Ergebnisse der Tool-Aufrufe, sodass Ihr menschlicher Agent genau sieht, was die KI gefunden hat und wo sie aufgehört hat. Dadurch bearbeitet Ihr Team nur die Fälle, die wirklich menschliches Urteilsvermögen erfordern, und zwar mit vollständigem Kontext, anstatt jede eskalierte Konversation bei Null zu beginnen.

Der durch einen verwalteten RAG-Agenten eingesparte Entwicklungsaufwand summiert sich im Laufe der Zeit. Eine benutzerdefinierte Pipeline erfordert laufende Wartung: Aktualisierungen des Embedding-Modells, wenn der Anbieter eine neue Version veröffentlicht, Skalierung der Vektordatenbank, wenn Ihre Inhalte wachsen, Anpassungen des Chunkings, wenn Sie Ihre Website neu strukturieren, Überwachung der Verschlechterung der Abrufqualität, Prompt-Engineering, wenn sich das Verhalten des LLM ändert. Jede dieser Aufgaben ist einzeln ein kleines Projekt, aber sie summieren sich zu einer erheblichen betrieblichen Belastung. Ein verwalteter RAG-Agent übernimmt all dies. Das Crawling, Chunking, Embedding, Indizieren, Abrufen, Generieren und Bereitstellen der Infrastruktur wird von der Plattform gewartet. Sie pflegen Ihre Inhalte – die Worte auf Ihrer Website und die Dokumente in Ihrer Wissensbasis. Die RAG-Pipeline wandelt diese Inhalte ohne laufende Entwicklungsarbeit Ihres Teams in einen Agenten um.

Die Frage, wann man eine RAG-Implementierung selbst entwickeln und wann man sie zukaufen sollte, hängt von der Differenzierung ab. Wenn Ihre RAG-Pipeline Ihr Produkt ist – wenn Sie eine Suchmaschine, ein Recherchetool oder eine Plattform bauen, bei der die Abrufqualität der zentrale Wettbewerbsvorteil ist –, dann benötigen Sie benutzerdefinierte Embeddings, benutzerdefiniertes Re-Ranking, benutzerdefiniertes Chunking und die volle Kontrolle über jede Ebene. Wenn RAG ein Mittel zum Zweck ist – Sie benötigen einen KI-Agenten, der Fragen präzise anhand Ihrer Inhalte beantwortet, und Sie möchten ihn diese Woche einsetzen –, dann ist ein verwalteter RAG-Agent die pragmatische Wahl. Sie überspringen das Infrastrukturprojekt, überspringen die Evaluierung von Embedding-Modellen, überspringen die Bereitstellung von Vektordatenbanken, überspringen die Chunking-Experimente und erhalten einen produktionsreifen RAG-Agenten mit integriertem Tool-Aufruf, Personalisierung, mehrsprachiger Unterstützung und Eskalation.

Die Lücke zwischen einem funktionierenden RAG-Prototyp und einem produktiven RAG-Deployment ist der Punkt, an dem die meisten Teams an Dynamik verlieren. Der Prototyp funktioniert in einem Notebook: Sie betten einige Dokumente ein, fragen eine lokale Vektordatenbank ab, erhalten vernünftige Antworten. Dann schlägt die Realität zu. Wie halten Sie den Index aktuell, wenn sich Inhalte ändern? Wie gehen Sie mit Dokumenten um, die zu groß für einen einzelnen Chunk sind? Was ist mit Tabellen, Bildern mit Text, PDFs mit komplexen Layouts? Wie bedienen Sie die Abruf-Pipeline bei gleichzeitigen Benutzern mit geringer Latenz? Wie gehen Sie mit Inhalten in mehreren Sprachen um? Was ist mit Anfragen, die Daten erfordern, die sich nicht in Dokumenten befinden? Jede Frage löst ein Unterprojekt aus, und der RAG-Agent, der in zwei Wochen hätte bereitgestellt werden sollen, ist nun eine vierteljährliche Initiative. Asyntai verkürzt diesen Zeitrahmen, da jedes dieser Unterprojekte auf Infrastrukturebene gelöst ist. Sie stoßen nicht auf die Fragen, weil die Antworten in die Plattform integriert sind.

Produktions-RAG besteht nicht nur aus Abruf und Generierung – es ist Abruf, Generierung, Tool-Aufruf, Personalisierung, Eskalation, mehrsprachige Unterstützung, Analysen und eine Chat-Oberfläche, die alle zusammen in einem System arbeiten, das echte Kundenkonversationen im großen Maßstab verarbeitet. Das ist der Stack, den Asyntai bereitstellt. Ihre Inhalte gehen hinein. Fundierte, genaue, umsetzbare Antworten kommen heraus. Die Retrieval-Augmented Generation Pipeline läuft im Hintergrund, unsichtbar für Sie und Ihre Besucher, und erledigt das, was RAG schon immer tun sollte: einen KI-Agenten erschaffen, der die Wahrheit sagt.