{
  "title": "Un MVP de hazañas de fuerza para aplicaciones de IA",
  "excerpt": "Explorando el concepto de Producto Mínimo Viable (MVP) en aplicaciones de IA, centrándose en ofrecer valor mediante la comprensión y atención efectiva de las necesidades del usuario.",
  "content_html": "<p>Un producto mínimo viable (MVP, por sus siglas en inglés) es una versión de un producto con justo las características suficientes para que sea usable por los primeros clientes, quienes pueden entonces proporcionar retroalimentación para el desarrollo futuro del producto.</p>\n<p>Hoy quiero centrarme en cómo se ve eso al lanzar aplicaciones de IA. Para hacerlo, solo necesitamos entender 4 cosas.</p>\n<ul>\n<li>¿Qué significa realmente el 80%?</li>\n<li>¿Qué segmentos podemos atender bien?</li>\n<li>¿Podemos apostar fuerte?</li>\n<li>¿Podemos educar al usuario sobre los segmentos que no atendemos bien?</li>\n</ul>\n<p>El principio de Pareto, también conocido como la regla del 80/20, sigue aplicándose pero de una manera diferente a la que podrías pensar.</p>\n<h3>¿Qué es un MVP?</h3>\n<p>Una analogía que uso a menudo para ayudar a entender este concepto es la siguiente: Necesitas algo para ir del punto A al punto B. Quizás la visión es tener un coche. Sin embargo, el MVP no es un chasis sin ruedas ni motor. En cambio, podría parecerse a un monopatín. Lo lanzas y te das cuenta de que el producto necesita frenos o dirección. Así que luego lanzas un scooter. Después, descubres que el scooter necesita más palanca, así que añades ruedas más grandes y terminas con una bicicleta. Limitado por la fuerza que puedes aplicar como ser humano, empiezas a pensar en motores y puedes ramificarte en ciclomotores, bicicletas eléctricas y motocicletas. Y entonces, un día, lanzas el coche.</p>\n<h3>Considera la regla del 80/20</h3>\n<p>Cuando hablamos de que algo está 80% terminado o 80% listo, suele ser en un sentido de machine learning. En este contexto, cada componente es determinista, lo que significa que el 80% se traduce en 8 de 10 características completas. Una vez que las 2 características restantes estén listas, podemos lanzar el producto. Sin embargo, si queremos seguir la regla del 80/20, podríamos ser capaces de lanzar el producto con el 80% de las características y añadir el 20% restante más tarde, como un coche sin radio o aire acondicionado. Sin embargo, el significado del 80% puede variar significativamente, y esta definición puede no aplicarse a una aplicación impulsada por IA.</p>\n<h3>El problema con las estadísticas resumidas</h3>\n<p><img src=\"/assets/images/anscombes_quartet.png\" alt=\"Cuarteto de Anscombe\" class=\"post-img\" width=\"1200\" height=\"873\" /></p>\n<p>La imagen de arriba es un ejemplo del cuarteto de Anscombe. Es un conjunto de cuatro datasets que tienen estadísticas descriptivas simples casi idénticas pero distribuciones y apariencias muy diferentes. Esta es una explicación clásica de por qué las estadísticas resumidas pueden ser engañosas.</p>\n<p>Considera el siguiente ejemplo:</p>\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n        </tr>\n    </tbody>\n</table>\n<p>La puntuación promedio es 0.58. Sin embargo, si analizamos las consultas dentro de segmentos, ¡podríamos descubrir que estamos atendiendo la mayoría de las consultas excepcionalmente bien!</p>\n<blockquote>\n<p><strong>Admitir en qué eres malo</strong></p>\n<p>Ser honesto sobre en qué eres malo es una excelente manera de generar confianza con tus usuarios. Si puedes identificar con precisión cuándo algo tendrá un rendimiento deficiente y rechazarlo con confianza, entonces podrías estar listo para lanzar un gran producto mientras educas a tus usuarios sobre las limitaciones de tu aplicación.</p>\n</blockquote>\n<p>Es muy importante entender las limitaciones de tu sistema y ser capaz de comprender con confianza las características de tu sistema más allá de las estadísticas resumidas. Esto se debe a que no todos los sistemas son iguales. El comportamiento de un sistema probabilístico podría ser muy diferente del ejemplo anterior. Considera el siguiente dataset:</p>\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>.58</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>.57</td>\n        </tr>\n    </tbody>\n</table>\n<p>Un sistema como este también tiene la misma puntuación promedio de 0.58, pero no es tan fácil rechazar ningún subconjunto de solicitudes...</p>\n<h3>Aprender a decir no</h3>\n<p>Considera una aplicación RAG donde una gran proporción de las consultas son sobre consultas de cronología. Si nuestros motores de búsqueda no admiten esta restricción de tiempo, probablemente no podremos rendir bien.</p>\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n            <th>Query Type</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n    </tbody>\n</table>\n<p>Si estamos apurados para lanzar, podríamos simplemente construir un modelo de clasificación que detecte si estas preguntas son de cronología y lanzar una advertencia. En lugar de intentar constantemente empujar al algoritmo a que mejore, podemos educar al usuario y hacerlo cambiando la forma en que podríamos diseñar el producto.</p>\n<blockquote>\n<p><strong>Detectar segmentos</strong></p>\n<p>Detectar estos segmentos podría lograrse de varias maneras. Podríamos construir un clasificador o emplear un modelo de lenguaje para categorizarlos. Además, podemos utilizar algoritmos de clustering con los embeddings para identificar grupos comunes y potencialmente analizar las puntuaciones medias dentro de cada grupo. El único objetivo es identificar segmentos que puedan mejorar nuestra comprensión de las actividades dentro de subgrupos específicos.</p>\n</blockquote>\n<p>Una de las peores cosas que puedes hacer es pasar meses construyendo una característica que solo aumente tu productividad un poco mientras ignoras algún segmento más importante de tu base de usuarios.</p>\n<p>Al rediseñar nuestra aplicación y reconocer sus limitaciones, podemos potencialmente mejorar el rendimiento bajo ciertas condiciones identificando los tipos de tareas que podemos rechazar. Si somos capaces de poner estos datos de segmentos en algún tipo de Observabilidad En-Sistema, podemos monitorear de manera segura qué proporción de preguntas están siendo rechazadas y priorizar nuestro trabajo para maximizar la cobertura.</p>\n<h3>Descubre qué estás realmente tratando de hacer antes de hacerlo</h3>\n<p>Una de las cosas peligrosas que he notado trabajando con startups es que a menudo pensamos que la IA funciona en absoluto... Como resultado, queremos ser capaces de atender una gran aplicación general sin pensar mucho en qué es exactamente lo que queremos lograr.</p>\n<p>En mi opinión, la mayoría de estas empresas deberían intentar centrarse en una o dos áreas significativas e identificar un buen nicho a atacar. Si tu aplicación es buena en una o dos tareas, no hay forma de que no encuentres cien o doscientos usuarios para probar tu aplicación y obtener retroalimentación rápidamente. En cambio, si tu aplicación no es buena en nada, será difícil ser memorable y proporcionar algo que tenga uso repetido. Podrías obtener algo de viralidad, pero muy rápidamente, vas a perder la confianza de tus usuarios y encontrarte en una posición donde estás tratando de reducir la churn.</p>\n<p>Cuando estamos precargados, la capacidad de usar GPT-4 para hacer predicciones, y el tiempo hasta la retroalimentación es muy importante. Si podemos obtener retroalimentación rápidamente, podemos iterar rápidamente. Si podemos iterar rápidamente, podemos construir un mejor producto.</p>\n<h3>Reflexiones finales</h3>\n<p>El MVP para una aplicación de IA no es tan simple como lanzar un producto con el 80% de las características. En cambio, requiere una comprensión profunda de los segmentos de tus usuarios que puedes atender bien y la capacidad de educar a tus usuarios sobre los segmentos que no atiendes bien. Al entender las limitaciones de tu sistema y enfocarte en un nicho, puedes construir un producto que sea memorable y proporcione algo que tenga uso repetido. Esto te permitirá obtener retroalimentación rápidamente e iterar rápidamente, llevando finalmente a un mejor producto, al identificar tus hazañas de fuerza.</p>",
  "source_hash": "sha256:586dfae5ba8d3a4d77892daa3409a49b87721cd4076ee4a14aff999a3363624b",
  "model": "moonshotai/kimi-k2.6",
  "generated_at": "2026-06-10T20:24:07.027962+00:00"
}