Codex dejó de buscar en internet en una prueba en ruso y su tasa de éxito cayó del 100% al 0%

Le pides a un agente que corrija la exportación de un entrenamiento a un reloj. Modifica campos, introduce valores de frecuencia cardíaca y presenta un parche impecable. Pero el reloj no reconoce ese formato. La respuesta está en un foro, y el agente ni siquiera lo ha consultado. En un experimento publicado en Habr, este comportamiento apareció después de traducir las instrucciones del inglés al ruso. La conclusión práctica es sencilla: ante correcciones extrañas, conviene revisar el registro de consultas a las fuentes y proporcionar al agente las particularidades conocidas del proyecto.

La autora comprobó si el idioma de las instrucciones influía en el funcionamiento de los agentes y si necesitaba traducir los casos de su proyecto worklore, una biblioteca de casos de ingeniería analizados. En total realizó 1350 ejecuciones: seis tareas, nueve configuraciones de agentes, cinco variantes de presentación y cinco repeticiones de cada combinación. Es un pequeño experimento de la autora, pero muestra un fallo que puede pasar fácilmente inadvertido en el trabajo cotidiano.

Dónde empezó el agente a adivinar

El caso más claro fue el formato de un rango de frecuencia cardíaca en un entrenamiento para Garmin. Según las condiciones del experimento, la particularidad necesaria estaba descrita en un foro y no figuraba en la documentación. Con las instrucciones en inglés, Codex con un nivel de razonamiento bajo buscó el formato en internet en cada ocasión y resolvió correctamente los cinco intentos.

Tras traducir las instrucciones al ruso, el mismo agente no acudió a internet ni una sola vez. En lugar de comprobarlo, probó cambios verosímiles: eliminó el objetivo estructurado, pasó a valores absolutos de frecuencia cardíaca y añadió campos nuevos junto a la clave antigua. Ningún intento tuvo éxito. La tasa cayó del 100% al 0%, aunque cada porcentaje representa aquí solo cinco ejecuciones.

Kimi K3.1 mostró un patrón parecido en una tarea sobre las particularidades de un proveedor de OAuth. La versión en inglés produjo cinco soluciones correctas de cinco; la versión en ruso, ninguna. El agente omitió la búsqueda y mantuvo suposiciones erróneas sobre los parámetros de acceso y la duración del token. La autora no investigó por qué el idioma cambiaba la decisión de utilizar una herramienta.

El dato que faltaba resultó más útil que la traducción

Añadir una nota sobre un caso similar resolvía una parte considerable de los problemas. Por ejemplo, si un proveedor emite tokens que no caducan, conviene indicárselo explícitamente al agente. Así no tiene que deducir el comportamiento de un servicio concreto a partir de sus conocimientos generales sobre OAuth.

En cuatro tareas en las que la nota contenía el dato que faltaba, la tasa de éxito pasó del 47% al 94% con las instrucciones en inglés y del 35% al 92% con las instrucciones en ruso. En dos tareas de control, donde la respuesta ya figuraba en la documentación o en un registro, la mejora fue pequeña. Esto respalda una idea muy práctica: conservar las particularidades de las integraciones que descubre el equipo y facilitárselas al agente junto con la tarea.

Traducir la propia nota apenas cambió los resultados. Con las instrucciones en ruso, la nota en ruso produjo aproximadamente dos puntos porcentuales más de soluciones correctas, pero el intervalo de incertidumbre incluía la ausencia de efecto. Los identificadores, las rutas y los mensajes de error permanecieron en inglés en ambas versiones. Para este tipo de memoria técnica, la precisión de los detalles importó más que el idioma de la explicación.

Qué comprobar en tu propio proceso

Es pronto para afirmar, a partir de estos datos, que el ruso causa un mal rendimiento de los agentes. Solo se probaron seis tareas preparadas expresamente, un idioma distinto del inglés y cinco repeticiones por combinación. Además, se compararon configuraciones completas: modelo, entorno de ejecución y herramientas disponibles. El resultado no puede extrapolarse automáticamente a otras versiones o ajustes.

Hay otra limitación: en algunas ejecuciones, los agentes encontraron mediante búsquedas los casos publicados por el propio worklore. Esto modificó el contexto al que tenían acceso. La autora volvió a calcular por separado los resultados globales excluyendo esas ejecuciones; la observación principal se mantuvo, aunque para algunas combinaciones de modelo y tarea ya no quedó una comparación sin esa interferencia.

Un desarrollador puede tomar un problema conocido que requiera una fuente externa y ejecutarlo varias veces en dos idiomas. Debe revisar las llamadas a herramientas y el resultado de la validación del código. Si se omite la búsqueda de forma habitual, puede exigir explícitamente que se consulte la fuente y repetir la comparación. Conviene adjuntar desde el principio cualquier dato conocido, junto con un enlace o un extracto. Y quien evalúe un agente para su equipo desde la gestión de producto debería incluir el idioma de las tareas habituales en la evaluación: que una petición tenga el mismo significado no garantiza que se siga el mismo camino para resolverla.