LLM/ChatGPTとチャットUIを組み合わせた情報検索サービスの設計(LLMの使い所とUIについて)
現在、LLMを活用したチャット型求人検索サービスのプロダクトを開発しています。チャットボットと対話をして求人が見つかるサービスです（現在α版）。
「LLM x チャットUI x 情報検索」のプロダクトを開発している中で、チャットUIとこれまでの検索UIとの違いや、検索UXプロセスにおいてLLMをどのように導入するかを整理してみました。
具体的に言えば、LLMをプロダクトのどの部分に統合していけばユーザーにこれまでより良い体験を届けることができるのかをまとめています。
従来の情報検索サービスでは、多くが検索フォームUIを通じ、希望に合う情報を検索していました。求人検索だけでなく、ホテル検索、二次流通商品の検索、式場探し、マッチングアプリ等、様々な事業ドメインに検索サービスが存在します。
今開発しているプロダクトは、求人領域において検索体験をLLMによるチャットに置き換える実験をしています。
まだまだ立ち上げ途中なんですが、現段階でこの手のプロダクトはこういう形でプロダクト設計をして改善していくのがいいのでは？という内容をまとめました。
※立ち上げ初期の内容は以下の記事にまとめています。
LLMの活用ポイント：条件入力から結果表示まで
チャット型検索系サービスにおける検索条件の入力から検索結果の出力までの流れを上図のように整理してみました。
このステップの中で、LLMが効果的に使えそうな主なシーンは以下と考えています。
ヒアリング
クエリ生成
検索実行の判断と命令
検索エンジンにリクエストを投げるまでの1〜3の部分でLLMをうまく使うことで、これまでにないユーザー体験を提供できるプロダクトになるのではと考え、今試行錯誤してプロダクトをブラッシュアップしています。
LLMの強み：ユーザー意図の理解、要約、そして行動選択
fukabori.fmでMicrosoftの大髙さんが「LLMにやってもらうことは、人間の意図の理解と最終的な結果の生成」と仰っているのを聞き、端的な表現でわかりやすいなと感じました。
自分なりに咀嚼すると、LLMはユーザーが入力した文字列のコンテキストを理解し、適切なアクションを選択・実行し、結果をユーザーに返却する関数のようなものと理解しています。
この点がチャット型情報検索サービスにおけるヒアリングと検索実行のシーンにおいて相性が良いと考えています。
ヒアリングと検索実行のプロセス
今開発しているプロダクトでは、対話の流れやヒアリングすべき内容や大まかな手順をプロンプトで指定し、ユーザーの検索条件をキリの良いところまでヒアリングできたら検索を実行しています。
LLMを使わないチャットUIでの検索の場合、チャットのフローを全てプログラムで組む必要がありましたが、LLMを使うことで大枠の流れに沿って、細かな流れはうまいこと振る舞ってくれています。
具体的にはfunction callingを導入することで、"LLMが最適だと判断したタイミングで"ヒアリング内容から検索を実行してくれます。
ただし、LLMが最適だと考えるタイミングとプロダクト開発チームが考える最適なタイミングには乖離がある場合があって、毎回理想的なタイミングでのアクション実行をしてくれているかというとそうではありません。このあたりのタイミングの制御は、正直まだまだ課題が山積してます。
とはいえ、やっぱりLLMが優秀だなと感じるのは、仮に「条件A,B,Cの3つを聞けたら検索してね」とプロンプト等で指示している場合、ユーザーがその条件をまとめて答えた場合でも、1つずつ順番に答えた場合でも適切に条件A,B,Cを認識できていたり、条件Aが曖昧な表現の場合は追加で質問してAを正確に聞き出すような振る舞いが上手だなと思います。
検索クエリの生成
その他にもLLMの強みとして一般的によく挙げられる特徴のうちの1つに「要約」があります。
この強みは、情報検索サービスで検索APIをリクエストする時のクエリを生成するシーンにおいてうまく活用できる可能性があり、現在開発中のプロダクトでもクエリの生成をLLMに手伝ってもらっています。
ユーザーとの対話の流れ、内容を理解し、そこから検索クエリに抽象化してもらいます。
このクエリ生成においても、半分うまくいってる、半分はなかなか課題がある、といった具合で試行錯誤しています。
対話内容を抽象化し、検索クエリに変換する点はそこそこうまく行っても、そのクエリが利用している検索エンジンにフィットしたクエリかどうかは、LLM側または検索エンジン側をチューニングしていかないといけません。
情報検索サービスにLLMを導入する過程で、まず最初の壁がここかなと感じています。
LLMとユーザー対話のサイクル：理解から最適な結果へ
LLMの強みがコンテキストの理解・ユーザーの意図の理解なので、ユーザーとの対話のプロセスを抽象化して検索することがユーザーの課題解決に繋がるプロダクトとの相性が良いかなと思っています。
最初のヒアリング段階における対話ももちろんそうなのですが、一度検索結果を提示した後には、また一番最初の図の1のステップに戻ってユーザーと条件をすり合わせるプロセスに入ります。
提示した結果は最初のヒアリングに基づいてベストな結果を出しているわけですが、ユーザーがその結果をいざ見てみると「んー、もうちょっとこういうのがいいんだよなあ」という思考になります。
その段階で、「思っていたことと何が違ったのか」をユーザーと対話をして聞き出して、その差分を調整した上で再度新しい検索結果を提示します。
聞く → 探す → 提示する → 聞く → 探す → 提示する…というプロセスをループすることで、ユーザーが本当に思っていた条件を明確にすることができ、LLMはそのプロセスの理解能力に長けているのでは、という仮説を持っています。
チャットUI：検索フォームUIに比べて高い入力自由度
検索フォームを開いて、チェックボックスを選択したり、プルダウンから選択するようなUIの場合、ユーザーは自分の条件に最も近い条件を「選ぶ」というアクションをしていました。
一方、チャット形式でテキストボックスが1つだけあるUIにおいては、ユーザーは条件を選ぶのではなく「考える・想起する」というアクションに変わります。
つまりなんでも入力できるので、検索フォームUIでは指定しづらい条件も伝えられるようになります。
チャットUIのメリット・デメリット
チャットUIでの検索系サービスはLLMが盛り上がる以前から存在していたので、LLMが活用されたチャットUIになったからといって、チャットUIのpros/consは意識しないといけないと思っています。
従来の検索条件入力UIだと上図のようなメリット・デメリットがあるかと思います。
特に設定できる項目が多いUIの場合、操作の難易度は高くなるので、ユーザーの学習コストや操作コストが増える傾向にあります。
そのため、求人サイトをはじめとした検索サイトでは、ユーザーとのファーストタッチでは項目を最小限に絞った検索UIを表示し、まずファーストアクションを起こしてもらった後に、さらに絞り込む時のためにすべての条件を設定できるUIを表示することが多いです。
つまり検索UIがサービスの中で複数存在することになりますし、2段階ステップを踏むことがデフォルトになるUX設計になります。
特に階層が深いカテゴリーのような条件を指定する場合は、アコーディオンやドリルダウンで何度もタップ操作をして、選択して戻る行動を繰り返す必要があります。
一方でチャットUIのPros/Consは上図のようなイメージです。
LLMを活用することで柔軟性の高い対話ができるので、コンテキストに応じてユーザーが答えやすいように質問をすることが可能です(完璧を目指すにはなかなか大変ですが…)。
また、チャットUIは大多数の人が使ったことがあるUIであり、なおかつ入力欄が1つしかないので操作の学習コストは圧倒的に低いです。
ただし、なんでも入力できるがゆえに、ユーザーアクションにおけるコールドスタート問題が起こるため、ユーザーが最初に何をはじめたらいいのかをエスコートするような設計が重要になります。
それに加えて、全てを文字で入力する手間や次のアクションや条件を想起できない問題もあるため、これらはUIで解決する必要があるかなと思います。よく見るのは、次のアクションの例がボタンでタップできるみたいなやつですね。
この点については、今開発しているプロダクトでも検証中ですが、あまり色々UIに付け加えると、チャットUIのシンプルさがなくなっていき、結局操作難易度が高くなってしまう可能性もあるので、わりと慎重に検討しています。できる限りゴチャつかないように、最低限のUIでユーザーの行動をサポートできるにはどうしたらよいかを色々模索しています。
相性の良い検索エンジンの模索が必要
LLMを使ったチャットUI入力になったことで、検索クエリの自由度はこれまでより高くなります。
例えば、検索フォームで条件の指定した時のようにマスターデータの単語単位でのクエリも作れますし、Googleやフリーワード入力のようにもう少し自由度の高い単語のようなクエリも作れます。
さらには、1つの単語では表現できないような微妙なニュアンスやコンテキストの文章単位でのクエリも生成できます。
どのようなクエリを生成するかは、検索エンジンがどのような仕様なのかに関連してくるかと思います。
例えば検索エンジン（と検索API）の仕様が「エリアはXX、価格はYY〜ZZ円」のようになっている場合、エリアや価格等のクエリをそれぞれ生成する必要があります。また、フォーマットが決まっている場合も、「1,000円」や「千円」と入力されていたら「1000円」に変換する必要があります。
一方で、検索エンジンがベクトルサーチやセマンティック検索のような手法の場合、もう少しクエリの表現方法に自由度があり、わざわざ全部「1000円」に直したり、マスタデータと完全一致するようなクエリにする必要はなくなります。
今プロダクトを開発しているチームでの見解としては、ユーザーの入力がチャットUIを介すのであれば、ベクトルサーチのような検索エンジンの方が相性がよいと考えています。また、ユーザーの対話が長くなればなるほど、その効果が高いのではと見ています。
なぜなら、チャットUIでユーザーからヒアリングできた微妙なニュアンスやマスタデータでは表現しづらい条件をクエリ変換時に欠落することなく、検索を実行できるためです。
とはいえ、ベクトル検索を導入するにはその設計も色々と検証する点が多そうなので、チームで検証を重ねながら良い着地点を見つけようとしています。
We are hiring!
現在4人のチームでプロダクトを開発中です。LLM含め色々なチャレンジ・検証をしてプロダクトを伸ばし、LLM x 検索領域でのベストプラクティスを見つけていきたいと思っています。
プロダクトのコア体験部分をLLMで実装するチャレンジができるチームだと思います。
興味がある方は以下の求人またはTwitterのDMでお気軽にご連絡ください！
採用とか関係なく、このあたりのテーマについて色々お話したいので、LLM関連のプロダクト開発をしている方もぜひ交流させていただけると嬉しいです！ → Twitter: @kiiita
この記事が気に入ったらサポートをしてみませんか？