本地端流程筆記

本地端流程

整體流程

Ingestion pipeline

向量資料庫的比較

這幾個都是向量資料庫（Vector Databases），專門用來儲存和搜尋高維向量（embeddings）。以下是主要差異：

	Chroma	Pinecone	Weaviate	Qdrant
類型	嵌入式/本地優先	全託管雲端	混合搜尋導向	高效能向量搜尋
開源	✅	❌	✅	✅
部署方式	本地/Docker/雲端	僅雲端 SaaS	本地/雲端	本地/雲端
語言	Python 原生	多語言	Go	Rust

---

Chroma

• 最適合快速原型開發，幾行 Python 就能跑起來
• LangChain、LlamaIndex 的預設選項之一
• 輕量，適合個人專案或 POC

Pinecone

• 零維運負擔，完全託管，不用管基礎設施
• 企業級 SaaS，適合快速上線但需付費
• 無法自架，資料在第三方

Weaviate

• 強調混合搜尋（Hybrid Search），向量 + BM25 關鍵字一起用
• 內建 GraphQL API，schema 設計較完整
• 支援多模態（文字、圖片）

Qdrant

• 用 Rust 寫成，效能和記憶體效率最佳
• 支援豐富的**過濾（Filtering）**條件，適合複雜查詢
• Payload（metadata）處理能力強
• 近年在效能 benchmark 中表現突出

---

快速 POC / 學習用          → Chroma
不想管 infra，直接付費用    → Pinecone
需要混合搜尋 + GraphQL      → Weaviate
需要高效能 + 複雜過濾條件   → Qdrant

Retrieval策略

Retrieval = 從 RAG 撈出相關片段的方式

一般的常見流程會是：

1. 用戶輸入問題
2. 使用embedding模型將問題轉換為向量
3. 用向量數據庫進行相似度搜索，找出最相關的內容片段
4. 將這些片段和問題組合成一個prompt，交給LLM，讓他根據這些訊息生成答案。

最基本的是：把問題向量化 → 找最近的 Top-K 筆。但這不一定夠準。

1. Basic Vector Search

原理： 把問題轉成向量，找向量空間中距離最近的 K 筆。

問題「台積電上週外資買超多少？」
  → [0.12, -0.34, 0.87, ...] (384維)
  → Qdrant cosine similarity
  → Top-5 最相似的片段
問題 → embedding → Qdrant 找 Top-5 → 送給 LLM

Cosine similarity是衡量兩個向量之間方向相似程度的指標，Qdrant 用它來比較向量資料庫中的嵌入向量（embeddings）。

數學定義

$$\text{cosine\_similarity}(A, B) = \frac{A \cdot B}{|A| \cdot |B|}$$cosine_similarity(A,B)=∣A∣⋅∣B∣A⋅B​

也就是兩個向量的點積除以各自的模長之積。

值域與意義

值	意義
1.0	方向完全相同（最相似）
0.0	兩向量互相垂直（無關）
-1.0	方向完全相反（最不相似）

優點： 語意理解強，問「外資大買」和「法人積極買進」能找到同一筆。

缺點： 對精確數字、代碼、日期不敏感。「2330」和「2454」的向量可能很接近，因為上下文語境類似。

適合： 問題是概念性的，不依賴精確關鍵字。

2. Hybrid Search（向量 + 關鍵字）

原理： 同時跑兩個搜尋，再用 RRF（Reciprocal Rank Fusion）合併排名。

問題「2330 三大法人 2024-06-01」
  ├─ 向量搜尋  → [片段A:rank1, 片段C:rank2, 片段E:rank3]
  ├─ BM25關鍵字 → [片段B:rank1, 片段A:rank2, 片段D:rank3]
  └─ RRF合併   → 片段A綜合排名最高

RRF 公式： score = 1/(rank_vector + 60) + 1/(rank_keyword + 60)

優點： 兼顧語意和精確匹配，股票代碼、日期、公司名不會漏掉。

缺點： Qdrant 需要對文字欄位建 sparse vector 索引（需要額外設定）；實作複雜度較高。

適合： 財務資料查詢（有股票代碼、日期的情境）。

3. Re-ranking（重新排序）

原理： 兩階段。第一階段快速撈大量候選，第二階段用 Cross-Encoder 模型精準評分。

第一階段（召回）：向量搜尋 Top-50（快、粗）
                    ↓
第二階段（精排）：Cross-Encoder 模型對每個片段和問題做配對評分
                    ↓
              取 Top-5（慢、準）

Bi-Encoder vs Cross-Encoder 的差別：

	Bi-Encoder（向量搜尋用）	Cross-Encoder（re-rank用）
方式	問題和文件各自獨立編碼	問題＋文件一起輸入模型
速度	快（可預先計算）	慢（每對都要重新算）
精準度	中	高

優點： 精準度高，能處理向量搜尋撈到「語意相近但答案無關」的情況。

缺點： 需要額外跑一個 re-rank 模型（如 bge-reranker），增加延遲和資源消耗。

適合： 資料庫很大、Top-K 品質不穩定的情況。你有 388萬筆，值得考慮。

4. Multi-hop（多跳查詢）

原理： 把一個複雜問題拆成多個子查詢，每次查詢的結果作為下一次的輸入。

問題「台積電最近三個月外資買超趨勢如何，跟同期大盤比怎麼樣？」
第1跳：查「台積電外資買超」→ 得到台積電資料
第2跳：用台積電時間區間 → 查「大盤同期走勢」
第3跳：兩份資料一起送 LLM → 生成比較分析

也可以是 Query Decomposition：

問題拆解（由LLM執行）：
  子問題1：台積電 6-8月 外資買超總額？
  子問題2：大盤 6-8月 漲跌幅？
各自查詢 → 結果彙整 → LLM合成最終答案

優點： 能回答需要跨資料源、多步推理的複雜問題。

缺點： 延遲高（多次 LLM + 向量搜尋）；實作最複雜；中間任何一跳出錯就會影響最終答案。

適合： 問題本身需要「先找A再找B」的邏輯鏈，不適合簡單查詢。

四種策略比較表

	Basic Vector	Hybrid Search	Re-ranking	Multi-hop
實作難度	★☆☆☆	★★★☆	★★★☆	★★★★
回應速度	快	中	慢	最慢
精準度	中	高	很高	視問題而定
需要額外模型	否	否	是（re-ranker）	否（但耗LLM）

Agent模式