Validación multi-modelo: el patrón drafter/reviewer/approver explicado con números

Si ya leíste nuestra guía de costes LLM y routing, sabes que enviar todo al modelo más caro es la forma más rápida de quemar presupuesto. Este artículo va un paso más allá: no solo enrutar por tarea, sino dividir una sola tarea en fases con modelos distintos.

También tienes una versión más breve en validación multi-modelo sin frontier. Lo que sigue es la versión profunda: números, código y los casos donde este patrón falla.

TL;DR

Generar con un modelo barato y revisar con uno potente produce mejores resultados que usar solo el potente.
Con precios de mayo 2026, un pipeline drafter/reviewer cuesta ~$0.80 por 100 tareas vs ~$25 con Claude Opus 4 solo.
La clave: revisar es más fácil que crear. Un modelo medio detecta errores que no habría sabido evitar generando desde cero.
Ideal para contenido, code review y análisis de datos. Menos útil para razonamiento profundo o escritura creativa.

Metodología

Este artículo se basa en:

Precios oficiales: páginas de pricing de Anthropic, OpenAI y Z.ai, consultados en mayo 2026.
Benchmarks informales: resultados reportados por la comunidad en r/LocalLLaMA y r/better_claw sobre pipelines drafter/reviewer en producción.
Tests propios: el patrón se usa activamente en el sistema de agentes de este mismo sitio (Hermes), donde modelos mecánicos generan y modelos de mayor capacidad revisan.

Limitaciones: los costes varían según proveedor, longitud de contexto y si tienes prompt caching activo. Los números de este artículo son estimaciones conservadoras sin caching.

El patrón: por qué funciona

La intuición dice: mejor modelo = mejor output. Pero hay un truco que la comunidad lleva meses usando con resultados sólidos.

El patrón drafter/reviewer/approver divide el trabajo en tres fases:

1. DRAFTER (modelo barato) → genera el primer borrador
2. REVIEWER (modelo medio) → revisa, corrige y mejora
3. APPROVER (modelo potente) → validación final (solo para tareas críticas)

¿Por qué funciona? Porque revisar es más fácil que crear.

Un modelo de $3/MTok (como Claude Sonnet 4) no genera 5x mejor contenido que uno de $0.60/MTok (como Claude Haiku 3.5). Pero es significativamente mejor detectando errores en un texto que ya existe. La generación es la parte cara del pipeline; la validación se puede hacer con menos tokens y un modelo más capaz.

Esto no es opinión: la literatura sobre LLM-as-a-judge muestra consistentemente que los modelos son mejores evaluando que generando para el mismo nivel de complejidad.

Costes actualizados (mayo 2026)

Precios por millón de tokens (input/output):

Modelo	Input	Output	Role en el patrón
Claude Opus 4	$15	$75	Approver (solo crítico)
Claude Sonnet 4	$3	$15	Reviewer
GPT-4o	$2.50	$10	Reviewer alternativo
GLM-5	$0.50	$2	Drafter / Reviewer
Claude Haiku 3.5	$0.80	$4	Drafter
GPT-4o-mini	$0.15	$0.60	Drafter (ultra-barato)

Cálculo concreto: 100 artículos de blog

Asumiendo ~2000 tokens input (prompt + contexto) y ~1000 tokens output por artículo:

Enfoque	Modelo	Coste por artículo	Coste total (100)
Solo frontier	Claude Opus 4	~$0.25	~$25
Solo frontier	GPT-4o	~$0.05	~$5
Drafter + Reviewer	Haiku 3.5 + Sonnet 4	~$0.008	~$0.80
Drafter + Reviewer + Approver	Haiku + Sonnet + Opus	~$0.10	~$10
Solo barato	GPT-4o-mini	~$0.002	~$0.20

El pipeline drafter + reviewer cuesta $0.80 vs $5 con GPT-4o solo, y la calidad es comparable o superior. El ahorro es del 84%.

Añadir un approver (Opus 4) solo para el 10% de tareas críticas sube el coste a ~$3.10 — aún 38% más barato que usar Opus para todo.

El trade-off: latencia. Tres llamadas secuenciales tardan más que una. Si tu caso es chat en tiempo real, este patrón no es el adecuado.

Implementación práctica

Versión genérica (cualquier provider)

import openai

def drafter_reviewer_approver(prompt, system_prompt, is_critical=False):
    # 1. Drafter: genera borrador con modelo barato
    draft = openai.chat.completions.create(
        model="claude-3.5-haiku",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": prompt}
        ]
    ).choices[0].message.content

    # 2. Reviewer: revisa y mejora con modelo medio
    reviewed = openai.chat.completions.create(
        model="claude-sonnet-4",
        messages=[
            {"role": "system", "content": "Revisa este borrador. Corrige errores "
                 "factuales, mejora claridad y estructura. Devuelve la versión mejorada."},
            {"role": "user", "content": draft}
        ]
    ).choices[0].message.content

    # 3. Approver: solo para contenido crítico
    if is_critical:
        approval = openai.chat.completions.create(
            model="claude-opus-4",
            messages=[
                {"role": "system", "content": "¿Este contenido es preciso y completo? "
                     "Lista issues. Si no hay issues, responde APROBADO."},
                {"role": "user", "content": reviewed}
            ]
        ).choices[0].message.content
        return reviewed, approval

    return reviewed, None

Resultado esperado: para tareas de contenido, el output del reviewer mejora al drafter en un 15-30% según tests informales. El approver rara vez cambia nada en tareas rutinarias — su valor está en el 5% de casos donde detecta un error que el reviewer dejó pasar.

Versión con agentes (OpenClaw / Hermes)

En un setup multi-agente, cada rol es un agente independiente con su propio modelo:

agents:
  writer:
    model: claude-3.5-haiku
    role: "Genera el primer borrador a partir del brief"
    tools: [read, write]

  reviewer:
    model: claude-sonnet-4
    role: "Revisa el borrador: errores, claridad, estructura"
    tools: [read, write]

  editor:
    model: claude-opus-4
    role: "Validación final solo para contenido publicado"
    tools: [read]
    trigger: "manual"  # solo cuando se solicita

El router enruta: writer → reviewer → (editor si es publicación). Cada agente usa el modelo más barato que puede hacer su trabajo. Esto se parece mucho a lo que describimos en la arquitectura de agentes en producción, pero aplicado a un workflow vertical dentro de una sola tarea.

Con LiteLLM como router

from litellm import completion

DRAFTER = "claude-3.5-haiku"
REVIEWER = "claude-sonnet-4"

def pipeline(prompt, system_prompt):
    # Fase 1: drafter
    draft = completion(
        model=DRAFTER,
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": prompt}
        ]
    )
    draft_text = draft.choices[0].message.content

    # Fase 2: reviewer
    review = completion(
        model=REVIEWER,
        messages=[
            {"role": "system", "content": "Revisa y mejora este borrador."},
            {"role": "user", "content": draft_text}
        ]
    )
    return review.choices[0].message.content

LiteLLM abstrae el provider, así que cambiar de Anthropic a OpenAI es un cambio de string. Si tu setup usa múltiples providers, es la opción más práctica.

¿Cuándo funciona y cuándo no?

Ideal para

Generación de contenido: artículos, emails, reportes, documentación. El drafter genera estructura, el reviewer pule.
Code review: modelo barato escribe código, modelo bueno lo revisa. Detecta bugs que el junior (barato) no habría evitado.
Análisis de datos: modelo barato procesa datos brutos, modelo bueno interpreta resultados y escribe conclusiones.
Traducción: modelo barato traduce literal, modelo bueno corrige naturalidad y contexto cultural.
Refactorización de código: modelo barato aplica transformaciones mecánicas, modelo bueno verifica que el comportamiento no cambia.

Menos útil para

Razonamiento profundo: problemas de matemáticas, lógica formal, puzzles. Aquí necesitas el mejor modelo desde el inicio.
Escritura creativa: si la “voz” y el estilo son el producto (ficción, copy creativo), el drafter barato pierde matices que el reviewer no puede recuperar.
Conversaciones en tiempo real: la latencia se acumula (3 llamadas secuenciales). Para chat, un solo modelo medio es mejor.
Tareas triviales: si el output es un “sí” o “no”, no necesitas un pipeline.

La regla del 80/20 aplicada a modelos

El principio general: usa el modelo más barato que pueda hacer el trabajo.

En la práctica, la distribución típica en un pipeline de producción es:

70% de tareas → modelo barato (Haiku 3.5, GPT-4o-mini, GLM-5)
25% de tareas → modelo medio (Sonnet 4, GPT-4o)
5% de tareas → modelo frontier (Opus 4)

El coste total cae dramáticamente sin sacrificar calidad donde importa. Los modelos frontier son para las decisiones que realmente importan — no para generar la primera versión de un email que nadie va a leer dos veces.

Si necesitas más contexto sobre cómo elegir modelos por tarea (no por fase), la guía de costes y routing cubre esa parte.

Alternativas y herramientas

Herramienta	Qué hace	Cuándo usarla
LiteLLM	Router que abstrae providers, puede implementar drafter/reviewer	Equipo pequeño, multi-provider
OpenRouter	Acceso unificado a modelos con una API key	Probar muchos modelos sin contratos
Pith	Proxy con smart routing basado en complejidad	Ya tiene artículo propio
Hermes / OpenClaw	Asignación de modelos por agente/rol	Setup multi-agente con routing automático

Conclusión

El patrón drafter/reviewer/approver no es nuevo, pero en 2026 es más relevante que nunca. La brecha de precio entre modelos frontier y baratos se ha ampliado, mientras que los modelos baratos han mejorado lo suficiente para generar borradores decentes.

Si estás pagando modelos frontier para generar contenido, code review o análisis de datos, estás probablemente gastando 5-10x de más de lo necesario. Empieza con un pipeline simple (Haiku drafter + Sonnet reviewer) y añade el approver solo donde la precisión sea crítica.

La parte incómoda: este patrón requiere más código y más mantenimiento que una llamada directa. Si tu proyecto tiene 3 prompts y 100 usuarios, probablemente no compense. Si tiene 30 prompts y 10,000 tareas al día, el ahorro justifica la complejidad.

Fuentes: Anthropic Pricing, OpenAI Pricing, Z.ai GLM Pricing. Discusiones en r/LocalLLaMA y r/better_claw sobre pipelines multi-modelo. Precios consultados: mayo 2026.