🚀

俺だけの ChatBot環境 を作っている話

2023/12/12に公開

この記事はmob Advent Calendar 12日目の記事です。

ChatBot環境を構築してみたので紹介します。

前提

LangChain は使わずに作りました。
普段は モバイルアプリ開発がメインで、クラウドも自分の手で触る機会はあんまりない前提でみてください。

何作ってるの?

データソースをアップロードして RAG を構築できて、 Slack や LINE でやり取りできる自分用のチャットボットが欲しいなと思ったのでがっつり作ってみました。まだ未実装部分も残っているのですが、紹介してみます。

ダッシュボード

ダッシュボードでGoogleログイン認証で、このダッシュボードの中で ChatBotの作成をできる。

ChatBot を作成したら下記のことができるようになってる。

  • ChatBotとの会話
  • モデルの選択
  • デフォルトプロンプトの設定
  • データソースのアップロード (RAGに使われる)
  • Slack連携の設定
  • LINE連携の設定

(未実装部分)

  • ChatBotとの会話部分 ( Slack や LINE 動いてるから後回し )
  • テキスト以外の画像やPDFやWEB URLなどのデータソースのアップロード ( 画面つくって、API呼ぶだけですぐ作れるが、いまのところテキストばっかり使っているから後回し )

Slack や LINE 連携

ダッシュボードで設定したら、Slack や LINE でチャットボットとやり取りできるようになる。

(未実装部分)

  • RAG環境との連携 ( RAG環境構築して満足してしまってる。詰めが甘い。 )

RAG環境

表にはでてこないが構築できてる。データソースのアップロードもできる。

(未実装部分)

  • なし。

ちなみに作り方はここにメモりました。

https://zenn.dev/mobdev/books/da63d738595c0a

インフラ構成

インフラ構成はこんな感じになりました。線が重なって見辛いところはごめんなさい。

  • 全体方針
    • なるべくサーバーレス、Lambda に寄せる
    • AWSコンソールは直接触らない。 IaC を意識する
    • ただ直接 Cloud Formation は触りたくないので、 Amplify や Serverless Framework などを使う
  • Slack連携、LINE連携
    • Amplify だと SQS の設定が厳しいため、Serverless Framework を用いて、 Lambda, SQS, DynamoDB を設定する
  • ダッシュボードAPI
    • Slack連携、LINE連携と揃えるため、 Serverless Framework を用いて、 Lambda, DynamoDBを設定する
  • ダッシュボードフロント
    • フロントエンドのデプロイは Serverless Framework でやると、もう Cloud Formation を書いてるのと変わらないので、ここは Amplify CLI を用いる
    • 認証は Firebase で行う
  • Swagger-UI
    • ダッシュボードフロントと揃えてAmplify CLI を用いる
  • RAG
    • 本当はここも Serverless Framework でやりきりたかったが、 RAG を自作する以上は 類似検索ができないDyanmoDB では厳しい
      • (ついこの前、発表された DynamoDB でも Vector Search みたいな発表があったけど、構築した時はその前だったので... )
    • 今回は RDS (Postgress)でやることにする
    • VPC Lambda を使って RDS Proxy みたいな手もあるけど、ここまでいくともう Serverless Framework でやる意味うすれる
    • ということで、 RDS が使えて、Amplify みたいにサクッとデプロイできる Elastic Beanstalk にした

各コンポーネントでの技術選定について

  • 全体方針
    • なるべく Kotlin に寄せて、マルチモジュールで実装する
  • Slack連携
    • Kotlin, Slack Bolt
  • Line連携
    • Kotlin, Line SDK
  • ダッシュボード API
    • Kotlin, micronaut
    • Ktor も頑張れば使えるが、 micronaut は serverless friendly なのでこれににした
  • RAG
    • Kotlin, Ktor
    • EC2でガッツリやるので Ktor に
  • ダッシュボード フロント
    • TypeScript, Next.js, MUI
    • Kotlin で KVision や Compose など考えたけど、どれもまだ正直実用には耐えないなと思った
      • 一回 KVision でだいたい作ってみてたけど、 脳内で作りたいものを HTMLやJavaScript で考えて、それを KVision に変換してみたいな感じで(しかも癖ある)、無駄な変換作業が発生してて、これだったらもう初めから Kotlint じゃない方がええわって思って、最終的に Next.js にした
    • Next.js + SSG で S3 でホスティング

ダッシュボードのフロント部分以外は全てKotlinで実装することができました。現状モジュール構成はこうなっています。

それぞれ説明します。

モジュール名 説明
chatbot チャットボット部分のcore機能。OpenAIの機能の呼び出しや FunctionCall 部分を実装してる
dashboard:api ダッシュボードのAPIを実装している
dashboard:ragclient rag のAPI の openapi.yaml からモデルを自動生成したものが格納されるモジュール
datastore dashboard:api や slack, line などが使用する。データベースへのアクセス部分を実装している
line LINE 連携用 Lambda の Handler を実装している
rag RAG を Ktor で実装し RAG用の API を提供している。 dashboard:api や slack, lineから使われる。
slack Slack 連携用 Lambda の Handler を実装している
support:aws AWS系の共通処理

おわりに

大雑把に作っているものを紹介しました。

作っている間に OpenAI の方からは Assistants API が発表されて、もっと早く発表されてれば RAG を自分で作る必要ないじゃんってなったり、

AWSの方からは Amazon Q や Bedrock の発表に、さらには Vector Search for DynamoDB が発表されたりと、これまた自分で作る必要ないし、作るとしても RAG も Serverless に寄せれるじゃんってなったり、

と、いろいろありました。しかし、自分で実装することで得られる知識をたくさん得ることができたので満足しております。

Discussion