Giới thiệu pg_pinecone: Công cụ tìm kiếm mã nguồn mở cho dữ liệu Postgres

← Blog Giới thiệu pg_pinecone: Giải pháp tìm kiếm mã nguồn mở cho dữ liệu Postgres Harshita Daddala, Anthony Mahanna Ngày 27/10/2026 | Sản phẩm Chia sẻ: Chuyển đến mục: Cơ chế hoạt động của pg_pinecone Đánh giá hiệu năng (Benchmarks) Mở rộng quy mô và bổ sung tính năng với các truy vấn SQL không đổi Trải nghiệm sản phẩm Đóng góp hoàn thiện pg_pinecone Chia sẻ: Đăng ký nhận tin từ Pinecone Nhận thông tin cập nhật mới nhất qua thư điện tử khi bài viết được xuất bản: Nhận cập nhật Tóm tắt nội dung pg_pinecone là tiện ích mở rộng (extension) mã nguồn mở theo giấy phép Apache 2.0 dành cho Postgres, phục vụ tìm kiếm trên nguồn dữ liệu sẵn có, được xây dựng dựa trên công cụ tìm kiếm quy mô lớn của Pinecone. Bộ lọc được áp dụng trực tiếp trong quá trình tìm kiếm, bảo đảm các truy vấn phạm vi hẹp vẫn trả về đầy đủ kết quả ngay trong cơ sở dữ liệu Postgres. Hệ thống AI am hiểu nghiệp vụ doanh nghiệp cần khởi đầu từ chính nguồn dữ liệu của đơn vị đó, và đối với nhiều đội ngũ kỹ thuật, dữ liệu này được lưu trữ trong Postgres. Từ trợ lý hỗ trợ khách hàng, hệ thống gợi ý sản phẩm cho đến tác tử ghi nhớ lịch sử tác vụ, tất cả đều phụ thuộc vào khả năng tìm kiếm các bản ghi phù hợp nhất một cách nhanh chóng và chính xác. Thách thức này gia tăng theo quy mô dữ liệu. Phương pháp phổ biến hiện nay để thực hiện tìm kiếm vector trong Postgres là sử dụng chỉ mục đồ thị như HNSW; tuy nhiên, các đồ thị này rất tốn kém khi mở rộng. Hệ thống đòi hỏi dung lượng bộ nhớ ngày càng lớn để duy trì hiệu năng và mất nhiều thời gian để khởi tạo. Tìm kiếm kết hợp lọc dữ liệu cũng làm giảm độ chính xác; khi một truy vấn bị giới hạn trong phạm vi một người dùng hoặc một bên thuê (tenant), chỉ mục đồ thị có thể trả về ít kết quả hơn, khiến ứng dụng bỏ sót những phản hồi cần thiết. Hôm nay, tiện ích pg_pinecone chính thức được phát hành dưới dạng mã nguồn mở theo giấy phép Apache 2.0, phát triển trên nền tảng công cụ tìm kiếm quy mô lớn của Pinecone. Tiện ích này lập chỉ mục cho các cột vector hiện có. Thay vì cấu trúc đồ thị, chỉ mục của pg_pinecone lưu trữ một bản tóm lược tinh gọn của từng vector, qua đó duy trì tốc độ tìm kiếm cao với mức chiếm dụng bộ nhớ thấp và thời gian tạo chỉ mục nhanh chóng. Bộ lọc được áp dụng đồng thời trong quá trình tìm kiếm thay vì xử lý sau, giúp các truy vấn phạm vi hẹp vẫn thu được kết quả đầy đủ. Toàn bộ quy trình vận hành trực tiếp trong cơ sở dữ liệu Postgres, bảo đảm dữ liệu không bị chuyển ra ngoài. Giải pháp mang lại khả năng tìm kiếm có lọc nhanh chóng, chính xác trên nguồn dữ liệu sẵn có mà không cần vận hành thêm một hệ thống thứ hai. Cơ chế hoạt động của pg_pinecone pg_pinecone là một tiện ích mở rộng (extension) của Postgres, hoạt động tương thích với các cột vector hiện có trong pgvector. Ứng dụng kết nối tới Postgres theo phương thức chuẩn và sử dụng các câu lệnh SQL tương tự, chẳng hạn như ORDER BY embedding <=> $1 LIMIT 10. Toàn bộ các bảng dữ liệu, bao gồm cả các vector đầy đủ, được giữ nguyên vị trí lưu trữ và Postgres tiếp tục đóng vai trò là hệ thống ghi nhận gốc (system of record). Mỗi bảng sử dụng một trong ba công cụ xử lý: native (mặc định): công cụ riêng của pg_pinecone, có khả năng xây dựng và tìm kiếm chỉ mục hoàn toàn bên trong cơ sở dữ liệu Postgres, không yêu cầu tài khoản Pinecone, khóa API hay các lệnh gọi qua mạng; pgvector: tìm kiếm trên chỉ mục HNSW của pgvector hiện có; remote: chuyển tiếp yêu cầu tìm kiếm đến một chỉ mục trên dịch vụ do Pinecone quản lý. Việc chuyển đổi giữa các công cụ được thực hiện thông qua một lệnh gọi hàm pinecone.set_engine(), đồng thời các truy vấn hoàn toàn không thay đổi. Tương tự cấu trúc HNSW của pgvector, công cụ native của pg_pinecone áp dụng thuật toán tìm kiếm láng giềng gần đúng ANN (approximate nearest neighbor). Chỉ mục của công cụ này lưu trữ các mã vector nén (sử dụng thuật toán RaBitQ) theo từng cụm thay vì dạng đồ thị, đồng thời tiến hành lọc dữ liệu trực tiếp trong quá trình tìm kiếm thay vì xử lý sau. Cơ chế này giúp duy trì kích thước chỉ mục nhỏ gọn, tốc độ tìm kiếm nhanh và kết quả lọc đạt độ chính xác cao. Chỉ mục có dung lượng nhỏ gọn hơn Chỉ mục HNSW của pgvector lưu trữ bản sao đầy đủ của từng vector cùng các liên kết đến những láng giềng gần nhất. Quá trình tìm kiếm sẽ duyệt qua đồ thị này và so sánh các vector đầy đủ tại mỗi bước nhảy, do đó toàn bộ đồ thị cần được duy trì trong bộ nhớ để bảo đảm tốc độ xử lý. Thay vì sử dụng chỉ mục dạng đồ thị (vốn đạt hiệu quả cao đối với các tác vụ tĩnh, không yêu cầu bộ lọc với chỉ số QPS lớn), công cụ native gom các vector tương tự vào các cụm thông qua phương pháp chỉ mục tệp đảo ngược (IVF). Chỉ mục này lưu trữ một bản sao đã lượng tử hóa của từng vector dưới dạng mã RaBitQ (công bố bởi Gao và Long, SIGMOD 2024): tương đương khoảng một bit trên mỗi chiều, kèm theo một số giá trị hiệu chỉnh. Các mã cho mỗi cụm được đóng gói liền kề, giúp quá trình tìm kiếm chỉ cần đọc một số trang dữ liệu liên tiếp thay vì phải chuyển tiếp liên tục qua các nút trên đồ thị. Để so sánh RaBitQ với các phương pháp lượng tử hóa khác, có thể tham khảo công cụ VQ-Bench hoặc tài liệu phát triển hệ thống. Đối với 1 triệu vector 768 chiều, công cụ native chỉ tạo ra chỉ mục có dung lượng 136 MB, so với mức 2,0 GB của chỉ mục HNSW trên định dạng halfvec và 4,1 GB trên các vector kích thước đầy đủ. Tốc độ tìm kiếm nhanh hơn Phần lớn các thao tác trong quá trình tìm kiếm đều tiêu tốn rất ít tài nguyên. Việc so sánh vector truy vấn với mã RaBitQ chỉ yêu cầu một số phép toán thao tác bit thay vì toàn bộ các phép tính dấu phẩy động phức tạp, và chỉ một danh sách rút gọn các ứng viên mới được tính điểm với vector đầy đủ: Thăm dò các cụm gần nhất bằng cách so sánh vector truy vấn với tâm của từng cụm; Tính toán khoảng cách ước tính cho từng hàng dữ liệu từ mã RaBitQ và giữ lại các ứng viên tối ưu nhất; Xếp hạng lại các ứng viên này bằng cách sử dụng các vector đầy đủ lưu trữ trong bảng dữ liệu. Ở mức độ thu hồi (recall) 0,95, mỗi truy vấn mất 1,3 ms, so với 1,7 ms của HNSW trên halfvec và 2,7 ms trên vector kích thước đầy đủ. Ở mức độ thu hồi 0,99, thời gian xử lý đạt 2,3 ms so với lần lượt 4,7 ms và 6,7 ms. Kết quả lọc chính xác Thuật toán HNSW của pgvector áp dụng cơ chế lọc sau (post-filter): xác định các điểm lân cận gần nhất trước, sau đó mới áp dụng mệnh đề WHERE. Với bộ lọc hẹp, chẳng hạn như tỷ lệ một trên một trăm đơn vị thuê (tenant), phần lớn các ứng viên đều bị loại bỏ, khiến truy vấn có thể trả về số hàng ít hơn mức giới hạn (LIMIT) yêu cầu. Tính năng quét lặp (iterative scan) của pgvector bổ sung danh sách bằng cách tìm kiếm sâu hơn, song phải đánh đổi bằng thời gian xử lý và suy giảm độ chính xác nếu sử dụng cơ chế relaxed_order. Công cụ bản địa (native engine) thực hiện lọc ngay trong quá trình tìm kiếm và lựa chọn chiến lược xử lý dựa trên độ chọn lọc. Hệ thống lưu trữ giá trị của một cột lọc cạnh mã RaBitQ của từng hàng; đồng thời, tại thời điểm xây dựng, hệ thống sẽ thống kê số lượng hàng mang từng giá trị: Bộ lọc hẹp (mặc định từ 3% số hàng trở xuống): lọc trước (pre-filtering). Hệ thống quét toàn bộ các hàng phù hợp trên mọi cụm và chấm điểm từng hàng bằng vectơ đầy đủ, qua đó bảo đảm kết quả chính xác tuyệt đối. Bộ lọc rộng (trên 3% số hàng): lọc một giai đoạn (single-stage filtering). Hệ thống tìm kiếm số cụm lân cận gần nhất nhiều hơn so với khi không áp dụng lọc (lên đến một nửa số cụm), đồng thời kiểm tra điều kiện lọc bên trong từng cụm trước khi chấm điểm. Với 10% số hàng phù hợp, công cụ bản địa sử dụng phương thức lọc một giai đoạn và đạt độ phủ (recall) 1,000 trong 12,3 ms. Trong khi đó, thuật toán HNSW kết hợp quét lặp chỉ đạt độ phủ tối đa 0,920 trong 5,9 ms. Duy trì tính cập nhật của chỉ mục Khi bổ sung các hàng mới, mỗi vectơ sẽ tự động gia nhập vào cụm gần nhất và có thể tìm kiếm được ngay lập tức. Các trọng tâm (centroid) vẫn giữ nguyên vị trí từ quá trình khởi tạo p