Por qué dejamos de usar RAG (y nos costó un cliente decirlo en voz alta)

Voy a empezar con la frase que me hizo perder un cliente — uno bueno, no uno chico — en marzo del año pasado:

“— Pero, Maxi, ¿ustedes no usan RAG? — No, no en este caso. — Entonces no es serio.”

Cortó la reunión, se fue con otra factory que sí le prometía "RAG enterprise sobre tus 8.000 documentos". Seis meses después me llamó pidiendo una segunda opinión. El proyecto del competidor estaba pegado, los costos se le habían triplicado, y las respuestas del agente seguían siendo, en sus palabras, "buenas para una demo, terribles para producción".

Le devolví la llamada, le pasé un café, y le dije lo mismo que le había dicho seis meses antes: no es que RAG sea malo. Es que casi nunca es la respuesta correcta a la pregunta que vos creés que estás haciendo.

Primero, qué es RAG (resumen honesto)

RAG —Retrieval-Augmented Generation— es la idea de que, antes de pedirle al modelo que responda, vas a una base con tus documentos, traés los tres o cinco fragmentos "más parecidos" a la pregunta, los pegás en el prompt, y dejás que el modelo redacte la respuesta sobre eso.

El truco está en cómo se mide "más parecidos". Casi todas las implementaciones usan embeddings — convertís cada fragmento en un vector numérico, calculás distancia coseno contra el vector de la pregunta, y traés los más cercanos. Suena elegante. En slides queda hermoso. En producción, es una superficie de error.

Lo que sí indexamos (y por qué)

Acá viene la parte interesante: no es que no indexemos nada. Indexamos un montón. Pero indexamos cosas que tienen estructura conocida — productos, clientes, contratos, tickets, transcripciones de llamadas — y las indexamos por campos, no por similitud semántica. La diferencia parece sutil. No lo es.

Cuando un agente nuestro necesita saber "qué le prometimos al cliente X en febrero", no busca el fragmento que más se parece a esa pregunta. Busca el registro del cliente X, filtra por fecha, y lee. Es la diferencia entre preguntarle a Google y abrir tu carpeta de Drive. Una te da contexto plausible. La otra te da el dato.

Las tres razones por las que sacamos RAG de la mayoría de nuestros agentes

1. La latencia se va al diablo

En papel, una búsqueda vectorial tarda milisegundos. En la práctica, sumás: extracción de embedding de la query, llamada a la base, rerank, post-procesamiento, expansión de contexto, y recién después el LLM empieza a generar. Medimos esto en cinco proyectos distintos: agregaba entre 1,8 y 4,3 segundos a respuestas que tenían que sentirse instantáneas para no romper la conversación.

2. La calidad es no determinística — y nadie te avisa

Cambiás tu modelo de embeddings de v1 a v2, todo se rompe silenciosamente. Re-indexás con un chunking distinto, las respuestas cambian. Agregás 200 documentos nuevos y, sin tocar una sola línea del agente, una respuesta que ayer era buena hoy es ambigua. RAG es un sistema con memoria emocional: se acuerda de cosas que vos no le pediste que se acordara.

3. El modelo, en 2026, ya sabe

Esta es la parte incómoda. Los modelos frontier hoy tienen ventanas de contexto que en 2022 nos hubieran parecido pornografía científica. Para muchos casos de uso donde antes te morías por achicar 8.000 documentos a 5 fragmentos, hoy le pasás los 40 documentos relevantes enteros — y el modelo los procesa mejor, con menos pérdida, que cualquier rerank que vos puedas armar.

No estoy diciendo que metas 40 libros en el prompt. Estoy diciendo que la pregunta correcta no es "¿cómo indexo todo?". Es: "¿cuál es el subconjunto chico, estructurado, y vinculado a esta conversación, que el agente realmente necesita ver?".

Qué hacemos en su lugar

Si me preguntás cómo lo resolvemos, te voy a frustrar — no es una receta, son seis o siete decisiones encadenadas. Pero el espíritu se resume así:

1. Modelamos el conocimiento como datos estructurados antes que como texto suelto. Si algo merece ser respondido con autoridad, tiene que poder consultarse por clave, no por similitud.
2. Le damos al agente herramientas (funciones, no documentos) para preguntarle a esos datos cuando los necesita. El agente decide qué traer; nosotros nos aseguramos de que traer sea barato y exacto.
3. Cuando hay texto suelto que sí o sí tiene que entrar (un contrato firmado, una política), lo metemos entero en contexto en ese turno específico. Sin fragmentar, sin embeddings. El modelo lo lee como lo leería un humano.
4. Versionamos todo. Si cambia una política, cambia una versión del contrato — y el agente sabe a cuál corresponde la conversación que está teniendo. RAG no te da eso gratis; un sistema bien modelado, sí.
5. Medimos en producción contra una batería fija de preguntas reales que un humano ya respondió. Sin esa vara, no sabés si mejoraste o si tu impresión es que mejoraste.

Cuándo sí usamos RAG

No quiero quedar como el fanático que dice que la herramienta está rota. RAG es útil — para casos puntuales. Lo usamos cuando: hay un corpus muy grande de texto genuinamente desestructurado (literatura, papers, jurisprudencia), donde el costo de modelar es prohibitivo y el costo de equivocarse es bajo. Lo usamos también en exploración interna — un buscador para nosotros mismos, no para el cliente final. Y en algún caso aislado de Q&A sobre documentación técnica estática.

Pero "agente comercial que conoce a tu empresa", "agente de postventa que responde a clientes", "agente que toma decisiones operativas" — ninguno de esos tres, en producción, en serio, en escala, lo resolvimos con RAG. Y créeme que lo intentamos.

Lo que el cliente que perdí me enseñó

Cuando me devolvió la llamada seis meses después, le pregunté qué hubiera hecho distinto. Me dijo: "Hubiera escuchado tu por qué. Me vendieron una solución, vos me ibas a vender una decisión". Y tenía razón. RAG llegó a las salas de directorio antes que cualquier conversación honesta sobre arquitectura de agentes. Lo pidieron porque suena a "infraestructura seria". Y todos los proveedores, incluidos los mejores, lo ofrecen — porque negar un default es más caro que cumplirlo.

Nosotros decidimos pagar ese costo. Cada vez que un prospecto nos pregunta "¿usan RAG?", la respuesta honesta es "depende, contame qué querés que el agente haga". A veces ganamos el proyecto. A veces no. Pero los que ganamos, en general, los retenemos.

Si llegaste hasta acá y estás cocinando algo con RAG, no tirés el código. Hacé esto primero: agarrá tus diez últimas respuestas malas del agente, miralas una por una, y preguntate si el problema fue "no encontró el fragmento" o "encontró un fragmento que no debía mirar". Si te pasa lo segundo más del 30% de las veces, ya tenés tu respuesta.

— Maxi