0Pricing
AI Prompt Engineering · Lektion

Die Entscheidung bewerten

Qualität und Kosten messen

Die Entscheidung bewerten ist eine kostenlose AI Prompt Engineering-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AI Prompt Engineering-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AI Prompt Engineering-Kurs umfasst insgesamt 4 Lektionen.

Was Sie nicht messen, können Sie nicht entscheiden

Die Entscheidung zwischen Prompting, Tuning und einem hybriden Ansatz ist nur so gut wie die dahinterstehende Evaluation. Ohne ein eingefrorenes Eval-Set und ein Kostenmodell ist jeder Vergleich nur eine Anekdote.

  • Qualität und Kosten sind zwei Achsen – reduzieren Sie sie niemals vorzeitig auf eine einzige Zahl
  • Das Eval-Set muss für jeden verglichenen Ansatz zurückgehalten werden und unverändert bleiben
  • Der Gewinner ist der Ansatz am besten geeigneten Punkt der Qualitäts-Kosten-Grenze für Ihre Einschränkungen

Zuerst das eingefrorene Eval-Set erstellen

Erstellen Sie vor jedem Vergleich ein zurückgehaltenes Eval-Set, mit dem kein Ansatz trainiert wird. Es muss die reale Verteilung abdecken: häufige Fälle, bekannte Randfälle und adversariale Eingaben ungefähr in den Anteilen der Produktion.

Frieren Sie es ein. Jeder Ansatz – nur Prompt, getunt oder hybrid – wird auf demselben Set bewertet. Wenn sich das Eval-Set zwischen den Vergleichen verändert, sind die Zahlen nicht vergleichbar und die Entscheidung ist ungültig.

def split_eval(labeled, holdout_ratio=0.2, seed=42):
    import random
    rng = random.Random(seed)        # fixed seed = reproducible split
    data = labeled[:]
    rng.shuffle(data)
    cut = int(len(data) * (1 - holdout_ratio))
    train, frozen_eval = data[:cut], data[cut:]
    return train, frozen_eval        # eval never enters any training run

Metriken passend zur Aufgabe auswählen

Generische Genauigkeit verschleiert aufgabenspezifische Fehler. Wählen Sie Metriken, die das tatsächlich Relevante erfassen:

  • Exact Match/Schema-Match für strukturierte Ausgaben
  • Anhand einer Rubrik bewertetes LLM-as-judge für offene Qualitätsfragen, ergänzt durch eine von Menschen geprüfte Stichprobe
  • Tail-Metriken – Worst Case und p95, nicht nur der Mittelwert
  • Sicherheits-/Ablehnungsraten als harte Grenzwerte, getrennt von der Qualität bewertet

Ein Mittelwert, der einen katastrophalen Tail verschleiert, führt Sie zur falschen Entscheidung.

Jeden Kandidaten identisch bewerten

Lassen Sie nur Prompt, getunte und hybride Kandidaten durch den gleichen Scorer auf demselben eingefrorenen Set laufen. Erfassen Sie für jeden Kandidaten neben der Qualität den vollständigen Kostenvektor, damit die Vergleiche fair sind.

def evaluate(candidate, frozen_eval, scorer):
    results = []
    for ex in frozen_eval:
        out = candidate.run(ex['input'])
        results.append(scorer(out, ex['label']))
    mean = sum(results) / len(results)
    p95 = sorted(results)[int(0.95 * len(results)) - 1]
    return {'mean': mean, 'p95_worst': p95}

# Identical frozen_eval + scorer for prompt / tuned / hybrid

Den vollständigen Kostenvektor modellieren

Kosten sind keine einzelne Zahl. Erfassen Sie jede Komponente, damit der Vergleich bei Ihrem Anfragevolumen der Realität entspricht:

  • Inference pro Aufruf: Eingabe- plus Ausgabetokens multipliziert mit dem Preis (lange Prompts kosten pro Aufruf mehr)
  • Amortisiertes Training: Tuning-Kosten verteilt auf das erwartete Anfragevolumen
  • Wartung: Datenpipeline, Eval-Läufe und erneutes Tuning bei Änderungen des Basismodells
  • Latenz: separat bepreist, wenn sie sich auf Conversion oder User Experience auswirkt
def monthly_cost(calls, in_tok, out_tok, price_in, price_out,
                 train_cost=0.0, months_amortized=12):
    inference = calls * ((in_tok/1000)*price_in + (out_tok/1000)*price_out)
    amortized_train = train_cost / months_amortized
    return inference + amortized_train

# Long prompt-only: high in_tok, train_cost=0
# Tuned: low in_tok, train_cost>0 amortized over volume

Die Qualitäts-Kosten-Grenze darstellen

Tragen Sie die Kandidaten anhand ihrer Qualität und monatlichen Kosten auf einer Grenze auf. Ein Kandidat ist dominiert, wenn ein anderer sowohl eine höhere Qualität als auch geringere Kosten bietet; entfernen Sie dominierte Kandidaten.

Unter den nicht dominierten Kandidaten hängt die richtige Wahl von Ihrer Einschränkung ab: Wählen Sie den günstigsten Kandidaten, der die Qualitätsschwelle erfüllt, oder die höchste Qualität innerhalb der Kostenobergrenze. Die Entscheidung ist nun explizit und begründbar statt eine Frage der persönlichen Präferenz.

def non_dominated(candidates):
    # candidate: {'name','quality','cost'} -- higher quality, lower cost better
    keep = []
    for c in candidates:
        dominated = any(o['quality'] >= c['quality'] and o['cost'] <= c['cost']
                        and o != c for o in candidates)
        if not dominated:
            keep.append(c)
    return keep

Statistische Signifikanz statt Rauschen

Eine Verbesserung um zwei Punkte bei einer Evaluation mit 200 Beispielen kann reines Rauschen sein. Bevor Sie einen Gewinner bestimmen, prüfen Sie, ob der Qualitätsunterschied angesichts der Größe Ihres Eval-Sets statistisch aussagekräftig ist.

Verwenden Sie einen gepaarten Vergleich (dieselben Beispiele durch beide Kandidaten) und ein Konfidenzintervall für die Differenz. Wenn das Intervall null einschließt, liegt keine echte Verbesserung vor – die zusätzlichen Kosten des Tunings sind dann nicht gerechtfertigt.

def paired_diff_ci(scores_a, scores_b):
    import statistics
    diffs = [a - b for a, b in zip(scores_a, scores_b)]
    mean = statistics.mean(diffs)
    sd = statistics.pstdev(diffs)
    se = sd / (len(diffs) ** 0.5)
    return (mean - 1.96*se, mean + 1.96*se)  # if it spans 0 -> not significant

Eval-Leakage verhindern

Der schnellste Weg, Tuning fälschlich gut aussehen zu lassen, ist Eval-Leakage – Trainingsbeispiele, die sich mit dem Eval-Set überschneiden. Ein geleaktes Eval-Set belohnt das Auswendiglernen und lässt den Score des getunten Kandidaten künstlich steigen.

Entfernen Sie Duplikate über die Grenze zwischen Training und Evaluation, prüfen Sie auf nahezu identische Duplikate und bevorzugen Sie ein zeitlich getrenntes Eval-Set (nach Datum zurückgehalten), damit das getunte Modell es nicht gesehen haben kann. Leakage ist die häufigste Ursache für eine Tuning-Entscheidung, die in der Produktion scheitert.

Nach dem Ausliefern überwachen

Die Entscheidung ist mit dem Launch nicht endgültig. Die Verteilung der Produktionsdaten driftet, und ein getuntes Modell kann sich unbemerkt verschlechtern, wenn sich die Eingaben von seiner Trainingsverteilung entfernen.

  • Stichproben aus dem Live-Traffic ziehen und anhand derselben Rubrik bewerten
  • Bei Qualitätsverlusten und steigenden Kosten pro Aufruf alarmieren
  • Das eingefrorene Eval-Set erneut ausführen, sobald sich die Version des Basismodells ändert

Betrachten Sie den gewählten Ansatz als Hypothese unter kontinuierlicher Prüfung, nicht als abgeschlossene Entscheidung.

Entscheidungsprotokoll

Halten Sie den Vergleich in einem schriftlichen Entscheidungsprotokoll fest: das eingefrorene Eval-Set, den Qualitäts- und Kostenvektor jedes Kandidaten, das Ergebnis der Signifikanzprüfung, das angenommene Anfragevolumen sowie den gewählten Punkt auf der Grenze mit seiner Begründung.

So wird die Entscheidung nachvollziehbar und erneut überprüfbar. Wenn sich das Volumen oder das Basismodell ändert, öffnen Sie das Protokoll erneut und führen Sie den Vergleich noch einmal durch, statt die Entscheidung aus dem Gedächtnis neu zu diskutieren.

End-to-End-Entscheidungsfunktion

Führen Sie alles zusammen: Bewerten Sie jeden Kandidaten auf dem eingefrorenen Eval-Set, fügen Sie seine Kosten hinzu, verwerfen Sie dominierte Optionen, verlangen Sie gegenüber der günstigsten Baseline statistische Signifikanz und wählen Sie anschließend anhand Ihrer bindenden Einschränkung.

def decide(candidates, quality_bar, cost_ceiling):
    frontier = non_dominated(candidates)
    feasible = [c for c in frontier
                if c['quality'] >= quality_bar and c['cost'] <= cost_ceiling]
    if not feasible:
        return 'NO_CANDIDATE_MEETS_CONSTRAINTS'
    # cheapest option that clears the quality bar
    return min(feasible, key=lambda c: c['cost'])['name']

# Prefer prompt-only on ties: lower maintenance TCO

Kurzer Test

Ein getuntes Modell erzielt bei einer Evaluation mit 150 Beispielen zwei Punkte mehr als Prompting, aber ein gepaartes Konfidenzintervall für die Differenz umfasst null. Außerdem kostet es pro Monat mehr. Was ist die richtige Entscheidung?

Zusammenfassung

Entscheiden Sie anhand eines eingefrorenen Evals und eines ehrlichen Kostenvektors, nicht nach Intuition. Qualität und Kosten sind zwei Achsen; die Antwort ist ein Punkt auf der Qualitäts-Kosten-Grenze, gewählt anhand Ihrer bindenden Einschränkung.

  • Ein Eval-Set einfrieren und jeden Kandidaten darauf identisch bewerten
  • Aufgabengerechte Metriken auswählen und den Tail statt nur des Mittelwerts beobachten
  • Den vollständigen Kostenvektor modellieren und Trainingskosten auf das reale Volumen umlegen
  • Statistische Signifikanz verlangen; ein Konfidenzintervall, das null einschließt, ist keine Verbesserung
  • Eval-Leakage verhindern – die häufigste Ursache für scheinbare Tuning-Erfolge
  • Nach dem Launch überwachen und die Entscheidung dokumentieren, damit sie erneut ausgeführt werden kann

Häufig gestellte Fragen

Ist die Lektion „Die Entscheidung bewerten“ kostenlos?

Ja — der vollständige Text von „Die Entscheidung bewerten“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AI Prompt Engineering-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AI Prompt Engineering-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Die Entscheidung bewerten“?

Qualität und Kosten messen Du übst AI Prompt Engineering mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um AI Prompt Engineering zu starten?

Keine Vorkenntnisse erforderlich. AI Prompt Engineering auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Die Entscheidung bewerten“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser AI Prompt Engineering-Lektion Code schreiben und ausführen?

Ja. Jede AI Prompt Engineering-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Wann Prompting ausreicht
  2. Wann Fine-Tuning sinnvoll ist
  3. Hybrid: Prompting plus leichtes Tuning
  4. Die Entscheidung bewerten
← Zurück zu AI Prompt Engineering