Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Temas y estrategias avanzados

Temas en esta página

Multi-objective optimización

La optimización rápida avanzada acepta una métrica por ejecución, es decir, una única puntuación escalar por muestra. Sin embargo, admite implícitamente la optimización multiobjetivo (multidimensión): puede agrupar varios objetivos en un escalar (una métrica compuesta) y el servicio optimiza la respuesta en función de ese paquete. En esta sección se describen los patrones que recomendamos, cuando cada uno es apropiado, y los modos de error a los que hay que prestar atención.

Esto se aplica a todos los sectores, a cualquier lugar en el que te importe más de una cosa al mismo tiempo: precisión más el tono, precisión al usar las herramientas, seguridad, fidelidad, concisión, facilidad de latencia, integridad y mucho más.

Por qué una métrica es en realidad multiobjetivo

Dos datos sobre el sistema hacen que funcione:

Por lo tanto, «una métrica por ejecución» es un contrato sobre la forma de la señal, no un límite sobre lo que se puede optimizar.

Patrones para agrupar varios objetivos en una sola métrica

Elige uno en función de cómo se relacionan tus objetivos entre sí.

Patrón 1: suma ponderada (la más común)

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ, con ponderaciones que suman 1.

Cuándo usarlos: los objetivos son más o menos independientes y puedes clasificarlos. Trade-offs son aceptables: mejorar uno a expensas de otro está bien, siempre y cuando la suma aumente.

Elección de pesos:

Ejemplo (agente/uso de herramientas):

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

Patrón 2: Hard-fail puertas (críticas para la seguridad)

Defina uno o más objetivos de cierre. Si alguna puerta falla, la puntuación es de 0 (o algún piso) independientemente del resto. De lo contrario, la puntuación es la suma ponderada de los objetivos restantes.

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

Cuándo usarlo: al menos un objetivo no es negociable (filtración de información personal, modificación de una cuenta incorrecta, rechazo de contenido prohibido). Utilízalo siempre que el mensaje «bueno en promedio» no sea aceptable si no cumple con la barra de seguridad, aunque sea de vez en cuando.

Por qué esto es mejor que solo ponderar: solo con las pesas, el optimizador puede cambiar la seguridad por la calidad y aun así subir la puntuación. Una puerta hace imposible el equilibrio debido a la construcción.

Patrón 3: restricción + recompensa () Pareto-style

Elige el objetivo más importante como recompensa. Expresa el resto en forma de restricciones que, si se infringen, restan valor a la recompensa (en lugar de reducirla a cero).

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)

Cuándo usarlo: quieres que un objetivo principal sea el líder, pero los objetivos secundarios blandos deberían seguir dando forma al mensaje. Son menos frágiles que las puertas rígidas, menos ambiguas que las sumas ponderadas.

Patrón 4: lambda exterior e LLM-as-a-Judge interior (recomendado para mezclas difusas y estructurales)

Una métrica lambda calcula las subpuntuaciones deterministas (expresiones regulares, análisis de JSON, validación de esquemas) e invoca una LLM-as-a-Judge subevaluación para las partes borrosas (tono, fidelidad, utilidad) de la función Lambda. A continuación, las agrega en un escalar.

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

Cuándo usarlo: Sus objetivos combinan «es fácil de probar en código» (formatos, nombres de herramientas, longitud, presencia de citas) con «necesita un modelo para juzgar» (tono, fidelidad, amabilidad). Esto suele ser más limpio que pedirle a un solo LLM-as-a-Judge mensaje que produzca una sola puntuación compuesta, ya que las partes deterministas no van a la deriva de una secuencia a otra.

Patrón 5: Multi-dimension LLM-as-a-Judge (sin Lambda)

Usa el LLM-as-a-Judge flujo integrado, si lo deseas, con un flujo customLLMJConfig.customLLMJPrompt que defina tus propias dimensiones y peso. El juez emite puntuaciones por dimensión y unOverall; el sistema analiza Overall (o calcula el promedio de las dimensiones si Overall falta) en un escalar [0, 1].

Cuándo usarlos: todos tus objetivos son semánticos o difusos y no tienes subverificaciones deterministas. El más rápido de crear. Esté atento a la varianza de los jueces: vuelva a ejecutar el mismo conjunto de datos dos veces y compruebe la estabilidad de la puntuación antes de confiar en ella como señal de optimización.

Elegir un patrón

Puede combinar patrones. Una métrica de producción típica es «una suma ponderada más una barrera irrefutable en materia de seguridad».

Modos de fallo a tener en cuenta

Pre-launch lista de verificación

Optimización de las solicitudes escalonadas y de varios turnos

La optimización avanzada de las solicitudes optimiza una plantilla de solicitud única comparándola con las evaluaciones por muestra. No reconoce los turnos de forma nativa: no puede repetir un cuadro de diálogo ni optimizar el comportamiento en un turno específico de forma nativa. Una solicitud escalonada es una plantilla de solicitud en la que una conversación o un flujo de trabajo con varios turnos reutilizan la misma solicitud en varios turnos, y la propia solicitud contiene instrucciones para cada etapa, paso o fase del flujo de trabajo. Para optimizar estas solicitudes, ajuste el estado del cuadro de diálogo a las variables de entrada de la plantilla, incorpore las instrucciones del sistema que desee refinar y analice los promptTemplate turnos que realmente le interesan con respuestas de referencia por muestra.

Este patrón es independiente de la vertical. Se aplica a cualquier lugar en el que se invoque un modelo de forma repetida con un contexto cada vez mayor: flujos de servicio al cliente, ciclos de uso de herramientas por parte de los agentes, razonamiento en varios pasos, tutorías, turnos de asistente de código, control de calidad basado en documentos, flujos de trabajo de clasificación, etc.

¿Qué es lo que realmente optimiza Advanced Prompt Optimization

Todo lo que quieras optimizar debe estar dentro de promptTemplate sí mismo. Las cosas que varían según la muestra (el historial de la conversación, la consulta del usuario actual, el contexto recuperado) son{{variables}}: Las instrucciones del sistema que quieres refinar forman parte de la plantilla, nunca son una variable de entrada, o el servicio no tiene nada que reescribir.

Si desea que el servicio mejore el comportamiento en el turno N, exprese el turno N como la solicitud renderizada más las variables de entrada para una muestra, siendo la salida deseada del modelo Turn N. referenceResponse

Stage-at-a-time Patrón A: (motor de arranque recomendado)

Optimice una fase del diálogo a la vez. Cada muestra de evaluación representa un punto de decisión único dentro de esa fase.

En este caso, una «etapa» es cualquier cosa que se pueda describir con un conjunto coherente de criterios de éxito. Ejemplos por vertical:

Cuándo usar el patrón A

Forma de plantilla

Las instrucciones del sistema específicas de cada etapa se incluyen en la plantilla (esto es lo que reescribe el servicio). Solo el historial de la conversación y el turno actual son variables. La siguiente estructura es ilustrativa, no prescrita. Use los delimitadores o diseños que su modelo maneje mejor. Los únicos requisitos son: (a) las instrucciones del sistema que desea optimizar se encuentran dentro de la plantilla y (b) se hace referencia a las variables por muestra como. {{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 de muestra

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

Ventajas y desventajas

Ventajas: la señal de retroalimentación es precisa, las solicitudes son más pequeñas, la optimización se ejecuta más rápido y es más fácil crear una métrica específica.

Desventajas: No detecta las diferencias entre etapas; ejecutarás el servicio una vez por etapa y es posible que necesites una prueba de integración final.

Patrón B: conversación completamente plana (avanzada)

Optimice un mensaje monolítico de gran tamaño que sea el propietario de toda la política de varias etapas. Cada muestra es el cuadro de diálogo completo hasta un turno de sondeo.

¿Cuándo usar el patrón B

Forma de plantilla

El indicador completo del sistema monolítico y multifásico se encuentra literalmente dentro de la plantilla. El servicio reescribe este cuerpo durante la optimización. El historial y el turno actual siguen siendo variables. Elija cualquier diseño que su modelo maneje bien; el único requisito es que las instrucciones que se van a optimizar formen parte de la plantilla y que se haga referencia a {{name}} los datos de cada muestra.

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 de la muestra (sonda en cualquier 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..."
}

Por qué el patrón B puede funcionar mejor que el patrón A

Advertencias para el patrón B

Tool-call verificación en un turno específico

El servicio ve la salida de texto del asistente. Para calificar «la modelo llamó a la herramienta X con los ángulos correctos en la curva N», elige una:

Para obtener información sobre los criterios compuestos en muchas vueltas o en muchas subcomprobaciones (corrección, tono e integridad de la herramienta), consulte la sección. Multi-objective optimización

Ruta recomendada

Cuándo no usar la optimización avanzada de prontas para varios turnos

Lista de verificación para principiantes