Cápsula 06: Recomendación por Escenarios

Descripción de la cápsula

Hasta ahora tienes criterios, pesos y una matriz de scoring. Pero una matriz sin contexto es solo una hoja de cálculo. En esta cápsula vas a aplicar el framework completo a cuatro escenarios realistas que cubren el espectro típico de un AI engineer: desde el solo developer que quiere validar una idea, hasta la empresa con regulaciones estrictas y equipos grandes.

El objetivo no es darte "la respuesta correcta" (no existe), sino mostrarte cómo los mismos criterios producen recomendaciones diferentes cuando cambian las restricciones. Al final, tendrás plantillas reutilizables que podrás adaptar a cualquier escenario que enfrentes en tu carrera.

Cada recomendación incluye justificación numérica, trade-offs explícitos y triggers de reevaluación. Así, cuando alguien te pregunte "¿por qué elegiste X?", podrás responder con datos, no con opiniones.

Por qué los escenarios importan más que los benchmarks

Un benchmark te dice que Qdrant es 15% más rápido que Weaviate en un dataset sintético de 1M vectores. Eso es útil. Pero no te dice si Qdrant es mejor para ti. Tu equipo, tu presupuesto, tus plazos y tus regulaciones cambian la respuesta completamente.

Los escenarios capturan lo que los benchmarks no pueden:

┌─────────────────────────────────────────────────┐
│              BENCHMARK                          │
│  "Qdrant: 45ms p95 @ 1M vectors"              │
│                                                 │
│  ✗ No dice si tu equipo sabe operarlo          │
│  ✗ No dice si cabe en tu presupuesto           │
│  ✗ No dice si cumple compliance                │
│  ✗ No dice si escala con tu crecimiento        │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│              ESCENARIO                          │
│  "Startup de 3 devs, 200K vectores,            │
│   $300/mes, sin DevOps, MVP en 8 semanas"      │
│                                                 │
│  ✓ Filtra opciones irrealizables               │
│  ✓ Prioriza criterios reales                   │
│  ✓ Produce recomendación accionable            │
│  ✓ Define cuándo reevaluar                     │
└─────────────────────────────────────────────────┘

Framework de recomendación por escenario

Antes de analizar cada escenario, aquí está el proceso que seguirás:

from dataclasses import dataclass, field
from typing import Optional


@dataclass
class Scenario:
    name: str
    team_size: int
    has_devops: bool
    vector_count_now: int
    vector_count_12m: int
    budget_monthly_usd: int
    latency_p95_ms: int
    compliance_required: bool
    timeline_weeks: int
    description: str = ""


@dataclass
class Recommendation:
    scenario: Scenario
    primary: str
    alternative: str
    scores: dict
    decisive_criteria: list
    risks: list
    reevaluation_trigger: str


def recommend_for_scenario(
    scenario: Scenario,
    weights: dict,
    providers: dict[str, dict],
) -> Recommendation:
    """
    Aplica la matriz de scoring a un escenario específico
    y genera recomendación con justificación.
    """
    scores = {}
    for provider_name, provider_scores in providers.items():
        total = 0
        max_total = 0
        for criterion, weight in weights.items():
            total += weight * provider_scores.get(criterion, 0)
            max_total += weight * 1.0
        scores[provider_name] = round((total / max_total) * 100, 1)

    ranked = sorted(scores.items(), key=lambda x: x[1], reverse=True)

    top_criteria = sorted(weights.items(), key=lambda x: x[1], reverse=True)
    decisive = [c[0] for c in top_criteria[:3]]

    return Recommendation(
        scenario=scenario,
        primary=ranked[0][0],
        alternative=ranked[1][0],
        scores=scores,
        decisive_criteria=decisive,
        risks=_identify_risks(scenario, ranked[0][0], providers[ranked[0][0]]),
        reevaluation_trigger=_suggest_trigger(scenario),
    )


def _identify_risks(scenario, provider, scores):
    risks = []
    for criterion, score in scores.items():
        if score < 0.5:
            risks.append(f"{criterion}: score bajo ({score})")
    if scenario.vector_count_12m > scenario.vector_count_now * 5:
        risks.append("Crecimiento >5x en 12 meses")
    return risks


def _suggest_trigger(scenario):
    if scenario.timeline_weeks <= 8:
        return "Reevaluar al completar MVP"
    elif scenario.vector_count_12m > 1_000_000:
        return "Reevaluar al alcanzar 500K vectores"
    return "Reevaluar trimestralmente"

Escenario 1: Solo Developer — Validación de idea

Contexto

solo_dev = Scenario(
    name="Solo Developer - Validación de idea",
    team_size=1,
    has_devops=False,
    vector_count_now=10_000,
    vector_count_12m=100_000,
    budget_monthly_usd=50,
    latency_p95_ms=500,
    compliance_required=False,
    timeline_weeks=4,
    description="Developer indie validando si RAG agrega valor a su producto",
)

Pesos ajustados al escenario

Cuando eres solo developer, la velocidad de setup y el costo dominan todo lo demás:

weights_solo = {
    "setup_speed": 5,       # necesitas algo corriendo hoy
    "cost_control": 5,      # presupuesto personal
    "ops_simplicity": 5,    # no hay equipo de soporte
    "documentation": 4,     # aprenderás solo con docs
    "scale": 2,             # no es prioridad todavía
    "latency": 2,           # 500ms es aceptable para MVP
    "compliance": 1,        # no aplica
}

Scoring de proveedores

providers_solo = {
    "ChromaDB_local": {
        "setup_speed": 1.0,
        "cost_control": 1.0,
        "ops_simplicity": 0.9,
        "documentation": 0.8,
        "scale": 0.4,
        "latency": 0.7,
        "compliance": 0.3,
    },
    "Pinecone_starter": {
        "setup_speed": 0.9,
        "cost_control": 0.7,
        "ops_simplicity": 1.0,
        "documentation": 0.9,
        "scale": 0.8,
        "latency": 0.9,
        "compliance": 0.5,
    },
    "Qdrant_cloud_free": {
        "setup_speed": 0.8,
        "cost_control": 0.9,
        "ops_simplicity": 0.8,
        "documentation": 0.7,
        "scale": 0.7,
        "latency": 0.85,
        "compliance": 0.4,
    },
}

result = recommend_for_scenario(solo_dev, weights_solo, providers_solo)

Resultado

Recomendación

Primary: ChromaDB local — setup en 5 minutos, cero costo de infra, ideal para iterar rápido.

Alternativa: Pinecone Starter — si prefieres no gestionar nada y aceptas el free tier con límites.

Trade-offs explícitos

Trigger de reevaluación

Reevalúa cuando: (a) superes 50K vectores activos, (b) necesites queries concurrentes de múltiples usuarios, o (c) valides product-market fit y decidas escalar.

Escenario 2: Startup pequeña — Producto en construcción

Contexto

startup = Scenario(
    name="Startup pequeña - Producto en construcción",
    team_size=4,
    has_devops=False,
    vector_count_now=200_000,
    vector_count_12m=1_500_000,
    budget_monthly_usd=500,
    latency_p95_ms=300,
    compliance_required=False,
    timeline_weeks=12,
    description="Equipo de 4 devs construyendo SaaS con RAG como feature core",
)

Pesos ajustados

El balance cambia: ahora la escala importa porque esperas crecimiento real, y la latencia empieza a ser un diferenciador:

weights_startup = {
    "scale": 4,             # crecimiento esperado 7x
    "latency": 4,           # diferenciador de UX
    "ops_simplicity": 5,    # sin DevOps dedicado
    "cost_control": 4,      # runway limitado
    "setup_speed": 3,       # tienes 12 semanas
    "documentation": 3,     # equipo puede invertir en aprender
    "compliance": 1,        # no aplica aún
}

Scoring y resultado

providers_startup = {
    "Pinecone_standard": {
        "scale": 0.9, "latency": 0.9, "ops_simplicity": 1.0,
        "cost_control": 0.6, "setup_speed": 0.9,
        "documentation": 0.9, "compliance": 0.5,
    },
    "Qdrant_cloud": {
        "scale": 0.85, "latency": 0.85, "ops_simplicity": 0.8,
        "cost_control": 0.8, "setup_speed": 0.7,
        "documentation": 0.7, "compliance": 0.5,
    },
    "Weaviate_cloud": {
        "scale": 0.85, "latency": 0.8, "ops_simplicity": 0.85,
        "cost_control": 0.7, "setup_speed": 0.75,
        "documentation": 0.8, "compliance": 0.5,
    },
}

Recomendación

Primary: Pinecone Standard — ops simplicity máxima, escala probada, permite al equipo enfocarse en producto.

Alternativa: Qdrant Cloud — mejor relación costo/control, más opciones de tuning si el equipo invierte tiempo.

Trade-offs

Trigger de reevaluación

Reevalúa cuando: (a) el costo managed supere 15% del cloud budget total, (b) necesites features que el managed no soporte (custom indexes, on-prem), o (c) levantes ronda y puedas contratar DevOps.

Escenario 3: Equipo mid-size — SaaS en crecimiento

Contexto

midsize = Scenario(
    name="Mid-size team - SaaS en crecimiento",
    team_size=15,
    has_devops=True,
    vector_count_now=5_000_000,
    vector_count_12m=20_000_000,
    budget_monthly_usd=3000,
    latency_p95_ms=150,
    compliance_required=False,
    timeline_weeks=16,
    description="Equipo con SRE, SaaS multi-tenant, SLA de 99.9%",
)

Pesos ajustados

Con equipo de DevOps, la simplicidad operativa baja de prioridad. Escala, latencia y SLA dominan:

weights_midsize = {
    "scale": 5,             # 20M vectores en 12 meses
    "latency": 5,           # p95 < 150ms es agresivo
    "multi_tenancy": 5,     # SaaS multi-tenant
    "sla_guarantee": 4,     # 99.9% uptime
    "ops_simplicity": 3,    # tienen SRE
    "cost_control": 3,      # presupuesto razonable
    "compliance": 2,        # no estricto pero importa
}

Scoring y resultado

providers_midsize = {
    "Pinecone_enterprise": {
        "scale": 0.9, "latency": 0.85, "multi_tenancy": 0.9,
        "sla_guarantee": 0.95, "ops_simplicity": 1.0,
        "cost_control": 0.5, "compliance": 0.7,
    },
    "Qdrant_self_hosted": {
        "scale": 0.85, "latency": 0.9, "multi_tenancy": 0.7,
        "sla_guarantee": 0.7, "ops_simplicity": 0.5,
        "cost_control": 0.9, "compliance": 0.8,
    },
    "Weaviate_enterprise": {
        "scale": 0.85, "latency": 0.8, "multi_tenancy": 0.85,
        "sla_guarantee": 0.85, "ops_simplicity": 0.8,
        "cost_control": 0.6, "compliance": 0.75,
    },
    "Milvus_self_hosted": {
        "scale": 0.95, "latency": 0.85, "multi_tenancy": 0.6,
        "sla_guarantee": 0.6, "ops_simplicity": 0.4,
        "cost_control": 0.85, "compliance": 0.7,
    },
}

Recomendación

Primary: Pinecone Enterprise — SLA garantizado, multi-tenancy nativo, libera al equipo SRE para otros problemas.

Alternativa: Weaviate Enterprise — buen balance entre managed y control, hybrid search nativo que puede diferenciar el producto.

Análisis de costo a 12 meses

Self-hosted parece más barato en infra, pero las horas de operación lo hacen más caro en TCO total.

Trigger de reevaluación

Reevalúa cuando: (a) el costo managed supere $5K/mes, (b) necesites custom sharding por región, o (c) tu SLA suba a 99.99%.

Escenario 4: Enterprise — Compliance y control estricto

Contexto

enterprise = Scenario(
    name="Enterprise - Compliance estricto",
    team_size=50,
    has_devops=True,
    vector_count_now=50_000_000,
    vector_count_12m=200_000_000,
    budget_monthly_usd=15000,
    latency_p95_ms=100,
    compliance_required=True,
    timeline_weeks=24,
    description="Empresa regulada, datos sensibles, self-hosted obligatorio, auditorías externas",
)

Pesos ajustados

Compliance y control no son negociables. Todo lo demás se optimiza alrededor de esas restricciones:

weights_enterprise = {
    "compliance": 5,        # no negociable
    "data_residency": 5,    # datos en jurisdicción específica
    "scale": 5,             # 200M vectores
    "latency": 4,           # p95 < 100ms
    "audit_trail": 4,       # auditorías externas
    "ops_simplicity": 2,    # equipo dedicado disponible
    "cost_control": 2,      # presupuesto amplio
}

Scoring y resultado

providers_enterprise = {
    "Qdrant_self_hosted": {
        "compliance": 0.9, "data_residency": 1.0, "scale": 0.85,
        "latency": 0.9, "audit_trail": 0.7, "ops_simplicity": 0.5,
        "cost_control": 0.85,
    },
    "Weaviate_self_hosted": {
        "compliance": 0.85, "data_residency": 1.0, "scale": 0.8,
        "latency": 0.8, "audit_trail": 0.7, "ops_simplicity": 0.55,
        "cost_control": 0.8,
    },
    "Milvus_self_hosted": {
        "compliance": 0.8, "data_residency": 1.0, "scale": 0.95,
        "latency": 0.85, "audit_trail": 0.6, "ops_simplicity": 0.4,
        "cost_control": 0.8,
    },
    "Pinecone_enterprise": {
        "compliance": 0.6, "data_residency": 0.4, "scale": 0.9,
        "latency": 0.85, "audit_trail": 0.8, "ops_simplicity": 1.0,
        "cost_control": 0.5,
    },
}

Recomendación

Primary: Qdrant Self-hosted — mejor balance compliance + performance, API moderna, comunidad activa para soporte.

Alternativa: Weaviate Self-hosted — hybrid search nativo es ventaja si el caso de uso lo necesita, buena documentación de deployment enterprise.

Por qué Pinecone NO funciona aquí

A pesar de ser excelente en ops y SLA, Pinecone falla en los criterios no negociables de este escenario:

Trigger de reevaluación

Reevalúa cuando: (a) Pinecone o proveedores managed ofrezcan deployment on-prem/dedicated, (b) cambien regulaciones de residencia de datos, o (c) escala supere capacidades del cluster actual.

Tabla comparativa de escenarios

Recomendación por variable dominante

A veces no encajas en un escenario tipo. En ese caso, busca tu variable dominante:

Por presupuesto

Por tamaño de equipo

Por compliance

Anti-patrones de recomendación

Errores que ves repetidamente en equipos reales:

Anti-patrón 1: "Elegimos por el benchmark"

❌ "Milvus es el más rápido en ANN Benchmarks, vamos con Milvus"

✓ "Milvus tiene mejor throughput raw, pero nuestro equipo de 3 no puede 
   operar un cluster distribuido. Pinecone nos da 85% del performance 
   con 0% del ops overhead."

Anti-patrón 2: "Elegimos para el futuro lejano"

❌ "Algún día tendremos 100M vectores, así que necesitamos Milvus ahora"

✓ "Tenemos 50K vectores hoy, llegaremos a 500K en 12 meses. ChromaDB 
   cubre eso. Migraremos cuando alcancemos 1M y tengamos presupuesto 
   para managed."

Anti-patrón 3: "Open source es gratis"

❌ "Qdrant es open source = $0"

✓ "Qdrant self-hosted cuesta $200/mes en infra + 15hrs/mes de operación.
   A $50/hr = $950/mes total. Qdrant Cloud cuesta $180/mes con 2hrs/mes 
   de ops = $280/mes total."

Anti-patrón 4: "El CTO ya decidió"

❌ "El CTO quiere Pinecone porque lo vio en una conferencia"

✓ "Respetamos la preferencia, pero aquí está la matriz: Pinecone score 
   72 vs Qdrant 84 para nuestro escenario. La diferencia está en costo 
   y compliance. ¿Revisamos juntos los pesos?"

Troubleshooting

"Mis recomendaciones cambian cada semana"

Esto pasa cuando los pesos no están anclados a restricciones reales. Congela criterios y pesos por ciclo trimestral. Si un stakeholder quiere cambiar un peso, debe justificar qué restricción cambió. Pon los pesos en un documento compartido con fecha de última revisión y próxima revisión programada.

"Un proveedor gana por muy poco (menos de 3 puntos)"

No elijas por décimas. Cuando dos opciones están a menos de 5 puntos de diferencia, aplica el tie-breaker de simplicidad: elige la opción que requiera menos cambios operativos para tu equipo actual. Si siguen empatadas, elige la que tenga menor costo de salida (exit cost).

"No logro justificar la alternativa al equipo"

Incluye explícitamente el criterio donde la opción principal es más débil. Por ejemplo: "Pinecone es nuestra recomendación principal (score 84), pero si el costo managed supera $X/mes, Qdrant self-hosted (score 81) nos ahorra 40% con trade-off de 15hrs/mes de ops."

"El escenario no encaja en ninguno de los cuatro"

Mezcla los pesos de los escenarios más cercanos. Un equipo de 8 devs con compliance parcial toma pesos del startup pero sube compliance a 4. No necesitas un escenario exacto: necesitas pesos que reflejen tus restricciones reales.

"El negocio cambió: pasamos de startup a enterprise"

No rehagas todo. Actualiza solo los pesos que cambiaron (compliance sube, cost_control baja), recalcula scores, y documenta el delta. Si el ranking cambia, planifica migración con timeline realista.

Ejercicios

Ejercicio 1: Personaliza tu escenario

Crea un Scenario para tu situación actual (real o proyectada). Define los 7 campos obligatorios y calcula scores para al menos 3 proveedores.

mi_escenario = Scenario(
    name="EdTech startup - plataforma de tutoring AI",
    team_size=3,
    has_devops=False,
    vector_count_now=80_000,
    vector_count_12m=400_000,
    budget_monthly_usd=200,
    latency_p95_ms=400,
    compliance_required=False,
    timeline_weeks=10,
)

weights = {
    "setup_speed": 4,
    "cost_control": 5,
    "ops_simplicity": 5,
    "scale": 3,
    "latency": 3,
    "documentation": 4,
    "compliance": 1,
}

providers = {
    "ChromaDB_local": {
        "setup_speed": 1.0, "cost_control": 1.0, "ops_simplicity": 0.9,
        "scale": 0.5, "latency": 0.7, "documentation": 0.8, "compliance": 0.3,
    },
    "Qdrant_cloud": {
        "setup_speed": 0.8, "cost_control": 0.8, "ops_simplicity": 0.8,
        "scale": 0.8, "latency": 0.85, "documentation": 0.7, "compliance": 0.5,
    },
    "Pinecone_starter": {
        "setup_speed": 0.9, "cost_control": 0.6, "ops_simplicity": 1.0,
        "scale": 0.9, "latency": 0.9, "documentation": 0.9, "compliance": 0.5,
    },
}

result = recommend_for_scenario(mi_escenario, weights, providers)
# ChromaDB gana por costo + setup, pero Qdrant Cloud es alternativa
# sólida si esperas crecer a 400K en 12 meses.

Ejercicio 2: Cambia los pesos y observa el efecto

Toma el Escenario 2 (Startup) y haz tres variaciones de pesos. Registra cómo cambia el ranking.

# Variación A: prioriza costo sobre todo
weights_cost_first = {
    "scale": 3, "latency": 3, "ops_simplicity": 4,
    "cost_control": 5, "setup_speed": 3,
    "documentation": 2, "compliance": 1,
}
# Resultado: Qdrant Cloud sube al #1 (mejor relación calidad/precio)

# Variación B: prioriza latencia y SLA
weights_perf_first = {
    "scale": 4, "latency": 5, "ops_simplicity": 3,
    "cost_control": 2, "setup_speed": 2,
    "documentation": 2, "compliance": 1,
}
# Resultado: Pinecone se mantiene #1 (mejor latency score)

# Variación C: prioriza flexibilidad y control
weights_control_first = {
    "scale": 4, "latency": 3, "ops_simplicity": 2,
    "cost_control": 4, "setup_speed": 2,
    "documentation": 3, "compliance": 3,
}
# Resultado: Qdrant Cloud sube al #1 (open source = más control)

# Conclusión: la recomendación es sensible a los pesos.
# Documenta POR QUÉ cada peso tiene ese valor.

Ejercicio 3: Detecta el anti-patrón

Lee estas tres justificaciones y señala cuál anti-patrón comete cada una:

1. "Elegimos Milvus porque soporta 1 billón de vectores y nosotros tenemos 50K."
2. "Weaviate es open source así que es gratis."
3. "Nuestro inversor nos dijo que usemos Pinecone."

Ejercicio 4: Diseña trigger de reevaluación

Para cada escenario (1-4), define tres métricas concretas que dispararían una reevaluación de la decisión.

Ejercicio 5: Matriz para tu Decision Questionnaire

Conexión con proyecto: Toma tres de las preguntas de tu Decision Questionnaire (cápsula 08) y asigna cómo cada respuesta posible modifica los pesos de la matriz.

def adjust_weights_from_questionnaire(base_weights: dict, answers: dict) -> dict:
    """Ajusta pesos según respuestas del cuestionario."""
    adjusted = base_weights.copy()

    # Pregunta: "¿Cuántos vectores manejarás en 12 meses?"
    if answers.get("vectors_12m", 0) > 1_000_000:
        adjusted["scale"] = max(adjusted.get("scale", 3), 5)

    # Pregunta: "¿Tienes equipo de DevOps?"
    if not answers.get("has_devops", False):
        adjusted["ops_simplicity"] = max(adjusted.get("ops_simplicity", 3), 5)

    # Pregunta: "¿Necesitas compliance (HIPAA, SOC2, etc.)?"
    if answers.get("compliance_required", False):
        adjusted["compliance"] = 5
        adjusted["data_residency"] = 5

    return adjusted


base = {
    "scale": 3, "latency": 3, "ops_simplicity": 3,
    "cost_control": 3, "compliance": 1,
}
answers = {
    "vectors_12m": 2_000_000,
    "has_devops": False,
    "compliance_required": True,
}
result = adjust_weights_from_questionnaire(base, answers)
# {'scale': 5, 'latency': 3, 'ops_simplicity': 5,
#  'cost_control': 3, 'compliance': 5, 'data_residency': 5}

Resumen

• Los benchmarks miden performance aislado; los escenarios capturan restricciones reales como equipo, presupuesto y compliance.
• Para solo developer: prioriza setup speed y costo cero (ChromaDB local).
• Para startups: prioriza ops simplicity y costo predecible (managed cloud).
• Para mid-size con SRE: optimiza SLA y multi-tenancy (enterprise managed).
• Para enterprise regulado: compliance y data residency no son negociables (self-hosted).
• Documenta siempre trade-offs y triggers de reevaluación: la decisión de hoy no es permanente.
• Los anti-patrones más comunes son elegir por benchmark, por futuro lejano, por precio de sticker, o por autoridad.
• Tu Decision Questionnaire (cápsula 08) automatizará este proceso de pesos → scoring → recomendación.

Recursos adicionales

• Decision Matrix Method — Wikipedia
• Pinecone Pricing — Referencia de costos managed
• Qdrant Cloud Pricing — Comparativa open source vs cloud
• Weaviate Pricing — Tiers y features por nivel
• Milvus Documentation — Deployment enterprise self-hosted
• Total Cost of Ownership for Cloud — Framework TCO de AWS
• Martin Fowler — Two Hard Things — Naming y cache invalidation aplican a decisiones
• Google SRE Book — Decision Making — Cómo Google toma decisiones de infraestructura

Tiempo estimado: 25-30 minutos
Siguiente: 07-casos-de-eleccion-real.md