RAG: el conocimiento del cliente dentro del sistema

Llega el momento en que un modelo tiene que responder sobre algo que no vio nunca: el catálogo de tu cliente, sus condiciones de garantía, sus dos mil páginas de manuales internos.

La técnica que resuelve esto se llama RAG —generación aumentada por recuperación— y suena más complicada de lo que es. En una frase: antes de preguntarle al modelo, buscas los fragmentos relevantes y se los pones delante.

Eso es todo. El resto son detalles de implementación, y casi todos los problemas vienen de la parte de buscar, no de la de generar.

Por qué no vale con pegar el documento entero

Dos razones. La primera es coste: pagas por token, y mandar dos mil páginas en cada consulta es insostenible. La segunda es calidad: aunque quepa, la atención del modelo se diluye y responde peor con mucho ruido que con poco contexto bien elegido.

Así que el trabajo real es elegir bien los cinco párrafos que hacen falta para esta pregunta concreta.

Cómo se busca por significado

El truco está en convertir el texto en números. Un modelo de embeddings transforma cualquier fragmento en una lista de números que representa su significado, de forma que fragmentos que hablan de lo mismo quedan cerca aunque usen palabras distintas.

Guardas todos esos vectores en una base preparada para buscar por cercanía. Cuando llega una pregunta, la conviertes igual, buscas los fragmentos más cercanos, y esos son los que le pasas al modelo.

Por eso «¿me devuelven el dinero si no me gusta?» encuentra el párrafo sobre política de devoluciones aunque no comparta ni una palabra.

Donde de verdad se gana o se pierde: el troceado

Esta es la parte que casi nadie trabaja y la que determina si el sistema funciona.

Trozos muy pequeños pierden el contexto: recuperas una frase que dice «no aplica en ese caso» sin saber a qué caso se refiere.

Trozos muy grandes traen ruido: metes tres temas para responder a uno, y el modelo se despista.

Trocear por longitud fija es lo peor y lo más común. Parte frases y separa un encabezado de su contenido.

Lo que funciona: trocear por estructura. Por apartados, por artículos, por preguntas del documento de preguntas frecuentes. Y arrastrar a cada trozo el título de la sección a la que pertenece, para que el fragmento se entienda solo.

Si un sistema RAG responde mal, mira los trozos antes de tocar el prompt. Nueve de cada diez veces está ahí.

Comprobar lo que recupera, no solo lo que responde

El error de diagnóstico más frecuente: el sistema contesta mal y se culpa al modelo.

Antes de eso, mira qué fragmentos recuperó. Si le pasaste los párrafos equivocados, ningún modelo puede acertar. Y si le pasaste los correctos y aun así falló, entonces sí es problema de instrucción.

Monta desde el principio una forma de ver los fragmentos recuperados en cada consulta. Sin esa ventana, estás depurando a ciegas.

La regla que hace vendible el sistema

Que cite de dónde lo saca.

Cuando la respuesta va acompañada del documento y el apartado de origen, pasan tres cosas: el usuario puede comprobarlo, tú puedes depurar, y el cliente confía. Un sistema que responde sin fuente es un sistema que nadie puede auditar, y en cuanto se equivoque una vez, dejará de usarse entero.

Y una segunda regla, complementaria: cuando no encuentre nada relevante, que lo diga. Un RAG que siempre contesta algo es un RAG que se inventa cosas cuando no sabe. Fija un umbral: si lo más cercano no está lo bastante cerca, la respuesta correcta es «no tengo esa información».

El coste que aparece después: mantener el índice

Un RAG no se monta una vez y se olvida. Los documentos del cliente cambian: se actualiza una tarifa, se revisa una condición, se retira un producto. Si tu índice sigue guardando la versión vieja, tu sistema responderá con seguridad absoluta usando información caducada — y eso es peor que no responder, porque nadie sospecha.

Decide desde el principio cómo se actualiza: cada cuánto se revisan los documentos de origen, qué pasa cuando uno se borra y cómo evitas que convivan dos versiones del mismo texto. Guarda junto a cada fragmento la fecha del documento del que salió; te permite tanto avisar de que algo es antiguo como depurar cuando algo no cuadra.

Es la parte que no se ve en ninguna demostración y la que decide si el sistema sigue siendo útil al año siguiente.

Cuándo NO usar RAG

Se ha convertido en la respuesta automática a todo, y muchas veces no es la mejor.

Si la información cabe entera en el contexto —un documento de veinte páginas— pásasela y ya está. Montar toda la maquinaria para eso es complicarse.

Si la respuesta requiere contar, sumar o cruzar registros, RAG es la herramienta equivocada: eso es una consulta a una base de datos. «¿Cuántos pedidos hubo en marzo?» no se responde buscando párrafos parecidos.

Si la información cambia cada minuto, tendrás que resolver también la actualización de los vectores, que es un problema propio y a menudo el más caro de mantener.