Incrustaciones

Para obtener información detallada sobre nuestros procesos de capacitación, fuentes de datos y evaluaciones, consulte nuestros informes técnicos en arXiv para jina-embeddings-v3 y jina-embeddings-v4.

jina-embeddings-v4 es nuestro modelo multimodal universal más reciente (3800 millones de parámetros) compatible con texto e imágenes con contexto de 32 K, recuperación densa y de interacción tardía, y rendimiento SOTA en documentos visualmente ricos. jina-clip-v2 es una opción más ligera (865 millones de parámetros) compatible con 89 idiomas con una resolución de imagen de 512 x 512 y representaciones de Matryoshka. Ambos son excelentes en tareas de recuperación de texto a texto, texto a imagen e imagen a imagen.

Tanto jina-embeddings-v4 como jina-embeddings-v3 admiten 89 idiomas con un excelente rendimiento multilingüe. Los 30 idiomas principales incluyen: alemán, árabe, bengalí, chino, coreano, danés, eslovaco, español, finlandés, francés, georgiano, griego, hindi, indonesio, inglés, italiano, japonés, letón, noruego, polaco, portugués, rumano, ruso, sueco, tailandés, turco, ucraniano, urdu y vietnamita. jina-clip-v2 también admite 89 idiomas para tareas multimodales.

La longitud del contexto varía según el modelo: jina-embeddings-v4 admite hasta 32 000 tokens, mientras que jina-embeddings-v3 y jina-clip-v2 admiten hasta 8192 tokens. Un token puede abarcar desde un solo carácter hasta una palabra completa. Este contexto extendido permite un análisis exhaustivo de documentos y una mayor precisión en la comprensión del contexto para datos textuales extensos.

No hay un límite estricto en la cantidad de elementos por solicitud. La API agrupa las entradas internamente por número de tokens para optimizar el uso de la GPU. Puedes enviar tantos textos o imágenes como necesites en una sola solicitud.

Para jina-embeddings-v4, jina-clip-v2 y jina-clip-v1, puede usar url o bytes en el campo input de la solicitud de API. Para url, proporcione la URL de la imagen que desea procesar. Para bytes, codifique la imagen en formato base64. jina-embeddings-v4 también puede incrustar documentos PDF directamente pasando una URL de PDF o bytes de PDF codificados en base64.

jina-embeddings-v4 es nuestro modelo insignia más reciente, que alcanza la excelencia en la recuperación de documentos visualmente enriquecidos (ViDoRe) y en pruebas multimodales. Para tareas de solo texto, jina-embeddings-v3 supera a OpenAI y Cohere en las pruebas MTEB de inglés y multilingüe, además de ser más pequeño y eficiente. Ambos modelos son compatibles con el aprendizaje de representación Matryoshka (MRL), lo que permite el truncamiento de dimensiones (hasta 32 para la versión 3 y hasta 128 para la versión 4) sin una pérdida significativa de rendimiento.

La transición se simplifica, ya que nuestro punto final de API coincide con los esquemas JSON de entrada y salida del modelo text-embedding-3-large de OpenAI. Esta compatibilidad garantiza que los usuarios puedan reemplazar fácilmente el modelo de OpenAI por el nuestro cuando utilicen el punto final de OpenAI.

Los tokens se calculan en función de la longitud del texto y el tamaño de la imagen. Para el texto de la solicitud, los tokens se contabilizan de la forma estándar. Para las imágenes, se realizan los siguientes pasos: 1. Tamaño del mosaico: Cada imagen se divide en mosaicos. Para jina-embeddings-v4, los mosaicos miden 28x28 píxeles, para jina-clip-v2, los mosaicos miden 512x512 píxeles, mientras que para jina-clip-v1, los mosaicos miden 224x224 píxeles. 2. Cobertura: Se calcula el número de mosaicos necesarios para cubrir la imagen de entrada. Incluso si las dimensiones de la imagen no son perfectamente divisibles por el tamaño del mosaico, los mosaicos parciales se contabilizan como mosaicos completos. 3. Mosaicos totales: El número total de mosaicos que cubren la imagen determina el coste. Por ejemplo, una imagen de 600x600 píxeles estaría cubierta por mosaicos de 22x22 (484 mosaicos) en jina-embeddings-v4, por mosaicos de 2x2 (4 mosaicos) en jina-clip-v2 y por mosaicos de 3x3 (9 mosaicos) en jina-clip-v1. 4. Cálculo del coste: Para jina-embeddings-v4, cada mosaico cuesta 10 tokens; para jina-clip-v2, cada mosaico cuesta 4000 tokens; mientras que para jina-clip-v1, cada mosaico cuesta 1000 tokens. Ejemplo: Para una imagen con dimensiones de 600x600 píxeles: • Con jina-embeddings-v4 • La imagen se divide en mosaicos de 28x28 píxeles. • El número total de mosaicos requeridos es 22 (horizontales) x 22 (verticales) = 484 mosaicos. • El costo de jina-embeddings-v4 será de 484*10 = 4840 tokens. • Con jina-clip-v2 • La imagen se divide en mosaicos de 512x512 píxeles. • El número total de mosaicos requeridos es 2 (horizontales) x 2 (verticales) = 4 mosaicos. • El costo de jina-clip-v2 será de 4*4000 = 16000 tokens. • Con jina-clip-v1 • La imagen se divide en mosaicos de 224x224 píxeles. • El número total de fichas necesarias es 3 (horizontales) x 3 (verticales) = 9 fichas. • El coste de jina-clip-v1 será 9*1000 = 9000 tokens.

Sí, jina-clip-v2 y jina-clip-v1 pueden incorporar imágenes y textos. ¡Pronto anunciaremos la incorporación de modelos en más modalidades!

Si tiene consultas sobre cómo ajustar nuestros modelos con datos específicos, contáctenos para analizar sus requisitos. Estamos abiertos a explorar cómo nuestros modelos se pueden adaptar para satisfacer sus necesidades.

Sí, nuestros servicios están disponibles en los mercados de AWS, Azure y GCP. Si tiene requisitos específicos, comuníquese con nosotros a sales AT jina.ai.

El parámetro task en jina-embeddings-v3 y jina-embeddings-v4 activa adaptadores LoRA específicos de cada tarea para un rendimiento óptimo. Utilice retrieval.query para consultas de búsqueda, retrieval.passage para documentos que se buscarán, text-matching para similitud semántica, classification para clasificación de texto y separation para tareas de agrupamiento.

jina-embeddings-v4 admite la recuperación densa (de un solo vector) y la de interacción tardía (multivector) mediante el parámetro output_type. La interacción tardía conserva información más detallada a nivel de token para una mayor precisión de recuperación en consultas complejas. jina-colbert-v2 es un modelo dedicado a la interacción tardía.

La fragmentación tardía es una técnica que primero integra todo el documento mediante modelos de contexto extenso y luego extrae las incrustaciones de fragmentos de las representaciones a nivel de token. A diferencia de la fragmentación simple (fragmentar primero, luego incrustar), la fragmentación tardía preserva el contexto entre fragmentos, lo que mejora la recuperación para aplicaciones RAG. Habilítela mediante el parámetro late_chunking en jina-embeddings-v3.

Si bien algunos de nuestros modelos de incrustación tienen la capacidad arquitectónica de procesar contextos más largos, la API puede imponer límites inferiores debido a las limitaciones de VRAM de la GPU en nuestra infraestructura de inferencia. Procesar secuencias muy largas requiere una cantidad considerable de memoria, por lo que optimizamos nuestra configuración de servicio para equilibrar el rendimiento, la latencia y el coste en la mayoría de los casos de uso. Si necesita compatibilidad con contextos más largos, póngase en contacto con nuestro equipo de ventas para hablar sobre opciones de implementación dedicadas.

jina-embeddings-v4 se basa en el modelo base Qwen2-VL, publicado bajo la Licencia de Investigación de Qwen. Esta licencia solo permite su uso con fines de investigación y no comerciales, lo que significa que no podemos ofrecer jina-embeddings-v4 como producto comercial. Por ello, ofrecemos acceso gratuito al modelo a través de nuestra API. Hay dos razones por las que jina-embeddings-v4 puede parecer más lento que otros modelos: en primer lugar, jina-embeddings-v4 es un modelo significativamente más grande que jina-embeddings-v3, por lo que requiere inherentemente más tiempo de cálculo por solicitud. En segundo lugar, dado que no podemos comercializar este modelo, limitamos intencionalmente el rendimiento de la API para gestionar los costes de infraestructura. Los usuarios no deben esperar un rendimiento de alto volumen ni de producción al utilizar la API jina-embeddings-v4. Para cargas de trabajo de producción que requieren un mayor rendimiento, recomendamos usar jina-embeddings-v3 o implementar jina-embeddings-v4 en su propia infraestructura a través de Hugging Face.

Los límites de velocidad dependen del tipo de clave API:

Gratis: 100 RPM, 100 000 TPM, 2 solicitudes simultáneas
Pago: 500 RPM, 2 000 000 TPM, 50 solicitudes simultáneas
Premium: 5000 RPM, 50 000 000 TPM, 500 solicitudes simultáneas

Además, existe un límite de velocidad basado en IP de 10 000 solicitudes cada 60 segundos para evitar abusos. Si necesita límites mayores, póngase en contacto con nuestro equipo de ventas.

Cada modelo tiene una longitud máxima de contexto por entrada:

jina-embeddings-v4: 32,768 tokens
jina-embeddings-v3: 8,192 tokens
jina-embeddings-v2-*: 8,192 tokens
jina-clip-v1/v2: 8,192 tokens
jina-colbert-v1/v2: 8,192 tokens
jina-code-embeddings-*: 32,768 tokens

Las entradas que excedan el límite devolverán un error a menos que se configure truncate: true, lo que trunca automáticamente a la longitud máxima.

Los tamaños máximos de archivo son: Imágenes: 5 MB, PDF: 8 MB. Los archivos más grandes se rechazarán con un error.

Sí, la misma clave API es válida para todos los productos de la base de búsqueda de Jina AI. Esto incluye las API de lectura, incrustación, reclasificación, clasificación y ajuste, con tokens compartidos entre todos los servicios.

Sí, el uso de tokens se puede monitorear en la pestaña "Clave API y facturación" ingresando su clave API, lo que le permite ver el historial de uso reciente y los tokens restantes. Si ha iniciado sesión en el panel de API, estos detalles también se pueden ver en la pestaña "Administrar clave API".

Si ha perdido una clave recargada y desea recuperarla, comuníquese con el servicio de asistencia de jina.ai con su correo electrónico registrado para recibir asistencia. Se recomienda iniciar sesión para mantener su clave API almacenada de forma segura y de fácil acceso.

No, nuestras claves API no tienen fecha de vencimiento. Sin embargo, si sospecha que su clave ha sido comprometida y desea retirarla, comuníquese con nuestro equipo de soporte para obtener ayuda. También puede revocar su clave en el panel de administración de claves API.

Sí, puedes transferir tokens de una clave premium a otra. Después de iniciar sesión en tu cuenta en el panel de administración de claves API, usa la configuración de la clave que deseas transferir para mover todos los tokens pagos restantes.

Sí, puedes revocar tu clave API si crees que se ha visto comprometida. Al revocar una clave, se deshabilitará de inmediato para todos los usuarios que la hayan almacenado, y todo el saldo restante y las propiedades asociadas quedarán inutilizables de forma permanente. Si la clave es una clave premium, tienes la opción de transferir el saldo restante pagado a otra clave antes de la revocación. Ten en cuenta que esta acción no se puede deshacer. Para revocar una clave, ve a la configuración de claves en el panel de control de administración de claves API.

Esto se debe a que nuestra arquitectura sin servidor descarga ciertos modelos durante períodos de bajo uso. La solicitud inicial activa o "calienta" el modelo, lo que puede tardar unos segundos. Después de esta activación inicial, las solicitudes posteriores se procesan mucho más rápido.

No. Nunca utilizamos sus solicitudes, entradas ni salidas de API para entrenar nuestros modelos de incrustación, reranking ni ningún otro. Sus datos siguen siendo suyos. Cumplimos con las normas SOC 2 Tipo I y Tipo II.

Se aplican límites de velocidad por clave de API:

Gratis: 100 RPM, 100 000 TPM, 2 solicitudes simultáneas
Pago: 500 RPM, 2 000 000 TPM, 50 solicitudes simultáneas
Premium: 5000 RPM, 50 000 000 TPM, 500 solicitudes simultáneas

También hay un límite de velocidad basado en IP de 10 000 solicitudes cada 60 segundos. Estos límites se aplican a todas las API de Jina (Incrustaciones, Reranker, Lector, etc.).

No hay límite de tamaño de lote para las API de incrustaciones ni para las de reranking. Puede enviar tantos elementos o documentos como necesite por solicitud. Ambas API procesan las entradas internamente por lotes según el número de tokens para optimizar el uso de la GPU.

Nuestro modelo de precios se basa en la cantidad total de tokens procesados, lo que permite a los usuarios la flexibilidad de asignar estos tokens en cualquier cantidad de oraciones, ofreciendo una solución rentable para diversos requisitos de análisis de texto.

Ofrecemos una prueba gratuita de bienvenida a los nuevos usuarios, que incluye diez millones de tokens para usar con cualquiera de nuestros modelos, gracias a una clave API generada automáticamente. Una vez alcanzado el límite de tokens gratuitos, los usuarios pueden comprar fácilmente tokens adicionales para sus claves API a través de la pestaña "Comprar tokens".

No, los tokens no se deducen por solicitudes fallidas.

Los pagos se procesan a través de Stripe y admiten una variedad de métodos de pago que incluyen tarjetas de crédito, Google Pay y PayPal para su comodidad.

Sí, se emitirá una factura a la dirección de correo electrónico asociada a su cuenta de Stripe tras la compra de tokens.