Leer tus documentos

Buscar antes de responder

Un LLM sabe lo que fue comprimido en sus pesos durante el entrenamiento. Pero tu documentación interna, tus notas, tus facturas o una página publicada ayer no están necesariamente ahí.

El RAG añade una etapa antes de la generación: buscar documentos relevantes, ponerlos en el contexto, y dejar que el modelo responda con esa información.

Elige una pregunta: se embeddea, se compara con los chunks del corpus, y los más pertinentes se inyectan en el prompt antes de la generación. Es ese desvío el que permite a un LLM responder sobre documentos que nunca vio durante su entrenamiento.

Dos cosas que quedarse de esta manipulación. Primero, los chunks recuperados no son los que contienen las palabras de la pregunta: pregunta "¿cuál es el planeta más grande?" y obtienes los gigantes gaseosos, aunque la palabra "grande" no aparezca en ninguno de esos extractos. Lo que decide es la proximidad en el espacio vectorial, no el vocabulario. Segundo, el modelo nunca ve el corpus entero: solo recibe el puñado de extractos seleccionados. Toda la calidad de un RAG se juega por tanto antes de la generación. Si el chunk bueno no se recupera, ninguna finura de prompt lo salvará — por eso el resto de este capítulo habla sobre todo de troceado y de búsqueda.

De documentos a vectores

Primero se cortan los documentos en chunks. Cada chunk se convierte en un embedding y se guarda en una base vectorial.

Cuando llega una pregunta, también se convierte en vector. Luego buscamos los chunks más cercanos por similitud semántica. No buscamos solo palabras iguales: buscamos significado cercano. (En realidad no se compara con todos los chunks: pasadas unas decenas de miles de vectores, las bases vectoriales usan índices aproximados — HNSW, IVF — que encuentran los vecinos más cercanos sin recorrerlo todo. Es incluso su razón de ser.)

El prompt aumentado

Los chunks recuperados se insertan en el prompt:

Pregunta del usuario + contexto recuperado + instrucciones de respuesta

El modelo no "aprende" esos documentos de forma permanente. Los lee en ese momento, dentro de la ventana de contexto.

Por qué es útil

RAG resuelve tres problemas prácticos:

• actualidad — puedes responder con información más reciente que el entrenamiento
• especialización — puedes usar documentos privados o técnicos
• trazabilidad — puedes mostrar de dónde viene una respuesta

Pero no es magia. Si la búsqueda recupera malos chunks, el modelo razonará con malos datos.

Fragilidades

Un pipeline RAG puede fallar por varias razones:

• chunks demasiado grandes o demasiado pequeños
• embeddings poco adaptados al dominio
• preguntas que necesitan combinar muchas fuentes
• contexto recuperado contradictorio
• modelo que ignora una parte del contexto

La calidad depende tanto del retrieval como del modelo generativo.

¿Qué modelo de embedding usar?

No todas las preguntas llevan a los buenos chunks con el mismo embedding. Un modelo entrenado en español generalista recuperará mal código Python; un modelo entrenado en código recuperará mal intercambios médicos.

Las opciones que vuelven en la práctica:

• text-embedding-3-small / -large (OpenAI) — calidad sólida, generalista, multilingüe. Durante mucho tiempo la opción por defecto al empezar; hoy superada en los benchmarks, pero perfectamente utilizable.
• bge-large / bge-m3 (BAAI) — open-source, excelente en multilingüe. Dominaron los benchmarks MTEB en 2024.
• Gemini Embedding (Google) — a la cabeza del MTEB en inglés.
• Qwen3-Embedding (Alibaba) — el mejor de los modelos de pesos abiertos, que puedes alojar tú mismo.
• Voyage 3.x, Cohere embed-v4, Jina v4 — las referencias comerciales del momento; la última es multimodal (texto e imágenes en el mismo espacio).
• all-MiniLM-L6-v2 (Sentence-Transformers) — pequeño, rápido, desplegable en local. Buena relación calidad/coste para casos simples.
• Modelos especializados por dominio (código, biomédico, jurídico) — siempre mejores en su nicho, más débiles fuera.

Esta clasificación se mueve cada seis meses. Y cuidado al leerla: las puntuaciones del MTEB v2 no se comparan con las de la v1, las tareas cambiaron entre una y otra.

Una regla práctica: probar dos o tres modelos sobre tus datos y tus preguntas. El ranking MTEB no dice gran cosa de tu caso particular.

El reranker: una segunda pasada

La búsqueda vectorial tiene un defecto: es rápida pero gruesa. Un embedding de unos cientos de dimensiones es una media difusa de un texto. Muchos chunks "más o menos relevantes" salen a flote, y los realmente buenos a veces se quedan ahogados.

De ahí una etapa que se ha vuelto estándar en sistemas RAG serios: el reranker.

La idea, en dos pasos:

1. Primera pasada (búsqueda vectorial) — recuperar los 50 o 100 chunks más cercanos. Rápido.
2. Segunda pasada (reranking) — un modelo pequeño (a menudo un cross-encoder) evalúa cada par (pregunta, chunk) juntos, da una puntuación precisa y conserva el top 5–10. Lento por chunk, pero solo se hace sobre los 50 candidatos de la primera pasada.

El reranker ve la pregunta y el chunk al mismo tiempo, lo que el embedding no hace. Capta sutilezas semánticas que la búsqueda vectorial pierde. Cohere, Jina AI, BAAI ofrecen rerankers listos para usar.

Sin reranker, tu RAG se estanca. Con reranker, la calidad sube un escalón sin cambiar el resto del pipeline.

Lo siguiente

Con RAG, el modelo puede consultar documentos. Pero el pipeline clásico — embed, retrieve, generate — es una arquitectura "pasiva": el modelo recibe una pregunta, busca chunks, responde. Desde 2025 le hace competencia en muchos casos de uso la búsqueda agéntica: se le da al modelo una herramienta de búsqueda y se le deja buscar en bucle, reformular, escarbar hasta tener lo que necesita.

Con herramientas, puede hacer todavía más: calcular, llamar APIs, navegar, escribir archivos. Eso nos lleva a los agentes.

Actualizado el 2 de agosto de 2026