El modelo se niega a leer documentos: prueba en tres proveedores
Prueba de contexto mostró content_filter para cada documento superior a ~2000 tokens en AWS, API del fabricante y Google. Incluso con texto sobre plantas.
👁 114 lecturas
Preparamos una prueba de contexto de modelos: un documento con información oculta, preguntas sobre ella y verificación de cuánto encuentra el modelo. El resultado fue cero, así que por un momento pensamos que el modelo tenía mala memoria. Al revisar la respuesta cruda de la API resultó que el modelo no había leído ni una palabra - la entrada fue rechazada por moderación y devolvió content_filter con native_finish_reason: refusal.
Conclusión en un párrafo
Cero aciertos en una prueba de memoria no siempre es evidencia de contexto corto. En nuestra medición el modelo devolvía content_filter y native_finish_reason: refusal para CADA documento superior a aproximadamente 2000 tokens, y esto en tres proveedores independientes - AWS, API del fabricante y Google. El rechazo afectaba incluso a texto sobre plantas, sin ningún contenido técnico, nombres de herramientas ni nada que pudiera considerarse sensible. Cuando sustituimos el modelo por uno alternativo con el mismo material y las mismas preguntas, acertó 6 de 6 informaciones ocultas en 2,3-4,9 s. Es decir, la tarea era realizable, y el resultado anterior medía moderación, no memoria.
Cómo era la prueba de contexto de modelos
El esquema era simple y deliberadamente aburrido. Tomábamos un documento, insertábamos seis informaciones concretas en diferentes lugares - al principio, en medio, cerca del final - y luego hacíamos seis preguntas, una por cada información oculta. Contábamos aciertos y tiempo de respuesta. Nada más.
El material de prueba lo empezábamos con una versión corta y escalábamos hacia arriba. Esto es importante, porque precisamente este procedimiento permitió ver dónde está el límite. Por debajo de aproximadamente 2000 tokens las respuestas llegaban normalmente. Por encima - content_filter, cada vez, sin excepción.
Para descartar el contenido como causa, cambiamos el documento por un texto sobre plantas. Cero terminología técnica, cero código, cero nada controvertido. Rechazo idéntico.
Tres proveedores, el mismo límite de contexto IA
El primer pensamiento ante un rechazo suele ser: algo en la configuración de ese endpoint concreto. Por eso repetimos la prueba en tres rutas de acceso independientes - AWS, directamente con el fabricante del modelo y en Google. Son infraestructuras separadas, paneles separados, configuraciones de seguridad separadas. El comportamiento fue el mismo.
Este es para nosotros el elemento más contundente de toda la medición. Si el problema estuviera en nuestro código o en un umbral de moderación mal configurado, no se habría repetido en tres plataformas simultáneamente.
| Elemento | Antes del diagnóstico (modelo que rechaza) | Tras el cambio (modelo alternativo) |
|---|---|---|
| Aciertos en información oculta | 0 - sin respuesta de fondo | 6 de 6 |
| Tiempo de respuesta | no aplica - rechazo | 2,3-4,9 s |
| Estado devuelto | content_filter, native_finish_reason: refusal |
finalización normal |
| Umbrales de rechazo | cada documento superior a ~2000 tokens | ninguno |
| Texto sobre plantas | rechazo | procesado |
| Número de proveedores con este comportamiento | 3 de 3 (AWS, fabricante, Google) | 0 |
Por qué «el modelo se niega a responder» se confunde fácilmente con mala memoria
La mayoría de bibliotecas cliente y capas de abstracción muestran contenido de respuesta vacío o un mensaje sustitutivo breve. El código de motivo de finalización suele estar oculto un campo más adentro y nadie lo mira si el script de prueba simplemente cuenta aciertos. En ese esquema, una cadena vacía se ve exactamente como «el modelo no encontró la información».
El efecto es engañoso, porque el resultado cero encaja con la hipótesis intuitiva. Esperamos que un documento largo sobrecargue la memoria, así que el fallo en un documento largo parece una confirmación. Y estamos midiendo algo completamente distinto: si el material siquiera pasó por el filtro de entrada.
Esta es nuestra opinión, pero creemos que parte de las comparaciones publicadas sobre «límite de contexto IA» miden precisamente moderación. No tenemos datos más allá de nuestra propia medición, así que lo tratamos exclusivamente como hipótesis, no como hecho establecido.
Qué cambió concretamente tras sustituir el modelo
Tras el cambio a otro modelo no tocamos nada más. El mismo documento, las mismas seis preguntas, el mismo orden, la misma infraestructura. Aciertos: 6 de 6. Tiempos: de 2,3 a 4,9 s, dependiendo de lo profundo que estuviera en el documento la información buscada.
La dispersión 2,3-4,9 s también es información. Muestra que el modelo realmente recorre el material, y no responde desde memoria de patrón. Si respondiera con generalidades, los tiempos estarían más igualados.
Lo más importante: si el segundo modelo ejecutó la tarea completa, entonces la tarea era realizable. El cero anterior no era una evaluación de la dificultad de la prueba.
Cuándo sospechar de moderación y no de contexto
De nuestra medición se desprenden varias señales de alerta. Primera: el resultado no se degrada gradualmente, sino que cae de golpe. Un problema real de memoria suele dar una transición suave - primero se pierde una información, luego otra. El filtro de entrada se activa de forma binaria.
Segunda señal: el límite cae en un valor redondo y bajo. Aproximadamente 2000 tokens es decididamente demasiado poco para hablar de agotamiento de ventana de contexto de cualquier modelo contemporáneo. Si el resultado se desploma tan pronto, casi seguro que el contexto no es el culpable.
Tercera: rechazo para contenido seguro. El texto sobre plantas es buen material de control precisamente porque no tiene nada que bloquear. Si también él vuelve con rechazo, la causa está en el volumen o en la configuración, no en el tema.
Cómo comprobarlo tú mismo
- Registra las respuestas crudas completas de la API, no solo el campo con contenido. Te interesan los códigos de motivo de finalización - en nuestro caso fueron
content_filterynative_finish_reason: refusal. - Prepara un documento con seis informaciones ocultas distribuidas de principio a fin del texto. Anota dónde está exactamente cada una.
- Ejecuta la prueba en una versión corta, decididamente por debajo de 2000 tokens. Este es tu punto de referencia - si aquí no funciona, el problema está en el prompt, no en la longitud.
- Aumenta el volumen del documento a saltos y anota en qué valor aparece el primer rechazo. Si el límite cae bruscamente, y no gradualmente, piensa en filtro.
- Sustituye por material temáticamente neutral - en nuestro caso fue texto sobre plantas. Si también él vuelve con rechazo, el contenido no es la causa.
- Repite con un segundo y tercer proveedor. Nosotros comprobamos AWS, API del fabricante y Google. La concordancia de comportamiento en tres plataformas descarta error local de configuración.
- Cambia el modelo por otro, sin cambiar nada más. Si acierta las seis informaciones, tienes prueba de que el test era realizable, y el cero anterior medía otra cosa.
- Registra los tiempos de respuesta por separado para cada pregunta. La dispersión - en nuestro caso 2,3-4,9 s - confirma que el modelo efectivamente busca en el material.
De dónde vienen estos números
Todos los valores provienen de nuestra medición ejecutada antes del 21.09.2026. Probamos un modelo a través de tres rutas de acceso independientes: AWS, API directa del fabricante y Google. Material de prueba: documento con seis informaciones ocultas, escalado en volumen, más versión de control sobre plantas sin contenido técnico. Los rechazos con códigos content_filter y native_finish_reason: refusal ocurrieron para cada documento superior a aproximadamente 2000 tokens en los tres proveedores. El modelo alternativo con el conjunto idéntico de tareas acertó 6 de 6 informaciones ocultas en 2,3-4,9 s. No damos nombres de modelos ni umbrales exactos de moderación, porque no tenemos confirmación de que la configuración del lado de los proveedores haya permanecido sin cambios tras la fecha de medición. Los fragmentos marcados como opinión son nuestras conclusiones, no resultados de medición.
More on this from FULGOR
revista·PNG transparente con Qwen-Image-2.1: canal alfa nativo22,7% de píxeles totalmente transparentes y rango alfa completo 0-255. Cómo pedir transparencia y qué vigilar en imágenes normales.