¿Puede un modelo de búsqueda entender mejor un documento si no lo resume en un solo vector? La nueva propuesta de Sentence Transformers responde que sí. Su componente MultiVectorEncoder permite entrenar modelos de embeddings multi-vector, también conocidos como modelos ColBERT o de interacción tardía, para adaptarlos a dominios concretos como medicina, derecho, código o documentación empresarial.
La guía publicada en Hugging Face no se queda en la teoría: explica cómo elegir el modelo, preparar los datos, seleccionar la función de pérdida, evaluar los resultados y entrenar todo el sistema con una sola GPU de consumo.
Un vector por documento frente a un vector por token
Los modelos densos tradicionales convierten cada documento completo en un único vector. Después, comparan el vector de la consulta con el del documento mediante una operación de similitud. Es una estrategia eficiente, pero obliga al modelo a comprimir demasiada información en una sola representación.
Los modelos multi-vector siguen otro camino. Generan un vector pequeño por cada token del texto y comparan la consulta con el documento token por token. El operador MaxSim busca el mejor elemento equivalente para cada token de la consulta y luego suma esas coincidencias.
En lugar de preguntarse si dos textos se parecen en general, el modelo puede identificar qué fragmentos concretos de la consulta encuentran respaldo en el documento.
Esta granularidad suele mejorar la recuperación de información, especialmente cuando importan términos específicos. La desventaja es que el índice almacena muchos más vectores y necesita una estrategia de compresión adecuada.
Por qué conviene ajustar el modelo al dominio
Un modelo entrenado para búsquedas web no necesariamente entiende igual una consulta médica, una cláusula legal o una pregunta sobre el código interno de una empresa. El vocabulario, el estilo de las consultas y la definición de relevancia cambian según el contexto.
El ajuste con datos del propio dominio permite que el modelo aprenda esas señales. En el caso presentado por Hugging Face, los documentos médicos tenían un promedio de 941 tokens. Muchos modelos disponibles limitan los documentos a entre 180 y 512 tokens, por lo que descartan una parte importante del contenido antes de calcular la relevancia.
En esa evaluación, mantener el límite de documentos produjo diferencias de hasta 0,24 puntos en NDCG@10, una métrica habitual para medir la calidad de los primeros resultados. La conclusión es directa: antes de comparar arquitecturas, hay que confirmar que el modelo pueda leer el documento completo.
La receta de entrenamiento
Todo el flujo puede ejecutarse instalando el paquete de entrenamiento de Sentence Transformers:
pip install -U "sentence-transformers[train]"
El proceso reúne seis piezas principales:
- Modelo: un checkpoint multi-vector existente o una arquitectura creada desde cero.
- Dataset: pares de consulta y documento relevante, además de datos de evaluación.
- Función de pérdida: el mecanismo que guía la actualización de los pesos.
- Argumentos de entrenamiento: parámetros de memoria, velocidad, precisión y seguimiento.
- Evaluador: una herramienta para medir la calidad de recuperación.
- Trainer: la clase que coordina todos los componentes.
Qué modelo usar como punto de partida
Uno de los resultados más interesantes de la guía aparece al comparar distintos puntos de inicio. Los checkpoints que ya fueron preentrenados para interacción tardía, pero todavía no recibieron el ajuste supervisado final, se adaptaron mejor al dominio médico.
El modelo lightonai/mLateOn-unsupervised pasó de un NDCG@10 de 0,9087 a 0,9398 después de entrenarse con 25.000 pares médicos. En cambio, algunos checkpoints terminados descendieron tras el ajuste, porque su entrenamiento general ya había fijado patrones que no encajaban tan bien con el nuevo dominio.
La recomendación práctica es comenzar, en este orden, con:
- Un checkpoint multi-vector preentrenado, pero no ajustado de forma supervisada para búsquedas generales.
- Un modelo base fuerte al que se añada una nueva proyección a nivel de token.
- Un checkpoint finalizado para recuperación general, solo si no existen las opciones anteriores.
También es posible utilizar un transformer base como answerdotai/ModernBERT-base. Sentence Transformers añade una capa de proyección token a token, que debe entrenarse antes de que el modelo sea útil.
Datos, pérdida y memoria de GPU
Para el caso común de preguntas y pasajes relevantes, la guía recomienda MultiVectorMultipleNegativesRankingLoss. En cada lote, el documento correcto de una consulta funciona como positivo y los documentos de las demás consultas actúan como negativos.
Los lotes grandes suelen aportar más negativos y mejorar el aprendizaje. Sin embargo, los modelos multi-vector consumen bastante memoria, sobre todo cuando trabajan con documentos largos. Por eso se recomienda CachedMultiVectorMultipleNegativesRankingLoss, una variante que permite mantener un lote efectivo grande mientras procesa los documentos en fragmentos pequeños.
En el ejemplo presentado, el lote efectivo fue de 128 muestras, mientras que los documentos se codificaron en grupos de 16 para controlar la memoria. Con documentos de longitud muy variable, también puede utilizarse un presupuesto máximo de tokens por fragmento.
Hay un detalle técnico importante: la pérdida multi-vector utiliza por defecto scale=1.0. No conviene copiar automáticamente el valor 20.0 habitual en algunos modelos densos. La similitud MaxSim suma coincidencias token a token y ya produce valores en un rango más amplio. Una escala demasiado alta puede saturar el softmax y debilitar los gradientes.
Una configuración pensada para documentos largos
El entrenamiento de referencia utilizó varias decisiones que fueron comprobadas mediante experimentos:
- Un millón de pares de preguntas y pasajes médicos.
- Una época de entrenamiento.
- Tasa de aprendizaje de
1e-4. - Longitud máxima del modelo de hasta 8192 tokens.
- Marcadores
[Q]para preguntas y[D]para documentos. - Lotes sin duplicados para mejorar los negativos en lote.
- Precisión
BF16en una GPU compatible. - Evaluación periódica durante el entrenamiento.
El modelo también excluyó tokens de puntuación durante la comparación y el almacenamiento. Esa modificación redujo el tamaño del índice en 9,6% en el conjunto evaluado, con una mejora moderada de calidad.
El entrenamiento completo tomó 14,5 horas en una RTX 3090 y utilizó un máximo aproximado de 17,5 GB de memoria de video. Para presupuestos más pequeños, 100.000 pares alcanzaron resultados situados a solo 0,012 puntos de NDCG@10 del entrenamiento con un millón de ejemplos.
Evaluar con un corpus que realmente desafíe al modelo
Un error común es evaluar una búsqueda contra un conjunto demasiado fácil. Si cada consulta solo se compara con su documento correcto y unos pocos candidatos, casi cualquier modelo puede obtener una puntuación alta.
La guía utiliza 1.000 preguntas médicas y un corpus de 200.000 pasajes. Los documentos relevantes se mezclan con 190.000 distractores procedentes del conjunto de entrenamiento. De esta manera, el evaluador puede diferenciar entre modelos realmente útiles y modelos que solo aprovechan coincidencias sencillas.
Sentence Transformers incluye evaluadores específicos como:
MultiVectorInformationRetrievalEvaluatorpara consultas, corpus y documentos relevantes.MultiVectorNanoBEIREvaluatorpara pruebas estándar sin preparar un dataset propio.MultiVectorTripletEvaluatorpara tríos de consulta, positivo y negativo.MultiVectorRerankingEvaluatorpara evaluar listas de candidatos.MultiVectorDistillationEvaluatorpara comparar el modelo con un teacher.
Para un proyecto real, el evaluador de recuperación construido con datos separados del entrenamiento suele ser la referencia más útil. ¿De qué sirve un resultado espectacular si el corpus de prueba no se parece a las búsquedas que recibirán tus usuarios?
El modelo ajustado supera a alternativas generales
En la evaluación médica, multi-vector-encoder/mLateOn-medical logró un NDCG@10 de 0,9139. Superó a los modelos generales de interacción tardía, a modelos densos, a sistemas dispersos y a la búsqueda léxica con BM25.
Algunas cifras comparativas fueron:
mLateOn-medical: 0,9139.lightonai/mLateOn: 0,8520.GTE-ModernColBERT-v1: 0,8502.Qwen3-Embedding-4B: 0,7817.voyage-4-nano: 0,7563.- BM25: 0,7501.
splade-v3: 0,6853.
El modelo ajustado obtuvo el resultado correcto en la primera posición para el 84,9% de las consultas, frente al 75,8% del modelo general más fuerte en esa comparación. Eso representa una reducción de más de un tercio en los errores de primer resultado.
Estos números no significan que el modelo médico sea el mejor para cualquier tarea. Significan algo más útil: un modelo especializado puede superar a alternativas mucho más grandes cuando conoce el vocabulario y la estructura de su propio dominio.
El tamaño del índice ya no es un obstáculo insalvable
Almacenar un vector por token puede parecer demasiado costoso. En el experimento, los embeddings sin comprimir ocuparon cerca de 45 GB para 200.000 documentos médicos, mientras que un modelo denso habría necesitado menos de 1 GB.
Pero ese no es necesariamente el tamaño final de producción. La guía combina reducción de vectores, cuantización y poda. Con cuantización residual de un bit mediante PLAID, el índice bajó a 3,37 GB, con una pérdida de solo 0,0155 puntos de NDCG@10 frente a los embeddings sin comprimir.
Con poda adicional, el índice llegó a 1,45 GB y conservó un NDCG@10 de 0,8642. También se evaluó HierarchicalTokenPooling, que agrupa vectores de un documento y almacena sus medias. Reducir a la mitad la cantidad de vectores costó apenas 0,0033 puntos y no cambió la precisión en la primera posición.
La lección para una implementación real es clara: no basta con elegir un checkpoint. La estrategia de indexación, cuantización y compresión puede determinar tanto el costo como la latencia del sistema.
Qué significa para tus propios proyectos
La nueva API de MultiVectorEncoder convierte el entrenamiento de modelos ColBERT en un proceso más accesible. No necesitas comenzar con un clúster de GPUs ni con un teacher especializado: un conjunto de pares de consulta y documento, una evaluación bien diseñada y una GPU de consumo pueden ser suficientes para obtener mejoras importantes.
Si trabajas con documentos largos o información muy específica, vale la pena probar este enfoque junto con una línea base sencilla como BM25 y un modelo denso general. La comparación te dirá si las coincidencias a nivel de token aportan valor real en tu caso.
La IA de recuperación no tiene que ser una caja negra ni una apuesta basada en el tamaño del modelo. Con datos propios, métricas honestas y una configuración que respete la longitud de los documentos, puedes construir un buscador especializado que entienda mejor lo que tu audiencia realmente necesita.