Databricks hat KARL (Knowledge Agents via Reinforcement Learning) vorgestellt, einen neuen KI-Agenten, der die Einschränkungen traditioneller Retrieval-Augmented Generation (RAG)-Pipelines überwinden soll. Die meisten RAG-Systeme für Unternehmen zeichnen sich durch einen Suchtyp aus und scheitern stillschweigend, wenn sie mit anderen konfrontiert werden. Ein für die Berichtssynthese optimiertes Modell wird beim präzisen Abrufen von Entitäten Schwierigkeiten haben, während ein Modell, das sich auf die Suche konzentriert, bei der mehrstufigen Argumentation scheitern wird. KARL möchte dieses Problem lösen, indem es darin geschult wird, sechs verschiedene Verhaltensweisen bei der Unternehmenssuche gleichzeitig zu handhaben.
Das Problem mit aktuellen RAG-Systemen
Bestehende RAG-Systeme sind spröde. Sie sind in der Regel auf bestimmte Suchaufgaben abgestimmt und daher anfällig, wenn sie mit der Komplexität der realen Welt konfrontiert werden. Ein für die einfache Beantwortung von Fragen geschulter Agent kann zusammenbrechen, wenn er mit der Rekonstruktion fragmentierter interner Aufzeichnungen oder der Synthese von Informationen aus unstrukturierten Besprechungsnotizen beauftragt wird. Diese Inflexibilität zwingt Teams dazu, für jeden Anwendungsfall separate Pipelines zu erstellen, was zu Wartungsaufwand und isoliertem Wissenszugriff führt.
So funktioniert KARL: Multi-Task-Reinforcement-Lernen
Databricks trainierte KARL mithilfe eines neuartigen RL-Algorithmus (Reinforcement Learning) und erreichte eine mit Claude Opus 4.6 vergleichbare Leistung bei 33 % geringeren Kosten pro Abfrage und 47 % geringerer Latenz. Entscheidend ist, dass das Modell vollständig auf von ihm selbst generierten synthetischen Daten trainiert wurde, wodurch eine teure Kennzeichnung durch Menschen entfällt. Möglich wurde dies durch OAPL, eine Richtlinie zur optimalen vorteilsbasierten Richtlinienoptimierung mit verzögerter Inferenz, die Databricks gemeinsam mit Forschern von Cornell und Harvard entwickelt hat.
Die wichtigste Innovation von OAPL ist seine Stabilität in verteilten Trainingsumgebungen. Im Gegensatz zu herkömmlichen LLM-RL-Ansätzen werden Richtlinienverzögerungen effektiv bewältigt, was ein stichprobeneffizientes Training ermöglicht und die GPU-Kosten senkt. Dadurch ist das Modell für den realistischen Einsatz in Unternehmen geeignet.
Sechs von KARL behandelte Verhaltensweisen bei der Unternehmenssuche
Um KARL zu bewerten, hat Databricks KARLBench erstellt, einen Benchmark, der die Leistung bei sechs kritischen Verhaltensweisen bei der Unternehmenssuche bewertet:
- Einschränkungsgesteuerte Entitätssuche: Abrufen bestimmter Entitäten unter strengen Bedingungen.
- Dokumentenübergreifende Berichtssynthese: Kombinieren von Informationen aus mehreren Quellen in einem kohärenten Bericht.
- Durchquerung langer Dokumente mit tabellarischer Argumentation: Extrahieren von Erkenntnissen aus großen Dokumenten mit numerischen Daten.
- Umfassender Entitätsabruf: Identifizieren aller relevanten Entitäten innerhalb eines bestimmten Datensatzes.
- Verfahrensbegründung bei technischer Dokumentation: Befolgen von Schritt-für-Schritt-Anweisungen aus komplexen Handbüchern.
- Faktenaggregation über unternehmensinterne Notizen: Kombination fragmentierter Daten zur Beantwortung komplexer Fragen.
KARL zeigte eine starke Generalisierung und schnitt im Gegensatz zu Standard-RAG-Systemen gut bei Aufgaben ab, für die es nie explizit geschult wurde.
Die Komprimierungsschicht: Kontextverwaltung
Eine große Herausforderung bei der Unternehmenssuche ist die Verwaltung des Kontextfensters von Large Language Models (LLMs). Herkömmliche RAG-Systeme basieren entweder auf riesigen Vektordatenbanken oder zwingen LLMs dazu, zu viele Informationen auf einmal zu verarbeiten. KARL begegnet diesem Problem, indem es lernt, seinen eigenen Kontext durch RL Ende-zu-Ende zu komprimieren. Wenn der Kontext die Grenzen des LLM überschreitet, komprimiert der Agent ihn und behält dabei die Genauigkeit bei, bleibt aber innerhalb der Grenzen. Ohne diese Komprimierung sinkt die Leistung des Modells erheblich.
Einschränkungen und zukünftige Roadmap
KARL kämpft mit Anfragen mit inhärenter Mehrdeutigkeit, bei denen es mehrere gültige Antworten gibt. Bei komplexen Abfragen gibt das Modell manchmal frühzeitig auf, was laut Databricks oft das richtige Verhalten für die Kosteneffizienz ist. Derzeit unterstützt KARL nur die Vektorsuche; Für die zukünftige Entwicklung ist die Integration mit SQL-Datenbanken, Dateisystemen und Python-basierten Berechnungen geplant.
Auswirkungen auf Unternehmensdatenteams
KARL hebt drei entscheidende Überlegungen für Teams hervor, die ihre Abrufinfrastruktur aufbauen:
- Pipeline-Architektur ist wichtig: Eng optimierte RAG-Pipelines schlagen bei verschiedenen Abfragetypen fehl.
- Verstärkendes Lernen ist der Schlüssel: Die Destillation aus Expertenmodellen kann nicht mit den Generalisierungsfähigkeiten von RL-geschulten Agenten mithalten.
- Effizienz ist mehr als Kosten: Speziell entwickelte Suchagenten erledigen Aufgaben schneller, reduzieren unnötige Abfragen und komprimieren den Kontext effektiv.
Der Aufbau eines Modells, das weiß, wie man sucht, ist wertvoller, als einfach alles über Allzweck-APIs weiterzuleiten.
