https://yennj12.js.org/yennj12_blog_V4/tags/document-parsing/Recent content in Document Parsing on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 10 Sep 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part2-deepdoc-chunking-zh/Thu, 10 Sep 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part2-deepdoc-chunking-zh/大多數人處理 RAG 的文件解析，是 PyPDF2.extract_text() 加一個 RecursiveCharacterTextSplitter(512, 50)，然後把精力全部投在 prompt 上。 真正的答案是：如果 chunk 是壞的，prompt 再怎麼調都是在補救；而 chunk 的品質，在解析那一步就已經決定了 80%。 「Quality in, quality out」不是口號，它是一個工程順序的宣告。 這篇文章拆的就是 RAGFlow 的「in」。 前言 Part 1 畫完了 RAGFlow 的全景圖。本篇下鑽到 ingestion 路徑的前半段——從一個二進位檔案，到一組準備好被編碼的 chunk。 這一段對應兩個目錄： deepdoc/ 「這份文件長什麼樣子」 ← 視覺與格式理解 ├── vision/ OCR / 版面辨識 / 表格結構辨識（ONNX 模型） └── parser/ 19 個格式解析器 + 外部解析後端接入 rag/app/ 「這份文件該怎麼切」 ← 14 種切分模板 rag/nlp/ 切分契約與分詞（__init__.py 68 KB，delim.py，rag_tokenizer.py） 順序很重要：先理解版面，再決定切法。 反過來就是 naive RAG。 一、核心問題：為什麼「抽文字」不等於「解析」 先看一個具體的失敗案例。一份雙欄排版的論文 PDF，用純文字抽取會得到： Abstract 1. Introduction ← 兩欄的標題被讀成同一行 We propose a novel Recent work ← 左欄句子 + 右欄句子黏在一起 method for in retrieval-augment document ed generation has understanding.