Die Architektur

Ein Produktions-KI-Chatbot hat vier Komponenten:

1. Chat-UI: Eingabefeld, Nachrichtenverlauf, Ladezustände, Fehlerbehandlung 2. Konversationszustand: Ein Array von Nachrichten (Rolle + Inhalt) im Frontend-Zustand gespeichert 3. Backend-Proxy: Eine Supabase Edge Function oder ein Xano-Endpunkt, der OpenAI aufruft 4. System-Prompt: Der Anweisungssatz, der die Persona, das Wissen und die Einschränkungen deines Chatbots definiert

Der Konversationszustand ist das wichtigste Konzept. OpenAIs API ist zustandslos, jede Anfrage muss die gesamte Konversationshistorie enthalten. Dein Frontend hält diese Geschichte aufrecht und sendet sie mit jeder Nachricht. Für deutsche B2B-Apps: speichere Konversationen in Supabase EU-Region für DSGVO-Konformität.

Chatbot-Architektur: Retrieval vs. Generierung

Bevor du mit dem Bauen beginnst, entscheide, ob dein Chatbot primär retrieval-basiert oder generierungs-basiert sein soll. Diese Entscheidung bestimmt die Architektur, die Kosten und die Qualitätsmerkmale des fertigen Produkts.

Ein retrieval-basierter Chatbot findet die am besten passende Antwort aus einer vordefinierten Wissensbasis. Der Nutzer stellt eine Frage, dein System findet das ähnlichste Frage-Antwort-Paar in der Datenbank und zeigt es an, optional vom LLM neu formatiert. Das ist schnell, günstig (wenige Tokens werden verbraucht) und innerhalb der Wissensdomäne hochgenau. Es scheitert, wenn Nutzer Fragen stellen, die die Wissensbasis nicht abdeckt, was zu wenig hilfreichen Antworten wie "Dazu habe ich keine Informationen" führt.

Ein generierungs-basierter Chatbot sendet die Frage des Nutzers mit Kontext an ein LLM und lässt das Modell eine neue Antwort formulieren. Das behandelt Fragen, die nie explizit geschrieben wurden, kann Informationen aus mehreren Quellen zusammenführen und erzeugt natürliche, konversationelle Antworten. Die Kosten sind höher (mehr Tokens pro Nachricht), und das Modell kann gelegentlich plausibel klingende, aber falsche Informationen erzeugen. Für die meisten kundenorientierten Support-Chatbots ist die richtige Architektur hybrid: starte mit Retrieval (ziehe die drei relevantesten Wissensbasis-Artikel) und nutze Generierung, um aus diesen Quellen eine kohärente Antwort zu formulieren, mit der harten Einschränkung, dass das Modell nicht außerhalb dieser Quellen antworten soll. Das ist RAG, Retrieval Augmented Generation, und es gibt dir Genauigkeit mit Flexibilität.

Chat-UI in WeWeb bauen

In WeWeb erstelle eine seitenstufige Variable messages (Array, Standard leer). Füge zwei Komponenten hinzu:

Nachrichtenliste: Eine Repeating Group, die an messages gebunden ist. Jedes Element hat ein bedingtes Erscheinungsbild, Nutzernachrichten rechtsbündig mit Primärfarb-Hintergrund, Assistentennachrichten linksbündig mit neutralem Hintergrund. Binde den Text an item.content.

Eingabebereich: Eine Texteingabe, die an eine userInput-Variable gebunden ist, plus einen "Senden"-Button. Beim Klick: (1) {role: "user", content: userInput} zu messages hinzufügen, (2) userInput leeren, (3) API-Aktion aufrufen, (4) Antwort als {role: "assistant", content: response} hinzufügen.

Füge einen Lade-Spinner hinzu, der während des API-Aufrufs angezeigt wird.

Den Chatbot auf deine Dokumentation trainieren

Ein Chatbot, der nur weiß, worauf GPT-4o trainiert wurde, kennt die spezifischen Funktionen, Preise, Richtlinien oder Abläufe deines Produkts nicht. Damit der Chatbot für deine Nutzer wirklich nützlich wird, musst du deine Wissensbasis in die Konversation einspeisen. Es gibt zwei Ansätze: statische Injektion (Dokumentation direkt in den System-Prompt einfügen) und dynamische Injektion über RAG.

Statische Injektion funktioniert für kleine Wissensbasen unter 5.000 Wörtern. Schreibe deine Dokumentation als strukturierten Text, füge sie dem System-Prompt hinzu, und das Modell nutzt sie als primäre Referenz. Nachteil: Der statische Ansatz wird bei größerem Umfang teuer (die gesamte Wissensbasis wird mit jeder Nachricht mitgesendet), und die Aktualisierung des System-Prompts bei Dokumentationsänderungen ist manuelle Arbeit.

Für größere Wissensbasen ist RAG der richtige Ansatz. Verarbeite deine Dokumentation in Abschnitte von 200 bis 500 Wörtern, embedde jeden Abschnitt mit OpenAIs text-embedding-3-small-Modell und speichere die Embeddings in Supabase mit der pgvector-Erweiterung. Zum Zeitpunkt der Anfrage embeddest du die Nachricht des Nutzers, findest die drei bis fünf ähnlichsten Abschnitte per Kosinus-Ähnlichkeitssuche und injizierst nur diese Abschnitte in den System-Prompt. Das kostet dramatisch weniger pro Nachricht und skaliert auf Tausende von Dokumentationsseiten. Wenn du die Dokumentation aktualisierst, embeddest du die geänderten Abschnitte neu und aktualisierst die Datenbank, der Chatbot übernimmt die Änderungen bei der nächsten Anfrage automatisch.

Die Supabase Edge Function

Deine Edge Function empfängt das Nachrichten-Array und den System-Prompt, ruft OpenAI auf und gibt die Antwort zurück:

```typescript
serve(async (req) => {
  const { messages, systemPrompt } = await req.json()

  const completion = await openai.chat.completions.create({
    model: "gpt-4o",
    messages: [
      { role: "system", content: systemPrompt },
      ...messages
    ],
    max_tokens: 500,
    temperature: 0.7
  })

  return new Response(
    JSON.stringify({ content: completion.choices[0].message.content }),
    { headers: { "Content-Type": "application/json" } }
  )
})
```

Der systemPrompt kann vom Frontend übergeben werden (nützlich für Apps mit mehreren Personas) oder in der Funktion fest hinterlegt werden (sicherer).

Einen effektiven System-Prompt schreiben

Der System-Prompt bestimmt alles über das Verhalten deines Chatbots. Ein guter Produktions-System-Prompt enthält:

- Rolle: "Du bist ein Kundensupport-Agent für Acme SaaS, ein Projektmanagement-Tool." - Wissen: "Du hilfst Nutzern bei: Projekte erstellen, Teammitglieder einladen, Integrationen konfigurieren und Abrechnungsfragen." - Einschränkungen: "Beantworte nur Fragen zu Acme SaaS. Erwähne niemals Konkurrenzprodukte. Erfinde niemals Funktionen, die nicht existieren." - Format: "Halte Antworten unter 100 Wörtern. Verwende Aufzählungslisten für Schritte. Antworte auf Deutsch, sofern der Nutzer nicht in einer anderen Sprache schreibt." - Eskalierung: "Wenn der Nutzer Frustration ausdrückt oder einen Abrechnungsfehler erwähnt, sage: 'Ich verbinde dich mit unserem Team' und löse den Eskalierungs-Flow aus."

Für deutsche Apps: füge die Anweisung hinzu, standardmäßig auf Deutsch zu antworten, mit der Möglichkeit, die Sprache zu wechseln.

Eskalation an menschlichen Support

Jeder Produktions-Chatbot braucht einen klaren Eskalationspfad für Fragen, die die KI nicht sicher beantworten kann, emotional aufgeladene Gespräche und Situationen, die Aktionen auf Kontoebene erfordern, die ein Bot nicht ausführen sollte (Rückerstattungen ausstellen, Konten löschen, Abrechnungsausnahmen machen). Plane das von Anfang an in den System-Prompt und die UI ein, nicht als nachträglichen Gedanken.

Definiere im System-Prompt explizite Eskalierungs-Trigger: "Wenn der Nutzer einen Abrechnungsstreit, eine fehlgeschlagene Zahlung oder eine Kontosperrung erwähnt, versuche nicht, das Problem zu lösen. Antworte stattdessen genau mit: ESCALATE: [kurzer Grund], und nichts anderes." Deine Edge Function erkennt das ESCALATE-Präfix und erstellt ein Support-Ticket in deinem Helpdesk (Intercom, Zendesk oder sogar eine Supabase-Tabelle), anstatt die Nachricht dem Nutzer anzuzeigen.

Ersetze in der UI, wenn eine Eskalation erkannt wird, die Chatbot-Oberfläche durch eine Nachricht: "Ich verbinde dich mit unserem Support-Team. Es meldet sich innerhalb von [SLA]. Du kannst auch eine E-Mail an support@deinunternehmen.de schreiben." Sende dem Support-Team eine E-Mail mit dem vollständigen Gesprächsverlauf. Dieser Ansatz hält die Übergabe für den Nutzer reibungslos und gibt dem Support-Mitarbeiter den vollen Kontext. Miss die Eskalationsrate als zentrale Chatbot-Kennzahl, eine Rate über 20% deutet darauf hin, dass die Wissensbasis erweitert werden muss.

Persistenten Kontext hinzufügen

Der einfache Chatbot vergisst alles, wenn die Seite aktualisiert wird. Um ihn smarter zu machen:

Nutzerkontextinjektion: Wenn die Chatbot-Sitzung startet, hole die Kontodaten des Nutzers (Plan, Nutzung, letzte Aktivität) und füge sie dem System-Prompt hinzu: "Der aktuelle Plan des Nutzers ist Pro. Ihre letzte Aktivität war vor 3 Tagen. Sie haben 2 aktive Projekte."

Konversationspersistenz: Speichere Nachrichten in einer Supabase-Tabelle (chatbot_sessions) mit user_id und session_id. Beim Seitenladen hole die letzten N Nachrichten und fülle das messages-Array vorab.

Wissensbasis: Für Produktdokumentation speichere Artikel in Supabase mit Embeddings (mit pgvector). Bevor du GPT-4o aufrufst, führe eine Ähnlichkeitssuche durch und injiziere die relevantesten Artikel in den System-Prompt. Das nennt sich RAG (Retrieval Augmented Generation) und verbessert die Antwortgenauigkeit dramatisch.

Chatbot-Erfolg messen

Ein Chatbot ohne Messung ist eine Funktion ohne Feedback-Schleife. Die wichtigsten Kennzahlen für einen Support- oder Produkt-Chatbot: Lösungsrate (Prozentsatz der Gespräche, bei denen der Nutzer nicht eskaliert hat oder ein separates Support-Ticket erstellt hat), Sitzungslänge (durchschnittliche Nachrichten pro Gespräch, zu kurz deutet darauf hin, dass der Bot früh scheitert, zu lang deutet darauf hin, dass er nicht effizient löst) und Bewertung nach dem Chat (ein einfaches Daumen-hoch/runter nach jedem Gespräch, in Supabase gespeichert und in einem Dashboard einsehbar).

Über diese nutzerorientierten Kennzahlen hinaus solltest du deine Edge Function so instrumentieren, dass sie protokolliert: welche Wissensbasis-Artikel am häufigsten abgerufen wurden (zeigt dir, wonach Nutzer am häufigsten fragen), welche Anfragen keine starke Übereinstimmung in der Vektordatenbank hatten (zeigt dir Lücken in der Wissensbasis) und Modell-Latenz sowie Token-Anzahl pro Sitzung (zeigt dir deine Kosten pro Gespräch). Überprüfe diese Kennzahlen im ersten Monat nach dem Launch wöchentlich.

Die aussagekräftigste Kennzahl ist die Liste der Anfragen ohne Wissensbasis-Treffer. Exportiere sie wöchentlich, schreibe Antworten für die 20 am häufigsten unbeantworteten Anfragen, füge sie der Wissensbasis hinzu und embedde neu. Ein Chatbot, der seine Lösungsrate im ersten Monat um 5% pro Woche verbessert, erreicht oft innerhalb von 6 Wochen nach dem Launch eine Lösungsrate von über 80%, deutlich besser als die meisten menschenzentrierten Support-Workflows bei SaaS-Unternehmen in der Frühphase.

Kosten und Performance in der Produktion

Für ein SaaS mit 500 aktiven Nutzern, die jeweils 10 Nachrichten pro Tag senden:

- Durchschnittliche Nachricht: 50 Tokens Input + 100 Tokens Output - GPT-4o-Preise: 2,50 USD/M Input + 10 USD/M Output - Tageskosten: 500 × 10 × 150 Tokens = 750.000 Tokens = ~2,50 USD/Tag = ~75 €/Monat

Zur Kostenkontrolle: implementiere ein Sitzungs-Token-Budget (höre auf, Verlaufsnachrichten hinzuzufügen, wenn das Gespräch 2.000 Tokens überschreitet, beginne mit der Zusammenfassung alter Nachrichten). Nutze GPT-4o mini für einfache Anfragen (0,15 USD/M Input) und reserviere GPT-4o für komplexe.

Antwortzeit: GPT-4o antwortet in 1-3 Sekunden. Füge einen Tippindikator hinzu, um Erwartungen zu setzen. Für Unter-Sekunden-Erlebnisse implementiere Streaming.

DSGVO und EU KI-Verordnung für KI-Chatbots

Für deutsche Apps gibt es zusätzliche Überlegungen für KI-Chatbots:

Datensparsamkeit: Speichere nicht mehr Konversationshistorie als notwendig. Implementiere automatische Löschung von Konversationen, die älter als dein Bedarf sind (z.B. 90 Tage).

Transparenz: Informiere Nutzer, dass sie mit einer KI sprechen. Die EU KI-Verordnung verlangt eine klare Kennzeichnung von KI-Interaktionen ab 2025.

Keine sensiblen Daten: Konfiguriere den System-Prompt, aktiv abzuweisen, wenn Nutzer sensible personenbezogene Daten, Steueridentifikationsnummern, Bankdaten oder Gesundheitsdaten im Chat teilen.

EU-Datenzentralisierung: Alle Konversationsprotokolle in Supabase EU-Region. Deine Edge Function in EU-Region. OpenAI verarbeitet Daten außerhalb der EU, dokumentiere dies in deiner Datenschutzrichtlinie und dem Auftragsverarbeitungsvertrag mit OpenAI.