La mayoría de los tutoriales de RAG terminan en la demo. Fragmentas por recuento de tokens, lo metes todo en una base de datos vectorial y te das por satisfecho. Eso funciona cuando un usuario pregunta "¿Cuál es la política de devoluciones?" en un FAQ limpio. Pero se desmorona cuando alguien pega medio contrato y pregunta sobre la cláusula tres, o cuando un desarrollador escribe un código de error oscuro en la búsqueda de tu documentación.

Las ventanas de tokens fijas cortan los acuerdos legales a mitad de una frase. Los fragmentos grandes entierran las referencias de la API bajo párrafos de ruido. Lo peor de todo es que una recuperación lenta hace que los usuarios abandonen la consulta antes de que el modelo empiece siquiera a generar. Aprendimos esto por las malas. Cuando pasamos nuestra capa de recuperación de la esperanza a la medición, redujimos la latencia en un cuarenta por ciento y elevamos el recall al noventa y cinco por ciento. Esto es exactamente lo que cambió.

Fragmentación Inteligente

Deje de pensar en el tamaño del fragmento como un número mágico. Una ventana de 512 tokens no tiene sentido para un documento legal donde una sola cláusula abarca varios párrafos, y es igualmente inútil para la documentación de una API donde la firma de una función y su descripción de dos líneas deben permanecer juntas. Cambiamos a una división consciente de la estructura.

Para textos legales, la fragmentación recursiva respeta la jerarquía del documento. Las cláusulas permanecen intactas. Para la documentación de API, utilizamos una división consciente de las funciones que mantiene las firmas, los parámetros y los ejemplos juntos como unidades atómicas. Los tickets de soporte y los datos conversacionales necesitan límites semánticos, dividiéndose donde cambia el tema en lugar de en un recuento arbitrario de caracteres. El resultado es que cada fragmento aporta suficiente contexto para ser útil, pero no tanto como para diluir la señal. Su modelo de embeddings tiene un presupuesto de atención limitado. Gástelo sabiamente.

Recuperación Híbrida

La búsqueda vectorial destaca al encontrar contenido conceptualmente similar. Pregunta sobre consultas lentas de bases de datos y te mostrará guías de optimización de rendimiento. Pero pide "Error 0x80070057" y la búsqueda semántica se desvía hacia territorio no relacionado porque los embeddings densos no manejan bien las coincidencias exactas. BM25, por otro lado, da en el clavo con cadenas exactas y términos poco comunes, pero no tiene idea de que "latencia" y "tiempo de respuesta lento" significan lo mismo.

Ejecutamos ambas en paralelo y las fusionamos mediante Reciprocal Rank Fusion. RRF es simple y efectivo. Toma las listas clasificadas de cada método y puntúa los documentos basándose en su posición, dando una oportunidad justa a los candidatos fuertes de cualquiera de los dos sistemas. Tras la fusión, ejecutamos un reordenador (reranker) de codificador cruzado sobre los resultados combinados y devolvemos solo los cinco mejores. El reranker añade unos cincuenta milisegundos de latencia, pero mejoró nuestro recall en un quince por ciento. Esa compensación se amortiza con creces en la calidad de la generación.

Expansión de Consultas

Los usuarios son pésimos haciendo consultas. Abrevian, escriben mal o empaquetan tres preguntas en un largo desvarío. Si buscas exactamente lo que escribieron, perderás los documentos que realmente necesitan.

Ahora transformamos cada consulta antes de que llegue al índice. Primero, generamos múltiples versiones reformuladas de la pregunta original para cubrir sinónimos y frases alternativas. Segundo, descomponemos preguntas complejas en subpreguntas más pequeñas. Una consulta como "¿Por qué está fallando el reembolso para clientes internacionales y cómo lo soluciono?" se convierte en dos búsquedas distintas: una sobre fallos de reembolsos internacionales y otra sobre los pasos de remediación. Solo la expansión de consultas elevó nuestro recall del setenta y ocho por ciento al noventa y cuatro por ciento. La lección es sencilla: no confíe en el primer borrador del usuario. Ayúdelo.

Deje de adivinar, empiece a buscar

El tamaño del fragmento, el porcentaje de solapamiento, el límite top-k y la profundidad del reranker interactúan de formas que es imposible ajustar a mano. Pasamos demasiados ciclos debatiendo si 256 tokens era mejor que 512, mientras ignorábamos el ajuste de solapamiento que en realidad estaba destruyendo la coherencia.

Reemplazamos la intuición con la optimización bayesiana. En lugar de una búsqueda de cuadrícula (grid search), que desperdicia cómputo en regiones obviamente malas, los métodos bayesianos construyen un modelo probabilístico de lo que funciona y buscan activamente la frontera de Pareto que maximiza el recall minimizando la latencia. Para nuestro stack, eso significó encontrar la combinación específica de tamaño de fragmento, solapamiento y top-k que nos diera un recall del noventa y cinco por ciento sin disparar nuestro presupuesto de latencia. Diferentes casos de uso se situaron en diferentes puntos de esa frontera. Los chatbots de atención al cliente priorizaron la velocidad. La investigación legal interna priorizó el recall. La optimización automatizada nos permitió atender ambos sin tener que copiar y pegar archivos de configuración manualmente.

Los Resultados

Los números hablan por sí solos. Nuestro Recall@10 subió del setenta y ocho por ciento al noventa y cinco por ciento. La latencia p95 bajó de 850 milisegundos a 320 milisegundos. Y debido a que el modelo finalmente estaba recibiendo contexto relevante en lugar de ruido, la tasa de alucinación cayó del doce por ciento al tres por ciento. Una mejor recuperación no solo hace que las respuestas sean más rápidas. Las hace veraces.

Qué hacer a continuación

Si estás reconstruyendo tu capa de recuperación, empieza por aquí:

  • Divide en fragmentos según la estructura del documento, no por el recuento de tokens. Ajusta tu estrategia de división a la forma de tus datos.
  • Utiliza la recuperación híbrida. Combina la búsqueda vectorial y BM25, mézclalas con Reciprocal Rank Fusion y realiza un reranking antes de generar.
  • Expande las consultas para una mejor cobertura. Reformula y descompón antes de que se ejecute la búsqueda.
  • Crea un golden dataset para las pruebas. No puedes optimizar lo que no mides.
  • Optimiza los parámetros con herramientas automatizadas. La búsqueda bayesiana encontrará mejores configuraciones que tu intuición.

La recuperación no es un archivo de configuración que estableces una vez y olvidas. Es infraestructura, y la infraestructura merece el mismo rigor que el código de producción: pruebas, mediciones y optimización continua. Trátala de esa manera y tu sistema RAG dejará de ser una demo para convertirse en un producto.

Comunidad de aprendizaje opcional: GyaanSetu AI