Day 25 已經詳細學過LLM、Token、Context Window、Embedding、Vector Database、Retriever、Top-K、Hallucination、Grounding
與 RAG，所以今天不重複基本定義，而是把它們組成完整的 Production RAG
System。
RAG：
Retrieval-Augmented Generation
= 檢索增強生成
先找相關資料
↓
把資料提供給 LLM
↓
再產生 Answer
今天所有第一次出現的新名詞，都會先解釋英文、中文、用途與簡單例子；縮寫也會逐字拆解。
假設公司有：
Employee Handbook
Internal Wiki
Product Documentation
Customer Contracts
Engineering Documents
User 問：
公司的 PTO policy 是什麼？
只靠 LLM 可能有問題：
Model 沒看過 Private Documents
文件可能剛更新
文件不能公開
Context Window 不適合塞全部文件
Model 可能 Hallucinate
所以：
User Question
↓
Find relevant internal information
↓
Give evidence to LLM
↓
Generate grounded answer
Knowledge Base
Knowledge → 知識
Base → 基礎 / 集合
中文：知識庫
集中保存某個 Organization、Product 或 Domain 相關知識的 Data Source。
例如：
Company Policies
Technical Documentation
FAQ
Product Manuals
Support Articles
Domain（領域）
某一類專業知識、問題或 Business 範圍。
例如：
Healthcare
Finance
Semiconductor
E-commerce
Human Resources
Private Data（私人 / 非公開資料）
不應公開給所有人的 Data。
例如：
Internal Documents
Customer Contracts
Employee Records
Private Source Code
RAG 的重要用途之一，就是在 Inference 時使用這些 Private Knowledge。
Pipeline（處理流程 / 流水線）
Data 依序經過多個 Processing Steps。
例如：
Raw Document
↓
Parse
↓
Chunk
↓
Embed
↓
Store
RAG 主要可拆成：
1. Ingestion Pipeline
2. Query Pipeline
Ingestion（資料匯入 / 資料攝取）
把外部 Data 收進 System，準備後續處理。
例如：
PDF
Word
Web Page
Database Record
↓
RAG System
Ingestion Pipeline（資料匯入處理流程）：
Documents
↓
Load
↓
Parse
↓
Clean
↓
Chunk
↓
Add Metadata
↓
Create Embeddings
↓
Index
↓
Store
Raw Document
Raw → 原始、尚未處理
Document → 文件
例如剛上傳的：
employee_handbook.pdf
還沒有經過 RAG Processing，就是 Raw Document。
Document Loader
Document → 文件
Loader → 載入器
中文：文件載入器
從某個 Source 取得 Document 的 Component。
例如：
PDF Loader
Web Loader
Database Loader
Cloud Storage Loader
Parser（解析器）
把原始格式轉換成 System 比較容易處理的 Structure。
PDF
↓
Parser
↓
Text + Structure
Parsing（解析）：
Parser 執行上述工作的 Process。
OCR = Optical Character Recognition
逐字：
O = Optical = 光學的
C = Character = 字元 / 文字
R = Recognition = 辨識
中文：光學字元辨識
如果 PDF 是掃描圖片：
Scanned Page
↓
OCR
↓
Text
OCR 如果辨識錯誤，後面的 Retrieval Quality 也可能變差。
Extraction（擷取 / 提取）
從原始 Data 中取出需要的資訊。
例如：
PDF → Text Extraction
PDF → Table Extraction
Cleaning（資料清理）
移除或修正對後續處理沒有幫助的 Content。
例如每頁都重複：
CONFIDENTIAL
Page 1 of 100
Company Name
可以視需求清理，但不能誤刪真正重要的內容。
Chunk / Chunking Day 25 已詳細解釋。
Chunk Size（分塊大小）
每個 Chunk 包含多少 Content。
可以用：
Characters
Tokens
Sentences
Paragraphs
衡量。
Chunk 太大：
More Noise
More Tokens
Higher Cost
Chunk 太小：
Context may become incomplete
Boundary（邊界）
Chunk 在哪裡開始、在哪裡結束。
不好的切法：
Employees are entitled to
--- CUT ---
20 paid vacation days.
因此 Chunking 不只是決定 Size，也要考慮 Boundary。
Strategy（策略）
為達成目標而選擇的方法。
Chunking Strategy（分塊策略）：
Fixed-Size Chunking
Paragraph-Based Chunking
Section-Based Chunking
Semantic Chunking
Fixed → 固定
Size → 大小
例如每 500 Tokens 切一次。
優點：簡單、可預測。
缺點：可能切在不自然的位置。
依自然 Paragraph Boundary 分塊。
依 Heading / Section：
Vacation Policy
Insurance
Security
切分。
Semantic → 語意
根據 Content 意思的變化決定 Boundary。
可能更有語意連貫性，但 Complexity / Cost 也較高。
Coherence（連貫性）
一段 Content 內的資訊是否彼此有語意和邏輯上的連續關係。
好的 Chunk 希望：
Related content stays together
Overlap（重疊）
相鄰 Chunks 保留一部分相同 Content。
例如：
Chunk 1: Token 1–500
Chunk 2: Token 451–950
451--500 就是 Overlap。
用途：
避免重要資訊剛好在 Boundary 被切斷。
但 Overlap 太大會：
Increase Embedding Cost
Increase Storage
Create Duplicate Results
Waste Tokens
Metadata
Meta → 描述其他資料的
Data → 資料
中文：中繼資料 / 描述資料的資料
Chunk：
Employees receive 20 PTO days.
Metadata：
{
"document_id": "handbook_2026",
"title": "Employee Handbook",
"section": "Vacation Policy",
"page": 18,
"department": "HR",
"version": "2026",
"access_level": "employee"
}
用途：
Filtering
Authorization
Citation
Freshness
Debugging
Filter（篩選）
根據條件排除不符合的 Data。
例如：
tenant_id = company_A
version = 2026
department = HR
ID = Identifier = 識別碼
Document ID（文件識別碼）
穩定識別某份 Document 的 Value。
例如：
doc_12345
Version（版本）
同一份 Document 在不同時間的版本。
Versioning（版本管理）
追蹤 Data 不同 Versions 的機制。
例如：
Employee Handbook 2025
Employee Handbook 2026
RAG 必須避免把舊 Policy 和新 Policy 同時當成正確答案。
Embedding Day 25 已解釋。
Embedding Pipeline
把 Chunks 批次轉成 Embedding Vectors 的流程。
Chunks
↓
Embedding Model
↓
Vectors
↓
Vector Store
Vector Store（向量儲存系統）
保存 Vectors，並通常支援 Similarity Search 的 Storage Layer。
日常討論常和 Vector Database 混用，但概念上：
Vector Store → 強調 Vector 儲存 / 搜尋
Vector Database → 通常指更完整的 Database System
實際功能依產品而異。
Indexing（建立索引）
把 Data 組織成適合快速 Search 的結構。
Vectors
↓
Build Index
↓
Faster Search
如果每次 Query 都和所有 Vectors 比較，大 Dataset 會很昂貴。
Exact Search（精確搜尋）
完整比較所有可能 Candidates，尋找真正最近的結果。
如果有：
100M vectors
每次掃 100M Vectors 可能很慢。
所以大型 Vector Search 常使用 ANN。
ANN = Approximate Nearest Neighbor
逐字：
A = Approximate = 近似的
N = Nearest = 最近的
N = Neighbor = 鄰居
中文：近似最近鄰搜尋
不保證每次都做完整 Exhaustive Comparison，而是快速找出非常可能接近
Query Vector 的 Candidates。
核心 Trade-off：
Exactness
vs
Speed
Nearest Neighbor（最近鄰）
Vector Space 中距離 Query Vector 最近或最相似的 Data Point。
ANN 的目標就是高效率找到這些附近 Candidates。
Recall（召回率）
所有真正 Relevant Results 中，System 成功找回多少。
公式：
Recall
=
Retrieved Relevant Results
/
All Relevant Results
例如真正 Relevant 有 10 個，找到 8 個：
Recall = 8 / 10 = 80%
最簡單記：
該找的，有沒有漏？
這裡是 Information Retrieval 的 Precision，不是 Geohash Precision。
Precision（精確率）
Retrieved Results 中，有多少真的 Relevant。
公式：
Precision
=
Retrieved Relevant Results
/
All Retrieved Results
例如找回 20 個，其中 8 個 Relevant：
Precision = 8 / 20 = 40%
最簡單記：
找回來的，有多少是真的有用？
Recall
→ 該找的，有沒有漏？
Precision
→ 找回來的，有多少是真的對？
如果：
All Relevant = 10
Retrieved = 20
Retrieved Relevant = 8
則：
Recall = 80%
Precision = 40%
Retrieval Quality（檢索品質）
Retriever 找到的 Content 是否真的能幫助回答 User Question。
受很多因素影響：
Parsing
Chunking
Embedding Model
Metadata
Search Algorithm
Top-K
Query
Filters
Index
Reranking
因此：
RAG Answer 不好，不一定是 LLM 不夠強，也可能是 Retrieval 找錯資料。
Query Pipeline（查詢處理流程）
User 提問後，從 Question 到 Retrieval 再到 LLM Answer 的完整流程。
User Question
↓
Process Query
↓
Retrieve
↓
Rerank
↓
Build Context
↓
LLM
↓
Answer
Query Embedding（查詢向量）
把 User Query 透過 Embedding Model 轉成 Vector。
Question
↓
Embedding Model
↓
Query Vector
再進行 Similarity Search。
Candidate Retrieval（候選資料檢索）
第一階段先快速找一批可能 Relevant 的 Candidates。
例如：
10M chunks
↓
ANN
↓
Top 50 candidates
這 50 個不一定全部送給 LLM。
Reranking
Re → 再一次
Ranking → 排名
中文：重新排序
對第一階段 Candidates 再做更精細的 Relevant Ranking。
Reranker（重新排序模型 / 元件）
執行 Reranking 的 Component。
Fast Retrieval
↓
Top 50
↓
Reranker
↓
Top 5
↓
LLM
Two-Stage Retrieval（兩階段檢索）
Stage 1
ANN → Top 50
Stage 2
Reranker → Top 5
目標：
Speed
+
Quality
Semantic Search Day 25 已有基礎。
Keyword Search（關鍵字搜尋）
根據 Query 與 Documents 中的 Words / Terms 搜尋。
它特別適合：
Error Code
Product Name
Function Name
Part Number
Exact Technical Term
例如：
ORA-00942
Lexical Search
Lexical → 詞彙 / 字詞層面的
Search → 搜尋
中文：詞彙搜尋
主要利用 Words / Terms 的 Matching，而不是主要依賴 Embedding Meaning。
BM25 = Best Matching 25
BM = Best Matching = 最佳匹配
25 = 方法發展過程中的版本名稱
BM25 是經典的 Lexical Search Ranking Algorithm。
它會考慮：
Term 出現頻率
Term 在整個 Corpus 是否罕見
Document 長度
25 不是「25 個條件」。
Corpus（語料庫 / 文件集合）
Search / NLP System 正在處理的一整組 Documents。
例如：
10,000 company documents
可以視為一個 Corpus。
Term（詞 / 搜尋詞）
Search System 用來比對的 Word / Unit。
TF = Term Frequency
T = Term = 詞
F = Frequency = 頻率
中文：詞頻
某個 Term 在一份 Document 中出現多少次。
IDF = Inverse Document Frequency
I = Inverse = 反向 / 反比概念
D = Document = 文件
F = Frequency = 頻率
中文：逆文件頻率
核心直覺：
在所有 Documents 都很常見的字，區分能力通常較低；較罕見的 Term
可能更有辨識力。
例如：
"the"
vs
"ORA-00942"
TF-IDF = Term Frequency-Inverse Document Frequency
TF = Term Frequency = 詞頻
IDF = Inverse Document Frequency = 逆文件頻率
中文：詞頻－逆文件頻率
衡量某個 Term 對某份 Document 的重要程度的一種經典方法。
BM25 與 TF-IDF 有概念關聯，但不是完全相同的 Algorithm。
Hybrid Search
Hybrid → 混合
Search → 搜尋
中文：混合搜尋
RAG 常見：
Semantic Search
+
Keyword / BM25 Search
為什麼？
Semantic Search
→ Meaning 很強
Keyword Search
→ Exact Terms 很強
例如：
"How do I solve ORA-00942?"
兩者結合可能比單獨使用其中一種更穩定。
Fusion（融合）
把多個來源組合。
Score Fusion（分數融合）
把 Semantic Search 與 Keyword Search 的 Results / Scores 合併成新的
Ranking。
Vector Results
+
BM25 Results
↓
Fusion
↓
Candidate Results
Assembly（組裝）
Context Assembly（上下文組裝）
把最後選出的 Chunks 整理成適合送給 LLM 的 Context。
可能包含：
Remove duplicates
Order chunks
Include source metadata
Respect token budget
Token / Context Window Day 25 已解釋。
Token Budget（Token 預算）
規劃有限 Context Space 要分配多少 Tokens 給各部分。
System Instruction
Conversation
Retrieved Chunks
User Question
Expected Output
都會競爭 Context Window。
Context Packing（上下文打包）
在有限 Token Budget 中，選擇並安排最有價值的 Retrieved Content。
目標：
High Relevance
Low Noise
Enough Evidence
Within Token Budget
Duplicate（重複資料）
多份 Content 實際高度重複。
Deduplication
De → 去除
Duplication → 重複
中文：去重
Overlap 可能讓 Search 找到多個幾乎一樣的 Chunks。
去重可以：
Save tokens
Reduce noise
Citation（引用 / 引用來源）
告訴 User Answer 根據哪份 Source。
例如：
Employee Handbook
Page 18
Vacation Policy
Traceability（可追溯性）
能從 Answer 一路追查回 Original Source。
Answer
↓
Chunk ID
↓
Document ID
↓
Page
↓
Original Document
Citation 提升 Verification 能力，但 Citation 本身不代表 Answer
自動正確。
Freshness 已在之前詳細學過。
Incremental Update
Incremental → 增量的
Update → 更新
中文：增量更新
如果 10,000 Documents 中只有一份變更：
Changed document
↓
Re-parse
↓
Re-chunk
↓
Re-embed
↓
Update index
不必每次全部重建。
Full Rebuild（完整重建）
把整個 Dataset 重新 Parse / Embed / Index。
優點：
Conceptually simple
缺點：
Slow
Expensive
Wasteful for small changes
Upsert
來自：
Update
+
Insert
中文可理解成：
有就更新，沒有就新增
Vector Store 更新 Chunk / Vector 時很常見。
Tombstone（墓碑標記 / 刪除標記）
不一定立即物理刪除 Data，而是先標記「已刪除」。
例如：
chunk_id = 123
deleted = true
之後 Background Process 再真正 Cleanup。
Authorization / Access Control 之前已學過。
RAG 的重點：
不要先 Retrieve Forbidden Data，再叫 LLM 不要說。
應該：
User Identity
↓
Resolve Permission
↓
Authorization Filter
↓
Retrieve only allowed chunks
↓
LLM
Authorization Filter（授權篩選）
Retrieval 時直接排除 User 無權查看的 Documents。
Tenant（租戶）
在 SaaS：
使用同一套 Software，但 Data 需要彼此隔離的一個 Customer /
Organization。
例如：
Company A
Company B
Company C
Multi-Tenancy
Multi → 多個
Tenancy → 租戶架構
中文：多租戶架構
One RAG Platform
├── Company A
├── Company B
└── Company C
最重要 Requirement：
Company A
must never retrieve
Company B private documents
Tenant ID（租戶識別碼）
表示 Data 屬於哪個 Tenant。
{
"tenant_id": "company_a",
"document_id": "doc_123"
}
Data Isolation（資料隔離）
不同 Users / Tenants 的 Private Data 不應錯誤互相暴露。
跨 Tenant Retrieval 是 Security Incident，不只是 Search Quality
Problem。
ACL = Access Control List
逐字：
A = Access = 存取
C = Control = 控制
L = List = 清單
中文：存取控制清單
記錄哪些 Users / Groups 對 Resource 有哪些 Permissions。
例如：
Document X
Engineering → READ
HR → READ
External User → DENY
Permission Inheritance
Permission → 權限
Inheritance → 繼承
中文：權限繼承
例如 Folder：
Engineering
→ Engineering Team can read
裡面的 Documents 可能繼承同樣 Permission。
Ingestion Pipeline 不能忽略這些資訊。
Data Leak（資料洩漏）
不應被看到的 Data 被未授權者取得。
Private RAG 中，這是最嚴重的 Failure 類型之一。
Query Rewriting（查詢改寫）
Retrieval 前，把 User 原始 Question 改成更適合 Search 的 Query。
例如：
"What about the one we discussed yesterday?"
根據 Conversation Context 改成：
"2026 employee PTO policy"
Query Expansion
Query → 查詢
Expansion → 擴展
中文：查詢擴展
例如：
PTO
↓
PTO
Paid Time Off
Vacation Leave
Paid Leave
可能提高 Recall，但擴展太多也可能增加 Noise、降低 Precision。
Synonym（同義詞）
意思相同或接近的 Words。
例如：
car
automobile
Query Expansion 可以利用 Synonyms。
Retrieval Failure（檢索失敗）
沒找到真正需要的 Evidence。
可能原因：
Bad parsing
Bad chunking
OCR error
Wrong query
Bad embedding
Outdated index
Top-K too small
Wrong permission filter
Generation Failure（生成失敗）
已經 Retrieve 正確 Evidence，但 LLM 仍回答錯。
Debug 時先問：
Did retrieval find the correct evidence?
沒有：
Retrieval Problem
有：
Did LLM use it correctly?
沒有：
Generation Problem
Golden Dataset
Golden → 可信的標準答案集合
Dataset → 資料集
中文：人工確認過的高品質評估資料集
例如：
Question:
How many PTO days?
Expected source:
Employee Handbook Page 18
Expected answer:
20 days
Ground Truth
Ground → 基礎
Truth → 真實 / 正確答案
中文：標準真值 / 已知正確答案
Evaluation 時用來比較 System Output 的可信 Reference。
Retrieval Evaluation（檢索評估）
單獨測 Retriever 有沒有找對 Supporting Documents。
例如：
Recall
Precision
Top-K Hit Rate
這裡不是 Cache Hit Rate。
在指定 Top-K Results 中，是否成功出現需要的 Relevant Result。
例如：
100 questions
90 questions have correct source in Top-5
則：
Top-5 Hit Rate = 90%
Team 要先明確定義 Evaluation Rule。
End-to-End
End → 一端
to → 到
End → 另一端
中文：端到端
End-to-End Evaluation
從 Question 一直到 Final Answer 測整條 Pipeline。
Question
↓
Retrieval
↓
Reranking
↓
Context
↓
LLM
↓
Answer
Faithfulness（忠實度）
Answer 是否忠實依據 Retrieved Evidence，而不是自行增加沒有 Source
支持的內容。
Context：
Employees receive 20 PTO days.
Answer：
Employees receive 20 PTO days plus 10 bonus days.
如果 Bonus 沒有 Evidence：
Low Faithfulness
Answer Relevance（回答相關性）
Final Answer 是否真正回答 User Question。
User：
How many PTO days?
如果 Answer 講了 500 字公司歷史卻沒有回答天數：
Low Answer Relevance
Retrieval Quality
├── Recall
├── Precision
└── Hit Rate
Generation Quality
├── Faithfulness
├── Answer Relevance
└── Correctness
System Quality
├── Latency
├── Availability
├── Cost
└── Security
不要只問：
"AI 感覺回答得好不好？"
Latency 之前已學過。
Retrieval Latency（檢索延遲）
從開始 Search 到取得 Retrieved Results 的時間。
RAG Total Latency 可拆：
Query Processing
+
Query Embedding
+
Vector Search
+
Keyword Search
+
Reranking
+
Context Assembly
+
LLM TTFT
+
Generation
Ingestion Latency（資料匯入延遲）
Document 新增 / 修改後，到它真正能被 Search 找到所需的時間。
例如：
Upload 10:00
Searchable 10:05
→ 5 minutes
Index Freshness（索引新鮮度）
Search Index 和 Original Data 最新狀態有多同步。
Event 已學過。
Event-Driven Ingestion（事件驅動資料匯入）
DOCUMENT_UPDATED
↓
Queue
↓
Worker
↓
Parse
↓
Chunk
↓
Embed
↓
Update Index
Worker（工作處理程序 / 工作者）
從 Queue / Task System 取得工作並執行的 Process / Service。
Queue
├── Document A
├── Document B
└── Document C
Worker 1 → A
Worker 2 → B
Worker 3 → C
Backfill（回填）
對既有歷史 Data 補做新的 Processing。
例如公司已有 1M Documents，今天才建立 RAG：
Historical Documents
↓
Parse
↓
Chunk
↓
Embed
↓
Index
這就是 Backfill。
Online Path（線上路徑）
User 正在等待 Response 的 Request Path。
Question → Retrieve → LLM → Answer
Offline Path（離線路徑）
User 不需要當下等待的 Background Processing。
Document Ingestion
Embedding
Backfill
Index Rebuild
不要每次 User 問問題才重新 Parse / Embed 全部 Documents。
Preprocessing
Pre → 事先
Processing → 處理
中文：前處理
例如：
Cleaning
Chunking
Metadata extraction
Embedding
Indexing
都可以先在 Offline Path 完成。
Cache 已學過。
Cache Key（快取鍵）
用來唯一識別 Cached Result 的 Key。
Private RAG 不能只用：
question
可能還要包含：
tenant_id
permission scope
document version
query
避免跨 Tenant / Permission 回傳錯誤 Cache。
Fallback（備援處理 / 替代方案）
主要方式失敗時的替代行為。
例如 Reranker Failure：
Fallback to initial retrieval ranking
但如果 Authorization Service Failure：
Do NOT fallback to unrestricted search
Sensitive RAG 應優先避免 Data Leak。
Layer-by-Layer
Layer → 層
by → 一層接一層
不把 RAG 當一個整體，而是逐層檢查。
Wrong Answer 時：
1. Original source correct?
2. Parsing correct?
3. OCR correct?
4. Chunking correct?
5. Version correct?
6. Index fresh?
7. Retrieval correct?
8. Filters correct?
9. Reranking correct?
10. Correct context sent to LLM?
11. Generation correct?
Black Box（黑箱）
只能看到 Input / Output，但不容易知道內部發生什麼。
不要只：
Question
↓
RAG
↓
Wrong Answer
Production RAG 應記錄：
Retrieved Chunk IDs
Scores
Filters
Reranking Results
Prompt Version
Model Version
Latency
Token Usage
Prompt Version（Prompt 版本）
追蹤 Request 使用哪一版 Prompt。
rag_prompt_v1
rag_prompt_v2
Model Version（模型版本）
記錄 Request 使用哪個 Model / Model Release。
這些資訊有助於 Debug 和 Evaluation。
Reproducibility（可重現性）
發生問題後，能否盡量重現當時的條件。
可以記錄：
Query
Retrieved Chunks
Prompt Version
Model Version
Generation Settings
Timestamp
LLM 可能不是完全 Deterministic，所以不代表一定得到完全相同 Output。
RAG Cost 可能來自：
Parsing
OCR
Embedding
Vector Storage
Vector Search
Keyword Search
Reranking
LLM Input Tokens
LLM Output Tokens
Observability
Optimization（最佳化）
在 Requirement 可接受的前提下，讓 System 更有效率。
例如：
Don't re-embed unchanged documents
Batch embeddings
Choose reasonable chunk size
Limit Top-K
Rerank only candidates
Cache carefully
Choose appropriate model
不能為省錢犧牲：
Security
Freshness
Required Quality
Batch Embedding（批次建立 Embedding）
一次將多個 Chunks 組成一批送到 Embedding Model。
可能改善：
Throughput
Request Efficiency
Overhead（額外負擔 / 額外成本）
主要工作之外，為完成 Operation 額外付出的時間或資源。
每個 API Request 可能有：
Network
Authentication
Headers
Serialization
Scheduling
Batching 可以減少部分重複 Overhead。
Serialization（序列化）
把 Program 內部 Data Structure 轉成適合傳輸 / 儲存的格式。
例如 Object：
{"query": "PTO"}
轉成 JSON。
Deserialization（反序列化）
把 JSON 等格式重新轉成 Program 可以操作的 Data Structure。
Document Sources
┌──────────┼──────────┐
↓ ↓ ↓
PDF Web Page Database
└──────────┼──────────┘
↓
Document Loader
↓
Parser
↓
OCR if needed
↓
Cleaning
↓
Chunking
↓
Add Metadata
↓
Embedding Pipeline
↓
Vectors
↓
Indexing
↓
Vector Store
Metadata 可能保存：
document_id
tenant_id
version
page
section
permissions
source
User
↓
Authentication
↓
Authorization Context
↓
Question
↓
Query Processing
↓
Query Embedding
↓
┌─────────────────────┐
│ │
↓ ↓
Vector Search Keyword Search
│ │
└──────────┬──────────┘
↓
Hybrid Search
↓
Candidate Chunks
↓
Reranking
↓
Authorization / Metadata Check
↓
Deduplication
↓
Context Packing
↓
Prompt Augmentation
↓
LLM
↓
Grounded Answer
↓
Citations
↓
User
User：
How many PTO days do I get?
Flow：
Question
↓
Tenant / Permission Filter
↓
Query Expansion:
PTO / Paid Time Off / Vacation Leave
↓
Semantic Search + BM25
↓
Candidate Chunks
↓
Reranker
↓
Top Relevant Chunks
↓
Context Packing
↓
LLM
↓
20 paid vacation days
↓
Citation:
Employee Handbook, Page 18, Version 2026
System 回：
30 PTO days
不要立刻說：
LLM hallucinated
先檢查：
Source
↓
Parsing / OCR
↓
Chunking
↓
Version
↓
Index Freshness
↓
Retrieval
↓
Reranking
↓
Context
↓
Generation
這是 Production RAG 非常重要的 Debugging 思路。
不要一開始背 Product Names。
先問：
1. What documents?
2. PDF, web, database?
3. How many documents?
4. How often do they change?
5. Is data private?
6. Different user permissions?
7. Multi-tenant?
8. Required latency?
9. Need citations?
10. Need exact keyword search?
11. Need semantic search?
12. How fresh must index be?
13. What if no relevant document is found?
14. How will retrieval quality be evaluated?
15. Traffic?
16. Cost budget?
Documents can be much larger than the useful context for one question.
Chunking creates smaller retrievable units so the system can send only
relevant sections to the model. Large chunks can add noise and token
cost, while very small chunks can lose context, so chunk size and
boundaries are trade-offs.
Overlap preserves content across neighboring chunk boundaries so
important information is less likely to be separated. Too much overlap
increases embedding cost, storage, duplicate search results, and token
usage.
Metadata describes a chunk's source and properties, such as document
ID, page, version, tenant, and permissions. It supports filtering,
authorization, freshness management, citations, and debugging.
A = Approximate = 近似的
N = Nearest = 最近的
N = Neighbor = 鄰居
ANN quickly finds vectors that are likely to be close to a query
vector without exhaustively comparing every vector. It trades some
exactness for much better search performance at scale.
Recall
→ 該找的，有沒有漏？
Precision
→ 找回來的，有多少真的有用？
公式：
Recall
=
Retrieved Relevant / All Relevant
Precision
=
Retrieved Relevant / All Retrieved
Semantic search is strong at matching meaning, while lexical search is
strong for exact terms such as error codes, identifiers, and product
names. Hybrid search combines both signals for more robust retrieval.
BM25, short for Best Matching 25, is a classic lexical ranking
algorithm. It considers signals such as term frequency, term rarity
across documents, and document length to rank search results.
The first retrieval stage searches a large dataset quickly and returns
candidates. A reranker applies a more expensive relevance model to the
smaller candidate set and chooses the best chunks before sending
context to the LLM.
DOCUMENT_UPDATED
↓
Identify changed document
↓
Parse
↓
Chunk
↓
Re-embed
↓
Upsert new vectors
↓
Delete obsolete chunks
↓
Invalidate related caches
也就是 Incremental Update。
Data Isolation + Authorization
Authenticated User
↓
Resolve Tenant + Permission
↓
Authorization Filter
↓
Retrieve allowed chunks only
↓
LLM
絕對不要：
Retrieve forbidden data
↓
Ask LLM not to reveal it
1. Check original source
2. Check parsing / OCR
3. Check chunking
4. Check version
5. Check index freshness
6. Inspect retrieved chunks
7. Inspect scores
8. Check metadata / authorization filters
9. Check reranking
10. Check context sent to LLM
11. Check prompt / model version
12. Determine retrieval failure vs generation failure
Data
□ Knowledge Base
□ Domain
□ Private Data
□ Pipeline
□ Ingestion
□ Ingestion Pipeline
□ Raw Document
□ Document Loader
□ Parser
□ Parsing
□ OCR
□ Optical Character Recognition
□ Extraction
□ Cleaning
Chunking
□ Chunk Size
□ Boundary
□ Chunking Strategy
□ Fixed-Size Chunking
□ Paragraph-Based Chunking
□ Section-Based Chunking
□ Semantic Chunking
□ Coherence
□ Overlap
Metadata
□ Metadata
□ Filter
□ Document ID
□ Identifier
□ Version
□ Versioning
Index / Search
□ Embedding Pipeline
□ Vector Store
□ Indexing
□ Exact Search
□ ANN
□ Approximate Nearest Neighbor
□ Nearest Neighbor
□ Keyword Search
□ Lexical Search
□ BM25
□ Corpus
□ Term
□ TF
□ IDF
□ TF-IDF
□ Hybrid Search
□ Score Fusion
Retrieval
□ Recall
□ Precision
□ Retrieval Quality
□ Query Pipeline
□ Query Embedding
□ Candidate Retrieval
□ Reranking
□ Reranker
□ Two-Stage Retrieval
Context
□ Context Assembly
□ Token Budget
□ Context Packing
□ Duplicate
□ Deduplication
□ Citation
□ Traceability
Freshness
□ Incremental Update
□ Full Rebuild
□ Upsert
□ Tombstone
□ Index Freshness
□ Ingestion Latency
Security
□ Authorization Filter
□ Tenant
□ Multi-Tenancy
□ Tenant ID
□ Data Isolation
□ ACL
□ Access Control List
□ Permission Inheritance
□ Data Leak
Query Improvement
□ Query Rewriting
□ Query Expansion
□ Synonym
Evaluation
□ Retrieval Failure
□ Generation Failure
□ Golden Dataset
□ Ground Truth
□ Retrieval Evaluation
□ Retrieval Hit Rate
□ End-to-End Evaluation
□ Faithfulness
□ Answer Relevance
Operations
□ Event-Driven Ingestion
□ Worker
□ Backfill
□ Online Path
□ Offline Path
□ Preprocessing
□ Cache Key
□ Fallback
□ Layer-by-Layer Debugging
□ Black Box
□ Prompt Version
□ Model Version
□ Reproducibility
Cost
□ Cost Optimization
□ Batch Embedding
□ Request Overhead
□ Serialization
□ Deserialization
OCR
O = Optical = 光學的
C = Character = 字元 / 文字
R = Recognition = 辨識
→ Optical Character Recognition
→ 光學字元辨識
ID
= Identifier
= 識別碼
ANN
A = Approximate = 近似的
N = Nearest = 最近的
N = Neighbor = 鄰居
→ Approximate Nearest Neighbor
→ 近似最近鄰搜尋
BM25
BM = Best Matching = 最佳匹配
25 = 方法發展過程中的版本名稱
→ Best Matching 25
→ 經典 Lexical Search Ranking Algorithm
TF
T = Term = 詞
F = Frequency = 頻率
→ Term Frequency
→ 詞頻
IDF
I = Inverse = 反向 / 反比概念
D = Document = 文件
F = Frequency = 頻率
→ Inverse Document Frequency
→ 逆文件頻率
TF-IDF
= Term Frequency-Inverse Document Frequency
= 詞頻－逆文件頻率
ACL
A = Access = 存取
C = Control = 控制
L = List = 清單
→ Access Control List
→ 存取控制清單
LLM
Token
Tokenizer
Context Window
Chunk
Chunking
Embedding
Embedding Model
Vector
Dimension
Semantic Similarity
Similarity Search
Vector Space
Vector Database
Retrieval
Retriever
Top-K
Noise
Relevance
Hallucination
Grounding
RAG
Prompt Augmentation
Inference
TTFT
Evaluation
API
Cache
Message Queue
Authentication
Authorization
Access Control
Latency
Throughput
Availability
Observability
ACID
CAP
Private Documents
↓
Document Loader
↓
Parser / OCR
↓
Cleaning
↓
Chunking
↓
Metadata
↓
Embedding
↓
Indexing
↓
Vector Store
User Question
↓
Authentication
↓
Tenant / Permission Resolution
↓
Query Processing
↓
Semantic Search + Keyword Search
↓
Hybrid Search
↓
Candidate Retrieval
↓
Reranking
↓
Authorization Check
↓
Deduplication
↓
Context Packing
↓
Prompt Augmentation
↓
LLM
↓
Answer + Citation
Golden Dataset
↓
Run Queries
↓
Evaluate Retrieval
↓
Recall / Precision / Hit Rate
↓
Evaluate Generation
↓
Faithfulness / Answer Relevance
↓
Compare Versions
不要背：
PDF
↓
Embedding
↓
Vector DB
↓
LLM
真正要問：
What data?
↓
How do we parse it?
↓
How do we chunk it?
↓
What metadata?
↓
How do we preserve permissions?
↓
How do we create embeddings?
↓
How do we index millions of chunks?
↓
Semantic or keyword search?
↓
Need hybrid search?
↓
How many candidates?
↓
Need reranking?
↓
How much context?
↓
How do we cite sources?
↓
How do we update changed documents?
↓
How do we prevent cross-tenant leaks?
↓
How do we evaluate retrieval?
↓
How do we debug wrong answers?
↓
What is the latency and cost?
RAG 的核心不是「接一個 Vector Database」，而是建立一條可靠的
Knowledge Pipeline：把正確、最新、User 有權限看的資料找出來，再把真正
Relevant 的 Evidence 提供給 LLM。
Day 27｜AI Agent Architecture：Tool
Calling、Memory、Planning、Workflow 到底是什麼？
新的 Agent Concepts 會包含：
AI Agent
Agentic AI
Tool
Tool Calling
Function Calling
Action
Observation
Reasoning Loop
Planning
Planner
Executor
Workflow
Orchestration
Short-Term Memory
Long-Term Memory
Checkpoint
Human-in-the-Loop
HITL
Approval
Agent Loop
Max Steps
Termination Condition
Tool Error
Agent Guardrail
仍然遵守：
之前詳細解釋過
→ 不重複長篇定義
第一次出現的新名詞
→ 完整英文
→ 中文
→ 縮寫逐字拆解
→ 是什麼
→ 為什麼需要
→ 簡單例子
→ 最後才進 Architecture
iThome鐵人賽
看影片追技術