Chunking là bước chia tài liệu dài thành các đoạn nhỏ (chunk) trước khi tạo embedding và lưu vào vector database trong hệ thống RAG. Mỗi khi người dùng hỏi, hệ thống tìm vài chunk liên quan nhất để đưa cho AI. Chunk quá dài làm loãng ý và tốn token, chunk quá ngắn làm mất ngữ cảnh. Cách phổ biến là chia theo cấu trúc tài liệu như mục, tiêu đề, điều khoản, giữ mỗi đoạn khoảng vài trăm từ và cho các đoạn chồng lấn một phần. Chunking tốt thường cải thiện chất lượng RAG nhiều hơn việc đổi sang mô hình đắt tiền.
Chunking là gì và vì sao RAG cần chia tài liệu
Chunking là việc cắt một tài liệu thành nhiều mảnh văn bản nhỏ, mỗi mảnh được xử lý và tìm kiếm như một đơn vị độc lập. Trong RAG, hệ thống không đưa nguyên cuốn sổ tay nhân viên 80 trang vào prompt mỗi lần có câu hỏi. Nó chỉ lấy vài đoạn liên quan.
Có ba lý do khiến chunking bắt buộc:
- Giới hạn ngữ cảnh và chi phí: dù context window ngày càng lớn, đưa toàn bộ kho tài liệu vào mỗi câu hỏi vẫn tốn token và chậm.
- Độ chính xác tìm kiếm: một embedding đại diện cho cả chương dài sẽ trộn nhiều chủ đề, khó khớp với câu hỏi cụ thể.
- Trích dẫn nguồn: chunk nhỏ cho phép chatbot chỉ rõ thông tin lấy từ mục nào, trang nào.
Một ví dụ dễ hình dung
Quy chế lương thưởng của công ty 40 người có các mục: lương cơ bản, phụ cấp, thưởng Tết, thưởng doanh số. Nếu cả quy chế là một chunk, câu hỏi về thưởng Tết sẽ kéo theo toàn bộ nội dung phụ cấp. Nếu mỗi mục là một chunk, hệ thống lấy đúng phần thưởng Tết.
Các chiến lược chunking phổ biến
Không có cách chia nào tốt cho mọi loại tài liệu. Dưới đây là các chiến lược hay dùng, xếp từ đơn giản đến phức tạp.
| Chiến lược | Cách làm | Hợp với | Nhược điểm |
|---|---|---|---|
| Kích thước cố định | Cắt mỗi N token, có chồng lấn | Văn bản thuần, thử nghiệm nhanh | Dễ cắt ngang câu, ngang bảng |
| Đệ quy theo ký tự phân tách | Ưu tiên cắt ở đoạn, rồi câu, rồi từ | Đa số tài liệu văn phòng | Chưa hiểu cấu trúc mục |
| Theo cấu trúc | Cắt theo tiêu đề, mục, điều khoản | Quy chế, hợp đồng, sổ tay, Markdown | Mục quá dài vẫn cần chia tiếp |
| Theo ngữ nghĩa | Dùng embedding phát hiện chỗ đổi chủ đề | Biên bản họp, bài viết dài | Tốn tính toán, khó dự đoán |
| Cha con | Tìm bằng chunk nhỏ, trả về chunk cha lớn hơn | Tài liệu kỹ thuật nhiều chi tiết | Cài đặt phức tạp hơn |
Kích thước chunk và độ chồng lấn bao nhiêu là hợp lý
Đây là câu hỏi được hỏi nhiều nhất, và câu trả lời trung thực là: phụ thuộc vào tài liệu và kiểu câu hỏi. Tuy vậy, có vài điểm xuất phát hợp lý để thử.
- Câu hỏi tra cứu ngắn (số ngày phép, thông số máy): chunk nhỏ, khoảng 150–300 từ, giúp tìm chính xác.
- Câu hỏi cần giải thích (quy trình xử lý khiếu nại): chunk trung bình, khoảng 300–600 từ, giữ trọn một quy trình.
- Chồng lấn: khoảng 10–20% độ dài chunk, để câu nằm ở ranh giới không bị mất ngữ cảnh.
Lưu ý tiếng Việt thường tốn nhiều token hơn tiếng Anh cho cùng một nội dung, vì vậy nếu công cụ tính theo token, con số tương ứng sẽ lớn hơn số từ. Mô hình embedding cũng có giới hạn độ dài đầu vào; phần vượt quá có thể bị cắt mà bạn không biết.
Cách chọn bằng thực nghiệm
- Chuẩn bị 30–50 câu hỏi thật kèm đáp án.
- Thử 2–3 cấu hình kích thước khác nhau.
- Đo tỷ lệ chunk đúng nằm trong top kết quả.
- Chọn cấu hình tốt nhất, không chọn theo cảm tính.
Xử lý PDF, bảng biểu và file scan trước khi chunking
Chunking chỉ tốt khi văn bản đầu vào sạch. Với tài liệu doanh nghiệp Việt Nam, phần lớn rắc rối nằm ở bước chuyển đổi.
- PDF xuất từ Word: thường trích chữ được, nhưng tiêu đề trang, chân trang, số trang lặp lại chèn vào giữa nội dung. Nên lọc bỏ trước khi chia.
- PDF scan, ảnh chụp: cần OCR. Kiểm tra lỗi dấu tiếng Việt sau OCR, vì ‘phụ cấp’ thành ‘phu cap’ sẽ làm tìm kiếm kém đi.
- Bảng biểu: cắt ngang bảng làm mất tiêu đề cột. Nên giữ trọn bảng trong một chunk, hoặc chuyển mỗi hàng thành câu có đủ tên cột, ví dụ ‘Gói bảo trì Tiêu chuẩn: số lần đến tận nơi 2 lần mỗi tháng’.
- Excel: thường nên đưa vào công cụ truy vấn dữ liệu thay vì chunk như văn bản.
- Slide: mỗi slide là một chunk tự nhiên, nhớ kèm tiêu đề bài trình bày.
Gắn ngữ cảnh vào từng chunk
Một kỹ thuật hiệu quả là thêm vào đầu mỗi chunk tên tài liệu, tên chương, mục. Chunk ‘Thời hạn: 30 ngày’ trở thành ‘Chính sách đổi trả 2026 › Điều kiện đổi hàng › Thời hạn: 30 ngày’. Chi tiết nhỏ này giúp tìm kiếm chính xác hơn rõ rệt.
Siêu dữ liệu đi kèm chunk nên có gì
Mỗi chunk không chỉ là đoạn văn bản. Nó nên mang theo siêu dữ liệu (metadata) để lọc, trích dẫn và cập nhật.
- Tên và đường dẫn tài liệu gốc: để chatbot trích dẫn và người dùng mở file kiểm tra.
- Vị trí: số trang, tên mục, số điều.
- Phiên bản và ngày hiệu lực: rất quan trọng với quy chế, bảng giá, chính sách thay đổi theo năm.
- Phòng ban, chi nhánh, đối tượng: để lọc đúng quy định cho nhân viên văn phòng hay công nhân, chi nhánh Thủ Đức hay Bình Dương.
- Mức truy cập: tài liệu chỉ dành cho kế toán không được trả cho nhân viên kinh doanh.
Khi có metadata, hệ thống có thể lọc trước rồi mới tìm ngữ nghĩa. Câu hỏi ‘chi nhánh Bình Dương làm ca mấy giờ’ chỉ tìm trong chunk thuộc Bình Dương, tránh lấy nhầm giờ làm của văn phòng chính.
Cập nhật tài liệu
Khi quy chế mới thay thế quy chế cũ, cần xóa hoặc đánh dấu hết hiệu lực các chunk cũ. Nếu không, chatbot sẽ trộn quy định cũ và mới trong cùng câu trả lời.
Lỗi chunking thường gặp và cách nhận biết
- Câu trả lời bị cụt: chatbot nêu bước 1–3 của quy trình nhưng thiếu bước 4–6. Thường do quy trình bị cắt thành hai chunk và chỉ một chunk được lấy.
- Nhầm đối tượng: chunk ‘được hỗ trợ 50%’ không còn câu đứng trước nói rõ áp dụng cho ai. Cần chồng lấn hoặc gắn tiêu đề mục.
- Chunk toàn rác: mục lục, header, chân trang, bảng chữ ký chiếm chỗ trong kết quả tìm kiếm. Lọc bỏ ở bước tiền xử lý.
- Trùng lặp: cùng một nội dung có trong 3 file bản nháp, bản chính, bản sửa. Kết quả tìm kiếm bị chiếm bởi các bản sao.
- Bảng vỡ: số liệu tách khỏi tên cột, AI đọc ‘2 lần’ mà không biết là 2 lần gì.
- Dùng một cấu hình cho mọi loại file: hợp đồng, biên bản họp và FAQ có cấu trúc rất khác nhau.
Cách phát hiện nhanh nhất là mở xem trực tiếp các chunk được lấy ra cho những câu hỏi trả lời sai. Phần lớn công cụ RAG như Dify, AnythingLLM, Open WebUI đều cho xem nguồn được dùng.
Quy trình chunking gợi ý cho kho tài liệu nội bộ
Dưới đây là quy trình thực tế cho một công ty muốn xây chatbot hỏi đáp quy định nội bộ.
- Kiểm kê tài liệu: liệt kê file, xác định bản hiện hành, loại bỏ bản nháp và bản cũ.
- Chuẩn hóa định dạng: ưu tiên chuyển sang văn bản có cấu trúc như Markdown hoặc Word có heading rõ ràng.
- Phân nhóm theo loại: quy chế, biểu mẫu, hướng dẫn kỹ thuật, FAQ. Mỗi nhóm một cấu hình chunking.
- Chia theo cấu trúc trước, giới hạn kích thước sau: cắt theo mục, mục nào quá dài thì chia tiếp có chồng lấn.
- Gắn tiêu đề và metadata: tên tài liệu, mục, ngày hiệu lực, quyền truy cập.
- Kiểm tra mẫu: đọc ngẫu nhiên 20 chunk xem có tự hiểu được khi đứng một mình không.
- Đo bằng bộ câu hỏi: chỉnh lại nếu tỷ lệ tìm đúng thấp.
Tiêu chí đơn giản nhất để đánh giá một chunk: nếu đưa riêng đoạn này cho một nhân viên mới đọc, họ có hiểu nó nói về cái gì và áp dụng cho ai không. Nếu không, chunk đó cần thêm ngữ cảnh.
Đừng chỉnh tham số chunking theo cảm giác. Hãy mở xem các chunk được lấy cho 10 câu trả lời sai gần nhất; nguyên nhân thường lộ ra ngay, như bảng bị cắt hoặc chunk thiếu tiêu đề mục.
Muốn đưa AI vào công việc của doanh nghiệp? PCTech tư vấn, đánh giá mức sẵn sàng AI và triển khai chatbot, AI agent, tự động hóa cho doanh nghiệp.
10 câu hỏi, 2 phút, nhận mức độ và việc nên làm tiếp theo. Dùng thử ngay
Câu hỏi thường gặp
Chunk size bao nhiêu là tốt nhất?
Không có con số chung. Điểm xuất phát hợp lý là vài trăm từ mỗi chunk với chồng lấn 10–20%, sau đó thử nghiệm bằng câu hỏi thật để điều chỉnh.
Context window lớn rồi có cần chunking nữa không?
Vẫn cần với kho tài liệu lớn, vì đưa toàn bộ vào mỗi câu hỏi tốn chi phí, chậm và có thể làm mô hình bỏ sót chi tiết. Với vài tài liệu ngắn, đưa nguyên văn đôi khi là lựa chọn đơn giản hơn.
Chunking file Excel thế nào?
Bảng tính có cấu trúc thường nên được truy vấn trực tiếp hoặc chuyển mỗi hàng thành câu có tên cột. Cắt Excel như văn bản thường làm mất quan hệ giữa cột và giá trị.
Chồng lấn giữa các chunk để làm gì?
Chồng lấn giữ lại phần ngữ cảnh ở ranh giới, tránh việc một câu quan trọng bị cắt đôi hoặc mất câu dẫn giải thích nó áp dụng cho ai.
Đổi chiến lược chunking có phải tạo lại embedding không?
Có. Mỗi lần thay cách chia, toàn bộ chunk thay đổi nên phải tạo lại embedding và lập chỉ mục lại trong vector database.
Công cụ không cần code có cho chỉnh chunking không?
Nhiều nền tảng như Dify, Flowise, AnythingLLM cho chỉnh kích thước chunk và độ chồng lấn trong giao diện. Mức tùy biến sâu như chia theo cấu trúc có thể cần cấu hình nâng cao hoặc lập trình.
Bài viết liên quan
- RAG là gì? Cho AI đọc tài liệu nội bộ
- Embedding là gì? Cách AI hiểu nghĩa của văn bản
- Vector database là gì? Nền tảng cho AI đọc tài liệu nội bộ
- Reranker là gì? Tăng độ chính xác tìm kiếm cho RAG
- Xây kho tri thức (knowledge base) cho AI trả lời nội bộ
- Context window (cửa sổ ngữ cảnh) là gì? Ảnh hưởng gì khi dùng AI
- OCR là gì? Đọc hóa đơn, chứng từ tự động
- Cách trích xuất bảng và số liệu từ PDF bằng AI
