Es realmente muy interesante, pero da un poco de miedo pensar que esto no lo hizo ni el gobierno ni una empresa como Google.
Siento que el mundo está desbordado de datos.
"El CTO de Amplitude, Wade Chambers, mostró de forma piloto a algunos colegas una herramienta de IA creada internamente"
Tal como el artículo de Naver mencionado en la presentación del Sr. Ha Yong-ho, parece que la transformación con IA también necesita voluntad u objetivos desde el nivel C para difundirse bien en toda la empresa.
Si se trata de líderes organizacionales con una comprensión profunda y visión, ok, pero en la parte de andar jugando con los números por temas de costos, ¿líderes atrapados en la idea de que la IA sirve para todo??? Se escucha cómo están exprimiendo a la gente ;_;
¡Oh, yo también hice algo parecido!
Es un servicio que traduce y resume con IA las publicaciones de Hacker News al coreano y las envía a un canal de Telegram.
Si hubiera sabido que existía algo así, no lo habría hecho.. jaja. ¡Me suscribí!
Dicen que si implementas IA la productividad se duplica, pero también te duplican el trabajo... el sueldo sigue igual y ni siquiera te cubren el costo de la IA...
Sí, muchas gracias por sus buenos comentarios. Tal como mencionó, no es adecuado para casos de uso de RDB y puede entenderse como una posición de motor de búsqueda (Elasticsearch), vectorDB (Pinecone). Internamente también utilizamos Lucene, que ha sido comprobado durante mucho tiempo, para admitir funcionalidades como indexación, ordenación y agregación. ¡Gracias! :)
Como usted dijo, más que una base de datos universal, parece que sería una solución que podría utilizarse como "verdadero" serverless en situaciones específicas.
¡No esperaba que fuera a contestar en coreano! (¡Lo escribí demasiado cínico...)
Al principio pensé que era una idea revolucionaria. De hecho, el mayor problema de las DB serverless era que había un servidor real funcionando en un lugar donde eso no se veía. Cuando el tráfico se concentra, se produce una situación de caída hasta que se asigna ese servidor (más o menos 5 minutos). Por eso, las DB serverless existentes en la nube (AWS, etc.) son difíciles de usar a nivel de producción.
Quise probarlo. Pero la razón de mis dudas era que, si lo hacíamos, habría que implementar lógicas binarias de indexación, ordenamiento y demás como las que ya existen en mysql, postgresql; me pregunté qué tan difícil sería rehacer sobre Lambda un proyecto de DB de código abierto confiable. Así fue.
Como es un producto que ustedes están construyendo, espero muchos avances! ¡Muy buenas expectativas!
Muchas gracias por sus buenos comentarios. El punto que mencionó sobre que se necesita state para reducir la latencia acierta exactamente el trade-off central de nuestra arquitectura.
En primer lugar, con respecto a la latencia de consulta, en nuestros benchmarks el p99 (percentil 99) está alrededor de 130-210 ms. Supongo que cuando comentó que la diferencia era de 100 veces, probablemente se refería al peor caso mencionado en el texto: que durante un cold start puede tardar unos segundos. Como bien señaló, esta parte es claramente una desventaja de nuestra arquitectura, y como se indica en el texto, sucede en producción en menos del 0.01% (P99.99). En la mayoría del resto de consultas, el diseño aprovecha la memoria local y el disco de cada Lambda como caché para ofrecer un rendimiento estable.
Por ello, como usted indicó, puede que esta arquitectura no sea adecuada para sistemas de transacciones financieras de latencia ultrabaja, donde se deba garantizar que todas las consultas sean inferiores a 10 ms. Sin embargo, en la mayoría de las aplicaciones de búsqueda y recomendación basadas en IA, una latencia de 100-200 ms en P99 se considera un rendimiento suficientemente bueno, y creo que la ventaja de reducir en más de un 90% los costos de infraestructura y la carga operativa es mucho mayor.
Es irónico que un sitio web que no le da la bienvenida a los LLM tenga un resumen hecho por un LLM.
Parece que haría falta introducir una opción para configurar el MBTI del modelo de IA.
Es realmente muy interesante, pero da un poco de miedo pensar que esto no lo hizo ni el gobierno ni una empresa como Google.
Siento que el mundo está desbordado de datos.
Como el código está publicado, creo que te será útil revisarlo.
"El CTO de Amplitude, Wade Chambers, mostró de forma piloto a algunos colegas una herramienta de IA creada internamente"
Tal como el artículo de Naver mencionado en la presentación del Sr. Ha Yong-ho, parece que la transformación con IA también necesita voluntad u objetivos desde el nivel C para difundirse bien en toda la empresa.
Si se trata de líderes organizacionales con una comprensión profunda y visión, ok, pero en la parte de andar jugando con los números por temas de costos, ¿líderes atrapados en la idea de que la IA sirve para todo??? Se escucha cómo están exprimiendo a la gente ;_;
Parece que en la primera línea del texto hay un enlace a una imagen, ordenado de forma fácil de ver de un vistazo.
No me identifica mucho, porque me parece que es un truco que solo funciona en circunstancias muy específicas.
¡Oh, yo también hice algo parecido!
Es un servicio que traduce y resume con IA las publicaciones de Hacker News al coreano y las envía a un canal de Telegram.
Si hubiera sabido que existía algo así, no lo habría hecho.. jaja. ¡Me suscribí!
https://t.me/hnaisummarykr
¿Alguien sabe de qué trata esto?
Tengo curiosidad por saber cómo verificaron el funcionamiento local.
Lo mismo en los comentarios de Hacker News, y en el foro LocalLLaMA de Reddit también dicen que GLM está bastante bien
GLM 4.5 AIR IS SO FKING GOODDD
Ay...
Dicen que si implementas IA la productividad se duplica, pero también te duplican el trabajo... el sueldo sigue igual y ni siquiera te cubren el costo de la IA...
Sí, muchas gracias por sus buenos comentarios. Tal como mencionó, no es adecuado para casos de uso de RDB y puede entenderse como una posición de motor de búsqueda (Elasticsearch), vectorDB (Pinecone). Internamente también utilizamos Lucene, que ha sido comprobado durante mucho tiempo, para admitir funcionalidades como indexación, ordenación y agregación. ¡Gracias! :)
Como usted dijo, más que una base de datos universal, parece que sería una solución que podría utilizarse como "verdadero" serverless en situaciones específicas.
¡No esperaba que fuera a contestar en coreano! (¡Lo escribí demasiado cínico...)
Al principio pensé que era una idea revolucionaria. De hecho, el mayor problema de las DB serverless era que había un servidor real funcionando en un lugar donde eso no se veía. Cuando el tráfico se concentra, se produce una situación de caída hasta que se asigna ese servidor (más o menos 5 minutos). Por eso, las DB serverless existentes en la nube (AWS, etc.) son difíciles de usar a nivel de producción.
Quise probarlo. Pero la razón de mis dudas era que, si lo hacíamos, habría que implementar lógicas binarias de indexación, ordenamiento y demás como las que ya existen en mysql, postgresql; me pregunté qué tan difícil sería rehacer sobre Lambda un proyecto de DB de código abierto confiable. Así fue.
Como es un producto que ustedes están construyendo, espero muchos avances! ¡Muy buenas expectativas!
Gracias, seguro que será de mucha ayuda ✌️
Al principio lo armé con n8n, pero luego me cambié a AWS Lambda + @ 🙇♂️
Así lo estoy administrando jaja
Les recomiendo intentar hacer uno, es divertido 👍
Muchas gracias por sus buenos comentarios. El punto que mencionó sobre que se necesita
statepara reducir la latencia acierta exactamente el trade-off central de nuestra arquitectura.En primer lugar, con respecto a la latencia de consulta, en nuestros benchmarks el p99 (percentil 99) está alrededor de 130-210 ms. Supongo que cuando comentó que la diferencia era de 100 veces, probablemente se refería al peor caso mencionado en el texto: que durante un cold start puede tardar unos segundos. Como bien señaló, esta parte es claramente una desventaja de nuestra arquitectura, y como se indica en el texto, sucede en producción en menos del 0.01% (P99.99). En la mayoría del resto de consultas, el diseño aprovecha la memoria local y el disco de cada Lambda como caché para ofrecer un rendimiento estable.
Por ello, como usted indicó, puede que esta arquitectura no sea adecuada para sistemas de transacciones financieras de latencia ultrabaja, donde se deba garantizar que todas las consultas sean inferiores a 10 ms. Sin embargo, en la mayoría de las aplicaciones de búsqueda y recomendación basadas en IA, una latencia de 100-200 ms en P99 se considera un rendimiento suficientemente bueno, y creo que la ventaja de reducir en más de un 90% los costos de infraestructura y la carga operativa es mucho mayor.
Gracias de nuevo por su comentario tan detallado.