Tầng 4 — Chunking & Indexing

Căng thẳng cốt lõi

• Chunk quá nhỏ → mất ngữ cảnh, đại từ mất tham chiếu, embedding thiếu tín hiệu.
• Chunk quá to → loãng tín hiệu (một câu liên quan trong 2000 token bị pha loãng), và tốn context window khi đưa vào prompt.

Liên hệ với Tầng 0: chunking là cách can thiệp vào dl/avgdl ở tầng dữ liệu. Chunk đều nhau làm b gần như vô nghĩa — đó là dấu hiệu chunking đang làm việc.

Đo thật trên data/corpus.jsonl (gộp/tách tài liệu để mô phỏng các mức chunk, k1 = 1.2, nDCG@5 trên 24 truy vấn):

đơn vị index	avgdl (từ)	CV độ dài	dao động nDCG@5 khi quét b 0→1	b tối ưu
câu lẻ	23.6	0.30	0.029	1.0
tài liệu (~44 từ)	48.5	0.14	0.008	0.25
gộp 2 tài liệu	96.9	0.11	0.017	0.25
gộp 10 tài liệu	484.6	0.08	0.003	0

Chunk càng đều (CV thấp) thì b càng không còn tác dụng, và b tối ưu tụt về 0. b là băng dán cho chunking kém. Grid k1×b đầy đủ và cách chọn chunk size theo loại truy vấn: 3.15.

Khi so sánh hai chunk size, phải cố định ngân sách context. So top-5 chunk nhỏ với top-5 chunk to là so hai lượng văn bản khác nhau — chunk to thắng vì được trả nhiều chữ hơn, không phải vì tìm giỏi hơn. Cố định số token trả về (k điều chỉnh theo avgdl), căng thẳng thật hiện ra: trên corpus này chunk nhỏ thắng ở recall của đúng mẩu thông tin (0.778 vs 0.708), chunk to thắng ở thứ tự (nDCG 0.819 vs 0.758). Đó là lý do parent-child tồn tại — lấy cả hai cột.

Số dẫn từ nguồn ngoài, có benchmark nhiều dataset: truy vấn factoid đáp án ngắn tối ưu ở 64–128 token; truy vấn cần ngữ cảnh rộng cần 512–1024 token. Chưa biết gì về phân bố truy vấn thì khởi điểm 256–512 token, overlap 10–20%.

Đọc thêm

• [VI] Tối ưu chunking trong RAG: thiết kế kích thước đoạn — Viblo — chọn kích thước chunk và overlap, bằng tiếng Việt
• [EN] Rethinking Chunk Size For Long-Document Retrieval, 2025 (arXiv 2505.21700) — nguồn cho 64–128 token (factoid) vs 512–1024 token (cần ngữ cảnh), đo trên nhiều dataset

Các chiến lược, từ thô đến tinh

Chiến lược	Cách làm	Khi nào dùng
Fixed-size + overlap	cắt N token, chồng lấn 10–20%	baseline, luôn thử trước
Recursive	cắt theo phân cấp: đoạn → câu → từ	văn bản có cấu trúc
Semantic	cắt ở chỗ embedding của câu kề nhau đổi nhiều	chi phí cao, lợi ích thường nhỏ
Parent-child	index chunk nhỏ để tìm, trả về chunk cha để đọc	rất hiệu quả, nên là mặc định
Late chunking	encode cả tài liệu dài trước, rồi pool theo từng chunk	chunk thừa hưởng ngữ cảnh toàn tài liệu
Contextual retrieval	dùng LLM sinh 1–2 câu ngữ cảnh gắn vào đầu mỗi chunk trước khi index	tốn tiền index một lần, cải thiện lớn

Parent-child và contextual retrieval là hai thứ đáng làm nhất. Cả hai đều tấn công đúng vào căng thẳng ở trên: tìm bằng đơn vị nhỏ (tín hiệu đậm), đọc bằng đơn vị lớn (ngữ cảnh đủ).

Đọc thêm

• [VI] 5 chiến lược chunking hiệu quả — Viblo — năm chiến lược chunking, so sánh
• [VI] Is simple chunking enough? — Viblo — vì sao chunking đơn giản thường không đủ
• [EN] Evaluating chunking strategies for retrieval — Chroma Research — nghiên cứu đo thật các chiến lược chunking
• [EN] Contextual Retrieval — Anthropic — contextual retrieval: thêm ngữ cảnh vào chunk trước khi index
• [EN] Text splitters — LangChain docs — các splitter có sẵn và ngữ nghĩa của từng cái

Metadata — thứ bị coi nhẹ nhất

Chunk nào cũng nên mang: nguồn, ngày, phiên bản, phòng ban, quyền truy cập, loại tài liệu. Lý do:

1. Filter trước khi tìm rẻ hơn tìm rồi lọc — và nhiều truy vấn thật ra là truy vấn filter, không phải truy vấn semantic (“hợp đồng ký sau tháng 6”).
2. Trích dẫn được nguồn (Tầng 8).
3. Phân quyền — bắt buộc, và phải ở tầng index, không phải ở tầng prompt.