OpenAIのAPIを使って営業資料をベクトル検索するボットをつくってみた

山本紘暉

2023.06.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

新規事業統括部の山本です。

ChatGPTをはじめとした、大規模言語モデル（Large Language Model）を使用したサービスを利用することで社内の業務効率化をした、というニュースを聞くことが増えてきました。クラスメソッドでもOpenAI APIなど、AIを利用した社内の業務効率化に取り組んでいます。

前回の記事では、OpenAIのAPIを利用した業務効率化のためのはじめの一歩として、自社ブログ（DevelopersIO）の記事を検索するボットを作成してみました。ベーシックな文章検索+応答生成（Retrieval Augmented Generation）ではなく、クエリ自体もLLMに考えさせるChatの機能を付与し、実際の動作を確認しました。

https://dev.classmethod.jp/articles/implement-devio-articles-search-bot/

この記事では。同様の機能・構成を使って、実際の営業資料を検索するボットを作成した際の、プロジェクトの経緯・データの扱いに関する工夫・営業メンバーに使ってもらった結果について記載します。

プロジェクトの経緯

今回のプロジェクトは以下のような経緯でスタートしました。

今年4月に始まった「ChatGPT（OpenAI API）を使って社内の業務を改善してみよう」というタスクフォースの一つとしてスタートした
Slack上で課題を出し合っている中で、営業メンバーから「資料の作成に時間がかかっており、効率化や改善する余地がありそう」という課題があがった
当初の解決策としては「営業資料のドラフトを自動で作成する」ということを考えたが、話し合いの中でそこまでは技術的なハードルが高そうだ、という結論になった
さらに業務の内容を聞いてみると、その前段階の課題として「（資料作成の参考とする）過去の類似資料を検索するのに時間がかかる or その分野を担当したことがある人に聞かなければならず、手間がかかったり、心理的障壁がある」という課題があることがわかった
その解決策として「営業提案資料を検索できるシステムを作成する」ことを目標とした

目的

取り組みの目的を整理すると以下のとおりです。

実際の営業資料で試す。気をつけるべき点・ノウハウなどを知る
検索結果がどのようになるか、性能（速度や精度）を確認する
営業メンバーに使用していただき、フィードバックを得て、改善点を見つける
業務効率化につながりそうか検討する

使用データと工夫

使用した提案資料の内容は以下のようなものでした。

形式：パワーポイント
内容：お客様各社に合わせて、クラスメソッドのご支援や提供サービスをご提案したもの
件数：200件

内容にお客様の情報が含まれていたため、個人情報や顧客情報に関してセキュリティ面で懸念がありました。作業当時のクラスメソッドの社内ガイドラインでは、こうした情報は原則AIサービスに入力してはいけないことになっていました。（6月末にガイドラインが改定されました）

そのため、対策として該当する情報を削除・マスキングすることにしました。個人や団体を特定できてしまいそうな内容・お客様の情報として、以下の項目を対象としました。

顧客の個人名・所属名・会社名（団体名）
システム名・プロジェクト名
他、特徴的な内容

営業メンバーにも協力していただき、手動で200件の資料のデータをチェックし、該当箇所を削除または置き換え（例：山本紘暉 → 従業員A）をしました。

（ChatGPT・OpenAI APIのデータの取り扱いや、クラスメソッドでのデータの取り扱いに関するガイドラインについては、江口さんのブログ記事に詳しく書かれているのでぜひご覧ください）

https://dev.classmethod.jp/articles/openai-data-usage-policy/

https://dev.classmethod.jp/articles/guideline-for-use-of-ai-services/

構成

構成は前回の記事とほぼ同様なので、こちらをご覧ください。

https://dev.classmethod.jp/articles/implement-devio-articles-search-bot/

大まかに言うと、以下のような構成です。

準備時
- マスキング処理をした営業資料を、OpenAIのEmbeddings APIに渡してベクトル化し、それらをまとめてデータベースを作成する
使用時
- ユーザが探したい資料の内容を入力する
- 入力内容と会話の履歴をもとに、LLMにクエリを考えさせる
- クエリとしてベクトルに変換してデータベースを検索し、内容が近そうな文章を取り出し、それに該当するファイルをユーザに表示する
- （会話の履歴を保存する）

前回との差分としては、以下の箇所を変えました。

入力するデータが営業資料になった
- 形式がパワーポイントに変わった
  → 使用するLoaderを変更した
- プロンプト内部のキーワードを修正した
  
  → themeを「営業用の提案資料」に変更した
出力を変更した
- 結果をクリックした時、リンク先に跳ばすのではなく、資料のファイルをダウンロードするようにした
全体を非公開にした
- (社内文書を出力するので外部には公開しないようにした)
- フロントエンド（web）・バックエンド（server）を、社内ネットワーク内のサーバPCで行うようにした（IPアドレスでアクセス可能）

結果

画面と操作の流れは以下のようです。（これも前回とほぼ一緒です）

最初は以下のように検索する画面が表示されます

検索したいワードを入れてエンターを押すと、検索が開始されます

数秒後、検索結果が表示されます（LLMが考えて、検索で使用したワードも表示しています）

クリックするとファイルがダウンロードされる

必要なら、続けてメッセージを入力して検索を繰り返す（このとき前の会話も考慮して、検索ワードが考えられる）

フィードバック

営業メンバーの方にお願いし、実際に使っていただきました。フィードバックは以下のようなものでした。3名に使用していただきました。（◯：良かった点、✕：悪かった点・改善したほうが良い点）

結果

速度
- ◯：思ったより早く出力された
- ◯：検索が早かった
精度
- ◯：検索したキーワードに合致するしている資料が表示された
機能
- ◯：取り扱いサービスや課題、支援内容など、様々な切り口で検索ができるので汎用性が高い
- ◯：一覧になっているので見やすい
- ✕：会話の中で抽出していくようなアプローチはできなかった
- ✕：違う単語を検索したいときに、「リセット」ボタンがあると使いやすそう
- ✕：資料の作成日、提案書にでてくる技術要素の一覧も一緒に出力してくれるといいかもしれない
```
例1：
・作成日：YYYY/MM/DD
・キーワード：GuardDuty、ECS、コンテナ

例2：
・作成日：YYYY/MM/DD
・キーワード：GuardDuty、EC2、ALB、CloudFront
```
- ✕：ソートを選べたらより良さそう（最近の提案書のほうが転用できる内容が多そう）
- ✕：PPTXなので都度ファイルダウンロードするのは面倒、Googleスライドなどで表示させたい

※ 使用した際のキャプチャを、この記事の最後（Appendix）に記載しています

考察・改善点

今回の取り組み内容とフィードバックから、良かった点・改善点としては以下の点が挙げられます。

◯：速度や精度はまあまあ良さそう
- フィードバックしていただけた人数がが少ないので、検証としては不十分だとは思います
✕：対応できない検索がある
- 今回のような埋め込みを用いたベクトル検索だと、検索のワード・文章自体に似たものは検索できます。しかし、「〇〇円以上を提案した」や「〇〇以外を使った」といった、数字を大小を比較したり、なにかを除外する検索はできません。
- また、フィードバックにもあったような、「技術要素で検索したい」「日時で検索したい」、というようなメタ的な検索も必要そうです。これには別途メタデータを抽出してそれと共に保存して検索できる仕組みがあると良さそうです。
✕：会話に対応した検索ができない
- Chat（会話の履歴をもとに、LLMにクエリを考えさせる）機能があるため、ある程度であれば対応できるのですが、Appendixのような「この中でーーを探して」という検索には対応できないという問題があります。この問題を解決するには、そもそもの構成から検討する必要があります。
マスキングが大変
- 今回200件の資料のマスキング作業を行いました。かかった時間はおおよそ1件あたり数分程度（Max5分程度）でした。そこまで長い時間ではないのですが、仮にこのシステムを運用するとして、資料をデータベースに登録するために、毎回資料を作成するたびにマスキング作業を実施するのは、少し手間がかかり、運用としてはギリギリな印象です。（もし仮にサービスとして他社へ提供するケースだとしたら、かなりマイナス材料になりそうなレベルです）
- 他のセキュリティ的に問題がないAPIやサービスを検討するのが良さそうです。データが保存されず、内容を見られないようなAPIがあれば、セキュリティ的にはそのままマスキングしていないデータを使用することができ、この手間をなくすことができます。（ただし、データを取り扱う際は情報元の理解を得た方が良い、というのが一般的な考えだと思われます）

反省点

今回の取り組みにおいて、以下の点が自分に不足していたなと反省しています。

機能面が足りてなく、性能面のフィードバックにならなかった
- 今回はプロトタイプとして作成し、検索の精度や、会話の中で指示通り検索できるかをもっと検証したかったです。ただ、いただいたフィードバックには、こういう機能が欲しいという、すぐわかる便利系な意見が多くなってしまいました。機能面をもう少し充足させてからフィードバックをお願いした方が良かったです。
認証認可など考えていなく、利用できる人がオフィスに出社できる人に限られてしまった
フィードバックを分析するために、実行結果まとめたり、フィードバックをまとめる機能がなかった
- クラウドにデータを送信するようにして、入力したデータや出力した結果を保存・分析できる基盤を整えてから実施するべきでした。でないと、ユーザにフィードバックしてもらうだけになってしまい、次への課題を見つけだすのに時間がかかってしまいます
キーワードで検索される場合が多かった。会話調で試してもらいたかった。
- 今回の取り組みを実験として考えると、メンバーへのお願いの仕方（指示）が悪かったかなと思います。また、文章で検索できたり、会話ができたりすることが伝わる画面になっていないことも改善の余地があった点です。ChatGPTライクな画面であればもう少し伝わったかも知れません。
- 別の観点で見ると、まだそういう体験に慣れていない人が多いということになるため、会話での検索が徐々に浸透することでより使ってもられるようになりそうです。

まとめ

OpenAI APIを使った業務効率化の一つとして、営業の提案資料を検索するシステムを作成してみました。お客様の情報を含む社内データを利用するため一部をマスキングする、という工夫しました。作成したシステムを営業メンバーに使っていただきフィードバックをいただきました。速度や精度の面では良さそうな印象だったものの、検索の機能を改良することや、体験する上でもう少し便利な機能を追加することが今後の課題です。