• Google Custom Search v.s. RAG 向量資料庫 + Gemini：新世代知識檢索架構比較
搜尋外部知識 or 只理解內部知識？
當我們想做問答知識庫時，應該會想
「要讓模型用 Google 搜尋外部資料？還是讓它只理解公司內部資料（不要亂回答）？」
兩種主流方案，我覺得各自有合適的情境：
- Google Custom Search (CSE)：以搜尋引擎為核心的外部資料檢索。
- 向量資料庫 + Gemini (RAG 架構)：以語意理解為核心的內部知識檢索。
後面附上兩種架構的 Python 基礎範例
一、Google Custom Search：外部資料檢索
1. 技術原理
Google Custom Search 是 Google 提供的 JSON API，讓開發者能在自己的應用中嵌入搜尋功能。它利用 Google 的索引系統，簡單理解就是建立自己的搜尋引擎，但允許「限制搜尋範圍」或「自訂搜尋結果呈現方式」
使用者查詢 → Google 索引引擎 → 自訂搜尋引擎 (CSE)
↓
依照開發者要求架構，回傳連結、摘要、圖片
↓
依照開發者要求架構，回傳連結、摘要、圖片
2. 實作範例（Python）
from googleapiclient.discovery import build
# 初始化
API_KEY = "你的Google API Key"
CSE_ID = "你的Custom Search Engine ID"
def google_search(query):
service = build("customsearch", "v1", developerKey=API_KEY)
res = service.cse().list(q=query, cx=CSE_ID, num=5).execute()
for item in res.get("items", []):
print(f"標題：{item['title']}")
print(f"連結：{item['link']}")
print(f"摘要：{item['snippet']}")
print("-" * 40)
google_search("AI market trends 2025")
適用場景
市場調查、產業趨勢分析、競爭對手研究、對外技術資料收集
限制
無法理解公司內部專有資料、僅回傳「現有網頁內容」，若是知識很新可能會沒資料，非語意生成、無法直接回答「組織內的知識問題」
二、向量資料庫 + Gemini（RAG 架構）：企業內部知識理解引擎
1. 技術原理
RAG（Retrieval-Augmented Generation）是一種結合「語意檢索 + 生成式模型」的架構。簡單理解就是，讓模型「先從內部資料找出最相關資料」，再根據上下文生成答案
公司文件/資料庫（Embedding 向量化）
↓
向量資料庫（語意索引 Similarity Search）
↓
LLM 模型（生成回答）
↓
向量資料庫（語意索引 Similarity Search）
↓
LLM 模型（生成回答）
2. 實作範例（Python）
from langchain.vectorstores import Chroma
from langchain.embeddings import OpenAIEmbeddings
from langchain.chat_models import ChatOpenAI
# 假設有一份公司內部資料
docs = [
"2024 年公司營收成長 15%，主要來自北區業務。",
"行銷部門增加了數位廣告投放預算。",
"競爭對手 X 公司市佔率下降 3%。"
]
# 向量化資料
embeddings = OpenAIEmbeddings()
vector_db = Chroma.from_texts(docs, embedding=embeddings)
# 使用者查詢
query = "去年營收為何成長？"
similar_docs = vector_db.similarity_search(query, k=2)
# 檢索結果交給生成式模型（例如 GPT）
context = "\n".join([doc.page_content for doc in similar_docs])
prompt = f"根據以下資料回答問題：\n{context}\n\n問題：{query}"
llm = ChatOpenAI(model="gpt-4o-mini")
response = llm.invoke(prompt)
print("AI 回答：", response.content)
優點
可直接回答企業內部知識問題、支援多種資料來源（文件、資料庫、報表）、地端可私有部署，確保資料安全、支援語意相似度查詢（非僅關鍵字）
限制
初期需建構向量資料庫與更新機制、成本與維運比 Google Search 高
差異比較
| Google Custom Search | 向量資料庫 + Gemini (RAG) | |
|---|---|---|
| 資料來源 | 公開網頁 | 公司內部知識庫 |
| 檢索方式 | 關鍵字比對 | 語意相似度 |
| 輸出結果 | 網頁連結、摘要 | 自然語言生成回答 |
| 知識更新 | 依賴 Google 索引 | 可自動或定期更新內部資料 |
| 隱私安全 | 公開搜尋結果 | 可全程私有部署 |
| 應用場景 | 外部市場研究 | 內部問答、知識助理、報告生成 |
| 優勢 | 最新資訊、覆蓋廣 | 深度理解企業語意關係 |
| 缺點 | 無法理解上下文 | 需建構向量庫與管理流程 |
在我轉職後進入顧問服務業的第一份工作裡，沒有遇過純外部資料庫搜尋，團隊實際使用過兩種知識檢索架構：
混合式（向量資料庫 + LLM）、純向量資料庫
客戶產業報告整理的資料預測
當我們進行「產業資料預測」或「客戶成長潛力分析」時，往往擁有多年累積的內部資料
這類任務重點在於「從大量歷史資料中找出相似樣本與潛在模式」，並給出最相似的資料
技術策略：
將結構化與非結構化資料整理成 json metadata 架構（欄位包含時間、地區、產品、價位、關鍵指標等）
PS metadata 架構設計本身是核心關鍵，之後可另開一篇深入介紹如何設計
用向量資料庫執行「語意相似度比對」，找出最相似的歷史樣本
再交由 LLM（如 Gemini 或 GPT）綜合分析上下文，生成預測資料
這樣的架構能結合：數據準確性（純相似度比對確保可重現性）、分析彈性（LLM 自然語言推理與文字生成能力）
當然，也有一些資料超級穩定、歷史趨勢明確的客戶，我會選擇直接使用純向量資料庫進行相似度判斷，跳過 LLM 推理步驟
整合應用：Hybrid Search 架構
外部層：Google Custom Search — 抓取公開資訊
內部層：向量資料庫 + Gemini — 理解公司知識
整合層：模型融合回答，附來源標註
範例：
[外部資料]：根據市場報告，產業平均成長 12%
[內部資料]：去年營收成長 15%，主要因北區銷售提升
LLM 判斷：本公司成長幅度高於產業平均
結語
想「找得到」外部資訊 → 用 Google Custom Search
想「看得懂」內部知識 → 用 向量資料庫 + Gemini (RAG)
兩者並非對立，而是互補，可以同時具備：外部即時資訊視野、內部知識深度理解
補充
