Mejorar las respuestas de RAG con un cambio medido a la vez
Un flujo de trabajo basado en medidas para corregir respuestas débiles de RAG: ajuste gradual del particionamiento, top_k, el reordenamiento, la búsqueda híbrida y la reescritura de consultas, monitoreando al mismo tiempo las métricas de recuperación.
Es fácil armar un pipeline RAG inicial: cargar documentos, incrustarlos, almacenar los vectores, obtener algunos fragmentos y pasarlos a un LLM. Funciona, pero las respuestas suelen ser incorrectas incluso cuando el documento contiene claramente la información correcta. En la mayoría de esos casos, el modelo no es el culpable; el paso de recuperación nunca le proporcionó el contexto adecuado. Esta guía explica los elementos de recuperación que suelen ser más importantes y, lo que es más relevante, una forma sistemática de determinar cuáles de ellos realmente ayudan a su sistema.
Trate las respuestas incorrectas primero como problemas de recuperación
Antes de cambiar los prompts o modelos, verifique qué se recuperó para una pregunta que falló. Si el pasaje relevante falta del contexto, ninguna cantidad de ajuste en los prompts corregirá la respuesta.
Divida en fragmentos según límites significativos
El tamaño de los fragmentos tiene un efecto sorprendentemente grande en la calidad de la recuperación. Los fragmentos demasiado grandes mezclan varios temas, por lo que sus representaciones vectoriales se vuelven vagas y incluyen texto no relacionado. Los fragmentos demasiado pequeños separan oraciones del contexto que les da significado. En lugar de dividir ciegamente cada 500 caracteres, mantenga juntos los párrafos relacionados o secciones completas, y utilice encabezados y saltos de párrafo como puntos de división naturales.
Ajuste top_k en lugar de adivinarlo
Muchos pipelines recuperan los cinco fragmentos más similares simplemente porque cinco es un valor predeterminado común. Sin embargo, el pasaje correcto podría encontrarse en la posición seis o siete. Aumentar top_k puede mejorar el recuerdo, pero cada fragmento adicional también añade ruido y tokens al prompt. Considere top_k como un parámetro para probar según sus propias preguntas, no como una constante que copiar. Los umbrales de relevancia son otra opción, abordada en más allá de top-k con umbrales, búsqueda híbrida y reclasificación.
Añadir una etapa de reclasificación
La búsqueda vectorial es rápida pero poco precisa: es buena para encontrar candidatos plausibles, pero menos eficaz a la hora de determinar cuál es realmente el mejor. Un modelo de reclasificación realiza un segundo análisis. Primero, la búsqueda vectorial devuelve un conjunto más amplio, quizás diez fragmentos. Luego, un modelo de reclasificación, típicamente un codificador cruzado que lee la consulta junto con cada fragmento, les asigna puntuaciones y conserva los tres o cuatro mejores. El modelo recibe un contexto más claro, pero a costa de una mayor latencia y costo por consulta.
Combinar búsqueda semántica y por palabras clave
Los embeddings capturan bien el significado, pero a veces los tokens exactos son más importantes que el significado. Una consulta como ERROR_CODE_4291 tiene poco contenido semántico, por lo que la búsqueda de similitud podría pasar por alto el único documento que la menciona. La clasificación por palabras clave, como BM25, maneja bien este caso. Por eso, muchos sistemas ejecutan tanto la búsqueda vectorial como la por palabras clave y fusionan los resultados, un enfoque conocido como búsqueda híbrida.
Cierra la brecha de vocabulario en las consultas
Rara vez los usuarios formulan preguntas de la misma manera en que están redactados los documentos. Alguien podría preguntar por qué un pago está fallando, mientras que la página correspondiente habla sobre un fallo en la autorización de la tarjeta. La reescritura de consultas, MultiQuery (generando varias formulaciones y recuperando información para cada una) e HyDE (generando una respuesta hipotética y buscando con su representación vectorial) pueden ayudar a cerrar esa brecha. Sin embargo, añaden llamadas a modelos de lenguaje grande y complejidad, por lo que deben utilizarse solo después de probar los métodos más simples mencionados anteriormente.
Mide cada cambio en relación con un punto de referencia
El hábito más importante es evitar hacer suposiciones. “Añadimos un nuevo sistema de clasificación, así que la recuperación de información es mejor” es una hipótesis hasta que se mide. Crea un pequeño conjunto de preguntas reales con pasajes relevantes conocidos, y luego sigue métricas como:
- Recall@K: si la información correcta aparece entre los K fragmentos recuperados más relevantes.
Primero registre un valor de referencia. En una prueba ilustrativa, podría verse así:
Baseline Recall@5: 68%
Luego aplique un cambio a la vez, vuelva a ejecutar las mismas preguntas y registre cada resultado. Una secuencia de mejoras podría verse así:
Better chunking: 74%
Hybrid search: 82%
Reranking: 89%
Estos valores son un ejemplo, no una referencia de rendimiento; sus propios datos se comportarán de manera diferente. Lo importante es que un registro por cambio le indica qué paso generó su complejidad y cuál no. Para un análisis más profundo sobre la localización de fallos, consulte evaluar RAG por etapa de fallo.
Conclusión
Comience con la pipeline más simple: de la consulta a la recuperación de información, pasando por el contexto y llegando al LLM, y mejore una etapa a la vez: haga un cambio, mézcalo, evalúe su latencia y costo, y repita el proceso. Un sistema RAG sencillo que pueda comprender y medir suele valer más que uno complejo lleno de técnicas que nadie puede justificar con cifras.