Empezar aquí
Patrón · fundamento

Qué patrón elegir

Un árbol de decisión y una tabla comparativa para escoger el patrón más simple que resuelve tu caso, con su coste, su latencia y las señales para cambiar.

Cuándo usarlo
Al empezar un sistema nuevo o cuando el actual falla y dudas si necesitas más complejidad.
Cuándo no
No sustituye a medir: si ya tienes evals que comparan dos diseños, decide con sus resultados.
Publicado 4 min de lectura

Esta página condensa la sección en una herramienta de decisión. La regla que la guía viene de Building effective agents (Anthropic, 2024): elige la solución más simple que funcione y añade complejidad solo cuando demuestre que mejora el resultado. El árbol te lleva al patrón candidato; la tabla te dice qué pagas por él; las señales del final te dicen cuándo cambiar.

Qué es

Un recorrido de preguntas en orden. Cada respuesta “no” te deja en un peldaño más bajo de la escalera de complejidad, que es donde quieres quedarte si puedes.

flowchart TB
  A{¿Una llamada con buen prompt acierta?} -- sí --> P0[Llamada simple]
  A -- no --> B{¿Faltan datos o acciones externas?}
  B -- sí --> P1[Llamada aumentada]
  B -- no --> C{¿Puedes escribir los pasos antes?}
  P1 --> C
  C -- sí --> D{¿Hay tipos de entrada distintos?}
  D -- sí --> P3[Enrutado]
  D -- no --> P2[Encadenado o paralelización]
  C -- no --> E{¿Se divide en partes según la entrada?}
  E -- sí --> P4[Orquestador y trabajadores]
  E -- no --> P5[Agente autónomo]

Dos preguntas transversales se aplican sobre cualquier hoja:

  • ¿Hay un criterio claro de calidad y una crítica mejora el resultado? Añade un bucle de evaluador-optimizador alrededor del paso que falla.
  • ¿Hay aspectos independientes o necesitas más confianza? Añade paralelización, por seccionado o por votación.

Tabla comparativa

PatrónQuién decide el flujoCosteLatenciaÚsalo para
La llamada aumentadaTu códigoBajoBajaResponder con datos propios o una acción puntual
Encadenado de promptsTu código, en serieMedioMediaFases fijas con validación entre ellas
EnrutadoTu código, según una clasificaciónBajoMediaCategorías que se atienden mejor por separado
ParalelizaciónTu código, en paraleloMedioBajaAspectos independientes o votación
Orquestador y trabajadoresUn modelo planifica; tu código ejecutaAltoMediaSubtareas que dependen de la entrada
Evaluador-optimizadorTu código, en bucle con topeAltoAltaCalidad con rúbrica clara
Agente autónomoEl modelo, en bucleAlto y variableAlta y variableProblemas abiertos con feedback del entorno

Coste y latencia son relativos entre patrones, para la misma tarea y el mismo modelo. Las cifras reales dependen de tus prompts, del modelo y del tamaño del contexto: mídelas con Coste y latencia: medir antes de optimizar.

Cuándo usarlo

  • Al diseñar desde cero: recorre el árbol con tres o cuatro entradas reales delante, no con la idea general del producto.
  • Cuando un sistema falla: identifica el tipo de fallo antes de añadir piezas. La tabla de señales de abajo te ayuda.
  • Para explicar una decisión al equipo: la tabla da un vocabulario común para justificar por qué no hace falta un agente.

Cuándo no

El árbol es una heurística. Si ya tienes un conjunto de evaluación y puedes probar dos diseños, la medición manda. Tampoco lo uses para elegir un único patrón para todo el producto: lo normal es combinar varios, cada uno donde encaja.

Ejemplo concreto

Un asistente para un despacho de abogados que responde consultas sobre contratos de clientes.

  1. ¿Una llamada basta? No: el modelo no conoce los contratos.
  2. ¿Faltan datos? Sí: llamada aumentada con recuperación sobre los contratos. Se convierte en RAG con citas verificables.
  3. ¿Pasos fijos? Sí para las consultas sobre una cláusula: recuperar, responder, verificar citas. Eso es un encadenado.
  4. ¿Tipos distintos? Sí: “consulta de cláusula” frente a “comparar varios contratos”. Enrutado delante.
  5. La ruta “comparar varios contratos” se divide según cuántos contratos se mencionen: orquestador y trabajadores.

Resultado: enrutado → (encadenado | orquestador-trabajadores), todo sobre llamadas aumentadas. Ningún agente autónomo, porque ningún flujo requiere decidir pasos imprevisibles.

Señales para cambiar de patrón

Lo que ves en las trazasQué probar
Un único prompt cumple unas reglas y olvida otrasDivide la tarea en pasos: Encadenado de prompts
Un arreglo para un tipo de caso estropea otroSepara los casos: Enrutado
Tu cadena tiene ramas if que crecen sin pararPlantéate un orquestador o un agente: Orquestador y trabajadores
El resultado es aceptable pero mejora cuando lo criticas a manoAñade un bucle de crítica: Evaluador-optimizador
El agente repite siempre la misma secuencia de herramientasBájalo a workflow: ya conoces los pasos
El agente gasta muchos pasos en lo mismoMejora las herramientas antes que el prompt: Diseño de herramientas

Esqueleto de código

No hay un esqueleto propio: cada patrón tiene el suyo en su página. Lo que sí conviene es un arnés común para comparar diseños con los mismos casos. Así la decisión sale de datos.

import time

def comparar(disenos: dict, casos: list[dict], evaluar) -> None:
    """disenos: {"encadenado": funcion, "agente": funcion}; casos: [{"entrada", "esperado"}]"""
    for nombre, sistema in disenos.items():
        aciertos, tiempos = 0, []
        for caso in casos:
            inicio = time.perf_counter()
            salida = sistema(caso["entrada"])
            tiempos.append(time.perf_counter() - inicio)
            aciertos += evaluar(salida, caso["esperado"])
        tiempos.sort()
        print(f"{nombre}: {aciertos}/{len(casos)} aciertos · "
              f"mediana {tiempos[len(tiempos) // 2]:.1f} s")

Añade el coste sumando resp.usage en cada sistema. Tienes evaluadores listos en Evaluar con código o con un modelo juez.

Patrones relacionados

Volver arriba ↑