Vektör Veritabanları: Teknik Bir Başlangıç Kılavuzu [PDF]

 (tge-data-web.nyc3.digitaloceanspaces.com)
1 puan yazan GN⁺ 2024-01-13 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka uygulamaları yapılandırılmamış ve yüksek boyutlu verilerle çalıştıkça, vektör veritabanları verileri sayısal diziler biçiminde depolayıp arayan özel sistemler olarak önem kazanıyor
  • Temel nokta, kayıtları satır-sütunlar ya da açık ilişkiler yerine veri özellikleri arasındaki benzerliğe göre bağlayarak örtük anlamdan yararlanmak
  • Anlamsal ilişkiler çok boyutlu vektörler olarak kodlandığında benzerlik araması, kümeleme ve sınıflandırma gibi analiz işleri daha hızlı yapılabiliyor
  • Üretken yapay zekada, büyük miktarda yüksek boyutlu veriyi yönetmek ve benzer vektör aramasıyla eğitim ve çıkarım hızını ve kişiselleştirilmiş sonuçları iyileştirmek için kullanılıyor
  • Gelişmiş indeksleme, arama hedefini yüksek alakalılığa sahip bir alt kümeye indirerek arama süresini azaltıyor ve benzerliği diğer koşullarla birleştiren karmaşık sorguları mümkün kılıyor

Vektör veritabanlarının işlediği veri biçimi

  • Vektör veritabanı, yüksek boyutlu veri temsilleri olan vektörleri depolamak, yönetmek ve işlemek için özel bir veritabanıdır
  • Geleneksel veritabanları verileri satır ve sütunlarda saklarken, vektör veritabanları verileri çok boyutlu uzayda vektörler olarak saklar
  • Her vektör, bir veri noktasının özelliklerini veya niteliklerini temsil eden sayısal bir dizidir

Anlam ve benzerlik temelli bağlantılar

  • Geleneksel veritabanları, öğeler arasındaki ilişkileri açık bağlantılar veya hiyerarşiler temelinde kurar
  • Vektör veritabanları, kayıtları veri özelliklerinin benzerliğine göre algoritmik olarak bağlar
  • Bu yöntem, veritabanı öğelerinin içindeki örtük anlama dayanarak daha sezgisel bağlantılar oluşturabilir

Analitik sorgulara göre yapılandırma

  • Veriler, anlamsal ilişkileri yansıtan çok boyutlu vektörler, yani sayısal diziler olarak kodlandığında gelişmiş analiz işleri hızlı biçimde gerçekleştirilebilir
  • Desteklenen işlemler arasında benzerlik araması, kümeleme ve sınıflandırma bulunur
  • Hesaplama modeli; örüntü tespiti, öngörüsel analiz ve yüksek analiz gereksinimleri olan uygulamalar için uygundur

Yapay zeka ve üretken yapay zekada kullanım

  • Yapay zeka ve makine öğreniminin yaygınlaşması, vektör veritabanlarına talebin artmasının başlıca nedenlerinden biridir
  • Üretken yapay zeka alanında vektör veritabanları, büyük miktarda yüksek boyutlu veriyi verimli şekilde depolamak ve yönetmek üzere tasarlanmıştır
  • Benzer vektörleri hızla arayıp sonuçları getirebildiği için üretken yapay zeka modellerinin eğitim ve çıkarım süreçlerini önemli ölçüde hızlandırabilir
  • Üretken yapay zeka sistemlerinin kullanıcılara daha kişiselleştirilmiş ve daha alakalı içerik sunmasına da yardımcı olur

İndeksleme ve karmaşık arama koşulları

  • Vektör veritabanları, benzer vektörleri hızla sorgulamak ve aramak için gelişmiş indeksleme teknikleri kullanır
  • İndeks, arama hedefini daha küçük ve daha alakalı vektör alt kümelerine daraltarak arama süresini önemli ölçüde azaltır
  • Benzerlik koşullarını diğer arama ölçütleriyle birleştiren karmaşık sorguları da işleyebilir
  • Bu esneklik, gelişmiş arama özellikleri gerektiren ileri düzey yapay zeka uygulamaları için önemlidir

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-13
Hacker News görüşleri
  • Birkaç ek kaynak:
    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...
    Kaynak atfı: https://twitter.com/eatonphil/status/1745524630624862314 ve https://twitter.com/ChristophMolnar/status/17457316026829826...
  • Özel bir vektör veritabanına ihtiyaç var mı slaytı oldukça ilginç ama asıl bu soruya cevap vermiyor
    Bu benim de merak ettiğim bir noktaydı; bir kıstas veya pratik kural olsa iyi olurdu
    Kısa süre önce Simon Willison’ın harika llm aracıyla embedding’lerle uğraştım; yaklaşım olabilecek en basit şeydi: mesafe hesaplamak için birkaç UDF ile birlikte embedding’leri SQLite’ta saklamak
    Bu sadelik cazip, ama trafik ve veri belli bir eşiği aşınca daha uzmanlaşmış bir veritabanına ihtiyaç duyulacağı açık; merak ettiğim şey bu sınırın yaklaşık nerede olduğu
    • Birkaç yıl önce LSH kullanan bir vektör indeksi yapmıştım
      Arama en basit haliyle her şeyi tarayıp Hamming mesafesiyle (xor ve popcount) karşılaştırıyordu; 2011 model tek çekirdekli bir MBP üzerinde 200 bin hash değerini 10ms’nin altında tarayıp en benzer öğeyi bulabiliyordum
    • findsight.ai’yi çalıştıran hızlı ve kirli motoru on milyonlarca vektöre kadar ölçeklendirdim; ayrıntılar bu sunumda var: https://youtu.be/elNrRU12xRc?t=1556
      Yaklaşık 1.000 satır koddu, yani sonunda harici bir vektör veritabanına ihtiyaç olmadı
    • Dürüst olmak gerekirse 100 bin kadar vektör için her şeyi belleğe alma yaklaşımı ya da SQLite, pgvector gibi çözümler tamamen yeterli
      Ama bunun ötesinde Pinecone gibi makul seçenekler karmaşıklaşıyor, yavaşlıyor ve saçma derecede pahalı hale geliyor
      Benim bildiğim en iyi seçenek turbopuffer.com; Pinecone’dan yaklaşık 100 kat daha ucuz ve gerçekten ölçekleniyor gibi görünüyor
      Slayttaki önerilen vektör DB listesinde yoktu, ben de iyi bir öneri olarak bırakayım dedim
    • Duruma göre değişir ama birkaç hafta önce çıkan şu yazı, gerçekte neye ihtiyacımız olduğunu nasıl düşünmemiz gerektiğine odaklanmamda çok yardımcı oldu: sonuçta ihtiyaç duyduğumuz şey bir arama motoruydu
      https://news.ycombinator.com/item?id=38703943
  • Birkaç ay önce TGE Data’nın özel bir müşterisi için vektör veritabanı dersi vermiştim; ardından bunu daha geniş bir kitle için kısa bir ders olarak kaydetmeye karar verdim
    Bu ders; vektörler, vektör veritabanları, indeksler ve benzerlik aramasının temel kavramlarını kapsayan teori ile demoları birleştiriyordu ve sonunda Pinecone ile Weaviate veritabanı demolarıyla bitiyordu
    • Harika. O zaman bir video da var mı?
  • İyi bir giriş kaynağı ama bu tür tanıtımların özellik seçimi meselesini fazla hızlı geçtiğini düşünüyorum
    Bu aşamada insan muhakemesi çok ince bir biçimde, bazen neredeyse yok sayılacak ölçüde devreye giriyor; buna rağmen dışarıdan bakınca çok otomatikleştirilmiş, “tamamen matematikten ibaret” bir sistem gibi görünüyor
    Ses örneğini ele alırsak, N boyutlu bir vektör oluşturmak için hangi özellikleri çıkaracaksınız? Kolay cevap “olabildiğince çok” olabilir
    Ama birincisi, kolayca adlandırılabilen özellikler bile özelliklendirme verisinde erişilebilir olmayabilir
    İkincisi, alan bilgisi derin değilse kullanmanız gereken örtük özelliklerin varlığından bile habersiz olabilirsiniz
    Üçüncüsü, alan bilginiz derin olsa bile yine de kullanmanız gereken örtük özellikleri bilmiyor olabilirsiniz
    Örneğin Reich tarzı faz kaydırmalı minimal müziğin hayranı olduğunuzu varsayalım. Bu türün tipik bir örneği olan, örneğin Piano Phase’e benzeyen müzikleri bulmak için vektör veritabanına dolaylı bir sorgu yapıyorsunuz
    Veritabanı; baskın frekans, nota başlangıçları arasındaki aralık, ses yüksekliği, frekans dağılımına dayalı tını özellikleri, algılanan kök nota ve gam gibi çeşitli ses ve müzik özelliklerini kullanıyor

Ancak veritabanının özellik kümesinde “zamana göre notalar arasındaki aralığın sabit olması” yoksa, sorgu tını, armoni, melodi ve ritmi benzer olanları bulabilir ama temel özellik olan iki melodik çizginin göreli fazının sürekli değişmesini paylaşan parçaları bulmak tamamen şansa kalır
Görsel, metin, sayısal veri gibi her tür veride benzer örnekler üretmek zor değil
Elbette bu, vektör veritabanlarının ve özellik sınıflandırmasının işe yaramadığı anlamına gelmez
Belirli bir veri kümesinde eşleşme kalıpları bulunurken ya da bulunamazken en başta sorulması gereken sorulardan biri, özellik kümesinin tam olduğuna dair güçlü bir güvence olup olmadığı, yoksa bunun nasıl genişletileceğidir

  • Vektör veritabanları arama ve arama sonucunu geri getirme için ayarlanmıştır
    Genelde vektör üretme yöntemi, büyük ölçekli ön-eğitimli bir modeli ince ayar yapıp iç temsillerini çıkarmaktır
    Veri kümesinde başarılı sorgu ve geri getirme sonuçları bulunduğundan, ham girdiyi kullanıp vektör veritabanının desteklediği benzerlik hedefine göre kayıp fonksiyonunu optimize etmek yeterlidir
    Tablo, metin, görüntü, ses gibi genel biçimlerde özellik seçiminde insan yargısı neredeyse hiç devreye girmez; sadece attention uygulanır
    Bu arada E5-Mistral gibi modern metin-vektör modelleri, veri kümesinde insan kürasyonu bile gerektirmez

  • “Bilmediğini bilmeme” noktasını iyi yakalamış
    Bir başka Steve Reich hayranı görmek güzel; sevdiğim Music for 18 Musicians benzeri parça önerilerini merak ediyorum

  • Harika bir genel bakış, ancak son bölüm Postgres+pgvector gibi bir vektör deposu ile Pinecone gibi bir vektör veritabanı arasında hangisinin seçileceğine dair klişe soruyu ele almıyor
    Sorgu hızı, ekleme/indeks oluşturma hızı, kullanım kolaylığı gibi çeşitli ödünleşmeleri tartışıp her uygulama için uygun seçime yardımcı olan daha fazla sunum görmek isterim

    • Bir zamanlar çeşitli vektör arama araçlarının karşılaştırmalarını toplamaya başlamıştım: http://vectorsearch.dev/
      PR her zaman memnuniyetle karşılanır
    • İlkine vektör eklentisi derim
      Veritabanı, depolama katmanına türlü türlü işlevler eklenmiş halidir

  • digitaloceanspaces.com S3 tarzı bir barındırma sağlayıcısı, bu yüzden Hacker News’in buna özel işlem uygulayıp alan adını sadece digitaloceanspaces.com diye göstermek yerine tge-data-web.nyc3.digitaloceanspaces.com gibi göstermesi iyi olurdu
    Gerçi S3’te de aynı sorun var gibi görünüyor: https://news.ycombinator.com/item?id=38876761
    Başka yerlerde emsal var. x.github.io alt alan siteleri burada özel işleme tabi tutuluyor: https://news.ycombinator.com/from?site=lfranke.github.io

  • Bu materyal, mühendislerin başlangıç noktası olarak kullanması için oldukça riskli görünüyor
    Anlama göre kümelendiği ya da analize optimize edildiği gibi ifadeler şüpheli
    Kümelenme, hesaplanan embedding’e bağlıdır. Embedding’in verinin anlamını iyi yaklaştırdığına inanıyorsanız böyle düşünmek kabul edilebilir olabilir
    Ama bunu bozan embedding’leri hayal etmek kolay. Örneğin anlamca aynı olan bir ses dosyası ile bir metin dosyasını aynı embedding sürecine soksanız bile, multimodal değilse embedding vektör uzayında büyük olasılıkla birbirlerinden uzak düşerler
    Gelecekte, anlamsal benzerlikten çok kullanım biçimine göre vektör uzayında birbirine yakın yerleştirilen embedding’lerin kesinlikle ortaya çıkacağını düşünüyorum
    Bir öneri sistemi kuruyorsanız, tek seferlik bir satın almanın çeşitli varyasyonlarını birbirine yakın gruplamak istemezsiniz
    Örneğin anlamsal olarak en benzer uçuşlar aynı varış noktasına giden farklı saatlerdeki uçuşlar veya yakın havalimanlarına giden uçuşlar olabilir; ama pratikte, o uçuşu alanların sıkça birlikte satın aldığı otelleri gruplayıp göstermek isteyebilirsiniz
    Vektör veritabanları, zaman farkındalığı gibi ek boyutları da veriye katabilir. Anlamı kodlayan vektörleri kullanmak zorunda değilsiniz
    Bu yüzden vektör veritabanları, girdi vektörüne dayalı sorgulama ya da arama için optimize edilmiştir; OLAP sorgularına benzemez
    Snowflake’ten çok Elasticsearch’e daha yakındır. Vektör uzayı üzerinde raporlama ya da büyük ölçekli analiz beklentisiyle vektör veritabanı kullanacaksanız, benim bildiğim kadarıyla şu anda doğrudan kullanılabilir bir ürün yok

    • Embedding hesaplama benim için hâlâ bir gizem
      Bir elma fotoğrafından “elmalık” özelliğini temsil eden bir vektöre gidildiğini ve sonra bu vektörün sıradan matematikle başka vektörlerle karşılaştırıldığını anlıyorum
      Anlamadığım şey, görüntüyü girdi alıp vektör üreten kişi/şeyin kim/ne olduğu
      Belgeler için de aynı şey geçerli. Diziye bir sayı daha ekleyerek bir boyut eklemek istersem, vektör veritabanının hangi kısmını değiştirirsem o boyut vektör hesabına dahil olur?
      Yoksa belgeyi, görüntüyü ya da her neyse onu vektör temsiline çevirme süreci veritabanının dışında başka bir yöntemle mi yapılıyor?
      Düzeltme: Embedding hesaplama işi makine öğrenimi algoritmalarının görevi gibi görünüyor, ama o zaman o algoritmaların da önce eğitilmesi gerekir. Sonuçta iş sonsuz bir eğitim zincirine çıkıyor

  • PQ’nun neden bir “indeks stratejisi” olarak listelendiğini anlamıyorum
    PQ, vektör sıkıştırma/kuantizasyon tekniğidir; arama uzayını bölme yöntemi değildir
    Vektörleri PQ ile brute-force/düz indeks, IVF indeks ve HNSW içinde kodlayabilirsiniz; Faiss’te bunlar sırasıyla IndexPQ, IndexIVFPQ, IndexHNSWPQ olarak yer alır
    İsterseniz k-D ağaçları veya ANNOY ile de kullanabilirsiniz
    “Sorgu hızı doğruluktan daha önemliyse çok büyük veri kümeleri için HNSW ya da Annoy kullanın” sözü de sorunlu
    Grafik tabanlı tekniklerin bellek ek yükü ve kurulum maliyeti büyüktür; milyar ölçekli veri kümeleri için pratik değildir
    Genelde IVF tekniklerinden daha doğru ve daha hızlıdırlar, ama benzer doğruluğu elde etmek için IVF’in çok sayıda hücreyi ziyaret etmesi gerekir
    Buna karşılık IVF, diğer tekniklerin aksine büyük ek yük olmadan trilyon ölçekli veritabanlarına kadar ölçeklenebilir ve yine de makul hız/doğruluk ödünleşmesi sunar
    Ben olsam, “sorgu hızı önemli ama yüksek doğruluk da istiyorsanız ve düz/brute-force indeksin gerçekçi olmadığı orta ölçekli veri kümelerinde kullanın” derdim

    • Bu, sürekli bir uzayı ayrık bir uzaya dönüştürmektir
      Önce PQ uygular, sonra yeni ayrık vektör üzerinde KNN çalıştırırsınız
      Böylece sözlük uzayını sabit boyuta sıkıştırabilirsiniz
    1. slayttaki tabloda Traditional Databases ile Vector Databases için Indexing & Search Efficiency hücreleri sanki yer değiştirmiş gibi görünüyor
    • Bana da son satır yer değiştirmiş gibi görünüyor

  • SQLite gibi gömülü bir embedding veritabanı önerisi var mı?
    Küçük ölçekli problemler için; ama LMDB + FAISS'ten daha kullanışlı olsa iyi olur