Hồ sơ vụ việc không phải là một kho tài liệu nhỏ: Vì sao RAG cần phân tích cả thư mục

Các cửa sổ ngữ cảnh ngày càng dài hơn, và lời khuyên đi kèm trở nên đơn giản: đừng truy vấn nữa, hãy đưa toàn bộ vào prompt. Với một hồ sơ vụ việc (case file), lời khuyên này gần như hiệu quả. Mười một file PDF về một yêu cầu bồi thường bảo hiểm có thể dài khoảng sáu mươi trang, nằm gọn trong một cửa sổ 200.000 token nhiều lần.

Nhưng nó vẫn bỏ lỡ hai câu hỏi mà người xử lý hồ sơ cần: Hóa đơn sửa chữa thứ hai có trong thư mục hay không, và ngày tổn thất trên đơn yêu cầu bồi thường có khớp với ngày trong báo cáo của giám định viên hay không?

Lý do nằm ở hình dạng của sự vật. Một hồ sơ vụ việc là một tập hợp các tài liệu không giống nhau về một thực thể duy nhất, và đơn vị công việc là cả cái tập hợp đó. Một yêu cầu bồi thường, một đơn xin tín dụng, một hồ sơ bệnh án, một hồ sơ tuyển dụng. Hợp đồng, chứng chỉ, ảnh chụp, báo cáo chuyên gia, thư từ: không có gì trong đó giống với thứ khác, và câu trả lời đến từ việc đọc xuyên suốt tất cả.

Vì vậy, cả hai câu hỏi đều không phải là tìm kiếm. Câu hỏi đầu tiên liên quan đến một tài liệu không tồn tại, và không một lượng ngữ cảnh nào có thể chứa nó. Câu hỏi thứ hai cần một giá trị từ mỗi trong hai file, để so sánh. Các mô hình đọc phần giữa của một đầu vào dài kém tin cậy hơn phần đầu và cuối, và điều này đã được đo lường. Trong một tập hợp mười một tài liệu, cả hai giá trị đều nằm ở giữa.

Tập hợp (bundle) không phải là một kho ngữ liệu nhỏ

Mười một file về một vụ hỏa hoạn

Một vụ hỏa hoạn làm hư hại một xưởng mộc vào ngày 12 tháng 3. Trong sáu tuần tiếp theo, thư mục hồ sơ của nhà môi giới cho yêu cầu bồi thường đó chứa đầy mười một file PDF: đơn yêu cầu bồi thường, bảng điều khoản hợp đồng có hiệu lực trong tháng đó, chứng chỉ thanh toán phí bảo hiểm, báo cáo của giám định viên tổn thất, hai bảng báo giá sửa chữa, một hóa đơn sửa chữa, một bộ ảnh chụp thiệt hại, hai lá thư, và một bảng kê phương tiện thuộc một hợp đồng khác và bị lưu nhầm vào đây.

Không có gì trong danh sách đó giống với bất cứ thứ gì khác. Ảnh chụp không chứa văn bản. Báo cáo giám định viên là văn xuôi. Bảng báo giá là bảng biểu. Đơn yêu cầu bồi thường là các ô trống với giá trị được điền vào.

Hãy hỏi người xử lý hồ sơ xem cô ấy làm gì đầu tiên, cô ấy không tìm kiếm. Cô ấy chạy theo một danh sách mình thuộc lòng và đánh dấu những gì có. Yêu cầu bồi thường hỏa hoạn, vì vậy báo cáo của đội cứu hỏa là bắt buộc, và nó không có trong thư mục. Hai báo giá được chấp nhận, vì vậy hai hóa đơn sẽ được gửi đến, và chỉ có một hóa đơn. Đó là vài phút làm việc, và chưa có tài liệu nào được đọc.

Chỉ sau đó cô ấy mới đọc. Ngày tổn thất trên đơn yêu cầu bồi thường ghi 12 tháng 3. Giám định viên viết rằng ông đã kiểm tra hiện trường vào ngày 3 tháng 3. Một trong hai ngày đó là sai, và cho đến khi ai đó xác định được, hồ sơ không thể tiến triển.

Hai hình dạng khác cho bạn những gì, và chúng tiêu tốn gì ở đây

Bài viết trước trong loạt bài đã nêu ra ba hình dạng mà một bộ sưu tập có thể có và một bài kiểm tra ba câu hỏi để biết bạn đang giữ loại nào. Đây là hình dạng thứ ba: các tài liệu đến theo từng tập hợp, nhiều tài liệu về một vụ việc.

Hai hàng quan trọng nhất ở đây:

• Hàng chỉ mục: Một bảng mô tả những gì tồn tại. Ở đây, hàng là vụ việc và nội dung là danh sách các phần mà vụ việc được cho là phải có, một thứ khác để viết ra và một thứ khác để điền.
• Kết quả trống: Trong hai hình dạng kia, không tìm thấy nghĩa là bước truy vấn thất bại và bạn đi sửa nó. Trong hồ sơ vụ việc, không tìm thấy có thể là câu trả lời đúng, và thường là câu trả lời mà câu hỏi đang nhắm tới.

So sánh còn lại là điều khiến nhiều người mắc bẫy, vì từ xa hai thứ trông giống hệt nhau. Một thư mục không đồng nhất được coi như một tài liệu dài và định tuyến theo dàn ý lồng nhau của nó. Một hồ sơ vụ việc không đồng nhất theo đúng cách đó, vì vậy việc định tuyến chạy tốt ở đây. Nhưng nó trả lời sai câu hỏi: định tuyến chọn một phần, và những câu hỏi này là về toàn bộ tập hợp.

Mô tả sơ đồ ba hình dạng corpus và câu hỏi kiểm tra

Danh sách các phần mà một loại vụ việc dự kiến

Sự chuẩn bị cho hình dạng này là một tạo tác ngắn: một danh sách các phần mà loại vụ việc đòi hỏi, với số lượng và điều kiện đi kèm.

Đây là việc phân tích, được nâng lên một tầng. Trên một PDF duy nhất, bước phân tích trả về một tập hợp nhỏ các bảng quan hệ: một hàng cho mỗi dòng, một hàng cho mỗi phần, một hàng cho mỗi ô trong bảng. Một thư mục được phân tích theo cùng một cách: một bảng các vai trò dự kiến, một bảng các file đã đến với vai trò được gán và độ tin cậy của việc gán đó.

Chỉ mục về những gì nên có

Một danh sách những gì nên có, thay vì mô tả những gì đang có. Chỉ mục được xây dựng bằng cách đọc kho ngữ liệu mô tả những gì kho ngữ liệu chứa. Hãy hỏi nó hợp đồng nào bị thiếu và câu hỏi không phân tích được. Mọi thứ trong bảng đều có mặt do cấu trúc.

Danh sách ở đây được viết trước khi thư mục được mở ra, và nó đến từ quy trình thay vì từ các file. Một yêu cầu bồi thường thiệt hại tài sản cần đơn yêu cầu, bảng điều khoản, bằng chứng phí bảo hiểm đã thanh toán, báo cáo giám định viên, ít nhất một báo giá, một hóa đơn cho mỗi báo giá được chấp nhận, ảnh chụp, và báo cáo của đội cứu hỏa khi nguyên nhân là hỏa hoạn. Danh sách đó có giá trị cho loại vụ việc dù có hay không có bất kỳ tài liệu nào trong số đó được lưu trữ.

Việc suy ra cùng một danh sách từ các thư mục bạn đã có sẽ khiến phần bị thiếu biến mất. Mọi vai trò trong danh sách như vậy là vai trò đã xuất hiện trong ít nhất một thư mục, vì vậy một phần không ai nộp sẽ không có trong danh sách.

Mỗi hàng của danh sách chứa gì

Bốn trường cho mỗi phần: nó là gì, số lượng dự kiến, khi nào nó bắt buộc, và liệu vụ việc có thể tiếp tục mà không có nó không.

Ví dụ về một phần dự kiến có thể là:

class ExpectedPiece(BaseModel):
    role: str                  # từ ngữ nghiệp vụ: "báo cáo giám định viên tổn thất"
    min_count: int             # 0 khi phần này là tùy chọn
    max_count: int | None      # None khi số lượng bất kỳ đều được
    required_when: str | None  # điều kiện trên các trường của chính vụ việc
    blocks_payment: bool       # vụ việc có thể tiếp tục khi phần này vắng mặt không

required_when là điều ngăn danh sách tạo ra các cảnh báo sai. Báo cáo đội cứu hỏa là bắt buộc trong vụ hỏa hoạn và không liên quan trong vụ thiệt hại do nước, vì vậy một danh sách phẳng các phần bắt buộc sẽ phàn nàn về mọi yêu cầu không phải hỏa hoạn. Một kiểm tra sai hầu hết thời gian sẽ bị tắt. Điều kiện đọc các trường từ chính vụ việc, có nghĩa là vụ việc phải mang một số trường riêng trước khi kiểm tra tính đầy đủ có thể chạy.

blocks_payment là điều làm cho đầu ra có thể sử dụng. Hai phần bị thiếu và một trong số đó chặn tiền: người xử lý cần thấy cái nào, và một boolean cho mỗi phần là đủ để nói điều đó.

Khớp thư mục với danh sách

Với danh sách ở một bên và mười một file ở bên kia, kiểm tra tính đầy đủ là một phép nối với ba kết quả.

• Một phần có mặt khi ít nhất min_count file được gán cho vai trò của nó.
• Một phần bị thiếu khi vai trò là bắt buộc, điều kiện của nó đúng, và không có file nào được gán cho nó.
• Một file không khớp khi không có vai trò nào trong danh sách phù hợp với nó.

Phép nối dựa trên một bước có thể sai. Việc gán vai trò cho mỗi file là một phân loại, và phân loại có thể mắc lỗi. Một hóa đơn được lưu dưới dạng báo giá đọc thành một hóa đơn bị thiếu cộng với một báo giá thừa, và báo cáo sau đó mang hai dòng sai thay vì không có dòng nào. Việc gán vai trò do đó giữ độ tin cậy riêng của nó, và một gán có độ tin cậy thấp sẽ được chuyển cho người xử lý như một câu hỏi thay vì một phán quyết.

Hai câu hỏi mà truy vấn không thể trả lời

Cả hai câu hỏi mà người xử lý đã hỏi đều có cùng một đặc tính: không có đoạn văn bản nào trong tập hợp trả lời chúng, vì vậy không có mức độ xếp hạng nào đưa bạn đến đó.

Phần bị thiếu

Hãy hỏi một quy trình xử lý từng tài liệu một xem báo cáo đội cứu hỏa ở đâu, nó trả về kết quả trống. Hãy hỏi nó điều tương tự trong một vụ việc mà báo cáo được lưu dưới một tên lạ, nó cũng trả về kết quả trống. Đó là những tình huống khác nhau và quy trình không thể phân biệt chúng, vì kết quả trống không mang thông tin về lý do tại sao nó trống.

Kiểm tra tính đầy đủ có thể, và đó là mục đích của danh sách. Nó biết vai trò tồn tại, nó biết điều kiện đúng, và nó biết không có gì được gán. Câu trả lời nó tạo ra là một câu có lý do kèm theo: báo cáo đội cứu hỏa là bắt buộc vì nguyên nhân tổn thất là hỏa hoạn, không có file nào trong thư mục được gán cho vai trò đó, và việc thanh toán bị chặn cho đến khi có báo cáo.

Để đến đó cần ba thứ mà quy trình không có mặc định: một danh sách các vai trò để sự vắng mặt có tên, một điều kiện trên mỗi vai trò để sự vắng mặt chỉ được tuyên bố khi phần đó thực sự đến hạn, và độ tin cậy trên việc gán vai trò để một tài liệu bị lưu sai được báo cáo là nghi ngờ thay vì một câu trả lời dứt khoát "không".

Điều cuối cùng quan trọng hơn vẻ ngoài. Một báo cáo nói "thiếu" khi tài liệu nằm trong thư mục dưới một tên xấu còn tệ hơn không có báo cáo, vì người xử lý sau đó hỏi khách hàng về một file mà khách hàng đã gửi.

Sự mâu thuẫn giữa hai phần

Câu hỏi thứ hai so sánh. Ngày tổn thất xuất hiện trên đơn yêu cầu và một lần nữa trong báo cáo giám định viên, và hai ngày không khớp.

Truy vấn top-k là công cụ sai ở đây, không phải vì chất lượng của nó. Xếp hạng trả về các đoạn văn bản giống câu hỏi nhất. Sự mâu thuẫn không giống bất cứ thứ gì: cả hai nửa đọc bình thường khi đứng riêng, không đoạn nào đề cập đến đoạn kia, và không có gì trong một trong hai đoạn gần với câu hỏi hơn phần còn lại của file.

Thứ hiệu quả là cơ học. Khai báo các trường đáng so sánh và giữa các vai trò nào, trích xuất trường đó từ mỗi phần với một hợp đồng có kiểu dữ liệu và trích dẫn, sau đó so sánh các giá trị.

Sơ đồ các cặp so sánh được khai báo và giá trị trích xuất

Ba chi tiết quyết định liệu điều này có hiệu quả trong thực tế hay không:

• Các cặp được khai báo, không được khám phá. Chín phần tạo ra ba mươi sáu cặp, và nhân với mọi trường trên mọi phần, không gian so sánh là lớn và hầu hết là vô nghĩa. Những gì mọi người thực sự kiểm tra là một số ít cặp trên mỗi loại vụ việc, và người dùng nghiệp vụ có thể nêu tên chúng trong cùng cuộc trò chuyện tạo ra danh sách các phần dự kiến.
• Các giá trị được định kiểu trước khi so sánh. 12/03/2025 và "March 12, 2025" là cùng một ngày và hai chuỗi khác nhau. "Alpine Joinery SARL" và "Alpine Woodworks" là hai chuỗi khác nhau có thể hoặc không phải cùng một công ty. So sánh chạy trên các giá trị đã phân tích, và trường hợp thứ hai, nơi chuẩn hóa là một phán đoán thay vì định dạng, là trường hợp cần một người trong quy trình.
• Mọi giá trị giữ trích dẫn của nó. Một báo cáo chỉ nói các ngày không khớp không cho người xử lý gì để kiểm tra. Một báo cáo nói đơn yêu cầu ghi 12 tháng 3 ở trang 1 và báo cáo ghi 3 tháng 3 ở trang 4 có thể được giải quyết trong mười giây.

Câu trả lời là trạng thái của vụ việc

Hãy hỏi một kho ngữ liệu một câu hỏi, một câu trả lời tốt nêu tên các tài liệu. Hãy hỏi một hồ sơ vụ việc, một câu trả lời tốt mô tả vụ việc. Câu trả lời đó là một đối tượng được cấu thành thay vì một đoạn văn bản.

Đối tượng chứa gì

Bốn danh sách và một phán quyết. Các danh sách là những gì các phần trước tạo ra; phán quyết là câu mà người xử lý sẽ viết ở đầu file.

class CaseState(BaseModel):
    case_id: str
    case_type: str                  # "yêu cầu bồi thường thiệt hại tài sản"
    present: list[MatchedPiece]     # vai trò, doc_id, độ tin cậy khớp
    missing: list[MissingPiece]     # vai trò, lý do đến hạn, chặn điều gì
    unmatched: list[str]            # file không có vai trò nào trong danh sách phù hợp
    conflicts: list[FieldConflict]  # các cặp khai báo không khớp
    verdict: Literal["complete", "incomplete", "conflicting"]
    verdict_reason: str             # một câu nêu tên điều chặn

Hai đặc tính của đối tượng đó quan trọng cho cách nó được điền:

• Nó là một câu trả lời dạng danh sách, không phải dạng xếp hạng top. Mọi mục đều có giá trị và thứ tự không quan trọng.
• Nó được điền từng phần thay vì trong một lần gọi. Mười một tài liệu có thể nằm trong một cửa sổ, và đặt tất cả chúng vào đó vẫn là lựa chọn tệ hơn: việc trích xuất là theo từng phần, trích dẫn phải nêu tên phần mà nó đến, và đọc từng tài liệu một là điều giữ cho cả hai điều đó đúng.

Nơi nó hỏng

Trong ba hình dạng, đây là hình dạng có ít kiến thức tiền lệ nhất, cả trong loạt bài và trong tài liệu về truy vấn. Các điểm hỏng dưới đây đi kèm với ít giải pháp đã biết hơn so với các bài viết khác.

Hàng cuối cùng là quan trọng nhất. Các tiêu chuẩn truy vấn đo lường liệu đoạn văn bản đúng có được trả về hay không. Không có bộ tiêu chuẩn nào đo lường liệu một hệ thống có nói đúng rằng một tài liệu bắt buộc chưa bao giờ được nộp hay không. Điều gần nhất trong tài liệu là nửa "không thể trả lời" của một bộ đọc hiểu, một câu hỏi khác được hỏi trên một đoạn văn bản duy nhất. Vì vậy, việc đánh giá vẫn mang tính địa phương: lấy năm mươi vụ việc mà người xử lý đã kiểm tra bằng tay, chạy kiểm tra tính đầy đủ, và đếm hai loại lỗi riêng biệt. Một phần bị gọi sai là thiếu tốn một cuộc gọi cho khách hàng. Một phần bị thiếu không bị phát hiện có nghĩa là vụ việc được giải quyết trên một hồ sơ không đầy đủ, điều mà kiểm tra tồn tại để ngăn chặn.

Hình minh họa về các thành phần của hồ sơ và kiểm tra tính đầy đủ

Kết luận

Một hồ sơ vụ việc không phải là một tài liệu cũng không phải một kho ngữ liệu. Nó là một tập hợp các phần không giống nhau về một thực thể duy nhất, và đơn vị công việc là cả tập hợp.

Động thái được kế thừa từ các bài viết về tài liệu đơn là quan hệ. Hãy phân tích tập hợp thành các bảng trước, và mọi câu hỏi sau đó trở thành một truy vấn; các lời gọi mô hình đến sau cấu trúc, không thay thế nó.

Hai điều sau đó, và cả hai đều rẻ. Chỉ mục là một danh sách những gì loại vụ việc đòi hỏi, được viết từ quy trình trước khi bất kỳ thư mục nào được mở, điều mang lại tên cho một tài liệu vắng mặt. Và câu trả lời là trạng thái của vụ việc, bốn danh sách và một phán quyết, mỗi mục mang file và trang đằng sau nó.

Hai câu hỏi đáng xây dựng không phải là câu hỏi truy vấn, và đó là phần khó xử. Một tài liệu bị thiếu không có trong kho ngữ liệu theo định nghĩa, và một mâu thuẫn là so sánh giữa hai giá trị có định kiểu thay vì một đoạn để xếp hạng. Cả hai đều dễ tính khi danh sách tồn tại và các cặp được khai báo, và không cái nào xảy ra trừ khi bạn quyết định xây dựng nó.

Nếu bạn có một thư mục như thế này, thử nghiệm đầu tiên tốn một buổi chiều. Hãy viết ra các phần mà một loại vụ việc dự kiến, lấy hai mươi vụ việc thực tế, và chạy phép nối bằng tay. Số lượng các phần bị thiếu là quy mô của vấn đề, và nó đáng biết trước khi bất kỳ ai viết mã ingest.

Đọc thêm và nguồn tham khảo

Trong loạt bài:

• Giới thiệu loạt bài Document Intelligence: những gì loạt bài xây dựng, từng viên gạch, theo thứ tự.
• Baseline Enterprise RAG: từ PDF đến câu trả lời được tô sáng.
• Embeddings Aren't Magic: các chế độ hỏng dự đoán được của truy vấn RAG.
• RAG không phải là machine learning, và bộ công cụ ML giải quyết sai vấn đề.
• Từ regex đến mô hình thị giác: kỹ thuật RAG nào phù hợp với vấn đề nào.
• 10 lỗi RAG phổ biến chúng tôi thấy trong sản xuất.

Nguồn bên ngoài:

• Scott Barnett et al., Seven Failure Points When Engineering a Retrieval Augmented Generation System, 2024 (arXiv 2401.05856). Nội dung bị thiếu là điểm hỏng đầu tiên của họ, được đo trên ba hệ thống sản xuất. Trong hồ sơ vụ việc, nó không còn là lỗi mà trở thành đầu ra.
• Pranav Rajpurkar, Robin Jia và Percy Liang, Know What You Don't Know: Unanswerable Questions for SQuAD, 2018 (arXiv 1806.03822). Năm mươi nghìn câu hỏi được viết để câu trả lời đúng là từ chối. Thứ gần nhất trong tài liệu tiêu chuẩn để chấm điểm hệ thống về sự vắng mặt, và nó vẫn về một đoạn văn bản thay vì một tập hợp.
• Harsh Trivedi et al., MuSiQue: Multihop Questions via Single-hop Question Composition, 2022 (arXiv 2108.00573). Các câu hỏi được xây dựng để không một đoạn duy nhất nào có thể trả lời chúng, đặc tính mà mọi kiểm tra chéo trong phần 3.2 có.
• Yuta Koreeda và Christopher D. Manning, ContractNLI: A Dataset for Document-level Natural Language Inference for Contracts, 2021 (arXiv 2110.01799). 607 hợp đồng được chú thích với nhãn entailed, contradicting hoặc not mentioned, với các đoạn bằng chứng. Phiên bản cấp tài liệu của kiểm tra mâu thuẫn, hữu ích để thấy họ thấy khó khăn như thế nào.
• Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023 (arXiv 2307.03172). Hiệu suất cao nhất khi văn bản liên quan nằm ở đầu hoặc cuối đầu vào và giảm ở giữa, lý do được đo lường cho việc đặt toàn bộ tập hợp trong một prompt không phải là giải pháp.