Migración de Jina Embeddings v2 a v3

• Cuando se usa late_chunking=True, el número total de tokens (sumados a través de todos los fragmentos en input) por solicitud está restringido a 8192, la longitud máxima de contexto permitida para v3.
• Cuando se usa late_chunking=False, este límite de tokens no aplica, y los tokens totales solo están restringidos por el límite de tasa de la API de Embeddings.

Para habilitar el late chunking, pasa late_chunking=True en tus llamadas a la API.

Puedes ver la ventaja del late chunking al buscar en un historial de chat:

history = [
    "Sita, have you decided where you'd like to go for dinner this Saturday for your birthday?",
    "I'm not sure. I'm not too familiar with the restaurants in this area.",
    "We could always check out some recommendations online.",
    "That sounds great. Let's do that!",
    "What type of food are you in the mood for on your special day?",
    "I really love Mexican or Italian cuisine.",
    "How about this place, Bella Italia? It looks nice.",
    "Oh, I've heard of that! Everyone says it's fantastic!",
    "Shall we go ahead and book a table there then?",
    "Yes, I think that would be a perfect choice! Let's call and reserve a spot."
]
Copiar

Si preguntamos What's a good restaurant? con Embeddings v2, los resultados no son muy relevantes:

Con v3 y sin late chunking, obtenemos resultados similares:

Sin embargo, vemos una marcada mejora en el rendimiento cuando usamos v3 y late chunking, con el resultado más relevante (un buen restaurante) en la parte superior:

Como puedes ver, aunque la mejor coincidencia no menciona la palabra "restaurante" en absoluto, el late chunking preserva su contexto original y lo presenta como la respuesta correcta principal. Codifica "restaurante" en el nombre del restaurante "Bella Italia" porque ve su significado en el texto más amplio.

tagEquilibra Eficiencia y Rendimiento con Embeddings Matryoshka

El parámetro dimensions en Embeddings v3 te da la capacidad de equilibrar la eficiencia de almacenamiento con el rendimiento a un costo mínimo. Los embeddings Matryoshka de v3 te permiten truncar los vectores producidos por el modelo, reduciendo las dimensiones tanto como necesites mientras conservas información útil. Los embeddings más pequeños son ideales para ahorrar espacio en bases de datos vectoriales y mejorar la velocidad de recuperación. Puedes estimar el impacto en el rendimiento según cuánto se reducen las dimensiones:

data = {
    "model": "jina-embeddings-v3",
    "task": "text-matching",
    "dimensions": 768, # 1024 by default
    "input": [
        "The Force will be with you. Always.",
        "力量与你同在。永远。",
        "La Forza sarà con te. Sempre.",
        "フォースと共にあらんことを。いつも。"
    ]
}

response = requests.post(url, headers=headers, json=data)
Copiar

tagFAQ

tagYa estoy fragmentando mis documentos antes de generar embeddings. ¿Ofrece el late chunking alguna ventaja sobre mi propio sistema?

El late chunking ofrece ventajas sobre la pre-fragmentación porque procesa todo el documento primero, preservando relaciones contextuales importantes a través del texto antes de dividirlo en fragmentos. Esto resulta en embeddings más ricos en contexto, que pueden mejorar la precisión de recuperación, especialmente en documentos complejos o extensos. Además, el late chunking puede ayudar a entregar respuestas más relevantes durante la búsqueda o recuperación, ya que el modelo tiene una comprensión holística del documento antes de segmentarlo. Esto lleva a un mejor rendimiento general comparado con la pre-fragmentación, donde los fragmentos se tratan independientemente sin el contexto completo.

tag¿Por qué v2 es mejor en clasificación por pares que v3, y debería preocuparme?

La razón por la que los modelos v2-base-(zh/es/de) parecen tener mejor rendimiento en Clasificación por Pares (PC) se debe principalmente a cómo se calcula el puntaje promedio. En v2, solo se considera el chino para el rendimiento de PC, donde el modelo embeddings-v2-base-zh sobresale, llevando a un puntaje promedio más alto. Los benchmarks de v3 incluyen cuatro idiomas: chino, francés, polaco y ruso. Como resultado, su puntaje general parece más bajo cuando se compara con el puntaje de solo chino de v2. Sin embargo, v3 aún iguala o supera a modelos como multilingual-e5 en todos los idiomas para tareas de PC. Este alcance más amplio explica la diferencia percibida, y la caída en el rendimiento no debería ser una preocupación, especialmente para aplicaciones multilingües donde v3 sigue siendo altamente competitivo.

tag¿Realmente v3 supera a los modelos bilingües v2 en idiomas específicos?

Al comparar v3 con los modelos bilingües v2, la diferencia de rendimiento depende de los idiomas específicos y las tareas.

Los modelos bilingües v2 fueron altamente optimizados para sus respectivos idiomas. Como resultado, en benchmarks específicos para esos idiomas, como Clasificación por Pares (PC) en chino, v2 podría mostrar resultados superiores. Esto es porque el diseño de embeddings-v2-base-zh fue adaptado específicamente para ese idioma, permitiéndole sobresalir en ese ámbito específico.

Sin embargo, v3 está diseñado para un soporte multilingüe más amplio, manejando 89 idiomas y siendo optimizado para una variedad de tareas con adaptadores LoRA específicos para cada tarea. Esto significa que aunque v3 podría no superar siempre a v2 en cada tarea específica para un idioma (como PC para chino), tiende a tener mejor rendimiento general cuando se evalúa en múltiples idiomas o en escenarios más complejos y específicos de tareas como recuperación y clasificación.

Para tareas multilingües o cuando se trabaja con varios idiomas, v3 ofrece una solución más balanceada y completa, aprovechando una mejor generalización entre idiomas. Sin embargo, para tareas muy específicas de un idioma donde el modelo bilingüe fue finamente ajustado, v2 podría mantener una ventaja.

En la práctica, el modelo correcto depende de las necesidades específicas de tu tarea. Si estás trabajando solo con un idioma particular y v2 fue optimizado para él, podrías seguir viendo resultados competitivos con v2. Pero para aplicaciones más generales o multilingües, v3 es probablemente la mejor opción debido a su versatilidad y optimización más amplia.

tag¿Por qué v2 es mejor en resumen que v3, y debo preocuparme por esto?

v2-base-en tiene mejor rendimiento en resumen (SM) porque su arquitectura fue optimizada para tareas como similitud semántica, que está estrechamente relacionada con el resumen. En contraste, v3 está diseñado para soportar una gama más amplia de tareas, particularmente en tareas de recuperación y clasificación, y está más adaptado a escenarios complejos y multilingües.

Sin embargo, esta diferencia de rendimiento en SM no debería ser una preocupación para la mayoría de los usuarios. La evaluación de SM se basa en solo una tarea de resumen, SummEval, que principalmente mide similitud semántica. Esta tarea por sí sola no es muy informativa o representativa de las capacidades más amplias del modelo. Dado que v3 sobresale en otras áreas críticas como recuperación, es probable que la diferencia en resumen no impacte significativamente tus casos de uso en el mundo real.