生成AIでFAQを作れますか?

作れます。けれど、作れません。

なんか大人の日本語としてだめな解答文になってしまいました。(汗)
でも、無責任に解答したくないので、こんな書き方になりました。

メンドくさい奴だと思われるかもしれませんが、生成AIでFAQを作れるかどうかは、
「FAQ」の定義に左右されるのです。
FAQを、「Q&Aになった文のペア」(定義①)とすれば、
生成AIでFAQを作れます。
FAQを、「ユーザーからのお問い合わせの多いQとそれをほぼ確実に解決できるAのペア」と(定義②)すれば、生成AIではFAQは作れません。

このことは、念のため生成AI自身(Chat-GPT、Copilot、Gemini)との私との、暑苦しい討論で確認しましたので正確だと思います。
また近い将来はどうかというと、上記の3人のAIによると、将来もあまり変わらないだろうということです。

これを読んでいるカスタマーサポートやマネージャーの方々は、どちらのFAQを作りたいですか?
もし定義①のFAQでよければ、生成AIがマニュアルやコールセンターの応対履歴から作ってくれるでしょう。しかも何百個も、何千個も。

ただし、私はFAQコンサルとしてそれはお勧めしません。なにしろそんなFAQは何千個あろうが、Q&Aのペアの集まりにすぎず、ユーザーの役に立つ「品質保証」はないものです。品質保証がないということは、別の言葉で言うと「粗悪品交じりで歩留まりの悪い」と言うことになります。すると運用効率も費用対効果も悪いものになります。

やっぱりFAQは定義②「ユーザーからのお問い合わせの多いQと、それを確実に解決できるAのペア」でなければいけません。歩留まりという損得勘定ができれば、当然こちらのFAQが理想です。

では、なぜ生成AIは、定義②のようなFAQを作ることができないのでしょうか。優れたプロンプトエンジニアが、秀逸なコマンドを生成AIに送ったところで無理なものなのでしょうか。RAG(Retrieval-Augmented Generation:検索拡張生成)と組み合わせても難しいのでしょうか。

残念ながら、難しいです。いくつか理由があります。
1. よくあるお問い合わせにはトレンドがあり、常に変わる。つまり「よくある」のリアルタイム判断は生成AIには困難。
2. またよくあるお問い合わせに対して何を回答とすればベストかということも、ケースバイケース。生成AIには判断が困難。
3. お問い合わせ内容によっては答えが複雑になる可能性がある。そのうちどの部分を切り出せば、確実な解決ができるFAQにできるのかという判断は生成AIには困難。
4. RAGを使った場合でも、参照対象のデータソースの質に大きく左右される。情報が多すぎるとかえって矛盾が生じることにもなりかねない。
5. 上記を何とか克服してプロンプトエンジニアが頑張っているうちにコスト(時間と人件費、システム代)が膨れ上がる。無理をするとコンフリクト(文脈不整合)やハルシネーション(不正確な回答)の原因を作る。

今現在、生成AIに希望を見出して取り組んでいる会社の人やお金をもらって提供しているベンダーさんをディするつもりはありません。むしろその取り組みに敬意を表します。ただ、事実は事実なので受け止めて頂く必要はあります。このブログをバッシングの材料とせず、賢明な判断材料としてください。

異なる観点で考えてみましょう。世界中で最も優れたAI、つまり「人間」に定義②のようなFAQを作ることはできるのか?という観点です。もしあなたの会社で今のところそれができていないのなら、そのノウハウがないということになります。ノウハウがなければ生成AIにプロンプトも送れない。したがって同じく無理なのです。

では、生成AI(または人間が)定義②のFAQを作るという道すじが途絶えてしまうのか・・とあきらめてしまいますか。それは、あきらめが早すぎです。(笑)

良い方法があります。まず、あなたのバイアスをはずしてください。
FAQ→大量に作らなければいけない
という固定概念はありませんか? 
その凝り固まった概念を外して、とっとと燃えるゴミの日に捨ててください。

バイアスが外れてすっきりした頭で、「1番問い合わせの多いFAQを1つだけ作る」と考えてください。
一気に視界が開けてきませんか。それなら生成AIへのプロンプトもFAQ運営者への指示も簡単そうではないですか。
それで上手くいったら、(ユーザーの解決率が上がったら)2番目にお問い合わせの多い・・、3番目‥とほんのちょっとずつちょっとずつ欲張っていくのです。

ちなみにこれがほんとのスモールスタートであり、アジャイルな運用といえます。(つづく)

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です