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-multi-objective) + [Ottimizzazione dei prompt a più turni e in più fasi](#advanced-prompt-optimization-multi-turn) ## Multi-objective ottimizzazione Advanced Prompt Optimization accetta una metrica per esecuzione, un singolo punteggio scalare per campione. Tuttavia, supporta implicitamente l'ottimizzazione multi-obiettivo (multidimensionale): puoi raggruppare più obiettivi in un unico scalare (una metrica composita) e il servizio ottimizza il prompt rispetto a quel pacchetto. Questa sezione illustra i modelli che consigliamo, laddove ciascuno di essi è appropriato, e le modalità di errore a cui prestare attenzione. Questo vale per tutti i settori verticali, ovunque ci si preoccupi di più di una cosa contemporaneamente: precisione \+ tono, correttezza dei comandi \+ sicurezza, fedeltà \+ concisione, compatibilità con la latenza \+ completezza e altro ancora. ### Perché una metrica è in realtà multiobiettivo Questo sistema funziona grazie a due fattori: + **La metrica restituisce un singolo valore float per campione. ** Il ciclo di feedback di ottimizzazione legge questo scalare come segnale di ottimizzazione. È possibile calcolarlo partendo da un numero qualsiasi di punteggi secondari. + **Entrambi i backend delle metriche aggregano già internamente i punteggi secondari. ** + Il LLM-as-a-Judge modello predefinito è classificato in base a tre dimensioni (precisione della risposta, completezza della risposta, qualità dell'espressione), assegna pesi ed emette un `Overall` punteggio singolo normalizzato a [0, 1]. I criteri personalizzati vengono uniti nello stesso scalare. Per ulteriori informazioni, consulta [Personalizzato LLM-as-a-judge](advanced-prompt-optimization-evaluation.md#advanced-prompt-optimization-evaluation-llmj). + Le metriche lambda/codice personalizzato restituiscono un numero e tu controlli il modo in cui viene calcolato, incluso qualsiasi insieme di sottoobiettivi. Quindi «una metrica per corsa» è un contratto sulla forma del segnale, non un limite a ciò per cui è 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 una 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 spese di un altro va bene purché la somma aumenti. **Scelta dei pesi: ** + Peso in base all'importanza per l'utente, non in base alla frequenza nel set di dati. + Inizia in modo grossolano: `0.5 / 0.3 / 0.2` va bene. Non regolate eccessivamente i pesi: si tratta di un problema di ottimizzazione separato. **Esempio (uso dell'agente/dello strumento): ** ``` final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance ``` #### Schema 2: cancelli (critici per la sicurezza Hard-fail ) Definire 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 (fuga di dati personali, modifica dell'account errato, rifiuto di contenuti proibiti). Usalo ogni volta che una richiesta «mediamente buona» non è accettabile se non viene visualizzata la barra di sicurezza anche occasionalmente. **Perché è meglio della semplice ponderazione: ** con i soli pesi, l'ottimizzatore può scambiare sicurezza con qualità e comunque scalare il punteggio. Un cancello rende impossibile il compromesso dovuto alla costruzione. #### Schema 3 — Vincolo \+ ricompensa () Pareto-style Scegli l'obiettivo più importante come ricompensa. Esprimi il resto come vincoli che, se violati, sottraggono alla 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 usarlo: ** vuoi che sia un obiettivo primario a guidare, ma obiettivi secondari flessibili dovrebbero comunque dare forma al prompt. Meno fragili dei cancelli rigidi, meno ambigui delle somme ponderate. #### Schema 4 — Lambda esterno, LLM-as-a-Judge interno (consigliato 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 fuzzy (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 usarlo: ** i tuoi obiettivi combinano «codice facile da testare» (formati, nomi degli strumenti, lunghezza, presenza di citazioni) con «necessità di un modello da giudicare» (tono, fedeltà, disponibilità). Spesso è più semplice che chiedere a un LLM-as-a-Judge prompt di produrre una singola partitura composita, perché le parti deterministiche non si spostano da una riga all'altra. #### Schema 5 — Multi-dimension LLM-as-a-Judge (senza Lambda) Usa il LLM-as-a-Judge flusso integrato, opzionalmente con uno `customLLMJConfig.customLLMJPrompt` che definisce le tue dimensioni e il tuo peso. Il giudice emette punteggi per dimensione e un valore`Overall`; il sistema analizza `Overall` (o calcola la media delle dimensioni se `Overall` mancano) in uno scalare [0, 1]. **Quando usarlo: ** tutti i tuoi obiettivi sono semantici/confusi e non hai controlli secondari deterministici. Il più veloce da scrivere. Fai attenzione alla varianza del giudizio: riesegui lo stesso set di dati due volte e verifica la stabilità del punteggio prima di affidarti a esso come segnale di ottimizzazione. ### Scelta di un modello | \# | Hai... | Utilizzo | | --- | --- | --- | | 1 | 2—4 obiettivi sfocati, tutti semantici | Schema 5 (multidimensionale) LLM-as-a-Judge | | 2 | 2—4 obiettivi che mescolano struttura e semantica | Schema 4 (Lambda esterno \+ interno) LLM-as-a-Judge | | 3 | Almeno un criterio non negoziabile safety/correctness | Pattern 2 (hard-fail gate): combinalo con 1 o 4 | | 4 | Un obiettivo primario chiaro \+ preferenze soft | Schema 3 (vincolo \+ ricompensa) | | 5 | Diversi obiettivi indipendenti all'incirca uguali | Schema 1 (somma ponderata) | È possibile combinare i modelli. Una tipica metrica di produzione è «somma ponderata \+ un limite assoluto sulla sicurezza». ### Modalità di guasto da tenere d'occhio + **Premia l'hacking su Surface Form. ** Se il tuo punteggio secondario è «la risposta contiene la parola «sicuro», l'ottimizzatore scriverà dei prompt che impongono «sicuro» in ogni output. Preferisci i punteggi secondari basati sui risultati (nome dello strumento, valore dello slot, validità strutturale) rispetto alla presenza di parole chiave. + **Judge Drift. ** Una LLM-as-a-Judge metrica multidimensionale i cui pesi variano a seconda della chiamata (perché viene chiesto al giudice di sceglierli) fornisce un segnale di ottimizzazione rumoroso. Inserisci i pesi nei tuoi criteri personalizzati o sposta la ponderazione delle dimensioni nel codice Lambda. + **Il punteggio composito è saturo. ** Se la metrica raggiunge velocemente 0,95 e rimane invariata, i punteggi secondari sono troppo indulgenti. Restringi le rubriche; valuta la possibilità di aumentare la soglia massima (ad esempio, il credito parziale diventa 0 anziché 1) in modo che l'ottimizzatore abbia margine di manovra. + **Sub-objectives conflitto diretto. ** «Concisione» vs. «completezza» è un vero compromesso. Lo schema a somma ponderata seleziona un punto operativo su quella frontiera; se non ti piace, cambia i pesi. ### Pre-launch lista di controllo + Calcola la metrica nel prompt iniziale sull'intero set di dati e controlla le medie per dimensione, non solo quelle scalari. Se una dimensione è già satura, valuta la possibilità di eliminarla dal pacchetto. + Spot-check 5 campioni a mano. Il verdetto della metrica corrisponde al tuo giudizio? In caso contrario, correggi la metrica prima di ottimizzare il prompt. ## Ottimizzazione dei prompt a più turni e in più fasi L'ottimizzazione avanzata dei prompt ottimizza un singolo modello di prompt rispetto alle valutazioni per campione. Non è nativamente sensibile ai turni: non può iterare su una finestra di dialogo o ottimizzare il comportamento in un turno specifico in modo nativo. Un prompt * graduale * è un modello di prompt in cui una conversazione o un flusso di lavoro a più turni riutilizza lo stesso prompt in più turni e il prompt stesso contiene istruzioni per ogni fase, passaggio o fase del flusso di lavoro. Per ottimizzare questi prompt, riduci lo stato della finestra di dialogo nelle variabili di input del modello, incorpora le istruzioni di sistema che desideri perfezionare e analizza le curve che ti `promptTemplate` interessano davvero con risposte di riferimento per campione. Questo modello è indipendente dalla verticale. Si applica ovunque un modello venga richiamato ripetutamente in un contesto in crescita: flussi di assistenza clienti, cicli di utilizzo degli strumenti agentici, 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 + **Input: ** una `promptTemplate` stringa con `{{placeholder}}` variabili. + **Per esempio: ** ognuna `evaluationSamples[i]` fornisce i valori per quelle variabili e un`referenceResponse`. L'ottimizzatore esegue l'inferenza, la valutazione, il feedback e la riscrittura in modo indipendente per campione, quindi aggrega la metrica tra i campioni. + **Produzione: ** raffinata`promptTemplate`. Le variabili, il set di dati e la metrica sono input fissi; cambia solo il modello. Tutto ciò che desideri ottimizzare deve vivere all'interno di se stesso. `promptTemplate` Le cose che variano a seconda del campione (la cronologia delle conversazioni, la richiesta corrente dell'utente, il contesto recuperato) sono`{{variables}}`. Le istruzioni di sistema che desideri perfezionare fanno parte del modello: non sono mai una variabile di input, altrimenti il servizio non ha nulla da riscrivere. Se desideri che il servizio migliori il comportamento alla curva N, esprimi il turno N come prompt plus-input-variables renderizzate per un campione, indicando l'output del modello Turn-N desiderato. `referenceResponse` ### Pattern A — (iniziatore consigliato) Stage-at-a-time Ottimizza una fase della finestra di 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: + **Agentico/uso dello strumento: turno di ** formazione del piano, turno di selezione degli strumenti, turno di interpretazione dei risultati degli strumenti, turno della risposta finale. + **Assistenza clienti**: ricezione, verifica, azione, conferma, chiusura. + **Tutoraggio/formazione: ** valutare le conoscenze, spiegare il concetto, verificare la comprensione, riassumere. + **QA del documento: risposta basata sul ** recupero, chiarimento successivo, turno di citazione. + **Assistente alla codifica: chiarimento delle ** specifiche, generazione di codice, scrittura del codice, test. review/fix #### Quando usare il Pattern A + È possibile denominare fasi distinte con criteri di successo distinti. + Una fase consiste nel ridurre la qualità e si desidera correggerla senza disturbare gli altri. + Desiderate un'iterazione rapida e un segnale di feedback preciso e debuggabile. #### Forma del modello Le istruzioni di sistema specifiche della fase vengono inserite 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 da ottimizzare sono contenute all'interno del modello e (b) le variabili per campione sono indicate 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, prompt più piccoli, esecuzioni di ottimizzazione più rapide, più facile creare una ** metrica mirata. **Contro: ** non rileva variazioni tra le fasi; il servizio verrà eseguito una volta per fase e potrebbe essere necessario un test di integrazione finale. ### Schema B — Conversazione completamente appiattita (avanzata) Ottimizza un unico prompt monolitico di grandi dimensioni che contiene l'intera policy in più fasi. Ogni esempio è la finestra di dialogo completa fino al turno di una sonda. #### Quando usare Pattern B + Il tuo prompt di produzione è già monolitico e non vuoi dividerlo. + Volete che l'ottimizzatore veda come i turni precedenti impostano i turni successivi, in modo che le riscritture preservino il flusso tra le fasi. + La correttezza al turno della sonda dipende dal contesto costruito nelle varie fasi (ad esempio, «alla svolta N, è necessario già fare riferimento ai fatti giusti» o «deve essere già stato richiamato lo strumento giusto»). #### Forma del modello Il prompt di sistema completamente monolitico e multifase si trova letteralmente all'interno del modello. Il servizio riscrive questo corpo durante l'ottimizzazione. La cronologia e la svolta attuale rimangono variabili. Scegliete un layout che il vostro modello gestisca correttamente; i requisiti sono solo che le istruzioni da ottimizzare facciano parte del modello e che si faccia riferimento ai dati per campione. `{{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 angolo 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é il Pattern B può funzionare meglio del Pattern A + L'ottimizzatore rileva la progressione delle fasi`conversation_so_far`, quindi il feedback sull'ottimizzazione può ragionare su più fasi contemporaneamente. + Un singolo prompt ottimizzato viene implementato senza dover unire più prompt ottimizzati, riducendo la post-elaborazione per te. #### Avvertenze per il modello B + **Stocasticità nei turni precedenti. ** I turni dell'assistente alla produzione potrebbero non corrispondere sempre `conversation_so_far` esattamente a quelli in scatola. Considera la cronologia predefinita come la traiettoria prevista; in produzione, la deriva nelle curve precedenti può invalidare l'ottimizzazione. Usa immagini rappresentative e reali delle conversazioni piuttosto che percorsi felici sintetizzati. + **Costo del token. ** Le storie lunghe aumentano il costo di inferenza per prova. Il servizio esegue molti candidati × esempi × iterazioni. Stabilisci il budget di conseguenza e considera di limitarlo ai K turni più recenti, oltre a un riepilogo se il costo è il collo di bottiglia. + **Bias di risposta di riferimento. **`referenceResponse`dovrebbe essere quello che direbbe un assistente corretto vista quella storia. Se la risposta di riferimento è troppo restrittiva (solo una frase accettabile), l'ottimizzatore si adatta eccessivamente. Preferisci una metrica che valuti i risultati (nome dello strumento, valori degli slot, decisione) rispetto alla corrispondenza tra superficie e forma, ove possibile. ### Tool-call verifica in un momento specifico Il servizio vede l'output di testo dell'assistente. Per valutare «il modello ha chiamato lo strumento X con gli args corretti alla curva N», scegline uno: + **Convenzione nell'output: ** chiedi all'assistente di emettere un token strutturato `X(arg=...)` e di valutarlo con l' regex/JSON analisi in una metrica Lambda. Il più economico, il più affidabile. + **LLM-as-a-Judge criteri personalizzati: ** fornisci una domanda `customLLMJPrompt` che chieda al giudice: «La risposta (a) nomina lo strumento`X`, (b) include argomenti`arg`, (c) corrisponde alla formulazione richiesta`Y`?» Ogni controllo secondario è \+1; aggregato. Facile da scrivere, maggiore varianza. + **Metrica lambda con simulazione a valle: ** se disponi di un cablaggio per l'esecuzione degli strumenti, esegui l'output del modello e valuta gli effetti collaterali osservati. Massima fedeltà, massima configurazione. Per criteri compositi basati su più turni o su più controlli secondari (correttezza, tono e completezza dello strumento), consulta la sezione. [Multi-objective ottimizzazione](#advanced-prompt-optimization-multi-objective) ### Percorso consigliato + **Inizia con il Pattern A ** sul palco che danneggia maggiormente la qualità. Ottieni una metrica funzionante, un set di dati di 20-50 esempi e un'ottimizzazione completa. Questo convalida il set di dati e la metrica prima di investire nella più ampia serie di Pattern B. + **Quindi esegui Pattern B una volta ** con il prompt monolitico completo e una metrica composita multiobiettivo per rilevare le regressioni tra fasi che il Pattern A può sfuggire. + **Iterate il set di dati prima della richiesta di iterazione. ** Se il servizio riscrive la metrica in salita ma il comportamento di produzione non migliora, la metrica o il set di dati possono spesso essere il problema. ### Quando non utilizzare Advanced Prompt Optimization per più turni + **Bug relativi alla politica di dialogo/stato-macchina ** (logica di transizione a fasi errate): una semplice riscrittura del prompt non può risolvere il problema. Correggi prima il livello di orchestrazione. + **Schemi degli strumenti errati: ** il servizio non modificherà le definizioni degli strumenti. Può modificare solo il prompt che chiede al modello di utilizzarli. + **Alterna tra cronologia predefinita e cronologia dal vivo: ** se le conversazioni reali divergono notevolmente dai campioni di valutazione dopo alcuni turni, il segnale di ottimizzazione del Pattern B è debole. In questo caso, oltre allo stato ideale, può essere utile acquisire tracce di produzione reali e accettabili per i cicli di ottimizzazione. + **Il comportamento richiesto dipende dallo stato privato che ** l'ottimizzatore non vede mai (ad esempio, i dati degli account utente che il modello apprende solo tramite le chiamate agli strumenti): rendi esplicito tale stato nel `conversation_so_far` campione della sonda o accetta che il servizio possa solo regolare il comportamento della superficie. ### Lista di controllo iniziale + Scegli i turni della sonda che ti interessano. Ognuno diventa uno o più campioni. + Decidi il modello A o B (o entrambi: prima A, poi B). + Crea più di 20 campioni rappresentativi con `referenceResponse` valori realistici `conversation_so_far` e puliti.