MetaScreener: Multi-LLM-Ensemble für das Screening in systematischen Reviews

Welches Problem MetaScreener adressiert

Systematische Reviews beginnen mit einer Datenbanksuche, die je nach Fragestellung leicht mehrere tausend Titel liefern kann. Das Screening dieser Treffer auf Titel- und Abstract-Ebene ist der zeitaufwendigste manuelle Schritt im gesamten Review-Prozess, und er ist fehleranfällig, wenn Ermüdung einsetzt. MetaScreener setzt genau hier an: Es liest Trefferlisten aus PubMed, Scopus und ähnlichen Quellen ein und erzeugt für jeden Eintrag eine Include- oder Exclude-Entscheidung mit einem Konfidenzwert. Die Zielgruppe sind Review-Teams, die ihre Screening-Last reduzieren wollen, ohne die Nachvollziehbarkeit aufzugeben. Das Projekt beschreibt sich selbst als Open-Source-Multi-LLM-Ensemble und positioniert sich damit ausdrücklich nicht als Einzelmodell-Lösung. Der Anspruch ist, dass mehrere Modelle gemeinsam entscheiden, damit ein einzelnes Modell nicht zum Single Point of Failure wird.

Vier Schichten: von der Inferenz zur Entscheidung

Die Architektur folgt einer Hierarchical Consensus Network genannten Pipeline mit vier Schichten. In Schicht 1 laufen vier oder mehr LLMs parallel über die OpenRouter-API und bewerten jeden Treffer. Schicht 2 ist eine Regel-Engine mit harten Regeln, die sofort ausschließen, und weichen Regeln, die Punktabzüge vergeben. Schicht 3 kombiniert Calibrated Confidence Aggregation (CCA) und Element Consensus Scoring (ECS): CCA bildet rohe Modellwerte über Platt- oder Isotonic-Kalibrierung auf Wahrscheinlichkeiten ab, ECS bewertet die Übereinstimmung pro PICO-Element. Schicht 4 ist der Decision Router mit vier Stufen: Tier 0 für harte Regelausschlüsse, Tier 1 für automatische Entscheidungen bei hoher Konfidenz, Tier 2 für automatische Entscheidungen bei mittlerer Konfidenz und Tier 3 für Fälle, die an menschliche Prüfer weitergeleitet werden. Diese Aufteilung ist der interessanteste Teil des Designs, weil sie Unsicherheit nicht versteckt, sondern sichtbar in eine eigene Bearbeitungsspur leitet.

Installation und Konfiguration

Das Projekt bietet drei Wege. Über pip genügt `pip install metascreener`, danach startet `python -m metascreener` die Web-Oberfläche auf Port 8000. Alternativ gibt es ein Docker-Image: `docker pull chaokunhong/metascreener:latest` und anschließend `docker run -p 8000:8000 -e OPENROUTER_API_KEY="sk-or-v1-..." chaokunhong/metascreener`. Für Entwickler ist der Weg über den Quellcode vorgesehen, mit `uv sync --extra dev` und `python run.py`; dann läuft das FastAPI-Backend auf Port 8000 und der Vite-Dev-Server auf Port 5173. Voraussetzung ist in allen Varianten ein OpenRouter-API-Schlüssel, der entweder in der Settings-Seite der Weboberfläche oder als Umgebungsvariable `OPENROUTER_API_KEY` gesetzt wird. Python 3.11 oder neuer wird für die pip- und Quellcode-Variante verlangt, Node.js 18 oder neuer nur für den Quellcode-Weg mit dem Frontend. Der Workflow selbst ist in acht Schritte gegliedert, von der Kriteriengenerierung über Titel-Abstract- und Volltext-Screening bis zu Extraktion, Risk-of-Bias-Bewertung und Evaluation.

Modelle, Presets und Kostenrahmen

MetaScreener bindet laut README 15 Open-Source-LLMs über OpenRouter an, gegliedert in drei Fähigkeitsstufen. Zur Flagship-Stufe zählen DeepSeek V3, Qwen 3 und Kimi K2.5, zur Strong-Stufe unter anderem Llama 4 Maverick, GLM 5 und MiniMax M2.7, zur Lightweight-Stufe Gemma 3 27B, Mistral Small 4 und Phi 4. Drei Presets werden dokumentiert: Balanced mit vier Modellen zu etwa 0,005 US-Dollar pro Paper, Precision mit zwei Thinking- und zwei großen Modellen zu etwa 0,009 US-Dollar und Budget mit einem Anchor- plus drei schnellen Modellen zu etwa 0,003 US-Dollar. Diese Zahlen stammen aus der README und sind keine unabhängig geprüften Werte. Wer den Precision-Preset wählt, zahlt rund das Dreifache des Budget-Presets. Ob dieser Aufpreis die Entscheidungsqualität messbar verbessert, lässt sich aus den vorliegenden Materialien nicht ableiten, und genau das ist eine der Fragen, die ein Team vor dem Produktiveinsatz selbst klären muss.

Reproduzierbarkeit als Designentscheidung

Das Projekt setzt auf `temperature=0.0` und `seed=42` und führt einen Audit-Trail über jede Entscheidung. Das ist ein bewusster Kontrast zu vielen LLM-Anwendungen, bei denen Sampling-Parameter offen bleiben und Ergebnisse zwischen Läufen schwanken. Für systematische Reviews ist das relevant, weil PRISMA-Berichte verlangen, dass der Screening-Prozess nachvollziehbar ist. Die Kalibrierungsschicht ist der zweite Teil dieser Strategie: Rohe Modellwahrscheinlichkeiten sind typischerweise nicht kalibriert, das heißt, ein Modell, das 0,9 ausgibt, liegt nicht zwangsläufig in 90 Prozent der Fälle richtig. Platt- und Isotonic-Kalibrierung sollen diese Lücke schließen. Ob das auf einem konkreten Datensatz gelingt, hängt von der Kalibrierungsgrundlage ab, und dazu macht das README keine Angaben. Wer den Audit-Trail für einen Review-Bericht nutzen will, sollte die Evaluation-Seite im Web-UI als Quelle verwenden, nicht die Rohausgaben der Modelle.

Grenzen und Fälle, in denen MetaScreener das falsche Werkzeug ist

Die wichtigste Einschränkung steht implizit in der Architektur selbst: Tier 3 leitet unsichere Fälle an menschliche Prüfer weiter. Das bedeutet, dass MetaScreener die Screening-Last reduziert, sie aber nicht eliminiert. Wer hofft, den manuellen Schritt vollständig zu ersetzen, wird enttäuscht. Ein zweiter Punkt betrifft die Abhängigkeit von OpenRouter: Ohne API-Schlüssel und Internetverbindung läuft nichts, und die Kosten skalieren mit der Zahl der Treffer multipliziert mit der Zahl der Modelle im Ensemble. Ein Review mit 10.000 Treffern und dem Precision-Preset landet rechnerisch bei etwa 90 US-Dollar, wenn man die README-Angabe zugrunde legt. Drittens: Die Kalibrierung ist domänenabhängig. Ein Ensemble, das auf medizinischen Abstracts kalibriert wurde, überträgt sich nicht ohne Weiteres auf sozialwissenschaftliche oder technische Literatur. Und schließlich ist die Volltextverarbeitung von PDFs ein eigener Verarbeitungsschritt mit Chunking, dessen Qualität das Screening-Ergebnis beeinflusst. Wer PDFs mit komplexen Tabellen oder mehrspaltigem Layout screenen will, sollte die Volltext-Ergebnisse stichprobenartig gegen das Original prüfen, bevor er sich auf die Tier-1-Entscheidungen verlässt.

Alternative: einzelnes Modell mit manueller Nachkontrolle

Die naheliegende Alternative ist ein einzelnes LLM mit einem einfachen Prompt und manueller Nachkontrolle aller Entscheidungen. Der Unterschied liegt nicht in der Genauigkeit eines einzelnen Modells, sondern in der Fehlerstruktur: Ein Einzelmodell hat einen systematischen Bias, der bei jedem Treffer gleich wirkt. Ein Ensemble aus vier Modellen mit unterschiedlichem Training und unterschiedlichen Anbietern streut diesen Bias, und die Element-Consensus-Bewertung macht sichtbar, wo Modelle uneinig sind. Der Preis dafür ist der vierfache API-Aufwand und eine komplexere Pipeline. Wer nur eine kleine Review mit wenigen hundert Treffern durchführt, fährt mit einem einzelnen Modell und manueller Prüfung oft günstiger und schneller. Wer dagegen regelmäßig große Trefferlisten verarbeitet und die Entscheidungen dokumentieren muss, profitiert von der Struktur, die MetaScreener vorgibt. Der Vergleich mit kommerziellen Screening-Werkzeugen wie Rayyan oder Covidence ist ebenfalls relevant, aber anders gelagert: Diese bieten kollaboratives Screening durch mehrere menschliche Reviewer mit Konfliktlösung, während MetaScreener den ersten Durchgang automatisiert und die menschliche Prüfung auf unsichere Fälle konzentriert.

Wartung, Lizenz und Aktualisierungsaufwand

Das Repository steht unter Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben. Der letzte Push liegt laut Repository-Metadaten bei Juni 2026, die letzten Releases sind ein FP-Audit-Protokoll von Mai 2026 und zwei Alpha-Versionen von Februar 2026. Die Versionsnummer v2.0.0a4 zeigt, dass sich das Projekt in einer Alpha-Phase befindet, was für den Produktiveinsatz ein Risiko darstellt: Schnittstellen und Konfigurationsschlüssel können sich zwischen Alpha-Releases ändern. Wer MetaScreener in einen laufenden Review integriert, sollte die Version pinnen und vor jedem Upgrade die Release Notes prüfen. Die Abhängigkeit von OpenRouter bedeutet zusätzlich, dass sich die verfügbaren Modelle und deren Preise unabhängig vom Projekt ändern können. Ein Modell, das heute im Balanced-Preset steckt, kann morgen aus dem Katalog verschwinden. Das ist kein Fehler des Projekts, aber ein Betriebsrisiko, das Teams einplanen müssen. Ob der Autor das Projekt langfristig pflegt, lässt sich aus den vorliegenden Angaben nicht beurteilen; dafür wäre ein Blick auf die Commit-Historie und die Reaktion auf Issues nötig, die hier nicht vorliegen.

Redaktionelles Fazit

MetaScreener ist ein sinnvolles Werkzeug für Teams, die große Trefferlisten aus PubMed, Scopus oder anderen Datenbanken vorsortieren müssen und dabei nachvollziehbare, kalibrierte Entscheidungen mit Audit-Trail benötigen. Wer eine einzelne, kleine Review mit wenigen Dutzend Treffern durchführt, oder wer die Screening-Entscheidung vollständig ohne menschliche Nachkontrolle automatisieren will, sollte auf ein anderes Vorgehen setzen. Vor dem produktiven Einsatz ist zu prüfen, wie die Kalibrierung auf die eigene Fachdomäne übertragen wird, welche Presets konkret verwendet werden und ob die Tier-Schwellen auf die eigene Fehlertoleranz passen. Ein erster belastbarer Schritt ist der Export der Screening-Ergebnisse aus der Evaluation-Seite und der Abgleich mit einem manuell gescreenten Referenzsatz.

Offizielle Quellen

1. ChaokunHong/MetaScreener on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases