RAG: que la IA responda con tus datos, no con lo que inventó

RAG (Retrieval-Augmented Generation, "generación aumentada por recuperación") es la técnica que conecta la IA con tus documentos: antes de responder, el sistema busca los fragmentos más relevantes de tu material y se los pasa al modelo para que conteste con eso. El resultado es una IA que responde desde tu manual, tu base de conocimiento o tus contratos —no desde lo que "recuerda" de internet—, alucina mucho menos y puede citar de dónde sacó cada dato. Si querés un asistente que sepa de lo tuyo y no invente, esto es lo que lo hace posible.

Qué es RAG y por qué no es ingeniería de contexto

Conviene marcar la diferencia de entrada, porque se confunden. La ingeniería de contexto es lo que vos decidís y escribís a mano en el prompt: qué instrucciones ponés, qué ejemplos, qué documento pegás. RAG es el sistema automático que elige esos documentos por vos, en tiempo real, de entre miles. No le pegás el material a mano: armás una base con todo tu conocimiento y, ante cada pregunta, el sistema recupera solo los pedazos que importan y los inyecta en el prompt.

La distinción práctica: una es lo que escribís, el otro es la maquinaria que lo trae solo.

RAG no reemplaza a la ingeniería de contexto: la automatiza a escala. Vos no podés pegar a mano el fragmento correcto de 4.000 páginas en cada consulta; RAG lo hace por vos. Sirve cuando tu conocimiento es más grande de lo que entra (o conviene meter) en un prompt, y cuando cambia seguido.

El pipeline: de tus documentos a una respuesta con fuente

RAG son dos momentos. Uno es el indexado, que hacés una vez —o cada vez que cambian los docs—: partís el material, lo convertís en vectores y lo guardás. El otro es la consulta, que corre en cada pregunta: buscás los fragmentos parecidos y se los das a la IA para que responda. Son cinco pasos en total: chunking, embeddings, base vectorial, recuperación y generación.

# 1. INDEXADO (una vez, o cada vez que cambian los documentos)
for doc in documentos:
    chunks = partir(doc, tamaño=500, solapamiento=80)   # ~500 tokens c/u
    for chunk in chunks:
        vector = embed(chunk)          # modelo de embeddings -> lista de números
        db.guardar(vector, texto=chunk, fuente=doc.nombre)

# 2. CONSULTA (en cada pregunta del usuario)
pregunta = "¿Cuántos días de vacaciones me corresponden el primer año?"
vector_pregunta = embed(pregunta)
top_k = db.buscar_similares(vector_pregunta, k=20)   # los 20 chunks más parecidos

# 3. GENERACIÓN (la IA responde SOLO con esos chunks)
respuesta = llm(prompt_con_contexto(pregunta, top_k))

El embedding es lo que hace magia: convierte texto en una lista de números (un vector) donde lo que significa parecido queda cerca. Por eso "vacaciones" matchea con "días de descanso" aunque no compartan una sola palabra. Y ojo con el k: traer más chunks de los que uno cree ayuda —en las pruebas de Anthropic, recuperar el top-20 rinde bastante mejor que el top-5 o el top-10—, así que arrancá alto y recortá si aparece ruido.

El modelo responde con lo que le trajo el retriever, no con lo que sabe. Si el retriever trae basura o no trae lo justo, la respuesta va a ser mala por más bueno que sea el modelo. El grueso del trabajo de un buen RAG está en las dos primeras etapas: cómo partís y cómo recuperás.

Chunking: cómo partir los documentos sin romper el sentido

No podés indexar un PDF de 200 páginas como una sola pieza: nada sería "parecido" a una pregunta puntual, y le meterías al modelo un bloque enorme de ruido. Lo partís en chunks (fragmentos) de unos cientos de tokens. Dos parámetros mandan: el tamaño (chunks chicos = precisos pero sin contexto; grandes = con contexto pero ruidosos) y el solapamiento (repetir un cacho entre chunks vecinos para no cortar una idea justo al medio).

config_chunking = {
    "tamaño": 500,            # tokens por chunk; apuntá a un rango de 300-800
    "solapamiento": 80,       # ~15% del chunk, para no cortar ideas al medio
    "separadores": ["\n\n", "\n", ". "],   # cortá por párrafo, después por oración
    "metadata": ["fuente", "titulo", "fecha", "url"],  # de dónde salió cada chunk
}

Apuntá a 300–800 tokens por chunk con ~15% de solapamiento, y cortá por estructura (párrafos), no por cantidad de caracteres. Guardá siempre metadata —de qué archivo salió, título, fecha—: es lo que después te deja citar la fuente y filtrar por, digamos, "solo documentos de 2026".

Qué vector DB usar: pgvector, Pinecone o Chroma

La base vectorial guarda los embeddings y encuentra los más parecidos rápido, sin comparar uno por uno. Tres opciones sensatas según dónde estés parado:

• pgvector — una extensión de Postgres. Si ya tenés Postgres, es la más obvia: los vectores viven al lado de tus datos, sin sumar otra pieza de infraestructura. Es producción-grade y alcanza de sobra para la enorme mayoría de los casos.
• Pinecone — servicio administrado, cero mantenimiento, latencia baja a gran escala. Pagás por no ocuparte de la infra.
• Chroma — la más simple para arrancar y prototipar local. Anda bien hasta cierto volumen; cuando pasás de millones de vectores, se queda corta.

-- pgvector: tu Postgres de siempre, ahora con vectores
CREATE EXTENSION vector;

CREATE TABLE chunks (
  id        bigserial PRIMARY KEY,
  texto     text,
  fuente    text,
  embedding vector(1536)          -- dimensión que devuelve tu modelo de embeddings
);

-- índice HNSW para buscar por similitud sin recorrer toda la tabla
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

-- traer los 20 chunks más parecidos a la pregunta (<=> = distancia coseno)
SELECT texto, fuente
FROM chunks
ORDER BY embedding <=> :vector_pregunta
LIMIT 20;

Si ya usás Postgres, empezá con pgvector; no sumes una base nueva hasta que el volumen te lo exija. La base casi nunca es el cuello de botella: lo son el modelo de embeddings, la estrategia de chunking y la metadata que elegiste guardar.

El prompt que inyecta los chunks recuperados

Acá se cierra el círculo. Tomás los chunks que trajo el retriever y los pegás en el prompt con una instrucción clara: respondé solo con esto, y si no está, decilo. Este template es el corazón del asunto —lo que convierte "recuperar texto" en "responder con fuente"—:

Sos el asistente de RRHH de la empresa. Respondé la pregunta del empleado
USANDO ÚNICAMENTE el contexto de abajo. Si la respuesta no está en el
contexto, decí "No lo tengo en la documentación" — no inventes.

Al final, citá entre paréntesis la fuente de cada dato que uses.

<contexto>
[1] (manual-rrhh.pdf) El primer año se generan 14 días corridos de vacaciones...
[2] (convenio-2026.pdf) A partir del quinto año el descanso sube a 21 días...
[3] (politica-licencias.pdf) Las vacaciones se piden con 30 días de aviso...
</contexto>

Pregunta: ¿Cuántos días de vacaciones me corresponden el primer año?

Decile explícito que use SOLO el contexto y que cite la fuente; sin esa instrucción, el modelo mezcla lo recuperado con lo que inventa. Pedir la cita no es cosmético: te deja auditar si la respuesta es real y ataca la alucinación de raíz. Si la fuente no aparece, ya sabés que la IA se lo mandó por su cuenta.

RAG, fine-tuning o meter todo en un contexto largo

Tres formas de que la IA "sepa" de lo tuyo, y se confunden seguido:

• Contexto largo — pegás todo el material en el prompt. Va bien cuando tu base entra en la ventana (como referencia, por debajo de ~200.000 tokens) y usás prompt caching para no pagarla en cada llamada. Simple, pero no escala ni se actualiza solo.
• RAG — recuperás lo relevante de una base grande y cambiante. Es lo que querés cuando el conocimiento no entra en un prompt, se actualiza seguido, o necesitás citar la fuente.
• Fine-tuning — reentrenás el modelo para que adopte un estilo, un formato o una tarea. Cambia el cómo responde, no le agrega hechos frescos: para datos que cambian todo el tiempo, no sirve.

Si el problema es que el modelo no conoce tus datos actualizados, la respuesta es RAG, no fine-tuning. Fine-tuning es para comportamiento; RAG es para conocimiento. Muchas veces lo maduro es combinar: RAG para los hechos, fine-tuning para el tono.

Cuando el RAG básico se queda corto, hay dos palancas concretas antes de tocar el modelo. Una es la búsqueda híbrida: combinar la búsqueda semántica (embeddings) con una de palabra clave clásica (BM25), para que los códigos de error, nombres propios y números exactos no se te escapen. La otra es un reranker, un segundo modelo que reordena los chunks recuperados y deja arriba los más pertinentes.

Y un dato duro para cerrar: agregarle a cada chunk una frase de contexto antes de indexarlo, sumado a esas dos palancas, baja las recuperaciones fallidas hasta un 67% según las mediciones de Anthropic. Traducido: la IA encuentra el fragmento correcto muchas más veces.

Próximo paso

Elegí un solo cuerpo de conocimiento que ya tengas —tu manual de onboarding, tus FAQs, tus contratos tipo— y armá un RAG mínimo sobre eso: partilo en chunks, metelo en pgvector y probá el template de arriba con cinco preguntas reales. Vas a ver al toque dónde falla el retrieval y dónde acierta. Si querés que montemos el pipeline sobre tus documentos y lo dejemos andando en serio, agendá una llamada en /agenda y lo armamos sobre tu caso concreto.