DatabricksにおけるRAGの実践

こちらのイベントでお話しした内容です。

https://mlops.connpass.com/event/315387/

スライドはこちら。

<script defer class="speakerdeck-embed" data-id="8705fa0c858f471c995463a0c514ae5f" data-ratio="1.7772511848341233" src="//speakerdeck.com/assets/embed.js"></script>

冒頭は自己紹介、[書籍](https://www.amazon.co.jp/dp/4798182281)の宣伝、会社紹介という流れでした。

# Databricksとは？

Apache Sparkを開発した人たちが創業した会社です。
![Screenshot 2024-05-23 at 20.24.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/9701a2b1-130e-c20d-c842-91c7992aa807.png)

Databricksは会社名であると同時にプラットフォームの名前です。全ての会社が**データ+AIカンパニー**になるための手助けをするためのプラットフォームを提供しています。

# DatabricksにおけるRAGのデプロイメント

ここで言いたいのは、**RAGで必要なものはほぼ揃ってます！** ということです。GUI部分が執筆時点ではカバーされていませんが、間も無く提供される[Lakehouse Apps](https://qiita.com/taka_yayoi/items/582cec2e2b888e6e515e)でカバーされます！
![Screenshot 2024-05-23 at 20.29.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/0c54cced-3d95-4579-dae5-4a2f35f043b6.png)

# プロダクションレベルの生成AIアプリ(RAG)の構築

生成AI、特にLLMの具体的なアプリケーションで一番具現化されているものはRAG(Retrieval Augmented Generation)であると言えます。ただ、RAGの構築においても様々な課題がありますし、その運用に関しても検討すべきことはたくさんあります。
![Screenshot 2024-05-23 at 20.33.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/034046f6-9ded-afa9-00eb-aa4e16e7221b.png)

以降では、以下に示すRAG構築におけるステップごとにどのような課題があり、Databricksがどのように取り組んでいるのかを説明します。

- **生成AIモデルの選択**: 今では世の中に膨大な数の生成AIモデルが存在しています。あなたのユースケースではどのモデルが最適なのでしょうか？
- **生成AIモデルの文脈付け**: 生成AIモデルの選定が完了したら、ベクトルDBを用いるなどしてRAGを構築する必要があります。
- **アプリのデプロイと監視**: RAGを作って終わりではありません。RAGアプリケーションがリクエストに対して適切なレスポンスをしているのかを監視し、必要に応じてモデルの見直しを行う必要があります。

## 生成AIモデルの選択

一つの企業において複数のRAGアプリケーションを構築するケースも増えてきています。そうなると、それぞれのアプリケーションで使用しているLLMの管理も課題になってきます。資格情報やレート制限の管理など。Databricksの[モデルサービング](https://docs.databricks.com/ja/machine-learning/model-serving/index.html)の機能を用いることで、モデルプロバイダーのLLM、オープンソースのLLM、お客様自身が構築したLLMを効率的に管理、運用できるようになります。これは一種のLLMに対するゲートウェイとして動作し、資格情報やレート制限を一元管理できるようになります。
![Screenshot 2024-05-23 at 20.37.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/f1a779af-04a3-c980-3340-206271d789bf.png)

この他にも、RAGの構築では欠かせないプロンプトエンジニアリングに役立つ機能も提供しています。これが[AI Playground](https://docs.databricks.com/ja/large-language-models/ai-playground.html)です。AI Playgroundでは、様々なLLMに対して同時に同じプロンプトを投入することができます。これによってレスポンスを直接比較することができるようになります。
![Screenshot 2024-05-23 at 20.40.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/a2781a25-0228-97d3-13a5-9e2fc91e84f9.png)

## 生成AIモデルの文脈付け

RAGにおいては、クエリーにヒットしたドキュメントとクエリーを組み合わせてレスポンスを生成します。この際、クエリーにヒットする文書を取得する際に重要な役割を担うのがベクトルデータベースです。すでにFAISSやChromaを使われているかもしれませんが、Databricks謹製のベクトルデータベースもあります。それが、[Vector Search](https://docs.databricks.com/ja/generative-ai/vector-search.html)です。
![Screenshot 2024-05-23 at 20.44.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/cc24f5c7-726b-9d5e-d70c-87b0749a618f.png)

このVector Searchの良いところは、ソーステーブルの更新に合わせてベクトルDBを自動で更新できる機能だったり、Databricks環境に組み込まれているので既にお持ちのデータをベースにして容易にRAGを構築できるということです。

## アプリのデプロイと監視

RAGを作って終わりではありません(自分自身、この論調頻繁に使ってますが)。そのアプリケーションが期待した通りに動作しているのかどうかを監視する必要があります。
![Screenshot 2024-05-23 at 20.48.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/f57bad79-c445-a15b-9f82-4948e793afc4.png)

そのためには、上述のモデルサービングに推論テーブルと[レイクハウスモニタリング](https://docs.databricks.com/ja/machine-learning/model-serving/inference-tables.html)を組み合わせることができます。この機能を活用することで、RAGアプリケーションへの入力とそれに対するレスポンスを記録することができ、必要に応じてアクションを講じることができるようになります。

# デモ

ここまで資料での説明でしたので、このあとは実機デモを行いました。以下の記事に記載されている内容です。

https://qiita.com/taka_yayoi/items/f174599e4721e51e9e1d

https://qiita.com/taka_yayoi/items/cd23bf48142db120e70d

LTということでしたので、これで9分弱でした。

### はじめてのDatabricks

[はじめてのDatabricks](https://qiita.com/taka_yayoi/items/8dc72d083edb879a5e5d)

### Databricks無料トライアル

[Databricks無料トライアル](https://databricks.com/jp/try-databricks)