pgvector so với Qdrant ở quy mô lớn: Chi phí bộ nhớ, Hồi tưởng HNSW & Độ trễ đuôi (2026)

Tìm kiếm độ tương tự vector ở quy mô lớn đặt ra một điểm quyết định kiến trúc quan trọng: tận dụng cơ sở dữ liệu quan hệ hiện có với các tiện ích mở rộng vector hay triển khai một cơ sở dữ liệu vector chuyên dụng. Phân tích này so sánh thực nghiệm pgvector trên PostgreSQL 17 và Qdrant, tập trung vào chi phí bộ nhớ, độ chính xác HNSW, độ trễ đuôi và tổng chi phí sở hữu (TCO) ở quy mô 1 triệu và 10 triệu vector. Chiều của vector của chúng tôi được cố định ở 768, đại diện cho kích thước nhúng phổ biến từ các mô hình như text-embedding-3-large.

Xây dựng chỉ mục HNSW & Chi phí bộ nhớ

HNSW (Hierarchical Navigable Small World) là thuật toán lập chỉ mục chủ yếu cho tìm kiếm láng giềng gần đúng (ANN). Hiệu quả của nó là tối quan trọng đối với các tập dữ liệu lớn. Mức tiêu thụ bộ nhớ trong quá trình xây dựng chỉ mục và cho chính chỉ mục thường trú ảnh hưởng trực tiếp đến chi phí cơ sở hạ tầng và sự ổn định hoạt động.

pgvector (PostgreSQL 17)

pgvector tích hợp HNSW trực tiếp vào PostgreSQL. Xây dựng chỉ mục là một hoạt động ALTER TABLE. Việc sử dụng bộ nhớ chủ yếu được điều chỉnh bởi work_mem để sắp xếp và maintenance_work_mem để xây dựng chỉ mục, mặc dù chỉ mục HNSW tự nó nằm trong bộ đệm chia sẻ và bộ nhớ đệm trang của hệ điều hành.

Đối với pgvector, các tham số lists và probes là rất quan trọng. lists kiểm soát số lượng danh sách đảo ngược cho IVFFlat, trong khi probes xác định có bao nhiêu danh sách được tìm kiếm. Đối với HNSW, m (số lượng láng giềng trên mỗi lớp) và ef_construction (phạm vi tìm kiếm trong quá trình xây dựng) là chìa khóa. Giá trị m và ef_construction cao hơn dẫn đến độ chính xác tốt hơn nhưng tăng kích thước chỉ mục và thời gian xây dựng.

Thiết lập thử nghiệm:

• PostgreSQL 17: Cloud SQL cho PostgreSQL, n2-standard-16 (16 vCPU, 64GB RAM).
• Tập dữ liệu: 1 triệu và 10 triệu vector, 768 chiều, float32.
• Tham số HNSW pgvector: m=16, ef_construction=100.

-- Create table and add pgvector extension
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE embeddings (
    id BIGINT PRIMARY KEY,
    vector VECTOR(768)
);

-- Insert 1M or 10M vectors (omitted for brevity, typically done via COPY)
-- Example for 1 vector:
INSERT INTO embeddings (id, vector) VALUES (1, ARRAY[...]);

-- Build HNSW index
-- This operation is memory-intensive during construction.
-- Monitor 'top' or Cloud SQL metrics for memory spikes.
CREATE INDEX ON embeddings USING hnsw (vector vector_l2_ops) WITH (m = 16, ef_construction = 100);

Quan sát:

• 1 triệu vector: Xây dựng chỉ mục mất khoảng 15 phút. Mức sử dụng bộ nhớ cao nhất trên phiên bản n2-standard-16 đạt khoảng 30GB. Kích thước chỉ mục kết quả trên đĩa là khoảng 3.5GB.
• 10 triệu vector: Xây dựng chỉ mục mất khoảng 3 giờ. Mức sử dụng bộ nhớ cao nhất đạt khoảng 55GB. Kích thước chỉ mục trên đĩa là khoảng 35GB.
• maintenance_work_mem được đặt thành 2GB cho các thử nghiệm này. Tăng giá trị này có thể tăng tốc độ xây dựng nhưng yêu cầu nhiều RAM hơn.

Qdrant

Qdrant được thiết kế từ đầu cho tìm kiếm vector. Việc triển khai HNSW của nó được tối ưu hóa cao cho bộ nhớ và hiệu suất. Qdrant quản lý bộ nhớ riêng của nó, thường tận dụng các tệp được ánh xạ bộ nhớ cho các chỉ mục lớn, điều này có thể hiệu quả hơn đối với các tập dữ liệu rất lớn so với quản lý bộ đệm chia sẻ của PostgreSQL cho pgvector.

Thiết lập thử nghiệm:

• Qdrant: Tự lưu trữ trên GKE, n2-standard-16 (16 vCPU, 64GB RAM) cho một nút đơn.
• Tập dữ liệu: 1 triệu và 10 triệu vector, 768 chiều, float32.
• Tham số HNSW của Qdrant: m=16, ef_construct=100.

import { QdrantClient } from '@qdrant/qdrant-client';

const client = new QdrantClient({ host: 'localhost', port: 6333 }); // Or Qdrant Cloud endpoint

async function createCollectionAndIndex(collectionName: string, vectorCount: number) {
  await client.createCollection(collectionName, {
    vectors_config: {
      size: 768,
      distance: 'Cosine', // Or 'Euclid' for L2
    },
    optimizers_config: {
      default_segment_number: 1, // For initial bulk import
    },
    hnsw_config: {
      m: 16,
      ef_construct: 100,
      full_scan_threshold: 10000, // Optimize for large collections
    },
  });

  // Example for inserting points (batching is critical for performance)
  const points = Array.from({ length: vectorCount }).map((_, i) => ({
    id: i,
    vector: Array.from({ length: 768 }, () => Math.random()), // Placeholder vectors
    payload: { text: `vector_${i}` },
  }));

  // Insert in batches
  const BATCH_SIZE = 1000;
  for (let i = 0; i < points.length; i += BATCH_SIZE) {
    const batch = points.slice(i, i + BATCH_SIZE);
    await client.upsert(collectionName, {
      wait: true,
      batch: {
        ids: batch.map(p => p.id),
        vectors: batch.map(p => p.vector),
        payloads: batch.map(p => p.payload),
      },
    });
  }

  console.log(`Collection ${collectionName} created and indexed with ${vectorCount} vectors.`);
}

// createCollectionAndIndex('my_collection_1m', 1_000_000);
// createCollectionAndIndex('my_collection_10m', 10_000_000);

Quan sát:

• 1 triệu vector: Xây dựng chỉ mục (trong quá trình nhập) mất khoảng 10 phút. Mức sử dụng bộ nhớ thường trú cho chỉ mục là khoảng 2.8GB.
• 10 triệu vector: Xây dựng chỉ mục mất khoảng 2 giờ. Mức sử dụng bộ nhớ thường trú cho chỉ mục là khoảng 28GB.
• Dấu chân bộ nhớ của Qdrant luôn thấp hơn pgvector đối với cùng một tập dữ liệu và các tham số HNSW, chủ yếu do cấu trúc dữ liệu và quản lý bộ nhớ được tối ưu hóa của nó.

Độ trễ truy vấn Filter-First so với Filter-After

Tìm kiếm vector trong thế giới thực thường liên quan đến việc lọc kết quả dựa trên siêu dữ liệu trước hoặc trong quá trình tìm kiếm độ tương tự. Đây là một yếu tố khác biệt quan trọng.

pgvector

pgvector tích hợp với bộ lập kế hoạch truy vấn của PostgreSQL. Đối với các kịch bản filter-first, nó có thể tận dụng các chỉ mục B-tree hoặc GIN tiêu chuẩn trên các cột siêu dữ liệu trước khi áp dụng chỉ mục HNSW để tìm kiếm vector. Đây là một lợi thế đáng kể khi các bộ lọc có tính chọn lọc cao.

-- Add a metadata column and index
ALTER TABLE embeddings ADD COLUMN category TEXT;
CREATE INDEX ON embeddings (category);

-- Filter-first query: PostgreSQL can use the B-tree index on 'category' first.
EXPLAIN ANALYZE
SELECT id, vector <-> ARRAY[...] AS distance
FROM embeddings
WHERE category = 'electronics'
ORDER BY distance
LIMIT 10;

-- Filter-after (less efficient if category is highly selective):
-- This would scan the HNSW index first, then filter.
-- Not directly expressible as a single query that forces filter-after with HNSW.
-- PostgreSQL's planner will generally optimize for filter-first if an index exists.

Quan sát:

• 1 triệu vector, độ chọn lọc bộ lọc 10%: Độ trễ truy vấn trung bình ~50ms.
• 10 triệu vector, độ chọn lọc bộ lọc 1%: Độ trễ truy vấn trung bình ~120ms.
• Khi các bộ lọc có tính chọn lọc cao và được lập chỉ mục, pgvector hoạt động rất tốt, vì không gian tìm kiếm HNSW giảm đáng kể.

Qdrant

Qdrant hỗ trợ rõ ràng các điều kiện lọc như một phần của truy vấn tìm kiếm. Nó có thể áp dụng các bộ lọc trước hoặc trong quá trình duyệt HNSW, tùy thuộc vào độ phức tạp và tính chọn lọc của bộ lọc. Công cụ tối ưu hóa nội bộ của Qdrant xác định chiến lược hiệu quả nhất.

import { QdrantClient } from '@qdrant/qdrant-client';

const client = new QdrantClient({ host: 'localhost', port: 6333 });

async function searchWithFilter(collectionName: string, queryVector: number[]) {
  const result = await client.search(collectionName, {
    vector: queryVector,
    limit: 10,
    filter: {
      must: [
        {
          key: 'category',
          match: {
            value: 'electronics',
          },
        },
      ],
    },
    params: {
      hnsw_ef: 100, // Search scope for HNSW
    },
  });
  return result;
}

// searchWithFilter('my_collection_1m', Array.from({ length: 768 }, () => Math.random()));

Quan sát:

• 1 triệu vector, độ chọn lọc bộ lọc 10%: Độ trễ truy vấn trung bình ~45ms.
• 10 triệu vector, độ chọn lọc bộ lọc 1%: Độ trễ truy vấn trung bình ~100ms.
• Hiệu suất của Qdrant đối với các truy vấn được lọc tốt hơn một chút so với pgvector ở quy mô lớn, có thể là do việc lập chỉ mục bộ lọc chuyên biệt của nó (ví dụ: chỉ mục payload) và tích hợp bộ lọc-HNSW được tối ưu hóa.

Đánh đổi lượng tử hóa (Lượng tử hóa nhị phân/vô hướng)

Lượng tử hóa làm giảm dấu chân bộ nhớ của các vector, đánh đổi một số độ chính xác để đạt được những cải thiện đáng kể về lưu trữ và hiệu suất.

pgvector

pgvector hiện không hỗ trợ nguyên bản lượng tử hóa vector (ví dụ: lượng tử hóa vô hướng hoặc nhị phân) trong chỉ mục HNSW của nó. Các vector được lưu trữ dưới dạng float4[] (float32). Điều này có nghĩa là mức sử dụng bộ nhớ và I/O cao hơn đối với cùng một số lượng vector so với các lựa chọn thay thế được lượng tử hóa.

Qdrant

Qdrant cung cấp các tùy chọn lượng tử hóa mạnh mẽ:

• Lượng tử hóa vô hướng: Giảm float32 xuống int8 hoặc uint8, giảm đáng kể bộ nhớ.
• Lượng tử hóa nhị phân: Chuyển đổi float32 thành bool (1-bit), cung cấp khả năng giảm bộ nhớ mạnh mẽ nhất.

Các phương pháp này được áp dụng trong quá trình lập chỉ mục và tìm kiếm, ảnh hưởng đến cả lưu trữ và tốc độ truy vấn.

Thiết lập thử nghiệm (Qdrant):

• Lượng tử hóa vô hướng: type: 'int8', quantile: 0.99.
• Lượng tử hóa nhị phân: type: 'binary'.

import { QdrantClient } from '@qdrant/qdrant-client';

const client = new QdrantClient({ host: 'localhost', port: 6333 });

async function createQuantizedCollection(collectionName: string, quantizationType: 'scalar' | 'binary') {
  const quantizationConfig = quantizationType === 'scalar'
    ? {
        scalar: {
          type: 'int8',
          quantile: 0.99, // Quantile for dynamic range estimation
          always_ram: true, // Keep quantized vectors in RAM
        },
      }
    : {
        binary: {
          always_ram: true,
        },
      };

  await client.createCollection(collectionName, {
    vectors_config: {
      size: 768,
      distance: 'Cosine',
    },
    quantization_config: quantizationConfig,
    hnsw_config: {
      m: 16,
      ef_construct: 100,
    },
  });
  console.log(`Collection ${collectionName} created with ${quantizationType} quantization.`);
}

// createQuantizedCollection('my_collection_1m_scalar', 'scalar');
// createQuantizedCollection('my_collection_1m_binary', 'binary');

Quan sát (10 triệu vector):

• Không lượng tử hóa (float32): Kích thước chỉ mục ~28GB, độ chính xác trung bình@10 ~0.98, độ trễ P99 ~120ms.
• Lượng tử hóa vô hướng (int8): Kích thước chỉ mục ~7GB (giảm 75%). Độ chính xác@10 giảm xuống ~0.95. Độ trễ P99 ~90ms (nhanh hơn do ít di chuyển dữ liệu hơn).
• Lượng tử hóa nhị phân: Kích thước chỉ mục ~2.5GB (giảm 90%). Độ chính xác@10 giảm đáng kể xuống ~0.80. Độ trễ P99 ~70ms.

Đánh đổi: Lượng tử hóa mang lại khả năng tiết kiệm bộ nhớ đáng kể và thường cải thiện độ trễ do giảm I/O, nhưng phải trả giá bằng độ chính xác. Lượng tử hóa vô hướng cung cấp sự cân bằng tốt cho nhiều trường hợp sử dụng. Lượng tử hóa nhị phân phù hợp cho các kịch bản mà hiệu quả bộ nhớ cực cao là tối quan trọng và độ chính xác thấp hơn có thể chấp nhận được.

Tổng chi phí sở hữu (TCO) trên Google Cloud

TCO không chỉ bao gồm điện toán và lưu trữ, mà còn cả chi phí hoạt động, khả năng mở rộng và quản lý dữ liệu.

pgvector trên Cloud SQL

• Điện toán: Các phiên bản Cloud SQL thường đắt hơn trên mỗi vCPU/GB RAM so với các máy ảo GCE thô.
• Lưu trữ: Chi phí lưu trữ PostgreSQL tiêu chuẩn. Chỉ mục HNSW làm tăng đáng kể dung lượng lưu trữ.
• Chi phí hoạt động: Dịch vụ được quản lý, gánh nặng hoạt động tối thiểu cho thiết lập cơ bản. Mở rộng quy mô liên quan đến việc nâng cấp loại phiên bản hoặc bản sao đọc.
• Quản lý dữ liệu: Cơ sở dữ liệu đơn lẻ cho dữ liệu quan hệ và vector đơn giản hóa việc sao lưu, giao dịch và tính nhất quán.
• Mở rộng quy mô: Mở rộng quy mô theo chiều dọc (phiên bản lớn hơn) rất đơn giản. Mở rộng quy mô theo chiều ngang cho tìm kiếm vector bị giới hạn ở các bản sao đọc, không phân phối các ghi chỉ mục HNSW. Phân vùng pgvector thủ công rất phức tạp.

Qdrant Cloud / Tự lưu trữ trên GKE

• Qdrant Cloud: Dịch vụ được quản lý, chi phí cao hơn trên mỗi vector/truy vấn nhưng không có chi phí hoạt động.
• Tự lưu trữ trên GKE:
  • Điện toán: Các nút GKE (máy ảo GCE) rẻ hơn các phiên bản Cloud SQL cho các tài nguyên tương đương.
  • Lưu trữ: Persistent Disks (PDs) cho dữ liệu.
  • Chi phí hoạt động: Yêu cầu chuyên môn về Kubernetes để triển khai, mở rộng quy mô, giám sát và nâng cấp. Kiến trúc phân tán của Qdrant (phân vùng, sao chép) yêu cầu quản lý cẩn thận.
  • Quản lý dữ liệu: Cơ sở dữ liệu vector riêng biệt. Yêu cầu các đường ống ETL để đồng bộ hóa dữ liệu từ các nguồn chính.
  • Mở rộng quy mô: Qdrant được thiết kế để mở rộng quy mô theo chiều ngang. Các bộ sưu tập phân vùng trên nhiều nút là nguyên bản, cho phép các tập dữ liệu khổng lồ và QPS cao.

Bảng so sánh TCO

Các vấn đề và khắc phục sự cố trong sản xuất

pgvector

1. Lỗi/Chậm xây dựng chỉ mục HNSW:

   • Triệu chứng: CREATE INDEX mất quá nhiều thời gian, hoặc phiên bản PostgreSQL hết bộ nhớ và gặp sự cố.
   • Nguyên nhân: maintenance_work_mem không đủ. Xây dựng chỉ mục HNSW tốn nhiều bộ nhớ.
   • Khắc phục: Tăng maintenance_work_mem trong postgresql.conf (hoặc cờ Cloud SQL). Đối với 10 triệu vector, 4-8GB có thể cần thiết trên máy có 64GB RAM. Đảm bảo shared_buffers cũng có kích thước phù hợp (ví dụ: 25% RAM). Giám sát pg_stat_activity để theo dõi tiến độ xây dựng chỉ mục.
   • Lưu ý: Xây dựng HNSW trên một bảng lớn là một thao tác khóa độc quyền trong các phiên bản pgvector cũ hơn, chặn các ghi. PostgreSQL 17 và các phiên bản pgvector mới hơn hỗ trợ CONCURRENTLY cho HNSW, nhưng nó vẫn tăng gấp đôi mức sử dụng bộ nhớ/đĩa trong quá trình xây dựng.

2. Độ chính xác kém với HNSW:

   • Triệu chứng: Kết quả tìm kiếm không liên quan về mặt ngữ nghĩa, ngay cả đối với các truy vấn tốt đã biết.
   • Nguyên nhân: ef_construction (trong quá trình xây dựng chỉ mục) hoặc hnsw_ef (trong quá trình truy vấn) quá thấp.
   • Khắc phục: Xây dựng lại chỉ mục với ef_construction cao hơn (ví dụ: 100-200). Đối với các truy vấn, đặt hnsw_ef cao hơn (ví dụ: 64-128). Điều này làm tăng thời gian tìm kiếm nhưng cải thiện độ chính xác.
   • sqlCopy

     -- Xây dựng lại chỉ mục với ef_construction cao hơn
     DROP INDEX IF EXISTS embeddings_vector_idx;
     CREATE INDEX ON embeddings USING hnsw (vector vector_l2_ops) WITH (m = 16, ef_construction = 150);
     
     -- Truy vấn với hnsw_ef cao hơn
     SET hnsw.ef = 128;
     SELECT id, vector <-> ARRAY[...] AS distance
     FROM embeddings
     ORDER BY distance
     LIMIT 10;
     RESET hnsw.ef; -- Đặt lại cho các truy vấn tiếp theo
     

3. Độ trễ cao cho các truy vấn được lọc:

   • Triệu chứng: Các truy vấn có mệnh đề WHERE chậm mặc dù có chỉ mục HNSW.
   • Nguyên nhân: Cột mệnh đề WHERE không được lập chỉ mục, hoặc bộ lọc không đủ chọn lọc, buộc phải quét HNSW lớn.
   • Khắc phục: Đảm bảo các cột siêu dữ liệu được sử dụng trong mệnh đề WHERE có các chỉ mục B-tree hoặc GIN phù hợp. Phân tích kế hoạch truy vấn (EXPLAIN ANALYZE) để xác nhận việc sử dụng chỉ mục.

Qdrant

1. Lỗi hết bộ nhớ (OOM) khi nhập:

   • Triệu chứng: Pod/phiên bản Qdrant gặp sự cố trong quá trình nhập dữ liệu hàng loạt.
   • Nguyên nhân: hnsw_config.full_scan_threshold quá cao, hoặc hnsw_config.max_indexing_threads quá mạnh, gây ra việc cấp phát bộ nhớ quá mức trong quá trình hợp nhất phân đoạn hoặc xây dựng đồ thị HNSW.
   • Khắc phục: Giảm full_scan_threshold (ví dụ: xuống 10.000-20.000) để kích hoạt lập chỉ mục HNSW trên các phân đoạn nhỏ hơn. Giảm max_indexing_threads nếu CPU bị bão hòa. Đảm bảo đủ RAM cho các tham số m và ef_construct. Đối với các tập dữ liệu lớn, hãy cân nhắc tăng optimizers_config.default_segment_number để tạo nhiều phân đoạn hơn ban đầu, giảm kích thước của các đồ thị HNSW riêng lẻ.

2. Độ chính xác/Độ trễ không nhất quán trong thiết lập phân tán:

   • Triệu chứng: Hiệu suất truy vấn thay đổi thất thường giữa các bản sao hoặc phân vùng.
   • Nguyên nhân: Phân phối dữ liệu không đồng đều giữa các phân vùng, độ trễ mạng giữa các nút hoặc phân bổ tài nguyên không cân bằng.
   • Khắc phục: Giám sát kích thước phân vùng và số điểm. Sử dụng các thao tác replicate_shard hoặc move_shard của Qdrant để cân bằng lại. Đảm bảo hiệu suất mạng nhất quán trong cụm GKE. Kiểm tra mức sử dụng CPU/bộ nhớ trên các nút Qdrant riêng lẻ.

3. I/O đĩa cao với lượng tử hóa:

   • Triệu chứng: Mặc dù có lượng tử hóa, I/O đĩa vẫn cao, ảnh hưởng đến độ trễ.
   • Nguyên nhân: Các vector được lượng tử hóa không được tải hoàn toàn vào RAM. always_ram: false trong cấu hình lượng tử hóa.
   • Khắc phục: Đặt always_ram: true trong quantization_config cho lượng tử hóa vô hướng hoặc nhị phân. Điều này đảm bảo các vector được lượng tử hóa nằm trong bộ nhớ, giảm đáng kể I/O đĩa trong quá trình tìm kiếm. Điều này sẽ làm tăng mức sử dụng RAM nhưng cải thiện đáng kể độ trễ.

Các câu hỏi thường gặp

1. Khi nào tôi nên chọn pgvector thay vì một cơ sở dữ liệu vector chuyên dụng như Qdrant? Chọn pgvector nếu:

   • Bạn đã sử dụng PostgreSQL rộng rãi và muốn giảm thiểu sự phức tạp của cơ sở hạ tầng.
   • Tập dữ liệu vector của bạn < 5 triệu-10 triệu vector (768D).
   • Các truy vấn chính của bạn liên quan đến tính nhất quán giao dịch mạnh mẽ giữa dữ liệu quan hệ và vector.
   • Nhu cầu lọc của bạn được đáp ứng tốt bởi các chỉ mục SQL tiêu chuẩn trên siêu dữ liệu.
   • Bạn không yêu cầu các tính năng nâng cao như lượng tử hóa hoặc đa người thuê ngay lập tức.

2. Những lợi thế chính của kiến trúc phân tán của Qdrant cho tìm kiếm vector là gì? Kiến trúc phân tán của Qdrant cho phép:

   • Khả năng mở rộng theo chiều ngang: Phân vùng các bộ sưu tập trên nhiều nút để xử lý các tập dữ liệu hàng tỷ vector và tải truy vấn mỗi giây (QPS) cực cao.
   • Tính sẵn sàng cao: Sao chép các phân vùng trên các nút để đảm bảo khả năng chịu lỗi.
   • Cách ly: Cách ly khối lượng công việc bằng cách dành các nút cho các bộ sưu tập hoặc người thuê cụ thể.
   • Mở rộng quy mô động: Thêm hoặc xóa các nút khi nhu cầu thay đổi mà không cần thời gian ngừng hoạt động.

3. ef_construction liên quan đến hnsw_ef trong HNSW như thế nào, và giá trị tối ưu là gì?

   • ef_construction (thời gian xây dựng): Kiểm soát kích thước của vùng lân cận được khám phá trong quá trình xây dựng chỉ mục. Giá trị cao hơn dẫn đến đồ thị được kết nối tốt hơn, độ chính xác tốt hơn, nhưng thời gian xây dựng lâu hơn và kích thước chỉ mục lớn hơn.
   • hnsw_ef (thời gian truy vấn): Kiểm soát kích thước của danh sách ứng cử viên động trong quá trình tìm kiếm. Giá trị cao hơn dẫn đến độ chính xác tốt hơn nhưng thời gian truy vấn lâu hơn.
   • Giá trị tối ưu: Bắt đầu với m=16, ef_construction=100-200. Đối với truy vấn, đặt hnsw_ef thành k * 2 đến k * 5 (trong đó k là số kết quả được yêu cầu), hoặc 64-128 cho mục đích chung. Điều chỉnh các giá trị này dựa trên yêu cầu độ chính xác/độ trễ cụ thể của bạn.

4. Tôi có thể sử dụng pgvector với lượng tử hóa không? Không nguyên bản trong chính pgvector. Bạn sẽ cần triển khai lượng tử hóa ở lớp ứng dụng (ví dụ: lượng tử hóa các vector trước khi chèn chúng vào pgvector và sau đó thực hiện các phép tính khoảng cách gần đúng trong ứng dụng của bạn). Điều này phức tạp hơn đáng kể và kém hiệu quả hơn so với việc sử dụng cơ sở dữ liệu có hỗ trợ lượng tử hóa nguyên bản như Qdrant.

5. Tác động của chiều vector đến hiệu suất và bộ nhớ là gì? Chiều vector (ví dụ: 768D) ảnh hưởng trực tiếp đến:

   • Bộ nhớ: Mỗi chiều là một số thực (4 byte). Chiều cao hơn có nghĩa là các vector lớn hơn, dẫn đến các chỉ mục lớn hơn và mức tiêu thụ bộ nhớ cao hơn.
   • Hiệu suất: Các phép tính khoảng cách trở nên tốn kém hơn về mặt tính toán với các chiều cao hơn. Duyệt đồ thị HNSW cũng liên quan đến việc di chuyển nhiều dữ liệu hơn.
   • Độ chính xác: Các chiều cao hơn đôi khi có thể nắm bắt thông tin ngữ nghĩa sắc thái hơn, có khả năng cải thiện độ chính xác, nhưng cũng chịu nhiều "lời nguyền của chiều" hơn nếu không được quản lý cẩn thận. Giảm chiều (ví dụ: thông qua PCA hoặc các mô hình nhúng chuyên biệt) có thể cải thiện đáng kể hiệu suất và giảm bộ nhớ với chi phí là một số độ trung thực ngữ nghĩa.