Technisches Resümee: Opti-Q: Ein auf Constraints basierender Optimierungsrahmen für die Multi-LLM-Frageplanung

1. Problemstellung

Der Einsatz von Large Language Models (LLMs) für das Beantworten von Fragen (Question Answering, QA) steht vor erheblichen Herausforderungen hinsichtlich Nichtdeterminismus, heterogener Ressourcenprofile (finanzielle Kosten, Latenz, Energie) und variierender Performance bei unterschiedlichen Fragetypen. Während jüngere Arbeiten darauf hindeuten, dass koordinierte Multi-LLM-Kollaborationen ein einzelnes „bestes“ Modell übertreffen können, führen naive Ausführungsstrategien (z. B. das Abfragen aller Modelle oder die Verwendung fester Kaskaden) oft zu einer ineffizienten Ressourcennutzung, höheren Kosten und suboptimaler Antwortqualität.

Aktuelle Orchestrierungs-Frameworks (z. B. LangChain, DSPy) verlassen sich oft auf entwicklergesteuerte Workflows oder dynamische, kurzsichtige Entscheidungen zur Laufzeit, ohne die Auswirkungen auf nachfolgende Prozesse zu berücksichtigen. Es mangelt an Systemen, die die Multi-LLM-Orchestrierung als ein kostenbasiertes, multikriterielles Frageplanungsproblem behandeln, bei dem der optimale Ausführungsplan (sequenziell, parallel oder hybrid) vor der Ausführung basierend auf benutzerdefinierten Constraints (Budget, Latenz, Energie) und der gewünschten Antwortqualität (QoA) ausgewählt wird.

2. Methodik: Das OPTI-Q Framework

OPTI-Q ist ein datenbankinspirierter, kostenbasierter Optimierer, der ein „Plan-vor-Ausführung“-Paradigma für das Multi-LLM-QA implementiert. Es modelliert das Problem als eine Multi-Objective Optimization (MOO) Aufgabe, bei der das Ziel darin besteht, Pareto-optimale Pläne zu finden, die QoA gegen finanzielle Kosten, Latenz und Energie abwägen.

A. Modellierung und Formalisierung

• Fragemodell: Eine Frage $Q$ ist definiert durch einen Prompt, ein Thema und Benutzer-Constraints ($F_{max}, L_{max}, E_{max}, QoA_{min}$) sowie einen Gewichtungsvektor $W$ zur Priorisierung der Ziele.
• Planmodell: Pläne werden als gerichtete azyklische Graphen (DAGs) dargestellt, wobei Knoten LLM-Aufrufe (physische Operatoren) und Kanten den Datenfluss repräsentieren.
  • Sequenzielle Operatoren: Übergeben Zwischenantworten als Kontext an nachfolgende Modelle.
  • Parallele Operatoren: Führen mehrere Modelle gleichzeitig aus.
  • Blending-Operatoren: Verschmelzen die Ausgaben aus parallelen Zweigen mithilfe eines dedizierten „Blender“-Modells.
• Optimierungsziel: Maximiere $[QoA(\pi), -Financial(\pi), -Latency(\pi), -Energy(\pi)]$ unter Einhaltung der Benutzer-Constraints.

B. Kernkomponenten

1. PERFDB (Statistik-Katalog):

   • Eine Performance-Datenbank, die offline und inkrementell aus Benchmarks und Ausführungstraces befüllt wird.
   • Speichert Statistiken (QoA, Kosten, Latenz, Energie) für einzelne LLMs und zusammengesetzte Teilpläne, gruppiert nach Ausführungskontext (Thema, Operatortyp, Modell).
   • Ermöglicht die Pre-Execution-Schätzung von Planmetriken, ohne den Plan tatsächlich auszuführen. Es behandelt Stochastizität durch die Speicherung von Varianzschätzungen und Konfidenzintervallen.

2. Kosten-Nutzen-Schätzung:

   • Token-Schätzung: Prognostiziert Input-/Output-Token-Anzahlen basierend auf modellspezifischen Tokenizern und historischen Ausgabelängen, um Kosten zu schätzen.
   • QoA-Schätzung: Verwendet einen themenabhängigen Lookup in der PERFDB. Für zusammengesetzte Pläne werden multiplikative relative Effektfaktoren (für sequentielle Schritte) und durchschnittliche relative Änderungsfaktoren (für Blending) angewendet, die aus historischen Traces abgeleitet wurden, um die Qualität des vollständigen Plans zu schätzen.
   • Ressourcen-Schätzung: Berechnet finanzielle Kosten (fix + variabel pro Token), Energie (proportional zu Tokens) und Latenz (linear mit Token-Volumen; parallele Zweige nehmen die maximale Zeit in Anspruch).

3. Plan-Generierung und Suche:

   • Kodierung: Pläne werden kompakt als Konnektivitätsmatrix (Adjazenzmatrix) und Modell-Zuweisungsvektor kodiert.
   • Suchraum: Der Raum der möglichen Pläne ist kombinatorisch und NP-schwer zu optimieren.
   • Optimierungs-Engines: OPTI-Q unterstützt eine „pluggable“ Engine mit drei Strategien:
     • Dynamische Programmierung (DP): Exakter Solver für kleine Instanzen; nutzt Pruning zur Bewältigung der Zustandsraumexplosion.
     • Hill Climbing (HC): Leichtgewichtige, gierige Heuristik für eine schnelle, lokale Suche.
     • NSGA-II: Ein multi-objektiver evolutionärer Algorithmus, der als Standard für große Planräume verwendet wird, um die Pareto-Front zu approximieren.
   • Selektion: Der Optimierer generiert eine Menge nicht-dominanter, zulässiger Pläne. Der finale Plan wird basierend auf den Benutzergewichten $W$, die auf die normalisierten Ziele angewendet werden, ausgewählt.

C. Implementierung

• System: Modulares Framework, das einen Optimierer mit einer Ausführungsengine integriert.
• Modelle: Getestet mit fünf Open-Source-Modellen (Gemma-3:27B, LLaMA3-ChatQA, Qwen2.5, Phi-4, Mistral), die lokal via Ollama ausgeführt werden.
• Blending: Verwendet Gemma-3:27B als dedizierten Blender und übertrifft dabei spezialisierte Komponenten wie GenFuser in der Validierung.
• Prompting: Nutzt Zero-Shot-Prompting mit spezifischen Kontext- und Blending-Prompts, um das Modellverhalten zu steuern.

3. Zentrale Beiträge

1. Cost/Benefit-Formalisierung: Eine Formalisierung der Multi-LLM-QA-Planung als beschränktes Multi-Objective-Optimierungsproblem, das QoA, Kosten, Latenz und Energie explizit abwägt.
2. Statistik-getriebener Optimierer: Ein System, das sequenzielle, parallele und hybride Workflows enumeriert und prunt, wobei die Qualität und die Ressourcenkosten vor der Ausführung mittels eines historischen Statistik-Katalogs (PERFDB) geschätzt werden.
3. Integriertes System: Ein funktionsfähiger Prototyp, der Fragen dynamisch über Open-Source-LLMs routet und optimale Ausführungs-Graphen in Echtzeit auswählt.

4. Experimentelle Ergebnisse

Das Framework wurde auf den Benchmarks MMLU-Pro (Multiple-Choice) und SimpleQA (Open-Ended) gegen vier State-of-the-Art-Baselines (ThriftLLM, LLM-Ensemble, FrugalGPT, LLM-Blender) evaluiert.

• Performance-Gewinne: Unter einem spezifizierten Budget verbesserte OPTI-Q die durchschnittliche QoA um ≈58% auf SimpleQA und um ≈41% auf MMLU-Pro im Vergleich zu den stärksten budgetbewussten Baselines bei identischen Kosten pro Frage.
• Skalierbarkeit: NSGA-II bot das beste Skalierbarkeits-Qualitäts-Verhältnis und behielt eine nahe an der Referenz-Pareto-Front liegende Qualität bei Planungszeiten im niedrigen Zehnsekundenbereich bei (z. B. 21s für $k=5$ Operationen).
• Robustheit gegenüber Datenknappheit: In „Cold-Start“-Szenarien (Level 0 PERFDB-Abdeckung) übertraf OPTI-Q die Baselines dennoch. Mit zunehmenden historischen Daten (Level 1–4) verbesserte sich die QoA signifikant (z. B. +66,7% auf MMLU-Pro) und die Fehler bei der Ressourcen-Schätzung sank drastisch.
• Budget-Einhaltung: Das System hielt eine hohe Budget-Adhärenz ein (88–96%), wobei Überschreitungen prim primär durch die Kosten und weniger durch die Latenz getrieben wurden.
• Vergleich mit kommerziellen APIs: OPTI-Q erreichte eine höhere QoA als kommerzielle Modelle (z. B. Claude Opus 4.6, GPT 5.4) auf SimpleQA, während es signifikant weniger kostete (37,8× bzw. 14,5× weniger, wenn man externe Serverkosten berücksichtigt). Auf MMLU-Pro erreichte es eine konkurrenzfähige Qualität (0,82 vs. 0,871 für Gemini 3.5 Flash) zu einem Bruchteil der Kosten.

5. Bedeutung und Ansprüche

Die Arbeit behauptet, dass eine datenbankähnliche Planung bessere Qualitäts-Ressourcen-Trade-offs für Multi-LLM-QA liefert als eine dynamische, kurzsichtige Orchestrierung oder feste Ensembles.

• Paradigmenwechsel: Sie zeigt, dass die Behandlung der LLM-Orchestrierung als deklaratives Query-Planning-Problem statt als prozedurale Skriptaufgabe eine dynamische, fragenspezifische Anpassung ermöglicht, die den Nutzen unter Nebenbedingungen maximiert.
• Praktische Lebensfähigkeit: Die Ergebnisse legen nahe, dass eine strukturierte, statistikgetriebene Planung eine praktische Grundlage für adaptive LLM-Orchestrierung bietet, die es ermöglicht, Leistung und Effizienz zu balancieren, ohne auf teure, hochfähige kommerzielle APIs angewiesen zu sein.
• Zukünftiges Potenzial: Die Autoren postulieren, dass diese „Plan-vor-Ausführung“-Abstraktion über QA hinaus auf reichere Retrieval-Augmented Generation (RAG)- und Agenten-Workflows ausgeweitet werden kann, sofern neue Operatoren mit ähnlichen Kosten-Nutzen-Profilen im Statistik-Katalog charakterisiert werden können.