【生成AIアプリのためのベクトル検索】② 従来のAIアプリケーションと生成AIアプリケーションの構築手順の違い

# はじめに

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

2022年からの生成AIの隆盛に対して、[Apache Cassandra](https://cassandra.apache.org/_/index.html)に対して、[DataStax](https://www.datastax.com/jp)エンジニアにより[ベクトル検索機能の拡張提案](https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes)が提案され、DataStax社のCassandraマネージドサービスである[Astra DB](https://www.datastax.com/lp/astra-registration)で利用可能になっています。
本記事シリーズは、このような動向の一環として同社から発表されたホワイトペーパーの内容に基づきます。

## 出典と日本語版

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

https://www.datastax.com/resources/whitepaper/vector-search-for-generative-ai-apps

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

# 生成AIアプリのためのベクトル検索②

生成 AIと大規模言語モデル（LLM）は多くの熱狂を生み出しています。それは、開発者にとって、AI アプリケーションの構築方法を劇的に簡略化させたことで、さらに革命的なものとなっています。その理由を理解するために、従来のアプローチと生成的なアプローチの違いを見てみましょう。

## 従来のAIアプリケーションの構築手順
生成AIが普及する前は、AIアプリケーションを構築する際に多くの障壁がありました。そのプロセスの主なステップは次のとおりです。

### データから課題に関連する部分を特徴量として選別
「課題に関連する部分」が何であるかを判断するのは難しく、しばしば、経験に基づいた推測の代わりに、それを理解するためだけに別のモデルを構築する必要さえあります。生データから、課題に関連するデータを特徴量として選別することは、多くの場合、困難な問題であることが分かっています。

### 特徴量を使った要件に応じた機械学習モデルのトレーニング
画像分類などの一般的な機械学習の問題であれば、個別の問題に合わせて「ファインチューニング」することできる既製のモデルが存在する場合があります。Google の AutoML Vision(参考文献 1) はそのようなシステムの好例です。既存のモデルに、犬がどのようなものであるかを示すサンプルデータセットを提供するだけで、画像に写った犬を認識することのできるチューニングされたバージョンのモデルが得られます。

一方、ファインチューニングするための既存のモデルを見つけることができないようなタイプの問題があります。その場合、独自のモデルをトレーニングする必要がありますが、これは多大な時間を要し、計算コストが跳ね上がる傾向があります。一方、新しいユースケースに合わせて既存のモデルを変更する場面において、求める結果を導き出すためには、基礎となる数学に対する深い理解が必要になります。

### モデルをデプロイし、API として公開
機械学習モデルをデプロイする際、アプリケーションが機械学習モデルを提供するサービスを利用できるようにすることになります。それには、モデルサービスが必要なデータに確実にアクセスできること、アプリケーションがモデルサービスにアクセスし予測ステップの結果をリクエストするためのインターフェースを設計することが必要です。このステップのAPI 実装の選択は、予測がどのように使用されるかに直接的に依存します。また、認証/認可についての配慮と実装も必要になります。

### プロダクション環境でモデルを実行
モデルがプロダクションで利用され始めると、しばしば新たな課題に遭遇します。一般的な例としては、モデルの予測（出力）ステップのレイテンシ、時の経過に伴うモデルの陳腐化によるアウトプットの品質低下、モデルにとって重要なデータの投入までに生じる時間的ギャップなどが挙げられます。

## 従来の AI アプリケーション チーム

従来のスタイルのAI アプリケーションを構築して出荷するために必要なスキル セットを持つチームを編成・維持するのは決して容易ではありません。たとえば、従来の AI アプリケーション チームは、それぞれスキルの異なる、次のような役割で構成されるのが一般的です。

 - データエンジニア - 使用する生のデータセットを取得し、探索と利用を容易にするためにデータを保存およびクリーニングする責任を持ちます。データエンジニアチームは、データモデリング、ETL パイプライン、データウェアハウジングの専門家集団です。
 - データサイエンティスト - データを機械学習モデルで活用できるようにベクトルに変換する、データ探索と特徴量エンジニアリングを担当します。このチームは、モデルのソリューション化に際して、バイアスや過学習などの問題を回避する必要があります。そのためには、AI モデルの適切な選択とトレーニングが重要となり、それには、しばしば統計学に関する深い知識が求められます。
 - 意思決定科学の専門家（デシジョンサイエンティスト） - A/Bテストや仮説検証に関する専門家集団。このチームは、モデルがプロダクトに対して適正な成果をもたらすことを保証するようサポートします。また、AI 製品の構築に多額の投資を行う前に、データ サイエンティストが主導する AI モデル構築に先立つ探索的分析を支援し、データ内の洞察が単なる相関関係ではなく因果関係を示しているかどうかを判断する場合もあります。多くの企業では、データサイエンティストが、このデシジョンサイエンティストとしての役割も担っています。
 - 機械学習エンジニア - 主に本番環境でモデルを実行する最後のステップを担当します。このチームは、特徴量エンジニアリングとモデル予測のステップが大規模実行に耐えること、適切に監視されていること、およびアプリケーションにとって許容可能な応答時間で予測が返されることを保証します。


これらはすべて、深い技術スキルが必要となる高度に専門化された役割であり、これまでAI アプリケーションを成功裡に構築して運用するためには必須とされていました。


## 生成AIを用いたAIアプリケーションの構築手順

LLM を使用した生成AIに誰もが興奮している理由の大きな部分として、上記の手順を踏まずに、問題を解決できることがあります。
生成AIにおいては、やるべきことは以下だけです。

 1. LLM にデータを補完する方法を理解する（コンテクスト）
 2. AIモデルに実行させたいタスクを自然言語で記述する (プロンプト)
 3. LLM APIへのAPIコールを実行する

従来のAI アプリケーションに比べて、プロセスは劇的に単純になっています。そのため、生成AIを扱うことは、あらゆるチーム、あらゆる開発者にとって、十分現実的な範疇にあるといえます。

>「最もホットな新しいプログラミング言語は英語だ」
Tesla社のAI ディレクターAndrej Karpathy氏のツイッター上での発言(参考文献 2)

## 参考文献

19) “AutoML Vision documentation.” Google Cloud, https://cloud.google.com/vision/automl/docs
20) Karpathy, Andrej. “Andrej Karpathy on Twitter: "The hottest new programming language is English."” Twitter, 2023年1月24日, https://twitter.com/karpathy/status/1617979122625712128