title: 7 · Filtrar antes de buscar: el pre-filtrado
7 · Filtrar antes de buscar: el pre-filtrado
Llegamos al corazón técnico del libro, y conviene llegar desinflados de mitos. De toda la ingeniería de recuperación, la pareja pre-filtrado / post-filtrado es la que más se usa mal, y se usa mal porque se presenta como una preferencia de implementación —"según el motor, se hace de una forma u otra"— cuando en realidad es una decisión de arquitectura con consecuencias matemáticas. Este capítulo toma partido desde el título: filtra antes. Los dos siguientes explican por qué, qué cuesta y dónde está el límite.
Qué significa, exactamente, filtrar antes
El pre-filtrado consiste en decidir, antes de calcular ninguna similitud, qué píldoras son elegibles para la consulta. Dominio del cliente, vigencia de la norma, estado editorial, permisos: todo lo que el contrato declara obligatorio se aplica como condición de entrada. Solo entonces el motor busca lo parecido —pero únicamente dentro de ese universo acotado—. La imagen mental correcta no es "buscar y quitar": es cerrar las puertas de las estanterías prohibidas y solo después encender la linterna. La similitud nunca llega a ver lo no elegible; no lo ordena peor, no lo penaliza: no lo ve.
Es una diferencia de categoría, no de matiz, y se entiende mejor con el caso que la enseñó. La consulta sobre el plus de nocturnidad llegó un día con el contexto del cliente siderúrgico mientras el corpus entero contenía treinta y un convenios. Sin pre-filtrado, el primer resultado fue el convenio de hostelería —gemelo semántico del convenio del metal, como se contó en el capítulo cinco—. Con pre-filtrado, la hostelería no participó: sus puertas estaban cerradas. No se necesitó reranker, ni umbrales, ni suerte: el error fue imposible, no improbable. Esa es la aportación esencial del pre-filtrado y la razón por la que el contrato lo exige para todo lo crítico: convierte ciertos fallos en imposibles. En un sistema que responde sobre derechos de personas, convertir lo improbable en lo imposible no es una optimización: es la definición de hacer bien el trabajo.
El precio: el índice que sufre el filtro
Hasta aquí, todo ventajas. Ahora el coste, porque lo tiene, y es el coste más mal explicado de esta disciplina. Los motores vectoriales no comparan la consulta contra todas las píldoras una a una: usan índices de vecindad —la técnica más común se llama HNSW— que construyen, en la fase de ingesta, algo parecido a un mapa de barrios: cada punto conectado con sus vecinos más cercanos, con rutas que permiten, con pocas paradas, llegar a la zona de la consulta. Es lo que hace que buscar entre millones de vectores tarde milisegundos. El detalle que importa es que ese mapa se construyó sin saber nada de futuros filtros: los barrios mezclan, en el mismo edificio, la píldora del convenio del metal y la de hostelería, porque son vecinas en sentido semántico aunque vivan en dominios distintos.
Y ahí aparece el problema: cuando el filtro aprieta —el dominio de un cliente pequeño contiene el 0,5 por ciento del corpus—, el motor recorre el mapa de barrios encontrando que casi todas las puertas están cerradas. Con filtros poco selectivos, todo va bien: el filtro deja pasar la mayoría y la búsqueda fluye. Con filtros muy selectivos, el recorrido se degrada: algunos motores abandonan la navegación y pasan a un recorrido exhaustivo —comprobar candidato a candidato, exacto pero más lento—, otros simplemente devuelven menos resultados de los pedidos. La consecuencia práctica es una regla de diseño que conviene grabarse: el pre-filtrado es barato cuando deja pasar mucho y caro cuando deja pasar poco. Un filtro que deja pasar el 30 por ciento del corpus es gratuito. Uno que deja pasar el 0,5 por ciento puede multiplicar la latencia —o quedarse sin resultados por el camino—, y hay que saber que el motor está ahí, en ese límite, antes de diseñar sistemas sobre filtros hiperselectivos.
Conviene decir también que los motores han ido construyendo defensas —índices parciales por faceta, estrategias de filtro que se adaptan a la selectividad, opciones de fuerza bruta controlada—, y que están bien explicadas en el apéndice C, con criterios para compararlas. Pero la conclusión de arquitectura no depende del motor de este año: las restricciones duras van pre-filtradas aunque cuesten, porque no son negociables; lo que el coste obliga a revisar es el diseño de la partición, no la decisión. Si un cliente genera millones de píldoras y sus filtros son caros, la respuesta no es bajar el filtro a post: es repensar la partición —colección propia, como vimos en el capítulo cinco—.
La granularidad del filtro: consulta, sesión, sistema
Hay una segunda dimensión del pre-filtrado que casi nunca se documenta: quién aporta cada condición y cuándo. El filtro no es un bloque monolítico que salta en el momento de la búsqueda; es una pila de condiciones que se ha ido formando antes, y diseñar esa pila es parte del oficio. Hay condiciones de sesión que el sistema aplica siempre y sin que nadie las pida: el dominio del cliente activo, el permiso del usuario conectado, la vigencia. No dependen del texto de la consulta y por eso no pueden fallar por despiste del usuario: están antes de que el usuario empiece a escribir. Hay condiciones de consulta que se derivan del texto cuando el texto las dice: "en el convenio del metal", "sentencias de 2024". Y hay condiciones de política que el contrato impone sin excepción: lo confidencial no entra, lo caducado no entra, lo no validado no entra.
El valor de separar los niveles es que cada nivel tiene un modo de fallo distinto y distinto remedio. Si falla una condición de sesión, es un bug de contexto —grave, silencioso, se arregla en la capa de aplicación—. Si falla una de consulta, es un problema de comprensión del lenguaje —se arregla con extracción de filtros mejor hecha—. Y las de política no pueden fallar por diseño, porque no dependen de nadie: se aplican como la gravedad. Cuando el capítulo nueve hable de permisos, esta separación será precisamente lo que sostenga la seguridad: lo que depende del usuario no puede depender del usuario.
Criterio de salida
Las restricciones duras del contrato —dominio, vigencia, estado, permiso— se aplican pre-búsqueda, en el 100 por ciento de las consultas, en tres niveles separados: sesión, consulta y política. La selectividad de cada filtro está medida y sus latencias conocidas; los filtros hiperselectivos tienen partición propia o plan para tenerla.
Queda media pareja en el aire: el filtro que llega tarde. No es el hermano pobre del pre-filtrado; es otra herramienta con otra matemática —y una trampa aritmética que ha hundido más de un sistema—. El post-filtrado, en la siguiente página.