Por qué sacamos la búsqueda, el etiquetado y las recomendaciones de la nube

La mayoría de las extensiones de navegador «con IA» envían todo a un servidor, incluidas las partes que no tienen nada que ver con la IA. La búsqueda, la limpieza de etiquetas o «encontrar elementos similares» son técnicas consolidadas con décadas de antigüedad. No necesitan un modelo de lenguaje y definitivamente no necesitan una petición de red de ida y vuelta. Revisamos cada función de AI Summary Helper y nos preguntamos: ¿esto realmente necesita la nube, o simplemente la usamos por defecto porque es la arquitectura más fácil?

La mayoría no la necesitaba.

Qué se trasladó al dispositivo

Búsqueda. Originalmente, la extensión solo buscaba coincidencias en el título y las etiquetas del artículo: rápido, pero ciego a cualquier contenido del cuerpo del texto. En lugar de escanear todo el texto por fuerza bruta con cada pulsación de tecla o enviar cada consulta a un servidor, creamos un pequeño índice TF-IDF a partir del archivo guardado del propio usuario. Los campos livianos (título, etiquetas) se comprueban primero y al instante, igual que antes. Las consultas más largas se amplían contra el índice, que se genera una vez por sesión y se actualiza de forma incremental, sin volver a escanearse en cada pulsación.

Detección de duplicados. Antes de completar un guardado, se ejecuta una comprobación por niveles: primero una coincidencia exacta de URL normalizada (económica, O(1)), luego similitud de título en los pocos candidatos que pasan ese filtro, y solo entonces —para los pocos restantes— una comparación completa de similitud de coseno mediante TF-IDF. La mayoría de los guardados nunca llegan al nivel más costoso, porque los niveles livianos ya los resolvieron.

Normalización de etiquetas. Con el tiempo, las etiquetas se dispersan: «ML», «Machine Learning», «machine-learning» significan lo mismo para un humano, pero nada parecido para un filtro. Una pequeña tabla de alias detecta los casos obvios; una combinación basada en distancia de edición difusa (fuzzy edit-distance) sobre todo el vocabulario de etiquetas se encarga del resto, eligiendo la variante que el usuario utilizó con más frecuencia como forma canónica en lugar de imponerle una «correcta».

Legibilidad y tono. El nivel de legibilidad de Flesch-Kincaid es pura aritmética sobre el conteo de oraciones y sílabas: no requiere ningún modelo. El análisis de sentimiento es una lista de palabras AFINN integrada con una pequeña verificación de negación en los dos tokens precedentes. Ninguno de estos procesos necesitaba salir del navegador.

«Artículos similares» y Resumen. Ambos reutilizan exactamente los mismos vectores TF-IDF que la búsqueda ya generó. Habría sido fácil crear tres sistemas de similitud independientes para tres funciones distintas. Crear un solo índice y permitir que la búsqueda, las recomendaciones y la selección del resumen lean de él mantuvo el sistema más ligero y significó que optimizar el índice una sola vez mejoraba las tres funciones a la vez.

Lo que dejamos deliberadamente en la nube

El paso de resumen propiamente dicho —la parte que realmente requiere un modelo de lenguaje— todavía necesita una llamada de red. No hay forma de evitarlo con el tamaño actual de los modelos en dispositivo si se busca la calidad de salida de un modelo en la nube. Los usuarios pueden usar su propia clave de API para ese paso (OpenAI, Gemini, Mistral, DeepSeek) o apuntar la extensión a una instancia local de Ollama y prescindir también de la red en esa etapa. Ese es el único punto donde la ejecución en local no viene por defecto: es opcional, porque la compensación es real: un modelo local es más lento y ofrece menor calidad que uno alojado, y no queríamos fingir lo contrario.

Por qué esto va más allá de un argumento de privacidad

El aspecto de la privacidad es real: una extensión con permisos amplios de host que envía el contenido de la página a un servidor para tareas que no lo requieren plantea una duda legítima de confianza, no es solo una cuestión de imagen. Pero la razón más pragmática para hacerlo es que, por lo general, es la decisión de ingeniería correcta. La búsqueda TF-IDF no necesita 200 ms de latencia de red. La deduplicación de etiquetas no necesita acarrear una factura de API. Elegir la herramienta adecuada para cada tarea, en lugar de recurrir por defecto a «consultar la nube», suele dar como resultado algo más rápido, más económico de operar y más resiliente sin conexión: la privacidad viene de la mano sin costo adicional, no al revés.