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 (multidimensional): puede agrupar varios objetivos en un escalar (una métrica compuesta) y el servicio optimiza el indicador en función de ese paquete. En esta sección se describen los patrones que recomendamos, cuándo cada uno de ellos es apropiado y los modos de error a los que hay que prestar atención.

Esto se aplica a todos los mercados verticales: en cualquier lugar en el que te importe más de una cosa al mismo tiempo: precisión + tono, precisión al usar herramientas + seguridad, fidelidad + concisión, compatibilidad con la latencia + integridad, etc.

¿Por qué una métrica es en realidad multiobjetivo

Dos datos sobre el sistema hacen que esto funcione:

Por lo tanto, «una métrica por ejecución» es un contrato sobre la forma de la señal, no un límite de 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 (el más común)

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

Cuándo usarlo: Los objetivos son prácticamente independientes y puedes clasificarlos. Trade-offs son aceptables: mejorar uno a costa de otro está bien siempre y cuando la suma aumente.

Elegir pesos:

Ejemplo (uso de agentes/herramientas):

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

Patrón 2: Hard-fail puertas (fundamentales para la seguridad)

Defina uno o más objetivos de bloqueo. Si alguna puerta falla, la puntuación es 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 (información de identificación personal filtrada, modificación de una cuenta errónea, rechazo de contenido prohibido). Utilícela siempre que no se acepte un mensaje que diga «bueno en promedio» si no cumple con los requisitos de seguridad, aunque sea de vez en cuando.

Por qué esto es mejor que la simple ponderación: solo con pesas, el optimizador puede comparar la seguridad con la calidad y, aun así, subir cuesta arriba. Una puerta hace que la compensación sea imposible desde el punto de vista de la construcción.

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

Elige el objetivo más importante como recompensa. Exprese el resto como restricciones que, al infringirlas, 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 utilizarla: quieres que un objetivo principal sea el primero, pero los objetivos secundarios más flexibles deberían seguir siendo los que marquen la pauta. Menos frágiles que las puertas rígidas y menos ambiguas que las sumas ponderadas.

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

Una métrica Lambda calcula las subpuntuaciones deterministas (expresiones regulares, análisis de JSON, validación de esquemas) y realiza una LLM-as-a-Judge subevaluación para las partes difusas (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 «fácil de probar en código» (formatos, nombres de herramientas, longitud, presencia de citas) con «necesita un modelo para juzgar» (tono, fidelidad, utilidad). Esto suele ser más sencillo que pedir una sola anotación para LLM-as-a-Judge producir una sola partitura compuesta, ya que las partes deterministas no van a la deriva de una a otra.

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

Utilice el LLM-as-a-Judge flujo integrado, opcionalmente con un flujo customLLMJConfig.customLLMJPrompt que defina sus propias dimensiones y ponderaciones. El juez emite puntuaciones por dimensión y unaOverall; el sistema las analiza Overall (o promedia las dimensiones si Overall faltan) en un escalar [0, 1].

Cuándo usarlo: Todos tus objetivos son semánticos o difusos y no tienes subcontroles deterministas. El más rápido de crear. Esté atento a la varianza del juez: vuelva a ejecutar el mismo conjunto de datos dos veces y compruebe la estabilidad de la puntuación antes de confiar en él 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 un freno a la seguridad».

Modos de fallo a tener en cuenta

Pre-launch lista de verificación

Optimización de las indicaciones escalonadas y de varios giros

La optimización avanzada de solicitudes optimiza una plantilla de solicitudes única en comparación con las evaluaciones por muestra. No reconoce los giros de forma nativa: no puede iterar un diálogo ni optimizar el comportamiento en un turno específico de forma nativa. Un mensaje por etapas es una plantilla de mensajes en la que una conversación o flujo de trabajo con varios turnos reutiliza el mismo mensaje en varios turnos, y el propio mensaje contiene instrucciones para cada etapa, paso o fase del flujo de trabajo. Para optimizar estas solicitudes, aplana el estado del diálogo en las variables de entrada de la plantilla, incorpora las instrucciones del sistema que desees refinar y analiza los promptTemplate giros que realmente te interesan con respuestas de referencia por muestra.

Este patrón es independiente de la vertical. Se aplica en cualquier lugar donde se invoque un modelo de forma repetida y 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 y mucho más.

¿Qué optimiza realmente la optimización avanzada de solicitudes

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

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

Stage-at-a-time Patrón A — (se recomienda iniciarlo)

Optimice una fase del diálogo a la vez. Cada muestra de evaluación representa un único punto de decisión 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 están integradas en la plantilla (esto es lo que el servicio reescribe). Solo el historial de conversaciones y el turno actual son variables. La siguiente estructura es ilustrativa, no prescrita. Utilice los delimitadores o el diseño que mejor se adapte a su modelo. Los únicos requisitos son: (a) las instrucciones del sistema que desea optimizar estén dentro de la plantilla y (b) las variables de cada muestra estén referenciadas 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: Señal de retroalimentación ajustada, indicaciones más pequeñas, ejecuciones de optimización más rápidas y más fácil crear una métrica específica.

Contras: No capta desviaciones 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 completa y aplanada (avanzado)

Optimice un mensaje monolítico de gran tamaño que sea el propietario de toda la política multietapa. Cada muestra es el diálogo completo hasta una vuelta de sonda.

¿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; los requisitos son únicamente 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 curva 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 sobre 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 argumentos correctos en la curva N?», elige una de las siguientes opciones:

Para conocer los criterios compuestos en varios turnos o varias subcomprobaciones (corrección de la herramienta y tono e integridad), consulte la sección. Multi-objective optimización

Trayectoria recomendada

¿Cuándo no se debe utilizar la optimización avanzada de solicitudes para varios turnos

Lista de verificación para principiantes