Autor: Beñat Descalzo Alcuaz (equipo Ada Byron)
(Nota: Esta L.A. es parte de una serie de artículos. Si no lo has hecho, accede al artículo general aquí)
Definimos la "ventana de contexto" de un modelo de lenguaje como la cantidad de contexto que puede mantener razonablemente, sin empezar a olvidar o a inventarse detalles. Las ventanas de contexto útiles son limitadas (a día de esta redacción, ~256K tokens llevándolo al límite, aunque se anuncien 1M tokens) y, a partir de cierta cantidad de texto, es mucho más probable que el modelo alucine o pierda rigor en la tarea original[1]. Además, en cuanto comete un error, está estudiado uno de sus mayores problemas: tiende a redoblar la apuesta, reafirmándose implícitamente en sus propios fallos[2].
Sin embargo, las interfaces de estos modelos permiten, sin mayor aviso, subir todos los documentos que al usuario le apetezca. Esto crea la falsa ilusión de que el modelo es fiable para trabajar con tanta información al mismo tiempo, realizando además varias tareas distintas (captura de requisitos y redacción de los mismos, por ejemplo).
Sin ir más lejos, veamos un ejemplo que sucedió en nuestro equipo, en el proyecto P2.3. Ofrecimos a Deepseek todos nuestros documentos de gestión, incluído un documento E250 incompleto:
Una de las constraints más importantes de este proyecto es el origen de los vídeos, pues se trabaja con una mezcla de contenido ya existente (en los canales y playlists proporcionados por el cliente) y adquisiciones a otros grupos de la asignatura para los vídeos del ODS5.
Véase, en el documento descriptivo de los requisitos del canal:
"Características finales del canal
1. Mantiene todos los contenidos iniciales, salvo que se haya acordado expresamente con el cliente la supresión o modificación de alguno de ellos.2. Debe albergar dos nuevos vídeos, desarrollados a partir de guiones consistentes con las especificaciones del entregable P2.2.E210. Estos vídeos deben disponer de subtítulos en los idiomas establecidos para el sitio web."
Por tanto, no se espera que una de las tareas sea la búsqueda de vídeos externos para su adición. Sin embargo, es esa la interpretación de Deepseek, que nos ofrece con total confianza:
Si esta información llega a manos de un miembro del equipo que no se haya implicado activamente con los documentos de requisitos, lo descrito puede parecer totalmente razonable y no merecerle una reflexión más profunda. Esto lo hace aún más peligroso, pues hacer caso a esas instrucciones podría suponer perder el visto bueno del cliente (un error, además, extendido a la página web).
Un problema relacionado es el de la lectura de archivos en formatos complejos. Para un LLM, un fichero PDF o DOCX es problemático: si se observa el razonamiento de estos modelos en local, buena parte de los tokens iniciales se pierden intentando realizar la lectura (llamadas a pdftotext, leer de a bloques de líneas, intentar extraer las imágenes con código, etc.). Esto contribuye a la contaminación del contexto en la propia conversación, lo que puede suponer parte del problema.
Por tanto, si se quieren obtener resultados algo más fiables, conviene separar las tareas en dos fases, con agentes independientes entre sí:
- FASE DE ANÁLISIS: Ejecutando un solo agente por fichero, obtener una versión en texto plano del mismo (p. ej. "extrae todo el texto de este DOCX, y donde haya fotos, añade una descripción detallada de la misma en el texto plano"). Puede tener sentido solicitar, a su vez, que se resuman o simplifiquen los documentos sin pérdida de detalle.
- FASE DE SÍNTESIS: El agente final que armonice todo el trabajo debería trabajar directamente con los ficheros de texto plano, para evitar toda la carga de contexto relacionada con entender los demás formatos. Idealmente, además, se debería intentar evitar que recaigan sobre él demasiadas tareas (p. ej. redactar, de una, la planificación completa), siendo más útiles en subtareas específicas.
Algunos entornos como Codex u Claude Code están surgiendo útiles para estas tareas por su habilidad de "llamar a subagentes" automáticamente y esperar a la respuesta, lo que simplifica el proceso para el usuario final. Sin embargo, todos estos entornos dependen de suscripciones de pago.
(nota del autor: a la fecha de esta redacción, Github Copilot y Gemini acaban de anunciar una subida drástica de sus precios[3][4], así que es posible que a la fecha de leer este documento sea inasumible siquiera contratar uno de estos sistemas).
REFERENCIAS
[1] "LongCodeBench: Evaluating Coding LLMs at 1M Context Windows", arXiv:2505.07897 (Rando et al.): https://arxiv.org/abs/2505.07897.
"We find that long-context remains a weakness for all models, with performance drops such as from 29% to 3% for Claude 3.5 Sonnet, or from 70.2% to 40% for Qwen2.5."
[2] "LLMs Get Lost in Multi-Turn Conversation", arxiv:2505.06120 (Laban et al.): https://arxiv.org/abs/2505.06120.
"We find that LLMs often make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely"
[3] "Github Copilot is moving to usage-based billing", GitHub Blog: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/.
"GitHub has absorbed much of the escalating inference cost behind that usage, but the current premium request model is no longer sustainable."
[4] "Google Launches Gemini 3.5 Flash With Higher Prices but No Generational Leap", Trending Topics: https://www.trendingtopics.eu/google-launches-gemini-3-5-flash-with-higher-prices-but-no-generational-leap/.
"(...) the model costs three times as much as its predecessor (...)"
No comments:
Post a Comment