Bài 3 — Chunking và embedding: hai đòn bẩy lớn nhất của recall

Ở bài 2 bạn đã biết đo recall@k. Bài này bàn về hai thứ ảnh hưởng recall mạnh nhất mà PM thường bỏ qua: cách cắt tài liệu (chunking) và cách biểu diễn ý nghĩa (embedding).

Chunking — nghệ thuật cắt tài liệu

Chunk là đơn vị nhỏ nhất được truy hồi. Cắt sai là hỏng từ gốc.

Vì sao kích thước chunk quan trọng

• Chunk quá lớn (ví dụ nguyên chương): mỗi chunk chứa nhiều chủ đề, embedding bị "pha loãng", điểm tương đồng với câu hỏi cụ thể thấp → recall giảm. Ngoài ra tốn token.
• Chunk quá nhỏ (một câu): mất ngữ cảnh xung quanh, mô hình đọc được mảnh vụn không đủ để trả lời; thông tin bị chia cắt giữa nhiều chunk.

Điểm cân bằng thực dụng thường là cắt theo đơn vị ngữ nghĩa (đoạn văn, mục, điều khoản) với kích thước vừa phải, kèm overlap (phần chồng lấn) giữa các chunk để không cắt đứt câu ở ranh giới.

Các chiến lược chunking

• Fixed-size + overlap: cắt theo số token cố định, chồng lấn 10–20%. Đơn giản, ổn định.
• Semantic/structure-aware: cắt theo cấu trúc tài liệu (heading, điều, mục, bảng). Giữ trọn ý.
• Parent-child (small-to-big): index chunk nhỏ để tìm chính xác, nhưng trả về chunk cha lớn hơn để đủ ngữ cảnh cho mô hình. Rất hiệu quả trong thực tế.

Ví dụ chunking hỏng

Tài liệu HR: "Nhân viên được nghỉ phép 12 ngày/năm. Nhân viên thâm niên trên 5 năm được cộng thêm 3 ngày." Nếu chunk cắt giữa hai câu, người hỏi "nhân viên 6 năm nghỉ bao nhiêu ngày?" chỉ nhận chunk đầu → trả lời 12 (sai). Cắt theo đoạn hoặc dùng overlap sẽ cứu tình huống này.

Embedding — biểu diễn ý nghĩa thành vector

Embedding biến văn bản thành vector; câu hỏi và chunk gần nhau về ý nghĩa sẽ gần nhau trong không gian vector. Đây là trái tim của semantic search.

Điều PM cần lưu ý

• Ngôn ngữ: nhiều model embedding yếu với tiếng Việt. Hãy test cụ thể trên corpus tiếng Việt, đừng tin bảng benchmark tiếng Anh.
• Domain: thuật ngữ chuyên ngành (y tế, luật, tài chính) có thể bị model hiểu sai. Cân nhắc model chuyên ngành hoặc bổ sung keyword search.
• Tính nhất quán: câu hỏi và tài liệu phải dùng cùng một model embedding. Đổi model thì phải re-index toàn bộ — một sai lầm vận hành phổ biến.
• Kích thước chiều (dimension) và chi phí lưu trữ/tìm kiếm tăng theo.

Semantic vs keyword vs hybrid

• Semantic search giỏi bắt ý nghĩa nhưng dễ trượt với mã sản phẩm, tên riêng, con số, viết tắt (ví dụ "lỗi E-402").
• Keyword/BM25 giỏi khớp chính xác từ khóa nhưng không hiểu đồng nghĩa.
• Hybrid search (kết hợp cả hai) thường cho recall tốt nhất trong sản phẩm thật. Nếu người dùng hay tra mã/tên riêng, hybrid gần như bắt buộc.

Khung tư duy tối ưu retrieval

Khi recall thấp, lần lượt hỏi:

• Chunk có chứa đủ câu trả lời không? (vấn đề chunking)
• Câu hỏi và chunk có được biểu diễn tốt không? (vấn đề embedding/ngôn ngữ)
• Có cần khớp chính xác từ khóa không? (cần hybrid)

Checklist tối ưu

• [ ] Thử ít nhất 2–3 kích thước chunk, đo recall@k cho từng cái.
• [ ] Kiểm tra chunk quanh các câu hỏi fail — có bị cắt cụt ý không?
• [ ] Test embedding trên chính corpus và ngôn ngữ của bạn, không tin benchmark ngoài.
• [ ] Đánh giá hybrid nếu người dùng tra mã/tên riêng/số.
• [ ] Đảm bảo pipeline re-index khi đổi model embedding.

Sai lầm thường gặp

• Chọn 1 kích thước chunk rồi không bao giờ thử lại. Đây là biến số rẻ nhất để cải thiện, đừng bỏ qua.
• Tin benchmark embedding tiếng Anh cho sản phẩm tiếng Việt. Luôn test trên dữ liệu thật.
• Chỉ dùng semantic, bỏ keyword rồi ngạc nhiên khi "E-402" không tìm ra.
• Đổi model embedding mà quên re-index, khiến vector câu hỏi và tài liệu lệch chuẩn.
• Cắt chunk cứng nhắc theo token, phá vỡ bảng biểu và danh sách.

Bài 4 sẽ thêm một tầng nữa để nâng precision mà không hy sinh recall: re-ranking và giữ index luôn tươi mới.