View a markdown version of this page

Praktik terbaik untuk indeks vektor - Amazon DynamoDB

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik untuk indeks vektor

Rekomendasi berikut membantu Anda merancang indeks vektor yang akurat, berkinerja, dan hemat biaya.

Pilih model dan dimensi embedding Anda terlebih dahulu

Model penyematan yang Anda gunakan menentukan jumlah dimensi yang dimiliki vektor Anda, dan Anda atur Dimensions saat membuat indeks. Anda tidak dapat mengubah jumlah dimensi setelah pembuatan. Tentukan model embedding sebelum Anda membuat indeks, dan gunakan model yang sama untuk menghasilkan vektor yang disimpan dan vektor kueri. Dimensi yang lebih sedikit mengurangi biaya pencarian, penulisan, dan penyimpanan, tetapi model dimensi yang lebih tinggi dapat menangkap lebih banyak detail semantik. Pilih jumlah dimensi terkecil yang memenuhi persyaratan relevansi Anda. Lihat Menghasilkan penyematan vektor.

Cocokkan fungsi jarak dengan penyematan Anda

Pilih fungsi jarak yang cocok dengan bagaimana model embedding Anda mewakili kesamaan. COSINEmembandingkan arah dan mengabaikan besaran, yang sesuai dengan sebagian besar model penyematan teks. EUCLIDEANmengukur jarak absolut dan peka terhadap besaran. DOT_PRODUCTjuga sensitif terhadap besarnya. Jika Anda menggunakannya, normalisasi penyematan Anda ke panjang satuan sehingga skor mencerminkan arah daripada panjang vektor. Anda tidak dapat mengubah fungsi jarak setelah Anda membuat indeks, jadi validasi pilihan Anda terhadap kumpulan data representatif terlebih dahulu. Lihat Bagaimana fungsi jarak memberi peringkat hasil.

Pilih kunci partisi yang cocok dengan pola kueri Anda

Kunci partisi membatasi setiap SearchVectors panggilan ke bagian indeks vektor yang termasuk dalam nilai kunci partisi tunggal. Panggilan tidak mencari seluruh indeks. Mencari lebih sedikit data menurunkan biaya, dapat meningkatkan latensi dan penarikan, dan menskalakan throughput secara horizontal di seluruh nilai kunci partisi.

Anda harus memberikan nilai kunci partisi SearchConditionExpression di setiap pencarian. Setiap pencarian dicakup ke tepat satu nilai kunci partisi. Pilih kunci partisi yang cocok dengan pola kueri yang didukung aplikasi Anda.

Misalnya, jika Anda menyimpan data berbasis lokasi berdasarkan negara bagian AS, Anda memiliki sekitar 50 nilai kunci partisi. Setiap negara memiliki sejumlah vektor yang berarti untuk ingatan yang baik. Partisi 50 menyediakan hingga sekitar 50x penskalaan throughput horizontal. Ini berfungsi ketika setiap pencarian menargetkan satu negara.

Hindari kardinalitas ekstrem di kedua arah:

  • Terlalu tinggi (misalnya, ID item unik) — Setiap partisi berisi satu item tanpa tetangga untuk dibandingkan, yang menghasilkan daya ingat yang buruk.

  • Terlalu rendah (misalnya, boolean) — Sebagian besar item mendarat di satu partisi, yang membatasi penskalaan throughput dan mengurangi latensi dan manfaat biaya.

Untuk memfilter lebih lanjut dalam partisi, gunakan atribut filter sebaris.

Contoh throughput. Pertimbangkan model penyematan 768 dimensi (seperti Cohere Embed v3) dengan 1 KB data item non-vektor, memberikan ukuran item total sekitar 4 KB (768 dimensi × 4 byte +1 KB). Dengan ukuran item ini, batas kunci per partisi diterjemahkan menjadi:

  • Cari: 1 GBps ÷ 4 KB ≈ 250.000 vektor diperiksa per detik per nilai kunci partisi. Seiring bertambahnya jumlah vektor dalam partisi, setiap pencarian memeriksa lebih banyak data dan Anda akan mendekati batas ini lebih cepat.

  • Tulis: 10 MBps ÷ 4 KB ≈ 2.500 penulisan vektor per detik per nilai kunci partisi

Menyebarkan data Anda di lebih banyak nilai kunci partisi melipatgandakan batas ini. Misalnya, 50 nilai kunci partisi menyediakan hingga 50× pencarian agregat dan throughput tulis. Jika beban kerja Anda melebihi batas kunci per partisi ini, hubungi Dukungan. AWS

Jaga agar penyematan tetap sinkron dengan konten sumber

DynamoDB tidak menghitung ulang penyematan untuk Anda. Setiap kali Anda mengubah konten sumber yang diwakili oleh penyematan, buat ulang vektor dengan model penyematan yang sama dan tulis kembali ke item. Jika tidak, indeks terus mengembalikan hasil berdasarkan vektor basi. Pertimbangkan untuk menangkap perubahan konten dengan DynamoDB Streams dan menggunakan proses hilir untuk meregenerasi dan menulis ulang penyematan yang terpengaruh.

Proyeksikan hanya atribut yang Anda butuhkan

SearchVectorstidak dapat mengembalikan atribut yang tidak diproyeksikan ke dalam indeks vektor. Memproyeksikan lebih banyak atribut meningkatkan penyimpanan indeks dan biaya penulisan. Proyeksikan atribut yang dibaca aplikasi Anda langsung dari hasil pencarian, dan ambil sisanya dengan tindak lanjut GetItem atau BatchGetItem pada tabel dasar saat Anda membutuhkannya.

Gunakan beberapa indeks untuk membandingkan model penyematan

Anda dapat membuat hingga 5 indeks vektor pada satu tabel. Gunakan indeks terpisah untuk mengevaluasi model penyematan yang berbeda atau versi model secara berdampingan. Simpan setiap penyematan model dalam atribut vektor yang berbeda dan buat indeks vektor untuk masing-masing. Ini memungkinkan Anda membandingkan kualitas pencarian antar model dengan data dasar yang sama tanpa memigrasikan indeks produksi Anda.

Misalnya, saat memutakhirkan dari satu versi model ke versi lain, buat indeks kedua dengan dimensi model baru dan fungsi jarak. Isi ulang dengan penyematan dari model baru, jalankan kueri uji terhadap kedua indeks, dan bandingkan relevansi. Setelah puas, migrasikan aplikasi Anda ke indeks baru dan hapus yang lama.