Entrenar tu propio modelo de embeddings: guía de ajuste de Embedding Gemma 2

Un modelo de embeddings listo para usar conoce bien los datos generales, pero no tiene idea de tus documentos, tus nombres de producto ni los sonidos que importan a tu aplicación. Embedding Gemma 2 destaca justo en ese hueco: abierto por Google bajo licencia Apache 2.0, reúne texto, imágenes, audio y vídeo en un único espacio compartido de 768 dimensiones . Según la ficha publicada en HuggingFace, el sistema suma 740 millones de parámetros en total, con una variante ligera de texto de 270 millones cuando basta con ella. El presentador empieza con una demostración en directo: una versión ajustada con pares de pregunta y pasaje creados desde las grabaciones de su propio canal responde a una pregunta devolviendo el momento exacto, con una marca de tiempo en la que se puede hacer clic. La pregunta del vídeo es nítida: ¿pueden unos minutos de ajuste hacer al modelo claramente mejor con tus propios datos sin romper lo que ya sabe hacer?

El ajuste significa algo distinto en un modelo de embeddings que en un gran modelo de lenguaje. Con un modelo de lenguaje muestras la entrada y el texto exacto a reproducir, así que los datos de entrenamiento ya contienen la respuesta correcta palabra por palabra. Un modelo de embeddings no escribe nada: convierte una entrada en una lista de números que solo tienen sentido en relación mutua. Esa red de relaciones se llama espacio de embeddings , y no existe una lista correcta única para anotar como objetivo. Lo único que puedes decirle al modelo es qué elementos deben terminar cerca entre sí. La documentación de Google para desarrolladores enmarca el ajuste exactamente así: cerrar la brecha entre comprensión general y precisión propia del dominio. Entender esta diferencia importa, porque la forma de los datos de entrenamiento nace de ella.

Pares y negativos dentro del lote

Los datos de entrenamiento se componen de pares de pregunta y pasaje respuesta. El presentador lo explica con un servicio de asistencia para el hogar conectado: cada ejemplo asocia una pregunta de cliente con el pasaje del centro de ayuda que la responde. Sin puntuaciones ni respuestas erróneas etiquetadas; solo se recogen preguntas con los pasajes que les pertenecen. Esa sencillez es el atractivo, porque la preparación de datos nunca se convierte en un proyecto de etiquetado de semanas. Tus documentos existentes y las preguntas reales de los usuarios suelen bastar. Lo esencial es que los pares estén limpios y que cada pregunta quede realmente respondida por su pasaje.

Acercar cada pregunta a su pasaje no basta por sí solo, porque el modelo podría apilar todas las entradas en el mismo punto y aun así puntuar bien. La solución es entrenar por lotes: en un lote de 32 pares, cada pregunta toma su propio pasaje como respuesta correcta y todos los demás pasajes del lote como incorrectos. Cada paso produce así abundantes contraejemplos gratis, sin etiquetar ni uno. El presentador lo compara con un examen de opción múltiple donde los demás pares del lote sirven como opciones falsas ya preparadas. En la documentación de SBERT este enfoque se llama Multiple Negatives Ranking , y es la misma idea que OpenAI usó en CLIP para reunir imágenes y textos en un solo espacio. Extraer los negativos de la estructura del lote en vez de recogerlos a mano es lo que vuelve tan práctico al método.

El truco tiene un precio: si el mismo texto de respuesta aparece dos veces en un lote, la función de pérdida enseña al modelo que la respuesta correcta es errónea. Dos clientes preguntando por el mismo procedimiento de restablecimiento, cayendo en el mismo lote, alejan la primera pregunta de su pasaje correcto. La corrección pasa por un muestreador que nunca coloca dos veces el mismo texto en un lote, conocido en el ecosistema SBERT como muestreador sin duplicados . Parece un detalle menor, pero con datos repetitivos tuerce en silencio todo el entrenamiento. El presentador insiste a propósito: es un defecto de organización de los datos, no de etiquetado, y ninguna curva de pérdida lo revela.

Formato de prompt, LoRA y medición

El segundo punto a resolver es la disciplina de prompt. Embedding Gemma 2 espera una breve instrucción de tarea delante de la consulta de búsqueda y un formato de título más texto para los documentos: el formato usado en el entrenamiento es por tanto el que deberá usar el código de búsqueda. El presentador lo compara con la disciplina de plantillas de prompt para modelos de lenguaje: las plantillas de entrenamiento y de producción deben coincidir exactamente. Cambiar el formato después invalida en la nueva presentación las relaciones de cercanía aprendidas con esfuerzo. Por eso conviene fijar la plantilla de producción antes siquiera de preparar los datos.

La parte más interesante es qué se entrena realmente. En vez de actualizar todos los pesos, los ensayos usan LoRA : pequeñas matrices entrenables junto a las capas congeladas, sin tocar los pesos originales. En los ensayos presentados eso era menos del 2 % de los pesos, así que basta un pequeño archivo adaptador en lugar de una copia completa del modelo. La guía de GoogleBlog para desarrolladores destaca el mismo diseño modular, con codificadores de texto, visión y audio cargables según necesidad. El anuncio del blog de Google apunta en la misma dirección: un modelo de baja latencia que corre en equipos de consumo. El tronco común conlleva sin embargo un riesgo: texto, imágenes, vídeo y audio pasan por la misma columna, así que entrenar con audio también modifica la parte que procesa fotos y texto. Ese precio debe medirse por separado.

El último principio trata de la medición. Que baje la pérdida de entrenamiento solo muestra que el modelo mejoró en los ejemplos vistos; la verdadera pregunta es la calidad de búsqueda en preguntas jamás vistas, pues de lo contrario el resultado es memorización y no capacidad. Se reserva por tanto un conjunto de prueba, dividido por fuente: si pasajes del mismo artículo figuran a la vez en entrenamiento y prueba, el modelo ya ha visto la respuesta. La división correcta es por artículo, por vídeo o por grabación. Ese montaje responde además a una segunda pregunta: ¿adquirió el modelo una escucha o comprensión general, o solo las etiquetas entregadas? El presentador construye sus dos experimentos alrededor de esa pregunta.

Dos pequeños estudios y tres reglas

El primer estudio apunta al punto débil del vídeo anterior: los sonidos cotidianos. La colección ESC50 reúne clips breves de 50 sonidos comunes como ladridos, lluvia o motosierra, y su página de GitHub lista 2000 grabaciones en 50 clases. Cada nombre de sonido se convierte en una frase, lo que transforma la clasificación en búsqueda: el modelo integra el clip y la frase de etiqueta, y elige la más cercana. Antes del entrenamiento, el modelo solo colocaba el sonido correcto en primer lugar una vez de cada cuatro, cerca del 25 % de precisión. Los pares de frase y clip de audio se entrenaron luego durante siete minutos y medio en un acelerador A100. En clips inéditos, la precisión del primer puesto subió de una de cada cuatro a unas dos de cada tres, y sonidos como el cepillado de dientes empezaron a reconocerse casi siempre. Después el presentador ocultó 10 sonidos por completo del entrenamiento: los sonidos entrenados mejoraban como antes, los ocultos nada. El modelo había aprendido las etiquetas entregadas, no la escucha en general. Del lado del coste, la búsqueda de fotos y de voz no se movió mientras la búsqueda general de texto retrocedía unos 4 puntos . También apareció una trampa de ingeniería: el primer control se había hundido hacia cero, no por el adaptador sino por el procesador guardado con él, que recortaba cada clip a milisegundos. Una corrección de una línea, reutilizando el procesador del modelo base, lo resolvió. La lección es clara: después de guardar y recargar un adaptador de audio, hay que medir de nuevo el rendimiento.

El segundo estudio retoma la demostración inicial: el presentador dividió las versiones escritas de 120 de sus vídeos en pasajes breves. Sin preguntas asociadas, pidió a un modelo Gemini redactar una pregunta de espectador por pasaje, produciendo justo los pares de pregunta y pasaje respuesta que pide la teoría. La división se hizo por vídeo, así que las preguntas de prueba venían de vídeos nunca vistos en el entrenamiento. Antes del entrenamiento, el pasaje correcto volvía primero unas dos veces de cada tres; tras menos de tres minutos de entrenamiento, la tasa subía a tres de cada cuatro. El coste en texto general se repetía en unos 4 puntos. El veredicto es de doble filo: unos minutos de ajuste mejoraron claramente al modelo en sus propios sonidos y vídeos, pero aprendió etiquetas más que capacidades generales, cediendo algunos puntos de búsqueda textual general. El presentador cierra con tres reglas: convierte tus datos en pares manteniendo los duplicados fuera de los lotes, evalúa con datos inéditos divididos por fuente, y comprueba qué más cambió tras el entrenamiento, ya que todas las modalidades comparten el tronco.