DSPy und GEPA Trial

Überblick

DSPy behandelt LLM-Pipelines als optimierbare Programme mit Signatures, Modulen und Telepromptern statt handgetunten Prompt-Strings. GEPA und verwandte Optimizer suchen über Prompts und Demonstrations mit Task-Metriken (DSPy). GEPA (Genetic-Pareto) reflektiert in natürlicher Sprache über Ausführungs-Traces, schlägt neue Instruktionen vor und hält eine Pareto-Front von Kandidaten; es ist als dspy.GEPA und als eigenständiges Paket gepa verfügbar (GEPA-Paper).

Trial, wenn Prompt-Iteration ein Engpass ist und gelabelte Eval-Sets existieren. Black-Box-Optimierung ohne menschliches Review der finalen Prompts und Failure Cases ist zu vermeiden.

Adoptionssignale

  • Das GEPA-Paper wurde als Oral auf der ICLR 2026 angenommen; es berichtet, dass GEPA GRPO im Schnitt um 6 % und um bis zu 20 % übertrifft, bei bis zu 35-mal weniger Rollouts, und MIPROv2 um mehr als 10 % schlägt (GEPA-Paper).
  • Databricks berichtet, dass ein GEPA-optimiertes gpt-oss-120b auf der Extraktions-Suite IE Bench die Baselines von Claude Opus 4.1 und Claude Sonnet 4 übertroffen hat und dabei 90- bzw. 22-mal günstiger im Serving war (Databricks-Blog).
  • GEPA ist in andere Plattformen eingebaut: mlflow.genai.optimize_prompts() bietet es ab MLflow 3.5 als einen von zwei Optimizern an (MLflow Prompt Optimization), und der Google-Befehl adk optimize nutzt GEPA, um Agent-Instruktionen zu verfeinern (ADK Agent Optimization).
  • Nubank setzt laut seinem Paper zu Kundenservice-Agents bei 100 Mio. Nutzern GEPA-Optimierung ein, um die LLM-as-Judge-Bewertung konsistenter zu machen (Nubank-Paper).
  • DSPy hat rund 38.000 GitHub-Sterne und eine MIT-Lizenz (DSPy auf GitHub) sowie etwa 5,2 Mio. PyPI-Downloads in den 30 Tagen bis zum 30. September 2026 (PyPI Stats); das eigenständige GEPA-Repository hat rund 6.800 Sterne (GEPA auf GitHub).

Risiken

  • Overfitting auf die Metrik. GEPA optimiert, was die Metrik belohnt; ohne separates Validation-Set verwendet GEPA das Trainingsset doppelt, und DSPy warnt im Log, dass die Prompts dadurch auf das Trainingsset überangepasst werden (dspy.GEPA Quellcode), und eine schwache Metrik führt zu Prompts, die sie ausnutzen.
  • Optimierungskosten. Jeder Lauf braucht ein Budget (auto, max_full_evals oder max_metric_calls) und ein starkes Reflection-Modell (dspy.GEPA Docs); Databricks weist darauf hin, dass die berichteten Einsparungen nur das Serving betreffen und GEPA-Läufe 2 bis 3 Stunden dauerten (Databricks-Blog).
  • An ein Modell gebundene Prompts. Ein optimierter Prompt ist auf das Task-Modell abgestimmt, gegen das optimiert wurde; ein Modell-Upgrade oder Providerwechsel erfordert neue Optimierung und erneute Validierung.
  • Framework-Churn. DSPy 3.4 bezeichnet sich als LM-Übergangsrelease, mit 3.5 als Migrationsfrist für Legacy-Custom-LM-Integrationen (DSPy 3.4.0 Release Notes).
  • Schwer prüfbare Ergebnisse. Evolvierte Instruktionen können lang und schwer lesbar sein, was Compliance-Review und Change-Freigabe gegenüber handgeschriebenen Prompts erschwert.

Vorteile & Nachteile

Vorteile

  • Hinter GEPA steht begutachtete Evidenz: Das ICLR-2026-Oral-Paper berichtet im Schnitt 6 % Vorsprung vor GRPO bei bis zu 35-mal weniger Rollouts und mehr als 10 % Vorsprung vor dem Prompt-Optimizer MIPROv2.
  • Optimierte Prompts können kleinere oder Open-Weight-Modelle für eine feste Aufgabe auf das Niveau größerer Modelle heben; Databricks berichtet, dass ein GEPA-optimiertes gpt-oss-120b auf seinem Extraktions-Benchmark die Baseline von Claude Opus 4.1 bei rund 90-mal geringeren Serving-Kosten übertrifft.
  • GEPA ist nicht mehr an DSPy gebunden: Es steckt in dspy.GEPA, in der optimize_prompts-API von MLflow und hinter dem Befehl adk optimize von Google ADK, sodass dieselbe Methode in mehreren Stacks nutzbar ist.

Nachteile

  • Die Optimierung ist nur so gut wie Metrik und Eval-Set; ohne separates Validation-Set warnt DSPy, dass GEPA die Prompts auf die Trainingsbeispiele überanpasst.
  • Optimierungsläufe sind selbst teuer und langsam, weil jede Iteration das Task-Modell und ein starkes Reflection-Modell aufruft; Databricks hat auf seinem Benchmark etwa 2 bis 3 Stunden pro GEPA-Lauf gemessen.
  • Die DSPy-APIs ändern sich weiter: Release 3.4 (September 2026) markiert Legacy-Custom-LM-Integrationen als deprecated und nennt 3.5 als Migrationsfrist.

Empfehlung

DSPy mit GEPA eignet sich für einen Trial bei Aufgaben, für die bereits eine messbare Definition guter Ergebnisse existiert, etwa Extraktion, Klassifikation, Routing oder LLM-as-Judge-Prompts, und für die mindestens einige hundert gelabelte Beispiele in Trainings- und Validation-Set aufgeteilt vorliegen. Der Optimizer ist wie ein Build-Schritt zu behandeln: Eval-Set, Metrik und resultierender Prompt werden gemeinsam versioniert, das Budget für Metrik-Aufrufe wird begrenzt, und eine Person prüft den finalen Prompt und seine Failure Cases vor dem Rollout.

Für offene Textgenerierung ohne verlässliche Metrik oder für Teams, die noch keine Evals in CI betreiben, lohnt sich die Einführung nicht. Teams, die bereits MLflow oder Google ADK nutzen, können GEPA zunächst über diese Integrationen testen, bevor sie das Programmiermodell von DSPy übernehmen. Die DSPy-Version sollte gepinnt, die Migration auf die LM-Schnittstelle von 3.5 eingeplant und die Optimierung bei jedem Modellwechsel wiederholt werden.

Quellen