Chunking แปลงเนื้อหาหน้าเว็บที่ normalize แล้วให้เป็นหน่วย retrieval การเลือกที่ไม่ดีทำให้ต้นทุนเพิ่ม (fragment มากเกินไป), recall แย่ลง (block ใหญ่เกินไป) หรือ precision เจือจาง (ขอบเขตแตก) ไม่มีวิธีที่ดีที่สุดแบบสากล กลยุทธ์ต้องสอดคล้องกับโครงสร้าง corpus, ความผันผวน และรูปแบบ query คู่มือนี้แผนที่พื้นที่ออกแบบ trade-off, workflow การประเมิน และคันโยก optimization สำหรับ production RAG pipelines
ทำไม Chunking จึงสำคัญ
เป้าหมาย:
- เพิ่มโอกาสสูงสุดให้ข้อเท็จจริงที่เกี่ยวข้องปรากฏใน top-k retrieval
- รักษาความสอดคล้องเชิงความหมายเพื่อให้คำตอบที่สร้างขึ้นมี grounding
- ใช้ token ให้คุ้มค่าและหลีกเลี่ยงการ embedding boilerplate ซ้ำ
- รองรับการอัปเดต incremental ที่ deterministic ด้วย chunk IDs ที่เสถียร
chunking ที่ไม่ตรงงานจะแสดงออกเป็น redundancy สูง, Recall@k ต่ำ, boundary facts ที่ hallucinate และค่า embedding ที่บวม
Fixed Window Chunking
หน้าต่าง N-token แบบง่าย เช่น 500 tokens ข้อดี: deterministic, implement ง่าย, พฤติกรรม update เสถียร ข้อเสีย: ขอบเขตตัดผ่าน concept และต้องมี overlap ซ้ำเพื่อลด truncation จึงทำให้ต้นทุนเพิ่ม ใช้อย่างประหยัด: เหมาะเป็น baseline สำหรับ content ที่หลากหลายหรือมีโครงสร้างไม่ดี ซึ่งสัญญาณ semantic ไม่น่าเชื่อถือ
Overlapping Sliding Windows
ขนาดหน้าต่าง W พร้อม overlap O เช่น 500 / 50 tokens ช่วยลดการตัด fact ที่ขอบเขต overlap เกินประมาณ 15% มักให้ recall เพิ่มน้อยลงแต่เพิ่มขนาด index ต่อเนื่อง ติดตาม duplication_ratio = distinct_token_count / total_token_count เพื่อปรับ O ลง
การตรวจจับขอบเขตเชิงความหมาย
แบ่งตามสัญญาณโครงสร้าง: หัวข้อ H2/H3, กลุ่ม list, code blocks, ขอบเขต table บังคับใช้ min/max token bounds โดย merge sibling ที่เล็กเกินไป และ split section ที่ใหญ่เกินไป ประโยชน์: cohesion สูงขึ้น overlap น้อยลง ความเสี่ยง: markup ผิดรูป hierarchy ของ heading ไม่สม่ำเสมอ ลดความเสี่ยงด้วย hierarchy repair และ fallback เป็นการแบ่ง paragraph เมื่อไม่มี heading
Hierarchical Chunking
index สองชั้น: coarse section embeddings เช่นทั้ง section ของ tutorial และ subchunks ละเอียด Flow retrieval: coarse ANN → filter top N sections → fine retrieval ภายในนั้น ข้อดี: ลดพื้นที่ค้นหาระดับ global สำหรับ corpus ใหญ่และปรับ latency ดีขึ้น ความซับซ้อน: มีส่วนเคลื่อนไหวมากขึ้นและต้องมี cascade scoring logic
Adaptive / Dynamic Chunking
ปรับขนาด chunk ตามความหนาแน่น semantic เฉพาะที่และสัญญาณโครงสร้าง ตัวอย่าง logic: เริ่มที่ heading section ถ้า >800 tokens ให้ split ตาม cluster ของ paragraph ที่ให้คะแนนด้วย semantic similarity ถ้า <120 tokens ให้ merge กับ sibling ถัดไป เว้นแต่ topic divergence > threshold ต้องมี pre-pass แบบ embedding หรือ similarity จ่ายต้นทุนครั้งเดียวตอน ingestion เพื่อประสิทธิภาพ retrieval ระยะยาวที่ดีขึ้น
ข้อพิจารณาเรื่อง Embedding
รักษา metadata: token_count, model_version, content_hash หลีกเลี่ยง truncation ด้วยการ pre-compute tokens และ split ก่อนเรียก model Dense models เสื่อมคุณภาพเมื่อมี boilerplate มากเกินไป จึงควร strip navigation artifacts ก่อน chunk Monitor vector_density (unique terms / tokens) เพื่อหา fragment สัญญาณต่ำที่ควร re-merge
วิธีประเมินผล
Benchmark ต่อกลยุทธ์:
| Metric | Purpose |
|---|---|
| Recall@k | การรักษา fact |
| Precision@k | noise ใน context |
| Chunk Count | ตัวชี้วัดต้นทุน |
| Duplication Ratio | การจูน overlap |
| Avg Tokens per Chunk | การใช้หน้าต่าง |
| Latency (Retrieval) | ประสิทธิภาพ index |
รันบน gold query set และรับกลยุทธ์ใหม่เฉพาะเมื่อ recall ที่เพิ่มขึ้นคุ้มกับ delta ของต้นทุนและ latency
Playbook การ implement
- Baseline: Fixed 500 + 10% overlap; เก็บ benchmark
- เพิ่ม Semantic Boundaries: แทนที่ window เมื่อ heading เชื่อถือได้; วัดใหม่
- เพิ่ม Hierarchical Layer หาก corpus >250k chunks หรือ latency > target
- Deploy logic แบบ Adaptive สำหรับ section size ที่ variance สูง
- ประเมินรายไตรมาส: เปรียบเทียบต้นทุนต่อ quality delta กับความสามารถโมเดลใหม่
เก็บ diff ของ chunk manifest ต่อ iteration เพื่อ rollback
ประเด็นสำคัญ
- Semantic boundaries มักชนะ pure fixed windows ด้าน precision/cost
- Overlap คือปุ่มปรับ วัด duplication อย่าเดา
- Hierarchical retrieval ช่วย scale โดยไม่เพิ่ม latency แบบ linear
- chunk IDs ที่เสถียรรองรับ incremental embedding refresh อย่างปลอดภัย
- ประเมินการเปลี่ยนกลยุทธ์เหมือน code deploy: benchmark, compare, log