การทำระบบให้ AI ตอบคำถาม Chunking คืออะไร สำคัญอย่างไร? และการให้ข้อมูล AI แบบไหนไม่ให้ AI ทำเนื้อหาผิดพลาดเวลาตอบคำถามเรา

มีสมมติฐานว่า ถ้าเราถาม AI ใน Knowledge-Base หรือคลังความรู้ภายในบริษัท เช่นว่า “ถ้ายังไม่ผ่านโปรเบิกค่าแว่นได้ไหม?” AI ตอบว่า “ได้ ปีละไม่เกิน 3,000 บาท” แต่คู่มือบริษัทระบุว่าต้องผ่านทดลองงานก่อน จากตัวอย่างนี้ AI เจอวงเงินถูกต้อง แต่เงื่อนไขพลาด ตรงนี้เอาที่สามารถระบุได้ว่า การหั่นข้อมูลเพื่อนำข้อมูลให้ AI ยังไม่ดีพอ หรือ Chunking ยังไม่ดีพอ เราต้องเก็บข้อเท็จจริงกับเงื่อนไขไว้ด้วยกันเสมอ

Chunking คืออะไร แล้วทำไมเราไม่ส่งไฟล์ทั้งไฟล์ให้ AI ไปเพื่อตอบคำถามเลย?

RAG คือการค้นข้อมูลจากเอกสารให้ AI อ่านก่อนตอบ Chunking คือแบ่งข้อความให้ค้นหาง่ายโดยไม่เปลี่ยนแปลต้นฉบับ จากนั้นเราจึงนำ Chunk หรือก้อนของประโยคที่มีความหมายตรงกับคำตอบ นำไปรวบรวมให้ AI ตอบคำถามให้เราอีกที

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

รอยต่อของประโยคที่เราตัดมาผิด ทำให้ความหมายเปลี่ยนไปยังไง?

ตัวอย่าง:

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

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

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

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

1. Fixed-size: ตัดตามความยาว

กำหนดความยาวแล้วตัดตามช่วง (เช่น กำหนดไว้เลยว่าตัดที่ 40 token) แบบนี้ทำง่ายแต่มีความเสี่ยงตัดกลางประโยคหรือตาราง และต้องใช้ตัวนับของโมเดลจริง เพราะภาษาไทยไม่ได้แปลงเป็น Token แบบตายตัว 1 คำ 1 token แบบภาษาอังกฤษ

2. Fixed-size + Overlap: ให้ข้อความตรงรอยต่อที่ตัดประโยคซ้อนทับกัน

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

3. Recursive splitting: แบ่งจากขอบเขตใหญ่ไปขอบเขตเล็กๆ

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

4. Structure-aware: ใช้โครงสร้างเอกสารช่วยแบ่ง

ใช้หัวข้อและตารางเป็นแนวในการแบ่ง แต่ก็อาจมีจุดอ่อนที่อาจจะเก็บค่าลอยๆ เช่น ในตารางมีเลข 3,000 อยู่ ถ้าเก็บ “3,000” ลอยๆ มันจะดูไม่มีความหมาย ต้องเก็บหน่วยกับคำกำกับไว้ด้วย ซึ่งอาจจะเป็นหัวคอลัมน์

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

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

6. Parent-child และ Contextual: จัดสิ่งที่ค้นกับสิ่งที่อ่าน

Parent-child ค้นชิ้นเล็ก (child) แล้วขยายหัวข้อใหญ่ (parent) ให้อ่าน ต้องรักษาลิงก์ไปต้นฉบับ คุมขนาด และตรวจสิทธิ์ของ Parent ด้วย

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

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

เลือกให้ตรงเอกสาร ไม่ใช่เลือกตามชื่อที่ดูเก่งที่สุด

เป็นเพียงแนวทางเริ่มต้น ต้องตรวจเอกสารจริงด้วยครับ

บทเรียนจาก PDF ท่องเที่ยวไทยที่ผมเคยเจอ

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

หั่นใหม่ไม่ช่วยคืนคำที่อ่านผิด Markdown ทำให้เห็นโครงสร้างง่ายขึ้น แต่ตารางยังต้องมีหัวข้อ อ่านประสบการณ์ PDF เพิ่มเติม

Chunk size กับ Overlap ควรเป็นเท่าไร?

ไม่มีค่าตายตัว 300–500 Tokens และ Overlap 10–20% เป็นตัวเลขตั้งต้นให้ลอง ไม่ใช่มาตรฐานหรือผลวัดจากระบบของผม พิจารณาว่า:

1. แต่ละส่วนเก็บใจความและเงื่อนไขครบไหม?
2. รวมคำถามและคำตอบแล้วข้อความไม่เกินขนาด token ที่ model รับได้ไหม?
3. Overlap ทำให้ข้อมูลเพิ่มขึ้นหรือแค่คำซ้ำๆ?
4. คำถามหาชื่อหรือตัวเลข อาจใช้ chunk ชิ้นเล็กๆได้ แต่คำถามเปรียบเทียบเงื่อนไขจากเงื่อนไขหลายๆข้อ ต้องดึงหลาย chunk หรือต้องขยายบริบทการค้นหา

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

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

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