最も強力なAIモデルはWeb API経由でアクセスするリモートのクラウド環境で実行されるため、セキュリティ、サービスの可用性、および安定した価格に関してAIサービスプロバイダーを信頼する必要があります。信頼性、プライバシー、管理可能なコスト、優れたデータガバナンスに対する合理的な要求と、ますます強力で高度かつ多くのリソースを必要とするAIの利用を簡単に両立させることはできません。

政府の規制、裁判所の決定、他者の利益を考慮したビジネス上の判断はいずれも、最近、特定のサービスへのアクセスを制限する結果となっています。また、他のサービスに切り替えることができたとしても、AIモデルはいつでも好きなときに簡単に交換できるようなコンポーネントではありません。セマンティック埋め込みを使用するアプリケーションは、データインジェスト時と同じモデルにクエリ時にもアクセスできることに依存しています。埋め込みモデルへのアクセスを失うことは、検索システムが停止することを意味します。

AI価格設定モデルはそのリスクをさらに増大させます。主要なAIベンダーによる最近の財務情報開示は、顧客が潜在的な値上げを懸念する十分な理由となっています。予測不能なコストを伴う製品への依存は、明確なリターンを生み出さない可能性がある資本集約的なAI投資に、さらなるリスクをもたらします。

Jina On-Premは、これらの課題に対するElasticの解決策です。

オンプレミスAIを必要とするのは誰でしょうか？

ローカルホスティングとAIモデルの直接制御により、さまざまな技術的要求、業界の要件、ビジネス上のニーズに対応できます。

ローカルにインストールすることで、AIサービスプロバイダーに支払う費用は削減できますが、ハードウェアや信頼性の高いアクセスのコストは組織が負担することになります。利用量によっては、単純にその方が安くなる場合もあります。しかし、自社でAIを実行することを検討すべき差し迫った理由は他にもあります。以下で説明する課題のいずれかが貴社に関係する場合は、Jina On-PremのようなローカルAIソリューションをご検討ください。このリストはすべてを網羅したものではありません。

ユースケース

なぜオンプレミスなのか

例

エアギャップ/高セキュリティ

アウトバウンドデータ送信なし、完全なネットワーク分離

防衛、インテリジェンス、機密研究

規制遵守

データ主権、国境を越えた送信やサードパーティへの露出なし

ヘルスケア（医療保険の相互運用性と説明責任に関する法律［HIPAA］）、金融、EU企業（一般データ保護規制［GDPR］）

レイテンシが重要

ネットワーク依存なし、接続障害は許容されない

ロボティクス、エッジコンピューティング、車両、船舶

コストの予測可能性

固定インフラコスト vs. 将来の料金が不確実なトークンごとの価格設定

大容量かつ継続的な推論ワークロード

責任の軽減

サードパーティへのデータ露出なし、法的特権と注意義務を維持

法律事務所、政府機関

エアギャップ環境やファイアウォールで保護されたシステムにオンプレミスAIが必要な理由

エアギャップ環境やファイアウォールで保護されたシステムでは、外部のAI APIを使用できません。Jina On-Premは、外部接続なしでお客様のインフラ上で完全に実行されます。

特に機密性の高いデータを管理する組織にとって、セキュリティとプライバシーへの配慮は最重要課題です。十分なセキュリティ対策が講じられていなかったり、外国政府の要求に従う可能性があったりする外部のサードパーティに機密データをすぐに渡してしまうのであれば、その保護に投資してもほとんど意味がありません。

機密データを扱う組織の従業員は、安全なデータ処理に関するトレーニングを受けることがよくありますが、そのデータを扱っている最中にインターネット上のあらゆるページを開くことができるWebブラウザーを全員が使用している場合、このトレーニングはあまり効果的ではありません。エアギャップや非常に厳格なファイアウォールによる分離は、利用可能な最も効果的なセキュリティ対策ですが、それによってあらゆる種類の外部サービスを利用することが困難になります。

レイテンシの影響を受けやすいシステムや高可用性システム向けのオンプレミスAI

サービスとしてのソフトウェア（SaaS）やクラウドコンピューティングは、自前のコンピューターでアクセス性と信頼性の高いサービスを提供するコストと、問題を他社にアウトソーシングすることとの間の妥協案です。しかし、これらにはレイテンシの変動や障害が伴い、問題が発生した際にコントロールを完全に失うことになります。AIサービスも例外ではありません。埋め込みモデルにアクセスできないときに検索システムがオフラインになるのであれば、それはもはや優れた妥協案とは言えないかもしれません。

さらに、外部のAIに依存すると、簡単に予測や管理ができないリスクが常に伴います。政治的出来事、悪天候、または海底光ファイバーケーブルにアンカーを引っ掛ける船舶などが原因で、インターネットアクセスやネットワークのレイテンシーは予告なく悪化する可能性があります。政府機関は、AIモデルへのアクセスを突然ブロックするために輸出禁止措置を使用することがあり、実際、近年そのような事例が発生しています。AIサービスプロバイダーは、より新しいモデルへの切り替えを促すために、モデルの提供を終了することがあります。外部サービスの柔軟性と管理可能なコストは、依存に伴うリスクとのバランスを取る必要があります。

GDPR、HIPAA、データ主権のコンプライアンスに対応するオンプレミスAI

個人データを収集する組織は、管轄区域によって異なり、相反する要件が課されることもある、ますます厳格な規制の対象となります。特に、HIPAAの規則は米国の医療提供者に非常に厳格なデータ保護を課しており、またカナダ、欧州連合、および多くのアジアの管轄区域における厳格な一般データ保護法では、個人情報を扱うすべての企業に対して、安全な方法で処理を行うこと、およびそのデータの他の当事者や他の管轄区域への転送を制限することが義務付けられています。これらの規則は、外国の事業者がそれらの管轄区域内に顧客を持っている場合、その事業者に対しても義務を課すことがあります。金融機関は、多くの場合、さらに厳格な規則の対象となり、他の形態の犯罪行為に対して負うのと同様に、情報セキュリティに対しても直接的な責任を負います。

規制への準拠は、特にサードパーティのAIサービスの使用に国境を越えたデータ送信が伴う場合、それらのサービスと両立しない可能性があります。

さらに、最近の出来事が示しているように、国際的なクラウド事業者が外国政府からの圧力を受けた場合、データストアの物理的な場所を制限する規則は信頼できる保護手段とならない可能性があります。国内法が管轄区域間で抵触し、ローカルでのデータストレージと処理が義務付けられ、サードパーティサービスの利用が不可能になる場合があります。場合によっては、AIシステムを含め、プロセスのすべての部分をインハウス化することだけが唯一のソリューションとなることもあります。

サードパーティのデータ送信によるAIの法的責任リスク

データ保護法や機密データの取り扱いに関する注意義務は、通常、法的責任を伴い、時には非常に重大なものとなることがあります。サードパーティのサービス提供業者によるデータの取り扱いについて、お客様が法的責任を負う可能性があります。裁判所や法的手続きによって、安全でないサービス提供業者からある程度事後的な保護が得られる場合もありますが、そうした救済措置は、国家安全保障機関、法執行機関、あるいは犯罪的なハッカーに対しては利用できないか、一般的にも有効ではありません。

政府に関しては、国境を越えてサービスを提供するクラウドサービスプロバイダーが、機密性の高い国家情報を外国の関係者に開示した事例がすでに発生しています。

しかし、外国の政府やハッカーについて心配しておらず、外部のAIサービスプロバイダー自体が安全である場合であっても、それらが外部にあるという事実だけで法的責任が生じる可能性があります。

例えば、ほとんどの管轄区域において、弁護士とクライアントとのコミュニケーションは特別な法的保護を受けており、法律事務所がこの情報を記録または格納する際には厳格な法的責任を負います。米国では、この「弁護士・クライアント間の秘匿特権」は非常に有名で、映画やテレビ番組のプロットの中心にもなっています。しかし、その秘匿特権が失われる理由の1つとして、特権を有しない人物と情報を共有することが挙げられ、最近の動向からは、外部のAIサービスプロバイダーがそのような人物に該当する可能性があることが示唆されています。

少なくともアメリカ合衆国においては、インデキシングサービスを提供する埋め込みモデルなど、サードパーティのAIサービスをインターネットAPI経由で利用するだけでも、重大な機密保持規則に違反する可能性があります。法律事務所は、セキュリティ侵害が発生しなかったとしても、外部でホストされているソフトウェアを使用しているというだけで、訴訟を起こされたり、懲戒処分を受けたり、弁護士資格を剥奪されたりする可能性があります。

オフライン、エッジ、および物理的に隔離されたシステム向けのオンプレミスAI

コンピューターシステムが分離される理由は、セキュリティ上の理由だけではありません。例えば、移動する車両は、不可欠な機能においてインターネット接続に頼ることはできません。船舶や航空機には非常に大規模なオンボードコンピューターシステムが搭載されており、インターネット接続なしで機能する必要があるため、外部のAIサービスを使用することはできません。海洋プラットフォーム、僻地にあるリモート施設、北極や南極、グローバルネットワークへの適切な物理接続がない小さな島々にあるコンピューターサービスはすべて、必要なすべてのサービスをローカルでホストすることでメリットを得られる設備の例です。エンタープライズコンピューティングにおけるAIの役割が大きくなるにつれ、これらの制限に対処することがより重要になります。

物理システムへのAIの新たな応用（ロボティクスや、物流管理システム、さらにはスーパーマーケットのレジなどの、限られた空間内で動作する、または現実世界を対象とするその他のユースケース）は、グローバルインターネットに接続されている可能性がありますが、接続障害やレイテンシーの急増を許容することはできません。運用のためにAIシステムに依存している場合、そのAIシステムは可能な限りローカルで、信頼性が高くなければなりません。

オンプレミスAIを必要としないのは誰でしょうか？

リモートソフトウェアサービスやオフサイトAIには、確かにメリットがあります。AIモデルの実行には、寿命が短いことで知られる、高価で消費電力の大きいプロセッサーが必要になる場合があります。市場要因や外部の経済ショックにより、現在、高品質なハードウェアの入手は特に困難になっています。このような状況下では、ローカルAIの高額な資本コストを負担する代わりに、外部APIを使用してトークン単位で支払う方が理にかなっている場合があります。

外部APIは、断続的に利用するユーザーに最も適しています。AIモデルを主に分析のためのデータのバッチ処理に使用し、常時オンラインで稼働させる必要のある検索システムを実行しない場合、多額の資本を要するハードウェアやローカル環境への投資はほとんど意味がありません。

さらに、信頼性やアクセシビリティの理由からクラウドでホストされているEC Webサイトなど、データ処理がすでにクラウドベースである場合、同じクラウドインフラ内にあるAIサービスを使用する方が、独自にライセンスを取得したAIモデルを導入するよりも費用対効果が高くなる可能性があります。すでにクラウドサービスプロバイダーに依存しているため、そのAIサービスに依存してもリスクが大幅に増えることはありません。

お客様のユースケースがこの説明に当てはまる場合は、お客様のニーズに対応するため、EIS、AWS Marketplace、Google Cloud PlatformでJina AIモデルをご利用いただけます。

以下の表は、主な要素をまとめたものです。どちらが適しているかは、お客様のデータ、インフラ、使用パターンによって異なります。

要因

オンプレミスを優先

Cloud APIを優先

使用パターン

継続的または大量の推論

断続的な処理またはバッチ処理

データの機密性

規制対象、データ主権の対象、または機密

国境を越えたデータ移転や第三者への提供に関する制限なし

ネットワーク環境

エアギャップ、ファイアウォール保護、または不安定な環境

安定した常時接続のインターネット

既存のインフラ

GPUハードウェアを所有している、または調達できる

AIと同じ場所ですでにクラウドホストされている

コストモデル

固定ハードウェア + ライセンス、大規模でも予測可能

トークン単位；初期費用は低く、長期的には変動

レイテンシー許容度

なし（ロボティクス、エッジ、リアルタイム）

ネットワークの変動を許容可能

運用責任

お客様のチームがハードウェアと可用性を管理

プロバイダーがハードウェアとアップデートを管理し、お客様側で統合を管理

前出のセクションで取り上げた問題のうちお客様に該当するものを踏まえ、個別の状況やユースケースに照らして費用対効果を検討する必要があります。費用対効果分析は、時間の経過とともに変化することは間違いありません。短期的であっても、AI業界の未来やハードウェアの価格を予測することはできません。

Jina On-Premのご紹介

ローカルAIサービスを活用できるユーザー向けに、Jina AIの高性能モデルを完全に自己完結した形で導入するためのインストールスイートであるJina On-Premをご紹介します。

Jina AIのモデルは、何倍も大きな埋め込みモデルと同等の精度を誇り、計算コスト、メモリ使用量、ハードウェア要件を削減します。そのため、AIをオンプレミスで維持したい、あるいは維持する必要があるユーザーにとって最適な選択肢となります。商用ライセンスは、あらゆる規模のユースケースに対応する、拡張性がある規模に応じた価格設定のソリューションとして提供されています。

JinaオンプレミスはどのAPIスキーマをサポートしていますか？

• ローカルインストール用の依存関係一式として、あるいは数分でインストールして実行できるDockerコンテナーとして利用できます。

• Jina On-Premインストールは、外部システムを呼び出しません。

  • Hugging Face Hubやモデルレジストリへの呼び出しは行われません（HF_HUB_OFFLINE=1およびTRANSFORMERS_OFFLINE=1が組み込まれています）。

  • ライセンスサーバーはありません。

  • テレメトリまたはログのエンドポイントはありません。

• CPUとGPUの両方のハードウェアをサポートしており、GPUの自動検出に対応しています。

• 最新のjina-embeddings-v5-omniマルチモーダル埋め込みモデルおよびjina-reranker-v3を含む、全28種類のJina AIモデルが利用可能です。

• 標準的なAI APIスキーマ（Jina API、OpenAI、Cohere、Voyage AI、Gemini）経由でアクセスできます。Jina On-Premは、それらのスキーマ上に構築されたアプリケーション向けのドロップインソリューションです。

• EISで提供されるモデルのドロップイン代替として使用できます。Jina On-Premは、エアギャップ環境に導入されたElasticと直接統合されます。

Jina AIオンプレミスモデルのハードウェア要件

ハードウェア要件はJinaモデルによって異なります。以下の表は、GPUを使用する場合の最新モデルの推奨事項を示しています。NVIDIA L4 GPUを上回る性能は必要ありませんが、v5埋め込みモデルにはA100が推奨されます。当社の最新の埋め込みモデルには、現在最低8GBのVRAMが必要です。

モデル

最低VRAM

推奨GPU

jina-embeddings-v5-text-nano

2GB

T4 / L4

jina-embeddings-v5-text-small

3GB

L4 / A10G

jina-embeddings-v5-omni-small

8GB

L4 / A10G / A100

jina-reranker-v3

3GB

L4

jina-clip-v2

4GB

L4

jina-code-embeddings-1.5b

4GB

L4

ReaderLM-v2

4GB

L4

一度に複数のモデルを使用する場合、必要なVRAM容量が増大します。詳細については、サイジングとハードウェアのページをご参照ください。

DockerでJina On-Premをインストールする方法

最もすばやく利用を開始するには、（まだインストールしていない場合は）Dockerをインストールして、Jina On-Premクイックスタートページの手順に従います。

全28種類のJinaモデル向けに、あらかじめ構築されたDockerコンテナーが用意されています。1つをダウンロードしてインストール先に転送すれば、5分足らずでJina AIモデルを稼働させることができます。

マルチモーダルまたはカスタムビルドの場合、あるいはコンテナー外にインストールするために依存関係一式をダウンロードする場合は、バンドルガイドに記載されている手順に従ってください。

Jina On-Premインストールは、すべてのJina APIおよびEIS機能、ならびにOpenAI、Cohere、Voyage AI、Gemini APIを介した埋め込み生成をサポートしているため、標準的なインターフェースを使用して既存のアプリケーションに統合できます。詳細については、APIドキュメントをご参照ください。

Jina On-Premでインストールされたモデルを含むJinaモデルは、さまざまなライセンス条件で利用でき、最新モデルはCC BY-NC 4.0ライセンスの下で非商用目的に無料で利用できます。Jina On-Premを商用利用するためにライセンスを取得する場合は、Elastic営業担当までお問い合わせください。

テキスト、画像、動画、音声記録のための高性能なセマンティック埋め込みを作成し、100近い言語にまたがる分類、クラスタリング、意味的類似性の測定、検索のためのインデキシングに利用できます。データがテキストだけでなく、PDF、録音、動画といった形式でも存在する場合、それぞれに個別のパイプラインを用意する必要はなくなります。

jina-embeddings-v5-omniファミリーは画像、音声、印刷物、動画をサポートする、現在市場で最もコンパクトな埋め込みモデルです。以下を提供します。

• jina-embeddings-v5-textのフロンティアクラスのテキスト埋め込みを検索、分析、AIエージェント用途で使用。

• クラス最高の埋め込みを視覚的な意味的類似性、視覚的理解、画像検索用途で使用。jina-embeddings-v5-omni-small は、10億（10⁹）個のパラメーターを持つモデルの中で画像ベンチマークにおいて最高のパフォーマンスを発揮し、当社の以前のjina-clip-v2よりも優れています。このモデルに匹敵する性能を発揮できるのはパラメーター数が3倍から30倍もあるごく少数のモデルのみです。

• 多言語の視覚的理解および検索のための最先端の埋め込み技術で、最大20倍もの規模を持つモデルを凌駕します。

• 同サイズクラスで最高のオーディオ埋め込みであり、標準ベンチマークでより優れた性能を発揮するのは、パラメーター数が2倍以上のモデルのみです。

• 動画のサポート、特に映像内の物体やイベントを特定する機能。

これは、情報検索、文書処理、データ分析といったあらゆる分野に応用可能です。jina-embeddings-v5-omni は、異なるメディアサイロに閉じ込められた情報を開放し、AIエージェントによる検索、分析、使用を可能にします。音声・動画記録、PDF、印刷ページのスキャン画像、インフォグラフィックなどの情報は、データエコシステムにおいてデジタル化されたテキストと同等の扱いを受けます。

jina-embeddings-v5-textと同様に、これらのモデルにはsmallとnanoの2つのサイズがあります。どちらのモデルも、音声インプットと視覚インプットをサポートする追加モジュールによって、対応するテキスト版を拡張しています。ユーザーは読み込み時にモジュールを選択できます。さらに、意味的類似性、分類、クラスタリング、情報検索向けのタスク固有の拡張は、コンパクトな低ランク適応（LoRA）アダプターとして実装され、すべて読み込まれるため、ユーザーは推論時に選択できます。

どちらのモデルも非常にコンパクトです。jina-embeddings-v5-omni-small従来のGPU搭載サーバーで動作可能であり、 jina-embeddings-v5-omni-nanoは汎用ハードウェアで動作できるほど小型です。これは、計算コストの大幅な節約の可能性を示し、ライセンスされたローカルインストールとエッジ処理を可能にし、レイテンシを削減し、データの制御を強化します。

v5-omniスイートは、革新的なモデル設計と機械学習技術を用いて、以前に学習済みのモデルを再学習させることなく、新しい埋め込みモデルを構成します。既存のjina-embeddings-v5-textモデルスイートのインプット前処理器として、音声および動画メディア用の事前トレーニング済みの、言語に合わせた埋め込みモデルからエンコーダを使用しています。結果として得られるモデルは、画像や音声録音に対して、テキストに対して生成する埋め込み表現と意味的に互換性のある埋め込み表現を生成します。

v5-omniモデルは、jina-embeddings-v5-text と同一のテキスト埋め込みを生成します（つまり、jina-embeddings-v5-omni-small に jina-embeddings-v5-text-small、jina-embeddings-v5-omni-nano に jina-embeddings-v5-text-nano）。これにより、インデックスを再構築することなく、既存のテキスト検索リポジトリをマルチメディアアプリケーションに拡張できます。

内蔵エンコーダーはすべてオープンウェイトソースから派生したものです。画像と動画にはQwen3.5モデルのエンコーダーを使用しました。

• jina-embeddings-v5-omni-nanoの場合、Qwen3.5-0.8Bの微調整されたSigLIP2 Baseエンコーダーを使用します。

• jina-embeddings-v5-omni-smallには、Qwen3.5-2Bの微調整されたSigLIP2 So400mエンコーダーを使用します。

• 音声サポートのため、Qwen2.5-Omni-7Bから抽出したWhisper-large-v3のエンコーダーを、smallバージョンとnanoバージョンの両方に追加しました。

これらのメディア固有のエンコーダーを、訓練済みのクロスモーダルプロジェクターを備えたテキスト処理基盤に接続しました。これらのプロジェクターは、ネイティブ出力をjina-embeddings-v5-textと互換性のある入力埋め込みに変換します。jina-embeddings-v5-omniモデルで新たに学習された部分は、それらのプロジェクターの重みだけです。

このアーキテクチャーは、4つのLoRAアダプターのそれぞれに対して、jina-embeddings-v5-omni-small用に約550万、jina-embeddings-v5-omni-nano用に350万未満のクロスモデルプロジェクターのみをトレーニングする必要があることを意味します。このアプローチでは、異なる埋め込みモデルを接続するために必要な追加トレーニングを最小限に抑え、それぞれの専門的なトレーニングを活用することで、非常にコンパクトで高性能なモジュール式の埋め込みスイートを実現します。

選択されたモデルプロパティ

入力/出力

モデル名

入力コンテキストウィンドウのサイズ

埋め込みサイズ

jina-embeddings-v5-omni-small

32,768トークン

1024ディメンション（最小：32）

jina-embeddings-v5-omni-nano

8,192 トークン*

768次元（最小：32）

* 非テキストメディアのトークン化方法については、以下のjina-embeddings-v5-omniの使用をご覧ください。

サイズ

モデル名

合計サイズ

jina-embeddings-v5-omni-small（テキストのみの基本モデル＋4つのLoRAアダプター）

700M パラメータ

画像/動画サポート（Qwen3.5-2Bから抽出したSigLIP2 So400Mエンコーダー）

10.06億パラメーター

音声サポート（Qwen2.5-Omni-7Bから抽出したWhisper-large-v3エンコーダー）

13.54億パラメーター

両方

16.60億パラメーター

LoRAアダプター（各）

20M

jina-embeddings-v5-omni-nano（テキストのみの基本モデル＋4つのLoRAアダプター）

266M パラメータ

画像/動画サポート（Qwen3.5-0.8Bから抽出したSigLIP2ベースエンコーダー）

354M パラメータ

音声サポート（Qwen2.5-Omni-7Bから抽出したWhisper-large-v3エンコーダー）

916M パラメータ

両方

1.004B パラメータ

LoRAアダプター（各）

7M

* 非テキストメディアのトークン化方法については、以下のjina-embeddings-v5-omniの使用をご覧ください。

タスク特化型トレーニング

jina-embeddings-v5-omniファミリーはjina-embeddings-v5-textと同じタスク固有のLoRAアダプタをサポートしています。

タスク

使用例

検索

情報検索は単独または他の検索および候補評価技術と組み合わせて行われます。v5-omniモデルでは、1つのインデックスから1回のクエリで音声、動画、画像を取得できます。

クラスタリング

あらゆるメディアにおけるトピックの発見と自動的なトピック整理。

分類

分類、感情分析、関連する各種タスク。

意味的類似性

メディア全体でのデータ重複除去、レコメンデーションシステム、関連メディア、音声に一致するテキストの検索、翻訳の識別、その他の類似タスク。

出力の埋め込みは選択されたタスクカテゴリに依存します。例えば、検索指向の埋め込みをクラスタリングに、または意味的類似性の埋め込みを分類に使用すべきではありません。

マルチメディア、マルチモーダル、多言語、多機能

jina-embeddings-v5-omni で何ができるかを示すために、2つの小説の有名な冒頭部分を取り上げて、それらの意味的類似性を測定してみましょう。

二都物語（チャールズ・ディケンズ）

高慢と偏見 (ジェーン・オースティン)

意味的類似性アダプターを備えたjina-embeddings-v5-omni-smallを使用すると、これらのテキストの類似度は0.5329です。

この数値は比較対象がなければあまり意味がないので、同じモデルとアダプターを使用して、これら2つのテキストをフランス語訳と比較してみましょう。

言語間のテキストの意味的類似度スコア

『二都物語』（英語）

高慢と偏見（英語版）

二都物語（フランス語版）（Paris et Londres en 1783, tr. H. Loreau）

0.9095

0.5074

高慢と偏見（フランス語版）（Orgueil et Préjugés,tr. Leconte et Pressoir）

0.4826

0.8784

この2つのテキストは、同じ言語や別の言語の他のテキストよりも、翻訳との類似性がはるかに高いことを示しています。これは、jina-embeddings-v5-omni-smallに変更されずに含まれたjina-embeddings-v5-text-smallの非常に高性能な多言語セマンティック埋め込みを反映しています。

マルチメディアサポートをjina-embeddings-v5-omniに加えることで、この実験をまったく異なる種類のデータに拡張できるようになります。例えば、私たちは両方の小説の最初のページのスキャンを古い印刷版から入手しました。

図2： 二都物語、19世紀の年代不明版、および 高慢と偏見、1903年マクミラン版。

意味的類似性アダプターを再度使用して、両方のテキストをスキャン画像と比較してみましょう。

テキストと画像間の意味的類似度スコア

二都物語（スキャン）

高慢と偏見（スキャン）

二都物語（テキスト）

0.7336

0.4891

高慢と偏見（本文）

0.4804

0.7213

意味的類似度スコアは、画像の内容に一致するテキストを強く支持することがわかります。

同じ設定を使用して、テキストをSNSの投稿のスクリーンショットやそれらのテキストを参照するミームと比較することもできます。

図3：イーロン・マスクのツイート（ 『二都物語』に言及）と『高慢と偏見』の有名な冒頭シーンに言及したミーム。

テキストと画像間の意味的類似度スコア

二都物語

高慢と偏見

マスク氏のツイート（画像）

0.7156

0.4912

「Keep calm」ミーム（画像）

0.4555

0.6244

音声でも同じことができます。英語とフランス語の両テキストの朗読録音を入手しました。

• 二都物語 （英語音声：Librivox）

• 二都物語（フランス語音声、OmniVoice AI生成）。

• 高慢と偏見（フランス語音声、Librivox）。

• 高慢と偏見（フランス語音声、OmniVoice AI生成）。

異なる言語間のテキストと音声のセマンティック類似度スコア

『二都物語』（英語音声）

二都物語（フランス語音声）

高慢と偏見(英語音声)

高慢と偏見（フランス語音声）

『二都物語』 (英語テキスト)

0.3816

0.3106

0.1607

0.1774

二都物語（フランス語テキスト）

0.3528

0.3253

0.1598

0.1721

高慢と偏見(英語テキスト)

0.1910

0.1682

0.3511

0.3398

高慢と偏見（フランス語テキスト）

0.1667

0.1474

0.3018

0.3702

この多言語・マルチメディア能力は情報検索にも及びます。

jina-embeddings-v5-omniモデルの検索アダプターは非対称検索を実装しています。これは、クエリを埋め込む方法が検索対象のドキュメントを埋め込む方法とは異なることを意味します。そのため、クロスモーダルクエリは常に一方向にあり、クエリが一方のメディアに、ドキュメントがもう一方のメディアにあるため、逆の場合とは異なるスコアが得られます。

以下の表は、二都物語と高慢と偏見のテキスト、音声、ページスキャン画像の検索スコアを示しています。これは、二都物語（英語）のテキストがクエリとしてエンコードされた場合です。

テキストからテキスト

ドキュメント

検索スコア

二都物語（フランス語テキスト抜粋）

0.7597

高慢と偏見（英語テキスト抜粋）

0.1482

高慢と偏見（フランス語テキスト抜粋）

0.0523

テキストから画像

ドキュメント

検索スコア

二都物語（英語ページスキャン）

0.5517

二都物語（フランス語ページスキャン）

0.3576

高慢と偏見（英語ページスキャン）

0.1917

テキストから音声

ドキュメント

検索スコア

『二都物語』（英語音声）

0.3277

二都物語（フランス語音声）

0.1980

高慢と偏見(英語音声)

0.1419

高慢と偏見（フランス語音声）

0.1759

ユーザーは、クエリを逆向きに実行することもでき、音声からテキストへ、画像からテキストへの検索を行うことができます。

以下は、 二都物語の英語音声をクエリとして、さまざまなテキストをドキュメントとして使用した場合のスコアです。

画像からテキスト

ドキュメント

検索スコア

二都物語（英語テキスト抜粋）

0.3352

二都物語（フランス語テキスト抜粋）

0.2650

高慢と偏見（英語テキスト抜粋）

0.1626

高慢と偏見（フランス語テキスト抜粋）

0.1385

そして、二都物語（英語版）の1ページ目のスキャン画像をクエリとして使用した場合のスコアは以下のとおりです。

音声からテキスト

ドキュメント

検索スコア

二都物語（英語テキスト抜粋）

0.5304

二都物語（フランス語テキスト抜粋）

0.4845

高慢と偏見（英語テキスト抜粋）

0.1467

高慢と偏見（フランス語テキスト抜粋）

0.0761

動画検索

jina-embeddings-v5-omniの動画インデキシングと検索機能は、Elasticsearchデータベースに新たな機能をもたらしますが、テキストに適用される多くの同じ警告の対象となります。長編映画の単一の埋め込みを生成することは、非常に長い小説を埋め込むようなものです。詳細な情報が埋もれてしまい、結果として得られる埋め込みは、多くの非常に曖昧なクエリに適合する可能性があります。

指輪物語の全文（約50万語）を埋め込めば、探しているものが何であれ、ほとんどの検索クエリに対して適切な結果が得られる可能性が高いでしょう。同様に、2時間のハリウッド映画のインデックスを作成すると、誤ったマッチングが多く、詳細が完全に見落とされます。jina-embeddings-v5-omniは短いクリップに最適です。

この例では、1961年の映画ティファニーで朝食をの予告編をダウンロードしました。この予告編はわずか158秒で、パブリックドメインとなっています。予告編をインターネットアーカイブで見ることができます。

図4：ティファニーで朝食をの劇場ポスター。

PySceneDetectを使い、予告編を28のシーンに分割しました。長さは1.877秒（45フレーム）から18.393秒（441フレーム）までさまざまです。シーン検出は完璧ではありませんが、動画を検索しやすいように小さな断片に分割するのに十分な仕組みを提供します。次に、jina-embeddings-v5-omni-smallを使用して、28セグメントのそれぞれについてドキュメント埋め込みを生成しました。これにより、動画内の特定の要素を見つけるためのテキストクエリの有効性をテストすることができました。

例えば、「cat」を検索すると、上位3つの結果として次のクリップが返されました。猫が登場する唯一のシーンがトップで、スコアは0.1634です。

クリップ1番目をご覧ください。

次に高い一致度は0.1237で、はるかに低い値です。

クリップ2をご覧ください。

また、アクションをクエリすることもできます。「kiss」という文字列でクエリを実行すると、上位4つの一致結果にはすべてキスが含まれています。

クリップ3をご覧ください。スコアは0.2864です。

スコア：2番目のマッチ（0.2494）、3番目のマッチ（0.2099）、4番目のマッチ（0.2068）

また、「Buddy Ebsen」のように、一度しか表示されない動画に表示されているテキストを検索することもできます。jina-embeddings-v5-omni-small は0.3885というスコアで、次点の候補よりもかなり高い、最も一致する候補として容易に識別できます。

Buddy Ebsenのクリップ。

視覚的文書検索

Jina AIのマルチモーダル埋め込みモデルは、ビジュアルドキュメント処理においてトップパフォーマーであり、多言語ビジュアルドキュメント処理においては最先端です。これは、テキスト、図、構造化情報を含む画像データを扱うことを意味します。重要なデータは、印刷スキャン、PDFファイル、図、技術図面、スクリーンショット、画像、インフォグラフィックなどの形式で存在することがよくあります。これらの画像は、しばしば機械的に構成されたり、コンピューターで生成されたりします。それらは通常、意味を損なうことなくテキストに還元することはできず、自然な風景の撮影用に設計されたコンピュータビジョンモデルには適していません。

jina-embeddings-v5-omni埋め込みには、画像内の物体、それらに印刷されたテキスト、および両者の関係に関する情報が含まれます。視覚的文書検索により、物と関連テキストの両方を含むリッチ画像をインデックス化し、それを複数の言語間で行うことが可能になります。

例として、さまざまなECサイトから4つの商品画像を使ってみましょう。

では、「ラーメン」というクエリで jina-embeddings-v5-omni-small がこの4枚の画像をどれだけ評価しているか見てみましょう。

Campbell’s Chunky Chicken Noodle（カナダ版パッケージ）

Kraft Dinner（カナダ版パッケージ）

マルちゃん味噌風味生ラーメン（日本版パッケージ）

Birkelスパゲッティ（ドイツ版パッケージ）

0.0872

0.0711

0.1123

0.0886

日本の製品を一致としてすぐに見つけます。

ここで、「マカロニチーズ」（日本語のmacaroni and cheese）のクエリを試してみましょう。

Campbell’s Chunky Chicken Noodle（カナダ版パッケージ）

Kraft Dinner（カナダ版パッケージ）

マルちゃん味噌風味生ラーメン（日本版パッケージ）

Birkelスパゲッティ（ドイツ版パッケージ）

0.2207

0.3487

0.2760

0.2674

英語のクエリと同じくらい簡単に正しい一致を見つけます。

jina-embeddings-v5-omni また、チャートのような情報豊富な画像の解釈にも優れています。実際にどのように機能するかを確認するには、次の2つの棒グラフをご覧ください。

左側の図1は世界の疾病負担に関するもので、右側の図2は犬種ごとの寿命に関するものです。

検索にjina-embeddings-v5-omni-smallを使用した場合、それぞれが一方のチャートには関連するが両方のチャートには関連しない、2つの潜在的なテキスト質問がどれだけうまく一致するかを見てみましょう。

テキストの質問

チャート1

グラフ 2

「高齢者によく見られる健康問題にはどのようなものがありますか？」

0.2787

0.1099

「犬の寿命は？」

0.1350

0.3564

画像をクエリとして使用して、テキストを検索する逆のプロセスも可能です。以下の表は、関連する科学論文の要約から抽出された対象文書と、グラフ画像をクエリとして使用した場合の検索スコアを示しています。

テキスト1

テキスト 2

極度の貧困の中で暮らす人々の健康は、長年にわたり世界の開発努力の焦点となっており、持続可能な開発目標の時代においても引き続き優先事項となっています。しかし、この特定の集団における負担の規模と原因を定量化するための体系的な試みは、ほぼ20年間行われていません。私たちは、世界で最も貧しい10億人を対象に、原因別の疾病率を推定し、高所得層の疾病率と比較しました。

コンパニオンドッグは表現型が最も多様な種の一つです。品種間のばらつきは形態や行動の側面だけでなく、寿命にも及びます。この事実にもかかわらず、品種間の平均余命のばらつきを評価したり、長寿の系統的特徴の可能性を評価したりする研究はほとんど行われていません。

チャート1

0.2377

0.1357

グラフ 2

0.0673

0.3576

特徴

切り捨て可能な埋め込み

jina-embeddings-v5-omni を支える基盤jina-embeddings-v5-text モデルをマトリョーシカ表現学習でトレーニングしたので、これらのモデルからテキストとマルチメディアの埋め込みを切り捨てることができます。

デフォルトでは、 jina-embeddings-v5-omni-small 1024次元の埋め込みを生成し、16ビット精度で保存するために2KBの容量を必要とします。jina-embeddings-v5-omni-nanoの埋め込みは768次元で、約1.5KBを占めます。これらの埋め込みのサイズを32次元（64バイト）に縮小することができます。これにより、精度は若干低下しますが、処理速度は大幅に向上し、リソースコストも削減されます。一般に、埋め込みサイズを半分に減らすと、精度が約2％低下して128次元になり、それを下回ると精度がはるかに速く低下します。

切り捨て可能な埋め込みにより、ユーザーはそれぞれのユースケースに応じて、精度、速度、コストの最適なトレードオフを決定できます。

量子化

jina-embeddings-v5-omniファミリーは、 jina-embeddings-v5-text基盤から量子化に対する堅牢なパフォーマンスも継承しています。これにより、処理速度がさらに向上し、より精度の低い数値を格納することで計算とストレージのコストが削減されます。これらのモデルは Elasticsearchの Better Binary Quantization（BBQ）と連携するように訓練されており、量子化されていない埋め込みとほぼ同じ性能を提供します。Massive Text Embedding Benchmark（MTEB）の検索ベンチマークスイートでは、バイナリ化によるパフォーマンス低下は16ビットの完全な値を使用した場合と比較して3%未満にとどまり、同時に93%のスペースを節約し、処理速度と検索速度を劇的に向上させます。

言語間パフォーマンス

jina-embeddings-v5-textの広範な多言語トレーニングは jina-embeddings-v5-omni にも引き継がれ、jina-embeddings-v5-text-small の事前トレーニングでは約100の言語、jina-embeddings-v5-text-nano では15の主要なグローバル言語がサポートされています。音声メディアの場合、 Whisper-large-v3モデルはトレーニングに約100言語を使用しており、 jina-embeddings-v5-omni-smallおよび-nanoに統合されているQwen-modified SigLip2ビジョンモデルは 201種類の言語と方言のデータを使用してトレーニングされています。

ベンチマーク性能

テキスト

jina-embeddings-v5-omni テキストのみに使用する場合、これらのモデルはjina-embeddings-v5-textモデルと同一です。セマンティックテキスト埋め込みのMMTEBベンチマークスイートにおいて、それぞれのサイズカテゴリーでトップパフォーマンスを示しています。

図5：テキストベンチマークでの jina-embeddings-v5-omni のサイズとパフォーマンス、競合モデルとの比較。記載されているサイズは、他のメディアの読み込み拡張機能を含まないサイズです。

視覚的な意味的類似性

標準的な視覚的意味的類似性ベンチマークにおいて、jina-embeddings-v5-omni はそのサイズに近いモデルの中で最高のスコアを出しています。jina-embeddings-v5-omni モデルは、同等のサイズの公開オープンウェイトモデルの中で圧倒的に最良の性能を示しています。jina-embeddings-v5-omni-smallは視覚的意味的類似性タスクにおいて、その3倍のサイズのモデルにしか負けず、 jina-embeddings-v5-omni-nanoはjina-embeddings-v5-omni-smallと10～25倍のサイズのモデルにしか負けません。

図6：jina-embeddings-v5-omni-small、jina-embeddings-v5-omni-nano、および比較対象モデルの視覚的意味的類似性ベンチマーク平均スコア、ならびに視覚拡張機能を含むそれらのサイズ。

視覚的文書検索

jina-embeddings-v5-omni-small は、10億パラメーター未満でありながら、30億パラメーターおよび70億パラメーターのモデルに匹敵します。jina-embeddings-v5-omni-nanoも同様にそのサイズで際立っており、10倍から60倍も大きいモデルを凌駕しています。

図7 ：6つのベンチマーク（DocVQA、InfoVQA、ShiftProj、SynAI、Tabfquad、TatDQA）におけるViDoRe視覚文書検索の平均スコア。

音声検索

標準的なMAEB（Massive Audio Embedding Benchmark）音声検索ベンチマークにおいて、jina-embeddings-v5-omni-smallとjina-embeddings-v5-omni-nanoはどちらもトップクラスのパフォーマンスを発揮しています。非常に大きなモデルのみ – jina-embeddings-v5-omni-smallの3倍以上のサイズ – がそのスコアを上回ります。

図8：MAEB音声検索ベンチマークにおけるさまざまなモデルの平均スコア。

LAIONのlarger_clap_general モデルは、jina-embeddings-v5-omni-nanoのスコアをより少ないパラメーターで改善していますが、v5-omniスイートの追加マルチモーダル機能は何もない、音声のみのモデルです。

動画

動画では、jina-embeddings-v5-omni-smallがテキストクエリに合致する場所を見つけることに優れています。Charades-STAとMomentSeekerテストは、このタスクの標準的なベンチマークであり、下のグラフからjina-embeddings-v5-omni-smallがサイズがはるかに小さいにもかかわらず、同等のオープンウェイトモデルの中で最高のスコアを獲得していることがわかります。

図9：さまざまなモデルのサイズと、それらのモデルに対するCharades-STAスコア。

図10：さまざまなモデルのMomentSeekerスコアとそれらのサイズ。

また、 jina-embeddings-v5-omni-small ByteDanceのSeed 1.6と比較しました。Seed 1.6は、パラメータ数が非公開のクローズドウェイトモデルです。私たちのモデルは、Charades-STAベンチマークではSeed 1.6を大きくBeatsし、MomentSeekerではほぼ同等です。

モデル

Charades-STAのスコア

MomentSeekerスコア

seed-1.6-embedding

29.30

59.30

jina-embeddings-v5-omni-small

55.57

58.93

強みと制限事項

jina-embeddings-v5-omni モデルは、特に以下のようなさまざまな方法で、ユーザーがデジタル化された情報をインデックス化、検索、分析する能力を拡張します。

• テキストクエリからの多言語音声検索。

• PDF、スキャン、視覚的文書検索。

• 動画の時間的グラウンディング、つまり、自然言語のテキスト記述と一致する動画の部分を特定すること。

• 音楽ジャンルを含むオーディオジャンルの分類。

• シーン情報とオブジェクト識別に基づく画像分類。

他のいくつかの分野では、パフォーマンスはやや劣ります。jina-embeddings-v5-omni を使ってこれらの作業をすることは可能かもしれませんが、そのためのトレーニングはしていませんし、結果は芳しくないかもしれません。

当社は以下の分野における技術向上に積極的に取り組んでいます。

• 自然言語の説明から特定の動画を見つけること。

• 画像間の意味類似性と検索。

• 音声における意図の分類、例えば音声コマンドの認識など。

• 画像とそれに付随するテキスト、または音声、画像、テキストを組み合わせたものなど、複数のメディアからの入力を処理。

jina-embeddings-v5-omniの使用

このモデルスイートは、テキスト、音声、画像と動画を組み合わせた入力という3つの入力方法をサポートしています。jina-embeddings-v5-omniは、幅広い標準フォーマットを変換し、他の前処理を行うフレームワーク内で動作します。

画像処理には、最初のSigLip2リリースで提供されたNaFlex方式と同じものを使用します。入力画像が262,144ピクセル（512x512に相当）より小さい場合は、その最小値を超えるまで拡大されます。また、3,072,000ピクセルより大きい場合は、その最大値より小さくなるまで縮小されます。変換プロセスでは、画像の高さと幅の両方が14ピクセルの倍数になるように調整し、縦横比の歪みを最小限に抑えてその目標を達成します。結果は28×28ピクセルのパッチに分割されます。そのため、パッチの総数は画像を覆うために必要な28×28の正方形の数になります。推論時には各パッチは単一のトークンとして扱われ、各画像入力には単一の画像を区切るための特別な開始トークンと終了トークンが付随します。

jina-embeddings-v5-omni モデルは、画像を変更するのと同じ方法で動画の解像度を変更し（上記を参照）、動画から最大32フレームを抽出します。動画に32フレーム以上ある場合（標準フォーマットは通常1秒あたり少なくとも24フレームなので、その可能性は高い）、抽出するフレームを均等な間隔で配置します。そして、動画プリプロセッサは、2フレームごとに、動画全体をカバーするのに必要な28×28ピクセルの正方形の数に等しいトークンのセットを1つ生成します。

図11： jina-embeddings-v5-omniは動画から等間隔の32フレームを抽出します。長い動画だと多くの部分が失われてしまいます。

動画の前処理の詳細については、 SigLip2の技術文書をご覧ください。

音声トークン化は、Qwen-2.5-Omniに組み込まれているアプローチに従います。音声ファイルは30秒ごとに分割され、30秒を超える場合は16kHzにリサンプリングされ、128チャンネルのメルスペクトログラムに変換されます。各40ミリ秒が単一のトークンとして扱われます。そのため、30秒のセグメントごとに750トークンが処理されます。これは1トークンが40ミリ秒の音声に相当し、さらに1サンプルを区切るための特別な開始トークンと終了トークンが追加されます。

音声前処理の詳細については、Qwen-2.5-Omni Technical Reportをご覧ください。

可用性

jina-embeddings-v5-omni-smallとjina-embeddings-v5-omni-nanoは、Elastic Inference Service（EIS）上で、Jina APIを通じて利用可能であり、ローカルインストールはダウンロード（smallおよびnano）で利用可能です。モデルの重み付けデータは、非商用ライセンスで試用できるよう無料で配布されています。商用利用についてはElasticの営業担当までお問い合わせください。

はじめに

テキストにjina-embeddings-v5-omniを使用するには、 jina-embeddings-v5-textの場合と同様にsemantic_textフィールドを使用して統合できます。inference_id .jina-embeddings-v5-omni-smallまたは.jina-embeddings-v5-omni-nanoに設定するだけです。手順については リファレンスガイド をご覧ください。

他のメディアをjina-embeddings-v5-omniで埋め込むには、推論APIを使用する必要があります。例：

jina-embeddings-v5-omni-nanoの場合、POST URIを_inference/embedding/.jina-embeddings-v5-omni-nanoに変更してください。

他のメディアのドキュメントをエンコードしたり、分類やクラスタリングのための埋め込みを生成したりするには、推論エンドポイントをjinaaiサービスで作成してください。

クエリの場合は、以下の例のようにクエリビルダーを使います。inference_idの値を.jina-embeddings-v5-omni-nanoに置き換えて、smallの代わりにnanoモデルを使用してください。

詳細については、クエリビルダーのドキュメントを参照してください。

jina-embeddings-v5-omniでBBQを使用するには、BBQインデキシングの説明に従います。

詳細情報

jina-embeddings-v5-omniの詳細については、モデルの技術レポートおよびJina AI Webサイトのページをご覧ください。Hugging Faceのjina-embeddings-v5-omni コレクションページには、これらのモデルをローカルでダウンロードして実行するための技術情報と手順も含まれています。jina-embeddings-v5-omniモデルはCC-BY-NC-4.0ライセンスの下でダウンロードでき、自由に試用できますが、商用利用の場合はElasticの営業担当までお問い合わせください。

この統合により、Elasticsearchユーザーは、データをセキュリティ境界内に保持し、予測可能なインフラストラクチャコストを実現し、Google Cloud上でネイティブに動作する、新たなデプロイメントオプションを利用できるようになります。同時に、より広範なGoogle Cloudエコシステムで、Jinaが専用に構築した最先端の検索および取得モデルを利用できるようになります。

これは、より広範な展開の第一段階です。次に登場するモデルと合わせると、このラインナップは完全な検索スタックを形成します。データの埋め込み、クエリの埋め込み、候補の検索と再ランク付け、マルチモーダル埋め込みによる画像への検索拡張など、すべてお客様が管理するインフラストラクチャー上で実現します。jina-embeddings-v3の利用は今日から開始できます。このモデルはすでにElastic Inference Service（EIS）を介してElasticsearchエコシステム全体の本番検索パイプラインを支えています。

モデル

タイプ

パラメーター

主要な機能

Model Garden上のステータス

`jina-embeddings-v3`

テキスト埋め込み

572M

実績のある多言語対応の主力モデル、8,000コンテキスト、1024次元の出力、32次元まで切り捨て可能

提供中

「jina-embeddings-v5-text-small」

テキスト埋め込み

677M

最先端のサブ1B多言語モデル、32,000コンテキスト、1024次元の出力、32次元まで切り捨て可能

まもなくリリース

`jina-embeddings-v5-text-nano`

テキスト埋め込み

2億3900万

クラス最高、5億パラメーター、8,000コンテキスト、768次元の出力、32次元まで切り捨て可能

まもなくリリース

`jina-reranker-v3`

リランカー

600M

リスト別リランキング、131,000コンテキスト、最大64件の文書

まもなくリリース

`jina-clip-v2`

マルチモーダル埋め込み

900M

共有スペースのテキスト+画像、89言語、8Kのテキストコンテキスト、512×512の画像

まもなくリリース

すべてのモデルは、Google Cloudで最もコスト効率の高いGPUティアである単一のNVIDIA L4（24 GB）で動作します。Google Cloud Model Gardenの他のほとんどの埋め込みモデルではA100 80 GBまたはH100が必要となり、トークンを計算する前から、インスタンスの1時間あたりのコストのおよそ3倍の費用がかかります。

Vertex AIを介してデプロイする場合、追加の商用ライセンスは必要ありません。

Model Gardenを使用する理由とは？

APIを利用するのではなく、Model Garden経由でデプロイする理由はコントロール、コスト、コンテキストの3点にあります。

データが外部に出ることは決してなし

多くの開発者にとっての最大の魅力は、セルフデプロイアーキテクチャーです。Model Gardenを通じてJinaモデルをデプロイすると、Google CloudプロジェクトとVPC内のGPUインスタンス上で加重が実行されます。これは、金融や医療など、データセキュリティに関する懸念を抱える業界で働くすべての人にとって、状況を一変させるものとなるでしょう。外部API呼び出しがないため、機密データはセキュリティ境界内に留まります。

予測によるスケーリング

文章を埋め込んだり、ドキュメントのランキングを変更したりするたびに料金を支払うのではなく、時間単位の固定料金を支払うことになります。また、Jinaのすべてのモデルは、Google Cloudで最も手頃なGPUティアである単一のNVIDIA L4で実行できるため、参入障壁は低いです。1,000件のリクエストを処理する場合でも、10億件を処理する場合でも、インフラストラクチャーの費用は予測可能なままです。これは、トラフィックの増加に対して課金するのではなく、むしろトラフィックの増加に対して報酬を提供する仕組みです。

すべてを一箇所で提供します

データがすでにGoogle Cloud、BigQuery、またはCloud Storage上のElasticsearchに保存されている場合は、推論エンジンをその近くに配置しておくのが理にかなっています。Model Gardenを通じてデプロイすることで、Jinaの検索基盤モデルは、アクセス制御のためのIDとアクセス管理（IAM）、既存のGoogle Cloud請求書での統一された請求、機械学習オペレーション（MLOps）ワークフローのためのVertex AIパイプラインに接続する機能など、すでに使用しているすべてのエンタープライズ機能を継承します。

Jina AI Cloud APIとElastic Cloudはトラフィックの急増や既存の検索ワークフローに対応する最速の手段を提供する一方、Model Gardenは、厳格なデータセキュリティと大規模な運用における予測可能なコストを必要とするエンタープライズアプリケーションに最適です。Elasticは、お客様の現状に合わせてサービスを提供したいと考えています。

Jina AIモデル

jina-embeddings-v3

5億7200万個のパラメーターと8000個のトークンコンテキストを備えた、実績のある多言語埋め込みモデル。Massive Text Embedding Benchmark（MTEB）英語で65.5点を獲得しました。5つのタスク固有の低ランク適応（LoRA）アダプター（検索クエリ/パッセージ、テキストマッチング、分類、クラスタリング）と、1024次元から64次元へのマトリョーシカ切り捨てをサポートします。すでにEISを通じてElasticsearchエコシステム全体で広く採用されています。

多くの本番システムが既にv3に依存しているため、当社はいち早くv3を導入しています。v3ベースのパイプラインをGoogle Cloudに移行する場合、埋め込みの次元を変更したり、インデックスを再作成したりすることなく、同じモデルをネイティブに実行できるようになりました。

jina-embeddings-v5-text（smallおよびnano）

2026年2月にリリースされた当社の第5世代テキスト埋め込みモデルは、数倍の規模のモデルに匹敵する最高レベルの性能を実現しています。

v5-text-small （677M）は、9つのタスクタイプの131個のタスクを含むMultilingual MTEB（MMTEB）ベンチマークスイートで67.0点、MTEB英語ベンチマークで71.7点を獲得しています。これは、MTEBリーダーボード上で、10億未満の言語を対象とした多言語埋め込みモデルの中で最も強力なモデルです。

v5-text-nano （239M）はMMTEBで65.5点を獲得しています。5億パラメータ以下の他のモデルでこのレベルに達するものはありません。ほとんどの同等モデルの半分以下のサイズであるため、エッジ環境やレイテンシに敏感な導入環境にとって最適な選択肢となります。

両モデルとも以下をサポートしています。

• 4つのタスク特化型LoRAアダプター：検索、テキストマッチング、分類、クラスタリング。推論時にtaskパラメーターを介して適切なアダプターを選択します。

• マトリョーシカ次元切り捨て：埋め込み次元を1024（nanoの場合は768）から32に削減します。中程度の切り捨て（例えば256次元）では、品質の低下は最小限に抑えられます。次元を半分にすると、ストレージはおよそ半分になります。

• バイナリ量子化：1024次元の埋め込みデータをバイナリ化によって2KBから128バイトに圧縮します。特別な訓練により、この圧縮による損失は最小限に抑えられます。

• 多言語対応：119言語（小型版）と93言語（ナノ版）。

jina-reranker-v3

最後ではあるが遅くない相互作用アーキテクチャーを使用して構築された、0.6Bパラメーターの多言語リスト別再ランカー。クエリと最大64件の候補一致が、131,000トークンの単一のコンテキストウィンドウに入力され、モデルはスコアリングを行う前に文書間の比較を実行します。Jina Reranker v3はBEIRで61.94 nDCG@10を達成し、サイズが6倍小さいモデルを凌駕しています。これは、各文書を個別にスコアリングするポイント別型リランカーとは根本的に異なり、特に単一文書からのパッセージ検索でより良い結果をもたらします。

jina-clip-v2

テキストと画像を共通の1024次元空間にマッピングする、0.9Bのマルチモーダル、多言語埋め込みモデル。以下をサポートします。

• テキスト画像検索に対応する89の言語。

• 512×512の画像解像度。

• 8,000トークンのテキストインプット。

• 両方のモダリティにおいて、マトリョーシカ法による1024から64への次元削減を行います。

画像からテキストへのベンチマーク、特に多言語タスクにおける高い競争力。

はじめに

Jina Embeddings v3が本日、Model Gardenで利用可能になりました。実行する方法を説明します。

Vertex AI APIが有効で、少なくとも1つのg2-standard-8インスタンス（NVIDIA L4）に十分なGPU割り当てがあるGoogle Cloudプロジェクトが必要です。Google Cloudを初めて利用する場合はまずセットアップガイドをご覧ください。

Jina Embeddings v3のModel Gardenページでは、モデルのアップロード、エンドポイントの作成、マシンタイプの選択、デプロイといった一連の流れを詳しく説明しています。自分のプロジェクトでファイルを開き、表示される手順に従ってください。地域や割り当て量によっては、A100およびH100マシンも利用可能ですが、まずはL4で十分です。

クリックから最初の埋め込みまで、すべてのプロセスは数分で完了します。

今後の対応

Jina embeddings v3は出発点です。今後数週間以内に、Jinaの検索スタックの残りの部分、すなわちv5テキスト埋め込み（smallとnano）、jina-reranker-v3、マルチモーダル検索用のjina-clip-v2をModel Gardenに導入する予定です。すべては、同じセルフデプロイモデルで単一のL4 GPU上で実行されます。

組織は大量のドキュメントコレクション（サポートチケット、法的書類、ニュースフィード、研究論文など）を蓄積しており、適切な質問をする前にその内容を理解する必要があります。ラベルやトレーニングデータがなければ、何千もの文書を手動で確認するのは非現実的です。何を検索すればいいかわからない場合、従来の検索は役に立ちません。

この投稿では、この検索の問題に対処するElasticsearchネイティブのアプローチによる教師なし文書クラスタリングと時間軸に沿ったストーリー追跡について説明します。最終的には、次のようにストーリーの文脈を日々にわたってたどることができるようになります。

読み取れる内容：

• なぜクラスタリング埋め込み（検索埋め込みではない）が、クエリーなしでトピック発見を行いたい場合に重要なのか。

• Elasticsearchのk-nearest-neighbor（kNN）とバッチ処理msearch を使用したトピックにより、密度探査型重心分類で文書をグループ化する方法。

• significant_text がクラスターに自動ラベルを付けることで、モデルをトレーニングしなくてもテーマを読めるようにする方法。

• テーマが日々どのように変化するかを示す上で、時間軸に沿ったストーリーチェーンが日々のクラスターをどのように結び付けるのか。

このパイプラインでは、2025年2月のBBCニュースとガーディアンの記事を約8,500件、テストコーパスとして使用しています。ニュースは明確な時間的推移を示すため便利ですが、このパターンは文書の発見が重要なあらゆる場面に適用されます：法的レビュー、コンプライアンスの監視、研究の統合、カスタマーサポートのトリアージ。

スタック：

• Jina v5のクラスタリング埋め込み：トピックグループ化のためのタスク固有の低ランク適応（LoRA）アダプター。JinaはElasticに統合され、そのモデルはElastic Inference Service（EIS）を通じてネイティブで利用可能です。

• Elasticsearch：拡張性のあるkNN、significant_textラベリング、ベクトルストレージ。

• DiskBBQ：ディスクベースのベクトルインデックス形式で、 Better Binary Quantization（BBQ）と階層的なk-平均法による分割を組み合わせ、近似最近近接傍（ANN）加速を実現します。このインデックス分割はベクトル探索の内部で行われ、本投稿で用いる密度探査型クラスタリング・アルゴリズムとは別です。bbq_diskはディスクに量子化されたベクトルを格納し、ヒープにはパーティションメタデータのみを保持することで、bbq_hnswと比較してリソース要件を大幅に削減しながら、高い再現率を維持します。

• グローバルクラスタリング + 日々の時間軸に沿ったリンク付け：発見とストーリーの進化。

以下が必要です：

• Elasticsearchの導入（Elastic Cloud、Elasticsearchサーバーレス、またはElastic Self-Managed 8.18+/9.0+）：bbq_disk 8.18以降が必要です。オプションのdiversify retrieverセクションは9.3+またはサーバーレスが必要です。

• Jina APIキー：無料プランには1000万トークンが含まれており、これはコアクラスタリング・パイプライン（約425万トークン）をカバーします。オプションの検索対クラスタリング比較は、2番目の埋め込みパスを使用します。

• Guardian APIキー（無料）。

セットアップ

必要なパッケージをインストールしてください：

オプション（このリポジトリからスクレイピングヘルパーを実行する場合のみ）：

次に、プロジェクトのルートにある.envファイルでAPIキーを設定します。

このノートブックは load_dotenv(override=True)を呼び出し、局所的な .env 値が優先されます。

パート1：ディスカバリークラスタリング - なぜ埋め込みをクラスタリングするのか？

ほとんどのベクター検索は、クエリを関連文書に一致させるようにトレーニングされた検索埋め込みを使用します 。これは検索には最適ですが、発見には適していません。まったくクエリーせずにコーパスに存在するトピックを見つけたい場合は、類似した文書をグループ化する埋め込みが必要です。

Jina v5では、タスク固有の低ランク適応（LoRA）アダプタを使用してこの問題を解決します。LoRAは、ほとんどのベースモデルの重みを凍結したまま、ターゲットとなる内部層に小さな低ランクの更新を加えるため、完全な再トレーニングを行うことなく、モデルの挙動が特定のタスクにシフトします。同じベースモデルでも、taskパラメータによって異なる埋め込みが生成されます。

タスク

訓練の目的

ユースケース

retrieval.passage

クエリーと文書のマッチング

Search、Retrieval-Augmented Generation（RAG）

クラスタリング

トピックのグループ化（密度が高いクラスタリングの最適化）

発見、分類

クラスタリング・アダプターは、同じトピックに関する文書を埋め込み空間で近づけ、異なるトピックに関する文書を離すように訓練されています。下のビジュアル比較で、その違いが具体的にわかります。

検索とクラスタリング：視覚的な比較

違いを確認するために、両方のタスクタイプを含むサンプル文書を埋め込んでいます。クラスタリングは元の1024次元の埋め込み空間で実行されます。均一多様体近似と射影（UMAP）は、可視化のためそれらの埋め込みを2Dに投影する目的でのみ使用されます。東映UMAPは局所的な近傍構造を保持するため、クラスターの分離を比較する上で有用です。

以下では、同じ480件の文書のサンプルが両方のタスクタイプに埋め込まれ、UMAPで2Dに投影されています。クラスタリングパネルで、より密集していて、分離された色群を探します。

検索埋め込み（左）はトピックを広く分散させます。クラスタリング埋め込み（右）は、同じドキュメントからより緊密で分離されたグループを生成します。

クラスタリング埋め込みは、より緊密で視覚的に際立ったグループを生み出します。検索用の埋め込みはトピックをより均等に分散させ、（きめの細かい類似性で）検索する上で理想的です。しかし、発見のためには、緊密なトピッククラスターが重要です。

このため、このチュートリアルの残りの部分では task="clustering" が使用されています。

データセットの読み込み

次のコーパスは、2025年2月の2つのニュースソースを組み合わせています。

• RealTimeData/bbc_news_alltime HuggingFaceデータセット経由のBBCニュース。

• Guardian Open Platform API経由のThe Guardian。

複数のソースがあると、クラスタリングがトピックではなくソース固有のスタイルを見つけることを検証するのに役立ちます。

クラスタリングタスクによる埋め込み

Jina v5 APIはすべての文書に対してtask="clustering"で呼び出されます。埋め込みはディスクにキャッシュされるため、その後の実行ではAPIを完全にスキップします。

API呼び出しはシンプルです。taskパラメータが、典型的な埋め込み使用との主な違いです。

以下のタイミングはキャッシュヒットを反映しています。APIに対する最初の実行は、コーパスサイズによって時間がかかります。

単一のElasticsearchインデックスへのインデキシング

発見クラスタリングでは、1か月間を1つのインデックス（docs-clustering-all）にまとめます。日々の分割は、時間軸に沿ったストーリーリンクのために後から行われます。

インデックスマッピングでは、ベクトルフィールドにbbq_diskを使用します。

1024次元のfloat32ベクトルは4KBです。bbq_disk は階層的k-means法を使用してベクトルを小さなクラスターに分割し、それらをバイナリ量子化し、再スコアリングのためにフルプレシジョンのベクトルをディスクに格納します。パーティションのメタデータのみがヒープに存在し、そのため大規模なコーパスでもメモリ要件は低く抑えられます。より多くのヒープを許容できるワークロードの場合、bbq_hnsw は、より高いリソースコストでより高速な検索を行うための階層的ナビゲーシブル・スモールワールド（HNSW）グラフを構築します。

dense_vectorフィールドタイプは複数の量子化戦略をサポートしています：bbq_diskとbbq_hnswは、ここで使用されている1024次元ベクトルのような高次元埋め込みに最適です。

クラスタリング：密度探査型重心分類

HDBSCANのような従来型のクラスタリングアルゴリズムでは、完全なn×dベクトル行列をメモリに保持し、フルパス更新を繰り返し実行できることを前提としています。8,495件のドキュメントを1024次元で扱う場合、処理可能（最大35MB）ではあるものの、このアプローチは追加のインフラストラクチャーなしでは数百万の文書にスケールすることはできません。

このアルゴリズムは、ボロノイ領域への割り当て割り当てとノイズフロアによるKMeans++法の初期化と概念的には似ていますが、ElasticsearchのkNN検索を計算プリミティブとして使用し、ほぼ全ての作業をサーバー側で行います。

1. 文書の5%を密度プローブとしてサンプリングします（ランダムサンプル、最低50件）。

2. バッチ処理された　msearch　kNNによるプローブ密度。各プローブはkNNクエリを実行し、隣接プローブの平均類似度を記録します。平均類似度が高い＝埋め込み空間の密な領域。msearch は単一のHTTPコールで複数の検索リクエストを送信し、これは重要です。密度プローブは数百のkNNクエリを生成し、それらをバッチ処理することでリクエストごとのオーバーヘッドを回避します。

3. 多様性を考慮した高密度シードの選択：中央値以上の密度を持つ候補は、密度の降順でソートされ、既存のすべてのシードとのコサイン類似度が分離閾値を下回る場合にのみ貪欲に受け入れられます。これがクライアント側での唯一の計算です（8,000件の文書で最大0.01秒）。

4. msearch kNNで全ての書類を重心に照らして分類します。各シードが重心として機能し、kNN検索は類似度しきい値を超える近接文書を取得します。各文書は、最も高いスコアを返した重心に割り当てられます。小さなクラスターはノイズとして処理されます。

Elasticsearchが面倒な処理を担当します：msearchは密度プローブ、msearchは分類、significant_textはラベル付けを担います。このコーパス（8,495件の文書）では、5％の密度プローブサンプルが425件のkNNプローブクエリを開始し、msearchが9つのHTTPコール（バッチサイズ50）にバッチ処理され、プローブごとに1つのリクエストを処理することによるオーバーヘッドを回避します。bbq_diskANNルックアップと組み合わせることで、クラスタリング段階を高速かつスケーラブルに保つことができます。kNNクエリは、クラスタリングパス中の速度のために最小のnum_candidates値を使用します。本番環境の検索クエリでは、レイテンシを犠牲にしてリコールを向上させるために、より高いnum_candidates値を使用する必要があります。

クラスターは各重心の周りの埋め込み空間の密度によって決定される実際的なサイズを持ち、厳格なkの上限によって決定されるものではありません。密なトピック領域はより大きなクラスターを生み出し、ニッチなトピックは小さなクラスターを生み出します。

KMeansやHDBSCANが実用的ではない理由

KMeans法は球状クラスターを想定しており、メモリに完全なn×d行列が必要です。メモリに収まるコーパスの場合、HDBSCANは強力な代替手段です。任意のクラスタ形状に対応でき、密度に関するセマンティクスも十分に理解されています。

密度探査型重心アプローチは、異なるニッチをターゲットとしています。ストレージ、検索、およびクラスタリングを1つのシステムで行いたい場合や、スケールがクライアント側の行列操作を実用的でなくするようなコーパスです。これは、Elasticsearch kNNを計算プリミティブとして使用し、任意のクラスターサイズを処理し、ほぼすべての計算をサーバー側で行います。

ノイズレートについて理解する

最大28%のノイズ率は設計によるもので、故障モードではありません。設定されたsimilarity_thresholdでどの高密度クラスターにも適合しない文書は、一致率が低いと強制的に判断されるのではなく、割り当てられずに残されます。これは品質ゲートの役割を果たします：意見を記したコラム、短い記事、そして一回限りのストーリーは、一貫したグループを定義する主題の密度が不足しているため、クラスタリングに抵抗する性質があります。

しきい値は調整可能です。similarity_thresholdを下げると、より積極的なクラスタリングが生成されます（より多くの文書が割り当てられますが、クラスターは緩くなります）。一方、これを上げると、クラスターが引き締まり、ノイズの割合が増加します。こうした様々なニュースコンテンツを含むコーパスにおいては、約30％のノイズは妥当な動作基点と言えます。本番環境での導入は、分野固有の品質基準に合わせてしきい値を調整することが推奨されます。

significant_textを使用した自動ラベル付け

各クラスターには人間が読みやすいラベルが必要です。Elasticsearchのsignificant_textアグリゲーションは、フォアグラウンドセット（クラスター）とバックグラウンドセット（完全なコーパス）を比較して、異常に頻繁に現れる用語を見つけます。

内部的には、絶対頻度の変動と相対頻度の変動のバランスを取る統計的ヒューリスティック（デフォルトではJLHスコア）を使用しており、機械学習や大規模言語モデル（LLM）の呼び出しは行っていません。英国の政治に関するクラスターでは、starmer、labour、downingのような用語が浮かび上がる可能性があります。これらの用語は、全体的なニュースコーパスと比較して、そのクラスターで不釣り合いに頻出しているためです。

このグローバルパスでは、ラベルはdocs-clustering-allに対して直接計算されるため、前景と背景の両方が月全体のデータから描画されます。パート2では、ラベル付けに日次インデックスパターン（docs-clustering-*）を使用します。これは、クエリで一致するすべてのインデックスを同時に対象にできるワイルドカードで、significant_textにより広い背景を与えてコントラストを高めます。

最小クエリー形状は次のようになります。

significant_text また、品質ゲートの役割も果たします。有意な用語を生成しないクラスターには、特徴的な語彙がありません。これらはまとまりのないグループであり、誤解を招くようなラベルを付けるのではなく、ノイズとして分解する必要があります。

軽量で決定論的なクリーンアップステップで、ノイズの多いラベルの用語（数値トークン、一般的な単語）を削除し、必要に応じて代表的な見出しに切り替えます。これにより、ラベルをElasticsearchネイティブのまま維持しつつ、可読性を向上させます。

クラスターの可視化

以下の可視化は、グローバルクラスタリングパスが発見した内容を示しています：クラスター化された文書とノイズ文書の日付ごとの内訳、全月のUMAP投影、およびクラスターがソースではなくトピックを反映していることを確認するソースミックスチャート。

2025年2月におけるクラスター化された文書とノイズ文書の日次分布。

UMAPの色のついた島はそれぞれがクラスターを表しています。クラスターは、純粋に類似性を埋め込むことで発見された、同じトピックに関する記事の集合です。灰色のノイズポイントは、いずれのクラスターにもきれいに収まらなかった記事（多くの場合、短い記事、意見記事、または一回限りのストーリー）です。

情報源の内訳図を見ると、各クラスターにはBBCニュースとガーディアンの両方からの記事が含まれていることが確認できます。クラスタリングは、ソースではなくトピックを見つけ出すものであり、まさに教師なし学習から期待される結果です。

Diversify Retrieverによるクラスター幅の調査

通常のkNNは、クラスターの重心（密なコア）に最も類似した文書を返します。しかし、実際のクラスターはサブトピックも対象にします。The Diversify Retrieverは、Maximal Marginal Relevance（MMR） を使用して、重心に関連するだけでなく、互いに異なる文書を抽出します。

鍵となるパラメータは λ（ラムダ）です。

• λ = 1.0 → 純粋な関連性（通常のkNNと同じ）。

• λ = 0.0 → 純粋多様性（最大限に分散された結果）。

• λ = 0.5 → バランスが取れている：トピックに関連しているが、異なる角度をカバーしている。

最小Retrieverリクエストの形状は次のようになります。

type、field、および query_vector パラメーターは、diversifyレベルで必要です。field はMMRに結果間の類似性に使用する dense_vector フィールドを指示し、query_vector は関連性スコアリングの参照点を提供します。

これにより、単に「その中心は何か？」という問いではなく、「このクラスターは実際に何を対象としているのか？」という問いに答えることができます。

プレーンなkNNは、トピックの1つの角度、つまり中心点および互いに最も類似したドキュメントの周りにクラスターを形成します。Diversify Retrieverは、同じクラスターの異なるファセット、つまりサブトピック、異なるソース、多様な視点を提示します。

多様性指標はこれを定量的に裏付けます。Diversify Retrieverの結果では、平均ペアワイズ類似度が低く、これは返された文書がより広範囲をカバーしていることを意味します。

これは以下の用途に役立ちます。

• クラスターが実際に対象としている内容を理解。その中心だけでなく端も含め理解します。

• 要約の生成。多様で代表的な文書は、LLMにより良い材料を提供します。

• 人によるレビューや下流工程でのラベリングのために、代表的な例を発見。

• 品質チェック。多様な結果が一貫性に欠けている場合、クラスターの分割が必要かもしれません。

パート2：時間軸に沿ったストーリーチェーン

日をまたいだデータストーリーの追跡

パート1では、トピック発見のために1か月全体をグローバルにクラスタリングしました。時間軸に沿ったフローでは、同じ密度プローブの重心分類が日次インデックスごとに1日単位で独立して実行され、その後、クラスターが隣接する日々にわたってリンクされます。注意：日々のクラスターはパート1のグローバルクラスターとは独立しており、それぞれの1日はその日のコンテンツに合わせて独自のクラスター割り当てとラベルを生成します。

関連付けの手法：サンプルとクエリ

A日目の各クラスターについて：

1. いくつかの代表的な文書をサンプルとして選択します。

2. kNNをB日目のインデックスに対して実行します。

3. B日目のクラスターごとにヒット数を数えます。

4. ヒット率がしきい値（kNNの割合≥ 0.4）を超える場合は、リンクを記録します。

この処理は高速で（クラスターごとにわずかなドキュメントのみがクエリされ、すべてではありません）、ElasticsearchのネイティブkNNを使用し、外部ツールは必要ありません。

kNN分数が100％ということは、ソースクラスターからサンプリングされたすべてのドキュメントが同じターゲットクラスターに到達していることを意味し、これは異なる日付間のリンクが理論上最も強くなります。ほとんどの上のリンクはフットボール関連で、これは理にかなっています。プレミアリーグは毎日報道され、高いトピックの一貫性があります。

The score | operator | gedling → league | striker | season リンクは、ニッチなローカルフットボールクラスター（Gedling はノンリーグクラブです）が翌日に広範なプレミアリーグクラスターに吸収される例であり、これは異なる粒度での日々の再クラスタリングの自然な効果です。

ストーリーチェーンの構築

ストーリーチェーンとは、連日にわたって連続した一連のクラスターです。

個々のペアワイズリンクは、月曜日の「UK politics」クラスターが火曜日のクラスターにリンクしていることを示しています。チェーンはストーリー全体を明らかにします。月曜日に始まり、週を通して展開し、金曜日までに消えていくストーリーです。

チェーンは、kNN分数が0.4以上のリンクから貪欲に構築されます。これは、ソースクラスターからサンプリングされたドキュメントの少なくとも40％が単一のターゲットクラスターに到達したことを意味します。最も古いクラスターから開始し、アルゴリズムは常に最も強い発信リンクを追跡します。

最も長いチェーンは、ウクライナとロシアに関する報道を19日間連続で追跡していますが、2025年2月の地政学的な緊張が持続していることを考えると、これは驚くべきことではありません。2番目に長いチェーンは、19日間にわたるプレミアリーグのサッカーを追跡するものです。より短いチェーンは、映画賞シーズン（6日間）、シックス・ネーションズラグビー（10日間）、英国の政治指導者に関する報道（7日間）を追跡しています。それぞれのチェーンは、アルゴリズムが日々のインデックス全体にわたる埋め込み類似性のみから発見したストーリー展開を表しています。

サンキー：ストーリーの流れを可視化する

サンキーダイアグラムは、リンクの幅がつながりの強さを表す流れの可視化です。ここでは、各垂直バンドが1日を表し、各ノードは日々のクラスター（ドキュメント数によってサイズが決まる）であり、各色のパスは時間の経過に沿って1つのストーリーチェーンを追跡します。リンク幅はkNNのオーバーラップ強度をエンコードします。リンクが太いほど、サンプリングされたドキュメントの数がより多くターゲットクラスターに到達したことになります。色はチェーンごとに分かれているので、左から右へ流れる1つのカラーパスで1つのストーリーの進行がわかります。

たとえば、ウクライナとロシアのチェーン（比較的長い経路の一つとして示されている）は、2月初旬から第3週まで途切れることなく続いており、一貫して太い線で結ばれていることから、日々の話題の連続性が強いことがわかります。

2025年2月に流れる時間軸に沿ったストーリーチェーン各色のパスは、複数日にわたって続くストーリーを表し、リンクの幅はkNNの重なりの強さを示します。

このアプローチがもたらすメリット

このウォークスルーでは、Elasticsearch上に構築された完全な教師なしドキュメントクラスタリング・パイプラインについて説明しました。

1. クラスタリング埋め込み：Jina v5のタスク固有のアダプターは、トピックのグループ化に最適化された埋め込みを生成し、単なるクエリと文書のマッチングだけではありません。

2. グローバルな発見クラスタリング：1つのインデックスで1か月間をクラスタリングすることで、日をまたいだトピックの発見を最大化します。

3. 密度プローブによる重心分類：5％をサンプリングし、msearch kNNを介して密度をプローブし、多様な高密度シードを選択し、すべての文書を重心に対して分類します。Elasticsearchは負荷の高い計算を処理します。シード選択のみがクライアント側で実行されます（最大0.01秒）。

4. significant_textラベリング：有意性テストは、MLモデルや手動アノテーションなしで意味のあるクラスタラベルを生成します。有意な項を生み出さないクラスタは非整合となり、ノイズに格下げされます。これは内蔵された品質ゲートです。

5. 時間軸に沿ったストーリーのリンク付け：日次インデックスとサンプルおよびクエリのクロスインデックスkNNは、ストーリーが時間とともにどのように進化するかを追跡します。

重要なポイント

• 埋め込みタスクの種類が重要です。クラスタリング埋め込みは、測定可能かつより緊密な話題のグループを生成します。

• Elasticsearchはストレージ層およびクラスタリングエンジンの両方としてkNN検索を通じて機能します。

• 密度探査型重心分類は、ほぼすべての計算をサーバー側で行い、埋め込み空間の密度によって決定される合理的なサイズのクラスターを生成します。

• significant_text 高速で解釈可能で、自動ラベリングと品質管理の両方に効果的です。

このアプローチは、以下の場合に有用です。

• タイムスタンプ付きのテキストがあり、ラベル付きトレーニングデータを使用せずにトピックを発見したい場合があります。

• ストレージ、ベクトル検索、ラベル付け、および時間軸に沿ったリンク付けのために、1つのスタックが必要な場合があります。

検討すべき拡張機能：

• 複数期間クラスタリング（週間、月間集計）。

• リアルタイムのインジェストと段階的なクラスター割り当て。

• LLM生成のクラスタサマリーは、significant_text項をシードとして用います。

• より大規模なスケールでは、サンプリングされたKMeansの重心が密度ベースのクラスタリングのウォームスタートシードとして機能し、探査フェーズのコストを削減できます。

はじめましょう

タイムスタンプ付きの文書コーパスを差し替えます。日付のあるテキストのコレクションであれば、このパイプラインで利用可能です。完全なノートブックとサポートコードは、付属レポジトリで入手できます。

• Elastic Cloudの無料トライアルを開始：bbq_diskサポート付きのマネージドクラスターを数分でご利用いただけます。

• Elasticsearch Serverlessをお試しください：クラスターの管理は不要で、自動的にスケールし、このウォークスルーのすべてをサポートします。

このファミリーには2つのモデルが含まれます。

• jina-embeddings-v5-text-small

• jina-embeddings-v5-text-nano

これらのモデルは、埋め込みモデルの革新的な新しいトレーニングレシピの成果です。いずれも、同等サイズのモデルよりも何倍も優れたパフォーマンスを発揮し、メモリとコンピューティングリソースを節約し、リクエストへの応答を高速化します。

jina-embeddings-v5-text-smallモデルは6億7700万パラメーターを持ち、32768トークンのインプットコンテキストウィンドウをサポートし、デフォルトで1024次元の埋め込みを生成します。

jina-embeddings-v5-text-nano はその兄弟の約3分の1のサイズで、239Mのパラメーターと8192トークンのインプットコンテキストウィンドウを持ち、スリムな768次元の埋め込みを生成します。

モデル名

合計サイズ

インプットコンテキストウィンドウサイズ

埋め込みサイズ

jina-v5-text-small

677M パラメータ

32768トークン

1024次元

jina-v5-text-nano

2億3900万パラメーター

8192 トークン

768次元

これら2つのモデルは、MMTEB（Multilingual MTEB）ベンチマークの総合的なパフォーマンスにおいてクラス最高です。5億未満のパラメーターを持つモデルの中でjina-embeddings-v5-text-nanoはトップパフォーマーであり、2億5000万未満のパラメータを持ちながらも、7億5000万未満のパラメータを持つ多言語埋め込みモデルの中でjina-embeddings-v5-text-smallモデルがリーダーです。

これらのモデルは、Elastic Inference Service（EIS）やオンラインAPIを介して利用でき、ローカルホスティングでも利用できます。jina-embeddings-v5-textモデルにアクセスする方法については、以下の「はじめに」セクションを参照してください。

埋め込みモデルとセマンティックインデックスにより、検索アルゴリズムの精度が劇的に向上するだけでなく、以下のようなセマンティック類似性や意味抽出を伴うタスクにもさまざまな用途があります。

• 重複したテキストの検索。

• 言い換えや翻訳の認識。

• トピックの発見。

• 推奨エンジン。

• 感情分析と意図分析。

• スパムフィルタリング。

• その他多数。

特徴

この新しいモデルファミリーには、関連性を高め、コストを削減するために設計された多くの特徴があります。

タスクの最適化

私たちは、jina-embeddings-v5-text のモデルを4つの幅広いタスクタイプに最適化しました。

タスク

ユースケースの例

検索

自然言語クエリを使用して検索し、ドキュメントのコレクション内で最も関連性の高い一致を取得。

テキストマッチング

意味的類似性、重複除去、言い換えや翻訳の整合性など。

クラスタリング

トピックの検出、ドキュメントコレクションの自動整理。

分類

ドキュメントの分類、感情と意図の検出、同様のタスク。

あるタスクを最適化するということは、通常、別のタスクを妥協する必要があることを意味します。そのため、ほとんどの埋め込みモデルは、1種類のタスクに対してのみ競争力のあるパフォーマンスを発揮します。しかし、jina-embeddings-v5-textモデルは、タスク固有のLow-Rank Adaptation（LoRA）アダプターをトレーニングすることで、妥協することなく4つのすべての分野に特化できます。

LoRAアダプターはAIモデルのプラグインの一種であり、全体のサイズをわずかに増やすだけでAIモデルの動作を劇的に変化させます。jina-embeddings-v5-text モデルファミリーでは、タスクごとにモデル全体を用意し、それぞれに何億ものパラメーターを持たせる代わりに、各タスクにコンパクトなLoRaアダプターを備えた1つのモデルだけを使用できます。これによりメモリ、ストレージ容量、推論コストを節約できます。

埋め込みの切り捨て

私たちは、 Matryoshka Representation Learningを使用してjina-embeddings-v5-textモデルをトレーニングしました。これにより、品質への影響を最小限に抑えながら、埋め込みを小さなサイズに削減できます。

デフォルトでは、jina-embeddings-v5-text-small は1024次元の埋め込みベクトルを生成し、各ベクトルは16ビットで表されます。大量のドキュメントコレクションの場合、格納するデータ量が多くなり、埋め込みで満たされたベクトルデータベースでの検索は、データベースのサイズと各格納されたベクトルが持つ次元の数に比例します。

しかし、埋め込みのサイズを半分に減らす（1024次元のうち512次元を切り捨てる）だけで、占有スペースを半分にしながら検索速度を2倍にすることができます。これはパフォーマンスに影響を与えます。情報を捨てると精度が低下しますが、下のグラフが示すように、埋め込みの半分を取り除いてもパフォーマンスはわずかしか低下しません。

埋め込みが少なくとも256次元であれば、精度の損失は比較的小さいはずです。しかし、そのレベルを下回ると、関連性と正確性はすぐに低下します。

このような埋め込みの切り捨てにより、ユーザーは精度と計算コストのバランスを自分で管理できるようになり、検索AIから大きな効率の向上と大幅なコスト削減を実現するツールを提供します。

堅牢な量子化

量子化は埋め込みのサイズを縮小するもう一つの方法です。量子化では、各埋め込みの一部を破棄するのではなく、埋め込み内の数値の精度を下げます。jina-embeddings-v5-text モデルは16ビット数値で埋め込みを生成しますが、これらの数値を四捨五入して精度と格納に必要なビット数を減らすことができます。最も極端な場合では、各数値を1ビット（0または1）に減らすことで、jina-embeddings-v5-textのデフォルトの1024次元の埋め込みを2キロバイトから128バイトに圧縮できます。これは、バイナリ量子化だけで94％の削減になります。切り捨ての場合と同様に、これによりメモリと計算コストが大幅に節約されますが、切り捨てと同様に、量子化によって埋め込みの精度は低下します。

jina-embeddings-v5-textモデルはElasticsearchのBetter Binary Quantizationに対応し、精度の損失を最小限に抑えるようにトレーニングされており、これらのモデルからの二値化埋め込みのベンチマークテストでは、非二値化モデルとほぼ同等の性能を示しています。二値化性能に関する詳細なアブレーション研究についてはテクニカルレポートをご参照ください。

多言語パフォーマンス

多くの埋め込みモデルは、多数の言語を含む素材でトレーニングされているため、多言語対応です。しかし、サポートされているすべての言語で、すべてが同じように優れたパフォーマンスを発揮するわけではありません。

MMTEBの多言語ベンチマークで211の言語を特定し、それらを分離して、言語ごとにモデルを類似のモデルと比較できるようにしました。下の画像は、私たちの結果をヒートマップとしてまとめたものです。各パッチは言語（ISO-639コードで識別）であり、緑色が濃くなるほど、類似モデルの平均と比較してモデルのパフォーマンスが優れていることを示します。

正確さは言語によって異なりますが、jina-embeddings-v5-text モデルは最先端か、世界のほとんどの言語でほぼ最新です。

詳細な多言語パフォーマンスについては、jina-embeddings-v5-textテクニカルレポートを参照してください。

ElasticにおけるJina：最先端のネイティブAIによる検索

jina-embeddings-v5-textモデルをEISで使用することで、Elasticsearchでネイティブに高パフォーマンスの多言語埋め込みモデルを実行できます。これは、完全に管理されたGPUアクセラレーションによる推論で、インフラを提供したりスケールする必要はありません。jina-embeddings-v5-text モデルは、最新のAI開発によって強化されたコンパクトで多言語対応のモデルで、成長するEISモデルカタログを拡張します。これらのモデルは、情報検索と標準データ分析ベンチマークにおいて最先端のパフォーマンスを発揮し、他に類を見ない世界規模の多言語サポートを提供します。

サイズが大きく異なる2つのモデルが用意されているため、ユーザーは用途や予算に応じてどちらが最適かを判断できます。さらに、より小さなサイズに切り詰められたり、より低い精度に量子化されたりしてもパフォーマンスを維持する堅牢な埋め込みにより、jina-embeddings-v5-text モデルはストレージと計算コストおよび処理遅延においてさらなる具体的な節約の機会を提供します。

jina-embeddings-v5-textファミリー、Jina Reranker、Elasticの高速ベクトルおよびBM25検索により、ユーザーはElasticのエンドツーエンドの最先端のハイブリッド検索にアクセスできるようになりました。最も関連性の高い結果が必要な場合、Retrieval-Augmented Generation（RAG）パイプライン、検索アプリケーション、またはデータ分析において、ElasticとJinaの検索AIモデルは、堅固で費用対効果の高い品質を提供します。

はじめに

jina-embeddings-v5-textモデルはEISに完全に統合されており、インデックス作成時にtypeフィールドをsemantic_textに設定し、inference_idフィールドでモデル（jina-embeddings-v5-text-smallまたはjina-embeddings-v5-text-nano）を指定することで使用できます（次の例を参照）

Elasticsearchはインデキシングおよび検索時に適切なLoRAアダプターを自動的に選択します。埋め込み次元（上記の「埋め込みの切り捨て」セクション参照）は、カスタム推論エンドポイントを作成する際に設定できます。

jina-embeddings-v5-textモデルの利用については Elasticsearchのドキュメントを参照してください。

詳細情報

jina-embeddings-v5-textモデルについて詳しくは、Jina AIブログのリリースノートとテクニカルレポートをお読みください。パフォーマンスとJina AIの革新的な新しいトレーニング手順に関するより詳細な技術情報が記載されています。これらのモデルのローカルダウンロードや運用については、Hugging Faceのjina-embeddings-v5-textコレクションページをご覧ください。

Jina AIモデルは CC-BY-NC-4.0ライセンスの下で利用可能ですので、自由にダウンロードして試すことができますが、商用利用の場合は Elastic Salesまでお問い合わせください。

Jinaモデルは、情報処理、整理、検索をサポートするように設計された大きく3つのカテゴリーに分類されます。

• セマンティック埋め込みモデル

• リランキングモデル

• 小規模な生成言語モデル

セマンティック埋め込みモデル

セマンティック埋め込みの背後にある考え方は、AIモデルがインプットの意味的側面を高次元空間の幾何学の観点から表現することを学習できるというものです。

セマンティック埋め込みは、高次元空間内の点（技術的にはベクトル）と考えることができます。埋め込みモデルは、ニューラルネットワークの一種で、デジタルデータ（テキストや画像など、あらゆるものが入力となりえますが、最も一般的なのはテキストや画像）を入力として受け取り、対応する高次元点の位置を一連の数値座標として出力します。モデルが適切に機能している場合、2つのセマンティック埋め込み間の距離は、対応するデジタルオブジェクトがどの程度同じ意味を持つかに比例します。

これが検索アプリケーションにとっていかに重要であるかを理解するには、「dog」という単語の埋め込みと「cat」という単語の埋め込みを空間上の点として想像してみましょう。

優れた埋め込みモデルは、「feline」という単語に対して「dog」よりも「cat」にずっと近い埋め込みを生成し、「canine」は「cat」よりも「dog」にずっと近い埋め込みを生成するはずです。なぜなら、これらの単語はほぼ同じ意味だからです。

モデルが多言語対応であれば、「cat」と「dog」の翻訳でも同じ結果が期待できます。

埋め込みモデルは、物事間の意味の類似性や不一致を埋め込み間の空間的関係に翻訳します。上の図は2次元のみであるため、画面上で確認できますが、埋め込みモデルでは数十から数千の次元のベクトルが生成されます。これにより、数千語以上を含む文書に対して、何百または何千もの次元を持つ空間上の点を割り当てることで、全体のテキストの意味の微妙なニュアンスをエンコードすることが可能になります。

マルチモーダル埋め込み

マルチモーダルモデルは、セマンティック埋め込みの概念をテキスト以外のもの、特に画像にも拡張します。画像の埋め込みは、その画像の忠実な記述の埋め込みに近いものとなることが期待されます。

セマンティック埋め込みには多くの用途があります。とりわけ、効率的な分類器の構築、データのクラスタリング、データの重複排除やデータの多様性の調査などのさまざまなタスクの実行に使用できます。いずれも、手作業では管理できないほど大量のデータを扱うビッグデータアプリケーションにとって重要です。

埋め込みの最大の直接的な利用は情報検索です。Elasticsearchでは、埋め込みを含む検索オブジェクトをキーとして格納できます。クエリは埋め込みベクトルに変換され、検索によって埋め込みに最も近いキーを持つ格納オブジェクトが返されます。

従来のベクトルベースの検索（低密度ベクトル検索とも呼称）が、ドキュメントやクエリの単語やメタデータに基づくベクトルを使用するのに対し、埋め込みベースの検索（高密度ベクトル検索とも呼称）は、単語ではなくAIによって評価された意味を使用します。これにより、一般に従来の検索方法よりもはるかに柔軟かつ正確になります。

マトリョーシカ表現学習

埋め込みの次元数や数値の精度はパフォーマンスに大きな影響を与えます。空間が非常に高次元で数値が非常に高精度な場合、非常に詳細で複雑な情報を表すことができますが、トレーニングと実行に費用がかかる、より大規模なAIモデルが必要となります。生成されるベクトルはより多くのストレージ容量を必要とし、距離を計算するのにより多くの計算サイクルが必要です。セマンティック埋め込みモデルを使用するには、精度とリソース消費の間で重要なトレードオフを行う必要があります。

ユーザーの柔軟性を最大化するために、Jinaモデルはマトリョーシカ表現学習と呼ばれる技術で訓練されています。これにより、モデルは最も重要な意味的区別を埋め込みベクトルの最初の次元に前もってロードするため、より高い次元を切り捨てても良好なパフォーマンスを得ることができます。

実際には、これはJinaモデルのユーザーが埋め込みの次元数を選択できることを意味します。次元を少なく選択すると精度は低下しますが、パフォーマンスの低下は軽微です。ほとんどのタスクで、Jinaモデルのパフォーマンス指標は、埋め込みサイズを50％縮小するたびに1〜2％低下し、サイズが約95％小さくなります。

非対称検索

意味的類似性は通常、対称的に測定されます。「cat」と「dog」を比較したときに得られる値は、「dog」と「cat」を比較したときに得られる値と同じです。しかし、情報検索に埋め込みを使用する場合、対称性を破り、検索オブジェクトをエンコードする方法とは異なる方法でクエリをエンコードすると、埋め込みがより効果的に機能します。

これは、埋め込みモデルをトレーニングする方法によるものです。トレーニングデータには、単語のような同じ要素が多くの異なるコンテキストでインスタンスとして含まれており、モデルは要素間のコンテキスト上の類似点と相違点を比較することで意味論を学習します。

例えば、「animal」という単語は、「cat」や「dog」と同じ文脈にはあまり出てこないので、「animal」の埋め込みは「cat」や「dog」に特に近いわけではない可能性があります。

これにより、「animal」のクエリで猫や犬に関するドキュメントが検索される可能性が低くなります。これは目標とは逆の結果となります。そのため、代わりに、クエリの場合と検索のターゲットの場合で「animal」を異なる方法でエンコードします。

非対称検索とは、クエリに異なるモデルを使用したり、埋め込みモデルを特別に訓練して、検索のために格納する際に一方向にエンコードし、クエリを別の方向にエンコードすることを意味します。

マルチベクトル埋め込み

単一の埋め込みは、インデックス付きデータベースの基本的なフレームワークに適合するため、情報検索に適しています。検索キーとして単一の埋め込みベクトルを使用して、検索用のオブジェクトを格納します。ユーザーがドキュメントストアをクエリする際、そのクエリは埋め込みベクトルに変換され、そのキーが（高次元の埋め込み空間において）クエリ埋め込みに最も近いドキュメントが一致候補として取得されます。

マルチベクトル埋め込みの動作は少し異なります。クエリと格納されたオブジェクト全体を示す固定長のベクトルを生成する代わりに、それらの小さな部分を表す埋め込みのシーケンスを生成します。これらの部分は通常、テキストの場合はトークンまたは単語、視覚データの場合は画像タイルです。これらの埋め込みは、その文脈における部分の意味を反映しています。

例えば、次の文を考えてみましょう。

• She had a heart of gold（彼女は心優しい人でした）.

• She had a change of heart（彼女は心変わりしたのです）.

• 彼女は心臓発作を起こしました。

表面的には非常によく似ているように見えますが、マルチベクトルモデルでは「heart」の各インスタンスに対して非常に異なる埋め込みが生成され、文全体の文脈の中でそれぞれが別の意味を持つことが示されます。

2つのオブジェクトのマルチベクトル埋め込みを比較する場合、多くの場合、面取り距離の測定が必要になります。つまり、1 つのマルチベクトル埋め込みの各部分を別のマルチベクトル埋め込みの各部分と比較し、それらの間の最小距離を合計します。以下に説明するJinaリランカーを含む他のシステムでは、類似性を評価するために特別にトレーニングされたAIモデルにそれらを入力します。マルチベクトル埋め込みには単一ベクトル埋め込みよりもはるかに詳細な情報が含まれているため、通常、両方のアプローチは単一ベクトル埋め込みを単純に比較するよりも精度が高くなります。

しかし、マルチベクトル埋め込みはインデキシングにはあまり適していません。次のセクションのjina-colbert-v2モデルで説明するように、これらはタスクのリランキングによく使用されます。

Jina埋め込みモデル

Jina埋め込みv4

jina-embeddings-v4は、広く使用されているさまざまな言語の画像とテキストをサポートする、38億（3.8x10⁹）パラメーターの多言語およびマルチモーダル埋め込みモデルです。視覚的知識と言語的知識を活用する新しいアーキテクチャを使用して両方のタスクのパフォーマンスを向上させ、画像検索、特に視覚的ドキュメント検索で優れた性能を発揮します。これは、チャート、スライド、マップ、スクリーンショット、ページスキャン、ダイアグラムなどの画像を処理することを意味します。これらは一般的な種類の画像で、しばしば重要な埋め込まれたテキストが含まれており、実世界のシーンの画像で訓練されたコンピュータービジョンモデルの範囲外にあります。

コンパクトなLow-Rank Adaptation（LoRA）アダプターを使って、このモデルを複数の異なるタスクに最適化しました。これにより、メモリや処理の追加コストを最小限に抑えながら、いずれのタスクでもパフォーマンスを犠牲にすることなく、単一のモデルを複数のタスクに特化させることができます。

主な機能には以下のようなものがあります。

• ビジュアルドキュメント検索における最先端のパフォーマンス、および大規模モデルをはるかに凌駕する多言語テキストと通常の画像のパフォーマンス。

• 大きなインプットコンテキストサイズのサポート：32,768トークンは約80ページのダブルスペースの英語テキストに相当し、20メガピクセルは4,500 x 4,500ピクセルの画像に相当します。

• 最大2048次元から128次元まで、ユーザーが選択した埋め込みサイズ。経験的に、そのしきい線を下回るとパフォーマンスが劇的に低下することがわかりました。

• 単一埋め込みとマルチベクトル埋め込みの両方をサポートします。テキストの場合、マルチベクトル出力は、インプットトークンごとに1つの128次元埋め込みで構成されます。画像の場合、28x28ピクセルタイルごとに1つの128次元埋め込みを生成します。

• 目的のために特別に訓練された2つのLoRAアダプターによる非対称検索最適化。

• 意味的類似度計算に最適化されたLoRAアダプター。

• プログラミング言語とITフレームワークへの特別なサポート。LoRAアダプターを介してのサポートも提供します。

私たちは、幅広い一般的な検索、自然言語理解、AI分析タスクのための汎用的な多目的ツールとしてjina-embeddings-v4を開発しました。機能を考えると比較的小規模なモデルですが、導入には依然としてかなりのリソースが必要であり、クラウドAPI経由または高ボリューム環境での使用に最適です。

Jina embeddings v3

jina-embeddings-v3は、6億未満のパラメーターを持つ、コンパクトで高性能な多言語のテキストのみの埋め込みモデルです。最大8192トークンのテキストインプットをサポートし、デフォルトの1024次元から64次元まで、ユーザーが選択したサイズの単一ベクトル埋め込みを出力します。

私たちは、情報検索や意味的類似性だけでなく、感情分析やコンテンツモデレーションなどの分類タスク、ニュースの集約や推奨などのクラスタリングタスクなど、さまざまなテキストタスク向けにjina-embeddings-v3をトレーニングしてきました。jina-embeddings-v4と同様に、このモデルは次の使用カテゴリーに特化したLoRAアダプターを提供します。

• 非対称検索

• 意味的類似性

• 分類

• クラスタリング

jina-embeddings-v3 は jina-embeddings-v4よりもはるかに小さいモデルであり、インプットコンテキストのサイズが大幅に削減されていますが、操作にかかるコストは少なくなります。それにもかかわらず、テキストに関しては非常に競争力のあるパフォーマンスを有し、多くのユースケースにとってより良い選択肢です。

Jinaコード埋め込み

Jinaの専門的なコード埋め込みモデルであるjina-code-embeddings（0.5bおよび1.5b）は、15プログラミング方式とフレームワーク、さらにコンピューティングや情報技術に関連する英語のテキストをサポートしています。これらは、それぞれ5億 （0.5x10⁹）と15億（1.5x10⁹）のパラメーターを持つコンパクトなモデルです。どちらのモデルも、最大32,768トークンのインプットコンテキストサイズをサポートしており、ユーザーは出力の埋め込みサイズを選択（小さいモデルでは896から64次元、大きいモデルでは1536から128次元）できます。

これらのモデルは、LoRAアダプターではなくプレフィックスチューニングを使用して、5つのタスク固有の特殊化のための非対称検索をサポートしています。

• コードからコードへ。さまざまなプログラミング言語で同様のコードを取得できます。コードの調整、コードの重複排除、移植とリファクタリングのサポートに使用されます。

• 自然言語からコードへ。自然言語クエリ、コメント、説明、ドキュメントに合わせたコードを取得します。

• コードから自然言語へ。コードをドキュメントまたはその他の自然言語テキストと一致させます。

• コード間の補完。既存のコードを完成させたり強化したりするために、関連するコードを提案します。

• 技術的な内容のQ＆A。情報技術に関する質問に対する自然言語による回答を特定します。テクニカルサポートのユースケースに最適です。

これらのモデルは、比較的小さい計算コストで、コンピューターのドキュメント作成やプログラミング資料に関連するタスクに優れたパフォーマンスを提供します。開発環境やコードアシスタントに統合するのに適しています。

Jina ColBERT v2

jina-colbert-v2は、5億6000万のパラメーターを持つマルチベクトルテキスト埋め込みモデルです。多言語対応で、89言語の素材を使用してトレーニングされており、可変の埋め込みサイズと非対称検索をサポートしています。

前述のように、マルチベクトル埋め込みはインデックス作成にはあまり適していませんが、他の検索戦略の結果の精度を高めるのに非常に役立ちます。jina-colbert-v2を使用すると、マルチベクトル埋め込みを事前に計算し、それを使用してクエリ時に検索候補をリランキングすることができます。このアプローチは、次のセクションのリランキングモデルの1つを使用するほど正確ではありませんが、クエリや候補の一致ごとにAIモデル全体を呼び出すのではなく、格納されているマルチベクター埋め込みを比較するだけなので、はるかに効率的です。これは、リランキングモデルを使用する際の遅延や計算オーバーヘッドが大きすぎる、または比較する候補の数が多すぎるユースケースに最適です。

このモデルは、インプットトークンごとに埋め込みのシーケンスを出力し、ユーザーは128次元、96次元、または64次元の埋め込みのトークンを選択できます。候補テキストの一致は8,192トークンに制限されます。クエリは非対称にエンコードされるため、ユーザーはテキストがクエリか候補一致かを指定する必要があり、クエリは32トークンに制限する必要があります。

Jina CLIP v2

jina-clip-v2は、9億パラメーターのマルチモーダル埋め込みモデルであり、テキストが画像のコンテンツを説明する場合に、テキストと画像が近い埋め込みを生成するようにトレーニングされています。その主な用途は、テクスチャクエリに基づいて画像を取得することですが、テキストからテキストへの検索とテキストから画像への検索に別々のモデルを必要としないため、高性能のテキストのみのモデルでもあり、ユーザーのコスト削減に役立ちます。

このモデルは8,192トークンのテキストインプットコンテキストをサポートし、画像は埋め込みを生成する前に512x512ピクセルに拡大されます。

対照言語画像事前トレーニング（CLIP）アーキテクチャは、トレーニングと操作が簡単で、非常にコンパクトなモデルを作成できますが、基本的な制限がいくつかあります。あるメディアの知識を別のメディアでのパフォーマンスの向上に活用することはできません。あるメディアを利用して別のメディアのパフォーマンスを向上させることはできません。そのため、「dog」と「cat」という単語の意味はどちらも「car」よりも近いことはわかっていても、犬の写真と猫の写真はどちらも車の写真よりも関連性が高いことは必ずしもわかっていません。

また、これらはモダリティギャップと呼ばれる問題も抱えています。これはつまり、犬に関するテキストの埋め込みは、犬の画像の埋め込みよりも、猫に関するテキストの埋め込みに近い可能性が高いということです。この制限のため、CLIPはテキストから画像への検索モデルとして、またはテキストのみのモデルとして使用し、1つのクエリ内でこれら2つを混在させないことをお勧めします。

リランキングモデル

リランキングモデルは、1つまたは複数の候補一致と、クエリをモデルへのインプットとして取り、それらを直接比較して、はるかに高い精度の一致を生成します。

原理的には、各クエリを保存されている各ドキュメントと比較することで、情報検索にリランキングを直接使用できますが、これは計算コストが非常に高く、最小のコレクション以外では実用的ではありません。そのため、リランカーは、埋め込みベースの検索やその他の検索アルゴリズムなど、他の手段によって見つかった候補一致の比較的短いリストを評価するために使用される傾向があります。リランキングモデルは、検索を実行するとクエリが異なるデータセットを持つ個別の検索システムに送信され、それぞれが異なる結果を返す可能性があるハイブリッド検索スキームやフェデレーション検索スキームに最適です。多様な結果を1つの高品質な結果に統合する場合に非常に効果的です。

埋め込みベースの検索は、保存されているすべてのデータの再インデックスや、結果に対するユーザーの期待の変更など、大きな負担を伴う可能性があります。既存の検索スキームにリランカーを追加することで、検索ソリューション全体を再構築することなく、AIの利点の多くを追加することができます。

Jinaリランカーモデル

Jinaリランカーm0

jina-reranker-m0は、24億（2.4x10⁹）パラメーターのマルチモーダルリランカーで、テキストクエリとテキストや画像からなる候補一致をサポートします。これはビジュアルドキュメント検索の主要モデルであり、PDF、テキストのスキャン、スクリーンショット、テキストなど半構造化情報を含むコンピュータ生成または修正された画像、加えてテキストドキュメントと画像からなる混合データの格納に理想的なソリューションです。

このモデルは、単一のクエリと候補一致を受け取り、スコアを返します。同じクエリを異なる候補で使用すると、スコアは比較可能となり、それらのランク付けに使用できます。クエリテキストや候補テキストや画像を含む最大10,240トークンのインプットサイズをサポートします。画像をカバーするために必要な28x28ピクセルのタイルはすべて、入力サイズを計算するためのトークンとしてカウントされます。

Jinaリランカーv3

jina-reranker-v3は、同等のサイズのモデルに対して最先端のパフォーマンスを備えた6億パラメーターのテキストリランカーです。jina-reranker-m0とは異なり、1つのクエリと最大64件の一致候補のリストを受け取り、ランキング順を返します。クエリとすべてのテキスト候補を含む131,000トークンの入力コンテキストがあります。

Jinaリランカーv2

jina-reranker-v2-base-multilingualは非常にコンパクトで汎用的なリランカーで、関数呼び出しやSQLクエリをサポートする追加の機能を備えています。3億弱のパラメーターで、高速、効率的、正確な多言語テキストリランキングを提供し、テキストクエリにマッチするSQLテーブルと外部関数を選択するための追加サポートもあり、エージェント的なユースケースに適しています。

小規模な生成言語モデル

生成言語モデルは、OpenAIのChatGPT、Google Gemini、AnthropicのClaudeのように、テキストまたはマルチメディアのインプットを受け取り、テキスト出力で応答するモデルです。大規模言語モデル（LLM）と小規模言語モデル（SLM）を明確に区別する境界はありませんが、最先端のLLMを開発、運用、使用する際の実用的な問題はよく知られています。最もよく知られているものは一般公開されていないため、そのサイズを推定することしかできませんが、ChatGPT、Gemini、Claudeは1～3兆（1～3x10¹²）のパラメーター範囲にあると予想されます。

これらのモデルを実行することは、たとえ公開されたものであっても、従来のハードウェアの範囲をはるかに超えており、広大な並列アレイに配置された最先端のチップを必要とします。有料のAPIを使ってLLMにアクセスすることもできますが、これには大きなコストがかかり、レイテンシーも大きく、データ保護、デジタル主権、クラウドの本国送還などの要求と整合させるのは困難です。さらに、その規模のモデルのトレーニングとカスタマイズに関連するコストはかなりの額になる可能性があります。

その結果、最大規模のLLMのすべての機能は備えていないものの、特定の種類のタスクを低コストで同様に実行できる小規模モデルの開発に多大な研究が行われてきました。一般的に、企業は特定の問題に対処するためにソフトウェアをデプロイしますが、AIソフトウェアも同様で、LLMよりもSLMベースのソリューションの方が望ましい場合が多いのです。これらは通常、一般的なハードウェア上で実行でき、実行速度が速く、消費電力が少なく、カスタマイズがはるかに簡単です。

JinaのSLMサービスは、AIを実用的な検索ソリューションに最も効果的に組み込む方法に重点を置いて拡大しています。

Jina SLM

ReaderLM v2

ReaderLM-v2は、ユーザーが提供したJSONスキーマや自然言語命令に基づいて、HTMLをMarkdownまたはJSONに変換する生成言語モデルです。

データの前処理と正規化はデジタルデータの優れた検索ソリューションを開発する上で不可欠な部分ですが、現実世界のデータ、特にウェブから得られる情報は混沌としていることが多く、単純な変換戦略では非常に脆弱になることがよくあります。代わりに、ReaderLM-v2 はウェブページのDOMツリーダンプの混沌を理解し、有用な要素を堅牢に識別できるインテリジェントなAIモデルソリューションを提供します。

15億（1.5x10⁹）パラメーターを持つこのシステムは最先端のLLMよりも3桁コンパクトですが、この1つの狭義のタスクにおいては最先端のLLMと同等のパフォーマンスを発揮します。

Jina VLM

JINA-VLMは、画像に関する自然言語の質問に答えるために訓練された24億（2.4×10⁹）パラメーターの生成言語モデルです。視覚的ドキュメント分析、つまりスキャン、スクリーンショット、スライド、図表、類似の非自然画像データに関する質問に回答する機能を非常に強力にサポートしています。

例：

画像内のテキストの読み取りにも非常に優れています。

しかし、jina-vlmの真に優れた点は、情報収集や人工画像の内容を理解することです。

または：

jina-vlm 自動キャプション生成、製品の説明、画像の代替テキスト、視覚障害者向けのアクセシビリティ用途に最適です。また、検索拡張生成（RAG）システムが視覚情報を使用したり、AIエージェントが人間の助けを借りずに画像を処理したりする可能性も生まれます。