Ocho buenas prácticas de RAG probadas en 746 páginas de manuales

Un bot de soporte desarrollado a partir de tres PDF reales —un manual de 408 páginas para propietarios de vehículos eléctricos, una guía de televisión de 329 páginas y un folleto de 9 páginas que incluía un ratón inalámbrico— se convirtió en un entorno de pruebas para ocho optimizaciones populares de RAG. La regla era estricta: nada se adoptaba a menos que una medición realizada en ese corpus, evaluada contra una clave de respuestas etiquetada, demostrara que funcionaba. La literatura y los hábitos no contaban.

El resultado fue que la precisión aumentó del 72 % al 89 %, mientras que los tokens de prompt por consulta disminuyeron de 14 a 57 %. Esto se logró con cuatro cambios, no con ocho. Dos de las ideas descartadas incluso perjudicaron el rendimiento, y una de las optimizaciones implementadas resultó no ejecutarse nunca. Toda la investigación costó aproximadamente 0,015 dólares en llamadas a la API.

A continuación se muestra el rendimiento de cada idea. El elemento más valioso de la lista no es en absoluto una técnica de RAG.

Un error mayor que cualquier hiperparámetro

Antes de ajustar la recuperación, verifique qué es lo que realmente llegó al índice. Todos confirman que el PDF se analizó. La pregunta más relevante es en qué estado se encuentra el texto.

Un bucle infinito responde a ello:

SOFT = "­"    # U+00AD, the soft hyphen
for manual in manuals:
    print(manual.name, extract(manual).count(SOFT))

El manual del coche devolvió 2,272.

Un guion suave es una instrucción del compositor al procesador de texto: dividir la palabra aquí si se agota la línea. Un lector de PDF la obedece y la oculta, por lo que los ojos nunca la ven, pero un extractor de texto la transmite sin modificarla. La página muestra una palabra completa, mientras que el índice recibe cadenas como ve, guion suave, salto de línea, hicle.

En ese manual, 999 palabras distintas fueron divididas por la mitad, incluyendo, repetidamente, el sustantivo más importante de cualquier manual de coche. La palabra Vehicle apareció 1,486 veces como palabra completa, cuando debería haber aparecido 1,580 veces. Noventa y cuatro apariciones no pudieron ser localizadas mediante búsqueda.

Esto daña simultáneamente cada ruta de recuperación. La búsqueda por palabras clave coincide con cadenas literales, y “hicle” no es “vehicle”, sin posibilidad de crédito parcial. La búsqueda vectorial tiene un rendimiento peor de lo esperado, ya que los modelos de embedding dividen el texto en fragmentos subpalabras, y un fragmento como “hicle” se desintegra en partes sin sentido. Incluso un hallazgo afortunado inserta un contexto distorsionado en el prompt.

La solución es de una sola línea, pero con una trampa. El texto justificado también se rompe en guiones reales. Una palabra rota como “cus-tomer” debería volver a formarse como “customer”, pero “toll-free” debe mantenerse con guion, y diferenciarlas requiere un diccionario. Había 95 de esas palabras, y todas quedaron rotas, con el número anotado. Una brecha conocida de 95 palabras es un artefacto muy distinto a una suposición silenciosa que corrompe discretamente un corpus. Ningún tamaño de bloque puede recuperar una palabra que el índice nunca registró como tal.

El mejor tamaño de bloque es una trampa

Los fragmentos más grandes contienen más contexto y, por lo tanto, se corresponden con más preguntas, pero también incluyen texto irrelevante adicional en cada consulta, de forma permanente. Existe solapamiento para que una respuesta situada en un límite no quede dividida en dos.

Se probaron nueve configuraciones con la clave de respuestas. Medir la precisión no cuesta nada, mientras que el costo es lo que se paga por ella.

El solapamiento nunca ha justificado su uso, aunque no de la manera que sugiere una primera lectura. Con 700 caracteres, eliminar el solapamiento aumentó la puntuación en 11 puntos, lo cual parece negativo hasta que se verifica el otro caso: con 1800 caracteres, un solapamiento de 0, 100 y 200 arrojaron exactamente el 89% de puntuación. Una comparación indica que el solapamiento es costoso y otra afirma que no tiene efecto alguno.

Lo que explica ambos resultados es una estadística que casi no apareció en la página. En todas las configuraciones, incluso las más pequeñas, cada respuesta cabía por completo dentro de un único bloque, y ninguna fue cortada en una frontera. La superposición servía como protección contra un problema que carece este corpus, por lo que su valor medido oscilaba entre cero y negativo. Verificar con qué frecuencia las respuestas realmente cruzan una frontera debería hacerse antes de pagar ese costo adicional.

Luego está la trampa. La mejor puntuación, del 89%, se obtuvo con 1400 caracteres y 200 de superposición. Al elegirla, se envían 1,283 tokens por consulta en lugar de 750, lo que representa un 71% más en cada consulta durante toda la vida útil del producto. Con 18 preguntas en el conjunto de prueba, un 89% significa 16 respuestas correctas y un 83% significa 15. La mejor configuración supera a la más económica exactamente en una pregunta.

Por lo tanto, el ganador no debería determinarse por defecto. Hay que elegir la configuración más económica cuya puntuación no pueda diferenciarse de la del ganador, lo que en este caso significaba cualquier valor dentro de 8 puntos. Seis de las nueve configuraciones empataron según esa regla, y ganó la más económica. La precisión pasó del 72 % al 83 %, además con un costo menor en tokens; fue el primer “almuerzo gratis” del proyecto, obtenido al decidir no optimizar la métrica que se medía.

Un filtro que costó 22 puntos

El corpus abarca tres productos. Una pregunta sobre el ratón no tiene motivo para buscar en un manual de automóvil de 408 páginas, ya que los otros dos documentos solo aumentan las posibilidades de error. La estrategia era detectar el producto y limitar la búsqueda a ese manual.

Un clasificador lo logró. Elegió correctamente el 78 % de las veces en menos de 4 ms, sin costo alguno; una mayoría sólida en comparación con buscar en tres veces más texto. Sin embargo, la precisión disminuyó en 22 puntos.

El mecanismo tardó un tiempo vergonzosamente largo en hacerse visible. Un filtro incorrecto no solo no descarta la respuesta correcta, sino que la elimina por completo. Sin filtrado, una búsqueda confusa en los tres manuales sigue mostrando el pasaje correcto, quizás en la posición 4 en lugar de 1, y un sistema de reclasificación puede recuperarlo. Con filtrado, una pregunta mal dirigida busca en el documento equivocado, y el fragmento correcto no es clasificado como de baja calidad porque no forma parte del conjunto de candidatos.

Por lo tanto, un clasificador que tiene un 78% de aciertos no implica una ligera pérdida de calidad. Impone un techo estricto del 78% en todo el proceso posterior, sin importar cuán bueno sea el resto del sistema.

La solución no es un clasificador más preciso, sino la posibilidad de abstenerse: aplicar el filtro solo cuando se tenga certeza, y buscar todos los resultados cuando las puntuaciones de los dos productos principales sean similares. En una pregunta como “¿Cómo vincularlo por Bluetooth?”, la palabra “vincularlo” tiene mucho peso, y el clasificador está tan incierto como cualquier otra persona.

O saltarse por completo la inferencia

El router más económico funciona como un menú desplegable. Para una herramienta de este tipo, preguntar de qué producto trata una consulta solo requiere un toque, que con frecuencia el usuario ya realiza al abrir el chat desde la página de ayuda del producto. Esto resuelve al instante una ambigüedad que el clasificador solo puede adivinar, y el filtro siempre da el resultado correcto.

Las cifras son exactas. El clasificador dirigió erróneamente 4 de las 18 preguntas. La búsqueda sin filtro encontró 15 respuestas, la búsqueda con filtro encontró 11, y cada error de enrutamiento convirtió un resultado correcto en uno incorrecto. Si se eliminan esos errores de enrutamiento, la precisión se mantiene, al tiempo que también se logra la precisión que prometía el filtro.

La optimización que nunca se ejecutó

Esta parte sería tentadora de eliminar por cuestiones estéticas.

El plan era responder con un modelo económico de 20 mil millones de parámetros cuando la recuperación de información pareciera fiable, y pasar a un modelo de 120 mil millones de parámetros cuando no lo fuera. Las respuestas incorrectas tienden a agruparse donde la recuperación de información es deficiente, y el reordenador ya genera una puntuación de confianza, por lo que no hay costo adicional.

El umbral se fijó en 0.0, lo cual parecía razonable: un codificador cruzado emite un logit, sigmoid(0) equivale a 0.5, y valores por debajo de cero se interpretan como un aumento cuando es más probable que el fragmento principal sea irrelevante que relevante. Imprimir la distribución real mostraba otra historia: las puntuaciones más altas observadas tenían un mínimo de 3.24, un valor medio de 8.29 y un máximo de 10.00.

El umbral estaba por debajo de la puntuación más baja jamás registrada, por lo que nunca se activó, ni siquiera una vez. La política de escalado era idéntica a utilizar siempre el modelo económico, además de generar un gasto adicional en forma de una fila en la tabla de resultados que no indicaba nada pero aparentaba ser un hallazgo. Un umbral de cero no es un valor por defecto neutral; es una afirmación sobre una distribución que nadie ha examinado, y todo umbral absoluto de logit tiene ese defecto, ya que la distribución cambia cuando el reordenador o el corpus varía.

La solución consistió en calcular el número de forma automática. Se ejecutan únicamente los dos puntos finales correspondientes a los casos “real”, “siempre económico” y “siempre caro”, registrando la puntuación, la corrección y el costo de cada pregunta. Cada umbral intermedio implica volver a procesar las filas ya en memoria, sin llamadas API adicionales, y se realiza un análisis exhaustivo en lugar de uno basado en muestras.

El análisis arrojó una sorpresa: cada umbral solo modifica el costo, mientras que la precisión no varía en absoluto. El diagnóstico explica por qué. De doce preguntas, solo una pudo ser recuperada, lo que significa que el modelo económico falló y el caro tuvo éxito. Esa pregunta obtuvo una puntuación de 10.00, el valor más alto del rango, mientras que las preguntas que el modelo económico ya había respondido correctamente tenían una mediana de 8.29. El único fallo que merecía ser tratado con mayor prioridad era aquel del cual el sistema de recuperación estaba más seguro, por lo que ninguna regla basada en aumentar la prioridad cuando hay incertidumbre puede detectarlo en ningún umbral. La señal de enrutamiento no logra predecir lo que se suponía que debía predecir.

También surgió un efecto secundario. La ejecución en tiempo real indicó un 92%, mientras que la reproducción de las filas ya pagadas predijo un 83%. La diferencia no se debe a un umbral específico, sino a que el evaluador del LLM califica de manera distinta respuestas idénticas al analizarlas por segunda vez, evitando así anunciar una ganancia de 9 puntos que en realidad no significa nada.

El cambio que pagó dos veces

La reclasificación fue la solución más eficaz, y su razón merece ser comprendida además de adoptada.

Una búsqueda vectorial incrusta la pregunta y cada fragmento por separado, a través de un modelo que nunca los considera como un par. Un codificador cruzado, en cambio, toma el par como una sola entrada y la evalúa directamente, lo cual es mucho más preciso, pero demasiado lento para aplicarse a todo un corpus. Por eso, el proceso obtiene 25 candidatos de forma económica, los vuelve a ordenar y conserva los 4 mejores.

La tasa de recuperación aumentó del 83 % al 89 %. La cifra más reveladora es en qué posición quedó la respuesta. Antes de volver a clasificar, el grupo correcto solía estar en segundo o tercer lugar, por lo que se enviaban cinco para estar seguros. Después, generalmente estaba en primer lugar, y cuatro eran suficientes. Aceptar una precisión básica permite reducir el número de grupos a dos, lo que supone un 57 % menos de tokens.

Dado que el orden mejora, menos grupos alcanzan la misma precisión, y son los tokens de la solicitud los que se facturan. Este cambio permite obtener mayor precisión y, al mismo tiempo, un descuento. Su costo es de 73 ms de CPU local, en comparación con 1,252 ms en una llamada a un LLM, una diferencia que nadie nota.

Qué se mantiene

• Inspeccione la entrada antes de utilizar el recuperador. Un bucle sencillo puede descubrir problemas como el problema con los guiones o confirmar que no hay limitaciones, lo que hace que los gastos posteriores sean más seguros.
• La configuración por defecto es la medida de otra persona, o la de nadie. Una superposición del 100% nunca fue útil y un umbral de 0.0 nunca se activó; en entornos de producción ninguno de los dos daría señales de sí mismo. El único síntoma sería una factura más alta sin explicación alguna.
• Considere cómo se comporta una optimización en los casos en que comete errores, y no solo con qué frecuencia lo hace. Un filtro que falla el 22% de las veces pero simplemente reordena los resultados puede ser aceptable. Uno que falla el 22% de las veces y hace que la respuesta sea inaccesible, en cambio, no.
• Una idea rechazada es un resultado. Cuatro ideas que no se implementan son cuatro elementos más sin mantenimiento, monitoreo, control de versiones ni alertas en medio de la noche.

Existe una advertencia importante. La clave de respuestas contiene 18 pares verificados de pregunta y respuesta, por lo que cada pregunta vale 5.6 puntos. El colapso en la asignación de puntos de 22 puntos involucra cuatro preguntas, lo cual es suficiente para tomar medidas. El resultado de superposición de 11 puntos involucra solo dos preguntas, por lo que en el mejor de los casos es orientativo. Una clave de respuestas basada en los propios datos del equipo debe tener prioridad sobre confiar en las cifras de terceros. La ejecución completa tarda aproximadamente cinco centésimos en una CPU de portátil, con un límite presupuestario estricto que genera una excepción en lugar de mostrar la cifra en la factura.

Leer más

• Siete arquitecturas RAG más allá del enfoque básico y cuándo aplicarse cada una — El enfoque RAG básico falla de maneras predecibles. Siete arquitecturas, desde notas contextuales hasta sistemas multiagente y recuperación de memoria, con sus ventajas y desventajas y cuándo utilizar cada una.
• Notas prácticas: Por qué su pipeline RAG necesita un re-ranker (y cómo) — Guía paso a paso de las Notas prácticas: Por qué su pipeline RAG necesita un re-ranker (y cómo: contratos, verificaciones y espacios de código listos para usar para los equipos que implementan este patrón.