Recorrido de diseño de la búsqueda de documentos sobre un corpus: canalización de indexación, permisos y reindexación

Objetivo

Buscar sobre un corpus que reside en un sistema de registro, con resultados que respeten los permisos y un índice que nunca se retrase respecto a la fuente más allá de un límite establecido.

Requisitos previos

Una definición de documento (id, título, cuerpo, metadatos, propietario, visibilidad, updated_at), los idiomas implicados, y un límite de actualidad (freshness) que el producto acepte.

Pasos

1. Restricciones: la fuente sigue siendo la autoridad y el índice es derivado y reconstruible; un usuario nunca debe ver un fragmento (snippet) de un documento que no puede abrir; la consulta por cada pulsación de tecla es una decisión de producto, no un valor por defecto.
2. Componentes: un indexador alimentado por eventos de cambio (un outbox) o por sondeo de updated_at; un almacén de índice, comenzando con el índice de texto completo propio de la base de datos y pasando a un motor dedicado cuando las funciones de ranking o la escala lo exijan; un servicio de consultas que analiza la entrada, aplica filtros de permisos, clasifica y resalta; un reconciliador que compara la fuente y el índice.
3. Modelo de datos: search_doc(doc_id, version, text fields, acl_keys[], updated_at, indexed_at); las claves de ACL (id del propietario, ids de grupo, public) son campos indexados, de modo que el filtrado ocurre dentro del motor en lugar de después del ranking. En PostgreSQL, la documentación indica que los índices GIN son el tipo de índice de búsqueda de texto preferido, y mantienen una entrada por lexema con una lista comprimida de ubicaciones.
4. Gestión del índice: versionar el índice (docs_v3) y cambiar un alias tras una reconstrucción completa; mantener el indexador idempotente (upsert por doc_id, ignorando versiones anteriores a la ya indexada); tratar las eliminaciones como eventos explícitos, nunca por ausencia.
5. Ranking: comenzar con la relevancia por defecto del motor más un peso de título y un término de actualidad; registrar la consulta, los id de resultado y la posición del clic, de modo que un cambio de ranking posterior pueda evaluarse frente al registro.
6. Modos de fallo: eventos de cambio perdidos (el reconciliador compara los recuentos y el updated_at máximo por rango, y reindexa la diferencia); cambios de permisos no propagados (tratar las ediciones de ACL como actualizaciones de documento); consultas muy largas o con muchos comodines (limitar la longitud, no permitir comodines al inicio); reindexación bajo carga (regular el ritmo, leer desde una réplica); fragmentos que exponen campos que el documento visible oculta (indexar solo lo que puede mostrarse).
7. Medir: el retraso del índice (updated_at de la fuente menos indexed_at), la latencia de consulta, la tasa de resultados cero, la proporción de consultas con un clic entre los primeros resultados, la desviación (drift) detectada por el reconciliador, la duración de la reindexación completa.
8. No primero: la búsqueda semántica o vectorial, los sinónimos y la corrección ortográfica, el ranking personalizado, el autocompletado, la búsqueda entre idiomas.

Resultado esperado

Un documento editado en la fuente aparece dentro del límite de actualidad, desaparece cuando se elimina u oculta, y una reconstrucción desde cero es una operación rutinaria y no un incidente.

Límites y base de verificación

Diseño propuesto, sin mediciones. La calidad de la relevancia no se aborda más allá de registrar lo suficiente para evaluarla después; el límite de actualidad es una entrada del producto, no una propiedad del diseño.