KI-Features: handeln und betreiben — Cheat Sheet

Der Spickzettel zur zweiten Hälfte des Seminars KI-Features im eigenen Produkt: Sobald das Feature Werkzeuge aufruft, Vorgänge auslöst und in Betrieb geht. Wie belegbare Antworten überhaupt entstehen — Aufgabentypen, Aufruf, Schema, Retrieval —, steht auf dem ersten Blatt: KI-Features: belastbar antworten.

Maßgeblich für API-Details ist die Herstellerdokumentation; dieses Blatt trifft eine Auswahl — die Entscheidungsraster, die einen Modellwechsel überleben.

Werkzeuge: lesend und schreibend trennen

Lesend und schreibend werden im Code getrennt gehalten, nicht nur in der Tabelle: jede schreibende Aktion ist bestätigungspflichtig.

Die Werkzeugbeschreibung ist selbst ein Prompt — sie braucht den Zweck in einem Satz, wann das Werkzeug zu verwenden ist und wann ausdrücklich nicht, was es zurückgibt und welche Einschränkungen gelten:

{
  "name": "verfuegbarkeit_pruefen",
  "description": (
      "Prüft den Lagerbestand zu einer aktiven "
      "Katalognummer. Nur für aktive Nummern; "
      "ausgelaufene Teile über teil_suchen. "
      "Gibt Bestand und Lieferzeit zurück."),
  "input_schema": SCHEMA_KATALOGNUMMER,
}

Ohne den Hinweis auf ausgelaufene Teile ruft das Modell die Prüfung falsch auf.

Modul: Werkzeuge: das Modell darf handeln

Fehlermeldungen gehen in den Prompt

Ein Werkzeugfehler ist kein Ausnahmefall, sondern ein Ergebnis — er wird zurückgegeben, damit das Modell sinnvoll weitermachen kann. Keine Stapelabbilder und keine Datenbankfehler im Klartext: Sie landen im Kontext.

Modul: Werkzeuge: das Modell darf handeln

Workflow oder Agent

Im Zweifel Workflow — der Umbau zum Agenten ist später leicht, der Rückbau nicht. Fällt die Wahl auf einen Agenten, stellt sich die Frage nach der Bauform:

Für Features auf internen Systemen sind die ersten beiden meist die richtige Wahl: Die Werkzeuge bleiben im eigenen Code und unter eigenen Rechten. Jede Schleife braucht einen Deckel — nach Runden und nach Kosten:

for runde in range(MAX_RUNDEN):
    antwort = aufruf(verlauf)
    if antwort.stop_reason != "tool_use":
        return antwort
    if kosten.ueberschritten():
        return abbruch("Kostendeckel", verlauf)
    verlauf += werkzeuge_ausfuehren(antwort)
return abbruch("Rundenzahl", verlauf)

Modul: Vom Workflow zum Agenten

Wenn der Kontext wächst

Die letzte Zeile ist für die meisten Produktfeatures die richtige Antwort. Wer zusammenfasst, verliert leicht den Beleg — und bricht damit die Belegpflicht.

Modul: Vom Workflow zum Agenten

Goldstandard und Prüfungen nach Aufwand

Erzeugte Fragen sind zu glatt und treffen die Sprache der Nutzer nicht — der Datensatz entsteht aus echten Fällen.

Die Reihenfolge hält den teuren Teil klein — das ist ihr eigentlicher Zweck. Ein Modell als Prüfer hat bekannte Schlagseiten: Es bevorzugt längere Antworten und den eigenen Stil, besonders bei gleichem Modell auf beiden Seiten. Ohne Kalibrierung gegen menschliche Urteile bleibt die Zahl bedeutungslos.

Modul: Evaluierung: die Qualität messbar machen

Angriffsfläche und Gegenmittel

Die Gegenmittel sitzen im Code, nicht im Prompt. Prompt Injection kommt dabei nicht nur aus der Eingabe: Alles, was indiziert wird, kann eine Anweisung enthalten — Tickets, Anhänge, PDF fremder Herkunft. Werkzeugergebnisse sind nicht vertrauenswürdiger als Nutzereingaben.

Rechte werden unabhängig vom Modell geprüft, mit der Identität aus der Sitzung:

def rueckruf_anlegen(args, sitzung):
    werkstatt = sitzung.werkstatt_id   # nie aus args
    if not darf_rueckruf(werkstatt):
        return fehler("nicht berechtigt")
    return vorschlag_anlegen(werkstatt, args)

Steht die Kennung in args, kann das Modell eine andere liefern — die Prüfung wäre wertlos.

Die sechs Fragen vor der Auslieferung: Sind fremde Inhalte im Prompt gekennzeichnet? Prüft der Code Rechte unabhängig vom Modell? Ist jede schreibende Aktion bestätigungspflichtig? Wird die Ausgabe maskiert und validiert? Gibt es Grenzen für Länge, Häufigkeit und Kosten? Ist protokolliert, was zur Aufklärung nötig ist?

Modul: Sicherheit

Latenz zerlegen, statt das Modell zu wechseln

Das Modell zu wechseln ist selten der erste und fast nie der beste Schritt. Wo Antwortzeit keine Rolle spielt — nächtliche Auswertungen, Vorabklassifizierung, Zusammenfassungen —, gehört die Arbeit in die Stapelverarbeitung.

Der Cache fällt lautlos aus. Er erzeugt keinen Fehler, nur Kosten, und die Ursache ist ohne Kennzahl praktisch nicht zu finden. Die vier häufigsten: Datum oder Uhrzeit in der Systemanweisung · eine Vorgangsnummer im Vorspann statt in der Nutzernachricht · eine je Nutzer anders sortierte Werkzeugliste · ein Datenobjekt ohne stabile Feldreihenfolge.

Modul: Kosten, Latenz und Betrieb

Was protokolliert wird

Nutzerkennungen pseudonymisiert, Löschfristen vor dem Start festlegen. Vier Kennzahlen tragen den laufenden Betrieb: Verweigerungsquote und Anteil unplausibler Antworten, Trefferquote des Caches, Kosten je Vorgang, Latenz je Abschnitt.

Modul: Kosten, Latenz und Betrieb

Typische Fallen

• Werkzeugrechte am Modell festmachen statt an der Sitzung.
• Nebenläufigkeit einbauen, ohne die Werkzeuge dafür sicher zu machen — oder ein fehlgeschlagenes Ergebnis weglassen und Wiederholungen provozieren.
• Den Verlauf unbegrenzt wachsen lassen und die Grenze im Betrieb entdecken.
• Kontextpflege einbauen, obwohl der Vorgang von Natur aus kurz ist.
• Zusammenfassungen erzeugen, ohne ihre Qualität je zu prüfen.
• Erzeuger und Prüfer dasselbe Modell sein lassen.
• Bei rotem Evaluierungslauf die Grenze senken statt die Ursache zu suchen.
• Den Evaluierungslauf nur von Hand starten und ihn nach drei Wochen vergessen.
• Die Abwehr gegen Prompt Injection allein in die Systemanweisung schreiben.
• Ein internes Datenobjekt vollständig zurückgeben, weil es gerade zur Hand ist.
• Protokolldaten in den Prompt spiegeln, um das Debuggen zu erleichtern.
• Die Trefferquote des Caches nicht überwachen — der Ausfall zeigt sich erst auf der Rechnung.

Zum Seminar KI-Features im eigenen Produkt