El patrón más sencillo consiste en proporcionar al modelo toda la información necesaria junto con la petición. No hay índice vectorial, chunking ni pipeline de recuperación.

Imaginemos una aplicación que analiza el manual interno de un equipo, un contrato concreto o el código de un repositorio pequeño. Si el contenido cabe en el contexto aceptado por el modelo y el coste es razonable, introducir una infraestructura RAG completa puede aportar más complejidad que valor.

Las ventanas de contexto actuales pueden ser enormes. Google documenta modelos Gemini con ventanas de un millón de tokens o más y plantea explícitamente el contexto largo como alternativa viable para determinados problemas que anteriormente requerían RAG. También advierte de que enviar más información tiene implicaciones de coste y latencia y que la recuperación sobre contextos muy grandes no es perfecta en todos los escenarios.

Cuándo tiene sentido

El contexto directo encaja especialmente bien cuando:

• El corpus es pequeño o mediano.
• Cambia poco.
• Cada consulta necesita buena parte de los documentos.
• Quieres reducir componentes de infraestructura.
• El número de consultas no hace prohibitivo reenviar el mismo contenido.

La caché de contexto puede cambiar todavía más esta ecuación cuando muchas peticiones reutilizan un prefijo grande de información. La documentación actual de Gemini, por ejemplo, contempla caching explícito e implícito para reducir el coste asociado a esos patrones.

Su principal limitación

Que algo quepa en la ventana de contexto no significa que debamos enviarlo siempre. Más tokens implican más datos que procesar y normalmente más tiempo hasta obtener la respuesta. Además, en problemas con múltiples piezas concretas de información escondidas en un contexto enorme, la precisión puede degradarse. Por eso el tamaño máximo de contexto no debería convertirse en un objetivo de arquitectura.

La pregunta correcta no es cuánto contexto admite el modelo, sino cuánto contexto necesita realmente para responder.

Opción 2: búsqueda semántica

La búsqueda semántica intenta recuperar contenido por significado y no únicamente mediante coincidencias literales.

Para ello, normalmente convertimos documentos y consultas en embeddings: representaciones vectoriales que permiten calcular qué fragmentos están semánticamente próximos.

Supongamos que un usuario pregunta:

«¿Qué ocurre si un empleado deja la empresa?»

El documento quizá no contiene esa frase. Puede hablar de «procedimiento de baja», «revocación de credenciales» o «offboarding».

Una búsqueda literal podría perder información relevante. Una búsqueda basada en embeddings tiene más posibilidades de relacionar ambos conceptos.

Cuándo funciona bien

La búsqueda semántica es atractiva cuando:

• Los usuarios formulan preguntas con vocabulario diferente al de los documentos.
• Queremos descubrir contenido conceptualmente similar.
• Existen grandes cantidades de texto no estructurado.
• No necesitamos generar siempre una respuesta: quizá solo queremos devolver documentos relevantes.

Este último punto es importante.

Una búsqueda vectorial no es RAG por sí misma.

Puedes usar embeddings para un buscador interno, recomendaciones o detección de similitud sin que intervenga ningún LLM generativo.

El problema de utilizar solo vectores

El significado no lo es todo.

Hay consultas donde una coincidencia exacta importa mucho:

• ERR_CONNECTION_RESET;
• SKU-28491;
• Factura 2026-00381;
• nombres propios;
• versiones;
• fechas;
• referencias legales.

Microsoft destaca precisamente esta diferencia: la búsqueda vectorial funciona bien para similitud conceptual, mientras que la búsqueda textual mantiene ventajas para coincidencias exactas y terminología especializada.

Eso nos lleva a una arquitectura cada vez más habitual.

Opción 3: búsqueda híbrida

La búsqueda híbrida ejecuta dos estrategias a la vez:

• búsqueda textual o keyword
• búsqueda vectorial.

Después combina sus resultados.

Azure AI Search, por ejemplo, ejecuta ambas consultas en paralelo y fusiona sus rankings mediante Reciprocal Rank Fusion RRF, para obtener un único conjunto ordenado de resultados. También permite añadir reranking semántico posteriormente.

Este enfoque resuelve una debilidad frecuente de los sistemas puramente vectoriales.

Pensemos en:

«¿Qué cambios afectan al endpoint /v2/orders en la versión 4.3?»

La similitud semántica puede localizar documentación relacionada con pedidos y APIs.

La búsqueda textual puede garantizar que aparezcan resultados que contienen exactamente /v2/orders y 4.3.

La combinación suele proporcionar una recuperación más robusta.

Una regla práctica

Cuando tus datos contienen una mezcla de lenguaje natural y elementos que deben coincidir exactamente  (códigos, nombres, números, fechas o identificadores), evalúa búsqueda híbrida antes de apostar exclusivamente por vectores.

No significa que siempre gane. Significa que deberías medirla.

Opción 4: RAG

RAG empieza a aportar todo su valor cuando la información disponible supera lo que tiene sentido enviar directamente al modelo y debemos seleccionar dinámicamente qué contexto utilizar.

Un pipeline habitual puede parecerse a esto:

fuentes → ingestión → chunking → índices → recuperación → reranking → construcción del contexto → LLM → respuesta

La ventaja fundamental es la escalabilidad. El modelo no tiene que recibir toda la base documental. Solo recibe una selección de evidencia potencialmente relevante.

Anthropic describe el mismo principio al explicar que RAG permite escalar a bases de conocimiento que exceden la ventana de contexto: el sistema recupera solamente fragmentos relevantes y los incorpora a la petición.

Pero cada etapa añade decisiones nuevas.

Chunking

¿Cómo dividir documentos?

Un fragmento demasiado pequeño puede perder contexto. Uno demasiado grande incorpora ruido y consume más tokens.

Anthropic ha mostrado precisamente cómo los chunks aislados pueden perder información esencial, por ejemplo, a qué empresa o periodo pertenece una cifra, y propone añadir contexto específico a cada fragmento antes de indexarlo mediante su enfoque de Contextual Retrieval.

Recuperación

¿Cuántos resultados recuperamos?

Recuperar poco puede dejar fuera la respuesta correcta. Recuperar demasiado introduce ruido y aumenta el contexto enviado.

Reranking

Una primera búsqueda puede generar candidatos rápidamente. Un reranker posterior puede volver a ordenarlos utilizando una evaluación semántica más potente.

Filtros y seguridad

En aplicaciones empresariales, relevancia no equivale a autorización. Un documento puede ser perfecto para responder una pregunta y, aun así, el usuario no debería poder verlo. Por eso permisos, tenant, departamento, región, versión o clasificación del documento deben formar parte del diseño de recuperación y no añadirse como parche después.

Observabilidad

Un sistema RAG necesita responder preguntas que una llamada sencilla a un LLM no plantea:

• ¿se recuperó el documento correcto?
• ¿el problema fue retrieval o generación?
• ¿qué chunks llegaron al modelo?
• ¿qué puntuación tenían?
• ¿qué versión del documento se utilizó?
• ¿el modelo respondió utilizando realmente la evidencia recuperada?

Sin esa observabilidad, optimizar RAG se convierte rápidamente en ensayo y error.