RAG en local: cuándo merece la pena y cuándo es un juguete

Cada pocas semanas alguien pregunta cómo montar un RAG sobre su documentación. La respuesta corta es que depende de la pregunta que vayas a hacer, y que hay un porcentaje alto de casos donde un grep bien afinado gana. Este artículo es el criterio que aplico antes de levantar nada.

Qué resuelve RAG de verdad

RAG (generación aumentada por recuperación) sirve para una cosa concreta: encontrar trozos de texto relevantes cuando la coincidencia exacta de palabras no funciona.

Gana cuando:

• Las preguntas son conceptuales: “¿cómo decidimos los topes de facturación?”.
• El vocabulario del que pregunta y el del documento no coinciden.
• La información está repartida y hay que juntar varios fragmentos.

Pierde cuando:

• Buscas un identificador, un error exacto o un nombre de función → grep es instantáneo, determinista y no alucina.
• El corpus es pequeño (menos de, digamos, 50 documentos): leerlos enteros es más barato y más fiable que indexarlos.
• Necesitas que la respuesta sea auditable al 100%: con RAG siempre hay un fragmento recuperado y un modelo interpretando.

La decisión, en una tabla

Situación	Herramienta
Busco un error o un ID exacto	grep/ripgrep
Corpus pequeño (< 50 docs)	leer completo, sin índice
Preguntas conceptuales, vocabulario variable	RAG
Necesito citas verificables	RAG con enlaces al fragmento
Datos muy sensibles	local, y solo si el índice se queda en casa

Montar el índice: las decisiones que importan

1. El troceado (chunking)

Es la decisión que más afecta a la calidad y la que menos gente revisa. Trozos demasiado pequeños pierden contexto; demasiado grandes diluyen la señal y encarecen cada consulta.

# Un troceado razonable para documentación técnica:
# respeta los encabezados y no parte código por la mitad.
def chunk(texto, max_tokens=600, solape=80):
    bloques = partir_por_encabezados(texto)
    return [ventana(b, max_tokens, solape) for b in bloques]

Regla práctica: el trozo debe responder por sí solo a una pregunta. Si al leerlo hace falta el párrafo anterior para entenderlo, es demasiado pequeño.

2. El modelo de embeddings

Aquí sí conviene gastar un poco de cabeza: un modelo malo de embeddings hace que el problema parezca de “generación” cuando en realidad es de recuperación. Y ojo con mezclar idiomas: si el corpus está en español, el modelo tiene que ir bien en español, no solo en inglés.

3. El re-ranking

Recuperar 20 candidatos y quedarse con los 5 mejores cuesta poquísimo y suele mejorar el resultado más que cambiar de modelo generador.

Cómo evaluar sin engañarte

La trampa clásica es probar con 5 preguntas que tú mismo has escrito sabiendo ya la respuesta: todo funciona. El método que uso:

1. Conjunto de preguntas reales (20-30), incluyendo las que sabes que fallan.
2. Para cada una, marcar qué documento debería salir. Sin esto no hay evaluación posible.
3. Medir dos cosas separadas: ¿recuperó el documento correcto? y ¿la respuesta final fue correcta?.
4. Repetir con grep como línea base. Si tu RAG no supera al grep en recuperación, no merece la complejidad.

Si no puedes medir si el sistema acierta, no tienes un sistema: tienes una demo.

Lo que se rompe en producción

• Índice desactualizado. Si los documentos cambian y el índice no, el RAG responde con datos viejos con total seguridad. La reindexación tiene que ser parte del flujo, no un script manual que se olvida.
• Coste por consulta descontrolado. Recuperar 50 fragmentos y pasarlos todos al modelo multiplica el coste sin mejorar la respuesta.
• Confianza excesiva en la respuesta. RAG no elimina las alucinaciones: las reduce cuando la recuperación es buena, y las esconde cuando es mala. Hay que citar siempre el fragmento de origen y comprobarlo.

Mi conclusión

Para buscarme a mí mismo entre mis notas: grep y nombres de fichero decentes. Para preguntas conceptuales sobre documentación larga y cambiante: RAG, con índice local, troceado que respeta la estructura y evaluación medida. Y en cualquier caso, la decisión se toma con el conjunto de preguntas reales delante, no con la sensación de que las respuestas suenan bien.