Yoru Karu Studio

前言 在多線程環境中，如何讓每個線程擁有自己獨立的資料副本？這是一個經典的並發編程問題。 想像一個實際場景： # ❌ 全局變量會被所有線程共享 current_user = None def process_request(request): global current_user current_user = request.user # 線程 A 設置 do_some_work() # 在這期間，線程 B 可能修改 current_user！ send_email(current_user) # 可能發給錯誤的用戶！問題： 線程 A 處理用戶 Alice 的請求 線程 B 同時處理用戶 Bob 的請求 兩個線程共享同一個 current_user 變量 結果：Alice 的郵件可能發給 Bob！ 解決方案：使用 threading.local # ✅ 每個線程有自己的 current_user thread_local = threading.local() def process_request(request): thread_local.current_user = request.user # 線程隔離 do_some_work() # 其他線程不會影響 send_email(thread_local.current_user) # 安全！這篇文章將深入探討 threading.local 的實現原理，以及 Django 如何利用它保證線程安全。

為什麼 RAG 是 LLM 時代的必備技術？ 想像大語言模型（LLM）是一位擁有淵博知識的頂尖學者。 預訓練就像這位學者在學校裡閱讀了數萬本書，形成了強大的語言能力和世界觀。 然而，他參加的是閉卷考試（直接提問 LLM）：他無法回憶起所有細節，容易遺忘最近發生的事，也無法參考他從未讀過的公司內部文件。 RAG的作用，就是將閉卷考試變為開卷考試。當問題出現時，先讓他迅速查閱相關的參考資料，然後根據手邊的文件作答，確保答案的準確性和時效性。 理解 RAG，是從「玩轉」LLM 提升到「應用」LLM 解決實際業務問題的關鍵。 🧠 LLM 的三大知識困境 在沒有 RAG 之前，直接使用預訓練 LLM 進行問答，面臨三大挑戰： 1. 幻覺（Hallucination） 當模型被問到一個它不確定的細節時，它傾向於編造聽起來合理但事實上錯誤的資訊。這源於其訓練目標是「產生最可能的下一個詞」，而非「產生事實準確的詞」。 2. 知識過時（Knowledge Staleness） LLM 的知識截止日期是其最後一次預訓練的時間點。對於訓練之後發生的新事件、最新財報、或法規變動，LLM 無法獲知。 範例：你問 2024 年的模型誰贏得了 2025 年的奧斯卡獎，它會根據過去的資訊來猜測或給出過時的答案。 3. 知識隔離（Knowledge Isolation） LLM 無法存取你的專屬領域知識，例如公司的產品手冊、內部郵件、私有程式碼文件或未公開的研究報告。若要讓 LLM 基於這些文件回答，傳統方法成本過高。 🔎 RAG（檢索增強生成）是什麼？ RAG 是一種將檢索系統 (Retriever) 和 生成模型 (Generator) 結合的技術，其目標是：在 LLM 生成回覆之前，先從外部知識庫中檢索相關的片段（Context），然後將這些片段作為提示詞的一部分輸入給 LLM，引導模型生成基於事實的答案。 RAG 的核心：將答案的依據外部化 特性 傳統 LLM（閉卷） RAG LLM（開卷） 知識來源 模型參數（記憶） 外部知識庫（參考資料） 問答流程 問句 → 直接生成答案 問句 → 檢索相關資料 → 根據資料生成答案 知識更新 需重新訓練或微調模型 只需更新外部資料庫 準確性 依賴記憶，易產生幻覺 基於事實，準確性高 📐 RAG 的標準架構流程 RAG 系統分為兩個主要階段：索引階段（預處理）和運行階段（問答）。