Cómo construir desde cero en 2 meses un motor de búsqueda web con 300 millones de embeddings neuronales

• A partir del deterioro en la calidad de los motores de búsqueda y de los avances en modelos de embeddings basados en Transformer, se presenta la experiencia de desarrollar durante 2 meses un motor de búsqueda web basado en 300 millones de embeddings
• Mediante un total de 200 clústeres de GPU, rastreadores distribuidos a gran escala, RocksDB, HNSW y otra infraestructura y algoritmos de alto rendimiento, se implementó una búsqueda con comprensión de lenguaje natural en tiempo real
• Con el objetivo de ofrecer preguntas y respuestas centradas en la intención en lugar de coincidencias por palabras clave, se aplicaron diversas técnicas de NLP/ML como normalización, chunking y encadenamiento de enunciados para el parsing de documentos y la preservación del contexto
• Se presentan el diseño de sistemas distribuidos a gran escala en cada capa —pipeline, almacenamiento, service mesh, índice vectorial, etc.— así como estrategias para optimizar cuellos de botella y costos
• Finalmente, se describe la creación de un motor de búsqueda personalizado con latencia ultrabaja, gran distribución y alta precisión

---

Panorama general y motivación

• El autor decidió construir recientemente un motor de búsqueda desde cero, motivado por la preocupación ante la caída en la calidad de los buscadores, el spam SEO y el aumento de contenido irrelevante, así como por el hecho de que los modelos de embeddings basados en Transformer han mejorado notablemente su comprensión del lenguaje natural
• Las limitaciones de los motores de búsqueda existentes provienen de su falta de comprensión de preguntas a nivel humano y de su simple coincidencia basada en palabras clave
• El objetivo es lograr un ranking centrado en la intención que permita que el contenido de buena calidad siempre aparezca en los primeros resultados y que explore de manera equilibrada incluso la cola larga
• El proceso de construir un motor de búsqueda web abarca múltiples áreas, entre ellas ciencias de la computación, lingüística, ontología, NLP, ML, sistemas distribuidos e ingeniería de rendimiento
• Este proyecto fue el desafío de implementar un motor de búsqueda completamente nuevo en 2 meses, partiendo en solitario y sin infraestructura ni experiencia previa

Arquitectura general del sistema

• Se generaron 300 millones de embeddings de texto basados en SBERT en 200 clústeres de GPU
• Cientos de rastreadores concurrentes recopilaron 50,000 páginas por segundo y construyeron un índice total de 280 millones de páginas
• RocksDB y HNSW se almacenaron e indexaron con sharding sobre 200 núcleos, 4 TB de RAM y 82 TB de SSD
• La latencia total de respuesta a consultas se fijó en alrededor de 500 ms
• La estructura y el flujo completos se dividieron en rastreadores, pipeline, almacenamiento, índice de vectores de embeddings, service mesh y áreas de frontend/backend

Experimentos y mejoras en búsqueda basada en embeddings

Neural Embedding Playground

• Los experimentos confirmaron que la búsqueda con modelos de embeddings como SBERT ofrece una comprensión de consultas más natural y mayor precisión que la búsqueda tradicional centrada en palabras clave
• Es posible entender la intención de la consulta de entrada a nivel de contexto y oración, y extraer respuestas realmente relevantes

Ejemplo de búsqueda tradicional vs. búsqueda neuronal

• Búsqueda tradicional: resultados aleatorios, centrados en coincidencia de palabras clave
• Búsqueda por embeddings: entiende el contexto y la intención de la pregunta, y ofrece resultados precisos centrados en oraciones clave o conceptos
• Para combinaciones de conceptos complejos, preguntas implícitas/compuestas y consultas con señales de calidad, permite encontrar respuestas basadas en significado

Parsing y normalización de páginas web

• El objetivo de la normalización es extraer del HTML solo los elementos de texto con significado, eliminando ruido como diseño visual y elementos de control

• Siguiendo estándares como WHATWG y MDN, se preservan estructuras como p, table, pre, blockquote, ul, ol y dl

• Se eliminan por completo elementos de chrome del sitio como menús, navegación, comentarios e interfaces

• Se aplican reglas especiales por sitio (por ejemplo, en.wikipedia.org) para resolver problemas de extracción excesiva o insuficiente

• También es posible aprovechar datos estructurados basados en significado (meta, OpenGraph, schema.org, etc.) para construir un grafo de conocimiento y mejorar el ranking

Chunking y preservación del contexto

Chunking a nivel de oración

• Para superar las limitaciones de los modelos de embeddings, se aplicó chunking por oraciones en lugar de usar la página completa
• Durante el chunking, se distinguen correctamente con spaCy sentencizer diversos casos como límites naturales entre oraciones, gramática, abreviaciones, URL y expresiones informales

Preservación y conexión del contexto

• Se identifican relaciones de dependencia entre oraciones, encabezados, párrafos, tablas, etc., y se generan embeddings junto con esa información contextual
• Por ejemplo, incluso la estructura de tablas se inserta encadenando encabezados o cláusulas superiores para no perder el significado de cada fila

Encadenamiento de enunciados (Statement Chaining)

• Con un clasificador DistilBERT se analiza una oración junto con la anterior para automatizar la verificación de dependencia contextual y la extracción de cadenas
• Al generar embeddings, se incluyen conjuntamente todas las oraciones dependientes superiores para mejorar la conservación del contexto

Resultados del uso del prototipo

• En un entorno sandbox, pruebas con diversas consultas reales confirmaron preguntas y respuestas mucho más precisas y ajustadas al contexto que los métodos existentes
• Incluso con discrepancias de palabras clave, omisiones, metáforas o preguntas compuestas, la aplicación reconoce la intención y empareja correctamente las oraciones contextuales, descubriendo también de forma efectiva conocimiento y relaciones ocultas

Rastreador web a gran escala (basado en nodos)

• Se consideraron diversos factores de estabilidad y eficiencia, como work stealing para distribuir la carga, control de concurrencia y tráfico por dominio, y validación de DNS/URL/headers
• El rastreador aplica Promise con I/O asíncrona, mecanismos resistentes a DDoS, gestión de recursos (memoria, delay, backoff) y detección de dominios ruidosos
• Se reforzó el filtrado de URL duplicadas o anómalas mediante normalización de URL, restricciones sobre protocolo, puerto e información de usuario, y canonicalization

Pipeline (cola de tareas distribuida)

• El estado de cada página se gestionó en PostgreSQL y, al inicio, se usaron directamente polling y transacciones
• En un entorno distribuido a gran escala (miles de rastreadores), surgieron problemas de escalabilidad y cuellos de botella de colas/bloqueos, por lo que se pasó a un coordinador en memoria basado en Rust para gestionar el estado de la cola
• Estructura de tareas: índice basado en hash map, binary heap, grupos por dominio, polling aleatorio, intercambio con swap_remove y otros métodos de indexación
• La memoria por tarea ronda los 100 B, por lo que incluso 1B de tareas pueden manejarse en un servidor de 128 GB
• Después se desarrolló una cola open source basada en RocksDB como reemplazo de SQS, con soporte de 300 mil ops/seg en un solo nodo

Diseño de almacenamiento (Oracle → PostgreSQL → RocksDB)

• Al inicio se usó Oracle Cloud (egress y almacenamiento de bajo costo) y luego PostgreSQL (TOAST), pero se llegó a los límites de escalado de escritura y rendimiento
• Debido a características de PostgreSQL como MVCC, write amplification y WAL, aparecieron cuellos de botella con INSERT paralelos a gran escala, por lo que finalmente se migró a RocksDB como almacén KV
• Con almacenamiento separado de blobs (BlobDB), archivos SST, multihilo e indexación hash de RocksDB, se aprovechó al máximo el rendimiento de los SSD NVMe
• Se escaló a 64 shards de RocksDB; cada shard se enruta con xxHash(key) y usa serialización con Serde + MessagePack
• Finalmente, miles de clientes (rastreadores/parsers/vectorizadores) procesaban 200 mil ops/seg, con metadatos y blobs almacenados de forma separada y comprimida

Service mesh y networking

• Al escalar la infraestructura, se adoptó un diseño basado en mTLS + HTTP2 para descubrimiento automático de instancias de servicio y seguridad en la comunicación
• En cada nodo se aplicaron certificados basados en una CA raíz, se usó serialización directa con MessagePack y se desarrollaron DNS interno, CoreDNS y un SDK cliente personalizado
• Aunque existía experiencia previa con VPN como ZeroTier y Tailscale, por problemas de red, rendimiento y operación se eligió directamente HTTP + mTLS
• La administración se unificó mediante control de servicios del sistema (systemd + cgroup + journald), logrando mayor ligereza y estandarización

Pipeline de generación de embeddings con GPU a gran escala

• Al principio se usó la API de OpenAI, pero por costos se migró a entornos de GPU de alto rendimiento como Runpod
• El pipeline separó de forma asíncrona cada etapa, logró más de 90% de eficiencia de GPU y generó 100 mil embeddings por segundo con 250 GPU
• Pipeline en Rust, inferencia en Python → IPC mediante named pipe, y ajuste automático de recursos con backpressure estructurado

Indexación vectorial (HNSW/sharding)

• Se utilizó el algoritmo HNSW para búsqueda vectorial en memoria, con ANN (Approximate Nearest Neighbor) para latencia ultrabaja
• Al alcanzar el límite de RAM, se aplicó sharding uniforme por nodo (64 nodos), y cada shard se buscó en paralelo con su propio índice HNSW
• Debido a que HNSW requiere gran cantidad de RAM y tiene limitaciones para actualizaciones en vivo, finalmente se migró a CoreNN, una vector DB open source basada en disco
• CoreNN puede consultar con alta precisión hasta 3B embeddings incluso en un solo nodo con 128 GB de RAM

UX del motor de búsqueda y optimización de latencia

• En la UX de un motor de búsqueda, la inmediatez de la respuesta es clave (sin indicador de carga, SSR tradicional)
• Con Cloudflare Argo y otros, se acercó el servicio a los edge PoP y se adoptó HTTP/3 para minimizar la latencia de transporte
• Todos los datos se preparan a nivel de servidor de aplicación, se minimizan los round trips de API individuales y se responde de inmediato con páginas minificadas y comprimidas

---

Este resumen explica de forma concreta cómo un motor de búsqueda web a gran escala que aplica las tecnologías más recientes de procesamiento de lenguaje natural y ML puede construirse end-to-end en solo 2 meses, guiando al lector a través de las principales decisiones de diseño y optimización en sistemas, algoritmos e infraestructura.

[GN⁺]

Comentarios de Hacker News

• Sorprende que el modelo de embeddings más reciente de OpenAI ofrezca un costo bajísimo de $0.0001 por millón de tokens en inferencia por lotes; al hacer cuentas, incluso si se embeben 1,000 millones de páginas con 1,000 tokens cada una, el total sería de apenas $100. Si uno corre la inferencia por su cuenta con GPUs spot de Runpod, sale unas 100 veces más caro. Dejando de lado otros costos de API, me pregunto si esto no será una especie de estrategia de honeypot de OpenAI para asegurarse datos fuente especializados por dominio.

  • Tengo entendido que OpenAI no vuelve a entrenar con la mayoría de los datos procesados vía API; salvo alguna excepción especial, según sé eso no ocurre.

• Al final del artículo menciona que planea agregar datos de Common Crawl. Creo que la información de ranking basada en grafo web de nuestro equipo podría ayudar mucho a decidir qué páginas rastrear. Fue interesante ver un caso real a gran escala, y me sorprendió que la base de datos vectorial fuera más rentable de lo esperado.

• De verdad me genera admiración. El texto además está increíblemente bien organizado. Coincido en que la clave de un buscador está en los datos depurados y filtrados: basura entra, basura sale. También me vuelve a recordar que, incluso en el entrenamiento de LLM, una cantidad pequeña de datos de alta calidad termina siendo más importante. Me da curiosidad qué tan bien funcionaría construir un buscador donde un LLM revise todo el contenido.

  • Ahora mismo estoy gestionando directamente el SEO del sitio web del pequeño negocio de un amigo. Le hice ajustes técnicos y escribí bastante contenido manual adaptado a la zona. Después de dos meses, Bing ni siquiera ha podido sacar el favicon, y Google tardó un mes completo. Aun así, siguen apareciendo arriba sitios nacionales de captura de leads totalmente irrelevantes, spam de blogs de Yelp y páginas de otras empresas sin ninguna relación con la localidad. Claramente parece que algo no está funcionando bien en el sistema de PageRank y de rastreo.

• De verdad inspira respeto. Reunir tantas tecnologías y hacer que funcionen como una sola cosa es impresionante. Creo que el valor decisivo de un motor de búsqueda está en el algoritmo real de ranking. No me queda claro cómo se usa el LLM para el ranking en este proyecto. Entre las técnicas antiguas de ranking estaba la de recopilar datos reales de búsquedas y clics de usuarios; eso es literalmente datos de entrenamiento humanos de búsqueda → enlace clicado. Incluso con apenas unos cuantos clics, el ranking mejora claramente. Si metes esos datos en una red neuronal, puedes convertirlo en un problema de clasificación y mejorar el ranking. Cuanta más gente haga clic, mayor será el peso.

• No hay otra forma de decirlo: es realmente asombroso. En la práctica funciona bastante bien. Si con 10,000 personas suscritas pagando $5 al mes se pudieran cubrir los costos, entonces un buscador financiado por la comunidad no suena tan descabellado.

  • Para quien conozca los LLM encoder-only, es evidente que Google en realidad ya está acabado. Lo único que todavía lo sostiene es que lleva tiempo rastrear toda la web del mundo y mantener el índice siempre actualizado. Si una entidad abierta como Common Crawl o un servicio de pago resolviera el problema del rastreo web en tiempo real, la muralla defensiva de 25 años de Google se vendría abajo y la búsqueda se volvería algo comoditizado.

  • Yendo más allá, estamos viendo en tiempo real cómo se reemplazan una por una todas las funciones de las grandes empresas de IT. Con los modelos, las barreras tecnológicas corporativas ahora también han bajado muchísimo.

• Nunca había imaginado que una sola persona pudiera construir algo así. No parece estar tan lejos de un motor de búsqueda comercial. Tal vez hasta esté a una distancia alcanzable de Google. Que cueste apenas $50,000 al año es absurdamente barato; dan ganas de mandarle capital semilla ahora mismo.

• Es un proyecto realmente genial. Probé aquí también una consulta que no suele salir bien en buscadores famosos (opciones recomendadas de monitores ultrawide de alta resolución), pero sigue ocurriendo que páginas meta especializadas solo en grandes rankings aparecen por encima de páginas con información realmente especializada. Parece haber una obsesión demasiado fuerte con el ranking. Si yo fuera a buscar la respuesta por mi cuenta, elegiría algunos foros de hardware y blogs y compararía con cuidado especificaciones, ventajas y desventajas. Como es difícil verificar si un sitio realmente hizo ese análisis, en casos especiales sería más razonable valorar mejor a los sitios que citan datos concretos. Como usuario, quiero ver las fuentes primarias usadas en el análisis. Pero los buscadores reales no suelen elevar así la evidencia de fuentes desde abajo hacia arriba.

  • Puede que esto ni siquiera sea, en esencia, un problema de búsqueda. No es una consulta donde exista una sola página con la “respuesta correcta”, sino una pregunta que requiere combinar varias fuentes e “inferir”.

• Me parece realmente genial. Pensé en intentar reemplazar todo con esto; quizá termine siendo una pequeña pérdida de tiempo, pero aun así voy a probar varias búsquedas y dejar mis impresiones. En general casi siempre me llevó al lugar correcto, aunque no el 100% de las veces. Por ejemplo, al intentar encontrar fediverse con lemmy, me salió una página de liberapay. Ojalá sí cumpla la promesa de integrar Common Crawl y también tome como referencia otros sitios como archive.org. Se están invirtiendo decenas de miles de millones en la industria de la IA, y de verdad me gustaría que experimentos como este funcionaran bien y tuvieran éxito, aunque fuera con financiamiento comunitario o reparto de trabajo. Sinceramente, mucha gente ya está cansada de la situación casi monopólica de los buscadores actuales. Tengo entendido que Ecosia también está preparando su propio motor de búsqueda, y ojalá colaborara con este proyecto o recibiera ayuda de él. Yo realmente quiero un motor de búsqueda descentralizado. Entiendo que todavía haya dudas en abrir el código por temas de sostenibilidad, pero frustra ver que se desperdicia tantísimo dinero en cosas sin mucho sentido, cuando este proyecto tiene un potencial enorme, así que ojalá lo hicieran open source. Creo que la comunidad al final encontraría formas de hacerlo sostenible, por ejemplo con crowdfunding. Todavía no termino de leer toda la publicación, pero me emocionó tanto que fui a probarlo de inmediato. El artículo en sí es muy profundo y creo que este enfoque puede servirle bastante a otras personas como referencia. Sinceramente, se siente como magia, y hacía mucho que un proyecto no me entusiasmaba de principio a fin de esta manera. Entiendo que abrirlo como open source es complicado y también entiendo el contexto de un país del tercer mundo, pero de verdad estaría dispuesto a donar aunque fueran $50 de mi propio dinero. Yo, que jamás he hecho un pago en línea, igual tengo ganas de apoyarlo así de mucho. Por eso espero que sí aproveche algo como Common Crawl y lo haga junto con la comunidad. De verdad le deseo lo mejor tanto al proyecto como a su carrera.

• Fue de los textos más reveladores que he leído últimamente. Me gustó especialmente que explicara en detalle qué decisiones tomó para bajar costos y en qué puntos realmente logró ahorros. Aunque se enfocó en neural search, me da curiosidad si también probó búsqueda híbrida combinando BM-25 + embeddings. Y también me gustaría saber qué modelos de reranking le resultaron más útiles y eficientes.

• Fue una experiencia muy entretenida de leer. Yo también estoy desarrollando algo parecido para búsqueda de negocios y me topo con muchos desafíos similares. Mucha gente cree que rastrear/procesar/indexar es fácil, pero hacerlo a gran escala y de forma rentable es un problema completamente distinto. Mis aplausos para wilsonzlin; me gustaría conversar sobre el tema. Realmente son muy pocos los que construyen algo así end-to-end por su cuenta.