MongoDB Atlas Vector Search cho khử trùng lặp eKYC quy mô lớn: Bài học từ POC 10 triệu vector

Vector search thường được nhắc đến như một năng lực retrieval cho AI, nhưng một số workload đặt ra yêu cầu rất khác. Khử trùng lặp danh tính là một ví dụ. Trong workflow đối sánh eKYC 1:N, danh tính mới được biểu diễn thành một vector rồi so sánh với tập danh tính lớn hiện có để xác định khả năng trùng lặp hoặc gian lận. Với loại hệ thống này, vector retrieval không chỉ là một bước gợi ý. Chất lượng search có thể tác động trực tiếp đến quyết định kinh doanh. Vì vậy, cần đánh giá latency, recall, kiến trúc index và tối ưu memory theo cách khác.

Workload: 10 triệu vector với yêu cầu latency hướng production

Đánh giá tập trung vào dataset 10 triệu vector, trong đó mỗi vector biểu diễn một facial embedding 1024 chiều. Mục tiêu hiệu năng chính là tối thiểu 100 request mỗi giây trong khi duy trì P95 query latency dưới 10 milliseconds. Các môi trường test riêng được dùng cho hiệu năng và độ chính xác. Môi trường lớn đo latency, throughput, độ ổn định và hành vi index ở quy mô 10 triệu vector; môi trường nhỏ hơn dùng để đánh giá recall và quantization trên các dataset được kiểm soát.

Kết quả của các bài test hiệu năng

1,255 QPS với P95 9.85 ms trên workload 10 triệu vector.

Hiệu năng duy trì quan trọng hơn một benchmark ngắn

1,344 QPS

Với đối sánh danh tính, không thể xem recall là metric thứ yếu

Exact nearest-neighbor search ngày càng tốn kém khi số lượng vector tăng, vì mỗi query phải so sánh với toàn bộ search space. Trong POC, exhaustive search cần khoảng 182 ms cho mỗi query ở 1 triệu vector và 480 ms ở 10 triệu vector. HNSW duy trì gần 8 ms ở cả hai quy mô, nhanh hơn khoảng 24 lần ở 1 triệu vector và khoảng 60 lần ở 10 triệu vector.

Vì sao exhaustive search không còn thực tế ở quy mô lớn

60 lần nhanh hơn

Tối ưu memory có thể trở thành vấn đề về độ chính xác

Quantization có thể giảm đáng kể memory của vector index, nhưng cần đánh giá đánh đổi dựa trên vai trò của search result trong ứng dụng. Trong bài test, scalar quantization giảm index memory từ 4.51 GiB xuống 1.36 GiB. Tuy nhiên, Recall@10 giảm từ 99.37% xuống 92.83%, còn Exact Match@10 giảm từ 94.88% xuống 41.22%. Với workload recommendation, một mức thay đổi nhất định về thứ hạng có thể chấp nhận được. Với khử trùng lặp danh tính 1:N, khi kết quả vector search có thể tác động trực tiếp đến việc phát hiện danh tính trùng lặp, mức suy giảm exact-match quality này không được xem là chấp nhận được.

Production readiness cũng bao gồm hành vi vòng đời index

indexed incrementally

Năm bài học cho kiến trúc vector search production

1. Bắt đầu từ quyết định cần đưa ra, không phải từ vector database. Xác định false negative hoặc thay đổi thứ hạng có ý nghĩa gì đối với doanh nghiệp trước khi chọn search parameter.
2. Đo latency và recall cùng nhau. Query latency thấp không mang nhiều giá trị nếu retrieval quality thấp hơn ngưỡng chấp nhận được.
3. Cô lập search workload khi có thể. Dedicated search resource giảm tranh chấp giữa database write, indexing và query execution.
4. Test tải duy trì, không chỉ benchmark peak. Hành vi memory, throttling và độ ổn định dài hạn có thể cho thấy các vấn đề mà bài test ngắn bỏ sót.
5. Coi vòng đời index là một phần của kiến trúc production. Incremental indexing, kịch bản rebuild và quy trình recovery cần được lập kế hoạch vận hành rõ ràng.

Vector search là một đánh đổi kỹ thuật, không phải một con số benchmark duy nhất

Thực hành MongoDB Partner của TitanBases