Proxy-Pointer RAG: Khi Cấu trúc Gặp Quy mô - Độ Chính Xác 100% Cho Truy Xuất Thông Minh

Trong bài viết trước, tôi đã giới thiệu về Proxy-Pointer RAG — một kiến trúc truy xuất nhúng cấu trúc tài liệu trực tiếp vào chỉ mục vector. Nó đạt được độ chính xác "phẫu thuật" tương tự như các hệ thống "Vectorless RAG" (như PageIndex) mà không gặp phải các hình phạt về khả năng mở rộng hay chi phí. Bài viết đó đã đặt nền móng về lý do, cách thức và một so sánh hứa hẹn trên 10 truy vấn đối với một báo cáo của Ngân hàng Thế giới.

Mặc dù là một bằng chứng khái niệm hữu ích, nhưng điều đó chưa chứng minh được sự sẵn sàng cho môi trường sản xuất (production readiness). Bài viết này nhằm giải quyết vấn đề đó.

Trong môi trường doanh nghiệp, phần lớn các tài liệu áp dụng RAG — hướng dẫn kỹ thuật, bài báo nghiên cứu, hợp đồng pháp lý, báo cáo chính sách, hồ sơ hàng năm, tài liệu tuân thủ — đều có tiêu đề mục. Điều này khiến chúng trở nên có cấu trúc. Và cấu trúc đó bao hàm ý nghĩa, chính là cách con người hiểu và tìm kiếm một tài liệu phức tạp bằng cách tổ chức luồng các mục trong tâm trí. Một Vector RAG tiêu chuẩn thường loại bỏ cấu trúc này khi nó xé nhỏ tài liệu thành một túi các đoạn văn bản phẳng (flat chunks), dẫn đến các phản hồi không tối ưu. Proxy-Pointer thay vào đó khai thác cấu trúc phổ biến này để cải thiện đáng kể độ chính xác của việc truy xuất với chi phí bổ sung tối thiểu.

Để kiểm tra áp lực kiến trúc này, chúng tôi cần những tài liệu có cấu trúc đòi hỏi khắt khe nhất — loại tài liệu mà một dấu thập phân sai lệch hoặc một chú thích bị bỏ lỡ có thể làm vô hiệu hóa toàn bộ phân tích. Đó chính là các hồ sơ tài chính. Các báo cáo thường niên 10-K có cấu trúc lồng nhau sâu, tham chiếu chéo qua nhiều báo cáo tài chính và đòi hỏi lập luận số học chính xác. Nếu Proxy-Pointer có thể xử lý những tài liệu này, nó có thể xử lý bất kỳ tài liệu nào có tiêu đề.

Bài viết này cung cấp bằng chứng để hỗ trợ khả năng của Proxy-Pointer. Tôi đã lấy bốn hồ sơ 10-K năm tài chính 2022 công khai — AMD (121 trang), American Express (260 trang), Boeing (190 trang) và PepsiCo (500 trang) — và kiểm tra Proxy-Pointer trên 66 câu hỏi qua hai điểm chuẩn riêng biệt, bao gồm cả các truy vấn đối kháng được thiết kế đặc biệt để phá vỡ các hệ thống truy xuất ngây thơ. Kết quả rất quyết đoán và được tóm tắt dưới đây.

Ngoài ra, trong bài viết này, tôi cũng đang mã nguồn mở (open-source) toàn bộ quy trình xử lý — để bạn có thể chạy nó trên các tài liệu của riêng mình, tái tạo kết quả và phát triển nó thêm.

Tóm tắt nhanh: Proxy-Pointer là gì?

Vector RAG tiêu chuẩn chia nhỏ tài liệu thành các đoạn văn bản mù quáng (blind chunks), nhúng chúng và truy xuất top-K dựa trên độ tương đồng cosine. Mô hình tổng hợp (synthesizer LLM) nhìn thấy văn bản bị phân mảnh, thiếu ngữ cảnh — và thường xuyên bị ảo giác (hallucinate) hoặc bỏ lỡ câu trả lời hoàn toàn.

Trong bài viết trước, Proxy-Pointer đã khắc phục điều này với năm kỹ thuật kỹ thuật có chi phí bằng không:

• Cây khung xương (Skeleton Tree): Phân tích tiêu đề Markdown thành cây phân cấp (Python thuần, không cần LLM).
• Tiêm đường dẫn (Breadcrumb Injection): Nối đường dẫn cấu trúc đầy đủ (ví dụ: AMD > Báo cáo tài chính > Dòng tiền) vào trước mỗi đoạn văn bản trước khi nhúng.
• Chia nhỏ theo cấu trúc (Structure-Guided Chunking): Chia nhỏ văn bản trong ranh giới mục, không bao giờ cắt ngang qua chúng.
• Lọc nhiễu (Noise Filtering): Loại bỏ các mục gây xao nhãng (mục lục, bảng chú giải, tóm tắt điều hành) khỏi chỉ mục.
• Ngữ cảnh dựa trên con trỏ (Pointer-Based Context): Sử dụng các đoạn văn bản được truy xuất làm con trỏ để tải toàn bộ mục tài liệu nguyên vẹn cho bộ tổng hợp.

Kết quả là: mọi đoạn văn bản đều biết vị trí của nó trong tài liệu, và bộ tổng hợp nhìn thấy các mục hoàn chỉnh — không phải các mảnh vụn.

Các cải tiến kể từ bài viết đầu tiên

Một số cải tiến đáng kể đã được thực hiện đối với quy trình xử lý trước khi điểm chuẩn. Các cải tiến này được phác thảo như sau:

Thay đổi trong Quy trình Indexing

Kiến trúc độc lập (Standalone Architecture): Bản triển khai ban đầu dựa vào PageIndex như một phần phụ thuộc để tạo cây khung xương. Điều này đã được loại bỏ hoàn toàn. Proxy-Pointer hiện nay cung cấp một trình xây dựng cây Python thuần tự chứa khoảng 150 dòng, phân tích tiêu đề Markdown thành cấu trúc JSON phân cấp — không có phụ thuộc bên ngoài, không có lệnh gọi LLM, chạy trong vài mili-giây.

Bộ lọc nhiễu sử dụng LLM: Phiên bản đầu tiên sử dụng danh sách tiêu đề nhiễu được mã hóa cứng (NOISE_TITLES). Cách này bị lỗi khi có các biến thể như "Lời cảm ơn" so với "Lời ghi nhận" hoặc "Mục lục" so với "TABLE OF CONTENTS". Trong phiên bản này, quy trình mới gửi cây khung xương nhẹ nhàng đến gemini-flash-lite và yêu cầu nó xác định các nút nhiễu trên sáu danh mục. Điều này bắt được các từ đồng nghĩa ngữ nghĩa mà regex không thể làm được.

Thay đổi trong Quy trình Retrieval

Truy xuất hai giai đoạn: Ngữ nghĩa + LLM Re-Ranker: Bài viết đầu tiên sử dụng truy xuất top-K đơn giản từ FAISS. Quy trình tinh chỉnh hiện nay hoạt động trong hai giai đoạn:

• Giai đoạn 1 (Recall rộng): FAISS trả về 200 đoạn văn bản hàng đầu theo độ tương đồng nhúng, được khử trùng lặp theo (doc_id, node_id) và đưa vào danh sách ngắn 50 nút ứng viên duy nhất.
• Giai đoạn 2 (Xếp hạng lại cấu trúc): Các đường dẫn breadcrumb phân cấp của tất cả 50 ứng viên được gửi đến một LLM Gemini, sau đó xếp hạng chúng theo mức độ liên quan về cấu trúc — không phải độ tương đồng nhúng — và trả về top 5. Đây là điểm khác biệt chính: một truy vấn về "dòng tiền của AMD" giờ đây sẽ ưu tiên đúng đường dẫn AMD > Báo cáo tài chính > Dòng tiền thay vì một đoạn văn chỉ đơn thuần nhắc đến dòng tiền.

Những tinh chỉnh này đã biến Proxy-Pointer từ một nguyên mẫu hứa hẹn thành một động cơ truy xuất cấp độ sản xuất.

Điểm chuẩn: Hai bài kiểm tra, 66 câu hỏi, Bốn công ty

Để đánh giá quy trình một cách nghiêm ngặt, tôi đã tải xuống các báo cáo thường niên 10-K năm tài chính 2022 của AMD, American Express (AMEX), Boeing và PepsiCo. Các tài liệu này được trích xuất sang Markdown bằng LlamaParse và lập chỉ mục thông qua quy trình Proxy-Pointer.

Sau đó, tôi đã kiểm tra dựa trên hai điểm chuẩn riêng biệt:

Điểm chuẩn 1: FinanceBench (26 Câu hỏi)

FinanceBench là một điểm chuẩn đã được thiết lập gồm các câu hỏi định tính và định lượng trên các hồ sơ tài chính. Tôi đã chọn tất cả 26 câu hỏi bao gồm bốn công ty trong bộ dữ liệu — bao gồm lập luận số học, trích xuất thông tin và lập luận logic. Do các hạn chế cấp phép bộ dữ liệu, các câu hỏi và câu trả lời đúng của FinanceBench không được bao gồm trong kho lưu trữ github. Tuy nhiên, các bảng điểm với câu trả lời của Proxy-Pointer được cung cấp để tham khảo.

Điểm chuẩn 2: Bài kiểm tra áp lực toàn diện (40 Câu hỏi)

FinanceBench, mặc dù hữu ích, chủ yếu kiểm tra khả năng ghi nhớ sự thật. Tôi cần thứ gì đó khó hơn — các truy vấn sẽ phá vỡ một hệ thống dựa vào việc khớp đoạn văn bản bề mặt. Vì vậy, tôi đã tạo ra 40 câu hỏi tùy chỉnh, 10 câu cho mỗi công ty, được thiết kế đặc biệt để kiểm tra áp lực về lập luận số học, truy xuất đa bước (multi-hop), khả năng chống chịu đối kháng và đối chiếu chéo giữa các báo cáo.

Dưới đây là năm ví dụ minh họa sự phức tạp:

• Multi-hop Numerical (AMEX): "Tính tỷ lệ thu nhập lãi thuần trên tổng doanh thu trừ chi phí lãi vay cho năm 2022 và so sánh với năm 2021. Sự phụ thuộc có tăng không?" Điều này yêu cầu định vị hai mục dòng khác nhau trên hai năm tài chính, tính tỷ lệ cho mỗi năm và sau đó so sánh chúng.
• Adversarial Numerical (AMD): "Ước tính xem việc tích lũy hàng tồn kho có góp phần đáng kể vào sự sụt giảm dòng tiền trong năm tài chính 2022 hay không." Đây là một câu hỏi đối kháng có chủ đích.
• Tỷ lệ tái đầu tư (PepsiCo): "Tính tỷ lệ tái đầu tư được định nghĩa là Chi tiêu vốn (Capex) chia cho (Dòng tiền từ hoạt động kinh doanh trừ Cổ tức)."
• Chất lượng dòng tiền (Boeing): "Tỷ lệ phần trăm dòng tiền từ hoạt động kinh doanh trong năm tài chính 2022 được tiêu thụ bởi thay đổi vốn lưu động?" Câu trả lời ở đây ngược với trực giác: 0% — vì vốn lưu động thực sự là nguồn cung cấp tiền.
• Quy kết (AMEX): "Ước tính bao nhiêu phần trăm tăng trưởng tổng doanh thu là do tăng doanh thu chiết khấu."

Mọi câu hỏi đều có câu trả lời đúng được tính toán trước với các giá trị số cụ thể, giúp việc đánh giá không mơ hồ.

Kết quả

Cấu hình k=5 (Chính)

Trong cấu hình này, bộ truy xuất chọn một tập hợp 5 nút (k_final = 5), và các mục tương ứng được gửi đến LLM tổng hợp để phản hồi.

• FinanceBench (26 câu hỏi): 26/26 — Độ chính xác 100%
• Comprehensive (40 câu hỏi): 40/40 — Độ chính xác 100%
• Tổng cộng: 66/66 — Độ chính xác 100%

Một điểm số hoàn hảo trên tất cả 66 câu hỏi. Mọi giá trị số khớp với thực tế. Mọi đánh giá định tính đều phù hợp với dữ liệu hồ sơ.

Cấu hình k=3 (Kiểm tra áp lực)

Để hiểu ranh giới thất bại của hệ thống, tôi đã chạy lại cả hai điểm chuẩn với k_final=3 — chỉ truy xuất 3 mục tài liệu thay vì 5. Điều này cố ý hạn chế cửa sổ ngữ cảnh để kiểm tra xem độ chính xác truy xuất có đủ mạnh mẽ để hoạt động với ít nút hơn hay không.

• FinanceBench (26 câu hỏi): 25/26 — Độ chính xác 96.2%
• Comprehensive (40 câu hỏi): 37/40 — Độ chính xác 92.5%
• Tổng cộng: 62/66 — Độ chính xác 93.9%

Các thất bại trong lần chạy k=3 rất mang tính gợi mở: mọi thất bại k=3 đều được gây ra bởi độ phủ ngữ cảnh không đủ, không phải do truy xuất sai. Điều này xác nhận một thông tin kiến trúc quan trọng: khi các câu hỏi yêu cầu tham chiếu chéo nhiều phần của báo cáo tài chính, k=5 cung cấp độ phủ cần thiết.

Kho lưu trữ Mã nguồn mở

Proxy-Pointer hiện đã được mã nguồn mở hoàn toàn (giấy phép MIT) và có thể được truy cập tại Kho lưu trữ Github Proxy-Pointer.

Nó được thiết kế để bắt đầu nhanh trong 5 phút. Quy trình hoàn toàn chạy trên một khóa API Gemini duy nhất sử dụng gemini-flash-lite, mô hình tiết kiệm chi phí nhất trong danh sách của Google. Không cần GPU. Không cần cơ sở hạ tầng phức tạp hay cây lập chỉ mục tốn kém token.

Chỉ cần clone, cấu hình, lập chỉ mục vector và truy vấn.

Kết luận

Khi tôi xuất bản bài viết đầu tiên về Proxy-Pointer, đó là một giả thuyết thú vị: bạn không cần các cây điều hướng bằng LLM đắt đỏ để làm cho truy xuất nhận thức được cấu trúc — bạn chỉ cần thông minh về những gì bạn nhúng. Bằng chứng là một so sánh 10 truy vấn trên một tài liệu duy nhất.

Bài viết này vượt xa giả thuyết để đi đến bằng chứng.

66 câu hỏi. Bốn công ty Fortune 500. Độ chính xác 100% ở k=5. Lập luận số học đa bước, đối chiếu chéo báo cáo, các trường hợp đối kháng và các chỉ số tài chính ngược với trực giác — Proxy-Pointer đã xử lý tất cả. Và khi chúng ta cố ý làm cho nó thiếu ngữ cảnh ở k=3, nó vẫn đạt độ chính xác 93,9%.

Nếu hệ thống truy xuất của bạn đang gặp khó khăn với các tài liệu có cấu trúc phức tạp, vấn đề có thể không phải là mô hình nhúng của bạn. Đó là vì chỉ mục của bạn không biết bất kỳ thứ nào nằm ở đâu trong tài liệu. Hãy cung cấp cho nó cấu trúc, và độ chính xác sẽ theo sau.