RAG en 2026: arquitectura, embeddings y cuándo (no) usarlo

RAG (retrieval-augmented generation) lleva desde 2023 presentado como la solución por defecto para que un modelo responda con información que no estaba en su entrenamiento. Es una descripción incompleta: RAG no es una técnica, es un pipeline con media docena de piezas independientes, y la mayoría de los “RAG que no funcionan bien” fallan en una pieza concreta —casi siempre el chunking o la ausencia de reranking— no en la idea general.

Este artículo describe cómo es ese pipeline en detalle, y también cuándo montar uno es la decisión correcta y cuándo es sobreingeniería para un problema que se resuelve más simple.

Anatomía de un pipeline RAG

graph LR
D[Documentos] --> C[Chunking]
C --> E[Embeddings]
E --> V[(Base de datos vectorial)]
Q[Pregunta del usuario] --> QE[Embedding de la query]
QE --> R[Retrieval]
V --> R
R --> RR[Reranking]
RR --> G[Generación]
G --> RES[Respuesta]

1. Ingesta y chunking

Antes de poder buscar nada hay que partir los documentos en fragmentos (chunks) que quepan en un embedding y sean lo bastante autocontenidos como para ser útiles por sí solos. Este paso es, en la práctica, donde más pipelines RAG fallan sin que nadie lo note hasta que alguien pregunta algo que debería tener respuesta y no la obtiene.

El error clásico es partir por número fijo de caracteres o tokens sin mirar la estructura del documento: un chunk que corta una tabla a la mitad, o que separa una afirmación de la frase que le da contexto (“esto aplica solo si el cliente es Enterprise”), pierde la información que hacía útil ese fragmento en primer lugar.

Anthropic publicó una técnica —contextual retrieval— que ataca directamente este problema: antes de generar el embedding de cada chunk, se le antepone un fragmento corto (50-100 tokens) que sitúa ese chunk dentro del documento completo (“esta sección trata sobre X en el contexto del documento Y sobre Z”), generado por un modelo barato a partir del documento entero. Según los datos publicados por Anthropic, esta técnica reduce los fallos de retrieval en un 49%, y hasta un 67% cuando se combina con reranking. El coste adicional es una pasada de generación por chunk durante la ingesta, no en cada consulta, así que no afecta a la latencia en producción.

async function chunkConContexto(documento: string, chunk: string): Promise<string> {
  const contexto = await generarContextoBreve(documento, chunk); // modelo barato, offline
  return `${contexto}\n\n${chunk}`;
}

2. Embeddings

El embedding convierte cada chunk (y cada query) en un vector que captura significado semántico, no solo coincidencia de palabras. La oferta en 2026 se ha consolidado en unos pocos modelos de referencia: text-embedding-3-large de OpenAI (hasta 3.072 dimensiones), la familia voyage-3 de Voyage AI (mejor puntuación MTEB de la comparativa, especialmente fuerte en código y documentación técnica), Gemini Embedding 2 de Google (el primer modelo de Google con soporte multimodal completo) y BGE-M3 como alternativa open source con soporte para búsqueda densa, dispersa y multi-vector en un único modelo.

Para la mayoría de aplicaciones RAG de texto, text-embedding-3-small sigue siendo el punto de partida razonable: buen equilibrio entre calidad, velocidad y coste. Voyage compensa su precio más alto cuando el corpus es predominantemente código o documentación técnica, donde su ventaja de precisión es más consistente.

import { embed } from 'ai';
import { openai } from '@ai-sdk/openai';

const { embedding } = await embed({
  model: openai.embedding('text-embedding-3-small'),
  value: chunkConContexto,
});

3. Almacenamiento y retrieval

El vector se guarda en una base de datos con capacidad de búsqueda por similitud (normalmente coseno o producto interno). No hace falta un motor dedicado desde el primer día: si ya usas PostgreSQL, pgvector —sobre todo combinado con la extensión pgvectorscale— resuelve bien la búsqueda vectorial hasta el entorno de las decenas de millones de vectores, con la ventaja operativa de que los datos vectoriales viven en la misma base de datos y la misma transacción que el resto de tu aplicación, sin un sistema adicional que sincronizar. Cubrimos esto en detalle en nuestro artículo sobre bases de datos vectoriales, pgvector y embeddings.

El retrieval puro por similitud vectorial (dense retrieval) no siempre es suficiente: falla en búsquedas por coincidencia exacta (un código de producto, un identificador) que un embedding puede no distinguir bien de términos parecidos. La combinación de búsqueda densa (semántica) con búsqueda dispersa tipo BM25 (léxica), fusionando ambos rankings, es el patrón que mejor cubre los dos tipos de consulta a la vez.

4. Reranking

El primer retrieval suele traer de vuelta más candidatos de los que se van a usar (por ejemplo, 100-150), priorizados con un modelo de embeddings relativamente barato. El reranker es un segundo paso, con un modelo más caro pero mucho más preciso (típicamente un cross-encoder, que evalúa la query y el documento juntos en vez de comparar vectores por separado), que reordena esos candidatos para quedarse con los 10-20 mejores antes de pasarlos al modelo de generación.

Saltarse este paso es, junto con el chunking naíf, la causa más común de que un sistema RAG “recupere cosas que no son relevantes”: el embedding es una aproximación barata y razonablemente buena, pero no está optimizado para precisión fina en el top de la lista, que es justo lo que importa cuando solo vas a pasarle al modelo un puñado de fragmentos.

5. Generación

Con los fragmentos ya rankeados, se construye el prompt final: system prompt con instrucciones sobre cómo usar el contexto (incluida la instrucción explícita de no responder si la información no está en los fragmentos recuperados, para reducir alucinaciones) y los chunks seleccionados, normalmente con su fuente para poder citarla.

RAG vs. fine-tuning vs. contexto largo

Los tres enfoques resuelven problemas distintos y la pregunta correcta no es cuál “gana” en general, sino cuál encaja con tu restricción real.

El patrón que domina en producción durante 2026 no es elegir uno, es combinar fine-tuning y RAG cuando ambos problemas coexisten: el fine-tuning enseña cómo razonar y responder en el dominio (tono, formato, patrones de la tarea), y RAG aporta sobre qué razonar en el momento de la consulta, con datos que pueden haber cambiado después del último entrenamiento.

Cuándo RAG es sobreingeniería

• El corpus es pequeño y estático. Si toda la base de conocimiento cabe cómodamente en la ventana de contexto del modelo y no cambia cada semana, meter ese contenido directamente en el prompt (o en caché de contexto, si el proveedor lo ofrece) es más simple, más barato de mantener y evita toda la maquinaria de chunking, embeddings e índices.
• La necesidad real es una única consulta estructurada. Si lo que hace falta es “dame el estado del pedido X” o “cuál es el precio de este producto”, eso es una llamada a una función o una query SQL directa, no una búsqueda semántica sobre fragmentos de texto. Envolver una consulta exacta en un pipeline de similitud vectorial añade latencia e imprecisión donde ya existía una respuesta exacta.
• Nadie ha medido el retrieval por separado de la generación. Si el “no funciona bien” que reportan los usuarios en realidad viene de un retrieval que no encuentra los fragmentos correctos, ningún ajuste al prompt de generación lo va a arreglar. Evaluar retrieval y generación como dos problemas distintos —con métricas propias para cada uno— es lo que permite saber cuál de las dos piezas hay que mejorar.
• El caso de uso necesita comportamiento consistente, no conocimiento actualizado. Si lo que se busca es que el modelo siempre responda con un formato o tono determinado, fine-tuning resuelve eso de forma más directa y barata en inferencia que intentar forzarlo con instrucciones en un prompt cada vez más largo.

Errores frecuentes en producción

• Medir “funciona” de forma cualitativa en vez de con un conjunto de preguntas de evaluación fijo con respuestas conocidas, lo que hace imposible saber si un cambio en el pipeline mejora o empeora las cosas.
• No reindexar cuando el contenido fuente cambia, dejando que el sistema responda con seguridad usando información obsoleta.
• Ignorar el coste de reranking a escala: es efectivo, pero añade latencia y coste por consulta que hay que presupuestar, no descubrir en la factura del primer mes en producción.
• Elegir el tamaño de chunk de forma arbitraria y no revisarlo nunca más, cuando en realidad depende del tipo de contenido (un chunk pequeño funciona mejor para FAQs cortas; uno más grande, para documentación técnica con contexto interdependiente).

La pregunta que decide

Antes de montar un pipeline RAG completo, merece la pena preguntarse qué problema concreto resuelve que no resuelva ya meter el contenido en el contexto o hacer una consulta directa. Si la respuesta es “el corpus es demasiado grande, cambia con frecuencia, y necesito citar de dónde sale cada dato”, RAG es la herramienta correcta y vale la pena invertir en hacerlo bien —chunking cuidado, embeddings adecuados al dominio, reranking, evaluación separada de cada etapa—. Si la respuesta es más vaga que eso, probablemente estás resolviendo con infraestructura un problema que una consulta directa o un prompt más largo ya resolvían.