ทำไม PDF ถึงไม่น่ารักกับ AI และการ RAG ด้วย PDF มันวุ่นวายและซับซ้อนขนาดไหน ทำไมผมเททั้งใจให้ Markdown

#เอไอ #ปัญญาประดิษฐ์ #ค้นหาข้อมูลในเอกสารด้วย AI #ขับเคลื่อนด้วย AI #AI อ่านเอกสารให้บริษัท

---

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) ที่ผมสรุปได้จากประสบการณ์นี้:

Architecture

                    ┌──────────────┐
                    │   Document   │
                    │   Ingest     │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │  Direct  │ │  Image   │ │  Image   │
        │  Text    │ │  (Color) │ │  (B&W)   │
        │ Extract  │ │  Render  │ │  Render  │
        └────┬─────┘ └────┬─────┘ └────┬─────┘
             │            │            │
             ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │  Text    │ │  Vision  │ │  Vision  │
        │  Output  │ │  Model   │ │  Model   │
        │          │ │  (Desc)  │ │  (OCR)   │
        └────┬─────┘ └────┬─────┘ └────┬─────┘
             │            │            │
             └────────────┼────────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │  Cross-Validate │
                 │  & Synthesize   │
                 │  (Multi-Model)  │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │  Spell-Check    │
                 │  & Normalize    │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │  Human Review   │
                 │  (Optional)     │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │  Structured     │
                 │  Output → Embed │
                 └─────────────────┘

หัวใจสำคัญของแพทเทิร์นนี้คือ: ไม่มี 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 นี่คือสิ่งที่ผมเรียนรู้มาแบบเจ็บๆ:

1. PDF is a presentation format, not a data format ถ้าคุณ control แหล่งที่มาของเอกสารได้ ให้ผลักดันให้ใช้ Markdown แทน คุณจะตัดปัญหาไปได้เกินครึ่ง

2. Multi-path extraction with cross-validation คือแพทเทิร์นที่จำเป็นถ้าคุณต้อง support PDF จริงๆ อย่าหวังพึ่ง path เดียว เพราะมันจะพังกับ edge case แน่นอน

3. สำหรับภาษาที่ซับซ้อนอย่างภาษาไทย spell-check model คือ must-have ไม่ใช่ nice-to-have OCR และ vision model hallucinate หนักมากกับฟอนต์เฉพาะทางและข้อความบนภาพ

4. 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 ของคุณเองได้เลยนะครับ