AIがプロジェクトの詳細を忘れたときは、思い出す前に尋ねるべきである
AIアシスタントが進行中のクリエイティブプロジェクトから日常的な詳細を取得できない場合、確認できない内容を明示し、不足している事実を特定したうえで、ユーザーに情報源を尋ねる必要があります。ユーザーがその詳細を確認した後にのみ、作業上の理解を更新すべきです。このような対応は、もっともらしい過去のやり取りをでっち上げるよりも有用です。プロジェクトの記録と推測を明確に区別できるからです。
もっともらしい記憶も推測にすぎない理由
クリエイティブなプロジェクトは小さな決定の積み重ねで成り立っています。どのタイトルが最終候補に残ったか、ドラフトが一人称か二人称か、あるいはユーザーがどのカラーパレットを選んだかなどです。アシスタントがこれらの詳細のいずれかを見つけられない場合、流暢な回答は信頼できる記憶のように聞こえながら、知らぬ間に新しい選択肢を紛れ込ませてしまう可能性があります。
NIST（アメリカ国立標準技術研究所）は、生成AIの作為（作話）を、自信ありげに提示される虚偽のコンテンツだけでなく、入力と乖離したり矛盾したりする出力も含むと定義しています。捏造されたプロジェクトの詳細は、そうした実用上のリスクに当てはまります。すでに決定された事項だと誤認される恐れがあるのです。NISTの『Generative AI Profile』はそのメカニズムを一般的な観点から説明しています。ここでのプロジェクト作業における影響は設計上の推論であり、特定の製品に関する調査結果ではありません。
OpenAIの研究でも同様に、一般的な評価のインセンティブによって、不確実性を認めることよりも推測することが報われてしまう場合があると指摘されています。その例は一般的な質問応答ですが、設計上の教訓はそのまま通じます。アシスタントは、自信に満ちた完了を過去のやり取りが存在する証拠として扱うべきではありません。Why language models hallucinate
まずアシスタントが実際に見えているものを明確にする
アシスタントは、現在の会話内で確認できる詳細、利用可能なプロジェクト情報源から取得可能な詳細、そして検証できない詳細という3つの状態を区別すべきです。これらの状態には異なる表現が必要です。現在のスレッドの前半にその詳細がある場合、アシスタントはそれを引用または要約し、そのコンテキストを示すことができます。メモやドキュメントが見つかった場合は、その情報源の名前を挙げることができます。どちらも利用できない場合は、率直にそう伝えるべきです。
有用な不確実性の表明は、具体的かつ限定的です。「現在利用可能なプロジェクト情報からは、どちらのタイトルを選択されたか確認できません」。これは、ユーザーがタイトルを選んだことがない、アシスタントがあらゆる可能なアーカイブを検索した、あるいは不足している詳細が存在しない、といったことを意味しません。記録を取得できないことは、その記録が決して作成されなかった証拠にはならないため、これらの区別は重要です。
Googleの『People + AI Guidebook』では、関連する機能と限界を説明し、ユーザーの理解や意思決定に影響を与える事柄に焦点を当てて説明することを推奨しています。ここにあてはめると、モデルの内部構造に関する技術的な説明ではなく、利用可能なプロジェクトのコンテキストについての簡潔な説明が求められます。Explainability + Trust
最小限で有用な情報源を尋ねる
情報の不足を伝えた後、的を絞った質問を1つ投げかけます。例えば、「メモを貼り付けていただくか、決定したタイトルを教えていただけますか？」といった形です。ユーザーが持つ情報源の候補が複数ある場合は、「最新のドラフト、プロジェクトのメモ、あるいは以前のチャットのいずれかにありましたか？」と簡単な選択肢を提示します。日常的なクリエイティブ作業を尋問のようにすることなく、情報復帰をスムーズにすることが目的です。
実用的な応答パターンは次のとおりです。「アクセス可能な情報からはパレットを確認できません。メモを共有していただくか、色を教えていただければ、次のドラフトにそれを使用します」。これにより、不足している事実を特定し、証拠や確認を求め、次に何が行われるかを説明します。また、不確実な選択肢は保留にしつつ、影響のない部分のタスクを続行できるため、作業の勢いを維持できます。
明確化は、不足している情報が答えを変えてしまう場合に有効です。協調対話の研究において、TestoniとFernándezは、モデルの不確実性に基づいた明確化戦略が特定の描画タスクにおいてタスクの成功率を向上させることを発見しました。一方で、質問をすることにはコストが伴うことも報告しています。このことは、バランスの取れたアプローチを支持しています。つまり、プロジェクトの欠落した事実が重要な場合にのみ質問し、その質問を簡潔に保つということです。Asking the Right Question at the Right Time
ユーザーが確認した後にのみ更新する
ユーザーが情報源を提供したり詳細を確認したりしたら、確認された事実を簡潔な形で復唱します。「了解しました。貼り付けていただいたメモに基づき、現在のタイトルを『小さな庭のノート』とします」。情報源の記載と少し異なる場合は、黙ってどちらかを選ぶのではなく、その不一致を提示します。例えば、「メモには『庭のノート』とありますが、先ほどは『小さな庭のノート』とおっしゃっていました。どちらを使用しますか？」と尋ねます。
更新は、対象のプロジェクトと提示された証拠の範囲内にとどめるべきです。貼り付けられた1行のテキストは、現在のタスクでその1行を使用する根拠にはなりますが、その詳細が永続的であること、すべてのバージョンに適用されること、あるいは現在の会話を超えて保存されるべきであることを自動的に証明するものではありません。製品に可視化されたプロジェクト記録がある場合は、提案された更新を表示し、ユーザーがそれを修正できるようにします。そのような記録がない場合は、記憶が恒久的に変更されたかのように主張してはなりません。
この確認ステップは、追跡可能性とユーザー管理から導き出された設計上の推奨事項です。ユーザーはどの事実が採用されたかを確認し、それが今後の作業に影響を与える前に修正できます。これはクリエイティブな選択が変化していく場合に特に役立ちます。以前のドラフトには古いタイトルが含まれ、最近のメッセージで新しいタイトルが決まることがあります。アシスタントは、ドラフトを1つの時代を超越した記憶として平坦化するのではなく、その変遷を保持すべきです。
推測を紛れ込ませた質問を避ける
作り話の答えを組み込んでしまうと、質問であっても誤解を招く可能性があります。「ティールを選びましたよね？」という質問は、アシスタントが確認していない詳細へと会話を誘導してしまいます。「何色を選びましたか？」といったニュートラルな質問を優先してください。もし「ティール」と記された実際のリソースがあるなら、「下書きのメモにはティールと記載されています。引き続きこのパレットでよろしいですか？」と情報源を特定します。そのような言い回しによって、情報源の証拠と現時点での確認が切り離されます。
生成された代替案を、思い出した事実であるかのように提示してはなりません。ユーザーが以前の決定を見つけられない場合、アシスタントは選び直す手助けを提案できますが、それを新たな選択として明示する必要があります。「以前のパレットを復元できません。今、新しく選びますか？」。この区別により、プロジェクトの履歴を書き換えることなくクリエイティブなコラボレーションが可能になります。
不完全な質問に応答する言語モデルに関する2024年の研究では、文脈に応じた適切な明確化の挙動は、自動的に現れるのではなく、特定のモデルサイズやプロンプト条件下で現れることが判明しました。この結果は、モデルがデフォルトで信頼性の高い適切な質問をしてくれると思い込まず、プロダクトチームがこの挙動を明示的に設計・評価すべきであるという注意を促しています。Clarifying Completions
日常的なプロジェクトタスクで挙動を評価する
プロダクトチームは、日常的なクリエイティブプロジェクトのプロンプトを使用してこのインタラクションをテストできます。アシスタントが利用できるコンテキストに関連情報がない状態で、不足しているタイトル、選択された形式、ドラフトの好みなどを尋ねてみます。優れた応答とは、不足を明示し、過去のやり取りのでっち上げを避け、関連する情報源や確認を求め、確認された情報を一貫して使用するものです。
現在のスレッドや提供されたメモの中に詳細が存在する類似のケースも含めてテストします。そのような場合、アシスタントはどこから得た情報かを正確に示しつつ、利用可能な証拠を活用すべきです。また、矛盾するバージョンやユーザーによる修正もテストします。有用な評価とは、根拠のない想起と根拠のある情報取得を区別し、アシスタントがタスク全体を停止させることなく影響のない作業を継続できるかどうかを確認するものです。
これは提案された評価手法であり、引用された研究によって確立された結果ではありません。この手法の情報としての価値は、その決定手順にあります。アクセス権を判断し、限界を述べ、最小限の役立つ情報源を求め、採用された詳細を確認し、更新の範囲を明確に保つ。この手順により、「わかりません」という回答が作業における生産的な一歩へと変わります。
不確実性をプロジェクトの継続性の一部にする
クリエイティブプロジェクトのアシスタントにとって、不足している詳細を認めることは行き止まりではありません。それは継続性を守るための方法です。未検証の履歴を埋めないままにしておくことで、システムは支援を続けることができます。明確な不確実性、的を絞ったリクエスト、そして目に見える確認によって、ユーザーはプロジェクトの記録に何を残すべきかを決定でき、アシスタントには次のドラフトに向けた確かな基盤が与えられます。