Chunking

Chunking คือขั้นตอนหั่นเอกสารยาวๆ ให้กลายเป็นชิ้นย่อยขนาดพอเหมาะ ก่อนจะแปลงแต่ละชิ้นเป็น embedding แล้วเก็บลง vector-database เพื่อใช้ใน rag เอกสารทางสถาปัตยกรรมของ Microsoft Azure อธิบายว่า chunking คือ "การหั่นเอกสารให้เป็นชิ้นขนาดเหมาะสมที่แต่ละชิ้นมีเนื้อหาที่เกี่ยวข้องกันเชิงความหมาย" และถือเป็นขั้นตอนที่ชี้ชะตาความสำเร็จของระบบ RAG (Microsoft Learn) เหตุผลที่ต้องหั่นก่อนมาจากข้อจำกัดทางเทคนิค เพราะโมเดลที่ทำ embedding แต่ละตัวมี context window จำกัด ถ้าป้อนเอกสารทั้งก้อนเข้าไปตรงๆ ข้อมูลบางส่วนจะถูกตัดทิ้งโดยไม่ตั้งใจ (Pinecone, pinecone.io/learn/chunking-strategies)

ขนาดของ chunk ที่เลือกส่งผลตรงต่อคุณภาพคำตอบทั้งสองทาง Microsoft ระบุว่า chunk ที่เล็กเกินไปมักไม่มีบริบทพอจะตอบคำถามได้ครบ และถ้าเนื้อหาที่เกี่ยวข้องกระจายอยู่คนละชิ้น ระบบอาจดึงมาได้ไม่ครบทุกส่วน ส่วน Pinecone อธิบายฝั่งตรงข้ามว่า ข้อความที่ยาวเกินไปจะเพิ่ม noise และเจือจางน้ำหนักของประโยคหรือวลีแต่ละอันในชิ้นนั้น ทำให้หาคู่ที่ตรงจริงๆ ตอนค้นใน index ได้ยากขึ้น และการใช้ chunk ใหญ่ยังเพิ่มทั้งเวลาตอบและค่าใช้จ่ายในขั้นตอนถัดไปด้วย Pinecone แนะนำให้เริ่มจากการทดลองหลายขนาดเทียบกัน โดยยกตัวอย่างชิ้นเล็กที่ 128 หรือ 256 token ซึ่งจับความหมายได้ละเอียดกว่า และชิ้นใหญ่ที่ 512 หรือ 1024 token ซึ่งเก็บบริบทได้มากกว่า ส่วนขนาดสูงสุดที่ใช้ได้จริงยังถูกจำกัดด้วย context window ของโมเดล embedding ที่เลือก (Pinecone) ในทางปฏิบัติ เครื่องมืออย่าง langchain จึงเปิดให้กำหนดทั้งขนาด chunk และระยะเหลื่อม (overlap) ระหว่างชิ้นได้ เอกสารอ้างอิงของ LangChain ระบุว่า TextSplitter ใช้ค่าเริ่มต้น chunk_size 4000 ตัวอักษร และ chunk_overlap 200 ตัวอักษร โดย chunk_overlap คือส่วนที่ชิ้นซึ่งอยู่ติดกันใช้ร่วมกัน เอกสารของ LangChain อธิบายว่าการให้ชิ้นเหลื่อมกันช่วยลดการสูญเสียข้อมูลเมื่อบริบทถูกแบ่งคร่อมสองชิ้น (LangChain Reference, LangChain Docs)

คนทำงานมักเจอคำนี้ตอนทีม IT หรือ vendor เสนอทำ "แชตบอตตอบจากคู่มือบริษัท" แล้วผลลัพธ์ออกมาไม่ครบหรือดึงข้อมูลไม่เกี่ยวมาปนบ่อยๆ ต้นตอส่วนใหญ่ย้อนกลับไปที่การตั้งค่า chunking ตั้งแต่ตอนนำเข้าเอกสาร วิธีหั่นก็มีหลายแบบให้เลือกตามลักษณะเอกสาร ตั้งแต่ fixed-size ที่หั่นตามจำนวน token คงที่ (Pinecone แนะนำให้เริ่มจากวิธีนี้ก่อน) ไปจนถึง content-aware ที่หั่นตามโครงสร้างเอกสารอย่างหัวข้อหรือย่อหน้า และ semantic chunking ที่ใช้ embedding มาจัดกลุ่มเนื้อหาที่ความหมายใกล้กันเข้าด้วยกัน ซึ่ง Microsoft จัดว่าใช้แรงวิศวกรรมและต้นทุนประมวลผลอยู่ในระดับสูง เพราะต้องเขียน logic เฉพาะที่ซับซ้อนขึ้นมาเอง ข้อควรระวังคือ Microsoft เตือนไว้ว่ากลยุทธ์ chunking ที่เลือกไว้ตั้งแต่แรกมักกลายเป็นการตัดสินใจที่แก้ทีหลังยาก เพราะการเปลี่ยนกลยุทธ์ chunking กระทบขั้นตอนถัดไปอย่างมีนัยสำคัญ และมักต้องตามไปแก้ทั้ง workflow (Microsoft Learn)

ตัวอย่างจากบทสนทนาจริง

ฝ่ายจัดซื้อ: "ทำไมพอถามระบบเรื่องเงื่อนไขการคืนสินค้าในสัญญาฉบับนี้ มันตอบมาแค่ครึ่งเดียว ทั้งที่เอกสารมีเขียนไว้ครบ"

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

ระวังสับสนกับ

• reranking : chunking เกิดตอนเตรียมข้อมูลเข้าคลัง คือหั่นเอกสารก่อนทำ embedding ส่วน reranking เกิดทีหลังตอนค้นเสร็จแล้ว คือจัดลำดับผลลัพธ์ที่ดึงมาได้ใหม่ให้ชิ้นที่เกี่ยวข้องที่สุดขึ้นก่อน คนละจังหวะกันในสาย pipeline ของ RAG
• context-window : context window คือขนาดข้อมูลสูงสุดที่โมเดลรับได้ในการเรียกครั้งเดียว ส่วน chunk size คือขนาดที่เราเลือกหั่นเอกสารต้นทางก่อนเก็บลง vector database สองค่านี้ไม่จำเป็นต้องเท่ากันและมักถูกเลือกแยกกันคนละเหตุผล