El equipo de built-in AI de Chrome ha propuesto en la Semantic Embedder API exponer su generador de embeddings del navegador como API web, y he querido experimentar con esa idea antes de que exista en producción. O lo que es lo mismo, generar embeddings en local, dentro del navegador, sin servidor, ni API keys y sin coste por uso. Se me han ocurrido mil aplicaciones, pero esta es sólo una de ellas.
Con los embeddings funcionando dentro del navegador he pensado en cruzarlos con el chunker con el que Chrome trocea las páginas en pasajes para su búsqueda de historial y con el query fan-out (podéis leer más sobre esto en la evolución del query augmentation). De ese cruce sale el pipeline de un sistema de retrieval corriendo dentro de Chrome: trocear, embeber y rankear pasajes contra una query y sus variantes.
El resultado del experimento es una extensión de Chrome que he llamado Passage Lens y es un side panel que te enseña qué pasajes de la página se recuperarían para cada query, qué variantes de intención cubre tu contenido, y cuáles se quedan huérfanas (tus content gaps). Además pinta un heatmap sobre la propia página con el percentil de relevancia de cada pasaje.
Abres una página, escribes una query y la extensión ejecuta este pipeline:
Para el fan-out hay dos modos. El recomendado es pegar tus propias variantes, las que hayas sacado tú mismo de la API de Gemini, de ChatGPT, de los datos de grounding de Bing o de donde quieras. El segundo, Gemini Nano, lo metí por jugar, por el gusto de meter un LLM en local y simular un proceso de fan-out naif. Gemini Nano es el modelo que Chrome trae dentro, y he hecho que genere variantes usando la taxonomía de la patente de Google US20230281193A1: equivalente, generalización, especificación, follow-up, implicación y clarificación, una por tipo. Podría haber hecho algo más pro, pero quería que todo lo hiciera el navegador sin coste. Esto tiene muchas limitaciones, porque la patente describe un modelo de control que decide dinámicamente cuántas variantes emitir, de qué tipos, cuándo parar, entrenado con su data... y eso no lo estoy reproduciendo. Genero una por tipo para tener una muestra random completa y automática, nada más.
Si una variante de fan-out no tiene ningún pasaje que la responda bien, la extensión te la marca en rojo como content gap. Y ojo, que el retrieval funcione por pasajes no significa que tengas que trocear tu contenido como explico aquí. Los chips de query son clicables, y al hacer clic en una variante, el ranking de pasajes y el heatmap se filtran para esa query concreta, y otro clic devuelve la vista global.
Esta es la parte que me parece más nerd del experimento, y la respuesta corta es que tu navegador lleva más de 2 años siendo un sistema de retrieval.
En octubre de 2023 aterrizó en Blink el módulo content_extraction, una interfaz para capturar el inner-text de las páginas de cara a las features on-device que venían. La extracción de contenido es un mundo en sí mismo y que me tiene obsesionado desde que existen los chatbot LLM. El 6 de febrero de 2024 se creó el componente history_embeddings y tres semanas después, el 23 de febrero, el mismo ingeniero añadió el DocumentChunker sobre ese módulo. El CL describe el algoritmo tal cual lo he portado a JS: agregación de nodos de texto en pasajes, subiendo desde las hojas del árbol, intentando no pasarse de un límite de palabras. Es decir, el chunker se escribió básicamente para los History Embeddings.
Lo que hace la feature de Chrome es trocear las páginas que visitas en pasajes, las embebe con un modelo local y guarda los vectores en una base en tu perfil (en el componente conviven un sql_database.cc y un vector_database.cc). Con eso puedes buscar el historial por significado en vez de por coincidencia de palabras. Google lo lanzó el 1 de agosto de 2024 como búsqueda de historial con IA, opt-in y empezando por USA. O sea, que cuando publico esto Chrome lleva 2 años generando y almacenando embeddings de la navegación de sus usuarios, en local y con la mayoría del sector sin enterarse (yo me enteré el año pasado gracias a Dan Petrovic) y ojo, parece que hay algo más. Esta fue mi respuesta aquello y veo que iba bien encaminado 🙂
En diciembre de 2024 el embedder de pasajes se sacó a componente propio, passage_embeddings, que es lo que haces cuando más features van a consumirlo.
¿Y de dónde sale el modelo que genera esos embeddings? Porque en el código de Chromium no está, lo que hay ahí es tan solo la maquinaria para recibirlo y ejecutarlo. El modelo se lo baja Chrome a cada perfil desde los servidores de Google, por la infraestructura de model delivery de Optimization Guide, y son dos ficheros: un modelo de embeddings en formato TFLite y un tokenizer SentencePiece, con su metadata de ventana de entrada, dimensión del vector y umbral de similitud. Tampoco corre en el proceso del navegador, sino en un servicio sandboxed aparte que carga el modelo con TFLite y expone un GenerateEmbeddings() con tres niveles de prioridad (user-initiated, urgent y passive), que es lo que le permite ir embebiendo tu navegación en segundo plano sin que te enteres. O sea, que es un modelo propietario que no viene en el binario, que Google te instala en el perfil y que ninguna web puede tocar. Quedaos con este detalle, que explica lo de Brave de más abajo.
Lo segundo es la apuesta de built-in AI. Chrome distribuye Gemini Nano dentro del navegador y expone APIs de tarea para webs y extensiones como Prompt API, Summarizer, Translator, Writer. El argumento de Google para meter modelos en el cliente es simplemente por privacidad (el contenido no sale de la máquina), latencia (sin round-trips de red) y coste (la inferencia la paga el dispositivo del usuario, no el servidor). Y añado que si cada web tuviera que descargarse su propio modelo de 200MB, la web entera se volvería inusable. Un modelo compartido a nivel de navegador amortiza esa descarga entre todos los sitios.
Y lo tercero es la propuesta de exponer ese embedder on-device como API web estándar. Es un borrador temprano y no está aprobado para shipear, pero la dirección es que cualquier web pueda generar embeddings en local sin traerse su modelo. El día que eso llegue, Passage Lens tirará el motor vendorizado y usará el nativo. Mientras tanto, la extensión carga sus propios Transformers.js y runtime de ONNX, que es exactamente el problema que la API quiere resolver.
Además acabo de ver en el código actual de passage_embeddings, al lado del executor de History Embeddings de siempre, hay un GemmaModelExecutor con su flag execute_for_gemma y con métricas que se llaman AI.SemanticEmbedder.LaunchDuration y AI.SemanticEmbedder.TaskDuration. Es decir, que la API nativa va a reutilizar el mismo servicio de embeddings del historial cambiando el modelo por uno de la familia Gemma, con toda la pinta de ser EmbeddingGemma. Si esta propo se confirma, el modelo que he vendorizado en Passage Lens será el mismo que Chrome acabará sirviendo de serie. El objetivo estratégico de Google aquí es convertir Chrome en la plataforma de IA por defecto. Si el navegador trae el modelo, el runtime y las APIs, el navegador es la capa donde se construyen las herramientas, y quien controla esa capa decide qué modelo se usa. A Google le sale además gratis en inferencia, que a su escala no es un detalle menor...
Me preocupaba porque Brave es Chromium, y es el navegador que llevo años usando... así que he estado investigando y he visto que no. Lo comprobé lanzando un Brave con perfil limpio y consultando si las APIs de LanguageModel, Summarizer y Translator están en window y no aparecen.
Por lo que estas features no son de Chromium, son de Google Chrome. Los modelos no vienen compilados en el binario y Brave elimina o proxytea sistemáticamente todo lo que habla con servidores de Google. Su apuesta de IA va por otro lado con Leo, un asistente con modelos en la nube detrás de un proxy que anonimiza las peticiones. Filosofías opuestas. Google mueve el modelo al dispositivo y lo integra en la plataforma web y Brave mantiene el modelo fuera y protege la petición.
El código está en github.com/natzir/passage-lens. Es cargar la carpeta como extensión unpacked en chrome://extensions (con el modo desarrollador activado), abrir cualquier página y darle a Analyze. El primer análisis descarga los pesos de EmbeddingGemma (~200MB, una vez; después quedan cacheados) y el acceso a cada sitio se concede por origen la primera vez que lo analizas.
Passage Lens es un tan solo un ejercicio para jugar con el navegador y sus piezas de infraestructura de retrieval (chunker, embedder, LLM pequeño) y cómo una extensión puede combinarlas para montar herramientas SEO que antes exigían backend, API keys y coste por uso.
Piensa en lo que se puede construir con este stack sin que un solo byte de contenido salga de tu máquina 🙂
La Inteligencia Artificial ha dejado de ser una promesa futurista para convertirse en una fuerza transformadora en el presente y, el SEO, tenía que subirse también a la ola. Problema: nadar por el estado actual de herramientas, workflows y agentes de IA para SEO puede ser complicado, y el hype existente nubla la realidad práctica. […]
Leer másCuando un buscador necesita encontrar información, puede intentar entenderte de dos maneras, o interpretando el significado abstracto de lo que pides o buscando las palabras exactas que has utilizado. Ambos enfoques son potentes pero incompletos por sí solos. En este artículo veremos qué es la búsqueda híbrida y las técnicas que los buscadores como Google […]
Leer más