Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fortgeschrittene Themen und Strategien

Themen auf dieser Seite

Multi-objective Optimierung

Advanced Prompt Optimization akzeptiert eine Metrik pro Lauf — einen einzelnen Skalarwert pro Stichprobe. Es unterstützt jedoch implizit die Optimierung mit mehreren Zielen (mehreren Dimensionen): Sie können mehrere Ziele in einem Skalar (einer zusammengesetzten Metrik) bündeln, und der Service optimiert die Aufforderung anhand dieses Pakets. In diesem Abschnitt werden die von uns empfohlenen Muster behandelt, sofern sie jeweils angemessen sind, und die Fehlerarten, auf die Sie achten sollten.

Das gilt für alle Branchen — überall dort, wo Ihnen mehr als eine Sache gleichzeitig wichtig ist: Genauigkeit + Ton, Korrektheit beim Tool-Call + Sicherheit, Zuverlässigkeit + Prägnanz, Latenzfreundlichkeit + Vollständigkeit und mehr.

Warum eine Metrik eigentlich mehrere Ziele umfasst

Zwei Fakten über das System sorgen dafür, dass es funktioniert:

Bei „einer Metrik pro Lauf“ handelt es sich also um einen Vertrag über die Signalform und nicht um eine Begrenzung dessen, wofür Sie optimieren können.

Muster für die Bündelung mehrerer Ziele in einer einzigen Metrik

Wählen Sie eines davon aus, in welchem Verhältnis Ihre Ziele zueinander stehen.

Muster 1 — Gewichtete Summe (am häufigsten)

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ, wobei sich die Gewichtungen zu 1 summieren.

Verwendungszweck: Die Ziele sind in etwa unabhängig voneinander und können nach einer Rangfolge geordnet werden. Trade-offs sind akzeptabel — es ist in Ordnung, eines auf Kosten eines anderen zu verbessern, solange die Summe steigt.

Gewichte wählen:

Beispiel (agentic//tool-use):

final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance

Muster 2 — Hard-fail Tore (sicherheitskritisch)

Definieren Sie ein oder mehrere Torziele. Wenn ein Tor versagt, ist der Punktestand 0 (oder ein Stockwerk), unabhängig vom Rest. Andernfalls ist die Punktzahl die gewichtete Summe der verbleibenden Ziele.

if not safety_check_passed:
    return 0.0
if wrong_tool_called_for_destructive_action:
    return 0.0
return 0.6 * accuracy + 0.4 * tone

Verwendungszweck: Mindestens ein Ziel ist nicht verhandelbar (PII-Leak, falsches Konto geändert, Ablehnung verbotener Inhalte). Verwenden Sie diese Option immer dann, wenn die Aufforderung „durchschnittlich gut“ nicht akzeptabel ist, wenn sie auch nur gelegentlich die Sicherheitsleiste nicht erfüllt.

Warum das besser ist als bloße Gewichtung: Mit Gewichten allein kann der Optimierer Sicherheit gegen Qualität eintauschen und trotzdem den Punktestand erklimmen. Ein Tor macht den Kompromiss baulich unmöglich.

Muster 3 — Einschränkung + Belohnung () Pareto-style

Wählen Sie das wichtigste Ziel als Belohnung aus. Drücken Sie den Rest als Einschränkungen aus, die, wenn sie verletzt werden, von der Belohnung abziehen (anstatt sie auf Null zu setzen).

reward = task_accuracy
penalty = 0.0
if response_too_long:
    penalty += 0.1
if missed_required_disclosure:
    penalty += 0.2
return max(0.0, reward - penalty)

Verwendungszweck: Sie möchten, dass ein primäres Ziel die Führung übernimmt, aber weiche sekundäre Ziele sollten die Aufforderung immer noch prägen. Weniger spröde als harte Gates, weniger zweideutig als gewichtete Summen.

Muster 4 — Lambda außen, LLM-as-a-Judge innen (empfohlen für Fuzzy+-Strukturmischungen)

Eine Lambda-Metrik berechnet deterministische Teilwerte (Regex, JSON-Analyse, Schemavalidierung) und ruft eine LLM-as-a-Judge Unterbewertung für die unscharfen Teile (Ton, Treue, Hilfsbereitschaft) innerhalb der Lambda-Funktion auf. Anschließend werden sie zu einem Skalar zusammengefasst.

def compute_score(prompt, prediction, gold, ...):
    structural = grade_format_and_tools(prediction)        # 0..1 from regex
    semantic   = call_llm_judge(prediction, gold, criteria) # 0..1 from LLMJ
    if structural < 1.0 and is_safety_critical(prompt):
        return 0.0
    return 0.6 * semantic + 0.4 * structural

Einsatzzweck: Ihre Ziele sind eine Mischung aus „einfach im Code zu testen“ (Formate, Namen der Tools, Länge, Vorhandensein von Zitaten) und „braucht ein Modell, das beurteilt werden kann“ (Tonfall, Treue, Hilfsbereitschaft). Das ist oft sauberer, als eine einzige LLM-as-a-Judge Aufforderung zur Erstellung eines einzigen zusammengesetzten Ergebnisses aufzufordern, da die deterministischen Teile nicht von Lauf zu Lauf abweichen.

Muster 5 — Multi-dimension LLM-as-a-Judge (kein Lambda)

Verwenden Sie den integrierten LLM-as-a-Judge Flow, optional mit einemcustomLLMJConfig.customLLMJPrompt, der Ihre eigenen Dimensionen und Gewichtungen definiert. Der Richter gibt Punktzahlen pro Dimension und einen ausOverall; das System analysiert die Dimensionen Overall (oder berechnet den Durchschnitt, falls sie fehlen) und Overall berechnet daraus einen Skalar [0, 1].

Verwendungszweck: Alle Ihre Ziele sind semantisch/unscharf und es gibt keine deterministischen Unterprüfungen. Am schnellsten zum Verfassen. Achten Sie auf die Beurteilungsvarianz — führen Sie denselben Datensatz zweimal durch und überprüfen Sie die Stabilität der Ergebnisse, bevor Sie ihm als Optimierungssignal vertrauen.

Ein Muster auswählen

Sie können Muster kombinieren. Eine typische Produktionskennzahl ist „gewichtete Summe plus eine harte Sicherheitslücke“.

Fehlerarten, auf die Sie achten sollten

Pre-launch Checkliste

Optimierung von Multi-Turn- und Staging-Prompts

Advanced Prompt Optimization optimiert eine einzelne Eingabeaufforderungsvorlage anhand von Bewertungen pro Probe. Es ist nicht systemintern rundenorientiert — es kann also nicht über einen Dialog iterieren oder das Verhalten bei einem bestimmten Zug nativ optimieren. Eine abgestufte Aufforderung ist eine Eingabeaufforderungsvorlage, bei der eine Konversation oder ein Workflow mit mehreren Runden dieselbe Aufforderung abwechselnd wiederverwendet, und die Aufforderung selbst enthält Anweisungen für jede Phase, jeden Schritt oder jede Phase des Workflows. Um diese Eingabeaufforderungen zu optimieren, reduzieren Sie den Status des Dialogs auf die Eingabevariablen der Vorlage, fügen Sie die Systemanweisungen, die Sie verfeinern möchten, ein und untersuchen Sie anhand von promptTemplate Referenzantworten pro Stichprobe die Züge, die Ihnen wirklich wichtig sind.

Dieses Muster ist vertikal unabhängig. Es gilt überall dort, wo ein Modell in wachsendem Kontext wiederholt aufgerufen wird — Kundenservice-Abläufe, Abläufe bei der Nutzung von Tools, mehrstufiges Denken, Nachhilfe, Wechsel von Code-Assistenten, dokumentengestützte Qualitätssicherung, Triage-Workflows und mehr.

Was Advanced Prompt Optimization tatsächlich optimiert

Alles, was Sie optimieren möchten, muss in sich promptTemplate selbst enthalten sein. Dinge, die je nach Beispiel variieren (der Konversationsverlauf, die aktuelle Benutzeranfrage, der abgerufene Kontext), sind{{variables}}. Die Systemanweisungen, die Sie verfeinern möchten, sind Teil der Vorlage — niemals eine Eingabevariable, oder der Dienst muss nichts umschreiben.

Wenn Sie möchten, dass der Service das Verhalten bei Turn N verbessert, geben Sie Turn N als gerenderte Eingabeaufforderung plus Eingabevariablen für ein Beispiel an, wobei referenceResponse es sich dabei um die gewünschte Turn-N-Modellausgabe handelt.

Muster A — (empfohlener Starter) Stage-at-a-time

Optimieren Sie jeweils eine Phase des Dialogs. Jede Bewertungsprobe steht für einen einzelnen Entscheidungspunkt innerhalb dieser Phase.

Eine „Phase“ ist hier alles, was Sie anhand eines kohärenten Satzes von Erfolgskriterien beschreiben können. Beispiele nach Branchen:

Wann sollte Muster A verwendet werden

Form der Vorlage

Die stufenspezifischen Systemanweisungen sind in die Vorlage integriert (dies wird vom Service neu geschrieben). Nur der Konversationsverlauf und der aktuelle Spielzug sind Variablen. Die folgende Struktur dient der Veranschaulichung und ist nicht vorgeschrieben. Verwenden Sie die Trennzeichen oder das Layout, mit dem Ihr Modell am besten umgehen kann. Die einzigen Anforderungen sind: (a) Die Systemanweisungen, die Sie optimieren möchten, befinden sich direkt in der Vorlage, und (b) auf die Variablen pro Probe wird verwiesen. {{variablename}}

You are an assistant in the {STAGE_NAME} phase of a multi-turn task.
- ...the policy / goals / format / tool-use rules for this phase...
- ...constraints the model must satisfy at this point in the conversation...

Conversation so far:
{{conversation_so_far}}

User's current message:
{{user_query}}

Form der Probe

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n... (turns 1..N-1)"},
        {"user_query": "...the user input that triggers this stage..."}
    ],
    "referenceResponse": "...the assistant output that satisfies the stage's success criteria..."
}

Vor- und Nachteile

Vorteile: Präzises Feedback-Signal, kleinere Eingabeaufforderungen, schnellere Optimierungsläufe, einfachere Erstellung einer zielgerichteten Metrik.

Nachteile: Erkennt keine catch zwischen den einzelnen Phasen. Sie führen den Service einmal pro Phase aus und benötigen möglicherweise einen abschließenden Integrationstest.

Muster B — Vollständige vereinfachte Konversation (fortgeschritten)

Optimieren Sie eine große monolithische Aufforderung, die für die gesamte mehrstufige Richtlinie zuständig ist. Jedes Beispiel umfasst den gesamten Dialog bis zu einer Testrunde.

Wann sollte Muster B verwendet werden

Form der Vorlage

Die vollständige monolithische, mehrphasige Systemaufforderung befindet sich buchstäblich in der Vorlage. Der Dienst schreibt diesen Text während der Optimierung neu. Die Historie und der aktuelle Spielzug bleiben Variablen. Wählen Sie ein beliebiges Layout, mit dem Ihr Modell gut zurechtkommt. Die Anforderungen bestehen lediglich darin, dass die zu optimierenden Anweisungen Teil der Vorlage sind und dass auf die Daten pro Probe verwiesen wird. {{name}}

You are an assistant for {TASK}. The conversation may proceed through phases:
1. {PHASE_1} — ...
2. {PHASE_2} — ...
3. {PHASE_3} — ...
(...the entire multi-phase policy, tool-use rules, tone, formatting, refusal rules...)

Conversation so far (turns 1..N-1, with role tags):
{{conversation_so_far}}

User's current message:
{{user_query}}

Probenform (Sonde bei beliebiger Drehung N)

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n[tool_call: X(...)]\n... (turns 1..N-1)"},
        {"user_query": "...the user input at turn N..."}
    ],
    "referenceResponse": "...desired assistant output at turn N..."
}

Warum Muster B besser funktionieren kann als Muster A

Vorbehalte für Muster B

Tool-call Überprüfung bei einer bestimmten Runde

Der Dienst sieht die Textausgabe des Assistenten. Wählen Sie eine der folgenden Optionen aus, um zu bewerten, ob das Modell bei Turn N Tool X mit den richtigen Argumenten aufgerufen hat:

Informationen zu zusammengesetzten Kriterien für viele Umdrehungen oder viele Unterprüfungen (Richtigkeit, Tonalität und Vollständigkeit des Werkzeugs) finden Sie im Multi-objective Optimierung Abschnitt.

Empfohlener Pfad

Wann sollte Advanced Prompt Optimization nicht für Multi-Turn verwendet werden

Checkliste für Einsteiger