今天進入生成式 AI 職缺中出現頻率最高的主題：RAG（48.1%）。

因為它太重要，我用三天處理：今天講索引端（文件怎麼進去）、明天講檢索端（怎麼找出來）、後天講生成與評測（怎麼用、怎麼知道好不好）。

如果你只能讀一天，讀今天——因為多數 RAG 系統的品質上限，在文件進資料庫的那一刻就決定了。

今天要解決的問題

一個真實的抱怨：

「我們把公司 3,000 份文件都放進去了，但它還是常常答不出來。是不是要換更強的模型？」

換模型幾乎不會解決這個問題。因為問題通常出在：使用者問「請假規定是什麼」，而檢索取回的是三段被攔腰切斷的段落——第一段結尾寫「請假規定如下：」，第二段是表格的中間三列，第三段從「……但主管得視情況調整」開始。

模型拿到這種脈絡，只能靠猜。這不是模型的問題，是索引的問題。

📊 職缺訊號

「RAG 與企業知識庫」出現在 48.1% 的生成式 AI 職缺中，是最高的任務訊號。值得注意的是 JD 的用詞已經從早期的「熟悉 RAG」進化為「優化檢索品質」「處理企業文件的權限與更新」——市場已經過了「會做 RAG」的階段，進入「會把 RAG 做好」的階段。

一、現象：RAG 的兩條管線

先建立全局：

圖 18-1：RAG 的兩條管線（示意架構）。兩者共用同一個嵌入模型是硬性要求——換模型就必須重建索引。

今天處理上半部。 這半部的特性是：做錯了，下半部再怎麼優化都補不回來。

二、原理：切塊策略決定品質上限

切塊（chunking）看起來很無聊，卻是 RAG 品質最大的單一變因。

圖 18-2：四種切塊策略對同一份文件的切法比較（示意對照）。固定大小會攔腰切斷語意；遞迴切分尊重段落句讀；結構感知沿標題切；父子塊以小塊檢索、大塊生成。

父子塊為什麼是最佳解？ 因為它同時解決兩個矛盾的需求：

• 檢索需要小塊——語意集中、向量才精準。
• 生成需要大塊——脈絡完整、模型才答得好。

用小塊命中、回傳大塊，兩者兼得。

三、動手：建一個能用的索引

3.1 切塊：結構感知 ＋ 重疊

"""chunk.py —— 結構感知切塊，保留標題階層作為 metadata。"""
import re
from langchain_text_splitters import RecursiveCharacterTextSplitter

def split_markdown(text: str, source: str):
    """依標題切段，並把標題路徑寫進 metadata（明天檢索時會用到）。"""
    chunks, heading_stack, buf = [], [], []

    def flush():
        if buf:
            body = "\n".join(buf).strip()
            if body:
                chunks.append({
                    "text": " > ".join(heading_stack) + "\n" + body,   # ← 標題放進內文
                    "metadata": {
                        "source": source,
                        "heading_path": " > ".join(heading_stack),
                        "level": len(heading_stack),
                    },
                })
            buf.clear()

    for line in text.split("\n"):
        m = re.match(r"^(#{1,4})\s+(.*)", line)
        if m:
            flush()
            level = len(m.group(1))
            heading_stack[:] = heading_stack[:level - 1] + [m.group(2).strip()]
        else:
            buf.append(line)
    flush()

    # 過長的段落再用遞迴切分，並保留重疊避免切斷語意
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=800, chunk_overlap=120,
        separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""],
    )
    out = []
    for c in chunks:
        for piece in splitter.split_text(c["text"]):
            out.append({"text": piece, "metadata": c["metadata"]})
    return out

兩個關鍵設計：

1. 把標題路徑寫進切塊內文（人事規章 > 請假規定 > 特休）。這讓一個孤立的段落也帶著它的上下文，對嵌入品質的提升非常明顯。
2. separators 要含中文標點。預設的分隔符是為英文設計的，中文文件用預設值會切得很難看。

3.2 嵌入：選型與那條硬性規則

"""embed.py —— 嵌入模型的選擇與使用。"""
from sentence_transformers import SentenceTransformer

# 中文場景的選型考量：多語支援、序列長度上限、維度（影響儲存與速度）
MODEL_NAME = "BAAI/bge-m3"        # 多語、支援長序列，中文表現穩定
model = SentenceTransformer(MODEL_NAME)

def embed(texts: list[str], is_query: bool = False):
    """注意：部分模型對「查詢」與「文件」需要不同的前綴，用錯會顯著掉分。"""
    if is_query and "bge" in MODEL_NAME:
        texts = [f"為這個句子生成表示以用於檢索相關文章：{t}" for t in texts]
    return model.encode(texts, normalize_embeddings=True)

⚠️ RAG 的第一條硬性規則

建立索引與查詢時，必須使用同一個模型的同一個版本。 換了模型（甚至只是升版）就必須重建整個索引，因為新舊向量不在同一個空間裡，相似度計算完全沒有意義。

實務做法：把嵌入模型名稱與版本寫進索引的 metadata，服務啟動時比對，不一致就拒絕啟動——寧可起不來，也不要靜默地給出爛結果。

3.3 向量庫：選型與索引原理

圖 18-3：HNSW 索引的運作直觀（示意架構）。上層稀疏圖快速逼近目標區域，逐層下降後在底層稠密圖精細搜尋——以可調的精度損失換取數量級的速度提升。

要理解的核心概念是「近似」：HNSW 是近似最近鄰演算法，它不保證找到真正最相似的前 k 筆。這個取捨由參數控制（ef_search 越大越準也越慢），而多數人不知道自己在做這個取捨。

"""index.py —— 用 Chroma 建立索引（本機可跑，適合起步）。"""
import chromadb

client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection(
    name="company_docs",
    metadata={"hnsw:space": "cosine", "embedding_model": MODEL_NAME},   # 記下模型
)

def index_documents(chunks):
    collection.add(
        ids=[f"{c['metadata']['source']}#{i}" for i, c in enumerate(chunks)],
        embeddings=embed([c["text"] for c in chunks]).tolist(),
        documents=[c["text"] for c in chunks],
        metadatas=[{
            **c["metadata"],
            "dept": c["metadata"].get("dept", "all"),      # ← 權限過濾用（Day 27）
            "updated_at": "2026-07-25",                     # ← 增量更新用
        } for c in chunks],
    )

四、取捨：企業文件的三個真實難題

教學範例都用乾淨的 Markdown，真實企業文件不是這樣。三個必然遇到的問題：

💡 給起步者的最小可行索引

別一開始就追求完美。第一版這樣做就好：

1. 只放一個部門、格式最乾淨的 50 份文件（不要一次 3,000 份）。
2. 用結構感知切塊，chunk_size=800、overlap=120。
3. metadata 至少放：source（來源檔名與頁碼）、dept（權限）、updated_at（更新）。
4. 先驗證這 50 份的檢索品質（明天講怎麼量），再擴大。

範圍小而品質好的 RAG，遠比範圍大而品質差的有用。 後者會讓使用者第三次答錯後就再也不用了——而使用者的信任一旦失去，比技術問題難修得多。

今日小結

• RAG 有兩條管線：離線索引與線上查詢。索引做錯了，查詢端再怎麼優化都補不回來。
• 切塊策略是最大的單一變因。父子塊（小塊檢索、大塊生成）是企業文件的最佳解，因為它同時滿足「檢索要小、生成要大」的矛盾需求。
• 中文切塊的兩個實務要點：把標題路徑寫進切塊內文、分隔符要含中文標點。
• 硬性規則：索引與查詢必須用同一個嵌入模型版本，換模型就要重建索引；把模型版本寫進 metadata 並在啟動時比對。
• HNSW 是近似演算法，精度與速度是可調的取捨——要知道自己在調什麼。
• 企業文件的三個真實難題：PDF 解析、權限過濾、刪除連動（最常被漏）。
• 起步策略：先做 50 份文件並驗證品質，再擴大。

明天預告

索引建好了，明天處理檢索端：為什麼純向量檢索會漏掉「型號 A-2350」這種精確關鍵字、混合檢索與重排序各能提升多少、以及那個所有 RAG 系統都會遇到的問題——使用者問「那它的保固呢」，系統完全不知道「它」是什麼。

我也會給一張「每加一層優化，品質上升多少、延遲增加多少」的取捨圖。

延伸閱讀

• 📄 Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020)——RAG 一詞的出處
• 📄 Malkov & Yashunin, *Efficient and robust approximate nearest neighbor search using HNSW* (2016)——圖 18-3 那個分層圖的原始論文