Filtros de metadatos RAG para chatbots de IA: separar idioma, versión y acceso

Un chatbot de IA puede encontrar pasajes de texto semánticamente muy similares y, aun así, preparar la respuesta incorrecta: el manual en inglés en lugar del español, la documentación de la versión anterior en lugar de la actual o notas internas para un invitado sin permiso. En ese caso, la clasificación no es necesariamente mala. Lo que estaba mal era el espacio de búsqueda.

Los filtros de metadatos RAG resuelven exactamente este problema. Limitan antes o durante la búsqueda qué documentos y fragmentos (chunks) pueden considerarse como contexto. La relevancia responde después a la pregunta "¿Qué es lo que mejor encaja por contenido?". El filtro responde primero a "¿Qué se permite y debe tener en cuenta en esta situación?".

Por qué la similitud por sí sola no es un alcance confiable

La búsqueda vectorial e híbrida ordena los contenidos según su cercanía lingüística o semántica. Un manual para la versión 4 de un producto puede ser especialmente similar a una pregunta sobre la versión 5. Una lista de precios para otro mercado puede contener los mismos nombres de productos. Y un documento interno de soporte puede ofrecer una respuesta más precisa que las preguntas frecuentes públicas, aunque nunca debería aparecer en un chat público.

Por lo tanto, el recuperador (retriever) debe distinguir dos tipos de condiciones:

• Límites estrictos como cliente/inquilino (tenant), rol, estado de publicación o rango de datos permitido. Ante un valor desconocido, la búsqueda debe permanecer cerrada.
• Criterios de selección funcionales como idioma, familia de productos, versión, región o período de validez. Aumentan la precisión y evitan contextos contradictorios.

El resumen actual de OWASP para aplicaciones LLM asigna explícitamente los riesgos de vectores y embeddings al límite de confianza de una aplicación de IA. Esta es una perspectiva importante: un control de autenticación antes del chat no es suficiente si la búsqueda de similitud posterior se ejecuta en un índice demasiado amplio.

Un esquema de metadatos sostenible para el día a día

Los buenos filtros no comienzan con una consulta larga, sino con unos pocos campos canónicos. Para muchos chatbots de sitios web, seis grupos son suficientes:

• Idioma y mercado: por ejemplo, locale y market, con valores fijos definidos en lugar de texto libre.
• Producto y versión: ID de producto estable, rango de versión y, opcionalmente, plataforma o tarifa.
• Validez: estado de aprobación, válido desde, válido hasta y una versión de fuente única.
• Público objetivo: público, cliente, socio o equipo interno (separado de la verificación de roles real).
• Ámbito de acceso: cliente/inquilino, grupo o principal, proveniente exclusivamente de un contexto de servidor verificado.
• Origen: ID de origen, URL, tipo de documento y área de contenido responsable para garantizar la trazabilidad.

Los metadatos pertenecen al nivel en el que se realiza la búsqueda. Si un documento se divide en fragmentos, los campos de alcance clave deben terminar de forma confiable en cada fragmento. De lo contrario, un documento puede estar clasificado correctamente mientras que los resultados de búsqueda individuales pierden esa clasificación. La documentación de OpenAI sobre File Search muestra, por ejemplo, cómo se utilizan los atributos de archivo para el filtrado de metadatos. La referencia de Amazon Bedrock documenta operadores de comparación, lista y rango para la misma idea básica.

Nunca permita que el modelo de lenguaje autorice los filtros

Un modelo puede deducir pistas como el idioma o la referencia del producto a partir de la pregunta. Sin embargo, no debe decidir a qué cliente/inquilino pertenece una persona o qué rol tiene. Estos valores deben provenir de la sesión, del sistema de identidad y de las reglas de negocio del lado del servidor. Tampoco se debe pasar una cadena de filtro generada por el modelo al servicio de búsqueda sin verificar.

Un flujo de trabajo sólido se ve así:

1. El servidor autentica la solicitud y determina el rango de datos permitido.
2. Las reglas deterministas establecen campos estrictos como cliente/inquilino, rol y estado de publicación.
3. Las características detectadas, como el idioma o el producto, se validan con respecto a los valores permitidos.
4. El recuperador solo ejecuta una estructura de filtro parametrizada y tipada.
5. La aplicación vuelve a verificar las fuentes devueltas para comprobar el alcance esperado.
6. En caso de que falte contexto o sea contradictorio, el chatbot solicita aclaraciones o emite una respuesta alternativa segura (fallback).

La documentación de Microsoft sobre Security Filters hace una distinción útil: un principal en el filtro es inicialmente solo un valor. La autenticación y la autorización deben llevarse a cabo de manera confiable fuera de la expresión de búsqueda. Para portales de clientes, nuestra publicación sobre la separación entre chatbot de IA público y autenticado profundiza en este límite.

¿Prefiltrado o posfiltrado?

La posición del filtro afecta la calidad y el tiempo de ejecución. Un prefiltro limita los candidatos durante la búsqueda vectorial. Un posfiltro busca primero de forma más amplia y luego elimina los resultados no permitidos. Según la documentación de Azure sobre filtros vectoriales, el posfiltrado puede omitir resultados adecuados con filtros selectivos y un valor de k pequeño; el prefiltrado favorece la exhaustividad (recall) en el subconjunto permitido, pero puede causar más esfuerzo computacional con filtros muy estrechos.

Para límites de acceso estrictos, "buscar primero en amplio y ocultar después" no es un patrón básico adecuado. El alcance autorizado debe imponerse dentro de la consulta de búsqueda. Para filtros puramente funcionales, un equipo puede medir las variantes de pre y posfiltrado. Lo que cuenta aquí no es solo el tiempo medio de respuesta, sino también la frecuencia con la que falta un resultado permitido existente debido al orden elegido.

Los filtros no reemplazan la clasificación. Dentro del corpus permitido, Hybrid Search y Reranking pueden seguir priorizando las mejores fuentes. Por lo tanto, el orden es: definir el alcance, recuperar candidatos, evaluar la relevancia, verificar fuentes y generar la respuesta.

Cuatro casos de uso de filtrado típicos

Idioma con una respuesta alternativa deliberada

Para una pregunta en español, la primera recuperación debe elegir contenido aprobado en español. Si no hay resultados, la aplicación no debe mezclar silenciosamente varios idiomas. Una segunda ruta explícita puede recurrir a un idioma base aprobado y señalar esta circunstancia en la respuesta. Una evaluación Locale-QA para bases de conocimiento multilingües también verifica si las variantes son realmente equivalentes en contenido.

Versión del producto y validez temporal

Una fuente no debe parecer actualizada únicamente porque se rastreó recientemente. Lo decisivo es la versión funcional y la aprobación. Marque el contenido con ID de producto estable, rango de versión, valid_from, valid_until y estado. En caso de aprobaciones superpuestas, el flujo de trabajo (pipeline) debe reportar un conflicto en lugar de colocar ambos textos en la misma instrucción (prompt). Cómo interactúan la cadencia de rastreo y el mantenimiento de fuentes se describe en la guía sobre mantener actualizada la base de conocimiento del chatbot de IA.

Cliente/Inquilino y rol

Con un índice compartido, cada consulta debe contener el cliente/inquilino determinado por el servidor y los principales válidos. La falta de metadatos de ACL significa "no recuperable", no "público". Después de un cambio de rol o de la revocación de un permiso, una prueba debe mostrar que las sesiones antiguas ya no reciben fragmentos previamente autorizados.

Soporte público e instrucciones de trabajo internas

Una instrucción de escalamiento interna puede encajar perfectamente desde el punto de vista temático con la pregunta de un cliente. Eso no la convierte en una fuente permitida. Separe el alcance de publicación y el tipo de documento; marque el contenido no aprobado como excluido de forma predeterminada. En caso de duda, un bot público debería cambiar a una ruta de contacto o derivación humana (handoff) en lugar de adivinar detalles internos.

Los errores de implementación más comunes

• Taxonomía de texto libre: Valores como es, ES y es-ES forman involuntariamente tres grupos.
• Apertura por defecto (Default-open): Los fragmentos sin rol, estado o cliente/inquilino entran en cualquier espacio de búsqueda.
• Lógica booleana incorrecta: Un OR entre el cliente/inquilino y el idioma elimina prácticamente el límite estricto.
• Desviación entre documento y fragmento (Document-Chunk-Drift): Al reindexar, los nuevos metadatos no se transfieren a todos los fragmentos.
• Solo pruebas positivas: El equipo verifica si aparece un documento permitido, pero no si falta con seguridad un documento prohibido de contenido similar.
• Resultados vacíos tratados como problema del modelo: Un filtro estricto no devuelve nada y la aplicación permite que el modelo continúe respondiendo sin fuentes.

Control de calidad de filtros: probar límites, no solo coincidencias

Un conjunto de pruebas útil contiene al menos un candidato opuesto cercano para cada respuesta esperada: idioma incorrecto, versión antigua, aprobación caducada, otro cliente/inquilino o público objetivo interno. De esta forma, la prueba muestra si el filtro realmente separa y no solo coloca el resultado correcto arriba por casualidad.

Las métricas clave son la tasa de violación del alcance, la exhaustividad (recall) en el subconjunto permitido, la proporción de recuperaciones vacías, la cantidad de valores de metadatos desconocidos, la latencia del filtro en el percentil 95 y la proporción de respuestas alternativas y preguntas de aclaración. Para el contenido restringido, la tasa de violación del alcance tolerada debe ser cero. El NIST AI RMF Core recomienda probar los sistemas de IA antes del despliegue y periódicamente durante la operación, documentando los límites de seguridad, confiabilidad y contexto.

Para ello, no registre contenido innecesario ni preguntas completas de los usuarios. Por lo general, basta con la versión del filtro, el alcance abstracto, el número de candidatos, las ID de origen seleccionadas, el motivo de rechazo y el resultado del control posterior. Esto permite la solución de problemas sin crear una segunda fuga de datos en el sistema de observabilidad.

Lista de verificación práctica antes del lanzamiento

1. Documentar los campos de metadatos canónicos, tipos de datos, valores permitidos y propietarios.
2. Separar los límites de acceso estrictos de los campos de selección funcionales.
3. Tratar sistemáticamente los valores relevantes para la seguridad que falten como no autorizados.
4. Construir filtros a partir de un contexto de servidor verificado y parametrizar las entradas.
5. Leer por muestreo los metadatos después de la ingesta y el fragmentado (chunking).
6. Probar casos positivos, negativos, límite y de revocación contra el índice real.
7. Medir el comportamiento del pre y posfiltrado con un k realista y alcances selectivos.
8. Manejar los resultados vacíos mediante preguntas de aclaración, una respuesta alternativa segura o derivación a un agente humano.
9. Versionar los cambios de filtros y desplegarlos junto con pruebas de regresión de recuperación.

Los filtros de metadatos RAG son, por lo tanto, más que una función de comodidad de búsqueda. Son el vínculo entre el modelo de contenido, la identidad, la frescura de datos y la calidad de la recuperación. Aquellos que primero establecen el alcance de forma determinista le dan al ranking y al modelo de lenguaje una base de trabajo más pequeña, más limpia y verificable.

Siguiente paso: Elija una pregunta de soporte real y construya cinco fuentes opuestas casi coincidentes con idioma, versión y permisos incorrectos. Solo cuando ninguna de ellas supere el alcance de recuperación permitido, el filtro debería pasar al flujo de chat en producción.

Fuentes

• OpenAI: File Search y filtrado de metadatos
• Microsoft: Filtros en consultas vectoriales
• Microsoft: Patrón de filtros de seguridad
• Amazon Bedrock: API RetrievalFilter
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026