Chunking in RAG สำคัญอย่างไร และมีแบบไหนบ้าง?

(ศิลปะการหั่นข้อมูลให้ AI อ่านแล้วเข้าใจ)

---

สมติว่าคุณถาม AI ที่นำเข้าเอกสารของคุณกับระบบหรือทำการ RAG ไว้เรียบร้อยแล้ว แล้วถาม AI ว่า "พนักงานที่ยังไม่ผ่านโปรเบิกค่าแว่นได้ไหม?" และคำตอบอยู่ในคู่มือสวัสดิการ ที่ซึ่งนำเข้าข้อมูลไปแล้ว แต่ AI กลับตอบว่า "เบิกได้ปีละ 3,000 บาท" แล้วลืมเงื่อนไขสำคัญที่ว่า ต้องผ่านทดลองงานก่อน

ปัญหาอาจไม่ได้อยู่ที่โมเดลตอบไม่เก่ง หรือระบบค้นหาไม่ดี แต่อาจเกิดตั้งแต่ตอนเราแบ่งเอกสารให้ระบบอ่านครับ: ข้อความเรื่องวงเงิน อาจจะอยู่ท้ายประโยค ส่วนเงื่อนไขอาจจะอยู่ต้นประโยค และระบบดึงมาได้แค่ชิ้นแรก(ต้นประโยค) คำตอบเลยผิดตั้งแต่ต้นทาง

ในบทความก่อนเรื่อง Search & Retrieval Fundamentals ผมเล่าว่าระบบค้นหาหาท่อนข้อมูลที่เกี่ยวข้องมาให้ LLM ตอบอย่างไร คำถามต่อมาคือ ใครเป็นคนกำหนดว่าหนึ่ง "ท่อน" เริ่มและจบตรงไหน? นี่แหละครับคือเรื่องของ Chunking

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

---

1. Chunking คืออะไร? แล้วทำไมเราถึงไม่ส่งทั้งไฟล์เข้าไปทำ RAG ทีเดียวเลย?

Chunking คือการแบ่งเนื้อหาจากเอกสารต้นทางเป็นชิ้นเล็ก ๆ (chunks) เพื่อทำ index ค้นหาและหยิบเฉพาะส่วนที่เกี่ยวข้องมาให้ AI อ่านตอนตอบคำถาม ขั้นตอนแบบง่ายๆคือ:

ไฟล์ต้นทาง → สกัดและจัดระเบียบข้อความ → แบ่งเป็น chunks
          → เก็บข้อความ + ตำแหน่งอ้างอิง → ทำ index ไว้ค้นหา
คำถาม → ค้น chunks ที่เกี่ยวข้อง → จัด context(บริบท) → LLM ตอบพร้อมแหล่งที่มา

การทำ index อาจใช้ Keyword Search, Vector Search หรือผสมกันก็ได้ ไม่ใช่ว่าทุก chunk ต้องทำ embedding เสมอไป ส่วนคำว่า chunk ในที่นี้คือ หน่วยที่เราให้ระบบใช้ค้นหา คล้ายๆกับ keyword แต่เป็น vector ในเชิงความหมาย (ในเชิงภาษาไหน ก็ขึ้นอยู่กับ model ที่ใช้ทำ embedding) ซึ่งอาจไม่เท่ากับผลลัพท์ที่ส่งเข้า LLM เพื่อใช้รวบรวมเพื่อตอบ User (คล้ายๆ key-value เราใช้ key นึงเพื่อค้นหา แต่ผลลัพท์ที่จะเอาไปตอบก็อาจเป็นอีกอย่างก็ได้)

ทำไมไม่ใช้เอกสาร 100 หน้าเป็น chunk เดียวเลย? เพราะว่าถ้าใช้ทั้งหน้านั้นจะมีเนื้อหาหลายเรื่องปนกัน การค้นหาประเด็นเฉพาะเลยยากขึ้น โมเดล embedding และ LLM มีข้อจำกัดในด้านความยาวของข้อความ และการส่งข้อมูลที่ไม่เกี่ยวข้องกันทั้งหมดไป ให้ LLM ตอบก็สิ้นเปลืองเวลาและ token แถมยังมีโอกาสให้ LLM หลงทิศทางอีกด้วย

แต่ถ้าหั่นให้สั้นที่สุดก็ไม่ใช่คำตอบเหมือนกันนะครับ เช่นอย่างประโยคที่ว่า

"สำหรับพนักงานประจำ ที่ผ่านการทดลองงานแล้ว สามารเบิกค่าแว่นได้ ปีละ 3,000 บาท"

แต่ถ้าหั่น chunk จนชิ้นที่เจอเหลือแค่ "สามารเบิกค่าแว่นได้ ปีละ 3,000 บาท" ส่งไปให้ AI ตอบ โดยไม่มีคำว่า "สำหรับพนักงานประจำ ที่ผ่านการทดลองงานแล้ว" เราก็ได้คำตอบที่ AI มั่นใจว่าถูก แต่ว่ามันผิดเงื่อนไข กลายเป็น AI หลอนไปเองซะอย่างงั้น

เป้าหมายของ Chunking ไม่ใช่ทำให้ชิ้นเล็กที่สุด แต่ทำให้แต่ละชิ้นค้นเจอได้ และมีบริบทพอสำหรับตอบคำถามที่ตั้งใจจะถาม

---

2. การตัดประโยคผิดหนึ่งครั้ง มันเปลี่ยนแปลงคำตอบได้อย่างไร?

สมมติว่าคู่มือสวัสดิการเขียนว่า:

ข้อ 8.1 สวัสดิการค่าตัดแว่นสายตา
บริษัทสนับสนุนค่าตัดแว่นตาไม่เกิน 3,000 บาทต่อปี
สำหรับพนักงานประจำที่ผ่านการทดลองงานแล้วเท่านั้น

ถ้าระบบตัดตามความยาวแบบไม่สนใจประโยค ผลที่ได้อาจเป็น:

Chunk A: บริษัทสนับสนุนค่าตัดแว่นตาไม่เกิน 3,000 บาทต่อปี
Chunk B: สำหรับพนักงานประจำที่ผ่านการทดลองงานแล้วเท่านั้น

เมื่อค้นคำว่า "ค่าแว่น" ระบบอาจเจอ A แต่ไม่เจอ B เพราะ B ไม่มีคำว่าแว่นและไม่มีหัวข้อกำกับ จากนั้นเมื่อโยนผลลัพท์ไปให้ LLM เพื่อรวบรวมคำตอบให้ User, AI ก็ไม่มีข้อมูลพอจะตอบเรื่องสิทธิ์ของคนที่ยังไม่ผ่านโปร ต่อให้เราเขียน prompt ว่า "ห้ามแต่งข้อมูล" ก็ยังเลี่ยงเงื่อนไขที่ search pipeline ไม่ได้ส่งประโยคเต็ม หรือชุดข้อมูลที่ถูกต้องสมบูรณ์เข้ามาไม่ได้ครับ

ถ้ารักษาหัวข้อและประโยคที่เกี่ยวข้องกันไว้ในชิ้นเดียว (chunk เดียวกัน) เราจะได้:

[คู่มือสวัสดิการ > ข้อ 8.1 สวัสดิการค่าตัดแว่นสายตา]
บริษัทสนับสนุนค่าตัดแว่นตาไม่เกิน 3,000 บาทต่อปี
สำหรับพนักงานประจำที่ผ่านการทดลองงานแล้วเท่านั้น

คราวนี้ระบบค้นเจอเรื่องแว่นพร้อมเงื่อนไข และยังรู้ว่าข้อความมาจากหัวข้อไหน นี่คือความต่างระหว่าง ค้นเจอข้อความที่ดูเกี่ยวข้อง กับ ค้นเจอหลักฐานที่ตอบคำถามได้จริง

---

3. มีวิธีการทำ Chunking แบบไหนบ้าง?

เราไม่จำเป็นต้องเลือก วิธีใดวิธีหนึ่งเสมอไปครับ หลายระบบใช้หลายวิธีร่วมกัน เช่น แบ่งตามหัวข้อก่อน แล้วค่อยตัดหัวข้อที่ยาวเกินด้วยขนาด token

3.1 Fixed-size: หั่น chunk ตามจำนวนตัวอักษรหรือ token

วิธีนี้กำหนดความยาวตายตัว เช่น 500 tokens ต่อ chunk แล้วตัดต่อเนื่องกันไปเรื่อย ๆ วิธีนี้ทำง่ายมากๆ คุมจำนวนชิ้นและงบ token ได้ แต่เสี่ยงตัดกลางประโยค หัวข้อ ตาราง หรือเงื่อนไขสำคัญ (ปัญหาก็คล้ายๆกับตัวอย่างที่เสนอไปข้างต้น แต่อาจจะแย่กว่าด้วยซ้ำในบางเคส)

ถ้าต้องคุมขนาดสำหรับ embedding หรือ LLM ควรวัดด้วย tokenizer ของโมเดลที่ใช้จริง ไม่ใช่สมมติว่า 1 คำไทยเท่ากับ 1 token หรือใช้จำนวนตัวอักษรแทน token แบบตรง ๆ

3.2 Fixed-size + Overlap: ให้รอยต่อเหลื่อมกัน

สมมติ chunk นึงจบที่ประโยคเรื่องวงเงิน chunk ถัดไปเริ่มที่เงื่อนไข การคัดลอกข้อความบางส่วนให้ไปเจอกันอีกทีตรงรอยต่อ (overlap) ช่วยลดโอกาสที่เนื้อหาจะขาดได้ ช่วยแก้ปัญหาเรื่อง Fixed-size ที่อาจไปตัดคำเชื่อกันพอดี

แต่ วิธี overlap ก็อาจจะเจอความยากของภาษาไทยที่เขียนติดๆกัน ถ้าตนฉบับไม่เว้นวรรคเลย การ overlap หรือ การหารอยต่อจะยากมากขึ้น(เช่นยาว 2 บรรทัด จะเลือก overlap กันตรงไหนดี) หรือถ้าต้นฉบับอ่านสลับคอลัมน์ผิด หรือเงื่อนไขอยู่ไกลออกไปอีกหลายหน้า การซ้อนข้อความเล็กน้อยก็ช่วยไม่ได้ แถมชิ้นที่เกือบเหมือนกันอาจแย่งพื้นที่ในผลค้นหาอันดับต้น ๆ เพิ่มจำนวนรายการใน index และ token ที่ส่งให้ LLM จึงควรตัดตรงที่ซ้ำกัน ตรงที่ overlap กันออกด้วย หรือรวมบริบทเมื่อ ค้นหาได้แล้ว นำไปให้ LLM

3.3 Recursive splitting: แยกโดยให้ความสำคัญกับขอบเขต ประโยค/ข้อความ มากกว่าการคุมความยาวของประโยคหรือข้อความ

ให้ลองแบ่งตามหัวข้อหรือย่อหน้าก่อน ถ้า chunk ยังยาวเกินค่อยแบ่งตามประโยค และสุดท้ายจึงตัดตามขนาดที่กำหนด วิธีนี้เป็น baseline ที่ดีสำหรับข้อความทั่วไป เพราะอย่างน้อยเราก็ไม่ได้รีบผ่าประโยคโดยไม่จำเป็น

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

3.4 Structure-aware: หั่นตามโครงสร้างเอกสาร

ถ้าเอกสารมี # หัวข้อ, ## หัวข้อย่อย, ย่อหน้า รายการ และตาราง เราสามารถรักษาโครงสร้างเหล่านั้นไว้ได้ เช่นเก็บข้อความในหัวข้อ 8.1 พร้อมชื่อหมวด "สวัสดิการ" ถ้าหัวข้อยาวเกินขนาดที่ใช้ค้นหา ก็ตัดย่อยอีกทีโดยยังเก็บ reference หัวข้อไว้ในทุกๆ chunk ที่เราแยกไป

ตัวอย่างข้อมูล ที่เป็นตาราง

ประเภทสวัสดิการ	วงเงิน (บาท/ปี)
ค่าตัดแว่น	3,000
ค่าทันตกรรม	2,000

จากตารางตัวอย่าง อย่าแยกแถวที่เป็นตัวเลขออกจากชื่อคอลัมน์ลอย ๆ มันจะกลายเป็น "3,000" ลอยๆ ทำให้ดูไม่มีความหมาย แต่ถ้าเราเอาคอลัมน์มาด้วย จากตัวอย่างจะได้*"ประเภทสวัสดิการ ค่าตัดแว่น: วงเงิน 3,000 (บาท/ปี)"* ส่วน code block หรือข้อกำหนด ต่างๆที่มีลำดับขั้น ควรระวังไม่ตัดจนตัวอย่างโค้ดหรือเงื่อนไขหายไปหรือไม่ครบด้วยครับ

3.5 Semantic chunking: แบ่งเมื่อประเด็นเปลี่ยน

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

แต่ถ้าต้นฉบับมีหัวข้อชัดอยู่แล้ว มี pattern ชัดเจนอยู่แล้ว เราอาจไม่จำเป็นต้องเพิ่มขั้นตอนให้ยุ่งยาก หรือเพิ่มค่าใช้จ่ายเพื่อให้โมเดลเดาในสิ่งที่โครงสร้างชัดเจนอยู่แล้วเช่นกันครับ

3.6 Parent–child และ Contextual chunking: ค้นชิ้นเล็ก อ่านชิ้นใหญ่

เทคนิค Parent–child คือทำเป็นชิ้นเล็กๆ (child) ไว้สำหรับค้นหา และผูกไว้กับ parent หรือย่อหน้าหรือหัวข้อไว้ด้วย เมื่อค้นหาเจอจาก child แล้วจึงดึงย่อหน้าหรือหัวข้อใหญ่ (parent) กลับมาให้ LLM อ่าน ช่วยให้ค้นประเด็นเฉพาะได้ ทำให้ LLM ยังอ่านเงื่อนไข หรือทั้งย่อหน้าได้ทำให้องค์ประกอบค่อนข้างครบ แต่ว่าเราต้องเก็บความสัมพันธ์ระหว่าง child, parent และเอกสารต้นฉบับให้ถูกต้องด้วย

เทคนิค Contextual chunking เติมบริบทที่จำเป็นให้ chunk ที่กำกวม หรือสื่อความหมายไม่ชัด เช่นแนบชื่อเอกสารและอ้างอิงหัวข้อด้วย หรือคำอธิบายสั้น ๆ ที่มาจากบริบทต้นฉบับ ก่อนที่จะทำ index คำค้นหาด้วย ส่วนถ้าเราจะใช้ LLM สร้างคำอธิบาย เราจะต้องต้องระวังข้อความที่ model เติมขึ้นมาเองไม่ตรงต้นฉบับด้วย และควรเก็บข้อความจริงไว้ตรวจ เพื่ออ้างอิงเสมอ

จะเห็นว่าการเพิ่มความแม่นยำและการจัดการเพื่อนำไปค้นหาจึงไม่ใช่วิธีตัดอย่างเดียว แต่เป็นการออกแบบด้วยว่า จะสร้างจุดการค้นหาจากตรงไหน จะค้นอะไร และจะส่งอะไรให้โมเดลอ่าน หรือสรุปให้ User

และมีอีกวิธีคือ propositional/agentic chunking โดยให้ LLM อ่านทั้งเอกสารเพื่อเลือกจุดตัด หรือสกัดแต่ละข้อความให้เป็นประโยคที่เข้าใจได้เอง แต่วิธีนี้มีค่าใช้จ่ายเพิ่มขึ้นและมีความเสี่ยงที่การเรียบเรียงข้อความขึ้นมาใหม่จะทำเงื่อนไขหลุดไป และควรเก็บข้อความต้นฉบับและทดสอบเทียบกับวิธีที่ไม่ใช้ LLM ก่อน เพื่อเลือกระหว่างต้นทุนที่เพิ่มขึ้นและความถูกต้องหรือสิ่งที่จะได้ว่าคุ้มค่าหรือไม่

---

4. เลือกวิธีให้ตรงกับเอกสาร

ลักษณะข้อมูล	สิ่งที่แนะนำ	สิ่งที่ต้องระวัง
Markdown / คู่มือมีหัวข้อชัด	แบ่งตามหัวข้อ → ตัดย่อยเมื่อยาวเกิน	แนบหัวข้อแม่ให้ชิ้นย่อย; อย่าแยกตารางออกจากหัวคอลัมน์
ข้อความล้วนที่โครงสร้างไม่แน่นอน	Recursive splitting + overlap เท่าที่จำเป็น	ตรวจสอบรอยต่อของ ข้อความที่มีข้อยกเว้นและเงื่อนไข
สัญญา / ระเบียบ / FAQ ที่คำตอบต้องมีหลายย่อหน้า	เก็บชิ้นเล็กไว้ค้นหา + ขยายเป็นหัวข้อใหญ่ตอนอ่านก่อนจะนำไปสร้างคำตอบ	ต้องอ้างอิงเลขข้อ เวอร์ชัน และสิทธิ์เข้าถึงของเอกสารให้ถูกต้อง
PDF สแกน / เอกสารหลายคอลัมน์	ซ่อมข้อความจากการสกัดข้อความและไล่เรียงลำดับการอ่านก่อน แล้วค่อยแบ่งตามโครงสร้าง	ต่อให้แบ่งหรือทำ chunk ดีขนาดไหนก็แก้ปัญหา OCR ที่อ่านผิดหรือข้อความสลับตำแหน่งหรือสลับคอลัมน์ไม่ได้

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

เคสที่ผมเคยเจอกับ PDF เป็นโบชัวร์ท่องเที่ยวไทยที่ทำออกมาสวยมาก แต่ข้อความที่สกัดออกมาพังต้องซ่อมเยอะเลยครับ

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

ประสบการณ์นี้ผมเล่าไว้ละเอียดใน บทความ Markdown กับสงคราม PDF ซึ่งเป็นตัวอย่างชัดเจนว่า ไม่ใช่การทำ chunking แบบไหนดีที่สุด แต่ทำให้ผมระวังขั้นตอนก่อนการ แบ่งหรือหั่น chunk มากขึ้น ซึ่งถ้าอ่านข้อความต้นฉบับผิดไปแล้ว การเปลี่ยน chunk size หรือเพิ่ม overlap ก็ไม่มีทางทำให้คำที่หายไปแล้วกลับมาได้

ถ้าเอกสารเป็นของเราและเลือกวิธีเขียนได้ การใช้ Markdown ทำให้เรารู้ได้ง่ายว่าตรงไหนเป็นหัวข้อ ตาราง หรือ code block ชัดกว่า PDF หรือรูปภาพ ที่ต้องเดา layout แต่ Markdown ก็ไม่ได้ทำให้ AI เข้าใจทุกอย่างอัตโนมัติ เช่น หัวข้ออาจยาวหลายพัน token ตารางอาจกินหลายหน้า และยังต้องออกแบบ chunk กับตรวจผลการค้นหาอยู่ดี

---

5. แล้วขนาด chunk และ overlap ควรเป็นเท่าไร?

คำตอบคือ ไม่มีค่าตายตัว ครับ ค่า 300–500 tokens ต่อ chunk กับ overlap ประมาณ 10–20% อาจใช้เป็น ค่าตั้งต้น สำหรับเนื้อหาแบบมีย่อหน้า แต่ไม่ควรเอาเป็นมาตรฐาน บางทีอาจใช้สั้นกว่านั้นมาก บางหัวข้อมีเงื่อนไขยาว เลยต้องใช้ยาวกว่านั้น และโมเดล embedding ที่ใช้แต่ละตัวรองรับความยาวไม่เท่ากัน

แนะนำให้ดู 4 เรื่องนี้ก่อน:

1. ความหมาย: Chunk นี้มีหัวข้อ ประธาน เงื่อนไข หรือข้อยกเว้นที่จำเป็นครบไหม อ่านเดี่ยว ๆ แล้วรู้มั้ยว่าพูดถึงอะไร? หรือสื่อถึงอะไร?
2. ข้อจำกัดของโมเดลและงบประมาณ: โมเดลที่ใช้ รับได้กี่ token? เมื่อนำหลายชิ้นมารวมกันกับคำถามและคำสั่งแล้ว ยังอยู่ใน limit context ของ LLM ไหม?
3. ความซ้ำซ้อนและความคุ้มค่า: การหั่นชิ้นเล็กและ overlap มากทำให้ index เพิ่ม และผลอาจซ้ำกัน และใช้ token ซ้ำโดยไม่ได้อะไรเพิ่ม
4. ชนิดของคำถาม: คำถามหาชื่อหรือตัวเลข อาจใช้ chunk ชิ้นเล็กๆได้ แต่คำถามเปรียบเทียบเงื่อนไขจากเงื่อนไขหลายๆข้อ ต้องดึงหลาย chunk หรือต้องขยายบริบท

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

---

6. แล้วจะรู้ได้อย่างไรว่าหั่นดีแล้ว?

อย่าวัดแค่ว่า "AI ตอบลื่นหูไหม" ให้ตรวจตั้งแต่ ชิ้นที่ค้นหาเจอ ไปจนถึงคำตอบสุดท้ายครับ:

• สร้างชุดคำถามพร้อมระบุ เอกสาร/ข้อ/หน้าที่เป็นหลักฐาน เช่น "ยังไม่ผ่านโปรเบิกค่าแว่นได้ไหม?", "วงเงินเท่าไร?", "ถ้าเอกสารไม่มีข้อมูล ให้ตอบว่าอะไร?"
• ลองเทียบ 2–3 วิธีบนเอกสารและชุดคำถามเดียวกัน เช่น fixed-size, แบ่งตามหัวข้อ, และแบ่งตามหัวข้อร่วมกับขยายหัวข้อใหญ่ (parent) ดูว่าในผลค้นหาอันดับต้น ๆ มีข้อความ ครบพอตอบ กี่ข้อ (retrieval recall) ไม่ใช่แค่มีคำค้นหาออกมาเท่านั้น
• ตรวจรอยต่อของข้อความให้เป็นพิเศษ: ข้อจำกัด เฉพาะ, ยกเว้น, ต้อง, ไม่เกิน หลุดไปอยู่ชิ้นอื่นหรือเปล่า? ตารางยังมีหัวคอลัมน์และค่าต่างๆอยู่ครบไหม? chunk ซ้ำกินพื้นที่อันดับต้น ๆ หรือไม่?
• ตรวจคำตอบและ citation แยกจากคะแนนค้นหา: AI อ้างถึงข้อที่มีข้อความจริงไหม? ตอบเกินหลักฐานหรือเปล่า? ถ้าข้อมูลไม่มี ระบบยอมรับและบอกว่าไม่มีข้อมูลหรือไม่?
• เมื่อเอกสารอัปเดต ต้องรู้ว่าชิ้นไหนมาจาก File version ไหน เก็บ document_id, section, page/offset, version ตามชนิดเอกสาร เพื่อย้อนตรวจและลบ index เก่าได้ และอย่างระบบองค์กรต้องกรองสิทธิ์การเข้าถึง ก่อนส่งข้อมูลให้โมเดลไปตอบ เพื่อป้องกันข้อมูลหลุดด้วย

ถ้าข้อมูลต้นทางผิด ให้กลับไปแก้ ingestion ถ้าหลักฐานครบในเอกสารแต่ไม่ถูกค้นเจอ ให้ดู chunking และ retrieval ถ้าผลลัพท์คำตอบครบใน prompt แล้วยังตอบผิด ค่อยไปดูการจัดบริบทและขั้นตอบของ LLM การแยกจุดพังแบบนี้ทำให้เราไม่เสียเวลาแก้ผิดที่ และแก้ไม่กระทบกันด้วยครับ

---

7. บทสรุป: Chunk การหั่นข้อมูลคือการเลือกสิ่งที่ AI มีโอกาสได้เห็น

ระบบ RAG ไม่ได้ มีเจตนาให้อ่านทั้งคลังเอกสาร ทุกครั้งที่คุณถาม มันอ่านเฉพาะข้อมูลที่ระบบค้นหาและส่งมาให้ ดังนั้น ขอบเขตของ chunk ว่าเราหั่นถึงตรงไหน มีผลต่อขอบเขตของคำตอบ เสมอ

ผมแนะนำให้เริ่มจากทำข้อมูลต้นทางให้ถูกก่อน → หั่นตามหัวข้อหรือย่อหน้า → จำกัดชิ้นที่ยาวเกินไป → เก็บแหล่งอ้างอิง reference → ทดสอบกับคำถามจริง แล้วค่อยเพิ่ม overlap, parent–child หรือวิธีใช้โมเดลช่วยหั่นเมื่อ ผลการค้นหายังขาดบริบท หรือเนื้อหาสาระสำคัญ

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