Metlivi 部落格

當 AI 遺忘專案細節時,應先詢問而非自行「回想」

當 AI 助理無法檢索進行中創意專案的常規細節時,它應說明無法確認的內容、指出缺失的事實,並向使用者索取資料來源。唯有在使用者確認該細節後,它才應更新其工作理解。這種回應比憑空捏造看似合理的過往交流更有用,因為它能將專案記錄與臆測區隔開來。

2026年9月30日6 min read閱讀、藝術與文化作者:Metlivi Editorial Team
第 1 節

為何看似合理的記憶本質上仍是臆測

創意專案取決於諸多微小決策:入選的名單標題、草稿使用第一人稱還是第二人稱,或是使用者選擇的調色盤。如果助理找不到其中一個細節,流暢的回答聽起來可能像是可靠的回憶,卻在不知不覺中引入了新的選擇。

NIST 對生成式 AI 的虛談(confabulation)定義包括以自信口吻呈現的錯誤內容,以及偏離或矛盾於輸入內容的產出。虛構專案細節符合這項實際風險:它可能被誤認為是已做出的決定。NIST 的《生成式人工智慧概況》(Generative AI Profile)以通用術語描述了該機制;此處對專案工作的影響屬於設計推論,而非針對特定產品的研究結果。

OpenAI 的研究同樣指出,常見的評估激勵機制往往會獎勵猜測,而非承認不確定性。其案例為一般問答,但這項設計經驗同樣適用於此:助理不應將聽起來自信的補全當作過往交流記錄可用的證據。Why language models hallucinate

第 2 節

首先釐清助理實際能看到的內容

助理應區分三種狀態:當前對話中可見的細節、可從現有專案來源檢索的細節,以及無法驗證的細節。這些狀態需要不同的措辭。如果該細節出現在當前對話串的前文中,助理可以引用或總結它,並指向該脈絡。如果它找到了筆記或文件,可以指名該來源。如果兩者皆無,則應如實說明。

一個有用的不確定性陳述應具體且有限度:「根據我能獲取的專案資訊,我無法驗證您選擇了哪個標題。」它並不暗示使用者從未選擇過標題、助理已搜尋了所有可能的封存,或是該缺失細節不存在。這些區別至關重要,因為無法檢索記錄並不代表該記錄從未被建立過。

Google 的《People + AI Guidebook》建議解釋相關功能與限制,並將解釋重點放在影響使用者理解與決策的層面上。應用於此,這意味著對可用的專案脈絡進行簡短說明,而非對模型內部原理進行技術性解釋。Explainability + Trust

第 3 節

索取最小限度的有用來源

在陳述資訊落差後,提出一個具針對性的問題。例如:「您能否貼上筆記,或告訴我您最後決定的標題?」如果使用者可能有多種來源選擇,請提供簡短清單:「它是在最新草稿、您的專案筆記,還是先前的對話中?」其目標是使恢復資訊變得容易,而不會將例行的創意任務變成審訊。

一種實用的回應模式是:「根據我能存取的內容,我無法確認調色盤。如果您分享筆記或提醒我顏色,我會在下一版草稿中使用它們。」這指出了缺失的事實、請求證據或確認,並解釋接下來的步驟。這同時維持了工作動能:助理可以在未受影響的任務部分繼續進行,同時保留不確定的選擇供後續確定。

當缺失的資訊會改變答案時,進行釐清是很有用的。在一項協同對話研究中,Testoni 和 Fernández 發現,以模型不確定性為導向的釐清策略改善了他們特定繪圖任務的成功率;他們同時指出,提問會帶來成本。這支持了一種適度的方法:當缺失的專案事實至關重要時再提問,並保持問題焦點集中。Asking the Right Question at the Right Time

第 4 節

僅在使用者確認後才更新

一旦使用者提供來源或確認細節,以簡潔的形式重述確認的事實:「收到:根據您貼上的筆記,目前的標題為『小花園筆記』。」如果來源陳述略有出入,應指明不一致之處,而不是默自做出選擇。例如:「您的筆記寫著『花園筆記』;您剛剛說的是『小花園筆記』。我應該使用哪一個?」

更新的範圍應限定於專案與證據。貼上的一行文字可作為在當前任務中使用該內容的依據;這並不自動代表該細節是永久性的、適用於每個版本,或應該儲存在當前對話之外。如果產品具有可見的專案記錄,請顯示擬議的更新並提供使用者糾正的方法。如果沒有此類記錄,切勿聲稱記憶已被永久更改。

此確認步驟是源自可追溯性與使用者控制權的設計建議:使用者可以看到採納了哪項事實,並在它影響更多工作之前加以糾正。當創意選擇不斷演變時,這一點尤其有用。先前的草稿可能包含舊標題,而最近的訊息確立了新標題;助理應該保留該序列,而不是將草稿扁平化為某種理應永恆的記憶。

第 5 節

避免夾帶猜測的提問

如果問題中夾帶了虛構的答案,仍可能會產生誤導。「您選擇了藍綠色,對吧?」會對對話施加壓力,朝向助理尚未驗證的細節傾斜。請優先採用中立的請求:「您選擇了哪種顏色?」如果確實有來源載明是藍綠色,請指出該來源:「草稿筆記列出了藍綠色。這仍是您想要的調色盤嗎?」這種措辭將來源證據與當前的確認區分開來。

切勿將生成的替代方案呈現為記憶中的事實。如果使用者找不到舊的決定,助理可以主動協助重新選擇,但應將其標記為全新選擇:「我無法找回先前的調色盤。您想現在選擇一個嗎?」這種區別既能實現創意協作,又不會重寫專案歷史。

2024 年一項針對語言模型回應不完整問題的研究發現,符合脈絡的適當釐清行為是在特定模型大小和提示條件下才出現的,而非自動產生。此結果提醒產品團隊應明確設計並評估此行為,而非預設模型會可靠地主動提出正確問題。Clarifying Completions

第 6 節

利用常規專案任務評估此行為

產品團隊可以使用例行的創意專案提示詞來測試此互動:當助理可用的脈絡中缺少相關細節時,詢問缺失的標題、所選格式或草稿偏好。良好的回應應指明落差、避免虛構先前的交流、索取相關來源或確認,並在隨後始終如一地使用確認的資訊。

納入細節存在於當前對話串或所提供筆記中的相近案例。在這些情況下,助理應使用現有證據,同時精確指出其來源。此外,還要測試衝突的版本和使用者更正。有用的評估能將缺乏依據的回想與有依據的檢索區分開來,並檢查助理是否在未中斷整體任務的情況下繼續推進未受影響的工作。

這是一種提出的評估方法,而非引用的研究所確立的結果。其資訊增益在於決策序列:確定存取權限、說明限制、索取最小限度的有用來源、確認採納的細節,並保持更新範圍明確。這個序列將『我不知道』轉變為工作中有建設性的一步。

第 7 節

讓不確定性成為專案連續性的一部分

對於創意專案助理而言,承認細節缺失並非死胡同。這是保護連續性的一種方式:系統可以繼續提供協助,同時讓未經驗證的歷史保持空白。明確的不確定性、具焦點的請求以及可見的確認,讓使用者能夠決定專案記錄應包含的內容——並為助理的下一版草稿提供扎實的基礎。

相關閱讀

繼續探索這個主題