Google ha publicado EmbeddingGemma 2 bajo licencia Apache 2.0, y el comentario más útil sobre el lanzamiento no va de benchmarks: va de qué pasa el día que el modelo desaparece.
Lo que ha pasado
Un modelo de embeddings convierte un texto en una lista de números —un vector— que sirve para comparar textos entre sí: buscar por significado y no por palabra exacta. La novedad es que esta versión sale con licencia Apache 2.0, es decir, con los pesos descargables y uso comercial permitido.
Simon Willison lo comentó en Hacker News y el argumento es el que me interesa: para embeddings en concreto, apostar por un modelo cerrado que solo existe alojado en casa del proveedor no sale a cuenta. La razón es que estos modelos no se usan una vez. Se usan para calcular miles o millones de vectores y guardarlos para compararlos después. Cuando el proveedor retira ese modelo —y lo retira, porque tendrá uno mejor—, tú no pierdes una llamada: pierdes el índice entero y te toca recalcularlo y pagarlo.
Hay un precedente que cita él mismo: en abril de 2024, OpenAI dijo que asumiría el coste de volver a generar los embeddings con los modelos nuevos. Un detalle bonito, y exactamente el tipo de cosa que no puedes dar por hecha con el siguiente proveedor.
Y un matiz suyo que casi todo el mundo se salta al resumirlo:
No es que quiera alojar el modelo yo.
Prefiere pagar a alguien que lo sirva, sabiendo que si ese alguien cierra la persiana puede ejecutar los pesos abiertos él o buscar otro que lo haga. Los pesos abiertos como póliza, no como arquitectura.
Por qué importa si construyes algo
La diferencia entre un modelo de chat y un modelo de embeddings no es técnica, es contable. La respuesta de un chat es efímera: la usas y la tiras, y cambiar de proveedor es cambiar una cadena de texto en la configuración. El embedding es estado persistido. Vive en tu base de datos, y cambiar de modelo significa reconstruir ese estado entero.
De ahí salen cuatro cosas que yo haría hoy mismo, da igual qué modelo uses:
- Guarda el texto original y el troceado, no solo el vector. El error caro no es quedarte sin modelo: es tener un millón de vectores y no conservar los fragmentos de texto que los generaron, ni el código que los troceó así. Si no puedes reproducir el troceo, no puedes migrar aunque te regalen el modelo nuevo.
- Versiona el vector como versionas el esquema. Nombre del modelo, versión, dimensión, si lo normalizas y con qué plantilla lo generaste. Muchos modelos de embeddings usan prefijos distintos para la consulta y para el documento; si los mezclas, la calidad cae y nadie sabe por qué.
- No mezcles vectores de dos modelos en el mismo índice. La distancia entre un vector del modelo viejo y uno del nuevo no significa nada. Migración con índice paralelo y escritura doble, y el cambio de uno a otro cuando el nuevo gane.
- Ten un conjunto de consultas reales con el resultado que esperas. Sin eso no sabes si has migrado bien o si has empeorado la búsqueda sin enterarte, que es lo que pasa casi siempre.
El coste de recalcular no es la factura de GPU. Es la ventana de reindexado, la regresión de relevancia y todo lo que cuelga por debajo: cachés, resúmenes, lo que sea que hayas construido encima de esos vectores.
Lo que no cambia
Apache 2.0 no te libra de migrar. Cuando salga la versión siguiente y sea mejor, vas a querer la mejor, y tocará recalcular igual. Lo que te quita la licencia abierta no es la migración: es que te la impongan con fecha ajena.
Pesos abiertos tampoco significa reproducibilidad exacta. Cambia el runtime, la cuantización o la versión del tokenizador y los vectores pueden moverse un poco. Para un índice ya construido eso a veces da igual y a veces no —hay que medirlo con tus propias consultas, no suponerlo.
Y alguien tiene que guardar esos pesos. Si tu plan es descargarlos de un repositorio público dentro de cuatro años, tu plan es que ese repositorio siga ahí. Descárgalos ahora y mételos en tus copias, que pesan menos que el índice.
Última honestidad: tampoco es un drama universal. Recalcular un corpus mediano con un modelo pequeño es hoy cuestión de horas y de poco dinero. Esto duele a escala, o cuando no conservaste los textos.
Nuestra lectura
Estoy de acuerdo con Simon en el fondo y le cambio el acento. La licencia no es tu seguro: tu seguro es que puedas regenerar el índice desde los documentos originales un martes cualquiera, con el modelo que sea. Apache 2.0 es la segunda línea de defensa, y es una buena segunda línea, pero he visto más proyectos atascados por un troceado que nadie documentó que por un modelo retirado.
La regla que aplico es sencilla: si lo persistes, exige poder volver a generarlo; si es efímero, el que quieras. Para el chat, uso el modelo que mejor vaya este mes y me da igual que sea cerrado. Para lo que se queda en la base de datos, quiero una vía de escape que no dependa de la hoja de ruta comercial de nadie.
Creo que parte de este debate va a envejecer raro. Los modelos de embeddings son pequeños y cada vez más baratos de ejecutar; dentro de dos años recalcular un índice entero será una tarea programada de fin de semana y el enganche se habrá mudado a otro sitio —a la base de datos vectorial, al grafo, a lo que hayas construido encima. Lo que no va a envejecer es la obligación de conservar la fuente. Eso ha sido verdad con cada migración de buscador de los últimos veinte años y lo seguirá siendo.
Cuando nos piden montar búsqueda semántica sobre documentación interna, la primera pregunta nunca es qué modelo: es dónde están los textos y si se pueden volver a trocear exactamente igual. En la mitad de los casos, ahí se acaba la conversación sobre modelos y empieza la de verdad.
Cualquier duda me dices y lo vemos. Un saludo, Vicente.