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 turni multipli e in 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 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: + **La metrica restituisce un singolo valore float per campione.** Il ciclo di feedback di ottimizzazione legge questo scalare come segnale di ottimizzazione. Puoi calcolarlo partendo da un numero qualsiasi di punteggi secondari disponibili. + **Entrambi i backend metrici aggregano già internamente i punteggi secondari.** + Il LLM-as-a-Judge modello predefinito valuta in base a tre dimensioni (precisione della risposta, completezza della risposta, qualità dell'espressione), assegna pesi ed emette un singolo punteggio normalizzato a [0, 1]. `Overall` 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 obiettivi secondari. 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:** + 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: questo è un problema di ottimizzazione separato. **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 un`Overall`; 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 | \# | Hai... | Utilizzo | | --- | --- | --- | | 1 | 2-4 obiettivi confusi, tutti semantici | Pattern 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 modelli. Una metrica di produzione tipica è «somma ponderata più un limite di sicurezza imprescindibile». ### Modalità di guasto da tenere d'occhio + **Premia l'hacking in forma superficiale.** Se il punteggio secondario è «la risposta contiene la parola 'sicuro'?», l'ottimizzatore scriverà dei prompt che impongono «sure» in ogni output. Preferisci i punteggi secondari basati sui risultati (nome dello strumento, valore dello slot, validità strutturale) rispetto alla presenza di parole chiave. + **Giudice alla deriva.** Una LLM-as-a-Judge metrica multidimensionale i cui pesi variano a seconda della chiamata (perché al giudice viene chiesto di sceglierli) fornisce un segnale di ottimizzazione rumoroso. Aggiungi i pesi nei criteri personalizzati o sposta la ponderazione delle dimensioni nel codice Lambda. + **Il punteggio composito si satura.** Se la metrica raggiunge 0,95 velocemente e rimane invariata, i punteggi secondari sono troppo indulgenti. Restringi le rubriche; valuta la possibilità di alzare il limite massimo (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. Il modello a somma ponderata individua un punto operativo in quella frontiera; se non ti piace, modifica i pesi. ### Pre-launch lista di controllo + Calcola la metrica al prompt iniziale sull'intero set di dati e ispeziona le medie per dimensione, non solo quelle scalari. Se una dimensione è già satura, valuta la possibilità di eliminarla dal pacchetto. + Spot-check 5 campioni fatti 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 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 + **Input:** una `promptTemplate` stringa con `{{placeholder}}` variabili. + **Per esempio:** Ciascuno `evaluationSamples[i]` fornisce valori per tali variabili e un`referenceResponse`. L'ottimizzatore esegue l'inferenza, la valutazione, il feedback e la riscrittura indipendentemente per campione, quindi aggrega la metrica tra i campioni. + **Risultato: Un raffinato.** `promptTemplate` Le variabili, il set di dati e la metrica sono input fissi; cambia solo il modello. 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: + **Agente/utilizzo dello strumento: turno di formazione del piano, turno di selezione dell'utensile**, turno di interpretazione dei risultati dell'utensile, turno di risposta finale. + **Assistenza clienti**: acquisizione, verifica, azione, conferma, chiusura. + **Tutoraggio/istruzione:** valutare le conoscenze, spiegare i concetti, verificare la comprensione, riassumere. + **Documento QA:** risposta basata sul recupero, chiarimento successivo, citazione. + **Assistente alla codifica:** chiarimento delle specifiche, generazione del codice, codifica, test-scrittura. review/fix #### Quando usare 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 debugggibile. #### 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 + Il prompt di produzione è già monolitico e non vuoi dividerlo. + Volete che l'ottimizzatore veda come vengono impostati i turni precedenti e quelli successivi, in modo che le riscritture preservino il flusso tra le fasi. + La correttezza nella rotazione della sonda dipende dal contesto costruito nelle varie fasi (ad esempio, «alla curva N, è necessario fare riferimento ai fatti giusti» o «deve essere già stato chiamato lo strumento giusto»). #### 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 + L'ottimizzatore rileva la progressione delle fasi`conversation_so_far`, in modo che il feedback sull'ottimizzazione possa essere elaborato su più fasi contemporaneamente. + Un unico prompt ottimizzato viene implementato senza dover unire più step prompt ottimizzati, riducendo così la fase di post-elaborazione. #### Avvertenze per il modello B + **Stocasticità nei turni precedenti.** I turni di assistente di produzione potrebbero non corrispondere sempre esattamente a quelli in scatola. `conversation_so_far` Considerate la cronologia preimpostata come la traiettoria prevista; in produzione, una deviazione nei turni precedenti può invalidare l'ottimizzazione. Utilizzate conversazioni reali e rappresentative anziché percorsi felici sintetizzati. + **Costo del token.** Le storie lunghe aumentano vertiginosamente il costo dell'inferenza per processo. Il servizio esegue molti candidati × esempi × iterazioni. Pianificate di conseguenza il budget e valutate la possibilità di abbreviarlo ai K turni più recenti, aggiungendo un riepilogo se il problema è rappresentato dai costi. + **Distorsione della risposta di riferimento.** `referenceResponse`dovrebbe essere quello che direbbe un assistente corretto data quella storia. Se la tua risposta di riferimento è troppo ristretta (solo una formulazione accettabile), l'ottimizzatore la adatterà 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 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: + **Convenzione in uscita: chiedi** all'assistente di emettere un token strutturato simile `X(arg=...)` e di classificarlo con regex/JSON parse in una metrica Lambda. Il più economico, il più affidabile. + **LLM-as-a-Judge criteri personalizzati:** fornisci una risposta `customLLMJPrompt` che chieda al giudice: «La risposta (a) nomina lo strumento`X`, (b) include l'argomento`arg`, (c) corrisponde alla formulazione richiesta`Y`?» Ogni controllo secondario è \+1; aggregato. Facile da scrivere, più varianza. + **Metrica Lambda con simulazione downstream:** se disponi di un cablaggio per l'esecuzione degli strumenti, esegui l'output del modello e valuta gli effetti collaterali osservati. Massima fedeltà, maggior parte delle configurazioni. 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](#advanced-prompt-optimization-multi-objective) ### Percorso consigliato + **Inizia con il modello A** sul palco che sta danneggiando maggiormente la qualità. Ottieni una metrica funzionante, un set di dati di 20-50 campioni e un'ottimizzazione completa. Questo consente di convalidare il set di dati e la metrica prima di investire nella serie Pattern B più ampia. + **Quindi esegui Pattern B una volta** con il prompt monolitico completo e una metrica composita multiobiettivo per catturare le regressioni tra fasi che il Pattern A può non rilevare. + **Iterate il set di dati prima di iterare il prompt.** Se il servizio riscrive in modo determinante la metrica ma il comportamento di produzione non migliora, spesso il problema può essere la metrica o il set di dati. ### Quando non utilizzare Advanced Prompt Optimization per turni multipli + **Bug relativi alla politica di dialogo e alla macchina statale** (logica di transizione di fase errata): una semplice riscrittura del prompt non può risolvere questo problema. Correggi prima il livello di orchestrazione. + **Schemi di strumenti errati:** il servizio non modificherà le definizioni degli strumenti. Può solo modificare il prompt che chiede al modello di usarli. + **Scostamento tra cronologia predefinita e cronologia live:** 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 realmente accettabili per i cicli di ottimizzazione. + Il **comportamento richiesto dipende dallo stato privato** che l'ottimizzatore non vede mai (ad esempio, i dati dell'account utente che il modello apprende solo tramite le chiamate agli strumenti): rendi esplicito tale stato `conversation_so_far` per il campione della sonda o accetta che il servizio possa solo regolare il comportamento della superficie. ### Lista di controllo per principianti + Scegli i giri della sonda che ti interessano. Ciascuno diventa uno o più campioni. + Decidi lo schema A o B (o entrambi: prima A, poi B). + Crea più di 20 campioni rappresentativi con `referenceResponse` valori realistici `conversation_so_far` e puliti.