Databricks Large Language Models: Vom Modellvergleich zum LLM-Portfolio

Mehrere Fachbereiche setzen unterschiedliche Modelle ein, ohne sie nach denselben Kriterien verglichen zu haben. Das Marketing nutzt beispielsweise ein Modell, weil es bereits früh verfügbar war. Der Vertrieb testet parallel ein anderes Modell für längere Texte. Im Service läuft ein RAG-Prototyp auf einem Open-Weight-Modell, das aus einem frühen Technologieversuch übernommen wurde. Bei der späteren Auswahl für einen gemeinsamen Wissensassistenten empfiehlt jedes Team das Modell, das es bereits kennt.

Eine solche Modelllandschaft entsteht in wachsenden KI-Programmen häufig ohne bewusste Gesamtplanung. Frühe Pilotprojekte wählen meist das Modell, das zum jeweiligen Zeitpunkt am einfachsten verfügbar ist. Die Bewertung beschränkt sich oft auf wenige manuell ausgewählte Beispiele. Lizenz- und Vertragsbedingungen werden dabei nicht immer systematisch geprüft. Nutzungskosten laufen möglicherweise über einzelne Team- oder Projektkonten und sind zentral kaum sichtbar. Spätestens bei einer Governance- oder Audit-Anfrage zeigt sich, dass die Gründe für die Modellwahl nicht ausreichend dokumentiert wurden.

Vor einer belastbaren Modellentscheidung müssen mehrere Fragen geklärt werden.

Die Qualität eines Modells lässt sich nicht unabhängig vom konkreten Anwendungsfall bewerten. Auf einer Plattform mit mehreren Anwendungsfällen sollte die Modellauswahl deshalb als Portfolioentscheidung verstanden werden: Für jede Aufgabenklasse werden wenige geeignete Kandidaten definiert und miteinander verglichen, die Bereitstellung erfolgt über standardisierte Zugriffswege wie Foundation Model APIs oder External Models, und die Auswahl wird mit einer reproduzierbaren Evaluationspipeline geprüft. Ein Modell, das gute deutsche Marketingtexte erzeugt, muss nicht gleichzeitig bei SQL-Code oder Vertragsanalyse überzeugen. Für lange Dokumente und mehrstufige Schlussfolgerungen können andere Modelle besser geeignet sein.

Für die praktische Modellauswahl lassen sich fünf Gruppen unterscheiden. Sie unterscheiden sich bei Aufgabenprofil, Anbieter, Lizenz und Bereitstellung.

Öffentliche Benchmarks und Vergleichsplattformen (Stanford HELM, Hugging Face Open LLM Leaderboard, LMSYS Chatbot Arena) können eine erste Orientierung bieten. Sie ersetzen jedoch keine Evaluation mit eigenen Daten, Sprachen und Aufgaben.

Mehrsprachige Qualität wird bei der Modellauswahl häufig unterschätzt. Ähnliche Ergebnisse in englischen Benchmarks lassen nicht automatisch auf vergleichbare Qualität in deutscher Sprache schließen. Bei deutschen RAG-Antworten können sich Modelle deutlich bei Fachsprache, Stil und Genauigkeit unterscheiden.

Open-Weight-Modelle aus den Familien Llama, Mistral und Qwen können für viele deutsche Standardaufgaben gute Ergebnisse liefern. Qwen ist 2026 in mehrsprachigen Aufgaben besonders auffällig, Llama 4 verbessert lange Kontexte und Tool-Aufrufe deutlich. Die Bewertung sollte aber immer anhand aktueller Versionen und eigener Testfälle erfolgen. Bei stark spezialisierter Fachsprache oder langen strukturierten Ausgaben können zusätzliche Qualitätsunterschiede sichtbar werden. DeepSeek- und GLM-Modelle bieten bei Code, SQL und Reasoning eine wettbewerbsfähige Alternative, sind in der deutschsprachigen Textgenerierung aber je nach Version unterschiedlich stark; eine gezielte Eval lohnt sich vor jeder produktiven Festlegung.

Proprietäre Spitzenmodelle erzielen bei deutschen und mehrsprachigen Aufgaben häufig sehr gute Ergebnisse. Das kann besonders bei komplexer Fachsprache und langen Dokumenten relevant sein. Dem stehen externe Datenverarbeitung, Anbieterabhängigkeit und nutzungsabhängige Kosten gegenüber, die im RAG mit großen Wissensbasen schnell sichtbar werden.

Für deutsche Open-Weight-Modelle lassen sich grob unterschiedliche Anforderungsstufen unterscheiden. Für Standardgenerierung und kurze RAG-Antworten können aktuelle Llama- oder Mistral-Modelle geeignete Ausgangspunkte sein. Bei juristischen, medizinischen oder anderen stark spezialisierten Aufgaben sollte der Vergleich mit proprietären Modellen ausdrücklich Teil der Evaluation sein. Ein proprietäres Modell kann in solchen Fällen die pragmatischere Lösung sein, wenn es die Qualitätsanforderungen deutlich besser erfüllt. Alternativ kann geprüft werden, ob ein angepasstes Open-Weight-Modell wirtschaftlich und technisch sinnvoll ist.

Ein einzelnes Modell wird häufig nicht wegen nachgewiesener Überlegenheit gewählt, sondern weil ein einheitlicher Vergleich fehlt. Ohne gemeinsame Bewertungsmethode lassen sich Alternativen kaum objektiv vergleichen. Eine belastbare Modellentscheidung benötigt wiederholbare Tests. Andernfalls setzt sich oft das Modell durch, das bereits bekannt ist oder früh im Projekt eingesetzt wurde.

Eine Evaluationspipeline sollte mindestens drei Ebenen abdecken. MLflow kann technische und qualitative Metriken wie Latenz, Kosten und bestimmte Qualitätsindikatoren erfassen (Exaktheit, Toxizität, Halluzination, Token-Kosten, Latenz). Für Agenten und Tool-Aufrufe müssen zusätzlich Auswahl, Parameter und mehrstufige Abläufe bewertet werden. Den wichtigsten Teil bilden eigene Testfälle aus dem konkreten Anwendungsfall. Diese können durch ein Bewertungsmodell unterstützt und durch fachliche Stichproben abgesichert werden.

Öffentliche Benchmarks (MMLU, GPQA, Stanford HELM, LMSYS Chatbot Arena) helfen bei der Vorauswahl geeigneter Kandidaten. Die endgültige Auswahl sollte jedoch auf eigenen Daten, Sprachen und Zielaufgaben beruhen. Ein Modell mit besserem allgemeinem Benchmarkwert kann im eigenen deutschen Fachanwendungsfall dennoch schlechter sein.

Eine Evaluation wird erst dann dauerhaft nützlich, wenn sie reproduzierbar und automatisierbar ist. Ist die Pipeline etabliert, lassen sich neue Modelle und Versionen deutlich schneller vergleichen. Für einen neuen Kandidaten wird ein weiterer Endpoint ergänzt und gegen dieselben Testfälle ausgeführt. Für einen neuen Anwendungsfall wird ein eigenes, repräsentatives Testset aufgebaut, während der technische Bewertungsprozess wiederverwendet werden kann.

Der AI Playground eignet sich für eine erste qualitative Gegenüberstellung mehrerer Modelle. Offensichtlich ungeeignete Kandidaten können so früh ausgeschlossen werden. Modelle mit ähnlichem Ersteindruck sollten anschließend mit einer strukturierten Evaluation verglichen werden.

Wie sich Eval-Pipelines, Drift-Monitoring und Modell-Auswahl als Betriebsthema zusammenführen lassen, klären wir im Überblick zu AI-Governance auf Databricks.

In LLM-Projekten wird häufig Modellqualität mit Retrieval-Qualität verwechselt. Ein leistungsfähigeres Generierungsmodell kann fehlerhafte Datenaufbereitung oder Retrieval-Probleme nicht zuverlässig kompensieren.

Liefert die Suche unpassende oder unvollständige Textstellen, kann selbst ein sehr leistungsfähiges Modell keine verlässliche, quellenbasierte Antwort erzeugen. Erfasst das Embedding-Modell deutsche Fachbegriffe nicht ausreichend, muss zunächst die Such- und Embedding-Komponente verbessert werden. Werden Tabellen, Absätze oder zusammengehörige Inhalte beim Chunking ungünstig getrennt, erhält das Generierungsmodell nicht die notwendigen Informationen im Zusammenhang. Databricks ordnet die vier Anpassungs-Patterns Prompt Engineering, Retrieval-Augmented Generation, Fine-Tuning und Pre-Training als nicht-exklusive Bausteine ein. Prompting, RAG, Fine-Tuning und Pre-Training sind unterschiedliche Werkzeuge, die je nach Problem kombiniert werden können.

Für die Qualität einer RAG-Anwendung sind mindestens drei Bereiche entscheidend: Aufbereitung und sinnvolle Segmentierung der Quelldaten, Embedding-Modell, Indexierung und Suchverfahren, erst danach die Auswahl und Konfiguration des Generierungsmodells. In der Eval zeigt sich der Unterschied schnell. Bleibt die Antwort trotz korrektem und vollständigem Kontext unzureichend, liegt die Ursache wahrscheinlich eher beim Modell, Prompt oder Ausgabeformat. Fehlt der relevante Kontext bereits vor der Generierung, muss zunächst das Retrieval verbessert werden.

Wie RAG-Use-Cases auf Databricks tragfähig aufgebaut werden, klären wir im Überblick zu Retrieval-Augmented Generation auf Databricks. Welche Anpassungsstrategie wann sinnvoll wird (Prompt, RAG, Fine-Tuning oder Continued Pre-Training), zeigen wir im Überblick zu Mosaic AI Training auf Databricks.