Một Loại Tài Liệu, Hàng Triệu Tệp Tin: Trích Xuất Có Cấu Trúc Vào Bảng SQL Cho Truy Vấn RAG

Phần lớn công việc RAG hiện nay tập trung vào việc để mô hình tự khám phá cấu trúc của kho tài liệu: đọc từng tệp, trích xuất thực thể, suy ra mối quan hệ và tạo ra một đồ thị mà không ai cần thiết kế. Nhưng với năm nghìn bản sao của cùng một hợp đồng, chẳng còn gì để khám phá. Thay vào đó, bạn chỉ cần hỏi người quản lý kho tài liệu đó họ thường tra cứu theo trường nào — câu trả lời sẽ đến trong vòng mười giây.

Bài viết này thuộc Phần IV của loạt bài Enterprise Document Intelligence, tập trung vào một dạng cụ thể: kho tài liệu có một loại tài liệu duy nhất, hàng nghìn bản sao, và câu trả lời nằm ở việc chuyển đổi chúng thành một bảng SQL có cấu trúc thay vì cố gắng "khám phá" một schema không tồn tại.

Hình minh họa vị trí bài viết trong loạt bài

Một Loại Tài Liệu, Và Các Cột Đi Kèm Với Nó

Điều đầu tiên cần xác định: điều gì làm nên hình dạng nhận dạng này, và các cột của nó đến từ đâu?

Hình Dạng Trên Kệ Sách

Mười hai năm thông báo gia hạn cho một sản phẩm bảo hiểm xe cơ giới. Mọi đơn đặt hàng mà bộ phận thu mua đã phát hành kể từ khi ERP được đưa vào hoạt động. Báo cáo hàng tháng của một quỹ đầu tư. Mỗi tập hợp này là hàng nghìn tệp tin, và mỗi tệp là cùng một tài liệu với các giá trị khác nhau.

Số lượng không phải là điều quan trọng. Một trăm đơn đặt hàng hoạt động giống hệt một trăm nghìn đơn: câu hỏi mọi người đặt ra là về cái nào, không phải về vị trí bên trong một tệp cụ thể.

Hai điều theo sau. Các tài liệu ra từ một quy trình dùng chung bố cục trang đầu, nên cùng một giá trị nằm ở vị trí gần giống nhau mỗi lần. Và các giá trị tự lặp lại: mười một sản phẩm, khoảng bốn mươi khách hàng, bốn trạng thái. Một cột ở đây có một tập giá trị nhỏ, ổn định — chính điều này làm cho nó đáng để lọc.

Các Cột Đã Tồn Tại Trước Cả Kho Tài Liệu

Một trường như effective_date không đến từ văn bản. Nó đến từ người thiết kế biểu mẫu. Một template có các vị trí trống, một form có các ô, một màn hình back-office có các trường bắt buộc — và tệp PDF chính là màn hình đó được in ra giấy.

Không ai ghi lại quyết định đó. Không có từ điển dữ liệu, và người thiết kế biểu mẫu đã rời đi từ năm 2014. Điều còn sót lại là thực tiễn: các trường mọi người điền vào, và những trường họ kiểm tra trước khi trả lời khách hàng. Kiến thức đó nằm trong đầu những người xử lý, vì vậy trích xuất nó là một cuộc trò chuyện, không phải một công việc khai thác.

Cuộc Phỏng Vấn Giúp Bạn Xác Định Các Cột

Một giờ, hai người, và một danh sách sáu đến mười trường vào cuối buổi.

Hỏi Ai, Và Theo Thứ Tự Nào

Hãy hỏi người trực tiếp xử lý tài liệu, không phải quản lý sở hữu quy trình. Quản lý mô tả quy trình như thiết kế. Người xử lý biết trường nào thường trống trên các tệp cũ và trường nào hay bị gõ sai.

Hỏi hai người xử lý, riêng biệt. Giờ thứ hai dùng để bắt một điều: một trường mà cả hai cùng gọi tên giống nhau nhưng hiểu nghĩa khác nhau.

Bốn câu hỏi, theo thứ tự sau. Mỗi câu sẽ dễ trả lời hơn sau khi câu trước đã được giải quyết:

• Khi anh/chị cần tìm lại một tài liệu cụ thể, anh/chị tìm theo điều gì? — Câu hỏi này xác định các trường phạm vi (scope fields) — nền tảng của bảng.
• Nếu hai tài liệu trông giống hệt nhau nhưng chỉ khác ở một chỗ, anh/chị nhìn vào đâu để phân biệt? — Xác định các trường nhận dạng và trường duy nhất.
• Có trường nào trong danh sách này thường bị bỏ trống hoặc sai trên các tệp cũ không? — Phát hiện sớm các cột yếu, tránh gây hỏng bộ lọc sau này.
• Trong các báo cáo hoặc câu hỏi hàng ngày, anh/chị hay lọc theo tiêu chí gì nhất? — Kiểm tra lại danh sách với nhu cầu thực tế.

Điều thu được là một danh sách các tên theo ngôn từ của người xử lý. Kiểu dữ liệu và định nghĩa sẽ được làm rõ sau.

Hình minh họa bốn câu hỏi và những gì mỗi câu trả lời xác định về schema

Điều Gì Cho Biết Một Cột Là Thực Sự Có Giá Trị

Hai tín hiệu, và cả hai đều nằm ở câu trả lời chứ không phải ở bản thân trường.

• Nó được trả lời ngay lập tức. Hỏi một người họ lọc theo gì, một cột thực sự sẽ đến ở tốc độ trò chuyện bình thường, kèm theo ví dụ: "khách hàng, tất nhiên, và ngày hiệu lực, vì đó là cách chúng tôi biết phiên bản nào đang áp dụng." Một trường cần suy nghĩ — không ai lọc theo nó hôm nay, nên cũng sẽ không ai cập nhật nó.
• Hai người xử lý gọi tên nó giống nhau. Cùng từ, cùng nghĩa, cùng một ô trên trang. Tín hiệu đầu tiên không thể tự đứng một mình, vì một trường có thể được cả hai gọi tên nhanh chóng nhưng lại mang hai ý nghĩa khác nhau.

Không tín hiệu nào cần đến mô hình hoặc mẫu dữ liệu. Cả hai được giải quyết ngay trong phòng.

Ba Loại Câu Trả Lời Không Phải Là Cột

• Một từ mang hai nghĩa. Một người nói "ngày" và ý là ngày ký hợp đồng. Người kia nói "ngày" và ý là ngày bắt đầu bảo hiểm. Cả hai trả lời nhanh, cùng dùng một từ, và cột tạo ra sẽ chứa hai đại lượng trộn lẫn. Truy vấn về hợp đồng có hiệu lực trong tháng Ba sẽ loại bỏ các hàng mang ngày ký, và kết quả trả về vẫn trông như một câu trả lời. Một trường bị thiếu an toàn hơn, vì bộ lọc sẽ tin những gì có đó.
• Trống trên một nửa số tài liệu. Một trường được điền trên 1.900 hàng trong tổng số 5.000 là một tập con không có tên. Đôi khi tập con đó là thật — lúc đó, hãy nói rõ: trường đó thuộc về một loại phụ (subtype), và loại phụ đó mới là cột bạn đang thiếu. Đôi khi nó chỉ là một trường xuất hiện từ năm 2021, điều này cũng ổn, miễn là bộ lọc đọc giá trị null là "chưa ghi nhận" chứ không phải "không có".
• Một đánh giá, không phải một sự thật. "Khách hàng này có khó không?" là kiến thức thực tế nhưng không được in ở bất kỳ đâu. Bảo mô hình suy ra nó, bạn sẽ nhận được một ý kiến kèm trích dẫn. Hãy gác những trường này lại. Một số có thể quay lại sau như thứ mà doanh nghiệp tự viết vào chỉ mục bằng tay, không phải là trích xuất.

Chỉ Mục Là Một Mục Lục Cho Kho Tài Liệu

Chỉ mục có một công việc duy nhất, và cách nhanh nhất để hiểu nó là đặt nó cạnh thứ mà mọi độc giả đã quen dùng.

Một Tấm Bản Đồ Được Đọc Trước Khi Đọc Nội Dung

Mục lục không phải là một phần nội dung của tài liệu, nó là một tấm bản đồ của tài liệu đó. Sáu dòng đại diện cho ba mươi tư trang, và một câu hỏi về loại trừ sẽ đưa bạn đến mục 4 trước khi bạn đọc một trang nào.

Chỉ mục làm cùng một công việc ở cấp độ cao hơn. Nó không phải là nội dung của kho tài liệu. Năm cột đại diện cho năm nghìn tệp tin, và một câu hỏi về bảo hiểm đội xe của một khách hàng sẽ đưa bạn đến một hàng trước khi bạn mở một tệp tin nào.

Hình minh họa mối quan hệ giữa mục lục và chỉ mục kho tài liệu

Hãy theo sự so sánh này đến cùng, vì nó cho bạn biết điều gì thuộc về chỉ mục. Một mục lục không chứa văn bản của mục 4, nó chứa đủ thông tin để quyết định mục 4 có phải nơi cần tìm hay không. Một hàng chỉ mục chứa đủ thông tin để quyết định một tài liệu có phải ứng viên hay không. Khi nó bắt đầu chứa câu trả lời, nó trở thành một bản sao thứ hai của kho tài liệu — và bản sao đó sẽ ngày càng lệch.

Hàng Chỉ Mục, Được Viết Ra

Sáu trường, theo ngôn từ của người xử lý, kèm kiểu dữ liệu:

class PolicyIndexRow(BaseModel):
    """Một hàng của chỉ mục kho: một hợp đồng, sáu trường nghiệp vụ."""
    doc_id: str              # tệp tin, để câu trả lời có thể trích dẫn nguồn
    policy_number: str       # số hợp đồng doanh nghiệp nhập vào hệ thống
    client_name: str         # bên được bảo hiểm
    product: str             # một trong mười một sản phẩm, danh sách không bao giờ đổi
    effective_date: date     # ngày bắt đầu hiệu lực
    renewal_date: date       # ngày hết hạn nếu không gia hạn
    premium_eur: float       # số tiền phí bộ phận tài chính dùng để lọc

Không có gì trong khai báo này là một quyết định mô hình hóa. Mọi tên đều đến từ cuộc phỏng vấn. doc_id là trường duy nhất doanh nghiệp không đặt tên, và nó ở đó để câu trả lời có thể chỉ về tệp tin mà nó được đọc từ đó.

Chỉ Mục Sẽ Tiếp Tục Phát Triển, Và Đó Là Thiết Kế

Một câu hỏi xuất hiện mà các cột không thể trả lời: "Hợp đồng nào trong số này có điều khoản loại trừ chiến tranh?" Không có cột như vậy, nên câu hỏi buộc phải mở từng tài liệu một.

Hãy thêm cột, điền nó vào các tài liệu áp dụng, và mọi câu hỏi tương lai về loại trừ chiến tranh sẽ là một thao tác lọc thay vì quét toàn bộ kho tài liệu. Chi phí được trả một lần và lợi ích không hết hạn. Trên con đường ngây thơ, câu hỏi tương tự phải trả giá đầy đủ mỗi lần ai đó hỏi.

Hai thói quen giữ cho sự phát triển này trung thực: Chạy từng trường mới qua hai tín hiệu ở mục 2.2 trước, vì một cột được thêm dưới áp lực của một câu hỏi cấp bách là loại cột sẽ mang ba nghĩa khác nhau một năm sau. Và giữ một trích dẫn trên mọi giá trị, để một con số trong chỉ mục có thể được kiểm tra với trang mà nó được đọc từ đó.

Trả Một Lần, Hay Trả Cho Mọi Câu Hỏi

Việc chuẩn bị có đáng giá hay không là một phép toán. Đây là cách tính.

Hai Giai Đoạn, Và Chỉ Một Giai Đoạn Tăng Trưởng Theo Số Câu Hỏi

Quy trình xử lý một tài liệu không thay đổi. Nó giờ nằm bên trong hai giai đoạn có chi phí rất khác nhau.

• Giai đoạn nạp dữ liệu (ingestion) chạy một lần trên mỗi tài liệu, khi tệp tin đến và trước khi bất kỳ ai hỏi gì. Nó phân tích, điền các cột đã thống nhất, giữ tham chiếu trang cho mỗi giá trị, và thêm một hàng. Nó chỉ chạy lại khi tệp tin thay đổi.
• Giai đoạn truy vấn (querying) chạy một lần cho mỗi câu hỏi. Nó đọc các trường phạm vi từ câu hỏi, lọc chỉ mục xuống các ứng viên, và chạy quy trình trên những gì còn lại.

Ingestion bị giới hạn bởi số lượng tài liệu. Truy vấn bị giới hạn bởi số lượng câu hỏi — và đó là con số không ngừng tăng lên.

Hình minh họa hai giai đoạn và chỉ mục dùng chung

Năm Mươi Câu Hỏi Mỗi Ngày, Và Chúng Cộng Lại Thành Gì

Một nhân viên xử lý bồi thường sử dụng hệ thống như thế này khoảng năm mươi lần mỗi ngày. Đó là mức độ lớn mà chúng tôi thấy lặp đi lặp lại, và con số chính xác không thay đổi điều gì sau đây. Trong một năm làm việc, đó là khoảng mười hai nghìn câu hỏi từ một người, và một đội sáu người đưa con số đó vượt qua bảy mươi nghìn.

Nếu không chuẩn bị, mỗi câu hỏi trong số đó đều được định giá dựa trên toàn bộ kệ tài liệu. Hệ thống phải tính toán từ đầu tài liệu nào là ứng viên, bằng cách so sánh câu hỏi với các đoạn văn từ những tệp không hề liên quan.

Với sự chuẩn bị, câu hỏi bắt đầu bằng một bộ lọc trên một bảng và quy trình chạy trên những gì đi qua. Công việc cho mỗi câu hỏi không còn tăng theo kích thước kho tài liệu.

Vì ingestion trả một lần cho mỗi tài liệu và truy vấn trả một lần cho mỗi câu hỏi, ngay khi số câu hỏi trong vòng đời hệ thống đạt cùng mức độ với số tài liệu, phiên bản đã chuẩn bị sẽ vượt trội về chi phí tính toán. Nó vượt trội sớm hơn thế trên hai phương diện khác: câu trả lời đến từ một tài liệu do con người chọn, và bộ lọc là thứ mà một nhân viên nghiệp vụ có thể đọc và tranh luận.

Khi Việc Chuẩn Bị Không Đáng Giá

Một tài liệu chỉ được đọc một lần, hoặc không bao giờ, không xứng đáng cho một lượt xử lý sâu. Điền mười hai cột cho một phụ lục dùng một lần tốn kém hơn đọc phụ lục đó khi câu hỏi cuối cùng đến — nếu nó đến.

Vì vậy, hãy phân tầng công việc. Một template hợp đồng chuẩn được tra cứu hàng nghìn lần trong vòng đời danh mục xứng đáng được xử lý sâu, với mọi trường được trích xuất và mọi tham chiếu chéo được giải quyết. Phần đuôi dài nhận phiên bản rẻ — ở đây là tên tệp, siêu dữ liệu tệp và loại tài liệu. Một tài liệu có thể được nâng cấp sau, khi số lượt truy vấn của nó cho thấy nó xứng đáng với lượt xử lý sâu hơn.

Kết Luận

Trên một kho tài liệu chỉ có một loại tài liệu, không có schema nào để khám phá. Có một schema cần được ghi lại, và nó đã tồn tại trong thực tiễn của những người xử lý tài liệu.

Việc chuẩn bị bắt đầu bằng một giờ trò chuyện và hai tín hiệu: một trường được gọi tên không do dự, và hai người gọi nó giống nhau. Điều gì vượt qua cả hai sẽ được đưa vào chỉ mục. Điều gì thất bại là một loại phụ, một đánh giá, hoặc một từ mang hai nghĩa — và mỗi loại đó rẻ hơn nhiều nếu phát hiện trong phòng họp thay vì sau một lượt xử lý năm nghìn tệp tin.

Hãy thử hai tín hiệu trên một thư mục của riêng bạn trước khi viết bất kỳ mã ingestion nào. Hỏi người xử lý những tệp đó họ lọc theo gì, sau đó hỏi một người thứ hai, và xem bao nhiêu phần của schema quay lại trong mười giây đầu tiên.

Bài viết tiếp theo trong loạt bài này sẽ đề cập đến Article 14B (thư mục mà các tài liệu không chia sẻ trường nào) và Article 14D (hồ sơ vụ việc — một bó tài liệu về một thực thể duy nhất), nơi một hàng của bảng là một vụ việc chứ không phải một tài liệu.

Đọc Thêm Và Nguồn Tham Khảo

Để hiểu sâu hơn về bối cảnh, bạn có thể tham khảo các bài viết trước trong loạt bài Enterprise Document Intelligence, bao gồm các chủ đề về quy trình RAG, phân tích cú pháp tài liệu, và kỹ thuật prompt. Các nguồn bên ngoài quan trọng được trích dẫn trong bài gồm:

• Darren Edge và cộng sự, From Local to Global: A Graph RAG Approach to Query-Focused Summarization, 2024 — lựa chọn ngược lại: để mô hình trích xuất thực thể thay vì hỏi doanh nghiệp đặt tên cột.
• Jinyang Li và cộng sự, Can LLM Already Serve as A Database Interface?, 2023 — câu hỏi trên một bảng có kiểu dữ liệu rõ ràng sẽ như thế nào khi bảng đã tồn tại.
• Fatemeh Nargesian và cộng sự, Data Lake Management: Challenges and Opportunities, PVLDB 2019 — cùng một vấn đề trong quản lý dữ liệu từ nhiều năm trước.
• Scott Barnett và cộng sự, Seven Failure Points When Engineering a Retrieval Augmented Generation System, 2024 — các điểm lỗi được đo từ ba hệ thống sản xuất, trong đó bộ lọc chỉ mục loại bỏ lỗi thiếu tài liệu và sai tài liệu ngay từ đầu.