지난주 우리는 Jina Embeddings v3를 출시했습니다. 이는 최첨단 다국어 임베딩 모델이며 2023년 10월에 출시된 v2의 주요 업그레이드 버전입니다. V3는 다국어, task LoRA, 더 나은 long-context 지원 및 Matryoshka 학습을 특징으로 합니다. 현재 v2 사용자들은 v3로 전환하실 것을 강력히 권장드립니다. 이 마이그레이션 가이드는 v3의 기술적 변경사항을 다루어 원활한 전환을 돕고자 합니다.
tag주요 요약
- V3는 새로운 모델이므로 v2에서 전환할 때 모든 문서를 다시 인덱싱해야 합니다. V3 임베딩은 v2 임베딩 검색에 사용할 수 없으며, 그 반대도 마찬가지입니다.
- V3는 96%의 경우에서 v2보다 성능이 뛰어나며, 영어 요약 작업에서만 v2가 v3와 비슷하거나 약간 더 나은 성능을 보입니다. V3의 고급 기능과 다국어 지원을 고려할 때, 대부분의 경우 v2보다 v3를 선택하는 것이 좋습니다.
- V3는 세 가지 새로운 API 매개변수를 도입했습니다:
task,dimensions,late_chunking. 이러한 매개변수에 대한 자세한 이해를 위해서는 블로그 포스트의 해당 섹션을 확인하세요.
[이하 생략...]
# v2 English-German
data = {
"model": "jina-embeddings-v2-base-de",
"input": [
"The Force will be with you. Always.",
"Die Macht wird mit dir sein. Immer.",
"The ability to destroy a planet is insignificant next to the power of the Force.",
"Die Fähigkeit, einen Planeten zu zerstören, ist nichts im Vergleich zur Macht der Macht."
]
}
late_chunking 매개변수는 모델이 청크로 나누기 전에 전체 문서를 처리하여 긴 텍스트에서 더 많은 문맥을 보존할 수 있도록 제어합니다. 사용자 관점에서는 입력과 출력 형식은 동일하게 유지되지만, 임베딩 값은 각 청크를 독립적으로 계산하는 대신 전체 문서 문맥을 반영하게 됩니다.late_chunking=True를 사용할 때는 요청당 (input의 모든 청크의 합산) 총 토큰 수가 v3의 최대 문맥 길이인 8192로 제한됩니다.late_chunking=False를 사용할 때는 이 토큰 제한이 적용되지 않으며, 총 토큰은 Embedding API의 요율 제한에 의해서만 제한됩니다.
late chunking을 활성화하려면 API 호출 시 late_chunking=True를 전달하세요.
채팅 기록을 검색하면서 late chunking의 장점을 확인할 수 있습니다:
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."
]
Embeddings v2로 What's a good restaurant?를 검색하면 결과가 그다지 관련성이 없습니다:
| Document | Cosine Similarity |
|---|---|
| I'm not sure. I'm not too familiar with the restaurants in this area. | 0.7675 |
| I really love Mexican or Italian cuisine. | 0.7561 |
| How about this place, Bella Italia? It looks nice. | 0.7268 |
| What type of food are you in the mood for on your special day? | 0.7217 |
| Sita, have you decided where you'd like to go for dinner this Saturday for your birthday? | 0.7186 |
v3에서 late chunking 없이는 비슷한 결과가 나옵니다:
| Document | Cosine Similarity |
|---|---|
| I'm not sure. I'm not too familiar with the restaurants in this area. | 0.4005 |
| I really love Mexican or Italian cuisine. | 0.3752 |
| Sita, have you decided where you'd like to go for dinner this Saturday for your birthday? | 0.3330 |
| How about this place, Bella Italia? It looks nice. | 0.3143 |
| Yes, I think that would be a perfect choice! Let's call and reserve a spot. | 0.2615 |
하지만 v3와 late chunking을 함께 사용하면 성능이 크게 향상되어 가장 관련성 있는 결과(좋은 레스토랑)가 상단에 표시됩니다:
| Document | Cosine Similarity |
|---|---|
| How about this place, Bella Italia? It looks nice. | 0.5061 |
| Oh, I've heard of that! Everyone says it's fantastic! | 0.4498 |
| I really love Mexican or Italian cuisine. | 0.4373 |
| What type of food are you in the mood for on your special day? | 0.4355 |
| Yes, I think that would be a perfect choice! Let's call and reserve a spot. | 0.4328 |
보시다시피, 상위 일치 항목에 "restaurant"이라는 단어가 전혀 없더라도 late chunking은 원래 문맥을 보존하여 올바른 최상위 답변으로 제시합니다. 더 큰 텍스트에서 의미를 파악하기 때문에 "restaurant"을 레스토랑 이름 "Bella Italia"에 인코딩합니다.
tagMatryoshka Embeddings로 효율성과 성능의 균형 맞추기
Embeddings v3의 dimensions 매개변수를 사용하면 최소한의 비용으로 저장 효율성과 성능의 균형을 맞출 수 있습니다. v3의 Matryoshka embeddings를 사용하면 모델이 생성한 벡터를 잘라내어 유용한 정보는 유지하면서 필요한 만큼 차원을 줄일 수 있습니다. 더 작은 임베딩은 벡터 데이터베이스의 공간을 절약하고 검색 속도를 향상시키는 데 이상적입니다. 차원 감소에 따른 성능 영향을 추정할 수 있습니다:
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)
tagFAQ
tag이미 임베딩을 생성하기 전에 문서를 청크로 나누고 있는데, Late Chunking이 제 시스템보다 장점이 있나요?
Late chunking은 청크로 나누기 전에 전체 문서를 먼저 처리하여 텍스트 전반에 걸친 중요한 문맥적 관계를 보존하기 때문에 사전 청크화보다 장점이 있습니다. 이는 특히 복잡하거나 긴 문서에서 검색 정확도를 향상시킬 수 있는 더 문맥이 풍부한 임베딩을 생성합니다. 또한 late chunking은 모델이 문서를 세그먼트화하기 전에 전체적인 이해를 가지고 있기 때문에 검색이나 검색 중에 더 관련성 있는 응답을 제공하는 데 도움이 될 수 있습니다. 이는 청크가 전체 문맥 없이 독립적으로 처리되는 사전 청크화에 비해 전반적으로 더 나은 성능을 보입니다.
tagv2가 v3보다 Pair Classification에서 더 나은 이유는 무엇이며, 걱정해야 할까요?
v2-base-(zh/es/de) 모델이 Pair Classification(PC)에서 더 나은 성능을 보이는 이유는 주로 평균 점수 계산 방식 때문입니다. v2에서는 embeddings-v2-base-zh 모델이 뛰어난 중국어만 PC 성능에 고려되어 더 높은 평균 점수가 나옵니다. v3의 벤치마크는 중국어, 프랑스어, 폴란드어, 러시아어 등 4개 언어를 포함합니다. 그 결과, v2의 중국어 전용 점수와 비교할 때 전체 점수가 더 낮아 보입니다. 그러나 v3는 여전히 PC 작업에서 multilingual-e5와 같은 모델과 비슷하거나 더 나은 성능을 보입니다. 이러한 더 넓은 범위가 인식된 차이를 설명하며, 특히 v3가 여전히 경쟁력 있는 다국어 애플리케이션의 경우 성능 저하를 우려할 필요가 없습니다.
tagv3가 정말로 v2 이중 언어 모델의 특정 언어보다 성능이 뛰어날까요?
v3를 v2 이중 언어 모델과 비교할 때, 성능 차이는 특정 언어와 작업에 따라 다릅니다.
v2 이중 언어 모델은 해당 언어에 맞춰 고도로 최적화되었습니다. 그 결과, 중국어의 Pair Classification(PC)과 같은 해당 언어에 특화된 벤치마크에서는 v2가 더 우수한 결과를 보일 수 있습니다. 이는 embeddings-v2-base-zh의 설계가 해당 언어에 맞춰져 있어 그 좁은 범위에서 뛰어난 성능을 발휘할 수 있기 때문입니다.
하지만 v3는 89개 언어를 지원하고 작업별 LoRA 어댑터로 다양한 작업에 최적화되도록 설계된 더 넓은 다국어 지원을 위해 설계되었습니다. 이는 v3가 특정 언어의 모든 작업(중국어 PC와 같은)에서 항상 v2를 능가하지는 않을 수 있지만, 여러 언어에 걸쳐 평가하거나 검색 및 분류와 같은 더 복잡한 작업별 시나리오에서 전반적으로 더 나은 성능을 보이는 경향이 있다는 것을 의미합니다.
다국어 작업이나 여러 언어를 다룰 때 v3는 언어 간 더 나은 일반화를 활용하는 더 균형 잡히고 포괄적인 솔루션을 제공합니다. 그러나 이중 언어 모델이 미세 조정된 매우 언어별 작업의 경우 v2가 우위를 유지할 수 있습니다.
실제로는 작업의 특정 요구 사항에 따라 적절한 모델이 달라집니다. 특정 언어만 다루고 v2가 그 언어에 최적화된 경우에는 v2에서도 경쟁력 있는 결과를 볼 수 있습니다. 하지만 더 일반화되거나 다국어 애플리케이션의 경우 v3가 다용도성과 더 넓은 최적화 때문에 더 나은 선택일 수 있습니다.
tagv2가 v3보다 요약에서 더 나은 이유는 무엇이며, 이것을 걱정해야 할까요?
v2-base-en는 요약과 밀접한 관련이 있는 의미적 유사성과 같은 작업에 최적화된 아키텍처를 가지고 있기 때문에 요약(SM)에서 더 나은 성능을 보입니다. 반면 v3는 더 넓은 범위의 작업을 지원하도록 설계되었으며, 특히 검색 및 분류 작업에서 그리고 복잡하고 다국어 시나리오에 더 적합합니다.
하지만 SM에서의 이러한 성능 차이는 대부분의 사용자에게 걱정할 필요가 없습니다. SM 평가는 주로 의미적 유사성을 측정하는 SummEval이라는 단 하나의 요약 작업을 기반으로 합니다. 이 작업만으로는 모델의 더 넓은 능력을 잘 알 수 없거나 대표하지 못합니다. v3가 검색과 같은 다른 중요한 영역에서 뛰어나기 때문에, 요약의 차이가 실제 사용 사례에 크게 영향을 미치지 않을 것 같습니다.
