📰 Informe Diario de YouTube

Qué dice

un agente que encadena varios pasos (ej. buscar → elegir fuentes → escribir) produce salidas insatisfactorias en algunos casos, pero hay muchos componentes que pudieron haber causado el problema, y cada uno tiene su propio costo de arreglo. Elegir cuál trabajar "por instinto" lleva, según Ng, a "meses de trabajo con muy poco progreso" cuando la corazonada estaba mal.

Qué dice

uno de los mayores diferenciadores entre desarrolladores eficientes y no tanto es tener buena intuición sobre qué tan capaz es cada modelo para cada tipo de tarea. Lo ilustra con una demo de redacción de PII (información personal identificable): un modelo chico (Llama 3.1 8B) sigue mal la instrucción de redactar (se saltea nombres, deja partes de la dirección sin redactar), mientras que un modelo frontera más grande la sigue completa y correctamente — la diferencia no es "sabe más hechos", es qué tan bien SIGUE instrucciones. Dos hábitos concretos que recomienda para entrenar esa intuición: (1)

Matices y límites

es un hábito continuo, no un chequeo único al elegir modelo para un proyecto — la intuición se desactualiza con cada nueva generación de modelos, así que el hábito de "probar cada release" es lo que la mantiene vigente.

Solidez

experiencia-repetida

Qué dice

es "difícil saber de antemano dónde va a funcionar y dónde no" un workflow agéntico, así que el consejo que da (y que sigue él mismo) es construir incluso una versión rápida y descuidada ("quick and dirty") para poder mirarla en acción y recién ahí enfocar el esfuerzo. Lo contrasta explícito con la alternativa de "quedarse semanas teorizando e hipotetizando cómo construirlo" — prefiere construir algo rápido, de forma razonablemente segura y responsable (sin filtrar datos), y usar ese primer prototipo para

Matices y límites

no es "no evalúes nunca" — es una secuencia: prototipo rápido y responsable → mirar la salida a ojo → recién ahí decidir qué merece un eval formal. El propio Ng aclara que sigue usando este ciclo de forma repetida en su trabajo, no como paso único al arrancar un proyecto.

Solidez

experiencia-repetida

Qué dice

presenta cuatro patrones de diseño como el vocabulario base para combinar los "bloques" (LLMs, tools, memoria) en workflows más complejos: 1.

Matices y límites

son patrones combinables, no mutuamente excluyentes — un sistema real típicamente usa varios a la vez (ej. un agente con tools que también hace reflection sobre su propia salida). Planning y multi-agente son, según el propio Ng, más experimentales y menos adoptados fuera de sistemas de codificación altamente agénticos.

Solidez

dato-medido

Qué dice

propone un framework de dos ejes para clasificar cualquier eval de un sistema agéntico. Eje 1 —

Matices y límites

el eje "código vs. LLM-juez" no es una jerarquía de calidad — código es más barato y determinístico cuando aplica, LLM-juez existe justamente para lo que código no puede capturar (muchas formas válidas de decir lo mismo). Elegir LLM-juez cuando el criterio SÍ es objetivo es desperdicio, no rigor.

Solidez

dato-medido

Qué dice

un workflow agéntico tiene muchos pasos (generar términos de búsqueda, elegir qué páginas bajar, escribir el ensayo, etc.) y

Matices y límites

requiere primero tener casos fallidos reales para leer (viene después de [[construir-rapido-y-sucio-antes-de-invertir-en-evaluar]], no antes) — no se puede hacer error analysis sobre un sistema que todavía no corrió sobre inputs reales.

Solidez

experiencia-repetida

Qué dice

el consejo explícito para equipos construyendo workflows agénticos es enfocarse primero en que la SALIDA sea de suficiente calidad, y recién optimizar costo y latencia después, cuando el sistema "ya está funcionando bien". No dice que costo/latencia no importen — cuenta que a su equipo le pasó varias veces que un sistema shippeado con éxito atrajo tantos usuarios que el costo se volvió un problema real y tuvieron que "scramble to bring the cost back down" — pero lo describe como "un buen problema para tener". Cuando sí llega el momento de optimizar, el método es el mismo que error analysis:

Matices y límites

el propio ejemplo de Ng muestra que esto no es "ignorar costo indefinidamente" — en cuanto el volumen de usuarios lo vuelve un problema real, pasa a ser prioridad inmediata. Es un orden de secuencia, no una jerarquía de importancia permanente.

Solidez

experiencia-repetida

Qué dice

dentro del patrón "multi-agente", identifica cuatro formas concretas de hacer que los agentes se comuniquen entre sí, de más a menos controlable: 1.

Matices y límites

más control (lineal) generalmente significa menos flexibilidad para casos que no encajan en la secuencia fija; menos control (todos-con-todos) da más adaptabilidad pero resultados menos predecibles — es una elección explícita de trade-off, no una jerarquía de "mejor patrón".

Solidez

dato-medido