Transformación de consultas: reescritura, descomposición y multi-query

Cuarta entrega del bloque de técnicas de recuperación. Las tres anteriores mejoraban lo que el sistema hace con la consulta que recibe. Esta trata el caso incómodo: que la consulta que recibe no sea buscable tal como está escrita, algo que ocurre mucho más de lo que sugieren los conjuntos de prueba.

La pregunta del usuario no es una consulta

El pipeline mínimo asume, sin decirlo, que el texto que teclea el usuario es una buena representación de lo que necesita encontrar. Basta mirar el registro de consultas reales de cualquier sistema en marcha para ver que a menudo no lo es.

Las preguntas reales son elípticas («¿y para el resto de Europa?»), telegráficas («devolución rota»), compuestas («qué cubre y cuánto cuesta»), mal escritas, redactadas con vocabulario del usuario en lugar del vocabulario del documento, o formuladas en un nivel de abstracción que no se corresponde con el del corpus. Todas ellas se convierten igualmente en un vector y ese vector se usa igualmente para buscar, sin que nada avise de que la consulta era mala.

La transformación de consultas agrupa las técnicas que insertan un paso entre el usuario y el buscador: convertir la pregunta en una o varias consultas mejores antes de buscar. Todas comparten la misma estructura de coste —una o más llamadas adicionales al modelo, antes de la recuperación— y difieren en qué patología corrigen.

Reescritura

La forma más simple. Se pide al modelo que reformule la pregunta en una consulta autónoma, explícita y con la terminología probable del corpus. Es útil sobre todo en tres casos: preguntas telegráficas, preguntas con faltas o con jerga del usuario, y corpus con un registro muy distinto del de la pregunta (el usuario dice «me han cobrado de más» y el documento dice «regularización de facturación»).

La reescritura tiene un riesgo específico que conviene tener presente: el modelo puede añadir supuestos. Ante «problema con la factura» puede producir «error en el importe facturado», estrechando la búsqueda hacia una hipótesis que nadie ha confirmado. Una mitigación barata es buscar con las dos, la original y la reescrita, y fusionar con RRF como vimos en la entrega 15.

Resolución de referencias conversacionales

Es el caso particular de reescritura que resulta obligatorio en cualquier interfaz de chat. En un diálogo, el segundo turno casi nunca es autónomo:

Usuario: ¿Cuál es el plazo de devolución del seguro de viaje?
Sistema: Catorce días naturales desde la contratación.
Usuario: ¿Y si ya he empezado el viaje?

«¿Y si ya he empezado el viaje?» vectorizada en solitario es un desastre: no contiene «devolución», ni «seguro», ni «plazo». Devolverá fragmentos sobre viajes en general. La solución consiste en pasar al modelo los últimos turnos y pedirle una consulta independiente del contexto: «plazo de devolución del seguro de viaje una vez iniciado el viaje». Ahora sí es buscable.

Este paso no es opcional ni es una mejora avanzada: es un requisito de funcionamiento de cualquier RAG conversacional, y su ausencia explica una fracción notable de las quejas del tipo «funciona bien la primera pregunta y luego se pierde».

Descomposición de preguntas compuestas

Es el remedio del segundo punto de rotura de la entrega 14. Una pregunta con dos o más necesidades de información se rompe en subconsultas independientes, cada una se recupera por separado y los contextos se unen antes de generar.

Un ejemplo completo. Pregunta original:

«¿Cuánto ha subido la cuota del plan profesional desde 2023 y qué funcionalidades nuevas justifican la subida?»

Descompuesta por el modelo en tres subconsultas:

1. Precio de la cuota del plan profesional en 2023
2. Precio actual de la cuota del plan profesional
3. Funcionalidades añadidas al plan profesional desde 2023

Cada una es atómica, cada una tiene su respuesta localizada en algún fragmento concreto, y cada una recupera bien por separado. Sin descomponer, el vector único de la pregunta original cae en un territorio intermedio entre tarifas e historial de producto, y lo más probable es que recupere material de precios y nada de funcionalidades. El modelo redactaría entonces la parte de la subida con datos y la parte de la justificación con imaginación.

Merece la pena señalar lo que la descomposición no hace: no ordena las subconsultas ni encadena sus resultados. Las tres se lanzan en paralelo. Para preguntas donde la segunda subconsulta depende del resultado de la primera —«¿qué formación tiene el actual responsable de operaciones?», que exige saber primero quién es— hace falta recuperación de varios pasos, que es territorio de la entrega 21.

Multi-query: varias variantes de la misma pregunta

Aquí la pregunta no se rompe en partes: se reformula en tres o cuatro variantes que expresan la misma necesidad con vocabulario y enfoques distintos. «¿Puedo cancelar mi suscripción?» genera «proceso de baja de la suscripción», «condiciones de cancelación del contrato», «cómo dar de baja el servicio».

Cada variante se busca por separado y las listas resultantes se fusionan, otra vez con RRF. La lógica es la misma que en la búsqueda híbrida: un fragmento que aparece arriba en las listas de varias formulaciones distintas es muy probablemente relevante, mientras que uno que sólo aparece en una puede ser un artefacto de esa redacción concreta.

Multi-query ataca la fragilidad de la búsqueda densa frente a la formulación: el hecho, algo desagradable, de que la misma pregunta escrita de dos maneras devuelva conjuntos distintos de resultados. Es especialmente eficaz en corpus heterogéneos, donde el mismo concepto aparece nombrado de formas diferentes según quién escribiera cada documento.

El coste es el más alto de las técnicas de esta entrega: una llamada al modelo para generar variantes más n búsquedas más la fusión. Las búsquedas se paralelizan, así que la latencia añadida es la de la llamada de generación más la de la búsqueda más lenta, no la suma. La factura, en cambio, sí suma.

Step-back prompting

La técnica del paso atrás resuelve un desajuste distinto: el de nivel de abstracción. Hay preguntas tan específicas que ningún fragmento del corpus las contiene literalmente, pero cuya respuesta se deduce de un principio general que sí está escrito.

«¿Puedo devolver un abrigo que compré en rebajas hace veinte días si le falta la etiqueta?» es demasiado concreta: ningún documento habla de abrigos, rebajas, veinte días y etiquetas a la vez. La pregunta de paso atrás sería «condiciones generales de devolución de artículos rebajados», que sí recupera la política aplicable. Con esa política en el contexto, el modelo puede aplicar el razonamiento al caso particular.

En la práctica se suele buscar con las dos consultas, la específica y la general, y fusionar. La específica recupera excepciones concretas si las hay; la general recupera el marco. Funciona bien sobre corpus normativos, políticas y documentación de procedimientos; aporta poco sobre corpus de casos concretos, como incidencias o expedientes, donde lo específico es justamente lo que hay que encontrar.

La cuenta de coste y latencia

Dos observaciones sobre la tabla. La primera: todas estas técnicas añaden una llamada al modelo antes de recuperar, y esa llamada está en el camino crítico, no se puede paralelizar con nada porque todo lo demás depende de su resultado. Es latencia pura que el usuario espera antes de que empiece siquiera la búsqueda.

La segunda: esa llamada no necesita el modelo grande. Reescribir, descomponer o generar variantes son tareas de manipulación lingüística sencilla, y un modelo pequeño y rápido las hace bien por una fracción del coste y del tiempo. Usar el mismo modelo de generación para transformar consultas es un error frecuente y caro.

Límites

La transformación de consultas trabaja a ciegas. El modelo que reescribe no ha visto el corpus: no sabe qué vocabulario usan tus documentos ni qué temas contienen, así que reformula según su conocimiento general del idioma. Cuando el dominio es muy particular, esa reformulación puede alejarse del corpus en lugar de acercarse. Incluir en el prompt de reescritura una breve descripción del corpus y una lista de términos preferentes reduce bastante el problema.

Hay además un riesgo de amplificación: si la transformación se equivoca, todo lo que viene después trabaja sobre una consulta equivocada, y el reranking no lo detecta porque puntuará bien los fragmentos relevantes para la consulta transformada. Por eso conviene, casi siempre, conservar la consulta original entre las que se buscan y dejar que la fusión decida. Cuesta una búsqueda más y evita el fallo catastrófico.

Por último, aplicar todo esto a todas las preguntas es desperdicio. Una pregunta atómica, bien formulada y en el vocabulario del corpus no gana nada con multi-query. Un clasificador ligero que decida qué preguntas necesitan transformación —o simplemente aplicarla sólo en turnos posteriores al primero— ahorra la mayor parte del coste sin perder la ganancia.

Qué viene ahora

La siguiente entrega lleva la idea al extremo: en lugar de mejorar la pregunta para buscar con ella, generar un documento hipotético que responda a la pregunta y buscar con ese. Es HyDE, veremos la intuición geométrica que lo sostiene, el procedimiento paso a paso con un ejemplo completo, y el modo característico en que falla cuando el documento hipotético se inventa detalles que condicionan la búsqueda.

Si prefieres leerlo todo de golpe y en orden, los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.