systematic-literature-review

Fähigkeit zur systematischen Literaturübersicht

Übersicht

Diese Fähigkeit erstellt eine strukturierte systematische Literaturübersicht (SLR) über mehrere akademische Arbeiten zu einem Forschungsthema. Bei einer Themenabfrage durchsucht sie arXiv, extrahiert parallel strukturierte Metadaten (Forschungsfrage, Methodik, wichtigste Ergebnisse, Einschränkungen) aus jeder Arbeit, synthetisiert thematische Muster über die gesamte Sammlung und erstellt einen abschließenden Bericht mit konsistenten Zitaten.

Abgrenzung zu academic-paper-review: Diese Fähigkeit führt eine tiefgehende Peer-Review einer einzelnen Arbeit durch. Diese Fähigkeit hingegen führt eine breit angelegte Synthese über viele Arbeiten durch. Wenn der Benutzer eine einzelne Paper-URL angibt und um eine Überprüfung bittet, leiten Sie die Anfrage an academic-paper-review weiter.

Wann Sie diese Fähigkeit verwenden sollten

Verwenden Sie diese Fähigkeit, wenn der Benutzer einen der folgenden Punkte wünscht:

• Eine Literaturübersicht zu einem Thema („Untersuchen Sie Transformer-Aufmerksamkeitsvarianten“, „Überprüfen Sie die Literatur zu Diffusionsmodellen“)
• Eine Synthese über mehrere Arbeiten („Was sagen aktuelle Arbeiten zu X?“, „Vergleichen Sie Methodiken in Arbeiten zu Y“)
• Eine systematische Übersicht mit konsistentem Zitierformat („Erstellen Sie eine SLR zu Z im APA-Format“)
• Eine kommentierte Bibliografie zu einem Thema
• Einen Überblick über Forschungstrends in einem Bereich über einen bestimmten Zeitraum

Verwenden Sie diese Fähigkeit nicht, wenn:

• Der Benutzer genau eine Arbeit angibt und um eine Überprüfung bittet (verwenden Sie academic-paper-review)
• Der Benutzer eine sachliche Frage stellt, die keine Synthese mehrerer Quellen erfordert (antworten Sie direkt)
• Der Benutzer eine allgemeine Websuche ohne akademische Strenge wünscht (verwenden Sie die Standard-Websuche)

Arbeitsablauf

Der Arbeitsablauf besteht aus fünf Phasen. Führen Sie diese in der angegebenen Reihenfolge aus.

Phase 1: Planung

Bevor Sie eine Abfrage durchführen, klären Sie Folgendes mit dem Benutzer. Wenn etwas unklar ist, stellen Sie eine klärende Frage, die die fehlenden Teile abdeckt. Fragen Sie nicht einzeln nacheinander.

• Thema: Das Forschungsgebiet in klarem Englisch (z. B. „Transformer-Aufmerksamkeitsvarianten“).
• Umfang: Anzahl der Arbeiten (Standard 20, harte Obergrenze 50), optionaler Zeitraum (z. B. „letzte 2 Jahre“), optionale arXiv-Kategorie (z. B. cs.CL, cs.CV).
• Zitierformat: APA, IEEE oder BibTeX (Standard APA, wenn der Benutzer kein Format angibt und nicht für eine bestimmte Publikation zu schreiben scheint).
• Ausgabeort: Wo der endgültige Bericht gespeichert werden soll (Standard /mnt/user-data/outputs/).

Wenn der Benutzer „50+ Arbeiten“ sagt, begrenzen Sie es höflich auf 50 und erklären Sie, dass die Synthesequalität danach schnell abnimmt – für größere Übersichten sollte der Benutzer das Thema in Unterthemen aufteilen.

Phase 2: arXiv durchsuchen

Rufen Sie das mitgelieferte Suchskript auf. Versuchen Sie nicht, arXiv auf andere Weise zu durchsuchen, und schreiben Sie keinen eigenen HTTP-Client – dieses Skript übernimmt URL-Kodierung, Atom-XML-Parsing und ID-Normalisierung korrekt.

python /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \
  "<Thema>" \
  --max-results <N> \
  [--category <cat>] \
  [--sort-by relevance] \
  [--start-date YYYY-MM-DD] \
  [--end-date YYYY-MM-DD]

WICHTIG – Extrahieren Sie 2-3 Kern-Schlüsselwörter vor der Suche. Übergeben Sie nicht die gesamte Themenbeschreibung des Benutzers als Suchanfrage. Reduzieren Sie das Thema gedanklich auf die 2-3 wesentlichsten Begriffe. Lassen Sie Qualifikatoren wie „in der Computer Vision“, „für NLP“, „Varianten“, „aktuell“ weg – diese gehören in --category oder --start-date, nicht in die Suchzeichenfolge.

Formulierung der Suchanfrage – halten Sie sie kurz. Das Skript setzt Suchanfragen mit mehreren Wörtern für die Phrasensuche auf arXiv in doppelte Anführungszeichen. Das bedeutet:

• "Diffusionsmodelle" → sucht nach der exakten Phrase → gut, liefert relevante Arbeiten.
• "Diffusionsmodelle in der Computer Vision" → sucht nach dieser exakten 5-Wort-Phrase → zu spezifisch, liefert wahrscheinlich 0 Ergebnisse, da nur wenige Arbeiten diese exakte Zeichenfolge enthalten.

Verwenden Sie 2-3 Kern-Schlüsselwörter als Suchanfrage und verwenden Sie --category, um das Feld einzugrenzen, anstatt Feldnamen in die Suchanfrage zu stopfen. Beispiele:

Benutzer sagt	Gute Suchanfrage	Schlechte Suchanfrage
„Diffusionsmodelle in der Computer Vision"	"Diffusionsmodelle" --category cs.CV	"Diffusionsmodelle in der Computer Vision"
„Transformer-Aufmerksamkeitsvarianten"	"Transformer-Aufmerksamkeit"	"Transformer-Aufmerksamkeitsvarianten in NLP"
„Graph Neuronale Netze für Moleküle"	"Graph Neuronale Netze" --category cs.LG	"Graph Neuronale Netze für molekulare Eigenschaftsvorhersage"

Das Skript gibt ein JSON-Array an die Standardausgabe aus. Jede Arbeit hat: id, title, authors, abstract, published, updated, categories, pdf_url, abs_url.

Sortierstrategie:

• Verwenden Sie immer die Sortierung nach relevance – arXivs BM25-ähnliche Bewertung stellt sicher, dass die Ergebnisse tatsächlich für das Thema des Benutzers relevant sind. Die Sortierung nach submittedDate gibt die zuletzt eingereichten Arbeiten in der Kategorie zurück, unabhängig von der Themenrelevanz, was meist zu unpassenden Ergebnissen führt.
• Wenn der Benutzer nach „aktuellen“ Arbeiten fragt oder einen Zeitraum angibt, verwenden Sie --sort-by relevance kombiniert mit --start-date, um den Zeitraum einzuschränken und die Ergebnisse dennoch themenrelevant zu halten. Zum Beispiel: „aktuelle Diffusionsmodell-Arbeiten“ → --sort-by relevance --start-date 2024-01-01, nicht --sort-by submittedDate.
• Die Sortierung nach submittedDate ist nur dann angemessen, wenn der Benutzer explizit nach chronologischer Reihenfolge fragt (z. B. „Zeigen Sie mir die Arbeiten in der Reihenfolge ihrer Veröffentlichung“). Dies ist selten.
• lastUpdatedDate ist selten nützlich; ignorieren Sie es, es sei denn, der Benutzer fragt danach.

Führen Sie die Suche genau einmal aus. Wiederholen Sie die Suche nicht mit geänderten Suchanfragen, wenn die Ergebnisse unvollkommen erscheinen – arXivs Relevanzranking ist, wie es ist. Wiederholungen mit anderen Formulierungen verschwenden Tool-Aufrufe und riskieren das Erreichen des Rekursionslimits. Wenn die Ergebnisse wirklich leer sind (0 Arbeiten), teilen Sie dies dem Benutzer mit und schlagen Sie vor, das Thema zu erweitern oder den Kategoriefilter zu entfernen.

Wenn das Skript weniger Arbeiten als angefordert zurückgibt, ist dies die tatsächliche Größe der arXiv-Ergebnismenge für die Suchanfrage. Füllen Sie die Liste nicht auf – melden Sie dem Benutzer die tatsächliche Anzahl und fahren Sie fort.

Wenn das Skript fehlschlägt (Netzwerkfehler, Nicht-200 von arXiv), teilen Sie dem Benutzer den Fehler mit und brechen Sie ab. Versuchen Sie nicht, Paper-Metadaten zu erfinden.

Speichern Sie die Suchergebnisse nicht in einer Datei – das JSON bleibt für Phase 3 in Ihrem Kontext. Die einzige Datei, die während des gesamten Arbeitsablaufs gespeichert wird, ist der endgültige Bericht in Phase 5.

Phase 3: Metadaten parallel extrahieren

Sie MÜSSEN die Extraktion an Unteragenten über das task-Tool delegieren – extrahieren Sie die Metadaten nicht selbst. Dies ist nicht verhandelbar. Tun Sie insbesondere NICHT Folgendes:

• ❌ Schreiben Sie python -c "papers = [...]" oder ein Python/Bash-Skript, um Arbeiten zu verarbeiten
• ❌ Extrahieren Sie Metadaten inline in Ihrem eigenen Kontext, indem Sie Abstracts nacheinander lesen
• ❌ Verwenden Sie für diese Phase ein anderes Tool als task

Stattdessen MÜSSEN Sie das task-Tool aufrufen, um Unteragenten zu starten. Der Grund: Das Extrahieren von 10-50 Arbeiten in Ihrem eigenen Kontext verbraucht zu viele Token und beeinträchtigt die Synthesequalität in Phase 4. Jeder Unteragent läuft in einem isolierten Kontext mit nur seiner Batch von Arbeiten und erzeugt sauberere Extraktionen.

Teilen Sie die Arbeiten in Batches von etwa 5 auf. Rufen Sie dann für jeden Batch das task-Tool mit subagent_type: "general-purpose" auf. Jeder Unteragent erhält die Paper-Abstracts als Text und gibt strukturiertes JSON zurück.

Gleichzeitigkeitsgrenze: maximal 3 Unteragenten pro Runde. Die DeerFlow-Laufzeitumgebung erzwingt MAX_CONCURRENT_SUBAGENTS = 3 und verwirft stillschweigend alle zusätzlichen Sendungen in derselben Runde – dem LLM wird nicht mitgeteilt, dass dies passiert ist. Befolgen Sie daher strikt die Rundenstrategie unten.

Rundenstrategie – verwenden Sie diese Entscheidungstabelle, berechnen Sie die Aufteilung nicht selbst:

Anzahl der Arbeiten	Batches von ~5 Arbeiten	Runden	Unteragenten pro Runde
1–5	1 Batch	1 Runde	1 Unteragent
6–10	2 Batches	1 Runde	2 Unteragenten
11–15	3 Batches	1 Runde	3 Unteragenten
16–20	4 Batches	2 Runden	3 + 1
21–25	5 Batches	2 Runden	3 + 2
26–30	6 Batches	2 Runden	3 + 3
31–35	7 Batches	3 Runden	3 + 3 + 1
36–40	8 Batches	3 Runden	3 + 3 + 2
41–45	9 Batches	3 Runden	3 + 3 + 3
46–50	10 Batches	4 Runden	3 + 3 + 3 + 1

Senden Sie niemals mehr als 3 Unteragenten in derselben Runde. Wenn eine Zeile „2 Runden (3 + 1)“ sagt, bedeutet das: In der ersten Runde werden 3 Unteragenten parallel gesendet, warten Sie, bis alle 3 abgeschlossen sind, dann sendet die zweite Runde 1 Unteragenten. Runden sind auf Hauptagentenebene streng sequentiell.

Wenn die Anzahl der Arbeiten zwischen den Zeilen liegt (z. B. 23 Arbeiten), runden Sie auf das Layout der nächsten Zeile auf, senden Sie aber nur so viele Batches, wie Sie tatsächlich benötigen – die Entscheidungstabelle gibt Ihnen die Struktur, keine starre Vorschrift.

Führen Sie die Batch-Erstellung auf Hauptagentenebene durch: Sie haben bereits die Abstracts jeder Arbeit aus Phase 2, sodass jeder Unteragent reinen Texteingang erhält. Unteragenten sollten nicht auf das Netzwerk oder die Sandbox zugreifen müssen – ihre einzige Aufgabe ist es, Text zu lesen und JSON zurückzugeben. Bitten Sie Unteragenten nicht, arxiv_search.py erneut auszuführen; das würde Token verschwenden und das Risiko einer Ratenbegrenzung erhöhen.

Was jeder Unteragent erhält, als strukturierte Aufforderung:

Führen Sie diese Aufgabe aus: Extrahieren Sie strukturierte Metadaten und wichtigste Ergebnisse aus den folgenden arXiv-Papieren.

Papiere:
[Paper 1]
arxiv_id: 1706.03762
title: Attention Is All You Need
authors: Ashish Vaswani, Noam Shazeer, ...
published: 2017-06-12
abstract: <vollständiger Abstract-Text>

[Paper 2]
arxiv_id: ...
...

Geben Sie für jedes Papier ein JSON-Objekt mit den folgenden Feldern zurück:
- arxiv_id (String)
- title (String)
- authors (Liste von Strings)
- published_date (String, YYYY-MM-DD)
- research_question (1 Satz, welches Problem das Papier angeht)
- methodology (1-2 Sätze, wie sie es angehen)
- key_findings (3-5 Aufzählungspunkte, was sie tatsächlich gefunden haben)
- limitations (1-2 Sätze, was sie anerkennen oder was offensichtlich fehlt)

Geben Sie das Ergebnis als JSON-Array zurück, ein Objekt pro Papier, in derselben Reihenfolge wie die Eingabe. Fügen Sie keinen Text außerhalb des JSON hinzu – keine Einleitung, keine Markdown-Begrenzungen, nur das Array.

Parsing der Unteragentergebnisse: Das task-Tool gibt Zeichenfolgen mit einem festen Präfix wie Task Succeeded. Result: [...JSON...] zurück. Entfernen Sie das Präfix Task Succeeded. Result: (oder die Präfixe Task failed. / Task timed out.), bevor Sie versuchen, JSON zu parsen. Wenn ein Batch fehlschlägt oder unparsbares JSON zurückgibt, protokollieren Sie dies, notieren Sie, welche Arbeiten betroffen waren, und fahren Sie mit den restlichen Batches fort – brechen Sie die gesamte Synthese nicht wegen eines schlechten Batches ab.

Nach Abschluss aller Runden glätten Sie die Arrays pro Batch zu einer einzigen Liste von Paper-Metadatenobjekten, wobei die Reihenfolge erhalten bleibt.

Phase 4: Synthetisieren und formatieren

Erstellen Sie nun den endgültigen SLR-Bericht. Zwei Dinge passieren hier: die übergreifende Synthese (themenspezifische Analyse) und die Zitierformatierung.

Übergreifende Synthese: Der Bericht muss mehr tun, als nur Arbeiten aufzulisten. Identifizieren Sie mindestens:

• Themen: 3-6 wiederkehrende Forschungsrichtungen, Ansätze oder Problemframings in der Sammlung.
• Übereinstimmungen: Ergebnisse, auf die sich mehrere Arbeiten einigen.
• Meinungsverschiedenheiten: Wo Arbeiten zu unterschiedlichen Schlussfolgerungen kommen oder inkompatible Methodiken verwenden.
• Lücken: Was die kollektive Literatur noch nicht adressiert (oft explizit in den Feldern „Einschränkungen“ angegeben).

Wenn die Papiersammlung zu klein oder zu heterogen für eine thematische Synthese ist (z. B. 5 Arbeiten zu völlig unterschiedlichen Unterthemen), sagen Sie dies explizit im Bericht – erzwingen Sie keine Themen, die nicht vorhanden sind.

Zitierformatierung: Das genaue Format hängt von der Benutzerpräferenz ab. Lesen Sie nur die Vorlagendatei, die dem vom Benutzer angeforderten Format entspricht, nicht alle drei:

• templates/apa.md – APA 7. Auflage. Standard für Sozialwissenschaften und die meisten CS-Journale. Verwenden Sie diese, wenn der Benutzer APA anfordert oder kein Format angibt.
• templates/ieee.md – IEEE-numerische Zitate. Verwenden Sie diese, wenn der Benutzer eine IEEE-Konferenz oder ein IEEE-Journal anstrebt oder explizit nach IEEE fragt.
• templates/bibtex.md – BibTeX-Einträge. Verwenden Sie diese, wenn der Benutzer BibTeX, LaTeX oder maschinenlesbare Referenzen erwähnt. Wichtig: arXiv-Papiere werden als @misc, nicht als @article zitiert – die BibTeX-Vorlage behandelt dies explizit.

Jede Vorlage enthält sowohl die Zitierregeln als auch eine vollständige Berichtsstruktur (Executive Summary, Themen, Anmerkungen pro Papier, Referenzen, Methodikabschnitt). Befolgen Sie die Struktur der Vorlage wörtlich für den Berichtskörper und füllen Sie dann den Inhalt aus Ihren Metadaten aus Phase 3 ein.

Phase 5: Speichern und präsentieren

Speichern Sie den vollständigen Bericht unter /mnt/user-data/outputs/slr-<Thema-Slug>-<YYYYMMDD>.md, wobei <Thema-Slug> eine kleingeschriebene, mit Bindestrichen versehene Version des Themas ist (z. B. transformer-attention). Rufen Sie dann das Tool present_files mit diesem Pfad auf, damit der Benutzer die Datei herunterladen kann.

Zeigen Sie in der Chat-Nachricht eine kurze Vorschau an, damit der Benutzer sofort den Wert erkennt, ohne die Datei öffnen zu müssen:

1. Executive Summary – der 3-5 Sätze umfassende Absatz vom Anfang des Berichts, wörtlich.
2. Liste der Themen – Aufzählungsliste der Themen, die Sie in der Synthese von Phase 4 identifiziert haben (nur die Themennamen + einzeilige Erläuterung, nicht die vollständigen Themenabschnitte).
3. Anzahl der Arbeiten + ein Hinweis auf die Datei – z. B. „Vollständiger Bericht mit 20 Arbeiten, Anmerkungen pro Papier und formatierten Referenzen, gespeichert unter slr-transformer-attention-20260409.md.“

Geben Sie nicht den vollständigen 2000+ Wörter umfassenden Bericht inline aus – Anmerkungen pro Papier, Referenzen und Methodik gehören in die Datei. Die Vorschau dient dazu, dem Benutzer einen schnellen Überblick über den Bericht zu geben und zu entscheiden, ob er ihn öffnen möchte.

Beispiele

Beispiel 1: Typische SLR-Anfrage

Benutzer: „Erstellen Sie eine systematische Literaturübersicht zu aktuellen Transformer-Aufmerksamkeitsvarianten, 20 Arbeiten, APA-Format.“

Ihr Ablauf:

1. Phase 1: Bestätigen Sie das Thema (Transformer-Aufmerksamkeitsvarianten), den Umfang (20 Arbeiten, Standardzeitfenster) und das Format (APA). Stellen Sie eine klärende Frage nur, wenn etwas fehlt (z. B. „Ein bestimmter Zeitraum, oder soll ich standardmäßig die letzten 3 Jahre verwenden?“).
2. Phase 2: arxiv_search.py "Transformer-Aufmerksamkeit" --max-results 20 --sort-by relevance --start-date 2023-01-01.
3. Phase 3: 20 Arbeiten → Runde 1 = 3 Unteragenten × 5 Arbeiten = 15 abgedeckt, Runde 2 = 1 Unteragent × 5 Arbeiten = 5 abgedeckt.

...

[gekürzt für die Übersetzung]