¿Qué tan difícil es crear un motor de búsqueda realmente bueno? — Índice: Un sistema dinámico de recuperación de documentos con una precisión de milisegundos, diseñado específicamente para agentes de IA. Esta presentación técnica completa, a cargo de Abhi, fundador de @opennote, se centra en Index, su sistema de búsqueda desarrollado internamente. Este sistema no es un motor de búsqueda basado en humanos, sino que está diseñado para que agentes de IA logren una recuperación extremadamente rápida y precisa de las bases de conocimiento personales de los usuarios. ¿Por qué los sistemas de búsqueda existentes no pueden satisfacer las necesidades de los agentes inteligentes? Los motores de búsqueda tradicionales están diseñados para humanos. Los humanos aprenden gradualmente a comprender las peculiaridades del sistema, aprendiendo a reemplazar o complementar palabras y a ignorar fallos. Sin embargo, los agentes inteligentes carecen por completo de esta capacidad. Cada consulta comienza desde cero; carecen de memoria y de sensibilidad para la base de conocimientos. Y lo que es aún más grave: • Los agentes inteligentes son muy susceptibles a las alucinaciones; si el contexto es ligeramente erróneo, toda la respuesta se desmoronará. • Opennote normalmente maneja sólo unos pocos miles (no cientos de millones) de documentos, con una tolerancia prácticamente nula a los errores y requiriendo encontrar el segmento más correcto en el primer intento. • Dado que el producto está dirigido a consumidores comunes, no puede esperar unos pocos segundos como una herramienta de investigación; la latencia de extremo a extremo debe ser estable dentro de unos pocos cientos de milisegundos. Los autores enfatizan repetidamente que un índice debe cumplir simultáneamente los siguientes requisitos casi contradictorios: 1. Latencia extremadamente baja: P99 < 300 ms (misma velocidad en cualquier parte del mundo) 2. Alta precisión: Cuando un mismo concepto aparece en diferentes documentos, también es necesario encontrar aquel con el contexto más preciso. 3. Multitenencia y alcance dinámico: admite búsquedas simultáneas de cualquier combinación de "solo yo", "compartido con amigos", "toda la comunidad" y "más páginas públicas" sin degradación del rendimiento. 4. Baja latencia global: los usuarios y los agentes pueden estar en lados opuestos de la Tierra. 5. Los datos nunca son estáticos: los usuarios pueden editarlos, compartirlos, eliminarlos y cambiar permisos en cualquier momento. Selección de tecnología clave (muchas de las cuales son contraintuitivas) 1. El motor de búsqueda y almacenamiento elegido es Postgres (pgvector + pg_trgm + tsvector), alojado en PlanetScale, en lugar de las principales bases de datos vectoriales dedicadas como Pinecone, Weaviate, Qdrant y Chroma. La razón es: • Filtrado de metadatos extremadamente rápido, que minimiza el conjunto de candidatos antes de los cálculos vectoriales. • Soporte nativo para recuperación híbrida real (texto completo + coincidencia difusa + semántica). • El límite multiusuario, el filtrado dinámico y las funciones UPSERT/DELETE son inherentemente eficientes. • Pruebas reales muestran que la latencia P99 se redujo de 475 ms a 209 ms. 2. Toda la arquitectura de ejecución distribuida global se ejecuta en el ecosistema de Cloudflare: Workers + Hyperdrive + R2 + Workers AI + Vectorize + KV. La ventaja es que el código se ejecuta naturalmente en docenas de nodos de borde alrededor del mundo y, al acceder a la base de datos, se siente tan rápido como el acceso local después de ser acelerado por Hyperdrive. 3. Canal de procesamiento de documentos (Ingestión) Adopta un diseño de almacenamiento de objetos Worker + R2 completamente sin estado, adaptándose estrictamente al límite de memoria de 128 MB del Worker. El proceso es el siguiente: 1. Descomposición recursiva de bloques (suficientemente robusta para todo tipo de documentos desordenados) 2. Utilice el hash para comparar con precisión los fragmentos antiguos y nuevos, recalculando solo las partes realmente modificadas. 3. Vuelva a incrustar únicamente los fragmentos modificados (ahorra tiempo y dinero) 4. Generar resúmenes de documentos y párrafos importantes, brindando al agente contexto adicional sobre "de qué trata todo el documento". 5. INSERTAR nuevo fragmento 6. Elimine el fragmento antiguo y active la invalidación de caché. 4. Proceso de búsqueda 1. Al recibir una consulta del agente, primero realice la limpieza de parámetros y la concatenación de condiciones de filtro. 2. En Postgres, utilice metadatos para minimizar previamente el espacio de búsqueda (inquilino, fuente, etiqueta, tiempo, exclusión explícita, etc.). 3. Ejecute la búsqueda de texto completo y la búsqueda vectorial en paralelo en el conjunto de datos filtrado. 4. Normalice los dos conjuntos de puntuaciones a 0-1 y fusionelos dinámicamente utilizando un parámetro llamado alfa (0 = palabras clave puras, 1 = semántica pura). 5. Realice la deduplicación, la clasificación y la recuperación de los K principales dentro de la base de datos. 6. Opcionalmente, utilice Workers AI para realizar una reordenación liviana y, finalmente, devolver el resultado. 5. Sistema de almacenamiento en caché (la parte más ingeniosa) Los cachés regulares se ensucian después de las actualizaciones de documentos; el autor diseñó un mecanismo de tres capas para resolver completamente este problema: • Almacenamiento en caché preciso: la misma consulta + las mismas condiciones de filtrado afectan directamente al par clave-valor. • Almacenamiento en caché semántico: Use Vectorize para almacenar incrustaciones de consultas, lo que garantiza que consultas similares se puedan almacenar en caché. • Invalidación de índice invertido: Cada fragmento registra las consultas que aparecen en la caché; si un fragmento deja de ser válido, todas las cachés relacionadas se eliminan de forma proactiva. Esto reduce en gran medida la presión sobre la base de datos y garantiza que nunca se devuelva contenido obsoleto. Los resultados de la prueba real se compararon rigurosamente con ChromaDB utilizando el conjunto de datos estándar MSMARCO (10 000 pares de preguntas y respuestas) + el modelo BGE-M3. En cuanto a cuatro métricas (Recall@10, MRR@10, MAP@10 y NDCG@10), Index es prácticamente igual o ligeramente superior a Chroma. Además, cuenta con funciones adicionales como recuperación híbrida, aislamiento multiusuario y filtrado dinámico. En un entorno de producción real, la latencia P99 se mantiene estable en 300 ms. Index ahora lleva oficialmente la carga de búsqueda completa para las funciones de la comunidad Opennote. El autor cree que el índice actual es simplemente una herramienta de "recuperación" y que el siguiente paso es convertirlo en una herramienta de "comprensión": • Añadir relaciones temporales, causales y evolutivas entre fragmentos. • Introducir indicadores de importancia/popularidad. • Continuar destilando modelos de incrustación más pequeños, rápidos y especializados. • Permitir a los agentes personalizar estrategias de recuperación de varios pasos. El objetivo final es permitir que los agentes inteligentes posean realmente un "modelo mental" de la base de conocimientos del usuario, en lugar de adivinar a ciegas desde cero cada vez.
