El síntoma: responde, pero no ha leído todo
El corte casi nunca aparece como error. Lo que ves es esto: contesta con seguridad sobre las primeras páginas, dice «no consta» de algo que está en el anexo, mezcla dos versiones de una norma porque solo vio una, o resume un documento de 40 páginas como si tuviera 10. La conversación sigue con normalidad y la respuesta parece razonable.
La ventana de contexto es todo lo que el modelo puede tener delante a la vez: tus instrucciones, el texto del PDF, la pregunta y la respuesta que está escribiendo. Se mide en tokens (trozos de palabra), no en páginas. Si el total pasa del límite, algo se queda fuera.
En Ollama, el registro del servidor lo dice al arrancar. En nuestro equipo, con una gráfica de 16 GB, apareció esta línea: msg="vram-based default context" total_vram="15.9 GiB" default_num_ctx=4096. Es decir, 4.096 tokens salvo que tú pidas otra cosa. La documentación oficial de Ollama también habla de 4.096 por defecto en sus preguntas frecuentes (y de 2.048 en la referencia del Modelfile), así que no des el valor por supuesto: míralo en tu registro.
Cuánto ocupa tu documento (antes de culpar al modelo)
Lo primero es saber si cabe. Ollama devuelve en cada respuesta de su API el campo prompt_eval_count: los tokens que leyó del prompt. Si ese número sale igual o casi igual al contexto configurado, sospecha que el texto se ha recortado. Si sale muy por debajo, el problema está en otra parte (extracción del PDF, pregunta ambigua, modelo flojo).
Como referencia medida: nuestro corpus de prueba eran 14 documentos ficticios en español, de una o dos secciones cada uno, troceados en 43 fragmentos. Enteros ocupaban entre 4.211 y 4.350 tokens según el modelo (cada uno cuenta los tokens a su manera). Un contrato o un informe real de varias decenas de páginas ocupará bastante más. Con el contexto por defecto, meterlo todo en el prompt se habría cortado sin avisar; por eso en la prueba subimos num_ctx a 16.384.
Antes de nada, convierte el PDF a texto y ábrelo. Si sale vacío o desordenado (tablas rotas, columnas mezcladas, páginas escaneadas sin texto), ningún ajuste de contexto lo arregla: el modelo recibe basura. La extracción de PDF no la medimos en esta prueba.
Opción 1: subir el contexto (si cabe en tu equipo)
Es la solución más simple cuando el documento ocupa unos miles de tokens. Tienes tres sitios para hacerlo en Ollama, según cómo lo uses. Ten en cuenta que más contexto consume más memoria de la gráfica y que la API compatible con OpenAI (/v1) no permite cambiarlo en la petición: la documentación de Ollama indica crear un modelo propio con un Modelfile que lleve PARAMETER num_ctx.
Lo que medimos con 32.768 tokens de contexto: los tres modelos pequeños (qwen3.5:4b, qwen3.5:9b y gemma4:12b) funcionaron y la velocidad de generación bajó poco, a 86, 55 y 80 tokens por segundo con un prompt de unos 9.400 tokens. Con gemma4:12b y ese contexto, la VRAM ocupada por todo el equipo rondó los 8,4 GB. En una gráfica con menos memoria, prueba primero con 8.192 o 16.384.
- Ollama: preguntas frecuentes (tamaño de la ventana de contexto)
- Ollama: referencia del Modelfile (num_ctx)
- IA local en Windows: RAM, VRAM y contexto
- Servidor (PowerShell): $env:OLLAMA_CONTEXT_LENGTH = "16384"; ollama serve
- Dentro de ollama run: /set parameter num_ctx 16384
- API nativa (/api/chat o /api/generate): "options": { "num_ctx": 16384 }
- Para /v1: un Modelfile con FROM gemma4:12b y PARAMETER num_ctx 16384, y después ollama create gemma4-16k -f Modelfile
Comandos según la documentación de Ollama; los valores de 16.384 y 32.768 son los que usamos con Ollama 0.40.14 el 04/11/2026.
Opción 2: buscar por palabras clave y pasar solo los trozos útiles
Si el documento no cabe, o tienes muchos, la alternativa es trocearlo (por secciones, no por número fijo de caracteres) y, para cada pregunta, darle al modelo solo los trozos que más se parecen. La forma más barata es una búsqueda por palabras clave tipo BM25: no necesita ningún modelo, se programa en unas decenas de líneas y es instantánea.
En nuestra prueba, con los 3 mejores trozos por pregunta, el contexto que recibía el modelo bajó a 356–443 tokens en lugar de más de 4.200. La recuperación encontró el documento correcto en las 15 preguntas que tenían respuesta, y gemma4:12b y qwen3.5:9b acertaron las 18 preguntas (incluidas las 3 sin respuesta, donde debían decir «PENDIENTE»). Tiempo medio por pregunta: 0,6–0,7 segundos.
Funciona muy bien cuando la pregunta usa las mismas palabras que el documento: «dietas», «comida», «alojamiento», el nombre de la política. Falla cuando la persona pregunta con otras palabras («¿cuánto me pagan por cenar fuera?» frente a «importe de manutención»).
Opción 3: RAG con embeddings
Los embeddings convierten cada trozo en un vector que representa su significado, de modo que «cenar fuera» puede encontrar «manutención». Con Ollama basta un modelo pequeño de embeddings: embeddinggemma:300m (621 MB) indexó nuestros 43 trozos en 3,0 segundos.
Resultado medido: misma recuperación que las palabras clave (15 de 15) y mismos aciertos (18/18 con los dos modelos locales), pero más lento: 4,8–6,4 segundos por pregunta. La lentitud se debió a que, con un solo modelo cargado a la vez, Ollama alternaba en memoria el modelo de embeddings y el de chat. Con un corpus grande o preguntas formuladas con otras palabras, los embeddings deberían ganar; eso no lo medimos.
Cuál elegir, en una lista
Resultados de nuestra prueba con 18 preguntas: con todo en el prompt (contexto subido a 16.384), gemma4:12b acertó 18/18, qwen3.5:9b 17/18 y GPT-6 luna, de nube, 18/18. La única diferencia apareció con qwen3.5:9b y todo el texto delante: respondió «200 euros» donde el documento decía «superior a 150 euros», sin referencia.
- Un documento que cabe con margen en el contexto que tu equipo aguanta: súbelo y mételo entero (1,1–1,3 s por pregunta en nuestra prueba).
- Muchos documentos o uno enorme, y preguntas con el vocabulario del texto: palabras clave. Es lo más rápido y no añade modelos.
- Corpus grande y preguntas con palabras distintas a las del documento: embeddings, aceptando más tiempo y más piezas que mantener.
- Respuestas que alguien va a firmar: cualquiera de las tres, pero con referencia obligatoria a documento y sección.
Cómo comprobar que ha leído lo que tenía que leer
Prepara una batería corta antes de fiarte: una pregunta cuya respuesta esté al final del último documento (si falla, hay corte), otra sin respuesta en el texto (debe decir que no consta, no inventar), y si tienes versiones de una norma, una pregunta donde la versión antigua y la vigente den cifras distintas.
Exige referencia en cada respuesta («DOC-RAG-03 §2») y compruébala tú en el texto. En nuestras 2 preguntas de versión, todos los modelos usaron la política vigente (28 € de comida al día y 105 € por noche) y no la sustituida (24 € y 90 €). Esa pregunta es la que delata a un sistema que recupera el trozo equivocado.
- Resumir documentos con referencias que se pueden comprobar
- Cómo comprobar respuestas de IA: rúbrica y casos
- Responde usando SOLO el contexto. Si el dato no está en el contexto, responde "PENDIENTE".
- Si hay dos versiones de una política, usa la vigente e indícalo.
- Cita el documento y la sección (p. ej. "DOC-RAG-03 §2").
- Devuelve solo JSON: {"respuesta": "...", "referencia": "..."}
Prompt real del script rag.py del laboratorio (04/11/2026).
Casos raros que parecen cortes y no lo son
- PDF escaneado: no tiene texto, solo imagen. Necesitas OCR antes, y el OCR también se equivoca en silencio (lo medimos con facturas).
- Modelo que razona: puede gastar el contexto pensando y devolver la respuesta vacía. Nos pasó con qwen3.5:9b.
- Corrector demasiado estricto: el nuestro dio por mal «Dos semanas» porque buscaba «consecutivas». Lee a mano lo que marque como fallo.
- Velocidad que se hunde: si tienes varios modelos cargados y otros programas abiertos, la VRAM se llena. Con tres modelos y un juego, gemma4:12b bajó de 111 a unos 3,8 tokens por segundo.
Preguntas frecuentes
¿Hay una IA para leer PDF y responder preguntas gratis? Sí: con Ollama y un modelo local como gemma4:12b no pagas por pregunta y el documento no sale de tu PC (con OLLAMA_NO_CLOUD=1 no vimos ninguna conexión externa). Necesitas una gráfica con memoria suficiente o mucha paciencia: solo con CPU, qwen3.5:4b generó 11,9 tokens por segundo frente a 92–95 con GPU.
¿Qué IA lee PDF largos? Cualquiera cuyo contexto sea mayor que el documento más tus instrucciones. En local, eso depende de la memoria de tu gráfica; mide el documento con prompt_eval_count antes de elegir modelo.
¿RAG o meterlo todo en el contexto (RAG vs CAG)? Con pocos documentos que caben, meterlo todo es más simple y en nuestra prueba acertó igual. RAG compensa cuando el corpus no cabe o crece.
¿Puedo chatear con varios PDF a la vez? Sí, troceándolos y buscando entre todos. Pide siempre el documento y la sección de cada respuesta, porque con varios archivos es fácil que mezcle versiones.