Yoru Karu Studio

10-1. N+1 查詢問題（N+1 Query Problem） 📌 什麼是 N+1 查詢問題？ 簡單說： 查詢 N 條數據，卻執行了 N+1 次數據庫查詢 定義： 在查詢主對象時執行 1 次查詢，然後在遍歷時為每個對象的關聯數據又執行 N 次查詢。 🔴 問題演示 場景：查詢所有文章及其作者 # models.py class Author(models.Model): name = models.CharField(max_length=100) email = models.EmailField() class Post(models.Model): title = models.CharField(max_length=200) content = models.TextField() author = models.ForeignKey(Author, on_delete=models.CASCADE) created_at = models.DateTimeField(auto_now_add=True)❌ 有問題的代碼 # views.py def post_list(request): # 查詢所有文章 posts = Post.objects.all() # 第 1 次查詢：SELECT * FROM post # 遍歷文章，獲取作者名稱 for post in posts: print(f"{post.

從 RAG 到 RA-LLM：為什麼需要訓練？ 我們已經知道 RAG（Retrieval-Augmented Generation）的基本原理： Query → Retrieve Documents → Generate Answer但在實際應用中，你可能會遇到這些問題： ❌ 問題 1：檢索器找不到真正相關的文檔 通用的檢索模型對你的領域術語理解不夠 ❌ 問題 2：LLM 不會利用檢索到的資訊 預訓練的 LLM 可能忽略提供的上下文 ❌ 問題 3：檢索器和 LLM 不協調 檢索器找到的資訊，LLM 不知道如何使用 解決方案：RA-LLM Training（檢索增強 LLM 訓練） 本文將深入解析： Sequential Training（順序訓練）的概念 Retriever First（先訓練檢索器）策略 LLMs First（先訓練語言模型）策略 兩種方法的對比與選擇 🎯 什麼是 RA-LLM Training？ 核心概念 RA-LLM = Retrieval-Augmented Large Language Model 不只是在推理時使用檢索（RAG），而是在訓練階段就整合檢索能力。 傳統 RAG（推理時整合）: 預訓練的 Retriever + 預訓練的 LLM ↓ 在推理時組合使用 RA-LLM（訓練時整合）: 訓練 Retriever 和/或 LLM ↓ 讓它們學會協作 ↓ 在推理時更好的配合為什麼需要訓練？ 場景：醫療領域 RAG 系統 問題：「EGFR 突變的靶向治療方案有哪些？」 使用通用模型（未訓練）: ├─ 檢索器：不理解醫療術語 │ └─ 找到：一般性的癌症治療文章 ❌ ├─ LLM：不知道如何利用檢索結果 │ └─ 生成：基於預訓練知識的通用答案 ❌ └─ 結果：答案不準確 使用訓練過的 RA-LLM: ├─ 檢索器：理解醫療術語 │ └─ 找到：EGFR 靶向藥物的具體文獻 ✅ ├─ LLM：知道如何整合檢索資訊 │ └─ 生成：基於文獻的專業答案 ✅ └─ 結果：準確且專業的回答 🔄 Sequential Training（順序訓練） 核心思想 「不同時訓練所有組件，而是按順序逐個訓練」

03-6. XSS 防禦完整指南：輸出編碼、CSP、HttpOnly ⏱️ 閱讀時間： 15 分鐘 🎯 難度： ⭐⭐ (中等) ⚠️ 重要： 本篇是 XSS 系列最重要的一篇！ 🎯 本篇重點 學習如何完全防禦 XSS：輸出編碼（HTML Escape）、Django Template 自動轉義、CSP（Content Security Policy）、HttpOnly Cookie，以及完整的安全檢查清單。 🛡️ 防禦的核心原則 黃金法則 永遠不要信任用戶輸入！ 所有輸出到 HTML 的內容都必須編碼（Escape）為什麼需要輸出編碼？ 沒有編碼（危險）： 用戶輸入：<script>alert('XSS')</script> HTML 輸出：<div><script>alert('XSS')</script></div> 結果：JavaScript 被執行 有編碼（安全）： 用戶輸入：<script>alert('XSS')</script> HTML 輸出：<div>&lt;script&gt;alert('XSS')&lt;/script&gt;</div> 結果：顯示為純文字，不執行 關鍵： < 變成 &lt; > 變成 &gt; 瀏覽器會把 &lt; 顯示為 <，但不會當成 HTML 標籤 1️⃣ 輸出編碼（Output Encoding） HTML 實體編碼 特殊字元 → HTML 實體 < → &lt; > → &gt; & → &amp; " → &quot; ' → &#x27; / → &#x2F;Python 手動編碼 import html # ✅ 手動編碼 def escape_html(text): return html.

一個關鍵問題：如何讓 LLM 知道它不知道的事？ 當你想讓 LLM 回答關於你公司產品、內部文檔或最新資訊的問題時，你有三個選擇： Prompt Engineering（提示工程）：在 prompt 中直接提供資訊 RAG（檢索增強生成）：從知識庫動態檢索相關資訊 Fine-tuning（微調）：直接訓練模型學習新知識 但該如何選擇？Gao+ (2023) 的研究提供了一個清晰的框架來理解這三種方法的權衡。 本文將深入解析： 三種方法的核心差異 外部知識需求 vs 模型調整需求的二維分析 從基礎到進階的演進路徑 實際場景的選擇指南 📊 理解二維座標系統 兩個關鍵維度 根據 Gao+ (2023) 的研究框架，我們可以用兩個維度來評估不同方法： 維度 1：外部知識需求（Y 軸） 高 (High) │ │ 需要大量、頻繁更新的外部知識 │ 例如：最新新聞、公司資料、技術文檔 │ │ 低 (Low) 只需要通用知識或少量特定資訊 例如：常識問答、基礎對話維度 2：模型調整需求（X 軸） 低 (Low) 高 (High) 不需要改變模型行為 需要深度改變模型 例如：偶爾查詢 例如：領域專家、特定風格三種方法的定位 外部知識需求 (Y) ↑ │ 高 │ RAG 區域 │ (動態檢索) │ ▲ │ │ │ │ 中 │ Prompt Engineering │ (提供上下文) │ │ │ │ 低 │ │ │ ▼ │ Fine-tuning 區域 │ (內化知識) │ └──────────────────────→ 低 中 高 模型調整需求 (X) 💡 方法 1：Prompt Engineering（提示工程） 核心概念 「在輸入中直接提供需要的資訊或指導」

03-1. XSS 基礎：什麼是跨站腳本攻擊？ ⏱️ 閱讀時間： 12 分鐘 🎯 難度： ⭐⭐ (中等) ⚠️ 警告： 本文內容僅供學習與防禦用途，禁止用於非法攻擊 🎯 本篇重點 理解 XSS（Cross-Site Scripting）的基本原理、危害程度、三種類型（Reflected、Stored、DOM-based），以及真實案例。 🤔 什麼是 XSS？ XSS（Cross-Site Scripting，跨站腳本攻擊） = 在網頁中注入惡意 JavaScript，當其他用戶瀏覽時執行 一句話解釋： XSS 就像是在公共佈告欄上貼一張「有毒」的海報，任何看到海報的人都會中毒。 為什麼叫 XSS 不叫 CSS？ 原本應該叫 CSS (Cross-Site Scripting) 但 CSS 已經被 Cascading Style Sheets（層疊樣式表）使用 所以改成 XSS（Cross 的 X）技術定義 正常顯示用戶輸入： 用戶輸入：Hello World 網頁顯示：<div>Hello World</div> XSS 攻擊： 用戶輸入：<script>alert('XSS')</script> 網頁顯示：<div><script>alert('XSS')</script></div> ↑ 這段 JavaScript 會被執行！ 結果： 其他用戶瀏覽這個頁面時，會看到彈出視窗 （實際攻擊會竊取 Cookie、重定向等） 🎨 生活中的比喻 情境：公共佈告欄 正常使用： 你：在佈告欄貼「徵室友」海報 其他人：看到海報，聯絡你 XSS 攻擊： 駭客：貼「掃描此 QR Code 領 $1000」海報 QR Code 連到惡意網站 其他人：掃描 QR Code → 手機被植入病毒 關鍵問題： 佈告欄管理員沒有檢查海報內容 讓惡意海報和正常海報混在一起 無法分辨哪些是危險的技術對應 佈告欄 = 網站頁面 海報 = 用戶輸入（留言、個人資料） 看海報 = 瀏覽頁面 海報內容 = HTML/JavaScript 代碼 管理員沒檢查 = 網站沒有輸出編碼 XSS = 在「公共空間」注入惡意內容 讓所有訪客受害 💥 XSS 的危害 危害程度：🔥 高（滿分 5 顆星的 4 顆） 可能後果： 1.

RAG 不只一種：選擇適合的架構 當你開始建立 RAG 系統時，很快會發現「檢索 → 生成」這個簡單流程無法應對所有場景： ❓ 問題 1：第一次檢索的資訊不夠完整怎麼辦？ ❓ 問題 2：複雜問題需要分步驟解決怎麼做？ ❓ 問題 3：如何讓系統自己決定要不要檢索？ 根據 Gao+ (2023) 的研究，RAG 系統可以分為三大類型，每種都針對不同的問題場景設計。 本文將深入解析： Iterative RAG：提供更多上下文資訊 Recursive RAG：逐步拆解複雜問題 Adaptive RAG：靈活控制檢索與生成 🔄 Type 1: Iterative RAG（迭代式 RAG） 核心思想 「如果一次檢索不夠，就多檢索幾次」 基礎 RAG 的問題： Query → Retrieve → Generate → Response ↑ 只檢索一次，資訊可能不足 Iterative RAG 的解決方案： Query → Retrieve → Generate → Judge ↓ ↓ Response ← 迭代 N 次工作流程 步驟 1：Query（問題） 「Django 的部署最佳實踐是什麼？」 步驟 2：Retrieve（檢索） 找到：「Django 需要配置 WSGI 伺服器.