品牌提及、引用、推薦是三種事件:提及是回答文字裡出現品牌名稱;引用是回答把某個網域或網址呈現為來源;推薦還要看品牌有沒有被放進選擇情境、回答有沒有交代適用條件或理由。三者可以同時發生,也可以只出現其中一種。這適用於要把 AI 回答變成可比較資料的團隊;先保存原始問題、回答、可見來源與執行條件,再依預先寫好的規則各自標記——規則寫在看到結果之前。本文提供的是可以直接建欄位的東西:三種事件的最小定義與證據要求、判讀順序、常見誤判、失敗狀態怎麼處理。
三者的差別,用一場聚餐來想最快。有人在飯桌上提到你的公司,那是提及;有人說「這個數字是從他們官網看到的」,那是引用;有人說「你這種規模的團隊,去找他們談談」,那才是推薦。三句話可以出自同一場對話,也可能整晚只出現第一句。
報告把三者混成一欄的話,「品牌出現了」和「哪個頁面被採用」就再也分不開了。
定義:品牌提及和引用有什麼不同?三種事件各自回答什麼問題
先別急著算比例。把一個回答當成一份要審核的紀錄,至少拆成三個問題:品牌有沒有出現在回答文字裡?回答有沒有顯示某個來源?品牌有沒有被放進使用者要做選擇的情境?三個問題的證據來源不同,後續要做的工作也不同——提及不對要修實體描述,引用不對要查頁面,推薦不足要補適用條件。
| 事件 | 最小定義 | 需要看到的證據 | 可以往哪裡追 |
|---|---|---|---|
| Mention,品牌提及 | 回答文字出現可辨識的品牌或產品名稱 | 原始回答中的品牌字串與上下文 | 品牌名稱、別名、描述是否正確 |
| Citation,引用 | 回答顯示某個可辨識的來源網域或 URL,且能和回答建立來源關係 | 來源卡、內文連結、URL 或可辨識來源文字 | 哪一頁被採用、頁面是否能支撐該句 |
| Recommendation,推薦 | 在具有選擇意圖的問題中,品牌被列為可考慮選項,並附帶條件、用途或理由 | 問題的決策語境、回答中的品牌位置與推薦理由 | 品牌是否與類別、用途和適用條件連得起來 |
這裡的「最小定義」是編輯觀測規則,不是所有 AI 平台共同公布的標準。它要解決的問題很實際:同一個團隊在今天和三個月後讀到類似回答時,判定要落在同一個位置。各憑直覺標記的話,最後那張表每一格都填滿了,卻沒有兩格用同一把尺。
品牌提及、引用來源與推薦判讀應分開保存。
一個回答的三種可能組合
假設問題是「台灣有哪些 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。後續定義更新時,再把同一批案例重新判讀即可。
第二步,保存不可替代的原始欄位
最小資料列可以長這樣。以下是虛構的格式示例,不是實測結果;時間與來源欄位只示範保存方式:
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 產品的來源 UI 不一定呈現相同欄位。有的平台顯示完整 URL,有的平台先顯示來源卡或網域,還可能因裝置、登入狀態與搜尋模式而不同。OpenAI 官方已提醒 citations 可能不完整、過時或錯誤,所以任何跨平台表格都要標明取得方式與觀測條件。
Google 官方目前說明 AI Overviews 與 AI Mode 的模型與連結集合可能不同,頁面符合技術要求也不代表一定會被抓取、索引或提供。這表示「這次沒有 citation」的解釋仍需要回到執行狀態、頁面可抓取性、問題情境與其他來源,而不是直接寫成內容失效。
頁面的抓取、索引與搜尋資格是另一層技術條件,不能代替事件留證。Google 現行指南提醒符合資格不代表一定會被抓取、索引或提供;因此 citation 和 recommendation 仍要回到實際回答、可見來源與觀測條件核對。
最後,推薦事件本身需要獨立判讀。品牌提及和 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 是一個已知的資料狀態,猜一個路徑填進去則是一筆看不出來的錯誤資料。
查證邊界
本文的外部文件查閱日期為 2026-09-21,包含 Google Search Central 的 AI features、generative AI optimization guide、文件更新頁,以及 OpenAI Help Center 的 ChatGPT Search 說明。事件字典、資料表與待審核狀態是本文提出的工作方法,不是各 AI 平台共同公布的標準。平台的回答、來源介面與可取得欄位可能更新,使用前應重新讀取目標產品文件與實際來源。