RAG hesaplayıcı: belge vektörleştirme ne kadar tutar

Chunk nedir ve belgeler neden parçalara ayrılır

Belgeler üzerinde bir AI asistanı oluşturduğunuzda, model tüm arşivi tek seferde "okuyamaz". Bu nedenle her belge önce chunk adı verilen daha küçük birimlere ayrılır. Chunk genellikle birkaç paragraf, bir bölüm veya tek başına anlam ifade eden bir sayfa parçasıdır.

Mantık basittir: kullanıcı bir soru sorduğunda sistem tüm belgeyi taramaz, yalnızca en benzer chunkları arar ve yalnızca bunları AI modeline bağlam olarak gönderir. Daha küçük chunklar daha hassas arama anlamına gelir, ancak hesaplanması ve saklanması gereken daha fazla vektör de demektir. Daha büyük chunklar vektör sayısını azaltır, ancak bilgiyi "seyreltebilir", böylece model yarım sayfa metin alır ve bunun içinde yalnızca bir cümle ilgili olur.

İyi bir RAG hesaplayıcısı bu nedenle üç girdi alır: belge sayısı, ortalama chunk boyutu ve embedding modelinin fiyatı. Bundan toplam chunk sayısını, vektörleştirme maliyetini ve bu vektörlerin veritabanında kapladığı alanı hesaplar. Bu öncelikle planlama için faydalıdır, çünkü birçok kişi birkaç bin belgeden kaç chunk oluştuğunu hafife alır.

Chunk sayısı ve embedding maliyeti nasıl hesaplanır

Uygulamada süreç şöyledir:

1. Korpusdaki toplam token sayısını tahmin edin. Kaba bir kılavuz: bir sayfa metin yaklaşık 500 ila 700 kelime içerir, bu da yaklaşık 700 ila 1000 tokena karşılık gelir.
2. Chunk boyutunu seçin, örneğin 500 token.
3. Örtüşme ekleyin, örneğin yüzde 15, böylece etkin adım boyutu yaklaşık 425 token olur.
4. Chunk sayısını elde etmek için toplam token sayısını adım boyutuna bölün.
5. Chunk sayısını embedding modelinin token başına fiyatıyla çarpın.

Somut bir örnek: her biri 20 sayfa olan 200 belge yaklaşık 4 milyon token verir. 500 tokenlık chunk ve yüzde 15 örtüşme ile yaklaşık 9400 chunk elde edilir. Model vektörleştirmeyi token başına ücretlendiriyorsa, maliyet chunk sayısı üzerinden değil bu 4 milyon token üzerinden hesaplanır, çünkü örtüşme metnin bir kısmının iki kez işlenmesi anlamına gelir.

Vektör veritabanındaki alan, vektör boyutuna ve veri tipine bağlıdır. 4 baytlık kayıtta 1536 boyutlu bir vektör yaklaşık 6 KB kaplar, bu nedenle 9400 chunk yalnızca vektörler için yaklaşık 56 MB gerektirir, buna metadatalar ve indeksler de eklenir.

Hangi örtüşme ve chunk boyutu seçilmeli

Örtüşme, iki chunk arasındaki sınırda anlamın kaybolmaması için vardır. Bir cümle ortadan kesilirse, yalnızca ikinci kısmı alan model neyden bahsedildiğini anlamayabilir. Bu nedenle metnin son yüzde 10 ila 20'si bir sonraki chunkın başında tekrarlanır.

Pratik ipuçları:

• Genel dokümantasyon ve bloglar için 400 ila 600 token ile ve yüzde 10 ila 15 örtüşme ile başlayın.
• Teknik kılavuzlar ve sık kullanılan listeler için daha küçük chunklar kullanın, çünkü kullanıcılar belirli bir adımı arar.
• Sözleşmeler ve yasal düzenlemeler için token sayısına göre değil yapıya göre bölün, örneğin madde ve fıkra bazında. Tüm maddeyi içeren bir chunk, rastgele bir yerdeki kesitten çok daha fazla anlam taşır.
• Her zaman metadataları saklayın: belge adı, sayfa numarası ve bölüm başlığı. Bunlar olmadan AI asistanının yanıtının kullanıcının doğrulayabileceği bir kaynağı olmaz.

Uzman ipucu: chunk boyutunu bir kez ve sonsuza kadar seçmezsiniz. 20 ila 30 gerçek soruyla küçük bir test yapın ve sistemin doğru chunkı bulup bulmadığını karşılaştırın. Sık sık ıskalıyorsa sorun genellikle modelde değil metin bölmededir.

Vektörleştirme planlamasında en sık yapılan hatalar

İlk hata, maliyeti token yerine belge başına hesaplamaktır. Embedding fiyatı metin miktarına bağlıdır, dosya sayısına değil, bu nedenle taranmış görüntüler içeren bir PDF ile temiz metin içeren bir PDF aynı maliyete sahip değildir.

İkinci hata, yeniden vektörleştirmeyi göz ardı etmektir. Embedding modelini veya bölme yöntemini değiştirdiğinizde her şeyin yeniden işlenmesi gerekir. Bu nedenle önceden sürümleme ve eski vektörleri çalışmayı kesintiye uğratmadan yenileriyle değiştirme olanağını planlayın.

Üçüncü hata, yalnızca vektörleştirme fiyatına odaklanmaktır. Bu genellikle toplam işin küçük bir parçasıdır, en fazla zaman ise belgeleri temizlemeye, üstbilgileri ve dipnotları kaldırmaya ve arama kalitesini doğrulamaya gider.

Korpus on binlerce belgeye çıkarsa veya sık değişen birden fazla kaynağınız varsa, işleme ve güncelleme pipeline'ını planlamak hesaplamanın kendisinden daha zorlu hale gelir. Bu durumlarda EVI Solutions RAG sistemi mimarisi ve veri hazırlama otomasyonu konusunda yardımcı olabilir.