簡介#

在第四章中，我們開發了一個能回答開放式問題的聊天機器人。然而，許多應用需要存取 LLM 訓練資料以外的額外資訊，例如：

• 企業資料庫（如內部文件）
• 即時資料（如體育比分）
• 使用者上傳的檔案（如 PDF 文件）

讓聊天機器人存取這些資訊，能顯著提升回答的準確性與相關性，尤其在事實查詢或專業任務中效果更為明顯。一個實際案例是 Perplexity.ai [1]，它是一款以 AI 驅動的對話式搜尋引擎，能利用網路上的資訊回應使用者查詢。

本章將建構一個類似 ChatPDF [2] 的系統，讓員工能透過內部公司文件獲得解答。員工無需逐頁閱讀常見問題，只要直接向聊天機器人提問，即可獲得基於文件內容的回答。

需求釐清#

以下是面試中候選人與面試官之間的典型對話：

候選人： 外部知識庫的組成內容為何？是否會隨時間變化？ 面試官： 知識庫包含公司 Wiki 頁面和一個類似 Stack Overflow 的公司內部論壇。文件內容會更新，但更新頻率不如即時資料那麼快。

候選人： Wiki 頁面與論壇是否包含文字、圖片及其他模態的內容？ 面試官： 假設每個頁面都是 PDF 格式，包含文字、表格和圖表。為簡化問題，不需考慮其他模態。

候選人： 這些頁面是否遵循固定格式或範本？ 面試官： 沒有固定格式。有些是雙欄排版，有些是單欄，還有混合排版。

候選人： 總共有多少頁面？ 面試官： 大約 500 萬頁。

候選人： 系統是否需要附上文件引用來源？ 面試官： 是的。

候選人： 系統是否需要即時回應？ 面試官： 使用者可以容忍幾秒鐘的短暫延遲。

候選人： 系統是否需要支援多語言？ 面試官： 為簡化問題，僅支援英文。

候選人： 系統是否需要支援使用者回饋或後續追問？ 面試官： 初期不需要。但設計上應具備足夠的彈性，以便日後加入回饋機制或追問功能。

候選人： 文件預期的成長速度為何？ 面試官： 文件量預計每年成長 20%。

候選人： 是否需要處理安全性問題，例如防止有害、偏見或誤導性的輸出？ 面試官： 安全性很重要，但我們先把重點放在資料處理、架構設計和效能最佳化上。

將問題定義為機器學習任務#

定義系統的輸入與輸出#

• 輸入： 使用者提供的文字提示（Text Prompt）
• 處理上下文： 持續更新的文件資料庫，包含文字與圖片
• 輸出： 準確回應使用者查詢的文字回覆

選擇適合的機器學習方法#

大型語言模型（LLM）非常適合用於文字生成。然而，通用型 LLM 在處理特定領域時可能力有未逮，需要進行客製化以存取外部資料來源。要讓 LLM 根據公司特定資料回答問題，主要有三種方法：

• 微調（Finetuning）
• 提示工程（Prompt Engineering）
• 檢索增強生成（Retrieval-Augmented Generation, RAG）

以下逐一探討各方法的細節與取捨。

微調（Finetuning）#

此方法將預訓練（Pretraining）的通用 LLM 在公司特定資料（如內部文件）上進行微調（Finetuning）。透過更新模型權重，LLM 能更好地理解公司獨有的術語、流程和常見問題。第十章將深入探討進階微調技術，例如 LoRA [3]。

優點：

• 可客製化： 能讓模型針對特定領域生成量身定做的回應
• 提升準確度： 對專業主題的處理能力更佳

缺點：

• 計算成本高： 更新整個模型的參數需要大量運算資源
• 需頻繁重新訓練： 為持續納入最新資料，需要頻繁進行微調
• 需技術專業知識： 需要對機器學習原理與語言模型架構有深入了解
• 需大量資料： 需要大規模且高品質的資料集，收集不易
• 缺乏引用來源： 通常無法為回答提供參考來源，難以追溯資訊出處

提示工程（Prompt Engineering）#

提示工程透過精心設計的提示詞來引導通用 LLM 產生特定輸出。與微調不同，此方法不改變底層 LLM，而是將相關資訊（如公司資料或指令）直接納入提示詞中，以控制模型行為。例如，提示詞可以包含公司政策的摘要，如圖 4 所示。

優點：

• 易於使用： 操作簡單，不需技術背景，適用範圍廣
• 成本效益高： 相較於微調，運算成本極低
• 彈性佳： 可輕鬆修改提示詞來嘗試不同輸出，無需重新訓練模型

缺點：

• 一致性不足： 回應品質會因提示詞的措辭方式而有很大差異
• 客製化有限： 無法達到微調所能提供的深度客製化
• 受限於 LLM 既有知識： 輸出內容僅限於 LLM 原始訓練資料所涵蓋的資訊，對於高度專業領域或即時資訊的處理效果較差

RAG#

RAG 是一種進階方法，結合了通用 LLM 的能力與即時檢索系統。RAG 不僅依賴 LLM 的預訓練知識，還會在推論（Inference）階段從外部來源（如內部文件）檢索相關資訊，再將其提供給 LLM。

RAG 系統如圖 5 所示，包含兩個核心元件：

• 檢索（Retrieval）： 根據使用者的原始提示詞，從外部來源找出最相關的資訊，並以上下文形式回傳
• 生成（Generation）： 通常由通用 LLM 結合使用者的提示詞與檢索到的資訊來生成回應

優點：

• 可存取最新資訊： 透過從外部來源拉取資料，可以提供最即時的回應
• 上下文相關性高： 為模型的回答增添上下文，使回應更詳盡且相關

缺點：

• 實作複雜度高： 需要檢索與生成兩個元件協調運作
• 依賴檢索品質： 回應品質高度仰賴檢索到的資訊之相關性與準確度

哪種方法最適合 ChatPDF？#

• 微調（Finetuning） 能產生專業化回應，但計算成本高昂且無法引用原始文件，不適合此場景
• 提示工程（Prompt Engineering） 提供簡單且彈性的 LLM 引導方式，但無法擴展，因為將所有外部資料納入提示詞通常會超出 LLM 的上下文視窗（Context Window）
• RAG 在設置便利性、成本與可擴展性之間取得平衡，是處理大規模且持續演進的資料集之理想選擇

我們選擇 RAG 來建構 ChatPDF 系統。在模型開發章節中，我們將深入探討提示工程，以及如何將其與 RAG 結合以進一步提升系統效能。

資料準備#

RAG 系統的效能取決於知識資料庫的品質及其索引方式。當知識庫來源為網站時，應採用資料清理策略，例如移除不當內容或對敏感資訊進行匿名化處理，詳見第四章。

本節聚焦於如何從 PDF 頁面集合準備資料，包含以下三個步驟：

1. 文件解析（Document Parsing）
2. 文件分塊（Document Chunking）
3. 索引建立（Indexing）

文件解析（Document Parsing）#

PDF 是最廣泛使用的文件格式之一。正確擷取其內容，對於確保 LLM 能基於 PDF 內容準確回答問題至關重要。

解析（Parsing） PDF 指的是將其文字、圖片與其他元素轉換為語言模型可理解的結構化格式。主要有兩種方法：

基於規則的文件解析器#

基於規則的方法依賴預先定義的規則與樣式，根據文件的版面配置與結構進行內容擷取。當文件格式一致且可預測時，此方法易於實作。

然而，基於規則的方法難以應對多樣化的 PDF 類型與格式。其僵化的特性意味著，若文件不符合預期格式，就會產生擷取錯誤。因此，對於格式不一或版面複雜的文件，此方法的實用性較低。

基於 AI 的文件解析器#

基於 AI 的方法使用物件偵測（Object Detection） 和 OCR（光學字元辨識，Optical Character Recognition）[4] 等進階技術，從文件中識別並擷取各種元素（文字、表格、圖表）。這些方法能處理多種文件版面，更適合複雜文件。

可用的工具包括：

• Dedoc [5] — 支援解析多種文件格式，並將內容標準化為一致的結構
• Layout-Parser [6] — 使用高精度模型精確偵測文件的不同區域，但模型較大可能導致處理速度較慢

Layout-Parser 的運作方式：

1. 版面偵測： 使用進階物件偵測模型，偵測並在不同內容區域（段落、表格、圖片、標題）周圍產生矩形邊框
2. 文字擷取： 使用 OCR 處理每個矩形邊框內的內容，確保文字以正確的順序和格式被辨識
3. 結構化輸出生成： 產生包含以下內容的結構化輸出：
   • 文字區塊： 包含區塊座標、擷取的文字、閱讀順序和元資訊
   • 非文字區塊： 包含圖片或圖形的座標

多種線上服務提供文件解析功能，例如 Google Cloud Document AI [7] 和 PDF.co [8]。

文件分塊（Document Chunking）#

當我們識別出文件中的文字、圖片或表格區塊後，下一步是將它們索引至可搜尋的資料庫中。對於較長的文字區塊（如報告或書籍中的內容），將整段內容作為單一項目索引是不有效的，原因如下：

• 代表整本書或報告的嵌入向量（Embedding Vector）可能捕捉到整體脈絡，但遺漏重要細節，導致檢索準確度下降
• 檢索整本書或報告會超出大多數模型的 Token 限制（例如 GPT-4o 的 128K Token 限制）1

文件分塊透過將文字切割為更小、更易管理的片段或「區塊（Chunk）」來解決這些問題。分塊能提升檢索的品質與精確度，並確保每個區塊符合模型的輸入限制。

常見的分塊策略包括：

• 基於長度的分塊： 依照指定長度分割文字。實作簡單，但可能在句子或邏輯段落中間切斷。LangChain [9] 提供了 CharacterTextSplitter 和 RecursiveCharacterTextSplitter 等文字分割工具，支援可調整的區塊大小和重疊設定
• 基於正規表達式的分塊： 使用正規表達式，依據特定標點符號（句號、問號、驚嘆號）分割文字。能更好地實現句子層級的分塊，但可能缺乏更深層的語意理解
• HTML、Markdown 或程式碼分割器： 針對結構化格式，專用分割器會在元素邊界（標題、清單項目、程式碼區塊）處分割文字，同時保留文件的整體結構。LangChain 提供 MarkdownHeaderTextSplitter、HTMLHeaderTextSplitter 和 PythonCodeTextSplitter。這些工具適用於需要維護階層結構的網頁或技術文件

索引建立（Indexing）#

完成文件解析和分塊後，最後的關鍵步驟是索引建立 — 將分塊後的資料組織成一個能夠進行高效且準確檢索的結構。

為了決定索引流程，了解各種檢索技術並選擇最適合任務的方法至關重要：

• 關鍵字檢索（Keyword-Based）
• 全文檢索（Full-Text Search）
• 知識圖譜檢索（Knowledge Graph-Based）
• 向量檢索（Vector-Based）

關鍵字檢索（Keyword-Based）#

傳統的關鍵字檢索依賴查詢詞與文件內容的精確匹配。速度快且實作簡單，但無法理解查詢的語意。例如，它可能無法處理同義詞，導致結果不完整或不相關。對於大規模資料集或以語意相似度（而非精確字詞匹配）為目標的場景，此方法效果不佳。

全文檢索（Full-Text Search）#

全文搜尋引擎（如 Elasticsearch [10]）提供更進階的方法，能掃描整份文件以找出相關匹配，包括部分匹配和片語搜尋。然而，全文檢索在處理大規模資料集（如數百萬份 PDF 文件）時，計算負擔較高。雖然在尋找特定文字方面效果不錯，但在語意檢索上的效率較低。

知識圖譜檢索（Knowledge Graph-Based）#

知識圖譜檢索利用實體（人物、地點、概念）之間的結構化關係，根據實體間的連結來檢索資訊。此方法擅長回答複雜查詢並理解資料中的關聯。然而，建立與維護知識圖譜需要大量投入，對於大規模非結構化資料集（如 PDF 集合或 Wiki 頁面）並不總是可行的。更多細節請參考 [11]。

向量檢索（Vector-Based）#

此方法不依賴文字匹配，而是使用高維嵌入向量（High-Dimensional Embeddings） — 文字與圖片的數值表示 — 來衡量查詢與儲存資料區塊之間的相似度。即使查詢中的確切用詞與文件內容不同，此技術也能檢索到相關資訊，使其對大規模資料集更具彈性與效力。

哪種檢索技術適合 ChatPDF？#

為了選擇適當的檢索方法，我們先估算涉及的資料區塊數量：

• 公司管理約 500 萬頁文件
• 每頁大約包含 1,500 個字元和 3 張圖片
• 使用基於長度的分塊（區塊大小 500 字元、重疊 200 字元），每頁產生 5 個文字區塊和 3 個圖片區塊
• 總區塊數：5M × (1500 / (500 - 200) + 3) = 4,000 萬個區塊
• 此數字預計每年成長約 20%

面對約 4,000 萬個資料區塊且預計每年成長 20%，選擇一個可擴展且能高效處理持續成長資料量的檢索技術至關重要。

傳統檢索方法 [12] [13]（如關鍵字檢索和全文檢索）在速度、可擴展性和語意理解方面存在限制。知識圖譜檢索則需要大量建構與維護成本。

向量檢索是現代 RAG 系統中最主要的檢索技術，具備以下優勢：

• 語意理解： 能捕捉查詢的語意，即使文件中不存在精確的查詢詞，也能準確檢索
• 可擴展性： 嵌入向量使此方法對大規模資料集具有高度擴展性
• 效率： 一旦資料被索引為嵌入向量，系統即可高效檢索相關區塊

我們選擇向量檢索並據此建立索引。

為向量檢索建立索引#

在向量檢索系統中，每個資料區塊會被轉換為一個嵌入向量（Embedding Vector），以數值格式表示其內容。機器學習模型計算嵌入向量並儲存於向量資料庫（Vector Database） 中，使 RAG 系統能在推論時快速將查詢的嵌入向量與已儲存的嵌入向量進行比較，從而檢索最相關的資訊。

三步驟資料準備流程：(1) 文件解析將 PDF 轉換為結構化格式；(2) 文件分塊將長文字拆分為較小的區塊；(3) 嵌入與索引將每個區塊轉換為向量以實現精確檢索。

模型開發#

架構#

本節探討 RAG 系統的架構，聚焦於索引（Indexing）、檢索（Retrieval） 和生成（Generation） 元件中使用的機器學習模型。

索引（Indexing）#

如資料準備章節所述，我們使用機器學習模型將資料區塊（文字或圖片）轉換為嵌入向量。此過程涉及兩個模型：文字編碼器（Text Encoder） 和圖片編碼器（Image Encoder）。

文字編碼器（Text Encoder）#

文字編碼器是一個神經網路，將輸入文字轉換為密集向量表示（即「嵌入向量」）。這些嵌入向量捕捉文字的語意，使系統能評估文字的相似度。在索引階段，文字編碼器將每個文字區塊轉換為嵌入向量，並儲存於資料庫中以供高效檢索。

文字編碼器的架構通常基於純編碼器 Transformer（Encoder-Only Transformer），與第三章中介紹的架構相似。

圖片編碼器（Image Encoder）#

圖片編碼器將圖片資料轉換為嵌入向量。其架構可以是基於 CNN 或基於 Transformer 的，詳見第五章。

為了實現有效的檢索，將圖片嵌入向量與文字嵌入向量對齊非常重要。例如，若查詢為「公司裡有幾隻貓？」，系統需要確保編碼後的查詢與相關圖片的嵌入向量距離接近。主要有兩種方法：

1. 共享嵌入空間（Shared Embedding Space）： 使用能在共享空間中生成嵌入向量的圖片和文字編碼器。CLIP [14] 提供具有共享嵌入空間的預訓練編碼器，能實現跨模態檢索（Cross-Modal Retrieval）
2. 圖片描述（Image Captioning）： 使用圖片描述模型為圖片生成文字描述，再使用文字編碼器對描述進行編碼。此方法適用於使用不同模型的場景，或當訓練聯合模型需要大量資源時。建構圖片描述系統的詳細內容請參考第五章

在本章中，我們使用預訓練的 CLIP 模型同時作為文字和圖片編碼器。這些模型通常是預訓練好的，可以直接應用而無需額外訓練。

檢索（Retrieval）#

檢索流程將使用者的查詢轉換為與已索引資料相同的嵌入空間，使用的是與索引階段相同的文字編碼器。一旦查詢嵌入向量計算完成，即可與已儲存的嵌入向量進行比較，以檢索最相關的資料區塊。

生成（Generation）#

生成元件根據使用者查詢和檢索到的上下文產生最終回應。此任務通常由 LLM 處理，生成與上下文相關的文字。

RAG 系統可與各種類型的 LLM 搭配運作，不受架構限制，包括純解碼器 Transformer（Decoder-Only Transformer，詳見第四章）或支援透過 API 進行微調的雲端託管模型 [15] [16]。

訓練#

RAG 系統的大多數元件以預訓練模型為起點，因此微調 LLM 通常不是最佳化效能的第一步。在許多情況下，精心設計的檢索流程搭配有效的提示工程就能取得令人滿意的結果。

當系統在調整檢索參數和設計提示詞之後，仍然持續無法提供準確或相關的回答時，才應考慮進行微調。例如，若檢索到的文件是相關的，但 LLM 未能生成高品質的回應，微調可以幫助 LLM 更好地理解檢索資料的上下文與細微差異。

一個值得關注的方法是 RAFT（Retrieval-Augmented Fine-Tuning）。

RAFT#

RAFT [17] 提出了一種新穎的訓練方法，以增強 LLM 處理檢索文件中相關與不相關資訊的能力。

在傳統 RAG 系統中，LLM 的輸出高度依賴檢索文件的品質。然而，不相關的文件（「干擾文件」）可能被包含在檢索結果中，誤導 LLM 生成次佳回應。RAFT 透過兩個關鍵步驟解決此問題：

1. 文件標記： 將檢索到的文件標記為相關（Golden） 或不相關（Distractor）。這為 LLM 提供了明確的信號，讓它知道應該關注哪些文件
2. 聯合訓練（Joint Training）： 訓練 LLM 根據相關文件生成回應，同時最小化不相關文件的影響。損失函數（Loss Function）會經過調整，在回應生成過程中對使用不相關文件的情況進行懲罰

透過訓練模型優先處理相關內容並忽略干擾文件，RAFT 提升了 LLM 處理含雜訊檢索結果的能力。這對於檢索系統並非總是完美的實際應用場景至關重要。更多細節請參考 [17]。

取樣（Sampling）#

在 RAG 系統中，多個元件協同運作以產生使用者查詢的回應。本節探討這些元件，並重點介紹在檢索和生成階段提升效能的技術。

檢索（Retrieval）#

檢索過程包含兩個主要步驟：

1. 計算查詢嵌入向量
2. 執行最近鄰搜尋（Nearest Neighbor Search）

1. 計算查詢嵌入向量#

第一步是使用文字編碼器將使用者的查詢轉換為嵌入向量。此嵌入向量捕捉查詢的語意，使系統能將其與已索引的嵌入向量進行比較。

2. 執行最近鄰搜尋#

計算出查詢嵌入向量後，系統執行最近鄰搜尋（Nearest Neighbor Search） 以找出與查詢最相似的資料區塊。此搜尋根據選定的相似度度量，識別資料集中與查詢點最接近的資料點。常見的相似度度量包括：

• 歐幾里得距離（Euclidean Distance） [18]
• 餘弦相似度（Cosine Similarity） [19]
• 其他能捕捉嵌入空間中資料點之間關係的距離度量

最近鄰搜尋是資訊檢索、搜尋引擎和推薦系統的基礎元件。即使是效能上的微小提升，也能帶來顯著的整體系統改善。

最近鄰演算法大致分為兩類：

• 精確最近鄰（Exact Nearest Neighbor）
• 近似最近鄰（Approximate Nearest Neighbor）

精確最近鄰（Exact Nearest Neighbor）#

精確最近鄰搜尋（又稱線性搜尋）計算查詢嵌入向量 $E_q$ 與資料集中每個項目之間的距離，檢索 $k$ 個最近的鄰居。

雖然此方法保證能找到真正的最近鄰，但其時間複雜度為 $O(N \times D)$，其中 $N$ 為項目數量，$D$ 為嵌入維度。這種線性複雜度使其在大規模系統中非常緩慢。例如，對 4,000 萬個項目進行精確搜尋需要 4,000 萬次比較，導致高計算成本和延遲。

近似最近鄰（Approximate Nearest Neighbor, ANN）#

在許多應用中，檢索足夠相似的項目即可，不需要精確的最近鄰。ANN 演算法使用特殊的資料結構，在不搜尋整個資料集的情況下檢索「夠接近」的鄰居，將搜尋時間降至次線性複雜度（如 $O(\log(N) \times D)$）。

ANN 演算法大致可分為以下類別：

• 基於樹的方法（Tree-Based）
• 局部敏感雜湊（Locality-Sensitive Hashing）
• 基於聚類的方法（Clustering-Based）
• 基於圖的方法（Graph-Based）

面試官通常不會期望你了解這些類別的每個細節，但具備高層次的理解通常是有幫助的。

基於樹的方法（Tree-Based）#

基於樹的演算法將資料空間劃分為多個分區，並利用樹結構加速搜尋。範例：

• k-d tree [20] — 根據特徵值分割空間，透過縮小相關區域來加速搜尋
• R-trees [21]
• Annoy（Approximate Nearest Neighbor Oh Yeah）[22]

局部敏感雜湊（Locality-Sensitive Hashing, LSH）#

LSH 使用特殊的雜湊函數將相似的點分組到桶（Bucket） 中，確保空間中距離接近的點被雜湊到同一個桶。這大幅減少了搜尋空間，因為只需檢查與查詢在同一桶中的點，使 LSH 對大規模資料集非常高效。更多細節請參考 [23]。

基於聚類的方法（Clustering-Based）#

基於聚類的演算法使用距離度量（如餘弦相似度或歐幾里得距離）將資料組織成群集。最近鄰的檢索分兩步進行：

1. 群集間搜尋（Inter-Cluster Search）： 將查詢嵌入向量與所有群集的質心進行比較，選出距離低於指定閾值的群集
2. 群集內搜尋（Intra-Cluster Search）： 將查詢嵌入向量與所選群集中的項目進行比較

此兩步驟流程顯著提升了效率，如圖 16 所示。

基於圖的方法（Graph-Based）#

基於圖的演算法，如 HNSW（Hierarchical Navigable Small World）[24]，將資料結構化為一個圖，其中節點代表資料點，邊根據鄰近性連接各點。HNSW 透過分層導航此圖來運作，從較高層級的粗略圖開始，逐步移至更精細的層級。在每個層級上進行細化搜尋，僅探索鄰近的節點，從而大幅減少搜尋空間。

哪種 ANN 類別最適合 RAG 檢索系統？#

在 RAG 系統中，索引項目的數量通常非常龐大且持續增長，往往超過數億個嵌入向量。精確最近鄰搜尋的時間複雜度太高，因此我們依賴 ANN 演算法。

各種 ANN 演算法各有優勢，選擇合適的演算法取決於資料集大小、所需速度和準確度之間的權衡。為簡化起見，我們在檢索元件中採用基於聚類的 ANN 方法。

數個現代框架提供開箱即用的 ANN 支援：

• Elasticsearch [10] — 廣泛使用的搜尋引擎，支援向量相似度搜尋
• FAISS [25] — 由 Meta 開發的熱門函式庫，用於大規模資料集的高效最近鄰搜尋
• ScaNN [26] — 由 Google 開發的函式庫，專為快速高效的最近鄰搜尋而設計

生成（Generation）#

生成元件將使用者查詢和檢索到的上下文作為輸入，使用 top-p 取樣（Top-p Sampling） 生成回應。我們可以透過加入提示工程技術進一步提升生成回應的品質，如圖 17 所示。

提示工程（Prompt Engineering）#

提示工程透過最佳化輸入提示詞，幫助 LLM 生成更準確且與上下文相關的回應。透過精心設計提示詞，我們可以引導模型的輸出更好地契合特定任務。

雖然提示工程可以應用於檢索（例如設計更好的查詢以最佳化搜尋）和生成兩個階段，本章為教學目的，聚焦於將其應用於生成元件。同樣的方法也可用於提升檢索效能。

提示詞設計原則#

有效的提示詞設計對於最大化 LLM 效能至關重要。關鍵原則包括：

1. 從簡單開始： 以直觀的提示詞開始，逐步引入複雜度。反覆實驗是關鍵。Cohere 的 Playground [27] 等工具可讓你輕鬆測試和調整
2. 拆解複雜任務： 將包含多個子任務的任務分解為更小、更易管理的步驟，避免讓 LLM 負擔過重
3. 使用明確指令： 使用行動導向的指令，如「Write」、「Summarize」或「Translate」。將指令放在提示詞開頭，並以 ### 等分隔符號區隔
4. 具體明確： 清楚描述預期的格式、風格或成果。避免在提示詞中堆疊不必要的細節
5. 嘗試不同提示詞長度： 過多不必要的資訊可能使 LLM 混淆，而資訊過少則可能導致模糊的回應。在簡潔與充分細節之間取得平衡

提示工程技術#

多種技術已被開發來提升 LLM 輸出品質：

思維鏈提示（Chain-of-Thought Prompting）#

思維鏈提示（Chain-of-Thought, CoT） [28] 引導模型在得出最終答案前，經歷中間推理步驟。這對需要多跳推理（Multi-Hop Reasoning）的複雜查詢特別有用，模型需要從多份文件中整合資訊。

CoT 已被進一步擴展，例如 [29] 的技術讓模型能在選擇最佳回應前評估多條推理路徑。OpenAI 的 o12 [30] 和 [31] 已展示，透過在推論時分配更多計算預算（即測試時計算擴展，Test-Time Compute Scaling），可以提升 LLM 處理複雜任務的能力。

少樣本提示（Few-Shot Prompting）#

少樣本提示（Few-Shot Prompting） [32] 在實際查詢前，向模型提供幾個輸入-輸出範例。這幫助模型理解所期望的格式和語調，提升其生成與範例一致之回應的能力。

角色特定提示（Role-Specific Prompting）#

語言模型可能需要扮演特定「角色」以生成適當的回應。例如，在法律或醫療領域，提示模型扮演領域專家的角色，可確保回應具備必要的語調、準確度和權威性。

使用者上下文提示（User-Context Prompting）#

使用者上下文提示（User-Context Prompting） 根據提示詞中包含的特定使用者資訊來調整模型輸出。透過納入使用者個人資料、偏好或位置等資訊，模型可以生成更相關的個人化回應。

此方法在使用者特定資訊對回應內容有關鍵影響時特別有效，例如個人化推薦或基於位置的查詢。

整合運用：RAG 回應生成的提示工程#

結合這些技術，我們可以為 RAG 系統的回應生成設計高效的提示詞。清晰度和具體性等原則引導模型產生更準確的輸出。提示工程技術能顯著增強 RAG 的生成能力，帶來更可靠且符合上下文的結果。

評估#

與使用明確量化指標評估的傳統機器學習模型不同，評估 RAG 系統更為複雜。最終文字回應的品質取決於管線中多個元件的有效性。我們使用三角圖（Triad Diagram） 來說明不同評估面向之間的關係。

評估聚焦於四個關鍵面向：

• 上下文相關性（Context Relevance）
• 忠實度（Faithfulness）
• 回答相關性（Answer Relevance）
• 回答正確性（Answer Correctness）

上下文相關性（Context Relevance）#

上下文相關性衡量檢索元件根據查詢選擇相關文件的準確度和完整度。目標是確保所有相關內容出現在檢索結果的頂部。常見的指標包括：

• 命中率（Hit Rate）
• 平均倒數排名（Mean Reciprocal Rank, MRR）
• 正規化折損累積增益（Normalized Discounted Cumulative Gain, NDCG）
• Precision@k

更多關於檢索與排名系統的評估指標，請參考 [33] [34]。

忠實度（Faithfulness）#

忠實度評估生成的回應是否與檢索到的上下文事實一致。它檢查生成元件是否產生幻覺（Hallucination），即引入了不在上下文中的資訊。這一點至關重要，因為系統應產生嚴格反映來源資料的回答。

忠實度可透過以下方式評估：

• 人工評估： 專家手動審查回應，判斷其是否與事實一致且正確引用了檢索到的文件
• 自動化事實查核工具： [35] 和 [36] 等工具透過將回應與已驗證的事實資料庫進行比對來自動驗證，提供可擴展的不準確識別方案
• 一致性檢查： 評估 LLM 在多次查詢中是否提供一致的事實資訊，確保不會產生矛盾的資訊

回答相關性（Answer Relevance）#

回答相關性衡量生成的回答在完整性和無冗餘性方面與原始查詢的匹配程度。若回應包含不相關或冗餘的資訊，或缺少重要細節，則分數較低。此面向可透過使用另一個語言模型（如 ChatGPT）比較問題和答案來評估。

回答正確性（Answer Correctness）#

回答正確性聚焦於生成的回答與正確參考答案的匹配程度。它使用常見指標衡量相似度，包括 BLEU、ROUGE 和 METEOR。這些指標的詳細介紹請參考第三章。

整體機器學習系統設計#

RAG 系統由多個協同運作的元件組成，以高效地檢索和生成回應。本節探討以下關鍵元件：

• 索引流程
• 安全過濾
• 查詢擴展
• 檢索
• 生成

索引流程#

索引流程將知識庫轉換為嵌入向量，並儲存在索引表（Index Table） 中以供高效檢索。步驟如下：

1. 文件解析與分塊 — 將 PDF 中的文字和圖片分解為有意義的資料區塊
2. 嵌入 — 使用 CLIP 文字和圖片編碼器將資料區塊轉換為嵌入向量，確保文字和圖片嵌入向量映射到共享嵌入空間
3. 儲存 — 將嵌入後的資料區塊儲存於索引表中以供快速檢索

安全過濾#

安全過濾元件確保使用者請求是安全的且符合系統的準則。這包括在進一步處理之前，檢查查詢是否包含不當或有害內容。更多細節請參考第四章。

查詢擴展（Query Expansion）#

查詢擴展透過擴充使用者的查詢來提升檢索品質，使查詢具有更好的流暢度，並消除拼寫錯誤和文法問題。藉由拓寬搜尋範圍，查詢擴展幫助系統識別原始查詢中未明確提及的額外相關資料。

查詢擴展的技術細節請參考 [37]。

檢索#

檢索元件找出與使用者查詢最相關的資料區塊：

1. 使用 CLIP 文字編碼器將使用者查詢轉換為嵌入向量
2. 使用 ANN 演算法從索引表中高效檢索最相似的資料區塊

生成#

檢索到相關資料區塊後，生成元件透過兩個主要步驟產生最終輸出：

• 提示工程： 將使用者查詢和檢索到的上下文組合為提示詞，並使用 CoT 等技術最佳化以結構化模型的推理過程
• LLM 推論： LLM 使用 top-p 取樣生成最終回應

其他討論主題#

若面試結束時還有時間，可以考慮討論以下額外主題：

• PDF 文件解析中的表格偵測 [38] [39] [40]
• 近似最近鄰演算法的細節 [20] [21] [23] [24]
• 支援使用者上傳文件 [2]
• 動態檢索策略 [41] [42]
• 查詢改寫與擴展 [43] [37]
• 推論時 CoT 與測試時計算擴展 [30] [31]

總結#