En Statsig, tenemos la suerte de tener un asiento en primera fila para ver cómo se están construyendo los mejores productos de IA.
Vemos de primera mano cómo nuestros clientes confían en la experimentación para mejorar sus aplicaciones de IA: no solo OpenAI y otros proveedores líderes de modelos fundacionales, sino también equipos de producto de clase mundial que construyen aplicaciones de IA como Figma, Notion, Grammarly, Atlassian, Brex y otros.
No es una exageración decir que todas las aplicaciones de IA líderes dependen de pruebas A/B sistemáticas para probar, lanzar y optimizar su producto.
El problema con esta afirmación es que es... aburrida. El poder de la experimentación sistemática y las pruebas A/B no es un secreto. Ha sido una parte fundamental del stack de producto moderno desde principios de 2010, y eso no ha cambiado con la IA.
Ahora, a medida que la IA asume más del "construir" en el ciclo construir > medir > aprender, la medición, optimización e iteración se vuelven aún más críticas.
Hemos notado algunas tendencias particularmente interesantes en cómo la experimentación tradicional está evolucionando para apoyar el desarrollo de IA.
Tradicionalmente, las pruebas de IA/ML se centraban en entrenar modelos personalizados diseñados para tareas específicas. Los ingenieros de investigación especializados estaban profundamente involucrados desde la ideación hasta el desarrollo, las pruebas y el despliegue: un proceso que podía llevar meses o incluso años completar.
Esta versión de las pruebas offline era muy académica. Los investigadores probaban el modelo contra varias pruebas estadísticas y benchmarks (perplejidad, puntuación F, puntuación ROUGE, HELM) para evaluar su rendimiento para una tarea determinada.
También había un gran énfasis en la preparación y procesamiento de datos; los datos de entrenamiento tenían que prepararse cuidadosamente y dividirse en conjuntos de entrenamiento, validación y prueba que se usaban durante todo el desarrollo del modelo.
Después de todas estas pruebas, los modelos se evaluaban con retroalimentación humana y luego se enviaban a producción como un experimento. Muchos de nuestros clientes han tenido éxito con la experimentación para optimizar sus modelos de ML. Whatnot, por ejemplo, ejecutó cientos de pruebas para optimizar su feed y Runna desarrolló un algoritmo altamente personalizado para entrenar corredores.
A medida que los equipos comienzan a construir con modelos fundacionales (en lugar de preparar sus propios modelos), está surgiendo un nuevo paradigma para las pruebas offline: las evaluaciones offline.
Las evaluaciones funcionan preparando un conjunto de entradas representativas, como un conjunto de preguntas o prompts de usuarios, y ejecutándolas a través de una versión de prueba de una aplicación LLM. Los ingenieros o PMs revisan las salidas para cada versión, ven cuáles se ven mejor y luego envían la versión que parece funcionar mejor.
Por lo general, los resultados no muestran una diferencia tan dramática, pero las evaluaciones sistemáticas sí revelan diferencias sutiles en las salidas de diferentes combinaciones de entradas, como prompts, modelos, contexto y más.
Esta es una forma muy efectiva de tener una idea de qué cambios funcionan mejor. Desafortunadamente, este proceso sigue siendo lento y a menudo requiere una versión de "prueba" de la aplicación construida específicamente para ejecutar evaluaciones.
Estas aplicaciones de prueba también pueden carecer de componentes críticos de la experiencia del usuario, como el contexto de chats anteriores, elementos de UI que contribuyen a la sesión y otros componentes que pueden interactuar con cambios en un prompt o modelo.
Cada vez más, los equipos están usando una versión de producción de su aplicación para ejecutar evaluaciones offline, usando logging para almacenar salidas a diferentes entradas, o simplemente probando algunas entradas manualmente. Si bien esto inevitablemente resulta en menos muestras, permite a los equipos de producto ver un prototipo representativo en acción.
Una vez que tienen una versión con la que se sienten bien, simplemente envían la versión actualizada como una prueba A/B, dándoles una señal real de los usuarios sobre cómo está funcionando. Esto también proporciona datos sobre cómo los cambios afectan otros aspectos del rendimiento de la aplicación, como el costo y la latencia.
El mes pasado, desarrollamos un flujo de trabajo automatizado (disponible en Alpha) que te permite hacer cambios rápidos en prompts y modelos, probar contra un conjunto de datos de evaluación y enviar a producción como un experimento.
Nos estamos inclinando hacia esta tendencia con un nuevo conjunto de herramientas que vinculan las evaluaciones offline y los experimentos online. ¡Pronto habrá mucho más aquí!
Todas las empresas están usando IA para escribir código. Aunque las estadísticas varían, Microsoft dice que 1/3 del código es generado por IA, y Anthropic recientemente dijo que casi el 90% de su código es generado por IA.
A medida que esta tendencia continúa, la necesidad de optimización cuantitativa del rendimiento de las aplicaciones va a aumentar masivamente.
Primero, a medida que los ingenieros envían más código generado por IA, necesitan una forma de detectar errores, degradaciones de rendimiento y otros problemas potenciales. Para hacer esto, necesitas dos cosas:
Buen logging en todas las métricas de producto que te importan
La capacidad de vincular estas métricas a todo lo que lanzas
Segundo, la experimentación sistemática combinada con herramientas como análisis de producto y observabilidad es la única forma de escalar esto efectivamente.
Estamos viendo cada vez más clientes inclinándose hacia esta tendencia: usando IA para construir nuevas características rápidamente, probándolas en producción detrás de un feature gate al 0% para asegurar que no haya efectos de interacción inesperados, y lanzándolas como una prueba A/B para asegurarse de que tengan un impacto positivo en el rendimiento del producto.
A medida que los agentes comienzan a enviar nuevas características por sí mismos, los equipos necesitarán una forma de gestionar su trabajo y asegurarse de que esté moviendo el producto en la dirección correcta. Nuevamente, poner cambios detrás de un feature gate y ejecutar pruebas A/B es la mejor manera de hacer esto.
Nuestro equipo está usando Devin exactamente de esta manera. Alimentamos a Devin con solicitudes de clientes o tickets de soporte, le pedimos que encuentre y arregle el error, lo pruebe en un entorno de desarrollo, luego envuelva la actualización en un feature flag, agregue eventos de log relevantes, pruebe en producción y finalmente lo despliegue como una prueba A/B. Este proceso nos permite usar IA para procesar solicitudes increíblemente rápido, sin comprometer la seguridad o el pulido.
Estamos agregando capacidades que permiten a cualquiera usarnos de esta manera, incluido el servidor MCP de Statsig que ayuda a los agentes a crear gates o experimentos de forma independiente, y herramientas adicionales para desarrolladores que construyen con IA (como las reglas de Cursor).
Hoy, los ingenieros pueden centrarse más en el impacto de su trabajo en lugar del trabajo pesado de construir características. A medida que los LLMs escriben más código, el esfuerzo marginal para enviar una idea simple cae a cero. Eso significa que puedes probar muchas más ideas, más rápido.
En los playbooks clásicos de crecimiento liderado por producto de SaaS, los equipos probaban diferentes impulsores de momentos "ajá", como Notion o Canva ofreciendo plantillas listas para usar en el flujo de nuevos usuarios.
Ahora, con IA, puedes probar 10 veces más ideas. El desafío cambia de construir características a identificar cuáles realmente mueven tus métricas de producto y negocio. ¡Cada ingeniero, incluso los stakeholders no técnicos, pueden ser ingenieros de crecimiento ahora!
Incluso en Statsig, la IA no solo está cambiando cómo construimos productos, sino también cómo impulsamos el crecimiento. Por ejemplo, construimos un agente de onboarding de IA que te permite agregar Statsig a tu proyecto React con un solo comando. Continuamos mejorando probando características como soporte OAuth para hacer la experiencia del desarrollador más fluida y reducir aún más el tiempo hasta el valor.
Se ha vuelto común que las aplicaciones basadas en interfaces de chat (como ChatGPT, Vercel V0, Lovable) experimenten con prompts sugeridos para ayudar a los usuarios a descubrir y realizar valor rápidamente, lo que posteriormente impulsa el engagement y la retención.
A medida que los modelos fundacionales mejoran en inteligencia generalizada (llevarte al 80% de la solución), tu conocimiento de dominio diferenciado, comprensión de los problemas de los usuarios y superficies para aplicar IA marcarán toda la diferencia.
Lo que quiere decir es que incorporar IA en tu producto no es tan simple como conectar un LLM listo para usar. Necesitas hacerlo más útil con el contexto correcto, datos y comprensión de los flujos de trabajo de los usuarios.
Tomemos el caso de Grammarly vs. ChatGPT. ChatGPT ciertamente puede producir escritura de alta calidad en gramática y lenguaje. Sin embargo, Grammarly ha construido un negocio de más de $700 millones en ARR que continúa creciendo al centrarse en la productividad.
Han construido integraciones donde las personas realmente escriben (haciéndolo en tiempo real), guías de estilo, sugerencias estratégicas basadas en muestras de escritura propietarias, formas más rápidas de incorporar estas sugerencias y más. De manera similar, Harvey ha construido IA en flujos de trabajo legales clave y arcanos, nuevamente basándose en una profunda experiencia de dominio.
Es fácil construir una aplicación de IA, pero hacer una que sea realmente útil es una historia diferente. Necesitas muchas pruebas A/B para optimizar tu producto y hacer que la experiencia del usuario sea fluida.
Hoy, gracias a los servidores MCP, se ha vuelto más fácil integrar el contexto novedoso de tu producto con IA. Esto significa que más que nunca, necesitas centrarte en probar y optimizar tus modelos, prompts y conjuntos de datos para entregar valor real y diferenciado al usuario.
¡Y a medida que avanzamos hacia un mundo agéntico, los agentes también necesitan experimentación!
Los agentes son sistemas complejos de múltiples pasos que a menudo ejecutan una gran cantidad de tareas. Eso los hace candidatos perfectos para experimentos online: cambia un componente en un solo nodo y podrías ver efectos significativos aguas abajo en métricas clave como rendimiento, costo, etc.
Si estás interesado en asociarte con nosotros mientras construimos herramientas de experimentación específicamente enfocadas en optimizar agentes, ¡por favor contáctanos!
Atrás quedaron los días en que había productos sin IA y productos con IA. Hoy, cada producto tiene IA integrada. Esto significa que probar y optimizar aplicaciones de IA es importante para todos, no solo para unas pocas empresas con sede en San Francisco.