Qué es RAG (generación aumentada por recuperación)

Un LLM solo sabe lo que vio en el entrenamiento. No conoce el manual interno de tu empresa, el catálogo que actualizaste ayer ni la documentación de tu producto. Si le preguntas sobre eso, admitirá que no sabe o inventará una respuesta que suena verdadera.

RAG (del inglés retrieval-augmented generation, generación aumentada por recuperación) lo resuelve sin entrenar nada. Antes de preguntarle al modelo, tu código busca los fragmentos más relevantes en tus propios datos y se los entrega junto con la pregunta. El modelo pasa a responder leyendo, no recordando.

¿Cómo funciona un sistema RAG?#

Son dos fases. La primera corre una vez (y de nuevo cuando los datos cambian); la segunda corre con cada pregunta.

Indexación:

1. Reúnes los documentos (PDF, páginas, artículos de ayuda, filas de una base de datos).
2. Divides cada uno en pedazos más pequeños, los chunks.
3. Generas un embedding de cada chunk con un modelo de embeddings.
4. Guardas el chunk y su embedding en un índice.

Consulta:

1. El usuario hace una pregunta.
2. Generas el embedding de la pregunta con el mismo modelo.
3. Buscas en el índice los k chunks más cercanos (recuperación).
4. Armas un prompt con esos chunks como contexto.
5. Envías el prompt al LLM, que genera la respuesta.

El "aumentada" del nombre viene del paso 4: el prompt se aumenta con información recuperada.

¿Qué son los chunks y los embeddings?#

Un chunk es un fragmento de texto lo bastante pequeño para caber en el prompt junto con varios otros, y lo bastante grande para tener sentido por sí solo. Un párrafo o una sección corta suele funcionar. Los chunks muy pequeños pierden contexto, y los muy grandes diluyen el tema y gastan tokens.

Un embedding es una lista de números que un modelo genera para representar el significado del texto. Textos con significado parecido generan vectores cercanos, aunque no compartan palabras. Eso es lo que permite encontrar "cómo pido que me devuelvan el dinero" cuando el documento dice "política de reembolsos". Guardar esos vectores y buscar por cercanía es el trabajo de una base de datos vectorial.

¿Cómo se ve RAG en código?#

El ejemplo de abajo muestra el esqueleto completo en Python, sin dependencias. Para que sea ejecutable, la recuperación usa coincidencia de palabras en vez de embeddings, y el resultado es el prompt que enviarías al LLM.

import math
import re
from collections import Counter

DOCS = [
    "Los reembolsos se aceptan hasta 7 días después de la compra.",
    "El soporte atiende de lunes a viernes, de 9 a 18 h.",
    "Para cambiar la contraseña, abre Configuración y haz clic en Seguridad.",
]

def tokens(texto):
    return re.findall(r"\w+", texto.lower())

def similitud(a, b):
    ca, cb = Counter(tokens(a)), Counter(tokens(b))
    prod = sum(ca[t] * cb[t] for t in ca)
    norma = math.sqrt(sum(v * v for v in ca.values())) * math.sqrt(sum(v * v for v in cb.values()))
    return prod / norma if norma else 0.0

def recuperar(pregunta, k=1):
    return sorted(DOCS, key=lambda d: similitud(pregunta, d), reverse=True)[:k]

def armar_prompt(pregunta):
    contexto = "\n".join(recuperar(pregunta))
    return (
        "Responde usando solo el contexto de abajo. "
        "Si la respuesta no está en él, di que no lo sabes.\n\n"
        f"Contexto:\n{contexto}\n\nPregunta: {pregunta}"
    )

print(armar_prompt("¿Cuántos días tengo para pedir un reembolso después de la compra?"))

La salida es el prompt con el fragmento sobre reembolsos en el contexto. Fíjate en que la búsqueda por palabras es frágil: "reembolso" y "reembolsos" son tokens distintos, y el acierto vino de palabras como "días", "después" y "compra". En un sistema real, cambias esta búsqueda por embeddings, que miden la similitud por significado. El resto del flujo (armar el prompt y llamar al LLM) queda igual.

¿Cuándo usar RAG y cuándo no?#

RAG funciona bien cuando:

• los datos cambian con frecuencia (precios, documentación, políticas);
• los datos son privados y no están en el entrenamiento del modelo;
• necesitas citar de dónde vino la respuesta, porque cada chunk tiene un origen conocido;
• el volumen de texto no cabe entero en el prompt.

RAG no hace falta cuando:

• todo el contenido cabe en el prompt: en ese caso basta con enviarlo entero;
• quieres cambiar el estilo o el formato de las respuestas, que es trabajo del prompt o del fine-tuning;
• la pregunta exige razonar sobre el conjunto completo (como "resume todo"), porque la recuperación trae solo algunos fragmentos.

¿RAG o fine-tuning?#

El fine-tuning ajusta los pesos del modelo, lo que sirve para comportamiento y estilo. RAG lleva conocimiento al modelo sin cambiarlo, y actualizar la base es solo reindexar los documentos que cambiaron. Y nada impide usar los dos juntos.

¿Cuáles son los límites de RAG?#

• La recuperación decide la calidad. Si la búsqueda trae el fragmento equivocado, el modelo responde bien sobre el tema equivocado. Casi todo ajuste de RAG es un ajuste de recuperación: tamaño del chunk, valor de k, modelo de embeddings.
• La alucinación no desaparece. El modelo puede ignorar el contexto. Instrucciones claras en el prompt y pruebas con preguntas reales reducen el problema.
• Crecen el costo y la latencia. Cada pregunta genera un embedding y envía más tokens al LLM. Mira cómo entra eso en la cuenta en costo de una API de LLM.
• Los datos sensibles exigen cuidado. Lo que está en el índice puede llegar al prompt. Controla quién puede recuperar qué.

Cómo hacerlo en Square Cloud#

Un sistema RAG es una aplicación común: una API que recibe la pregunta, genera el embedding, consulta el índice y llama al LLM. En Square Cloud haces el deploy de esa API en diversos runtimes, como Python y Node.js, en un contenedor aislado y siempre encendido, con las claves de los proveedores en variables de entorno. Mira cómo publicarla en hosting de APIs.

Cada etapa del flujo tiene su lugar:

• Embeddings: un proveedor externo. El runtime de Python trae wheels listas de torch y transformers, pero un modelo local de embeddings no cabe en el Hobby de 1 GB.
• Índice: la plataforma no tiene base de datos vectorial, y el PostgreSQL alojado es el nativo, sin extensiones (nada de pgvector). Usa un servicio vectorial externo o, con unos pocos miles de fragmentos, una búsqueda en memoria dentro de la propia aplicación.
• Documentos y metadatos: hosting de bases de datos desde el Standard (R$44,99 al mes); el Hobby (R$12,49) no incluye bases de datos.
• Generación: desde el Standard, el AI Gateway responde en el formato de chat completions de OpenAI, con el modelo cubic. Apunta el SDK de OpenAI a la base URL https://api.squarecloud.app/v2/ai y usa una clave de API con el scope ai:chat.

El gateway solo hace la generación. Los fragmentos recuperados, el historial y la pregunta deben caber en la ventana de contexto del plan (hasta 16 mil tokens en el Standard, hasta 24 mil en el Pro), así que elige el k y el tamaño de los chunks teniendo eso en cuenta. Está en beta, con acceso anticipado sin costo extra, y los límites pueden cambiar cuando termine la beta. Para un chatbot completo, mira cómo hospedar un chatbot de IA.