OpenAIがo1モデルをリリースして以来。テストタイム・コンピューティングのスケーリング(スケーリング推論)は、AI界で最もホットなトピックの一つとなっている。簡単に言うと、事前学習や事後学習の段階で計算能力を積み上げるのではなく、推論の段階(つまり大規模言語モデルが出力を生成する段階)でより多くの計算資源を使った方が良いということである。 o1 モデルは、大きな問題を一連の小さな問題に分割する(つまりChain-of-Thought)ことで、モデルが人間のように段階的に考えることができるようになり、さまざまな可能性を評価し、より詳細な計画を立て、答えを出す前に自分自身を振り返るなどする。モデルは人間のように考えることができ、さまざまな可能性を評価し、より詳細な計画を立て、答えを出す前に自分自身を振り返るなどする。このように、モデルは再学習する必要がなく、推論中の追加計算によってのみ性能を向上させることができる。モデルに暗記させるのではなく、もっと考えさせる。-- アリババが最近発表したQwQモデルは、推論時の計算を拡張することでモデルの能力を向上させるという、この技術的傾向を裏付けている。
👩🏫 本論文におけるスケーリングとは、推論プロセス中に計算リソース(演算や時間など)を増加させることを指す。水平方向のスケーリング(分散コンピューティング)や加速処理(計算時間の短縮)については言及していない。
o1モデルを使ったことがある人なら、問題を解くために思考の連鎖を構築する必要があるため、多段階推論の方が時間がかかると感じるに違いない。
Jina AIでは、大規模言語モデル(LLM)よりもエンベッディングとリランカーに重点を置いています:思考の連鎖」という概念を、エンベディング・モデルにも適用することは可能だろうか?
一見すると直感的ではないかもしれないが、本稿では新たな視点を模索し、スケーリング・テストタイム・コンピュートがどのように適用できるかを実証する。ジーナクリップ
をより深く理解することができる。 トリッキーなアウト・オブ・ドメイン(OOD)イメージ カテゴリー分けは、不可能な課題を解決するために行われる。
CLIPのようなモデルは、画像とテキストのマッチングには強いが、モデルが見たことのない領域外(OOD)データに遭遇するとロールオーバーする傾向がある。
しかし、我々は次のことを発見した。モデルの推論時間を増やし、モデルのチューニングを必要としない連鎖思考のような多目的分類戦略を採用することで、領域外データの分類精度を向上させることができる。
ケーススタディ:ポケモン画像分類
Google Colab: https://colab.research.google.com/drive/1zP6FZRm2mN1pf7PsID-EtGDc5gP_hm4Z#scrollTo=CJt5zwA9E2jB
数千枚のポケモンカード画像を含むTheFusion21/PokemonCardsデータセットを使用した。これは画像分類タスクである。これは、切り取られたポケモンデッキ(説明文は削除されている)を入力し、正しいポケモン名を出力するものです。しかし、CLIP Embeddingモデルでは、いくつかの理由から、これは困難です:
- ポケモンの名前と見た目は比較的新しいモデルであり、直接的な分類で転がるのは簡単だ。
- ポケモンにはそれぞれ視覚的特徴があるCLIPは、形、色、ポーズなど、よりよく理解されている。
- カードのスタイルは統一されているがしかし、背景やポーズ、画風が異なることが、難易度を高めている.
- この作業には複数の視覚的特徴を同時に考慮するLLMの複雑な思考の連鎖のように。
ベースライン手法:直接類似性比較
最も単純なベースライン方法論から始めよう。 ポケモンの写真と名前の類似性の直接比較.
まず、CLIPモデルがテキストから直接答えを推測する必要がないように、カードからすべてのテキスト情報を削除する方がよい。次に ジーナクリップ-V1
歌で応える ジーナクリップ-V2
このモデルでは、画像とポケモンの名前を別々に符号化し、それぞれのベクトル表現を得る。最後に、画像ベクトルとテキストベクトル間の余弦類似度が計算され、類似度が最も高い方の名前が、その画像がどのポケモンであるとみなされる。
このアプローチは、他の文脈情報や属性を考慮することなく、画像と名前を一対一で照合することと同じである。以下の擬似コードで、この処理を簡単に説明する。
# 前処理 cropped_images = [crop_artwork(img) for img in pokemon_cards] # テキストを削除し、画像だけを残す。 pokemon_names = ["アブソル", "エアロダクティル", ...]. ポケモンの名前 # jina-clip-v1でエンベッディングを取得 image_embeddings = model.encode_image(cropped_images) text_embeddings = model.encode_text(pokemon_names) # 分類するための余弦類似度を計算する similarities = cosine_similarity(image_embeddings, text_embeddings) predicted_names = [pokemon_names[argmax(sim)] for sim in similarities] # 最も類似度の高い名前を選ぶ # 精度を評価する accuracy = mean(predicted_names == ground_truth_names)
上級:画像分類に思考の連鎖を応用する
今回は、写真と名前を直接一致させるのではなく、「ポケモンコネクト」をプレイするように、ポケモンの識別をいくつかのパートに分けた。
私たちは5つの主要属性を定義した:原色(例:「白」、「青」)、原形(例:「狼」、「翼のある爬虫類翼のある爬虫類")、主要な特徴("白い角"、"大きな翼 "など)、体の大きさ("4本足のオオカミ型"、"翼のある細長い体型"、"翼のあるほっそりとした")、背景の情景("宇宙"、"緑の森 "など)。
各属性のセットに対して、「このポケモンの体は主に{}色をしている」といった特別なキュー・ワードをデザインし、可能な選択肢を埋めていった。次に、このモデルを使って画像と各オプションの類似度スコアを計算し、ソフトマックス関数を使ってスコアを確率に変換します。
完全な思考の連鎖(CoT)は2つの部分からなる:分類グループ
歌で応える ポケモンルール
前者は質問の枠組みを定義するもので、各属性(色や形など)は質問テンプレートと可能な回答の選択肢のセットに対応しています。後者は、それぞれのポケモンに対して、どの選択肢を一致させるべきかを記録します。
例えば、アブソルの色は「白」で、姿は「狼」でなければなりません。完全なCoT構造を構築する方法については後述しますが、以下のpokemon_systemはCoTの具体例です:
ポケモンシステム "classification_cot": { "dominant_colour": { "prompt": "このポケモンの体の色は主に{}です、 "オプション": [ "白", # アブソル, アブソルG "灰色", # アグロン 「茶」、# エアロダクティル、ウィードル、ビードリル δ 「青」、# アズマリル 「緑」、# ブルバサウル、ビーナサウル、セレビィ&ビニュー、キャタピー 「黄色、# アラカザム、アンファロス 「赤」、# ブレインのモルトレス 「オレンジ」、# アルカニン 「水色」# ドラティニ ] } "primary_form": { "プロンプト": "{}のようです。", "オプション": [ 狼", # アブソル, アブソル G "装甲恐竜", # Aggron 「翼のある爬虫類", # エアロダクティル 「ウサギのようなクリーチャー」、# Azumarill 「ヒキガエルのような生物」、# Bulbasaur、Venusaur、Celebi&Venu 「イモムシの幼虫, # ウィードル, キャタピー 「スズメバチのような昆虫, # ビードリルδ 「キツネのような人型」、# アラカザム 「羊のような二足歩行」、# Ampharos 「犬のような獣」、# アルカニン 「炎の鳥」、# ブレインのモルトレス "蛇のような竜" # Dratini ] } "key_trait": { "prompt": "その最大の特徴は{}です。", "オプション": [ 「一本の白い角", # アブソル, アブソル G 「金属の鎧板", # アグロン/Aggron 「大きな翼", # エアロダクティル, ビードリル δ 「ウサギの耳」、# アズマリル 「緑の植物の球根」、# ブルバサウル、ビーナサウル、セレビィ&ビニュー 「小さな赤いトゲ」、# ウィードル 「大きな緑の目」、# キャタピー 「ヒゲとスプーン, # アラカザム 「光るテールオーブ」、# アンファロス 「炎のたてがみ」、# アルカニン 「炎の翼」、# ブレインのモルトレス 「頭に小さな白い角" # ドラティニ ] } "body_shape": { "プロンプト": "体型は{}と表現できます。", "オプション": [ 「狼のような4本足", # アブソル, アブソル G 「がっしりとした鎧", # アグロン "翼があり細長い", # エアロダクティル, ビードリル δ 「丸々としてふくよか」、# アズマリル 「4本足で頑丈」、# ブルバサウル、ビーナサウル、セレビィ&ビニュー 「長くてミミズのよう」、# ウィードル、キャタピー 「直立した人型」、# アラカザム、アンファロス 「毛むくじゃらでイヌのような」、# アルカニン 「炎を持つ鳥のような」、# ブレインのモルトレス 「蛇のような」 # ドラティニ ] } "background_scene": { "prompt": "背景は{}のようです。", "オプション": [ 「宇宙空間", # アブソルG, ビードリルδ 「緑の森", # アズマリル, ブルバサウル, ビーナサウル, ウィードル, キャタピー, セレビィ&ビニュー "岩だらけの戦場"、# アブソル、アグロン、エアロダクティル 「紫の心霊部屋」、# アラカザム 「晴れのフィールド」、# アンファロス 「火山の地面, # アルカニン "燃えさかる赤い空"、# ブレインのモルトレス "穏やかな青い湖" # ドラティニ ] } } "ポケモンルール": { "アブソル": { "dominant_colour": 0、 "primary_form": 0、 "key_trait": 0、 "body_shape": 0、 「background_scene": 2 }, "アブソル・G". 「アブソルG": { 「ドミナント・カラー": 0, "プライマリー・フォーム": 0, "バックグラウンド・シーン": 2 }, "アブソル・G": { 「primary_form": 0、 「primary_form": 0、"key_trait": 0、 「body_shape": 0、 「background_scene": 0 }, ... // ... } }
つまり、単純に類似性を一度だけ比較するのではなく、複数の比較を行い、各属性の確率を組み合わせることで、より合理的な判断ができるようになるのだ。
# 分類処理 def classify_pokemon(image). # すべてのプロンプトを生成する all_prompts = [] (すべてのプロンプトを生成する) for group in classification_cot. for option in group["options"]: prompt = group["prompt"].format(option) all_prompts.append(prompt) # ベクトルとその類似度を得る image_embedding = model.encode_image(image) text_embeddings = model.encode_text(all_prompts) 類似度 = cosine_similarity(image_embedding, text_embeddings) # 属性グループごとに類似度を確率に変換する 確率 = {}とする for group_name, group_sims in group_similarities: probabilities[group_name] = {}。 probabilities[group_name] = softmax(group_sims) # マッチした属性に基づいて各ポケモンのスコアを計算する score = {}とする。 for pokemon, rules in pokemon_rules.items(): score = 0 for group, target_idx in rules.items(): score += probabilities[group][target_idx]: {}. score += probabilities[group][target_idx]: {}. スコア[ポケモン] = スコア return max(scores, key=scores.get) # 最もスコアの高いポケモンを返す。
2つの方法の複雑さ分析
N個のポケモンの名前の中から、与えられた画像に最も一致する名前を見つけたいとします:
ベースライン法では、N個のテキスト・ベクトル(各名前に1個ずつ)と1個の画像ベクトルを計算し、N個の類似度計算(画像ベクトルと各テキスト・ベクトルを比較する)を行う必要がある。したがって、ベンチマーク手法の複雑さは、主にテキストベクトルの計算回数Nに依存する。
そして、私たちのCoTメソッドはQ個のテキストベクトル(Qはすべての質問と選択肢の組み合わせの総数)と1個の画像ベクトルを計算する必要があります。その後、Q個の類似度計算(各質問と選択肢の組み合わせに対する画像ベクトルとテキストベクトルの比較)を行う必要があります。したがって、手法の複雑さは主にQに依存する。
この例では、N = 13、Q = 52(1グループあたり平均約10のオプションを持つ属性の5つのグループ)。どちらの手法も画像ベクトルを計算し、分類ステップを実行する必要があり、比較ではこれらの共通操作を四捨五入しています。
極端な例では、Q = Nの場合、我々の方法は事実上ベンチマーク手法に退化する。つまり、推論時間の計算を効果的に拡張する鍵は
-
Qの値が大きくなるように問題を設計する。 -
それぞれの質問に、絞り込むための有用な手がかりがあることを確認する。 -
情報を最大限に得るためには、質問間で情報が重複しないようにするのがベストです。
結果
13種類のポケモンを含む117枚のテスト画像で評価した。精度の結果は以下の通りである:
また、一度ポケモンシステム
正しく作られている。同じCoTを、コードを変更することなく、微調整や追加トレーニングなしに、別のモデルに直接使用することができる。
興味深い。ジーナクリップ-V1
ポケモンデータを含むLAION-400Mデータセットで学習したため、ポケモン分類の基本精度は31.36%と高い。一方 ジーナクリップ-V2
このモデルはDFN-2Bで学習されたもので、より質の高いデータセットですが、より多くのデータをフィルタリングし、おそらくポケモン関連のコンテンツも削除しているため、基本的な精度は低くなっています(16.10%)。
待って、この方法はどうやって使うの?
👩🏫 私たちがやったことを復習しよう。
私たちはまず、サンプル数がゼロの分布外(OOD)問題を扱えない、訓練済みの固定ベクトル・モデルを使い始めました。しかし、分類木を作ったところ、突然それができるようになったのです。その秘密は何だろう?伝統的な機械学習における弱い学習者の統合のようなものだろうか? 私たちのベクトルモデルが「悪い」から「良い」にアップグレードできるのは、統合学習それ自体のためではなく、分類木に含まれる外部のドメイン知識のためであることは注目に値する。ゼロサンプルで何千もの質問を繰り返し分類することはできますが、答えが最終結果に寄与しなければ意味がありません。20問の "you tell me, I guess "ゲームのようなもので、1問ごとに解答を徐々に絞り込んでいく必要がある。 このように、外部からの知識や思考プロセスこそが重要なのである。 - 例のように、ポケモンシステムがどのように構築されているかがカギとなる。この専門知識は、人間から得ることも、大規模な言語モデルから得ることもできる。
ポケモンシステム
品質.このCoTシステムを構築するには、マニュアルから完全自動化まで多くの方法があり、それぞれに長所と短所がある。1.マニュアル施工
2.LLMアシスト建設
ポケモンの分類システムが必要です。以下のポケモンについて:[アブソル、エアロダクティル、ウィードル、キャタピー、アズマリル、...]。を含む分類システムを作ってください: 1. 以下の視覚的属性に基づく分類グループ: - ポケモンの原色 - ポケモンの形 - ポケモンの最も際立った特徴 - ポケモンの全体的な大きさ - そのポケモンが普段いる背景環境 2.分類グループごとに - 選択肢に「{}」を使った自然言語のヒントテンプレートを作成する。 - 可能な選択肢をすべて列挙する - 選択肢が相互に排他的で包括的であることを確認する 3. インデックスを使用してオプションを参照し、各属性グループのオプションに各ポケモンをマッピングするルールを作成します。 Python辞書形式で出力してください: - "classification_groups": 各属性のヒントとオプションを含む。 - "pokemon_rules":各ポケモンと対応するプロパティのインデックスを対応付けます。 フォーマット例 { "分類グループ": { "ドミナントカラー": { "prompt": "このポケモンの体の色は主に{}です。", "options": ["white", "grey", . "オプション": ["白", "灰色", ...]. }, ... ... }, "pokemon_rules". "ポケモンルール": { "アブソル": { "dominant_colour": 0, "白 "の#インデックス ... }, ... ... } }
LLMは素早く初稿を作成するが、手作業によるチェックや修正も必要となる。
より確実なアプローチは次のようなものだ。 LLM生成と手動検証の組み合わせ.まずLLMに初期バージョンを生成させ、次に属性のグループ化、オプション、ルールを手動でチェックして修正し、その修正内容をLLMにフィードバックして、LLMが納得するまで改良を続ける。このアプローチは、効率と精度のバランスをとるものである。
3.DSPyによる自動ビルド
完全自動ビルド ポケモンシステム
これはDSPyで繰り返し最適化できる。
まずはシンプルに ポケモンシステム
DSPyはこのフィードバックを使って、新しいデータを生成する。DSPyはこのフィードバックを使って新しい ポケモンシステム
パフォーマンスが収束し、大幅な改善が見られなくなるまで、このサイクルを繰り返す。
ベクトルモデルはプロセスを通して固定される.DSPyを使えば、最適なpokemon_system (CoT)設計を自動的に見つけることができ、タスクごとに一度だけチューニングする必要があります。
なぜベクトルモデルのテスト時間計算をスケーリングするのか?
事前学習済みモデルのサイズを常に大きくするコストがかかるため、持ち運ぶには高すぎる。
ジーナ・エンベッディング・コレクションジーナ・エンベディングス-V1
そしてv2
そしてv3
まで ジーナクリップ-V1
そしてv2
そして ジナコルベルト-v1
そしてv2
しかし、アップグレードのたびに、より大きなモデル、より多くの事前訓練されたデータ、そして増大するコストに依存している。
取るジーナ・エンベディングス-V1
2023年6月に1億1,000万パラメータでリリースされる場合、トレーニングには5,000ドルから10,000ドルの費用がかかる。その頃には ジーナ・エンベディングス-V3
しかし、それはまだリソースにお金を投じることが中心である。現在、トップモデルのトレーニングコストは数千ドルから数万ドルに上昇し、大企業では数億ドルを費やさなければならないほどだ。事前トレーニングに投資すればするほど、モデルの結果は良くなるが、コストが高すぎて、費用対効果がどんどん低くなっている。
そしてこの図は、ベクトルモデルのScアリング法横軸はモデルパラメーターの数、縦軸はMTEBの平均性能である。各ポイントはベクトルモデルを表す。傾向線は全モデルの平均を表し、青い点は多言語モデルである。
データはMTEBランキングの上位100ベクターモデルから選択した。データの質を保証するため、モデルサイズの情報を開示していないモデルや、一部の無効な投稿を除外した。
一方、ベクトルモデルは現在、多言語、マルチタスク、マルチモーダル、優れたゼロサンプル学習と命令追従能力など、非常に強力なものとなっている。この多用途性により、アルゴリズムの改良や推論時の計算の拡張など、想像力豊かな可能性が大きく広がる。
重要なのは、そのことだ:ユーザーは、本当に関心のあるクエリにいくら支払っても構わないと思っているのだろうか。?事前に訓練された固定モデルの推論に少し時間をかけるだけで、結果の質が劇的に向上するのであれば、多くの人がそれに価値を見出すと確信している。
我々の意見では。推論時間計算の拡張は、ベクトルモデリングの分野で未開拓の大きな可能性を秘めているこれはおそらく、今後の研究にとって重要なブレークスルーとなるだろう。より大きなモデルを目指すのではなく、推論段階に力を入れ、パフォーマンスを向上させるために、より巧妙な計算方法を模索する方がよい。 -- この方が経済的で効果的なルートかもしれない。
評決を下す
ある ジーナクリップ-V1/V2
実験では、以下のような重要な現象が見られた:
-
我々 モデルが見ていない、ドメイン外のデータについて(OOD)属より高い認識精度が達成され、モデルの微調整や追加トレーニングはまったく必要なかった。 -
このシステムは次のように機能する。 類似性検索と分類基準の反復的改良より細かな差別化が可能になる。 -
導入することで ダイナミックなキュー調整と反復推論(思考の連鎖 "に似ている)、ベクトルモデルの推論プロセスを単一のクエリーからより複雑な思考の連鎖へと変換する。
これはほんの始まりに過ぎない!スケーリング・テストタイム・コンピュートの可能性はこれをはるかに超える!しかし、探索すべき広大な空間がまだ残っている。例えば、「20の質問」ゲームにおける最適解戦略と同様に、最も効率的な戦略を繰り返し選択することで、解答空間を狭める、より効率的なアルゴリズムを開発することができる。推論時間計算を拡張することで、ベクトルモデルを既存のボトルネックから押し出すことができ、かつては手が届かないと思われていた複雑で細かなタスクを解き放ち、これらのモデルをより広範なアプリケーションに押し出すことができる。