讓聊天機器人回答訓練資料以外的問題——例如查內部公司文件。難點不在吞吐量，而在檢索到對的內容、生成不亂編、還能附上引用來源。
📋 Requirements
- 功能：員工直接向機器人提問，取得基於內部文件的回答，並附上文件引用來源。
- 知識庫：約 500 萬頁 PDF（Wiki 與內部論壇），含文字、表格、圖表；無固定版面，內容會更新但不如即時資料頻繁。
- 非功能：可容忍幾秒延遲、僅支援英文、文件量預計每年成長 20%；設計要保留日後加入回饋／追問的彈性。
🧠 Core Ideas
TIP
讓 LLM 讀公司資料有三條路：微調（改權重，成本高、無法引用來源）、提示工程（不改模型，但把全部資料塞進提示會超出 context window）、RAG（結合通用 LLM 與推論時的即時檢索）。RAG 在設置便利、成本與可擴展性間取得平衡，是大規模且持續演進資料集的理想選擇。
RAG 有兩個核心元件：檢索——依使用者提示從外部來源找出最相關資訊當上下文；生成——由 LLM 結合提示與檢索結果產生回應。好處是能存取最新資訊、上下文相關性高；代價是兩元件要協調運作，且回應品質高度仰賴檢索品質。
⚖️ Reference Design
資料準備 — 解析、分塊、索引
- 文件解析：把 PDF 的文字、圖片、表格轉成結構化格式。基於規則的解析器只適合格式一致的文件；面對多樣版面改用基於 AI 的解析器（物件偵測 + OCR），如 Layout-Parser、Dedoc。
- 文件分塊 (chunking)：長文整段索引會遺漏細節、又超過 token 限制，所以切成小區塊。策略有基於長度、基於正規表達式、以及 HTML/Markdown/程式碼專用分割器。
- 估算：500 萬頁、每頁約 1,500 字元 + 3 張圖，用區塊 500 字元、重疊 200 字元 → 約 4,000 萬個區塊，每年再成長 20%。
索引 — 為何選向量檢索
- 檢索技術有關鍵字、全文（如 Elasticsearch）、知識圖譜、向量四種。前兩者無法理解語意、大規模成本高；知識圖譜建構維護太貴。
- 向量檢索用高維嵌入向量衡量相似度，即使用詞不同也能命中語意相關內容，對大規模資料集最具彈性——雀屏中選。
- 每個區塊經編碼器轉成嵌入向量存入向量資料庫。文字用 text encoder（純編碼器 Transformer），圖片用 image encoder；兩者要對齊到共享嵌入空間（如 CLIP）或先用 image captioning 轉成文字再編碼。
檢索 — 最近鄰搜尋
- 用與索引階段相同的 text encoder 把查詢轉成嵌入向量，再做最近鄰搜尋，相似度度量常用歐幾里得距離或餘弦相似度。
- 精確最近鄰（線性搜尋）保證正確，但複雜度 O(N × D)——對 4,000 萬項目太慢。
- 改用近似最近鄰 (ANN)，次線性複雜度，四大類：基於樹（k-d tree、Annoy）、局部敏感雜湊 (LSH)、基於聚類、基於圖（HNSW）。本設計為簡化採基於聚類的 ANN。可用框架：Elasticsearch、FAISS、ScaNN。
生成與整體流程
- 生成：把使用者查詢與檢索到的上下文組成提示詞，交給 LLM 以 top-p 取樣產生回應；用提示工程（思維鏈 CoT、少樣本、角色特定、使用者上下文）提升品質。
- 大多數元件都以預訓練模型起步，微調 LLM 不是最佳化的第一步；先調檢索與提示，仍不理想才考慮微調（如 RAFT）。
- 整體管線：索引流程 → 安全過濾（擋不當／有害查詢）→ 查詢擴展（修拼字文法、拓寬搜尋）→ 檢索（CLIP text encoder + ANN）→ 生成（提示工程 + LLM 推論）。
🔑 Takeaways
- RAG vs 微調 vs 提示工程：要引用來源、要規模、要跟上更新，選 RAG；微調成本高又無來源，純提示工程塞不進 context window。
- 資料準備決定上限：解析 → 分塊 → 索引；分塊粒度直接影響檢索精度，估算區塊量才好選型。
- 檢索靠 ANN：大規模下精確最近鄰太慢，用近似最近鄰換取次線性延遲；相似度用歐氏／餘弦距離。
- 評估是三角關係：上下文相關性（Hit Rate／MRR／NDCG／Precision@k）、忠實度（有沒有幻覺、是否貼合來源）、回答相關性與正確性（BLEU／ROUGE／METEOR）。
No notes yet — jot your takeaways or Q&A here.