- Muchos productos de IA se quedan en ser wrappers que llaman por API a modelos externos como ChatGPT, incorporando al producto riesgos de diferenciación, costo, velocidad y personalización.
- Un enfoque de simples llamadas a un LLM permite construir rápido, pero cualquiera puede copiarlo, y si OpenAI agrega esa misma función a ChatGPT, se vuelve difícil proteger el valor único del producto.
- Los LLM de propósito general tienen un costo de ejecución alto; una estructura como la de GitHub Copilot puede cobrar US$10 al mes mientras cuesta en promedio US$20, y algunos usuarios llegan a generar hasta US$80 al mes en costos.
- Visual Copilot de Builder intentó usar solo LLM para convertir diseños de Figma en código, pero por la latencia de respuesta y los límites de calidad terminó cambiando a una toolchain propia.
- En la práctica, suele ser más rápido, barato y controlable resolver primero el problema con código convencional y agregar modelos de IA especializados solo en áreas acotadas que son difíciles de manejar con código estándar.
Límites del enfoque de wrappers simples sobre LLM
- Muchos de los productos de IA que se están creando hoy se parecen más a un wrapper sobre otro modelo: envían entrada en lenguaje natural a la API de ChatGPT y reciben una salida también en lenguaje natural.
- Es fácil de implementar y permite crear funciones llamativas rápidamente, pero si el valor único del producto depende de tecnología avanzada de IA, el riesgo de ser copiado aumenta mucho.
- Cuando una persona crea una app como un chat con PDFs, luego aparecen muchas apps similares, y después OpenAI la incorpora directamente en ChatGPT; ese patrón aparece cuando falta tecnología realmente diferenciada.
- Si el producto no pasa de enviar una solicitud a ChatGPT con un botón y mostrarle la respuesta al usuario, su capacidad de defensa es la más débil.
- Si ya existe bastante tecnología propia y el LLM solo ayuda en una parte pequeña pero importante, la posición es mejor, aunque los problemas de costo y velocidad siguen ahí.
El costo y la velocidad son restricciones reales al llevarlo a producto
- Los LLM crecieron en tamaño y complejidad para ganar versatilidad general, y con eso también aumentó su costo de ejecución.
- Según The Wall Street Journal, GitHub Copilot cobraba US$10 al mes a los usuarios, pero su costo promedio era de US$20, y algunos usuarios le generaban a GitHub hasta US$80 al mes en costos.
- Muchos productos no necesitan un modelo gigante entrenado con todo internet, y el 99.9% de ese entrenamiento puede no tener relación con un caso de uso específico.
- Puede ocurrir que operar un servicio basado en LLM cueste más de lo que los usuarios están dispuestos a pagar.
- La velocidad también influye mucho en la experiencia del producto.
- En experiencias como ChatGPT, donde se lee palabra por palabra, una salida lenta puede tolerarse hasta cierto punto.
- En apps donde se necesita la respuesta completa antes de pasar al siguiente paso del flujo, la latencia se traduce directamente en una peor usabilidad.
- Visual Copilot de Builder intentó usar una transformación con LLM para convertir diseños en código de alta calidad, pero el proceso de enviar toda la especificación del diseño y recibir una nueva representación token por token tomaba varios minutos, lo que no era práctico.
- La representación que devolvía el LLM tampoco era algo legible para humanos, así que el estado de carga se parecía más a un simple spinner, y la experiencia de usuario no era buena.
Solo con fine-tuning no alcanza para personalizarlo bien
- Los LLM admiten fine-tuning, así que se pueden ajustar un poco para acercarlos al resultado deseado.
- Builder aplicó fine-tuning al enfoque de usar diseños de Figma como entrada y código como salida, pero incluso dando muchos ejemplos la calidad no mejoró.
- El resultado fue un enfoque lento, caro y de baja calidad, por lo que hacía falta otra alternativa.
- La alternativa elegida fue construir una toolchain propia.
- un LLM con fine-tuning
- un compilador personalizado escrito por ellos mismos
- un modelo entrenado internamente
- Hoy entrenar modelos propios ya no es algo reservado a científicos de datos o Ph.D. en machine learning; también puede hacerlo un desarrollador con experiencia razonable.
- Este enfoque ayuda a crear productos más rápidos, confiables, baratos y diferenciados.
Los productos de IA complejos no se basan en un solo modelo gigante, sino en una toolchain
- Un malentendido común sobre los productos de IA es pensar que una sola gran IA inteligente se encarga de toda la tecnología central.
- Incluso un auto autónomo no funciona tomando entradas de cámaras, sensores y GPS en una sola IA gigante que inmediatamente produzca una acción como girar a la derecha.
- En la práctica, se conectan varios modelos especializados junto con código convencional.
- Los modelos de computer vision encuentran e identifican objetos.
- Los modelos de decisión predictiva anticipan el comportamiento de otras personas.
- Los modelos de procesamiento de lenguaje natural entienden comandos de voz.
- Mucho código y lógica convencionales producen el resultado final.
- Un auto autónomo es un caso muchísimo más complejo, y no hace falta ese nivel de complejidad al empezar un producto de IA más común.
- Las funciones de un auto tampoco aparecieron completas de una sola vez: empezaron con estacionamiento automático o frenado automático por proximidad, y luego se agregaron capas como corrección de salida de carril y decisiones completas de conducción.
- Igual que en software, las funciones de IA se construyen apilando una capa sobre otra.
Primero resuélvelo con código convencional y agrega IA especializada solo donde haga falta
- Un punto de partida importante del enfoque de Visual Copilot es no usar IA desde el principio.
- Primero hay que explorar el espacio del problema con programación convencional y encontrar en qué partes realmente hace falta un modelo especializado.
- El enfoque de “supermodelo” de meter grandes volúmenes de datos de Figma en el modelo y recibir código terminado directamente es demasiado complejo.
- Hay muchos frameworks que soportar.
- Hay muchísimas opciones de estilos y personalización.
- Es difícil reentrenar continuamente para reflejar datos nuevos.
- Puede volverse tan complejo, lento y caro que incluso dificulte lanzar el producto.
- Builder primero exploró hasta dónde podía llegar sin IA.
- Tenía que convertir cada nodo de diseño en algo que pudiera representarse como código.
- Tenía que entender con detalle elementos como imágenes, fondos y primeros planos.
- Tenía que manejar con mucha precisión cómo volver responsivo cualquier tipo de entrada.
- Crearon varios algoritmos sofisticados con lógica escrita a mano, por ejemplo para convertir elementos apilados verticalmente en
flex columny elementos uno al lado del otro enflex row. - Agregaron IA justo en el punto donde llegaron al límite del código estándar.
- Por ejemplo, detectar automáticamente qué capas debían combinarse en una sola imagen era algo fácil para la percepción humana, pero no para código imperativo en JavaScript.
- Tipos de modelo bien establecidos, como los de detección de objetos, pueden entrenarse en productos como Google Vertex AI seleccionándolos desde una GUI, preparando los datos y subiéndolos.
- Para generar datos, se puede usar internet.
- usar
puppeteerpara abrir sitios web en el navegador y tomar capturas de pantalla - recorrer el HTML para encontrar etiquetas
img - usar la ubicación de las imágenes como datos de salida y la captura de la página como datos de entrada
- así obtener coordenadas de subimágenes y la imagen original para entrenar un modelo de detección de objetos
- usar
- Al combinar código con modelos de IA especializados, se puede seleccionar un diseño, hacer clic en Generate code y luego esperar alrededor de 1 segundo para pasar a Builder.io.
- En Builder se puede obtener un sitio web totalmente responsivo y código de alta calidad personalizable, con soporte para múltiples frameworks y opciones.
Ventajas de producto al controlar modelos propios
- Tener modelos propios permite no quedarse solo en envolver modelos externos, sino seguir mejorándolos de forma continua.
- Si dependes únicamente de modelos externos como los de OpenAI, no puedes garantizar cuándo se volverán más inteligentes, más rápidos o más baratos para tu caso de uso específico.
- El grado de control que se logra solo con prompt engineering y fine-tuning también es limitado.
- Visual Copilot sigue en beta y todavía hay diseños que no interpreta bien, pero mejoran todos los días a partir del feedback de usuarios.
- Controlar la tecnología propia también permite ajustarse mejor a requisitos de privacidad.
- Grandes empresas muy enfocadas en privacidad suelen comentar que no pueden usar OpenAI ni productos que dependan de OpenAI.
- Existen requisitos de que los datos no entren en sistemas no autorizados.
- Como Builder controla toda la tecnología, puede aplicar estándares altos de privacidad.
- La etapa de LLM no es obligatoria, sino casi opcional, así que puede desactivarse.
- Las empresas también pueden conectar su propio LLM.
- un modelo completamente interno
- un fork de
llama2 - su propia instancia enterprise de OpenAI
- u otros modelos
- La IA debería usarse lo menos posible, dejando al código convencional como una base rápida, confiable, determinista y fácil de depurar, corregir, mantener y probar.
- La magia del producto no aparece por reemplazar todo con IA, sino por usar modelos de IA en áreas pequeñas pero decisivas.
1 comentarios
Opiniones de Hacker News
Coincido con el enfoque general del artículo, pero no creo que elegiría la forma de implementación que propone el autor.
La conclusión que saco es no depender demasiado de los LLM. Eso aplica tanto al alcance de las tareas que se les delegan como a evitar quedar atado a un LLM específico.
Por ejemplo, aunque uses OpenAI internamente, un producto que compita de frente con ChatGPT puede estar en desventaja a largo plazo. Si creas una app para reservar hoteles y vuelos con un chatbot, es muy probable que algún día ChatGPT, Microsoft o Google ofrezcan una función parecida mejor y dejen sin fuerza a un negocio pequeño.
También veo como una pérdida de tiempo depender demasiado de cosas como el SDK de OpenAI; llamar directamente a la API REST es más flexible.
Pero agregar un compilador a la cadena de herramientas es otro tema. Cada vez que metes un compilador, aumentan la complejidad innecesaria y la dependencia de una herramienta concreta. Si React o Svelte alcanzan, usar un transcompilador de componentes parece simplemente una cosa más que hay que aprender para crear una app web.
Creo que el mensaje final del artículo debería ser: “crea la cadena de herramientas más eficiente para lograr tu objetivo”. Agregar muchas herramientas no crea valor, ni tampoco seguir la forma en que lo hacen los demás; y esto aplica no solo a la integración de apps con LLM, sino a la ingeniería de software en general.
No tengo claro cómo la IA haría esto de forma distinta, ni si no terminaría chocando con las mismas restricciones.
Será algo único y no tan fácil de copiar, pero si se consideran los lenguajes que soporta, el costo de mantenimiento será enorme.
Esta capa adicional de abstracción se siente un poco como una fábrica-de-fábrica-de-fábrica.
De hecho, la IA tiene más margen para especializarse que la búsqueda de vuelos.
En chatbots para tareas especializadas, ahora que la interpretación básica del lenguaje ya es suficientemente buena, la calidad del modelo de lenguaje generalista no es el factor más importante. Un chatbot de reservas de viajes ajustado a mis preferencias e integrado con APIs de nicho relevantes no será desplazado fácilmente por una herramienta generalista que parsea un poco mejor las preguntas, pero quiere reservar todo mediante Expedia.
En mercados así, una buena o mala recomendación puntual también puede generar lealtad de marca o rechazo, así que tampoco parece algo cercano a que el ganador se lo lleve todo.
En realidad, ese no era el punto central del post.
Su producto es una herramienta que convierte automáticamente archivos de diseño de Figma en código React. Para resolver ese problema con código normal, la herramienta adecuada es justamente un compilador.
No están diciendo que todo el mundo deba usar compiladores.
En este contexto, la crítica a los compiladores en general no encaja mucho. La alternativa es usar ChatGPT como si fuera un compilador, y el artículo argumenta de forma bastante convincente que eso es peor. O quizá lo que se quiere decir es que el producto en sí, uno que genera código React, es malo; me da curiosidad.
Es un artículo que da para pensar, y estoy de acuerdo con la idea de “no uses IA durante el mayor tiempo posible”.
La IA se usa mejor para cosas que solo se pueden hacer con IA. Si hay una forma de crear una función o resolver un problema sin IA, suele ser mejor hacerlo así.
Ahora que todos tienen acceso casi equivalente a modelos de primer nivel, los buenos productos terminarán definiéndose por lo que no es IA: flujo de trabajo, UI, experiencia de usuario, rendimiento y otros factores clásicos.
Dicho eso, no me convence el consejo de “entrena tu propio modelo”. Puede ser una forma de hacer que tu producto envejezca rápido. Tal vez te diferencie por un rato, pero si en 6 a 12 meses OpenAI o un competidor con muchísimo financiamiento lanza un modelo mucho mejor, ese modelo diferenciado se convierte directamente en deuda técnica.
Que una startup pequeña intente competir por modelo parece una gran distracción. Es parecido a crear tu propia base de datos en lugar de usar Postgres o MySQL. Claro que necesitas un foso defensivo y un producto difícil de copiar, pero tiene que estar en un área donde, con los recursos que tienes, realmente puedas llegar a ser el mejor.
Entonces salió ChatGPT y el trabajo de los competidores quedó obsoleto de golpe, mientras él pudo ponerse al día con funciones de IA en pocas semanas.
Acertó en qué había que construir, aunque por las razones equivocadas, y al final fue un beneficio enorme para el negocio.
La diferenciación realmente es un factor bastante importante.
Es un buen texto y creo que le va a resonar a la mayoría de las nuevas startups de AI. Mi consejo es directamente no crear productos de AI.
El marco de “producto de X” rara vez lleva a aportar valor al cliente. Por ejemplo: productos web3, productos de observabilidad, productos de visión artificial, productos de AI, etc.
Como con toda buena idea de startup, la clave es partir de una necesidad real del usuario, no encajar a la fuerza un problema porque quieres usar una tecnología emergente. Ponerle una UI a una tecnología inflada por las expectativas no satisface una necesidad del usuario.
No lo digo porque odie los LLM, pero la mayoría de la gente que conozco offline detesta interactuar con chatbots como producto. Me mudé hace poco y tuve que lidiar con bots de soporte al cliente de proveedores de energía, agua e internet; todos fueron horribles.
Creo que partir de “GPT es genial” para crear chatbots personalizados difícilmente resuelve una necesidad real del usuario o deriva en un negocio sostenible.
Incluso descubrir un problema lo suficientemente real como para justificar el costo tecnológico está fuera de la zona cómoda de muchos técnicos. Asumimos que el problema es real o, peor, deseamos que lo sea, y nos lanzamos directo a resolverlo. Porque construir es nuestro terreno conocido.
Esa actitud o proceso en sí no está mal. En muchos casos en que técnicos resolvieron problemas reales, el problema real apareció por accidente durante el proceso de construir, iterar y abandonar.
Por eso, para los técnicos, la mejor forma de encontrar un problema real quizá no sea quedarse mucho tiempo en el descubrimiento del problema, sino tener un mejor ciclo de lanzamiento-iteración-abandono: mirar el uso actual, extrapolar el futuro y decidir rápidamente qué construir y qué no.
Después de leer biografías de varios líderes tecnológicos, llegué a ver que la capacidad clave que los distingue es empezar con un MVP muy básico y refinar de forma exponencial, en poco tiempo, su intuición sobre la demanda futura.
Hace unos años ya existían los chatbots, y casi todas las grandes empresas tenían una estrategia para ellos. La idea era reducir mucho el personal de call center y mejorar la experiencia del cliente.
El problema no era solo la calidad de la conversación. Para muchos usuarios, lo importante no era solo obtener la respuesta a su problema, sino sentir una conexión humana, que alguien los estaba escuchando.
Lo que quiero es que el trámite se resuelva lo más rápido posible; si hablo con una persona real o no, no me importa.
La razón por la que hasta ahora los chatbots no ayudaban era que agregaban tiempo y frustración al proceso. El primer paso era lograr que el chatbot escupiera un número de teléfono o, con suerte, te conectara con un agente.
Por supuesto, los chatbots anteriores a OpenAI eran pésimos. Pero si los chatbots posteriores a OpenAI son realmente excelentes, no veo por qué la gente no los usaría.
Hace unos años era blockchain. No sé qué viene después, pero ya se ve que la red de “tecnólogos” de LinkedIn se movió de startups cripto a startups de AI.
Parece una decisión que sacrifica mucho la velocidad de lanzamiento.
Si tardas 6 a 12 meses en lanzar, otros equipos quizá ya estén usando directamente modelos alojados, iterando dos veces y construyendo una base real de clientes. Para entonces, tú le muestras la v0.1 a tu primer cliente, y el cliente puede decirte que en realidad quería otra cosa.
Entonces no se trata de ajustar un poco el prompt, sino de volver a programar el compilador y la cadena de herramientas, de arriba abajo en el stack.
Puede tener sentido si conoces muy bien al cliente y los requisitos, pero en una situación tan fácil me inclino más al escepticismo: ¿por qué no validar temprano el concepto con un modelo alojado, aunque sea generalista y caro? Es el típico problema de que la optimización prematura es la raíz de todos los males.
Había mucho sobre tecnología y pipelines, pero sin un producto que construir ni un problema que resolver, nada de eso significa nada.
Es parecido a discutir con los usuarios si SOAP es mejor que REST. A los usuarios no les importa cómo lo construiste.
Lo estás pensando demasiado desde el punto de vista competitivo. Basta con construir algo que no sea fácil de copiar.
Hay muchas formas de hacerlo, pero desde una perspectiva competitiva esa es la única regla necesaria.
En casi todos los mercados verticales, cerca del 100% del mercado total sigue abierto.
La diferenciación técnica es solo una pequeña pieza; creo que lo primero importante es el alcance.
Es una carrera hacia 1.000 millones de usuarios y, si eres B2B como nosotros, quizá hacia 1 millón de usuarios. Al mismo tiempo, es una carrera por el mayor valor —el problema resuelto y la experiencia de usuario—, no una carrera por las mejores especificaciones técnicas.
Si tu diferenciador es algo que otra persona no puede copiar usando OAI, entonces es seguro usar OAI.
Si tu único diferenciador es que usas OAI, de todos modos ya estás condenado.
En términos generales, estoy de acuerdo con el estado que se plantea como conclusión. Nuestro producto también usa LLM dentro de un flujo de control tipo máquina de estados, y funciona bien.
Pero no comparto el tono del autor. Si eres un desarrollador que solo ha usado la UI web de ChatGPT, deberías probar y construir tecnología de “wrapper de AI” al 100%.
Porque hasta que no encuentres por ti mismo los límites de los modelos de primer nivel, es difícil ver dónde y cómo usar LLM dentro de un stack de software tradicional.
La empresa del autor también parece haber recorrido finalmente ese camino. Al principio hicieron un prototipo basado en LLM que convertía de Figma a código, y después de que funcionó “hasta cierto punto”, encontraron los huecos del proceso.
Así que creo que es mejor construir lo que quieras con algo como GPT-4-Vision —por ejemplo, un “sistema de calificación de tarjetas coleccionables basado en AI”— y luego buscar cómo convertirlo en un producto real que funcione, como builder.io.
Parece que pronto la IA estará integrada en muchos tipos de software. Ahí es cuando se pondrá realmente genial y también aterrador.
Un ejemplo simple es un cliente de correo electrónico. Si alguien pide una decisión o una confirmación, la IA podría extraer la pregunta y presentar botones de opción.
Ej.: aceptar un horario propuesto para una cita: [viernes 10:00] [lunes 11:30] [proponer otro horario]
George pregunta si puede presentar el borrador: [sí] [no]
Parece que el software de tickets de soporte al cliente como Zendesk ya tiene IA. Es muy probable que muchas solicitudes de soporte ya se estén respondiendo casi automáticamente.
Recursos Humanos también podría usar IA para filtrar solicitudes de empleo, hacer que investigue información adicional sobre los candidatos en internet y luego crear entradas estandarizadas en una base de datos. Claro, podría tener muchísimas fallas.
Lo interesante son este tipo de aplicaciones, no otra extensión o plugin de ChatGPT.
La idea es ejecutar un pipeline para cada correo nuevo y hacer que sugiera algunas acciones.
Todavía estoy considerando varios enfoques, pero ya parece bastante viable.
La introducción parece un poco demasiado florida y exagerada. Por ejemplo, los LLM no son tan caros, no me convence mucho la afirmación de WSJ de que Copilot pierde dinero por usuario, y tampoco creo que los LLM siempre sean “dolorosamente lentos”.
Aun así, las recomendaciones concretas del artículo son bastante razonables.
La idea es resolver con código la mayor cantidad posible de partes y usar IA especializada para lo que no se pueda hacer con código.
Es razonable, pero no especialmente novedoso.
Esperaba que profundizara más en cómo crear productos de IA realmente útiles y buenos. Ha habido muchos intentos últimamente, como el lanzamiento de Humane, pero todavía no parece haber muchos éxitos.
Este artículo se centra bastante en cómo construir productos de IA, pero personalmente creo que el éxito o fracaso de un “producto de IA” depende más de si es realmente útil que de la diferenciación, el costo, la velocidad o la personalización del modelo.
Por desgracia, la mayoría de los productos que he visto hasta ahora se sienten como soluciones en busca de un problema.
Creo que el camino que deberían seguir ahora las empresas es identificar las partes más tediosas y repetitivas al usar un producto, y encontrar una forma de simplificarlas de manera confiable con IA.
Como en todo ciclo de sobrecalentamiento, si lo único que tienes es un martillo, todo parece un clavo.
El martillo de hace poco era blockchain, y ahora es la IA.
Si fuiste lo bastante ingenuo como para creerte las promesas de blockchain, es natural que te decepcione que la IA no sea una pirámide para hacerse rico de golpe, que te permita ganar millones de dólares sin tiempo, energía ni pensamiento original.
Si eso es lo único que buscas, seguirás decepcionándote, y con razón.
La IA tiene muchísimo más que ofrecer que blockchain. Compararlas como si estuvieran al mismo nivel significa que no entiendes bien ninguna de las dos.