Upserting Data
AIFINEX Flow ile Vector Stores'a nasıl veri ekleyeceğinizi öğrenin
AIFINEX Flow kullanarak verilerinizi bir Vector Store'a aktarmanın iki temel yolu vardır: API call'u yoluyla ya da bu amaç için hazırladığımız özel düğümleri kullanarak.
Bu kılavuzda, verilerinizi bir Vector Store'a aktarmadan önce Document Stores kullanarak hazırlamanız şiddetle tavsiye edilse de, bu amaç için gerekli olan özel düğümleri kullanarak tüm süreci gözden geçirecek, adımları, bu yaklaşımın avantajlarını ve verimli veri işleme için optimizasyon stratejilerini özetleyeceğiz.
Ekleme sürecinin anlaşılması
Anlamamız gereken ilk şey, bir Vector Store'a veri ekleme işleminin bir Retrieval Augmented Generation (RAG) sisteminin oluşumu için temel bir parça olduğudur. Ancak, bu işlem tamamlandıktan sonra, RAG bağımsız olarak yürütülebilir.
Başka bir deyişle, Flow'da tam bir RAG kurulumu olmadan veri ekleyebilir ve RAG'nizi ekleme işleminde kullanılan belirli düğümler olmadan çalıştırabilirsiniz, yani RAG'nin çalışması için iyi doldurulmuş bir vektör deposu çok önemli olsa da, gerçek alma ve oluşturma işlemleri sürekli ekleme gerektirmez.
Kurulum
Diyelim ki Upstash Vector Store'umuza eklememiz gereken PDF formatında uzun bir veri kümemiz var, böylece bir LLM'ye bu belgeden belirli bilgileri alması talimatını verebiliriz.
Bunu yapmak ve bu öğreticiyi göstermek için, 5 farklı düğüm içeren bir upstash akışı oluşturmamız gerekir:
1. Document Loader
İlk adım, PDF verilerimizi bir Document Loader düğümü kullanarak Flow örneğine yüklemektir. Document Loaders, PDF'ler, TXT, CSV, Notion sayfaları ve daha fazlası dahil olmak üzere çeşitli belge biçimlerinin alımını gerçekleştiren özel düğümlerdir.
Her Document Loader'ın, veri kümemize istediğimiz zaman metadata eklememizi ve çıkarmamızı sağlayan iki önemli ek parametre ile birlikte geldiğini belirtmek önemlidir.
2. Text Splitter
PDF'imizi veya veri setimizi yükledikten sonra, onu daha küçük parçalara, belgelere veya yığınlara ayırmamız gerekir. Bu, 2 ana nedenden dolayı çok önemli bir ön işleme adımıdır:
Erişim hızı ve alaka düzeyi: Büyük belgeleri bir vektör veritabanında tek bir varlık olarak depolamak ve sorgulamak, daha yavaş erişim sürelerine ve potansiyel olarak daha az alakalı sonuçlara yol açabilir. Belgeyi daha küçük parçalara bölmek daha hedefli erişim sağlar. Daha küçük, daha odaklanmış bilgi birimlerine karşı sorgulama yaparak daha hızlı yanıt süreleri elde edebilir ve alınan sonuçların hassasiyetini artırabiliriz.
Uygun maliyetli: Belgenin tamamı yerine yalnızca ilgili parçaları aldığımız için, LLM tarafından işlenen belirteçlerin sayısı önemli ölçüde azalır. Faturalandırma genellikle token tüketimine dayandığından, bu hedefli erişim yaklaşımı doğrudan LLM'miz için daha düşük kullanım maliyetleri anlamına gelir. LLM'ye gönderilen alakasız bilgi miktarını en aza indirerek maliyeti de optimize ediyoruz.
Node
Flow'da bu bölme işlemi Text Splitter düğümleri kullanılarak gerçekleştirilir. Bu düğümler, aşağıdakiler de dahil olmak üzere bir dizi metin bölümleme stratejisi sağlar:
Character Text Splitting: Metni sabit sayıda karakterden oluşan parçalara bölme. Bu yöntem basittir ancak kelimeleri veya cümleleri parçalara bölerek bağlamı bozabilir.
Token Text Splitting: Metnin kelime sınırlarına veya seçilen gömme modeline özgü tokenizasyon şemalarına göre bölümlere ayrılması. Bu yaklaşım, kelime sınırlarını koruduğu ve metnin altında yatan dilsel yapıyı dikkate aldığı için genellikle anlamsal olarak daha tutarlı parçalara yol açar.
Recursive Character Text Splitting: Bu strateji, metni belirli bir boyut sınırı içinde kalırken anlamsal tutarlılığı koruyan parçalara bölmeyi amaçlar. Özellikle iç içe geçmiş bölümler veya başlıklar içeren hiyerarşik belgeler için çok uygundur. Karakter sınırında körü körüne bölmek yerine, cümle sonları veya bölüm sonları gibi mantıksal kırılma noktalarını bulmak için metni özyinelemeli olarak analiz eder. Bu yaklaşım, hedef boyutu biraz aşsa bile her yığının anlamlı bir bilgi birimini temsil etmesini sağlar.
Markdown Text Splitter: Markdown biçimli belgeler için özel olarak tasarlanan bu ayırıcı, metni markdown başlıklarına ve yapısal öğelere göre mantıksal olarak böler ve belge içindeki mantıksal bölümlere karşılık gelen parçalar oluşturur.
Code Text Splitter: Kod dosyalarını bölmek için özel olarak tasarlanan bu strateji, kod arama ve dokümantasyon gibi görevlere uygun anlamlı parçalar oluşturmak için kod yapısını, işlev tanımlarını ve programlama diline özgü diğer öğeleri dikkate alır.
HTML-to-Markdown Text Splitter: Bu özel ayırıcı önce HTML içeriğini Markdown'a dönüştürür ve ardından Markdown Metin Ayırıcıyı uygulayarak web sayfalarının ve diğer HTML belgelerinin yapılandırılmış bölümlere ayrılmasını sağlar.
Text Splitter düğümleri, metin segmentasyonu üzerinde granüler kontrol sağlayarak aşağıdaki gibi parametrelerin özelleştirilmesine olanak tanır:
Chunk Size: Her bir yığının istenen maksimum boyutu, genellikle karakter veya jeton olarak tanımlanır.
Chunk Overlap: Ardışık parçalar arasında üst üste binecek karakter veya belirteç sayısı, parçalar arasında bağlamsal akışı korumak için kullanışlıdır.
Chunk Overlap Anlama
Vektör tabanlı erişim ve LLM sorgulaması bağlamında, yığın örtüşmesi, özellikle sınırlı erişim derinliği veya bir sorguya yanıt olarak Vector Store'dan alınan en benzer yığınların maksimum sayısını belirleyen parametre olan top K ile uğraşırken, bağlamsal sürekliliğin korunmasında ve yanıt doğruluğunun iyileştirilmesinde önemli bir rol oynar.
Sorgu işleme sırasında LLM, verilen sorguyla anlamsal olarak en ilgili parçaları almak için Vector Store'a karşı bir benzerlik araması yürütür. Top K parametresiyle temsil edilen alma derinliği küçük bir değere, varsayılan olarak 4'e ayarlanırsa, LLM yanıtını oluşturmak için başlangıçta yalnızca bu 4 parçadan gelen bilgileri kullanır.
Bu senaryo bize bir sorun teşkil eder, çünkü örtüşme olmadan yalnızca sınırlı sayıda parçaya güvenmek, özellikle birden fazla parçaya yayılan bilgi gerektiren sorgularla uğraşırken eksik veya yanlış yanıtlara yol açabilir.
Yığın örtüşmesi, metinsel bağlamın bir kısmının ardışık yığınlar arasında paylaşılmasını sağlayarak bu soruna yardımcı olur ve belirli bir sorgu için ilgili tüm bilgilerin alınan yığınlar içinde yer alma olasılığını artırır.
Başka bir deyişle, bu örtüşme, parçalar arasında bir köprü görevi görerek, LLM'nin küçük bir alınan parçalar kümesiyle sınırlı olsa bile daha geniş bir bağlamsal pencereye erişmesini sağlar (Top K). Bir sorgu, tek bir yığının ötesine uzanan bir kavram veya bilgi parçasıyla ilgiliyse, örtüşen bölgeler gerekli tüm bağlamı yakalama olasılığını artırır.
Bu nedenle, metin bölme aşaması sırasında yığın çakışmasını ekleyerek, LLM'nin yeteneğini geliştiriyoruz:
Bağlamsal sürekliliği korumak (preserve contextual continuity): Üst üste binen parçalar, ardışık segmentler arasında daha yumuşak bir bilgi geçişi sağlayarak modelin metni daha tutarlı bir şekilde anlamasına olanak tanır.
Geri getirme doğruluğunu artırma (Improve retrieval accuracy): Üst üste binme, hedeflenen Top K geri getirilen parçalar içindeki tüm ilgili bilgileri yakalama olasılığını artırarak, daha doğru ve bağlamsal olarak uygun yanıtlara katkıda bulunur.
Accuracy vs. Cost
Bu nedenle, erişim doğruluğu ve maliyet arasındaki dengeyi daha da optimize etmek için iki temel strateji kullanılabilir:
Yığın Örtüşmesini Artırmak/Azaltmak (Increase/Decrease Chunk Overlap): Metin bölme sırasında örtüşme yüzdesini ayarlamak, parçalar arasındaki paylaşılan bağlam miktarı üzerinde ince taneli kontrol sağlar. Daha yüksek örtüşme yüzdeleri genellikle daha iyi bağlam korumasına yol açar, ancak tüm belgeyi kapsamak için daha fazla parça kullanmanız gerekeceğinden maliyetleri de artırabilir. Tersine, daha düşük örtüşme yüzdeleri maliyetleri azaltabilir, ancak parçalar arasındaki temel bağlamsal bilgileri kaybetme riski taşır ve potansiyel olarak LLM'den daha az doğru veya eksik yanıtlara yol açar.
Top K değerini artırma/azaltma(Increase/Decrease Top K): Varsayılan top K değerini (4) artırmak, yanıt üretimi için dikkate alınan parçaların sayısını artırır. Bu doğruluğu artırabilirken, maliyeti de artırır.
3. Embedding
Şimdi veri setimizi yükledik ve verilerimizin Vector Store'umuza eklenmeden önce nasıl bölüneceğini yapılandırdık. Bu noktada, embedding düğümleri devreye girerek tüm bu parçaları bir LLM'nin kolayca anlayabileceği bir “dile” dönüştürür.
Bu mevcut bağlamda embedding, metni anlamını yakalayan sayısal bir temsile dönüştürme işlemidir. Embedding vektörü olarak da adlandırılan bu sayısal temsil, her bir boyutun metnin anlamının belirli bir yönünü temsil ettiği çok boyutlu bir sayı dizisidir.
Bu vektörler, LLM'lerin bu çok boyutlu uzayda aralarındaki mesafeyi veya benzerliği ölçerek vector store içindeki benzer metin parçalarını karşılaştırmasına ve aramasına olanak tanır.
Embeddings/Vector Store Dimensions'ı Anlama
Bir Vector Store dizinindeki boyut sayısı, verilerimizi yukarı eklediğimizde kullanılan embedding modeli tarafından belirlenir ve bunun tersi de geçerlidir. Her boyut, veri içindeki belirli bir özelliği veya kavramı temsil eder. Örneğin, bir boyut belirli bir konuyu, duyguyu veya metnin başka bir yönünü temsil edebilir.
Verilerimizi yerleştirmek için ne kadar çok boyut kullanırsak, metnimizden nüanslı anlam yakalama potansiyelimiz de o kadar artar. Ancak bu artışın bedeli sorgu başına daha yüksek hesaplama gereksinimleridir.
Genel olarak, daha fazla sayıda boyut, ortaya çıkan gömme vektörlerini depolamak, işlemek ve karşılaştırmak için daha fazla kaynağa ihtiyaç duyar. Bu nedenle, 768 boyut kullanan Google embedding-001 gibi gömme modelleri, teoride, 3072 boyuta sahip OpenAI text-embedding-3-large gibi diğerlerinden daha ucuzdur.
Boyutlar ve anlam yakalama arasındaki ilişkinin kesinlikle doğrusal olmadığına dikkat etmek önemlidir; daha fazla boyut eklemenin eklenen gereksiz maliyet için ihmal edilebilir fayda sağladığı bir azalan getiri noktası vardır.
4. Vector Store
Vector Store düğümü ekleme akışımızın son düğümüdür. AIFINEX Flow örneğimiz ile vektör veritabanımız arasında köprü görevi görerek, oluşturulan katıştırmaları, ilişkili meta verilerle birlikte, kalıcı depolama ve daha sonra geri alma için hedef Vector Store dizinimize göndermemizi sağlar.
Bu düğümde, daha önce de söylediğimiz gibi, bir sorguya yanıt olarak Vector Store'dan alınan en benzer parçaların maksimum sayısını belirleyen parametre olan “top K” gibi parametreleri ayarlayabileceğimiz yerdir.
5. Record Manager
Record Manager düğümü, upsert akışımıza isteğe bağlı ancak inanılmaz derecede faydalı bir eklentidir. Vector Store'umuza upsert edilen tüm parçaların kayıtlarını tutmamızı sağlayarak gerektiğinde verimli bir şekilde parça eklememize veya silmemize olanak tanır.
Daha ayrıntılı bir kılavuz için sizi şu kılavuza yönlendiriyoruz
6. Tam Genel Bakış
Son olarak, ilk belge yüklemesinden son vektör temsiline kadar her aşamayı inceleyelim ve anahtar bileşenleri ve bunların ekleme sürecindeki rollerini vurgulayalım.
Document Ingestion(Belge Alımı):
Veri formatınız için uygun Document Loader düğümünü kullanarak ham verilerimizi Flow'u besleyerek başlıyoruz.
Strategic Splitting(Stratejik Bölünme):
Ardından, Text Splitter düğümü belgemizi daha küçük, daha yönetilebilir parçalara böler. Bu, verimli erişim ve maliyet kontrolü için çok önemlidir.
Uygun metin bölücü düğümünü seçerek ve daha da önemlisi, bağlam korumayı verimlilikle dengelemek için yığın boyutunu ve yığın örtüşmesini ince ayarlayarak bu bölmenin nasıl gerçekleşeceği konusunda esnekliğe sahibiz.
Meaningful Embeddings(Anlamlı Yerleştirmeler):
Şimdi, verilerimiz Vector Store'a kaydedilmeden hemen önce, Embedding düğümü devreye giriyor. Her bir metin parçasını ve anlamını LLM'mizin anlayabileceği sayısal bir temsile dönüştürür.
Vector Store Index(Vektör Mağazası İndeksi):
Son olarak, Vector Store düğümü Flow ile veritabanımız arasında köprü görevi görür. Gömülerimizi, ilişkili metadatalarla birlikte, belirlenen Vector Store dizinine gönderir.
Burada, bu düğümde, bir sorguyu yanıtlarken kaç parçanın dikkate alınacağını etkileyen Top K parametresini ayarlayarak geri alma davranışını kontrol edebiliriz.
Data Ready(Veriye Hazır):
Eklendikten sonra, verilerimiz artık Vector Store'da vektörler olarak temsil edilir ve benzerlik araması ve geri alma için hazırdır.
Record Keeping (Optional)(Kayıt Tutma (İsteğe Bağlı)):
Gelişmiş kontrol ve yönetim verileri için Record Manager düğümü, eklenen tüm parçaların kaydını tutar. Bu, verileriniz veya ihtiyaçlarınız geliştikçe kolay güncelleme veya kaldırma işlemlerini kolaylaştırır.
Özünde, üst veri ekleme işlemi ham verilerimizi hızlı ve uygun maliyetli erişim için optimize edilmiş LLM'ye hazır bir formata dönüştürür.
Last updated