Cápsula 07: Casos de Elección Real

Descripción de la cápsula

En la cápsula anterior aplicaste la matriz a escenarios tipo. Ahora vas a ver cómo funciona en casos completos con personajes, restricciones cambiantes y decisiones que no son obvias. La diferencia: aquí no hay "respuesta correcta desde el principio". Cada caso incluye momentos de incertidumbre, datos incompletos y presión del negocio — exactamente como pasa en la realidad.

El objetivo es que practiques el proceso completo de decisión: desde el levantamiento de requisitos hasta la justificación documentada, pasando por los momentos incómodos donde la matriz te dice una cosa y tu intuición te dice otra. Al final de esta cápsula, habrás visto el framework sobrevivir cuatro escenarios con restricciones reales y sabrás aplicarlo a tu propio proyecto.

Estos casos están diseñados para conectarse directamente con tu Decision Questionnaire (cápsula 08). Cada decisión que verás aquí podría haber sido guiada por el cuestionario que construirás.

Estructura de cada caso

Cada caso sigue este flujo:

┌─────────────────────────────────────────┐
│  1. CONTEXTO                            │
│     Quién, qué, cuándo, con qué         │
├─────────────────────────────────────────┤
│  2. REQUISITOS INICIALES                │
│     Lo que el equipo cree que necesita   │
├─────────────────────────────────────────┤
│  3. REQUISITOS REALES                   │
│     Lo que descubren al profundizar      │
├─────────────────────────────────────────┤
│  4. MATRIZ APLICADA                     │
│     Pesos, scores, ranking              │
├─────────────────────────────────────────┤
│  5. COMPLICACIÓN                        │
│     Algo cambia o sale mal              │
├─────────────────────────────────────────┤
│  6. DECISIÓN FINAL                      │
│     Con justificación documentada       │
├─────────────────────────────────────────┤
│  7. RESULTADO A 6 MESES                 │
│     ¿Qué pasó después?                 │
└─────────────────────────────────────────┘

Caso A: Startup HealthTech — RAG para documentación médica

1. Contexto

Empresa: MediSearch, startup de 8 personas (5 devs, 1 PM, 1 diseñador, 1 fundador).

Producto: Buscador inteligente de literatura médica para médicos generales. Los doctores hacen preguntas en lenguaje natural y reciben respuestas con citas de papers y guías clínicas.

Estado actual: Prototipo funcional con OpenAI embeddings + búsqueda brute force en NumPy. Funciona con 15K documentos pero el inversor quiere demo con 500K+ para la siguiente ronda.

Timeline: 10 semanas para la demo al inversor.

2. Requisitos iniciales (lo que dice el equipo)

from dataclasses import dataclass


@dataclass
class MediSearchRequirements:
    vectors_now: int = 15_000
    vectors_demo: int = 500_000
    vectors_12m: int = 2_000_000
    latency_target_ms: int = 200
    budget_monthly: int = 400
    team_devs: int = 5
    has_devops: bool = False
    timeline_weeks: int = 10
    compliance: str = "ninguno por ahora"


initial_reqs = MediSearchRequirements()

3. Requisitos reales (lo que descubren)

En la semana 2, el equipo legal del inversor pregunta: "¿Los datos médicos están cifrados en tránsito y en reposo?"

Resulta que los papers no son datos de pacientes, pero las queries de los médicos sí pueden contener información sensible (síntomas de pacientes específicos). Esto cambia todo:

@dataclass
class MediSearchRealRequirements(MediSearchRequirements):
    query_data_sensitive: bool = True
    encryption_at_rest: bool = True
    encryption_in_transit: bool = True
    data_residency: str = "LATAM o US"
    audit_queries: bool = True


real_reqs = MediSearchRealRequirements()

4. Matriz aplicada

weights = {
    "setup_speed": 4,       # demo en 10 semanas
    "scale": 4,             # 500K para demo, 2M en 12 meses
    "latency": 4,           # <200ms para UX fluida
    "encryption": 5,        # queries con datos sensibles
    "data_residency": 3,    # preferible LATAM/US
    "ops_simplicity": 5,    # sin DevOps
    "cost_control": 3,      # presupuesto limitado pero flexible
}

providers = {
    "Pinecone": {
        "setup_speed": 0.9, "scale": 0.9, "latency": 0.9,
        "encryption": 0.9, "data_residency": 0.7,
        "ops_simplicity": 1.0, "cost_control": 0.6,
    },
    "Qdrant_Cloud": {
        "setup_speed": 0.8, "scale": 0.85, "latency": 0.85,
        "encryption": 0.8, "data_residency": 0.8,
        "ops_simplicity": 0.8, "cost_control": 0.8,
    },
    "Weaviate_Cloud": {
        "setup_speed": 0.75, "scale": 0.8, "latency": 0.8,
        "encryption": 0.85, "data_residency": 0.75,
        "ops_simplicity": 0.85, "cost_control": 0.7,
    },
    "ChromaDB_local": {
        "setup_speed": 1.0, "scale": 0.4, "latency": 0.7,
        "encryption": 0.3, "data_residency": 1.0,
        "ops_simplicity": 0.7, "cost_control": 1.0,
    },
}


def score_provider(weights: dict, scores: dict) -> float:
    total = sum(weights[k] * scores.get(k, 0) for k in weights)
    max_total = sum(weights.values())
    return round((total / max_total) * 100, 1)


results = {name: score_provider(weights, scores)
           for name, scores in providers.items()}
# Pinecone: 86.1, Qdrant Cloud: 81.4, Weaviate Cloud: 79.3, ChromaDB: 66.8

5. Complicación

Semana 4: el CTO descubre que Pinecone Standard no incluye logs de queries para audit trail. El equipo legal del inversor quiere poder demostrar que pueden auditar qué queries se hicieron. Opciones:

• A: Subir a Pinecone Enterprise (fuera de presupuesto: ~$1500/mes)
• B: Implementar audit logging en la capa de aplicación (3-5 días de desarrollo)
• C: Cambiar a Qdrant Cloud que permite más control de logging

6. Decisión final

El equipo elige Pinecone Standard + audit logging en aplicación (opción B):

decision_doc = {
    "provider": "Pinecone Standard",
    "justification": (
        "Score más alto (86.1). El gap de audit se resuelve con middleware "
        "de logging en la app (3 días de dev, no bloquea la demo)."
    ),
    "alternative": "Qdrant Cloud (81.4) — si Pinecone sube precios post-demo",
    "risks": [
        "Vendor lock-in: migración costará ~2 semanas si cambiamos",
        "Costo escala: $400/mes hoy → $800-1200/mes a 2M vectores",
        "Audit en app-layer: más frágil que audit nativo",
    ],
    "mitigations": [
        "Abstracción con interfaz genérica para el vector store",
        "Revisión de costos mensual con alerta a $600/mes",
        "Tests de integración para el middleware de audit",
    ],
    "reevaluation": "Post-demo (semana 12) o si costo > $600/mes",
}

7. Resultado a 6 meses

• Demo exitosa, levantaron ronda seed.
• Pinecone funciona bien a 800K vectores, costo $280/mes.
• El audit middleware tuvo 1 bug (queries no logueadas en timeout) que arreglaron en sprint 8.
• Planean evaluar Qdrant Cloud en Q3 cuando pasen a 2M vectores y el costo suba.

Lección: La matriz acertó. La complicación del audit se resolvió con ingeniería, no con cambio de proveedor. La clave fue tener la alternativa documentada.

Caso B: FinTech regulada — Embeddings de transacciones

1. Contexto

Empresa: PayGuard, fintech con 40 empleados, 12 en engineering.

Producto: Sistema de detección de fraude que usa embeddings de patrones de transacciones para encontrar anomalías similares a fraudes conocidos.

Estado actual: Sistema legacy con Elasticsearch + cosine similarity. Funciona pero con latencia de 2-3 segundos por query. El equipo de ML quiere vector DB nativa.

Timeline: 16 semanas (migración gradual, no big bang).

2. Requisitos iniciales

@dataclass
class PayGuardRequirements:
    vectors_now: int = 8_000_000
    vectors_12m: int = 30_000_000
    latency_target_ms: int = 50    # detección de fraude es time-critical
    budget_monthly: int = 5_000
    team_devs: int = 12
    has_devops: bool = True         # equipo de plataforma de 3
    has_sre: bool = True
    timeline_weeks: int = 16
    compliance: str = "PCI-DSS, SOC2"
    data_residency: str = "US obligatorio"
    multi_region: bool = True       # DR obligatorio

3. Requisitos reales

El equipo de compliance agrega restricciones en la semana 3:

@dataclass
class PayGuardRealRequirements(PayGuardRequirements):
    encryption_at_rest: str = "AES-256 con key management propio"
    network_isolation: bool = True   # VPC peering o private link
    audit_immutable: bool = True     # logs no modificables
    pen_test_required: bool = True   # vendor debe permitir pen testing
    data_deletion_sla: str = "72 horas máximo"
    vendor_soc2_type2: bool = True   # certificación del proveedor

4. Matriz aplicada

weights = {
    "latency": 5,           # <50ms es crítico para fraude
    "scale": 5,             # 30M vectores
    "compliance_pci": 5,    # no negociable
    "network_isolation": 5, # no negociable
    "multi_region": 4,      # DR obligatorio
    "encryption_custom": 4, # key management propio
    "ops_simplicity": 3,    # tienen equipo
    "cost_control": 3,      # presupuesto razonable
}

providers = {
    "Qdrant_self_hosted": {
        "latency": 0.9, "scale": 0.85, "compliance_pci": 0.9,
        "network_isolation": 1.0, "multi_region": 0.7,
        "encryption_custom": 0.9, "ops_simplicity": 0.5,
        "cost_control": 0.85,
    },
    "Pinecone_enterprise": {
        "latency": 0.85, "scale": 0.9, "compliance_pci": 0.7,
        "network_isolation": 0.7, "multi_region": 0.85,
        "encryption_custom": 0.5, "ops_simplicity": 1.0,
        "cost_control": 0.5,
    },
    "Milvus_self_hosted": {
        "latency": 0.85, "scale": 0.95, "compliance_pci": 0.85,
        "network_isolation": 1.0, "multi_region": 0.8,
        "encryption_custom": 0.85, "ops_simplicity": 0.4,
        "cost_control": 0.8,
    },
    "Weaviate_self_hosted": {
        "latency": 0.8, "scale": 0.8, "compliance_pci": 0.85,
        "network_isolation": 1.0, "multi_region": 0.7,
        "encryption_custom": 0.8, "ops_simplicity": 0.55,
        "cost_control": 0.8,
    },
}

results = {name: score_provider(weights, scores)
           for name, scores in providers.items()}

5. Complicación

Semana 6: el equipo de plataforma hace un PoC con Qdrant self-hosted en Kubernetes. Descubren que:

• Qdrant funciona excelente en single-node (42ms p95 con 1M vectores de prueba)
• Multi-region replication requiere configuración manual y no está tan maduro como esperaban
• El equipo de 3 en plataforma ya está al 90% de capacidad con otros servicios

El CTO presenta dos caminos:

Camino A: Qdrant self-hosted
  ✓ Compliance perfecto
  ✓ Latencia excelente
  ✗ Multi-region complejo → necesitan contratar 1 SRE más ($12K/mes)
  ✗ Timeline se extiende 4-6 semanas

Camino B: Milvus self-hosted
  ✓ Multi-region más maduro (Milvus distributed)
  ✓ Scale a 30M probado en producción por otros
  ✗ Ops más complejo (Pulsar/Kafka dependency)
  ✗ Latencia ligeramente mayor (55ms p95 en PoC)

6. Decisión final

El equipo elige Qdrant self-hosted + contratación de SRE:

decision_doc = {
    "provider": "Qdrant Self-hosted (Kubernetes)",
    "justification": (
        "Score más alto (83.5). Latencia de 42ms cumple el SLA de 50ms con "
        "margen. Multi-region se resuelve con replicación a nivel de app + "
        "Qdrant snapshots entre regiones. El costo de 1 SRE adicional ($12K/mes) "
        "se justifica contra el overhead operativo de Milvus con Pulsar."
    ),
    "alternative": "Milvus Self-hosted — si multi-region de Qdrant no escala",
    "migration_plan": [
        "Semanas 1-4: Deploy Qdrant en staging, migrar pipeline de embeddings",
        "Semanas 5-8: Migrar 20% del tráfico (transacciones no críticas)",
        "Semanas 9-12: Migrar 80% del tráfico con fallback a Elasticsearch",
        "Semanas 13-16: 100% migrado, decomission Elasticsearch vector search",
    ],
    "risks": [
        "Multi-region snapshot lag: max 30 min de delay aceptable para DR",
        "Contratar SRE toma 4-8 semanas: team lead cubre interim",
        "Qdrant version upgrades: test en staging antes de producción",
    ],
    "reevaluation": "Trimestral, o si latencia p95 supera 45ms en producción",
}

7. Resultado a 6 meses

• Qdrant en producción con 12M vectores, p95 de 38ms.
• Multi-region con snapshots cada 15 minutos (aceptable para DR).
• SRE contratado en semana 10, ya operando el cluster.
• Costo total: $2,800/mes (infra) + $12K/mes (SRE) = $14,800/mes.
• Comparación: Pinecone Enterprise habría costado ~$8K/mes pero no pasaba compliance.

Lección: A veces la opción "más cara en headcount" es la única viable cuando compliance es no negociable. El costo de NO cumplir PCI-DSS es existencial para una fintech.

Caso C: E-commerce — Recomendaciones de producto a escala

1. Contexto

Empresa: StyleFind, e-commerce de moda con 200 empleados, 35 en tech.

Producto: Sistema de recomendaciones "Find Similar" donde los usuarios suben fotos o describen prendas y el sistema encuentra productos similares en el catálogo.

Estado actual: Modelo de recomendaciones basado en collaborative filtering. Quieren agregar visual similarity con embeddings de imágenes (CLIP).

Timeline: 20 semanas (lanzamiento para Black Friday).

2. Requisitos

• Vectores: 0 hoy → 2M al lanzamiento → 5M en 12 meses
• Latencia: p95 < 100ms (UX e-commerce exigente)
• Budget: $2,000/mes
• Equipo: 35 devs con DevOps + 4 ML engineers
• Timeline: 20 semanas (lanzamiento Black Friday)
• Pico: Black Friday 20x tráfico normal (50 → 1,000 qps)
• Embeddings: CLIP 512D (texto + imagen)

3. Requisitos reales — el factor Black Friday

El equipo de infra levanta una restricción que nadie había mencionado:

Tráfico normal:     50 queries/segundo
Black Friday:       1,000 queries/segundo (20x)
Cyber Monday:       800 queries/segundo (16x)
Resto del año:      50-100 queries/segundo

Esto cambia los pesos dramáticamente. La base de datos necesita auto-scaling agresivo o capacidad provisionada para picos:

weights = {
    "scale": 5,             # 5M vectores
    "latency_at_peak": 5,   # <100ms incluso a 1000 qps
    "auto_scaling": 5,      # 20x picos no negociable
    "multimodal_support": 4, # CLIP embeddings
    "ops_simplicity": 4,    # equipo grande pero no quieren dedicar ML engineers a ops
    "cost_efficiency": 4,   # pagar por picos constantes es desperdicio
    "setup_speed": 3,       # 20 semanas es razonable
    "compliance": 1,        # no aplica
}

4. Matriz aplicada

providers = {
    "Pinecone_standard": {
        "scale": 0.9, "latency_at_peak": 0.85, "auto_scaling": 0.9,
        "multimodal_support": 0.8, "ops_simplicity": 1.0,
        "cost_efficiency": 0.5, "setup_speed": 0.9, "compliance": 0.5,
    },
    "Qdrant_cloud": {
        "scale": 0.85, "latency_at_peak": 0.85, "auto_scaling": 0.7,
        "multimodal_support": 0.85, "ops_simplicity": 0.8,
        "cost_efficiency": 0.8, "setup_speed": 0.8, "compliance": 0.5,
    },
    "Weaviate_cloud": {
        "scale": 0.8, "latency_at_peak": 0.8, "auto_scaling": 0.75,
        "multimodal_support": 0.9, "ops_simplicity": 0.85,
        "cost_efficiency": 0.7, "setup_speed": 0.75, "compliance": 0.5,
    },
    "Milvus_on_k8s": {
        "scale": 0.95, "latency_at_peak": 0.9, "auto_scaling": 0.85,
        "multimodal_support": 0.8, "ops_simplicity": 0.4,
        "cost_efficiency": 0.85, "setup_speed": 0.5, "compliance": 0.5,
    },
}

results = {name: score_provider(weights, scores)
           for name, scores in providers.items()}

5. Complicación — El costo de los picos

El equipo de finanzas hace las cuentas:

Pinecone es el más caro anualizado, pero Milvus requiere expertise de K8s que el ML team no tiene. El equipo debate si contratar infraestructura o pagar el premium.

6. Decisión final

Arquitectura híbrida: Qdrant Cloud + pre-warming para picos

Provider: Qdrant Cloud — Score 80.0, cercano al top. El factor decisivo es TCO anual: $4,880 vs $8,150 de Pinecone (-40%).

Arquitectura para picos:

• Normal: Qdrant Cloud tier estándar, 2M vectores
• Pre-peak: Scale up manual 48h antes de Black Friday / Cyber Monday
• Peak: Capacidad provisionada 3x para absorber 1000 qps
• Post-peak: Scale down 72h después del evento

Alternativa: Pinecone Standard — si pre-warming resulta operativamente costoso.

Riesgos: Pre-warming manual requiere calendario de eventos; picos no planificados causan latencia hasta escalar.

Reevaluación: Post-Black Friday: ¿pre-warming funcionó? ¿Cuántos picos no planeados hubo?

7. Resultado a 6 meses

• Black Friday: pre-warming funcionó. p95 de 85ms a 950 qps. Un spike a 1,100 qps causó 120ms p95 durante 3 minutos.
• Costo real anual: $5,200 (ligeramente sobre estimado por storage creciente).
• El ML team no tuvo que aprender K8s, siguieron enfocados en mejorar embeddings CLIP.
• Decidieron mantener Qdrant Cloud y mejorar el proceso de pre-warming con alertas automáticas.

Lección: La opción con score más alto no siempre es la mejor cuando el TCO anual y las habilidades del equipo pesan. Una solución "80% automática + 20% manual" puede ser más pragmática que una "100% automática y 2x más cara".

Caso D: Consultora AI — Múltiples clientes, múltiples necesidades

1. Contexto

Empresa: DataPulse, consultora de AI con 15 personas.

Situación especial: No construyen un solo producto. Tienen 6-8 clientes simultáneos, cada uno con necesidades diferentes. Necesitan una estrategia de vector DB que funcione across projects.

2. El problema único de las consultoras

No pueden usar un proveedor diferente para cada cliente — el equipo no tiene ancho de banda para dominar 4 tecnologías diferentes.

3. Matriz adaptada — criterio de "versatilidad"

weights_consultora = {
    "versatility": 5,       # debe servir para clientes diversos
    "learning_curve": 5,    # equipo debe ser productivo rápido en cualquier proyecto
    "managed_and_self": 4,  # poder ofrecer ambos modelos
    "scale_range": 4,       # 50K a 3M sin cambiar de tech
    "cost_predictability": 4,  # poder cotizar a clientes con confianza
    "documentation": 4,     # equipo rota entre proyectos
    "community": 3,         # soporte cuando el equipo está ocupado
}

providers = {
    "Qdrant": {
        "versatility": 0.9, "learning_curve": 0.8,
        "managed_and_self": 1.0, "scale_range": 0.85,
        "cost_predictability": 0.8, "documentation": 0.75,
        "community": 0.8,
    },
    "Weaviate": {
        "versatility": 0.85, "learning_curve": 0.75,
        "managed_and_self": 1.0, "scale_range": 0.8,
        "cost_predictability": 0.75, "documentation": 0.8,
        "community": 0.75,
    },
    "Pinecone": {
        "versatility": 0.7, "learning_curve": 0.9,
        "managed_and_self": 0.3, "scale_range": 0.9,
        "cost_predictability": 0.6, "documentation": 0.9,
        "community": 0.7,
    },
    "ChromaDB": {
        "versatility": 0.6, "learning_curve": 1.0,
        "managed_and_self": 0.4, "scale_range": 0.5,
        "cost_predictability": 0.9, "documentation": 0.8,
        "community": 0.7,
    },
}

results = {name: score_provider(weights_consultora, scores)
           for name, scores in providers.items()}

4. Complicación — Cliente B necesita self-hosted

El Cliente B (fintech, 3M vectores, compliance) firma contrato. Necesitan self-hosted y el equipo nunca ha operado Qdrant en producción. Tres opciones:

• A: Aprender Qdrant self-hosted (2-3 semanas de ramp-up) — consistente pero retrasa
• B: Usar Weaviate self-hosted (experiencia previa) — rápido pero rompe estandarización
• C: Subcontratar DevOps para deployment de Qdrant ($5K one-time) — mantiene estándar sin retraso

5. Decisión final

Opción C: Subcontratar DevOps para el primer deployment de Qdrant self-hosted, con knowledge transfer al equipo interno.

Estrategia: Estandarización en Qdrant (cloud + self-hosted).

Inversión: DevOps contractor $5K one-time + 2 workshops internos de 4h + runbook de deployment.

Reevaluación: Cada 6 meses, o cuando un cliente requiera features que Qdrant no soporte.

6. Resultado a 6 meses

• 4 clientes operando en Qdrant (2 cloud, 1 self-hosted, 1 cloud migrado de ChromaDB).
• El equipo se volvió experto en Qdrant: deployment, tuning, monitoring.
• La estandarización redujo onboarding de nuevos devs de 2 semanas a 3 días.
• Un cliente nuevo pidió hybrid search → evaluaron brevemente Weaviate pero lo resolvieron con Qdrant sparse vectors.

Lección: Para consultoras, la variable dominante es versatilidad + learning curve del equipo. La consistencia tecnológica across projects ahorra más dinero que optimizar cada proyecto individualmente.

Patrones comunes entre los cuatro casos

1. Compliance trumps all: Cuando compliance es requisito, elimina managed-only options inmediatamente (Caso B). No pierdas tiempo evaluando lo que no puedes usar.

2. TCO beats sticker price: En los 4 casos, el proveedor "más barato" en precio directo nunca fue el más barato en TCO. Siempre suma horas de operación y riesgo.

3. Complications test the decision: Toda decisión va a enfrentar una complicación. El framework no la previene pero te da herramientas para responder racionalmente (re-puntuar, no tirar todo).

4. Alternative documented saves you: Tener alternativa documentada con score da confianza al equipo: "si X falla, tenemos Y listo con gap de solo N puntos".

Troubleshooting

"Mi caso real no se parece a ninguno de estos cuatro"

No necesita parecerse exactamente. Extrae los pesos del caso más cercano y ajusta los 2-3 criterios que sean diferentes. La estructura del framework es la misma: define restricciones → puntúa → elige → documenta → reevalúa.

"Hice la matriz pero mi jefe no acepta el resultado"

El problema no es la matriz, es que tu jefe tiene criterios implícitos que no están en la matriz. Pregúntale: "¿Qué criterio agregarías y con qué peso?" Si dice "confianza en la marca", agrégalo con peso 3 y recalcula. Si el resultado cambia, esa era la restricción real.

"No tengo benchmark para puntuar proveedores"

Usa tres fuentes: (1) documentación oficial del proveedor, (2) benchmarks públicos (ANN Benchmarks, blogs técnicos), (3) un PoC de 2-3 días con datos representativos. No necesitas perfección: necesitas puntuaciones razonables que puedas defender y revisar después.

"La complicación que surgió invalida toda la decisión"

Rara vez la invalida toda. Re-puntúa solo los criterios afectados y recalcula. Si el ranking no cambia, la decisión se mantiene. Si cambia, tienes la alternativa documentada para activar sin pánico.

"El equipo quiere cambiar de proveedor cada 3 meses"

Establece un costo de cambio explícito en la matriz (migration_cost como criterio con peso). Cuando alguien proponga cambiar, el costo de migración entra al cálculo y típicamente ancla la decisión actual a menos que el beneficio sea muy claro.

Ejercicios

Ejercicio 1: Analiza un caso y cuestiona la decisión

Toma el Caso A (MediSearch) y argumenta POR QUÉ la decisión debería haber sido diferente. Usa la matriz pero con pesos que reflejen una prioridad diferente.

weights_alternative = {
    "setup_speed": 2,       # baja prioridad (ya no es urgente post-demo)
    "scale": 5,             # 2M vectores es el objetivo real
    "latency": 4,
    "encryption": 5,
    "data_residency": 4,    # sube: LATAM importa para mercado target
    "ops_simplicity": 3,    # baja: equipo puede aprender
    "cost_control": 5,      # sube: startup con runway limitado
}

# Con estos pesos, Qdrant Cloud sube al #1 porque:
# - Mejor costo a 2M vectores ($180/mes vs $800+ Pinecone)
# - Open source = menor vendor lock-in
# - Data residency en más regiones

# Contra-argumento: en semana 10 con demo al inversor,
# llegar 2 semanas tarde por aprender Qdrant podría costar
# la ronda de inversión. El costo de Pinecone ($400/mes)
# es insignificante comparado con perder $500K de funding.

Ejercicio 2: Construye tu propio caso

Escribe un caso completo siguiendo la estructura de 7 pasos. Usa tu empresa/proyecto actual o inventa uno realista.

mi_caso = {
    "contexto": {
        "empresa": "___",
        "producto": "___",
        "estado_actual": "___",
        "timeline": "___",
    },
    "requisitos_iniciales": {
        "vectors": "___",
        "latency": "___",
        "budget": "___",
        "team": "___",
    },
    "requisitos_reales": "¿Qué descubriste que no sabías al inicio?",
    "matriz": {
        "weights": {},
        "providers": {},
        "scores": {},
    },
    "complicacion": "¿Qué pasó que no esperabas?",
    "decision": {
        "primary": "___",
        "justification": "___",
        "alternative": "___",
        "risks": [],
    },
    "resultado_6m": "¿Cómo proyectas que saldrá?",
}

Ejercicio 3: Scoring cruzado

Toma los 4 proveedores del Caso C (StyleFind) y puntúalos usando los pesos del Caso B (PayGuard). ¿Cambia el ranking? ¿Por qué?

# Pesos de PayGuard aplicados a proveedores de StyleFind
weights_payguard = {
    "latency": 5, "scale": 5, "compliance_pci": 5,
    "network_isolation": 5, "multi_region": 4,
    "encryption_custom": 4, "ops_simplicity": 3, "cost_control": 3,
}

# Proveedores de StyleFind NO tienen scores para compliance_pci,
# network_isolation, etc. Esto demuestra que:
# 1. Los proveedores managed (Pinecone, Qdrant Cloud) obtienen
#    scores muy bajos en compliance y network isolation
# 2. El ranking se invierte completamente
# 3. Solo las opciones self-hosted sobreviven

# Lección: los pesos cambian TODO. No existe un "mejor proveedor"
# absoluto. Existe el mejor proveedor PARA TU CONTEXTO.

Ejercicio 4: Mapa de complicaciones

Para cada caso (A-D), identifica una complicación adicional que podría haber ocurrido y cómo habría afectado la decisión.

Ejercicio 5: Decision Questionnaire connection

Conexión con proyecto: Toma los 4 casos y extrae las 5 preguntas más importantes que un cuestionario automatizado debería hacer para clasificar cualquier caso nuevo en uno de los 4 escenarios.

Ejercicio 6: Post-mortem de decisión

Elige uno de los 4 casos y escribe un post-mortem a 12 meses: ¿Qué cambió? ¿La decisión se mantiene? ¿Qué harías diferente?

Resumen

• Cada caso real tiene complicaciones que la matriz sola no predice, pero el framework te da estructura para responder sin pánico.
• La alternativa documentada es tan importante como la elección principal: te da un plan B con datos, no con intuición.
• Compliance no negociable elimina opciones antes del scoring — no pierdas tiempo evaluando lo inviable.
• TCO real (servicio + ops + riesgo) siempre supera al "sticker price" como criterio de decisión.
• Para consultoras y equipos multi-proyecto, la consistencia tecnológica (una sola stack) suele ganar sobre la optimización individual.
• Los trigger de reevaluación convierten una decisión estática en un proceso vivo que se adapta.
• Tu Decision Questionnaire (cápsula 08) automatizará la clasificación que hiciste manualmente en estos 4 casos.
• La mejor decisión no es la que acierta siempre, sino la que puedes justificar, defender y cambiar con datos cuando el contexto evoluciona.

Recursos adicionales

• Google SRE Book — Decision Making — Framework de decisiones de infra en Google
• Pinecone Architecture Blog — Detalles técnicos de cómo funciona internamente
• Qdrant Documentation — Guías de deployment self-hosted y cloud
• Weaviate Architecture — Conceptos de arquitectura y deployment
• Milvus Distributed Guide — Deployment distribuido y tuning
• AWS Well-Architected Framework — Principios de decisión de arquitectura
• ANN Benchmarks — Benchmarks objetivos de algoritmos de búsqueda
• ThoughtWorks Technology Radar — Evaluación de tecnologías con contexto de adopción

Tiempo estimado: 30-35 minutos
Siguiente: 08-proyecto-cuestionario-decision.md