Claude 3 y Gemini 1.5: leer un proyecto entero de una vez

En apenas tres semanas, los dos principales competidores de OpenAI han movido la misma pieza. El 15 de febrero Google presentó Gemini 1.5 Pro, con una ventana de contexto de hasta un millón de tokens en vista previa limitada para desarrolladores y empresas; según Google, más de 700.000 palabras. El 4 de marzo Anthropic lanzó la familia Claude 3 (Haiku, Sonnet y Opus) con 200.000 tokens de contexto estándar y la posibilidad de ampliarlo para clientes concretos.

Para un despacho de arquitectura, la traducción es inmediata: por primera vez es razonable entregar a un modelo un proyecto completo en una sola consulta. El pliego de prescripciones técnicas, la memoria descriptiva y constructiva, el anejo de cumplimiento del CTE, el estudio geotécnico y el presupuesto, todo a la vez.

Conviene entender qué resuelve eso y qué no.

Qué cambia de verdad

Hasta ahora, trabajar con documentos largos obligaba a trocearlos. El modelo veía fragmentos, perdía el hilo entre capítulos y no podía detectar contradicciones entre documentos que no tenía delante a la vez. Con ventanas de este tamaño, esa limitación desaparece en buena parte.

Los usos con valor real en un estudio son concretos:

• Coherencia interna del proyecto. Comprobar que la transmitancia declarada en la memoria constructiva coincide con la que figura en el anejo de DB-HE, o que la resistencia al fuego de la estructura indicada en la justificación del DB-SI es la misma que aparece en el pliego.
• Lectura de pliegos de concurso. Extraer criterios de adjudicación, documentación exigida, plazos y condiciones de solvencia de un pliego administrativo y su pliego técnico en una sola pasada.
• Revisión de proyectos ajenos. En una dirección de obra heredada, o en una revisión previa al visado, obtener un mapa rápido del contenido y de sus puntos débiles.
• Respuesta a requerimientos. Cruzar un informe técnico municipal con el proyecto presentado para localizar los apartados afectados.

El contexto largo no hace al modelo más sabio. Le permite tener delante todo el expediente. Son cosas distintas.

Qué no resuelve

La tentación es pensar que, si el modelo lo ha leído todo, sus conclusiones son fiables. No es así, por tres razones.

Primera: leer no es localizar. Anthropic afirma que Claude 3 Opus supera el 99 % de acierto en su prueba de recuperación de un dato aislado dentro de un texto largo. Es un resultado notable, pero esa prueba mide encontrar una aguja concreta, no razonar con veinte requisitos repartidos por trescientas páginas. En tareas de cruce múltiple, los errores y omisiones siguen apareciendo.

Segunda: sin cita no hay verificación. Un modelo que responde que el proyecto cumple el DB-SI sin indicar en qué página, tabla y apartado lo ha comprobado no está ayudando, está trasladando el riesgo. Toda afirmación técnica debe venir acompañada de la referencia exacta al documento del proyecto y al artículo de la norma, para que el técnico pueda contrastarla en segundos.

Tercera: el modelo no sabe qué norma está vigente. Si se le entrega el proyecto, pero no la normativa, contestará con lo que recuerda de su entrenamiento. Y lo que recuerda puede ser una versión anterior del DB-HE o una mezcla de varias. El contexto largo permite incluir también el texto normativo de referencia, y eso es precisamente lo que hay que hacer.

A esto se suma un efecto menos evidente: cuanto más largo es el contexto, más fácil es que el usuario confíe en la respuesta. Si el modelo ha leído las trescientas páginas, parece razonable creer que no se le escapa nada. Esa confianza es la que hay que disciplinar con método.

Coste, privacidad y método

Hay dos consideraciones prácticas que conviene no olvidar. La primera es el coste: las consultas con cientos de miles de tokens se pagan por volumen y, repetidas a diario sobre el mismo expediente, suman. No tiene sentido cargar el proyecto entero para una pregunta que afecta a un solo capítulo.

La segunda es la confidencialidad. Un proyecto contiene datos del promotor, a veces datos personales y casi siempre información comercial sensible. Antes de subirlo a cualquier servicio hay que conocer las condiciones de uso de datos del proveedor, distinguir entre versiones de consumo y versiones empresariales o de API, y contar con la autorización del cliente cuando proceda.

En cuanto al método, propongo una regla sencilla para el estudio:

1. Preguntas cerradas y verificables. No pedir si el proyecto cumple, sino qué valor de resistencia al fuego figura en cada documento y en qué página.
2. Exigir la cita en cada respuesta. Documento, página y apartado. Si el modelo no la da, la respuesta no se usa.
3. Incluir la norma de referencia en el mismo contexto, con su versión y fecha.
4. Contrastar una muestra de las respuestas antes de confiar en el método para un tipo de proyecto.

Mi posición

El contexto largo es el avance más útil para el trabajo de oficina técnica desde la aparición de los modelos de lenguaje. Convierte en factible la revisión de coherencia de un proyecto completo, que hasta ahora era manual, lenta y propensa a errores.

Pero no cambia el reparto de responsabilidades. La Ley de Ordenación de la Edificación atribuye al proyectista la responsabilidad de que el proyecto cumpla la normativa, y esa responsabilidad no se delega en una herramienta. El modelo es un revisor incansable que necesita supervisión, no un firmante.

Los estudios que mejor aprovecharán esta capacidad no serán los que carguen más páginas, sino los que diseñen preguntas precisas y exijan citas comprobables.