End-to-End-Produktion: Überprüfung, Überwachung und Ethik

Gewinne:

• Kann die End-to-End-Architektur entwerfen, die eine LLM-Funktion von der Idee bis zur Produktion begleitet
• Richtet Schichten zur Durchsetzung der Verifizierung, zur menschlichen Genehmigung und zur Nachverfolgung (Protokollierung/Metriken) ein.
• Grenzen übersetzen Ethik- und Datenschutzprinzipien in Produktionsentscheidungen

In den vorherigen zehn Einheiten haben wir die Teile nacheinander gelernt: Anforderungsstruktur, Token-Ökonomie, Ablauf, Systemeingabeaufforderung, Modellauswahl, Cache, Batch, Fehlermanagement, sicherer Schlüssel und Automatisierung. In dieser letzten Einheit kombinieren wir die Teile und etablieren die ganzheitliche Architektur, die eine LLM-Funktion von der Idee bis zur Produktion trägt. Die Produktion unterscheidet sich von einer „funktionierenden Demo“: Die Verifizierung ist obligatorisch, der Output muss überwacht werden, Grenzen und ethische Grundsätze müssen in Entscheidungen verankert werden. Diese Einheit ist die Trägersäule des Moduls; Alle vorherigen kommen hier zusammen.

Schichten der Produktionsarchitektur

Eine solide LLM-Qualifikation besteht aus ungefähr fünf Schichten:

1. Eingabeebene: Daten sammeln, bereinigen, sensible Bereiche maskieren, nur das Notwendige übertragen.
2. Modellebene: Wählen Sie das richtige Modell aus (Einheit 5), legen Sie Systemeingabeaufforderung und Parameter fest (Einheit 4), Cache (Einheit 6).
3. Validierungsebene: Überprüfen Sie die Ausgabe bei Bedarf anhand von Schema/Regel, Quelle und menschlicher Genehmigung.
4. Aktionsebene: Aktion mit validierter Ausgabe ausführen; Erfassen Sie wirkungsvolle Aktionen.
5. Überwachungsebene: Erfassen und messen Sie jeden Anruf, jede Kosten, jeden Fehler und jede Qualität.

Diese Schichten sind eine Pipeline; Jeder überprüft die Ausgabe des vorherigen.

Warum ist eine Verifizierung erforderlich?

LLMs können flüssige, aber manchmal ungenaue Ergebnisse liefern. Dies nennt man Halluzination: Das Modell fabriziert möglicherweise Informationen, die wahr erscheinen, aber nicht wahr sind. In einem Chatspiel ist das tolerierbar; kann in einem Produktionssystem (Rechnung, Gesundheit, Recht, Finanzen) nicht toleriert werden. Es stellte sich also heraus, dass es völlig unzuverlässig war; wird bestätigt.

Verifizierungsebenen (zunehmend je nach Auswirkung):

• Format-/Schemavalidierung: Entspricht die Ausgabe dem erwarteten JSON-Schema? (Die strukturierte Ausgabe gewährleistet dies weitgehend.)
• Regel-/Logiküberprüfung: Sind die Werte angemessen? (Ist der Betrag negativ, liegt das Datum in der Zukunft, ist die Kategorie gültig?)
• Quellenverifizierung: Basiert die Behauptung auf den bereitgestellten Unterlagen? Sagt das Modell etwas, das nicht im Dokument enthalten ist?
• Menschliche Zustimmung: Ein Experte überprüft schwerwiegende oder mehrdeutige Entscheidungen.

Achtung: „Das Modell ist so gut, dass keine weitere Überprüfung erforderlich ist“ ist der gefährlichste Produktionsfehler. Egal wie gut das Modell ist, die Verifizierungsschicht ist ein Sicherheitsnetz bei Entscheidungen mit großer Auswirkung. Schon eine einzige falsche automatische Entscheidung kann die gesamte eingesparte Zeit zunichte machen.

Human-in-the-Loop

Nicht jede Entscheidung muss vollautomatisch erfolgen. Beim Human-in-the-Loop-Ansatz beschleunigt das Modell die Arbeit und der Mensch genehmigt sie. Die richtige Balance hängt von der Auswirkung der Entscheidung und der Zuverlässigkeit des Modells für diese Aufgabe ab.

Auswirkungen der Entscheidung

Ansatz

Niedrig (Labelvorschlag, Entwurf)

Vollständige Automatisierung; Fehler sind billig und reversibel

Mittel (Routing, Priorisierung)

Automatisierung + Probenkontrolle

Hoch (Geld, Vertrag, Gesundheit, Löschung)

Die Einwilligung des Menschen ist zwingend erforderlich; das Modell deutet es nur an

Überwachung: Was Sie nicht sehen, können Sie nicht verwalten

In der Produktion müssen Sie jeden Anruf überwachen. Ohne Überwachung können Sie Kosten und Qualität nicht verbessern oder Probleme frühzeitig erkennen. Zu erfassende Schlüsselkennzahlen:

• Nutzung/Kosten: Pro Anfrage und Gesamtzahl der Token, Modellverteilung, tägliche Ausgaben.
• Latenz: Durchschnittliche und Worst-Case-Antwortzeit.
• Fehlerrate: 429/500-Raten, Wiederholungsversuche, Abbrüche.
• Qualität: Rate abgelehnter Ausgaben auf der Verifizierungsebene, Korrekturrate bei menschlicher Genehmigung, Benutzerfeedback.

Tipp: Schreiben Sie keine sensiblen Daten (persönliche Informationen, Schlüssel) in Überwachungsprotokolle. Berücksichtigen Sie Protokolle im Rahmen der Vertraulichkeit; Aufnahme ggf. durch Maskierung (Einheit 9).

Ethik und Grenzen

Ethische Verantwortung ist ebenso Teil der Produktionsentscheidung wie technische Genauigkeit:

• Transparenz: Der Nutzer soll wissen, ob er mit einer künstlichen Intelligenz oder einem Menschen spricht.
• Fairness und Voreingenommenheit: Das Modell kann aufgrund der Daten, auf denen es trainiert wird, voreingenommen sein. Überwachen Sie diskriminierende Konsequenzen bei Entscheidungen mit großer Tragweite (Einstellung, Kredit).
• Haftung: Wenn eine automatisierte Entscheidung Schaden verursacht, sind Sie dafür verantwortlich; „Das Modell hat es gesagt“ ist keine Verteidigung.
• Akzeptanz von Grenzen: Das Modell kann einige Aufgaben nicht zuverlässig ausführen; Sie nicht zu automatisieren, ist auch eine Designentscheidung.

Kopierbare Vorlagen

# Validierungscheckliste (nach Ausgabegenerierung)1) Ist das Schema gültig? (strukturierte Ausgabevalidierung)2) Sind die Werte sinnvoll? (Regelprüfung: Bereich, Datum, Aufzählung)3) Basiert die Behauptung auf der Quelle? (ablehnen, wenn nicht im Dokument enthalten)4) Ist die Auswirkung groß? → zur menschlichen Genehmigung senden5) Wenn alles bestanden wurde → Aktion zulassen, speichern

# Systemaufforderung, die das Verlassen auf die Quelle erzwingt. Verlassen Sie sich nur auf die Informationen im bereitgestellten Dokument. Fügen Sie nichts hinzu, was nicht im Dokument enthalten ist. Wenn eine Information nicht im Dokument enthalten ist, schreiben Sie „Nicht im Dokument gefunden“. Erraten oder erfinden Sie niemals Dinge.

# Menschlicher Genehmigungsschwellenwert (Entscheidungsregel)WENN Entscheidungstyp in [Geld, Vertrag, Löschung, Gesundheit] → menschliche Genehmigung obligatorischIF model_trust < Schwellenwert ODER Validierung „unsicher“ → der menschlichen Genehmigung unterwerfenOTHER → automatisch anwenden + Stichprobenkontrolle

# Trace-Log-Vorlage (Schreiben sensibler Daten){ „time“:…“, „model“:…“, „input_token“:..., „output_token“:..., „delay_ms“:..., „stop_reason“:…“, „authentication“: „passed|rejected|human“, „cost_usd“:... } // Persönliche Daten und Schlüssel werden NIEMALS geschrieben

Schwache Eingabeaufforderung / Starke Eingabeaufforderung (Produktionszuverlässigkeit)

# SCHWACH (keine Bestätigung, keine Quelle, gilt automatisch) Bewerten Sie diesen Antrag, treffen Sie eine Rückerstattungsentscheidung und beantragen Sie ihn.

# STARK (quellenbasiert, generiert Empfehlung, überlässt es der menschlichen Genehmigung)Bewerten Sie diesen Rückgabeantrag nur anhand des Rückgaberichtliniendokuments. Entscheidung mit Begründung empfehlen, aber nicht umsetzen: {"recommendation": "approve|reject", "reason": "...", "policy_clause": "..."}. Wenn es keine klare Grundlage im Richtliniendokument gibt, geben Sie "unklar" an. Ein Vertreter wird die endgültige Entscheidung genehmigen.

Leistungsstarke Version; Es ordnet die Entscheidung der Quelle zu, positioniert das Modell als „Vorschlaggeber“ statt als „Macher“ und stellt den wirkungsvollen Schritt hinter die menschliche Zustimmung. Dies ist die Essenz der Produktionssicherheit.

Drei Mini-Hüllen

Fall 1 – Der Tag, an dem die Verifizierungsschicht gespeichert wurde. Ein Fintech-Unternehmen ließ das Modell Transaktionsbeschreibungen klassifizieren und automatische Buchhaltungsunterlagen erstellen. Sie fügten eine Regelvalidierung hinzu: Sobald das Modell den Betrag falsch ausgab (12.500 statt 1.250 im Dokument), lehnte die Regel „Betrag stimmt nicht mit dem Dokument überein“ die Ausgabe ab und der Datensatz fiel an den Menschen. Ohne Überprüfung würde der falsche Datensatz stillschweigend in das System gelangen.

Fall 2 – Flüchtling durch Überwachung gefasst. Ein SaaS-Team hatte ein Überwachungspanel eingerichtet; Eines Morgens verdreifachten sich die Tageskosten. Aus den Protokollen ging hervor, dass ein Client in eine Schleife gelangte und dieselbe Anfrage tausende Male sendete. Sie fügten Quote und Deduplizierung hinzu; Das Problem wurde innerhalb weniger Stunden gelöst. Ohne Sendungsverfolgung wäre die Rechnung am Monatsende eine Überraschung.

Fall 3 – Akzeptieren des Limits. Ein Healthcare-Startup plante, vollautomatisch eine Diagnoseempfehlung auszusprechen und diese dem Patienten anzuzeigen. In einer Ethik- und Haftungsprüfung kamen sie zu dem Schluss, dass dies tabu sei: Das Modell liefert einem Arzt nur eine Zusammenfassung und mögliche Punkte, der Arzt stellt die Diagnose. Einen Job nicht zu automatisieren, ist ebenfalls eine ausgereifte Designentscheidung.

Häufige Fehler

• Überspringen der Validierung: Blindes Anwenden der Ausgabe mit der Aussage „Das Modell ist gut“.
• Automatisierung von Entscheidungen mit großer Auswirkung: Die Zustimmung des Menschen ist in den Bereichen Geld/Gesundheit/Recht von entscheidender Bedeutung.
• Keine Überwachung: Kosten- und Qualitätsprobleme werden erst spät entdeckt.
• Sensible Daten in Protokolle schreiben: Datenschutzverletzung; Speichern Sie es, indem Sie es maskieren.
• Versuchen Sie nicht, sich auf die Quelle zu verlassen: Das Modell stellt möglicherweise das dar, was nicht im Dokument enthalten ist.
• Grenzen ignorieren: Einige Aufgaben nicht zu automatisieren ist die richtige Entscheidung; Transparenz und Verantwortung liegen bei Ihnen.

Tiefer: Release-Management, Rollback und inkrementelle Bereitstellung

Bei der Einführung einer LLM-Funktion in die Produktion geht es nicht darum, sie einzurichten und dann zu vergessen; besteht darin, ein Live-System im Laufe der Zeit sicher zu ändern. Es hat drei Säulen.

Versionierung. Ihre Systemaufforderung, Modellauswahl und Überprüfungsregeln ändern sich im Laufe der Zeit. Versionieren Sie jede wesentliche Änderung und notieren Sie, welche Version live ist. Wenn eines Tages die Qualität sinkt: „Was haben wir geändert?“ Sie sollten die Frage innerhalb von Minuten beantworten können. In einem versionlosen System dauert es Tage, die Grundursache einer Regression zu finden.

Rollback. Wenn sich eine neue Eingabeaufforderung oder ein neues Modell im Live-Betrieb schlechter verhält als erwartet, sollten Sie in der Lage sein, schnell zur vorherigen, bekannten Version zurückzukehren. Eine Änderung ohne Rollback-Plan ist das blinde Eingehen eines Live-Risikos. „Ich habe etwas geändert, es ist schlimm geworden, ich kann nicht mehr zurück“ ist das teuerste Produktionsszenario.

Schrittweiser Rollout. Anstatt eine Änderung auf einmal auf den gesamten Datenverkehr anzuwenden, führen Sie sie zunächst auf einen kleinen Prozentsatz (z. B. 5 %) aus und überwachen Metriken (Qualität, Kosten, Fehler). Wenn es gut ist, erhöhen Sie den Prozentsatz; Wenn es schlecht ist, erhalten Sie es zurück, wobei nur ein kleiner Teil davon betroffen ist. Dadurch wird das Risiko erheblich begrenzt.

Diese drei Praktiken kombinieren Techniken aus allen vorherigen Einheiten: Evaluierung (Einheit 5) misst Änderungen im Voraus, Überwachung (diese Einheit) gibt während der Ausbreitung eine Frühwarnung, die Verifizierungsschicht fängt fehlerhafte Ausgaben ab, bevor sie umsetzbar werden. Bei der Produktion handelt es sich nicht um eine einzige korrekte Einrichtung; Es handelt sich um eine kontinuierliche Disziplin, die zuverlässig misst, überwacht und Änderungen vornehmen kann. Das gesamte Modul dient der Etablierung dieser Disziplin.

Zusammenfassend

Die Produktion ist mehr als eine funktionierende Demo: Sie ist eine Pipeline aus Eingabe-, Modell-, Verifizierungs-, Aktions- und Überwachungsebenen. Die Ausgabe ist ohne Überprüfung unzuverlässig; Entscheidungen mit großer Auswirkung sind an die Zustimmung des Menschen gebunden; Jeder Anruf wird auf Kosten, Fehler und Qualität überwacht. Ethik, Transparenz, Voreingenommenheitskontrolle, Rechenschaftspflicht und Akzeptanz von Grenzen sind wesentliche Bestandteile technischer Entscheidungen. Alle in diesem Modul gelernten Teile kommen in diesem ganzheitlichen Design zusammen.

Anwendungsaufgabe

Entwerfen Sie eine LLM-Funktion durchgängig. (1) Füllen Sie die fünf Ebenen (Eingabe, Modell, Verifizierung, Aktion, Überwachung) für Ihre spezifische Aufgabe aus. (2) Markieren Sie anhand der Auswirkungen, welche Entscheidungen eine menschliche Zustimmung erfordern. (3) Schreiben Sie mindestens drei Validierungsprüfungen (Schema, Regel, Quelle). (4) Bestimmen Sie die wichtigsten Kennzahlen, die Sie verfolgen, und die, die Sie nicht protokollieren. (5) Schreiben Sie in dieser Funktion eine Grenze und einen ethischen Grundsatz auf, den Sie akzeptieren.

Checkliste

• [ ] Ich kann fünf Schichten der Produktionspipeline entwerfen.
• [ ] Ich kann die Ausgabe anhand von Schema, Regel und Quelle validieren.
• [ ] Ich kann eine menschliche Zustimmungsschwelle basierend auf den Auswirkungen der Entscheidung festlegen.
• [ ] Ich überwache Kosten, Fehler und Qualität und schreibe keine sensiblen Daten in Protokolle.
• [ ] Ich kann Ethik, Verantwortung und Grenzen in Produktionsentscheidungen umsetzen.

Modulprüfung

1. Was macht die Rolle „System“ in einer LLM-Chat-API?

• A) Gibt dem Model dauerhafte Anweisungen und Verhaltensregeln, die während des gesamten Gesprächs gelten ✔
• B) Behält die letzte vom Benutzer geschriebene Frage
• C) Speichert die vom Modell erzeugte Antwort
• D) Verschlüsselt den API-Schlüssel

Beschreibung: Die Systemrolle gibt dem Modell dauerhafte Anweisungen, Persönlichkeit und Regeln, die während des gesamten Gesprächs gelten; Es handelt sich um eine Weiterleitung auf hoher Ebene, getrennt von Benutzernachrichten.

2. Warum wird der Konversationsverlauf (vorherige Nachrichten) jedes Mal in einer API-Anfrage erneut gesendet?

• A) Es ist eine Sicherung erforderlich, da der Server den Verlauf löscht
• B) API-Aufrufe sind zustandslos; ✔ Der Kontext wird bei jeder Anfrage erneut gesendet, da sich das Modell nicht an den Verlauf erinnert
• C) Nur für die Rechnungsstellung erforderlich, hat keine Auswirkung auf das Modell
• D) Das Senden des Verlaufs ist obligatorisch, um eine Verlangsamung der Antwort zu vermeiden

Erläuterung: LLM-API-Aufrufe sind zustandslos; Das Modell erinnert sich nicht an frühere Runden, sodass der gesamte relevante Verlauf bei jeder Anfrage erneut gesendet wird, um den Kontext beizubehalten.

3. Was ist ein „Token“ bei der LLM-Preisgestaltung?

• A) Einmalpasswort zur Anmeldung bei der API
• B) Eine feste Gebühr, die für jede Anfrage gezahlt wird
• C) Die kleinste Einheit, in der das Modell den Text verarbeitet; entspricht normalerweise dem Wortteil ✔
• D) Eine Einheit, die nur die Länge der Ausgabe misst

Beschreibung: Token ist die kleinste Einheit, in der das Modell Text verarbeitet. Es entspricht normalerweise einem Wortfragment und sowohl die Eingabe als auch die Ausgabe werden basierend auf der Anzahl der Token berechnet.

4. Warum sind Output-Tokens bei den meisten LLM-Anbietern teurer als Input-Tokens?

• A) Ausgabe-Tokens sind immer länger als Eingabe-Tokens
• B) Eingabetokens sind kostenlos
• C) Ausgabetoken werden zweimal über das Internet gesendet
• D) Die Stückkosten sind höher, da die Ausgabegenerierung zusätzliche Berechnungen für jeden Token erfordert ✔

Beschreibung: Für jedes Ausgabe-Token muss das Modell eine schrittweise Generierung (Berechnung) durchführen. Diese Produktionskosten sind höher als die Verarbeitung des gesamten Inputs, sodass der Output-Stückpreis normalerweise höher ist.

5. In welcher Situation ist die Nutzung von Streaming am vorteilhaftesten?

• A) In langen Antworten; Reduziert die wahrgenommene Verzögerung und verhindert Zeitüberschreitungen ✔
• B) Nur in sehr kurzen Ein-Wort-Antworten
• C) Um die Kosten auf Null zu reduzieren
• D) Um den API-Schlüssel auszublenden

Beschreibung: Bei langen Antworten reduziert Streaming die wahrgenommene Latenz, indem die ersten Wörter sofort angezeigt werden, und verhindert HTTP-Zeitüberschreitungen bei großen max_tokens-Werten.

6. Welche Auswirkungen hat die Erhöhung des Parameters „Aufwand“ in modernen Modellen im Allgemeinen?

• A) Kürzen Sie die Antwort immer
• B) Rotiert den API-Schlüssel automatisch
• C) Es reduziert lediglich den Input-Token-Preis
• D) Erhöht die Denktiefe und die Token-Ausgaben; Es verbessert möglicherweise die Qualität, erhöht aber auch die Latenz und die Kosten ✔

Beschreibung: Der Aufwandsparameter passt an, wie intensiv das Modell über eine Aufgabe nachdenkt und wie viele Token es ausgibt; Ein Upgrade verbessert möglicherweise die Qualität, erhöht jedoch auch die Latenz und die Kosten. Für einfache Aufgaben genügt ein geringer Aufwand.

7. Was ist im Allgemeinen der kostengünstigste Ansatz für eine einfache, umfangreiche Klassifizierungsaufgabe?

• A) Verwenden Sie immer das teuerste und leistungsstärkste Modell
• B) Bei jeder Anfrage alle Modelle gleichzeitig anrufen
• C) Auswahl des leichtesten/billigsten Modells, das die Aufgabe erfüllt, indem es mit einer kleinen Evaluierung verifiziert wird ✔
• D) Den max_tokens-Wert unnötigerweise zu hoch halten

Erläuterung: Wenn die Aufgabe nicht komplex ist, können die Kosten durch die Wahl eines schnelleren und günstigeren Modells, das die Aufgabe problemlos bewältigt (z. B. Haiku-Klasse), anstelle des teuersten und leistungsstärksten Modells erheblich gesenkt werden.

8. In welchem ​​Szenario reduziert Prompt Caching die Kosten am meisten?

• A) Wenn ein großer und fester Kontext wiederholt über viele Anfragen hinweg verwendet wird ✔
• B) Wenn bei jeder Anfrage ein völlig anderer Text gesendet wird
• C) Wenn nur eine einzige Anfrage gestellt wird
• D) Um die ausgegebenen Token zu reduzieren

Beschreibung: Beim Caching handelt es sich um eine Präfixübereinstimmung. In Fällen, in denen ein großer, unveränderlicher Kontext (Systemaufforderung, Dokumente) über viele Anfragen hinweg wiederverwendet wird, kostet das Lesen aus dem Cache nur einen kleinen Bruchteil (~0,1x) des Gesamtpreises.

9. Wie muss ich die Eingabeaufforderung bearbeiten, damit der Eingabeaufforderungscache zutrifft?

• A) Variable Inhalte am Anfang und feste Inhalte am Ende platzieren
• B) Betten Sie für jede Anfrage das aktuelle Datum und die aktuelle Uhrzeit in die Systemaufforderung ein
• C) Festen Inhalt (Systemeingabeaufforderung, Dokumente) am Anfang und variablen Inhalt am Ende platzieren ✔
• D) Ändern der Reihenfolge der Werkzeugliste bei jeder Anfrage

Erläuterung: Da es sich beim Cache um eine Präfixübereinstimmung handelt, werden feste/unveränderliche Inhalte (Systemeingabeaufforderung, Dokumente) initialisiert; Der variable Inhalt (Datum, Benutzerfrage, Anfrage-ID) wird ans Ende gestellt. Selbst ein einzelnes Byte, das zu Beginn geändert wird, führt dazu, dass der Cache ungültig wird.

10. Für welche Art von Arbeitslast ist die Stapelverarbeitung am besten geeignet?

• A) Live-Chat, bei dem der Benutzer eine sofortige Antwort auf dem Bildschirm erwartet
• B) Nur eine kurze Frage
• C) API-Schlüssel generieren
• D) Aufträge, die verzögerungstolerant sind, ein großes Volumen haben und keine sofortigen Ergebnisse erfordern ✔

Beschreibung: Die Stapelverarbeitung eignet sich für große Mengen an Aufträgen, die keine sofortige Reaktion erfordern und Verzögerungen tolerieren. Ergebnisse werden nach einiger Zeit geliefert, aber die Stückkosten sind normalerweise niedriger.

11. Was wird verwendet, um sicher zuzuordnen, zu welcher Anfrage die Ergebnisse in einem Stapel gehören?

• A) Senden der Reihenfolge (Position) der Anfragen
• B) Länge der Antworten
• C) Letzte 4 Ziffern des API-Schlüssels
• D) Eine eindeutige benutzerdefinierte_ID, die jeder Anfrage zugewiesen wird ✔

Anmerkung: Massenergebnisse können in einer anderen Reihenfolge als der Übermittlungsreihenfolge zurückgegeben werden; Daher ist es notwendig, die Ergebnisse nach ID und nicht nach Standort abzugleichen, wobei jeder Anfrage eine eindeutige benutzerdefinierte_ID zugewiesen wird.

12. Welches Verhalten wird empfohlen, wenn Sie von der API den Fehler 429 (Ratenbegrenzung) erhalten?

• A) Erzwingen, indem viele weitere Anfragen gleichzeitig gesendet werden
• B) Erneuter Versuch mit exponentiellem Backoff, gefolgt von der Überschrift „Retry-After“ ✔
• C) Brechen Sie die Anfrage vollständig ab und zeigen Sie dem Benutzer den Fehler als Absturz an
• D) Ändern des API-Schlüssels

Erläuterung: 429 ist ein wiederholbarer Fehler; Der richtige Ansatz besteht darin, es erneut mit exponentiellem Backoff zu versuchen und dabei den Retry-After-Header zu berücksichtigen. Die meisten offiziellen SDKs erledigen dies automatisch.

13. Welche der folgenden HTTP-Fehlercodes gelten im Allgemeinen als wiederholbar?

• A) 400 (ungültige Anfrage)
• B) 401 (Authentifizierungsfehler)
• C) 529 (Server überlastet) ✔
• D) 404 (nicht gefunden)

Erläuterung: 429 (Geschwindigkeitsbegrenzung), 500 (Serverfehler) und 529 (Überlastung) sind vorübergehende Fehler und können durch Zurücksetzen erneut versucht werden. Fehler wie 400 und 401 sind Anfrage-/Identitätsprobleme; Ein erneuter Versuch wird das Problem nicht lösen.

14. Welche der folgenden Möglichkeiten ist die sichere Verwaltung von API-Schlüsseln?

• A) Speichern in der Umgebungsvariablen/im versteckten Manager, nicht in den Code einbetten und regelmäßig rotieren ✔
• B) Schreiben Sie den Schlüssel direkt in den Quellcode und senden Sie ihn an das Repository
• C) Einfügen des Schlüssels in clientseitiges (Browser-)JavaScript
• D) Teilen eines einzelnen Schlüssels mit dem gesamten Team per E-Mail

Beschreibung: Schlüssel werden niemals in den Quellcode oder das Repository geschrieben; Es wird in einer Umgebungsvariablen oder einem versteckten Verwaltungstool gespeichert, mit minimalen Berechtigungen gewährt und regelmäßig rotiert.

15. Was ist im Hinblick auf den Datenschutz der beste Ansatz für die LLM-Integration mit einem Automatisierungstool (n8n, Zapier, Make)?

• A) Alle Rohdaten an das Modell senden, auch wenn dies nicht erforderlich ist
• B) Schreiben des API-Schlüssels im Klartext innerhalb des Flow-Schritts
• C) Minimierung und Maskierung sensibler Daten und Speicherung des Schlüssels als geheime Anmeldeinformationen ✔
• D) Persönliche Daten dauerhaft im Flow-Verlauf speichern

Beschreibung: Da die Automatisierung der Dateneingabe Systeme und Modelle von Drittanbietern durchläuft, müssen sensible/personenbezogene Daten minimiert und maskiert werden und es müssen nur erforderliche Felder gesendet werden. Der API-Schlüssel wird auch als geheime Anmeldeinformationen im Tool gespeichert.

16. Warum ist die Validierung der Ausgabe in einer LLM-basierten Produktionsfunktion obligatorisch?

• A) Es ist nur eine Formatierung erforderlich, da das Modell keine Fehler macht
• B) Weil das Modell flüssig, aber manchmal falsch produzieren kann; Das Schema/die Regel muss mit der Genehmigung von Ressourcen und Menschen geprüft werden ✔
• C) Eine Validierung sollte vermieden werden, da sie nur die Kosten erhöht
• D) Die Verifizierung dient nur dazu, die Anzahl der Token zu reduzieren

Beschreibung: LLMs können flüssige, aber manchmal ungenaue (halluzinatorische) Ergebnisse liefern; es kam also zu Entscheidungen mit großer Auswirkung; Es sollte bei Bedarf durch Schema-/Regelprüfung, Quellenvalidierung und menschliche Genehmigung geprüft werden.