LLM-Evaluierung im großen Maßstab wird zum Engpass, wenn die Datensätze wachsen. Spark-LLM-Eval bietet eine verteilte Architektur mit Fokus auf statistische Strenge und Kostenkontrolle.
Das Problem der großflächigen LLM-Evaluierung zeigt sich nicht sofort — bis der Beispielsatz die Grenze von Zehntausenden überschreitet. Standardwerkzeuge zur LLM-Evaluierung arbeiten auf einer Maschine und setzen ein begrenztes Datenvolumen voraus. In Produktionsszenarien hält dies der Last nicht stand: Es treten seltene Fälle auf, es gibt eine Segmentierung der Benutzer und die Notwendigkeit für Regressionstests bei Hunderttausenden oder Millionen von Anfragen. Zusätzlich wird die Situation durch die Anforderung an statistische Signifikanz (Konfidenzintervalle, Signifikanztests) kompliziert, die die Rechenlast erhöht und den Engpass verstärkt.
In Spark-LLM-Eval wird die Evaluierung als datenparallele Aufgabe betrachtet. Jedes Beispiel wird unabhängig verarbeitet, und die Aggregation der Metriken erfolgt auf Cluster-Ebene. Die Architektur basiert auf Apache Spark: DataFrame mit Beispielen durchläuft die Phasen der Vorbereitung von Prompts, verteiltem Inferenz und Berechnung der Metriken. Ein zentrales Element ist Pandas UDF, das Batch-Verarbeitung ermöglicht und die Overhead-Kosten im Vergleich zu zeilenweisen UDFs senkt. API-Beschränkungen (Rate Limiting) werden durch ein Token-Bucket auf Executor-Ebene gelöst, wobei jedem Worker ein Anteil des globalen Limits (RPM, TPM) zugewiesen wird. Dies verhindert eine Überlastung des Anbieters, führt jedoch zu einem Kompromiss: Bei ungleicher Last kann ein Teil des Executors untätig sein.
Das System zeigt eine lineare Skalierung bis zu den API-Limits. Mit der Erhöhung der Anzahl der Executors steigt der Durchsatz auf ~9800 Beispiele pro Minute, danach wird die Begrenzung extern. Dies führt zu einer Beschleunigung von bis zu 21× im Vergleich zur sequenziellen Verarbeitung. Die Leistung hängt jedoch nicht nur von der Rechenleistung, sondern auch von der Latenz der API ab, was das System I/O-bound macht. Für große Datensätze (10k+) werden die Overhead-Kosten von Spark unbedeutend, was die Anwendbarkeit des Ansatzes für hochbelastete Evaluierungen bestätigt.
Eine separate Schicht ist das Caching von Antworten über Delta Lake. Der Schlüssel wird als SHA-256 von den Anfrageparametern (Prompt, Modell, Temperatur usw.) berechnet, was Determinismus gewährleistet. Diese Lösung vereinfacht die Reproduzierbarkeit und ermöglicht es, Inferenz von der Berechnung der Metriken zu trennen. Im Replay-Modus können API-Aufrufe vollständig ausgeschlossen und die Metriken auf bereits erhaltenen Antworten neu berechnet werden. Der praktische Effekt ist eine Kostenreduktion von bis zu 75% und eine Zeitersparnis von bis zu 69% in Szenarien der Metrikiteration. Der Kompromiss ist offensichtlich: Es fehlt an einem semantischen Cache, sodass jede Änderung des Prompts zu einem Cache-Miss führt.
Eine interessante Schicht ist die integrierte Statistik. Anstelle von Punkt-Schätzungen berechnet das System sofort Bootstrap-Konfidenzintervalle und wählt Signifikanztests je nach Art der Metrik aus. Beispielsweise wird für binäre Metriken der McNemar-Test verwendet, für kontinuierliche der gepaarte t-Test oder Wilcoxon. BCa-Bootstrap zeigt eine genauere Abdeckung bei kleinen Stichproben (ca. 95%) als Percentile-Bootstrap oder analytische Methoden. Dies ist wichtig: Bei großen Datenmengen können selbst kleine Unterschiede statistisch signifikant, aber praktisch nutzlos sein. Daher wird zusätzlich die Effektgröße (z.B. Cohens d) berechnet.
Die Unterstützung von Metriken umfasst mehrere Klassen: von einfachen lexikalischen (Exact Match, F1, BLEU) bis hin zu semantischen (BERTScore, Embeddings) und LLM-as-judge. Letzteres ist besonders empfindlich gegenüber systematischen Verzerrungen: Positionsbias, Neigung zu langen Antworten, Selbstbevorzugung. Das Framework korrigiert dies nicht, sondern macht das Verhalten nur beobachtbar. Für RAG-Szenarien wurden Metriken wie Faithfulness und Kontextrelevanz hinzugefügt, die es ermöglichen, nicht nur die Antwort, sondern auch die Retrieval-Schicht zu bewerten.
Für die Industrie sieht dies nach einer pragmatischen Weiterentwicklung bestehender Werkzeuge aus. Die zentrale Idee liegt nicht in neuen Metriken, sondern darin, sie auf realen Datenmengen anwendbar zu machen. Spark fungiert hier als infrastrukturelle Schicht und nicht als ML-Innovation. Die Haupttrade-offs bleiben: Abhängigkeit von API-Limits, fehlendes adaptives Rate Limiting und begrenzte Effizienz des Caches. Dennoch fügt sich der Ansatz gut in bestehende Datenpipelines ein und kann in CI/CD oder Regressionstests für LLM integriert werden.
In der praktischen Anwendung ist das System besonders nützlich, wo die Dynamik der Qualität wichtiger ist als ein einmaliger Benchmark. Beispielsweise beim Vergleich von Modellen, beim Verfolgen von Degenerationen oder beim Testen von Änderungen an Prompts. Dabei bleibt die Hauptaussage einfach: LLM-Evaluierung im großen Maßstab ist bereits eine Aufgabe für Infrastruktur und Statistik und nicht nur für die Qualität des Modells.
Informationsquelle
arXiv ist das größte offene Preprint‑Repository (seit 1991 unter der Schirmherrschaft der Cornell University), in dem Forschende schnell Arbeitsfassungen von Artikeln veröffentlichen; die Materialien sind öffentlich zugänglich, unterliegen jedoch keiner vollständigen Begutachtung, weshalb Ergebnisse als vorläufig angesehen und möglichst in überarbeiteten Versionen oder in begutachteten Fachzeitschriften überprüft werden sollten. arxiv.org