Bảng trong PDF cho RAG: Đừng Làm Phẳng Lưới Dữ Liệu

Khi câu trả lời bạn cần nằm trong một bảng, tại giao điểm của một hàng và một cột, việc làm phẳng PDF thành văn bản sẽ phá hủy mối liên hệ đó: nhãn rơi vào một chỗ, giá trị lại nằm ở chỗ khác, và mô hình phải đoán xem con số nào thuộc về hàng nào. Đây là nơi mà việc phân tích cú pháp ngây thơ âm thầm làm mất câu trả lời. Bài viết này là một phần bổ sung trong chuỗi bài về Kiến trúc Thông tin Doanh nghiệp, cung cấp một phương pháp chẩn đoán và năm thao tác có thể kết hợp (composable) để giữ nguyên cấu trúc lưới của bảng, thay vì sử dụng một cây quyết định cứng nhắc.

Hình ảnh minh họa về xử lý bảng trong tài liệu PDF

Vì Sao Bảng Làm Vỡ Pipeline RAG?

Quy trình RAG (Retrieval-Augmented Generation) tiêu chuẩn đọc một tệp PDF, chia nhỏ thành văn bản, nhúng các đoạn văn bản đó và truy xuất kết quả khớp nhất. Pipeline này xử lý các gạch đầu dòng và đoạn văn bản tốt. Tuy nhiên, khi câu trả lời cho một câu hỏi nằm bên trong một ô của bảng, pipeline tiêu chuẩn bắt đầu tạo ra các con số không có thực (hallucination), và thường không ai phát hiện ra cho đến khi một kiểm toán viên mở tài liệu gốc.

Có ba vấn đề chính xảy ra khi việc phân tích cú pháp bảng thất bại:

• Cấu trúc hàng và cột bị mất, khiến cho mô hình ngôn ngữ (LLM) ở phía sau nhìn thấy một chuỗi giá trị không có ý nghĩa quan hệ.
• Tiêu đề bảng thường chỉ nằm ở trang đầu tiên của một bảng dài nhiều trang, khiến các trang tiếp theo trở thành một mớ hỗn độn các con số.
• Việc trích dẫn nguồn ở cấp độ dòng bị phá vỡ vì không có cách nào để chỉ vào "hàng 47" khi hàng 47 đó chưa bao giờ được dựng lại như một hàng hoàn chỉnh.

Gốc rễ của cả ba thất bại này là: một bảng là dữ liệu mà ai đó đã đặt vào một định dạng trình bày (layout) vì định dạng phân phối yêu cầu như vậy. Việc phân tích cú pháp làm phẳng bảng thành văn bản sẽ phá hủy thứ mà người tạo tài liệu đã có. Cách tiếp cận đúng không phải là xử lý bảng tốt hơn như văn bản, mà là khôi phục chúng về dạng cấu trúc ban đầu càng sớm càng tốt và coi chúng như dữ liệu từ đó trở đi.

Bốn Cách Biểu Diễn Một Bảng Dữ Liệu

Cùng một bảng có thể tồn tại trong pipeline ở bốn cấp độ cấu trúc khác nhau. Việc chọn đúng cấp độ cho từng bảng là quyết định thiết kế đầu tiên, trước khi bất kỳ thao tác nào được chạy.

A. Dòng-như-một-dòng (Row-as-line)

Đây là mặc định, là những gì trình phân tích cú pháp tạo ra một cách tự nhiên. Mỗi hàng của bảng trở thành một hàng trong dữ liệu dạng dòng với kiểu "_type=table" và văn bản được hiển thị dưới dạng một hàng Markdown (| cột1 | cột2 | cột3 |). Dòng này giữ nguyên bounding box của nó trên trang, vì vậy việc đánh dấu và trích dẫn hoạt động giống như đối với văn xuôi. Cách biểu diễn này đủ cho các câu hỏi đọc thông tin từ bảng giống như đọc từ văn xuôi.

B. DataFrame Bảng Riêng (Separate table_df)

Khi bạn cần thao tác trên hình dạng 2D của bảng, bạn tách bảng ra khỏi dòng dữ liệu thông thường vào một DataFrame riêng, với tiêu đề cột được giữ làm tên cột và các hàng là các hàng của DataFrame. Ba thao tác yêu cầu điều này: nối một bảng tiếp tục qua năm trang mà chỉ có tiêu đề ở trang đầu, chiếu xuống còn hai cột trong số mười bốn cột vì câu hỏi chỉ hỏi về một năm, và lọc các hàng có vùng khớp với phạm vi yêu cầu.

C. Trích Xuất Theo Cột Với Các Cột Được Đặt Tên và Phân Loại

Một số bảng xuất hiện lặp lại giữa các tài liệu với hình dạng ổn định: bảng phí bảo hiểm của hợp đồng, bảng tóm tắt thu nhập trong báo cáo tài chính, hoặc các biểu mẫu quy định có trường cố định. Đây không còn là "bảng trong PDF" nữa. Chúng là dữ liệu mà nhà sản xuất tình cờ cung cấp dưới dạng PDF vì đó là định dạng phân phối. Cách tiếp cận đúng là khôi phục lại dạng ban đầu, lưu trữ các bảng trong một kho dữ liệu dạng cột tại thời điểm nạp, được lập chỉ mục theo ID tài liệu và ID bảng. Khi đó, bảng là dữ liệu. Bạn có thể truy vấn bằng SQL, nối giữa các tài liệu và tổng hợp. Cấp độ này mở ra các câu hỏi ở cấp độ toàn bộ tài liệu: "Tổng phí bảo hiểm trên tất cả các hợp đồng của tôi là bao nhiêu?"

D. Dạng Cột Nhưng Không Đồng Nhất (Heterogeneous)

Đôi khi bạn muốn truy cập ở cấp độ tài liệu nhưng các bảng lại không tuân theo một schema chung: các nhà cung cấp khác nhau, phiên bản khác nhau, bố cục khác nhau của "cùng một" thông tin. Nội dung được đặt trong một cột văn bản duy nhất bên cạnh siêu dữ liệu của nó (doc_id, page, table_id). Bạn vẫn giữ truy xuất ở cấp độ tài liệu và tìm kiếm toàn văn, nhưng cấu trúc 2D đã biến mất. Đây là phương án dự phòng trung thực khi các điều kiện tiên quyết của cấp độ C không được đáp ứng.

Ví dụ về phân tích cú pháp bảng từ PDF

Phương Pháp Chẩn Đoán: table_df_meta

Đối với mỗi bảng được phát hiện trong một tài liệu, một quá trình chẩn đoán sẽ ghi lại năm thuộc tính độc lập. Kết quả là một DataFrame nhỏ (một hàng cho mỗi bảng) mà bộ điều phối đọc để chọn cấp độ biểu diễn (A, B, C hoặc D) và các thao tác để áp dụng.

• Chất lượng phân tích cú pháp: Ba mức độ: Tốt (parser trả về một lưới rõ ràng), Một phần (parser trả về các ô nhưng lưới không đều), hoặc Thất bại (parser không tìm thấy lưới có thể sử dụng).
• Kích thước: Cặp (n_hàng, n_cột). Ngưỡng liên quan là "vừa với ngữ cảnh của LLM".
• Trạng thái tiêu đề: Ba giá trị: Có, Không, hoặc Tiếp nối (bảng là sự tiếp nối của bảng trước, tiêu đề thực sự nằm ở trang trước).
• Tính liên tục trên nhiều trang: Tự động (bắt đầu và kết thúc trên cùng một trang), Tiếp tục-từ-trang-N, hoặc Tiếp-tục-đến-trang-M.
• Bối cảnh ở cấp độ tài liệu: Tỷ lệ tổng diện tích bảng so với tổng diện tích văn bản trong tài liệu.

Năm Thao Tác Có Thể Kết Hợp

Mỗi thao tác nhận một bảng (hoặc một tập hợp các bảng) làm đầu vào và trả về một bảng đã được biến đổi. Chúng có tính chất lũy đẳng: nếu thao tác không khớp với điều kiện tiên quyết của nó thì sẽ không làm gì cả, do đó việc kết hợp là an toàn.

O1. Tái Cấu Trúc Từ Vị Trí (Structural Reconstruction from Positions)

Áp dụng khi chất lượng phân tích là một phần và các hộp giới hạn từ (word bounding boxes) có sẵn. Thao tác xây dựng lại lưới bằng cách nhóm các vị trí từ thành các dải cột và dải hàng. Điều này có thể khôi phục một bảng sạch mà trình phân tích cú pháp gốc đã bỏ sót.

O2. Nối Nhiều Trang Kèm Lan Truyền Tiêu Đề (Multi-page Concatenation with Header Propagation)

Áp dụng khi tính liên tục trên nhiều trang được xác định. Thao tác này sao chép tiêu đề từ bảng đầu tiên của chuỗi và tạo ra một bảng duy nhất được nối với một cột mới là source_page để bảo toàn nguồn gốc. Nếu không có thao tác này, một bảng 200 hàng chia thành 8 trang sẽ tạo ra 8 bảng riêng biệt và 7 trong số đó là "trẻ mồ côi" về mặt ngữ nghĩa.

O3. Chiếu Theo Câu Hỏi (Question-driven Projection)

Áp dụng khi kích thước bảng vượt quá ngưỡng ngữ cảnh. Thao tác này đọc các bộ lọc phạm vi và từ khóa khái niệm của câu hỏi, chiếu bảng xuống các cột có tiêu đề khớp và lọc các hàng có giá trị khớp với bộ lọc phạm vi. Đây là chiến lược "lọc trước khi truy xuất", được áp dụng ở cấp độ bảng bên trong một tài liệu.

O4. Trích Xuất Theo Cột (Columnar Extraction)

Áp dụng khi bảng lặp lại giữa các tài liệu với một hình dạng đã biết, hoặc tài liệu bị chi phối bởi các bảng dùng chung một schema. Thao tác này chuyển bảng vào kho dữ liệu dạng cột ở cấp độ C. Các câu hỏi tiếp theo sẽ được định tuyến đến một tác tử SQL thay vì pipeline truy xuất và tạo sinh.

Ví dụ về bảng dữ liệu phức tạp

O5. Dự Phòng Bằng Mô Hình Ngôn Ngữ Thị Giác (Vision-LLM Fallback)

Áp dụng khi O1 thất bại hoặc chất lượng phân tích quá kém ngay từ đầu. Thao tác này kết xuất vùng trang xung quanh bảng thành một hình ảnh và gửi đến một LLM có khả năng thị giác với một lời nhắc có cấu trúc yêu cầu biểu diễn bảng dưới dạng JSON. Chi phí đắt hơn O1 ít nhất một bậc độ lớn, vì vậy nó phải là phương án dự phòng, không phải là mặc định.

Các thao tác này có thể kết hợp với nhau. Một bảng vừa là một phần, vừa là bảng tiếp nối từ trang ba, lại vừa lớn, cần câu trả lời được lọc, sẽ thực hiện theo thứ tự: O1, O2, rồi O3. Một tài liệu chứa nhiều bảng dài tiếp nối nhau sẽ chạy O2 trên tất cả các phần tiếp nối, sau đó chạy O4 trên các bảng đã được hợp nhất.

Vai Trò Của Bộ Điều Phối (Dispatcher)

Bộ điều phối đọc table_df_meta và đưa ra một chuỗi các thao tác cho mỗi bảng. Nó mang tính xác định và đủ nhỏ để nằm gọn trong một tệp Python. Điều quan trọng cần lưu ý là việc lựa chọn trình phân tích cú pháp (parser) cũng quan trọng không kém việc lựa chọn thao tác. Cùng một trang được phân tích bởi hai công cụ khác nhau có thể cho ra các kết quả chẩn đoán rất khác nhau.

Ví dụ, với Bảng 3 trong bài báo "Attention Is All You Need", một parser thông thường có thể làm hỏng cấu trúc 13 cột thành 3 ô đa dòng, trong khi một parser mạnh hơn như Azure Document Intelligence có thể khôi phục tất cả 13 cột một cách sạch sẽ. Do đó, việc chọn đúng parser ngay từ đầu sẽ giảm đáng kể khối lượng công việc mà các thao tác khác phải thực hiện sau này.

Ví dụ khác: với các trang của Bộ khung An ninh mạng NIST v1.1, một parser có thể chia sai 4 cột logic thành 8 cột và làm cho một nửa số ô bị trống. Bộ điều phối sẽ quyết định chạy O1 để gấp các cột thừa lại và O2 để truyền điền các giá trị còn thiếu, tạo ra một bảng hoàn chỉnh. Tương tự, với bảng dự báo giá của Ngân hàng Thế giới, O1 giúp khôi phục nhãn của các hàng (ví dụ "wheat", "coffee") đã bị parser làm mất.

Loại Câu Hỏi Sẽ Định Hình Câu Trả Lời

Khi đã có bảng dữ liệu đúng (sau khi chẩn đoán và kết hợp), hình dạng của câu hỏi sẽ quyết định cách tạo ra câu trả lời:

• Tra cứu một ô (Cell lookup): Câu trả lời nằm trong một ô duy nhất. Trích dẫn nguồn ở cấp độ ô, sử dụng hình chữ nhật bounding box của ô đó.
• Trả về một phạm vi hoặc một cột: Câu trả lời là một lát cắt của cột hoặc hàng. Trả về một bảng Markdown nhỏ có cấu trúc, trích dẫn ở cấp độ bảng.
• Tổng hợp (Aggregate): Câu trả lời là một phép tính (ví dụ tổng, trung bình). Câu hỏi này nên được định tuyến đến một tác tử SQL, tạo ra truy vấn SELECT SUM(...), thực thi và biểu diễn kết quả. Trích dẫn là truy vấn SQL, không phải là một đoạn văn bản.

Kết Luận

Mô hình "chẩn đoán cộng với các thao tác có thể kết hợp" là phản ứng đúng đắn khi vấn đề phân tích cú pháp có nhiều chiều và các chiều này không loại trừ lẫn nhau. Một bảng là dữ liệu mà người tạo ra nó đã biết; nhiệm vụ của hệ thống là khôi phục bảng về dạng cấu trúc ban đầu để truy vấn của người dùng có thể khai thác đúng giá trị. Xử lý bảng như văn bản, dù cẩn thận đến đâu, cũng làm mất cấu trúc hàng-cột mà câu hỏi của chuyên gia phụ thuộc vào.