Google DeepMind liberó EmbeddingGemma 2, un modelo de embeddings multimodal abierto, con licencia Apache 2.0, que mapea texto (incluido código), imágenes, video y audio en un único espacio de 768 dimensiones. Tiene 740 millones de parámetros y fue diseñado para correr en hardware de consumo, como teléfonos y laptops. EmbeddingGemma 2
Para quien no vive en el detalle técnico, los embeddings son la pieza invisible detrás de la búsqueda semántica, la generación aumentada por recuperación (RAG), la clasificación y el agrupamiento de contenido: convierten lenguaje y otros formatos en coordenadas numéricas donde lo parecido queda cerca. Hasta hace poco, producir esas representaciones exigía modelos de miles de millones de parámetros y, en muchos casos, APIs propietarias por las que se paga por volumen.
El nuevo modelo cambia esa ecuación: combina un núcleo de texto de 270 millones de parámetros con dos encoders opcionales, uno de visión de 170 millones y otro de audio de 300 millones, que se cargan solo si el caso de uso los necesita. ficha técnica en Hugging Face
De un modelo de texto a un espacio compartido
La apuesta no es nueva. La primera generación, documentada en arXiv, era solo texto: 308 millones de parámetros montados sobre la arquitectura Gemma 3, que aprendieron destilando el conocimiento del sistema Gemini Embedding de Google, con un regularizador para dispersar las representaciones y una fusión de puntos de control entrenados con distintas mezclas de datos. El resultado lideró los tableros del benchmark MTEB entre los modelos de menos de 500 millones de parámetros y rindió a nivel de sistemas del doble de tamaño.
Esta segunda generación aplica la misma lógica a cuatro modalidades. El modelo entiende más de 100 idiomas, admite contextos de hasta 8.192 tokens —suficientes para minutos de audio o video— y en tareas de código supera a su predecesor en alrededor de 14 %: 78,68 contra 68,76 en el MTEB de código. Hugging Face
El detalle con más impacto operativo está en el recorte de dimensiones. Gracias al aprendizaje de representaciones matrioska (MRL), los vectores completos de 768 dimensiones pueden truncarse a 512, 256 o 128 y renormalizarse. En texto, la calidad aguanta: en el MTEB multilingüe, bajar de 768 a 256 dimensiones cuesta 0,95 puntos (61,36 a 60,41) y divide el almacenamiento vectorial por tres; a 128 dimensiones la caída llega a 57,89, pero el ahorro es de seis veces. En multimodal, el recorte agresivo sale caro: el promedio del benchmark MMEB pasa de 59,01 a 45,65. ficha técnica en Hugging Face
Lo que dice una evaluación independiente
Fuera de los reportes del propio Google, un equipo de la Universidad Politécnica de Milán, la Johannes Kepler University de Linz y la Universidad de Música de Núremberg comparó doce codificadores de texto recientes —entre ellos EmbeddingGemma— sin ajuste previo, para medir cuánta información emocional contienen sus vectores. El estudio, publicado en arXiv, usó tres marcos psicológicos (el modelo PAD de Mehrabian, la rueda de Plutchik y las emociones de Ekman) y tres conjuntos de datos: el léxico NRC-VAD con unas 55.000 palabras, el NRC-EIL con casi 6.000 términos y GoEmotions con más de 54.000 comentarios.
El hallazgo: a nivel de palabra, los modelos abiertos sensibles a instrucciones igualan o superan a los propietarios en la información afectiva que capturan; a nivel de oración, los propietarios y los modelos ajustados a tareas recuperan la ventaja. Para una empresa, la lectura es sencilla: si la necesidad es clasificar menciones cortas, mensajes de clientes o atributos de producto, un modelo abierto con el prefijo de instrucción adecuado está a la altura. Si la tarea exige matices emocionales en párrafos largos, todavía conviene comparar con servicios de pago.
Lo que cambia para una empresa latinoamericana
Para la región, el valor está tanto en el rendimiento como en las condiciones de uso. Licencia abierta, sin costo por token y pesos que se descargan y se quedan en infraestructura propia o en el dispositivo resuelven dos dolores habituales: la factura en dólares por consumo de API y la necesidad de controlar dónde viajan los datos de clientes, un punto que pesa cada vez más en las decisiones de compra de tecnología. El soporte declarado de más de 100 idiomas elimina además el primer filtro con el que se descartan herramientas en español y portugués: el filtro correcto es una prueba con datos propios.
Esta advertencia técnica es concreta: medir antes de truncar. Para una base de conocimiento solo de texto, 256 dimensiones probablemente bastan; para una plataforma que busca por imágenes o procesa audio, quedarse en 768 evita que el ahorro en almacenamiento se pague en precisión. Y como muestra la evaluación afectiva, el mejor modelo depende de la tarea: código abierto alcanza para búsqueda y clasificación básica, pero no todas las cargas de trabajo son iguales.
Con cada generación, Google comprime más capacidad en menos parámetros y la frontera entre lo que corre en la nube y lo que corre en el bolsillo se estrecha. La decisión para un ejecutivo latinoamericano ya no es si adoptar este tipo de modelo, sino con qué dimensiones, en qué dispositivo y bajo qué control de datos desplegarlo.
