Ich baue derzeit eine automatisierte Forschungs-Ingestionspipeline mit n8n, um ein akademisches RAG-System (Retrieval-Augmented Generation) zu betreiben.
Das Workflow-Ziel:
Der Automatisierungs-Workflow wird ausgelöst, wenn ein neues Forschungsthema erfasst wird. Er ruft eine akademische Dateninfrastruktur-Engine namens ScholarAPI.net auf, um vollständige akademische Daten und hochdetaillierte Zitierungsmetadaten abzurufen. Sobald die JSON-Payload abgerufen ist, übermittelt n8n die Daten an einen Embedding-Knoten und schiebt sie in einen Vector Store.
Die Herausforderung:
Bei HTTP-Request-Knoten-Aufrufen an ScholarAPI.net kann die JSON-Antwort mit dem vollständigen Text mehrerer wissenschaftlicher Arbeiten recht umfangreich sein (manchmal mehrere Megabyte sauberer, strukturierter Text pro Batch).
Ich bin auf zwei spezifische architektonische Fragen gestoßen, um den Workflow optimiert zu halten:
Umgang mit Timeouts / Ausführungslimits: Bei großen Batches von vollständigen Textdaten könnte die vorgelagerte API-Verarbeitung einen Moment dauern. Was ist die Best Practice in n8n zum Einrichten von robusten Wiederholungsprofilen oder zum Verlängern von Timeouts auf dem HTTP-Request-Knoten, damit der Workflow nicht vorzeitig fehlschlägt?
Speicher-/Datensplitting: Das direkte Verarbeiten großer verschachtelter JSON-Payloads in einem einzigen Ausführungs-Thread verursacht hohen Speicherverbrauch. Sollte ich den „Item Lists
@Asgef_Sha für Timeouts hat der HTTP Request-Node ein Timeout-Feld unter Options – erhöh das für langsame Aufrufe und aktiviere Retry On Fail in den Settings mit Max Tries und Wait Between Tries. Achtung: Retry funktioniert nur, wenn On Error auf Stop Workflow gesetzt ist – wechsel das zu einer Continue-Option, sonst ignoriert n8n die Retry-Counts.
Für die Payloads, teile sie nicht manuell mit Item Lists oder einem Code-Node auf – n8n hat dafür einen Recursive Character Text Splitter-Node (Chunk Size + Chunk Overlap), den du in deinen Vector Store mit dem Default Data Loader einspeist. Split erst das papers-Array aus, damit jedes für sich durchläuft, statt das ganze Multi-MB-Blob in einer Ausführung zu halten.
Willkommen @Asgef_Sha! achamm’s Ratschlag zum Text Splitter ist genau richtig. Ein zusätzliches Muster für Multi-Paper-Batches: Nach dem Abrufen der HTTP-Antwort einen SplitInBatches-Knoten verwenden, um Papers in Gruppen von 5–10 auf einmal zu verarbeiten, dann jeden Batch durch den Text Splitter und die Vector Store Insertion leiten. Dies verhindert, dass eine einzelne große Payload während des Embedding im Speicher sitzt, was dazu führen kann, dass die Ausführung stehen bleibt, selbst wenn das Timeout verlängert wird. Es lohnt sich auch, das HTTP Request Timeout auf mindestens 120 Sekunden für ScholarAPI’s Volltext-Aufrufe zu setzen, da die serverseitige Aggregation bei großen Anfragen langsam sein kann.
Für diese Art von RAG-Ingestion würde ich das Ganze nicht in einer langen synchronen Ausführung behalten. Speichere die rohe ScholarAPI-Response zunächst, teile die Payload in verwaltbare Chunks auf und verarbeite/embedde sie dann in kleineren Schritten mit Wiederholungen und Checkpoints. Großes JSON plus lange HTTP-Aufrufe sind der Ort, wo langweilige Zuverlässigkeit einen cleveren All-in-One-Workflow schlägt. Bist du in der Lage, die rohe Response irgendwo zu speichern, bevor der Embedding-Schritt beginnt?
Gute Antworten oben bereits. Der Text Splitter plus Split Out plus SplitInBatches deckt das Chunking ab, und OMGItsDerek hat recht, dass man die Raw Response vor dem Embedding persistieren möchte. Ich würde auf diesen letzten Punkt aufbauen, denn bei dieser Art von Ingestion ist die Architektur wichtiger als irgendeine einzelne Node-Einstellung.
Ein paar Dinge, die mir bei großen Text-Ingestion-Pipelines geholfen haben:
Teilt es in zwei Workflows auf, nicht einen. Workflow A ruft einfach ScholarAPI auf und schreibt jedes Paper in eine Tabelle oder einen Object Store mit Status „fetched
Hi
Ich denke, ich verstehe, was du meinst — das Problem hier ist nicht nur Timeout oder Batching, sondern die Tatsache, dass n8n eine sehr große JSON-Payload innerhalb eines einzelnen Execution-Kontextes verarbeitet.
Bei Fällen wie ScholarAPI, die riesige strukturierte Texte zurückgeben, ist der eigentliche Engpass normalerweise der Execution Memory + Node-Verkettung, nicht nur HTTP-Limits.
Ich habe ähnliches Verhalten gesehen, bei dem Splitting oder „Async-ing
Zwei konkrete n8n-Einstellungen zur Behebung: Erstens im HTTP Request Node > Options > Timeout auf 300000 (5 Min.) setzen, damit der Aufruf bei großen Payloads nicht mitten in der Antwort abbricht. Zweitens, falls ScholarAPI ein Array von Papers zurückgibt, die Ausgabe durch einen Split In Batches Node mit Batch-Größe 1 vor dem Embedding-Schritt leiten – dadurch bleibt nur ein Paper im Ausführungskontext statt alle zusammen. Um den Memory Scope wie von @Bella123 vorgeschlagen vollständig zu isolieren, einen separaten Sub-Workflow über Execute Workflow für den Embed + Store Schritt aufrufen. So wird der Text jedes Papers nach der Rückgabe des Sub-Workflows garbage-collected, anstatt sich in der Parent Execution anzusammeln.
Ich würde das in Erfassung, Normalisierung und Embedding aufteilen, statt zu versuchen, einen großen Workflow alles auf einmal handhaben zu lassen.
Bei diesem ScholarAPI-→-RAG-Pfad ist das Risiko normalerweise nicht nur die lange HTTP-Anfrage. Das Problem ist, dass eine riesige Payload an mehreren verschiedenen Grenzen fehlschlagen kann:
fetch boundary
Der HTTP-Aufruf kann eine Zeitüberschreitung verursachen oder zu viele Daten zurückgeben, um sie bequem in einer Ausführung zu halten.
normalization boundary
Du musst entscheiden, was ein „Dokument
