RAG Query Rewriting: cómo resolver correctamente las preguntas de seguimiento en chatbots de IA

Una sola pregunta como «¿Y cuánto tiempo es válido?» suele ser clara para las personas. Recuerdan el producto comentado anteriormente, la ubicación y el plazo al que se refiere. Sin embargo, una búsqueda de conocimiento inicialmente solo ve unas pocas palabras. Sin el contexto conversacional adecuado, es posible que no encuentre nada o que busque sobre un tema equivocado. El RAG Query Rewriting resuelve este problema transformando una pregunta de seguimiento dependiente del contexto en una consulta de búsqueda independiente antes de ejecutar la búsqueda.

Puede parecer un pequeño paso intermedio, pero a menudo determina la calidad de un chat web de múltiples turnos. Esta guía muestra cómo los equipos pueden resolver preguntas de seguimiento, cuándo es mejor hacer una repregunta de aclaración y cómo evitar que una reescritura introduzca nuevos hechos, permisos incorrectos o contexto obsoleto en la búsqueda.

Por qué las preguntas de seguimiento desbordan la búsqueda de conocimiento

La primera pregunta del usuario suele ser concreta: «¿Qué garantía se aplica al Modelo A?». A continuación, siguen frases cortas como «¿Y para la variante más grande?», «¿Se aplica esto también en España?» o «¿Qué necesito para eso?». Los pronombres, los sujetos elididos y las referencias a respuestas anteriores son naturales en la conversación. Sin embargo, como consulta de búsqueda aislada, resultan muy débiles.

Un canal de búsqueda clásico por palabras clave, vectorial o Hybrid Search solo puede evaluar lo que recibe como consulta. El reranking mejora el orden de los resultados existentes, pero no sustituye la falta de significado de «eso» o «para eso». Por lo tanto, el Query Rewriting se sitúa antes: transforma la pregunta actual y el historial relevante en una consulta independiente y apta para la búsqueda.

Lo que debe lograr una buena reescritura

Una reescritura bien lograda es lo suficientemente completa para la búsqueda (retrieval), pero se mantiene fiel a la intención del usuario. Por ejemplo, «¿Y para España?» se puede convertir en «¿Qué condiciones de garantía se aplican al Modelo A en España?», si el Modelo A y la garantía se establecieron claramente en el diálogo inmediatamente anterior. La reescritura aún no responde a la pregunta; su único propósito es encontrar las fuentes adecuadas.

La guía de arquitectura actual de Azure sobre Conversational RAG recomienda incluir el historial de conversación relevante y formular la pregunta actual antes del retrieval como una consulta independiente con las referencias resueltas. Es importante destacar la separación que también se reconoce allí: para la respuesta posterior, se conserva la pregunta original del usuario. De este modo, el sistema puede verificar si las evidencias encontradas realmente coinciden con la pregunta formulada.

Completar, pero no inventar

Un reescritor (rewriter) puede adoptar datos que estén presentes de forma inequívoca: producto, versión, país, idioma o el último proceso mencionado. Sin embargo, no debe añadir un número de cliente que falte, no debe asumir una variante de producto ni convertir un plazo incierto en una fecha concreta. Una precisión que parezca útil pero que sea inventada enviará con total seguridad la búsqueda en la dirección equivocada.

Los permisos se mantienen fuera del modelo de texto

El tenant, el usuario autenticado, las áreas de documentos autorizadas y los roles se determinan en el lado del servidor. No deben incluirse como afirmaciones redactadas libremente en la consulta reescrita. El backend aplica los filtros de metadatos correspondientes de forma separada e inalterable. Ni un mensaje anterior del chat ni la reescritura del modelo deben poder desbloquear un espacio de búsqueda más amplio.

El contexto necesita un presupuesto deliberado

Enviar todo el historial del chat sin filtrar al reescritor rara vez es una buena solución. Los temas antiguos pueden solapar la pregunta actual, el contenido de datos personales puede arrastrarse innecesariamente y los historiales largos aumentan la latencia y los costes. Como orientación práctica, la guía de Microsoft sugiere de dos a cinco turnos de conversación recientes y un resumen de los contenidos más antiguos. No se trata de un límite universal, sino de un punto de partida para realizar pruebas propias.

Un paquete de contexto compacto puede constar de los siguientes elementos:

• la pregunta actual del usuario sin modificaciones,
• unos pocos mensajes del usuario y del asistente que sean directamente relevantes,
• entidades ya confirmadas como producto, proceso u ubicación,
• locale y zona horaria como campos técnicos,
• un resumen breve y verificado de las partes más antiguas del diálogo, y
• la versión de la regla de reescritura, el índice de conocimiento y la configuración de retrieval.

Los permisos reales sobre los documentos se mantienen al margen. Asimismo, se deben eliminar las direcciones de correo electrónico, números de pedido o respuestas completas que no sean necesarias antes de la reescritura. Un historial ajustado a la minimización de datos facilita además la posterior resolución de errores.

Un flujo de trabajo robusto en seis pasos

1. Verificar la independencia: Una pregunta nueva y clara como «¿Cómo cambio mi contraseña?» puede ir directamente a la búsqueda. No todos los mensajes necesitan una reescritura por parte del modelo.
2. Identificar referencias: El sistema detecta pronombres, elipsis, palabras comparativas y referencias como «allí», «ambos» o «la segunda opción».
3. Seleccionar el contexto relevante: Solo se incluyen las intervenciones que resuelvan estas referencias de manera plausible. Un cambio deliberado de tema pone fin al contexto anterior.
4. Decidir entre reescritura o repregunta: Si existe exactamente una resolución sólida, se genera una consulta de búsqueda independiente. Si existen varios significados plausibles, el chatbot realiza una breve pregunta de aclaración.
5. Buscar y, si es necesario, descomponer: La consulta pasa por la búsqueda Keyword, vectorial o Hybrid Search. Las preguntas compuestas se pueden descomponer en subpreguntas claramente definidas.
6. Responder a la pregunta original: La respuesta se genera a partir de las fuentes encontradas, se refiere a la redacción original y menciona abiertamente las incertidumbres o la falta de evidencias.

La visión general de Microsoft sobre Agentic Retrieval describe un flujo similar: la consulta y el historial de conversación se integran en la planificación, las subconsultas focalizadas se ejecutan en paralelo y los resultados se consolidan posteriormente. La documentación de Amazon Bedrock también detalla la planificación, las subconsultas iterativas y la verificación de si el contenido encontrado es suficiente para elaborar una respuesta. Estas funciones de producto pueden asumir partes del canal, pero las barreras de calidad y seguridad de la propia aplicación siguen siendo necesarias.

¿Reescritura, pregunta de aclaración o Query Decomposition?

Entrada	Reacción adecuada	Justificación
«¿Y esto aplica en España?» tras una pregunta clara sobre garantías	Formular una consulta independiente	El objeto y la referencia son inequívocos.
«¿Qué pasa con la otra?» tras haber mencionado tres variantes	Hacer una breve pregunta de aclaración	Existen varias interpretaciones plausibles.
«Compara el precio, el plazo de entrega y la devolución para ambos modelos»	Descomponer en subconsultas focalizadas	Varios aspectos independientes requieren resultados sólidos.
«Nuevo tema: ¿cómo me pongo en contacto con soporte?»	Buscar sin el contexto anterior del producto	El usuario señala un cambio de tema.

Por lo tanto, la Query Decomposition no es lo mismo que el Query Rewriting. El Rewriting convierte una pregunta dependiente en una independiente; la Decomposition divide una pregunta compleja en varias tareas de búsqueda. La documentación de Bedrock sobre Query Decomposition muestra que múltiples subconsultas pueden mejorar la cobertura. Sin embargo, cada consulta adicional requiere un límite, un modelo de permisos común y una consolidación trazable.

Tratar las salidas de la reescritura como si fueran código

Aunque el resultado sea solo texto, debe contar con un contrato estricto. Lo ideal es un objeto estructurado con campos como standaloneQuery, decision, resolvedReferences y reason. Las decisiones válidas pueden ser, por ejemplo, SEARCH_AS_IS, REWRITE, CLARIFY y DECOMPOSE. El backend valida la longitud, el idioma y los campos permitidos antes de iniciar la búsqueda.

El reescritor no recibe herramientas ni responde directamente al usuario. Las instrucciones del sistema procedentes del historial del chat, los textos de documentos insertados o peticiones como «Ignora las reglas» siguen siendo datos, no comandos de control. Para espacios de búsqueda de alto riesgo, una regla determinista puede forzar además que los filtros de producto, locale o tenant nunca provengan de texto libre.

Probar con un conjunto de pruebas propio para preguntas de seguimiento

La calidad no se puede demostrar con demos aisladas que hayan salido bien. Complemente el Golden Set para la calidad de respuesta existente con diálogos múltiples reales. Para cada caso, se deben registrar el historial original, la pregunta actual, la decisión de reescritura esperada, las entidades permitidas, las adiciones prohibidas y las fuentes esperadas.

• Pronombres y sujetos elididos en preguntas de seguimiento breves
• Correcciones como «No, me refería al Modelo B»
• Cambios de tema y retornos a un tema anterior
• Variantes ambiguas que requieran obligatoriamente una repregunta
• Cambios de locale, fecha y zona horaria
• Intentos no autorizados de cambiar el espacio de búsqueda o el tenant
• Historiales largos con detalles antiguos irrelevantes
• Preguntas compuestas que deban descomponerse y consolidarse posteriormente

Mida por separado: ¿Coincide la reescritura con la intención del usuario? ¿Encuentra el retrieval las fuentes esperadas? ¿Se volvió a preguntar en caso de una ambigüedad real? ¿Se mantuvieron inalterables los filtros de permisos? ¿Cuánta latencia adicional genera este paso? El marco NIST AI RMF Core integra la realización repetida de pruebas, mediciones y documentación en todo el ciclo de vida de la IA. Para los equipos web, esto significa: cambiar la regla de reescritura, el modelo o la selección de contexto únicamente tras pasar pruebas de regresión y mediante un despliegue observable.

Lista de comprobación compacta para equipos web

• ¿Se conserva la pregunta original del usuario sin cambios hasta la respuesta?
• ¿Se incluyen únicamente partes del historial relevantes y acordes a la minimización de datos?
• ¿Puede el reescritor elegir claramente entre reescritura, repregunta y descomposición?
• ¿Añade exclusivamente entidades confirmadas y ninguna suposición?
• ¿Aplica el backend el locale, el tenant y los permisos de forma independiente a la reescritura?
• ¿Cuenta cada subconsulta con límites fijos de cantidad, tiempo y costes?
• ¿Se evalúan los resultados del retrieval en función de la pregunta original?
• ¿Cubre el conjunto de pruebas de diálogos múltiples las referencias, correcciones y cambios de tema?

Conclusión: primero aclarar la consulta de búsqueda, luego responder

El RAG Query Rewriting convierte la brevedad natural de la conversación en una consulta de búsqueda sólida. El mayor beneficio no proviene de hacer reescrituras lo más creativas posible, sino de establecer límites claros: adoptar el contexto confirmado, resolver la incertidumbre mediante preguntas de aclaración, mantener los permisos en el lado del servidor y seguir evaluando la respuesta frente a la pregunta original. Comience con veinte preguntas de seguimiento típicas de su servicio de soporte, marque la decisión esperada y pruebe cada cambio frente a esos mismos casos. Así, un chat de múltiples turnos será más comprensible sin que la búsqueda responda en silencio a una pregunta diferente.

Fuentes

• Microsoft Azure Architecture Center: Prompt Engineering para RAG
• Microsoft Learn: Agentic Retrieval en Azure AI Search
• Amazon Bedrock: Configurar consultas y generación de respuestas
• Amazon Bedrock: Agentic Retrieval para bases de conocimiento
• NIST AI Risk Management Framework Core