Primero, digámoslo de manera poco amable:
El proyecto de IA más reciente en la plaza de Binance, medio como un 'concurso de vocabulario'. Cuanto más futurista sea tu cartel, y cuanto más parezca infraestructura tu título, más fácil será ser compartido. Luego, al hacer clic, el contenido suele ser un conjunto de cuatro partes: memoria, razonamiento, automatización, liquidación. Y se acompaña con la frase 'listo para IA', como si estuviera certificado.
@Vanarchain Este tipo de proyectos también escapan de este contexto narrativo. ¿Quieres que te diga si hay espacio para la imaginación? Por supuesto que lo hay. ¿Quieres que te diga si creo en ello? **No tengo prisa por creer.** Porque he visto demasiadas cosas que 'parecen infraestructura', y al final se convierten en dos finales:
Una forma es un 'mercado de componentes', donde hay de todo, pero cuando los desarrolladores entran, descubren que el costo de ensamblaje, costo de adaptación y costo de mantenimiento son todos su responsabilidad;
Otro tipo más común: la infraestructura de PPT, que suena como un estándar industrial, pero se implementa como un taller artesanal.
Así que no quiero escuchar más 'narrativas grandiosas'. Si Vanry vale la pena, solo tengo tres medidas para evaluar:
¿Quién está usando? ¿Qué se ha ahorrado? ¿Por qué a largo plazo?
Si no puedes responder, no me culpes por ser mordaz.
I. No hablemos aún de 'almacenes de piezas estándar', primero dime: ¿qué hay en el almacén que se pueda usar directamente?
Muchos proyectos dicen 'proporcionamos piezas estándar', lo dicen como si fuera una revolución industrial. El problema es que las palabras 'piezas estándar' no son algo que tú te atribuyas, son los usuarios (desarrolladores/proyectos) quienes las utilizan.
Las llamadas piezas estándar deben cumplir al menos tres condiciones:
1) Reutilizable: no se trata de que 'el concepto sea reutilizable', sino de que el código/interfaz/proceso pueda ser reutilizado.
2) Combinable: no se trata de que 'teóricamente sea combinable', sino de que realmente pueda ensamblarse con otras cosas sin pelearse entre sí.
3) Mantenible: no se trata de que 'el demo funcione', sino de que, una vez implementado, si surgen problemas, se puedan localizar, actualizar y ser compatibles, sin volver loco al proyecto.
Si dices que Vanry es un 'almacén de piezas estándar', entonces debo preguntar:
Cuando los desarrolladores integran tu sistema, ¿es 'simplemente usarlo después de instalar' o 'instalar y luego modificar durante tres semanas'?
¿Puedes explicarme claramente el costo de integración: qué módulos necesitan ser modificados, qué servicios dependen y cómo se monitorea después de la implementación?
¿Qué hacer si hay un problema? ¿Puedes ayudar a resolverlo o solo dirás 'por favor consulta la documentación'?
No es una crítica, es la realidad que un proyecto de infraestructura debe enfrentar:
Cuanto más bajo el nivel, más cruel; cuanto más abstracto, más fácil caer.
II. Deja de usar las cuatro palabras 'memoria/razonamiento/automatización/liquidación' para engañar a la gente: este conjunto de palabras ya se ha usado hasta el cansancio.
No me opongo a estas cuatro direcciones, lo que me opongo es:
Muchos proyectos los consideran un 'escudo universal'.
Dices 'memoria', quiero preguntarte: ¿es suficiente almacenar información para considerarlo memoria? ¿O es necesario formar un contexto útil a largo plazo?
Dices 'razonamiento', quiero preguntarte: ¿es suficiente dar una explicación para considerarlo razonamiento? ¿O es necesario mantener un estándar de juicio consistente en diferentes escenarios?
Dices 'automatización', quiero preguntarte: ¿es suficiente activar una acción para considerarlo automatización? ¿O es necesario evitar activaciones erróneas y movimientos erráticos bajo condiciones complejas?
Dices 'liquidación', quiero preguntarte: ¿es suficiente poder transferir fondos para considerarlo liquidación? ¿O es necesario que los resultados sean verificables, rastreables y conciliables?
Mira, cuando desglosas las cuatro palabras, todas son trampas.
¿Dónde están las trampas? En la brecha entre 'poder decir' y 'poder usar'.
@Vanarchain Para ganar, no se trata de hacer que estas cuatro palabras se vean más bonitas, sino de demostrar:
Haces que uno de esos huecos sea más profundo que los demás, más sólido que los demás, más fácil que los demás.
De lo contrario, solo estás vendiendo un 'paquete conceptual', no haciendo infraestructura.
III. Lo que más odio de las frases de marketing: 'captura de valor a largo plazo'.
Cada vez que veo 'captura de valor', quiero preguntar: ¿cuya valor has capturado? ¿Con qué lo has capturado? ¿Por qué puedes capturarlo?
El valor a largo plazo de la infraestructura no se escribe, se ejecuta.
Y para ejecutarlo se necesitan dos cosas:
Densidad de uso y dependencia de ruta.
Densidad de uso: cuántas interacciones reales ocurren aquí. No es 'muro de logotipos de socios', no es 'ecosistema 100+', es la llamada real, transacciones reales, retención real.
Dependencia de ruta: una vez que usas el tuyo, es complicado reemplazarlo. No es un secuestro, es un asentamiento de ingeniería razonable: cuanto más lo usas, más fluido es, cuanto más cambias, más doloroso es.
La pregunta es: ¿qué está ofreciendo Vanry ahora?
Si solo dices 'somos infraestructura de IA', eso para mí es solo una vacía declaración.
Porque cualquiera puede decirlo, lo verdaderamente difícil es hacer que otros quieran integrar el proceso central.
Evalúo si estos proyectos tienen valor a largo plazo, generalmente no miro la 'historia', sino tres señales:
1) ¿Hay un grupo de desarrolladores reutilizando el mismo conjunto de capacidades?
No todos los proyectos 'personalizan un conjunto', sino que todos realmente usan la misma estructura.
2) ¿Hay escenarios estables de alta frecuencia?
Por ejemplo, si cierto tipo de aplicación funciona bien, los usuarios la usan todos los días, no es un aumento temporal por evento.
3) ¿Se ha formado una 'opción por defecto'?
Cuando los desarrolladores mencionan una capacidad, piensan en ti primero, no en otras soluciones.
Si no hay ninguna de estas tres señales, entonces 'captura de valor a largo plazo' es solo PPT.
IV. Cadenas cruzadas, ecosistemas, Base... no consideres más esto como un 'factor adicional', para mí esto es solo 'operaciones básicas'.
Sé que a muchas personas les gusta contar 'cadenas cruzadas' como el clímax de la historia.
Pero en esta era, las cadenas cruzadas ya no son sorprendentes. Lo sorprendente es: ¿qué puedes hacer después de la cadena cruzada?
La cadena cruzada es esencialmente solo 'ir a más lugares'.
Si ir a más lugares es solo para decir 'cubrimos más', eso es expansión, no producto.
Lo que realmente tiene valor es: después de cruzar a un nuevo ecosistema, ¿es tu producto más fácil de usar, se usa con más frecuencia y genera mayor retención?
Así que mi opinión sobre la cadena cruzada de Vanry es muy simple:
No es un factor adicional, es un pase de entrada al examen.
Una vez dentro, debes puntuar por el tema. El tema es 'uso real'.
V. ¿Cuál es la 'ventana de oportunidad' que estoy dispuesto a darle a Vanry?
Aunque me quejo con dureza, no creo que Vanry no tenga oportunidades.
Solo me opongo al ritmo de 'primero hacer un dios y luego aterrizar'.
Si Vanry realmente quiere cambiar mi opinión, no necesita publicidad llamativa, solo necesita hacer tres cosas 'muy poco atractivas pero muy críticas':
1) Cuantificar el 'ahorro de trabajo'
No me digas 'más fácil de desarrollar'. Dame una comparación clara:
¿Cuántas semanas se necesitan para la integración de una función de IA similar antes de conectarse, y cuántos días se necesitan después de conectarse?
¿Cuánto se reduce el costo de mantenimiento en el mismo proceso?
Cuanto más ingenierizado lo hagas, más fácil será obtener estos datos. Si no puedes, dudaré que realmente hayas llegado a la fase de ingeniería.
2) Proporcionar un caso 'replicable'.
No quiero escuchar 'ciertos socios'. Quiero ver 'cómo otros te usan y que ellos también puedan hacerlo'.
La replicabilidad significa: que la documentación, herramientas, interfaces, andamios y mejores prácticas estén todos disponibles.
El valor de la infraestructura radica en 'ser replicada', no en 'ser entrevistada'.
3) Tratar el 'uso real' como KPI, no tratar la 'popularidad de la narrativa' como KPI.
Muchos proyectos mueren en la popularidad: la popularidad es demasiado grande, el uso no puede seguir el ritmo, y al final solo pueden cubrir el vacío con mayor popularidad.
La infraestructura es precisamente lo contrario: cuanto más sólida sea la utilización, más naturalmente seguirá la popularidad.
VI. Conclusión: ¿Por qué tengo una postura crítica hacia Vanry?
Porque he visto demasiados proyectos que 'parecen el futuro', pero al final son derrotados por 'nadie los usa a diario'.
La narrativa de la IA es especialmente peligrosa:
Es demasiado fácil apilar conceptos para crear un artículo que 'parezca correcto', y también es fácil pasar por alto una cosa: el producto no se escribe, se ejecuta.
Así que mi actitud hacia @Vanarchain es muy clara:
Quiero que hagas infraestructura de IA, no me opongo;
Si quieres que crea en el valor a largo plazo, solo miro los resultados;
Si quieres que pase de la duda al reconocimiento, es muy simple: presenta un flujo de uso replicable y datos comparables.
Finalmente, lanzo una pregunta para los comentarios (sinceramente):
¿Cuál crees que es el paso más propenso a fallar en los proyectos de infraestructura de IA?
