Việc ra mắt Vectroid, một cơ sở dữ liệu vector serverless mới, đã khơi mào một cuộc thảo luận thú vị trong cộng đồng nhà phát triển về tình trạng phân mảnh của công nghệ tìm kiếm vector. Trong khi Vectroid hứa hẹn giải quyết những đánh đổi truyền thống giữa tốc độ, độ chính xác và chi phí, các nhà phát triển đang đặt ra những câu hỏi lớn hơn về cách tiếp cận của ngành trong việc xây dựng cơ sở dữ liệu vector.
Lời kêu gọi cho một Universal Vector Engine
Cuộc thảo luận hấp dẫn nhất xuất hiện từ thông báo của Vectroid tập trung vào việc thiếu một thư viện tìm kiếm vector có thể nhúng và được chuẩn hóa. Các nhà phát triển chỉ ra rằng bối cảnh hiện tại buộc các nhóm phải tích hợp khả năng vector vào các cơ sở dữ liệu hiện có như PostgreSQL hoặc xây dựng các hệ thống hoàn toàn riêng biệt như Milvus và giờ đây là Vectroid.
Cộng đồng đang kêu gọi một thứ gì đó tương tự như Apache DataFusion - một thư viện phục vụ như IR của cơ sở dữ liệu nhưng dành cho các hoạt động vector. Điều này sẽ cho phép các hệ thống cơ sở dữ liệu khác nhau tích hợp tìm kiếm vector chất lượng cao mà không cần phát minh lại các thuật toán cốt lõi mỗi lần. Ý tưởng này đã thu hút sự chú ý, với một số nhà phát triển chỉ ra các thư viện hiện có như USearch và FAISS như những nền tảng tiềm năng, mặc dù những thư viện này chưa thực sự đạt được điểm ngọt ngào là những thành phần sẵn sàng cho cơ sở dữ liệu.
DataFusion: Một framework thực thi truy vấn cung cấp khả năng lập kế hoạch và thực thi truy vấn SQL có thể được nhúng vào các hệ thống khác
Các Thư Viện Tìm Kiếm Vector Hiện Có Được Đề Cập
- USearch: Thư viện C++11 đơn header, được sử dụng trong extension DuckDB-VSS và ClickHouse
- FAISS: Thư viện của Facebook Research cho tìm kiếm tương đồng
- pgvector: Extension PostgreSQL cho các phép toán vector
- DataFusion: Framework thực thi truy vấn của Apache (được trích dẫn như mô hình cho thư viện vector mong muốn)
Thách thức kiến trúc vượt ra ngoài thuật toán
Trong khi cuộc thảo luận bắt đầu với lời kêu gọi các thư viện tốt hơn, các nhà phát triển có kinh nghiệm nhanh chóng nhấn mạnh rằng những thách thức thực sự nằm ở kiến trúc hệ thống phân tán. Các thuật toán cốt lõi như HNSW (Hierarchical Navigable Small Worlds) đã được hiểu rõ, nhưng việc tìm ra cách cân bằng chi phí, độ chính xác và tốc độ ở quy mô lớn đòi hỏi những quyết định kiến trúc tinh vi.
Cách tiếp cận của Vectroid trong việc tách biệt ghi và đọc và mở rộng chúng một cách độc lập đại diện cho một giải pháp cho những thách thức này. Nhóm đằng sau Vectroid, bao gồm một đồng sáng lập của Hazelcast, đã xây dựng hệ thống của họ trên một phiên bản được chỉnh sửa của Apache Lucene với các tối ưu hóa tùy chỉnh cho khối lượng công việc vector. Họ đã tạo ra một hệ thống tệp tùy chỉnh hoạt động trực tiếp với Google Cloud Storage, bỏ qua các lớp lưu trữ truyền thống để có hiệu suất tốt hơn.
HNSW: Một thuật toán dựa trên đồ thị cho tìm kiếm láng giềng gần nhất xấp xỉ, cung cấp sự cân bằng tốt giữa tốc độ và độ chính xác
Các Thành Phần Kiến Trúc Kỹ Thuật
- Thuật toán: HNSW ( Hierarchical Navigable Small Worlds ) cho tìm kiếm vector
- Backend: Apache Lucene được chỉnh sửa với các tối ưu hóa tùy chỉnh
- Lưu trữ: Tích hợp trực tiếp với Google Cloud Storage ( S3 sẽ có sớm)
- Mở rộng: Các microservice riêng biệt cho đọc và ghi
- Hạ tầng: Triển khai Kubernetes được quản lý thông qua Terraform / Helm
- Ngôn ngữ: Triển khai hoàn toàn bằng Java
Tuyên bố hiệu suất và kiểm tra thực tế
Các tuyên bố benchmark của Vectroid đã thu hút cả sự quan tâm và hoài nghi. Công ty báo cáo việc lập chỉ mục 1 tỷ vector trong 48 phút và đạt được độ trễ P99 34 mili giây trên các tập dữ liệu lớn. Tuy nhiên, các thành viên cộng đồng đang đặt câu hỏi liệu những bộ sưu tập vector khổng lồ như vậy có thực sự hữu ích không, trích dẫn nghiên cứu gần đây cho thấy độ chính xác embedding giảm đáng kể ở quy mô rất lớn.
Cấu trúc chi phí cũng gây ra sự nghi ngờ. Trong khi Vectroid tuyên bố lập chỉ mục tập dữ liệu Deep1B với chi phí dưới 12 đô la Mỹ sử dụng các instance spot của Google Cloud, một số nhà phát triển cho rằng đối với nhiều trường hợp sử dụng, các cách tiếp cận đơn giản hơn có thể hiệu quả về chi phí hơn so với việc xây dựng các hệ thống phân tán phức tạp.
Điểm chuẩn hiệu suất Vectroid
- Lập chỉ mục 1 tỷ vector trong 48 phút
- Độ trễ P99: 34ms trên bộ dữ liệu MS Marco (138 triệu vector, 1024 chiều)
- Chi phí lập chỉ mục: <12 USD cho bộ dữ liệu Deep1B sử dụng 6x n2-standard-96 spot instances
- Duy trì độ nhớ lại >90% trong khi mở rộng quy mô lên 10 luồng truy vấn mỗi giây
Sự phân chia giữa mã nguồn mở và độc quyền
Thông báo này đã khơi lại các cuộc tranh luận về cách tiếp cận độc quyền so với mã nguồn mở trong không gian cơ sở dữ liệu vector. Một số thành viên cộng đồng bày tỏ sự thất vọng với việc lại có thêm một giải pháp mã nguồn đóng khác gia nhập thị trường nơi đã có các lựa chọn thay thế mở. Tuy nhiên, các nhà sáng lập Vectroid lập luận rằng việc duy trì mã nguồn đóng ban đầu cho phép họ di chuyển nhanh hơn, đồng thời hứa hẹn khả năng di chuyển dữ liệu để giảm lo ngại về việc bị khóa.
Căng thẳng này phản ánh những câu hỏi rộng lớn hơn về cách đổi mới xảy ra trong phần mềm cơ sở hạ tầng. Trong khi các giải pháp mã nguồn mở cung cấp tính minh bạch và sự tham gia của cộng đồng, các giải pháp độc quyền thường di chuyển nhanh hơn và có thể tài trợ cho những nỗ lực tối ưu hóa tích cực hơn.
Kết luận
Việc ra mắt Vectroid đã trở thành chất xúc tác cho những cuộc thảo luận sâu sắc hơn về hướng phát triển tương lai của hệ sinh thái cơ sở dữ liệu vector. Liệu ngành có cần các thư viện được chuẩn hóa tốt hơn, đổi mới kiến trúc nhiều hơn, hay chỉ đơn giản là tối ưu hóa tốt hơn các cách tiếp cận hiện có vẫn là một câu hỏi mở. Điều rõ ràng là khi các ứng dụng AI thúc đẩy nhu cầu tìm kiếm vector, cộng đồng đang tích cực tìm kiếm các giải pháp không buộc phải đánh đổi đau đớn giữa hiệu suất, chi phí và độ chính xác.
Tham khảo: Why & how we built Vectroid