เตรียมเอกสารก่อนทำ RAG: ทำไมไฟล์สวย ๆ ถึงใช้ไม่ได้ และวิธีเช็กใน 5 วินาที

ถ้าคุณกำลังจะทำระบบ AI ถามตอบจากคู่มือหรือเอกสารภายในของบริษัท มีงานหนึ่งที่ต้องทำก่อนแตะเรื่องโมเดลหรือ vector database เลย นั่นคือ ทำให้เอกสารของคุณกลายเป็นข้อความจริง ๆ ก่อน เพราะระบบค้นคืนข้อมูลทุกตัวในโลกนี้อ่านได้แค่ข้อความ ไม่ได้อ่านรูป และไฟล์ที่คนส่วนใหญ่มีอยู่ในมือ (คู่มือเครื่องจักร ระเบียบบริษัท สัญญาที่เซ็นแล้วสแกนเก็บ) จำนวนมากเป็น “รูปภาพที่อยู่ในไฟล์ PDF” ไม่ใช่ข้อความ คนที่ข้ามขั้นนี้มักจบลงที่ระบบซึ่งตอบว่า “ไม่พบข้อมูล” กับทุกคำถาม แล้วเข้าใจผิดว่าโมเดลไม่เก่งพอ

สรุปสั้น ๆ: PDF สองไฟล์ที่หน้าตาเหมือนกันเป๊ะบนหน้าจอ อาจเป็นคนละชนิดกันโดยสิ้นเชิง ไฟล์หนึ่งมีข้อความอยู่ข้างใน อีกไฟล์เป็นแค่รูปถ่ายกระดาษ วิธีแยกใช้เวลา 5 วินาที (ลากคลุมข้อความดู) ถ้าเป็นรูป ต้องทำ OCR ก่อน และ OCR ภาษาไทยยากกว่าภาษาอังกฤษอย่างมีนัยสำคัญ เพราะสระและวรรณยุกต์ซ้อนกันหลายชั้น ปี 2026 มีทางเลือกที่ดีขึ้นมากและรันในเครื่องตัวเองได้ ไม่ต้องอัปเอกสารขึ้นเว็บแปลงไฟล์

ปัญหาไม่ได้อยู่ที่ AI แต่อยู่ที่ไฟล์

PDF ไม่ใช่รูปแบบไฟล์แบบเดียว มันเป็นกล่องที่ใส่ของได้สองอย่าง และสองอย่างนี้ต่างกันคนละโลกสำหรับงาน AI

PDF ข้อความ คือไฟล์ที่ถูกสร้างจากโปรแกรมโดยตรง เช่น Save as PDF จาก Word, export จากระบบบัญชี หรือใบเสร็จที่ระบบออกให้ ข้างในมีตัวอักษรจริง ๆ พร้อมพิกัดว่าตัวไหนอยู่ตรงไหน โปรแกรมอ่านออกทันที

PDF ภาพ คือไฟล์ที่ได้จากเครื่องสแกน เครื่องถ่ายเอกสาร หรือการถ่ายรูปหน้ากระดาษด้วยมือถือ ข้างในไม่มีตัวอักษรเลยแม้แต่ตัวเดียว มีแค่รูปภาพของหน้ากระดาษวางเรียงกัน สายตาคนอ่านออกสบาย แต่คอมพิวเตอร์เห็นเป็นแค่จุดสีเรียงกัน

ความน่าปวดหัวคือ บนหน้าจอทั้งสองแบบดูเหมือนกันทุกประการ เปิดด้วยโปรแกรมเดียวกัน เลื่อนดูได้เหมือนกัน สั่งพิมพ์ได้เหมือนกัน หลายคนจึงเตรียมโฟลเดอร์เอกสารไว้อย่างดี 200 ไฟล์ ต่อระบบเสร็จ แล้วมาเจอตอนท้ายว่าระบบ index ได้ศูนย์คำ

ทุก pipeline ของ RAG ไม่ว่าจะออกแบบซับซ้อนแค่ไหน เริ่มต้นด้วยขั้นเดียวกันเสมอคือ “อ่านไฟล์ออกมาเป็นข้อความ” ถ้าขั้นนี้ได้ข้อความเปล่า ทุกขั้นหลังจากนั้นก็ทำงานบนความว่างเปล่าตามไปด้วย

คุณภาพของคำตอบสูงสุดเท่าที่ระบบจะทำได้ ถูกล็อกไว้แล้วตั้งแต่ขั้นแปลงไฟล์ ไม่มีโมเดลตัวไหนกู้ข้อความที่ไม่เคยถูกอ่านออกมาได้

เช็ก 5 วินาทีว่าไฟล์คุณเป็นแบบไหน

เปิดไฟล์ PDF ขึ้นมา แล้วลากเมาส์คลุมข้อความบนหน้าจอ

• ถ้าลากแล้วมีแถบสีคลุมตัวอักษรเป็นบรรทัด ก็อปวางไปที่ Notepad แล้วได้ข้อความออกมา แปลว่าเป็น PDF ข้อความ ผ่าน
• ถ้าลากแล้วได้กรอบสี่เหลี่ยมคลุมทั้งหน้าเหมือนเลือกรูป หรือคลุมไม่ติดเลย แปลว่าเป็น PDF ภาพ ต้อง OCR ก่อน

อีกวิธีที่เร็วพอกันคือกด Ctrl+F แล้วพิมพ์คำที่คุณเห็นอยู่ตรงหน้าจอชัด ๆ ถ้าหาไม่เจอ แปลว่าไฟล์นั้นไม่มีข้อความให้หา

ถ้าทำงานกับไฟล์จำนวนมากและอยากเช็กทีเดียวหลายสิบไฟล์ ใช้เครื่องมือบรรทัดคำสั่งจากชุด poppler ได้ คำสั่ง pdftotext ไฟล์.pdf - จะพ่นข้อความในไฟล์ออกมาที่หน้าจอ ถ้าพ่นออกมาว่างเปล่าหรือได้แต่เลขหน้า นั่นคือไฟล์ภาพ เขียนวนลูปเช็กทั้งโฟลเดอร์แล้วแยกกองได้ในไม่กี่นาที

มีอีกกรณีที่หลุดบ่อยและอันตรายกว่าสองแบบแรก คือ ไฟล์ผสม เช่น สัญญาที่พิมพ์จากคอมแต่หน้าสุดท้ายเป็นหน้าที่เซ็นแล้วสแกนกลับเข้ามา หรือคู่มือที่แทรกภาพถ่ายหน้าคู่มือรุ่นเก่าไว้กลางเล่ม ไฟล์แบบนี้จะผ่านการเช็กด้วยหน้าแรกสบายมาก แต่เนื้อหาสำคัญบางส่วนหายไปเงียบ ๆ ตอน index วิธีกันคือสุ่มเช็กหน้ากลางและหน้าท้ายด้วย ไม่ใช่เช็กแค่หน้าแรก

เส้นทางตามชนิดไฟล์ และเป้าหมายที่ไม่ใช่แค่ได้ตัวอักษร

เมื่อรู้ว่าไฟล์เป็นแบบไหนแล้ว เส้นทางต่อไปมีไม่กี่เส้น

• PDF ข้อความ — ดึงข้อความออกมาตรง ๆ ด้วย pdftotext หรือ PyMuPDF ระวังเอกสารสองคอลัมน์ เพราะเครื่องมือพื้นฐานมักอ่านพาดขวางหน้าจนสองคอลัมน์ปนกันเป็นประโยคเดียว และระวังหัวกระดาษกับท้ายกระดาษที่จะถูกดึงมาซ้ำทุกหน้า
• Word, PowerPoint, HTML — แปลงเป็นข้อความหรือ Markdown ได้ตรงไปตรงมา งานหลักคือรักษาหัวข้อไว้ให้ครบ
• PDF ภาพและรูปถ่าย — ต้องผ่าน OCR ก่อน ไม่มีทางลัด
• ไฟล์สแกนที่เอียง มืด หรือถ่ายด้วยมือถือ — ปรับให้ตรงและเพิ่มความคมชัดก่อนเข้า OCR ผลต่างเยอะกว่าที่คิด

จุดที่หลายคนพลาดคือคิดว่าเป้าหมายของขั้นนี้คือ “ให้ได้ตัวอักษรออกมา” ซึ่งจริง ๆ แล้วเป้าหมายคือ ได้ตัวอักษรพร้อมโครงสร้าง ข้อความก้อนเดียวยาวเหยียดที่ไม่เหลือร่องรอยว่าอะไรเป็นหัวข้อ อะไรเป็นตาราง อะไรเป็นเชิงอรรถ จะทำให้ขั้นตัด chunk หลังจากนี้ทำงานได้แย่ลงมาก

ปี 2026 มีเครื่องมือโอเพนซอร์สที่ออกแบบมาเพื่อเรื่องนี้โดยเฉพาะ คือคืนผลเป็น Markdown ที่ยังมีหัวข้อและตารางติดมาด้วย แทนที่จะเป็นข้อความแบน ๆ

• Docling — เริ่มต้นจากทีมวิจัยของ IBM (MIT license) แปลงเอกสารเป็นโครงสร้างที่เก็บลำดับการอ่าน ขอบเขตช่องตาราง และตำแหน่งรูปไว้ ต่อเข้ากับ framework ฝั่ง RAG ได้ตรง ๆ
• Marker — จาก Datalab แปลง PDF, Office และ EPUB เป็น Markdown, JSON หรือ HTML คุณภาพดี ตัวโค้ดเป็น Apache 2.0 ใช้เชิงพาณิชย์ได้ แต่ weight ของโมเดลใช้ license คนละตัว (AI Pubs Open Rail-M ที่แก้ไขแล้ว ฟรีสำหรับงานวิจัย งานส่วนตัว และบริษัทที่ทุนหรือรายได้ต่ำกว่า 5 ล้านดอลลาร์) องค์กรใหญ่กว่านั้นต้องคุยเรื่อง license แยก

OCR ภาษาไทยยากกว่าอังกฤษ ต้องตั้งความคาดหวังให้ถูก

นี่คือหัวข้อที่ tutorial ภาษาอังกฤษไม่เคยเตือน และเป็นจุดที่คนทำเอกสารไทยเสียเวลาไปมากที่สุด

ภาษาไทยเขียนซ้อนกันได้ถึงสี่ชั้นในบรรทัดเดียว ทั้งสระบน วรรณยุกต์ที่วางทับสระอีกที ตัวพยัญชนะ และสระล่าง เครื่องมือ OCR ที่ออกแบบมาสำหรับภาษาที่เขียนเรียงกันเป็นแถวเดียวจึงสับสนได้ง่ายมาก โดยเฉพาะตอนที่วรรณยุกต์ตัวเล็ก ๆ อยู่ใกล้ขอบบรรทัดหรือสแกนมาไม่คม ผลที่ได้บ่อยคืออ่านตัวอักษรถูกแต่วรรณยุกต์หาย ซึ่งเปลี่ยนความหมายของคำไปเลย

เส้นทางที่ใช้ได้จริงตอนนี้มีสองสาย

สายคลาสสิก คือ OCRmyPDF ที่ทำงานร่วมกับ Tesseract จุดเด่นคือมันไม่ได้แค่พ่นข้อความออกมา แต่ใส่ชั้นข้อความกลับเข้าไปในไฟล์ PDF ใบเดิม ทำให้ไฟล์เดิมค้นหาและก็อปข้อความได้โดยที่หน้าตายังเหมือนเดิมทุกอย่าง คำสั่งพื้นฐานคือ ocrmypdf -l tha+eng input.pdf output.pdf โดยต้องติดตั้งชุดภาษาไทยของ Tesseract เพิ่มก่อน และการใส่ทั้ง tha+eng สำคัญกับเอกสารไทยเกือบทุกฉบับ เพราะมักมีศัพท์เทคนิคหรือชื่อรุ่นเป็นภาษาอังกฤษปนอยู่เสมอ

สายใหม่ปี 2026 คือใช้โมเดลภาษาที่มองภาพได้มาอ่านเอกสารแทน ซึ่งเข้าใจโครงหน้ากระดาษไปพร้อมกับอ่านตัวอักษร ที่น่าสนใจสำหรับคนไทยเป็นพิเศษคือ Typhoon OCR จาก SCB 10X ซึ่งเป็นโมเดลที่ตั้งใจทำมาเพื่อเอกสารไทยและอังกฤษโดยเฉพาะ คืนผลเป็น Markdown หรือ HTML ที่เก็บตารางไว้ได้ และเปิดโค้ดไว้ภายใต้ Apache 2.0 (เช็ก license ของ checkpoint แต่ละตัวแยกอีกที) เวอร์ชัน 1.5 ขนาด 3B ดึงผ่าน Ollama ได้ตรง ๆ ด้วยคำสั่ง ollama run scb10x/typhoon-ocr1.5-3b ไฟล์ราว 3.2GB เล็กพอที่เครื่องโน้ตบุ๊กทั่วไปรันไหว

⚠️ อย่าเผลอใช้เว็บแปลงไฟล์ฟรี ถ้าเหตุผลที่คุณเลือกรัน AI ในเครื่องตั้งแต่แรกคือ “เอกสารห้ามออกจากองค์กร” การอัปคู่มือหรือสัญญาขึ้นเว็บ OCR ออนไลน์ก็คือการส่งเอกสารทั้งฉบับออกไปแล้ว คือรั่วตั้งแต่ก่อนเริ่มทำระบบ ทั้ง OCRmyPDF และ Typhoon OCR ทำงานในเครื่องได้ทั้งคู่ ไม่มีเหตุผลต้องแลกความเป็นส่วนตัวกับความสะดวก

จุดที่ OCR เพี้ยนบ่อยที่สุดมีอยู่ไม่กี่ที่ รู้ไว้ก่อนจะประหยัดเวลาไล่หาสาเหตุได้มาก ตาราง มักถูกอ่านเป็นข้อความเรียงต่อกันจนตัวเลขหลุดคอลัมน์ ตัวเลขและรหัส อย่างเลขที่สัญญาหรือ part number สลับกันได้ง่ายระหว่างเลขศูนย์กับตัวโอ เลขหนึ่งกับตัวแอล ไดอะแกรมและภาพประกอบ หายไปทั้งอันโดยไม่มีร่องรอย และ ลายเซ็นหรือตราปั๊มที่ทับข้อความ ทำให้บรรทัดนั้นอ่านไม่ออก วิธีที่คุ้มที่สุดคือ OCR แค่ 3 หน้าก่อน (หน้าที่มีตาราง หน้าที่มีตัวเลขเยอะ และหน้าเนื้อความธรรมดา) เปิดดูผลด้วยตาจริง แล้วค่อยตัดสินใจว่าจะรันทั้งเล่มหรือเปลี่ยนเครื่องมือ

ผ่าน OCR แล้วยังพังได้อีกรอบ ตอนตัด chunk

สมมติว่าคุณได้ข้อความสะอาดออกมาแล้ว ยังมีกับดักภาษาไทยรออยู่อีกด่านหนึ่ง

ขั้นตอนถัดไปของ RAG คือหั่นข้อความยาวเป็นท่อนเล็ก ๆ (chunk) ก่อนแปลงเป็นเวกเตอร์ และวิธีหั่นที่ tutorial ส่วนใหญ่สอนคือ “ตัดทุก ๆ 500 ตัวอักษร” ซึ่งใช้กับภาษาอังกฤษได้เพราะมีช่องว่างระหว่างคำให้เห็นขอบชัด แต่ภาษาไทยไม่มีช่องว่างระหว่างคำและไม่มีเครื่องหมายจบประโยคที่ชัดเจน การนับตัวอักษรแล้วตัดจึงมีโอกาสตัดกลางคำ กลางชื่อบริษัท หรือกลางเลขที่เอกสาร ทำให้ความหมายของ chunk นั้นเพี้ยนไปทั้งชิ้น

ทางที่ปลอดภัยกว่าคือตัดที่ขอบย่อหน้าหรือบรรทัดว่าง ซึ่งเป็นขอบที่มีความหมายจริงในเอกสาร หรือถ้าต้องการละเอียดกว่านั้นก็ใช้ไลบรารีตัดคำภาษาไทยอย่าง PyThaiNLP ช่วยก่อน และนี่เป็นอีกเหตุผลที่การรักษาโครงสร้างเอกสารไว้ตั้งแต่ขั้นแปลงไฟล์คุ้มค่ามาก เพราะถ้ายังรู้ว่าตรงไหนเป็นหัวข้อและตรงไหนเป็นย่อหน้า คุณมีขอบที่ดีให้ตัดตั้งแต่ต้น

อีกจุดคือโมเดลที่ใช้แปลงข้อความเป็นเวกเตอร์ (embedding) ต้องรองรับภาษาไทยจริง ๆ ไม่ใช่แค่ป้ายว่า multilingual ถ้าเลือกตัวที่เก่งเฉพาะภาษาอังกฤษ ต่อให้เอกสารสะอาดแค่ไหน ระบบก็จะดึงท่อนที่ไม่เกี่ยวกลับมาอยู่ดี และควรดูตัวเลข token สูงสุดของโมเดลด้วย เพราะบางตัวรับได้แค่ระดับร้อย token ซึ่งสั้นกว่าย่อหน้าเอกสารทั่วไป ส่วนที่เกินจะถูกตัดทิ้งเงียบ ๆ

เช็กลิสต์ก่อนกดปุ่ม index

ก่อนจะเสียเวลาแปลงเอกสารทั้งโฟลเดอร์ ไล่เจ็ดข้อนี้ก่อน

• ✅ สุ่มเปิด 5 ไฟล์ ลากคลุมข้อความดู แยกให้ออกว่ากองไหนเป็นข้อความ กองไหนเป็นภาพ
• ✅ เช็กหน้ากลางและหน้าท้าย ของไฟล์ยาว ไม่ใช่แค่หน้าแรก เพื่อจับไฟล์ผสม
• ✅ ไฟล์ภาพผ่าน OCR ด้วยชุดภาษาไทยและอังกฤษ แล้วเปิดผลดูด้วยตาจริง ไม่ใช่ดูแค่ว่ารันสำเร็จ
• ✅ ตรวจตารางและตัวเลขเป็นพิเศษ เพราะถ้าเอกสารคุณคือคู่มือหรือสเปก ตัวเลขที่เพี้ยนอันตรายกว่าคำที่เพี้ยน
• ✅ เอกสารทั้งหมดอยู่ในเครื่อง ตลอดกระบวนการ ไม่ผ่านเว็บแปลงไฟล์ออนไลน์
• ✅ หัวข้อยังอยู่ครบ หลังแปลง ถ้าเหลือแต่ข้อความก้อนเดียว ให้กลับไปใช้เครื่องมือที่คืน Markdown
• ✅ ตัด chunk ที่ขอบย่อหน้า ไม่ใช่นับตัวอักษร และเลือก embedding ที่รองรับไทย

สิ่งที่คนประเมินต่ำที่สุดในโครงการ RAG ไม่ใช่ความยากของโมเดล แต่คือสัดส่วนเวลาที่หมดไปกับการเตรียมเอกสาร ในโครงการจริงหลายงาน ขั้นตอนนี้กินเวลามากกว่าการต่อระบบค้นคืนเสียอีก และมันคือขั้นที่ตัดสินคุณภาพคำตอบสุดท้ายมากที่สุดด้วย เพราะทุกอย่างหลังจากนี้ทำงานบนสิ่งที่ขั้นนี้ส่งต่อไปให้เท่านั้น

ที่น่าสนใจคือแนวโน้มปี 2026 ทำให้เรื่องนี้สำคัญขึ้น ไม่ใช่น้อยลง วิธีค้นคืนรุ่นใหม่ที่กำลังมาแรงหลายแบบ (ทั้งแบบที่ให้ AI ไล่อ่านสารบัญและเลือกบทเอง หรือแบบที่แปลงเอกสารเป็นโครงข่ายความสัมพันธ์) ล้วนพึ่งพาโครงสร้างของเอกสารมากกว่าเดิมทั้งหมด เอกสารที่ถูก OCR ออกมาเป็นข้อความแบนราบไร้หัวข้อ จะได้ประโยชน์จากเทคนิคเหล่านี้น้อยที่สุด เพราะฉะนั้นเวลาที่ลงไปกับการเตรียมเอกสารให้ดีวันนี้ ไม่ได้ช่วยแค่ระบบที่คุณกำลังจะสร้าง แต่ช่วยทุกอย่างที่คุณจะต่อยอดจากมันในอีกสองสามปีข้างหน้าด้วย