Bevor Sie Code anfassen: Entscheidungen, die alles bestimmen
Die Integration eines Sprachmodells in eine Website beginnt nicht mit der Installation eines SDK. Sie beginnt mit der Beantwortung von drei Fragen, die den Rest der Checkliste bestimmen: Welche konkrete Aufgabe löst das LLM, wo wird die Inferenz ausgeführt und wer trägt die Kosten pro Token. Wenn Sie für alle drei keine abschließende Antwort haben, wird jede Integration am Ende ein teurer Prototyp sein, den niemand wartet.
Diese Checkliste ist nach realen Projektphasen geordnet. Sie ist kein theoretischer Leitfaden: Jeder Punkt enthält den Grund, warum er existiert, und den typischen Fehler, den er vermeidet. Einige Punkte gelten nicht für alle Fälle, und ich weise ausdrücklich darauf hin.
Phase 1. Definition des Anwendungsfalls (überspringen Sie diesen Teil nicht)
1.1. Schreiben Sie die Aufgabe in einem überprüfbaren Satz
„Die Benutzererfahrung verbessern“ ist keine Aufgabe. „Eingehende Support-Tickets in fünf Kategorien mit einem Konfidenz-Label klassifizieren“ ist eine. Wenn Sie nicht messen können, ob die Antwort des Modells korrekt ist, können Sie es nicht mit Garantien integrieren.
1.2. Prüfen Sie, ob ein LLM wirklich notwendig ist
Viele Aufgaben, die LLMs zugeschrieben werden, lassen sich mit Regeln, regulären Ausdrücken oder einem klassischen, günstigeren und deterministischen Klassifikator lösen. Ein LLM glänzt bei freier Sprache, Ambiguität und Generierung; es versagt bei exakten Berechnungen, strenger Logik und Daten, die sich jede Minute ändern. Wenn Ihr Fall „einen Betrag aus einer Rechnung mit festem Format extrahieren“ ist, brauchen Sie wahrscheinlich kein generatives Modell.
1.3. Definieren Sie die maximal akzeptable Kosten pro Interaktion
Die Preise pro Million Token variieren stark zwischen Anbietern und zwischen Modellen derselben Familie. Berechnen Sie vor der Integration: durchschnittliche Prompt-Länge + durchschnittliche Antwortlänge × geschätztes tägliches Volumen. Ein Chatbot, der 3.000 Anfragen pro Tag mit Prompts von 2.000 Token erhält, kann mehr kosten als das jährliche Hosting der Website. Haben Sie diese Zahl, bevor Sie die erste Zeile schreiben.
Phase 2. Architektur und Sicherheit
2.1. Der API-Schlüssel gelangt niemals in den Browser
Dies ist der häufigste und der teuerste Fehler. Jeder Aufruf aus dem clientseitigen JavaScript legt den Schlüssel in den Entwicklertools offen. Der Aufruf an den Anbieter muss von Ihrem Server oder einer Edge-Funktion ausgehen. Wenn Sie Streaming zum Browser benötigen, verwenden Sie einen Proxy in Ihrem Backend, der die Chunks weiterleitet.
2.2. Entscheiden Sie zwischen externer API und selbst gehostetem Modell
Externe API: schnell zu implementieren, ohne Infrastruktur, aber Sie sind von der Verfügbarkeit und den Preisen des Anbieters abhängig, und die Daten verlassen Ihre Umgebung. Selbst gehostetes Modell (zum Beispiel offene Gewichte, bereitgestellt mit lokalen Inferenzwerkzeugen): volle Kontrolle und feste Kosten, aber es erfordert GPU, Wartung und Know-how. Für kleine oder mittlere Websites ist die API in der Regel die vernünftige Entscheidung; bei sensiblen Daten mit strengen Anforderungen an den Datenstandort kann Selbsthosting obligatorisch sein.
2.3. Filtern und minimieren Sie die Daten, die Sie senden
Entfernen Sie vor dem Senden eines Prompts personenbezogene Identifikatoren, E-Mails und Zahlungsdaten, die das Modell nicht benötigt. Das ist nicht nur regulatorische Compliance: Es reduziert Token und verbessert die Qualität der Antwort, indem Rauschen beseitigt wird.
2.4. Schutz vor Prompt-Injection
Wenn das LLM Inhalte verarbeitet, die der Benutzer kontrolliert (Kommentare, Produktbeschreibungen, eingefügte Texte), gehen Sie davon aus, dass diese Inhalte bösartige Anweisungen enthalten können. Praktische Gegenmaßnahmen: Trennen Sie Systemanweisungen und Benutzerinhalte durch klare Begrenzungszeichen, validieren Sie die Ausgabe gegen ein Schema und lassen Sie niemals zu, dass die Ausgabe des Modells destruktive Aktionen ohne menschliche Bestätigung auslöst.
Phase 3. Design des Prompts und der Ausgabe
3.1. Stabile und versionierte Systemanweisung
Speichern Sie den System-Prompt in einer Datei mit Versionskontrolle. Wenn Sie ein Wort ändern, können Sie Ergebnisse vergleichen. Prompts, die im Code mit der Geschäftslogik vermischt leben, sind unmöglich zu auditieren.
3.2. Strukturierte Ausgabe, wann immer möglich
Wenn das Ergebnis eine Datenbank oder eine Oberfläche speist, fordern Sie JSON mit einem definierten Schema an und validieren Sie die Antwort mit einem strikten Parser. Wenn das Modell Freitext zurückgibt und Sie per Komma splitten, brechen Sie, sobald das Modell das Format ändert. Die meisten aktuellen Anbieter bieten Modi für strukturierte Ausgabe; nutzen Sie sie.
3.3. Fügen Sie Beispiele in den Prompt ein (Few-Shot)
Zwei oder drei Beispiele korrekter Ein-/Ausgaben verbessern das Ergebnis in der Regel mehr als Absätze von Anweisungen. Sie kosten Token, also reservieren Sie sie für Aufgaben, bei denen das Format wichtig ist.
3.4. Definieren Sie das Verhalten im Zweifelsfall
Geben Sie ausdrücklich an, was das Modell tun soll, wenn es etwas nicht weiß: ein Feld confianza: baja zurückgeben, einen konkreten Satz zur Weiterleitung an einen Menschen oder eine leere Antwort, die Ihre Oberfläche interpretiert. Ohne diese Anweisung wird das Modell mit voller Sicherheit erfinden.
Phase 4. Integration ins Frontend
4.1. Ladezustände und Abbruch
Generative Antworten dauern Sekunden. Die Oberfläche benötigt einen sichtbaren Wartezustand und eine Abbrechen-Schaltfläche, die die Anfrage abbricht. Wenn Sie Streaming verwenden, zeigen Sie den Text an, während er eintrifft: Das reduziert die wahrgenommene Langsamkeit deutlich.
4.2. Barrierefreiheit der Komponente
Der Antwortcontainer muss aria-live=»polite» haben, damit Screenreader den neuen Text ankündigen. Streaming ohne Barrierefreiheits-Handling erzeugt kaputte Erfahrungen für Benutzer mit Screenreadern.
4.3. Limits im Client und auf dem Server
Begrenzen Sie die Eingabelänge auf beiden Seiten. Ein Textfeld ohne Limit ist ein direkter Weg zu riesigen Prompts, die Ihre Rechnung aufblähen. Fügen Sie außerdem ein Limit für Anfragen pro Sitzung oder pro IP hinzu.
Phase 5. Qualität, Evaluierung und Monitoring
5.1. Testsuite mit erwarteten Antworten
Stellen Sie vor der Veröffentlichung 30 bis 100 repräsentative Fälle mit der von Hand annotierten korrekten Antwort zusammen. Führen Sie den Prompt bei jeder Änderung gegen diese aus. Ohne diese Testbank ist jede Änderung ein Glücksspiel.
5.2. Protokollierung von Anfragen und Antworten (mit Vorsicht)
Speichern Sie den Prompt, die Antwort und die Latenz, um debuggen zu können. Anonymisieren Sie vor der Speicherung und definieren Sie eine Aufbewahrungsfrist. Ein Log ohne Aufbewahrungsrichtlinie wird zur Belastung.
5.3. Warnungen zu Kosten und Latenz
Konfigurieren Sie eine Ausgabenschwelle pro Tag, die Sie warnt, bevor die Rechnung außer Kontrolle gerät. Eine Endlosschleife im Client oder ein Bot, der Anfragen wiederholt, können den Verbrauch innerhalb von Stunden vervielfachen.
Phase 6. SEO und Sichtbarkeit
6.1. Generierte Inhalte werden nicht durch Zauberei indexiert
Wenn das LLM Seiten oder Fragmente generiert, die Sie positionieren möchten, benötigen sie eine eigene URL, einen Titel, eine Meta-Beschreibung und serverseitiges Rendering. Ein Widget, das nach einer Benutzerinteraktion Text innerhalb eines div generiert, trägt nichts zum Crawling bei.
6.2. Generieren Sie keine massenhaften Inhalte ohne Überprüfung
Die Qualitätsrichtlinien der Suchmaschinen entmutigen Inhalte, die in großem Umfang ohne Mehrwert produziert werden. Wenn Sie das LLM zum Schreiben verwenden, nutzen Sie es als Entwurf mit redaktioneller Überprüfung. Laut der offiziellen Dokumentation der wichtigsten Suchmaschinen bleibt das Kriterium der Nutzen für den Benutzer, nicht die Produktionsmethode.
6.3. Blockieren oder markieren Sie die internen Routen des Assistenten
Die Endpunkte Ihrer API und die Generierungsrouten dürfen weder crawlbar noch indexierbar sein. Fügen Sie noindex und Einschränkungen in robots.txt hinzu, wo es angebracht ist.
Phase 7. Launch und Wartung
7.1. Progressives Deployment
Aktivieren Sie die Funktion zunächst für einen Prozentsatz der Benutzer. Messen Sie Fehlerrate, Latenz und Zufriedenheit, bevor Sie sie für den gesamten Traffic öffnen.
7.2. Degradationsplan
Was passiert, wenn der Anbieter 429- oder 500-Fehler zurückgibt? Definieren Sie eine Ersatzantwort: Nichtverfügbarkeitsmeldung, Kontaktformular oder gecachte Antwort. Ein Assistent, der die Seite bricht, wenn die API ausfällt, ist schlimmer als kein Assistent.
7.3. Regelmäßige Überprüfung des Modells
Anbieter ziehen Modellversionen mit vorherigen Ankündigungen zurück. Notieren Sie das Deprecation-Datum der von Ihnen verwendeten Version und testen Sie die Migration, bevor sie erzwungen wird. Prompts, die für eine Version feinabgestimmt wurden, können sich in der nächsten anders verhalten.
Ein konkreter Fall und seine Lektion
In einem Projekt für einen Assistenten für einen Komponentenshop testete das Team den Prompt mit Katalogfragen, und er funktionierte gut. Bei der Veröffentlichung begannen die Benutzer, nach Kompatibilitäten zwischen Teilen zu fragen. Das Modell antwortete mit Sicherheit über Kombinationen, die es im Katalog nicht gab. Die Ursache: Der Prompt enthielt eine Auswahl von Produkten, nicht den vollständigen Katalog, und das Modell füllte die Lücken mit Plausibilität. Die Lösung war kein besserer Prompt, sondern das Abrufen der relevanten Produkte aus der Datenbank und deren Übergabe als Kontext bei jeder Anfrage. Lektion: Wenn die Antwort von Daten abhängt, die sich ändern, benötigt das Modell Zugriff auf diese Daten zum Zeitpunkt der Anfrage, nicht eine statische Auswahl im Prompt.
Was diese Checkliste nicht löst
Es gibt keine Garantie, dass das Modell auf alles korrekt antwortet. LLMs halluzinieren, und keine Konfiguration beseitigt dieses Verhalten vollständig. Es gibt auch keinen perfekten Prompt: Was heute funktioniert, kann sich mit dem nächsten Update des Anbieters verschlechtern. Und es gibt Aufgaben, bei denen ein LLM nicht das richtige Werkzeug ist: exakte Suchen, Finanzberechnungen, deterministische Filter. Dies rechtzeitig zu erkennen, spart Budget und Frustration.
Wenn Sie diese Phasen der Reihe nach durchgehen und die Entscheidungen jeder Phase schriftlich festhalten, haben Sie etwas Wertvolleres als eine funktionierende Integration: Sie haben eine Integration, die Sie warten können, wenn sich das Modell, der Anbieter oder das Team ändert.