品牌提及和引用有什麼不同？AI 回答事件留證指南

三者的差別，用一場聚餐來想最快。有人在飯桌上提到你的公司，那是提及；有人說「這個數字是從他們官網看到的」，那是引用；有人說「你這種規模的團隊，去找他們談談」，那才是推薦。三句話可以出自同一場對話，也可能整晚只出現第一句。

這篇給你可以直接建欄位的東西：三種事件的最小定義與證據要求、判讀順序、常見誤判、失敗狀態怎麼處理。

事件欄位建好之後，用 AI 可見度資料契約追蹤品牌事件、引用事件與分母。

換成 AI 回答：回答寫「A 公司提供 GEO 服務」，旁邊的來源卻連到一篇介紹市場的第三方文章。這一列有品牌提及，也有 citation，但那個 citation 不一定支持那句公司描述；回答若還補上「適合需要固定觀測的團隊」，才需要再判斷推薦訊號。報告把三者混成一欄，「品牌出現了」和「哪個頁面被採用」就再也分不開了。

定義：品牌提及和引用有什麼不同？三種事件各自回答什麼問題

先別急著算比例。把一個回答當成一份要審核的紀錄，至少拆成三個問題：品牌有沒有出現在回答文字裡？回答有沒有顯示某個來源？品牌有沒有被放進使用者要做選擇的情境？三個問題的證據來源不同，後續要做的工作也不同：提及不對要修實體描述，引用不對要查頁面，推薦不足要補適用條件。

事件	最小定義	需要看到的證據	可以往哪裡追
Mention，品牌提及	回答文字出現可辨識的品牌或產品名稱	原始回答中的品牌字串與上下文	品牌名稱、別名、描述是否正確
Citation，引用	回答顯示某個可辨識的來源網域或 URL，且能和回答建立來源關係	來源卡、內文連結、URL 或可辨識來源文字	哪一頁被採用、頁面是否能支撐該句
Recommendation，推薦	在具有選擇意圖的問題中，品牌被列為可考慮選項，並附帶條件、用途或理由	問題的決策語境、回答中的品牌位置與推薦理由	品牌是否與類別、用途和適用條件連得起來

這套「最小定義」是我們自己用的觀測規則，它要解決的問題很實際：同一個團隊在今天和三個月後讀到類似回答時，判定要落在同一個位置。各憑直覺標記的話，最後那張表每一格都填滿了，卻沒有兩格用同一把尺。

品牌提及、引用來源與推薦判讀應分開保存。

一個回答的三種可能組合

假設問題是「台灣有哪些 AI 搜尋優化平台？」，回答中提到 Otlex、另一個平台與一篇產業報導，旁邊只列出報導 URL。此時可以標記 Otlex 的 mention；citation 要記為「自有網域未出現」；recommendation 是否成立，則先把這筆交給預先設定的推薦判讀規則，不要因為品牌被列在清單中就直接加一個肯定值。

另一個回答可能只引用 EthorX 的一篇說明頁，卻沒有在文字中提到品牌名稱。此時可以有 citation，mention 則依回答原文判斷。還有一種情況是回答明確說「如果你需要某種條件，可以考慮某品牌」，但來源是第三方評測。它可能同時有 mention 和 recommendation，卻沒有自有 citation。事件欄位分開後，這些組合都能保留，不必硬選一個代表答案。

證據：什麼資料才足以標記一個事件

Mention 要保存上下文，不只存品牌布林值

「有提及」的最低證據是原始回答中能找到品牌名稱，或你事先核准的別名。若產品名容易和一般詞混淆，還要保存前後句，確認它指向的是目標實體。例如「Otlex」出現於一段討論 AI 搜尋工具的句子，和出現在無關的網址或使用者自訂文字中，判讀可信度不同。

建議至少保存：

原始回答或可回看的檔案識別
brand_mentioned 的判定值
出現的精確字串與品牌別名
句子位置或回答段落
是否為問題重述、引用內容、旁註或回答主體

最後一項很重要。回答可能把問題原文照抄一次，裡面剛好含有品牌名；這和模型在回答中主動描述品牌，不一定是同一種現象。事件表不必替它發明更高的分數，只要留下上下文，後續審核就有依據。

Citation 要保存「回答如何指向來源」

引用的證據不是單純出現一個網址。你要記錄來源是以內文連結、citation 標記、Sources 面板、來源卡，還是只有一個網域名稱出現。若平台只讓你看到來源名稱，先保存看得到的名稱；取得完整 URL 後再補進資料，缺少證據時別自己猜路徑。

OpenAI 的 ChatGPT Search 說明指出，使用搜尋的回答可能包含 citations，使用者可以打開來源；同時官方提醒結果與 citations 可能不完整、過時或錯誤。這就是為什麼引用事件要包含觀測時間與原始回答，而不是只存一個最後整理過的 URL。

Google Search Central 的 AI features 文件則描述 AI Overviews 與 AI Mode 可顯示支援回答的連結，且頁面要先符合一般 Search 的索引與技術條件。這支持「來源連結值得留證」的做法，但沒有提供一個可套用各平台的 citation 計分公式。

Recommendation 需要決策語境，先存證據再判讀

推薦事件不能脫離問題判斷。題目是「Otlex 是什麼？」時，回答把 Otlex 描述成產品，這比較接近品牌或產品資訊；題目若是「台灣有哪些適合某種需求的 AI 搜尋優化平台？」回答把 Otlex 列入選項並說明適用理由，才有足夠上下文進入 recommendation review。

這篇只把決策語境、品牌位置與原文保存好。推薦強度、理由是否充分、哪些條件算有效，看 AI 是否能保證品牌推薦。兩篇分開，事件分類才不會偷偷帶入一套未經審核的推薦結論。

說明：同一個回答可以同時有多種事件

用事件列和來源列分開保存

一個回答可能有三個品牌和五個來源。如果每個回答只留一列，你會遇到兩個問題：一是無法知道哪個來源支援哪個品牌，二是多來源被壓成一個「有引用」後，無法回頭檢查 URL。比較清楚的資料模型是三層：

answer_event 保存問題、平台、時間、原始回答與整體狀態。
entity_event 保存每個品牌的 mention、recommendation 判讀與回答位置。
source_event 保存每個可見來源、URL、來源類型與它在回答中的位置。

這樣同一個回答可以有一筆 answer_event、三筆 entity_event 和五筆 source_event。你不必先決定哪一個欄位最重要，資料可以保留回答的完整關係。

來源存在不等於來源支撐每個句子

回答畫面上列了來源，只能說這些來源被呈現。要判斷「來源是否支撐品牌描述」，仍應把回答中的主張與來源頁面放在一起核對。舉例來說，來源頁可能能證明公司名稱，卻沒有寫到回答所說的產品價格；這時可保留 citation 事件，但把主張支撐狀態標為「需人工核對」。

這個區分也能避免常見的反向誤判：只要某個品牌有 citation，就把回答裡所有句子都當成第一方資料。來源頁真正寫了什麼，還是要逐句讀回。沒有做到這一步，就把欄位命名成「來源呈現」，別寫成「主張已驗證」。

事件狀態和資料可用性要分開

回答沒有品牌提及，和回答根本沒有成功取得，含義不同。前者是一次有效回答中的事件結果；後者是執行狀態。建議把下列欄位分開：

層次	例子	判讀
執行狀態	success、timeout、blocked	這次觀測是否取得可讀回答
回答狀態	answer、empty、error	回答內容是否足以進一步判讀
事件結果	mention、citation、recommendation	在有效回答中看到了什麼
來源核對	fetched、redirected、needs review	可見來源是否已另行讀回

一次執行逾時，mention 就不能填成 false，因為你根本沒有取得回答。若回答成功但沒有提到品牌，才可以依規則記錄 mention 未出現。資料表保留這種差異，後續的 coverage 和分母才不會失真。

實作：從原始回答到事件表

第一步，先寫事件字典

在固定要觀測的那組問題之前，先把標記規則寫在工作文件。字典不用長，但要回答「看到什麼才算」、「看不到什麼要留空」與「誰需要人工複核」。例如：

欄位	`yes` 的條件	`no` 或待審核條件
`brand_mentioned`	回答文字出現核准品牌名或別名，且上下文指向目標實體	沒有出現；問題本身出現但回答沒有重述時要依規則處理
`own_domain_cited`	來源呈現中可辨識自有網域或 URL	只有第三方來源；來源不可讀時保留待審核
`recommendation_review`	問題有選擇意圖，回答把品牌和用途、條件或理由連起來	只有品牌清單、定義或背景敘述
`answer_valid`	取得可讀且與題目有關的回答	執行失敗、空回答或無法判讀

「待審核」是很實用的狀態。它表示規則遇到邊界案例，不需要逼著資料表立刻選 yes 或 no。後續定義更新時，再把同一批案例重新判讀即可。

第二步，保存不可替代的原始欄位

最小資料列可以長這樣（example-001 是示範用的值）：

answer_id: example-001
prompt_id: CATEGORY-04-v1
prompt_text: 台灣有哪些適合 B2B 團隊的 AI 搜尋優化平台？
engine: example-search
language: zh-Hant
region: Taiwan
observed_at: 2026-09-21T14:10+08:00
execution_status: needs_review
answer_text: 原始回答保存位置
visible_sources: 當下看得到的來源卡文字與連結
brand_events: needs_review
own_citation: needs_review
reviewer: assigned-reviewer

真實專案還可以加上模型或模式、問題清單版本、網站修改版本與權限。重點是先保存原始資料，再做摘要欄位；別只保存摘要而刪掉回答全文。若資料包含個人或客戶資訊，應先依專案的存取與保存政策清理，不能為了方便把私人內容丟進公開報告。

第三步，逐筆執行四個檢查

先看執行狀態。 確認回答是否成功取得，記錄失敗原因。失敗資料留在原始表，但不進入有效回答事件的分子。
再看回答文字。 找到品牌名稱、別名與上下文，記錄提及位置。這一步只判斷 mention，不順便判斷推薦。
接著看可見來源。 保存來源名稱、網域、完整 URL、呈現方式與位置。URL 正規化可以另做，原始顯示值要保留。
最後看決策語境。 若題目要求選擇方案，再把候選品牌送進 recommendation review。沒有選擇意圖的題目，不要因為品牌描述很正面就改成推薦事件。

跑完這四步，再產生報表需要的比例或分布。報表欄位要能點回 answer_id，審核者才不用靠一張模糊截圖猜測你怎麼標記。

第四步，處理同義品牌與更名

品牌別名要有版本。公司、產品或服務名稱可能有英文、中文、舊名或縮寫，如果一開始沒有字典，後續每個人會用不同方式搜尋。可以為每個品牌保存 entity_id、核准名稱、別名、有效日期與排除詞。

但別名表也有反效果。若某個普通詞和品牌同名，只因字串吻合就判定 mention，資料會看起來比實際更好。遇到歧義時保留原文與人工判讀狀態，並在報告說明排除規則。

留證之後仍然看不到的東西

不同 AI 產品的來源介面不一樣。有的顯示完整 URL，有的先顯示來源卡或網域，還會因裝置、登入狀態與搜尋模式而不同。OpenAI 提醒 ChatGPT Search 的 citations 可能不完整、過時或錯誤；Google 說 AI Overviews 與 AI Mode 的模型與連結集合可能不同，頁面符合技術要求也不保證被抓取、索引或提供。所以任何跨平台的表格都要標明取得方式與觀測條件，「這次沒有 citation」的解釋要回到執行狀態、頁面可抓取性、問題情境與其他來源，而不是直接寫成內容失效。

推薦事件要獨立判讀。品牌提及和 citation 可以直接從事件表取得，推薦則要先定義題目有沒有選擇意圖、回答有沒有給條件與理由。所以這篇不把清單裡的每個品牌都標成推薦。

接下來可以看什麼

要先看整體指標與分母，讀 AI Visibility 的量測框架；主要問題是「引用了哪一個頁面」的，讀 Citation Tracking 的追蹤方法。兩者都能用這篇的事件表，分析層次不同。想看 ChatGPT 的固定問題怎麼保存，看 ChatGPT 品牌監測流程。

我們的 Otlex 是 EthorX 開發的 AI 搜尋優化平台，觀測品牌在 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 七個 AI 引擎回答中的提及、引用與推薦，並把結果連回內容缺口。需要一起釐清觀測範圍、資料欄位與內容或網站調整的，EthorX GEO 服務有專案範圍的說明。

常見問題

品牌被 AI 提到，就代表官網被引用嗎？

提及只需要在回答文字中找到品牌名稱，引用還要有可辨識的來源關係。實際上很常見的一種組合是：回答用一篇第三方報導描述你的品牌，名字出現了，來源是別人的網站。兩個欄位分開保存。

只看到來源網域，可以直接補成完整 URL 嗎？

先保存畫面上真正看到的網域與來源名稱，拿到完整 URL 再補。讀不到頁面時把 URL 狀態留在待核對。補一個 /pricing 進去，下一輪沒有人分得出那是觀測到的還是推測的。

一個回答可以同時有 mention、citation 和 recommendation 嗎？

可以，而且並不少見。它們是三個獨立欄位，不會互相排斥。要審核的是每一欄的證據符不符合規則，以及那個問題有沒有足夠的選擇意圖支撐推薦判讀。問題本身只是在問定義的話，推薦那一欄就留空。

回答失敗時，品牌 mention 應該填 0 嗎？

執行失敗的意思是沒有拿到可判讀的回答：保存失敗狀態，並排除於有效回答的事件分子。填 0 等於在資料裡憑空製造一筆「AI 沒提到你」。取得有效回答、確認裡面真的沒有品牌，才記成未提及。

沒有完整 URL 時，如何避免誤判 citation？

先保存實際看見的來源名稱、網域、呈現方式和位置，完整 URL 標成待核對。要比較 citation 事件，就用固定問題保存回答、來源和觀測條件。缺 URL 是一個已知的資料狀態，猜一個路徑填進去則是一筆看不出來的錯誤資料。

品牌提及和引用有什麼不同？先把 AI 回答事件分開留證