Chunking RAG: tách đoạn mà giữ bảng và ngoại lệ

Đăng ngày 27/10/2026

Chunking RAG là việc chia tài liệu thành các đơn vị để tìm và cung cấp ngữ cảnh cho mô hình. Quyết định này ảnh hưởng việc một câu điều kiện, hàng bảng hay chú thích có còn đi cùng phần nó giải thích hay không. Đoạn ngắn có thể dễ tìm nhưng thiếu nghĩa; đoạn dài có thể chứa đủ thông tin mà làm chìm phần cần đọc. Vì vậy, chọn cách tách phải bắt đầu từ những câu hỏi cần giải quyết và lỗi cụ thể có thể quan sát.

Bài dùng kho quy trình kỹ thuật giả định tại một doanh nghiệp Việt Nam. Nhân viên cần tìm đúng phần tài liệu chứa bảng điều kiện và ngoại lệ để chuẩn bị hồ sơ cho người phụ trách kiểm. Ví dụ không đưa số ngưỡng kỹ thuật, chỉ dẫn thao tác thiết bị hay kết luận nghiệm thu. Không có kho tài liệu thật hoặc kết quả đo được tạo trong bài. Mục tiêu là giữ căn cứ nguyên nghĩa qua quá trình chia đoạn, tìm kiếm và mở nguồn để kiểm lại.

Tách cấu trúc và chia đoạn là hai việc khác nhau

Tài liệu Unstructured phân biệt nhận diện các thành phần tài liệu với bước ghép hoặc chia chúng thành đoạn phục vụ RAG. Trong cách làm được mô tả, thành phần quá lớn vẫn có thể phải tách tiếp; chồng lấn cũng có phạm vi và điều kiện riêng. Đây là ví dụ cơ chế từ tài liệu dự án, không phải bảo đảm mọi bảng và đoạn nghĩa luôn được giữ nguyên. Bài dẫn phần thư viện hiện hành, không coi trang API cũ đã chuyển vào mục kế thừa là hướng dẫn tích hợp mới[1].

Với kho giả định, lỗi có thể đã xuất hiện trước khi chia đoạn. Một bản scan đọc sai dấu, thứ tự hai cột bị đảo hoặc chú thích bị mất sẽ làm nguyên liệu đầu vào sai. Tăng độ dài đoạn không tạo lại phần chữ đã mất. Đội dự án nên giữ một bước đối chiếu bản chuyển đổi với tài liệu nguồn, đặc biệt ở bảng và điều kiện ngoại lệ. Chỉ sau đó mới so sánh ranh giới chia trên cùng nguyên liệu đã kiểm.

Nên lưu riêng bản gốc, bản nội dung đã chuyển đổi và cấu hình tạo đoạn. Khi lỗi được phản ánh, người kiểm biết mình đang xem sai do nhận chữ, do thứ tự đọc hay do ghép thiếu ngữ cảnh. Nếu chỉ còn một thư mục các đoạn rời, rất khó xác định bước nào tạo ra sai khác. Việc lưu dấu vết cần theo quyền và phạm vi tài liệu, không đồng nghĩa nhân bản toàn bộ kho sang mọi công cụ đang tham gia thử.

Ba đơn vị phục vụ ba công việc khác nhau

Tôi đề xuất phân biệt đoạn dùng để tìm, ngữ cảnh dùng để trả lời và phần nguồn người đọc mở để kiểm. Đoạn tìm có thể là phần nhỏ mang chủ đề cụ thể. Ngữ cảnh trả lời có thể cần thêm tiêu đề hoặc điều kiện liên quan. Phần mở kiểm cần đưa người đọc tới đúng trang, vùng và phiên bản nguồn. Chúng có thể trùng nhau trong tài liệu đơn giản, nhưng không nên buộc luôn giống nhau chỉ vì hệ thống ban đầu lưu một trường văn bản.

Chẳng hạn, một hàng bảng được tìm đúng theo tên hạng mục vẫn cần tên cột để biết giá trị thuộc điều kiện nào. Câu trả lời có thể cần chú thích ở cuối bảng, trong khi người kiểm muốn nhìn cả trang để xác nhận bố cục. Nếu hệ thống chỉ trả hàng bảng rời rồi dẫn tới đầu tệp, người kiểm phải tự ghép lại nghĩa. Nếu đưa cả tệp vào mô hình cho mọi câu hỏi, chi phí và lượng thông tin phải đọc lại có thể tăng không cần thiết.

Sự phân biệt này cũng giúp đo đúng. Tìm được đoạn ứng viên chưa có nghĩa ngữ cảnh cuối cùng đủ căn cứ. Ngữ cảnh đủ chưa có nghĩa bản nháp giữ đủ điều kiện. Người dùng mở được tệp chưa có nghĩa mở đúng vị trí được dẫn. Một cấu hình nên được kiểm qua cả ba công việc, để biết nó giúp bước nào và đẩy thêm gánh nặng sang bước nào.

Đơn vị nghĩa phải gắn với đối tượng đang được nói tới

Dense X Retrieval nghiên cứu thay đổi đơn vị truy hồi giữa đoạn, câu và mệnh đề tự đủ nghĩa trên kho Wikipedia tiếng Anh. Mệnh đề trong phương pháp được tạo để diễn đạt một ý riêng, giữ thông tin cần hiểu như đối tượng được nhắc đến. Đây không phải chỉ cắt tại dấu chấm. Kết quả trong các nhiệm vụ nghiên cứu giúp đặt câu hỏi về độ hạt của đơn vị tìm; chúng không chứng minh mọi kho kỹ thuật tiếng Việt nên được chuyển toàn bộ thành mệnh đề[2].

Trong quy trình giả định, câu “trường hợp này áp dụng ngoại lệ bên dưới” chưa tự đủ nghĩa khi bị tách khỏi đoạn trước. Một hệ thống có thể thêm đường dẫn tiêu đề và giữ quan hệ tham chiếu để hỗ trợ đọc. Nếu dùng mô hình viết lại thành câu độc lập, phần ấy là nội dung dẫn xuất cần được nhận diện. Không nên ghi đè văn gốc rồi coi câu đã diễn giải là nguyên văn của quy trình được phê duyệt.

Cần kiểm những từ nối và phạm vi: chỉ áp dụng cho đối tượng nào, ngoại trừ trường hợp gì và điều kiện nào phải đồng thời thỏa mãn. Tách một vế ra khỏi câu ghép có thể làm thay đổi điều được hiểu dù mọi từ còn đúng. Khi chưa có cách biểu diễn đủ rõ, giữ nguyên nhóm nội dung lớn hơn hoặc chuyển người kiểm sẽ phù hợp hơn việc cố làm mọi đoạn ngắn bằng nhau.

Tiêu đề, bảng và chú thích cần quan hệ có thể truy ra

DoclingDocument mô tả một cách biểu diễn tài liệu có văn bản, bảng, hình, quan hệ phân cấp và thông tin vị trí khi có sẵn. Các phần tử có thể tham chiếu cha, con và thứ tự đọc. Giá trị ở đây là có nơi để giữ quan hệ thay vì chỉ còn chuỗi chữ. Tuy nhiên, mô hình biểu diễn không chứng minh công cụ chuyển đổi đã nhận đúng mọi thành phần trong tệp. Dữ liệu cấu trúc vẫn phải được đối chiếu với nguồn[3].

Gói căn cứ tôi đề xuất gồm năm phần: đoạn đích, đường dẫn tiêu đề, cấu trúc bảng liên quan, điều kiện kèm theo và nguồn cùng phạm vi được dùng. Bên cạnh gói ấy là trạng thái kiểm. Không phải câu hỏi nào cũng có bảng hay chú thích; phần không có nên được ghi đúng là không áp dụng, khác với chưa lấy được. Với câu hỏi cần bảng, tên bảng, hàng, cột và đơn vị nếu có phải được nối đủ để hiểu điều đoạn đích đang nói.

Một chú thích có thể áp dụng cho một ô, cả hàng hoặc toàn bảng. Không nên tự gắn nó cho mọi đoạn chỉ vì cùng trang. Người phụ trách tài liệu cần xác nhận quan hệ khi định dạng không rõ. Nếu tài liệu có hai bảng gần nhau với tiêu đề tương tự, mã vị trí phải giúp phân biệt chúng. Sự gần nhau trên trang hỗ trợ tìm quan hệ, nhưng không tự thay việc kiểm quan hệ ấy.

Giới hạn ký tự và token chưa phải độ dài đủ nghĩa

Tài liệu chunking của Docling mô tả cách tinh chỉnh phân cấp theo bộ tách token, chia phần quá lớn và có thể ghép phần liền kề phù hợp. Nó còn có tùy chọn lặp tiêu đề khi bảng trải qua nhiều đoạn, kèm hành vi khác khi hàng quá rộng tùy cấu hình. Đây là các lựa chọn có thể kiểm, không phải lời hứa tiêu đề luôn được giữ bất kể thiết lập. Bài không chạy thư viện hoặc lấy một giá trị mặc định thành chuẩn cho tài liệu của doanh nghiệp[4].

Độ dài tính bằng ký tự, từ hiển thị và token không đồng nhất. Đội kỹ thuật cần biết cấu hình giới hạn đang áp dụng cho bước nào và bộ tách token nào. Không nên dùng số từ tiếng Việt trong một trang để suy chính xác lượng token mà mọi mô hình nhìn thấy. Phần tiêu đề hoặc thông tin được ghép thêm cũng chiếm chỗ; chỉ đo văn bản của đoạn đích có thể bỏ qua ngữ cảnh thực tế được cung cấp.

Nên xuất mẫu đoạn sau tất cả bước ghép và cắt cuối cùng. Một hàng bảng trông nguyên vẹn ở bản trung gian vẫn có thể bị cắt khi đưa vào giới hạn ngữ cảnh. Bộ kiểm cần xem đúng dữ liệu cuối, gồm phần tiêu đề được lặp, chú thích và mã nguồn. Nếu kết quả khác dự kiến, sửa cấu hình hoặc phạm vi câu hỏi dựa trên lỗi ấy, thay vì chỉ tăng giới hạn đến khi không còn cảnh báo kỹ thuật.

Chồng lấn giữ phần gần nhau, chưa nối mọi phụ thuộc

Cho hai đoạn chia sẻ một phần nội dung có thể giúp câu nằm sát ranh giới không bị mất hết ngữ cảnh liền kề. Nhưng ngoại lệ ở phụ lục khác không tự xuất hiện nhờ chồng lấn quanh một đoạn. Tương tự, lặp cả tiêu đề dài vào nhiều đoạn có thể làm kết quả tìm chứa nhiều phần giống nhau. Khi thử, cần phân biệt căn cứ mới được bổ sung với cùng một căn cứ được trả lại nhiều lần.

Một phương án khác là tìm theo đoạn con rồi lấy thêm phần cha hoặc nội dung có quan hệ rõ. Cách này cần giới hạn: phần mở rộng có còn cùng bản, đúng đối tượng và trong quyền của người hỏi không. Trả toàn bộ chương chỉ vì một đoạn trong chương liên quan có thể đưa thêm nội dung ngoài việc cần làm. Đội thiết kế nên nêu rõ điều kiện mở rộng và ghi phần nào thực sự được lấy, không chỉ tên một thuật toán.

Bộ kiểm có thể đặt câu hỏi cần một ý riêng, câu cần cả nhóm điều kiện và câu cần nối hai mục. Nếu tăng chồng lấn chỉ cải thiện nhóm đầu mà làm nhóm sau lẫn nhiều đoạn trùng, nên giữ kết quả theo loại câu hỏi. Một mức tổng tăng chưa đủ cho quyết định dùng chung. Không có số chồng lấn được đo trong tình huống bài viết; các lựa chọn ở đây là phương án cần thử trên kho có quyền.

Biểu diễn theo ngữ cảnh và cây tóm tắt giải bài toán khác nhau

Late Chunking nghiên cứu tạo biểu diễn token với ngữ cảnh dài trước, rồi gộp theo các đoạn để có vector cho từng phần. Nó khác việc chép thêm văn bản quanh đoạn vào ngữ cảnh của mô hình trả lời. Phiên bản nghiên cứu đã đọc cũng nêu những trường hợp cách thông thường có thể tương đương hoặc tốt hơn. Vì vậy, đây là một hướng thử có điều kiện về mô hình biểu diễn và độ dài, không phải cách sửa mọi lỗi bảng hoặc chú thích[5].

RAPTOR xây các tầng tóm tắt qua quá trình biểu diễn, gom nhóm và tổng hợp, cho phép truy hồi ở nhiều mức chi tiết. Nó hỗ trợ suy nghĩ về câu hỏi cần cái nhìn rộng, nhưng phần tóm tắt là sản phẩm được tạo từ nguồn. Không nên lấy một câu ở tầng tổng hợp để thay thế điều kiện nguyên văn khi người đọc cần kiểm một quy định cụ thể. Bài chỉ dùng cơ chế nghiên cứu làm tham chiếu, không chuyển kết quả benchmark thành hiệu quả của kho giả định[6].

Khi so sánh các hướng ấy, cần ghi rõ thứ gì thay đổi: nội dung đoạn, biểu diễn để tìm, cách mở rộng ngữ cảnh hay nguồn được dẫn. Nếu đổi tất cả cùng lúc, vẫn có thể đánh giá cả cấu hình như một gói nhưng khó biết phần nào giúp. Với kho quy trình có điều kiện quan trọng, nên giữ đường quay về nguồn gốc và kiểm phần diễn giải dẫn xuất riêng trước khi sử dụng nó làm căn cứ trả lời.

Câu hỏi cần đủ nhiều căn cứ mới thử được ranh giới

HiChunk, công bố tại ACL năm 2026, phân tích việc câu hỏi chỉ cần rất ít câu chứng cứ có thể che khác biệt giữa các cách chia đoạn. Bộ HiCBench kết hợp ranh giới phân cấp được gán nhãn với câu hỏi và câu trả lời tổng hợp có kiểm lọc, rồi xem các tầng chia đoạn, truy hồi và trả lời. Có thể học cách dựng câu hỏi cần đủ căn cứ từ thiết kế ấy, nhưng không nên gọi dữ liệu tổng hợp là câu hỏi thực địa hay dùng kết quả của nó để bảo đảm cho tiếng Việt[7].

Bộ câu hỏi cho kho giả định nên có ca chỉ tìm một tên mục, ca cần toàn bộ điều kiện trong bảng và ca cần bảng cùng ngoại lệ ở phần khác. Kết quả mong đợi phải ghi các mảnh cần thấy và phần không được suy rộng. Một câu hỏi rất dễ mà đoạn nào cũng chứa câu trả lời sẽ không giúp chọn cấu hình. Ngược lại, câu không có đáp án trong tài liệu phải được đánh dấu thiếu nguồn, tránh dùng nó để kết luận chia đoạn kém.

Cũng cần thử những thay đổi có kiểm soát về cách hỏi. Giữ nguyên ý nhưng dùng từ viết tắt giúp xem cấu hình có tìm được đối tượng hay không. Đổi đối tượng hoặc phiên bản phải có kết quả khác khi căn cứ khác. Người phụ trách nghiệp vụ xác nhận sự khác biệt ấy trước khi chấm. Nếu chính đội dự án chưa thống nhất phần nào cần dẫn, một bảng điểm chi tiết vẫn có thể đo độ khớp với một đáp án chưa được xác nhận.

Thêm ngữ cảnh có thể tăng đủ ý và tăng nhiễu cùng lúc

Lost in the Middle khảo sát ảnh hưởng của độ dài và vị trí thông tin trên các mô hình cùng nhiệm vụ được thử trong nghiên cứu. Kết quả nhắc rằng có nhiều nội dung trong đầu vào chưa đồng nghĩa sử dụng tốt nội dung ấy. Bài không coi hành vi của các mô hình lịch sử là kết luận chung cho mọi mô hình hiện nay. Ở đây, nguồn hỗ trợ nhu cầu kiểm thứ tự và lượng ngữ cảnh, thay vì mặc định lấy thêm chương sẽ luôn tốt[8].

Với bảng điều kiện, đủ căn cứ có thể cần thêm phần đầu bảng và chú thích. Nhưng một chương đầy đủ còn chứa nhiều trường hợp không áp dụng. Người kiểm nên xem bản nháp có phân biệt các trường hợp hay trộn chúng thành quy tắc chung. Nếu câu trả lời chỉ thay đổi vì một đoạn không liên quan được đặt trước, cần giữ ca ấy để kiểm lại. Không chọn bản nghe hợp lý nhất rồi bỏ các lần cho kết quả khác.

Để so sánh, giữ cùng nguồn, quyền và phiên bản, đồng thời ghi ngân sách ngữ cảnh cuối cùng. Hai cấu hình trả cùng số đoạn chưa chắc đưa cùng lượng thông tin; một cấu hình có thể toàn đoạn ngắn, cấu hình kia có phần cha rất lớn. Kết quả cần đọc cùng lượng căn cứ, phần trùng và thời gian kiểm của người dùng. Chỉ khi biết điều kiện so sánh mới có thể giải thích vì sao một cấu hình được chọn.

Ca giả định giữ nguyên bảng và phần chưa thể kết luận

Nhân viên trong ví dụ cần chuẩn bị hồ sơ tra quy trình cho một hạng mục. Kết quả tìm đầu tiên có hàng bảng đúng tên nhưng thiếu tiêu đề cột và chú thích. Gói căn cứ ghi thiếu quan hệ bảng, thay vì cho mô hình đoán ý của một giá trị rời. Phương án theo cấu trúc lấy lại hàng cùng tiêu đề và chỉ dẫn tới chú thích liên quan. Nếu chú thích chưa được đọc đúng, hồ sơ vẫn giữ trạng thái cần bổ sung.

Ở nhánh khác, đoạn nhỏ tìm trúng một ngoại lệ nhưng điều kiện áp dụng nằm trong phần cha. Mở rộng có kiểm soát giúp người đọc thấy ngoại lệ thuộc nhóm đối tượng nào. Nếu nguồn cha và đoạn con đang thuộc hai phiên bản khác nhau, chưa được ghép để trả lời. Đây là lỗi phiên bản mà tăng độ dài không giải quyết. Người phụ trách cần xác nhận bản dùng rồi tạo lại các quan hệ phục vụ, giữ lịch sử đủ để biết những câu trả lời nào chịu ảnh hưởng.

Nhánh cuối có câu hỏi cần nối hai phụ lục. Một cấu hình tìm được từng mục nhưng bước trả lời chỉ nhận mục đầu do giới hạn ngữ cảnh. Sổ lỗi ghi rõ đã tìm thấy nhưng chưa cung cấp đủ, không quy ngay cho bộ tìm kiếm. Đầu ra là hồ sơ có vị trí và phần thiếu để người kiểm tiếp tục; chưa phải khẳng định hạng mục thỏa điều kiện kỹ thuật. Ví dụ không có thao tác vận hành hoặc kết quả chấp thuận thật.

Sổ lỗi ranh giới giúp chọn cấu hình và giữ đường quay lại

Tôi đề xuất ghi bốn nhóm lỗi: rơi tiêu đề hoặc đối tượng, cắt điều kiện và ngoại lệ, mất quan hệ bảng, nhầm nguồn hoặc phiên bản. Mỗi dòng nối câu hỏi với đoạn cần thấy, đoạn đã lấy, ngữ cảnh đã đưa và lỗi trong bản nháp nếu có. Cần giữ cả ca từng đúng để kiểm hồi quy. Một thay đổi giúp bảng dài chưa chắc giữ tốt các câu hỏi ngắn trong cùng kho.

Có thể bắt đầu bằng một cấu hình đơn giản làm mốc, rồi thêm cách theo mục và cách đoạn con kèm phần cha nếu dữ liệu cần. Nhóm nhỏ nên chọn ít loại tài liệu có người quản rõ; kho đa định dạng cần xem chi phí chuyển đổi và sửa cấu trúc. Chi phí còn gồm làm lại chỉ mục, lưu nội dung dẫn xuất và thời gian người kiểm. Không có bằng chứng đủ thì giữ cấu hình cũ cho phần đang phục vụ, thử phương án mới trên phạm vi tách được.

Hỏi đáp về chunking RAG

Có độ dài đoạn tốt nhất cho mọi tài liệu không? Không có căn cứ để chọn một giá trị chung trong bài này. Cấu trúc, loại câu hỏi, mô hình biểu diễn và lượng ngữ cảnh cần kiểm đều ảnh hưởng lựa chọn. Hãy bắt đầu bằng cấu hình mốc rồi xem lỗi cụ thể: thiếu tiêu đề, ngoại lệ hay phần bảng nào. Một giá trị mặc định của thư viện là điểm bắt đầu kỹ thuật, chưa phải kết quả kiểm của doanh nghiệp.

Tăng chồng lấn có giữ được hết ngoại lệ không? Không, vì ngoại lệ có thể nằm xa hoặc cần quan hệ tham chiếu mà phần chồng lấn không chạm tới. Nó cũng có thể làm nhiều kết quả trùng nhau. Cần kiểm xem có thêm căn cứ mới hay chỉ lặp chữ. Với nội dung ở mục khác, nên giữ quan hệ rõ và điều kiện mở rộng có quyền, thay vì tăng phần chồng lấn cho cả kho một cách đồng loạt.

Có nên dùng tóm tắt thay mọi đoạn gốc không? Chưa nên nếu người đọc cần kiểm một điều kiện cụ thể. Tóm tắt có thể giúp tìm chủ đề hoặc nhìn rộng, nhưng là nội dung dẫn xuất và có thể bỏ chi tiết. Hệ thống cần quay được về đúng nguồn cùng phiên bản, đồng thời phân biệt phần diễn giải với văn gốc. Trong kho kỹ thuật giả định, đầu ra vẫn là hồ sơ chờ người phụ trách kiểm, không phải xác nhận vận hành.

Tìm được đúng đoạn mà trả lời thiếu thì có phải lỗi chunking không? Cần xem ngữ cảnh cuối đã cung cấp gì. Có thể đoạn quan trọng bị cắt ở bước ghép, phần bảng thiếu tiêu đề hoặc mô hình bỏ điều kiện dù đã nhận đủ. Sổ lỗi nên giữ các tầng ấy riêng. Chỉ sửa cách chia sau khi xác định ranh giới gây thiếu căn cứ; nếu không, thay cấu hình có thể không chữa lỗi và làm hỏng ca đang đúng.

Nguồn, phương pháp và giới hạn suy luận

Bài được biên soạn có hỗ trợ AI từ tám nguồn gốc đã mở đọc ngày 27/10/2026 trong phạm vi ghi tại hồ sơ nguồn. Các nghiên cứu được dẫn theo phiên bản cụ thể; HiChunk dùng bản ACL tháng 7/2026, Late Chunking dùng bản v3. Tài liệu Docling và Unstructured là tài liệu dự án; nghiên cứu có tác giả từ Jina AI, Weaviate và Tencent được nhận diện nguồn gốc thương mại. Không xem mô tả hoặc kết quả của bên phát triển là kiểm chứng độc lập cho kho của doanh nghiệp.

Ba đơn vị xử lý, gói căn cứ và sổ lỗi ranh giới là phân tích riêng cho tình huống giả định. Hình được tự thiết kế, không chép sơ đồ hay bảng nghiên cứu. Chưa có chạy thư viện, gọi dịch vụ, chuyển đổi tài liệu thật, đo benchmark hay thử thực địa. Bài không đưa ngưỡng kỹ thuật, chỉ dẫn vận hành, kết luận an toàn hoặc nghiệm thu; chưa được chuyên gia thẩm định. Kết quả theo mẫu và ngôn ngữ nguồn không được quy đổi thành tỷ lệ hiệu quả tại Việt Nam.