Baiyuan GEO Platform Whitepaper

Chapter 9 — Hallucination Repair:Closed-Loop 幻覺偵測與自動修復

偵測幻覺只是第一步；若沒有「修復 → 驗證 → 收斂」的閉環，幻覺會像草一樣春風吹又生。

Hallucination Repair(中文：幻覺修復)是百原 GEO Platform 的核心 SaaS 功能模組,對應 admin dashboard /dashboard/hallucination 頁面（標題顯示「幻覺修復中心」）。本章介紹此 Hallucination Repair 系統從偵測、判定、生成 ClaimReview、注入、再驗證的六階段全自動化閉環設計與技術實作。

目錄

9.1 為什麼「偵測」不足、需要「閉環」

傳統品牌監測工具的邏輯是：發現問題 → 通知客戶 → 客戶自己想辦法。這在傳統 SEO 時代可以接受，因為問題通常是「可見性不足」——客戶自己寫新內容、發外鏈就能改善。

但 AI 幻覺不同：

結論：光把問題丟給客戶是不負責任的。平台必須提供「從偵測到收斂」的完整自動化閉環。

Fig 9-1：閉環六階段

flowchart LR
    A[① 偵測<br/>抽取聲明] --> B[② 比對<br/>對照 Ground Truth]
    B --> C[③ 判定<br/>是否為幻覺]
    C -->|是| D[④ 生成<br/>ClaimReview]
    D --> E[⑤ 注入<br/>AXP + RAG]
    E --> F[⑥ 重掃驗證<br/>哨兵 + 完整]
    F -->|收斂| Done[結案]
    F -.->|仍存在| D
    C -->|否| Skip[不處理]

Fig 9-1: 從偵測到結案的六階段。任一階段失敗不影響其他阶段，系統具備局部容錯。

9.2 AI 幻覺的五種類型

百原平台將 AI 關於品牌的錯誤分成五類，各有不同的偵測與修復策略：

Fig 9-2：幻覺分類樹

flowchart TD
    Hallu[AI 幻覺]
    Hallu --> E1[① 實體錯置<br/>Entity Misidentification]
    Hallu --> E2[② 業務錯誤<br/>Business Fact Error]
    Hallu --> E3[③ 產業誤分<br/>Industry Miscategory]
    Hallu --> E4[④ 時空錯誤<br/>Temporal/Spatial Error]
    Hallu --> E5[⑤ 屬性錯誤<br/>Attribute Error]
    E1 -.->|範例| EX1["把台灣品牌說成日本公司"]
    E2 -.->|範例| EX2["把產品線描述成競品的"]
    E3 -.->|範例| EX3["把牙醫診所歸類成醫美"]
    E4 -.->|範例| EX4["把 2025 開業說成 2010 老店"]
    E5 -.->|範例| EX5["把 B2B SaaS 說成消費者 App"]

Fig 9-2: 五類幻覺並非互斥，一次 AI 回應可能同時包含多類；修復優先級依影響程度排序。

修復策略差異

類型 優先級 DB error_type 欄位值 主要修復手段
實體錯置 P0 entity_misidentification Schema.org sameAs 強化 + ClaimReview + Wikidata 連結
業務錯誤 P0 business_fact_error 在 AXP 明示正確產品線 + ClaimReview
產業誤分 P1 industry_miscategory 修正 industry_code + Schema.org @type + RAG 同步
時空錯誤 P1 temporal_spatial_error foundingDate / address 明確化 + ClaimReview
屬性錯誤 P2 attribute_error 強化描述、加入 FAQ、修正 audience

P0 類型直接影響品牌被誤認，必須最快修復；P2 多為語意偏差，較不急。

Dashboard 雙維度 filter:error_type × severity

百原 Hallucination Repair dashboard 對偵測結果同時支援兩個獨立維度的 filter:

LLM 偵測階段同時 emit 兩個維度(對應 hallucination_detections 表的 error_type 與 severity 欄位),Dashboard 兩維度獨立 filter 不互斥。error_type 透過 DB-level CHECK constraint 鎖死五分類 enum,防 LLM emit 非法值污染統計。

9.3 偵測主機制：NLI 分類 + Chainpoll 投票

實務上若只做「抽取 claim → 與 Ground Truth 比對」的單點查找，會遇到兩個核心問題：

  1. GT 覆蓋率低 — 沒人有辦法把品牌所有事實都手動窮舉成 key-value，缺漏就產生誤報
  2. 精確比對過嚴 — 同一事實有多種正確表達（「成立於 2018」vs「2018 年創立」vs「已有 7 年歷史」），字串比對會把正確的說法誤判為幻覺

百原平台的偵測主機制是 NLI（Natural Language Inference）三分類，GT 比對只是 NLI 所需知識來源的其中一層 fallback。

6 階層知識來源 authority chain(對齊 §平台鐵律「RAG LLM WIKI 是最終事實源」)

百原 GEO Platform 任何「比對 / 驗證 / 反駁 / 修正」走 6 階層 authority chain(平台鐵律,2026-04-29 用戶定錨):

flowchart TB
    Resp[AI 回應原文] --> Ext[原子事實抽取<br/>LLM]
    Ext --> NLI[NLI 判定器]
    subgraph KS["6 階層 authority chain(權威度由高到低)"]
      K1["<b>L1 ★★★★★</b><br/>brand_website_cache + 中央 RAG KB<br/>客戶官網第一手,最權威"]
      K2["<b>L2 ★★★★</b><br/>ground_truths<br/>verified_at 不為 null"]
      K3["<b>L3 ★★★★</b><br/>brand_marketing_facts<br/>時間序列 + source_url"]
      K4["<b>L4 ★★★</b><br/>brand_faq<br/>結構化 Q&A"]
      K5["<b>L5 ★★★</b><br/>personal_profiles<br/>brand_type='personal_ip' 才有"]
      K6["<b>L6 ★★</b><br/>brand_taglines<br/>口號(master + 變體)"]
    end
    K1 --> NLI
    K2 --> NLI
    K3 --> NLI
    K4 --> NLI
    K5 --> NLI
    K6 --> NLI
    NLI --> Cls[分類結果<br/>entailment / contradiction /<br/>neutral / opinion]

Fig 9-3: 6 階層知識來源全部組合成一段 context 餵給 NLI。若合計 < 500 字則跳過偵測(避免在資料稀疏的狀態誤判)。對應 PROD hallucinationDetector.service.js#extractAndVerifyClaims v3.29.415 R3 擴展自 3 層為 6 階層。

為何要 6 階層而非單一 RAG:

這 4 個 SSOT 是「客戶在 GEO Platform 內主動維護的結構化事實」,比 RAG L1 語意檢索更精確,但覆蓋面窄。combine 6 階層讓 NLI 同時擁有「廣度(RAG)+ 精準度(L2-L6 結構化)」。

L1 品牌官網即時抓取的 SSRF 守門(對 1 萬租戶 readiness security):

L1 知識來源中「品牌官網即時抓取」涉及 server-side fetch 任意 user-controlled URL, 需防 SSRF(Server-Side Request Forgery)攻擊:

對應 PROD hallucinationDetector.service.js#fetchWebsiteText v3.29.282 R16 P2 加守。 任何 user / LLM-returned URL 進 server-side fetch 都必經此守。

NLI 四分類定義

類別 意義 處理
entailment 知識來源明確支持 claim 事實正確、通過
contradiction 知識來源與 claim 明確矛盾 判定為幻覺，進入修復流程
neutral 知識來源無法確認也無法否認 不判定（重要：neutral 不是幻覺）
opinion 主觀評價（「最好的」「值得推薦」） 跳過，主觀不做事實查核

NLI 模型同時為每個 claim 打一個 confidence（0.0–1.0）與 severity（critical / major / minor / info）。

為何「neutral ≠ 幻覺」是核心原則

最常見的誤設計是「知識來源沒提到就視為錯誤」。但品牌官網不可能列舉所有事實，AI 說「該公司有 50 名員工」若官網沒有員工數頁面，不代表這個數字是錯的，只代表我們無法驗證。把 neutral 誤判為 contradiction 會大量製造假幻覺，引發錯誤的修復動作，使 AI 下一輪閱讀到被「修正」為錯誤的內容。

Neutral 追蹤機制(hallucination_neutral_tracking 表):

平台不直接把 neutral claim 丟棄,而是寫入 hallucination_neutral_tracking 表追蹤:

這個機制讓「平台無法驗證」的灰色地帶有獨立管道,而非被誤分入 contradiction 或被完全忽略。

多源定向驗證(cross_platform_count)

對 contradiction 已 confirmed 的 claim,平台會在 hallucination_detections 表加 cross_platform_count:

對應 PROD hallucinationDetector.service.js line 388-405 多平台跨檢測邏輯。 1 萬租戶 readiness:此設計避免「修一個平台、其他平台繼續錯」的 whack-a-mole 問題。

Chainpoll：不確定地帶的二次確認

對 confidence ∈ [0.5, 0.8] 的不確定 claim，系統啟動 Chainpoll 多數決(對齊 PROD v3.29.392 cost optimization + v3.29.388 Redis cache 設計)：

// 同一 claim 以同一 prompt 呼叫 LLM 三次，取多數結果
async function chainpollVerify(brandName, platform, claim, knowledgeContext) {
  // v3.29.388 Redis 24h cache(同 claim+brand+knowledge_ctx hash 不重跑)
  const cacheKey = sha256(`${brandName}|${platform}|${claim}|${knowledgeContext}`);
  const cached = await redis.get(`hallucination_chainpoll:${cacheKey}`);
  if (cached) return JSON.parse(cached);  // ← 60-70% hit rate,1 萬租戶月省 $25-50

  const votes = { contradiction: 0, entailment: 0, neutral: 0 };
  const prompt = buildNLIPrompt(claim, knowledgeContext);

  // v3.29.392 split feature key:用 hallucination_detect_eval(judgment task,
  //   配 deepseek-chat 低 cost model),省 70% chainpoll cost($36 → $11/月)
  const results = await Promise.allSettled([
    aiCall('hallucination_detect_eval', prompt, { maxTokens: 20 }),
    aiCall('hallucination_detect_eval', prompt, { maxTokens: 20 }),
    aiCall('hallucination_detect_eval', prompt, { maxTokens: 20 }),
  ]);

  for (const r of results) {
    if (r.status !== 'fulfilled') continue;
    const text = (r.value.text || '').toLowerCase();
    if (text.includes('contradiction')) votes.contradiction++;
    else if (text.includes('entailment')) votes.entailment++;
    else votes.neutral++;
  }

  // Cache write(fail-safe:Redis 失效不擋主流程)
  await redis.setEx(`hallucination_chainpoll:${cacheKey}`, 86400, JSON.stringify(votes));
  return pickMajority(votes); // 2/3 以上才採信
}

Chainpoll 有效降低單次 LLM 幻覺分類本身的雜訊（畢竟分類器也是 LLM，也會有隨機性）。高 confidence（> 0.8）與低 confidence（< 0.5）的 claim 不觸發 Chainpoll，只有在模糊地帶才啟動，成本可控。

雙層 cost optimization(對 1 萬租戶 readiness):

Fail-safe 設計:Redis miss / connection error 自動 fallback 跑 3x LLM 原邏輯(對齊 §平台鐵律 defensive guard)。

Main extraction vs Chainpoll judgment 的 model 分工(R3 v3.29.415 對齊細節)

百原 Hallucination Repair 對「LLM 用什麼模型」做兩段分工,對齊不同 task 特性:

階段 feature key maxTokens Model 對應(modelRouter SSOT) 任務特性
主路徑:原子事實抽取 + NLI 三分類 hallucination_detect 2000 高品質 reasoning model(預設 anthropic/claude-haiku) 多 claim 結構抽取 + JSON output + 嚴重度判定,需 reasoning
Chainpoll 二次驗證 hallucination_detect_eval 20 低 cost judgment model(預設 deepseek-chat) 只回 1 詞(entailment / contradiction / neutral),pure judgment task

設計取捨:

False positive 反饋迴路(客戶可標「這不是幻覺」)

NLI 即使有 Chainpoll + 6 階層知識來源仍可能誤判。Hallucination Repair 提供客戶端 false positive 反饋機制:

這條反饋迴路讓 Hallucination Repair 系統能從客戶判斷學習,持續降低 FP rate。

嚴重度分類

一旦被判定為 contradiction，嚴重度欄位決定修復優先級：

Severity 判定標準 修復排程
critical 公司名稱、產品類別、國家／地點完全錯誤 立即啟動修復，24h 內注入
major 核心功能、價格錯誤 24h 內修復
minor 次要功能、規格偏差 週期掃描時修復
info 措辭不精確 累積到一定數量才處理

這個分級讓資源集中處理會造成商業損失的幻覺，避免被小瑕疵淹沒。

9.4 中央共用 RAG：SaaS 架構的關鍵基礎設施

上節的 L2 RAG 知識庫 並非每個租戶各自建置，而是整個百原 SaaS 平台共用一座中央 RAG 引擎（以下以「中央 RAG」稱之）。這是很容易被工程團隊跳過但影響深遠的架構決策。

為何用中央共用 RAG 而非每租戶獨立 RAG

面向 每租戶獨立 RAG 中央共用 RAG（百原採用）
運維成本 每個租戶需獨立部署／擴容 單一集群維護
模型推論成本 每租戶單獨跑 embedding／LLM 共享 GPU/API 資源，攤提成本
知識圖譜協同 租戶間無法互相驗證 中央可做跨租戶事實交叉比對（去識別化）
升級速度 每租戶需個別升級 一處升級、全平台同步
隔離風險 隔離天然明確 需設計 tenant isolation（X-Tenant-ID + 資料權限）

百原選擇中央共用，用工程設計換取規模效率。租戶隔離透過三層機制維持：

  1. HTTP header X-Tenant-ID — 每次查詢帶租戶識別，RAG 引擎據此過濾文件範圍
  2. API Key 簽章 — 每個 SaaS 後端呼叫 RAG 都帶 X-RAG-API-Key，RAG 端驗證來源
  3. RLS / 文件 ACL — 每個文件 ingest 時標記擁有者租戶，查詢時強制過濾

這三層與本平台自身的 RLS 雙保險（§2.5）類似：任何單一層疏漏都需要另外兩層同時失守才會發生跨租戶洩漏。

品牌層級隔離（2026-04-21 更新）：租戶內若有多個品牌，各品牌更進一步使用獨立的 Knowledge Base ID（rag_kb_id）區隔知識範圍。AXP 生成時指定該品牌的 kbId，確保不同品牌（如同一租戶下的「醫美品牌」與「美食品牌」）的事實互不污染。新品牌啟用 AXP 時，seedBrandRAGKB 函數自動建立 KB 並上傳品牌 Profile 與官網頁面 URL，詳見 §6.9。

Fig 9-4：中央共用 RAG 的架構

flowchart LR
    subgraph Platform["百原 GEO SaaS（應用層）"]
      T1[Tenant A<br/>後端]
      T2[Tenant B<br/>後端]
      T3[Tenant N<br/>後端]
    end
    subgraph RAG["中央 RAG 引擎"]
      direction TB
      Gate["API Gateway<br/>X-Tenant-ID / X-RAG-API-Key 驗證"]
      subgraph Core["引擎核心"]
        W["<b>L1 LLM Wiki</b><br/>語意處理層"]
        V["<b>L2 RAG</b><br/>Vector Retrieval"]
        W --> V
      end
      Gate --> Core
    end
    T1 -->|POST /api/v1/ask<br/>X-Tenant-ID: A| Gate
    T2 -->|POST /api/v1/ask<br/>X-Tenant-ID: B| Gate
    T3 -->|POST /api/v1/ask<br/>X-Tenant-ID: N| Gate
    V --> Ans[按租戶範圍過濾的答覆]

Fig 9-4: 所有租戶共用同一座 RAG，但所有查詢都經 Gateway 依 Tenant ID 過濾文件範圍。

9.5 L1 LLM Wiki：被動檢索之上的主動語意層

Wiki 在本架構中不是一般意義的「文件儲存」，而是一層由 LLM 主動處理與維護的語意知識層。它是整個幻覺偵測能運作的基礎設施，值得獨立章節深入描述。

9.5.1 為何不直接對原始文件做向量檢索

一個直覺的設計是：客戶上傳的官網、FAQ、產品頁直接做 embedding、存向量 DB，查詢時直接檢索。這種純「被動 RAG」的設計有三個嚴重缺陷：

這三個缺陷在通用 RAG 應用（如客服問答）中可容忍，在事實查核場景中是致命的。

9.5.2 LLM Wiki 的處理流程

LLM Wiki 是百原自建的語意處理層，對每筆 ingest 的文件執行以下處理：

Fig 9-5：LLM Wiki 的文件生命週期

flowchart TB
    In[新文件 ingest<br/>客戶上傳 / 官網爬 / API 推送] --> Norm[正規化<br/>去格式、抽純文字]
    Norm --> Segment[語意分段<br/>依主題切 chunk]
    Segment --> Ext[實體抽取<br/>主語／屬性／事實三元組]
    Ext --> Compare{與既有 Wiki 比對}
    Compare -->|新增事實| Add[加入 Wiki]
    Compare -->|矛盾| Conflict[標記衝突<br/>保留最新＋註記舊版]
    Compare -->|補充| Merge[合併更完整的描述]
    Add --> Reindex[增量編譯<br/>更新向量索引 + 知識圖譜節點]
    Conflict --> Reindex
    Merge --> Reindex
    Reindex --> Ready[對 L2 RAG 檢索可用]

Fig 9-5: Wiki 不只儲存文件，還主動維護「當前應被視為真實」的事實集合。任何新文件進來都會觸發對既有知識的一次再評估。

9.5.3 增量編譯（Incremental Compilation）

傳統 RAG 系統在新增／更新文件時，常需要「重建整個向量索引」，成本高到無法頻繁做。LLM Wiki 採用增量編譯：

對幻覺偵測的意義：修復 ClaimReview 注入 Wiki 後幾分鐘內，NLI 查詢就能使用到修正後的事實。不需等待夜間重建或週末 downtime。

設計取捨說明:早期 spec 曾規劃 valid_from / valid_to 雙時間戳設計支援「特定時點查詢」, 但實作後發現 NLI 查核場景只需「當前事實」,不需歷史時點重建。 改用 version + status 二元組降低 schema 複雜度,同樣支援回溯需求, compiled_at 提供 audit 時間追蹤。對應 PROD cs_rag_db.wiki_pages 表 schema。

9.5.4 LLM Wiki 的核心能力

LLM Wiki 以下列原生能力支援事實查核需求：

百原透過一層薄的 REST API 把 LLM Wiki 能力暴露給業務層，對業務層隱藏底層實作細節。任何底層 LLM 或向量引擎的替換都可在此層局部進行，不影響業務層。

9.5.5 L1 Wiki 對 L2 RAG 的啟用角色

L2 RAG 的向量檢索表面上看像「標準 RAG」，但其索引內容來自 L1 Wiki 處理後的結構化事實，而非原始文件。這個差異意味著：

換言之：L1 Wiki 是「知識本體」，L2 RAG 是「知識檢索」。沒有 L1，L2 只是一個更快的原始文件搜尋工具。

9.5.6 修復觸發 Wiki 增量重編(Hallucination Repair → Wiki recompile chain)

§9.5.3 承諾「修復注入到 Wiki 後幾分鐘內 NLI 查詢就能使用修正後的事實」。此承諾透過 Hallucination Repair 的 autoRepairHallucination chain 真實兌現:

flowchart LR
    Hit[偵測 contradiction<br/>confirmed] --> Auto[autoRepairHallucination]
    Auto --> A1[路徑 A<br/>axpQueue add axp-refresh]
    Auto --> A2[invalidateAllCrawlerAssets]
    Auto --> A3[compileWikiForBrand<br/>fire-and-forget]
    A3 --> WC[wikiCompiler<br/>增量重編 3-5min]
    WC --> Ready[NLI 查詢可用修正後事實]

這條 chain 是 Hallucination Repair 由「修復 AXP 文檔」延伸到「修復 NLI 知識上下文」的關鍵環節,確保下一輪 Chainpoll 投票拿到的 knowledge_context 已經是修正後事實。

function isHallucination(claim, groundTruth) {
  const gtValue = groundTruth[claim.predicate];
  if (!gtValue) return 'unknown'; // 沒 GT 資料，不判定
  return normalize(claim.object) !== normalize(gtValue)
    ? 'confirmed'
    : 'correct';
}

unknown 狀態代表平台沒有足夠資訊判定。這是重要設計：寧可標示「待驗證」，也不隨便判定為幻覺。誤判會觸發不必要的修復動作，反而可能引入新錯誤。

9.6 修復：ClaimReview 生成與多路徑注入

ClaimReview Schema.org 範例

{
  "@context": "https://schema.org",
  "@type": "ClaimReview",
  "datePublished": "2026-04-18",
  "url": "https://baiyuan.io/claims/founding-year",
  "claimReviewed": "百原科技成立於 2018 年",
  "itemReviewed": {
    "@type": "Claim",
    "appearance": "AI-generated response",
    "firstAppearance": "2026-04-16"
  },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "1",
    "bestRating": "5",
    "alternateName": "False"
  },
  "author": {
    "@type": "Organization",
    "name": "百原科技",
    "url": "https://baiyuan.io"
  }
}

ClaimReview 是 Schema.org 正式 property，Google、Facebook、Twitter 等平台都支援解析。它不是百原自定格式，而是與全球 fact-checking 生態系相容的標準1。

Addon 訂閱前提(R6 對齊 PROD 實作揭發)

Hallucination Repair 自動偵測需以下兩個條件同時滿足才會觸發:

  1. 客戶有效訂閱:tenant_addons.addon_key = 'hallucination_repair' 且 status IN ('active','trial')(且 trial 未過期)
  2. 品牌有 Ground Truth:ground_truths WHERE verified_at IS NOT NULL 至少 1 筆(closedLoop sentinel 條件)

兩者任一不滿足 → closedLoop worker 雖然按 cron 跑(sentinel 4h / full 24h),但 runPostScanDetection 直接 return 不做幻覺判定。

例外:users.billing_exempt = TRUE 的平台自家 user(geo-baiyuan / me-baiyuan 等 demo brand)不需訂閱也自動跑。

對應 PROD R6 audit 發現(2026-05-26):tenant_addons 表 0 rows 訂閱 hallucination_repair → 雖然 closedLoop 14 天累計 339 cycles,但全 0 detection。對齊 §9.8 PROD baseline 統計樣本來源:歷史 3366 detections 來自有訂閱 + GT 的 brand,訂閱失效後新增 0。

對 1 萬租戶 readiness 設計取捨:

三條注入路徑

flowchart LR
    CR[ClaimReview] --> P1[路徑 A<br/>AXP 影子文檔<br/>主路徑]
    CR --> P2[路徑 B<br/>RAG 間接同步<br/>v2.9.0 後改設計]
    CR --> P3[路徑 C<br/>GBP LocalPosts<br/>Phase 1 OAuth ✓ / Phase 2-3 規劃中]
    P1 --> AI1[被 AI Bot 爬取]
    P2 --> AI2[被 RAG 檢索<br/>透過源頭 SSOT 更新]
    P3 --> AI3[被 Google AI Overview 引用]
    style P2 stroke-dasharray: 3 3
    style P3 stroke-dasharray: 5 5

Fig 9-6: 同一份 ClaimReview 透過三條管道最大化被 AI 重新看到的機率。路徑 B 在 v2.9.0 後改採間接同步設計；路徑 C 分階段 ship plan。

路徑 A:AXP 影子文檔(主路徑)

路徑 B:RAG 間接同步(v2.9.0 後改設計)

設計取捨說明(v2.9.0 教訓):

早期實作曾直接把「事實更正聲明」格式的 ClaimReview JSON 推到 RAG 知識庫。實測造成 echo chamber: 下游 LLM query「品牌成立於哪一年」會拿到 30% 「正確值 X」+ 70%「平台說 Y 是錯的」這種 meta 內容, 兩種訊號互相 dilute 導致 NLI 信心度下降。

修法改走間接同步:

  1. 不直接推送「事實更正聲明」到 RAG(防 echo chamber 與知識庫污染)
  2. 改透過「AXP 重生 → 平台 SSOT 內容更新 → RAG 下次自動 ingest 修正後事實」
  3. 修正後事實透過 brand_marketing_facts / ground_truths / brand_faq SSOT 進 RAG, 而非「平台說 X 是錯的」這種 meta 內容
  4. 對應實作:compileWikiForBrand(brandId) 觸發 L1 Wiki 增量重編(§9.5.6), wikiCompiler 從更新後 SSOT 重抽事實,RAG L2 自動拿到 fresh embedding

設計取捨總結:Hallucination Repair 的「修復事實」優先於「公告錯誤」, 讓 RAG 知識庫保持「乾淨的正確答案」而非「正反雜訊混合」。

路徑 C:GBP LocalPosts(三階段 ship plan)

當前 99%+ AI bot 引用源(GPTBot / ClaudeBot / Perplexity / Gemini / DeepSeek / Kimi / 等)已由路徑 A AXP 影子文檔涵蓋,路徑 C 是針對 Google AI Overview 特定 SERP feature 的擴展強化。

9.7 兩層掃描閉環

修復注入後，如何驗證「AI 真的改了認知」？需要重掃 — 但頻率不能太低（修復後太久才驗證，使用者失去信任），也不能太高（成本爆）。百原設計兩層掃描分工：

Fig 9-7：兩層掃描分工矩陣

flowchart TB
    subgraph L1["Layer 1: 哨兵掃描 (4h 週期)"]
      T1[針對搜尋型 AI<br/>Perplexity / ChatGPT Search /<br/>Google AI Overview]
      T2[輕量：抽查 5 個指標 query]
      T3[目的：快速驗證<br/>修復是否被抓取]
    end
    subgraph L2["Layer 2: 完整掃描 (24h 週期)"]
      F1[針對知識型 AI<br/>Claude / Gemini / DeepSeek /<br/>Kimi / GPT-4o 等]
      F2[深度：20–60 個 intent query<br/>+ 七維度評分 + 指紋比對]
      F3[目的：確認語料整合、<br/>收斂判定]
    end

Fig 9-7: Layer 1 週期短、針對「會即時抓網」的 AI；Layer 2 週期長、針對「訓練週期長」的 AI。兩層共同構成完整驗收。

為何搜尋型與知識型分層

強行用統一頻率會造成：搜尋型驗收延遲（本來 4h 就能知道，等到 24h 太慢）、知識型誤報（4h 內根本沒來得及抓，誤判為修復失敗）。分層是兩類平台根本不同的必然設計。

Layer 1 與 Layer 2 資料共享

Layer 1 / Layer 2 各自寫不同表(R5 v3.29.417 對齊真實 PROD schema):

下游分析(儀表板趨勢、競品比較)會依需求合併或分離兩層資料:

PROD schema correction(R5 PROD-side audit 揭發):早期 spec 寫的「scan_results 表 + scan_layer 欄位」是設計時暫名,實作落地時改為 closed_loop_cycles.layer(對應每輪 cycle 而非每個 scan row)。客戶端 dashboard 仍走 scans + platform_results 表查詢,Layer 1/2 區分透過 closed_loop_cycles.layer 反查。

Platform-aware re-verification 策略(platform_repair_strategies SSOT)

不同 AI 平台對「修復內容多久能被吸收」差異極大,Hallucination Repair 透過 platform_repair_strategies 表動態查詢每平台對應週期:

Platform type 範例 verify_after_h 適用情境
訓練型(training) 標準版 Claude / Gemini / GPT-4o 168h(7 天) 預訓練語料,等下次模型重訓
混合型(hybrid) Claude with browsing / Gemini Live 48h(2 天) RAG-augmented 模型,定期重 ingest
即時型(realtime) Perplexity / ChatGPT Search / AI Overview 6-12h 實時抓網,修復立即可驗

對應 PROD hallucinationDetector.service.js#scheduleReVerification 內 SQL SELECT platform_type, verify_after_h FROM platform_repair_strategies WHERE platform = $1。

訓練型平台特殊處理:status 標為 awaiting_model_update(而非 repair_applied),客戶端 UI 顯示「待模型更新(預計 N 天後驗證)」,管理用戶期待。

Brand-level closed-loop overrides(客戶可調)

更積極的客戶可開啟 Closed-Loop 模式(brand_closed_loop_overrides.closed_loop_enabled=TRUE),覆寫平台預設週期:

對應 PROD scheduleReVerification line 651-661 closed-loop override 動態讀邏輯。

Re-verification queue + cron sweep(雙觸發機制)

hallucination-verify-queue worker 兩種觸發方式對齊 §平台鐵律「Worker 必須 defensive guard + queue auto-retention」:

  1. 個別 reverify job:autoRepairHallucination 排程 24h 後對單筆 detection 重驗
  2. 定時掃描 cron:每 6 小時撈所有 repair_applied 狀態 detection,batch reverify

worker 對齊 KNOWN_QUEUES retention list,7d failed + 30d completed 自動清。

9.8 收斂時序與驗收

Fig 9-8：一次典型修復的收斂曲線（示意）

%%{init: {'theme':'base'}}%%
xychart-beta
    title "Hallucination Prevalence after Remediation (illustrative)"
    x-axis ["Day 0", "Day 1", "Day 3", "Day 7", "Day 14", "Day 21", "Day 30"]
    y-axis "Hallucination Rate (%)" 0 --> 100
    bar [80, 75, 60, 40, 22, 10, 3]

Fig 9-8: 搜尋型 AI 通常 1–3 天收斂；知識型 AI 通常 2–4 週收斂。圖為聚合示意，個案時程差異大。

收斂判定規則

一個幻覺標記為「已收斂」需滿足：

  1. 連續 N 次掃描（N 由嚴謹度決定，通常 3–5）該 claim 在所有目標平台均未再出現
  2. 等效 claim 變體（同義改寫、翻譯、縮寫形式）也都未出現
  3. Layer 1 + Layer 2 都驗證過一輪（不能只有單層通過）

滿足後 UI 顯示「✅ 已修復」，客戶端記錄並附上收斂時間。

未收斂的處理

若超過預期收斂時程仍存在，系統升級為「頑固幻覺」：

頑固幻覺的處理往往需要人工介入，這是目前自動化閉環的邊界。誠實承認這個邊界，比假裝全自動更負責任。

PROD 實證:> 70% verified_fixed 收斂率(歷次 snapshot)

Hallucination Repair 自動化閉環在 PROD 環境的實測收斂率歷次 sprint snapshot:

統計時點 總偵測量 verified_fixed 收斂率 備註
2026-05-16(R3-r3 P2 audit) 1,101 949 86% 早期樣本(含較多易修 single-platform 案例)
2026-05-26(R4P PROD audit) 3,366 2,472 73.4% 樣本擴大 3 倍後 baseline

樣本量擴大 3 倍後收斂率自然回落(包含更多 cross-platform systemic 與訓練型平台等待 case),但仍 > 70% 全自動收斂:

設計取捨說明:Hallucination Repair 故意採保守策略,寧可放過 confidence 模糊地帶(detected 留作客戶端 review)也不誤觸發修復。 這代表「自動修復 ≠ 全自動修補一切」,而是「> 70% 高信心地帶全自動,剩 30% 模糊地帶交給客戶 Dashboard review」。

這個 73.4% baseline 數據驗證:閉環設計真實 work,不是只有架構圖的紙面功夫。 真實 PROD 收斂率會隨樣本量、平台組成、客戶 FP feedback 動態變動,> 70% 全自動收斂率是穩定 baseline。 未收斂的 26.6% 對應 [§9.8 頑固幻覺] 段,誠實標示需人工 review / 客戶補 SSOT 的邊界。

Audit trail:repair_actions 表全程記錄

每次 Hallucination Repair 動作寫入 repair_actions audit table:

對應 PROD repairRouter.service.js#logRepair chain 寫入。客戶端 dashboard 「修復歷史」tab 直接 query 此表,提供完整 audit trail。

Frontend Dashboard 結構(/dashboard/hallucination)

Hallucination Repair 客戶端 dashboard 路徑 /dashboard/hallucination,標題顯示「幻覺修復中心」(hallucinationCenter.title),含 3 個 tabs:

Tab 路徑 對應 API 用途
總覽(Overview) ?tab=overview /v1/hallucination-repair/brands/:brandId/stats 偵測量趨勢圖 + severity 分布 + 收斂率(PROD baseline > 70%)卡片 + 跨平台 heatmap
偵測紀錄(Detections) ?tab=detections /v1/hallucination-repair/brands/:brandId/detections error_type × severity 雙維度 filter + 每筆 detection 含 false-positive 按鈕
修復歷史(Repair History) ?tab=repair-history repair_actions 表 query 完整 audit trail(timeline + 修復路徑 + 結果)

舊版路徑 /dashboard/hallucination-repair 自動 redirect 到 /dashboard/hallucination?tab=ground-truth(向後兼容,Ground Truth 編輯走獨立 RAG 知識庫 page /dashboard/rag)。

REST API 公開介面(對應 /v1/hallucination-repair/* routes)

完整 API 列表(對應 backend/src/routes/addons.routes.js 與 appendix-b-api.md):

GET    /v1/hallucination-repair/brands/:brandId/ground-truths       # 列 ground truth
POST   /v1/hallucination-repair/brands/:brandId/ground-truths       # 新增 ground truth
POST   /v1/hallucination-repair/brands/:brandId/ground-truths/import # 批次匯入
DELETE /v1/hallucination-repair/brands/:brandId/ground-truths/:id   # 刪除 ground truth

GET    /v1/hallucination-repair/brands/:brandId/detections          # 列偵測紀錄
GET    /v1/hallucination-repair/brands/:brandId/stats               # 統計總覽

PUT    /v1/hallucination-repair/detections/:id/false-positive       # 客戶標「這不是幻覺」
POST   /v1/hallucination-repair/detections/:id/repair               # 手動觸發 autoRepair
POST   /v1/hallucination-repair/detections/:id/reverify             # 手動觸發 reverify
POST   /v1/hallucination-repair/brands/:brandId/scan                # 手動觸發整批偵測掃描
PUT    /v1/hallucination-repair/detections/:id/user-action          # 通用 user action endpoint

所有 endpoints 都走 authenticate + brandScope + requireBrandTypeMatch 三層守(對齊 §2.5 多租戶隔離)。

本章要點

參考資料

導覽：← Ch 8: GBP API 整合 · 📖 目次 · Ch 10: Phase 基線測試 →

  1. Schema.org. ClaimReview. https://schema.org/ClaimReview ↩

This site is open source. Improve this page.