# RAG: darle al modelo los datos que no tiene

> La generación aumentada por recuperación busca los fragmentos relevantes con embeddings y los pega al prompt. Es la forma más barata de que un modelo hable de tus datos sin reentrenarlo.

- Fuente canónica: https://www.ricardovelit.com/blog/p/rag-recuperacion-aumentada
- Nivel: intermedio · Lectura: 2 min · Publicado: 2026-09-08
- Etiquetas: rag, embeddings, busqueda
- Conviene leer antes: [que-son-los-embeddings](https://www.ricardovelit.com/blog/p/que-son-los-embeddings.md)
- Relacionados: [bases-de-datos-vectoriales](https://www.ricardovelit.com/blog/p/bases-de-datos-vectoriales.md), [temperatura-y-muestreo](https://www.ricardovelit.com/blog/p/temperatura-y-muestreo.md)
- Contiene componentes interactivos que solo funcionan en la versión web.

---
## El problema

Un modelo de lenguaje sabe lo que había en sus datos de entrenamiento hasta cierta fecha.
No sabe qué dice tu manual interno, tu contrato o el ticket que abrieron esta mañana. Y si
le preguntas, **inventará una respuesta plausible** con total seguridad.

Hay dos formas de arreglarlo: reentrenar el modelo con tus datos (caro, lento, y hay que
repetirlo cada vez que cambian) o **darle los datos en el momento de la pregunta**. Lo
segundo es RAG: *Retrieval-Augmented Generation*.

## Las tres etapas

```text
1. Indexar    documentos → trozos → embeddings → índice
2. Recuperar  pregunta → embedding → los k trozos más cercanos
3. Generar    prompt = instrucciones + trozos recuperados + pregunta → modelo
```

La magia está en la etapa 2, y no es magia: es la
[similitud coseno entre embeddings](/p/que-son-los-embeddings) aplicada a gran escala. La
pregunta se convierte en un vector; los trozos cuyo vector está más cerca son los que
probablemente contienen la respuesta.

## El detalle que decide si funciona: el troceado

Los documentos no se indexan enteros. Se cortan en **fragmentos** (*chunks*) de unos
cientos de tokens. El tamaño importa más de lo que parece:

| Fragmentos | Ventaja | Problema |
| --- | --- | --- |
| Pequeños (100–200 tokens) | Muy precisos: el vector representa una sola idea. | Pierden contexto: "él firmó" sin saber quién es él. |
| Grandes (800+ tokens) | Conservan el contexto. | El vector se diluye entre varias ideas; recupera peor. |

Un punto de partida razonable: 300–500 tokens con **solapamiento** del 10–20 % entre
fragmentos consecutivos, para que ninguna frase quede partida sin contexto.

## Qué le dices al modelo

El prompt final no es solo "responde esto". Es una instrucción con reglas:

```text
Responde SOLO con la información de los fragmentos siguientes.
Si la respuesta no está en ellos, di "no lo sé con estos datos".
Cita el fragmento que usaste.

[Fragmento 1] ...
[Fragmento 2] ...

Pregunta: ...
```

Ese "si no está, di que no lo sabes" es lo que convierte RAG en algo fiable. Sin esa
instrucción, el modelo rellena los huecos con su entrenamiento y vuelves al problema
original.

## Lo que RAG no resuelve

- **Preguntas que requieren leer todo.** "¿Cuántas veces aparece X en el corpus?" no se
  responde con los 5 fragmentos más cercanos.
- **Recuperación mala = respuesta mala.** Si el fragmento correcto no aparece entre los
  recuperados, el modelo no puede usarlo. La mayoría de los fallos de RAG son fallos de
  búsqueda, no de generación.
- **Datos contradictorios.** Si dos fragmentos dicen cosas distintas, el modelo elegirá uno
  o mezclará ambos. Hace falta limpiar el corpus, no ajustar el prompt.

## Para llevarte

RAG es **búsqueda semántica + un prompt con reglas**. La calidad depende del troceado y de
la recuperación mucho más que del modelo. Si algo falla, mira primero qué fragmentos se
recuperaron; casi siempre el problema está ahí.