インタビューの途中で、ユーザーが短すぎる回答を返すことがある。
「はい」とか「それで」とか「うーん」という一言だ。AIがインタビュアーとして次の質問を進めようとすると、文脈が乏しくて記事に使えない情報しか集まらない。
最初の実装は、どんな回答が来ても次の質問に進んでいた。結果として、記事生成に進んだとき「情報が足りない」という事態が起きた。
確認を求める仕組みを入れることにした。
Geminiに渡すプロンプトに「回答が短すぎるか曖昧な場合は、もう少し詳しく聞いてください」という指示を加えた。ただし、毎回確認を求めると会話が重くなる。条件を設けた。
条件は2つ。回答が20文字未満、または回答にキーワードが含まれない場合だ。「キーワード」は質問ごとに設定する。例えばお店の強みを聞く質問なら、「新鮮」「地元」「手作り」などの具体的な言葉が含まれているかを確認する。
含まれていなければGeminiに「この回答からは具体的な強みが読み取れません。もう少し具体的に教えていただけますか」という確認依頼を返させる。
確認依頼の文章を「全文化」した。
最初はGeminiに任せていた。「確認が必要なら確認してください」という指示だけを渡して、文章はGeminiが作っていた。
問題が起きた。Geminiが確認依頼と次の質問を混ぜた返答を作ることがあった。
「もう少し詳しく教えてください。また、次に営業時間についてお聞きしたいのですが」
1メッセージに2つの役割が混在する。ユーザーは何に答えればいいか迷う。
確認依頼は固定文に変えた。「先ほどのご回答について、もう少し詳しくお聞かせください」という決まった一文を返す。次の質問はその後、ユーザーが詳しく回答してから進む。
システムが生成する文章と、固定の案内文は役割が違う。混ぜると品質が落ちる。
確認の回数に上限を設けた。
同じ質問への確認が3回続いたら、その質問は「情報不十分」としてスキップして次に進む。永遠に確認ループに入る事態を防ぐ。
スキップした質問はskipped_questionsとして記録する。記事生成時に「この項目は情報が得られませんでした」という注記をつける。運営者が後から確認できる。
テストで分かったことがある。
「確認する」判定が厳しすぎると、ユーザーが疲れる。2回確認されると「うまく答えられていないのかな」という不安が生まれる。
条件を緩めた。20文字未満から15文字未満に変えた。キーワードチェックは外して、文字数だけで判断するようにした。短い回答でも文脈があれば使える。記事生成はGeminiが補完してくれる。
ユーザーが詰まらずにインタビューを完了できることの方が、回答の豊かさよりも重要だと判断した。
インタビューシステムの難しさは「AIが人の代わりに聞く」という役割の曖昧さにある。
熟練したインタビュアーは相手の表情を見て、詳しく聞くべきか次に進むべきかを判断する。AIには視覚情報がない。テキストだけで判断する。
だから制御は単純な方がいい。文字数を見て、次に進む。複雑な判断はGeminiに任せるより、ルールで決めた方が安定する。
次回は、管理画面がインタビュー完了を自動で検知して更新される仕組みを書く。
シンプルシステム株式会社 代表 伊藤勝彦