สงคราม PDF vs AI แล้วทำไม Markdown ถึงชนะ format เอกสารแบบต่างๆ ได้ขาดลอยแบบไม่ต้องคิดเยอะ
TLDR; ตอนสร้าง RAG pipeline ให้ NEXT4I ผมต้องสร้างระบบ ingest เอกสารที่ซับซ้อน เพราะ PDF มันไม่เป็นมิตรกับ AI เลยสักนิด แต่สำหรับ Markdown ความซับซ้อนหายไปเกินครึ่ง นี่คือแพทเทิร์นที่ผมใช้ และทำไมคุณควรลดความสำคัญกับ PDF ลงถ้าจะ build ระบบที่ให้ AI อ่านเอกสารไปด้วยได้
ตั้งต้น: RAG Pipeline ที่ดูเหมือนจะง่าย แต่ไม่ใช่
ตอนผมสร้าง RAG (Retrieval-Augmented Generation) pipeline ของ NEXT4I กับระบบที่อ่านเอกสารของคุณก่อน แล้วค่อยตอบคำถาม ผมคิดว่า flow มันจะประมาณนี้:
PDF File → Parse Text → Chunk → Embedding → Vector Search → LLM Answer
ง่ายๆ ตรงไปตรงมา ใช่ไหมครับ ?
ไม่ใช่เลย
PDF: ความดีงามสำหรับคนที่อ่าน แต่อาจเป็นฝันร้ายของ AI
เอกสารทดสอบของผมคือ PDF แนะนำการท่องเที่ยวในประเทศไทย ออกแบบสวย ทั้งฟอนต์และภาพ ทั้งการใช้สี layout สวยงาม ตื่นตาตื่นใจ
แต่พอลอง feed เข้า n8n pipeline สิ่งที่เกิดขึ้นคือนรกครับ:
ขั้นตอน
Tool ที่ใช้
ปัญหาที่เจอ
Direct PDF Extraction
PDF parser หลายตัว
ภาษาไทยพัง สระลอย, วรรณยุกต์กระจาย, วรรคตอนหาย, ข้อความบนพื้นหลังสีอ่านไม่ออก เช่น ฟอนต์ไทยมีหัว "ก" "ถ" "ภ"
Render PDF → Image
Page renderer
สีพื้นหลัง ลายน้ำ (watermark) กลบข้อความ
B&W Conversion
Image processor
เสีย context ในรูป กราฟ ตาราง
AI Vision (Color)
Multimodal LLM
อ่านภาพสวยๆ ได้ context แต่สะกดผิดเพียบ
AI Vision (B&W)
Multimodal LLM
อ่านตัวอักษรได้ดีขึ้น แต่ไม่เข้าใจบริบทของภาพ
Cross-Validation
หลายโมเดล + custom logic
แต่ละ path output ไม่เหมือนกัน ต้องสังเคราะห์
Spell-Check
AI spell-checker
ภาษาไทยสังเคราะห์ยาก ต้องใช้ AI อีกตัวตรวจคำผิดวนไป
Human Review
คนจริง
ยังเจอผิด โดยเฉพาะฟอนต์เฉพาะทาง และข้อความบนภาพ
Flow จริงที่ใช้:
PDF File
├─→ PDF Parser → Raw Text (ภาษาไทยพัง)
├─→ Render → Color Images (ภาพสี)
│ └─→ B&W Conversion → High-Contrast Images (ภาพขาวดำ)
├─→ AI Vision Model (Color) → Image Description + OCR
├─→ AI Vision Model (B&W) → Text Extraction
└─→ Cross-Validation Layer
├─→ Multi-Model Synthesis (รวมผลจากทุก path)
├─→ AI Spell-Check (ตรวจคำผิดภาษาไทย)
└─→ Human Review (คนตรวจซ้ำ)
└─→ Structured Output → Chunk → Embed → Search
ใช้ของเยอะมาก เพื่ออะไร ? เพื่อสกัด text จาก PDF ไฟล์เดียวครับ และนี่ยังไม่นับถึงต้นทุนของ Token ที่ใช้ด้วย
สาระสำคัญ (Core Value): ไม่มี extraction path เดียวที่ reliable พอสำหรับ PDF คุณต้องมีหลาย path ที่เป็นอิสระต่อกัน แล้วใช้ cross-validation สังเคราะห์ผลลัพธ์ วิธีคิดเหมือน sensor fusion ครับ: แต่ละ path คือ sensor ที่มี noise และอาจผิดเพี้ยนเพิ่มขึ้นจากอีกจุดไปยังอีกจุด และรวมถึงการ optimize ขั้นตอนเพราะแต่ละขั้นตอนมี cost และ token ที่ต้องจ่าย
แพทเทิร์นทั่วไป: Multi-Path Document Ingestion with Cross-Validation
ถ้าคุณกำลังสร้างระบบที่ต้อง ingest เอกสารแบบใดก็ได้ (arbitrary documents) คุณจะต้องเจอกำแพง PDF แบบนี้แน่ๆ ครับ นี่คือแพทเทิร์นที่นำไปใช้ซ้ำได้ (reusable pattern) ที่ผมสรุปได้จากประสบการณ์นี้: กดดูFlow ที่ลิงค์ด้านล่างได้เลยครับ
หัวใจสำคัญของแพทเทิร์นนี้คือ: ไม่มี extraction path เดียวที่ reliable พอด้วยตัวเอง คุณต้องมีหลาย path ที่เป็นอิสระต่อกันคอยผลิตผลลัพธ์ออกมา แล้วให้ synthesis layer ทำ cross-validate สังเคราะห์ผลรวม เหมือน sensor fusion ครับ และความเพี้ยนของ sensor อาจทวีความผิดเพี้ยนของข้อมูลได้
ทำไม Spell-Check ถึงจำเป็นสำหรับภาษาที่ไม่ใช่อังกฤษ
สำหรับภาษาอังกฤษ คุณอาจข้าม spell-check ไปได้บ้าง แต่สำหรับภาษาไทย ที่วรรณยุกต์ผิดตำแหน่งนิดเดียวก็เปลี่ยนความหมายคำได้ทั้งคำ คุณข้ามขั้นตอนนี้ไม่ได้เด็ดขาด OCR และ vision model มัก hallucinate ตัวอักษรบ่อยมากกับฟอนต์ตกแต่งหรือข้อความที่วางอยู่บนพื้นหลังรูปภาพ การมี language model ที่ fine-tune มาเพื่อตรวจแก้คำผิดโดยเฉพาะ คือความต่างระหว่าง "ใช้งานได้จริง" กับ "ขยะที่อ่านไม่ได้"
จุดเปลี่ยน: Markdown AI-Native Format
แล้วลองคิดดูครับ ถ้าเอกสารชุดนั้นเขียนด้วย Markdown ตั้งแต่แรก:
## สถานที่แนะนำ
| จังหวัด | ไฮไลท์ | ฤดูที่เหมาะ |
|---------|--------|------------|
| กระบี่ | เกาะ | พ.ย.–เม.ย. |
| เชียงใหม่ | ภูเขา | พ.ย.–ก.พ. |
ดู[แผนการเดินทางเต็ม](#itinerary)
```mermaid
graph TD
A[ถึงกรุงเทพ] --> B[บินไปกระบี่]
B --> C[เที่ยวเกาะ]
C --> D[กลับ]
AI อ่านปุ๊บ เข้าใจทันทีครับ:
## = หัวข้อ → ไม่ต้องเดาจากฟอนต์หรือขนาดตัวอักษร
| column | = ตาราง → ไม่ต้อง OCR reconstruct จาก pixel
Mermaid diagram → parse ได้ทันที ไม่ต้อง vision model มานั่งตีความภาพ
Code block → ชัดเจน ไม่ต้อง infer จาก monospace font
Flow ใหม่ที่ใช้กับ Markdown:
Markdown File → Parse → Chunk → Embed → Search
แค่นั้นครับ ขั้นตอนเดียว ไม่ต้อง OCR, ไม่ต้อง vision model, ไม่ต้อง B&W conversion, ไม่ต้อง cross-validation, ไม่ต้อง spell-check, ไม่ต้อง human review เพื่อแก้ error จาก format
"แต่ในความเป็นจริง เราไม่สามารถเลือกเอกสารที่จะนำเข้ามาได้ และเลี่ยงที่จะไม่ใช้ไฟล์นั้นไม่ได้ เพราะอาจจะมีข้อมูลสำคัญอยู่ แต่ถ้าต้องเริ่มต้นใหม่ ยังไง markdown คือตัวเลือกหลัก"
บทเรียนสำหรับ Dev สาย RAG
ถ้าคุณกำลังสร้างระบบ document ingestion หรือ RAG pipeline นี่คือสิ่งที่ผมเรียนรู้มาแบบเจ็บๆ:
PDF is a presentation format, not a data format ถ้าคุณ control แหล่งที่มาของเอกสารได้ ให้ผลักดันให้ใช้ Markdown แทน คุณจะตัดปัญหาไปได้เกินครึ่ง
Multi-path extraction with cross-validation คือแพทเทิร์นที่จำเป็นถ้าคุณต้อง support PDF จริงๆ อย่าหวังพึ่ง path เดียว เพราะมันจะพังกับ edge case แน่นอน
สำหรับภาษาที่ซับซ้อนอย่างภาษาไทย spell-check model คือ must-have ไม่ใช่ nice-to-have OCR และ vision model hallucinate หนักมากกับฟอนต์เฉพาะทางและข้อความบนภาพ
Mermaid diagram ใน Markdown คืออาวุธลับ AI parse ได้ทันที ไม่ต้องเสียเวลา OCR แผนภาพจาก PDF แล้วมานั่งตีความใหม่
ทำไมถึงสำคัญกับสถาปัตยกรรมของ NEXT4I
ที่ NEXT4I เราสร้างระบบให้ผู้ใช้งานทั่วไปและองค์กร สามารถคุยกับข้อมูลของตัวเองด้วย AI ทุกอย่างถูกออกแบบโดยยึดหลัก AI Integration by Design ครับ คือออกแบบโดยคิดถึง AI เป็น first-class citizen ตั้งแต่แรก ไม่ใช่แค่ของที่ทำมาเพิ่มทีหลัง
Markdown ไม่ใช่แค่ "อีกหนึ่ง format ที่ support" มันคือ backbone ของ content architecture เราครับ เพราะเราเรียนรู้มาแล้วว่า: format ที่คุณเลือกวันนี้ กำหนด ceiling ของสิ่งที่ AI จะทำได้ในวันพรุ่งนี้
ขอบคุณทุกท่านที่อ่านมาจนถึงตรงนี้ สำหรับ flow ที่ผมได้แชร์ไว้ สามารถเอาไปปรับใช้กับ pipeline ของคุณเองได้เลยนะครับ
ติดตามการเดินทางของ NEXT4I และบทความต้นฉบับได้ที่: {{NEXT4I_LINK_EN}}
เรากำลังสร้าง NEXT4I ให้เป็น AI-Native Ecosystem หากคุณสนใจ ลงทะเบียนล่วงหน้าได้ที่: {{WAITLIST_LINK}}
Raw Notes (for reference)
ในยุค AI File .md (Markdown file) คือที่สุด ทำไมผมถึงคิดแบบนั้น เพราะว่า คุณสามารถสร้าง pdf file, document file ที่ถูกต้อง กี่ไฟล์ กี่สไตล์ ก็ได้ ถ้าคุณ เขียน Markdown file ไว้ดี เพราะ AI จะสามารถ สร้างสรรค์ file ใหม่เอกสารใหม่ ได้จาก Markdown file ที่คุณเขียนมาดีพอ แค่ไฟล์เดียว ผมจึงมองว่า นี่คือเหตุผลที่ทำให้ความสำคัญ และประทับใจตรงที่ว่า แค่เราเขียนไฟล์ text ธรรมดาๆ AI ก็เข้าใจเราได้ ทำให้ผมเข้าใจเลยว่า สุดท้ายเราก็แค่โฟกัสกับการเขียนให้ครบถ้วนรอบคอบเท่านั้นเอง
ลองนึกภาพแบบนี้นะครับ สมมติคุณมีหนังสือสักเล่มที่ตัวอักษรเล็กมาก กระดาษบางจนเห็นตัวอักษรอีกหน้าทะลุ สีพื้นหลังก็จัดจ้านบาดตา เวลาคุณเปิดให้เพื่อนอ่าน เพื่อนคุณคงต้องใช้เวลาอ่านนานกว่าปกติมาก เพราะต้องคอยเพ่ง ไหนจะฟอนต์ที่เยอะแยะ บางตัวแยก "O" (โอ) กับ "0" (ศูนย์) หรือ "S" กับ "5" ไม่ออกด้วยซ้ำ
ยิ่งภาษาไทย หรือภาษาที่ลักษณะอักษรพยัญชนะซับซ้อนกว่านี้ไม่ต้องพูดถึง ไหนจะแยกแยะตัวอักษรออกจากพื้นหลัง กลับหน้ากระดาษไปมา บางทีไม่แน่ใจว่าตัวอักษรนั้นแล้วตัวหนาหรือตัวธรรมดา ยังต้องเดาอีกว่าตรงนี้คือหัวข้อหรือเปล่า? นี่คือสิ่งที่เราเจอตอนอ่าน PDF และก็เป็นสิ่งที่ AI เจอเหมือนกันเวลาสรุป PDF ของเราครับ
ผมมี use-case นึงที่จะแชร์ ผมกำลังทดลองสร้าง RAG Pipeline ที่ทำงานบนเอกสารที่ซับซ้อน เพื่อเป็นตัวตั้งต้นของระบบ ในการใช้ AI ในการค้นหาคำตอบ จากเอกสาร สำหรับ user หรือแม้แต่ในองค์กร Retrieval-Augmented Generation พูดง่ายๆ คือระบบที่ อ่านเอกสารของคุณก่อน แล้วค่อยตอบคำถามจากข้อมูลที่เพิ่งอ่านไป แทนที่จะเดาจากข้อมูลที่มันเคยถูกเทรนมาเท่านั้น
ดังนั้น เมื่อเรา RAG เอกสารเฉพาะของเราไปแล้ว AI จะตอบได้เฉพาะเจาะจงกับเอกสารนั้น ฟังดูแล้วเหมือนเทรน AI ใช่ไหม แต่จริงๆแล้วไม่ใช่นะ แค่ฟังดูเหมือนจะคล้ายกันเฉยๆ (ตัวอย่างเช่น เอกสาร ยอดขายของคุณ ชื่อสถานที่ท่องเที่ยวที่คุณชอบ คุณไม่สามารถเปิด ChatGPT แล้วถาม AI แล้วจะรู้ข้อมูลพวกนั้นของคุณได้) เทคนิคนี้เป็นหัวใจของระบบที่ใช้ AI ในการค้นหาคำตอบ จากเอกสารของคุณ แทบทุกเจ้าในตลาดตอนนี้
เอกสารทดสอบของผมคือ PDF แนะนำการท่องเที่ยวในประเทศไทย คือ pdf ที่ทำมาสวยมาก ออกแบบอย่างมืออาชีพ ภาพสวย ฟอนต์ไทยสวย เลย์เอาต์เนี้ยบกริบ ใครเปิดดูก็ต้องชมว่าสวย
แต่สำหรับ Pipeline บน n8n ของผม? มันคือนรกชัดๆ ไม่ต้องถึงกับภาษาไทยที่มีหัว เช่น "ก" หรือ "ถ" ภาษาอังกฤษยังยากเลย (ผมพูดเลยว่า โหดสุดๆ สามารถไปดู ตัวอย่างได้ที่ website https://www.tat.or.th/document-publications/e-brochures)
อย่างแรก ผมใช้เครื่องมืออ่าน PDF ซึ่งมีปัญหาอย่างหนักกับภาษาไทย ข้อความภาษาไทยบนพื้นหลังสีสันสดใส มีลายน้ำ มีรูปประกอบ ข้อความที่สกัดออกมาได้กระจัดกระจาย วรรคตอนหาย สระลอย เครื่องหมายวรรณยุกต์อยู่ผิดตำแหน่งไปหมด ต้องลองและเปลี่ยนอยู่หลายตัว ใช้ AI model เฉพาะก็แล้ว
ยังไม่พอครับ ผมต้องใช้เครื่องมืออีกตัว Render หน้า PDF เหล่านั้นออกมาเป็นรูปภาพ แล้วจับมันแปลงเป็นภาพขาวดำเพื่อให้ตัวอักษรชัดขึ้น เพราะบางทีสีพื้นหลังมันกลบข้อความจนอ่านแทบไม่ออก แล้วก็ใช้ AI Model สรุปเนื้อหาจากภาพพวกนั้น ทั้งภาพสีต้นฉบับ และภาพขาวดำที่แปลงแล้ว
ยังมีอีกนะ บางเอกสารมีตัวใหญ่ขึ้นย่อหน้า ที่กินไป 2 บรรทัดก็มีปัญหา หรือ บางอย่างที่ใช้รูปอธิบายแทน หรือ ต้องใช้ AI ช่วยดูรูปแล้ววิเคราะห์ เช่นภาพทะเลสีฟ้าสวยที่มีเกาะงดงามในภาคใต้ของไทย หรือกราฟต่างๆ ตารางต่างๆ
ยังไม่จบแค่นั้น ผมต้องใช้ Model หลายๆ ตัวตรวจสอบผลลัพธ์ทั้งหมดที่ได้จากทุกขั้นตอน ตั้งแต่ข้อความที่มาจากภาพสี ภาพขาวดำ การสกัดจาก PDF โดยตรง และจากคำบรรยายภาพ เพื่อ Cross-check และสังเคราะห์จนได้เนื้อหาที่แม่นยำที่สุดเท่าที่จะเป็นไปได้
แล้วผมก็ต้องให้คนมาตรวจทานอีกชั้น และเจอคำสะกดผิดเพียบเลยครับ เพราะภาษาไทยนี่สังเคราะห์ได้ยากจริงๆ โดยเฉพาะข้อความที่อยู่บนรูป หรือใช้ฟอนต์เฉพาะทาง ตัวอักษรบางตัวอ่านยากมาก
ผมเลยต้องใช้ AI Model อีกตัวมาช่วยตรวจคำผิด วนไปวนมาจนกว่าจะได้เนื้อหาที่ถูกต้อง ...ซึ่ง ผมก็ยอมรับตามตรงครับว่า ก็ไม่ได้ถูกต้องครบถ้วน และต้องใช้คนมาแก้ให้สมบูรณ์
แต่ถ้าจะพูดไปตามเนื้อเอกสาร ก็ต้องยอมรับว่า ไฟล์เหล่านี้ผู้ทำเขาเน้นให้คนมาอ่าน มากกว่าที่จะให้ AI เข้าใจ ผมควรจะหา source จากที่อื่นมาใช้แทน แต่... ผมก็จะเสีย source หรือ content ที่มีค่าชุดนี้ไป
แต่ถึงกระนั้นแล้ว ถ้าเป็นสมัยนี้ AI เก่งขึ้นมาก ก็อาจจะทำได้ง่ายขึ้นและถูกต้องมากขึ้น แต่ก็นั่นแหล่ะครับ นี่คือตัวอย่างความลำบากยากเข็ญ ในการสังเคราะห์เอกสารที่เป็น pdf แต่ถ้าเป็น Markdown file มันจะเปลี่ยนทันทีครับ ตาราง หรือ flow ใน markdown (อาจจะเป็น Mermaid diagram https://mermaid.js.org/) ถ้าคุณเห็น syntax ที่ใช้จะรู้เลยว่า คนอย่างเราๆ ยังพอจะเข้าใจได้ และแน่นอน AI เข้าใจทันทีเลย นี่แหล่ะครับ พลังของ Markdown file
ดูเพิ่มเติมในซีรีส์
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
