En los últimos 18 meses, casi cualquier reunión de descubrimiento que arrancamos con una Pyme termina con la misma frase: "queremos un ChatGPT pero con nuestros documentos". La respuesta del mercado a esto es siempre la misma — RAG (Retrieval-Augmented Generation). Y a veces es la respuesta correcta. Otras veces, te va a costar 6 meses descubrir que no lo era.
Este post recoge el framework que usamos en K2 Labs para decidir, en menos de una semana de trabajo, si un proyecto RAG va a funcionar para un cliente concreto. No es definitivo. Pero nos ha ahorrado tres compromisos que habrían sido catastróficos.
¿Qué es RAG, en cristiano?
RAG es el patrón "busca documentos relevantes, métele esos documentos al modelo, y haz que conteste con esa información". Es la diferencia entre preguntarle algo a un modelo a secas y darle top-k fragmentos de contexto antes de la pregunta.
Mecánicamente, son tres piezas:
- Indexación: tus documentos se trocean en chunks, se vectorizan con embeddings y se guardan en un vector store.
- Recuperación: ante una pregunta, buscas los chunks más similares.
- Generación: pasas la pregunta + los chunks al LLM y este responde.
En 2026, montar esto con LangChain o llama-index es un viernes de tarde. Lo que cuesta es que responda bien.
Cuándo SÍ tiene sentido
El sweet spot de RAG es bastante específico. Funciona muy bien cuando:
- El usuario hace preguntas de hechos con una respuesta canónica en algún documento.
- Tu corpus es relativamente estable y curado — manuales, políticas, bases de conocimiento internas.
- Hay volumen suficiente de uso para justificar mantener el sistema.
- Aceptas que la respuesta cite fuentes y que el usuario sea capaz de leerlas para validar.
Caso real: una distribuidora industrial con 4.000 fichas técnicas en PDF. Los técnicos del call center pasaban 40% de su tiempo buscando especificaciones. RAG redujo esa cifra a un 8%, con un ROI claro en 3 meses. Aquí, todas las casillas estaban marcadas.
Cuándo NO
Y aquí viene el matiz que rara vez se discute. RAG es una mala idea cuando:
- Las respuestas requieren razonamiento sobre múltiples documentos a la vez que se contradicen entre sí.
- El contenido cambia constantemente y la indexación tiene latencia.
- Las preguntas son procedurales o transaccionales — eso es una API, no un buscador semántico.
- El corpus es pequeño (menos de 100 docs). Un buen prompt con los docs en contexto rinde igual o mejor.
Si el problema se resuelve con búsqueda full-text + un LLM al final, no necesitas RAG. Necesitas Elasticsearch y un prompt.
El framework de decisión en 5 preguntas
En la primera reunión, hacemos esta batería. Si tres o más respuestas son "no", recomendamos otro abordaje.
- ¿La pregunta del usuario tiene una respuesta concreta dentro del corpus?
- ¿El corpus tiene más de 500 documentos significativos?
- ¿La actualización del contenido es semanal o más lenta?
- ¿Existe un baseline humano contra el que medir precisión?
- ¿Los usuarios aceptan una respuesta con citaciones?
Cierre
RAG no es una bala de plata, pero tampoco un fracaso. Es una arquitectura específica para un problema específico. La parte difícil del trabajo de un consultor en 2026 ya no es montar la pipeline — es tener la conversación honesta sobre si tu problema encaja.
Si estás considerando un proyecto así y quieres una segunda opinión antes de comprometerte, escríbenos. Una hora de discovery puede ahorrarte un semestre.