Chunking là gì — cắt tài liệu thành đoạn vừa phải để AI tìm và trả lời đúng

Bài này dành cho chủ doanh nghiệp và người quyết. Chunking được giải bằng ẩn dụ dễ hiểu, kèm các kiểu cắt, ảnh hưởng tới chất lượng trả lời và cách MONA áp dụng.

Vì sao đáng quan tâm: chunking là bước âm thầm nhưng quyết định độ chính xác của mọi chatbot tài liệu và hệ RAG. Cùng một kho dữ liệu, cắt sai khiến AI trả lời sai.

Hãy hình dung một cuốn sổ tay dày năm trăm trang. Hỏi một câu mà phải lật cả cuốn thì vừa lâu vừa dễ trượt. Nếu cuốn sổ được chia thành từng mục ngắn, mỗi mục dán nhãn rõ, thì tìm câu trả lời nhanh và đúng hơn nhiều.

Chunking chính là việc chia cuốn sổ đó thành các mục vừa phải. Mỗi đoạn là một mảnh đủ trọn một ý, được đánh dấu để sau này tìm lại.

Cắt quá vụn thì mỗi mảnh thiếu ngữ cảnh, đọc lên không hiểu. Cắt quá to thì một mảnh chứa nhiều ý lẫn lộn, tìm trúng mảnh nhưng vẫn lẫn rác. Cắt vừa tay là nghệ thuật chính của chunking.

Sau khi cắt, mỗi đoạn được biến thành một embedding và lưu vào vector database. Khi khách hỏi, hệ thống tìm các đoạn gần nghĩa nhất rồi đưa cho mô hình đọc và trả lời.

• Kích thước đoạn. Đo bằng số ký tự hoặc số token. To quá thì loãng, nhỏ quá thì cụt ý.
• Gối đầu giữa các đoạn. Cho hai đoạn liền nhau chồng nhau một phần để không cắt đứt câu giữa chừng.
• Cắt theo cấu trúc. Cắt theo tiêu đề, đoạn văn, mục — tôn trọng ranh giới ý thay vì cắt máy móc theo độ dài.

Vì vậy chunking không chỉ là chia nhỏ. Nó là chia sao cho mỗi mảnh vừa dễ tìm vừa đủ nghĩa để trả lời.

• Trả lời sát hơn. AI nhận đúng đoạn cần thay vì cả cục tài liệu, nên bám đúng ý.
• Ít bịa. Đoạn gọn, đúng ngữ cảnh thì mô hình ít bịa đặt hơn.
• Tra tài liệu nhanh. Nhân viên và khách tìm thấy đúng điều khoản, đúng mục trong giây lát.
• Tiết kiệm chi phí. Đưa vài đoạn đúng thay vì nhồi cả tài liệu giúp giảm token mỗi câu trả lời.
• Dễ kiểm chứng. Trả lời kèm đúng đoạn nguồn để người duyệt soi lại.

Chunking là chỗ ít ai để ý nhưng lại định đoạt việc chatbot tài liệu của doanh nghiệp đáng tin hay hay lạc.

Quy trình chuẩn gồm bốn nhịp:

• Đọc và làm sạch. Bóc chữ từ PDF, Word, web; bỏ phần thừa như đầu trang, chân trang.
• Cắt thành đoạn. Chia theo cấu trúc và kích thước đã chọn, có gối đầu để giữ mạch.
• Gắn nhãn nguồn. Mỗi đoạn ghi rõ thuộc tài liệu nào, mục nào, để truy ngược.
• Tạo embedding và lưu. Mỗi đoạn thành một vector, lưu vào kho để tìm theo nghĩa.

Khi khách hỏi, hệ thống tìm theo nghĩa ra các đoạn gần nhất, có thể chấm lại cho đúng nhất rồi mới đưa mô hình trả lời.

Giả sử khách hỏi về chính sách đổi trả. Sổ tay chính sách dài ba mươi trang đã được cắt thành các đoạn ngắn, mỗi đoạn một quy định.

Hệ thống không đọc cả ba mươi trang. Nó tìm đúng đoạn nói về đổi trả, lấy thêm một đoạn gối đầu cho đủ ngữ cảnh, rồi đưa mô hình trả lời gọn kèm nguồn.

Nếu tài liệu không được cắt, mô hình hoặc bị quá tải ngữ cảnh, hoặc trả lời chung chung. Chunking là thứ biến một cuốn sổ dày thành câu trả lời một dòng đúng chỗ.

Cùng một kho tài liệu, cách cắt quyết định chất lượng trả lời:

Khác biệt không nằm ở mô hình mạnh hay yếu, mà ở khâu chuẩn bị dữ liệu trước khi mô hình đọc.

Không có một kích thước đúng cho mọi tài liệu. Chọn kích thước là chọn điểm cân:

• Đoạn nhỏ. Tìm rất trúng, rẻ, nhưng dễ cắt đứt ý, câu trả lời có thể cụt.
• Đoạn to. Giữ trọn ngữ cảnh, nhưng một đoạn lẫn nhiều ý, tìm kém sắc và tốn token.
• Gối đầu. Cho hai đoạn chồng nhau một phần để không mất mạch ở chỗ cắt.

Cách làm đúng là đo trên câu hỏi thật của doanh nghiệp rồi chỉnh, không có con số chung cho mọi trường hợp.

Có nhiều cách cắt, chọn theo loại tài liệu và mức độ quan trọng của ngữ cảnh:

Thực tế thường phối hợp: cắt theo cấu trúc trước, rồi giới hạn độ dài và thêm gối đầu. Mục tiêu cuối là mỗi đoạn vừa dễ tìm vừa đủ tự đứng một mình.

• Cắt cứng theo độ dài. Cắt giữa câu, giữa điều khoản khiến đoạn mất nghĩa.
• Bỏ qua bảng và danh sách. Cắt vụn một bảng làm số liệu rời khỏi nhãn cột.
• Không gắn nhãn nguồn. Trả lời đúng nhưng không truy được lấy từ đâu, khó duyệt.
• Quên làm sạch. Để lẫn đầu trang, menu, mã trang vào đoạn làm nhiễu khi tìm.
• Cắt một lần rồi quên. Không đo lại trên câu hỏi thật để chỉnh kích thước.

Phần lớn lỗi chatbot tài liệu trả lời lạc bắt nguồn từ khâu cắt chứ không phải từ mô hình. Đây là chỗ đáng đầu tư công.

MONA tiếp cận chunking như một khâu kỹ thuật có đo đạc, không cắt theo cảm tính:

• Khảo loại tài liệu. Hợp đồng, chính sách, mô tả sản phẩm mỗi loại có cấu trúc riêng cần cách cắt riêng.
• Cắt tôn trọng cấu trúc. Theo mục và điều khoản, giữ bảng nguyên, thêm gối đầu.
• Đo trên câu hỏi thật. Lấy bộ câu hỏi của doanh nghiệp, so chất lượng trả lời theo từng cách cắt.
• Gắn nhãn để truy nguồn. Mỗi câu trả lời chỉ được đúng đoạn và đúng tài liệu gốc.

Việc xử lý tài liệu nội bộ luôn gắn với bảo mật. MONA tuân thủ guardrails và nguyên tắc dữ liệu theo Nghị định 13/2023, tài liệu doanh nghiệp được giữ trong phạm vi kiểm soát.

Chunking trở nên quan trọng ngay khi doanh nghiệp muốn AI trả lời dựa trên tài liệu của mình:

• Chatbot tài liệu. Trả lời khách dựa trên chính sách, sản phẩm, hướng dẫn.
• Trợ lý nội bộ. Nhân viên tra quy trình, hợp đồng, sổ tay nhanh.
• Tra cứu pháp lý, kỹ thuật. Lượng tài liệu dài, cần chỉ đúng điều khoản.
• Tổng hợp nhiều nguồn. Gom nhiều tài liệu thành một nơi hỏi đáp chung.

Khi dữ liệu còn ít và đơn giản, chunking nhẹ nhàng. Khi tài liệu nhiều, dài và quan trọng, cắt khéo là yếu tố sống còn của độ chính xác.

Chunking là khái niệm dễ hiểu nhưng làm tốt cần kinh nghiệm với từng loại tài liệu thật. Doanh nghiệp nên cân nhắc MONA khi:

• Muốn một chatbot hoặc trợ lý trả lời đúng dựa trên tài liệu riêng, không bịa.
• Có khối tài liệu lớn, nhiều định dạng, cần xử lý sạch và cắt khéo.
• Cần câu trả lời truy được nguồn để bộ phận pháp lý hoặc quản lý duyệt.
• Muốn một hệ RAG chạy ổn định, có đo đạc và bảo mật.

Hệ tri thức và chatbot tài liệu của MONA xây trên nền chunking được đo đạc cẩn thận. Tham khảo LMS AI cho đào tạo, tra cứu nội bộ và Sale AI cho tư vấn khách dựa trên đúng tài liệu sản phẩm.