Hybrid-RAG für Arbeitssicherheit mit n8n: Was funktioniert — und was nicht

TL;DR. Hybrid-Retrieval (Volltext + Vektor + Cross-Encoder) in Kombination mit n8n als Workflow-Orchestrator macht Arbeitssicherheits-Assistenten erst praxistauglich. Aber n8n verlangt ein eigenes Denken — kein Programmieren im klassischen Sinne, sondern Orchestrierung. Schwächen gibt es trotzdem: JavaScript-Python-Impedanz, schwieriges Debugging komplexer Chains, und Versions-Migrationen, die Überraschungen bringen, auf die man vorher nicht vorbereitet war. Ein ehrlicher Erfahrungsbericht.

Ein Sicherheitsbeauftragter steht auf dem Gerüst und braucht sofort eine Antwort: Welche Absturzsicherung ist für Arbeiten ab drei Metern Höhe bei nassem Untergrund vorgeschrieben? Er hat sein Telefon. Er hat Telegram. Die eigentliche Norm liegt irgendwo auf einem SharePoint-Server, in einem 340-seitigen PDF, das zuletzt 2021 jemand hochgeladen hat, und die Suchfunktion des SharePoint kennt den Begriff nicht, den er gerade eingetippt hat.

Zehn Minuten später hat er die Antwort. Nicht weil er den richtigen Suchbegriff gefunden hat — sondern weil er aufgehört hat zu suchen und einfach gefragt hat.

Genau das haben wir gebaut. Und es war nicht so einfach, wie sich dieser eine Satz liest.

Das Problem mit Dokumenten, die niemand findet

Das eigentliche Problem bei Arbeitssicherheits-Dokumenten ist nicht, dass sie fehlen. Fast jeder Industriebetrieb hat seine Vorschriften, seine internen Betriebsanweisungen, seine Gefährdungsbeurteilungen — ordentlich abgelegt, regelmäßig aktualisiert, als PDFs irgendwo auf einem Netzlaufwerk.

Das Problem ist der Abstand zwischen dem Dokument und der Frage.

Klassische Volltextsuche findet "Absturzsicherung", wenn jemand "Absturzsicherung" tippt. Sie findet es nicht, wenn jemand "Sicherung beim Gerüstbau" fragt — obwohl beide Begriffe dieselbe Sache meinen. Und ein Sprachmodell, das man ohne Dokumentanbindung loslässt, erfindet Normparagraphen, die so ähnlich existieren könnten, aber im Zweifelsfall eben nicht so stehen. Ein Assistent, dem man bei Sicherheitsvorschriften nicht vertrauen kann, wird nicht benutzt. Und ein Assistent, den man nicht benutzt, rettet keine Zeit — und im schlimmsten Fall auch niemanden.

Was Sicherheitsbeauftragte wirklich fragen — echte Testfälle

Bevor man versteht, warum Hybrid-RAG, muss man verstehen, was die Nutzer tatsächlich tippen. Aus unserem Golden-Set mit 120 verifizierten H&S-Anfragen drei Beispiele direkt aus dem Produktivbetrieb:

Schutzausrüstung für Maler: "Welche Schutzkleidung und PSA sind für Malerarbeiten vorgeschrieben?" — Das System antwortet mit den relevanten Abschnitten der geltenden Arbeitssicherheitsordnung. Berufsgruppen-spezifische Anfragen sind häufig: Maler, Kranfahrer, Elektriker auf der Baustelle — jede Berufsgruppe hat eigene Anforderungen, und die Nutzer erwarten eine konkrete Antwort, keine Verweise auf allgemeine Kapitel.

Höhenarbeiten: "Allgemeine Anforderungen an Arbeitsplätze für Höhenarbeiten" — Dieser Fall steckt in jeder Teststrategie, weil er den typischen Bruch zwischen lexikalischer Suche und semantischem Retrieval zeigt. Der Begriff "Höhenarbeiten" ist in der Normsprache oft als "Arbeit auf erhöhtem Standplatz" oder unter Einrüstungsvorschriften kodiert. Ohne Hybrid-Retrieval landen Nutzer regelmäßig im Nichts — obwohl die Information im Corpus vorhanden ist.

Kapitel-Abfrage: "Anforderungen aus Abschnitt IV" — Ein reiner Kapitel-Query ohne semantischen Kontext. Solche Anfragen haben in unserer Test-Suite eine Erfolgsquote von 100 %. Das Metadaten-Matching im Chapter-Retrieval-Pfad greift, bevor die Vektorsuche überhaupt beteiligt ist — eine explizite Routing-Entscheidung im Query-Workflow, keine Nebeneffekt.

Was uns außerdem überrascht hat: Nutzer senden regelmäßig abfotografierte Dokumente — handgeschriebene Sicherheitsunterweisungen, gescannte Seiten aus veralteten Druckausgaben, Screenshots aus anderen Chats. OCR ist deshalb kein optionales Feature, sondern Teil des Pflicht-Specs.

Warum reines Vektor-RAG nicht reicht

Als wir das System zum ersten Mal aufgebaut haben, starteten wir mit einem rein dense-basierten Retrieval: semantisch ähnliche Chunks aus dem Vektorspeicher, Top-5 weiter an das Sprachmodell. Das funktioniert für allgemeine Fragen überraschend gut — bis zum ersten Kunden-Audit.

Dort kommen Fragen wie: "Was steht in der Bauarbeits-Verordnung, Abschnitt IV, Punkt 48?" Exact-match ist das Gegenteil von semantisch ähnlich. Normcodes, Paragraphennummern, genaue Abschnittsbezeichnungen — das sind Keywords, kein semantisches Retrieval. Da hilft kein Embeddings-Modell, da muss Volltextsuche her.

Hybrid-RAG löst genau diese Spannung: Postgres FTS mit mehrsprachigen Analyzern läuft parallel zur pgvector-Suche. Die Ergebnisse werden über Reciprocal Rank Fusion zusammengeführt — k=60, top-12 — dann übernimmt ein Cross-Encoder-Reranker (bge-reranker-base, lokal) und liefert top-5 weiter. Recall@5 stieg bei unserem Golden Set von 0,71 auf 0,88. Der Cross-Encoder kostet etwa 150 ms Extra-Latenz. Er ist es wert.

Warum n8n — und welches Denken es verlangt

n8n ist kein RAG-Framework. Es ist ein Workflow-Automatisierungs-Tool — und das ist der springende Punkt.

Wer ein RAG-System für einen Industriebetrieb baut, stellt schnell fest: Das eigentliche Problem ist nicht der Retrieval-Algorithmus. Das Problem ist: Wie kommen die 340 Dokumente aus drei verschiedenen Systemen regelmäßig und automatisch in den Vektorspeicher? Wer triggert die Wiederverarbeitung, wenn ein SOP aktualisiert wird? Wie behandelt man ein Bild-PDF anders als einen bereits durchsuchbaren Text?

n8n beantwortet diese Fragen visuell und wartbar. Die Ingestion-Pipeline — Google-Drive-Webhook, Dokument herunterladen, Deduplizierung, OCR falls nötig, Chunking, Kategorisierung, Embedding, Upsert in pgvector — ist ein n8n-Workflow, der in Git eingecheckt ist, per Pull Request geändert wird und ohne Redeploy angepasst werden kann.

Abb. 1: Der Ingestion-Workflow in n8n — zwei Seiten, über 30 Knoten. Jeder Schritt ist sichtbar: von der Google-Drive-Quelle über OCR und Chunking bis zum kategorisierten Upsert in pgvector.

Aber n8n zu beherrschen ist nicht dasselbe wie gut zu programmieren. Das wird oft unterschätzt. Wer mit Python oder Java anfängt, denkt in Funktionen, Rückgabewerten und Kontrollfluss. n8n denkt in Flows: Daten bewegen sich durch Knoten, jeder Knoten bekommt den Output des vorherigen. Statt result = myFunction(input) schreibt man keinen Code — man konfiguriert, verdrahtet und parametriert.

Das klingt einfacher. Ist es aber nicht. n8n-Ausdrücke — {{ $node["NodeName"].json.field }} — haben ihre eigene Logik, die weder JavaScript noch ein klassisches Template-System ist. Fehlerbehandlung im visuellen Editor ist anders als try/catch: Man verbindet "Error"-Ausgänge mit separaten Knoten, die Fehler loggen, benachrichtigen oder Retry-Logik anstoßen. Wer das nicht versteht, baut Workflows, die still scheitern.

Ein konkretes Beispiel aus unserem System: Wir brauchten LDA-Topic-Modeling in der Ingestion-Pipeline — um neu hochgeladene Dokumente automatisch zu kategorisieren, bevor sie in pgvector landen. In Python ist das ein zwanzig-Zeilen-scikit-learn-Block. In n8n ist es ein Python-Task-Runner-Knoten, der in einem separaten Docker-Container läuft, mit pymorphy2 für russische Morphologie, gensim und NLTK — und der mit dem n8n-Hauptprozess über ein eigenes IPC-Protokoll kommuniziert. Das aufzusetzen war kein Standard-n8n-Setup. Das war ein Custom-Docker-Build mit eigenem Dockerfile, eigener Python-Umgebung, eigenem Runner-Image.

Weitere Fälle, die tiefe n8n-Kompetenz verlangt haben:

Mehrsprachige Query-Erkennung: Ein einziger JavaScript-Knoten erkennt, ob die Anfrage auf Russisch (kyrillisch), Deutsch (sprachspezifische Keywords), Slowenisch oder Englisch ist — und schaltet damit automatisch den richtigen FTS-Analyzer und das passende Prompt-Template um. Das ist kein Plug-and-play: Es erfordert genaues Verständnis davon, wie n8n mit Binary-Daten umgeht, wann Zeichen als UTF-8 ankommen und wann nicht.

Domain-Switching via Benutzerkommando: Superuser können mit /set_domain строительство oder /set_domain all den aktiven Normen-Corpus umschalten — mitten im Gespräch, ohne Neustart. Technisch ist das ein separater n8n-Workflow für Kommando-Erkennung, der in den Haupt-Query-Workflow einhängt und eine Postgres-Session-Tabelle schreibt. Die Schwierigkeit: Telegram-Webhooks sind zustandslos. Den Zustand über Konversations-IDs hinweg sauber zu verwalten, ohne race conditions zu erzeugen, war nicht trivial.

Aktivierungs-Code-Verwaltung: Nutzer aktivieren den Bot mit einem einmaligen Code. n8n übernimmt die gesamte Validierungs-Logik: Code empfangen, in Postgres prüfen, bei Erstnutzung invalidieren, Benutzer-Session anlegen, Datenschutzhinweis senden, Quittierung abwarten. Das sind sieben verkettete Aktionen in einem Workflow — und jede davon kann an einer anderen Stelle scheitern.

Fehler-Routing über dedizierte Kanäle: Jeder fehlgeschlagene Ingestion-Vorgang landet automatisch in einem separaten Telegram-Kanal für das H&S-Team. Das klingt simpel. In der Umsetzung bedeutet es: Jeder Workflow-Knoten hat einen Error-Ausgang, der zu einem zentralen Error-Handler-Workflow führt, der den Fehlerkontext normalisiert, strukturiert und weiterleitet. Ein eigener Workflow nur für Fehler — und der ist größer als die meisten regulären Workflows.

Auf der Query-Seite übernimmt n8n den Telegram-Webhook, analysiert die Anfrage mit einem LLM (Spracherkennung, Keyword-Extraktion, Routing-Entscheidung) und leitet sie je nach Strategie an unterschiedliche Retrieval-Pfade weiter.

Abb. 2: Der Query-Workflow in n8n — Webhook-Empfang, LLM-gestützte Query-Analyse, drei Retrieval-Routen (Broad, Hybrid Search, Chapter-based), Merge, Kontext-Assembly und Antwort-Dispatch.

Drei Punkte, die sich unabhängig davon bewährt haben:

Selbst gehostet. n8n läuft auf dem Server des Kunden. Die Dokumente verlassen das Netz nicht — bei Arbeitssicherheits-Daten aus Industriebetrieben ist das keine Verhandlungssache.

Fehlerbehandlung per Webhook. Fehlgeschlagene Ingestions landen automatisch in einem dedizierten Kanal. Das H&S-Team bemerkt Lücken im Corpus, bevor der erste Nutzer davon betroffen ist.

GitOps für Workflows. Workflow-JSON versioniert, Änderungen durch Code-Review sichtbar, kein blindes Klicken im UI.

Vibe Coding mit eigenem API-Schlüssel. Weil n8n selbst gehostet läuft und API-Schlüssel direkt in Workflow-Knoten konfiguriert werden, öffnet sich eine Arbeitsweise, die man aus klassischen IDEs nicht kennt: Man beschreibt den gewünschten Output eines Knotens einem LLM — etwa Claude oder einem lokal laufenden Modell — lässt sich den JavaScript- oder Python-Block generieren, und fügt ihn direkt ein. Kein Compile-Schritt, kein Deployment, sofortiger Test mit dem nächsten echten Dokument. Das funktioniert nicht, weil n8n irgendwie "KI-nativ" wäre, sondern weil jeder Knoten einen klar definierten Input und einen erwarteten Output hat — ideale Bedingungen für iteratives Generieren und sofortiges Verifizieren. Kombiniert man das mit einem eigenen Test-Framework — bei uns ein pytest-basiertes Golden-Set-Harness mit 120 verifizierten H&S-Fragen — und einem gewachsenen Repertoire an spezialisierten Sub-Workflows (eigene "Skills" für Dokumentenklassifikation, Spracherkennung, Fehlerformatierung, Aktivierungscode-Logik), entsteht eine Entwicklungsumgebung, die schnelles Iterieren mit Verlässlichkeit verbindet. Neue Knoten-Logik schreiben wir oft in Minuten — aber ohne das Test-Framework wüssten wir nicht, ob sie korrekt ist.

Was nicht gut funktioniert — der ehrliche Teil

n8n ist JavaScript. Der Reranker, die Embedding-Pipeline, der LLM-Dispatcher — das alles ist Python. Jeder Aufruf von n8n in Richtung RAG-Logik ist ein HTTP-Call an einen FastAPI-Service. Bei der Ingestion-Pipeline ist das kein Problem, die läuft asynchron. Bei Query-Time addiert sich Latenz anders.

Ein Telegram-Nutzer schickt eine Frage. n8n nimmt sie entgegen, baut einen HTTP-Request, ruft den Python-Orchestrator auf. Der macht Retrieval, Reranking, Modell-Dispatch, schickt die Antwort zurück. n8n leitet sie weiter. In dieser Kette stecken zwei serialisierte HTTP-Übergaben pro Anfrage — typischerweise 80–150 ms extra. Für einen H&S-Assistenten mit überschaubarer Nutzeranzahl ist das vertretbar. Für ein System mit hunderten parallelen Anfragen wäre n8n als Query-Router die falsche Wahl.

Das zweite Problem: Debugging. Wenn ein generiertes Zitat falsch ist — der Cross-Encoder einen falschen Chunk nach oben gereiht hat, oder der FTS-Analyzer einen Begriff nicht kannte — sieht man das in der n8n-Execution-History, aber man sieht nicht warum. Das Evaluierungs-Harness (Python/pytest über das Golden Set, 120 H&S-Fragen mit erwarteten Zitaten) lebt außerhalb von n8n und muss separat ausgeführt werden. In einer Testrunde kamen alle Content-Queries als Fehlschläge zurück — nicht weil das RAG-System kaputt war, sondern weil Windows-curl kyrillische Zeichen als ???????? übertrug. n8n hat das nicht gefangen. Die Execution-History zeigte "Erfolg", weil die HTTP-Anfrage technisch erfolgreich war. Das System antwortete dann korrekt mit "Information nicht gefunden" — weil es buchstäblich keine Frage erhalten hatte.

Drittens, und das ist das heikelste: Versions-Migrationen.

Wir haben im Februar 2026 auf n8n 2.2.3 migriert — Docker-Image 1.113.3+. Was uns erwartet hat, war ein vollständiger Umbau der Python-Task-Runner-Infrastruktur. In n8n 2.x kommuniziert der externe Code-Runner über ein geändertes IPC-Protokoll. Das bedeutete: neues Custom-Dockerfile, neue Runner-Image-Build-Kette, fünf Testphasen (Unit → Integration → End-to-End → Performance → Datenqualität), drei Wochen Parallelbertieb von alter und neuer Umgebung.

Der eigentliche Schmerz lag nicht im Umbau selbst, sondern in den Dingen, die man vorher nicht sehen konnte. Ein JavaScript-Knoten für Kapitel-Extraktion hatte in n8n 1.x eine undokumentierte Toleranz für fehlerhafte UTF-8-Sequenzen — in 2.x fiel er hart mit einem Exception aus. Nicht im Changelog. Nicht in den Release Notes. In einem Edge-Case-Test mit einem 5-MB-PDF aus dem Jahr 2018, das einen defekten Zeichencode enthielt. Hätten wir dieses Dokument nicht in der Testsammlung gehabt, wäre es erst in der Produktion aufgefallen — bei der ersten Anfrage eines Sicherheitsbeauftragten, dessen Betriebsanweisung zufällig dieses Format hatte.

Versions-Migration bei n8n bedeutet: intensive Tests mit realem Produktivdaten-Subset, nicht mit synthetischen Testfällen. Die Lücke zwischen dem, was in den Release Notes steht, und dem, was sich tatsächlich ändert, ist real.

Was 94 % Zitatgenauigkeit bedeuten — und was die anderen 6 % bedeuten

Unser Golden Set: 120 H&S-Fragen mit hinterlegten erwarteten Zitaten, quartalsweise manuell verifiziert. 94 % der Antworten linken auf einen Chunk, der die Aussage tatsächlich stützt.

Die 6 % sind Fälle, in denen die Frage zu unscharf war, das Dokument nicht im Corpus lag, oder der Cross-Encoder das falsche Stück gerankt hat. Die richtige Antwort auf diese Fälle ist nicht "diese 6 % wegoptimieren", sondern: Der Assistent gibt in diesen Fällen "nicht in meinen Quellen" zurück — statt zu halluzinieren. Das ist kein Systemfehler, das ist eine Designentscheidung.

Ein Assistent, der halluziniert und Sicherheitsbeauftragte trotzdem zufriedenstellt, ist gefährlicher als einer, der sagt "ich weiß es nicht". Dieser Satz klingt selbstverständlich. Wir haben ihn trotzdem mehr als einmal erklärt, weil "keine Antwort" manchen Kunden zunächst wie Versagen aussieht.

Was bleibt

Hybrid-RAG lohnt sich für regulierte Domänen — aber erst, wenn Volltext und Vektorsuche wirklich zusammenspielen. Lexical first ist keine Optimierung, die man macht, wenn Zeit ist: Bei Normcodes und Paragraphen ist sie die Voraussetzung für Verlässlichkeit.

n8n ist mächtiger als sein Ruf als "No-Code-Tool" vermuten lässt. Inzwischen ist es eine stabile, produktionsreife Orchestrierungs-Plattform — mit echten Python-Code-Knoten, direkter Postgres-Integration, GitOps-Unterstützung und einer Flexibilität, die klassische Workflow-Engines nicht bieten. Wer n8n richtig einsetzt, kann Systeme bauen, die ein Python-Skript alleine nicht leisten kann: visuell nachvollziehbar, wartbar ohne tiefe Programmierkenntnisse, erweiterbar ohne Redeploy.

Aber n8n zu beherrschen bedeutet nicht "kein Programmieren". Es bedeutet ein anderes Programmieren: Flow-basiert statt imperativ, knotenbasiert statt funktional, mit einer eigenen Denkweise für Fehlerbehandlung, Zustandsmanagement und Versions-Disziplin. Wer n8n wie Python behandelt, baut Systeme, die aus einem anderen Grund brechen als erwartet.

Für die Ingestion-Seite eines RAG-Systems in einer regulierten Domäne ist n8n eine ehrliche Wahl. Für Query-Time-Orchestration unter Last — und erst recht für Streaming-Antworten — ist Python-direkt die sauberere Wahl.

Und die eigentliche Frage, die man sich vor dem Go-live stellen sollte, ist nicht "Wie gut ist der Assistent im Schnitt?" — sondern "Was passiert in den Fällen, in denen er falsch liegt, und wer bemerkt das zuerst?" Wer diese Frage erst stellt, wenn das System schon im Einsatz ist, hat zu lange gewartet.

Mehr über den Worksafety Superassistant und die technische Architektur: sintaris.net/portfolio