La carrera de Bob van Luijt en tecnología comenzó a los 15 años, creando sitios web para ayudar a las personas a vender cepillos de dientes en línea. No muchos jóvenes de 15 años hacen eso. Aparentemente, esto le dio a Van Luijt suficiente ventaja para llegar a la confluencia de las tendencias tecnológicas actuales.
Van Luijt pasó a estudiar artes, pero terminó trabajando a tiempo completo en tecnología de todos modos. En 2015, cuando Google presentó su algoritmo RankBrain, la calidad de los resultados de búsqueda aumentó. Fue un momento decisivo, ya que introdujo el aprendizaje automático en la búsqueda. Algunas personas se dieron cuenta, incluido Van Luijt, que vio una oportunidad de negocio y decidió llevarla a las masas.
ZDNet conectado con van Luijt para obtener más información.
Weaviate, un motor de búsqueda B2B inspirado en Google
¿Mejora el aprendizaje automático RankBrain de Google los resultados de búsqueda para los usuarios? La gente se preguntaba cuándo se presentó RankBrain. Como ZDNet’s La propia Eileen Brown señaló: Sí, y los resultados entregados por RankBrain mejorarán a medida que aprenda lo que estamos tratando de pedirle.
Para van Luijt, este fue un momento «Ajá». Como todos los demás que trabajan en tecnología, tuvo que lidiar con muchos datos no estructurados. En sus palabras, relacionar datos es un problema. La integración de datos es difícil de hacer, incluso para datos estructurados. Cuando tiene datos no estructurados de diferentes fuentes, se vuelve extremadamente desafiante.
Van Luijt leyó sobre RankBrain y pensó que usa la vectorización de palabras para inferir relaciones en las consultas y luego tratar de presentar resultados. Los vectores son la forma en que los modelos de aprendizaje automático entienden el mundo. Donde las personas ven imágenes, por ejemplo, los modelos de aprendizaje automático ven representaciones de imágenes, en forma de vectores.
La introducción del algoritmo RankBrain de Google fue un momento decisivo para la búsqueda, ya que introdujo el aprendizaje automático en la búsqueda. Imagen: Search Engine Journal
Un vector es una lista muy larga de números, que se pueden considerar como coordenadas en un espacio geométrico. Los vectores tridimensionales, es decir, los vectores de la forma (X, Y, Z), corresponden a un espacio con el que los humanos están familiarizados. Pero también existen vectores multidimensionales, y esto complica las cosas:
«Hay muchas dimensiones, pero para pintar una imagen mental, puedes decir que solo hay tres dimensiones. El problema ahora es que es genial que puedas usar un vector para reconocer un patrón en una foto y luego decir, sí, es un gato , o no, no es un gato. Pero entonces, ¿qué pasa si quieres hacer eso por cien mil fotos o por un millón de fotos? Entonces necesitas una solución diferente, necesitas tener una forma de mirar en el espacio y encontrar cosas similares.»
Esto es lo que hizo Google con RankBrain para el texto. Van Luijt estaba intrigado. Comenzó a experimentar con modelos de procesamiento del lenguaje natural (PNL). Incluso llegó a preguntarle directamente a la gente de Google: ¿iban a crear una solución de motor de búsqueda B2B? Dado que su respuesta fue «no», se propuso hacer eso con Weaviate.
Buscando el espacio del documento con vectores
Vectores de salida de modelos de aprendizaje automático de PNL: colocan palabras individuales en un espacio vectorial. La idea detrás de Weaviate era: ¿Qué pasa si tomamos un documento, un correo electrónico, un producto, una publicación, lo que sea? Observamos todas las palabras individuales que lo describen y calculamos un vector para esas palabras.
Aquí será donde el documento se ubicará en el espacio vectorial. Y luego, si preguntas, por ejemplo: ¿Qué publicaciones están más relacionadas con la moda? El motor de búsqueda debería buscar en el espacio vectorial y encontrar publicaciones como Vogue, como algo cercano a la «moda» en este espacio.
Este es el núcleo de lo que hace Weaviate. Además, los datos en Weaviate se almacenan en formato gráfico. Cuando se ubican los nodos en el gráfico, los usuarios pueden recorrer más y encontrar otros nodos en el gráfico.
Weaviate utiliza vectores para buscar documentos en espacios que comprenden muchas dimensiones. (Imagen: Weaviate)
No es que no sea posible almacenar vectores en bases de datos tradicionales. Lo es, y la gente lo hace. Pero después de cierto punto, se vuelve impráctico. Además del rendimiento, la complejidad también es una barrera. Por ejemplo, van Luijt mencionó que, en la mayoría de los casos, las personas no están al tanto de los detalles de cómo ocurre la vectorización.
Weaviate viene con varios vectorizadores integrados. Algunos son de uso general, otros se adaptan a dominios específicos como la ciberseguridad o la atención médica. Una estructura modular permite a las personas agregar sus propios vectorizadores también.
Weaviate también funciona con marcos populares de aprendizaje automático como PyTorch o TensorFlow. Sin embargo, hay un inconveniente: en este momento, si entrena su modelo o usa uno provisto por Weaviate, se quedará con él.
Si un modelo cambia de una manera que influye en la forma en que genera vectores, Weaviate tendría que volver a indexar sus datos para que funcione. Actualmente, esto no es compatible. Van Luijt mencionó que no era necesario en sus casos de uso actuales, pero están buscando formas de respaldarlo.
Como startup, SeMI Technologies, la empresa que fundó van Luijt alrededor de Weaviate, está navegando por el mercado de la tracción. Actualmente, la industria minorista y de bienes de consumo les está funcionando bien, y Metro AG es un caso de uso destacado.
El desafío que tenía Metro era cómo encontrar nuevas oportunidades en el mercado. Weaviate les ayudó a hacer eso al combinar datos de su CRM y Open Street Maps. Si una ubicación donde existe una empresa no se puede asociar con un cliente en el CRM, eso indica una oportunidad.
GraphQL es una buena API UX
En todas las industrias, señaló van Luijt, el problema es siempre el mismo en el nivel raíz: los datos no estructurados deben estar relacionados con algo estructurado internamente. Los gráficos son bien conocidos por ayudar a aprovechar las conexiones. Pero resulta que incluso la incapacidad de encontrar conexiones puede generar valor comercial, como ejemplifica el caso de uso de Metro.
Van Luijt cree firmemente en el valor de los gráficos para aprovechar las conexiones, o la falta de ellas. La acumulación de datos en almacenes de datos y lagos de datos y almacenes de lagos y todo eso tiene valor. Pero, para obtener valor de las conexiones en los datos, es el modelo gráfico el que tiene más sentido, anotó.
Entonces, la pregunta es: ¿Cómo vamos a lograr que la gente acceda a esto? Para dar a las personas muchas capacidades para que puedan hacer «una gran cantidad de cosas», un lenguaje de consulta de gráficos como SPARQL puede tener sentido, dijo van Luijt.
El ascenso meteórico de GraphQL entre los desarrolladores ha atraído el interés en usarlo también como una capa de acceso para bases de datos. Imagen: Apollo
Pero si desea simplificar el acceso de las personas a los gráficos para que tengan una curva de aprendizaje muy corta, GraphQL se vuelve interesante, agregó: «La mayoría de los desarrolladores que no están familiarizados con la tecnología de gráficos, si ven SPARQL, comienzan a sudar y se ponen nerviosos. Si ven GraphQL, dicen: ‘Oye, entiendo esto. Esto tiene sentido’ «.
GraphQL tiene otra ventaja: la comunidad que lo rodea. Hay muchas bibliotecas disponibles y, debido a que Weaviate usa GraphQL, estas bibliotecas también se pueden usar. Van Luijt describió la decisión de usar GraphQL como una decisión de experiencia de usuario (UX): la UX para acceder a una API debería ser fluida.
Weaviate también apoya la noción de esquemas. Cuando una instancia comienza a ejecutarse, el punto final de la API está disponible y lo primero que deben hacer los usuarios es crear un esquema de propiedad de clase. Puede ser tan simple o tan complejo como sea necesario, y los esquemas existentes también se pueden importar.
Un enfoque pragmático
Van Luijt tiene puntos de vista muy pragmáticos en lo que respecta a las limitaciones de los vectores, así como al uso de código abierto. Para citar a Gary Marcus y Ray Mooney antes que él, «No se puede meter el significado de una oración $ &! # * Completa en un solo vector $! # & *».
Eso es cierto, pero ¿importa si puede obtener resultados prácticos al usar vectores? No mucho, argumenta van Luijt. El problema que Weaviate está tratando de resolver es encontrar cosas. Entonces, si la búsqueda de similitudes hace un buen trabajo para encontrar cosas usando vectores, eso es lo suficientemente bueno. La idea, añadió, es convertir la búsqueda basada en vectorización de un problema de ciencia de datos en un problema de ingeniería.
Se adopta el mismo enfoque pragmático cuando se trata de código abierto. Hay muchas razones por las que las personas optan por el código abierto. Para Weaviate, se eligió el código abierto, o más bien el núcleo abierto, como un mecanismo de transparencia hacia los clientes y usuarios.
Quizás sorprendentemente, van Luijt señaló que Weaviate no necesariamente busca colaboradores. Sería bueno tenerlo, pero el propósito principal del código abierto es permitir auditorías. Cuando los clientes piden a sus expertos que auditen Weaviate, ser de código abierto lo permite.
Weaviate está disponible tanto como software como servicio como local. Contrariamente a la sabiduría convencional, parece que la mayoría de los usuarios de Weaviate están interesados en implementaciones locales.
En la práctica, sin embargo, esto a menudo significa su propio proyecto en uno de los principales proveedores de nube, con servicios del equipo de Weaviate. A medida que el equipo y el producto se amplían, puede ser necesario un cambio hacia el modelo de autoservicio.
Divulgación: SeMI Technologies ha trabajado con el autor como cliente.