Architektur · Lokale KI + kontrolliertes Backend
Private KI- und RAG-Backend-Architektur für WordPress
Nutzen Sie unterstützte On-Device-KI dort, wo sie passt. Leiten Sie Workloads, die serverseitige Modelle, RAG, Quellenangaben oder öffentlichen Frontend-Zugriff benötigen, an ein konfiguriertes Backend weiter – statt an eine obligatorische, gemeinsam genutzte Plugin-SaaS-Laufzeit.
WordPress-Editor / Frontend
├→ unterstützte lokale KI
└→ konfigurierter API-Endpunkt
↓
API Gateway + Lambda
├→ Bedrock-Modellzugriff
├→ Wissensabruf
└→ Protokolle / Kontrollen
WordPress bleibt die Inhaltsquelle; die Backend-Verantwortung ist eindeutig.
Vertrauensgrenzen und Datenpfad
Lokale Verarbeitung und Backend-Verarbeitung sind getrennte Ausführungsmodi
AI-Kit kann unterstützte Aufgaben lokal in kompatiblen Browsern ausführen. Pro-Workflows können stattdessen einen konfigurierten API-Endpunkt verwenden, typischerweise im AWS-Konto des Kunden. Öffentliche Chatbot- und DocSearch-Funktionen benötigen einen vom Browser erreichbaren Backend-Pfad, da Besucher nach der statischen Veröffentlichung nicht von WordPress PHP abhängig sein können.
Editor-Aufgabe
├→ lokales Browsermodell, sofern unterstützt
└→ konfigurierte Backend-Route /admin/*
Besucher-Chatbot / DocSearch
→ konfigurierte Backend-Route /frontend/*
→ Abruf / Modellausführung
→ Antwort + Quelldaten
Wissensquellen
WordPress-Inhalte → aufbereitete Dokumente + Metadaten → Wissens-Backend
Grenze Ein konfiguriertes Backend macht nicht automatisch jede KI-Aktion lokal oder privat. Entscheidend ist, wo der jeweilige Workload ausgeführt wird, welche Inhalte diese Grenze überschreiten und wer Backend, Protokolle und Modellzugriff kontrolliert.
Was der AI-Kit-Backend-Stack bereitstellt
Das Backend besteht aus klar definierten Laufzeitaufgaben und ist kein undurchsichtiger KI-Proxy. Die Übersicht zeigt API-, Modell-, Retrieval-, Speicher-, Missbrauchsschutz- und Beobachtbarkeitskomponenten des konfigurierten Pfads.
| Baustein | Zweck | Zentrale Designentscheidung | Betrieblicher Hinweis |
|---|---|---|---|
| API Gateway REST API | Stellt Admin- und optionale Frontend-KI-Routen bereit | /admin/* ist stets die vertrauenswürdige Oberfläche; /frontend/* erscheint nur bei aktivierten Funktionsschaltern | Öffentliche und privilegierte Routen bleiben getrennt, auch wenn sie Handler-Code teilen. |
| AiHandlerFunction | Einheitlicher Lambda-Handler für Prompt- und Sprachfunktionen | Ein warmer Ausführungspfad für Prompt, Schreiben, Umschreiben, Zusammenfassen, Übersetzen, Korrekturlesen, Spracherkennung und KB-Auflistung | Gemeinsame Validierung, Metriken, Guardrails und Middleware verringern die betriebliche Streuung. |
| Amazon-Bedrock-Modelle | Führen Generierung, übersetzungsähnliche Aufgaben und RAG-Antwortsynthese aus | Das Frontend-Modell kann über parametrisierte Modellauswahl günstiger und leichter als das Admin-Modell sein | Modell-IDs sind Architekturparameter und keine fest codierten Plugin-Annahmen. |
| Bedrock Knowledge Base + S3 Vectors | Bietet verwaltetes Retrieval über Dokumentation oder Kundeninhalte | Neue KB erstellen oder vorhandene über Stack-Parameter wiederverwenden | Die Ausgaben KnowledgeBaseId und DataSourceId gehören zum Integrationsvertrag. |
| S3-Bucket für Dokumente und temporäre Assets | Speichert KB-Dokumente und temporäre Bild-Uploads für Prompts | Getrennte Präfixe für Dokumente, Konfiguration und temporäre Assets | Temporäre Bilder sollten schnell ablaufen; KB-Dokumente bewusst versioniert werden. |
| KnowledgeBaseSyncFunction | Führt Dokumentaufnahme-Workflows aus | Eine S3-/EventBridge-/DynamoDB-Debounce-Schleife verhindert eine Aufnahme bei jedem kleinen Dateiereignis | Nützlich, wenn WordPress bei der Veröffentlichung mehrere KB-Dokumente neu erzeugt. |
| reCAPTCHA + SSM/KMS | Schützt offene Frontend-Endpunkte | Geheimnis als verschlüsselter SSM-Parameter gespeichert und von Handlern abgerufen | Wichtig, wenn FrontendApiAuthMode für statische Websites auf NONE steht. |
| AWS WAF und Drosselung | Begrenzt Missbrauch auf öffentlichen und administrativen API-Pfaden | Getrennte Zulassungs-, Sperr- und Ratenregeln für Frontend- und Admin-Oberflächen | KI-Endpunkte verursachen Kosten; öffentlicher Zugriff braucht mehr Schutz als CORS. |
| CloudWatch, DLQ und Warnungen | Liefert Protokolle, Metriken, Erfassung fehlgeschlagener Aufrufe und optionale Benachrichtigungen | Pro Funktion definierte Aufbewahrung, benutzerdefinierte Metriken und gemeinsame SQS-DLQ | KI-Funktionen brauchen Beobachtbarkeit, weil Kosten, Latenz und Qualität Laufzeitthemen sind. |
Endpunktoberfläche: ein Backend, zwei Vertrauenszonen
Das Backend kann mehrere Funktionen bereitstellen, doch Admin- und Frontend-Routen müssen getrennt bleiben. Die Tabelle zeigt, welche Besucherrouten nur bei aktivierter Funktion existieren und welche Konfigurationsrouten ausschließlich für Admins bestimmt sind.
| Funktion | Admin-Route | Frontend-Route | Wann das Frontend erstellt wird | Designhinweis |
|---|---|---|---|---|
| Prompt / Chatbot / DocSearch | /admin/prompt | /frontend/prompt | EnableChatbotBackend=true | Kann KB, Quellenangaben, Neugenerierung, Feedback-Metadaten und optionale Bildeingaben verwenden. |
| Upload-URL erzeugen | /admin/generate-upload-url | /frontend/generate-upload-url | EnableChatbotBackend=true | Lädt Bilder per vorsigniertem PUT nach S3 und übergibt anschließend Schlüssel an Prompt-Anfragen. |
| Zusammenfassen | /admin/summarize | /frontend/summarize | EnableSummarizerBackend=true | Deaktiviert die KB normalerweise standardmäßig, da der Quelltext bereits mitgeliefert wird. |
| Schreiben | /admin/write | /frontend/write | EnableLanguageAIBackend=true | Als Backend-Fallback für Editor- oder Frontend-Generierung geeignet. |
| Umschreiben | /admin/rewrite | /frontend/rewrite | EnableLanguageAIBackend=true | Berücksichtigt Ton, Format und Länge, ohne Geheimnisse im Browser offenzulegen. |
| Übersetzen | /admin/translate | /frontend/translate | EnableLanguageAIBackend=true | Kann mit automatischer Spracherkennung kombiniert werden. |
| Korrekturlesen | /admin/proofread | /frontend/proofread | EnableLanguageAIBackend=true | Gibt korrigierten Text und strukturierte Korrekturmetadaten zurück. |
| Spracherkennung | /admin/detect-language | /frontend/detect-language | EnableLanguageAIBackend=true | Nutzt einen Backend-Pfad statt vorauszusetzen, dass der Browser die Sprache immer liefert. |
| Wissensdatenbanken | /admin/knowledge-bases | Keine öffentliche Route | Nur Admin | Auflistung und Auswahl von Wissensressourcen gehören in die vertrauenswürdige Konfigurationsoberfläche. |
Die Grounding-Richtlinie ist eine Produktentscheidung
Das Retrieval-Verhalten sollte zum Risiko und zu den Erwartungen der Nutzer passen. Die Tabelle vergleicht strikte KB-Antworten, klärungsorientiertes Verhalten und KB-bevorzugte Antworten.
| Grounding-Modus | Wann verwenden | Verhalten ohne relevante KB-Ausschnitte | Redaktionelle Auswirkung |
|---|---|---|---|
| KB_ONLY | Regulierte, risikoreiche oder strikt dokumentationsgebundene Antworten | Angeben, dass die Dokumentation die gewünschte Information nicht enthält | Autoren müssen die KB für erwartbare Fragen ausreichend vollständig halten. |
| ASK_WHEN_NO_KB | Mehrdeutige Quellensätze oder kategorienabhängige Antworten | Eine Rückfrage stellen, statt zu raten | Die Metadaten-Taxonomie wird Teil des UX-Designs. |
| KB_PREFERRED | Marketing, Produktbildung und allgemeiner Support | KB verwenden, wenn vorhanden; sonst klar von abgerufenen Dokumenten getrennt antworten | Guter Ausgleich für öffentliche Websites mit Dokumentation und allgemeinen Erklärungen. |
Matrix für Authentifizierung und Schutz
Admin-Routen, öffentlicher Chat, Sprachwerkzeuge, Uploads und Wissensverwaltung haben unterschiedliche Vertrauensstufen. Die Matrix zeigt die Standardhaltung und den erforderlichen Schutz jeder Oberfläche.
| Oberfläche | Standardhaltung | Mögliche Authentifizierungsmodi | Empfohlener Schutz | Warum |
|---|---|---|---|---|
| Admin-KI-Routen | Vertrauenswürdig / Admin | IAM oder Cognito | Standardmäßig IAM, optionale IP-Zulassungsliste, Protokolle und Warnungen | Diese Routen können breitere Fähigkeiten bereitstellen und sollten nicht öffentlich sein. |
| Frontend-Chatbot | Öffentlich oder für Mitglieder | NONE, IAM oder Cognito | reCAPTCHA + WAF öffentlich; Cognito-Bereiche nur für Mitglieder | Chat-Endpunkte verursachen Kosten und können beliebige Nutzereingaben erhalten. |
| Frontend-Zusammenfassung / Sprachwerkzeuge | Funktionsabhängig öffentliche Oberfläche | NONE, IAM oder Cognito | Nur benötigte Routen aktivieren; drosseln und Nutzlastgröße validieren | Jede Route erweitert die Missbrauchs- und Modellkostenoberfläche. |
| Hilfsfunktion für Bild-Uploads | Temporärer Asset-Eingang | Folgt der Prompt-Oberfläche | Strenger Inhaltstyp, Größe, Schlüsselpräfix und Ablauf des Lebenszyklus | Vorsignierte Uploads sind leistungsfähig und müssen eng begrenzt werden. |
| Knowledge-Base-Verwaltung | Nur Admin | IAM oder privilegiertes Cognito | Nie als anonymen Frontend-Endpunkt bereitstellen | KB-Auswahl und Backend-Ressourcen sind Konfiguration, keine Besucher-UX. |
Modellauswahl und Kostenhaltung
Verschiedene KI-Workloads erzeugen unterschiedliche Kosten- und Qualitätsanforderungen. Diese Tabelle verhindert, dass Editor-Aufgaben, öffentlicher Chat, DocSearch und multimodale Anfragen in ein einziges Modell- und Schutzprofil gezwungen werden.
| Workload | Kostendruck | Qualitätsanforderung | Architekturentscheidung |
|---|---|---|---|
| Editor: Umschreiben / Übersetzen / Korrekturlesen | Meist moderat und administrativ kontrolliert | Konsistente Ausgabe und geringe Reibung | Zuerst lokale KI versuchen; Backend-Fallback nutzen, wenn sie nicht verfügbar ist oder Richtlinien dies verlangen. |
| Frontend-Chatbot | Potenziell hoch, da Besucher Nutzung auslösen können | Fundierte, sichere und verständliche Antworten | Nur benötigte Routen aktivieren, leichteres Frontend-Modell, reCAPTCHA/WAF und begrenzte Antwortparameter verwenden. |
| DocSearch | Abhängig von Suchvolumen und abgerufenem Kontext | Gute Quellenangaben und präzise Quellenauswahl | RAG zuerst; optionales Reranking nur, wenn der Relevanzgewinn zusätzliche Aufrufe rechtfertigt. |
| Multimodaler Prompt | Höher, weil Bilder Speicher und Verarbeitung hinzufügen | Für ausgewählte Support- oder Inhaltsworkflows nützlich | Vorsignierte S3-Uploads, Objektgrößenlimits und Ablaufregeln verwenden. |
Wie der Bereitstellungsassistent das Betriebsmodell verändert
Der Assistent überführt Produktentscheidungen in eine explizite Backend-Konfiguration. Die Tabelle zeigt, wie Funktionswahl, Authentifizierung, Vorlagenquelle und Stack-Ausgaben CloudFormation und WordPress beeinflussen.
| Assistentenentscheidung | Auswirkung auf CloudFormation | Auswirkung auf WordPress |
|---|---|---|
| Frontend-Funktionen | Aktiviert nur die für Chatbot, DocSearch, Zusammenfassung oder Sprachwerkzeuge erforderlichen Backend-Routen. | Das Plugin kann nur die Oberflächen bereitstellen, die die Website tatsächlich unterstützen soll. |
| Admin-Authentifizierungsmodus | Bevorzugt standardmäßig Cognito für Admin-Aktionen und kann Berechtigungsbereiche erzwingen. | Admin-/Backend-Aktionen werden nicht versehentlich als öffentliche KI-Aufrufe behandelt. |
| Vorlagenquelle | Verwendet eine für CloudFormation lesbare S3-Vorlagen-URL. | Nutzer sehen einen AWS-nativen Stack-Prüfablauf statt eines verborgenen SaaS-Bereitstellungsschritts. |
| Ausgaben | Erzeugt ApiBaseUrl und weitere Stack-Ausgaben. | WordPress speichert den Endpunktvertrag; die Backend-Laufzeit gehört ihm nicht. |
Implementierungspfad
Wählen Sie den Ausführungspfad anhand von Workload und Governance-Anforderung
Leiten Sie nicht jede KI-Funktion über denselben Pfad, nur weil das Plugin mehrere KI-Fähigkeiten bereitstellen kann.
- Editor- und Besucher-Workloads klassifizieren — Trennen Sie editorseitiges Umschreiben, Übersetzen oder Metadatenarbeit von öffentlichen Chatbot-, DocSearch- und anderen besucherausgelösten Anfragen.
- Lokale Ausführung nur dort nutzen, wo sie tatsächlich unterstützt wird — Belassen Sie kompatible On-Device-Aufgaben im Browser, wenn dies Fähigkeit und Richtlinie erfüllt. Behaupten Sie keine lokale Ausführung für Browser oder Aufgaben, die sie nicht unterstützen.
- Vertrauenszonen des Backends konfigurieren — Trennen Sie privilegierte Admin-Routen von öffentlichen Frontend-Routen und ergänzen Sie je nach exponierter Oberfläche passende Authentifizierung, WAF-, Drosselungs- oder Missbrauchsschutzmaßnahmen.
- Abruf und Quellennutzung steuern — Legen Sie fest, welche WordPress-Inhalte in die Wissensquelle gelangen, wie sie aufgeteilt oder ausgeschlossen werden und wie Quellen- oder Zitationsdaten zurückgegeben werden, damit fundierte Antworten geprüft werden können.
Wann diese Architektur sinnvolle Kontrolle schafft
Gut geeignet
KI-Workloads mit unterschiedlichen Datenschutz- und Laufzeitanforderungen
- Einige Editor-Aufgaben können auf dem Gerät bleiben, während andere Funktionen ein serverseitiges Modell oder Retrieval-Backend benötigen.
- Das konfigurierte Backend und seine AWS-Ressourcen sollen in einem von Ihnen kontrollierten Konto liegen, statt einen gemeinsamen KI-Proxy des Anbieters vorauszusetzen.
- Besucherorientierte DocSearch- oder Chatbot-Funktionen benötigen fundierte Antworten und müssen auch auf einem statischen Frontend funktionieren.
Einfacher halten
Ein einfacherer KI-Pfad kann genügen, wenn
- Die Website nur gelegentliche Editor-Aufgaben benötigt, die bereits von unterstützter lokaler Browser-KI abgedeckt werden.
- Eine herkömmliche SaaS-KI-Integration die Anforderungen der Organisation an Daten, Governance und Betrieb erfüllt.
- Keine öffentliche KI, kein RAG, keine Quellenangaben, keine Backend-Beobachtbarkeit und keine kundengesteuerte Infrastruktur erforderlich sind.
Problemlösungen
Käuferfragen, die diese Architektur beantwortet
Wie nutze ich KI in WordPress, ohne jeden Entwurf durch einen KI-SaaS-Dienst zu senden?
Beginnen Sie mit KI in WordPress nutzen, ohne jeden Entwurf durch einen KI-SaaS-Dienst zu senden. Der Leitfaden unterscheidet unterstützte lokale Verarbeitung vom optionalen konfigurierten Backend-Pfad und vermeidet die Behauptung, jede KI-Aufgabe bleibe lokal.
Wie liefere ich Besuchern fundierte Antworten aus WordPress-Inhalten?
Lesen Sie Besuchern Antworten aus Ihren WordPress-Inhalten geben – mit Quellen. Die Lösung behandelt DocSearch und Chatbots; diese Architektur erläutert die Grenzen von Wissensquelle, Retrieval und Backend hinter fundierten Antworten und Quellen.
Wo ist die KI-gestützte Erzeugung von Bildmetadaten einzuordnen?
Lesen Sie Fehlende Alt-Texte und Metadaten für WordPress-Bilder in großem Umfang ergänzen. Die Erzeugung von Medienmetadaten ist ein Editor-Workflow und kann die unterstützten AI-Kit-Ausführungsmodi nutzen; bei barrierefreiheitsrelevanten Alt-Texten bleibt eine menschliche Prüfung wichtig.
Funktioniert Frontend-KI auch nach der statischen Veröffentlichung?
Ja, wenn der Browser das konfigurierte Backend direkt erreichen kann. WordPress statisch betreiben, ohne dynamische Funktionen zu verlieren erläutert die allgemeine Regel: Statische Seitenauslieferung und dynamische Browserdienste können getrennt bleiben.
Beginnen Sie beim KI-Datenpfad
Entscheiden Sie zuerst, wo der KI-Workload laufen soll – und erst dann über das Modell
Nutzen Sie den Private-KI-Leitfaden für die Entscheidung über den Datenpfad. Wenn die Website zusätzlich Retrieval über WordPress-Inhalte benötigt, verwenden Sie anschließend den Leitfaden für fundierte Antworten.