pgvector là extension của PostgreSQL cho phép lưu trữ và truy vấn vector embedding ngay bên cạnh dữ liệu quan hệ thông thường. Với các đội đã chạy Postgres trong production, nó loại bỏ chi phí vận hành của việc dựng thêm một vector database riêng. Chúng tôi đã đưa pgvector lên production trong một nền tảng nghiên cứu đầu tư đa nguồn, nơi nó vận hành retrieval-augmented generation trên hồ sơ SEC, bản ghi earnings call và ghi chú của analyst, và trải nghiệm đó đã thay đổi cách chúng tôi định phạm vi các dự án vector search.
Vì sao pgvector Thắng với Phần lớn Workload
Giá trị cốt lõi rất đơn giản. Thay vì quản lý hai hệ thống (Postgres cho dữ liệu quan hệ, Pinecone hoặc Weaviate cho vector), bạn giữ tất cả trong một database. Join giữa embedding và metadata trở nên tầm thường. Giao dịch ACID bao trùm cả các lần chèn vector. Câu chuyện backup, replication và monitoring Postgres sẵn có được mở rộng sang vector mà không tốn thêm gì. Với phần lớn workload RAG dưới vài triệu vector, pgvector là lựa chọn đúng đắn.
Số chiều Embedding và Bài toán Lưu trữ
Số chiều embedding quan trọng hơn mức phần lớn các đội lường trước. Mô hình mặc định OpenAI text-embedding-3-large tạo vector 3072 chiều. Tức là 12.288 byte mỗi dòng ở độ chính xác float4, chưa tính overhead của index. Chúng tôi chuẩn hóa sớm trên 3072 chiều vì hạ cấp sau này đồng nghĩa với việc re-embedding toàn bộ tài liệu, tốn kém và phá vỡ các A/B test về chất lượng tìm kiếm. README của pgvector tính chi tiết bài toán lưu trữ này. Hãy tính trước vào kế hoạch.
Lựa chọn Index: HNSW vs IVFFlat
Lựa chọn index là quyết định có hệ quả lớn nhất sau mô hình embedding. pgvector hỗ trợ hai loại index approximate nearest neighbor: IVFFlat và HNSW. Chúng tôi chọn HNSW cho workload của mình vì nó cho recall tốt hơn ở mức độ trễ chúng tôi cần (dưới 50ms p99 tại 1,5 triệu vector). IVFFlat build nhanh hơn và dùng ít bộ nhớ hơn, nhưng recall suy giảm gắt hơn khi dataset lớn dần. Tài liệu PostgreSQL về HNSW giải thích sâu các tham số. Hãy tune m và ef_construction trên dữ liệu thực, không phải trên benchmark tổng hợp.
Khi nào pgvector Đổ vỡ
Khi nào pgvector đổ vỡ? Ba điểm nghẽn xuất hiện nhất quán. Thứ nhất, lưu lượng truy vấn rất lớn ở độ trễ thấp (dưới 10ms với hàng trăm QPS) bắt đầu gây sức ép ngay cả trên một index HNSW đã tune kỹ, vì Postgres trả chi phí kết nối và planning cho từng truy vấn. Thứ hai, hybrid search kết hợp độ tương đồng vector với filter metadata chặt chẽ có thể sinh execution plan kém nếu planner chọn sequential scan thay vì vector index. Thứ ba, việc cô lập multi-tenant trở nên vụng về nếu thiếu một thiết kế schema cẩn trọng. Với những trường hợp này, một vector database chuyên dụng như Pinecone hoặc Qdrant thắng về hiệu suất thô và độ thuận tiện khi vận hành.
Chất lượng Truy xuất Vượt ra ngoài Index
Chất lượng truy xuất không chỉ là bài toán embedding. Chiến lược chunking, metadata filter và re-ranking đều quan trọng ngang với vector index. Trên nền tảng nghiên cứu đầu tư, chúng tôi chạy một query router phân loại mỗi truy vấn đến một trong bốn luồng: tra cứu có cấu trúc, similarity thuần, hybrid kết hợp cấu trúc và RAG, hoặc gọi thẳng LLM. Khoảng 35 phần trăm truy vấn không chạm vào vector index, vì chúng thuần túy là tra cứu dữ liệu. Việc routing giảm một phần ba tải cho pgvector, đồng thời cải thiện chất lượng câu trả lời. Tổng quan RAG của Anthropic đề cập các pattern tương tự từ phía mô hình.
Đánh giá trong CI
Đánh giá là phần nhiều đội bỏ qua và hối hận sau. Vector search cực kỳ ấn tượng trong demo nhưng đổ vỡ âm thầm trong production. Chúng tôi chạy một evaluation harness trong CI chấm điểm chất lượng truy xuất trên một tập cố định 200 truy vấn kèm chunk đáp án chuẩn. Bất kỳ thay đổi code nào làm recall tụt dưới 0,85 ở k=10 sẽ bị chặn merge. Cơ chế này phát hiện những vấn đề mà các dashboard độ trễ bỏ sót, chẳng hạn một bản nâng cấp mô hình embedding tạo ra xếp hạng tương tự về ngữ nghĩa nhưng bị xáo trộn một cách tinh vi.
Kết luận
Kết luận của chúng tôi cho các đội đang định phạm vi dự án vector search năm 2026: hãy bắt đầu với pgvector trừ khi bạn có một yêu cầu cứng loại trừ nó. Độ đơn giản vận hành của một database duy nhất đáng giá hơn phần hiệu suất biên mà một vector DB chuyên dụng mang lại với phần lớn workload. Nếu vượt quá khả năng của pgvector, việc migrate sau này mang tính cơ học. Chiều ngược lại (hợp nhất một vector DB chuyên dụng về lại Postgres) khó hơn nhiều. Để tìm hiểu sâu hơn về cách chúng tôi cấu trúc pipeline RAG bao quanh, xem hướng dẫn RAG best practices và case study về nền tảng nghiên cứu đầu tư.
