Xây dựng Pipeline RAG cho PDF trong sản xuất: Phân tích quan hệ, Truy xuất mục lục và Câu trả lời có cấu trúc

Giới thiệu

Trong môi trường doanh nghiệp, các hệ thống RAG (Retrieval-Augmented Generation) cơ bản thường thất bại khi đối mặt với các tài liệu thực tế phức tạp. Bài viết này nằm trong loạt bài "Enterprise Document Intelligence", tập trung vào việc xây dựng hệ thống RAG thông qua bốn trụ cột chính: phân tích tài liệu (document parsing), phân tích câu hỏi (question parsing), truy xuất (retrieval) và tạo câu trả lời (generation).

Ảnh minh họa

1. Tại sao Pipeline RAG cơ bản thường thất bại?

Một pipeline RAG đơn giản (phân tích PDF phẳng, trích xuất từ khóa, truy xuất trang, hỏi LLM) có thể hoạt động tốt với tài liệu sạch, nhưng sẽ gặp sự cố ngay lập tức trong thực tế:

Phân tích tài liệu (Document Parsing): Việc làm phẳng tài liệu (flattening) làm mất đi cấu trúc quan trọng như mục lục (TOC), bảng biểu, và metadata.
Phân tích câu hỏi (Question Parsing): Người dùng thường gõ sai chính tả hoặc sử dụng từ ngữ không khớp với tài liệu. Pipeline cơ bản không xử lý được các lỗi này.
Truy xuất (Retrieval): Bỏ qua cấu trúc tài liệu (TOC) khiến việc tìm kiếm thiếu chính xác.
Tạo câu trả lời (Generation): Trả về chuỗi văn bản thuần (raw string) gây khó khăn cho việc xử lý dữ liệu tự động. Cần các câu trả lời có kiểu dữ liệu (typed answers) để dễ dàng tích hợp.

2. Nâng cấp bốn trụ cột của RAG

2.1. Phân tích tài liệu: Mô hình quan hệ (Relational Set)

Thay vì một danh sách phẳng, chúng ta cần chuyển đổi PDF thành một tập hợp các bảng có quan hệ:

line_df: Một hàng cho mỗi dòng văn bản (page_num, line_num, text, bounding box).
page_df: Một hàng cho mỗi trang (page_num, text).
toc_df: Một hàng cho mỗi mục trong mục lục (title, level, start_page).
parsing_summary: Metadata mức tài liệu (loại tài liệu, ngôn ngữ, tóm tắt).

2.2. Phân tích câu hỏi: Từ nhiễu đến bản tóm tắt (Brief)

Quy trình này chuyển đổi câu hỏi thô thành một đối tượng ParsedQuestion bao gồm:

Keywords: Đã sửa lỗi chính tả và mở rộng bằng từ vựng chuyên ngành (expert vocabulary).
Intent: Ý định của người dùng (factual, listing, comparison).
RetrievalQuery: Bản tóm tắt cho bước truy xuất.
GenerationBrief: Bản tóm tắt cho bước tạo câu trả lời.

2.3. Truy xuất: Cấu trúc hóa việc tìm kiếm

Thay vì chỉ dựa vào vector index, chúng ta sử dụng:

Anchor: Sử dụng LLM để đọc mục lục (TOC) và xác định phần (section) chứa câu trả lời.
Context: Cắt ngữ cảnh dựa trên cấu trúc (ví dụ: toàn bộ section cho câu hỏi liệt kê, hoặc một cửa sổ dòng cho câu hỏi chi tiết).

2.4. Tạo câu trả lời: Typed Answers

Sử dụng schema có cấu trúc (Pydantic) để đảm bảo câu trả lời trả về đúng định dạng yêu cầu:

{
  "items": [
    {
      "text": "...",
      "start_page_num": 6, "start_line_num": 33,
      "quote": "..."
    }
  ],
  "answer_found": true,
  "confidence": 0.98
}

Việc này giúp các ứng dụng downstream có thể xử lý dữ liệu một cách tin cậy, kèm theo các chỉ số chất lượng như context_structured (để phát hiện lỗi OCR hoặc layout).

3. Kết luận

Việc nâng cấp từng trụ cột trong pipeline RAG giúp hệ thống trở nên mạnh mẽ, có khả năng kiểm chứng (auditable) và dễ dàng tích hợp vào các quy trình doanh nghiệp. Bằng cách sử dụng các hợp đồng dữ liệu (typed contracts) giữa các bước, chúng ta có thể dễ dàng theo dõi và sửa lỗi cho từng phần của hệ thống.