昨天介紹了RAG的基本介紹以及發展。今天會稍微深入去探討它的原理。

複習一下RAG的流程：檢索相關片段→注入上下文→LLM基於上下文生成答案。

下面先看文檔進入知識庫的第一道工序 -- 文件分塊(chunk)，再看檢索器的兩大技術線：稠密嵌入和稀疏嵌入，以及怎麼把兩者結合起來。

文件分塊 Chunking

以上就是RAG的流程，但在能夠檢索前，還有一步不可或缺的離線預處理 -- "分塊(chunking)"：把長文件切成適合獨立檢索的片段(chunk)。
分塊必不可少，原因有二(張員瑛：😅)。
1.嵌入模型對輸入長度有限制，且一整篇文件只壓縮成一個向量時，多個主題混在一起，向量無法精準表達任何一個 -- 段落越長，嵌入越難抓住重點。
2.檢索目標是只把"相關的部分"注入上下文，片段太大會連帶引入大量無關內容，浪費context window以及token、並稀釋注意力。

常見的分塊策略有三：

一、固定大小切分：最簡單的方法，按固定的token數(ex.512)切分，通常在相鄰塊之間保留一定重疊(ex.50~100 token)，避免關鍵句子剛好在邊界處被切斷。實現簡單、可預測，但完全無視文件結構 -- 段落、程式、表格都可能被截斷。

二、遞進式(階層)／結構感知分塊：按文件的自然邊界(文章標題、段落、句子)階層切分 -- 先嘗試按大邊界切塊，仍超長時再降級到更小的邊界。MD、HTML這類有顯示結構的文件尤其合適。這是目前生產系統最常用的默認選擇。

三、語意切分：計算相鄰句子的嵌入相似度，在語意"斷崖處"(相似度驟降的地方)下刀，使每塊內部主題盡量單一。切分品質更高，代價是需要額外的嵌入計算。(你可以想算相似度很多都要用transformer，需要額外的處理)

塊大小與重疊量的選擇是非常重要的權衡：塊太小，訊息不完全，脫離上下文語意會變模糊(ex.該公司收入增加3% -- 哪家公司?/哪一季?);塊太大，一塊混雜多個主題，嵌入向量被稀釋，檢索精度下降，命中後還會帶入更多無關內容。實踐中常見的起點是每塊256~1024token、相鄰塊重疊10%~20%，再根據檢索品質作調參。

同樣分享一個酷酷的repo
GitHub： https://github.com/K-Dense-AI/scientific-agent-skills

Scientific Agent Skills 是一個大型的科研 AI Agent 技能庫，提供 163 個可直接使用的技能，讓通用 coding agent 變成可執行科研流程的「AI co-scientist」。
-把常見科研任務做成可重用 skill（查資料庫、分析、建模、報告）
-CI 與測試規範完整（對有 scripts 的 skill 會要求對應 tests）
-有明確 Security Disclaimer：skills 可能執行程式、連網、改檔，安裝前要審查。