Castle on a Cloud

我們在上一篇文章中介紹了如何有系統地提供問題資訊, 讓 GPT 或是其他 LLM 模型可以更精確地回答, 考慮到 LLM 在各應用中的便利性, 以及其高昂的訓練成本, 透過提示 (prompting) 提升回答精確度的方法, 被廣泛的應用與討論, 其中, 最基本也最廣為人知的也就是 RAG (Retrieval-Augmented Generation). Retrieval-Augmented Generation 於 2020 年由 Facebook AI 提出,  是將生成式模型 (Generative Model) 與檢索模型 (Retrieval Model) 結合的架構. 其設計的核心任務包含了: 解決 LLM 記憶受限問題 (context window 大小限制) 提升回應準確性與可追溯性 (根據外部知識檢索來源回答) 減少 hallucination (幻覺生成) 現象 RAG 的工作流程, 包含了以下的步驟: Query Encoding: 將輸入的問題進行向量化 (embedding), 使用相容的 embedding model 處理 Retrieval: 透過向量相似度搜尋 (vector similarity search) 從外部知識庫檢索最相關的段落 Context Fusion: 將檢索結果與原始 query 進行 prompt engineering，形成完整輸入 Generation: 將結合 context 的 prompt 輸入 LLM, 生成基於外部知識與語言模型推理的答案 來自:  https://medium.com/data-science/retrieval-augmented-generation-rag-from-theory-to-langchain-implementation-4e9bd5f6a4f2 (2,3 併入 Augment 步驟) 和上一篇文章中介紹的 prompting 技術比較, RAG 技術最大的技術特點即是在設計時是針對一個普及的使用. 為了面對多樣不同的查詢, 用以提供範例的資料庫也將十分龐大, 因此, 如何根據當前的資料查詢, 找到相對應的範例就是一個重要的問題. 在 RAG 中使用兩個技術: embedding 將輸入的語意編碼, vecto...

這一系列的文章, 預計會寫個幾篇, 說實話, 這大概連技術文件都說不上, 就是紀錄一些現有熟知的技巧, 在專有名詞部分, 標題的 GPT 其實可借代成任何 LLM (Large Language Model), 這些模型, 以昂貴的訓練成本, 不開源的存取方式稱著, 當然, 他們會收集我們在網頁上的輸入以及反饋,  以免費存取作為代價, 以全人類的資料, 進一步優化這些生財工具, 但是, 對於個人而言, 我們如何客製化一個我們想要的 LLM? 首先, 我們先談談這是否必要? 針對多數的應用中, GPT 或是其他 LLM 其實都已對應大眾使用行為進行調整, 撇開幻覺生成 (Hallucination), 以及過於順從的問題, 在多數的時候, 不論你詢問星座或是 python coding, 他們都可以表現得不錯, 原因無他, 因為在網路上已有大量的相關資料供 LLM 學習. 然而, 若我們考慮一個小範圍且專業的領域呢? 或是, 當我們資訊的提供, 無法以文字或是圖片有效傳達該怎模辦呢? 我們不太可能重新訓練一個 LLM, 而是想借力於一個已經訓練好的 LLM 能力, 針對我們設想的任務優化, 通常來說, 我們有兩種方式可以達成, 分別是: 提示工程 (prompting) 以及模型優化 (fine-tuning). 我們先從最基本的提示工程開始吧! 為了要有一個準確的回答, 首先, 我們需要一個好的問題, 那麼, 一個好的問題需要提供那些資訊呢? 以下是 Gemini 提供的一些指引:  https://ai.google.dev/gemini-api/docs/prompting-strategies 1. 明確的指示（Clear instructions） 使用清楚、具體、直白的語句。 說明任務是什麼、要用什麼格式輸出。 若任務有多步驟，建議拆解並分別列出。 2. 上下文（Context） 提供必要背景資訊（如任務目標、角色、使用者需求）。 可加入範例、定義或限定條件讓模型更準確理解。 3. 角色扮演（Role prompting） 指定模型扮演的角色（例如：「你是資深數據分析師」）。 讓模型以特定觀點或風格作答，提高一致性與專業度。 4. Few-shot 示範（Few-shot prompting） 提供1～3個範例作為輸入與期望輸出格式。 ...