Zum Inhalt springen
Souveränes agentisches RAG — On-Premise-Dokumenten-Reasoning von Lexiane

Agentisches RAG | Souveränes Dokumenten-Reasoning | Lexiane

On-Premise agentisches RAG mit iterativer Reasoning-Schleife. Komplexe Korpusanalyse, Multi-Source-Abgleich, SHA-256-Prüfpfad, integrierte menschliche Kontrolle.

Ein klassisches RAG antwortet. Ein agentisches RAG denkt nach, bevor es antwortet — und erkennt, wann es vor einer Antwort weiter suchen muss.

Diese scheinbar einfache Unterscheidung verändert grundlegend, was ein Dokumentensystem leisten kann. Sie verschiebt die Grenze zwischen den Fragen, auf die eine KI zuverlässig antworten kann, und denen, die ihr strukturell entgehen. Und sie wirft Architekturfragen auf — über Kontrolle, Rückverfolgbarkeit, Zertifizierung —, die die meisten agentischen Implementierungen nicht ernsthaft behandeln.

Lexiane integriert eine agentische Schicht, die für den Produktionseinsatz konzipiert wurde: funktional, beherrschbar und architektonisch vom zertifizierten Kern getrennt.


Die strukturelle Grenze des klassischen RAG

Eine lineare RAG-Pipeline arbeitet in einem Durchlauf: Die Benutzeranfrage wird vektorisiert, die ähnlichsten Passagen werden abgerufen, und das LLM generiert eine Antwort aus diesem Kontext. Für die Mehrheit direkter Dokumentenanfragen ist dieses Modell effizient und ausreichend.

Aber es beruht auf einer impliziten Annahme, die selten formuliert wird: dass der erste Abruf ausreichend ist, um eine zuverlässige Antwort zu produzieren.

Diese Annahme gilt für einfache, gut gestellte Fragen. Sie versagt in drei häufigen Situationen.

Die Frage ist breiter als das, was der anfängliche Abruf abdecken kann. “Fasse die Entscheidungen des Projekts X zwischen Januar und März zusammen” ruft Dutzende von Passagen auf, die in Protokollen, exportierten E-Mails und Besprechungsnotizen verstreut sind. Ein Abruf durch semantische Ähnlichkeit gibt die Passagen zurück, die der Frageformulierung am nächsten sind — nicht unbedingt die über den gesamten Zeitraum relevantesten.

Die Frage ist mehrdeutig oder unscharf. Der Benutzer weiß, was er sucht, verfügt aber nicht über das genaue technische Vokabular, das der Vektorsuche ermöglichen würde, die richtigen Passagen zu treffen. Der erste Abruf gibt teilweise relevante Ergebnisse zurück, aber nicht diejenigen, die die eigentliche Frage wirklich beantworten würden.

Die Antwort erfordert die Kreuzreferenzierung mehrerer Quellen. Die relevanten Informationen sind im Korpus vorhanden, aber auf Dutzende von Dokumenten verteilt, die sich semantisch nicht ähneln. Kein einstufiger Abruf kann sie aggregieren.

In diesen drei Fällen produziert das klassische RAG eine Antwort — aber eine Antwort, die auf einem unzureichenden Kontext basiert. Ohne Qualitätsbewertungsmechanismus des Abrufs weiß das System nicht, dass es schlecht antwortet. Es antwortet mit demselben scheinbaren Vertrauen, ob es zehn perfekt relevante Passagen oder drei vage verwandte abgerufen hat.

Das agentische RAG löst dieses Problem, indem es eine Reasoning-Schleife zwischen Abruf und Generierung einführt.


Was ein RAG-Agent wirklich ist — und was er nicht ist

Vor der Detaillierung der Architektur ist eine Klarstellung angebracht. Der Begriff “agentisch” wird im KI-Sektor sehr weit verwendet, oft um Systeme zu beschreiben, die in Wirklichkeit Workflows mit vordefinierten Schritten sind — eine Reihe hartcodierter Operationen, die sequenziell ausgeführt werden, ohne wirkliche Entscheidung bei jedem Schritt.

Ein echtes agentisches System zeichnet sich durch eine grundlegende Eigenschaft aus: Es trifft bei jeder Iteration kontextbezogene Entscheidungen, basierend auf einer Bewertung des aktuellen Zustands — und diese Entscheidungen können je nach abgerufenem Inhalt divergieren, nicht nur je nach der Workflow-Struktur.

Es ist kein Chatbot. Ein Chatbot pflegt eine Konversationshistorie und generiert kontextualisierte Antworten — aber er sucht nicht, bewertet nicht und entscheidet nicht, seine Suche umzuformulieren.

Es ist keine erweiterte Suchmaschine. Eine Suchmaschine gibt Ergebnisse nach einem Ranking-Algorithmus zurück. Sie generiert keine Antwort, bewertet nicht, ob die Ergebnisse ausreichend sind, und trifft keine Entscheidung über das weitere Vorgehen.

Es ist kein Workflow mit festen Schritten. Ein vordefinierter Workflow führt immer dieselben Operationen in derselben Reihenfolge aus. Ein Agent kann je nach dem, was er findet, unterschiedliche Pfade gehen — zweimal umformulieren, wenn der erste Abruf unzureichend ist, ein externes Tool aufrufen, wenn der Dokumentkontext unvollständig ist, sich enthalten, wenn kein Pfad einen zuverlässigen Kontext produziert.

Das agentische RAG von Lexiane ist ein Orchestrator von RAG-Pipelines in einer Reasoning-Schleife. Bei jeder Iteration führt er eine vollständige Pipeline aus, bewertet das Ergebnis und trifft eine Entscheidung über das weitere Vorgehen — nach konfigurierbaren Regeln und deterministischen Wächtern.


Die Reasoning-Schleife: Anatomie einer Iteration

Schritt 1 — Transformation und Abruf

Jede Iteration beginnt mit einer Abrufphase. Die aktuelle Anfrage — die die umformulierte ursprüngliche Frage, eine zerlegte Teilfrage oder eine durch den Kontext vorheriger Iterationen angereicherte Frage sein kann — durchläuft die vollständige Abruf-Pipeline.

Der Abruf ist keine einfache Vektorsuche. Lexiane implementiert den Stand der Technik des Produktionsabrufs:

Anfragetransformation. Vor jeder Suche kann der QueryTransformer je nach Konfiguration mehrere Strategien anwenden:

  • Anfrageerweiterung — Anreicherung der Frage mit Synonymen, verwandten Begriffen und Umformulierungen, um Passagen abzudecken, die nicht dieselben Wörter wie die Frage verwenden.
  • HyDE (Hypothetical Document Embeddings) — Generierung eines hypothetischen Dokuments, das die Frage beantworten würde, Vektorisierung dieses Dokuments und Verwendung seines Embeddings für die Suche. Diese Strategie verbessert die Präzision der semantischen Suche bei abstrakten oder technischen Fragen erheblich.
  • Zerlegung in Teilfragen — Aufteilung der ursprünglichen Frage in gezieltere Fragen, jede eine spezifische Dimension der erwarteten Antwort adressierend.

Multi-Query-Retrieval mit RRF. Der MultiQueryRetrievalStage generiert N Varianten der Anfrage, führt für jede einen unabhängigen Abruf durch und fusioniert die Ergebnisse durch Reciprocal Rank Fusion. Die RRF-Formel — score(d) = Σ 1/(k + rang_i(d)) — produziert ein konsolidiertes Ranking, das Dokumente bevorzugt, die in mehreren unabhängigen Listen in guter Position erscheinen, ohne von einem einzigen Relevanzsignal dominiert zu werden.

Hybride Suche. Der Abruf kombiniert systematisch die Dense-Suche (semantische Vektorsimilarität) und die Sparse-Suche (BM25, lexikalische Übereinstimmung). Dokumente, die durch ihre Bedeutung relevant sind, und Dokumente, die durch ihre exakten Begriffe relevant sind, werden beide abgerufen — dann von einem Cross-Encoder fusioniert und neu gerankt.

Schritt 2 — Bewertung des abgerufenen Kontexts

Sobald der Abruf abgeschlossen ist, bewertet der Agent die Qualität des erhaltenen Kontexts nach mehreren Kriterien:

Globale Relevanz. Das Relevanztor (RelevanceGateStage) berechnet einen aggregierten Vertrauensscore über die abgerufenen Passagen. Dieser Score reflektiert, inwieweit der Kontext mit der gestellten Frage übereinstimmt.

Thematische Abdeckung. Der Agent bewertet, ob die abgerufenen Passagen die Dimensionen der Frage abdecken — oder ob bestimmte Dimensionen im aktuellen Kontext fehlen. Eine Frage, die einen Vergleich zwischen zwei Entitäten erfordert, von denen nur eine in den abgerufenen Passagen vertreten ist, hat einen unvollständigen Kontext.

Interne Konsistenz. Widersprüchliche Passagen zur selben Tatsache sind ein Signal, dass der Abruf widersprüchliche Informationen zurückgebracht hat — was entweder einen ergänzenden Abruf zur Klärung oder eine explizite Signalisierung des Widerspruchs in der Antwort erfordert.

Schritt 3 — Entscheidung

Auf der Grundlage dieser Bewertung trifft der Agent eine von drei Entscheidungen:

Antworten. Der Kontext ist ausreichend relevant, vollständig und kohärent. Die Generierungs-Pipeline wird mit dem konsolidierten Kontext der aufeinanderfolgenden Iterationen ausgelöst. Die erzeugte Antwort ist in rückverfolgbaren, zitierten und verifizierbaren Quellen verankert.

Umformulieren und neu starten. Der Kontext ist unzureichend oder unvollständig. Der Agent formuliert die Anfrage um, indem er Informationen aus den bereits abgerufenen Passagen verwendet, um die neue Suche zu orientieren. Diese Umformulierung kann mehrere Formen annehmen: direkte Umformulierung der Frage, Zerlegung in eine Teilfrage, die die fehlende Dimension adressiert, oder Umformulierung durch Erweiterung zum in den teilweise relevanten Passagen identifizierten Vokabular.

Ein externes Tool aufrufen. Der Dokumentkontext ist für diese Anfrage inhärent unvollständig — nicht weil der Abruf unvollkommen ist, sondern weil die Information nicht im Korpus ist. Der Agent kann ein konfiguriertes externes Tool aufrufen, um den Kontext anzureichern: Konsultation einer Echtzeit-Daten-API, Ausführung einer Berechnung, Zugriff auf eine relationale Datenbank oder Aufruf eines spezialisierten Dienstes.

Schritt 4 — Schleifenkontrolle

Deterministische Wächter rahmen jede Iteration und können die Schleife unabhängig vom LLM-Verhalten unterbrechen:

  • Maximale Iterationsanzahl — die Schleife stoppt nach N Zyklen, unabhängig von den erzielten Ergebnissen.
  • Maximale Latenz — eine globale zeitliche Einschränkung für die agentische Sitzung.
  • Minimaler Relevanzschwellenwert — wenn der Kontext nach mehreren Umformulierungen den erforderlichen Schwellenwert nicht erreicht, enthält sich das System, anstatt eine schlecht begründete Antwort zu generieren.
  • SicherheitsbedingungenEingabe- und Ausgabe-Guardrails operieren bei jeder Iteration. Eine bei Iteration N erkannte Prompt-Injection unterbricht die Schleife an diesem Punkt.

Diese Wächter sind konfigurierbare, explizite und einsehbare Regeln. Sie hängen nicht von einem internen Vertrauensschwellenwert des LLM ab — dessen Kalibrierung je nach Modellen opak und variabel ist.


Die Architekturentscheidung, die alles verändert

Das Agentische außerhalb des zertifizierten Kerns

Die wichtigste Architekturentscheidung des agentischen Moduls von Lexiane liegt nicht darin, was es tut — sondern darin, wo es sich befindet.

Die agentische Reasoning-Schleife befindet sich nicht im zertifizierten Kern. Sie orchestriert den Kern von außen, über seine öffentlichen Schnittstellen, genau wie ein menschlicher Benutzer Pipelines manuell orchestrieren würde — aber mit der Geschwindigkeit eines Programms.

Diese Trennung ist kein Implementierungsdetail. Es ist das Prinzip, das das System gleichzeitig leistungsfähig und auditierbar macht.

Warum die agentische Schleife nicht im zertifizierten Kern sein kann. Der Kern von Lexiane führt deterministische Pipelines aus. Geben Sie ihm zweimal dieselben Eingaben, produziert er dieselben Ausgaben. Das ist eine grundlegende Eigenschaft eines zertifizierbaren Kerns — ohne sie beweisen Tests nichts und kann das Audit nichts verifizieren.

Die agentische Schleife ist von Natur aus nicht deterministisch. Das LLM, das entscheidet, ob es umformuliert oder antwortet, ist kein Automat — seine Entscheidungen hängen vom aktuellen Kontext, seiner Temperatur, der Sitzungshistorie ab. Zwei Sitzungen mit derselben ursprünglichen Frage können unterschiedliche Pfade einschlagen und durch unterschiedliche Routen zu gleichwertigen Antworten gelangen.

Nicht deterministisches Verhalten in einen zertifizierten Kern zu setzen, würde ihn nicht zertifizierbar machen. Lexiane trennt sie: Der Kern bleibt deterministisch, zertifizierbar, auditierbar. Die agentische Schicht bleibt nicht deterministisch, aber begrenzt und kontrolliert.

Was diese Trennung konkret garantiert.

Die vom Agenten ausgeführten Pipelines sind genau dieselben wie die im klassischen Modus — dieselben Stages, dieselben Ports, dieselbe Validierungslogik bei der Assembly, derselbe Audit-Trail. Der Agent hat keinen Zugriff auf Kernfunktionalitäten, die nicht über seine öffentlichen Schnittstellen exponiert werden.

Jede vom Agenten ausgelöste Pipeline — jede Schleifeniteration — produziert ihre eigenen Einträge in der SHA-256-Kette. Die vollständige Entscheidungssequenz ist rekonstruierbar: warum der Agent bei Iteration 2 umformuliert hat, welche Passagen er bei Iteration 3 abgerufen hat, warum er schließlich bei Iteration 4 entschieden hat zu antworten.

Das nicht deterministische Verhalten ist in der agentischen Schicht enthalten und durch die deterministischen Wächter begrenzt. Es kann den Kern nicht kontaminieren oder seine Sicherheitseigenschaften verändern.


Was agentisches RAG ermöglicht

Analyse komplexer und umfangreicher Dossiers

Ein Angebotsantwort-Dossier, ein regulatorisches Markteinführungsdossier, ein juristisches Streitsachendossier — diese Dokumentensets sind umfangreich, heterogen und erfordern die Kreuzreferenzierung von Informationen, die auf Dutzenden oder Hunderten von Dokumenten verstreut sind.

Das agentische RAG kann eine Analyseanfrage automatisch in Teilfragen zerlegen, sie iterativ behandeln und die Ergebnisse in einer strukturierten Antwort synthetisieren. Eine Frage wie “Identifiziere die Vertragsrisiken in diesem Lieferantendossier” wird zu einer Reihe gezielter Suchen: Strafklauseln, Kündigungsbedingungen, Service-Level-Verpflichtungen, Streithistorie — jede als distinct Iteration behandelt, deren Ergebnisse vor der endgültigen Synthese konsolidiert werden.

Abgleich widersprüchlicher Quellen

Zwei Berichte über denselben Vorfall, die in den Fakten divergieren. Zwei Versionen eines regulatorischen Verfahrens, die sich in einem kritischen Punkt widersprechen. Eine Norm und ihre Durchführungsverordnung, die nicht perfekt kohärent sind.

Eine klassische Pipeline wählt den einen oder anderen Kontext nach vektorieller Nähe. Der Agent kann den Widerspruch identifizieren, beide Kontexte parallel anfordern und eine Antwort formulieren, die die Divergenz explizit signalisiert — mit präzisen Referenzen zu den Quelldokumenten jeder Version. Das ist eine grundlegende qualitative Eigenschaft für Kontexte, in denen eine Antwort, die einen Widerspruch verbirgt, schlimmer ist als keine Antwort.

Großskalige Extraktion und Aggregation

Alle Vertragsfristen aus einem Korpus von 500 Verträgen extrahieren. Alle in 10.000 Wartungsberichten erwähnten Geräte mit ihrem letzten Wartungsdatum identifizieren. Alle Entscheidungen, die in einem Zeitraum von 24 Monaten in Vorstandssitzungen zu einem bestimmten Thema getroffen wurden, aufzählen.

Diese Aufgaben erfordern viele gezielte Abrufiterationen und eine Aggregation, die eine einzige Generierung auf einem vollständigen Korpus nicht zuverlässig produzieren kann. Der Agent kann iterativ Teilmengen des Korpus verarbeiten, Teilergebnisse konsolidieren und ein kohärentes aggregiertes Ergebnis produzieren.

Traversierung des Wissensgraphen

In der GraphRAG-Konfiguration verfügt das agentische RAG über ein zusätzliches Tool: die Multi-Hop-Traversierung des Wissensgraphs aus den Dokumenten. Komplexe relationale Fragen — “Was sind die Verbindungen zwischen diesem Projekt, seinen Lieferanten und den dokumentierten Qualitätsvorfällen?” — können durch eine Kombination von Vektorabruf und RDF-Graphtraversierung gelöst werden, wobei jede Iteration den Kontext aus einem anderen Blickwinkel anreichert.

Konversationelle Sitzungen mit Reasoning-Gedächtnis

Der Lexiane-Server pflegt persistente konversationelle Sitzungen. In einem agentischen Kontext geht dieses Gedächtnis über eine einfache Austauschhistorie hinaus: Der Agent kann sich auf den konsolidierten Kontext vorheriger Fragen stützen, um seinen Abruf für die folgenden Fragen zu orientieren. Eine Dossieranalysesitzung kann sich über mehrere Austausche erstrecken, jede aufbauend auf dem Reasoning der vorherigen — ohne dass der Benutzer bei jeder Frage neu kontextualisieren muss.


Wann agentisches RAG verwenden — und wann nicht

Agentisches RAG ist nicht universell dem klassischen RAG überlegen. Es ist für bestimmte Aufgaben leistungsfähiger, für alle kostenintensiver und führt zusätzliche operationelle Komplexität ein. Das richtige Werkzeug hängt von der Art der Anfragen ab.

KriteriumKlassisches RAGAgentisches RAG
Direkte, gut formulierte FragenOptimalÜberdimensioniert
Mehrdeutige oder unscharfe FragenVariable ErgebnisseDeutliche Verbesserung
Mehrere zu kreuzreferenzierende QuellenTeilergebnisseDeutliche Verbesserung
Korpus < 10.000 gut strukturierte DokumenteAusreichendOptional
Umfangreicher, heterogener KorpusKann Passagen verfehlenEmpfohlen
Großskalige Extraktion und AggregationAuf einzelner Passage schwierigDafür konzipiert
Strenge Latenzanforderung (< 2s)GeeignetUngeeignet (mehrere Iterationen)
Zertifizierte Umgebung, deterministisches VerhaltenZertifizierbarNicht zertifizierbar (agentische Schicht)
Kontrolliertes Token-BudgetSparsamMehrfachverbrauch

Die praktische Regel: Wenn Ihre Benutzer hauptsächlich direkte Fragen zu klar abgegrenzten Themen stellen, deckt das klassische RAG mit Multi-Query-Retrieval den wesentlichen Bedarf ab. Wenn Ihre Anwendungsfälle regelmäßig komplexe Analysen, Multi-Source-Kreuzreferenzierungen oder großskalige Extraktionen umfassen — ist das agentische RAG der geeignete Modus.

Beide Modi koexistieren in Lexiane und verwenden exakt dieselben zugrundeliegenden Pipelines. Der Wechsel von einem zum anderen ist eine Konfigurationsentscheidung nach Anfragetyp, keine Systemmigrierung.


Menschliche Kontrolle in der agentischen Schleife

Die Frage der menschlichen Kontrolle über agentische Systeme ist zentral — sowohl für KI-Governance-Teams als auch für regulatorische Referenzwerke wie den AI Act. Ein System, das autonom denkt, muss beobachtbar, unterbrechbar und auditierbar sein.

Beobachtbarkeit jeder Iteration

Jede Iteration der agentischen Schleife wird in der SHA-256-Audit-Kette aufgezeichnet: gestellte Frage, gewählte Umformulierungsstrategie, abgerufene Passagen, getroffene Entscheidung (antworten / umformulieren / Tool), bewerteter Relevanzscore. Die vollständige Reasoning-Sequenz ist im Nachhinein einsehbar — nicht nur die endgültige Antwort.

Diese Audit-Granularität ermöglicht es einem Supervisor zu verstehen, warum das System diesen oder jenen Pfad eingeschlagen hat — und die Fälle zu identifizieren, in denen das Reasoning suboptimal war, um die Schleifenparameter anzupassen.

Deterministische Wächter als Kontrollmechanismus

Die Wächter, die die agentische Schleife einrahmen, sind keine LLM-Parameter. Es sind konfigurierbare Regeln, die durch den Orchestrator-Code angewendet werden, unabhängig von den Entscheidungen des Sprachmodells. Selbst wenn das LLM “entscheidet” weiterzumachen, können die Wächter die Schleife unterbrechen.

Diese Wächter repräsentieren die Richtlinie, die Ihre Organisation zur Nutzung des Systems definiert hat: maximale Iterationsanzahl, maximale Latenz, minimaler Relevanzschwellenwert zur Auslösung der Generierung. Sie sind die Materialisierung der menschlichen Kontrolle in der Schleife.

Ressourcenverbrauchs-Tracking

Die Token-Verbrauchsstatistiken (UsageStats) werden über die gesamte agentische Sitzung akkumuliert und sind nach der Ausführung zugänglich. In der Cloud-Konfiguration ermöglichen diese Daten die Überwachung und Budgetierung des API-Verbrauchs einer Multi-Iterations-Reasoning-Sitzung — und die Erkennung abnormal langer oder kostspieliger Sitzungen.

Rückkopplungsschleife

Der FeedbackStore-Port ermöglicht es Benutzern, die vom agentischen System erzeugten Antworten zu bewerten. Diese Rückmeldungen speisen ein für die kontinuierliche Verbesserung verwendbares Register: Identifizierung der Anfragetypen, bei denen das agentische Reasoning unzureichend ist, der Domänen, in denen die Abrufqualität gering ist, der Fälle, in denen die automatische Umformulierung die Ergebnisse eher verschlechtert als verbessert.


Leistungs- und Kostenüberlegungen

Agentisches RAG verbraucht mehr Ressourcen als eine klassische Pipeline — per Definition, da es mehrere Pipelines ausführt, wo der klassische Modus eine ausführt. Diese Realität muss in das Deployment-Design integriert werden.

Token-Verbrauch. Jede Schleifeniteration generiert Embeddings für die Umformulierung, ruft Passagen ab und beansprucht das LLM für die Entscheidung und eventuelle Generierung. Bei einem Cloud-Modell bedeutet das eine Vervielfachung der API-Kosten im Vergleich zu einer klassischen Pipeline. Die Iterations-Begrenzungswächter sind der primäre Kostenkontrollmechanismus.

Latenz. Die Antwortzeit einer agentischen Sitzung ist die Summe der Antwortzeiten jeder Iteration. Eine Sitzung mit drei Iterationen dauert dreimal so lang wie eine klassische Pipeline, plus den Overhead der Inter-Iterations-Bewertung. Agentisches RAG ist nicht für Anwendungsfälle geeignet, die eine Antwortlatenz von weniger als einigen Sekunden erfordern.

Kostenkontrollstrategien in der Produktion.

Routing nach Komplexität. Der QueryRouter-Port von Lexiane ermöglicht die Klassifizierung jeder Anfrage und ihre Weiterleitung an den geeigneten Modus — klassisch für direkte Fragen, agentisch für komplexe Fragen. Dieses Routing reduziert den durchschnittlichen Verbrauch erheblich, indem der agentische Modus für die Anfragen reserviert wird, die ihn wirklich benötigen.

Leichtes Entscheidungsmodell. Die Entscheidung, umzuformulieren oder zu antworten, kann einem weniger leistungsfähigen (und weniger teuren) Sprachmodell als dem Generierungsmodell anvertraut werden. Nur die endgültige Generierung beansprucht das Modell maximaler Qualität — die Zwischeniterationen verwenden ein wirtschaftliches Entscheidungsmodell.

Semantischer Cache. Der SemanticCache-Port ermöglicht das Cachen von Antworten auf Anfragen, die semantisch ähnlich zu vorherigen Anfragen sind. Eine bereits behandelte Frage — oder eine sehr ähnliche Frage — löst keine neue agentische Sitzung aus: Die Antwort wird direkt aus dem Cache zurückgegeben.


Häufige Fragen

Wie bestimmt Lexiane, dass eine Umformulierung besser als die vorherige ist? Die Qualitätsbewertung des abgerufenen Kontexts beruht auf dem Score des Relevanztors (RelevanceGateStage) und den Abdeckungsmetriken. Die Entscheidung umzuformulieren wird getroffen, wenn dieser Score unter dem konfigurierten Schwellenwert liegt. Die Umformulierungsstrategie — Erweiterung, Zerlegung, HyDE — wird durch die Konfiguration der agentischen Schicht und durch die Analyse des teilweise abgerufenen Kontexts bestimmt.

Kann der Agent Daten ändern oder Aktionen in externen Systemen auslösen? Nur die als verfügbare Tools explizit konfigurierten Aktionen. Das agentische Modul hat keinen Zugriff auf nicht in seiner Konfiguration definierte Funktionalitäten. Die verfügbaren Tools, ihre Parameter und ihre Berechtigungen werden bei der Assembly definiert — nicht dynamisch vom LLM. Der Agent kann sich nicht selbst Fähigkeiten zuschreiben.

Wie garantiert man, dass der Agent bei sensiblen Fragen nicht in eine unerwünschte Richtung geht? Eingabe- und Ausgabe-Guardrails operieren bei jeder Iteration. Eine sensible Anfrage wird vom InputGuardrail bei ihrer Erkennung blockiert — nicht nur bei der ursprünglichen Frage, sondern bei jeder vom Agenten produzierten Umformulierung. Eine Antwort, die die Inhaltsrichtlinien überschreitet, wird vom OutputGuardrail vor der Übermittlung abgefangen. Die deterministischen Iterations-Begrenzungswächter begrenzen die Dauer jedes Reasonings.

Ist agentisches RAG mit Privatem RAG (Air-Gapped) kompatibel? Ja. In der Air-Gapped-Konfiguration läuft die agentische Schleife vollständig lokal — mit dem lokalen LLM (Mistral.rs) als Entscheidungsmotor. Die primäre Einschränkung ist die Reasoning-Fähigkeit des lokalen Modells: Ein 7B-13B-Modell ist für die meisten dokumentarischen Umformulierungsentscheidungen kompetent, kann aber bei sehr komplexem Reasoning an Grenzen stoßen. Die Hybrid-Konfiguration — agentische Entscheidung an ein Cloud-LLM auf anonymisierten Fragmenten delegiert — bietet einen Kompromiss zwischen Reasoning-Leistung und Souveränität der Quelldaten.

Kann agentisches RAG auf bestimmte Benutzer oder bestimmte Anfragetypen beschränkt werden? Ja. Das Routing nach Komplexität (QueryRouter) ermöglicht die selektive Aktivierung des agentischen Modus — nach Benutzerprofil, Anfragetyp oder abgefragter Dokumentensammlung. Ein Standardbenutzer kann zur klassischen Pipeline geroutet werden, während ein Senior-Analyst den agentischen Modus für seine komplexen Anfragen hat.

Wie debuggt man eine agentische Sitzung, deren Ergebnis unbefriedigend ist? Der Audit-Trail zeichnet jede Iteration mit ihren Parametern auf: umformulierte Frage, verwendete Transformationsstrategie, abgerufene Passagen, bewerteter Relevanzscore, getroffene Entscheidung. Die vollständige Rekonstruktion des Reasonings ist aus dieser Kette möglich — was es ermöglicht, genau die Iteration zu identifizieren, bei der das Reasoning divergiert hat, und die Parameter entsprechend anzupassen.


Sprechen wir über Ihre komplexen Anwendungsfälle.

Agentisches RAG bringt den größten Mehrwert bei präzisen Dokumentenbedürfnissen: umfangreiche und heterogene Korpora, Fragen quer durch viele Quellen, Extraktions- und Aggregationsaufgaben in großem Maßstab. Diese Bedürfnisse variieren erheblich zwischen Organisationen.

Wir bieten einen Austausch über Ihre konkreten Anwendungsfälle an — die Fragen, die Ihre Teams heute stellen und auf die Ihr Dokumentensystem schlecht antwortet, die komplexen Analysen, die noch einen manuellen Eingriff erfordern, die Korpora, die einer klassischen Suche widerstehen. Und eine ehrliche Bewertung dessen, was agentisches RAG bringen kann — einschließlich wenn der klassische Modus mit Multi-Query-Retrieval den wesentlichen Bedarf zu geringeren Kosten deckt.

Was Sie erwarten können:

  • Eine Antwort innerhalb von 48 Geschäftsstunden
  • Einen technischen Ansprechpartner, der die agentischen Produktionsanwendungsfälle und ihre realen Grenzen kennt
  • Eine auf Ihren Bedarf kalibrierte Konfigurationsempfehlung — klassisch, agentisch oder hybrid nach Anfragetypen

→ Kontakt aufnehmen

Keine kommerzielle Verpflichtung. Ein Gespräch über Ihre Anwendungsfälle.

Zugang zum Auditable Core anfragen

Melden Sie sich an, um benachrichtigt zu werden, wenn unser Core-Auditprogramm öffnet. Gemäß unserer Datenschutzrichtlinie wird Ihre geschäftliche E-Mail-Adresse ausschließlich für diese technische Kommunikation verwendet, ohne nachfolgende Marketingnutzung. Zugang über sicheres privates Register verteilt.

Kontakt aufnehmen