Reescritura de consultas y HyDE

La calidad de la recuperación está limitada por la consulta. Las consultas sin procesar de los usuarios suelen ser breves, ambiguas, estar llenas de pronombres o estar formuladas de manera distinta a los documentos. La transformación de consultas modifica la consulta antes de la recuperación para aumentar la recuperación y la precisión.

Es una de las mejoras más económicas y con mayor impacto frente al RAG ingenuo: corrija la consulta y todas las etapas posteriores se beneficiarán.

La transformación más sencilla consiste en que un LLM reescriba la consulta del usuario con una forma más clara, autónoma y adecuada para la recuperación. Corrige errores tipográficos, amplía abreviaturas y elimina el ruido conversacional.

Esto es especialmente importante en conversaciones de varios turnos, donde el último mensaje resulta ininteligible sin contexto (¿Y qué ocurre con el segundo?).

En un RAG conversacional, condense el diálogo y el nuevo turno en una única pregunta independiente. Sin este paso, los pronombres y las elipsis hacen que el embedding carezca de sentido y la recuperación se desmorone.

Proporcione los turnos anteriores para que el reescritor pueda resolver expresiones como esto, eso o el anterior y convertirlas en entidades explícitas que el recuperador pueda encontrar.

La expansión genera sinónimos, términos relacionados o formulaciones alternativas para ampliar la cobertura léxica y semántica. Combate la discordancia de vocabulario: el documento dice invalidate y el usuario dice revoke.

Expanda la consulta para la recuperación y recupere después usando la unión de resultados; no muestre la forma expandida al usuario. Tenga cuidado con la expansión excesiva, que puede atraer resultados fuera de tema.

Genere varias reformulaciones diversas, recupere resultados para cada una y fusione las listas de resultados (fusión de rangos recíprocos). Las distintas formulaciones hacen aflorar fragmentos relevantes diferentes; la fusión combina sus ventajas y estabiliza la recuperación.

Esto intercambia llamadas de recuperación adicionales por robustez frente a una formulación individual defectuosa.

Las preguntas complejas y de varios saltos requieren una descomposición en subpreguntas, cada una recuperada por separado, para después combinarlas. No se puede responder mediante una sola recuperación a una pregunta como «¿Qué director ejecutivo de la empresa que adquirió X es mayor que...?».

Descomponga la pregunta, recupere información para cada subpregunta y permita que el generador combine las evidencias recopiladas.

HyDE (Hypothetical Document Embeddings, Gao et al., 2022) invierte el planteamiento. En lugar de generar el embedding de la consulta breve, solicita al LLM que genere un documento de respuesta hipotético; después genera el embedding de ese documento y lo usa para recuperar información.

El documento hipotético utiliza el mismo registro que los documentos reales, por lo que su embedding queda más cerca de las respuestas auténticas y corrige la discordancia entre la consulta y el documento.

Una pregunta y su respuesta están formuladas de manera diferente; una pregunta y una respuesta ficticia pero verosímil están formuladas de manera similar a la respuesta real. HyDE aprovecha el prior generativo del LLM para salvar esa distancia, aunque el contenido hipotético contenga errores factuales.

La corrección del contenido hipotético no importa demasiado: solo necesita el vocabulario y la estructura adecuados para quedar cerca de los documentos verdaderos en el espacio de embeddings.

HyDE añade una generación del LLM antes de la recuperación, lo que incrementa la latencia y el coste, y puede alucinar un contenido hipotético que se desvíe del tema. Esto perjudica la recuperación en consultas específicas o fuera de la distribución de datos que el modelo no conoce.

Mitigue este problema combinando la recuperación mediante vectores de HyDE con la recuperación basada en la consulta original mediante fusión, de modo que una hipótesis defectuosa no pueda hundir por completo la recuperación.

Estas transformaciones son complementarias. Use la condensación para conversaciones, la expansión/multi-query para las carencias de vocabulario, la descomposición para preguntas de varios saltos y HyDE cuando haya una discordancia entre el registro de la pregunta y el del documento. Muchos stacks de producción encadenan la condensación, después HyDE, luego fusionan los resultados con la consulta original y finalmente aplican el reordenamiento.

Cada transformación añadida tiene el coste de una llamada al LLM, así que actívelas según el tipo de consulta en lugar de ejecutarlas siempre todas.

Mida cada transformación según la mejora que aporte al recall@k de recuperación y a la precisión de la respuesta final frente a la consulta sin transformar, usando un conjunto sin fugas. Registre la latencia adicional y el coste del LLM para conservar únicamente las transformaciones que resulten rentables.

Tenga cuidado: una transformación que mejora el recall pero añade distractores puede reducir la precisión de la respuesta si no se combina con re-ranking y compresión.

Conclusiones clave:

• La recuperación está limitada por la consulta; transformarla es una mejora de RAG económica y de gran impacto.
• La reescritura y la condensación convierten las consultas de chat en consultas independientes; la expansión y las consultas múltiples corrigen las carencias de vocabulario.
• La descomposición gestiona las preguntas de varios saltos mediante la recuperación para cada subpregunta.
• HyDE incorpora una respuesta hipotética para salvar la diferencia de registro entre la pregunta y el documento; no es necesario que la hipótesis sea correcta.
• Combine las transformaciones según el tipo de consulta, fusiónelas con la consulta original para obtener mayor solidez y evalúe el recall, la precisión de la respuesta, la latencia y el coste.