RAG con base vectorial: cuando conviene y cuando no

RAG se ha vuelto la respuesta por defecto para cualquier agente que necesite contexto. Llega un cliente con un bot que responde mal y la primera recomendacion suele ser "metele una base vectorial". En la practica, muchas implementaciones gastan mas en embeddings y almacenamiento de lo que ahorran en soporte. Antes de abrir un indice nuevo conviene mirar tres escenarios concretos y decidir con datos, no con reflejo.

Documentacion tecnica extensa: aqui si gana

Cuando el corpus pasa de varios cientos de paginas y cambia cada semana, el prompt encadenado se queda corto. No hay forma de meter un manual de integracion completo en la ventana de contexto sin recortar justo la parte que el usuario necesita. En un proyecto de soporte a una API interna, el indice vectorial con chunking por seccion y re-ranking sobre los cinco primeros resultados bajo la tasa de respuestas incorrectas de un 34% a un 9%. El costo por embedding fue marginal frente a las horas de soporte que se dejaron de pagar. La clave estuvo en el re-ranking: sin el, la recuperacion traia fragmentos correctos pero mal ordenados y el modelo respondia con la seccion equivocada.

FAQs acotadas para pymes: casi nunca conviene

El caso opuesto es una pyme con treinta preguntas frecuentes estables. Ahi un prompt bien armado con las respuestas embebidas directamente resuelve el 90% de los casos y no agrega latencia. Montar una base vectorial para eso significa pagar embeddings, mantener un pipeline de ingesta y depurar chunking para un corpus que cabe en dos pantallas. Hemos visto equipos invertir semanas en afinar un retriever que responde peor que una lista de instrucciones ordenadas. Si el contenido no cambia y entra en contexto, RAG es sobreingenieria.

Agentes internos sobre bases pequenas: depende del tipo de consulta

El tercer escenario es el mas ambiguo. Una tabla de productos con doscientos registros no justifica un indice vectorial si las consultas son filtros exactos por categoria o rango. Pero si las preguntas son semanticas ("que plan le conviene a una ferreteria con tres sucursales"), la busqueda por similitud empieza a tener sentido. La regla que usamos: si el usuario pregunta con palabras que no aparecen literalmente en los datos, RAG aporta. Si pregunta con los mismos terminos del campo, un filtro SQL es mas rapido y mas barato.

Como medir si la base vectorial realmente sirve

Antes de comprometerse, armamos un set de veinte preguntas reales con su respuesta esperada y comparamos dos versiones del agente: una con prompt encadenado y otra con recuperacion. Medimos tres cosas: precision de la respuesta, latencia p95 y cantidad de consultas que terminan en derivacion a humano. Si la version con RAG no mejora al menos dos de las tres, no vale la pena mantener el pipeline. El chunking y el re-ranking son ajustables, pero hay un techo: cuando el corpus es ruidoso o esta mal estructurado, ningun embedding lo arregla.

La conclusion incomoda es que RAG no es una decision de arquitectura por defecto, sino una respuesta a un problema medido. Si el contexto cabe en el prompt, si las consultas son exactas o si el corpus no cambia, conviene quedarse con lo simple. Cuando el volumen de documentacion crece y las preguntas son abiertas, el indice vectorial se paga solo. La diferencia entre ambos casos se decide con numeros, no con moda.