RAG vs ajuste fino vs contexto largo: método de decisión para 2026

La generación aumentada por recuperación (RAG), el ajuste fino supervisado y el contexto largo no son tres precios del mismo producto. La recuperación selecciona evidencia al recibir la solicitud. El ajuste fino modifica el comportamiento del modelo a partir de ejemplos. El contexto largo aporta más material dentro de una solicitud. Un sistema de producción puede usar una, dos o las tres técnicas.

La pregunta útil no es qué técnica «gana en 2026», sino qué configuración probada cumple los objetivos de calidad, atribución, frescura, latencia, privacidad y coste del producto con su carga real. Este artículo ofrece un método de ingeniería, no una recomendación de proveedor.

¿Qué ha cambiado para 2026?

Las ventanas de contexto amplias, la caché de proveedores, la recuperación gestionada y los servicios de ajuste compatibles ampliaron el espacio de diseño. No crearon un cruce universal. Los límites, precios, reglas de caché, disponibilidad regional y métodos de ajuste varían según proveedor y modelo, y pueden cambiar más rápido que la aplicación.

Por ejemplo, la guía actual de Google documenta modelos con ventanas de contexto de un millón de tokens o más, recomienda caché para contextos grandes repetidos y advierte que rendimiento y latencia dependen del contexto y la tarea (guía de Google sobre contexto largo). Eso demuestra una capacidad, no promete que deba enviarse completo cada corpus.

¿Cuándo conviene probar el contexto largo?

Prueba una referencia de contexto largo cuando el material pertinente quepa en el límite documentado del modelo, importe conservar las relaciones entre documentos y la solicitud tolere la latencia y los tokens medidos. Puede servir para análisis ad hoc, un conjunto pequeño y estable o sesiones repetidas donde el proveedor registre aciertos reales de caché.

No conviertas un archivo de 10 MB en una cantidad universal de tokens. Codificación, idioma, marcado, imágenes, análisis de documentos, instrucciones, historial, margen de salida y contabilidad del proveedor afectan a la capacidad. Cuenta tokens tras la ingestión de producción y conserva margen. Evalúa la calidad con distintas posiciones y combinaciones de evidencia, no solo con una prueba aislada.

¿Cuándo conviene probar el ajuste fino supervisado?

Es candidato cuando una tarea definida presenta errores recurrentes y hay ejemplos etiquetados, representativos y de calidad. Puede mejorar formato, clasificación, extracción, sintaxis de dominio o comportamiento coherente. Empieza con una referencia de prompt y modelo, identifica errores medidos y reserva datos de evaluación antes del ajuste.

El ajuste fino no actualiza automáticamente otro modelo de embeddings, no garantiza conocimiento factual ni aporta atribución de fuentes. Los documentos cambiantes aún pueden requerir recuperación o contexto suministrado. Google recomienda empezar con prompting, estudiar errores y usar datos etiquetados representativos de producción (guía de ajuste de Vertex AI).

¿Cuándo conviene probar RAG?

RAG es buen candidato cuando solo una parte del corpus importa para cada solicitud, el contenido cambia por separado del modelo, los permisos deben filtrar evidencia o el producto debe mostrar atribución documental. También puede reducir el prompt, pero añade ingestión, fragmentación, indexado, recuperación, reranking, borrado, autorización y observabilidad.

La recuperación no garantiza una respuesta fundamentada. Mide si encontró la evidencia necesaria, si la respuesta la usó bien, si las citas respaldan las afirmaciones y qué ocurre cuando falta o se contradice. La evaluación RAG de NIST TREC trata recuperación, respuesta y atribución como evidencias separadas, no como una única puntuación (resumen del TREC 2025 RAG Track).

¿Alguna técnica garantiza citas o aislamiento entre tenants?

No. RAG puede devolver identificadores de fuente, pero la aplicación debe comprobar que las citas mostradas sustentan la respuesta. El contexto largo puede citar documentos suministrados si conserva referencias estables. Un modelo ajustado puede generar texto con aspecto de cita sin evidencia actual, por lo que las citas suelen requerir evidencia al recibir la solicitud y validación.

El aislamiento entre tenants es una propiedad de autorización de extremo a extremo. Un espacio de recuperación separado ayuda, pero filtros, cachés, logs, prompts, datos de ajuste y evaluación, y retención del proveedor pertenecen al modelo de amenazas. Ninguna etiqueta arquitectónica demuestra aislamiento.

¿Cómo se comparan los costes?

Usa precios actuales y consumo medido. Un modelo mensual útil incluye:

No mantengas plano el coste de RAG mientras crece el corpus. Pueden cambiar ingestión, actualizaciones, almacenamiento, calidad, filtrado y operaciones. No valores el contexto largo con un descuento de caché supuesto: registra tokens de aciertos y almacenamiento reales. Tampoco trates el entrenamiento como único coste del ajuste fino.

¿Cómo ejecutar una prueba de arquitectura justa?

1. Define clases de solicitud, riesgo, frescura, autorización, percentiles de latencia y límites de coste.
2. Crea un conjunto versionado con preguntas, documentos, permisos, evidencia esperada, casos extremos y abstenciones representativos.
3. Construye la referencia más simple basada solo en prompts y luego un candidato mínimo de recuperación, contexto largo o ajuste fino donde lo justifique el análisis de errores.
4. Ejecuta todos con el mismo conjunto congelado y versión del modelo. Registra calidad, cobertura, atribución, seguridad, latencia y coste completo.
5. Prueba actualizaciones, borrados, cambios de permisos, fallos de caché y servicio, y migraciones de proveedor.
6. Elige la configuración mínima que cumpla los umbrales y valídala con tráfico de producción bajo despliegue controlado.

¿Cómo sería el ejemplo de un asistente documental?

Para 100 MB de documentación y 10.000 preguntas mensuales, las cifras solas no eligen la arquitectura. Mide cuánto contenido analizado es pertinente, cuánto cambia, cómo se agrupan las solicitudes, a qué fuentes accede cada usuario y si las respuestas necesitan citas verificables.

Un experimento podría comparar una referencia de recuperación filtrada por permisos con contexto largo sobre conjuntos acotados. Si persisten errores de formato o clasificación, añade un candidato de ajuste fino. Informa distribución real de tokens, caché, llamadas de recuperación y reranking, almacenamiento, percentiles de latencia, calidad y esfuerzo operativo. Una cifra por consulta que omita estas entradas no es un modelo de decisión.

"La arquitectura sigue la evidencia medida de la carga real. Las etiquetas del modelo y el tamaño del corpus no pueden elegir el sistema por sí solos."

¿Cuándo ayudan las arquitecturas híbridas?

Los híbridos se justifican por fallos medidos, no por defecto:

• RAG más contexto largo. Recupera candidatos controlados y conserva más contexto alrededor para sintetizar.
• RAG más ajuste fino. Aporta evidencia actual al recibir la solicitud mientras ajustas un comportamiento, formato o clasificador estable.
• Router más varias rutas. Enruta clases solo tras evaluar errores del router, latencia añadida, carga operativa y ahorro.

Cada ruta añade versiones, permisos, alternativas, monitorización y combinaciones de evaluación. Conserva el híbrido solo si supera los mismos criterios con un margen que compense.

¿Qué debe añadir un equipo de la UE?

Añade ubicación, transferencias internacionales, retención, borrado, subencargados, logs, control de acceso, respuesta a incidentes y condiciones contractuales. «Endpoint de la UE» y «autohospedado» no son conclusiones completas de cumplimiento. Mapea el flujo real y confirma base jurídica y obligaciones con asesoramiento cualificado.

Repite la comparación cuando cambien materialmente corpus, carga, umbral de calidad, modelo, condiciones, precios o regulación. Una cadencia fija de seis meses puede servir de respaldo, pero los cambios son mejores disparadores que una promesa de calendario.