常見問答

兩者解決不同問題：

• Chroma（向量資料庫）：存的是文字的「語意座標」（bge-m3 編碼後的 1024 維向量），用來做模糊語意搜尋。問「住院賠不賠」可以找到「醫療給付條件」相關段落，即使字面不完全一樣。
• Neo4j（圖資料庫）：存的是「商品 → 保障項目 → 給付條件」這種結構化關係，用來做精確商品比對。可以查「市面上保失能等級 1-6 級的所有商品」這種精準條件。

前者找「相關內容」，後者找「結構化資訊」。同時用兩個才能兼顧召回率與精確率。

四大類：

• 新聞 RSS（14 個）：自由、中時、聯合、商周、工商、經濟日報等保險／金融板
• 保險社群討論區：MY83、保險法評論、PTT Insurance、Mobile01 保險板
• 金融評議中心：每月公布的理賠裁決書 RSS（114 年評字第 XXXX 號）
• 保險公司商品 DM：27 家保險公司官網商品介紹頁 PDF（含費率表、條款）

靜態 HTML 用 httpx + BeautifulSoup（輕量、快、不耗資源）。

動態渲染頁面（如保險公司商品頁靠 JS 載入條款）用 Playwright（真實啟動 Chromium，等 JS 跑完再抓 DOM）。

每篇訊號交給 Gemini Flash 評 0~1 分（temperature=0.2 確保穩定），prompt 明確列出三類高分情境：

• 真實財務缺口（理賠遭拒、保費爆漲、自費超支）→ 0.8+
• 理賠爭議裁決書（評議中心、訴訟判決）→ 0.7+
• 法規衝擊（金管會公告、衛福部新規）→ 0.6+
• 保險公司新聞稿、業配文 → 0.2 以下

分數 ≥ 0.8 列為「高痛點訊號」，會優先進入後續缺口分析。

7 類：①痛點/抱怨、②理賠爭議、③法規動態、④商品上市、⑤國際趨勢、⑥業界動態、⑦中性新聞。分類由 Gemini Flash 做，每篇可帶多標籤。後續觸發機制只看「痛點 + 爭議 + 法規」這三類的累積。

每篇訊號被 AI 分類後會落到一個主題（如「失能扶助險理賠」「實支實付副本爭議」）。系統用 14 天滑動窗口統計：

• 跨類別 ≥ 3 次：例「實支實付」在痛點、爭議、法規三類都出現各一次 → 觸發
• 同類別 ≥ 2 次：例同樣是理賠爭議類別出現 2 篇「失能等級認定」 → 觸發

達標即視為「成熟」，自動啟動缺口分析 pipeline。

自動跑完整缺口分析 pipeline，無需人工介入：

1. Chroma 撈該主題所有相關訊號
2. Neo4j 找市面相似商品（覆蓋分析）
3. Gemini 合成缺口 + 商機評分
4. TAM/SAM/SOM 市場規模試算
5. Gemini 寫 12 章保單草稿
6. 圓桌辯論修訂
7. 生成行銷材料（Slogan/亮點/FAQ）+ DM 圖

整流程約 5-10 分鐘，產出存到 data/reports/。

特定關鍵詞會直接觸發既定商品方向，不用等 14 天累積：

• 「金管會 + 實支實付」→ 實支實付革新版
• 「衛福部 + 長照給付」→ 在宅醫療險
• 「立法院 + 寵物福利」→ 寵物醫療險

這份 mapping 表是事先設定的「快速通道」，讓法規衝擊類訊號能立刻反應。

1. 語意檢索：bge-m3 從 2,841 篇訊號撈相關段落
2. 商品比對：Neo4j Cypher 找市面類似商品
3. 缺口合成 + 商機評分：Gemini 找出未被滿足的需求並打 1-5 分
4. 市場規模試算 + 建議書生成：TAM/SAM/SOM + 12 章草稿
5. 圓桌辯論：Gemini Pro 三方 + AI 總監修訂

由 Gemini 綜合三維度判斷：

• ① 真實需求強度：高痛點訊號數量、評議中心案件數
• ② 市場缺口大小：Neo4j 沒匹配商品的覆蓋率
• ③ 法規可行性：無強制理由禁止

分數 ≥ 4 才會繼續往下生成保單草稿（節省 Gemini token，避免低價值方向浪費資源）。

三層皆以「年保費營收（元）」為單位，商業決策最終看的是產值而非單純人口數。

層次	定義	算法
TAM 總可服務市場	目標客群 100% 購買後的年產值上限	目標年齡層人口 × 客單價（年繳保費） 例：高齡駕駛 233 萬人 × NT$3,000 ≈ 69.9 億元
SAM 可服務市場	扣除無法觸及、不符投保資格、通路限制後的年產值	TAM × 觸及可能性 × 資格符合率 注意：不是「乘 86% 滲透率」——壽險滲透率（保費/GDP）跟個人購買率是不同概念，混用會誤導
SOM 實際可獲市場	第一年真正能做到的業績（Bottom-Up）	行銷預算可觸及人數 × 轉化率 × 客單價 例：觸及 20 萬人 × 10% 轉化 = 2 萬人投保 → 2 萬 × NT$3,000 = 6,000 萬元

這樣的好處：估算數字可以直接交給公司「年度業績目標」與「預算規劃」討論，不會出現「總共 280 萬人」這種無營收意涵的數字。

三個角色各自由 Gemini Pro 用獨立 system prompt 扮演，對同一份建議書互相質疑：

• 精算師：質疑費率合理性、損率假設、責任準備金估算。常問「這個費率有沒有低估死差／病差／賠率？理賠資料夠不夠支撐這個計算？」
• 業務員：質疑保戶溝通難度、保單可讀性、銷售話術可行性。常問「保戶懂這個給付條件嗎？除外責任會不會被罵不誠實？如何 1 分鐘講完賣點？」
• 消費者代表：質疑費用合理性、理賠便利性、條款公平性。常問「真的會理賠嗎？保費 vs 給付划算嗎？申請流程要跑幾次？」

三方各寫 1-2 頁意見書，存到 {theme}-roundtable-opinions.md。

第四個 Gemini Pro 扮演「AI 總監」，讀完三方意見後綜合：

• 三方都認同的強項 → 保留並強化
• 有爭議的設計 → 讓步或補充說明
• 模糊條款 → 補強具體定義

輸出 {theme}-revised.md，這才是「提交給商品開發部」的最終版。

分量化與質化兩層：

• 量化：TAM/SAM/SOM 三層金額導向市場規模估算。TAM 抓潛在年產值上限、SAM 扣掉觸及／資格／通路限制後的可服務產值、SOM 用「行銷預算 × 轉化率 × 客單價」推第一年實際業績。
• 質化：圓桌辯論模擬。精算師問「賠率假設合理嗎」、業務員問「保戶會不會買」、消費者代表問「會不會抱怨理賠難」。三方對「商品落地後的市場反應」做對抗式模擬。

最終建議書同時呈現量化金額（例 SOM = 6,000 萬／年）+ 質化爭點（例業務員擔心話術太複雜）。

直接從 MY83 保險網（https://my83.com.tw/）抓取，涵蓋六大商品類別：

• 壽險
• 長照／失能險
• 意外險
• 醫療險
• 重大傷病險
• 癌症險

每個商品建模成 Neo4j 圖譜節點，含 9 個戰略欄位（保障項目、給付條件、除外責任、費率方向、目標客群、銷售管道、商品代號、生效日、保險公司）。MY83 是台灣最大的保險商品比較平台，把多家公司的條款結構化整理在同一介面，相對於跑 27 家公司官網省力很多。

每張保險商品的條款 PDF 用「語意切割」拆成 200-500 字片段：

• ① 以段落為基本單位
• ② 遇到「除外責任」「給付條件」「保費計算」等獨立小標題就強制斷開
• ③ 連續編號條款（例 1.1、1.2、1.3）合併保留上下文

切完後每片段加上 metadata（商品代號、章節編號、頁碼），存進 Chroma 向量資料庫。