Vektör veritabanları yanlış bir soyutlamadır

 (timescale.com)
11 puan yazan GN⁺ 2024-10-30 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka uygulamaları kurmaya çalışan mühendislik ekiplerini rahatsız eden mesaj: "embedding'ler yeniden senkronize edilmedi"
  • Basit bir vektör arama uygulaması, izleme, senkronizasyon ve sorun gidermeden oluşan karmaşık bir orkestrasyona dönüşür
  • Vektör veritabanlarıyla yapay zeka sistemleri kuran mühendislik ekipleriyle yapılan görüşmeler sonucunda, vektör veritabanlarının yanlış soyutlaması ve bugün kullanılma biçimlerinin kusurları ortaya çıkıyor

"RAG sistemi kurmanın yaygın bir örneği"

  • Pinecone, embedding'leri depolamak ve almak için vektör veritabanı olarak kullanılır
  • Metin verileri Pinecone'un metadata yapısına iyi uymadığı için blob'lar ve uygulama verileri DynamoDB ile işlenir
  • Anahtar sözcük tabanlı arama için OpenSearch gerekir
  • Artık 3 sistemi birbirine bağlamak ve senkronize etmek bir kâbustur

Kaynak belgeler silinirken şunların yapılması gerekir:

  1. DynamoDB'deki kaydı kaldırmak için boto3 çalıştırmak
  2. Embedding'lerin silindiğinden emin olmak için Pinecone'u güncellemek
  3. Anahtar sözcük arama indeksini güncellemek için bir POST isteği göndermek
  • Her kaynak belge güncellemesi, eklemesi veya silmesi için bunların yapılması gerekir
  • Yapılandırma yönetimi sadece dağınık değil, aynı zamanda risklidir
  • Hatta bir ekip, 4 ay önce silinmesi gereken bir indeks için ayda 2.000 dolar ödedi
  • Kullanıcılara yanlış veya eski veri döndürme riski vardır

Vektör veritabanları yanlış bir soyutlama üzerine kuruludur

  • Vektör veritabanları embedding'leri türetilmiş veri yerine bağımsız veri olarak ele alır
  • Embedding'leri bağımsız veri olarak ele almak gereksiz karmaşıklık yaratır

Daha iyi bir yol: "Vectorizer" soyutlaması

  • Embedding'leri bir veritabanı indeksi gibi ele alan "vectorizer" soyutlaması önerilir
  • Bu yaklaşım, embedding'leri kaynak veriyle otomatik olarak senkronize ederek bakım maliyetini ortadan kaldırır
  • CREATE INDEX komutuna karşılık gelen vectorizer şöyle görünür:
SELECT ai.create_vectorizer(
    'public.blogs'::regclass,
    embedding => ai.embedding_openai('text-embedding-3-small', 1536),
    chunking => ai.chunking_recursive_character_text_splitter('content')
);
  • Bu komut, blog tablosundaki tüm girdiler için embedding üretir ve tablodaki veriler değiştikçe embedding'leri güncellemeye devam eder

Vektör veritabanlarının (ve vektör veri tiplerinin) sorunu

  • Vektör veritabanları; metin, görsel ve çok modlu veriler için büyük ölçekli vektör embedding'lerini işlemek amacıyla geliştirildi
  • PostgreSQL, MySQL, MongoDB ve Oracle gibi genel amaçlı veritabanları da vektör arama desteği ekledi
  • Ancak bağımsız sistemler ya da mevcut veritabanlarına eklenen vektör arama özelliklerinin soyutlamasında ölümcül bir kusur vardır
  • Embedding veritabanına eklendiğinde, embedding'i yapılan yapılandırılmamış veri ile vektör embedding'in kendisi arasındaki bağ kopar
  • Bu bağ olmayınca embedding, türetilmiş veri yerine geliştiricinin yönetmesi gereken bağımsız bir veri atomu gibi yanlış ele alınır
  • Embedding'i türetilmiş veri olarak yeniden çerçevelemek, embedding'lerin kaynak veriye bağlı olmadığı mevcut vektör veritabanı soyutlamasının ne kadar saçma olduğunu açıkça gösterir

Geliştirme ekiplerinin yönetmesi gerekenler:

  • Karmaşık ETL (extract-load-transform) hatları

  • Embedding'ler için vektör veritabanı, metadata ve uygulama verileri için başka bir veritabanı, anahtar sözcük arama indeksi

  • Veri senkronizasyon servisleri

  • Güncelleme ve senkronizasyon için kuyruk sistemleri

  • Veri drift'ini yakalayan, embedding servislerindeki rate limit gibi durumları ele alan izleme araçları

  • Arama eski sonuçlar döndürdüğünde çalışan uyarı sistemleri

  • Tüm sistemler için doğrulama kontrolleri

  • Yeni bir embedding modeline geçmek ya da farklı bir chunking yöntemi denemek için özel kod yazmak ve değişiklikleri birden fazla veri servisi ile veritabanında koordine etmek gerekir

  • Bu işler, kaynak veri değiştikçe embedding'lerin zamanında üretildiğinden emin olma yükünü geliştirme ekiplerinin üzerine bırakır

  • Aksi halde embedding'lerin sık sık eski kalması ve kullanıcılara daha kötü bir uygulama deneyimi sunulması riski vardır

Daha iyi bir yol: karmaşıklığı veritabanının üstlenmesi

  • Embedding'leri türetilmiş veri olarak yeniden çerçevelemek, temel veri değiştikçe embedding üretme ve güncelleme sorumluluğunu veritabanı yönetim sistemine bırakmayı mümkün kılar
  • Bu değişiklik, geliştiricileri embedding'leri kaynak veriyle senkronize tutma yükünden kurtarır
  • Bu ayrım, RAG için tek seferlik veri içe aktarma yapan basit uygulamalarda önemli olmayabilir
  • Ancak gerçek dünyadaki çoğu uygulamada veri sürekli değişir
  • Embedding tabanlı anlamsal arama kullanan bir e-ticaret platformunu ya da güncel ürün bilgileriyle sürekli güncel kalması gereken bir ürün asistanı RAG uygulamasını düşünün.
  • Bu değişiklikleri manuel olarak takip etmek ve embedding'leri yeniden üretmek yalnızca emek yoğun ve hataya açık değildir; aynı zamanda geliştiricilerin temel iş hedeflerine odaklanmasını da engeller
  • Veritabanı sistemi bunu otomatik olarak halledebiliyorsa neden geliştirme zamanı boşa harcansın?

Vectorizer: indeks olarak vektör embedding'leri

  • Vektör embedding'lerini bağımsız tablolar veya veri tipleri olarak değil, embedding'i yapılan veriye ait özel bir indeks olarak kavramsallaştırmak daha etkili bir soyutlamadır
  • Vektör embedding'leri geleneksel anlamda bir indeks değildir
  • Bunun yerine, embedding'lere dayanarak verinin en ilgili parçalarını bulan bir indeksleme mekanizması gibi çalışır
  • Bu yeni indeks benzeri soyutlamaya "vectorizer" diyebiliriz

Vectorizer soyutlamasının başlıca faydaları:

Otomatik senkronizasyon

  • Veritabanı indekslemesinin temel faydalarından biri, temel veri ile indeksin otomatik olarak senkronize tutulmasıdır
  • Bir sütundaki veri değiştiğinde indeks buna göre güncellenir
  • Vektör embedding'lerini bir indeksleme biçimi olarak ele alarak aynı otomatik senkronizasyondan yararlanabiliriz
  • Sistem, vektör embedding'lerinin her zaman en güncel veriyle güncel kalmasını sağlar; böylece manuel güncelleme ihtiyacını ortadan kaldırır ve hata riskini azaltır

Güçlendirilmiş veri-embedding ilişkisi

  • Vektörler bağımsız saklandığında, özgün veriyle ilişkilerini kaybetmeleri kolaydır
  • Bu vektör verinin yakın zamandaki güncellemesinden mi üretildi? Yoksa önceki bir embedding modelinden kalan eski bir vektör mü?
  • Bu sorular önemlidir ve burada yaşanacak karışıklık ciddi hatalara yol açabilir
  • Vektör embedding'lerini indeks olarak doğrudan veriye bağlayarak bu ilişkiyi açık ve otomatik olarak korunur hale getirebiliriz

Basitleştirilmiş veri yönetimi

  • Geliştiriciler veri senkronizasyonunu manuel yönettiklerinde sık sık zorluk yaşar
  • Örneğin temel veri silindiğinde, önceki embedding modeline ait veriyi silmeyi unutmak tutarsızlığa yol açabilir
  • Vectorizer soyutlaması, bu ilişkilerin yönetimini sistemin sorumluluğu haline getirerek geliştiricinin bilişsel yükünü azaltır ve hata olasılığını en aza indirir

Vectorizer, DBMS'in temel vaadinin doğal evrimidir

  • Vectorizer kavramı, modern veritabanı yönetim sistemlerinin (DBMS) yeteneklerinin doğal bir evrimidir
  • Günümüz DBMS'leri, indeksler, trigger'lar ve materialized view'lar gibi deklaratif yapılar aracılığıyla veri dönüşümü ve senkronizasyonunu yönetmede zaten oldukça iyidir
  • Vectorizer soyutlaması, vektör embedding yönetiminin giderek daha önemli hale gelen görevini üstlenecek yeni bir araç sunarak bu paradigma ile iyi uyum sağlar
  • Bu yeteneği doğrudan DBMS'e dahil etmek, veritabanı sistemlerinin nihai vaadini gerçekleştirmeye bizi bir adım daha yaklaştırır
  • Veriyi; kullanıcıların uygulama geliştirme, veri analizi ve inovasyonu yönlendirme gibi en iyi yaptıkları işlere odaklanabilmesi için karmaşıklığı soyutlayacak şekilde yönetmek

PostgreSQL için Vectorizer uygulaması: pgai Vectorizer

  • Geliştiricilerin yükünü hafifletme vaadinden hareketle Timescale'in AI mühendisliği ekibi, PostgreSQL için bir vectorizer uyguladı
  • Bunun adı pgai Vectorizer ve şu anda Early Access aşamasında
  • Bu, PostgreSQL'i yapay zeka sistemleri için daha uygun hale getirmeyi ve PostgreSQL'e aşina geliştiriciler için yapay zeka geliştirmeyi kolaylaştırmayı amaçlayan PGAI projesinin bir parçası
  • pgai Vectorizer'ın PostgreSQL'deki veriler için vektör embedding'lerini nasıl otomatik oluşturup güncellediğini görmek için demo videoya göz atın

pgai Vectorizer nasıl çalışır

  • SQL içinde vectorizer tanımlanır ve oluşturulur
  • Aşağıdaki sorgu bir vectorizer oluşturur; çalışacağı tabloyu, vektörleştirilecek sütunları, kullanılacak embedding modelini ve embedding yapılacak kaynak veriye eklenecek diğer bilgilerin ek biçimlendirmesini belirtir
-- blogs tablosundaki verileri otomatik olarak embed eden vectorizer oluştur
SELECT ai.create_vectorizer(
   'public.blogs'::regclass
   -- OpenAI text-embedding-3-small modelini kullan
 , embedding=>ai.embedding_openai('text-embedding-3-small', 1536, api_key_name=>'OPENAI_API_KEY')
   -- Tabloda 100k satır olduğunda StreamingDiskANN indeksini otomatik oluştur
 , indexing => ai.indexing_diskann(min_rows => 100000, storage_layout => 'memory_optimized'),
   -- content sütununa recursive chunking uygula
 , chunking=>ai.chunking_recursive_character_text_splitter('content')
   -- Daha iyi arama için diğer sütunlardaki metadata'yı embedding'e ekle
 , formatting=>ai.formatting_python_template('Blog title: $title url: $url blog chunk: $chunk')
);
-- Vectorizer, kaynak tablo değiştiğinde embedding'leri günceller
-- Başka bir kullanıcı işlemi gerekmez
  • Ayrıca uzun metinlerin embedding modelinin token sınırına sığacak birden çok küçük parçaya bölünmesi gerektiğinden, yerleşik chunking işlevleri tanımlar

Kaynak veri değişikliklerini izleme

  • pgai Vectorizer, içerde kaynak tabloda yapılan değişiklikleri (insert, update, delete) tespit eder ve vektör embedding'lerini asenkron şekilde üretip günceller
  • pgai Vectorizer, self-hosted ve Timescale Cloud üzerinde tam yönetilen olmak üzere iki dağıtım türü için geliştirildi
  • pgai Vectorizer'ın bulut barındırmalı uygulamasında embedding üretimi için Timescale Cloud platformunun bulut yetenekleri kullanılır
  • pgai Vectorizer'ın açık kaynak sürümünde embedding üretmek için harici worker'lar çalıştırılır
  • pgai Vectorizer, yapılandırma ve katalog bilgisini veritabanı içinde, temel iç muhasebe verileriyle birlikte saklar

Embedding'ler fiilen nerede üretilir?

  • Asıl embedding süreci, veritabanı dışındaki harici bir süreçte gerçekleşir
  • Bu, veritabanı sunucusundaki yükü azaltır ve vectorizer'ın, veritabanının uygulama sorgularını işleme yeteneğini etkilememesini sağlar
  • Ayrıca embedding işlerini diğer veritabanı görevlerinden bağımsız olarak ölçeklendirmeyi kolaylaştırır
  • Bu süreç önce veritabanını okuyup yapılacak iş olup olmadığını kontrol eder
  • Varsa veritabanından veriyi okur, chunking ve formatting yapar, OpenAI gibi embedding modeli sağlayıcılarına çağrı göndererek embedding üretir ve sonucu tekrar veritabanına yazar

Süreci özelleştirme

  • pgai Vectorizer esnektir: embedding üretiminde kullanılan chunking ve formatting kurallarını belirleyebilirsiniz
  • Özellikle, vektörleştirilecek kaynak tablonun sütunlarını ve kaynak verinin embedding token sınırına sığmasını, ayrıca ilgili verinin her embedding'e dahil edilmesini sağlayacak chunking ve formatting kurallarını yapılandırabilirsiniz
  • pgai Vectorizer'ın Early Access sürümünde, OpenAI embedding modeli seçimi, metni daha küçük parçalara ayıran chunking stratejileri, her parçaya ek bağlam enjekte eden formatting seçenekleri, otomatik indeks oluşturma ve performans ayarı için özelleştirilebilir indexing yapılandırmaları desteklenir
  • Yakında kullanıcıların kendi Python kodlarını göndererek chunking, embedding ve formatting'i tamamen özelleştirebilmesini sağlayarak bunu daha da esnek hale getirmeyi planlıyorlar

Örneğin aşağıda, HTML kaynak dosyalarını recursive olarak bölen ve kaynak veriden OpenAI embedding'leri oluşturacak şekilde yapılandırılmış bir vectorizer yer alır. Kod, doküman, Markdown ve benzeri uygulama verilerine uygun olacak şekilde chunking ve formatting yapılandırılabilir

-- Gelişmiş vectorizer yapılandırması
SELECT ai.create_vectorizer(
   'public.blogs'::regclass,
   destination => 'blogs_embedding_recursive',
   embedding => ai.embedding_openai('text-embedding-3-small', 1536),
   -- HTML içeriğe belirtilen ayarlarla recursive chunking uygula
   chunking => ai.chunking_recursive_character_text_splitter(
       'content',
       chunk_size => 800,
       chunk_overlap => 400,
       -- En yüksek öncelikten en düşüğe sıralanmış, HTML farkındalıklı ayırıcılar
       separator => array[
           E'

', -- Ana belge bölümlerinden böl
           E'

',    -- div sınırlarında böl
           E'

',
           E'

',      -- Paragraflarda böl
           E'
',      -- Satır sonlarında böl
           E'
',     -- Liste öğelerinde böl
           E'. ',        -- Alternatif olarak cümle sınırları
           ' '          -- Son çare: boşluklardan böl
       ]
   ),
   formatting => ai.formatting_python_template('title: $title url: $url $chunk')
);

GN⁺ görüşü

  • pgai Vectorizer, embedding yönetimini büyük ölçüde basitleştirebilecek güçlü ve yenilikçi bir araç gibi görünüyor. Vectorizer soyutlaması, geliştiricilerin embedding'leri manuel yönetme yükünü azaltıyor ve embedding'lerin kaynak veriyle senkronize kalmasını sağlıyor.
  • Özellikle embedding modeli yükseltmeleri veya chunking stratejisi değişiklikleri gibi güncellemeler uygulanırken çok faydalı görünüyor. Geleneksel vektör veritabanlarında bu tür değişiklikler, birden çok sistemde özel kod yazmayı ve koordinasyon gerektiren karmaşık süreçlere yol açabilirken, pgai Vectorizer'da yalnızca vectorizer yapılandırmasını güncellemek yeterli oluyor.
  • Ayrıca embedding'leri PostgreSQL gibi genel amaçlı bir veritabanında yönetmek, birden fazla uzmanlaşmış sistemi orkestre etme zorunluluğunu ortadan kaldırabilir. Bu da uygulama geliştirmeyi önemli ölçüde basitleştirebilir.
  • Dikkate alınması gereken bir nokta, gerçek embedding üretiminin harici bir Python sürecinde yapılması. Bu, veritabanı performansını etkilememek için iyi bir tasarım tercihi olsa da embedding üretim sürecinin ayrıca izlenmesi ve yönetilmesi gerektiği anlamına geliyor.
  • Sonuç olarak pgai Vectorizer, yapay zeka uygulamaları için embedding yönetiminde önemli bir ilerlemeyi temsil ediyor. Daha fazla ekip bunu benimsedikçe ve geri bildirim verdikçe bu güçlü aracın daha da gelişmesi bekleniyor. Embedding yönetimini Postgres gibi tanıdık araçlara entegre etmek, daha fazla geliştiricinin ileri düzey yapay zeka yeteneklerinden yararlanmasını sağlayacaktır.

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-30
Hacker News görüşü

  • Veri senkronizasyonunun ek yükü abartılıyor ve çoğu embedding tabanlı iş akışında güncelleme ya da silme çok sık olmuyor. Küçük veri kümelerinde bile tutarlılık sorunlarını fark etmek zor. Yine de veri senkronizasyonu konusunda endişelenmeye gerek olmaması hâlâ harika

    • Embedding'leri Postgres veritabanında saklamanın en büyük dezavantajı, iş yüklerinin çok farklı olması. HNSW indeksleri çok fazla kaynak tüketiyor ve kaynak çekişmesi sorunlarına yol açabiliyor. Veritabanını taşıyınca tutarlılık sorunları yeniden ortaya çıkıyor
    • Filtrelemeyle etkileşim konusunda bir soru var. Kısmi indekslerden yararlanılıp yararlanılamayacağı ve pgvector'ın HNSW uygulamasındaki kısıtların hâlâ geçerli olup olmadığı merak ediliyor

  • Bir Elastic çalışanı olarak, Elasticsearch'ün yakın zamanda semantic_text adlı bir veri tipi eklediği belirtiliyor. Bu tip, metni otomatik olarak parçalara ayırıyor, embedding'leri hesaplayıp saklıyor. Sorgular da sadeleştiği için I/O azalıyor ve istemci kodu basitleşiyor

  • PostgreSQL için bir araç tanıtılıyor; bu araç vektör embedding'lerini veritabanı indeksi olarak yeniden kurguluyor. Şu anda yalnızca OpenAI destekleniyor ancak yakında yerel ve OSS model desteği planlanıyor. Geri bildirim ve tepkiler bekleniyor

  • FAISS'in tek bir veritabanı olarak kullanılmasına dair soru işareti dile getiriliyor. Bunun vektör embedding'leri için sqlite gibi olduğu, metadata ile vektörleri birlikte saklayarak ilişkileri koruyabildiği söyleniyor

  • Postgres'te vektör kullanımına olumlu bakılıyor; SQL sorgularında vektör arama ile mantığın birlikte kullanılması durumunda filtreleme sırası sorgulanıyor. pg_vector'ın DX'i beğeniliyor ancak vektör aramadan sonra filtreleme yapmak hızı düşürebiliyor

  • Ham embedding'leri bir vektör veritabanında saklamanın, metnin ham n-gram'larını veritabanında saklamak gibi olduğu belirtiliyor. Belgenin kendisini saklamak daha mantıklı

  • SQLite'ta sqlite-vec ve FTS5 kullanıldığı ve bunun çok faydalı olduğu belirtiliyor

  • Node.js'te PostgreSQL ORM'i geliştirilerek vektör alanları içeren kod yazılabildiği belirtiliyor. Bu sayede veri veya embedding içeriği sorgulanabiliyor ve modelin hangi alanlarının embedding olarak saklanacağı tanımlanabiliyor

  • Materialized Views'in iyi olduğu belirtiliyor

  • Karakter tabanlı chunk kullanan yapay zeka uygulamalarının PoC aşamasını aşamadığı belirtiliyor