Một cây cấp độ tệp cho phép mô hình ngôn ngữ lớn (LLM) suy luận trên một kho tài liệu.

Hệ thống tệp PageIndex: Tìm kiếm tài liệu quy mô lớn Đăng ngày 3/5/2026 Nhóm PageIndex Liên hệ với chúng tôi PageIndex hiện có thể mở rộng lên hàng triệu tài liệu Hiện có sẵn cho doanh nghiệp. Phiên bản đám mây sẽ ra mắt sớm. (Đăng ký truy cập sớm) Chúng tôi bắt đầu PageIndex với một niềm tin: việc truy xuất các tài liệu dài nên giống với cách đọc của con người hơn là tìm kiếm sự tương đồng ngữ nghĩa. Kể từ khi ra mắt, PageIndex mã nguồn mở, một trong những kho lưu trữ AI-infra (cơ sở hạ tầng AI) phát triển nhanh nhất trên GitHub, đã vượt mốc 26.000 lượt gắn dấu sao (star) trên GitHub chỉ trong vài tháng, đạt vị trí số 1 trên GitHub Trending, được chọn tham gia Quỹ Mã nguồn mở an toàn GitHub (GitHub Secure Open Source Fund) và hiện đang phục vụ hơn 23.000 người dùng đám mây trong môi trường sản xuất. Hôm nay, chúng tôi công bố chương tiếp theo: Hệ thống tệp PageIndex (PageIndex File System), một lớp mới trên công cụ truy xuất không dùng vector, cho phép một chỉ mục duy nhất xử lý hàng triệu tài liệu. Sản phẩm này ra mắt hôm nay như một phần của PageIndex Enterprise, với phiên bản đám mây sẽ có mặt vào cuối tháng này. Bài viết này là một chuyến tham quan nhanh: tại sao RAG (Retrieval Augmented Generation) dựa trên vector cổ điển lại gặp giới hạn, PageIndex là gì, tại sao một hệ thống tệp đơn thuần không hoạt động ở quy mô này và những gì Hệ thống tệp PageIndex bổ sung để vượt qua giới hạn đó. Nơi RAG dựa trên vector cổ điển thất bại Công thức RAG tiêu chuẩn hiện đã quen thuộc: chia mỗi tài liệu thành các đoạn văn, chạy từng đoạn qua mô hình nhúng để có được một vector có kích thước cố định, lưu trữ các vector đó trong cơ sở dữ liệu vector, và tại thời điểm truy vấn, nhúng câu hỏi và kéo về K hàng xóm gần nhất. Nó hoạt động, cho đến khi không còn hoạt động nữa. Hai vấn đề phát sinh, và cả hai đều trở nên tồi tệ hơn khi kho ngữ liệu tăng lên. 1. Các nhúng có sức mạnh biểu diễn hạn chế. Một vector có độ dài cố định duy nhất phải tóm tắt toàn bộ một đoạn thành vài trăm số, và các mô hình nhúng giới hạn độ dài đầu vào của chúng ở vài trăm hoặc vài nghìn token. Giới hạn đó buộc phải có hai sự thỏa hiệp làm giảm chất lượng một cách âm thầm: Việc chia đoạn làm mất tính liên tục ngữ nghĩa. Các tài liệu thực tế có các phần, bảng, chú thích và tham chiếu chéo trải dài qua các ranh giới trang. Việc cắt chúng thành các cửa sổ có kích thước cố định sẽ phá vỡ các phụ thuộc đó. Đoạn chứa câu trả lời thường thiếu ngữ cảnh làm cho câu trả lời có ý nghĩa. Truy xuất không có ngữ cảnh. Chỉ có truy vấn theo nghĩa đen của người dùng được nhúng. Cuộc trò chuyện trước đó, vai trò của người dùng, ý định đang phát triển của một cuộc đối thoại nhiều lượt: tất cả những điều đó phải được loại bỏ trước khi mã hóa. Công cụ truy xuất nhìn thấy một thăm dò đã bị loại bỏ ngữ cảnh, không phải một câu hỏi thực sự trong một tình huống thực tế. 2. Sự tương đồng không giống như sự liên quan. Tìm kiếm vector xếp hạng theo độ tương đồng cosine với truy vấn. Nhưng điều người dùng thực sự muốn là sự liên quan, và hai điều này khác nhau ở cả hai hướng: Tương tự nhưng không liên quan (độ chính xác thấp). Trong các lĩnh vực chuyên môn (pháp lý, y tế, tài chính), ngôn ngữ lặp đi lặp lại và những khác biệt nhỏ mang ý nghĩa quan trọng. Hai đoạn văn có thể trông gần như giống hệt nhau đối với một mô hình nhúng nhưng lại nói những điều trái ngược về việc ai phải chịu trách nhiệm, liều lượng nào cần dùng hoặc điều khoản nào áp dụng. Tìm kiếm vector vui vẻ trả về cái sai vì nó "trông có vẻ đúng". Liên quan nhưng không tương tự (độ thu hồi thấp). Ngược lại, câu trả lời đúng thường được diễn đạt rất khác so với truy vấn, hoặc nằm cách xa nhiều phần so với đoạn được trích dẫn nhiều nhất. Việc tìm thấy nó đòi hỏi phải suy luận về cấu trúc của tài liệu, chứ không phải khớp từ ở cấp độ bề mặt. Tìm kiếm vector không có cơ chế nào cho điều đó, vì vậy đoạn thực sự liên quan sẽ rơi xuống dưới hạng K và biến mất một cách âm thầm. Bạn không nhận được lỗi; bạn chỉ nhận được một câu trả lời tệ hơn. Đây không phải là những trường hợp ngoại lệ. Đây là hai chế độ lỗi mà các khách hàng doanh nghiệp của chúng tôi gặp phải lặp đi lặp lại, và chính xác là những gì đã thúc đẩy chúng tôi xây dựng một loại công cụ truy xuất khác biệt. PageIndex là gì? PageIndex là một khung RAG (Retrieval Augmented Generation) không sử dụng vector. Thay vì chia tài liệu thành các đoạn, nhúng chúng vào các vector và xếp hạng theo độ tương đồng cosine, PageIndex biểu diễn mỗi tài liệu dưới dạng một cây (các phần lồng vào các tiểu mục, các tiểu mục vào các trang, các trang vào các khối nội dung) và cho phép một LLM (mô hình ngôn ngữ lớn) điều hướng cây để tìm câu trả lời. Hình dạng của cây là mục lục mà bạn sẽ thấy trong một cuốn sách. Chính sách truy xuất là một LLM, tại mỗi nút, đặt một câu hỏi duy nhất: với truy vấn của người dùng, cuộc trò chuyện cho đến nay và vị trí hiện tại của tôi trong tài liệu, tôi có nên tìm kiếm bên trong cây con này không? Không có top-K cố định, không có tắc nghẽn nhúng, không có thông tin bị bỏ qua một cách âm thầm vì nó được xếp hạng K+1. Ba đặc tính xuất phát từ thiết kế này, và mỗi đặc tính chính xác là những gì RAG vector cổ điển không thể cung cấp: Phân loại mức độ liên quan, không phải độ tương đồng ngữ nghĩa. LLM không tính điểm cosine; nó đưa ra phán đoán có/không tại mỗi nút (cây con này có đáng để mở cho truy vấn này không?) bằng cách sử dụng hiểu biết toàn bộ tài liệu, không phải một proxy 768 chiều. Hai chế độ lỗi của tìm kiếm tương đồng (tương tự nhưng không liên quan, liên quan nhưng không tương tự) đơn giản là không áp dụng. Truy xuất phụ thuộc vào ngữ cảnh. Quyết định tại mỗi nút được điều kiện hóa bởi truy vấn, lịch sử cuộc trò chuyện, vai trò của người dùng và đường dẫn mà LLM đã đi qua. Không có giới hạn độ dài cố định buộc ngữ cảnh phải bị loại bỏ. Ngữ cảnh định hình mọi bước điều hướng. Quy trình truy xuất minh bạch. Dấu vết tìm kiếm là một đường dẫn dễ đọc qua cây: những phần nào đã được mở, những phần nào đã bị bỏ qua, những phần nào cung cấp bằng chứng. Bạn có thể kiểm tra lý do tại sao một câu trả lời được đưa ra, phát lại cùng một đường dẫn cho một mô hình khác và hiển thị chuỗi trích dẫn cho người dùng cuối. Tìm kiếm vector trả về một danh sách các đoạn mà không có câu chuyện; PageIndex trả về một lộ trình. Từ tài liệu đơn lẻ đến hệ thống tệp Đây là sự phản đối rõ ràng. RAG vector cổ điển mở rộng dễ dàng lên hàng triệu tài liệu: các nhúng được tính toán trước một lần, tra cứu top-K trên một tỷ vector là một vấn đề kỹ thuật đã được giải quyết tốt, và chỉ mục không quan tâm bạn có 1 nghìn hay 100 triệu đoạn. Ngược lại, PageIndex được xây dựng trên một cây tài liệu, một cấu trúc phong phú hơn, nhưng một cấu trúc mà một LLM phải điều hướng. Liệu LLM có bị tắc nghẽn khi có hàng triệu cây để đi qua không?