Cómo elegir un modelo de embeddings: seis criterios

Empieza el bloque cuarto de la serie, dedicado a los modelos. Antes de comparar proveedores concretos conviene fijar el marco: qué se está eligiendo realmente cuando se elige un modelo de embeddings, y por qué es la decisión más cara de revertir de todo el pipeline.

Un modelo de embeddings convierte un fragmento de texto en un vector: una lista de números que representa su significado de forma que dos textos parecidos queden cerca en el espacio. Lo vimos en la entrega 3. Lo que no dijimos entonces es que esa conversión no es un detalle intercambiable, sino el contrato sobre el que se construye todo lo demás: el índice, la base vectorial, los umbrales de similitud, las evaluaciones y el presupuesto de almacenamiento.

Hay decenas de modelos disponibles y la tentación es abrir el ranking público de turno y coger el primero. Es un mal método, por razones que veremos al final. Uno mejor consiste en pasar los candidatos por seis criterios.

Los seis criterios, en una tabla

Dimensionalidad: el número que multiplica tu factura de almacenamiento

Los modelos actuales producen vectores de entre unos cientos y unos pocos miles de dimensiones. La intuición dice que más dimensiones es más matiz capturado, y en parte es verdad, pero el coste crece en un sitio donde duele.

El cálculo es directo y conviene hacerlo antes de decidir. Un vector de 1.024 dimensiones en coma flotante de 32 bits ocupa unos 4 KB. Un millón de fragmentos son del orden de 4 GB sólo en vectores, sin contar el texto original, los metadatos ni la estructura del índice. Si el índice es HNSW —lo vimos en la entrega 5—, los grafos de vecinos añaden por encima un porcentaje nada despreciable, y todo eso quiere estar en memoria para que la búsqueda sea rápida. Duplicar la dimensionalidad duplica esa cifra y encarece cada comparación.

La contrapartida es que la ganancia de calidad al subir dimensiones se aplana muy pronto. Por eso varios modelos recientes ofrecen dimensiones variables: emiten un vector largo del que puedes quedarte con un prefijo más corto perdiendo poca calidad. Merece la pena probar ese recorte con tu conjunto de evaluación antes de asumir que necesitas el vector completo.

Ventana de contexto: el límite silencioso

Todo modelo de embeddings tiene un máximo de tokens que acepta. Los clásicos se quedaban en 512 tokens, que en español son aproximadamente entre 350 y 400 palabras. Los más nuevos llegan a 8.192 tokens y algunos bastante más.

Lo peligroso no es el límite en sí, sino cómo se comporta al superarlo: la mayoría de implementaciones trunca en silencio. Si tus fragmentos son de 1.200 tokens y el modelo admite 512, estás indexando el primer 40 % de cada fragmento y descartando el resto sin que nadie lance un aviso. La recuperación funciona, devuelve resultados, y nunca encuentra lo que estaba en la segunda mitad de los documentos. Es uno de los fallos más difíciles de diagnosticar precisamente porque no falla nada de forma visible.

La consecuencia práctica es que la elección del modelo y la estrategia de troceado son una sola decisión, no dos. Conviene además comprobar el recuento de tokens con el tokenizador del modelo elegido, porque el español gasta más tokens por palabra que el inglés en casi todos ellos.

Idioma: el criterio que más veces se pasa por alto

Un modelo entrenado sobre todo con texto inglés aplicado a documentos en español recupera peor. No de forma catastrófica —sigue devolviendo algo razonable, que es justo lo que hace difícil detectarlo—, sino con una degradación constante que se nota en las preguntas difíciles y en el recall de los casos límite.

Hay además un caso frecuente que merece atención propia: el corpus mezclado. Documentación técnica en inglés, usuarios que preguntan en español. Aquí no basta con que el modelo «entienda» los dos idiomas: hace falta que sitúe cerca en el espacio vectorial una frase y su traducción, que es una propiedad distinta y que no todos los modelos multilingües tienen igual de desarrollada. La entrega 25 se dedica entera a este asunto.

Dominio: cuándo el modelo general no llega

Los modelos de propósito general se entrenan con texto web, y funcionan bien con texto que se parece a texto web. El problema aparece con vocabularios cerrados: nomenclatura jurídica, códigos de artículo, referencias de pieza, nombres de fármacos, siglas internas de una empresa.

Frente a eso hay tres salidas, en este orden. La búsqueda híbrida de la entrega 15, casi siempre suficiente: combinar el vector con BM25 recupera exactamente esos identificadores que el embedding difumina. Enriquecer el fragmento con contexto en la indexación. Y, la última por coste, ajustar un modelo con pares de tu dominio, que exige datos etiquetados y un mantenimiento que casi ningún equipo pequeño quiere asumir.

Coste: dos facturas distintas

Conviene separar el coste de indexación del de consulta, porque tienen formas distintas. La indexación es un pico: se paga una vez por el corpus completo, y otra vez cada vez que cambies de modelo o de troceado. La consulta es un goteo: cada pregunta genera un embedding de un texto corto, así que en volumen normal pesa poco frente al coste de la generación. El pico dicta la decisión económica en corpus grandes; el goteo, en corpus pequeños con mucho tráfico.

Portabilidad: dilo en voz alta antes de firmar

Este es el criterio que más consecuencias tiene y el que menos aparece en las comparativas, así que lo enunciamos sin rodeos: cambiar de modelo de embeddings obliga a reindexar todo el corpus. Sin excepciones, sin atajos y sin compatibilidad parcial.

La razón es que los vectores de dos modelos distintos viven en espacios distintos. No hay ninguna relación útil entre la posición de un texto en el espacio del modelo A y su posición en el del modelo B, aunque tengan el mismo número de dimensiones. Un índice con vectores mezclados de dos modelos no devuelve resultados peores: devuelve ruido.

Lo que eso implica en la práctica es un proyecto, no un cambio de configuración: volver a pasar el corpus entero por el modelo nuevo, construir un índice paralelo, validar con el conjunto de evaluación, conmutar y mantener los dos índices durante la transición. Y recalibrar todos los umbrales de similitud, porque las distancias de un modelo no significan lo mismo que las de otro.

De ahí dos recomendaciones concretas. La primera: guarda el texto original de cada fragmento junto al vector, siempre, aunque parezca redundante. Si sólo tienes vectores, reindexar exige volver a la fuente y repetir la ingesta entera. La segunda: aísla la llamada al modelo de embeddings tras una interfaz propia mínima, para que el día que cambies no tengas que tocar veinte sitios del código.

Cómo leer MTEB sin dejarse llevar

MTEB es el conjunto de pruebas de referencia para modelos de embeddings: agrupa muchas tareas —recuperación, clasificación, agrupamiento, similitud semántica— y publica una tabla ordenada. Es útil como filtro grueso y engañoso como decisión final, por cuatro motivos.

• La media agrega tareas que no te importan. En un RAG sólo cuenta el bloque de recuperación. Un modelo excelente en clasificación puede subir la media sin aportarte nada.
• Las diferencias en lo alto de la tabla son diminutas. Entre el primero y el décimo suele haber una distancia menor que la que introduce cambiar el tamaño de tus fragmentos. Elegir por ese margen es optimizar ruido.
• Los conjuntos de prueba son públicos. Existe una presión real hacia el sobreajuste, deliberado o accidental, sobre datos que llevan años circulando.
• Tu corpus no está en MTEB. Ni tu idioma con el peso que le corresponde, ni tu dominio, ni la forma en que preguntan tus usuarios.

El uso razonable es filtrar: mira el apartado de recuperación, filtra por idioma, descarta lo que no cumpla tus límites de dimensión o contexto, y quédate con tres o cuatro candidatos. La decisión entre esos tres o cuatro se toma con tu propio conjunto de evaluación —cincuenta preguntas con respuesta conocida sobre tu corpus real, lo que en la entrega 40 llamaremos el golden dataset— y no con la tabla.

Límites de todo esto

Dos advertencias. La primera es que el modelo de embeddings rara vez es la causa del problema que tienes delante. Cuando un RAG recupera mal, el orden de sospechosos empieza por el troceado, sigue por los metadatos y la falta de búsqueda híbrida, y termina en el modelo.

La segunda es que ninguno de estos seis criterios sustituye a medir. Sirven para reducir el catálogo y para no cometer errores estructurales —truncamiento silencioso, idioma equivocado, una factura de memoria que no cabe en el presupuesto—, pero la elección final se hace con datos propios. Sin conjunto de evaluación no estás eligiendo: estás apostando.

Qué viene ahora

La siguiente entrega baja al detalle de los proveedores comerciales de embeddings: qué familias ofrece cada uno, en qué se diferencian de verdad, cómo está estructurado su precio, qué límites de tasa imponen y qué asumes cuando pones una API ajena en el camino crítico de tu indexación. Después llegará el turno de los modelos abiertos autoalojados y del cálculo del punto de equilibrio entre unos y otros.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.