Analyse-Pipeline für Feldversuche: von der Abfrage zum Dashboard

Jedes Auswertungsprojekt in der Feldversuchsanalyse wiederholt dieselben Schritte: Rohdaten aus einer Datenbank extrahieren, aufbereiten, visualisieren, statistisch auswerten. Um aus Versuchsdaten die Wirksamkeit eines Produkts zu bestimmen und Anwendungsempfehlungen abzuleiten, braucht es zwei Personen gleichzeitig – jemanden mit Fachwissen zur Kultur und zum Produkt und jemanden, der die Daten technisch beherrscht.

Genau das ist der Engpass. Der Fachbereich kann seine Frage nicht selbst beantworten, sondern muss sie in eine Warteschlange stellen. Und weil sich ein großer Teil der Arbeitsschritte über alle Auswertungen hinweg gleicht, wird derselbe Aufwand immer wieder erbracht.

Feldversuchsdaten aus mehreren Quellen gleichzeitig: verbundene relationale Datenbanksysteme wie SQLite, MySQL und PostgreSQL, ein Wissensgraph in Neo4j sowie verschiedene Webdienste.

Der auszuwertende Datensatz entsteht nicht als fester Export, sondern wird bei jeder Abfrage neu zusammengestellt – auf Basis von Filtern, die der Fachbereich selbst setzt: Erhebungstyp, Produktbestandteile, einzelne Versuche, Kulturen, Zeitraum. Dazu kommen Standortinformationen wie Wetter- und Bodendaten.

Die Werkzeugkette, nicht das Modell. Die größte Schwierigkeit lag darin, die verschiedenen Datenverarbeitungswerkzeuge zu einer funktionierenden Kette zu verbinden. Das erforderte Wissen über Datenspeicherung, Extraktion, Ladevorgänge und Analysetechniken gleichzeitig – jedes Glied für sich ist beherrschbar, die Verkettung ist die Arbeit.

Die Oberfläche als Projektrisiko. Das Werkzeug war von Anfang an für Anwender ohne technischen Hintergrund gedacht. Damit wird die Bedienbarkeit zur Erfolgsbedingung: Eine Pipeline, die fachlich korrekt rechnet, aber nicht ohne Anleitung bedienbar ist, wird nicht genutzt. Entsprechend gehörten Dokumentation und intuitive Führung zum Kern der Entwicklung, nicht zum Abschluss.

Extraktion und Aufbereitung automatisieren. Die Pipeline lädt die benötigten Daten selbstständig aus den angebundenen Datenbanken, dem Neo4j-Graphen und den Webdiensten und führt sie im R-Backend zusammen. Aufbereitung und Zusammenführung mit dplyr, tidyr und stringr; der resultierende Datensatz lässt sich als CSV herunterladen und weiterverwenden.

Räumlichen Kontext sichtbar machen. Über eine JavaScript-Bibliothek erzeugt das Werkzeug interaktive Karten der Versuchsstandorte samt zugehöriger Wetter-, Boden- und Metadaten. Durch Zoomen lassen sich einzelne Versuche auswählen und im Detail betrachten – bei Feldversuchen ist der Standort keine Nebeninformation, sondern häufig die Erklärung für abweichende Ergebnisse.

Modellieren und Einflüsse aufschlüsseln. Für die statistische Modellbildung kommen Random Forest und XGBoost zum Einsatz. Ausgegeben werden nicht nur Prognosen, sondern die Modellgüte über R², die Bedeutung der einzelnen Faktoren, deren jeweilige Wirkungsrichtung und die Stärke der Wechselwirkungen zwischen ihnen. Letzteres ist der fachlich interessanteste Teil: Welche Faktoren wirken nur gemeinsam?

Ergebnisse aus der Anwendung heraus verfügbar machen. Die Auswertung läuft im Webbrowser, Ergebnisse lassen sich als PDF oder DOCX speichern – damit landet ein Analyseergebnis ohne Zwischenschritt in einer Entscheidungsvorlage.

Das Werkzeug wurde erfolgreich implementiert und unterstützt Produktmanager in der operativen Arbeit. Es liefert einen unmittelbar zugänglichen Überblick über alle Studieninformationen zu einem Produkt und macht die entscheidenden Faktoren für eine erfolgreiche Anwendung und hohe Wirksamkeit sichtbar. Die Darstellung erfolgt in interaktiven Dashboards, und die Architektur erlaubt es, weitere Funktionen zu ergänzen, wenn sich die fachlichen Anforderungen ändern, ohne die bestehende Auswertung anzutasten.

Der eigentliche Effekt liegt jedoch in der Verlagerung: Auswertungen entstehen dort, wo die Fragen entstehen, statt in einer Warteschlange bei den Data Scientists.

Der Aufbau – heterogene Quellen automatisiert erschließen, filterbasiert einen Datensatz erzeugen, modellieren, Einflüsse aufschlüsseln, für Fachanwender bedienbar machen – trägt überall, wo Fachbereiche wiederkehrende Auswertungen brauchen und der Weg über eine Analyseabteilung zu langsam ist. In der pharmazeutischen Forschung ist das die Auswertung von Assay-Serien und präklinischen Studien.

Die Architektur würden wir heute stärker trennen. R Shiny bleibt für interne Fachanwendungen eine gute Wahl, aber Datenaufbereitung und Oberfläche gehören nicht in dieselbe Anwendung: Die Pipeline läuft in einem Orchestrator wie Dagster, die Transformationen in dbt, die Abfrageschicht über DuckDB. Bei der Modellierung sind Random Forest und XGBoost für Versuchsdaten dieser Größe weiterhin richtig, ergänzt um Foundation Models für tabellarische Daten bei kleineren Versuchsreihen. Die Wechselwirkungen zwischen Faktoren weisen wir heute über SHAP-Interaktionswerte aus statt über die eingebauten Wichtigkeitsmaße, die bei korrelierten Faktoren verzerren. Dazu Reproduzierbarkeit als Infrastruktur – containerisierte Umgebungen, fixierte Paketversionen, versionierte Datensätze – und als Ergänzung zu den Filtern eine Abfrage in natürlicher Sprache über den Versuchsdatenbestand.