Database Vektor: Pengantar Teknis [PDF]

 (tge-data-web.nyc3.digitaloceanspaces.com)
1 poin oleh GN⁺ 2024-01-13 | 1 komentar | Bagikan ke WhatsApp
  • Saat aplikasi AI menangani data tidak terstruktur dan berdimensi tinggi, database vektor menjadi penting sebagai sistem khusus untuk menyimpan dan menelusuri data dalam bentuk array angka
  • Intinya adalah menghubungkan record berdasarkan kemiripan antar atribut data, bukan baris-kolom atau relasi eksplisit, sehingga dapat memanfaatkan makna implisit
  • Ketika hubungan semantik dienkode sebagai vektor multidimensi, tugas analisis seperti pencarian kemiripan, clustering, dan klasifikasi dapat dilakukan lebih cepat
  • Dalam AI generatif, database ini digunakan untuk mengelola data berdimensi tinggi dalam jumlah besar, serta meningkatkan kecepatan pelatihan dan inferensi dan hasil personalisasi melalui pencarian vektor serupa
  • Pengindeksan tingkat lanjut mengurangi target pencarian menjadi subset yang lebih relevan untuk menurunkan waktu pencarian, serta memungkinkan kueri kompleks yang menggabungkan kemiripan dengan kondisi lain

Bentuk data yang ditangani database vektor

  • Database vektor adalah basis data khusus untuk menyimpan, mengelola, dan memproses vektor sebagai representasi data berdimensi tinggi
  • Berbeda dari basis data tradisional yang menyimpan data dalam baris dan kolom, database vektor menyimpan data sebagai vektor dalam ruang multidimensi
  • Setiap vektor adalah array angka yang merepresentasikan karakteristik atau atribut dari suatu titik data

Koneksi berbasis makna dan kemiripan

  • Basis data tradisional menetapkan hubungan antar elemen berdasarkan tautan eksplisit atau hierarki
  • Database vektor menghubungkan record secara algoritmis berdasarkan kemiripan atribut data
  • Pendekatan ini memungkinkan terciptanya koneksi yang lebih intuitif berdasarkan makna implisit di dalam elemen basis data

Struktur yang disesuaikan untuk kueri analitis

  • Ketika data dienkode sebagai vektor multidimensi, yaitu array angka yang mencerminkan hubungan semantik, tugas analitis tingkat lanjut dapat dijalankan dengan cepat
  • Operasi yang didukung mencakup pencarian kemiripan, clustering, dan klasifikasi
  • Model komputasi ini cocok untuk deteksi pola, analitik prediktif, dan aplikasi dengan kebutuhan analisis yang tinggi

Pemanfaatan dalam AI dan AI generatif

  • Meluasnya AI dan machine learning menjadi latar belakang utama meningkatnya permintaan akan database vektor
  • Di ranah AI generatif, database vektor dirancang untuk menyimpan dan mengelola data berdimensi tinggi dalam jumlah besar secara efisien
  • Kemampuan untuk dengan cepat menelusuri dan mengambil hasil dari vektor serupa dapat sangat mempercepat proses pelatihan dan inferensi model AI generatif
  • Database ini juga dimanfaatkan agar sistem AI generatif dapat memberikan konten yang lebih dipersonalisasi dan lebih relevan kepada pengguna

Pengindeksan dan kondisi pencarian yang kompleks

  • Database vektor menggunakan teknik pengindeksan tingkat lanjut untuk menelusuri dan mencari vektor serupa dengan cepat
  • Indeks mempersempit target pencarian ke subset vektor yang lebih kecil dan lebih relevan, sehingga waktu pencarian berkurang secara signifikan
  • Basis data ini juga dapat menangani kueri kompleks yang menggabungkan kondisi kemiripan dengan kriteria pencarian lainnya
  • Fleksibilitas ini penting dalam aplikasi AI tingkat lanjut yang memerlukan kemampuan pencarian yang canggih

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-13
Opini Hacker News
  • Beberapa materi tambahan:
    A Comprehensive Survey on Vector Database: Storage and Retrieval Technique, Challenge: https://arxiv.org/abs/2310.11703
    Survey of Vector Database Management Systems: https://arxiv.org/abs/2310.14021
    What are Embeddings: https://raw.githubusercontent.com/veekaybee/what_are_embeddi...
    Penyebutan sumber: https://twitter.com/eatonphil/status/1745524630624862314 dan https://twitter.com/ChristophMolnar/status/17457316026829826...
  • Slide apakah perlu basis data vektor khusus cukup menarik, tetapi sebenarnya tidak menjawab pertanyaan itu
    Itu juga bagian yang membuat saya penasaran, jadi akan bagus kalau ada kriteria atau aturan praktisnya
    Baru-baru ini saya mencoba menangani embedding dengan tool llm yang luar biasa dari Simon Willison, dan pendekatannya paling sederhana: menyimpan embedding di SQLite bersama beberapa UDF untuk perhitungan jarak
    Kesederhanaan ini menarik, tetapi begitu traffic dan data melewati level tertentu, pasti akan perlu basis data yang lebih terspesialisasi; saya penasaran kira-kira di mana batasnya
    • Beberapa tahun lalu saya pernah membuat indeks vektor yang memakai LSH
      Pencariannya dilakukan dengan cara paling sederhana, menyapu semuanya dan membandingkan jarak Hamming (xor dan popcount); di satu core MBP keluaran 2011, saya bisa memindai 200 ribu hash dalam kurang dari 10 ms untuk menemukan item yang paling mirip
    • Saya pernah menskalakan engine cepat dan kotor yang menjalankan findsight.ai hingga puluhan juta vektor, dan detailnya ada di presentasi ini: https://youtu.be/elNrRU12xRc?t=1556
      Kodenya kira-kira 1.000 baris, jadi pada akhirnya tidak perlu basis data vektor eksternal
    • Sejujurnya, untuk sekitar 100 ribu vektor, pendekatan memuat semuanya ke memori, atau memakai SQLite, pgvector, dan semacamnya sudah sepenuhnya memadai
      Namun di atas itu, opsi yang layak seperti Pinecone menjadi rumit, lambat, dan kelewat mahal
      Sepengetahuan saya, opsi terbaik adalah turbopuffer.com; biayanya kira-kira 100 kali lebih murah daripada Pinecone dan tampaknya benar-benar bisa diskalakan
      Karena tidak ada dalam daftar rekomendasi vector DB di slide, saya lemparkan sebagai rekomendasi yang cukup bagus
    • Mungkin tergantung kasusnya, tetapi tulisan yang muncul beberapa minggu lalu ini sangat membantu kami berfokus pada bagaimana seharusnya memikirkan apa yang benar-benar dibutuhkan: pada akhirnya yang dibutuhkan adalah mesin pencari
      https://news.ycombinator.com/item?id=38703943
  • Beberapa bulan lalu saya mengadakan kelas basis data vektor untuk klien privat TGE Data, lalu setelah itu memutuskan merekamnya sebagai kuliah singkat untuk audience yang lebih luas
    Kuliah ini memadukan teori dan demo yang membahas konsep dasar vektor, basis data vektor, indeks, dan similarity search, lalu diakhiri dengan demo basis data Pinecone dan Weaviate
    • Keren. Jadi ada video juga?
  • Ini materi pengantar yang bagus, tetapi saya merasa pengantar seperti ini terlalu cepat melewati persoalan pemilihan fitur
    Pada tahap ini, penilaian manusia masuk dengan sangat halus, kadang hampir sampai diabaikan, sehingga dari luar tampak seperti sistem “cuma matematika” yang sangat terotomatisasi
    Ambil audio sebagai contoh: fitur apa yang akan diekstrak untuk membuat vektor berdimensi N? Jawaban mudahnya mungkin “sebanyak mungkin”
    Namun pertama, bahkan fitur yang mudah diberi nama pun belum tentu memiliki akses ke data karakterisasinya
    Kedua, tanpa pengetahuan domain yang mendalam, Anda mungkin bahkan tidak tahu adanya fitur laten yang seharusnya dipakai
    Ketiga, sekalipun memiliki pengetahuan domain yang mendalam, Anda masih mungkin tidak tahu fitur laten yang seharusnya dipakai
    Misalnya, anggap Anda penggemar musik minimalis dengan phase shifting ala Reich. Anda mengajukan kueri tidak langsung ke basis data vektor untuk mencari musik yang mirip dengan karya representatif genre ini, misalnya Piano Phase
    Basis data menggunakan berbagai fitur audio dan musik seperti frekuensi dominan, interval antar-onset nada, volume, fitur timbre berbasis distribusi frekuensi, serta root dan tangga nada yang tampak

Namun jika kumpulan fitur basis data tidak memiliki “interval antar-nada yang konstan seiring waktu”, kueri mungkin bisa menemukan hal-hal yang mirip dalam timbre, harmoni, melodi, dan ritme, tetapi untuk menemukan lagu yang berbagi ciri inti berupa fase relatif dua garis melodi yang berubah secara konsisten, itu sepenuhnya bergantung pada keberuntungan
Tidak sulit membuat contoh serupa untuk jenis data apa pun, seperti visual, teks, numerik, dan sebagainya
Tentu saja, ini bukan berarti basis data vektor dan klasifikasi fitur tidak berguna
Salah satu pertanyaan awal yang harus diajukan saat berhasil atau gagal menemukan pola kecocokan dalam dataset tertentu adalah apakah kumpulan fitur dijamin kuat sudah lengkap, dan jika tidak, bagaimana perlu diperluas

  • Basis data vektor diarahkan untuk pencarian dan pengambilan hasil pencarian
    Biasanya cara membuat vektor adalah dengan melakukan fine-tuning pada model pralatih berskala besar lalu mengekstrak representasi internalnya
    Karena dataset berisi kueri yang berhasil beserta hasil pengambilannya, cukup optimalkan fungsi loss terhadap tujuan kemiripan yang didukung basis data vektor menggunakan input mentah
    Pada modalitas umum seperti tabel, teks, gambar, dan audio, hampir tidak ada penilaian manusia yang masuk ke pemilihan fitur; cukup terapkan attention
    Sebagai catatan, model teks-ke-vektor mutakhir seperti E5-Mistral bahkan tidak memerlukan kurasi manusia dalam dataset

  • Anda tepat menyoroti soal “tidak tahu apa yang tidak diketahui”
    Senang melihat penggemar Steve Reich lainnya, dan saya penasaran rekomendasi lagu yang mirip dengan Music for 18 Musicians favorit saya

  • Ini ikhtisar yang bagus, tetapi bagian terakhir tidak membahas pertanyaan klise tentang harus memakai penyimpanan vektor seperti Postgres+pgvector atau basis data vektor seperti Pinecone
    Saya ingin melihat lebih banyak presentasi yang membahas berbagai trade-off seperti kecepatan kueri, kecepatan insert dan pembangunan indeks, kemudahan penggunaan, dan seterusnya, agar membantu memilih yang sesuai untuk tiap aplikasi

    • Dulu saya mulai mengumpulkan perbandingan berbagai alat pencarian vektor: http://vectorsearch.dev/
      PR selalu diterima
    • Saya akan menyebut yang pertama sebagai ekstensi vektor
      Basis data adalah penyimpanan yang diberi berbagai fitur tambahan

  • digitaloceanspaces.com adalah penyedia hosting bergaya S3, jadi akan bagus jika Hacker News memperlakukannya secara khusus dan menampilkannya seperti tge-data-web.nyc3.digitaloceanspaces.com, alih-alih menyederhanakan domainnya menjadi digitaloceanspaces.com
    Namun S3 juga tampaknya punya masalah yang sama: https://news.ycombinator.com/item?id=38876761
    Ada preseden di tempat lain. Situs subdomain x.github.io diperlakukan khusus di sini: https://news.ycombinator.com/from?site=lfranke.github.io

  • Materi ini terlihat cukup berbahaya untuk dijadikan titik awal oleh engineer
    Pernyataan seperti dikelompokkan berdasarkan makna atau dioptimalkan untuk analitik terasa meragukan
    Pengelompokan bergantung pada embedding yang dihitung. Jika Anda percaya embedding itu mendekati makna data dengan baik, mungkin tidak apa-apa berpikir seperti itu
    Namun mudah membayangkan embedding yang mematahkan asumsi tersebut. Misalnya, meski file audio dan file teks dengan makna yang sama dimasukkan ke proses embedding yang sama, jika bukan multimodal, keduanya kemungkinan besar akan berjauhan di ruang vektor embedding
    Ke depannya, saya yakin akan muncul embedding yang menempatkan objek berdekatan di ruang vektor berdasarkan cara pemanfaatannya, bukan kemiripan semantik
    Jika membuat sistem rekomendasi, Anda tidak ingin mengelompokkan berbagai variasi pembelian sekali pakai secara berdekatan
    Misalnya, penerbangan yang paling mirip secara semantik mungkin penerbangan lain ke tujuan yang sama pada jam berbeda atau penerbangan ke bandara terdekat, tetapi dalam praktiknya Anda mungkin ingin mengelompokkan hotel yang sering dibeli bersama oleh orang-orang yang membeli penerbangan tersebut
    Basis data vektor juga dapat memasukkan dimensi tambahan seperti kesadaran waktu ke dalam data. Tidak harus selalu memakai vektor yang mengodekan makna
    Jadi basis data vektor dioptimalkan untuk lookup atau pencarian berbasis vektor input, bukan mirip dengan kueri OLAP
    Ini lebih dekat ke Elasticsearch daripada Snowflake. Jika Anda menggunakan basis data vektor dengan ekspektasi reporting atau analitik skala besar atas ruang vektor, sejauh yang saya tahu belum ada produk yang benar-benar layak dipakai saat ini

    • Perhitungan embedding masih misterius bagi saya
      Saya paham bahwa dari foto apel kita menuju vektor yang merepresentasikan “keapelannya”, lalu vektor itu dibandingkan dengan vektor lain menggunakan matematika biasa
      Yang tidak saya pahami adalah siapa/apa yang menerima gambar sebagai input dan mengeluarkan vektor
      Dokumen juga sama. Jika ingin menambahkan dimensi dengan cara memasukkan satu angka lagi ke array, bagian mana dari basis data vektor yang harus dimodifikasi agar dimensi itu ikut dalam perhitungan vektor?
      Atau apakah proses mengubah dokumen, gambar, atau apa pun menjadi representasi vektor dilakukan dengan cara lain di luar basis data?
      Sunting: perhitungan embedding tampaknya seperti tugas algoritma machine learning, tetapi kalau begitu algoritma itu juga harus dilatih lebih dulu. Pada akhirnya ini seolah berlanjut tanpa henti ke pelatihan

  • Saya tidak tahu mengapa PQ dicantumkan sebagai “strategi indeks”
    PQ adalah teknik kompresi dan kuantisasi vektor, bukan sarana untuk mempartisi ruang pencarian
    Anda bisa mengenkode vektor dengan PQ pada exhaustive search/flat index, indeks IVF, maupun HNSW, dan di Faiss masing-masing tersedia sebagai IndexPQ, IndexIVFPQ, dan IndexHNSWPQ
    Jika mau, ini juga bisa dipakai bersama k-D tree atau ANNOY
    Pernyataan “gunakan HNSW atau Annoy untuk dataset yang sangat besar ketika kecepatan kueri lebih penting daripada presisi” juga bermasalah
    Teknik berbasis graf memiliki overhead memori dan biaya pembangunan yang besar, dan tidak praktis untuk dataset skala 1 miliar
    Biasanya memang lebih akurat dan cepat daripada teknik IVF, karena untuk memperoleh akurasi serupa IVF harus mengunjungi banyak sel
    Sebaliknya, berbeda dari teknik lain, IVF dapat diskalakan hingga basis data skala 1 triliun tanpa overhead besar, sambil tetap menawarkan trade-off kecepatan dan akurasi yang masuk akal
    Saya akan mengatakan “gunakan untuk dataset ukuran menengah ketika kecepatan kueri penting tetapi Anda juga menginginkan akurasi tinggi, dan flat/exhaustive index tidak realistis”

    • Ini mengubah ruang kontinu menjadi ruang diskret
      Lakukan PQ terlebih dahulu, lalu jalankan KNN pada vektor diskret baru
      Dengan begitu, ruang kosakata dapat dikompresi ke ukuran tetap

  • Pada tabel di slide 15, kolom Indexing & Search Efficiency untuk Traditional Databases dan Vector Databases tampaknya tertukar

    • Menurut saya juga baris terakhir tampaknya tertukar

  • Apakah ada rekomendasi basis data embedding tertanam seperti SQLite?
    Untuk masalah berskala kecil, tetapi akan lebih baik jika lebih praktis daripada LMDB + FAISS