Un ingeniero de software de Nueva York se cansó tanto de los resultados irrelevantes y el spam de SEO en los motores de búsqueda que decidió crear uno mejor. Dos meses después, tiene un motor de búsqueda de demostración en funcionamiento. Así es como lo hizo, y cuatro ideas importantes sobre lo que siente que son los obstáculos para crear un motor de búsqueda de alta calidad.
Uno de los motivos para crear un nuevo motor de búsqueda fue la percepción de que los motores de búsqueda convencionales contenían una cantidad creciente de spam de SEO. Después de dos meses, el ingeniero de software escribió sobre su creación:
«Lo bueno es la falta comparable de spam de SEO».
Incrustaciones neuronales
El ingeniero de software, Wilson Lin, decidió que el mejor enfoque serían las integridades neuronales. Creó una prueba a pequeña escala para validar el enfoque y señaló que el enfoque de incrustaciones fue exitoso.
Contenido de fragmentación
La siguiente fase fue cómo procesar los datos, como debe dividirse en bloques de párrafos o oraciones? Decidió que el nivel de oración era el nivel más granular que tenía sentido porque permitía identificar la respuesta más relevante dentro de una oración al tiempo que permitía la creación de unidades de incrustación de nivel de párrafo más grandes para el contexto y la coherencia semántica.
Pero todavía tuvo problemas para identificar el contexto con referencias indirectas que usaban palabras como «it» o «el», por lo que dio un paso adicional para poder comprender mejor el contexto:
«Entrené en un modelo de clasificador de Distilbert que tomaría una oración y las oraciones anteriores, y etiqueta de la que depende de uno (si lo hay) para retener el significado. Por lo tanto, al incrustar una declaración, seguiría la» cadena «hacia atrás para asegurar que todos los dependientes también se proporcionaran en contexto.
Esto también tuvo el beneficio de etiquetar oraciones que nunca deberían coincidir, porque no eran oraciones de «hoja» por sí mismos «.
Identificar el contenido principal
Un desafío para el rastreo fue desarrollar una forma de ignorar las partes no contentales de una página web para indexar lo que Google llama al contenido principal (MC). Lo que hizo que esto fuera desafiante fue el hecho de que todos los sitios web usan un marcado diferente para indicar las partes de una página web, y aunque no lo mencionó, no todos los sitios web usan HTML semántico, lo que facilitaría mucho que los rastreadores identifiquen dónde está el contenido principal.
Entonces, básicamente se basó en etiquetas HTML como la etiqueta del párrafo
para identificar qué partes de una página web contenían el contenido y qué partes no.
Esta es la lista de etiquetas HTML en las que se basó para identificar el contenido principal:
- Blockquote – Una cita
- DL: una lista de descripción (una lista de descripciones o definiciones)
- OL – Una lista ordenada (como una lista numerada)
- P – elemento de párrafo
- Texto preformado preformado
- Tabla: el elemento para los datos tabulares
- UL – Una lista desordenada (como puntos de bala)
Problemas con el gateo
El rastreo fue otra parte que vino con una multitud de problemas para resolver. Por ejemplo, descubrió, para su sorpresa, que la resolución de DNS era un punto de fracaso bastante frecuente. El tipo de URL era otro problema, donde tuvo que bloquear cualquier URL para el rastreo que no estaba usando el protocolo HTTPS.
Estos fueron algunos de los desafíos:
“Deben tener https: protocolo, no FTP:, datos:, javascript:, etc.
Deben tener un ETLD y un nombre de host válidos, y no pueden tener puertos, nombres de usuario o contraseñas.
La canonicización se realiza para deduplicar. Todos los componentes están descodificados porcentualmente, luego se vuelven a codificar con un carácter mínimo consistente. Los parámetros de consulta se eliminan o ordenan. Los orígenes están más bajos.
Algunas URL son extremadamente largas, y puede encontrar límites raros como encabezados HTTP y tamaños de página del índice de bases de datos.
Algunas URL también tienen personajes extraños que no pensarías que estarían en una URL, pero que serán rechazadas aguas abajo por sistemas como PostgreSQL y SQS «.
Almacenamiento
Al principio, Wilson eligió Oracle Cloud debido al bajo costo de transferir datos (costos de salida).
Él explicó:
«Inicialmente elegí Oracle Cloud for Infra Needs debido a sus costos de salida muy bajos con 10 TB gratis por mes. A medida que almacenaba terabytes de datos, esto era una buena seguridad de que si alguna vez necesitaba mover o exportar datos (por ejemplo, procesamiento, copias de seguridad), no tendría un agujero en mi billetera. Su compuidad también era más tardío que otras nubes, mientras que aún era un programa mayor reliable». «
Pero la solución Oracle Cloud se encontró con problemas de escala. Así que trasladó el proyecto a PostgreSQL, experimentó un conjunto diferente de problemas técnicos y finalmente aterrizó en Rocksdb, que funcionó bien.
Él explicó:
“Opté por un conjunto fijo de 64 fragmentos de RockSDB, que simplificaban las operaciones y el enrutamiento del cliente, al tiempo que proporcionaban suficiente capacidad de distribución para el futuro previsible.
… En su apogeo, este sistema podría ingerir 200k escrituras por segundo en miles de clientes (rastreadores, analizadores, vectorizadores). Cada página web no solo consistía en HTML de origen sin procesar, sino también datos normalizados, fragmentos contextualizados, cientos de embebidos de alta dimensión y muchos metadatos «.
GPU
Wilson utilizó una inferencia con GPU para generar integridades vectoriales semánticas a partir de contenido web rastreo utilizando modelos de transformadores. Inicialmente utilizó incrustaciones de OpenAI a través de API, pero eso se volvió costoso a medida que el proyecto escalaba. Luego cambió a una solución de inferencia autohospedada utilizando GPU de una compañía llamada RUNPOD.
Él explicó:
«En busca de la solución escalable más rentable, descubrí RunPod, que ofrece GPU de alto rendimiento por dólar como el RTX 4090 a tarifas por horas mucho más baratas que AWS y Lambda. Estas operaban desde DC de Tier 3 con redes rápidas estables y mucha capacidad de calculación confiable».
Falta de spam de SEO
El ingeniero de software afirmó que su motor de búsqueda tenía menos spam de búsqueda y usó el ejemplo de la consulta «mejores blogs de programación» para ilustrar su punto. También señaló que su motor de búsqueda podía entender consultas complejas y dio el ejemplo de ingresar un párrafo completo de contenido y descubrir artículos interesantes sobre los temas en el párrafo.
Cuatro conclusiones
Wilson enumeró muchos descubrimientos, pero aquí hay cuatro que pueden ser de interés para los especialistas en marketing digital y editores interesados en este viaje de crear un motor de búsqueda:
1. El tamaño del índice es importante
Una de las conclusiones más importantes que Wilson aprendió de dos meses de construcción de un motor de búsqueda es que el tamaño del índice de búsqueda es importante porque en sus palabras, «la cobertura define la calidad». Esto es
2. El rastreo y el filtrado son los problemas más difíciles
Aunque el rastreo de la mayor cantidad de contenido posible es importante para surgir contenido útil, Wilson también aprendió que filtrar contenido de baja calidad era difícil porque requería equilibrar la necesidad de cantidad contra la inutilidad de rastrear una red aparentemente interminable de contenido inútil o basura. Descubrió que era necesaria una forma de filtrar el contenido inútil.
Este es en realidad el problema que Sergey Brin y Larry Page resolvieron con el rango de página. Page Rank Modelado Comportamiento del usuario, la elección y los votos de los humanos que validan las páginas web con enlaces. Aunque el rango de página tiene casi 30 años, la intuición subyacente sigue siendo tan relevante hoy que la perplejidad del motor de búsqueda de IA usa una versión modificada para su propio motor de búsqueda.
3. Limitaciones de los motores de búsqueda a pequeña escala
Otra conclusión que descubrió es que hay límites para cuán exitoso puede ser un pequeño motor de búsqueda independiente. Wilson citó la incapacidad de rastrear toda la Web como una restricción que crea brechas de cobertura.
4. Juzgar la confianza y la autenticidad a escala es compleja
Determinar automáticamente la originalidad, la precisión y la calidad de los datos no estructurados no es trivial
Wilson escribe:
«Determinar la autenticidad, la confianza, la originalidad, la precisión y la calidad automáticamente no es trivial … Si comencé de nuevo, pondría más énfasis en investigar y desarrollar este aspecto primero.
Infame, los motores de búsqueda usan miles de señales en las páginas de clasificación y filtrado, pero creo que los enfoques más nuevos basados en transformadores para la evaluación de contenido y el análisis de enlaces deberían ser más simples, rentables y más precisos «.
¿Interesado en probar el motor de búsqueda? Puede encontrarlo aquí y puede leer cómo los detalles técnicos completos de cómo lo hizo aquí.
Imagen destacada de Shutterstock/Red Vector
