独自のオープンソースChatGPT風チャットボットを作りたいなら
(hacks.mozilla.org)- Mozillaイノベーショングループの少人数チームは、1週間のハッカソンで社内向けチャットボットのプロトタイプを作り、サードパーティAPIなしでMozillaクラウド内でオープンソースLLMを運用する構成を試した
- 外部AI SaaSを排除した結果、MozillaのGCPアカウント内に直接サーバーを構築する必要があり、Hugging Face text-generation-inferenceの代わりに、より早く動かせるllama.cppへ切り替えた
- モデル選定は品質より先にライセンスとランタイム互換性に縛られ、商用利用可能なLLaMA系候補を手動評価した末にLLaMA 2を選んだ
- 社内知識の連携は埋め込みとベクトル検索で実装し、all-mpnet-base-v2、SentenceTransformers、LangChain、FAISSを組み合わせて社内Wikiの一部を回答に活用した
- プロトタイプは完成したが、信頼できるオープンソースチャットボットを作るには、ホスティング、モデル評価、バイアス、プロンプト、UIまで自分たちで判断すべき領域が多い
Mozillaが作ろうとした社内チャットボット
- Mozillaは、AIシステムが使うデータと意思決定に透明性があり、ユーザーのプライバシー・主体性・安全を尊重し、バイアスを減らして公平性を高めるべきだというtrustworthy AI原則を掲げている
- 多くのユーザーが最新AIを体験する主要な経路は、ChatGPTやBardのような生成AIチャットボットであり、支配的なサービスは強力なテック企業によって運営され、独占的技術に依存していることが多い
- Mozillaは、オープンソースこそがユーザーを力づけ、透明性を高め、技術が少数企業の世界観や財務的動機だけに従って発展しないようにする方法だと考えている
- ハッカソンの直接的な目標は、次の条件を満たす社内チャットボットのプロトタイプを作ることだった
- Mozillaのクラウドインフラ上で完全に動作し、サードパーティAPIやサービスに依存しない
- 無料のオープンソースLLMとツールで構成される
- Mozilla Manifestoとtrustworthy AI原則を反映する
- 一部のMozilla社内知識を統合し、社員の質問に答えられる
ホスティング: 外部SaaSではなく独自のGCPサーバー
- 機械学習アプリのホスティングサービスは多いが、MLOpsは難しく、設定が悪いAIアプリは遅い、高価、低品質になりうる
- チームの明示的な目標は、外部当事者が利用内容を聞いたり、ユーザーデータを収集したり、利用状況をのぞき見したりできないセキュリティとプライバシーだった
- そのためサードパーティのAI SaaSホスティングは使わず、Mozilla既存のGoogle Cloud Platformアカウント内に独自の仮想サーバーを構成した
- この選択により、MLOpsを自分たちで引き受ける代わりに、システムをMozillaの管理下に置き、非公開に保てた
ランタイム: Hugging Faceからllama.cppへ切り替え
- LLMアプリにはモデルを実行するランタイムエンジンが必要で、チームは時間制約のため llama.cpp とHugging Faceエコシステムに絞って検討した
- Hugging Faceはモデルライブラリ、ドキュメント、チュートリアル、ホスティング推論APIを提供している
- チームはホスティングAPIの代わりに、オープンソースの text-generation-inference を試した
- text-generation-inferenceは複数のモデルとモデルアーキテクチャをサポートし、Dockerデプロイも可能だが、サーバー実行までの環境設定の問題が大きかった
- GPU高速化ツールのため、サーバーのOS、ハードウェア、ドライバーの組み合わせが合っている必要があった
- NVIDIA CUDA toolkit が必要だった
- 1日のかなりの部分を設定に費やし、起動後も出力は予想より遅く、結果も良くなかった
- 時間制約のため、Georgi Gerganov が始めたllama.cppへ方針転換した
- llama.cppは特定のLLM系統をコンシューマー向けハードウェアで簡単に動かせるようにする
- 高価なGPUではなくCPUが使え、特にM1・M2のようなApple Silicon CPUで比較的小さな最新オープンソースモデルをうまく動かせる
- llama-cpp-python は OpenAI API specification の実装を提供し、ChatGPTの代わりに自前のLLMを差し込みやすい
- 最終的に、CUDAのバージョンや高価なホスティングGPUを扱う代わりに、AMDマルチコアCPU仮想サーバーでllama.cppを素早く実行した
モデル選択: ライセンスとアーキテクチャの制約
- llama.cppを選んだことで、使えるモデルはLLaMAアーキテクチャベースのモデルに絞られた
- Facebookは2022年末にLLaMAを発表し、LLaMAはモデルデータとアーキテクチャに分けて考えられる
- LLaMAアーキテクチャはオープンソースとして公開されたが、モデルデータであるweightsはオープンソースではなかった
- weightsの利用には申請による許可が必要で、非商用目的に制限されていた
- LLaMAは、Stanfordの Alpaca やLMSYSの Vicuna のような多くのモデル革新を促した
- しかしこれらのモデルはFacebookのweightsを使って開発されたため、元のweightsの法的制限を引き継いでいる
- 商用目的には使えないため、Mozillaチームの候補から外れた
- LLaMAアーキテクチャ自体はオープンソースコードなので、他グループがゼロからモデルを学習し、MIT、Apache 2.0、Creative Commonsライセンスで公開することは可能だった
- MPT、Falcon、Open Assistantのような別アーキテクチャベースのモデルは当時llama.cppで動かなかったため、候補から外れた
モデル品質、バイアス、安全性の評価
- モデル選択はライセンスと互換性だけでなく、信頼性にも直接影響する
- LLMは膨大なデータで学習され、特定の振る舞いや出力を作るために追加入力でファインチューニングされる
- このデータ選定自体がキュレーションであり、さまざまなバイアスを含んでいる
- モデルは学習ソースに応じて異なる特性を示す
- 幻覚のように無意味な回答を作り出すことがある
- 有害コンテンツ、誤情報、危険または有害な情報共有につながることがある
- 概念や人々の集団に対するバイアスを示すことがある
- オンライン学習資料の大半が英語であることは、ツールの利用可能性や触れる世界観に影響する
- Hugging Faceの Open LLM leaderboard のように性能と品質を評価する資料はあるが、出所やバイアスを基準にモデルを比較するのは依然として難しい
- Mozillaチームは、商用利用可能でLLaMAアーキテクチャ上で動くオープンモデルに範囲を絞ったうえで、毒性・バイアス・誤情報・危険コンテンツへの耐性を見るため、複数の質問を投げる手動評価を行った
- 最終選択はFacebookのLLaMA 2だったが、限られた時間内での評価方法論には欠陥がある可能性があり、ライセンス条件にも完全には納得していないため、推奨と受け取るべきではない
社内知識の統合: 埋め込みとベクトル検索
- Mozillaチームは、社員はアクセスできるが一般的なLLMは知らないMozilla社内データをチャットボットに一部接続しようとした
- 選んだ方法は、外部文書を回答生成に活用する埋め込みとベクトル検索だった
- 基本的な流れは次の通り
- 利用するデータを元の保存先から取得し、埋め込みモデルで変換する
- 埋め込みをチャットボットがアクセスできるベクトルデータベースに索引化する
- ユーザーが質問すると、チャットボットがベクトルデータベースから関連内容を検索する
- 検索された関連内容を基本モデルのコンテキストウィンドウに入れ、回答生成に使う
- チームはデータ統制を維持するため、サードパーティの埋め込みサービスやベクトルデータベースを使わなかった
- Pythonで自前実装したソリューションでは、次のツールを使った
- all-mpnet-base-v2 埋め込みモデル
- SentenceTransformers 埋め込みライブラリ
- LangChain
- FAISS ベクトルデータベース
- 社内Wikiの文書を数件入れただけなので範囲は限定的だったが、概念実証としては機能した
プロンプトエンジニアリングとコンテキストウィンドウ
- LLMは毎回、以前の会話やユーザーを記憶していない状態で始まるため、チャットボットが会話を続けるには開発者がメモリ管理を行う必要がある
- システムプロンプトは、チャットボットの機能と振る舞いを平文で指定する初期指示文である
- Mozillaチームは、チャットボットがMozilla Manifesto、敬意ある振る舞い、非差別ポリシーに従うようシステムプロンプトを設計した
- アポロ月面着陸捏造説について尋ねる質問では、誤情報回答を拒否する指示があると、月面着陸は捏造ではなかったと答えた
- 同じモデルで誤情報禁止の文言を外すと、一般的なアポロ否定論の一覧を提示した
- システムプロンプトには、Mozilla Assistantという名前、Mozilla Manifesto原則の順守、敬意・専門性・包摂性、有害・不道徳・非倫理的・違法の可能性がある行為の拒否、誤情報と差別的言語の禁止が含まれていた
- すべてのLLMには、現在の会話で記憶できる最大長であるコンテキストウィンドウがある
- ほとんどは学習時点で決まり、後から変えられない
- コンテキストウィンドウが大きいほど、以前の質問と回答をより長く参照できる
- ベクトル検索から取得したより大きなコンテンツ断片も入れられる
- LLaMA 2のコンテキストウィンドウは4096トークン、おおよそ3000語だった
- チームはコンテキストウィンドウを節約するためシステムプロンプトの長さを繰り返し削り、今後はより大きなコンテキストウィンドウをサポートするモデルを検討する予定だ
オーケストレーションとUIの選択
- チャットボット全体には、エージェントへのプロンプト注入、コンテキストウィンドウ管理、社内コンテンツの埋め込み、LLM呼び出しと応答処理など、複数レイヤーを調整するオーケストレーションが必要になる
- LLM分野の代表的ツールである LangChain は強力で柔軟だが、複雑さも大きい
- MozillaチームはLangChainを埋め込みとベクトル検索にだけ最小限使用した
- 短期で制約の大きいプロジェクトだったため、大半は自作のPythonコードで処理した
- もっと時間があれば、すべてを手作業ではやらなかった可能性が高い
- UIには、会話表示、過去スレッドの追跡、一定でない速度で出力されるバックエンド処理など、見た目以上に多くの機能が必要だ
- オープンソースのチャットボットUIである chatbot-ui はOpenAI APIを実装しており、ChatGPT UIの代替として使え、自前のLLMシステムのフロントエンドとしても活用しやすい
- Mozillaチームは通常ならchatbot-uiのようなプロジェクトを使ったはずだが、社内実験用チャットボットコードであるCompanionとその作者が同席していたため、これをUIとして使った
- CompanionのおかげでUIを素早く反復・実験できた
ハッカソンの結果と残された課題
- ハッカソン終了時点で、Mozillaチームは社内向けプロトタイプチャットボットを完成させた
- Mozilla内部で完全にホストされる
- 安全かつ非公開で使える
- 振る舞いにMozillaの価値観を反映しようとしている
- 目標達成の過程では、多くの難しい選択と妥協が必要だった
- 学んだことは3点に整理できる
- オープンソースチャットボットはまだ進化の途中で、決めるべきことが多く、明確なドキュメントが不足し、失敗の仕方も多い
- 生の性能以外の基準でモデルを評価・選択するのは難しすぎて、信頼できるAIアプリにとって正しい選択をするのも難しい
- 現時点では、効果的なプロンプトエンジニアリングがチャットボット成功の重要要素である
- Mozillaは、開発者がオープンソース機械学習エコシステムにより簡単に入れる方法を作り始めており、ハッカソンの成果をもとにオープンソースコミュニティへ貢献しようとしている
- オープンソースLLMが広く提供される状況で、より良い未来を作るには、誰もが集団的かつ能動的にその形成へ参加する必要がある
1件のコメント
Hacker Newsの意見
企業に連絡しようとするのは、サイトで答えを見つけられなかったか、Webサイトではできないことを担当者に頼まなければならないからです。たとえばサービスの解約のようなものです。
しゃべるFAQページは、不十分なユーザー体験を埋めようとする試みに見えますし、企業が私の探している情報をWebサイトに載せていないなら、チャットボットにも入れていない可能性が高いです。
ただし、チャットボットが適切な担当者につないでくれる点では役に立つかもしれませんが、人間の助けを得る前の障壁として置くのはアンチパターンだと思います。
そのため、サポートチームに連絡する前に、説明内容に基づいて関連する回答をすすめる質問を大量に表示するサイトが多く、AWSサポートもそうしています。
ボットは苛立たしいこともありますが、カスタマーサポートのコストを大きく下げることもできます。ユーザー体験がよく、ボットが答えられなければすぐに担当者につながるなら賛成です。もちろん、ボットがハルシネーションを起こして偽情報を言わないことが前提です。
質問に答えられるサポート要員がいないのでチャットボットを使っています。ボットがなければ何もないのと同じです。
その代わり、ボットのログを監視しています。製品やWebサイトに機能が欠けていれば追加し、その後のユーザーが完全にセルフサービスで処理できるようにしています。
ユーザーはいつでもアカウントを解約したり返金を受けたりできます。
こうした質問には大規模言語モデルがほぼ完璧に合っています。ただ、ボットが直接答えられない質問をもっと上手に検知できるよう改善されるとよいと思います。
もちろん、チャットボットが人間やよく書かれたFAQの代わりになれる場合もあります。しかし、こうした自己満足は、サポートがひどい主な理由を見落としています。サポートはそもそもそう設計されているからです。
「電話でしか解約できない」を例にすると、加入やアップセルのほうが技術的には難しい問題なのに、はるかに簡単にできるようになっています。短期的なコストや損失に見える行動には摩擦を追加するのが目的です。摩擦があると多くの人が諦めたり先延ばしにしたりすることを、企業は知っています。
これはナッジであり、ダークパターンの典型です。Cookieバナーで「すべて拒否」がたいてい隠されているのを見ればわかります。ナッジは、企業が法律を順守しているように見せながら、ユーザーの時間と注意をコストにして全体的な効果を回避させます。
チャットボットはサポート迷路に追加されたもう一つの層にすぎません。
すべての企業がチャットボットサポートを持つ未来にはまったく期待していません。
すでにかなり一般的で苛立たしいものですが、それでも半分くらいは質問を理解していないとわかるので、人間に抜けられる逃げ道はあります。
「コンピューターが駄目だと言っています」の時代はすでに来ています。
付け加えると、否定的で話題から外れたことだけを言いたいわけではなく、記事自体はかなり良さそうです。作者には拍手を送ります。エンジニアリングは素晴らしいですが、実際の使われ方が嫌なだけです。
チャットボットは万能ではありませんが、不要なノイズをかなり減らせます。必要なのは、特定のドメインで平均的なユーザーが尋ねる基本的な質問に答えられる何かです。
前の職場はかなり大きな会社で、Confluenceインスタンスが非常に巨大でした。そこで情報を探すのに多くの時間を無駄にしました。あのすべての情報で学習したチャットボットがあれば、かなり有用だったと思います。
Amazonが思い浮かびます。長年の顧客で、最近、不良のコンピューター周辺機器を受け取りました。
チャットボットに問題を短く説明すると、すぐに新しい注文が入り、既に受け取った品物はそのまま保管してよく、追加費用なしで優先配送されるという返答がありました。
それだけで、翌日に届いて問題なく動作しました。
もちろん、私が古くからの顧客で、すでに多くのお金を使っている人間だとわかっていたのでしょうが、想像できる限りほぼ最も苦痛のない体験でした。複数のWebページで選択肢をクリックしながら進めるより、ずっと良かったです。
「裁判長、私の弁論全体はたわごとで、存在しない法条文まで引用しましたが、それはChatGPTを使ったからです」— 実際にあった弁護士の話で、しかも弁護士資格を剥奪されることすらありませんでした。
「私たちが知り、愛していたWebをすでに変えつつある」という表現に難癖をつけるのは、明らかに本題から外れますが、今のWebを私は愛していません。
Webはますます少数の企業に支配されています。どのコンテンツが表示されるか（meta、google）、どのメールがスパムフィルターに入るか（ms、google）を彼らが決めています。
今のWebは愛とはほど遠いものです。私をフォローすると選んだ人たちにさえ届くために、戦い続けなければなりません。
結局、私のコミュニケーションの大半は現実世界か非公開チャットで行われています。ついでに、ビジネス用messengerがどれほどひどく不安定かも言いたいです。
今日のWebには何かが起こる必要があります。何が、どのようにかはわかりませんが、変化は間違いなく歓迎します。
それでも、人々がフォローできる他のあらゆる方法も提供すべきですが、RSSフィードを宣伝すれば人々は使い始めるかもしれません。
技術的にやってみたいなら、ActivityPubブリッジを設定してソーシャルメディアでもフォローできるようにできます。Wordpressを使っているなら、https://wordpress.org/plugins/activitypub/があります。
トップレベルのコメントの大半がチャットボットに否定的なようなので言っておくと、職場には実際に優れたチャットボットがあった。
私にとっては Confluence を検索するよりずっと良かったし、残りの休暇日数や勤務時間がどれくらい進んでいる／遅れているかといった 動的データ に関する質問にも答えられた。
記憶では、裏側で技術を巧みに使っていて、自然言語で聞いてもたいてい理解してくれた。
Confluence の検索は完全に冗談で、しかも質の悪い冗談だ。
顧客がチャットボットを使うのは、ウェブサイトの UI が分かりにくい からだ。情報を得たいのに、その方法が見つからない。
以前は Google で「サービス名 + 電話番号」や「サービス名 + 解約」を検索していた。
10回中9回は、ウェブサイト側が電話番号を簡単に教えたり、解約を簡単にさせたりしようとしていない。そもそも隠している行動を顧客にしてほしくないのなら、チャットボットはいったい何のためにあるのか？
チャットボット熱の中で働いていたが、顧客を本当に助ける意思がないなら、こちらにできることはあまりない、と複数の顧客企業に言わなければならなかった。
少なくとも人を相手にする企業において、チャットボットの本当の目標は、Web とモバイルアプリの UI を最初の接点から押しのけることだ。
ユーザーは単一のアイデンティティで、SMS やそれに近いチャット、あるいは電話を通じて企業と会話できるべきだ。
Web とモバイルアプリは、基本的なコミュニケーション手段を補助する二次、三次のユーティリティにすぎない。
企業が以前これを実現できなかった理由は、言語理解の精度 が十分ではなかったからだ。大規模言語モデルがその限界を解決した。
ボットが経験則でオペレーターとのやり取りを少し減らすのはおまけだ。より良い大規模言語モデルのおかげで、転送回避率も少しずつ大きくなっている。
右下に張り付いている迷惑なチャットボットウィジェットは、単一の電話番号を提供し、そこ経由のコミュニケーションがスムーズになるまでの暫定策だ。
最後に、タイトルは誤解を招く。オープンソースのチャットボットを作るということではなく、コミュニティとより速い AI の進歩のために、クローズド／商用ツールではなく オープンソースライブラリ だけを使ってチャットボットを作ろうという話だ。
「Mozilla の既存の Google Cloud Platform（GCP）アカウント内に自前の仮想サーバーを立てた。そうすることで、事実上 MLOps を自分たちでやることにしたわけだ。しかし、システムが非公開で完全に自分たちの管理下にあるという確信を持って進めることができた」とあるが、Google のインフラ内にサーバーを立てることが、どうして 非公開 で Mozilla の完全な管理下にあると言えるのか？
ベアメタルでセルフホスティングする方法まで説明するのはチャットボット構築記事の範囲を超えるし、Google Cloud の VPS が安全ではないかのように扱うのは少し無理がある。
ISO 27001 は情報セキュリティマネジメントシステムに関する国際標準であり、GCP の準拠は情報セキュリティへのコミットメントを示している。
ISO 27017 はクラウドセキュリティに特化しており、クラウドサービスプロバイダーに特化した管理策に焦点を当てている。
ISO 27018 はパブリッククラウドにおける個人識別情報の保護に関する標準だ。
SOC 2 レポートは、セキュリティ、可用性、処理の完全性、機密性、プライバシーに関する統制についての保証を提供し得る。
医療情報を扱うなら HIPAA 準拠が必要で、欧州または欧州市民のデータを扱うなら GDPR 準拠が重要だ。
米国政府の顧客なら FedRAMP 準拠が必須になる場合があり、クレジットカード情報を処理するなら PCI DSS 準拠が重要だ。
GCP 内で利用するサービスが、その業界やユースケースに必要な認証範囲に含まれているか確認する必要がある。こうした認証は通常 Google Cloud のウェブサイトで確認でき、公式文書が必要なら Google の営業またはサポートチーム経由で入手することもできる。
こうした ベクトルデータベース・チャットモデル を実際にどう作るのか気になるなら、先週のライブ配信で Colab 環境でほぼゼロから作り、Llama 2 で推論する過程を見せた。 https://www.youtube.com/live/kBB1A2ot-Bw?feature=share
この構成の大きな課題は、大規模に意味的類似度検索を実行することだ。Pinecone には、大規模なベクトルデータベースをスケールさせるためのデータ構造に関する資料がかなりよくまとまっている。
Mozilla がこの流れに参入して、自前の 大規模言語モデル を開発するのを待っていた。「インターネットをすべての人に開かれ、アクセス可能な状態に保つ」という組織のミッションを考えれば、とても理にかなっている。ただ、そのためのリソースや意思があるのかは分からない。
「機械学習運用、つまり MLOps が成長分野であるのには理由がある。こうしたアプリをデプロイし管理するのは難しい。多くの開発者や運用担当者がまだ備えていない特定の知識とスキルが必要だ」とあるが、何がそんなに難しい、あるいは違うのか？
コンパイル済みのアセットであるモデルをロードする Web API を実行するものだと理解していた。その点では大きく違うようには見えない。