https://yennj12.js.org/yennj12_blog_V4/tags/semantic-chunking/Recent content in Semantic Chunking on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part1-chunking-retrieval-zh/Tue, 30 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part1-chunking-retrieval-zh/多數 RAG 教學的做法：把文件每 1000 字切一刀，丟進向量資料庫，cosine 相似度 top-k 撈回來。 但實務上 80% 的爛答案，不是 LLM 不夠強，而是「切錯地方」或「撈錯段落」。 chatPDF 這次的優化，核心就兩件事：讓切塊跟著「語意」走，讓檢索同時懂「語意」和「字面」。 一、為什麼切塊與檢索是 RAG 的命門 一個 RAG 系統的流程很單純： PDF ──▶ 切塊(Chunking) ──▶ 向量化 ──▶ 檢索(Retrieval) ──▶ LLM 生成 ▲ ▲ │ │ 決定「知識的最小單位」 決定「撈回哪些單位」 LLM 生成是最後一步，但它能講什麼，完全取決於前面撈回了什麼。而撈回什麼，又取決於當初怎麼切。所以這條鏈裡，切塊與檢索才是真正的瓶頸——它們決定了 LLM 能「看到」的內容。 chatPDF 原本的問題很典型： 切塊是寫死的:不管 RAGConfig 設定什麼,都用固定字數硬切。一個句子、一張表、一段論證,常常被攔腰切斷。 檢索只有 dense 一種:純向量相似度。遇到「精確關鍵字」(產品型號、縮寫、法條編號)時,語意向量反而抓不準。 PR #1 就是針對這兩點:Semantic Chunking 與 Hybrid Retrieval。 二、固定切塊的問題:把意思切碎了 固定切塊(fixed-size chunking)是這樣的: 原文: "本季營收成長 18%。主因是雲端業務擴張。│ 另一方面,匯率造成 切在這 ▲ 3% 的逆風。展望下季,管理層預期..." 問題在於:它在「字數到了」就切,完全不管那裡是不是一個語意邊界。結果常常: 把一個完整論點切成兩半 → 兩個 chunk 都殘缺,檢索時誰都撈不全 把兩個無關主題塞進同一塊 → 向量被「平均」掉,語意模糊 固定切塊的失敗模式 ────────────────────────────────── chunk A: ".