はじめに

背景〜ベクトルデータベースとしてのApache CassandraとDataStax Astra DB

2022年からの生成AIの隆盛に対して、Apache Cassandraに対して、DataStaxエンジニアによりベクトル検索機能の拡張提案が提案され、DataStax社のCassandraマネージドサービスであるAstra DBで利用可能になっています。
本記事シリーズは、このような動向の一環として同社から発表されたホワイトペーパーの内容に基づきます。

出典と日本語版

このシリーズ記事の原典は、以下で入手可能です。

ブログ記事では、忠実な訳出ではなく、読みやすさを重視して、一部省略しています。
省略のない日本語版のホワイトペーパーの入手を希望される方はinfo-jp@datastax.comまでご連絡いただければ、提供させていただきます。

【生成AIアプリのためのベクトル検索】⑧ 分類

分類問題には多くのユースケースがあります。テキスト解析における分類問題として、ドキュメントのトピック分類があります。例えば、ドキュメントの内容がスポーツ、政治、エンターテインメント等、どのジャンルに関するものであるかを判断します。
以下、LLM を使用した分類に対するいくつかの異なるアプローチと、それぞれのメリットとデメリットについて解説します。まずは、実装の面で最も簡単なものから始め、より複雑なアプローチへと進んでいきます。

分類のためのFew-shot学習

LLMは、Few-shot学習プロンプトを用いて、テキスト分類のためにそのまま使用できます。Few-shot学習のプロンプトでは、分類用のさまざまなラベルの例をLLMに提供します。
ポジティブな感情とネガティブな感情を分類する簡単な例を見てみましょう。ここでは、OpenAI プラットフォーム上で、gpt-3.5-turboモデルを使用して、これがどのように可能になるかを例示します。
Few-shot学習の例を示すために、まず、プラットフォームが提供しているタスク定義機能の使用例を示します。

［システムプロンプト］
（ここで、文章を肯定的なものと否定的なものとに分類しています）

Document:
This movie was horrible.
Sentiment: 
Negative.
Document:
I loved the movie I saw this weekend, it was so exciting!
Sentiment:
Positive.
Document:
Worth every penny!  It was soooo good!
Sentiment:
Positive.

これで、ユーザープロンプトから新しいドキュメントを提示し、LLM にそのドキュメントに内在するセンチメントを返すようにリクエストする準備が整いました。
［ユーザープロンプト］

Document:
I hated that movie, it was so boring.
Sentiment:

この場合、LLM からの応答は「Assistant: Negative」になります。

分類のためのLLMファインチューニング

ファインチューニングでは、モデルに大規模な入出力ペアを提供し、目的に合わせて、モデルに実行させたい内容をチューニングします。 LLM の動作をファインチューニングするには、通常、少なくとも数百以上のサンプルを提供する必要があります(一般に、このように大量のサンプルをFew-shot学習用のプロンプトから渡すことは、入力テキストサイズの制限や、トークンに掛かるコストの面から、現実的ではありません)。

以下では、Few -shotプロンプトでは役不足であり、ファインチューニングが必要となる場合について、考えます。例として、特定の製品がテキスト内で議論されたかどうかをラベル付けする分類の問題を検討します。 Stripe社（金融サービスを提供するSaaS企業）は、Payments、Checkouts、Billingなどの製品を提供しています。ご覧の通り、製品名には一般名詞が使用されています。このような場合、LLMにとって、固有名詞としての製品名と、一般名詞としての会計用語とを区別することは難しいものになります。
ここで、「My stripe payments failed.」というフレーズを考えてみましょう。
ユーザーは、「Stripe Paymentsをセットアップしようとしたが、うまくいかなかった」と言っているのかもしれませんし、仔細に表現すると「Stripeからの請求書を支払おうとしたが、失敗した」という内容を伝えようとしていたのかもしれません。
この単純な例では、フレーズを「Stripe Payments」という製品に関する議論として分類すべきかどうかを判断することは困難に見えます。
対策として、文書内で Stripe paymentsという製品について説明しているまとまった量のサンプル（正事象）と、Stripe という単語の近くに「payments」という単語が出現しているが、製品の名称としてではなく会計用語として使用されている同規模のサンプル（反事象）からなる、十分な量のサンプルでLLMをファインチューニングすることが考えられます。これによって、LLMは、これら 2 つのケースを区別できるようになる可能性があります。

このアプローチには、以下のようなメリットとデメリットがあります。

メリット - 分類器の精度向上
デメリット - 少なくとも数百のトレーニングサンプルのセットを維持する必要性
デメリット - クラウドベンダーの提供するファインチューニングモデルは標準のLLMより高額