- Vector DB không phải là một danh mục CSDL riêng biệt
- Trong tương lai không xa, mọi CSDL bao gồm CSDL đồ thị, quan hệ, tài liệu và key-value cũng như cache đều sẽ hỗ trợ "tìm kiếm vector" dưới một hình thức nào đó
- Ranh giới giữa vector DB và các loại khác sẽ trở nên mờ nhạt, và các vector DB chuyên biệt như Pinecone, Weaviate, Milvus sẽ mất dần đà tăng trưởng và khác biệt hóa trong cạnh tranh
- Dự đoán rằng các CSDL hiện tại sẽ cố gắng tận dụng workload/cơ sở người dùng hiện có để nắm bắt các workload RAG (Retrieval Augmented Generation) mới
4 bình luận
PostgreSQL giờ cũng hỗ trợ mô-đun vector rồi! Mong các engine khác cũng sớm hỗ trợ nữa haha
Chà thì
Là một lập trình viên đã có 28 năm kinh nghiệm, với tôi thì vẫn là chà thì???
Thư viện phát triển biểu đồ sẽ không biến mất mà còn tiếp tục phát triển hơn nữa... có lẽ không cần đưa biểu đồ vào trong DB.
Dù DB có gộp với biểu đồ hay thứ khác đi nữa thì cũng chỉ làm tăng phần tải của DB, nên với tư cách là lập trình viên tôi lại càng lo hơn. Dù sao thì vấn đề lớn nhất hiện nay cũng là phải giải quyết chuyện DB ngày càng phình to và chậm dần theo thời gian; điều mấu chốt là phải tách ra tối đa để tùy biến tốc độ.
Tìm kiếm vector là việc lưu trữ các embedding mà các mô hình học sâu như LLM sử dụng dưới dạng vector, rồi nội bộ tính toán nhanh độ tương đồng giữa chúng để tìm hoặc lưu trữ; tôi muốn hỏi "chart" ở đây có ý nghĩa là gì.
Có vẻ như bạn thấy từ "vector" và cho rằng đó là từ đồng nghĩa, vì dạo này các thư viện biểu đồ thường render bằng ảnh vector như SVG.
Đây là một bình luận khá thú vị, nghe như thể người viết hiểu phần nào tình hình trong ngành.
Ý ở đó là: khái niệm content-based address (reference), vốn trước đây chỉ được nhắc đến trên lý thuyết, nay nhờ công nghệ AI phát triển cực nhanh gần đây (bao gồm cả các nội dung liên quan như vector hóa), đã trở nên dễ thực hiện đến mức người ta dự đoán rằng ngay cả trong các DBMS truyền thống, chúng ta cũng sẽ sớm thấy tính năng này.