Prueba tu lógica de agente, no sólo tu estrategia banner image

Reference

Macro Education

Prueba tu lógica de agente, no sólo tu estrategia

Las pruebas de retroceso tradicionales pasan por alto una capa crítica en los sistemas de comercio de IA: el proceso de decisión del agente en sí mismo.

Disponible también en English

Prueba tu lógica de agente, no sólo tu estrategia

Autor: el Equipo de FXMacroData
El nombre de la publicación: 21 de mayo de 2026

La mayoría de los equipos de trading de IA todavía hacen backtest de una sola capa: señal a PnL. Eso pasa por alto el componente de mayor riesgo en los sistemas modernos, el propio agente. Si su modelo interpreta mal una macro impresión, se desvía del esquema o viola la política bajo presión, una buena estrategia aún puede producir malas operaciones.

En FX, esto es más importante en torno a ventanas de eventos pesados en pares como El valor de las pérdidas ¿ Qué ? El valor de la moneda de referencia- ¿ Qué ?

La idea clave: Una estrategia de backtest pregunta "¿Habría ganado dinero esta regla?" La backtesting de agente pregunta "¿Haría esta IA la misma decisión segura repetidamente en condiciones realistas?"

Por qué las pruebas de retroceso de estrategia solo pierden los modos de fracaso reales

Cuando sólo evalúa PnL, oculta tres clases de fallas críticas:

  • Errores de interpretación: el modelo interpreta mal una liberación como El PNV y construye una tesis en la dirección equivocada.
  • Errores en el contrato: La salida rompe su esquema durante los períodos de alta volatilidad.
  • Desvío de la política de riesgo: el modelo recomienda un tamaño excesivo o ignora los criterios de invalidación.

Estos problemas a menudo aparecen antes de que la degradación de PnL se haga obvia.


El marco de pruebas de retroceso de agentes de cuatro capas

Capa 1: Repetición de contexto

Reconstruir cada marca de tiempo como el modelo lo habría visto en tiempo real. calendario de liberación- ¿ Qué ?

curl "https://fxmacrodata.com/api/v1/announcements/usd/core_pce?api_key=YOUR_API_KEY"
curl "https://fxmacrodata.com/api/v1/announcements/eur/inflation?api_key=YOUR_API_KEY"
curl "https://fxmacrodata.com/api/v1/forex?base=EUR&quote=USD&api_key=YOUR_API_KEY"

Capa 2: Repetición de la decisión

Ejecute el agente en cada contexto con el aviso de producción exacto y las restricciones. Almacene la salida en bruto más la salida analizada para que pueda auditar tanto el razonamiento como la estructura.

{
  "pair": "EUR/USD",
  "action": "long|short|flat",
  "confidence": 0.0,
  "thesis": "string",
  "invalidation": "string",
  "size_pct": 0.0
}

Capa 3: Simulación de políticas

Repita las mismas reglas de los guardianes que usas en vivo: riesgo máximo, bloqueos de ventanas de eventos, niveles de confianza y restricciones de concentración.

Capa 4: Atribución de resultados

Los resultados de los análisis se dividen en grupos separados:

  • Tese correcta, cumplimiento de las políticas, rentable.
  • Tese correcta, baja calidad de ejecución.
  • Tese incorrecta, la política debería haber bloqueado.
  • Fallo del esquema o del proceso independiente de la dirección del mercado.

Esto le dice si debe mejorar las indicaciones, las políticas o la tubería de ejecución.


Diseño de un conjunto de datos de reproducción de alta calidad

La mayoría de las tuberías de reproducción fallan porque el conjunto de datos es demasiado limpio o demasiado estrecho.

Una división práctica:

  • 40% de las sesiones normales: mezclas de bajo volumen, de tendencia y de rango limitado.
  • 35% de las ventanas de eventos: las emisiones de alto impacto como PCE de base y días de tipo de interés.
  • Ventanas de tensión del 25%: días de riesgo amplio con una dispersión inusualmente alta y ruido de latencia.

Para cada marca de tiempo, captura sólo lo que se sabía entonces, que incluye el contexto del calendario de lanzamiento, la trayectoria actual y cualquier contexto de política de los archivos de comunicación del banco central.

Replay row fields (recommended):
- ts_utc
- pair
- context_payload_hash
- prompt_version
- model_version
- raw_output
- parsed_output
- policy_decision
- simulated_execution
- realized_outcome

El hashing de las cargas útiles de contexto ayuda a detectar fugas accidentales de datos futuros durante los refactores.


Cómo valorar el razonamiento, no sólo la dirección

Añadir una simple rúbrica de razonamiento calificada por comprobaciones deterministas más una auditoría humana ligera:

  1. Corrección de la causa: ¿La tesis hace referencia al conductor macro correcto?
  2. Consciencia de las limitaciones: ¿La recomendación refleja las normas de riesgo?
  3. Calibración de la incertidumbre: ¿La confianza coincide con la calidad del contexto?
  4. Disciplina de acción: ¿ Qué modelo escoger ? flat ¿cuándo la evidencia es débil?

Lo seguiremos como ReasoningConsistency para que puedas comparar modelos y sugerencias más allá de PnL.

Patrón útil: Mantener un pequeño conjunto de evaluaciones (50-100 ejemplos) revisados por humanos mensualmente.

Calidad del agente de puntuación (más allá de la tasa de éxito)

Una tabla de resultados sólida debe seguir al menos estas métricas:

  • Tasa de aprobación del esquema: porcentaje de salidas que analizan limpiamente.
  • Tasa de cumplimiento de las políticas: porcentaje de los resultados que satisfacen las restricciones duras.
  • Consistencia de los razonamientos: con qué frecuencia la tesis se alinea con el contexto proporcionado.
  • Distribución de la latencia: p50/p95 tiempo de decisión en condiciones realistas de la tubería.
  • Estabilidad del régimen: la puntuación se desplaza a través de tendencias, rango limitado y ventanas de choque de eventos.

Ejemplo de puntuación ponderada:

AgentScore = 0.30 * SchemaPass
           + 0.25 * PolicyCompliance
           + 0.20 * ReasoningConsistency
           + 0.15 * RegimeStability
           + 0.10 * LatencyScore

Si ejecuta un flujo de trabajo de seguridad primero, aumente el peso en el esquema y el cumplimiento de políticas.


Arneses de repetición mínimos

Utilice un corredor de repetición que registre cada decisión y componente de puntuación.

from dataclasses import dataclass


@dataclass
class ReplayResult:
    ts: str
    parsed_ok: bool
    policy_ok: bool
    reasoning_ok: bool
    latency_ms: int
    pnl_r: float


def evaluate_one(ctx, agent, gatekeeper) -> ReplayResult:
    raw = agent.run(ctx)
    parsed = agent.parse(raw)
    parsed_ok = parsed is not None

    if not parsed_ok:
        return ReplayResult(ctx["ts"], False, False, False, agent.last_latency_ms, 0.0)

    gate = gatekeeper.validate(parsed, ctx)
    policy_ok = gate.allowed

    reasoning_ok = gate.reasoning_consistent
    pnl_r = gate.simulated_r if policy_ok else 0.0

    return ReplayResult(
        ts=ctx["ts"],
        parsed_ok=parsed_ok,
        policy_ok=policy_ok,
        reasoning_ok=reasoning_ok,
        latency_ms=agent.last_latency_ms,
        pnl_r=pnl_r,
    )

La clave es la repetición determinista: mismo contexto de entrada, misma versión de pedido, mismas reglas de validación.


Desde los resultados de la repetición hasta las decisiones de despliegue

No promueva cambios de modelo o de instantes directamente desde métricas de puntos.

  • Puerta uno: La tasa de aprobación del esquema no debe regredir.
  • Puerta 2: El cumplimiento de las políticas debe mantenerse por encima del umbral en los períodos de eventos.
  • Puerta 3: La coherencia de los razonamientos debe mejorar o mantenerse estable.
  • Puerta 4: La latencia p95 debe mantenerse dentro del presupuesto operativo.

Sólo si todas las puertas pasan, debe comenzar el modo sombra de negociación de papel.

Promotion policy example:
- Replay pass: required
- Shadow mode: 3 weeks minimum
- Live rollout: 20% traffic for 5 days, then full
- Auto-rollback: any schema fail burst or policy breach cluster

Esto evita el ciclo clásico donde los equipos se adaptan demasiado para repetir y sub-probar el comportamiento operativo.


Errores comunes en las pruebas

  • Se puede filtrar: Incluyendo accidentalmente campos futuros en el contexto.
  • Desviación rápida: backtesting con un aviso y el comercio en vivo con otro.
  • No hay segmentación de régimen: promediando los resultados de estados de volatilidad muy diferentes.
  • No hay repetición de la política: tratará todos los resultados del modelo como negociables.
Advertencia práctica: Los contratos rotos son un riesgo operativo, no un ruido cosmético.

Cómo mejora la fiabilidad de las operaciones en vivo

El backtesting de la lógica de los agentes mejora la confiabilidad de maneras en que los backtests clásicos no pueden:

  • Encuentra grupos de fallas alrededor de los días del banco central, desde el Reserva Federal ¿ Qué ? Banco de Inglaterra- ¿ Qué ?
  • Revela qué errores están relacionados con el prompt frente a los relacionados con la política.
  • Soporta actualizaciones de modelos más seguras porque puede comparar el comportamiento de decisión entre versiones antes de la implementación.
  • Crea una pista de auditoría reutilizable para cada candidato comercial aceptado o rechazado.

Si ya rastreas PnL, esto agrega la capa de observabilidad que falta que evita que la automatización de IA se degrade en silencio.


Resumen de las cosas

La lógica de la estrategia de backtesting es necesaria. La lóxica de back testing de agentes es lo que hace que los flujos de trabajo de comercio de IA sean duraderos. Los sistemas más fuertes evalúan tanto: ventaja del mercado como integridad de la decisión.

El siguiente paso: crear un punto de referencia de repetición mensual y exigir que cada cambio de pedido / modelo lo pase antes de llegar al modo en vivo. El COT y filtros de sesión de Sesiones de divisas El análisis de la capacidad de los mercados para evaluar el comportamiento de las pruebas de resistencia en diferentes estados de mercado.

Blogroll