RAG: ¿sigue siendo una competencia diferenciadora?

Un recordatorio breve, porque no es el tema

Un sistema RAG (retrieval-augmented generation) busca, en el momento de la pregunta, fragmentos de documentos considerados pertinentes y se los entrega a un modelo de lenguaje que redacta una respuesta apoyada en ellos. El esquema habitual cabe en una línea: documentos → embeddings → base vectorial → retrieval → LLM. El esquema es correcto, sirve para orientarse y hoy lo conoce casi cualquier candidato que opta a un puesto de GenAI.

Justo por eso ya no demuestra nada. Saber dibujar la cadena indica que has leído la documentación o seguido un tutorial. La pregunta profesional está en otro sitio: ¿qué haces cuando la cadena ya está montada y las respuestas siguen siendo malas? Este artículo describe qué distingue de verdad a alguien capaz de trabajar sobre un sistema RAG, y cómo situar el propio nivel con honestidad.

Por qué el esquema de arquitectura no prueba una competencia

Montar un RAG que funcione sobre un corpus limpio se ha vuelto un ejercicio corto. Las librerías ocultan casi toda la dificultad, los valores por defecto se comportan de forma razonable y una demostración convincente puede prepararse en unas horas. Lo que la demostración no dice es cómo se comporta el sistema con documentos reales: formatos heterogéneos, varias versiones del mismo documento, tablas, escaneos, vocabulario propio del negocio y permisos distintos según el usuario.

La competencia que se busca no es conocer los componentes, sino saber diagnosticar. Cuando una respuesta es incorrecta, ¿sabes decir si el problema viene de la ingesta, del troceado, del retrieval, del contexto entregado al modelo o del modelo? Planteada así en una entrevista, esa pregunta separa perfiles muy rápido.

Ninguna de las prácticas descritas aquí es obligatoria en abstracto. Unos cientos de páginas homogéneas no exigen el mismo dispositivo que una base documental corporativa multilingüe con permisos finos. Parte de la competencia consiste en saber qué se puede dejar fuera.

Lo que ocurre antes del modelo: datos, troceado, metadatos

La calidad de los datos fija el techo

Un sistema de búsqueda no puede devolver información que se perdió en la ingesta. Un PDF cuyas tablas se aplanaron en texto corrido, un documento cuya cabecera de contexto desapareció, dos versiones contradictorias del mismo procedimiento indexadas sin distinguirlas: nada de eso se recupera después con un modelo mejor ni con un prompt mejor. Una parte importante del trabajo real en RAG consiste en mirar los documentos uno a uno, algo que las demostraciones rara vez enseñan.

El troceado no es un parámetro por defecto

El chunking determina qué podrá encontrarse después. Un corte de tamaño fijo parte razonamientos y separa una definición de su ejemplo; un corte guiado por la estructura del documento — títulos, secciones, artículos, preguntas — conserva unidades con sentido para un lector. El solapamiento entre fragmentos, repetir el título de sección dentro de cada fragmento, tratar aparte tablas y listas: son decisiones, no valores que se copian.

Los metadatos son lo que hace explotable un corpus

Fuente, fecha, versión, entidad emisora, idioma, ámbito aplicable, nivel de confidencialidad. Sin ellos no se puede filtrar, ni citar correctamente, ni gestionar la frescura, ni aplicar permisos. Los metadatos suelen ser lo que más falta en proyectos retomados tras una fase de prototipo, y añadirlos después obliga a reindexar.

La estrategia de retrieval: donde se ve la competencia

La búsqueda vectorial por sí sola acerca textos que hablan de lo mismo. Ayuda cuando la pregunta está formulada de otra manera que el documento, y se rompe en cuanto la consulta contiene un identificador, una referencia de producto, un código de error, un nombre propio poco frecuente o unas siglas internas. La búsqueda léxica encuentra exactamente eso y falla con las reformulaciones.

• Búsqueda léxica: sólida con términos exactos, referencias y siglas; ciega ante los sinónimos.
• Búsqueda semántica: sólida ante reformulaciones; puede acercar documentos temáticamente próximos pero inadecuados para el hecho concreto.
• Búsqueda híbrida: cubre parte de ambos puntos ciegos, a cambio de una fusión de puntuaciones que hay que ajustar y evaluar.
• Filtros por metadatos: reducen el espacio de búsqueda a lo aplicable — ámbito, fecha, entidad — antes de cualquier cálculo de similitud.
• Reranking: reordena un conjunto de candidatos más amplio con un modelo más caro y más fino, y a menudo mejora más la calidad percibida que cambiar el modelo generativo.

Enumerar estas opciones tampoco basta. Lo que cuenta es poder decir por qué se eligió una combinación concreta en un corpus concreto, qué mejoró y cuánto costó en latencia.

Lo que recibe el modelo: contexto, citas, permisos, frescura

El paso del retrieval al modelo es donde se pierde mucha calidad. Cuántos fragmentos entregar, en qué orden, con qué truncado, si viajan con ellos el título de sección y la fecha del documento, y qué hace el sistema cuando ningún fragmento supera un umbral de pertinencia. Un sistema dispuesto a responder «no he encontrado apoyo suficiente» suele ser más explotable que uno que responde siempre.

• Citas: vincular cada afirmación a un fragmento identificable, con su fuente y su versión; si no, el usuario no puede verificar la respuesta.
• Permisos: filtrar según los derechos reales de quien pregunta, en el momento de la búsqueda y no después de generar. Un sistema que filtra la respuesta pero deja ver el título de un documento confidencial ya tiene un problema.
• Frescura: definir la frecuencia de reindexación, el tratamiento de documentos obsoletos y el comportamiento esperado cuando conviven dos versiones.
• Trazabilidad: conservar, para una respuesta dada, la consulta, los fragmentos seleccionados y la versión de configuración utilizada.

Evaluar el retrieval por separado de la generación

Probablemente sea el marcador más discriminante. Mientras la evaluación mire solo la respuesta final, se mide una mezcla de dos etapas y no se sabe cuál corregir. Separarlas responde a una pregunta sencilla: ¿el fragmento necesario para responder estaba entre lo que recibió el modelo?

1. 1

   Reunir preguntas reales

   paso 1

   Preguntas que hacen los usuarios, no preguntas construidas a partir de los documentos. Con los expertos de negocio se asocia a cada pregunta el fragmento o fragmentos que contienen la respuesta. Unas decenas de casos bien elegidos valen más que un gran volumen generado automáticamente.

2. 2

   Medir primero el retrieval

   paso 2

   Para cada pregunta, ¿aparece el fragmento esperado entre los resultados y en qué posición? Eso ya separa un fallo de búsqueda de un fallo de redacción, y la medida no depende del modelo generativo.

3. 3

   Medir después la generación

   paso 3

   Con los mismos fragmentos entregados, ¿la respuesta es fiel a ellos, completa, bien citada, y sabe abstenerse cuando falta información? El juicio puede ser humano sobre una muestra o automatizado, siempre que se haya comprobado que la automatización coincide con los expertos en los casos conocidos.

4. 4

   Repetir en cada cambio

   paso 4

   Nuevo troceado, nuevo modelo de embeddings, nuevo umbral, nuevo prompt, nuevo proveedor: se vuelve a pasar la misma serie. Sin eso, cada mejora es una impresión y las regresiones no se ven hasta que las reporta un usuario.

Caso práctico: cambiar de modelo no arregla un mal retrieval

Situación frecuente. Un asistente interno responde de forma incompleta sobre procedimientos internos. El equipo concluye que el modelo es débil y pasa a otro más potente y más caro. Las respuestas quedan mejor escritas, más seguras — y siguen siendo incorrectas en las mismas preguntas.

Latencia, coste, observabilidad, fallos

Un sistema consultado a diario por todo un equipo no tiene las restricciones de una demostración. Cada etapa añadida — búsqueda híbrida, reranking, llamadas múltiples — puede mejorar la calidad y añade retraso y coste. Arbitrar significa saber qué pérdida de calidad es aceptable para mantenerse dentro de un presupuesto sostenible, y poder explicarlo.

• Observabilidad: conservar consultas, fragmentos seleccionados, puntuaciones, latencia por etapa y coste por consulta. Sin esas trazas, cualquier diagnóstico se convierte en una reconstrucción.
• Modos de fallo: caída del proveedor, desbordamiento de contexto, degradación silenciosa tras una reindexación parcial, documentos borrados en origen pero todavía indexados.
• Retorno de usuarios: un canal sencillo para señalar una respuesta errónea, conectado a las trazas, alimenta el conjunto de evaluación con casos reales.
• Coste: la partida dominante no siempre es la evidente; el reranking y las llamadas repetidas pesan a veces más que la propia generación.

Tres niveles, y qué permite afirmar cada uno

No son títulos de puesto, son grados de autonomía. Situarse con honestidad es más sólido que reclamar el nivel superior: en una entrevista la diferencia aparece en la primera pregunta de diagnóstico.

1. 1

   Conocer RAG

   nivel 1

   Entender el principio, el vocabulario, el papel de cada componente y por qué no basta con enviar la pregunta al modelo. Suficiente para un rol de producto, proyecto o negocio que debe dialogar con un equipo técnico. Insuficiente para reclamar competencia de implementación.

2. 2

   Saber construir un prototipo

   nivel 2

   Montar los componentes sobre un caso de uso, tomar decisiones de troceado, obtener respuestas correctas en un corpus controlado y conocer los límites de lo construido. Es un nivel real y describirlo como tal es perfectamente aceptable. Presentarlo como experiencia de producción, no.

3. 3

   Saber operar un RAG en producción

   nivel 3

   Evaluar retrieval y generación por separado, diagnosticar una respuesta errónea, gestionar permisos y frescura, arbitrar calidad frente a coste y latencia, instrumentar, absorber una regresión y una caída de proveedor, mantener el sistema mientras el corpus evoluciona. Es el nivel que suelen buscar las ofertas cuando escriben «experiencia en RAG».

Cómo demostrarlo sin exagerar

Lo que convence no es la lista de herramientas, sino la cadena de decisiones. Una buena respuesta tiene esta forma: este era el problema, esto medí, esto cambié, esto costó, esto no resolví. La última parte cuenta tanto como las demás: nombrar un límite pendiente indica nivel, no debilidad.

Si tu experiencia se detiene en el prototipo, dilo y describe con precisión qué harías antes de pasar a producción. Es una respuesta creíble, verificable, y te evita la siguiente pregunta que no podrías sostener.

• RAG
• Evaluación
• Producción