Rails es conveniente porque impone convenciones y hace mucha magia bajo la capa de abstracción, aunque existe el trade-off de un rendimiento menor; pero eso no es un gasto inmediato.
En cambio, si el framework elige el modelo como se le da la gana, ¿quién se hace responsable cuando te explota el uso de tokens?
Mi opinión es que, sin importar el tamaño, el riesgo no puede ser reemplazado por la IA. Da igual si se trata de un empleado o del CEO. Si reemplazas con IA a un empleado que está asumiendo un riesgo, otra persona tendrá que cargar con ese riesgo. Con el CEO pasa exactamente lo mismo. Si lo reemplazas con IA, otra persona tendrá que asumir ese riesgo. Y al final, esa persona terminará cumpliendo el rol de CEO.
Yo creo que solo los “humanos” asumen el riesgo.
Pero que se diga que esto puede reemplazarse con IA, e incluso que se reemplace a la persona cuyo principal propósito de existencia como CEO es tomar “decisiones con un riesgo muy alto”, es lo que me hace dudar. No estoy diciendo que el CEO sea irremplazable y los empleados sí puedan ser reemplazados.
Sin embargo, creo que en un futuro cercano la tecnología podrá incluso distribuir/controlar/cubrir ese riesgo. Y hacia ahí ha avanzado siempre la tecnología.
El método de entrada en coreano era tan incómodo que me parecía inutilizable; ¿hoy en día ha mejorado mucho? Problemas como que en Chrome se coman lo que escribes o se borre la última letra eran bastante graves.
Así era como trabajaba con código de depuración cuando estaba en una empresa de videojuegos hace 25 años, y no era solo strcpy. En la versión de lanzamiento se volvía a desactivar para el servicio por la mejora de velocidad. De hecho, en el área de juegos los choques de memoria son de lo más sensible, así que trabajábamos con muchísimo cuidado y atención, e incluso creamos y usamos nuestro propio depurador de memoria. Pero al verlo hoy en día, resulta que eso estaba haciendo recolección de basura. Qué recuerdos tan nostálgicos.
Oh, muy buen artículo. Mencionaste que deciden si realizar validación adicional en función de la confiabilidad; también me da curiosidad cómo se medía exactamente ese valor de confiabilidad.
Parece un texto que resolvió muy bien el problema usando VLM; me pareció interesante.
Hay una duda que me surgió al leerlo:
Detección con YOLO: recortar solo el objeto principal para reducir el rango de análisis
Me da curiosidad cómo incorporaron este proceso.
Mientras leía, pensé que el VLM probablemente tendría mejor rendimiento que YOLO, así que al recortar quizá podría darse el problema de que el modelo YOLO juzgue mal y se pierda información importante antes siquiera de pasársela al VLM.
Me gustaría saber a partir de qué problema se les ocurrió usar el recorte, y cómo validaron la precisión antes de incorporarlo.
En algunos MCU de gama alta, como menciona, es posible configurar por región no solo los permisos de acceso sino también los atributos relacionados con la caché mediante la MPU. El siguiente material de ST será una buena referencia: https://community.st.com/t5/stm32-mcus/…
Sin embargo, en el ESP32-S3 usado en este artículo no se ofrece un método para configurar atributos de memoria cacheable / non-cacheable por región mediante la MPU o un mecanismo similar, como sí ocurre en CPU de propósito general o en algunos MCU.
En el caso del ESP32-S3, la memoria externa (Flash/PSRAM) está diseñada para ser accedida a través de la caché/MMU (TRM 4.3.3 External Memory), y el control de permisos de acceso se realiza mediante el PMS (Permission Management System) (TRM Chapter 15), pero este mecanismo está pensado para la protección de acceso y no para cambiar si pasa por caché o la ruta de acceso en sí.
Error C4996: "strcpy": esta función o variable puede no ser segura. Considere usar strcpy_s en su lugar. Para deshabilitar la advertencia de obsolescencia, use _CRT_SECURE_NO_WARNINGS. Consulte la ayuda en línea para más detalles.
Puede que tenga una gran influencia y, en consecuencia, reciba una compensación elevada, pero eso no puede equipararse automáticamente con ser la única persona en la empresa que asume un riesgo activo. Dependiendo de si quien lo nombró es o no el accionista mayoritario, con más razón aún no lo es.
Siguiendo la misma lógica, un empleado tendría una influencia pequeña, por lo que asumiría una responsabilidad menor y recibiría un salario más bajo, pero aun así sería también un trabajador que asume una responsabilidad activa, y tampoco hay razón para que el CEO no pueda ser reemplazado por IA.
¿No era ese justamente el argumento que dejó en su comentario inicial, que el CEO es la única persona que carga con un riesgo activo y por eso no puede ser reemplazado por IA?
Hoy en día, muchos de los problemas de Wayland también han desaparecido.
¿No aparecerá alguna herramienta nueva en 2026? Será distinta a Rails, pero más abstracta... Tengo expectativas.
De algún modo, de pronto me hace pensar en Aaron Swartz, cofundador de Reddit. Sin duda habría sido un cambio que él habría deseado profundamente..
Los frameworks de agentes... el nombre suena grandioso, pero al final no son más que herramientas que se lo pasan al LLM. Están vacíos por dentro.
Lo correcto es usar
snprintfen lugar destrcpy. Si haystrcpyen el código, hay que averiguar dónde vive el desarrollador que lo hizo.Rails es conveniente porque impone convenciones y hace mucha magia bajo la capa de abstracción, aunque existe el trade-off de un rendimiento menor; pero eso no es un gasto inmediato.
En cambio, si el framework elige el modelo como se le da la gana, ¿quién se hace responsable cuando te explota el uso de tokens?
Mi opinión es que, sin importar el tamaño, el riesgo no puede ser reemplazado por la IA. Da igual si se trata de un empleado o del CEO. Si reemplazas con IA a un empleado que está asumiendo un riesgo, otra persona tendrá que cargar con ese riesgo. Con el CEO pasa exactamente lo mismo. Si lo reemplazas con IA, otra persona tendrá que asumir ese riesgo. Y al final, esa persona terminará cumpliendo el rol de CEO.
Yo creo que solo los “humanos” asumen el riesgo.
Pero que se diga que esto puede reemplazarse con IA, e incluso que se reemplace a la persona cuyo principal propósito de existencia como CEO es tomar “decisiones con un riesgo muy alto”, es lo que me hace dudar. No estoy diciendo que el CEO sea irremplazable y los empleados sí puedan ser reemplazados.
Sin embargo, creo que en un futuro cercano la tecnología podrá incluso distribuir/controlar/cubrir ese riesgo. Y hacia ahí ha avanzado siempre la tecnología.
Recomiendo el método de entrada kime
El método de entrada en coreano era tan incómodo que me parecía inutilizable; ¿hoy en día ha mejorado mucho? Problemas como que en Chrome se coman lo que escribes o se borre la última letra eran bastante graves.
Es una observación aguda. La tasa de error de los humanos es aún mayor...
Así era como trabajaba con código de depuración cuando estaba en una empresa de videojuegos hace 25 años, y no era solo
strcpy. En la versión de lanzamiento se volvía a desactivar para el servicio por la mejora de velocidad. De hecho, en el área de juegos los choques de memoria son de lo más sensible, así que trabajábamos con muchísimo cuidado y atención, e incluso creamos y usamos nuestro propio depurador de memoria. Pero al verlo hoy en día, resulta que eso estaba haciendo recolección de basura. Qué recuerdos tan nostálgicos.Oh, muy buen artículo. Mencionaste que deciden si realizar validación adicional en función de la confiabilidad; también me da curiosidad cómo se medía exactamente ese valor de confiabilidad.
Como referencia, el modelo gpt-4o-mini tiene un costo excesivamente alto en tokens de entrada al usar imágenes, así que les recomendaría considerar también otros modelos ligeros.
Parece un texto que resolvió muy bien el problema usando VLM; me pareció interesante.
Hay una duda que me surgió al leerlo:
Me da curiosidad cómo incorporaron este proceso.
Mientras leía, pensé que el VLM probablemente tendría mejor rendimiento que YOLO, así que al recortar quizá podría darse el problema de que el modelo YOLO juzgue mal y se pierda información importante antes siquiera de pasársela al VLM.
Me gustaría saber a partir de qué problema se les ocurrió usar el recorte, y cómo validaron la precisión antes de incorporarlo.
Oh, se ve bien. ¡Ojalá lo porten a varios lenguajes!
Más que resolverlo al convertirlo en un problema estructural, me parece que lo que hicieron fue crear un modelo nuevo.
En algunos MCU de gama alta, como menciona, es posible configurar por región no solo los permisos de acceso sino también los atributos relacionados con la caché mediante la MPU. El siguiente material de ST será una buena referencia: https://community.st.com/t5/stm32-mcus/…
Sin embargo, en el ESP32-S3 usado en este artículo no se ofrece un método para configurar atributos de memoria
cacheable/non-cacheablepor región mediante la MPU o un mecanismo similar, como sí ocurre en CPU de propósito general o en algunos MCU.En el caso del ESP32-S3, la memoria externa (Flash/PSRAM) está diseñada para ser accedida a través de la caché/MMU (TRM 4.3.3 External Memory), y el control de permisos de acceso se realiza mediante el PMS (Permission Management System) (TRM Chapter 15), pero este mecanismo está pensado para la protección de acceso y no para cambiar si pasa por caché o la ruta de acceso en sí.
Enlace al TRM (Technical Reference Manual): https://documentation.espressif.com/esp32-s3_technical_reference_manua….
Error C4996: "strcpy": esta función o variable puede no ser segura. Considere usar
strcpy_sen su lugar. Para deshabilitar la advertencia de obsolescencia, use_CRT_SECURE_NO_WARNINGS. Consulte la ayuda en línea para más detalles.No hay MMU, pero sí se pueden definir regiones de memoria y sus atributos con el MPU.
Creo que valdría la pena revisarlo.
Puede que tenga una gran influencia y, en consecuencia, reciba una compensación elevada, pero eso no puede equipararse automáticamente con ser la única persona en la empresa que asume un riesgo activo. Dependiendo de si quien lo nombró es o no el accionista mayoritario, con más razón aún no lo es.
Siguiendo la misma lógica, un empleado tendría una influencia pequeña, por lo que asumiría una responsabilidad menor y recibiría un salario más bajo, pero aun así sería también un trabajador que asume una responsabilidad activa, y tampoco hay razón para que el CEO no pueda ser reemplazado por IA.
¿No era ese justamente el argumento que dejó en su comentario inicial, que el CEO es la única persona que carga con un riesgo activo y por eso no puede ser reemplazado por IA?
No parece que sirva de mucho..