Elastic ra mắt cơ sở dữ liệu vector serverless cho hàng trăm tỷ vector

Elastic($ESTC) đã ra mắt cơ sở dữ liệu vector serverless, cho phép xử lý từ nhúng tài liệu đến lưu trữ và tìm kiếm vector trên cùng một nền tảng. Sản phẩm hướng tới tìm kiếm hàng trăm tỷ vector, mô hình sinh tăng cường truy xuất (RAG) và các ứng dụng tác nhân trí tuệ nhân tạo (AI).

Ngày 11, Elastic công bố ‘Elasticsearch Vector Database’. Sản phẩm hiện có thể sử dụng ngay trên Elastic Cloud Serverless. Thông báo chính thức của Elastic cho biết người dùng chỉ cần nhập tài liệu và truy vấn để hỗ trợ tạo vector nhúng, điều chỉnh chỉ mục và quản lý hạ tầng liên quan.

Cơ sở dữ liệu vector lưu trữ các vector số hóa ý nghĩa của câu hoặc hình ảnh, sau đó tìm dữ liệu có ý nghĩa gần với câu hỏi. RAG là phương thức mô hình ngôn ngữ lớn (LLM) tìm tài liệu liên quan để tham khảo trước khi tạo câu trả lời, trong đó cơ sở dữ liệu vector đóng vai trò kho lưu trữ cốt lõi.

Sản phẩm mặc định xử lý việc chia nhỏ tài liệu, tạo vector nhúng, thiết lập chỉ mục và sắp xếp lại kết quả tìm kiếm. Người dùng có thể tìm kiếm vector văn bản, hình ảnh và đa phương thức trong cùng một chỉ mục, đồng thời kết hợp tìm kiếm từ khóa với tìm kiếm vector theo phương thức tìm kiếm lai.

Ngoài các mô hình riêng, sản phẩm còn cho phép sử dụng các mô hình nhúng và tái xếp hạng của Jina AI trong môi trường GPU được quản lý. Thiết kế này giúp nhà phát triển xây dựng chức năng tìm kiếm mà không phải thiết lập máy chủ mô hình và đường ống nhúng riêng.

Công nghệ cốt lõi giúp giảm gánh nặng bộ nhớ là ‘Better Binary Quantization (BBQ)’ của Elastic. Tài liệu kỹ thuật của Elastic cho biết BBQ nén vector theo đơn vị bit và có thể giảm mức sử dụng bộ nhớ tối đa 32 lần.

BBQ là phương thức nén mất dữ liệu nên có thể làm giảm độ chính xác tìm kiếm. Sản phẩm được cấu hình để bù đắp mức suy giảm này bằng cách tìm kiếm dư thừa và tái xếp hạng.

Với dữ liệu quy mô lớn, người dùng cũng có thể áp dụng ‘DiskBBQ’. Phương thức này lưu trữ vector chủ yếu trên ổ đĩa thay vì bộ nhớ, qua đó giảm yêu cầu RAM, nhưng có thể làm chậm tốc độ tìm kiếm. Vì vậy, người dùng cần lựa chọn giữa BBQ-HNSW, BBQ-Flat và BBQ-Disk tùy theo quy mô dữ liệu cũng như yêu cầu về độ chính xác và tốc độ.

Phí sử dụng được tính dựa trên dữ liệu lưu trữ và dung lượng tìm kiếm, không dựa trên mức sử dụng tài nguyên điện toán. Elastic cho biết không tính thêm phí cho các tác vụ chạy nền.

Mức phí thực tế và gánh nặng chi phí đối với người dùng trong nước chưa được công bố. Do đó, việc tiết kiệm bộ nhớ có dẫn đến giảm chi phí vận hành hay không cần được kiểm chứng riêng theo quy mô dữ liệu và tần suất tìm kiếm.

Ajay Nair, lãnh đạo mảng Elasticsearch và nền tảng tại Elastic, nói: “Nhà phát triển ứng dụng AI không cần trở thành kỹ sư hạ tầng để triển khai tìm kiếm vector”. Phát biểu này cho thấy định hướng tích hợp hạ tầng tìm kiếm, vốn trước đây được chia thành cơ sở dữ liệu và máy chủ mô hình riêng, trong nền tảng Elastic.

Trên thị trường tìm kiếm vector, các doanh nghiệp vẫn sử dụng cả phương thức cấu hình riêng lớp lưu trữ và tìm kiếm, mô hình nhúng cùng mô hình tái xếp hạng. Elastic tập trung gom các quy trình này vào một môi trường được quản lý nhằm rút ngắn giai đoạn thiết lập ban đầu và vận hành.

Xu hướng kết nối cơ sở dữ liệu doanh nghiệp với dịch vụ AI trong cùng môi trường đám mây cũng từng được ghi nhận qua trường hợp Oracle mở rộng dịch vụ cơ sở dữ liệu AI. Tuy nhiên, sản phẩm lần này của Elastic tập trung vào việc đơn giản hóa triển khai và vận hành tìm kiếm vector, thay vì kết nối với một cơ sở dữ liệu đám mây cụ thể.

Ngay sau khi sản phẩm ra mắt, Elastic chưa công bố thay đổi về thị phần hay kết quả triển khai của khách hàng. Chênh lệch về độ chính xác và tốc độ tìm kiếm do nén BBQ, cũng như chi phí vận hành thực tế hàng trăm tỷ vector, vẫn cần được kiểm chứng theo từng môi trường sử dụng.

Elastic hiện cung cấp sản phẩm trên Elastic Cloud Serverless. Vấn đề được quan tâm tiếp theo là sự cân bằng giữa mức tiết kiệm bộ nhớ, chất lượng tìm kiếm và tốc độ xử lý trong môi trường tìm kiếm quy mô lớn.