Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Argomenti e strategie avanzati

Argomenti in questa pagina

Multi-objective ottimizzazione

Advanced Prompt Optimization accetta una metrica per esecuzione: un singolo punteggio scalare per campione. Tuttavia, supporta implicitamente l'ottimizzazione multiobiettivo (multidimensionale): è possibile raggruppare più obiettivi in un unico scalare (una metrica composita) e il servizio ottimizza il prompt rispetto a tale pacchetto. Questa sezione descrive i modelli che consigliamo, quando ciascuno di essi è appropriato, e le modalità di errore da tenere d'occhio.

Questo vale per tutti i settori verticali, ovunque vi interessino più di una cosa contemporaneamente: precisione + tono, correttezza delle chiamate agli strumenti + sicurezza, fedeltà + concisione, compatibilità con la latenza + completezza e altro ancora.

Perché una metrica è in realtà multiobiettivo

Due caratteristiche del sistema lo rendono possibile:

Quindi «una metrica per corsa» è un contratto sulla forma del segnale, non un limite su ciò che è possibile ottimizzare.

Schemi per raggruppare più obiettivi in un'unica metrica

Scegline uno in base al modo in cui i tuoi obiettivi si relazionano tra loro.

Schema 1 — Somma ponderata (la più comune)

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ, con la somma dei pesi pari a 1.

Quando usarli: gli obiettivi sono più o meno indipendenti e puoi classificarli. Trade-offs sono accettabili: migliorarne uno a scapito di un altro va bene purché la somma aumenti.

Scelta dei pesi:

Esempio (agentic/ tool-use):

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

Modello 2: cancelli (critici per la sicurezza Hard-fail )

Definisci uno o più obiettivi di gating. Se un cancello fallisce, il punteggio è 0 (o qualche piano) indipendentemente dal resto. Altrimenti, il punteggio è la somma ponderata degli obiettivi rimanenti.

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

Quando utilizzarlo: almeno un obiettivo non è negoziabile (divulgazione di informazioni personali, modifica dell'account errato, rifiuto di contenuti proibiti). Usalo ogni volta che un messaggio «mediamente buono» è inaccettabile se non supera la barra di sicurezza anche occasionalmente.

Perché questo metodo è meglio della semplice ponderazione: con i soli pesi, l'ottimizzatore può scambiare la sicurezza con la qualità e comunque scalare il punteggio. Un cancello rende impossibile il compromesso in fase di costruzione.

Modello 3 — Vincolo + ricompensa () Pareto-style

Scegli l'obiettivo più importante come ricompensa. Esprimi il resto come vincoli che, se violati, sottraggono dalla ricompensa (anziché azzerarla).

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)

Quando utilizzarlo: se vuoi che sia un obiettivo primario a guidare, il prompt dovrebbe comunque essere guidato da obiettivi secondari non vincolanti. Meno fragili dei cancelli rigidi, meno ambigui delle somme ponderate.

Pattern 4 — Lambda esterna, LLM-as-a-Judge interna (consigliata per miscele fuzzy + strutturali)

Una metrica Lambda calcola i punteggi secondari deterministici (regex, analisi JSON, convalida dello schema) e richiama una LLM-as-a-Judge sottovalutazione per le parti confuse (tono, fedeltà, utilità) all'interno della funzione Lambda. Quindi li aggrega in un unico scalare.

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

Quando utilizzarlo: i tuoi obiettivi combinano «facilità di test nel codice» (formati, nomi degli strumenti, lunghezza, presenza di citazioni) con «bisogno di un modello per giudicare» (tono, fedeltà, disponibilità). Spesso è più semplice che chiedere a un solo LLM-as-a-Judge prompt di produrre una singola partitura composita, perché le parti deterministiche non andranno alla deriva da una corsa all'altra.

Schema 5 — Multi-dimension LLM-as-a-Judge (senza Lambda)

Usa il LLM-as-a-Judge flusso integrato, opzionalmente con un customLLMJConfig.customLLMJPrompt che definisce le tue dimensioni e il tuo peso. Il giudice emette punteggi per dimensione e unOverall; il sistema analizza Overall (o calcola la media delle dimensioni se Overall manca) in uno scalare [0, 1].

Quando utilizzarlo: tutti gli obiettivi sono semantici/confusi e non sono previsti controlli secondari deterministici. Il più veloce da scrivere. Fate attenzione alla varianza dei punteggi: eseguite nuovamente lo stesso set di dati due volte e verificate la stabilità del punteggio prima di affidarvi a questo come segnale di ottimizzazione.

Scelta di un pattern

È possibile combinare modelli. Una metrica di produzione tipica è «somma ponderata più un limite di sicurezza imprescindibile».

Modalità di guasto da tenere d'occhio

Pre-launch lista di controllo

Ottimizzazione dei prompt a turni multipli e in fasi

Advanced Prompt Optimization ottimizza un singolo modello di prompt rispetto alle valutazioni effettuate per campione. Non è nativamente sensibile al turno: non può iterare su una finestra di dialogo o ottimizzare il comportamento in un turno specifico in modo nativo. Un prompt in fasi è un modello di prompt in cui una conversazione o un flusso di lavoro a più turni riutilizza lo stesso prompt a turni e il prompt stesso contiene istruzioni per ogni fase, passaggio o fase del flusso di lavoro. Per ottimizzare questi prompt, appiattisci lo stato della finestra di dialogo alle variabili di input del modello, inserisci le istruzioni di sistema che desideri perfezionare e analizza i turni che ti interessano effettivamente con risposte di promptTemplate riferimento per campione.

Questo modello è indipendente dal punto di vista verticale. Si applica ovunque un modello venga richiamato ripetutamente con un contesto crescente: flussi di assistenza clienti, cicli di utilizzo agentici degli strumenti, ragionamento in più fasi, tutoraggio, turni di assistente al codice, controllo qualità basato sui documenti, flussi di lavoro di triage e altro ancora.

Cosa ottimizza effettivamente Advanced Prompt Optimization

Tutto ciò che desideri ottimizzare deve risiedere all'interno di sé stesso. promptTemplate Le cose che variano in base al campione (la cronologia delle conversazioni, la query corrente dell'utente, il contesto recuperato) sono{{variables}}. Le istruzioni di sistema che desideri perfezionare fanno parte del modello: mai una variabile di input, altrimenti il servizio non ha nulla da riscrivere.

Se desideri che il servizio migliori il comportamento al turno N, esprimi la variabile N come variabile prompt-plus-input-renderizzata per un campione, che sarà l'output desiderato del modello Turn-N. referenceResponse

Pattern A — (starter consigliato) Stage-at-a-time

Ottimizza una fase del dialogo alla volta. Ogni campione di valutazione rappresenta un singolo punto decisionale all'interno di quella fase.

Una «fase» qui è tutto ciò che si può descrivere con una serie coerente di criteri di successo. Esempi per verticale:

Quando usare Pattern A

Forma del modello

Le istruzioni di sistema specifiche dello stadio sono incluse nel modello (questo è ciò che il servizio riscrive). Solo la cronologia delle conversazioni e il turno corrente sono variabili. La struttura seguente è illustrativa, non prescritta. Usa i delimitatori o il layout che il tuo modello gestisce meglio. Gli unici requisiti sono: (a) le istruzioni di sistema che desideri ottimizzare in tempo reale all'interno del modello e (b) le variabili per campione siano referenziate come. {{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}}

Forma del campione

{
    "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..."
}

Pro e contro

Vantaggi: segnale di feedback preciso, istruzioni più piccole, esecuzioni di ottimizzazione più rapide, creazione più semplice di una metrica mirata.

Svantaggi: non cattura la deriva tra fasi; eseguirai il servizio una volta per fase e potrebbe essere necessario un test di integrazione finale.

Schema B — Conversazione completamente semplificata (avanzata)

Ottimizza un prompt monolitico di grandi dimensioni che gestisce l'intera politica in più fasi. Ogni campione rappresenta l'intera finestra di dialogo fino alla rotazione della sonda.

Quando usare Pattern B

Forma del modello

Il prompt del sistema monolitico e multifase completo si trova letteralmente all'interno del modello. Il servizio riscrive questo corpo durante l'ottimizzazione. La cronologia e il turno attuale rimangono variabili. Scegliete qualsiasi layout che il vostro modello gestisca bene; i requisiti sono solo che le istruzioni da ottimizzare facciano parte del modello e che i dati per campione siano referenziati. {{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}}

Forma del campione (sonda a qualsiasi giro 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..."
}

Perché Pattern B può funzionare meglio di Pattern A

Avvertenze per il modello B

Tool-call verifica in un turno specifico

Il servizio vede l'output di testo dell'assistente. Per valutare «il modello ha chiamato lo strumento X con gli args giusti al turno N», scegline uno:

Per i criteri compositi relativi a più turni o a molti controlli secondari (correttezza, tono e completezza dell'utensile), consultate la sezione. Multi-objective ottimizzazione

Percorso consigliato

Quando non utilizzare Advanced Prompt Optimization per turni multipli

Lista di controllo per principianti