Módulo 6: Decision Matrix para AI Engineers
Módulo 6: Decision Matrix para AI Engineers
Descripción del módulo
En el Módulo 5 desarrollaste criterio cualitativo: conoces los 5 proveedores principales, entiendes managed vs self-hosted, comparaste features para RAG, calculaste TCO y construiste un decision tree con reglas prácticas. Tienes un panorama completo del mercado. La pregunta obvia es: "¿ya puedo elegir?" Técnicamente sí — pero tu elección se sostiene sobre intuición informada, no sobre evidencia cuantificable. Y en una conversación con un Tech Lead o un CTO, "lo siento mejor así" no es un argumento defendible.
Este módulo resuelve exactamente ese gap: convertir criterio cualitativo en un proceso cuantitativo, reproducible y trazable. En lugar de decir "Pinecone me parece la mejor opción", dirás "Pinecone obtuvo 8.2/10 en mi matriz porque puntúa 9 en latencia (peso 25%), 7 en costo (peso 20%) y 9 en facilidad operativa (peso 15%), superando a Qdrant (7.8) y Weaviate (7.5) en mi escenario de startup con equipo de 3 personas y presupuesto de $200/mes". Esa es la diferencia entre opinión y decisión de ingeniería.
El entregable central del módulo es un cuestionario de decisión: un artefacto que toma como input los requisitos de un proyecto (escala, latencia, presupuesto, equipo, compliance) y produce como output una recomendación justificada con scoring numérico. No es un flowchart simple — es una herramienta que cualquier AI Engineer de tu equipo puede usar para tomar decisiones informadas sin necesidad de repetir todo el análisis desde cero.
🧠 El problema: decidir sin framework cuantitativo
Por qué el criterio cualitativo no alcanza
Después del Módulo 5, tienes una base sólida. Conoces las opciones, entiendes los trade-offs, puedes articular pros y contras de cada proveedor. Pero hay escenarios donde eso no es suficiente:
Escenario 1: Dos opciones "empatadas"
Tech Lead: "¿Qdrant o Weaviate para nuestro sistema RAG?"
Tú: "Ambas son buenas. Qdrant es más rápida,
Weaviate tiene mejor hybrid search..."
Tech Lead: "¿Pero cuál elegimos? Necesito una recomendación clara."
Tú: "..."
Sin pesos numéricos, no puedes desempatar. ¿Importa más la velocidad o hybrid search para TU proyecto? ¿Cuánto más? Sin cuantificar, la decisión se estanca.
Escenario 2: Justificar ante stakeholders no técnicos
CTO: "¿Por qué Pinecone y no la opción open-source?
Pinecone cuesta $500/mes."
Tú: "Porque nuestro equipo no puede operar infraestructura."
CTO: "¿Cuánto nos costaría operar self-hosted?
¿Ya hiciste el cálculo?"
Tú: "...no con números específicos."
Un CTO quiere ver una comparación con números. No necesita ser perfecta, pero necesita existir.
Escenario 3: Reevaluar cuando cambian los requisitos
[6 meses después]
PM: "El proyecto creció de 100K a 2M vectores.
¿Nuestra elección sigue siendo correcta?"
Tú: "Déjame revisar..."
[Repite todo el análisis desde cero]
Con una matriz documentada, solo actualizas los inputs (escala nueva, presupuesto actualizado) y recalculas. Sin ella, empiezas de cero cada vez.
El costo de decidir por feeling
En equipos de ingeniería, las decisiones no documentadas generan:
- Debate sin fin: Sin criterios compartidos, cada persona defiende su favorita
- Revisión constante: "¿Estamos seguros de que elegimos bien?" aparece cada trimestre
- Culpa sin contexto: Si algo falla, nadie recuerda por qué se eligió esa opción
- Onboarding lento: Nuevos miembros del equipo no entienden el razonamiento
- Reevaluación costosa: Cambiar de opinión sin datos es más costoso que recalcular una matriz
La habilidad que este módulo desarrolla
Lo que necesitas no es solo conocimiento de proveedores (eso ya lo tienes del Módulo 5). Necesitas un método de decisión estructurado que:
- Descomponga la decisión en criterios independientes
- Pondere cada criterio según importancia para tu contexto
- Puntúe cada opción en cada criterio con justificación
- Calcule un score compuesto que refleje tus prioridades
- Documente trade-offs y condiciones de reevaluación
- Comunique la recomendación de forma clara a cualquier audiencia
Esa es la diferencia entre un developer que "conoce herramientas" y un engineer que "toma decisiones técnicas defendibles".
🎯 Objetivo del módulo
Objetivo profesional:
Aplicar una decision matrix cuantitativa para seleccionar vector database según requisitos de proyecto, produciendo una recomendación justificada con scoring numérico, análisis de costos y documentación de trade-offs.
¿Por qué es importante para un AI Engineer?
Imagina que tu VP de Engineering te pide "recomendación formal de vector database para el sistema RAG de customer support" con requisitos concretos: 500K documentos creciendo a 2M, latencia p95 < 200ms, presupuesto máximo $800/mes, equipo de 2 sin DevOps dedicado, compliance US/EU. Quiere opciones evaluadas, criterios, scoring, recomendación principal y alternativa. Deadline: viernes.
¿Puedes responder con confianza? Después de este módulo, sí. Tendrás un proceso que convierte esos requisitos en una recomendación defendible en menos de una hora.
Al finalizar este módulo, serás capaz de:
- Definir criterios de evaluación relevantes para tu proyecto específico
- Asignar pesos justificados a cada criterio según prioridades de negocio
- Puntuar cada vector database con evidencia (no intuición)
- Calcular score ponderado y ranking final
- Analizar costos reales (TCO) y retorno de inversión por opción
- Formular recomendación principal + alternativa con condiciones de reevaluación
- Validar la decisión con escenarios reales y edge cases
- Construir cuestionario de decisión reusable para tu equipo
📚 Contenido del módulo — Roadmap detallado
Cápsula 01: Introducción al módulo (estás aquí)
| Aspecto | Detalle |
|---|---|
| Tema | Contexto, objetivos, roadmap y conexión con proyecto |
| Pregunta clave | ¿Por qué necesito un método cuantitativo si ya tengo criterio cualitativo? |
| Entregable | Claridad sobre el proceso completo del módulo |
| Tiempo | 8-10 min |
Cápsula 02: Requisitos y criterios de decisión
| Aspecto | Detalle |
|---|---|
| Tema | Cómo extraer criterios de evaluación de requisitos reales |
| Pregunta clave | ¿Qué dimensiones debo medir para tomar una decisión informada? |
| Entregable | Lista priorizada de 8-12 criterios con definición operativa |
| Tiempo | 10-12 min |
Qué aprenderás:
- Cómo convertir requisitos de negocio en criterios técnicos medibles
- Categorías de criterios: performance, operación, costo, features, ecosistema
- Diferencia entre criterios eliminatorios (must-have) y diferenciadores (nice-to-have)
- Cómo evitar criterios vagos ("buena documentación") y reemplazarlos con medibles ("docs con ejemplos en Python para cada endpoint")
Cápsula 03: Pesos y scoring de la matriz
| Aspecto | Detalle |
|---|---|
| Tema | Método para asignar pesos y puntuar opciones |
| Pregunta clave | ¿Cómo cuantifico la importancia relativa de cada criterio? |
| Entregable | Estructura de matriz con pesos justificados y rúbricas de scoring |
| Tiempo | 12-15 min |
Qué aprenderás:
- Métodos de ponderación: pairwise comparison, distribución de 100 puntos, MoSCoW cuantificado
- Escalas de scoring: 1-5 vs 1-10, cuándo usar cada una
- Rúbricas concretas: qué significa "7/10 en latencia" (definición objetiva)
- Cómo evitar sesgos comunes: anchoring, recency bias, halo effect
- Validación de consistencia: ¿los pesos reflejan tus prioridades reales?
Cápsula 04: Matriz de decisión aplicada
| Aspecto | Detalle |
|---|---|
| Tema | Construcción paso a paso de la matriz con datos reales |
| Pregunta clave | ¿Cómo se ve una matriz completa aplicada a los 5 proveedores? |
| Entregable | Matriz completa con scoring para ChromaDB, Pinecone, Weaviate, Qdrant, Milvus |
| Tiempo | 15-18 min |
Qué aprenderás:
- Aplicar criterios y pesos a cada proveedor con datos concretos
- Calcular score ponderado paso a paso
- Interpretar resultados: ¿qué significa una diferencia de 0.5 puntos?
- Sensitivity analysis: ¿cambia el ranking si ajusto un peso?
- Documentar justificación de cada puntuación individual
Cápsula 05: Análisis de costos y ROI
| Aspecto | Detalle |
|---|---|
| Tema | Framework para calcular costo total de propiedad y retorno |
| Pregunta clave | ¿Cuánto cuesta REALMENTE cada opción a 6, 12 y 24 meses? |
| Entregable | Modelo de costos comparativo con proyecciones |
| Tiempo | 12-15 min |
Qué aprenderás:
- Componentes de TCO: licencia, infra, DevOps, training, migración, oportunidad
- Modelo de proyección por crecimiento (lineal, exponencial, estacional)
- ROI de managed vs self-hosted según tamaño de equipo
- Break-even point: ¿cuándo self-hosted es más barato que managed?
- Cómo presentar análisis de costos a stakeholders financieros
Cápsula 06: Recomendación por escenarios
| Aspecto | Detalle |
|---|---|
| Tema | Aplicar la matriz a escenarios concretos con recomendación justificada |
| Pregunta clave | Dado un perfil de proyecto específico, ¿cuál es la recomendación y por qué? |
| Entregable | 4 recomendaciones documentadas para escenarios tipo |
| Tiempo | 10-12 min |
Qué aprenderás:
- Escenario startup early-stage: 1-2 devs, <100K vectores, presupuesto mínimo
- Escenario scale-up: 3-8 devs, 100K-1M vectores, SLA moderado
- Escenario enterprise: 10+ devs, 1M-50M vectores, SLA estricto, compliance
- Escenario research/academic: dataset grande, presupuesto nulo, latencia flexible
- Cómo adaptar los pesos de la matriz según cada escenario
Cápsula 07: Casos de elección real
| Aspecto | Detalle |
|---|---|
| Tema | Validación de la matriz contra decisiones reales documentadas |
| Pregunta clave | ¿Mi framework produce recomendaciones que se alinean con decisiones exitosas del mercado? |
| Entregable | Análisis de 3-4 casos reales con la matriz aplicada retrospectivamente |
| Tiempo | 10-12 min |
Qué aprenderás:
- Caso: startup que empezó con ChromaDB y migró a Pinecone (¿la matriz lo habría predicho?)
- Caso: empresa que eligió self-hosted Qdrant y ahorró 60% en costos
- Caso: equipo que eligió por hype y pagó el costo de migración
- Señales de que tu decisión necesita reevaluación (triggers de cambio)
- Cómo documentar la decisión para el "yo del futuro"
Cápsula 08: Proyecto — Cuestionario de Decisión
| Aspecto | Detalle |
|---|---|
| Tema | Construir herramienta de decisión interactiva basada en la matriz |
| Pregunta clave | ¿Puedo crear un artefacto que otro engineer pueda usar sin mi ayuda? |
| Entregable | Cuestionario funcional + documento de recomendación generado |
| Tiempo | 25-30 min |
Qué construirás:
- Cuestionario con 10-15 preguntas que capturan requisitos del proyecto
- Lógica de mapeo: respuestas → pesos → scoring automático
- Output: recomendación principal + alternativa con justificación
- Validación: probar el cuestionario con 3 escenarios y verificar coherencia
- Documentación de uso para que cualquier miembro de tu equipo lo aplique
⏱️ Tiempo estimado
Lectura + análisis: 100-130 minutos
| Cápsula | Tema | Tiempo |
|---|---|---|
| 01 | Introducción al módulo | 8-10 min |
| 02 | Requisitos y criterios de decisión | 10-12 min |
| 03 | Pesos y scoring de la matriz | 12-15 min |
| 04 | Matriz de decisión aplicada | 15-18 min |
| 05 | Análisis de costos y ROI | 12-15 min |
| 06 | Recomendación por escenarios | 10-12 min |
| 07 | Casos de elección real | 10-12 min |
| 08 | Proyecto — Cuestionario de Decisión | 25-30 min |
| Total | 100-130 min |
Nota: Este módulo es 60% análisis estructurado, 40% proyecto. No hay código de vector database que ejecutar — aquí el trabajo es pensar con método, cuantificar con rigor y documentar con claridad. El "código" es la lógica de tu cuestionario, no consultas a una base de datos.
🔗 Conexión con otros módulos
Vienes de:
Módulo 5: Landscape de Vector Databases
- Ya conoces los 5 proveedores principales y su filosofía de diseño
- Evaluaste managed vs self-hosted con criterios cualitativos
- Comparaste features para RAG y calculaste TCO aproximado
- Construiste un decision tree con reglas prácticas
- Identificaste anti-patrones de selección
Módulos 1-4: Fundamentos e implementación
- Fundamentos conceptuales: por qué (M1), cómo (M2), qué features (M3)
- Experiencia hands-on con ChromaDB (M4)
Este módulo te prepara para:
Módulo 7: Production Considerations para RAG
- Scaling, monitoring, backups, migrations con la DB elegida
- El "por qué elegí esta DB" ya estará resuelto — foco en "cómo la opero"
Módulo 8: Proyecto Integrador — RAG System con ChromaDB
- Sistema RAG completo (1,000+ docs, FastAPI, Docker) con elección justificada
- La justificación formal de "por qué ChromaDB" sale de la matriz de este módulo
Flujo completo:
Módulos 1-3: Fundamentos (POR QUÉ y CÓMO vector DBs)
↓
Módulo 4: ChromaDB hands-on (IMPLEMENTAR con una DB)
↓
Módulo 5: Landscape (COMPARAR cualitativamente)
↓
Módulo 6: Decision Matrix ← Estás aquí (CUANTIFICAR y DECIDIR)
↓
Módulo 7-8: Production + Proyecto (OPERAR y CONSTRUIR)
La transición M5 → M6
El Módulo 5 te dejó con un decision tree y criterio cualitativo ("Pinecone es bueno para equipos pequeños", "Qdrant es más rápido"). Este módulo eleva esas afirmaciones a scoring cuantificable: "Pinecone puntúa 9/10 en facilidad operativa (peso 15%)", "Qdrant obtiene 8/10 en latencia p95 (peso 25%)". La diferencia no es solo de formato — es de trazabilidad: con la matriz, cualquier persona puede revisar tus criterios, cuestionar un peso, ajustar un score y ver cómo cambia la recomendación.
🎓 ¿Qué aprenderás en este módulo?
Al finalizar este módulo, serás capaz de:
1. Definir criterios medibles
- ✅ Convertir requisitos de negocio ("necesitamos que sea rápido") en criterios técnicos ("latencia p95 < 200ms")
- ✅ Clasificar criterios en eliminatorios (must-have) vs diferenciadores (nice-to-have)
- ✅ Evitar criterios vagos que no se pueden evaluar objetivamente
- ✅ Adaptar criterios según contexto (startup vs enterprise)
2. Asignar pesos con método
- ✅ Usar pairwise comparison para establecer importancia relativa
- ✅ Validar que los pesos reflejan prioridades reales (no sesgos)
- ✅ Ajustar pesos según escenario sin invalidar el framework
- ✅ Documentar justificación de cada peso
3. Puntuar con evidencia
- ✅ Definir rúbricas concretas (qué significa "7/10" para cada criterio)
- ✅ Basar puntuaciones en datos verificables, no en impresiones
- ✅ Identificar y mitigar sesgos cognitivos en el scoring
- ✅ Manejar incertidumbre (rangos en lugar de puntuaciones exactas)
4. Calcular y analizar resultados
- ✅ Calcular score ponderado para cada opción
- ✅ Interpretar diferencias significativas vs ruido
- ✅ Realizar sensitivity analysis (¿qué pasa si cambio un peso?)
- ✅ Identificar el "margin of decision" (cuánto separa la primera de la segunda opción)
5. Comunicar decisiones
- ✅ Formular recomendación principal + alternativa
- ✅ Documentar condiciones de reevaluación (triggers de cambio)
- ✅ Presentar a audiencia técnica (engineers) y no técnica (management)
- ✅ Responder "¿por qué no elegiste X?" con datos, no con opiniones
💡 Filosofía del módulo
Framework > intuición
Lo que NO es este módulo:
❌ "Te digo cuál elegir"
❌ "Ranking definitivo de vector databases"
❌ "La respuesta correcta para todos"
❌ "Ignora tu contexto y usa esta tabla"
Lo que SÍ es:
✅ "Te doy un método para que TÚ decidas"
✅ "Framework adaptable a cualquier contexto"
✅ "Proceso que produce decisiones defendibles"
✅ "Herramienta que puedes reusar en proyectos futuros"
La diferencia es fundamental. Un ranking te dice qué hacer hoy. Un framework te enseña a decidir siempre — incluso cuando aparezca una vector database nueva que no existía cuando tomaste este curso.
Cuantificar no es inventar precisión falsa
Un error común al aplicar matrices de decisión es confundir "cuantitativo" con "exacto". Cuando dices que Pinecone puntúa 8/10 en facilidad operativa, no estás diciendo que mediste "facilidad" con un instrumento de precisión. Estás diciendo:
- Definiste qué significa "facilidad operativa" (rúbrica)
- Evaluaste Pinecone contra esa rúbrica con evidencia
- Asignaste un número que refleja tu evaluación informada
- Ese número es comparable con las puntuaciones de otras opciones
El valor no está en la precisión del número. Está en la consistencia: aplicas el mismo criterio a todas las opciones, con la misma rúbrica, y produces un resultado comparable. Eso es infinitamente más útil que "me gusta más Pinecone".
La decisión es un documento, no un momento
En ingeniería de software, las decisiones técnicas importantes se documentan como ADR (Architecture Decision Records). Tu matriz de decisión es exactamente eso: un registro de contexto, opciones evaluadas, criterios, resultado, trade-offs aceptados y condiciones de reevaluación. Cuando dentro de 6 meses alguien pregunte "¿por qué usamos Pinecone?", no necesitas recordar — solo abres el documento.
🚫 Qué NO cubre este módulo
Este módulo NO cubre:
❌ Implementación técnica de ningún proveedor
- No vas a instalar Pinecone, Weaviate, Qdrant ni Milvus
- ChromaDB ya lo usaste en Módulo 4
- El foco es evaluación y decisión, no código
❌ Benchmarks ejecutables head-to-head
- Usarás datos de benchmarks públicos y docs oficiales, no tests propios
- Aprenderás a interpretar benchmarks críticamente
❌ Decisión definitiva para tu proyecto real
- La matriz produce una recomendación, no una orden
- Este módulo te da el proceso; la validación final es con tu equipo
❌ Deployment ni operación (eso es Módulo 7)
- Scaling, monitoring, backups, migrations vienen después
❌ Landscape cualitativo (eso fue Módulo 5)
- Asumimos que conoces fortalezas y limitaciones de cada opción
- Aquí cuantificamos lo que allá describimos
Scope claro: Este módulo es sobre método de decisión cuantitativo. Convierte conocimiento cualitativo (M5) en recomendaciones formales con scoring, costos y documentación de trade-offs.
✅ Criterios de éxito
Completaste exitosamente este módulo cuando:
Puedes responder estas preguntas:
-
✅ ¿Qué criterios usarías para evaluar vector databases y por qué esos?
- Al menos 8 criterios agrupados en categorías (performance, costo, operación, features, ecosistema)
- Cada criterio con definición operativa medible
- Distinción clara entre eliminatorios y diferenciadores
-
✅ ¿Cómo asignas pesos y qué método usas?
- Pairwise comparison o distribución de puntos con justificación
- Pesos que suman 100% y reflejan prioridades del proyecto
- Validación: si latencia es tu prioridad #1, tiene el peso más alto
-
✅ Dado un escenario concreto, ¿puedes producir una recomendación con scoring?
- Matriz completa con scoring para al menos 3 opciones
- Score ponderado calculado correctamente
- Recomendación principal + alternativa con justificación
-
✅ ¿Cómo calculas el costo real (TCO) de cada opción?
- TCO = licencia + infra + DevOps + training + migración + crecimiento
- Proyección a 6 y 12 meses con escenarios de crecimiento
- Comparación managed vs self-hosted con break-even point
-
✅ ¿Puedes entregar un cuestionario de decisión que otro engineer pueda usar?
- 10-15 preguntas que capturan requisitos del proyecto
- Lógica de mapeo respuestas → recomendación
- Validado con al menos 3 escenarios diferentes
Si respondiste 4-5/5 correctamente Y entregaste cuestionario funcional → ✅ Módulo completado
🧩 Mini checklist de preparación
Antes de iniciar este módulo, asegúrate de tener claros estos puntos del Módulo 5:
- ¿Puedo describir las 5 vector databases principales y sus diferencias clave?
- ¿Entiendo la diferencia entre managed y self-hosted con sus trade-offs?
- ¿Conozco las features relevantes para RAG (filtering, hybrid search, multi-tenancy)?
- ¿Tengo una noción de costos (aunque sea aproximada) de cada opción?
- ¿Identifiqué anti-patrones de selección que debo evitar?
Si respondiste "no" a 2 o más, revisa las cápsulas correspondientes del Módulo 5 antes de continuar.
Además, piensa en un proyecto real (o hipotético) mientras avanzas:
- ¿Cuántos vectores necesita tu proyecto? (orden de magnitud)
- ¿Cuál es tu requisito de latencia? (< 100ms, < 200ms, < 500ms)
- ¿Cuántas personas hay en tu equipo técnico?
- ¿Tienes presupuesto mensual definido para infraestructura?
- ¿Hay restricciones de compliance o residencia de datos?
Tener un caso concreto en mente hace que cada cápsula sea inmediatamente aplicable en lugar de abstracta.
📖 Cómo usar este módulo
Estrategia recomendada:
-
Lee secuencialmente (Cápsulas 01 → 02 → ... → 08)
- Cada cápsula construye sobre la anterior
- Los criterios (C02) alimentan los pesos (C03), que alimentan la matriz (C04)
- No saltes a Cápsula 04 (matriz aplicada) sin haber definido criterios y pesos
-
Trabaja con un proyecto real en mente
- Cada cápsula invita a aplicar el concepto a TU caso
- "¿Qué criterios importan para MI proyecto?" es la pregunta constante
- Si no tienes proyecto real, usa los escenarios de Cápsula 06
-
Construye tu matriz progresivamente
- Abre un spreadsheet (Google Sheets, Excel, Notion) desde Cápsula 02
- Agrega criterios en C02, pesos en C03, scores en C04, costos en C05
- Al llegar a C08, tu cuestionario ya tiene la lógica construida
-
Cuestiona tus propios números
- La matriz es tan buena como tus inputs
- Si un score "se siente mal", revisa la rúbrica y la evidencia
- Sensitivity analysis (C04) te ayuda a ver qué tanto importan las imprecisiones
Tiempo sugerido:
Opción A: Dos sesiones (recomendado)
- Sesión 1: Cápsulas 01-04 (criterios, pesos, matriz aplicada) = 45-55 min
- Sesión 2: Cápsulas 05-08 (costos, escenarios, casos reales, proyecto) = 55-75 min
Opción B: Una sesión intensa
- Todo de corrido = 100-130 min
- Ventaja: contexto fresco; desventaja: fatiga analítica
Recomendación: Opción A. La primera sesión construye el framework, la segunda lo aplica. El break te permite reflexionar sobre tus propios pesos y criterios antes de usarlos.
🎯 Conexión con el proyecto: Cuestionario de Decisión
El proyecto de este módulo convierte toda la teoría en una herramienta concreta: un cuestionario que toma requisitos de proyecto como input y produce una recomendación justificada como output.
¿Qué es un cuestionario de decisión?
Es un documento estructurado (o spreadsheet interactivo) que toma 10-15 preguntas sobre tu proyecto (escala de vectores, capacidad DevOps, presupuesto, latencia requerida, compliance) y produce una recomendación con scoring:
INPUT: 10-15 preguntas → escala, equipo, presupuesto, SLA
OUTPUT: Recomendación principal: Pinecone (score: 8.2/10)
- Latencia: 9/10, Costo: 7/10, Operación: 9/10
Alternativa: Weaviate Cloud (score: 7.5/10)
Trigger de reevaluación: vectores > 2M o
presupuesto < $200/mes
La diferencia con la matriz pura: la matriz es la herramienta analítica (requiere entender pesos y criterios), el cuestionario es la interfaz de usuario (cualquier engineer responde preguntas y obtiene una recomendación en lenguaje claro).
Cómo se construye a lo largo del módulo
Cada cápsula aporta una pieza al cuestionario:
| Cápsula | Aporte al Cuestionario |
|---|---|
| 02 - Criterios | Las preguntas del cuestionario (qué preguntar) |
| 03 - Pesos | La lógica de ponderación (cómo mapear respuestas a pesos) |
| 04 - Matriz | El motor de scoring (cómo calcular recomendación) |
| 05 - Costos | Preguntas de presupuesto y modelo de proyección |
| 06 - Escenarios | Validación del cuestionario con perfiles tipo |
| 07 - Casos reales | Calibración: ¿el cuestionario produce resultados sensatos? |
| 08 - Proyecto | Ensamblaje final + documentación + pruebas |
No llegas a Cápsula 08 vacío. Llegas con todas las piezas: preguntas definidas, lógica construida, validación hecha. Solo falta ensamblar y pulir.
Resumen
- Módulo 6 convierte el criterio cualitativo del Módulo 5 en un proceso cuantitativo de decisión
- Aprenderás a definir criterios medibles, asignar pesos justificados y puntuar opciones con evidencia
- La decision matrix no busca precisión perfecta sino consistencia y trazabilidad
- Incluye análisis de costos reales (TCO) y proyecciones a 6-12 meses
- Validarás tu framework con escenarios tipo (startup, scale-up, enterprise) y casos reales
- El proyecto final es un cuestionario de decisión reusable que cualquier engineer puede aplicar
- La habilidad central — tomar decisiones técnicas defendibles con método — es transferible a cualquier evaluación tecnológica
- Es el puente entre conocimiento del mercado (M5) y operación en producción (M7)
🔗 Recursos adicionales
Frameworks de decisión:
- Pugh Matrix (Decision Matrix) — Método formal de matriz de decisión ponderada
- Architecture Decision Records (ADR) — Estándar para documentar decisiones técnicas
- Weighted Scoring Model - PMI — Modelo de scoring ponderado en project management
Documentación de proveedores (para scoring):
- ChromaDB Documentation — Features, limitaciones, roadmap
- Pinecone Documentation — Pricing, SLA, arquitectura managed
- Weaviate Documentation — Hybrid search, módulos, deployment
- Qdrant Documentation — Performance benchmarks, API, self-hosted
- Milvus Documentation — Arquitectura distribuida, cloud-native features
Comparaciones y benchmarks:
- DB-Engines Vector DBMS Ranking — Popularidad y adopción (no calidad)
- VectorDB Comparison by Superlinked — Comparativa comunitaria mantenida
Nota: Los docs de proveedores son útiles para verificar puntuaciones, no para decidir quién "gana". Tu matriz es la fuente de verdad para TU decisión.
🚀 ¿Listo para empezar?
Próximo paso:
Ve a Cápsula 02: Requisitos y criterios de decisión
Ahí aprenderás:
- Cómo extraer criterios de evaluación a partir de requisitos reales de proyecto
- Categorías de criterios (performance, costo, operación, features, ecosistema)
- Diferencia entre criterios eliminatorios y diferenciadores
- Cómo definir cada criterio de forma medible y no ambigua
Esta cápsula es la base de todo el módulo. Sin criterios bien definidos, los pesos y el scoring no tienen fundamento.
Tiempo de lectura: 8-10 minutos
Siguiente: 02-requisitos-criterios-decision.md