กลยุทธ์การทำ Chunking สำหรับ RAG: แบ่งเอกสารเพื่อการดึงข้อมูลที่มีประสิทธิภาพยิ่งขึ้น

ความล้มเหลวส่วนใหญ่ของ RAG เกิดจากวิธีการที่คุณแบ่งเอกสาร (split documents)

หากการดึงข้อมูล (retrieval) ของคุณไม่มีประสิทธิภาพ อย่าเพิ่งเริ่มจากการเปลี่ยน prompt หรือ LLM แต่ให้กลับไปดูที่ chunks ของคุณ หากข้อมูลที่ถูกต้องมีอยู่ในฐานข้อมูลแต่ระบบหาไม่เจอ แสดงว่ากลยุทธ์การทำ chunking ของคุณน่าจะเป็นปัญหา

การทำ chunking ที่ไม่ดีก่อให้เกิดปัญหาหลัก 3 ประการ:

• การตัดแบ่งที่ขอบเขต (Boundary truncation): ประโยคที่มีคำตอบถูกแบ่งออกเป็นสองส่วน ซึ่งทั้งสองส่วนไม่มีข้อมูลเพียงพอที่จะตรงกับคำค้นหา (query) • การเจือจางของบริบท (Context dilution): chunk ขนาดใหญ่มีประโยคที่เกี่ยวข้องเพียงประโยคเดียว แต่อีกสิบประโยคที่เหลือไม่มีประโยชน์ ข้อความส่วนเกินเหล่านี้จะทำให้สัญญาณทางความหมาย (semantic signal) อ่อนแอลง • การขาด metadata: chunks ขาดข้อมูลเกี่ยวกับแหล่งที่มาหรือวันที่ ทำให้ไม่สามารถค้นหาแบบกรองข้อมูล (filtered search) ได้

ใช้ 4 กลยุทธ์นี้เพื่อปรับปรุง pipeline ของคุณ:

  1. Fixed-size chunking เหมาะที่สุดสำหรับเนื้อหาที่เป็นความเรียงยาวต่อเนื่อง เช่น รายงานหรือบทความ • ใช้ 256 ถึง 512 tokens • ตั้งค่า overlap ไว้ที่ 10% ถึง 15% เพื่อป้องกันการตัดแบ่งประโยค

  2. Semantic chunking เหมาะที่สุดสำหรับข้อความที่มีความหนาแน่นสูง เช่น FAQ หรือเอกสารสนับสนุน (support docs) • แบ่งข้อความตามการเปลี่ยนหัวข้อ (topic shifts) แทนที่จะใช้จำนวน token • วิธีนี้จะช่วยรักษาความคิดที่สมบูรณ์ให้อยู่ด้วยกัน

  3. Structural chunking เหมาะที่สุดสำหรับเอกสารทางเทคนิค, Markdown หรือ HTML • แบ่งข้อความตามหัวข้อ (H1, H2, H3) • วิธีนี้จะเพิ่ม metadata ทำให้คุณสามารถกรองการดึงข้อมูลตามส่วนต่างๆ (section) ได้

  4. Hierarchical (Parent-Child) chunking เหมาะที่สุดสำหรับระบบที่ใช้งานจริง (production systems) ที่ต้องการทั้งความแม่นยำและบริบท • สร้าง child chunks ขนาดเล็ก (64-128 tokens) เพื่อการค้นหาแบบ vector ที่แม่นยำ • เชื่อมโยงกับ parent chunks ขนาดใหญ่ (512-1024 tokens) เพื่อให้ LLM อ่าน • วิธีนี้จะช่วยให้คุณได้รับข้อดีของทั้งสองรูปแบบ

วิธีเลือกขนาด:

• 128–256 tokens: เหมาะสำหรับการค้นหาข้อเท็จจริง (fact-lookup) และเอกสารทางเทคนิค • 256–512 tokens: เป็นจุดเริ่มต้นที่ดีสำหรับการใช้งานทั่วไป • 512–1024 tokens: ใช้สำหรับคำถามเชิงวิเคราะห์ที่มีเนื้อหายาว

กฎเหล็ก: ทดสอบกลยุทธ์ของคุณเสมอ ก่อนที่จะนำไปใช้งานจริง (ship)

สร้างชุดคำถามจริงประมาณ 30 ถึง 50 คำถาม ระบุคำตอบที่ถูกต้อง (annotate) และวัดค่า recall@3 อย่าเพิ่งเปลี่ยน embedding model จนกว่าค่า recall ของคุณจะสูงกว่า 80%

ที่มา: https://dev.to/dishant_sethi/rag-pipeline-chunking-strategies-split-documents-for-better-retrieval-aoe

ชุมชนแห่งการเรียนรู้เพิ่มเติม (ไม่บังคับ): https://t.me/GyaanSetuAi