Los LLM dañan los documentos al delegarles tareas

• DELEGATE-52 es un benchmark que evalúa qué tan fielmente se conserva un documento en flujos de trabajo de delegación donde el usuario encarga a un LLM tareas de edición de documentos largos
• Este benchmark cubre tareas que requieren edición profunda de documentos en 52 dominios especializados, como programación, cristalografía y notación musical; la simulación de ejemplo consiste en delegar 20 tareas consecutivas
• En experimentos con 19 LLM, incluso modelos de frontera como Gemini 3.1 Pro, Claude 4.6 Opus y GPT 5.4 dañan en promedio 25% del contenido del documento al final de flujos de trabajo largos
• El daño al documento aparece como errores poco frecuentes pero graves; la degradación aumenta con el tamaño del documento, la longitud de la interacción y la cantidad de archivos distractores, y el uso de herramientas tipo agente tampoco mejora el desempeño
• En su estado actual, es difícil considerar a los LLM como delegados confiables para la edición de documentos; microsoft/DELEGATE52 y datasets/microsoft/DELEGATE52 se publican como recursos relacionados con DELEGATE-52

---

Patrones de falla en la edición delegada

• El trabajo delegado parte de la confianza en que el usuario asigna la tarea al LLM y que este la ejecutará sin introducir errores en el documento
• En experimentos a gran escala con 19 LLM, los modelos actuales degradan los documentos durante el proceso de delegación
• Otros modelos fallan de forma más grave que los modelos de frontera
• El daño al documento se acumula durante interacciones largas y termina deteriorándolo silenciosamente

Cambios en los documentos mostrados como ejemplo

• En el dominio de Graph Diagrams, el documento Linux Kernel Architecture con Gemini 3.1 Pro aparece en 79% respecto al original después de 4 rondas, 49% después de 10, 48% después de 14 y 48% después de 20
• En el dominio de Textile Patterns, el documento 12-Shaft Twill Diamond con Claude 4.6 Opus aparece en 100% respecto al original después de 4 rondas, 40% después de 10, 27% después de 14 y 34% después de 20
• En el dominio de 3D Objects, el documento ActionBoy Palm Tree con GPT-5.2 aparece en 100% respecto al original después de 4 rondas, 31% después de 10, 15% después de 14 y 6% después de 20

Recursos publicados

• microsoft/DELEGATE52
• datasets/microsoft/DELEGATE52

[GN⁺]

Opiniones en Hacker News

• Tengo dudas sobre los resultados del uso de herramientas

  No sorprende que el contenido largo se degrade si se hace pasar de ida y vuelta por un LLM. Quienes usan LLM con frecuencia ya saben que no hay que hacerlo así.

  Me sorprendió que el paper dijera que el uso de herramientas no ayudó, pero al mismo tiempo aclara que implementaron un “agent harness básico” y que no era un sistema moderno optimizado.

  En la práctica, el harness solo tiene read_file() y write_file(), así que se parece más a agregar una etapa extra al proceso de ida y vuelta. Hoy en día, los harness de agentes de programación ponen mucho esfuerzo en el diseño de herramientas de edición de archivos; por ejemplo, está el conjunto de herramientas de edición de Claude: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

  Los comandos str_replace e insert son clave para evitar ediciones riesgosas que reescriben el archivo completo.

  Al menos sí ofrecen una herramienta run_python(), así que es posible que modelos mejores la hayan usado para ejecutar reemplazos de cadenas. Me gustaría ver si el prompt del sistema fomentaba manipulaciones basadas en Python o si empujaba a leer y volver a escribir el archivo.

  Encontré el código del harness aquí: https://github.com/microsoft/delegate52/blob/main/model_agen...

  El fragmento relevante del prompt dice algo como: “puedes abordarlo de la forma que consideres más efectiva, ya sea de manera programática o escribiendo directamente en el archivo”.

  Como suele pasar con este tipo de papers, los resultados reflejan más el diseño del harness usado por los autores que al modelo en sí. Ya sea un ingeniero de IA con experiencia o un prompt engineer, creo que iterando sobre el harness mismo se podrían lograr mejores resultados en esta prueba.

  • Coincido en casi todo, salvo en la parte de “quienes usan LLM con frecuencia ya saben que no hay que hacerlo así”.

    Ahora mismo, con la adopción de LLM empujándose en organizaciones y equipos enteros, hay mucha gente —quizá la mayoría— que usa LLM todos los días pero nunca ha tocado nada técnico como un harness.

    Para esa gente, el comportamiento del que se habla aquí sí es un problema serio.

  • Es un comentario algo relacionado, pero me gustaría ver un harness que use ed como herramienta base para editar/leer archivos. La mitad de los bash que ejecuta Claude ya parecen sed de todos modos, y si ed conservara estado, podría ayudar.

    ¿Qué haces cuando un editor completo consume demasiado ancho de banda^H tokens? Usas el editor estándar: ed.

  • Esto se parece más a un caso donde se construye un hombre de paja del trabajo con LLM.

    En tareas de edición solo deberían permitirse comandos de edición programáticos, y el texto no debería pasar por el LLM. El LLM debería analizar el texto y, según la retroalimentación, emitir comandos para alcanzar el objetivo.

  • En HN hay una tendencia a interpretar los resultados de la forma más negativa posible, porque se sienten como una amenaza a su trabajo y su identidad.

    En realidad, si una persona leyera un documento y luego lo volviera a decir completo para incorporar cambios, probablemente obtendría resultados peores que una degradación de 25%. Aunque una persona sí puede lograr 0% de degradación, eso solo pasa si recibe el documento cientos de veces hasta memorizarlo. El equivalente en un LLM sería el entrenamiento, y si entrenas al LLM con el documento, en este caso podría equipararse a la edición de una persona que lo memorizó.

    Pero ese no es el punto central. Los LLM se parecen a las personas en esto, así que el harness debería diseñarse para que editen como lo hace una persona: con búsqueda y modificaciones quirúrgicas. Todos los agentes de código editan así, por lo que este paper no es muy relevante.

  • Ya sea por restricciones de recursos o por simplificación, este tipo de papers tristemente pierde valor por metodologías difíciles de entender.

• Como he dicho desde hace tiempo, si maquillas con IA cualquier texto, la calidad baja, y si lo repites, el efecto se acumula.

  El nombre que más me gusta para esto es “ablación semántica”: https://www.theregister.com/software/2026/02/16/semantic-abl...

  • Yo lo he llamado regresión hacia la inteligencia promedio.
  • Me pregunto si “si lo repites” significa repetirlo dentro de la misma sesión, o hacerlo cada vez en una sesión nueva o una nueva ventana de contexto.

• La idea es que “delegar requiere confianza. Tiene que existir la expectativa de que el LLM hará el trabajo fielmente sin meter errores en el documento”, y justo por eso no funcionan como prometen los harness con decenas de archivos Markdown y rituales de prompts. En esencia, eso se acerca mucho a una pseudociencia llamada ingeniería de agentes.

  La ingeniería de agentes al final es casi lo mismo que la supuesta prompt engineering, solo que ahora los prompts están repartidos en decenas de archivos Markdown y directorios.

• De lo menos sorprendente que he leído últimamente sobre LLM.

  Los LLM se parecen al meme del JPEG. Funcionan como cuando guardas algo una y otra vez en JPEG: la calidad baja un poco cada vez, hasta que al final ya no se reconoce.

  Solo que en los LLM el punto de partida es la intención. Cada vez que pasas algo por un LLM, la intención se degrada, y en algo como un paper científico preciso, al reformularlo se pierden poco a poco matices y precisión.

  Los LLM son máquinas de regresión al promedio. Cuanto más se sale el contexto o la carga de trabajo actual del rango de entrenamiento, más tienden a arrastrarlo hacia un estado de equilibrio abstracto y homogéneo.

  • Sin duda lo he vivido programando con LLM. Después de avanzar rápido en una tanda de trabajo de funcionalidades, aunque sentía que había sido bastante cuidadoso, luego al revisar detalladamente pequeños fragmentos de código muchas veces llega el momento de “Dios mío”.

    Después toca pasar horas revisando todo otra vez y corrigiendo con cuidado las partes que no quedaron como quería, las partes donde yo fui ambiguo y las partes donde se activaron rarezas del LLM.

    La calidad del código en sí importa, pero me preocupa justo este problema de compresión iterativa. Si el codebase está limpio y mi modelo mental está actualizado, un LLM puede ayudarme a avanzar rápido en funcionalidades y aun así dejar el codebase en un estado razonable. Pero si el LLM empieza a ensuciar el codebase, los errores o malentendidos pasados se acumulan, y cada vez es más probable que se equivoque en más cosas. Por eso necesito “restaurarlo” a un estado correcto antes de volver a usar el LLM con tranquilidad.

  • Donde este resultado sí es realmente interesante y relevante es cuando un agente de código divide archivos fuente grandes en varios archivos pequeños. Opus y Claude Code, en lugar de usar operaciones tipo copiar/pegar como haría una persona, intentan recitar de memoria tramos largos de código fuente para ponerlos en archivos nuevos.

    Mover archivos es un poco más fácil. A veces el LLM intenta volver a decir el archivo desde memoria, pero si le indicas que use git mv y arregle los errores del compilador, por lo general lo hace bien.

    En cambio, la edición normal suele funcionar bien si tienes una configuración razonable de modelo y herramientas. Incluso Qwen3.6 27B aguanta esto. Para cambios in situ, además puedes revisar modificaciones inesperadas con git diff.

  • Hay hasta un juego infantil que muestra esto: https://en.wikipedia.org/wiki/Telephone_game

  • Un colega describe a los LLM como una “capa de tonterías”. No lo dice como un insulto total, sino para enfatizar que cada vez que pasas algo por un LLM, lo que sale del otro lado puede no coincidir con lo que esperabas o querías.

    Es como si alguien medio tomado en un bar te contara información en línea que dice haber visto por ahí. Puede ser correcta, pero también hay un riesgo considerable de que no lo sea.

    Por ejemplo, no deberías usar un LLM para llamar APIs, recopilar datos y producir un informe. Eso significa pasar datos críticos por una capa de tonterías, así que no puedes confiar en el resultado. En cambio, es mejor usar el LLM para escribir código que produzca salidas determinísticas a partir de datos determinísticos.

    He visto colegas hacer que un LLM resuma datos determinísticos que venían de una API, y el informe podía estar tan equivocado como acertado. Dependiendo de qué estés viendo, eso puede ser un riesgo desastroso.

  • Me pasó al editar mi currículum. El LLM eliminó todo lo que diferenciaba mi CV de un montón de ingenieros junior promedio con experiencia promedio. Todo lo especial, único o distinto terminó reemplazado por frases genéricas.

    Claro que no usé ese resultado, pero fue realmente frustrante que el LLM insistiera una y otra vez en que era mejor que la versión original.

    Me resultó mucho más útil usar LLM para sugerencias sobre fragmentos muy pequeños, como corregir una sola oración o quizá tres.

• El problema es que le estamos pidiendo demasiado a los LLM. Los agentes deberían diseñarse para usar el LLM como una capa lo más delgada posible que traduzca intención en lenguaje natural a un proceso determinístico, y minimizar al máximo los viajes de ida y vuelta con el LLM.

  • Eso se vuelve evidente para cualquiera que intente hacer algo apenas un poco complejo. Si construyes un pipeline que combine flujo de preprocesamiento, selección semántica de objetivos y llamadas mínimas de contexto con la API del LLM, puedes obtener una etapa de automatización muy potente.

    Si además lo combinas con una fase de validación separada, el LLM deja de ser un juguete y se vuelve una herramienta útil.

  • Si una persona sigue metida en ese nivel de proceso iterativo, entonces todavía no es un proceso automatizado.

• Normalmente les indico a los agentes que traten la redacción de documentos solo como la etapa final de renderizado. Los LLM son muy buenos para reunir conocimiento disperso y entretejerlo, así que prefiero almacenar el conocimiento en forma de ideas y hechos combinables.

  Un enfoque que de verdad me ha funcionado es darle al agente un directorio y pedirle que cree un archivo Markdown independiente por cada hecho o hallazgo encontrado. A cada archivo le hago poner metadatos al inicio para que sea fácil de buscar.

  Así, la mayor parte del trabajo deja de ser una mezcla enredada de “investigar y guardar repetidamente en el formato del documento final”, y se separa en tareas más coherentes: “investigar hechos y hallazgos que ayuden al documento” y “ensamblar el documento”.

  No es una solución completa, pero como cuando trabaja una persona, mejora la reutilización de los hallazgos.

• ¿No aplica esto también a las personas? Por eso los niños juegan al “teléfono descompuesto” y ven cómo se corrompe el mensaje. La solución es proveer una única fuente de verdad.

• Estoy construyendo herramientas para combatir este tipo de degradación: https://github.com/JigSpec/JigSpec

• Me gustó mucho el método de evaluación de aquí. Prueban la fidelidad haciendo viajar de ida y vuelta una cadena de pasos reversibles.

  Me impresionó que incluso en tareas que superficialmente parecen fáciles de manejar para una computadora, los modelos de frontera acumulen errores.

  Me pregunto si el resultado más fuerte en Python es solo producto de una evaluación especializada en Python, o si también se trasladaría a otros lenguajes generales comunes, y si se debe a algún elemento específico del proceso de entrenamiento.

• Ya sabíamos más o menos que los modelos no fallan por muchísimos errores pequeños, una “muerte por mil cortes”, sino que en algunas rondas reconstruyen casi perfecto y en otras sufren fallas catastróficas donde pierden de golpe 10 a 30 puntos o más.

  Del mismo modo, la degradación en modelos débiles proviene sobre todo de eliminar contenido, mientras que en modelos de frontera proviene de corromperlo. Por eso andamos moviendo y ajustando cosas como el harness y la temperatura.