RAG cho bảng dữ liệu: Truy xuất từng dòng thay vì toàn bộ bảng

Trong các hệ thống RAG (Retrieval-Augmented Generation) doanh nghiệp, việc xử lý dữ liệu dạng bảng thường gây khó khăn khi truy xuất toàn bộ bảng cho mỗi câu hỏi, khiến mô hình phải tự lọc thông tin không liên quan. Bài viết này giới thiệu phương pháp chia nhỏ từng dòng dữ liệu thành các chunk riêng biệt, kèm theo tiêu đề cột, giúp mô hình chỉ nhận đúng thông tin cần thiết, tiết kiệm token và tăng độ chính xác. Kỹ thuật này được minh họa qua bảng trong bài báo Attention Is All You Need và một hợp đồng bảo hiểm xe hơi, cho thấy hiệu quả rõ rệt khi tỷ lệ tiết kiệm ngữ cảnh tăng theo số dòng của bảng.

Vấn đề: Bảng dữ liệu là một khối, nhưng câu hỏi chỉ cần một dòng

Một hợp đồng bảo hiểm xe hơi in các điều khoản bảo hiểm dưới dạng bảng 40 dòng: mỗi dòng là một sự kiện được bảo hiểm, với các cột gồm sự kiện, giới hạn bồi thường, mức khấu trừ và điều kiện đủ tư cách. Khi người dùng hỏi "giới hạn bồi thường cho hành vi trộm xe là bao nhiêu?", cách truy xuất ngây thơ sẽ đánh chỉ mục toàn bộ bảng như một chunk duy nhất. Khi câu hỏi khớp, mô hình sinh sẽ nhận được 39 dòng sự kiện không liên quan cùng với một dòng cần thiết và phải tự đoán dòng nào người dùng muốn.

Sự không khớp này nằm giữa đơn vị thông tin của tài liệu (một hình chữ nhật bảng) và đơn vị câu hỏi của người đọc (một dòng). Câu hỏi như "giới hạn bồi thường cho hành vi trộm xe?" chỉ hỏi về một dòng. Câu hỏi như "những sự kiện nào được bảo hiểm?" lại cần toàn bộ bảng. Một hệ thống truy xuất chỉ cung cấp hình chữ nhật bảng sẽ trả lời tốt câu hỏi thứ hai nhưng xử lý sai câu hỏi đầu tiên.

Giải pháp không phải là chọn một quy mô cố định, mà là cung cấp cả hai quy mô và để bộ điều phối (dispatcher) lựa chọn dựa trên câu hỏi.

Xây dựng chỉ mục cấp dòng

Những gì bộ phân tích cú pháp đã xuất ra

Cả Docling và Azure Document Intelligence đều xuất bảng dưới dạng dòng markdown-pipe trong line_df. Một bảng có 4 dòng dữ liệu sẽ trở thành 6 dòng: một dòng tiêu đề (| Col1 | Col2 | ... |), một dòng phân tách (| --- | --- | ... |), và một dòng dữ liệu tương ứng cho mỗi dòng.

Bốn quy tắc phát hiện bảng được áp dụng nhất quán:

• Một dòng pipe bắt đầu và kết thúc bằng |, với ít nhất một pipe bên trong
• Dòng phân tách (phần bên trong là gạch ngang, dấu hai chấm và pipe) đánh dấu ranh giới giữa tiêu đề và thân bảng
• Các dòng pipe liên tiếp trên cùng trang, hoặc qua ngắt trang liền kề, thuộc cùng một bảng
• Bất kỳ dòng nào không phải pipe chen vào giữa đều đặt lại nhóm

Một chunk cho mỗi dòng dữ liệu

Hàm serialize_table_rows chuyển mỗi dòng dữ liệu của mọi bảng thành một chunk có thể truy xuất. Quá trình bao gồm: nhóm các dòng pipe thành các bảng, đọc tiêu đề từ dòng phía trên dòng phân tách, và xuất ra một dòng kết quả cho mỗi dòng dữ liệu.

Điểm mấu chốt nằm ở định dạng tuần tự hóa: mỗi dòng dữ liệu được chuyển thành chuỗi cột: giá trị | cột: giá trị | .... Sự lựa chọn này có chủ đích vì mô hình ngôn ngữ đọc hình dạng đó tự nhiên như một đoạn văn, và bộ truy xuất hiện tại — dù khớp từ khóa hay embedding — đều có thể xử lý mà không cần thay đổi. Người đọc nhận kết quả sẽ thấy một dòng tự giải thích (tên cột đi kèm với giá trị), thay vì một ô dữ liệu trần trụi.

Kiến trúc tuần tự hóa từng dòng dữ liệu trong bảng

Truy xuất ở hai quy mô

Chỉ mục cấp dòng là một quy mô bổ sung, không phải thay thế. Bộ điều phối chọn quy mô dựa trên hình dạng câu hỏi:

• Truy vấn cụ thể ("giới hạn bồi thường cho trộm xe?", "độ phức tạp của self-attention?"): định tuyến đến chỉ mục cấp dòng, trả về một dòng kèm tiêu đề cột
• Truy vấn tổng hợp ("những sự kiện nào được bảo hiểm?", "những loại lớp nào được so sánh?"): chỉ mục cấp dòng vẫn hoạt động, nhưng mọi dòng của cùng bảng đều khớp; bộ điều phối nhận thấy table_id trùng lặp và mở rộng trở lại toàn bộ bảng
• Truy vấn hỗn hợp ("tóm tắt giới hạn trộm xe và so sánh với giới hạn hỏa hoạn"): hai dòng trong cùng một bảng, mô hình sinh kết hợp câu trả lời từ cả hai

Quy tắc mở rộng từ cấp dòng lên cấp bảng được xác định rõ: khi k dòng dữ liệu của cùng table_id đều khớp với câu hỏi và k chiếm phần lớn bảng thì coi như khớp ở mức bảng. Ngưỡng thực tế là k / n_body_rows ≥ 0.6. Dưới ngưỡng đó, câu trả lời ở cấp dòng là trung thực nhất.

Hai quy mô truy xuất dữ liệu bảng được bộ điều phối lựa chọn dựa trên hình dạng câu hỏi

Kết quả trên ví dụ thực tế

Bảng bảo hiểm xe hơi

Với câu hỏi "giới hạn bồi thường cho hành vi trộm xe là bao nhiêu?", hàm tuần tự hóa trả về một dòng duy nhất dài 122 ký tự:

"Sự kiện được bảo hiểm: Trộm xe | Giới hạn: 25.000 EUR | Khấu trừ: 500 EUR | Điều kiện: Lắp định vị đang hoạt động"

Toàn bộ bảng (8 dòng trong ví dụ) dài 943 ký tự — tỷ lệ tiết kiệm 7,7 lần. Với hợp đồng 40 dòng, con số này lên tới khoảng 40 lần. Mô hình sinh chỉ đọc đúng dòng cần thiết, không thể trả lời nhầm giới hạn hỏa hoạn hay mức khấu trừ phá hoại.

Bài báo Attention Is All You Need

Bảng 1 (trang 6) có 4 dòng dữ liệu, mỗi dòng là một loại lớp: Self-Attention, Recurrent, Convolutional, Self-Attention (giới hạn). Các cột gồm Loại lớp, Độ phức tạp mỗi lớp, Số thao tác tuần tự, Độ dài đường đi tối đa.

• Truy vấn cụ thể "Độ phức tạp của self-attention mỗi lớp?": trả về dòng Self-Attention (trang 6, dòng 4) với 124 ký tự ngữ cảnh. Toàn bộ bảng là 528 ký tự — tỷ lệ 4,3 lần
• Truy vấn tổng hợp "Những loại lớp nào được so sánh?": bốn dòng đều khớp, bộ điều phối mở rộng trở lại toàn bộ bảng — không có sự thoái lui so với bộ truy xuất cấp bảng

So sánh tỷ lệ kích thước ngữ cảnh trên bảng Attention, cho thấy khoảng cách tăng theo số dòng

Xử lý trường hợp khó: tiêu đề nhiều dòng

Các bộ phân tích cú pháp thực tế không phải lúc nào cũng xuất ra một dòng tiêu đề duy nhất. Trên bảng 2 của bài báo Attention (BLEU và Training Cost), tiêu đề in trong PDF trải dài hai dòng. Docling làm phẳng thành dòng pipe đầu tiên với các ô trống, dòng phân tách, sau đó là một dòng dữ liệu thực chất là dòng tiêu đề thứ hai trước khi các con số bắt đầu.

Một bộ tuần tự hóa đơn dòng sẽ đọc dòng đầu tiên làm tiêu đề và dòng tiêu đề thứ hai làm dòng dữ liệu đầu tiên — gây ra lỗi âm thầm. Giải pháp nằm trong bước fold_multirow_header: phát hiện ô trống (dấu hiệu của cột hợp nhất từ nhiều cột), điền tiêu đề mở rộng sang phải, rồi kiểm tra xem dòng dữ liệu đầu tiên có phải là tiêu đề phụ (toàn nhãn, không có số, với số thực ở dòng bên dưới) hay không. Nếu đúng, nối hai cấp tiêu đề từng cột và bỏ dòng tiêu đề phụ khỏi phần dữ liệu. Quy trình này được bảo vệ cẩn thận để không ảnh hưởng đến các bảng thông thường.

Tích hợp vào hệ thống RAG hiện có

Chỉ mục cấp dòng nằm cạnh line_df, không nằm trong nó. Hợp đồng của bộ phân tích cú pháp không thay đổi và mọi consumer hiện tại vẫn hoạt động bình thường. Kết quả được lưu dưới dạng file parquet riêng (row_df.parquet).

Bộ truy xuất có thêm cờ use_row_level: bool bên cạnh các cờ use_toc, use_keywords, use_dense. Bộ phân tích câu hỏi (từ bài viết 6) đặt cờ này dựa trên hình dạng câu hỏi: truy vấn cụ thể với tài liệu có bảng sẽ bật, truy vấn tổng hợp tắt, truy vấn hỗn hợp bật và để quy tắc mở rộng xử lý việc kết hợp.

Tóm lại

Việc chia nhỏ từng dòng dữ liệu thành các chunk riêng biệt — mỗi chunk đi kèm tiêu đề cột — giúp hệ thống RAG xử lý hiệu quả các câu hỏi cụ thể về dữ liệu bảng. Bộ điều phối chọn quy mô phù hợp dựa trên hình dạng câu hỏi: truy vấn cụ thể đi thẳng đến cấp dòng, truy vấn tổng hợp mở rộng về cấp bảng. Kết quả cho thấy tỷ lệ tiết kiệm ngữ cảnh tăng theo số dòng của bảng — từ 4,3 lần trên bảng nhỏ đến 40 lần trên bảng lớn — giúp giảm chi phí token và tăng độ chính xác của câu trả lời. Các tiêu đề nhiều dòng được xử lý ngay trong bộ tuần tự hóa, đảm bảo không ảnh hưởng đến các bảng thông thường. Kỹ thuật này đặc biệt hữu ích cho các doanh nghiệp Việt Nam đang triển khai hệ thống tra cứu thông minh trên kho tài liệu nội bộ chứa nhiều bảng biểu như hợp đồng, báo cáo tài chính hay hồ sơ kỹ thuật.