Los sistemas RAG fallan con datos reales: el culpable es el retrieval, no el modelo

Un pipeline RAG parece magia: carga documentos, los divide en chunks, genera embeddings, conecta una base de datos vectorial. Haz una pregunta — el modelo responde con confianza y en detalle. Muéstraselo al cliente, quedan impresionados. Pero luego comienza la prueba real con preguntas reales, y resulta que el sistema falla en la mitad de ellas.

El Cuello de Botella de RAG

En preguntas reales, el sistema frecuentemente responde incorrectamente. Encuentra el documento equivocado por completo, o encuentra el documento correcto pero extrae el chunk de texto incorrecto, o no recupera nada relevante y el modelo alucina con confianza. Parece que el problema está en el modelo. En realidad, la recuperación es culpable.

GPT-4 y Claude responden perfectamente si se les proporciona el contexto correcto. Si el contexto es incorrecto — la alucinación es garantizada, no importa cuán bueno sea el modelo. El modelo responde solo tan bien como el contexto que se le proporciona.

El problema no está en los modelos. El problema está en la recuperación — en cómo buscamos chunks de documentos relevantes de tu base de datos. Este es el cuello de botella por el cual pasa todo el pipeline de RAG. Si la recuperación le da al modelo el contexto incorrecto, todo lo demás es tiempo y dinero desperdiciados.

"El modelo responde solo tan bien como el contexto que se le proporciona."

Cuando la Recuperación Falla

La recuperación puede fallar por docenas de razones. Aquí están las más comunes:

• Fragmentación demasiado grande o muy pequeña. Un chunk de 512 palabras puede capturar contexto vecino en lugar del fragmento necesario. Una pregunta sobre política de devolución, el chunk contiene descripción de tabla de tamaños
• Embeddings generados para datos en idioma inglés, pero la pregunta está en ruso. La distancia semántica entre el vector de la pregunta y los vectores de documentos es enorme, sin coincidencias
• La pregunta se reformula de tal manera que el vector de su embedding no coincide con los vectores en la base de datos. Buscas "devolver pedido", los documentos contienen "devolución de producto" — semántica diferente
• Documento relevante encontrado en 8º de 10, pero el modelo recibió solo los 5 primeros resultados. El contexto necesario simplemente no cae dentro de la ventana de visibilidad
• Índice lleno de duplicados y ruido. Muchos chunks irrelevantes sacan la información correcta de los resultados

Cada uno de estos problemas lleva al mismo resultado: el modelo alucina en lugar de proporcionar la respuesta correcta.

El Costo de la Recuperación

Optimizar la recuperación no es un hobby para entusiastas. Es trabajo real: una o dos semanas que un desarrollador gasta en análisis revelarán que el sistema está 30-40% por debajo de la precisión esperada. La razón no es el modelo, sino que la recuperación está buscando incorrectamente. En proyectos reales, esta es una pérdida enorme: tiempo gastado en RAG, dinero gastado en infraestructura, y el sistema no funciona porque los vectores de documentos no coinciden con los vectores de preguntas.

Lo Que Esto Significa

RAG funciona solo si funciona la recuperación. Sin ella, incluso el mejor modelo estará equivocado. Esto significa que antes de lanzar RAG a producción, necesitas invertir tiempo serio en optimizar la búsqueda, probar en datos reales, e iterar mejorando el pipeline de recuperación.