En Shakers, estamos encantados de compartir nuestro primer blog técnico sobre Shakers AI: nuestra solución de sistemas multiagente para la creación inteligente de proyectos. Aunque hemos estado trabajando "en secreto" durante muchos meses, hoy queremos compartir el conocimiento que hemos adquirido con nuestra comunidad. Construir productos de IA reales es muy complicado, y con este blog queremos compartir aprendizajes y apoyar a otros mientras a integrar IA generativa en sus plataformas.
Este artículo es el primero de nuestra serie técnica de tres partes. Explicaremos los componentes clave que permiten a nuestra plataforma convertir los requisitos del proyecto en equipos funcionales con presupuestos y hojas de ruta precisos. Esta primera publicación se centrará en el papel de la experiencia del usuario en el núcleo de Shakers IA y las características técnicas que nos permitieron obtener un sistema de IA listo para producción.
Introducción
En Shakers AI, hemos desarrollado un sistema de IA que transforma cómo los proyectos pasan de conceptos iniciales a equipos completamente formados con presupuestos y hojas de ruta precisos. Esta serie de blogs técnicos recorre nuestro camino de construcción de una aplicación nativa de IA que crea valor real para nuestros usuarios.
Esta publicación sigue la progresión natural de nuestro proceso de desarrollo:
- Parte 1: Por qué la UX es la clave del éxito en los productos de IA.
- Parte 2: Los tres componentes principales de Shakers AI.
- Parte 3: Optimización de tiempos de respuesta y UX.
Parte 1: ¡El Rey ha muerto!
¡Viva el Rey!
Generando valor
Shakers es una empresa tecnológica con una misión clara: redefinir cómo entendemos el trabajo. Queremos ayudar a las personas a construir relaciones más saludables y satisfactorias con sus trabajos, y empoderar a las empresas para crecer y resolver problemas de manera más eficiente.
En Shakers, entendemos que cada cliente es diferente. Mientras que hay empresas que nos llegan con objetivos específicos, como construir un nuevo chatbot para resolver dudas de los clientes, otros pueden saber lo que quieren pero no cómo lograrlo. Algunos clientes solo quieren orientación para alcanzar sus objetivos. Y sabemos que, como comunidad de talento que somos, que estar preparados para ayudar a todas estas organizaciones.
Lo que hemos aprendido durante todos estos años, es que todos los proyectos comparten un desafío común: pasar de una idea a una definición sólida de plazos, costos y especificaciones es difícil. Todavía encontramos muchos proyectos que incluyen descripciones vagas o especificaciones copiadas y pegadas de LinkedIn con información deficiente. En consecuencia, los freelancers y los responsables de la toma de decisiones tenían largas videollamadas para aclarar los objetivos del proyecto, los requisitos técnicos y los presupuestos. Muchas veces para proyectos inadecuados para su perfiles o que no cumplían las expectativas de ninguna de las partes.
Así, durante meses vimos en las entrevistas con nuestra comunidad que esta situación generaba incertidumbre sobre las aplicaciones, y, al final del día, mucha frustración. Así, a mitad de 2024, decidimos que era momento de remangarse y resolver esta situación de una vez por todas.
En el mundo de la IA, la UX es el Rey
En Shakers, no somos nuevos en el mundo de la IA. Hemos pasado tres años desarrollando nuestro sistema predictivo de emparejamiento de IA para recomendar equipos de freelancers. Esta vez, nuestro objetivo era pasar de ser adoptantes de IA a crear una aplicación nativa de IA donde la IA controlaría una experiencia de usuario personalizada. El equipo de producto tenía clara dos cosas: a) que los agentes de IA eran la herramienta adecuada para el trabajo; y b) lo que nuestros freelancers aman en un briefing bien elaborado.
Cuando comenzamos a diseñar este sistema, en plena vorágine de los incipientes agentes de IA, imaginamos que un orquestador con agentes especializados sería la arquitectura ideal. Así, seríamos capaces de proporcionar una experiencia única mientras subgrafos de agentes refinaban automáticamente de respuestas en partes críticas.¿Por qué, al final, decidimos ir en contra de esta arquitectura?
Porque nuestro producto no trataba de encontrar la información correcta para la consulta correcta, típico de otros RAGs, sino de muchas veces proporcionar información que ni el mismo cliente conoce que tiene que aportar. Muchos líderes empresariales no están familiarizados con definir proyectos. Con generar especificaciones técnicas específicas y un roadmap de un proyecto técnico. Solo quieren obtener una solución (y normalmente, lo antes posible). Enfrentarlos con una pizarra vacía y esperar que interactúen con Shakers AI parecía poco realista.
Esta situación nos obligó a definir las dependencias entre diferentes elementos de un proyecto. La base de unas buenas especificaciones de proyecto son tareas claras, organizadas en una hoja de ruta, con un presupuesto. También necesitamos saber quién realizará estas tareas. Antes de tener las tareas, deberíamos definir el equipo freelance. Para definir un equipo, necesitamos saber qué quiere lograr el cliente y los requisitos técnicos. Así que necesitamos una etapa de consultoría o preguntas para obtener información clave del cliente.
Así, cerramos el círculo de Shakers AI.
El poder de no saber nada
El poder de los sistemas de IA efectivos no reside en su complejidad, sino en su capacidad para navegar por los desconocidos desconocidos que los propios usuarios no pueden articular.
Para entender si nuestra intuición era correcta, realizamos varios pequeños prototipos que nos permitieron refinar nuestro proceso rápidamente. Los resultados iniciales fueron impresionantes. Algunos clientes tuvieron conversaciones muy fructíferas y disfrutaron de este enfoque socrático para definir sus proyectos. Objetivo cumplido. Sin embargo, detectamos otra tipología de usuarios: usuarios de aplicación rápida que querían terminar rápidamente versus usuarios comprometidos que preferían un enfoque de ritmo lento.
Después de varias rondas de discusión, decidimos dividir nuestro flujo de usuarios en puntos de decisión mayores y menores. La división se basó en cuán consecuentes eran para el proyecto final. Identificamos tres puntos principales de decisión: a) equipo; b) presupuesto; c) talentos. Para estos, nos centramos en reducir la carga cognitiva del usuario optando por un patrón de elección. Para el resto, proporcionamos nuestra mejor suposición y permitimos que el usuario cambie nuestra opción predeterminada.
Este patrón permite un equilibrio entre crear un chatbot puro, que puede cansar a los usuarios pero es simple, y proporcionar opciones bien diseñadas que los usuarios pueden elegir rápidamente. Al final, presentamos más de 60 posibles combinaciones de tipos de proyectos, rutas de usuario y variaciones de UI.
Parte 2: Creando sistemas LLM listos para producción
Cuando se transita del desarrollo controlado a implementaciones en el mundo real, las consultas de los usuarios rara vez llegan en formatos estructurados. Las consultas del mundo real típicamente sufren de múltiples problemas de calidad:
- Vaguedad: Los usuarios proporcionan información incompleta, asumiendo contexto implícito
- Desalineación: El lenguaje del usuario no se alinea con la terminología técnica esperada
- Límites: Algunas consultas no corresponden con la oferta de productos de Shakers.
- Seguridad: Algunas consultas pueden sondear vulnerabilidades o buscar hackear el sistema.
Estos desafíos requirieron un robusto pipeline de procesamiento de consultas. Desarrollamos lo que llamamos la "trifecta" de aplicaciones LLM un enfoque de tres fases que mejoró dramáticamente la confiabilidad de nuestro sistema.
Expansión de consultas y enriquecimiento de contexto
Nuestra primera percepción fue que la entrada bruta del usuario típicamente contiene información insuficiente. Implementamos un sistema integral de expansión de consultas que realiza:
- Clarificación de intención: Identificar el objetivo subyacente del usuario
- Clasificación: Categorizar la consulta dentro de nuestro marco de proyecto
- Validación de seguridad: Comprobar solicitudes potencialmente dañinas
- Enriquecimiento de contexto: Complementar la consulta con información propietaria y pública
Nuestro sistema realiza una evaluación exhaustiva en más de veinte dimensiones diferentes, transformando consultas ambiguas en solicitudes ricas y contextualizadas. Cada proyecto se evalúa en áreas como:
- Identificación de tareas: Determinar los entregables esperados
- Evaluación de stack tecnológico: Identificar tecnologías apropiadas
- Inferencia del conocimiento del cliente: Calibrar la familiaridad técnica del cliente
- Detección de brechas de experiencia: Identificar áreas que necesitan explicación adicional
- Determinación de prioridades: Entender qué aspectos necesitan énfasis
- Calibración de complejidad: Ajustar la profundidad de explicación basado en la experiencia del usuario
Esta evaluación permite a nuestro orquestador adaptar su enfoque a la situación de cada usuario, generando preguntas y opciones de respuesta calibradas al caso de negocio y nivel de conocimiento.
Evaluaciones de respuesta y reconocimiento de límites
Nuestro descubrimiento más importante fue identificar cuándo la recopilación adicional de información se vuelve contraproducente. Sin limitaciones, nuestro sistema continuaría haciendo preguntas indefinidamente—llevando a interrogatorios sobre detalles intrascendentes o introduciendo requisitos alucinados.
Impusimos una segunda llamada LLM que actúa como evaluador—comprobando si se ha proporcionado suficiente información y determinando cuándo concluir la fase actual. Este mecanismo de autocrítica:
- Evalúa la completitud de la información recopilada
- Evalúa si preguntas adicionales producirían rendimientos decrecientes
- Determina cuándo el sistema tiene suficiente contexto para proceder
- Previene interrogaciones excesivas que podrían frustrar a los usuarios
Este mecanismo produjo resultados notables a pesar de su simplicidad conceptual, creando conversaciones que se sienten con propósito en lugar de exhaustivas.
La Fórmula Dorada: Nuestro Enfoque Trifecta
Combinar la expansión de consultas, la generación multidimensional y la autoevaluación se ha convertido en nuestra fórmula dorada. Esta arquitectura ahora sirve como el plano para todo nuestro desarrollo de herramientas, asegurando calidad consistente en toda nuestra plataforma.
Este enfoque reconoce una verdad fundamental: la calidad de las salidas depende de la calidad de las entradas y la sofisticación del proceso de evaluación. Al mejorar las consultas, aplicar evaluación matizada e implementar autocrítica, hemos desarrollado un marco que entrega resultados valiosos incluso desde entradas imperfectas del usuario.
El Desafío de la Orquestación
Nuestro siguiente desafío fue crear un sistema que pudiera coordinar múltiples componentes. Implementamos una arquitectura jerárquica con un orquestador gestionando el flujo general del usuario, manejando funciones como:
- Clasificación de necesidades del usuario
- Determinación de composición del equipo
- Definición del alcance del proyecto
- Identificación y organización de tareas
- Estimación de presupuesto
- Especificación de requisitos de talento
Apoyando a este orquestador principal hay sub-orquestadores especializados dedicados a cada módulo central. El orquestador principal dirige a los usuarios a través de diferentes experiencias basadas en sus necesidades específicas, creando una experiencia coherente y personalizada.
Las organizaciones que adopten este modelo podrán aumentar su productividad hasta en un 55% y reducir sus costos en un 27%.
Parte 3: El Desafío del Tiempo de Respuesta
Al desarrollar aplicaciones impulsadas por IA, el tiempo de respuesta rápidamente emerge como un desafío crítico. Identificamos tres factores primarios que impactan significativamente los tiempos de respuesta.
1. Integrarse con todos los proveedores posibles.
Nuestro desarrollo comenzó usando exclusivamente los modelos de OpenAI. Si bien estos entregaron una impresionante calidad de salida, sus tiempos de respuesta no eran óptimos para todos nuestros casos de uso.
Realizamos comparativas exhaustivas entre múltiples proveedores y encontramos que para tareas específicas, cambiar a Gemini Flash y Llama 3.3 mejoró los tiempos de respuesta en un 300-500% con cambios mínimos de código.
La lección: permanecer agnóstico respecto al proveedor es esencial para optimizar aplicaciones LLM. Diferentes proveedores sobresalen en diferentes tareas, y seleccionar el modelo más apropiado para cada función proporciona enormes beneficios de rendimiento con poco esfuerzo de ingeniería.
2. Elegir el modelo y tamaño correctos para cada tarea
Nuestra filosofía inicial era usar los modelos más capaces disponibles. Para optimizar efectivamente, implementamos un enfoque sistemático:
- Comenzamos con los modelos más capaces disponibles
- Gradualmente redujimos el tamaño del modelo mientras rastreábamos tiempos de respuesta y calidad de salida
- Realizamos pruebas aleatorias para identificar dónde la degradación de calidad se volvía inaceptable
- Creamos una matriz de tareas y tamaños de modelo apropiados
Nuestras pruebas revelaron que para muchas tareas de clasificación y generación estructurada, los modelos más pequeños rendían casi tan bien como sus contrapartes más grandes mientras entregaban respuestas más rápidas.
3. Minimizar los tokens de salida
Nuestra percepción más valiosa vino de entender las diferencias de procesamiento entre tokens de entrada y salida. Los LLM procesan tokens de entrada en gran medida en paralelo, pero los tokens de salida se generan secuencialmente, creando una relación lineal entre la longitud de salida y el tiempo de generación.
Esta realización transformó nuestro enfoque:
- Nos volvimos generosos con los tokens de entrada—incluyendo cualquier contexto útil
- Los tokens de salida se convirtieron en recursos preciosos para ser cuidadosamente gestionados
- Reestructuramos cada llamada LLM para producir salidas altamente estructuradas
- Cuando era posible, requeríamos respuestas de una sola palabra en lugar de texto abierto
- Implementamos reglas estrictas de formato de salida para prevenir verbosidad innecesaria
Al optimizar para una salida mínima pero suficiente, redujimos los tiempos de espera mientras mejorábamos la consistencia de respuesta. Por otro lado, aprovechar la capacidad de hacer catching de prompts de varios proveedores genera ganancias en velocidad que no son desdeñables, con lo que siempre que se pueda es bueno “activar” este catching previo a las tareas directas de inferencia.
Conclusión
Nuestro viaje construyendo Shakers AI ha transformado nuestra comprensión del diseño efectivo de sistemas de IA. El enfoque trifecta—expansión de consultas, evaluación multidimensional y autocrítica—ha demostrado ser la base de aplicaciones LLM confiables que entregan valor real. Combinado con nuestra arquitectura de orquestación y estrategias de optimización de rendimiento, hemos creado un sistema que entiende las necesidades del usuario y entrega soluciones eficientemente.
Recomendamos centrarse en la experiencia del usuario por encima de la sofisticación técnica para organizaciones que se embarcan en viajes similares. Las arquitecturas de agentes más impresionantes entregan poco valor si son demasiado lentas, demasiado complejas o desconectadas de las necesidades reales del usuario. Comience con casos de uso claros, diseñe para capacidad de respuesta e implemente sistemas de validación que aseguren confiabilidad. Lo más importante, permanezca agnóstico respecto al proveedor y listo para adaptarse a medida que evoluciona el panorama de la IA.
Descubre más
sobre Shakers
Descubre cómo tu empresa se puede beneficiar de Shakers o contacta al equipo para saber más
Accede a los mejores freelances especializados en software, marketing y diseño para hacer frente a tus retos más importantes.
