Autor: Beñat Descalzo Alcuaz (equipo Ada Byron)
Pocas tecnologías han sido tan disruptivas en los últimos años como la IA generativa. Está afectando, ya sea bienvenida o por la fuerza, a todo trabajo que pueda realizarse en un ordenador (desde la generación de código hasta la -polémica- generación de ilustraciones). Por supuesto, la barbarie burocrática asociada a la gestión de un proyecto no iba a ser menos.
El director afronta la tarea de armonizar documentos sueltos, densos y potencialmente contradictorios: especificaciones formales del cliente, comunicaciones con el mismo, especificaciones internas de la organización, regulaciones pertinentes, y un largo etcétera. A la hora de planificar un proyecto es fácil mezclar mentalmente requisitos (especialmente cuando el tiempo para revisar la planificación es limitado), olvidar alguno de los puntos relevantes, o pasar por alto contradicciones sin resolver entre la organización y el cliente. Por supuesto, una de las primeras líneas de fuego debería ser siempre la revisión de calidad sobre la propia planificación, pero la idea principal se mantiene: en muchos casos, la fase de planificación es altamente propensa a errores.
¿Puede ayudar la IA con este problema? Creemos que es posible, y así lo hemos puesto a prueba en varias fases de los proyectos P2.2 y P2.3 de la organización. Nos ha sido una herramienta de gran utilidad para acelerar algunos procesos (especialmente, en lo concerniente al ámbito técnico), pero en lo relativo a la ambigüedad humana, hemos observado varios casos de error interesantes. En base a nuestra experiencia, estas son algunas de las lecciones que hemos aprendido:
1. UN SOLO MODELO NO PUEDE CON TODO: SEPARAR LA SÍNTESIS DEL ANÁLISIS
Definimos la "ventana de contexto" de un modelo 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 fecha de esta redacción, ~256K tokens en la mayoría de herramientas) 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 implícitamente, propagando el problema[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, de riesgos, división de tareas, etc. todo en uno).
Sin ir más lejos, veamos un ejemplo que sucedió en nuestro equipo, en el proyecto P2.3. Es un ejemplo en el que el modelo se enfrentaba a la captura de un requisito relativamente sencillo, pero alucinó, con confianza, en un sentido totalmente opuesto. Ofrecimos a DeepSeek todos nuestros documentos de gestión, incluido un documento E250 incompleto:
Una de las restricciones 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 listas de reproducción 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
- Mantiene todos los contenidos iniciales, salvo que se haya acordado expresamente con el cliente la supresión o modificación de alguno de ellos.
- 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 las líneas en bloques, 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").
- 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 ("extrae una lista de tareas asociadas al desarrollo de este proyecto", "propón riesgos plausibles", "divide entre X horas esta lista de tareas", etc.).
Algunos entornos, como Codex o Claude Code, están resultando ú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 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 en un futuro sea inasumible siquiera contratar uno de estos sistemas).
Lo curioso es que este problema, como ya he dicho en la introducción, no se da en temas puramente técnicos. Los agentes rozaban el límite de su contexto en el desarrollo de la web y, sin embargo, podían seguir adelante sin necesidad de mucha intervención. Por lo que hemos visto, a los modelos les cuesta mucho más mantener y comprender a escala supuestos implícitos, contextuales y ajenos a la formalidad técnica en sí misma.
2. SUPUESTOS IMPLÍCITOS: EL HUMANO SIEMPRE DEBE ESTAR PRESENTE
Como bien resume el refranero de la lengua cervantina, "el diablo se esconde en los detalles". Con LLMs, esto es especialmente cierto. Los humanos, a partir de nuestra experiencia, trabajamos bajo varios supuestos tan evidentes (a nuestra percepción) que no quedan escritos en ningún lado. Los LLMs no cuentan con esa intuición interna. Por tanto, la mejor heurística defensiva aquí es sencilla: da por hecho que, para todo aquello que no hagas explícito, el modelo va a hacer la interpretación menos caritativa posible.
De hecho, voy más allá: asume que existen errores que ni siquiera puedes imaginar que existan a priori, y que se esconden con sutileza en la salida. En nuestro caso, esto fue especialmente interesante de ver en el desarrollo del sitio web con el framework Astro. Por algún motivo, Codex asumió que, si se solicita el desarrollo de una web en Astro, este dato debería aparecer ni más ni menos que en la cabecera:
Asumió, a su vez, que todos los detalles y documentos de referencia internos para el desarrollo merecían un apartado propio en el landing de la página:
Otra de sus suposiciones iniciales era hacer una web de una sola página larga. Cuando le solicitamos modificar este detalle, lo hizo correctamente, pero una vez más decidió dejarlo documentado en el landing:
A lo largo del ciclo de desarrollo de la página web, esta clase de error nos sucedió en muchos puntos más (al añadir los vídeos relativos al ODS 5, al cambiar la distribución de las preguntas tipo test en el cuestionario de autoevaluación, etc.). Enfrentamos, a su vez, varios problemas de inconsistencia relativos a la traducción de las páginas en los 3 idiomas.
Estos errores, al contrario que los del primer punto, no son de alucinación respecto a la tarea. Los cambios son estrictamente correctos, y acordes a lo solicitado al agente. ¿El problema? Contar, como usuarios humanos, con un supuesto natural e implícito como "los detalles internos de implementación no deberían ser parte del producto final que el cliente quiere mostrar al público".
Este ejemplo es algo evidente, y salta a la vista en cuanto abres la página web. Además, se ha dado en el desarrollo del proyecto, no en su gestión, pero esto no debería servir sino para reforzar la idea central: si el modelo no es de fiar en puntos tan obvios, ¿cómo confiar ciegamente en su criterio para hechos mucho más implícitos?
Por ello, la lección es simple: lee, relee, y lee una vez más todo aquello que salga de la máquina. Además de ser muy cuidadoso con el enfoque y ámbito de tus solicitudes a los agentes, revisa atentamente toda salida intermedia y final.
Ya lo decía IBM en sus manuales allá por 1979[5]: "A COMPUTER CAN NEVER BE HELD ACCOUNTABLE, THEREFORE A COMPUTER MUST NEVER MAKE A MANAGEMENT DECISION". Esta máxima, hoy más que nunca, es esencial.
CONCLUSIÓN
Si no se usan con harto cuidado, los LLMs pueden ser el caballo de Troya del mundo moderno: sus salidas son tan razonables a la vista que cuesta descubrir por qué son tan destructivas. Un director de proyectos puede integrar estos modelos en su trabajo, y probablemente le sean útiles para acelerar la labor o mejorar la calidad en infinidad de tareas, pero debe ser consciente en todo momento de las limitaciones a las que se enfrenta con estas herramientas y cómo abordarlas para reducir el riesgo.
Por supuesto, como añadido, cuidado con la dependencia excesiva en la organización. El coste operativo de estos modelos supera con creces el precio actual que refleja el mercado, y algunos cambios en la industria empiezan a reflejar este hecho. Son herramientas utilísimas, pero un objetivo fundamental de toda organización debe ser evitar tenerlas como punto de fallo único; sus trabajadores deberían ser capaces de ejercer por su cuenta toda labor que deleguen en los modelos.
DISCLAIMER: Los fallos documentados en esta lección aprendida se han dado en los modelos más recientes a fecha de su uso (DeepSeek V3 y GPT 5.5 high), con el "modo de razonamiento" activo. Según avance la tecnología, es posible que los consejos aquí detallados pierdan relevancia a futuro, mas no deja de ser esencial la cautela absoluta cuando se asume la responsabilidad de firmar un documento como director/a.
No comments:
Post a Comment