Taste-Bench: terminar no es decidir bien
Taste-Bench: tu agente termina las tareas pero decide mal — el mejor modelo acierta el 59,7% de las bifurcaciones
TL;DR
- Verificado contra el HTML v1 del paper (arXiv 2609.25804, “The Tasteful Agent”, Pan et al., CityU Hong Kong + Microsoft, v1 del 22/09/2026; consultado el 04/10/2026): Taste-Bench convierte bifurcaciones de decisión de trayectorias agénticas reales en preguntas de elegir camino, etiquetadas por hindsight — lo que pasó después pone la etiqueta, sin anotación humana. 502 preguntas (390 de ingeniería, 112 de research) que sobreviven del 10,8% de las 4.657 bifurcaciones candidatas minadas.
- El mejor de 14 modelos, GPT-5.6 Sol, acierta el 59,7% (GPT-5.5: 59,5%). Cuando la evidencia que decide la bifurcación llega tarde a la trayectoria, la media de los 14 modelos cae del 62,3% al 21,0% — y con el protocolo estricto del benchmark, el azar da 25%.
- Lo contrarian, verificado: subir el reasoning effort del mínimo al máximo mueve la accuracy −0,2 puntos (Sol) y +2,2 (Luna). Ruido. Y los modelos gastan MÁS tokens de razonamiento justo en las bifurcaciones más difíciles, que son las que peor resuelven. El coste no compra criterio.
- El gusto se puede entrenar: destilar el razonamiento de un teacher que ya vio el resultado (Qwen3.6-27B + LoRA, KL forward sobre continuaciones del teacher) transfiere a tareas no vistas (+17,9 puntos en fold held-out) y, convertido en consejos, eleva un executor fijo de 14,6% a 33,7% en tareas held-out de SWE-bench Pro. La cota con consejos perfectos es 39,0%.
- Matiz a nuestro propio ranking: la correlación con SWE-bench Verified es r = +0,63 (R² = 0,39). Los 4 mejores modelos de SWE-bench Verified están a 4,0 puntos entre sí ahí y a 10,7 puntos en gusto. Que un agente acabe las tareas no dice cómo elige el camino.
Contexto: terminar no es decidir
SWE-bench y familia miden si el agente acaba la tarea: el repo queda parcheado, los tests pasan, éxito. Lo que no miden es la calidad de las decisiones intermedias — qué hipótesis testar, qué implementación extender, qué experimento lanzar — que es justo lo que determina cuánto del presupuesto se quema antes del resultado. El paper lo formula sin rodeos: una decisión equivocada se ve razonable en el momento, y su coste aparece mucho después, cuando el agente ya gastó buena parte del run.
Los autores (Pan et al., CityU Hong Kong + Microsoft) llaman gusto (taste) a la capacidad de elegir bien en esas bifurcaciones de horizonte largo. Su observación clave: la parte posterior de una trayectoria real contiene la evidencia para juzgar sus decisiones anteriores. Si dos intentos de la misma tarea comparten prefijo y divergen a mitad de run, y uno termina en tests en verde y otro no, la trayectoria misma etiqueta qué camino era mejor. Hindsight como supervisión gratis: el benchmark escala con las trayectorias que los sistemas agénticos ya producen.
La pregunta que mide Taste-Bench es precisa: ¿elige el modelo la dirección cuya ventaja aparecerá después, en el momento de decidir y sin ver nada de lo posterior? Eso es gusto: juicio sobre el futuro con información del presente.
Cómo se construye un benchmark de gusto sin anotadores
Cero anotación humana en la construcción. Dos mecanismos de minería, complementarios por diseño:
| Construcción | De dónde sale el fork | Qué captura | Quién pone la etiqueta |
|---|---|---|---|
| Trayectorias paralelas | Intentos independientes de la misma tarea que comparten prefijo y divergen en un punto | Decisiones malas que el agente nunca notó (el run siguió hasta el final) | El intento que pasa tests o logra el objetivo |
| Trayectorias detour | Corrección dentro de un mismo run: dirección abandonada vs. recuperación posterior | Decisiones malas que el agente comete y corrige tarde | La recuperación, que completa la tarea |
Las dos pools de donde se mina: 2.677 rollouts graduados (agentes GPT-5.4 y GPT-5.5 sobre 517 tareas de SWE-bench Pro) para ingeniería, y 1.132 runs sobre 47 tareas de R&D de RE-Bench y HCAST, descargados de MALT, el release público de transcripts de METR, para research. Un modelo generador propone bifurcaciones candidatas y escribe las dos direcciones con redacción neutra y paralela; luego un panel de jueces —distinto del generador— filtra lo que no sirve:
- Triviales: las que todo juez acierta leyendo solo las dos opciones, sin trayectoria. Si la respuesta se adivina por la redacción, fuera (4.657 candidatas → pasa el 10,8%).
- Indecidibles: las cuya etiqueta no se sostiene al leer el registro completo. Solo publican las que todo juez confirma con el record entero delante.
El protocolo de evaluación tapa el sesgo de posición clásico de las preguntas A/B: cada pregunta se presenta dos veces, en un orden fijo y en el exactamente inverso, y solo cuenta como acierto responder bien en ambos. Con esa regla, el azar da 25% y un modelo que siempre prefiere la misma posición puntúa 0%. Cuando leas el 59,7% del titular, recuerda que no es un 59,7% sobre un binario simple.
La revisión humana existe, pero como auditoría, no como pipeline: 100 preguntas muestreadas, dos revisores que eligen dirección y luego ven los resultados registrados. De 172 juicios A/B explícitos, 170 coinciden con la etiqueta minada (98,8%); entre revisores, 98,6% de acuerdo con κ = 0,973. Para un dataset generado automáticamente, el punto de partida es notable; no es garantía absoluta y en “Qué NO sabemos” volvemos sobre eso.
Minar trayectorias de agentes reales para extraer valor entrenable no es un patrón aislado de este paper; ya lo vimos en Code2Skill, que convierte repos de GitHub en skills a partir de trayectorias minadas. Aquí el giro es que la trayectoria se convierte en pregunta de evaluación, no en habilidad reutilizable.
Los números, verificados contra el paper
| Claim (nuestro titular) | Qué dice exactamente el HTML v1 | Estado |
|---|---|---|
| El mejor modelo acierta el 59,7% de las bifurcaciones | Literal, sec. 4.2: GPT-5.6 Sol, mejor de 14 modelos; GPT-5.5 a 59,5%; resto disperso por debajo | Verificado |
| Con evidencia tardía cae al 21% | Sec. 4.3: media de los 14 modelos, del 62,3% en forks “in prefix” al 21,0% en “more work”; el azar con este protocolo es 25% | Verificado |
| Más razonamiento no mejora el gusto | Sec. 4.4: −0,2 puntos (Sol) y +2,2 (Luna) de effort mínimo a máximo; 6.024 respuestas; solo 2 modelos | Verificado, con letra pequeña |
| Correlación parcial con SWE-bench Verified | Sec. 4.5: r = +0,63 (R² = 0,39) sobre 11 modelos —excluye 3 con más del 9% de respuestas no parseables—; en el subset de ingeniería, r = +0,37 | Verificado |
| La destilación transfiere a tareas no vistas | Sec. 5.2: 30,0% → 47,9% en fold held-out (+17,9 puntos, protocolo estricto); media por orden: 42,7% → 62,4% | Verificado |
| El advice del estudiante eleva el éxito end-to-end | Sec. 5.3: 14,6% → 33,7% en 41 tareas held-out de SWE-bench Pro; advice perfecto: 39,0% | Verificado |
| ”El gusto explica el éxito en producción” | No aparece en el paper | Interpretación nuestra, no del estudio |
Dos lecturas que la tabla no enseña solas.
Los detours son más duros que los paralelos, en los dos dominios. El paper lo reporta en el Apéndice D.1: el hueco entre construcciones supera al hueco entre ingeniería y research. Tiene sentido mecánico: en un detour, reconocer el error antes de que el propio agente lo notara exige anticipar un fallo que aún no ha ocurrido; en un fork paralelo al menos hay dos caminos simétricos delante.
Ingeniería y research se parecen más de lo que cabría temer. Si el gusto fuera pura experiencia de dominio, los modelos deberían desplomarse fuera de su zona de entrenamiento de código. No lo hacen de forma dramática: el factor que pesa es cuánto tarda en llegar la evidencia, no el dominio. Eso es lo que hace al benchmark interesante — mide algo transversal — y es también la base de nuestra lectura (nuestra, no del paper): el gusto es una capacidad propia, no un subproducto de saber mucho de un tema.
Lo contrarian: el presupuesto de razonamiento no compra criterio
El experimento más incómodo del paper es también el más barato de contar. Reran Taste-Bench con tres niveles de reasoning effort para dos modelos, manteniendo preguntas, prompt, límite de tokens y protocolo idénticos. Resultado: del esfuerzo mínimo al máximo, GPT-5.6 Sol baja 0,2 puntos y GPT-5.6 Luna sube 2,2. En la Figura 4, las curvas de los tres niveles se solapan en todos los horizontes temporales.
Y el detalle que duele en la factura: los dos modelos concentran más tokens de razonamiento en el nivel “more work” que en ningún otro, que es justo el de accuracy más baja. Los autores lo leen como que los modelos reconocen las bifurcaciones difíciles y piensan más en ellas — pero la evidencia que decidiría la bifurcación no está en el contexto, está en el futuro. Por mucho que pienses, no puedes deducir qué pasará después del fork si la información decisiva aún no ha ocurrido. El cómputo extra compra más ruido de razonamiento, no criterio.
Conectarlo con costes es inevitable y no es gratuito: la tesis de AgentDiet —que en agentes de coding, más tokens no implican mejores resultados y hay que podar el gasto por fase— encuentra aquí su versión más pura. Si tu agente se atasca en una bifurcación de diseño, doblar el presupuesto de razonamiento del modelo es la palanca equivocada: la palanca que funciona aparece en la siguiente sección, y es otra gente (o tú) mirando el resultado.
Otra víctima colateral: los rankings end-to-end. Los 4 mejores modelos de SWE-bench Verified están a 4,0 puntos entre sí en ese benchmark y a 10,7 en gusto; la correlación en el subset de ingeniería —el más comparables de todos, porque las preguntas se minan de SWE-bench Pro— baja a r = +0,37. Nuestra review de GPT-5.6 Sol lo sigue teniendo como referencia de coding agents, y aquí también gana (59,7%, mejor de 14); el matiz es que gana suspendiendo: falla 4 de cada 10 bifurcaciones. El puesto en un leaderboard de finalización no te dice quién decide bien el camino, y ahora hay un instrumento que separa ambas cosas.
El gusto se puede entrenar (con un profesor que ya vio el futuro)
La segunda mitad del paper es la que deja de ser diagnóstico. La receta de destilación:
- El teacher es el mismo modelo congelado con un privilegio: además de la pregunta, recibe una demostración corta del candidato correcto. Como ya sabe la respuesta, su razonamiento libre converge en el camino bueno.
- El student es el mismo base sin el privilegio, y el entrenamiento alinea sus tokens con las continuaciones muestreadas del teacher mediante un KL forward token-level sobre el razonamiento y la elección final (receta tipo SDPO).
- Folds disjuntos por tarea sobre las 390 preguntas de ingeniería: el student entrena en un fold y se evalúa en el otro, así que ninguna tarea de evaluación apareció en su entrenamiento.
Los números separan memorización de juicio. En el fold de entrenamiento, el acierto de una sola orden sube de 48,6% a 92,9% — eso podría ser memorizar etiquetas. En el fold held-out, con el protocolo estricto de dos órdenes, el student llega a 47,9% frente al 30,0% del base: +17,9 puntos en preguntas de tareas que nunca vio. La media sobre las dos órdenes sube de 42,7% a 62,4%. Para referencia sobre esas mismas 390 preguntas de ingeniería: GPT-5.6 Sol, el mejor de los 14, puntúa 56,9%. Un Qwen3.6-27B afinado con LoRA destilando su propio juicio privilegiado se coloca a 9 puntos del mejor modelo frontier evaluado en esta métrica concreta — sin cambiar de base, solo con la receta de supervisión.
La prueba end-to-end convierte juicio en resultado. Sobre 41 tareas held-out de SWE-bench Pro, el juicio del student en cada fork minado de runs previos se escribe como una nota de advice en el contexto, y un executor fijo (Qwen3.6-27B, el mismo en las tres condiciones) completa la tarea solo:
| Condición | Éxito en SWE-bench Pro held-out |
|---|---|
| Sin advice | 14,6% |
| Con advice del student | 33,7% (+19,1 puntos) |
| Con advice perfecto (cota superior) | 39,0% (+24,4 puntos) |
El student captura la mayor parte de la cota. La lectura práctica, y es la parte que un dev con agentes en producción debería subrayar: el consejo de alguien que ya vio el outcome vale +19 puntos, sin cambiar el modelo ejecutor. No es que el executor sea tonto y le sobre contexto; es que la información que necesita en la bifurcación no existe en su contexto, y alguien con hindsight puede ponérsela delante.
En la auto-mejora recursiva de agentes ya señalamos que el cuello de botella real de estos sistemas es el research direction-setting —decidir qué merece evaluarse—, no la capacidad de proponer cambios. Taste-Bench le pone número a esa intuición: 59,7% de acierto en el mejor modelo, y un mecanismo concreto (juicio destilado con hindsight) para mejorarlo.
Qué NO sabemos
- El experimento de reasoning effort usa 2 modelos, ambos de la familia GPT-5.6. −0,2 y +2,2 puntos en Sol y Luna no autorizan a generalizar a todas las familias, aunque el solape en todos los horizontes sugiera que no hay mucho que rascar. Tampoco probó otras formas de gastar cómputo (self-consistency, votación) que atacan el problema por otro lado.
- La etiqueta es el resultado realizado, no el contrafactual. Que un camino terminó mejor en este run no prueba que fuera mejor en general: ejecución y entorno también contaminan. Los filtros de jueces y la revisión humana (κ = 0,973) mitigan, no eliminan.
- El experimento end-to-end usa advice de forks minados de runs previos de las mismas 41 tareas. Mide el valor del juicio en bifurcaciones conocidas de antemano, no un sistema de advice en vivo sobre forks nuevos; ese salto queda sin medir.
- La destilación es en un 27B open-weights con LoRA. No sabemos si la misma receta rinde igual en modelos frontier cerrados, que además no puedes afinar así por API. El matiz práctico: hoy, esta técnica es para quien puede entrenar.
- Los pools son SWE-bench Pro y R&D académico. Nada de forks de producto real (migraciones, deploys, incidentes). La transferencia a tu stack cotidiano es plausible pero no está medida.
Qué haría yo
- Escribe el “por qué” antes del fork. Si diriges agentes, deja el criterio de decisión por escrito antes de ver los caminos: el paper muestra que sin evidencia tardía los modelos fallan mayoritariamente, y tu nota de criterio es la versión barata del advice del teacher.
- No compres criterio con tokens. Los modelos ya razonan más donde peor aciertan; si tu agente se atasca eligiendo dirección, el budget de razonamiento es la palanca equivocada. La que mide el paper es otra: información con outcome.
- Revisa las bifurcaciones tardías tú mismo. Donde la evidencia llega tarde (nivel “more work”) es donde los modelos están por debajo del azar del protocolo. Ahí es donde tu supervisión —o la de un juez con acceso al resultado— compra más puntos: el advice con hindsight movió 14,6% → 33,7%.
- Si tienes históricos de runs de agentes, tienes supervisión gratis. Forks paralelos y detours se minan solos; lo que hoy es log morado puede ser, como en este paper, un dataset de gusto o materia prima para destilar.
- Lee los rankings de agentes con esta vara nueva. Terminar (SWE-bench) y decidir (Taste-Bench) correlacionan a medias (r = +0,63; R² = 0,39). Cuando elijas modelo para un agente, la pregunta “¿termina las tareas?” y la pregunta “¿elige bien el camino?” ya no son la misma.
Conclusión
Taste-Bench aterriza una idea que los benchmarks end-to-end dejaban pasar: un agente puede terminar todas sus tareas y decidir mal la mitad de los caminos. El mejor modelo de 14 acierta el 59,7% de las bifurcaciones, cae al 21% cuando la evidencia llega tarde, y gastar más razonamiento no arregla nada porque la información que falta no está en el contexto: está en el futuro. A cambio, el paper demuestra que ese juicio se puede transferir — destilando el razonamiento de un teacher con hindsight y convirtiéndolo en consejos para un executor fijo, +19 puntos de éxito end-to-end sin tocar el modelo ejecutor.
Para quien opera agentes, la moraleja es operativa, no especulativa: separa quién ejecuta de quién decide, escribe los criterios antes del fork, y trata tus históricos de runs como el dataset de supervisión que son.
Metodología
Análisis basado en el texto completo del paper “The Tasteful Agent: Measuring and Improving Taste in Long-Horizon Tasks” (arXiv 2609.25804, v1, Pan et al., CityU Hong Kong + Microsoft), descargado en HTML el 04/10/2026 y leído en sus secciones 1-6 y apéndices relevantes; todas las cifras del texto y de las tablas provienen de ese documento, con las traducciones de citas hechas por nosotros. No hemos ejecutado el benchmark ni replicado ninguna condición: las comparaciones con SWE-bench Verified son las del propio paper, que toma las puntuaciones públicas del leaderboard de Vals AI bajo un harness compartido. La revisión humana (κ = 0,973) es de los autores del paper, no un control independiente nuestro. Las interpretaciones propias (“el gusto es una capacidad transversal”, “el coste no compra criterio”, la moraleja operativa) están etiquetadas como tales en el texto y no aparecen como conclusiones del estudio. El benchmark, el código y los resultados registrados de los 14 modelos evaluados están publicados (enlaces abajo), así que las cifras son contrastables sin confiar en nuestra lectura.
Fuentes
- The Tasteful Agent: Measuring and Improving Taste in Long-Horizon Tasks — arXiv 2609.25804, Pan et al.
- HTML v1 del paper (texto completo) — arXiv
- Taste-Bench en Hugging Face Papers — 162 upvotes a 04/10/2026; #1 Paper of the Day, 23/09/2026
- Código de evaluación — GitHub, wbopan/tastebench
- Dataset taste-bench — Hugging Face, wenbopan/taste-bench
- MALT: transcripts públicos de METR — fuente de las trayectorias de research
- RSI de agentes: qué es real en la auto-mejora recursiva — GPT Diffusion
- AgentDiet: reducir costes en agentes de coding — GPT Diffusion
- Review de GPT-5.6 Sol — GPT Diffusion
- Code2Skill: skills minadas de GitHub — GPT Diffusion