Google Cloud vừa cập nhật chỉ mục ScaNN của AlloyDB, với ngưỡng quy mô chính thức được công bố là hơn 10 tỷ vector. Ở quy mô này, số liệu đo thực tế cho thấy độ trễ P95 không vượt quá 51 mili giây, độ chính xác thu hồi (recall) đạt 95%. AlloyDB là dịch vụ cơ sở dữ liệu được quản lý của Google Cloud, tương thích giao diện PostgreSQL.
Thay đổi lần này nằm ở cấu trúc chỉ mục. Trước đây ScaNN dùng cây hai hoặc ba tầng để tổ chức vector, lần này được nâng lên bốn tầng.
Thêm một tầng cây, giảm hai bậc độ lớn khi truy vấn
Cách làm của tìm kiếm lân cận gần đúng (approximate nearest neighbor) là gom các vector theo độ tương đồng thành từng cụm theo tầng, khi truy vấn sẽ đi từ tầng trên cùng xuống dưới, mỗi tầng chỉ chọn ra vài nhánh gần nhất để mở rộng tiếp. Số tầng quyết định độ phức tạp tìm kiếm: cây hai tầng là O(N^1/2), ba tầng giảm xuống O(N^1/3), bốn tầng tiếp tục ép xuống O(N^1/4).
Các số mũ này chênh lệch rất lớn ở quy mô hàng chục tỷ. Tính nhẩm một chút, khi N là 10 tỷ, căn bậc hai của N xấp xỉ 100.000, căn bậc ba xấp xỉ 2.150, căn bậc bốn xấp xỉ 316. Số lượng ứng viên mà cùng một truy vấn phải chạm tới giảm từ mức trăm nghìn xuống còn mức vài trăm. Con số 51 mili giây chính là từ đây mà ra.
Các biện pháp cụ thể mà Google liệt kê gồm chiến lược phân nhánh Top-K, thuật toán SOAR, điều chỉnh trọng tâm cụm (centroid) và xây dựng cây cân bằng, cùng với lấy mẫu động để né giới hạn bộ nhớ. Google chỉ ra hai điểm nghẽn của cấu trúc cũ: cây càng lớn thì khối lượng tính toán khi xây chỉ mục và duyệt truy vấn càng tăng; còn khi lấy mẫu ở quy mô hàng chục tỷ vector thì rất dễ chiếm hết bộ nhớ khả dụng.
Chính AI Agent đã đẩy khối lượng dữ liệu lên cao
Theo Google, nhu cầu từ các ứng dụng AI Agent cấp doanh nghiệp đang đẩy các trường hợp sử dụng lên quy mô hàng tỷ vector, trong khi cơ sở dữ liệu vector nền tảng thường không kham nổi.
Câu này chỉ ra nguồn gốc của đợt mở rộng lần này. Trong kịch bản tìm kiếm tăng cường truyền thống (RAG), một công ty cắt toàn bộ tài liệu nội bộ thành từng đoạn nhỏ, quy mô thường ở mức chục triệu đến trăm triệu. AI Agent thì khác: mỗi bước thực thi nó đều phải nhìn lại lịch sử, tra cứu mô tả công cụ, lật lại sở thích người dùng, một tác vụ có thể kích hoạt tới hơn chục lần truy vấn. Nguồn dữ liệu cũng mở rộng từ tài liệu sang nhật ký hội thoại, nhật ký thao tác, sản phẩm trung gian — những thứ này tích lũy thêm mỗi ngày.
Thử tính thêm một phép toán. Với P95 là 51 mili giây, nếu một tác vụ Agent thực hiện 15 lần truy vấn, riêng phần cơ sở dữ liệu vector đã tốn khoảng 0,77 giây. Đó mới chỉ là phần cơ sở dữ liệu, còn suy luận mô hình, gọi công cụ, độ trễ mạng phải tính riêng. Độ trễ truy vấn nhìn trong một lượt tương tác đơn lẻ có vẻ không đáng kể, nhưng đặt vào một chuỗi nhiều bước thì trở thành một phần cảm nhận rõ rệt.
Cơ sở dữ liệu đa dụng đang thu nạp các sản phẩm chuyên biệt
Việc đưa khả năng truy vấn vector quy mô hàng chục tỷ vào một dịch vụ được quản lý tương thích PostgreSQL cho thấy cùng một hướng đi: vector không còn cần một hạ tầng riêng biệt nữa.
Với khách hàng doanh nghiệp, bài toán này rất dễ tính. Dữ liệu nghiệp vụ vốn đã nằm trong cơ sở dữ liệu quan hệ — bảng người dùng, bảng đơn hàng, quy tắc phân quyền đều ở đó. Nếu tách vector ra một cơ sở dữ liệu chuyên dụng riêng, đồng nghĩa với hai bộ sao lưu, hai bộ phân quyền, hai cơ chế đảm bảo tính nhất quán, và còn phải tự xử lý ranh giới giao dịch giữa hai hệ thống. Nếu chỉ cần thêm một chỉ mục vào cơ sở dữ liệu sẵn có là giải quyết được, độ phức tạp vận hành giảm ngay một nửa.
Vị thế của các cơ sở dữ liệu vector chuyên dụng cũng thay đổi theo trong hai năm qua. Chúng vẫn có lợi thế về hiệu năng cực hạn và tốc độ cập nhật thuật toán truy vấn, nhưng cơ sở dữ liệu đa dụng liên tục nâng ngưỡng đủ dùng lên cao hơn — từ triệu lên trăm triệu, giờ lên tới chục tỷ. Không gian còn lại cho sản phẩm chuyên dụng bị ép vào nhóm nhỏ có yêu cầu khắt khe nhất về độ trễ và thông lượng.
Lần này AlloyDB không công bố số lượng phân vùng, số chiều của vector, thời gian xây dựng chỉ mục và giới hạn QPS. Những thông số này trong thực tế lựa chọn công nghệ thường có giá trị tham khảo hơn cả quy mô đỉnh, đặc biệt là thời gian xây chỉ mục mất bao lâu — chi phí xây lại chỉ mục ở quy mô hàng chục tỷ có thể cao đến mức phi lý.
Nguồn tham khảo: Blog chính thức của Google Cloud, tài liệu chỉ mục ScaNN của AlloyDB, CocoLoop; các số liệu về quy mô vector, độ trễ P95 và tỷ lệ thu hồi lấy theo công bố chính thức, các phép quy đổi độ phức tạp là ước tính của tòa soạn.