Chunking: Cách bạn chia nhỏ corpus dựa trên bản chất của tài liệu
Một chunk là đơn vị nhỏ nhất được truy xuất (retrieved). Phương pháp chunking được lựa chọn dựa trên cấu trúc của tài liệu nguồn, chứ không phải dựa trên một kích thước mặc định tùy tiện.
Phương pháp Chunking | Cơ chế hoạt động | Khi nào nên áp dụng |
Fixed-size (Kích thước cố định) | Chia thành các đoạn có độ dài đồng đều (đi kèm phần chồng lấn / overlap) bất kể cấu trúc văn bản. | Văn bản đồng nhất, phi cấu trúc (unstructured text) nơi các ranh giới tự nhiên mờ nhạt; phương pháp đơn giản nhất để vận hành. |
Semantic (Theo ngữ nghĩa) | Chia theo ranh giới ý nghĩa, sự chuyển đổi chủ đề (topic shifts), hoặc các nhóm câu liên kết chặt chẽ với nhau. | Các đoạn văn xuôi cần chunk được truy xuất phải mang tính độc lập, tự trọn vẹn ý nghĩa để trả lời chính xác; giúp giảm việc cắt ngang giữa chừng một ý tưởng. |
Hierarchical (Phân cấp) | Giữ nguyên cấu trúc văn bản: phần, chương, mục con, và truy xuất ở cấp độ phân cấp phù hợp nhất. | Tài liệu có cấu trúc cao (hợp đồng, sổ tay hướng dẫn, chính sách) nơi ngữ cảnh của từng phần chứa đựng ý nghĩa quan trọng. |
Indexing: Cách làm cho chunks có thể tìm kiếm được, dựa trên cách đặt câu hỏi
Indexing quyết định định nghĩa của sự "tương đồng" (similarity) khi có truy vấn gửi đến. Chiến lược này được lựa chọn dựa trên hành vi và định dạng của câu truy vấn (query pattern).
Chiến lược Indexing | Tiêu chí khớp dữ liệu | Khi nào nên áp dụng |
Dense (Embeddings) | Độ tương đồng về ngữ nghĩa (semantic similarity) — khớp ý nghĩa, không bắt buộc khớp từ ngữ. | Các truy vấn diễn đạt khác với văn bản gốc; tìm kiếm theo lối diễn giải lại (paraphrase), theo ý định (intent) hoặc khớp khái niệm. |
Sparse (Keyword, ví dụ BM25) | Khớp chính xác thuật ngữ (exact terms), định danh (identifiers), mã hiệu, tên riêng. | Các truy vấn phụ thuộc chặt chẽ vào các tokens cụ thể: mã linh kiện, số hiệu điều luật, mã lỗi hệ thống. |
Hybrid (Kết hợp) | Kết hợp cả hai phương pháp trên và gộp chung kết quả lại. | Các mẫu truy vấn hỗn hợp (trường hợp phổ biến nhất trên production); giúp vớt lại các kết quả khớp chính xác mà tìm kiếm dense vô tình bỏ sót. |
Khi một hybrid index trả về hai danh sách kết quả được xếp hạng riêng biệt, chúng bắt buộc phải được gộp thành một. Reciprocal Rank Fusion (RRF) là phương pháp chuẩn mực, ít cần tinh chỉnh để thực hiện việc này: mỗi kết quả được chấm điểm dựa trên thứ hạng của nó trong từng danh sách, và điểm số tổng hợp sẽ ưu tiên các mục có thứ hạng cao ở cả hai bên. Điểm mấu chốt đối với một Architect là: việc kết hợp kết quả dense và sparse là một quyết định thiết kế có sẵn giải pháp mặc định rõ ràng và bảo vệ được.
Định hình các đánh đổi (Trade-offs)
Mọi thiết kế retrieval đều phải đánh đổi giữa 3 yếu tố:
Retrieval quality (Chất lượng truy xuất): Liệu đúng chunk cần tìm có được lấy về hay không?
Latency (Độ trễ): Quá trình truy xuất làm tăng thêm bao nhiêu thời gian cho mỗi request?
Maintenance (Chi phí bảo trì): Tốn bao nhiêu công sức và chi phí để giữ cho pipeline luôn chính xác khi tập tài liệu ngày một lớn lên và liên tục thay đổi?
Các chunks nhỏ hơn kết hợp với hybrid indexing thường giúp nâng cao chất lượng truy xuất nhưng lại làm tăng độ trễ; ngược lại, các chunks lớn hơn kết hợp với chỉ dùng dense indexing giúp giảm độ trễ và giảm tải bảo trì, nhưng lại dễ bỏ sót các truy vấn yêu cầu khớp chính xác từ khóa. Không có một cấu hình nào đúng tuyệt đối cho mọi bài toán, chỉ có điểm cân bằng phù hợp nhất với tập tài liệu và các dạng truy vấn cụ thể của bạn – một sự đánh đổi mà bạn có thể tự tin bảo vệ lập luận.
Chi phí · Độ phức tạp · Rủi ro
Chi phí (Cost): Hybrid indexing và kích thước chunk nhỏ hơn sẽ làm tăng cả năng lực tính toán khi truy xuất lẫn độ trễ trên mỗi request. Hãy định cỡ pipeline theo các mẫu truy vấn thực tế bạn đang có, chứ không phải theo kịch bản lý tưởng và cồng kềnh nhất có thể tưởng tượng ra.
Độ phức tạp (Complexity): Mọi lựa chọn về chunking và indexing đều là gánh nặng bảo trì khi kho tài liệu thay đổi. Một pipeline hoạt động chuẩn xác lúc launch có thể âm thầm xuống cấp khi có thêm các tài liệu mới được nạp vào.
Rủi ro (Risk): Mẫu thất bại nguy hiểm nhất là một câu trả lời tự tin được xây dựng trên một chunk sai. Chất lượng truy xuất không thể nhìn thấy bằng mắt thường ở đầu ra; nó bắt buộc phải được đo lường dựa trên một tập dữ liệu đã gán nhãn (labeled set), đó là lý do công việc này liên kết trực tiếp với hoạt động evaluation.
Nội dung bài viết thuộc lộ trình chuẩn bị chứng chỉ Claude Certified Architect, được tổng hợp và biên dịch từ tài liệu đào tạo chính thức của Anthropic PBC. Bản quyền nội dung gốc thuộc về Anthropic PBC. Bản dịch tiếng Việt và chú giải thực hành bởi HungPH Blog.
Thành viên gia nhập từ 19/09/2026