自社データ × ChatGPTで社内AIを構築するRAG ツール｜Doox β版をリリースしました

TLDR

• 社内のデータを元に質問への回答を LLM が生成する仕組み（RAG）を構築するためのサービスを開発しました。
• β 版として無料で公開しているので是非使ってみてください。
• サーバーレスな構成で Next.js を動かしている。技術のキャッチアップは大変だ。

背景

• 仕事をしていると社内の規定 / 製品情報 / 過去の履歴 .. などに関する問い合わせは日常的に発生するものだし、その工数は結構ある。通常は Wiki を作ってナレッジを共有するが、結局「近い人や担当に聞く」という行為はなかなか減らない。
• 色々な企業が、社内のデータを元に質問への回答を LLM が生成する仕組み（RAG）を独自に開発しているようで、技術ブログとかに書いている方も多い。
• 社内向け RAG の構築を SaaS プロダクトで提供したら各社の社内の問い合わせ工数と独自に RAG を構築するコストを下げられて嬉しいんじゃないか? という仮説。

作ったもの

ということで、Doox ｜自社データで学習した ChatGPT が社内問合せを自動化 というサービスを開発しました。以下のようなことができます。

• 組織を作り、社員など所属するユーザーを招待する
• チャットボットを作成し、社内データなどのソース（LLM に渡す外部情報）を登録する。現在は以下に対応しています
  • 各種テキストファイル
  • Notion API 経由の Notion Page の情報
  • 指定した URL の情報
• 所属するユーザーが Web の UI 上でチャットボットに質問する
• 質問の回答にはどのソースを元に回答されたかが表示される
• ユーザーの利用ログを見る

実現したいこと

最低限前述したことができるようにはなっているのですが、以下のような点を強化してきたいと考えています。

高い回答の精度

RAG の精度の良し悪しには様々な要因があり、外部情報の整理の仕方 / 外部情報の選択の方法 / LLM への渡し方 など各レイヤーでのチューニングや手法があります。
まだまだやれることは多くあるので、実際に利用されたユーザーからフィードバックやご意見をいただきながら改善していきたいと考えています。

継続的に利用され組織になじむ

「なくてもクリティカルではない」ツールは導入してみてもなかなか継続的に利用されずに使われなくなる、といったことが起こりがちだと思っています。
とはいえ社内の情報共有の難しさや問い合わせ対応などの工数はいずれの企業でも起こり得る課題ではあるので、組織のみなさんが継続的に利用できるような仕掛けになるべきだと考えています。
具体的には以下のようなアップデートを検討しています。

• ソースの多様化
  社内情報は様々な場所にちらばっています。Microsoft や Google のドライブ、Wiki ツール、チャットツール、各種 SaaS .. など、なるべくこれらをそのままソースとして活用できるようにしていきたいです。
  さらに、そういったソースが日々更新されることを考えると、更新された差分に追従していけるような仕組みも必要だと感じています。
• 利用シーンを増やす
  利用者の業務にスムーズに統合されることを考えると、普段社内で使っているチャットツールの中でチャットボットと会話できると利便性が上がると考えています。
• 回答の評価
  例えばユーザーによるチャットボットの回答の評価（Good / Bad）を可能にすることで、管理者によるソースの見直しやプロンプトの改善を行い、ひいては組織内の情報の管理が改善されると良いと考えています。

始めやすくて使いやすい

SaaS プロダクトは通常利用開始までに 問い合わせ → 商談 → (トライアル) → 申し込み といったプロセスを経ますが、複数のツールを比較検討する際は候補が多くなるほど時間がかかりますし、とりあえず使ってみて判断したいという方には面倒だと感じます。そのため今回はいきなり登録して使い始められるようにしました。https://my.doox.app/ja/signup から登録できます。
一旦 β 版として公開していますが正式版をリリースした後もこれは継続していく予定です。

β 版

どんな風に使ってもらえるかを把握したく、まずは β 版として以下の通り運営していきます。

• 無料で利用できる
• 利用するモデルは GPT-3.5 Turbo

お問い合わせ

ご利用に際してのお問い合わせはフォーム からお送りください。
ご質問、ご意見、フィードバック、ご要望 .. などなんでも受け付けています。

使った技術要素と所感

Qiita に投稿するので技術的なことも書いておきます。以下は今回利用した技術スタックの抜粋と所感です。

SST

AWS 用のサーバーレスフレームワーク。内側では CDK が使われている。結構面白いのでつらつらと書いていきます。

• サーバーレスに関して、安くて保守運用が楽でスケーラビリティが高いというのはそうだなと思う。安さについて、特に EC2 や Fargate で動かしていた Next.js が Lambda に乗るのが大きい。DB は DynamoDB にできるなら安くなりそう。
• Resource Binding という機構でアプリケーションから簡単に RDS や S3 に接続できるようになる。また Config という環境変数やシークレットを管理するための機構があり、これを bind することでアプリケーションから簡単にシークレットにアクセスできる。もし bind しているシークレットが Parameter Store にセットされていない場合はビルド時に気づける、といった利点もある。
• sst bind というコマンドがありこれはびっくりした。例えばローカルで Next.js の開発しているときに sst bind next dev で動かすと bind しているリソースが利用されるので、RDS を bind しておけばローカルに DB を立てなくても開発ができてしまう。ローカルで動いている Next.js が AWS のリソースを利用する AWS ズブズブ体験は新しかった。
• まだ使っていないのだけどLive Lambda Developmentというものもあるようで、AWS Lambda に送ったリクエストがローカルにプロキシされてローカルのコードが実行されるみたい。これはさらに AWS ズブズブなんじゃないかと想像している。Lambda の開発はLocalStackで環境をエミュレートすることが多いイメージだけど使いにくさもあるため、代替案になりそう。
• ローカル開発時も AWS のリソースを利用するとなるとチーム開発はどう考えるのかと疑問が湧くが、Working With Your Team には、本番環境や検証環境同様開発者にも専用の環境（AWS Account）を立てる というパターンの説明があり、ここまでやったらまあできるよねという感じ。SST をガッツリ使っている企業ではどうしているのだろう。
• Custom Domainsの設定も楽だった。CDK で書くときは HostedZone、各種 Record、Certificate、CloudFront との紐づけ .. などを記述しないといけないが、全部裏側でやってくれる。サブドメインの利用もすんなりいった。
• Consoleという、リソースの一覧やログを取得できるサービスが提供されている。Labmda のログはデフォルトだと同じ log group に送信されるため辛いのだが、 SST の機能で page 毎に log group を分けて出力してくれてそれをこの Console で見れる。Console が更に強化されてリクエスト数とかリソース状況とかもモニタリングできるようになったら素敵やなとか思っている。

という感じで SST は CDK と比較してもシンプルだったり、開発者向けの様々な便利機能がある。なのですげーなと思っていたのだが Moving away from CDK という記事があり、v3 では v2 までの CDK + CloudFormation を廃止して Pulumi + Terraform を利用していくとのこと。この記事に書いてある CDK + CloudFormation の辛さは共感できるものが多いし、AWS 以外のサーバーレスの開発が進んでいるプロバイダーにも対応するべくとのことでこの辺も進んでいるようです。

Next.js | App Router

React ベースの Web アプリケーションフレームワーク。推奨されている App Router で開発しました。

• 基本的に開発効率を上げてくれる。フロントエンドとバックエンドをまとめて書けたりルーティングが楽だったりとメリットが大きい。
• Server Components や Server Actions に触れると、全体的にフロントエンドのフレームワークだったのが Web 全体のフレームワークに寄っているのかという印象を受ける。ただその分どの処理がフロント/バックどっちで動いているかとか、そのためにどういう書き方があるのかとかをちゃんと理解/意識しないといけないと感じる。
• Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約 を読んで「Too much magic」は fetch と cache は確かにハマりがちなので頷けるし「Complexity」はそうよねという感じ。前提として React の理解も求められるのでキャッチアップのお勉強はほんま大変ざます。
• 直接は関係ないけど shadcn/ui という Radix UI と Tailwind CSS ベースの UI コンポーネントライブラリを使った。

Drizzle ORM

TypeScript ORM。最初は Prisma を検討していましたが Drizzle ORM を利用しました。

• schema.ts に書いたものが型定義に直結する。自分で型を書く必要が減るので助かる。この辺は Prisma も同等だが、Prisma は schema.prisma のような専用の拡張子のファイルを作成し、これを元に型を生成する一手間が加わる。
• Migration 機能が備わっていて Migration 用の .sql ファイルを生成してくれる。Migration は SST の Deploy の流れに組み込みたかった。Migration の実行自体は Lambda で行いたく、Prisma だとなかなか相性が悪いようで、実装サンプルなどを見ても大変そうだった。そもそも Prisma は Lambda 上で Migration することを推奨していないよう。
• SST との相性でいうと RDS Constructs は Kyselyによる Migration をサポートしているが、Kysely では Migration ファイルを自分で書かないといけなかったのが難点だった。
• 後述する LLM の箇所で Python を動かす必要があった場合、Prisma はPython 用の Clientがあるので Prisma を使うということになっていたかも。
• drizzle-zod というものもあり、Drizzle ORM のスキーマから Zod のスキーマを作ることができた。バリデーションまで一気通貫でつながるのが良い。
• Drizzle Studio という、ブラウザ上で DB 内のデータを表示したり SQL を発行したりするツールもあり、特にリレーションをたどってデータを簡単に見れるのが良い。

LlamaIndex.TS

RAG を作るので LLM（ChatGPT）を操作するための方法を探りました。

• 結論、LlamaIndex.TS という LlamaIndex の Typescript 版があり、それを分解しながら利用している。Python の方の LlamaIndex と比べると機能が少なかったりLlama Hubがなかったりと Python のほうが本家なのは否めないが、インフラ - バックエンド - フロントエンドの全体が Typescript で全て書けることは開発スピードや保守を考えるとやはり重視される。
• create-llama を使うと Next.js で作られた RAG システムのサンプルを動かすことができる。大変参考になった。
• LangChain を使わない という声がよく聞かれる。LangChain はしっかり触っていないのだが LlamaIndex もまあまあ複雑で、単純なことをやっている箇所でも中身を理解しようと処理を追うといくつものファイルを読んでいく必要があった。
• 様々な形式のドキュメントのロード、インデクシング、複数のモデル、チャットやエージェントといったタスク .. などに対応するために様々な概念とリソースが入り乱れ、その中から必要なものを抽出して把握するのが大変。
• LLM 周りは今後も継続的に改善強化していきたいので技術選定やライブラリとの付き合い方は試行錯誤が続きそう。

Astro

サービスサイト は Astro で構築しています。

• サービスサイトは通常記事・機能の紹介・事例 .. といったコンテンツをリッチにしたくなる。そうなると静的サイトジェネレータ（Astro のサイトでは content-driven websites という謳い文句で書かれている）を使いたい。
• SST に AstroSite という Constructがあり、SST で Astro サイトを AWS にデプロイする のも簡単にできた。
• .md ファイルを配置してフロントマターで meta 情報とかを渡して .. ということは Next.js でもライブラリを使えばできそうなので、分ける必然性はないと思いつつ、アプリケーションとは機能が異なりマーケティングに振っているサービスサイトは別で作るよねという考えがある。そもそも管理する主体も分かれると考えるとまとめて保守性を上げる、みたいなことはあまり意識しなくてよいかなとか。
• 最近Astro DBがリリースされたのでフォームに入るデータはそこで管理しようかと検討したが、結局Formsparkという Headless なフォームサービスを利用。フォームサービスは（も）月$10~とかのサブスクリプションが基本だが、このサービスは 50,000 Submission に対して$25（定価$50）と、枠を買う形式なのが良い（そして珍しい）