RAG 檢索升級：從 Anthropic Contextual Retrieval 到 ctxfst 的 Embedding 最佳實踐
RAG 檢索升級：從 Anthropic Contextual Retrieval 到 ctxfst 的 Embedding 最佳實踐
在建構 RAG（Retrieval-Augmented Generation）系統或知識圖譜時，我們常遇到一個核心痛點：把文件切成 Chunk 後，這段文字就失去了原本的上下文（Context）。
當使用者搜尋時，可能因為 Chunk 裡的關鍵字太少或太發散，導致雖然語意相似，卻找錯了段落（例如找「部署」卻搜到了完全不相干領域的「部署」）。為了解決這個問題，業界發展出了不同的 Embedding 策略，其中最具代表性的就是 Anthropic 提出的 Contextual Retrieval。
本文將帶你盤點 Vector Database 的三種 Embedding 做法，解析 Anthropic 的解法，然後告訴你：為什麼在這套框架下，ctxfst 獨立保留 context 欄位的設計，反而是更適合技能圖譜的「升級版」！
一、Vector DB 自動把文字變向量的 3 種做法
很多人以為用 Vector DB 就一定要自己在外面算好 Embedding，其實現代的 Vector DB（像 LanceDB 或 HelixDB）早就把這件事封裝得很漂亮了。主流做法有這三種：
| 方法 | 原理 | 說明與範例（以 LanceDB / HelixDB 為例） |
|---|---|---|
| 1. 外部預計算 | 你自己在外面用模型生成向量，再手動存入 DB。 | 適合自訂流程：model.encode(texts) → table.add({"text": texts, "vector": embeddings}) |
| 2. 內建 Registry | DB 內建模型清單，定義 Schema 時宣告即可自動 embed。 | **（推薦）**支援 OpenAI/HuggingFace，零程式碼注入：name: str = func.SourceField() |
| 3. 自訂函數 | 寫一段自訂的 embedding function，註冊到 DB 中。 | 透過 @register("my-model")，或是 HelixDB 原生的 Embed('...') 直接在語法中呼叫。 |
如果在建構 200 個節點左右的「中小技能圖譜」，非常推薦使用 Registry 的方法。例如在 LanceDB 中直接調用 sentence-transformers 的 bge-large-zh 中文模型，原本繁瑣的流程就會簡化成：
skills.yaml → LanceDB Registry 自動 Embedding → 存入 Similarity Graph。
二、RAG 的 4 種 Embedding 策略
有了自動 Embedding 的工具，下一個問題是：「我要拿什麼內容去算 Embedding？」
一般來說，我們有這四種策略：
| 策略 | 輸入給 Embedding 的內容 | 適用場景 | 在 ctxfst 中的對應欄位 |
|---|---|---|---|
| 1. 純 Chunk Content | 文章/段落正文 | 傳統 RAG 的做法，語意最豐富但也最高雜訊。 | chunks[].content |
| 2. Context Only | 高濃縮的語意摘要 | ctxfst 核心，精準導航，雜訊極少。 | chunks[].context |
| 3. Context + Content | 摘要與正文合併 | Anthropic 的做法，平衡精準與細節豐富度。 | context + content |
| 4. Tags Only | 關鍵字列表 | 快速過濾使用，通常不拿來算向量。 | chunks[].tags |
這裡就要提一下近期的 RAG 革命：Anthropic 提出的 Contextual Retrieval。
三、什麼是 Anthropic 的 Contextual Retrieval？
2024 年 9 月，Anthropic 發表了 Contextual Retrieval 技術，核心觀念就是 策略 3（Context + Content）。
他們發現，如果為每個 Chunk 先生成一段「50 到 100 token 的專屬脈絡描述（Context）」，然後把它硬生生接在原來的 Chunk 前面一起做 Embedding，檢索效果會奇蹟般地變好。
操作流程：
- 生成 Context：透過小模型（如 Claude Haiku 或 GPT-4o-mini）看過全篇文件，幫特定 Chunk 寫摘要。例如：「This section discusses Kubernetes Pod scheduling in the context of backend deployments.」
- 合併字串：
contextual_chunk = context + "\n" + original_chunk - 建立雙重索引：將合併後的字串丟去做 Vector Embedding，同時也做 BM25 文字索引。
- Hybrid 檢索與 Rerank：查詢時用向量 + BM25 的結果做 Rank Fusion（RRF），取前 20 名再過一次 Reranker。
效果驚人：根據 Anthropic 測試，加上 Contextual Embedding 加上 BM25 和 Reranker，Top-20 的檢索失敗率降低了 67%！
四、為什麼 ctxfst 的獨立 Context 是「升級版」？
既然 Anthropic 的合併法（Context + Content）這麼強大，為什麼我們在設計 Skill Graph 或是處理教學內容時，依然推薦 ctxfst 中的 策略 2（Context Only） 或保持欄位分離呢？
因為 Anthropic 這種「將 Context 和 Content 物理性合併成一個字串」的做法有兩個致命傷：
- 更新代價高：如果你只改了一個錯字，或是想微調 Context 讓向量更準，你必須重新生成合併字串，並且重新計算整個龐大 Chunk 的 Embedding。
- 對 Graph 不友善：知識圖譜需要乾淨的節點結構，摻雜了長篇大論的 Content 會讓實體關係變得模糊。
ctxfst 的設計哲學是分離（Separation of Concerns）：
我們把 context 獨立成一個專門為 Embedding 與 Graph 設計的精粹欄位，而把大篇幅的 content 留給 LLM 閱讀。
ctxfst vs Anthropic 合併法的 5 大優勢對比
| 優點 | Anthropic (Merge) | ctxfst（欄位分離） | 這對你來說代表什麼好處？ |
|---|---|---|---|
| 更新彈性 | 改一段需重算全重組 | 修改 context 欄獨立算，免動本文 |
微調技能的 Context 不會連累原文，省時省錢。 |
| Hybrid 支援 | 向量與 BM25 混雜在同一堆字 | Context 用於向量，Tags/Entities 用於精確篩選 | tags='Python' 先 Filter，再從 context 算 Cosine 最準。 |
| 圖譜友好度 (Graph) | 無結構化的長文本 | entities[] 或 tags 直轉 Nodes 與 Edges |
HelixDB 可以輕鬆將 entities[] 丟給 Graph 跑 SIMILAR。 |
| 診斷與迭代 | 塞在系統裡的黑盒 | YAML 格式全透明、可讀、可編輯 | 在教學 Demo 裡，學生改個 MD 檔馬上就能看到 Graph 變化。 |
| 多模態潛力 | 僅限文字 | YAML 可直接帶入 type: image 等結構 |
未來的技能圖可以輕鬆加上教學架構圖（Diagram）。 |
最佳實踐：在技能圖譜中該怎麼做？
在我們大概 200 個技能節點的規模中，最銳利的一把刀就是 用 chunks[].context 這個 50-token 的精華來做 Embedding。
# LanceDB 中 Schema 的設計範例
from lancedb.embeddings import get_registry
func = get_registry().get("sentence-transformers").create("bge-large-zh")
class CtxFstSchema(LanceModel):
# 用 context 來自動產生 vector（策略 2）
context: str = func.SourceField()
# content 照存，但不拿來算 vector
content: str
# 也可以透過 tags 拿來做前置過濾
tags: list[str]
vector: Vector(func.ndims()) = func.VectorField()為什麼這樣做最好？
- 極致精準：拿掉了不必要的贅字。如果你搜尋「Python 的 API 框架」，這 50 個 token 濃縮的
context會讓FastAPI直接貼到尋找空間的正中央，而不會因為原文剛好扯到了「電腦硬體」而被拉扯過去。 - 穩定：不論你教學文章（
content）怎麼改修辭，只要技術重點（context）沒變，Embedding 向量就不會震盪。 - 完美適配演算法：簡短的
context做 Entity Extraction 最準確。
結語
Anthropic 的 Contextual Retrieval 向整個業界證明了「前置 Context」對於檢索準確率的巨大價值。但也正因為這份研究，更加印證了 ctxfst 這種將 Metadata、Context、Content、Entities 分離的資料結構，才是 2026 年應對 Hybrid RAG 與 GraphRAG 整合的最佳解法。
它不僅吸收了 Anthropic 補充脈絡的優點，還保持了資料庫操作的優雅與圖譜構建的結構化。善用 ctxfst 的 context 欄位，你就能輕鬆搭建出高精準度、低維護成本的知識導航系統！