Cuando un asistente basado en RAG — de los que responden usando los documentos de la empresa — da respuestas equivocadas, la reacción instintiva es siempre la misma: «hace falta un modelo más potente» o «reescribamos el prompt». Casi siempre es el movimiento equivocado, y también el más caro. El cuello de botella está antes, en un componente del que se habla poco: el retrieval, es decir, la búsqueda que decide qué documentos acaban ante los ojos del modelo. Si el documento con la respuesta no llega a su mesa, ningún modelo — por grande que sea — puede inventárselo.
Es la continuación natural de las cinco lecciones de nuestra plataforma RAG, donde escribíamos que «la calidad se decide en el retrieval». Aquí explicamos por qué — y sobre todo cómo darse cuenta antes de gastar.
La cifra que circula en las presentaciones
Circula por todas partes la cifra de que «el 95% de los proyectos de IA generativa fracasa». Procede de un informe del MIT (The GenAI Divide, 2025), según el cual el 95% de los proyectos piloto no produce un impacto medible en la cuenta de resultados, frente a una inversión de 30–40 mil millones de dólares.
Tres dosis de honestidad necesarias antes de usar esa cifra: no es un dato específico sobre RAG, sino sobre los pilotos de GenAI en general; «ningún impacto medible en las cuentas» no significa «el sistema no funciona»; y la metodología del informe ha sido cuestionada por la fragilidad de la muestra respecto al titular.
Dicho esto, el informe señala una causa que coincide con nuestra experiencia sobre el terreno: el problema no está en la calidad de los modelos, sino en la integración — en el contexto que se les da. La tesis de este artículo es, por tanto, más acotada y más defendible: en la mayoría de los proyectos RAG que hemos visto encallar, la causa primera es la búsqueda, no el modelo. Y es una tesis que se puede medir, no solo contar.
El techo que ningún modelo puede romper
Un sistema RAG es una cadena de dos eslabones: hay un componente que busca los pasajes relevantes en tus documentos, y un modelo que escribe la respuesta leyendo esos pasajes. Toda la atención (y el presupuesto) suele ir al segundo eslabón. Pero rige una regla tan obvia como ignorada:
La calidad máxima de las respuestas está limitada por la calidad de la búsqueda: si el pasaje correcto no se encuentra, el modelo solo puede decir «no lo sé» — o inventar.
No existe una tercera opción. Cambiar de modelo desplaza la elección entre esas dos, no resuelve el problema. Por eso la primera inversión sensata no es un modelo más grande: es medir con qué frecuencia la búsqueda trae el documento correcto. Si lo hace 6 veces de cada 10, el techo de precisión de todo el sistema es el 60% — y ningún retoque del prompt lo subirá.
Por qué falla la búsqueda
Las causas recurrentes son pocas y concretas:
- Documentos mal troceados. Para poder buscarse, los documentos se dividen en fragmentos. Si el corte es mecánico, una tabla queda partida por la mitad, una regla se separa de su excepción, y el fragmento «en tal caso el plazo se reduce a 15 días» ya no dice de qué caso habla.
- Palabras distintas para la misma cosa. El usuario pregunta «¿puedo pagar a plazos un recibo vencido?», el documento habla de «plan de regularización de posiciones impagadas». Cero palabras en común: la búsqueda por palabras clave no lo encontrará jamás.
- La corrección que crea el problema opuesto. La respuesta típica es pasar a la búsqueda «semántica», que entiende el significado más allá de las palabras. Cierto — pero es débil justo donde la otra es fuerte: códigos de producto, siglas, números de artículo, nombres propios. El código de error
ERR_5012la búsqueda por palabras lo encuentra a la primera; la semántica lo «ahoga» entre conceptos parecidos. - Ninguna prueba de validación. El pecado original: sin un conjunto de preguntas reales con la respuesta esperada, cada cambio es una apuesta y cada reunión un intercambio de opiniones.
La solución: poner dos búsquedas a trabajar juntas
El punto clave: la búsqueda por palabras y la búsqueda por significado fallan en preguntas distintas y complementarias. No es una elección entre las dos — hacen falta ambas.
La búsqueda híbrida hace exactamente eso: ejecuta las dos búsquedas en paralelo y fusiona sus clasificaciones con un criterio que premia el consenso — un documento encontrado por ambas, aunque no en cabeza, gana a un documento que es primero para una sola. Que es el comportamiento correcto: un pasaje encontrado tanto por las palabras como por el significado es casi con certeza el que hace falta.
Un ejemplo real, que hemos verificado con los números delante. Pregunta: «¿puedo fraccionar una factura ya vencida?». El documento correcto — el del «plan de regularización de créditos impagados» — era el quinto en la clasificación de la búsqueda por palabras y el cuarto en la de significado: con una sola de las dos técnicas nunca habría entrado entre los tres primeros pasajes leídos por el modelo, y la respuesta habría sido incorrecta. Con la fusión de las dos clasificaciones subió al primer puesto — porque era el único presente en las dos.
| Estrategia de búsqueda | Posición del documento correcto | ¿Lo lee el modelo? |
|---|---|---|
| Solo por palabras clave | 5ª | ✗ |
| Solo por significado | 4ª | ✗ |
| Híbrida (fusión de ambas) | 1ª | ✓ |
Dos cosas importantes para quien decide. Primero: no es tecnología exótica — la búsqueda híbrida viene integrada de serie en los principales motores de búsqueda enterprise (Elasticsearch, OpenSearch, Azure AI Search) y se activa, no se inventa. Segundo: después de la búsqueda hace falta un paso de reordenación de los resultados, porque los modelos leen mejor lo que está al principio del contexto — un detalle documentado en la literatura que por sí solo cambia sensiblemente la calidad percibida.
Es la misma filosofía de nuestra plataforma ACME ECMS IA & RAG Integration: varios ejes de búsqueda sobre la base de conocimiento y reordenación de los pasajes antes de la generación. No es teoría: es el esquema publicado en esa página.
Cómo saber si funciona (antes de fiarte)
La prueba es sorprendentemente sencilla, y casi nadie la hace. Se construye un conjunto de prueba: 50–100 preguntas reales — recogidas de quienes usarán el sistema, no inventadas en un despacho — cada una con la indicación del documento que contiene la respuesta. Después se mide una sola cosa, sobre la búsqueda aislada, antes incluso de involucrar al modelo: ¿cuántas veces aparece el documento correcto entre los primeros resultados?
Esa cifra es el techo de todo el proyecto. Medida antes y después de cada intervención — activación de la búsqueda híbrida, reordenación, mejor troceado de los documentos — convierte las discusiones en decisiones: se ve en una tabla qué ha mejorado las cosas y cuánto, y se deja de atribuir al «modelo flojo» culpas que están en otra parte.
Las cinco preguntas que hacerle a quien te lo construye
- ¿Existe un conjunto de prueba con preguntas nuestras y respuestas esperadas? ¿Podemos verlo?
- ¿Cuál es el porcentaje de veces en que la búsqueda trae el documento correcto entre los primeros resultados, medido sobre nuestro archivo?
- ¿La búsqueda usa ambos ejes — palabras clave y significado — o solo uno?
- ¿Hay un paso de reordenación de los resultados antes de que el modelo los lea?
- Cuando una respuesta es incorrecta, ¿hay forma de saber si el documento correcto había sido encontrado? (Si la respuesta es sí, el problema es la generación; si es no, es la búsqueda. En nuestra experiencia, casi siempre es lo segundo.)
Si a estas preguntas llegan respuestas vagas, el proyecto está navegando a ciegas — sea cual sea el modelo que haya debajo.
La síntesis
El RAG no fracasa porque el modelo sea tonto. Fracasa porque se le da a leer el documento equivocado — y luego se le acusa de haber respondido mal.
Antes de invertir en un modelo más grande: medir la búsqueda, activar el eje que falta, añadir la reordenación. En nuestra experiencia es el orden de intervenciones con la mejor relación entre resultado y coste — pero es una experiencia, no un teorema: el conjunto de prueba construido con tus preguntas es el único árbitro que cuenta.
Si tu asistente documental se ha encallado en fase piloto, podemos mirarlo por dentro juntos — empezando, por supuesto, por la medición.
Fuentes.
- MIT Media Lab, Project NANDA — The GenAI Divide: State of AI in Business 2025 (julio de 2025); síntesis en Fortune, 18 de agosto de 2025. La metodología ha sido objeto de críticas independientes por la fragilidad de la muestra.
- Sobre la fusión de clasificaciones (Reciprocal Rank Fusion): Cormack, Clarke, Büttcher, SIGIR 2009; documentación de Azure AI Search, Elastic y OpenSearch. El ejemplo numérico citado ha sido recalculado y verificado por la redacción.
- Sobre la degradación de lectura en contextos largos: Liu et al., Lost in the Middle, TACL 2024.
