So sieht der Benchmark aktuell aus. Er testet die Fähigkeit von LLMs, geschäftliche und unternehmensbezogene Aufgaben zu bewältigen, die wir aus realen Industrieanwendungen extrahiert haben. Die Modelle werden mit komplexen Aufgaben konfrontiert, erhalten jedoch auch die Möglichkeit, durch gezielte Reasoning-Methoden wie Chain-of-Thought-Routinen innerhalb des Prompts ihre Leistung zu verbessern.

Aktuell führt OpenAI das Ranking an, dicht gefolgt von den Anthropic- und DeepSeek-Modellen. Besonders beeindruckend ist, dass lokal lauffähige Modelle in den Top 5 vertreten sind.

Noch bemerkenswerter ist, dass sich ein 70B-Modell auf Platz 5 befindet. Falls die Gerüchte über die NVIDIA RTX PRO 6000 Blackwell stimmen, würde eine einzelne GPU-Karte ausreichen, um dieses Modell in nativer fp8-Quantisierung für GPUs auszuführen, während noch genügend Speicherplatz für KV-Caches und größere parallele Kontexte übrig bliebe.

Neue AI-Coding-Aufgaben in den Benchmark importiert

Wie bereits erwähnt, ist dieser Benchmark noch nicht vollständig. Wir befinden uns weiterhin im Prozess der Überprüfung von AI-Anwendungsfällen in unserem Portfolio und importieren diese als neue Tests in den Benchmark.

Hier ist ein Beispiel für einen Fintech-Codeverständnis-Benchmark. Dieser Test (einer von vielen weiteren) lautet wie folgt:

Übrigens: Beachte, dass wir die Frage im Prompt vor den kontextuellen Daten platzieren. Dies zerstört zwar die Caching-Semantik vollständig, erleichtert aber die Arbeit der Modelle und verbessert die Gesamtgenauigkeit.

Der Quellcode für diese spezifische Aufgabe ist eine Klasse, die das Zustandsmanagement für Kreditkarten implementiert. Sie enthält eine Liste ausführbarer, ereignisgesteuerter Spezifikationen, die alle Verhaltensweisen überprüfen. Die gesamte Datei umfasst 1100 Zeilen dichten Python-Codes.

Allen Modellen steht eine benutzerdefinierte Chain-of-Thought-Routine zur Verfügung, die sie innerhalb ihrer Antwort nutzen können. Hier ist ein Beispiel dafür, wie o1 diese knifflige Frage korrekt löst:

Und so wird die Anfrage von Sonnet 3.7 (ohne Reasoning) verarbeitet:

Solche Coding-Aufgaben sind ein guter Indikator, um die Fähigkeiten von Modellen im Bereich Softwareentwicklung zu bewerten. Wir werden weiterhin AI-Anwendungsfälle in diesen Benchmark integrieren, um ihn relevanter und repräsentativer zu machen.

Nun kommen wir zur Bewertung aktueller Modelle:

OpenAI: o3-mini und GPT-4.5

Das o3-mini-Modell von OpenAI hat den ersten Platz in unserem Benchmark erreicht (Reasoning-Aufwand: mittel). Es ist derzeit das beste verfügbare Modell. In unserem aktuellen Coding-Benchmark erzielte es eine perfekte Punktzahl von 100 %, erreichte 45 % im BI-Benchmark und 70 % im Compliance-Benchmark.

Das kürzlich veröffentlichte GPT-4.5-Modell verfügt über kein explizites Reasoning. Es ist sehr präzise und versteht feine Nuancen gut, konnte jedoch nicht so hoch punkten und erreichte eine aggregierte Punktzahl von 51 %.

Hier ist ein Beispiel dafür, wie dieses Modell die oben beschriebene Coding-Aufgabe falsch gelöst hat. Es hat den Gedankengang einfach nicht vollständig zu Ende geführt:

Anthropic: Claude 3.7 Sonnet mit und ohne Reasoning

Anthropic-Modelle werden von Entwickler:innen und Nutzer:innen oft für ihr angenehmes und produktives Dialogformat gelobt. Allerdings hatte Anthropic in letzter Zeit nicht viel Erfolg mit fortgeschrittenen Modellen (erinnert sich noch jemand an Opus?) – bis jetzt.

Das neue Claude 3.7 Sonnet mit integriertem Reasoning erreichte in unserem Benchmark 70 % und erzielte eine perfekte 100 %-Wertung im Coding-Bereich, womit es den 2. Platz belegte. Das Schwestermodell ohne Reasoning landete auf Platz 8.

Wir haben Claude 3.7 Sonnet im Reasoning-Modus mit einem Budget von 25.000 Tokens ausgeführt, wobei 80 % davon für das Reasoning reserviert waren. Zusätzlich hatte das Modell einige Reasoning-Slots innerhalb des Antwortbudgets.

Was den Erfolg für Anthropic noch bemerkenswerter macht: Ihre Modelle verfügen noch immer nicht über einen echten Structured Output Mode, bei dem das Schema durch constrained decoding in 100 % der Fälle garantiert wird. Dennoch gelang es ihnen, in jedem einzelnen Testfall dieses Benchmarks ein korrekt parsebares JSON-Schema zu liefern.

Beachte, dass die Ergebnisse mit Anthropic-Modellen variieren können. In einigen Produktionsfällen beobachten wir beispielsweise Fehlerraten bei JSON-Schemata von etwa 5–10 %, was in der Regel eine nachträgliche Schema-Reparatur erforderlich macht.

Qwen-Modelle

Wir haben eine Reihe neuer Qwen-Modelle in unseren Benchmark aufgenommen, konzentrieren uns aber auf die beiden herausragenden: Qwen Max und QwQ 32B.

Qwen Max ist ein groß angelegtes MoE-Modell (Mixture of Experts). Es erzielte solide Ergebnisse und erreichte den 12. Platz. In seiner Leistung ist es vergleichbar mit Microsoft Phi-4 und Claude 3.5 Sonnet.

Qwen QwQ-32B ist ein lokal lauffähiges Modell, das den Stand der Technik in unserem Benchmark weiter vorantreibt. Es setzt eine neue Bestmarke für die Genauigkeit, die mit 32B-Modellen erreicht werden kann. Der bisherige Rekordhalter war ebenfalls ein Qwen-Modell (qwen-2.5-32B instruct), doch das neue Modell bringt echtes Reasoning mit.

Wir haben das QwQ-32B-Modell getestet, indem wir es über OpenRouter vom Fireworks-Provider ausgeführt haben – eine bewusste Wahl, da Fireworks Structured Outputs unterstützt. Diese Erfahrung hat uns jedoch einige Tage voller Frustration gekostet und ein grundlegendes Problem im Ökosystem der Reasoning-Modelle deutlich gemacht.

Krise des OpenAI SDK als gemeinsamer Standard für LLM-APIs

Zum Zeitpunkt des Schreibens sind die OpenAI-API und das Python-SDK de facto der Standard für die Anbindung verschiedener Modelle. Es ist nicht unbedingt der beste Standard, aber es hat sich bislang nichts anderes durchgesetzt. Innerhalb dieses Ökosystems kann man eine einzige Bibliothek nutzen, um auf verschiedene Server zuzugreifen, etwa vLLM oder ollama. Nvidia entwickelt eine OpenAI-kompatible Frontend-Schnittstelle für den Triton Inference Server. Selbst Google hat nach langer Überlegung angekündigt, OpenAI-kompatibel zu werden.

Meistens funktioniert alles – bis es das nicht mehr tut.

Ein Beispiel: Beim Aufruf des QwQ-32B-Modells über die OpenAI-SDK-Bibliothek (die laut OpenRouter garantiert funktionieren sollte) erhielten wir den Error: 'NoneType' object is not iterable – tief aus dem Inneren des OpenAI-SDK.

Die eigentliche Ursache war etwas komplexer.

Moderne Reasoning-Modelle verbrauchen mehr Tokens, um über ein Problem nachzudenken, bevor sie eine Antwort liefern. OpenAI-Modelle verbergen diesen Denkprozess, während Open-Source-Modelle ihn explizit kennzeichnen, indem sie in der Antwort -Tags verwenden.

Vermutlich wollte OpenRouter hier besonders intelligent und benutzerfreundlich sein. Es platziert automatisch die Denk-Tokens in ein spezielles „reasoning“-Feld der Antwort, während die eigentliche Antwort in „content“ abgelegt wird. Das allein reicht aus, um Probleme zu verursachen, insbesondere wenn das Modell mit StructuredOutput und constrained decoding arbeitet. Bemerkenswert ist, dass das Reasoning-Feld eine korrekte JSON-Antwort enthält, während das Content-Feld leer bleibt:

Wie bereits bekannt, haben wir gerade die zweite Runde der Enterprise RAG Challenge abgeschlossen. Vor dem Start hatten sich über 350 KI-Enthusiast:innen aus der ganzen Welt registriert. 

Die Herausforderung: Ein RAG-System für Geschäftsberichte
Die Herausforderung bestand darin, ein RAG-System zu entwickeln, das 100 Fragen zu 100 verschiedenen Geschäftsberichten beantworten kann. Der umfangreichste Bericht umfasste mehr als 1000 Seiten! Wir haben zahlreiche Einsendungen erhalten und über 100 ausgefüllte AI-Umfragen, in denen die Teams ihre Ansätze und Architekturen detailliert erklärten. 

Ein kollaboratives Forschungsexperiment
Dadurch wurde ERCr2 zu einem groß angelegten, kollaborativen Forschungsexperiment für präzise Enterprise-RAG-Systeme. Hier sind einige der wichtigsten Erkenntnisse, die wir gemeinsam mit der Community gewonnen haben: 

1. Die Qualität der Datenauslese ist entscheidend für die Gesamtgenauigkeit. Die besten RAG-Lösungen nutzten die Docling-Dokumentenextraktionsbibliothek. 
2. Eine gute Architektur ermöglicht hochwertige Ergebnisse – selbst mit einem kleinen lokalen LLM!

Ein Blick auf die Architektur der Gewinnerlösung: PDF-Parsing mit stark modifizierter Docling-Bibliothek Dense Retrieval Router Parent Document Retrieval Structured Output Chain-of-Thought (SO CoT) Structured Output Reparser (SO Reparser) Diese Architektur wurde mit verschiedenen LLM-Modellen evaluiert und erzielte folgende Ergebnisse:

Wie man sehen kann: Je weniger leistungsfähig ein Modell ist, desto niedriger sind die Ergebnisse. Aber dank der hohen Qualität des Retrievals fällt die Generationsbewertung nicht so stark ab, wie wir es erwartet hätten!

Mit einer guten Gesamtarchitektur und Llama-3.1 8B liegt die Antwortgenauigkeit beispielsweise bei 68,7 %. Ersetzen wir dieses Modell durch ein 70B-Modell, steigt die Genauigkeit nur um 4 %. Und wenn wir das lokale 70B-Modell durch das beste Reasoning-Modell ersetzen, verbessert sich die Enterprise RAG Accuracy lediglich um 9 %.

Diese Bewertung wurde aus unseren Benchmarks abgeleitet und auf die Enterprise RAG Challenge angewendet. Sie erwies sich als ein guter Indikator für die potenzielle Qualität, die mit einer bestimmten RAG-Architektur erreicht werden kann. Die RAG-Genauigkeit hängt stark von der Qualität der Retrieval-Komponente ab. Ist die endgültige RAG-Bewertung jedoch deutlich niedriger als die Qualität des Retrievals, gibt es oft einfach umsetzbare Verbesserungen, um die Präzision zu erhöhen.

Unsere dritte Erkenntnis: Reasoning-Patterns auf Basis von Structured Outputs und Custom Chains of Thought wurden von allen Top-Lösungen genutzt. Sie funktionieren selbst dann, wenn Structured Outputs vom LLM-Serving nicht direkt unterstützt werden (z. B. durch constrained decoding) und das Schema erst repariert werden muss.

Unsere vierte Erkenntnis: Vektorsuche ist noch nicht komplett tot. Ein hochwertiger Dense Retrieval-Mechanismus war die Basis für die beste Lösung. Interessanterweise nutzte die zweitplatzierte Lösung im Preis-Leaderboard jedoch keine Vektoren.

Insgesamt haben wir gelernt: Kleine, lokal lauffähige Modelle sind leistungsfähiger als ursprünglich gedacht. Open-Source-LLMs bieten bereits eine starke Konkurrenz zu proprietären Modellen, insbesondere wenn sie mit SO/CoT-Patterns an ihre Grenzen gebracht werden.

Vielleicht sehen wir im Jahr 2025 eine breitere Akzeptanz von KI-gestützten Geschäftssystemen, die lokal ausgeführt werden und dabei keine Qualitätskompromisse zugunsten der Sicherheit mehr eingehen müssen.

Transformieren Sie Ihre digitalen Projekte mit den besten KI-Sprachmodellen!

Entdecken Sie die transformative Kraft der besten LLM und revolutionieren Sie Ihre digitalen Produkte mit KI! Bleiben Sie zukunftsorientiert, steigern Sie die Effizienz und sichern Sie sich einen klaren Wettbewerbsvorteil. Wir unterstützen Sie dabei, Ihren Business Value auf das nächste Level zu heben.