Làm thế nào để truy xuất mọi thứ. Nhanh chóng.

Kiến trúc sản xuất cho tìm kiếm tài liệu tài chính ở quy mô lớn Giả định ban đầu: Bạn đã biết RAG là gì. Bạn đã biết các chế độ lỗi của nó – ô nhiễm cửa sổ ngữ cảnh, khoảng cách ngữ nghĩa, trôi dạt truy xuất, nhúng lỗi thời. Bạn đã gặp phải giới hạn khi tìm kiếm vector đơn giản hoạt động trong bản demo nhưng lại hỏng trong sản xuất. Bài viết này nói về những gì xảy ra sau giới hạn đó, đặc biệt trong bối cảnh ngành tài chính, nơi dữ liệu lộn xộn hơn, rủi ro cao hơn và yêu cầu truy xuất khắt khe hơn hầu hết các lĩnh vực khác. Không gian vấn đề: Dữ liệu tài chính không phải là văn bản sạch Một công ty dịch vụ tài chính – nhà quản lý tài sản, ngân hàng, công ty bảo hiểm, công ty công nghệ tài chính – có một kho dữ liệu trông đại khái như sau: Nhiều PDF: Các hồ sơ 10-K/10-Q/8-K, báo cáo kiểm toán, ghi chú nghiên cứu, tài liệu chính sách, hợp đồng, sổ tay tuân thủ Bảng tính: Các mô hình Excel, xuất CSV, sao kê tài khoản, bảng đối chiếu Thuyết trình: Các bộ tài liệu thu nhập PowerPoint, các buổi thuyết trình cho nhà đầu tư với biểu đồ, bình luận nhúng Biên lai và hóa đơn: Các tệp PDF được quét, đôi khi được chụp ảnh, đôi khi nhiều trang với tem, chữ viết tay và DPI thấp Văn bản không cấu trúc: Các chuỗi email, ghi chú của nhà phân tích, bản ghi nhớ nội bộ ở định dạng DOCX hoặc văn bản thuần túy Thách thức không chỉ là truy xuất. Đó là mọi thứ trước truy xuất. Một hóa đơn được quét được đưa qua bộ trích xuất pypdf đơn giản sẽ trở thành văn bản bị hỏng – các hàng bảng bị sập thành rác được phân tách bằng dấu phẩy, tiêu đề cột hợp nhất với các giá trị và các trường nhiều dòng mất cấu trúc. Nếu đó là những gì bạn đang nhúng, chỉ mục vector của bạn đã bị nhiễm độc trước khi một truy vấn nào được chạy. Vì vậy, kiến trúc có hai vấn đề riêng biệt và chúng cần được giải quyết độc lập: Chất lượng nhập liệu – phân tích cú pháp, trích xuất cấu trúc và phân đoạn theo cách bảo toàn tính toàn vẹn ngữ nghĩa Tốc độ và độ chính xác của truy xuất – tìm kiếm đoạn phù hợp nhanh chóng, với nguồn gốc, ở quy mô lớn Bài viết này đề cập đến cả hai, theo thứ tự, bởi vì bạn không thể có một hệ thống truy xuất nhanh và chính xác nếu chỉ mục của bạn chứa dữ liệu rác. Phần 1: Nhập liệu – Phân tích cú pháp trước khi lập chỉ mục Quyết định về bộ phân tích cú pháp Hầu hết các nhóm mặc định sử dụng pypdf hoặc PDFMiner. Cả hai đều tốt cho các tệp PDF sạch, có văn bản gốc với thứ tự đọc tuyến tính. Cả hai đều thất bại nặng nề trên: Bố cục nhiều cột Bảng có ô hợp nhất hoặc thiếu đường viền Các tệp PDF được quét/dựa trên hình ảnh với bất kỳ yêu cầu OCR nào Các tệp PDF có biểu đồ nhúng mà chú thích bị tách biệt về mặt không gian khỏi hình ảnh Đối với một kho dữ liệu tài chính, những trường hợp thất bại này không phải là trường hợp ngoại lệ. Chúng là tiêu chuẩn. Docling (IBM Research, hiện là Linux Foundation, giấy phép MIT) là giới hạn mã nguồn mở hiện tại cho phân tích cú pháp tài liệu trong các quy trình RAG. Nó sử dụng các mô hình thị giác máy tính để hiểu bố cục trang trước khi thực hiện trích xuất văn bản – nó xác định các loại phần tử (tiêu đề, đoạn văn, bảng, hình ảnh, danh sách, chú thích) và mối quan hệ không gian của chúng, sau đó tái tạo thứ tự đọc và cấu trúc. Đầu ra là một đối tượng DoclingDocument – một mô hình Pydantic giữ văn bản, bảng, hình ảnh, tiêu đề và siêu dữ liệu bố cục cùng nhau thay vì làm phẳng mọi thứ thành một khối văn bản. Điều quan trọng là, nó không coi một bảng là văn bản. Một bảng được trích xuất dưới dạng một đối tượng có cấu trúc với các mối quan hệ hàng/cột còn nguyên vẹn. from docling.document_converter import DocumentConverter converter = DocumentConverter() result = converter.convert("q3_earnings_report.pdf") doc = result.document # Các bảng xuất hiện dưới dạng đối tượng có cấu trúc, không phải văn bản tuyến tính for table in doc.tables: df = table.export_to_dataframe() # pandas DataFrame, cấu trúc được bảo toàn print(df) # Ví dụ IBM cũng phát hành Granite-Docling (tháng 1/2026) – một VLM (mô hình ngôn ngữ thị giác) 258M tham số thực hiện phân tích toàn bộ trong một lần, bao gồm OCR (nhận dạng ký tự quang học) trong các yếu tố được xác định và liên kết chú thích với hình ảnh của chúng. Mô hình này đáng để đánh giá trong các môi trường mà việc chạy quy trình tổng hợp của Docling (nhiều mô hình) quá chậm đối với việc nhập hàng loạt. Đối với các hóa đơn và biên lai được quét có chất lượng thấp hoặc bố cục không chuẩn, bước tiền xử lý rất quan trọng: làm thẳng, tăng cường độ tương phản và chuẩn hóa độ phân giải trước khi bất kỳ trình phân tích nào xử lý hình ảnh. Việc chấm điểm độ tin cậy trên các trường được trích xuất là điều cần thiết – bạn muốn các trích xuất bị lỗi được gắn cờ để xem xét thủ công thay vì âm thầm làm hỏng chỉ mục của bạn. Quyết định phân đoạn Đây là nơi hầu hết các hệ thống sản xuất mắc lỗi mà không thể nhìn thấy cho đến khi việc truy xuất thất bại. Cách tiếp cận sai lầm: phân đoạn token kích thước cố định được áp dụng đồng nhất trên tất cả các loại tài liệu. Phân đoạn kích thước cố định ở 256 hoặc 512 token là phù hợp cho văn xuôi đồng nhất. Các tài liệu tài chính không đồng nhất. Cùng một tệp PDF có thể có: Văn bản tường thuật dày đặc (tiết lộ yếu tố rủi ro) nơi các đoạn 512 token hoạt động tốt Bảng tài chính (báo cáo thu nhập, bảng cân đối kế toán) nơi các hàng bảng cần được giữ cùng với tiêu đề của chúng Biểu đồ có chú thích cần được lưu trữ theo cặp Tiêu đề phần cung cấp ngữ cảnh quan trọng cho các đoạn văn bên dưới chúng Nghiên cứu cho thấy: Một nghiên cứu của NVIDIA năm 2025 về truy xuất tài liệu tài chính (sử dụng FinanceBench làm tập dữ liệu đánh giá) cho thấy các truy vấn thực tế hoạt động tốt nhất với các đoạn 256–512 token, trong khi các truy vấn phân tích phức tạp được hưởng lợi từ các đoạn cấp trang hoặc 1024 token. Đây không phải là lý do để chọn một – đây là lý do để triển khai các chiến lược phân đoạn theo từng loại tài liệu. Cách tiếp cận thực tế: Loại tài liệu → Chiến lược phân đoạn Hồ sơ SEC (10-K, 10-Q) → Cấp độ phần (chia theo tiêu đề), ~512-1024 token Bảng được phân đoạn riêng biệt dưới dạng đối tượng có cấu trúc Tiêu đề bảng được lặp lại trong mỗi đoạn bảng Bài thuyết trình thu nhập (PPT) → Các đoạn cấp độ trang chiếu Mỗi trang chiếu = một đoạn, tiêu đề + nội dung + bất kỳ chú thích biểu đồ nào Biên lai / hóa đơn → Phân đoạn toàn bộ tài liệu (biên lai thường ngắn) Các trường chính được trích xuất dưới dạng siêu dữ liệu: nhà cung cấp, ngày, số tiền, tiền tệ Bảng tính (Excel/CSV) → Phân đoạn nhóm hàng cho dữ liệu dạng bảng Lược đồ được lưu trữ dưới dạng siêu dữ liệu cho mỗi đoạn Các cột số được chuẩn hóa thành chuỗi với các đơn vị được giữ nguyên Hợp đồng (DOCX) → Phân đoạn cấp độ điều khoản Tiêu đề điều khoản + nội dung điều khoản