キーワードベースの検索にさようなら
GPT 3+ や ChatGPT ではなく、プロンプト エンジニアリングの方が直感的に理解しやすいです。 Web やソーシャル メディアで利用できる多くのガイドと例を使用します。そのような
埋め込みは、プログラミングが必要であり、その仕組みに関するさまざまな直感に反する動作のために、あまり理解されていません。しかし、検索や既存のテキストベースのモデルと組み合わせて使用するための非常に強力なツールであり、その他のさまざまなユースケースで使用できます。
埋め込みは、AI ツールキット内で、命令モデル用の同様に強力なツールであることはほぼ間違いありません。さまざまな単語や文、さらには言語全体にわたる検索を処理できるためです。あらゆるクエリに対して、関連するドキュメントの検索に焦点を当てます。
たとえば、英語ベースのドキュメントからの検索と回答を強化するために使用できます。英語で ...
それとも日本語...
または、AI モデルがサポートするその他の言語。
ベクトル埋め込みは、検索や、質問応答、テキスト分類、テキスト生成などの他のタスクに使用できます。
この記事は検索の側面に焦点を当てていることに注意してください。回答プロセスはフォローアップ記事にあります.
ベクター埋め込みを生成するには、埋め込み AI モデルを使用します。これは、任意のテキスト (大きなドキュメント、文、さらには単語) をベクターと呼ばれる「N 次元配列」に変換します。
たとえば、 How do I write a UI test script with Uilicious?
OpenAI text-embedding-ada-002 モデルを介して配列 (ベクトルと呼ばれます) に変換できます: [0.010046141, -0.009800113, 0.014761676, -0.022538893, ... an a 1000+ numbers]
このベクトルは、テキストに対する AI モデルの要約された理解を表します。これは、AI だけが理解できる言語で書かれた「N ワードの要約」と考えることができます。
AI のドキュメントの理解 (テキストだけでなく) に基づいて、関連するドキュメントが互いに近い距離にある場合。
これは、従来の検索エンジンの単純なキーワード検索を超える大きな飛躍であり、文の構造と言語のバリエーションを処理できるためです (AI モデルがその言語を理解するようにトレーニングされている場合)。
以下は、理解しやすいように 2 次元空間に不正確に簡略化された架空の例です。
これは、2D 空間で次のように視覚的に表すことができます。
たとえば、D1、2、3 はすべて、さまざまな方法で Uilicious を使用する方法に関連するドキュメントであり、1 つのクラスターにまとめられています。
D4 と D5 は単なるリンクであり、それ以上の固有の価値がないため、別のクラスターに個別にグループ化されます。
さらに、D1 と D2 は、独自の JavaScript ベースのテスト言語を使用した Uilicious テスト コマンドに関するものであるため、さらにグループ化されています。
D3 は個別にグループ化されていますが、インフラストラクチャで Web ドライバー プロトコルを直接使用することに関するものであり、異なるユース ケースとオーディエンスを対象としています。
同様に、第 1 問と第 2 問についても、文の構造や言葉遣いが大きく異なるものの、本質的には同じ質問であるため、2 つの質問を 1 つのグループにまとめています。
さらに、質問は技術的には (Uilicious テスト スクリプトまたは webdriver プロトコルを使用して) 両方の方法で解釈できますが、質問は webdriver を介した Uilicious テスト スクリプトの使用を暗示しているため、その場所は D1 と D2 に「近く」、D1 と D2 からさらに離れています。 D3.
そのため、キーワードに大きな重複があるにもかかわらず、グループ化のこれらのニュアンスは、埋め込み内にエンコードされた AI によってキャプチャされます。キーワード検索との際立った違いを際立たせる
ただし、実際には、人間が理解しやすい単純化された 2 次元配列の代わりに、埋め込みは簡単に 1,000 次元以上の配列になる可能性があります。この配列は、使用される特定の AI モデルに固有のものであり、別の AI モデルの埋め込みと混合することはできません。
単純化された 2 次元の例は、1 つの質問 (または 1 つの視点) に基づいてグループ化するという高レベルの概念を理解するのに適していますが、N 次元を正確に表すものではありません。
複雑な N 次元の計算により、A が B に近く、B が C に近くても、A と C が互いに遠く離れていると見なされる状況が発生する可能性があります。これは非常に直感に反する落とし穴です。
このような距離は、同じ点に対して相対的に使用され、式が使用される場合にのみ役立ちます。どちらを使用して計算できますか
各式の有効性にはそれぞれ長所と短所がありますが、ユースケースが異なります。テキスト検索の場合、ユークリッド距離はほとんどの場合「よりうまく機能する」と一般に認められており、他の方法が優れている場合は「十分に機能する」と考えられています。
これらはすべて、N 次元を 1 点に対して 1 次元 (距離) に縮小するために実際に使用されます。結果として、これは、尋ねられた質問に応じて、グループ化が大幅に変更される可能性があることを意味します。
この距離の「相対性」の性質により、従来のデータベース検索インデックスは無効になります。
それが意味をなさない場合、これは数学N-Spheresで4次元空間が適切に視覚化される方法です.
1,000 次元を想像してみてください。ええ、それは意味がありません。
したがって、このトピックを PHD の論文で脱線させることなく、数学の教授を信頼しているだけとしてこれを要約します。
理解する必要があるのは、一般に、2 つのベクトル埋め込みポイント間の距離が近いほど、それらが互いに関連している可能性が高くなることです。
実用的な実装の観点から。最初にユークリッド距離を使用することから始めます。ユースケースに合わせて試行錯誤しながら、より良い結果を得るために微調整された他の数式の使用を検討する前に (推奨されません)。
さまざまなドキュメントを埋め込みに変換できるので、データベース内に保存して検索を実行できるようになりました。
ただし、テキストで検索する SQL データベースとは異なり、検索も検索対象のデータもベクトル埋め込みそのものです。これは、埋め込みの検索に関しては、従来のデータベース検索インデックスが効果的でないことを意味します。
すべてのドキュメントを埋め込み、事前に計算して、ベクトル検索データベースに保存できます。次に、これを使用して、最も近い距離でランク付けされた一致のリストを提供できます。
これは、次のような既存のベクター データベースを使用して実行できます。
注意すべき重要な点の 1 つは、ベクトル検索の「データベース技術」が比較的新しいことです。ベクトル検索データベースの大部分は、Facebook、Spotify、Google などの企業で見られるユースケース向けに設計されており、数百万または数十億のレコード セットがあります。また、小さなデータセットには最適化されていない可能性があります。
これは、今後数年間で絶えず変化する分野になるでしょう。将来のベクター検索データベースを追跡および検索するのに役立つ github の「awesome-list」を次に示します。
そのため、一般に、(<10,000 ~ 100,000 埋め込み) の小さなデータセットの場合、埋め込みデータセットをメモリに保持し、ブルート フォーシングのユークリッド距離の 2 乗は、多くのユース ケースで「十分」であり、正式なものよりも優れている場合があります。次のようなデータベース ソリューション (ディスク/ネットワークのオーバーヘッドが発生します)。
このアプローチの明らかな欠点は、データセット全体が、オーバーヘッドなしでメモリに収まるほど小さくなければならないことです。
ローカルのメモリ内埋め込み検索を使用しているか、正式なベクトル検索データベースを使用しているかに関係なく。
埋め込み検索は、さまざまな言語やシナリオで柔軟に機能する並べ替えとランク付けのアルゴリズムにすぎません。読者としてのあなたへの質問は、それをどのように使用できるかです。そのままGoogle検索の代替として、またはチャットからゲームまで、他のツールと組み合わせて使用できます。可能性は無限であり、探求の余地があります。
〜また次回まで🖖長生きと繁栄
Eugene Cheah @ tech-talk-cto.com
元の投稿: https://substack.tech-talk-cto.com/p/introducing-ai-embeddings-and-how
使用されているすべての画像と適切な帰属