短期インターンで社内の ChatGPT ボットを改善した話

こんにちは 👋
約3週間、Recommendation Squad でインターンをしてきた青砥です。

Wantedly には2022年のサマーインターンでお世話になり、ご縁があって再びインターンをしてきました。
今話題の ChatGPT に関わるタスクに取り組んだので、その成果をまとめます。

社内ツール gptalk について

Wantedly では、Slack に独自の ChatGPT ボット「gptalk」が導入されています。

Slack のチャンネルで @gptalk とメンションをつけてチャットを送ることで、そのメッセージの内容が OpenAI の API に投げられ、その応答をボットが返してくれる仕組みになっています。
これによって Slack 上で ChatGPT との対話を行うことが可能になっています。

インターンで取り組んだタスクについて

今回のインターンでは gptalk の機能開発と改良に取り組みました。言語は Go を使用しました。

背景

ここ数ヶ月で ChatGPT が世間を騒がせていますが、その活用方法についてはまだ世界中の人が模索されている段階です。そこで ChatGPT を社内の Slack で使えるようにした上で、独自機能の追加や改良を行うことで、Wantedly らしい新たな ChatGPT の活用方法の発掘に繋げるのがこのタスクの目的です。

取り組んだタスク

プロンプトの再利用を簡単に行える機能の追加
URLの解釈機能の改善
gptalk を呼び出せるチャンネルを制限する仕組みの追加

それぞれのタスクについて詳しく説明します。

1. プロンプトの再利用を簡単に行えるように

背景

ChatGPT を使っていると「〇〇を要約してください」や「〇〇になったつもりで文章を書いてください」など何度も使い回すようなプロンプトが出てくると思います。

社内の Slack で繰り返し使われていた例としては「ヘーゲルの弁証法」のプロンプトがあります。弁証法についての詳しい説明は省きますが、これは次のようなプロンプトを投げることで、ChatGPT が指定したテーマについての深掘りしながら議論を繰り返し、結論を導いてくれるというものです。

入力に対して、以下の処理で弁証法を行い議論を深めなさい。
$テーゼ = 入力
　　for i in range(5):
　　$アンチテーゼ = ヘーゲルからの多角的な反証を3つ($テーゼ)
　　$ジンテーゼ = ヘーゲルによる統合（$テーゼ, $アンチテーゼ)
　　print(f”試行{i}回目“)
　　print(“テーゼ: {$テーゼ}“)
　　print(“アンチテーゼ: {$アンチテーゼ}“)
　　print(“ジンテーゼ: {$ジンテーゼ}“)
　　テーゼ = ジンテーゼ
print(わかりやすく解説($ジンテーゼ))

しかし、プロンプトを別の文脈で再度で使いたい時には毎回コピペをする必要があり、人によっては面倒さを感じる部分だと思います。そこで、毎回コピペをすることなくプロンプトを再利用できる機能をゼロから実装し、社内の Slack に導入しました。

仕組み

具体的には、再利用したいプロンプトをあらかじめ登録しておき、Slack のメッセージ上で prompt:〇〇と指定することでプロンプトを再利用できる仕組みになっています。
例えば「これを分かりやすく要約してください」という文章を「要約」プロンプトとして登録しておくと、

@gptalk prompt:要約
＝＝要約してほしい文章＝＝

というメッセージを送るだけで、ChatGPT によって要約された文章が返されます。

この機能を実現している技術的な仕組みを説明します。
まず、ユーザーのメッセージに prompt:〇〇という文字列が含まれていた場合、指定されたプロンプト名〇〇を解釈し、それを元に登録されているプロンプトの本文を取得します。
その後、取得したプロンプトとユーザーのメッセージの本文を合体し、それを Open AI の API に投げて返ってきたメッセージを Slack 上でユーザーに返信する流れとなっています。

技術仕様を決める中で、プロンプトの保存場所について検討する必要がありました。GitHub のリポジトリに保存する方法以外に、Slack のコマンド等で対話的にプロンプトを保存する方法なども考えられます。今回は、以下の2つの観点からプロンプトの保存場所として GitHub のリポジトリを採用しました。

プロンプトは後から何度も修正される可能性がある
GitHub はエンジニアに限らずビジネスチーム等でも利用されており、社内全体で普及している

今後の課題

この機能を実際に社内の Slack に導入してみて分かった課題点もあります。
まず、必ずしも毎回同じプロンプトを使い続けることは少なく、その時の状況によって少しずつアレンジが必要となる点です。例えば、「〇〇を要約して欲しい」というプロンプトであっても、場合によって箇条書きや100文字以内など、細かい指定をしたい要件が出てくるはずです。
また、プロンプトを再利用できることがまだユーザーに浸透しておらず、なかなか利用が進んでいないという現状もあります。

以上の点から、登録したプロンプトをただ呼び出せるだけではユーザーのニーズを完全に満たすことにはならず、まだまだ改善の余地があると言えます。今後は、細かなユースケースに対応できるように改良を加えたり、社内でもプロンプトの再利用機能について認知してもらえるような施策が必要であると考えます。

2. URLの解釈機能の改善

背景

ChatGPT では、本来 URL を解釈することはできないため「https://wantedlyinc.com を要約して」といった要求には対応していません。

gptalk ではこれを独自に拡張して、ユーザーが URL を送信するとあらかじめそのページにアクセスして HTML を取得し、それをユーザーのメッセージと合体して API を叩くことで、擬似的に URL を解釈できるようになっています。技術的な仕組みはプロンプトの再利用機能とほぼ同じです。

問題点

従来の URL 解釈機能では、場合によってメッセージ内の URL の検出に失敗してしまう問題点がありました。具体的には、URL の前後に空白や改行が入っていると検出に失敗する現象が発生していました。

また、これに関連して、もしメッセージ内の URL の検出に失敗してもユーザーがそれに気づくことが難しいという問題点がありました。例えば「https://www.wantedly.com/id/aotoriku の人を要約してください」というメッセージに対して、もし URL の検出に失敗しても、大抵の場合エラーにならずに前後の文脈等から gptalk はメッセージを返してしまいます。そのため、ユーザーは URL が正しく解釈できているかどうかを gptalk からの返答メッセージの内容から判断する必要がありました。

以下の画像が実際に社内の Slack で起きた事例です。ユーザーは Wantedly のプロフィールをもとに、その人について要約してもらうよう gptalk に頼んでおり、一見すると gptalk は URL を解釈してその人についての要約を返しているように見えます。しかし実際には、システムの内部で URL の検出に失敗しており、指定されたページの HTML が取得できていなかったため、事実とは全く異なる回答が返っています。

このケースでは文章の内容が明らかに間違っていることから、URL の検出に失敗していることが分かりましたが、文章から判断できないケースも十分起こり得るため改善が必要でした。

解決方法

このような状況を改善するために、以下のタスクに取り組みました。
1. URLの検出ロジックを修正
　→ これまで URL の検出に失敗していたエッジケースにも対応
2. 検出したURLをメッセージの下部に表示
　→ もし検出に失敗しても、ユーザーが容易に気付けるように

URL を表示する際には、Slack が提供している Block Kit を活用しました。この Block Kit は、Bot のメッセージの文字に装飾を加えることができたり、ボタンなどのユーザーの入力を受け付ける要素を加えたりすることができるツールです。今回の URL はあくまで付加情報であり、メインとなる ChatGPT からの返答が目立つようにしたかったため、Block Kit の Context Block を活用することで、URL を小さな文字サイズかつ薄い色で表示するよう工夫を加えました。

Block Kit

A clean and consistent UI framework for Slack apps Customize the order and appearance of information and guide users through your app's capabilities by composing, updating, sequencing, and stacking blocks - reusable components that work almost everywhere

https://api.slack.com/block-kit

3. gptalk を呼び出せるチャンネルを制限

gptalk は当初、どのチャンネルでも呼び出すことが可能になっていました。しかし、以下の2つの観点から、gptalk を呼び出せるチャンネルを1つに制限しました。

利用状況を把握しやすくするため
ChatGPTの知見を共有しやすくするため

利用状況の把握

「利用状況の把握がしやすくする」については、主に機密保護に関わる観点です。Wantedly では機密情報の漏洩リスク等を考えて、ChatGPTに入力してもよい情報についてルールを設けています。しかし、gptalk がどのチャンネルでも自由に呼び出せてしまうと、利用者がルールをきちんと守っているかの把握が困難になってしまうため、呼び出しチャンネルを制限することが望ましいという判断になりました。

知見共有

「ChatGPTの知見が共有しやすくする」というのは、みんなでChatGPTのより良い使い方を見つけるというのが目的です。最近では、プロンプトエンジニアリングという言葉がよく話題になるように、ChatGPTに対してどのようなプロンプトを投げると、最適な使い方ができるかが注目されています。そのため、社内でも良いChatGPTの活用事例は、他の社員にも積極的に共有されるのが理想の状態と言えます。そのため、gptalk を使えるチャンネルを制限することで、他人のプロンプトを見ることが容易になり、結果的に社内でのプロンプトの知見向上に繋がるメリットがあります。