En cualquier libro o frase que uno vea,
lo del punto 3 siempre está escrito así,
pero en la práctica
¿por qué pregunta estas cosas?
¿por qué recién ahora lo menciona?
¿también pregunta este tipo de cosas?
el combo de 3 pasos y la posibilidad de que te perciban como un socio de baja calidad
que es un Computer-use Agent, y estoy de acuerdo con la mayor parte.
Este texto, más que dar tips prácticos, solo cubre un panorama general, así que si agregara algunos consejos más para cuando desarrollas un agentic/agent basado en LLM, al final los LLM están basados en transformers (i.e., razonamiento probabilístico; en vez de entender semánticamente el siguiente token/palabra con base en el token/state actual y el contexto, generan el output de forma probabilística), así que por muy bien que escribas el sys prompt, muchas veces no te dan la respuesta que quieres (e.g., les pides que respondan en formato JSON y a veces se les olvida un } o cosas así). Por eso, siempre es indispensable agregar varias fallback fn basadas en regex.
Y cuando escribes un sys prompt para que entregue structured output, normalmente conviene usar un non reasoning model, y mientras más largo sea el contexto, más seguido aparecen alucinaciones, así que más bien es mejor crear varios sys prompt y encadenarlos.
Si estás desarrollando un servicio, pueden ocurrir muchos errores, así que la clave es diseñar la arquitectura del servicio de forma modular y fault tolerant (e.g., hacer el supervisor agent async y los demás agent sync), sobre todo con estos sistemas agentic/agent donde el unexpected output ocurre con frecuencia.
Por eso, desde el principio conviene escribir el código respetando al máximo el SRP y de forma declarative; quiero decir que es mejor abordarlo de manera funcional (=sin side effects y con un flujo intuitivo).
Y dependiendo de si usas el LLM vía API o si vas a servir tú mismo el modelo, será diferente, pero si vas a servir directamente un SLM o LLM, es mejor no hacer model serving en el mismo servidor donde alojas el backend, y separar en otros servidores las tareas IO bound y las CPU bound tasks (i.e., tareas que requieren GPU, multiplicación de matrices, etc.), porque así queda mejor en términos de fault tolerance (e.g., hospedar las CPU bound task en Runpod).
Hay varios tips de desarrollo más, pero lo dejo hasta aquí para que no se haga demasiado largo.
Primero metieron traducciones automáticas horribles a las traducciones al coreano, y ahora ya evolucionaron. Como no pudieron ni frenar la traducción automática, ahora también nos van a hacer probar esa IA horrible.
Realmente odio las funciones de IA, especialmente esos servicios que se quedan esperando en segundo plano para "ayudarte".
Si se ejecutan de forma remota, está el problema de que se entregan mis datos; si se ejecutan localmente, está el problema de que consumen los recursos de mi computadora (CPU, memoria, batería, ...).
Es cierto jajaja
Parece como comparar un auto con un maratón..
jajaja, "haz que exista esa función"
¡Estoy totalmente de acuerdo contigo!
jajajaja
¿Desarrollo impulsado por alucinaciones... supongo?;;
> Parecía ideal para liderar, pero rechazó esos roles adicionales.
> Cuando el autor propone nuevos desafíos para el crecimiento...
Desde la perspectiva de un técnico, ¿no será que crecer es volverse aún mejor en lo que uno ya hace bien?
¡¡Muchas gracias por sus palabras!!
Quizás lo que se consideró fue que, en comparación con el aumento de responsabilidades y trabajo, el nivel salarial y las condiciones no han mejorado.
Eso es muy probable.
Por supuesto, si es un buen líder, escuchará amablemente
y resolverá el problema con precisión.
En cualquier libro o frase que uno vea,
lo del punto 3 siempre está escrito así,
pero en la práctica
¿por qué pregunta estas cosas?
¿por qué recién ahora lo menciona?
¿también pregunta este tipo de cosas?
el combo de 3 pasos y la posibilidad de que te perciban como un socio de baja calidad
Yo también actualmente estoy haciendo algo llamado UseDesktop
https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq
usedesktop.com
que es un Computer-use Agent, y estoy de acuerdo con la mayor parte.
Este texto, más que dar tips prácticos, solo cubre un panorama general, así que si agregara algunos consejos más para cuando desarrollas un agentic/agent basado en LLM, al final los LLM están basados en transformers (i.e., razonamiento probabilístico; en vez de entender semánticamente el siguiente token/palabra con base en el token/state actual y el contexto, generan el output de forma probabilística), así que por muy bien que escribas el sys prompt, muchas veces no te dan la respuesta que quieres (e.g., les pides que respondan en formato JSON y a veces se les olvida un
}o cosas así). Por eso, siempre es indispensable agregar varias fallback fn basadas en regex.Y cuando escribes un sys prompt para que entregue structured output, normalmente conviene usar un non reasoning model, y mientras más largo sea el contexto, más seguido aparecen alucinaciones, así que más bien es mejor crear varios sys prompt y encadenarlos.
Si estás desarrollando un servicio, pueden ocurrir muchos errores, así que la clave es diseñar la arquitectura del servicio de forma modular y fault tolerant (e.g., hacer el supervisor agent async y los demás agent sync), sobre todo con estos sistemas agentic/agent donde el unexpected output ocurre con frecuencia.
Por eso, desde el principio conviene escribir el código respetando al máximo el SRP y de forma declarative; quiero decir que es mejor abordarlo de manera funcional (=sin side effects y con un flujo intuitivo).
Y dependiendo de si usas el LLM vía API o si vas a servir tú mismo el modelo, será diferente, pero si vas a servir directamente un SLM o LLM, es mejor no hacer model serving en el mismo servidor donde alojas el backend, y separar en otros servidores las tareas IO bound y las CPU bound tasks (i.e., tareas que requieren GPU, multiplicación de matrices, etc.), porque así queda mejor en términos de fault tolerance (e.g., hospedar las CPU bound task en Runpod).
Hay varios tips de desarrollo más, pero lo dejo hasta aquí para que no se haga demasiado largo.
Ojalá le sirva a alguien.
¿Qué tal un servicio que se instale en un servidor remoto privado?
Primero metieron traducciones automáticas horribles a las traducciones al coreano, y ahora ya evolucionaron. Como no pudieron ni frenar la traducción automática, ahora también nos van a hacer probar esa IA horrible.
Bueno, lo de cgi pase, pero me sorprende la reacción sobre jsp jaja
¿jsp ya se convirtió en una reliquia tan antigua?
Realmente odio las funciones de IA, especialmente esos servicios que se quedan esperando en segundo plano para "ayudarte".
Si se ejecutan de forma remota, está el problema de que se entregan mis datos; si se ejecutan localmente, está el problema de que consumen los recursos de mi computadora (CPU, memoria, batería, ...).
Parece que será una buena referencia.
Es un desarrollador de origen ruso; pasó de Yandex a Riot y ahora se cambió a JPMorganChase.
jajajajaja, está demasiado gracioso
Parece mucho que solo le cambiaron el nombre.