Módulo 1: Arquitectura de sistemas basados en prompts

1

Prompt como unidad arquitectónica

Pensar en bloques de construcción

Cambio de paradigma

Un prompt no es texto: es una unidad arquitectónica con interfaz, contrato de comportamiento, dependencias y responsabilidades definidos.

Visión tradicional

• Prompt = texto que genera una respuesta
• Éxito = respuesta "buena"
• Iteración = ajustar palabras
• Escala = copiar y pegar

Visión arquitectónica

• Prompt = componente con contrato
• Éxito = comportamiento predecible
• Iteración = refinar la interfaz
• Escala = composición y reutilización

Anatomía de un prompt como componente

┌─────────────────────────────────────────────────────┐
│  PROMPT COMPONENT: "order_analyzer"                 │
├─────────────────────────────────────────────────────┤
│  INTERFACE                                          │
│  ├─ Input: OrderData, CustomerHistory               │
│  ├─ Output: AnalysisResult (structured)             │
│  └─ Errors: InsufficientData, AmbiguousOrder        │
├─────────────────────────────────────────────────────┤
│  CONTRACT                                           │
│  ├─ Preconditions: order.status == "pending"        │
│  ├─ Postconditions: result.confidence > 0.8         │
│  └─ Invariants: no side effects                     │
├─────────────────────────────────────────────────────┤
│  DEPENDENCIES                                       │
│  ├─ Requires: product_catalog (context)             │
│  ├─ Requires: pricing_rules (context)               │
│  └─ Optional: customer_preferences                  │
├─────────────────────────────────────────────────────┤
│  IMPLEMENTATION                                     │
│  └─ [prompt template with slots]                    │
└─────────────────────────────────────────────────────┘

Beneficios de la visión arquitectónica

🔄

Reutilización

🧪

Capacidad de prueba

📈

Escalabilidad

2

Arquitecturas de un solo prompt vs. múltiples prompts

Decidir la estructura del sistema

Mono-Prompt

Un único prompt que maneja toda la complejidad. Contexto completo en una llamada.

✓ Simplicidad de implementación

✓ Latencia baja (1 llamada)

✓ Contexto unificado

✗ Límite de complejidad

✗ Difícil de probar por partes

Multi-Prompt

Múltiples prompts especializados que se comunican. Descomposición de responsabilidades.

✓ Modularidad

✓ Capacidad de prueba por componente

✓ Escalabilidad de la complejidad

✗ Latencia mayor

✗ Pérdida de contexto entre llamadas

Matriz de Decisión

Criterio	Mono	Multi
Tarea simple y bien definida	✓	—
Múltiples etapas dependientes	—	✓
Latencia crítica	✓	—
Reutilización de componentes	—	✓
Trazabilidad de las decisiones	—	✓

3

Capas arquitectónicas de sistemas LLM

Separación de responsabilidades

Arquitectura en capas

┌─────────────────────────────────────────────────────┐
│  PRESENTATION LAYER                                 │
│  • Interface com usuário                            │
│  • Formatação de entrada/saída                      │
│  • Validação de input                               │
├─────────────────────────────────────────────────────┤
│  ORCHESTRATION LAYER                                │
│  • Roteamento de requests                           │
│  • Composição de prompts                            │
│  • Gestão de fluxo                                  │
├─────────────────────────────────────────────────────┤
│  BUSINESS LOGIC LAYER                               │
│  • Skills especializadas                            │
│  • Regras de negócio                                │
│  • Transformações de dados                          │
├─────────────────────────────────────────────────────┤
│  CONTEXT LAYER                                      │
│  • Gestão de contexto                               │
│  • RAG / Retrieval                                  │
│  • Memory management                                │
├─────────────────────────────────────────────────────┤
│  MODEL LAYER                                        │
│  • Abstração de LLM                                 │
│  • Fallbacks                                        │
│  • Rate limiting                                    │
└─────────────────────────────────────────────────────┘

Principio: Separation of Concerns

Cada capa tiene una responsabilidad única. Los cambios en una capa no afectan a las demás. Permite una evolución independiente.

Principio: Dependency Inversion

Las capas superiores no dependen de implementaciones específicas. Las abstracciones permiten cambiar los LLM o las fuentes de datos.

4

Contratos de comportamiento entre prompts

Garantías y expectativas

Los contratos definen lo que un prompt garantiza que se haga y lo que él espera recibir. Sin contratos, los sistemas de prompts son frágiles.

Elementos de un Contrato

Precondiciones

Lo que debe ser verdad ANTES de llamar al prompt.


                                    input.length < 10000

Postcondiciones

Qué será cierto DESPUÉS de la ejecución.


                                    output.format == "json"

Invariants

Lo que NUNCA cambia durante la ejecución.


                                    no_external_calls

Error Conditions

Cómo se señalan los errores.


                                    throws: AmbiguousInput

Ejemplo de contrato documentado

/**
 * @contract SentimentAnalyzer
 *
 * @precondition text.length > 0 && text.length < 5000
 * @precondition language in ["pt", "en", "es"]
 *
 * @postcondition result.sentiment in ["positive", "negative", "neutral"]
 * @postcondition result.confidence >= 0.0 && result.confidence <= 1.0
 * @postcondition result.reasoning.length > 0
 *
 * @invariant deterministic for same input (temperature=0)
 * @invariant no PII in output
 *
 * @throws EmptyInputError if text is empty
 * @throws UnsupportedLanguageError if language not supported
 * @throws LowConfidenceError if confidence < 0.5
 */

5

Patrones arquitectónicos recurrentes

Soluciones comprobadas

Cadena de responsabilidad

Prompts en cadena, donde cada uno puede resolver el problema o pasarlo al siguiente.

intent → router → specialist → fallback

Pipeline

Transformaciones secuenciales en las que el resultado de una es la entrada de la siguiente.

extract → transform → validate → format

Supervisor

Un prompt coordina y valida el trabajo de otros prompts.

supervisor → [workers] → aggregator

Reflection

El prompt analiza y mejora su propio resultado de forma iterativa.

generate → critique → refine → validate

Cuándo usar cada patrón

Cadena Enrutamiento dinámico, alternativas, escalamiento

Pipeline ETL de datos, procesamiento por etapas

Supervisor Tareas paralelas, agregación, validación cruzada

Reflection Calidad crítica, autocorrección y refinamiento

6

Análisis de arquitecturas reales

Casos de estudio en producción

Caso: asistente de soporte técnico

USER QUERY
    │
    ▼
┌─────────────────┐
│  INTENT ROUTER  │ ← Classifica intenção
└────────┬────────┘
         │
    ┌────┴────┬────────────┐
    ▼         ▼            ▼
┌───────┐ ┌───────┐ ┌──────────┐
│ FAQ   │ │TROUBLE│ │ ESCALATE │
│ MATCH │ │ SHOOT │ │ TO HUMAN │
└───┬───┘ └───┬───┘ └────┬─────┘
    │         │          │
    └────┬────┴──────────┘
         ▼
┌─────────────────┐
│   FORMATTER     │ ← Formata resposta
└────────┬────────┘
         ▼
┌─────────────────┐
│  SAFETY CHECK   │ ← Valida antes de enviar
└─────────────────┘

Caso: sistema de code review

PR DIFF
    │
    ▼
┌─────────────────────────────────────┐
│           SUPERVISOR                │
│  "Coordinate review, aggregate"     │
└────────────────┬────────────────────┘
                 │
    ┌────────────┼────────────┐
    ▼            ▼            ▼
┌────────┐  ┌────────┐  ┌────────┐
│SECURITY│  │ STYLE  │  │ LOGIC  │
│ CHECK  │  │ CHECK  │  │ CHECK  │
└───┬────┘  └───┬────┘  └───┬────┘
    │           │           │
    └─────┬─────┴───────────┘
          ▼
┌─────────────────────────────────────┐
│         AGGREGATOR                  │
│  "Consolidate, prioritize issues"   │
└────────────────┬────────────────────┘
                 ▼
┌─────────────────────────────────────┐
│         FORMATTER                   │
│  "Format as GitHub PR comment"      │
└─────────────────────────────────────┘

Ejercicio: analiza la arquitectura

Para cada estudio de caso, identifica:

1. ¿Qué patrón arquitectónico se utilizó?
2. ¿Cuáles son los contratos entre los componentes?
3. ¿Dónde están los puntos de falla?
4. ¿Cómo mejorarías la arquitectura?