Drupal-RAG-Architektur: Was Sie selbst entwickeln und was Sie verwalten lassen

Eine Drupal-RAG-Architektur ist mehr als ein Chatbot. Eine Drupal-native Lösung benötigt normalerweise Content-Extraktion, Chunking, Embeddings, Vektorsuche, Search-API-Konfiguration, ein LLM, Quellenangaben, Zugriffskontrollen, Aktualisierungsjobs, eine Oberfläche und den laufenden Betrieb. Ein verwalteter Dienst für öffentliche Websites verlagert mehrere Schichten aus Drupal heraus; die richtige Grenze hängt vom Datenzugriff und davon ab, wer für Fehler verantwortlich ist.

Michael Shamanoff Founder, Achla AI Für wen: Drupal-Verantwortliche, Architektinnen und Architekten sowie Implementierungsteams, die semantische Suche oder Antworten mit Quellenangaben bewerten. Wie: auf Grundlage offizieller Drupal-Projektseiten und aktueller Achla-Produktdateien, geprüft am 3. August 2026, ergänzt um eine eigene Verantwortungsmatrix und eine Pilot-Scorecard. KI unterstützte die Texterstellung; wesentliche Tatsachenbehauptungen sind im begleitenden Nachweisregister Quellen zugeordnet. Warum: Installationsanleitungen nennen Komponenten. Entscheider müssen darüber hinaus wissen, wer jede Schicht betreibt, wie sie ausfallen kann und welche Anforderungen einen verwalteten Ansatz mit öffentlichem Crawling ausschließen.

Die Drupal-RAG-Architektur, Schicht für Schicht

RAG umfasst zwei Abläufe. Die Indexierung überführt Inhalte in abrufbare Datensätze. Der Anfrageablauf verwandelt eine Frage in Retrieval, Kontext, Generierung und überprüfbare Nachweise.

Indexierungsablauf: vom Inhalt zu abrufbaren Chunks

1. Wählen Sie Drupal-Entitäten, Felder und Ansichtsmodi aus, die nützliches Quellmaterial enthalten.
2. Extrahieren Sie den Text und bewahren Sie Identität, Sprache, URL, Zugriffsmetadaten sowie Aktualisierungs- und Löschsignale.
3. Teilen Sie lange Inhalte in Chunks, die genügend Kontext behalten, um verständlich zu bleiben.
4. Erzeugen Sie Embeddings und speichern Sie sie in einem vektorfähigen Backend.
5. Aktualisieren, ersetzen oder löschen Sie Datensätze, wenn sich Drupal-Inhalte ändern.

Das offizielle Projekt AI Search verbindet Vektor-Embeddings mit Search API und dokumentiert ein Vektor-Backend, Chunking, Bewertungsschwellen, nachgelagerte Zugriffskontrollen für Entitäten, hybride Suche und RAG-Integration. Das sind Bausteine, kein vollständiges Betriebsmodell.

Anfrageablauf: von der Frage zur belegten Antwort

1. Wandeln Sie die Frage um oder leiten Sie sie an die gewählte Retrieval-Methode weiter.
2. Rufen Sie Kandidaten-Chunks ab und wenden Sie Schwellenwerte, Filter oder hybride Suchlogik an.
3. Stellen Sie den Kontext für das LLM zusammen, ohne Quellidentität oder Zugriffsbeschränkungen zu verlieren.
4. Erzeugen Sie eine Antwort oder ein ehrliches leeres Ergebnis.
5. Stellen Sie Quellenangaben dar und protokollieren Sie genug Nachweise, um Retrieval und Generierung getrennt zu diagnostizieren.

Behandeln Sie abgerufene Quellen, generierten Text und für Besucher sichtbare Quellenangaben als getrennte Nachweise: Relevantes Retrieval kann schlecht zusammengefasst werden, während flüssige Formulierungen auf der falschen Quelle beruhen können.

Was Search API leistet – und was nicht allein

Search API ist Drupals erweiterbares Such-Framework. Es definiert Indizes und arbeitet mit Backends, Feldern, Prozessoren, Views, Filtern und Facetten. Allein wählt es weder ein Embedding-Modell noch betreibt es jedes Backend, setzt einen LLM-Prompt zusammen, erzeugt Antworten, gestaltet eine Chat-Oberfläche oder bewertet die Quellenbindung.

Die offizielle Projektseite nennt außerdem eine wichtige Sicherheitsgrenze: Search API kann nicht für jeden Anwendungsfall allgemeine Zugriffsbeschränkungen bereitstellen. Website-Verantwortliche müssen sicherstellen, dass nur zugängliche Elemente indexiert oder angezeigt werden, auch wenn Teile des Ökosystems Node-Access-Anpassungen und weitere Prüfungen anbieten.

Eine semantische Ergebnisseite muss kein Chat werden. Entscheiden Sie, ob Besucher semantisch sortierte Ergebnisse, eine belegte Antwort, eine Unterhaltung oder mehrere Oberflächen benötigen.

Diese Entscheidung sollte vor der Auswahl der Oberfläche fallen. Ein gutes Ranking, eine generierte Antwort und eine dialogorientierte Nutzung stellen unterschiedliche Anforderungen an Retrieval, Nachweise und Fehlerbehandlung. Dass Search API den Index bereitstellt, beantwortet diese Produkt- und Betriebsfragen noch nicht.

Der aktuelle Status der Drupal-Projekte muss die Risikoentscheidung prägen

Releasebezeichnungen und Sicherheitsabdeckung ändern sich. Aktualisieren Sie diese Tabelle regelmäßig und erneut vor jeder Implementierungsentscheidung. Die folgenden Angaben wurden am 3. August 2026 auf offiziellen Drupal.org-Projektseiten beobachtet.

Eine Versionsnummer 1.0.x ersetzt keine Sicherheitsabdeckung. Prüfen Sie Reife, Wartung, Drupal-Versionen, Anbieterabhängigkeiten und den Status der Sicherheitsrichtlinie getrennt.

Eigenbau: Diese Komponenten muss Ihr Team verantworten

Ein Drupal-nativer Aufbau hält mehr Kontrolle nah an Drupal, schafft aber auch mehr betriebliche Verantwortlichkeiten. Das Projekt RAG Search zeigt einen Search-API-Vektorindex, der Prompt-Zusammenstellung und LLM versorgt, dazu optionale exakte und semantische Caches, Rate Limiting und erneute Zugriffskontrollen, bevor gespeicherte Chunks ausgegeben werden. Der Ausschluss aus der Sicherheitsrichtlinie bleibt ein wesentliches Warnsignal.

Drupal as RAG veranschaulicht einen anderen Weg mit Drupal 11, PostgreSQL samt pgvector und Ollama auf einem lokalen Rechner oder Netzwerkhost. Das beobachtete Release war Alpha und nicht abgedeckt. Es ist daher ein Architekturbeispiel, keine Empfehlung.

Die Frage nach der Verantwortung reicht damit deutlich weiter als die Installation eines Moduls. Für jede Schicht braucht es eine benannte zuständige Stelle, ein beobachtbares Fehlersignal, einen reproduzierbaren Abnahmetest und eine klare Aussage dazu, welche Daten und Zugriffsregeln diese Schicht verarbeiten darf.

Der umfassendere Zielkonflikt wird in Enterprise-KI-Suche versus Eigenbau behandelt.

Verwalteter Ansatz: Welche Schichten Drupal verlassen

Ein verwalteter Ansatz für öffentliche Websites überträgt Crawling, Indexierung, Retrieval, Modellaufrufe, Antwortausgabe und einen Teil des Monitorings an einen Servicebetreiber. Drupal liefert öffentliche Seiten sowie ein Skript oder einen Connector. Der Stack innerhalb von Drupal wird kleiner, doch der Dienst kennt Felder, Revisionen, Rollen und Zugriffsentscheidungen nicht Drupal-nativ, sofern sie nicht ausdrücklich umgesetzt und geprüft werden.

Die untersuchten Achla-Produktdateien beschreiben einen per Composer bereitgestellten Connector für Drupal 10/11, eine PHP-8.3-Validierungsmatrix und automatische Updates, die bei der letzten Prüfung am 16. Juli 2026 als verfügbar gekennzeichnet waren. Der verwaltete Dienst crawlt und indexiert die öffentliche Website und zeigt über ein Widget Antworten mit Quellenlinks. Das Widget unterstützt die Platzierungen bubble, inline und attach.

Achla ist kein Search-API-Backend. Es ist ein eigener verwalteter Weg für öffentliches Crawling und ein Widget. Er darf nicht als Lösung für private oder authentifizierte Drupal-Inhalte, rollenbezogenes Retrieval, Berechtigungen auf Zeilenebene oder transaktionale Drupal-Aktionen dargestellt werden. Der Betriebsrahmen wird in verwaltete Einrichtung ohne Entwickler näher erläutert.

Selbst entwickeln oder verwalten lassen? Entscheiden Sie nach Anforderungen

Berücksichtigen Sie Infrastruktur, Aktualisierungen, Sicherheitsprüfung, Anbieterschlüssel, Observability, Content-Betrieb, Störungsbehebung und den Nachweis funktionierender Zugriffsbeschränkungen – nicht nur Lizenzkosten.

Die Entscheidung ist deshalb keine einfache Gegenüberstellung von Softwarepaketen. Beim Eigenbau trägt das Team mehr technische Wahlfreiheit und mehr Diagnosepflichten. Beim verwalteten Weg sinkt der interne Betriebsumfang, dafür müssen Leistungsgrenzen, öffentliche Datenquellen, Nachweise und das Verhalten bei Störungen vertraglich und praktisch überprüfbar sein.

Zugriff, Quellenangaben und Aktualisierungen absichern

Private Inhalte bilden eine harte architektonische Weggabelung. Das allgemeine Search-API-Framework löst nicht automatisch alle Zugriffsbeschränkungen. AI Search dokumentiert Zugriffskontrollen für Entitäten nach der Abfrage; RAG Search dokumentiert rollenbezogene Cache-Schlüssel und erneute Prüfungen des Quellenzugriffs. Diese modulspezifischen Mechanismen müssen weiterhin mit echten Rollen, unveröffentlichten Inhalten, geänderten Berechtigungen und gespeicherten Antworten getestet werden.

Das Projekt AI RAG Search Chat zeigt, warum die Produktionsoberfläche größer als das Retrieval ist: Es ergänzt Such- und Chatseiten, Sessions, Berechtigungen, Rate Limiting, Anbieter und verknüpfte Quellen. Das beobachtete Release 1.0.7 war nicht durch die Sicherheitsrichtlinie von Drupal abgedeckt.

Bewahren Sie in jeder Architektur URLs und Quellkennungen beim Chunking, prüfen Sie, ob jede Quellenangabe die Antwort stützt, definieren Sie ein ehrliches Fehlschlagen und testen Sie die Weitergabe von Aktualisierungen und Löschungen. Quellengebundene Antworten sind leichter prüfbar, aber Retrieval und Quellenangaben beseitigen Modellfehler nicht. Nutzen Sie den Leitfaden zum Bewerten der Vertrauenswürdigkeit von KI-Suche.

Prüfen Sie dabei nicht nur neue Inhalte. Ändern Sie Berechtigungen, ziehen Sie Veröffentlichungen zurück, löschen Sie Testseiten und kontrollieren Sie nach dem dokumentierten Aktualisierungsfenster erneut Index, Cache, Antwort und Quellenlink. Nur so wird sichtbar, ob die Zuständigkeit für Aktualisierung und Löschung tatsächlich funktioniert.

Eine reproduzierbare Pilot-Scorecard verwenden

Erstellen Sie die Bewertungsmenge aus echten Aufgaben. Zwanzig bis dreißig repräsentative Fragen sind eine Planungsmethode, kein Benchmark und kein versprochener Grenzwert.

1. Erfassen Sie Frage, erwartete Quellseite, Inhalts-/Zugriffsklasse und ein zulässiges Ergebnis „nicht gefunden“.
2. Nehmen Sie exakte Begriffe, Paraphrasen, widersprüchliche Seiten, veraltete oder gelöschte Inhalte und eine unbeantwortbare Frage auf.
3. Verwenden Sie für einen Drupal-nativen Test privater Inhalte Konten mit unterschiedlichen Rollen; jede Offenlegung einer unzugänglichen Quelle lässt den Test scheitern.
4. Erfassen Sie abgerufene Quellen getrennt von generierter Formulierung und sichtbaren Quellenangaben.
5. Prüfen Sie die Indexaktualisierung nach Bearbeitung und Löschung und wiederholen Sie den Test, wenn relevante Caches beteiligt sein könnten.
6. Ergänzen Sie Tastatur-, Mobil-, Ausfall-, Leerresultat- und Fallback-Tests für die gewählte Oberfläche.
7. Ordnen Sie jeden Fehler Ingestion, Retrieval, Generierung, Quellen/UI, Zugriff oder Betrieb zu und benennen Sie für jede Architektur die verantwortliche Stelle.

Der Pilot gilt als gescheitert bei offengelegten geschützten Inhalten, erfundenen Quellen, defekten Quellenlinks, fehlendem Eingeständnis einer nicht vorhandenen Antwort oder gelöschten Inhalten, die über das dokumentierte Aktualisierungsfenster hinaus bestehen bleiben. Erfinden Sie keinen universellen Genauigkeitswert. Das wiederverwendbare RAG-Nachweisblatt trennt Behauptung, Quelle, erwartetes Verhalten und beobachtetes Ergebnis.

Häufige Architekturfehler

• Ein LLM als Retrieval zu behandeln, statt die abgerufenen Nachweise zu messen.
• Private Felder oder Inhalte zu indexieren, ohne Zugriffsregeln zu bewahren und zu testen.
• URLs, Sprache, Revision oder Entitätsidentität beim Chunking zu verlieren.
• Ergänzungen zu testen, aber nicht Bearbeitungen, Löschungen, Cache-Invalidierung und ehrliche Fehlschläge.
• Eine Version wegen fehlendem Alpha-Suffix als „sicher“ zu bezeichnen und die Sicherheitsabdeckung zu ignorieren.
• Einen öffentlichen Crawler als Search-API-Backend oder Private-Content-Integration zu bezeichnen.
• Lizenzpreise zu vergleichen, dabei aber Infrastruktur und Störungsverantwortung auszulassen.

Ein praktischer nächster Schritt für eine öffentliche Drupal-Website

Erstellen Sie einen eigenen Prototyp, wenn Drupal-native Felder und Berechtigungen, Anbieterkontrolle und ein bestehender Search-API-Betrieb zentrale Anforderungen sind. Bewerten Sie eine verwaltete öffentliche Suche, wenn die Quelle bewusst öffentlich ist und das Team die RAG-Serviceebenen von einem anderen Betreiber verantworten lassen möchte.

Wenn Sie belegte Antworten über öffentliche Drupal-Seiten und -Dokumente benötigen, ohne den RAG-Stack in Drupal zu betreiben, bewerten Sie Achlas Drupal-Einrichtung. Achla ist kein Search-API-Backend und nicht der oben beschriebene Weg für private Inhalte.

Fragen aus Drupal-Teams

Benötige ich Search API?

Für einen Drupal-nativen Weg auf Grundlage von Search-API-Modulen: ja. Ein getrennter verwalteter Dienst für öffentliches Crawling kann einen eigenen Index verwenden. Das sind unterschiedliche Architekturen; ein Connector oder Widget macht den verwalteten Index nicht zu einem Search-API-Backend.

Benötige ich immer eine Vektordatenbank?

Nicht für jede Sucherfahrung. Schlagwort- oder Facettensuche kann andere Backends verwenden. Das offizielle AI-Search-Modul nutzt vektorfähige Backends für semantisches Retrieval; ein verwalteter Dienst kann seine Retrieval-Infrastruktur hinter der Servicegrenze verbergen.

Kann semantische Suche ohne Chat funktionieren?

Ja. Semantisches Retrieval kann sortierte Ergebnisse in einer Suchoberfläche ausgeben. Ergänzen Sie Generierung nur, wenn eine formulierte Antwort der Aufgabe dient, Quellen erhalten bleiben, Fehlschläge ehrlich behandelt und Formulierungen getrennt vom Retrieval getestet werden können.

Was ist mit privaten Inhalten?

Beziehen Sie Anforderungen an Zugriffskontrollen von Beginn an in die Architekturentscheidung ein. Ein Drupal-nativer Entwurf kann Drupal-Berechtigungen bewahren, wenn sein vollständiger Indexierungs-, Retrieval-, Cache- und Anzeigeweg getestet wird. Achlas Weg in diesem Artikel ist auf öffentlich crawlbare Inhalte beschränkt.

Wie vergleiche ich Pilotprojekte?

Verwenden Sie dieselbe Fragenmenge, dieselben Quellerwartungen, Zugriffsfälle, Aktualisierungstests, Quellenprüfungen, Oberflächenbedingungen und Fehlerkategorien. Vergleichen Sie Nachweise und Verantwortlichkeiten, keine vom Anbieter gewählte Demo oder unbelegte Universalbewertung.

Gemeinsame Illustration

Eine RAG-Architekturentscheidung verteilt Extraktion, Abruf, Generierung, Quellenangaben und Betrieb auf unterschiedliche Verantwortliche.

*Eine RAG-Architekturentscheidung verteilt Extraktion, Abruf, Generierung, Quellenangaben und Betrieb auf unterschiedliche Verantwortliche.*