Chunking Nedir? RAG İçin Belgeleri Doğru Parçalara Bölmek

Chunking nedir?

Chunking, uzun bir belgeyi yapay zekanın gömme ve arama adımlarında kullanabileceği, kendi içinde anlamlı küçük parçalara (chunk) bölme işlemidir. Her parça ayrı indekslenir. Kullanıcı soru sorduğunda yalnızca en alakalı parçalar modele gider, yani model tüm arşivi okumak zorunda kalmaz.

Terim İngilizce "chunk" yani "yığın, dilim" sözcüğünden gelir. Türkçede çoğu ekip "parçalama" ya da "belge bölme" der, ama sektörde chunking kelimesi yaygın kaldı. Biz de yazıda bu adı kullanacağız.

Kavramın temelinde basit bir sezgi yatar: bilgiyi, soru gelince bulunabilecek büyüklükte paketlere ayırmak. Paketler çok büyükse aradığınızı bulmak zorlaşır, çok küçükse paketin içinde anlam kalmaz. Yazının tamamı bu dengeyle ilgilidir.

Chunking tek başına bir ürün değildir. Bir bilgi erişim hattının (RAG) ilk ve en çok ihmal edilen adımıdır. Kötü bölünmüş bir belgeyi hiçbir model kurtaramaz.

Peki chunking nedir sorusunun işletme tarafındaki karşılığı ne? Basitçe, şirket belgelerinizin yapay zeka tarafından ne kadar iyi bulunacağıdır. Aynı model, aynı arşiv ve aynı soru olsa bile bölme kuralı değişince cevap kalitesi değişir.

Bu yüzden chunking nedir diye sorarken aslında şunu soruyorsunuz: arşivimi aramaya hazır hale nasıl getiririm? Yazının geri kalanında bu soruyu adım adım yanıtlıyoruz.

Chunking nedir sorusunu bir benzetmeyle nasıl anlarız?

Kalın bir ansiklopedi düşünün. Soru sorduğunuzda tüm ciltleri masaya yığmazsınız. Dizin sayfasına bakar, ilgili maddeyi bulur ve yalnızca o sayfaları okursunuz.

Chunking, bu ansiklopedinin maddelerini sizin yerinize oluşturur. Madde çok kısaysa bağlam kopar. Madde çok uzunsa aradığınız cümle kalabalığın içinde kaybolur.

İyi bir ansiklopedi editörü gibi düşünün. Konuyu bölmeden önce başlıkları, paragrafları ve tabloları gözden geçirir. Hiçbir maddeyi cümlenin ortasında kesmez.

Yapay zeka sisteminde bu editör rolünü bir bölme kuralı üstlenir. Kuralı siz seçersiniz. Seçtiğiniz kural, aramanın isabetini doğrudan belirler.

Örneğin iki ekip aynı belge setiyle çalışsın. Birinci ekip sayfa sonlarında kesiyor, ikinci ekip başlıklara göre bölüyor. İkinci ekibin sistemi, yalnızca bu farktan dolayı daha tutarlı cevap verebilir.

Belgeler neden parçalara bölünür?

İki pratik neden var. Birincisi, gömme (embedding) modelleri her girdiyi tek bir sayı dizisine, yani vektöre çevirir. Çok uzun bir metni tek vektöre sıkıştırırsanız konu ayrıntıları birbirine karışır. Gömme kavramını embedding yazımızda ayrıca anlattık.

İkincisi, dil modellerinin bağlam sınırı vardır. Modele aynı anda verebileceğiniz metin sınırlıdır. Sınır genişlese bile her şeyi içeri doldurmak maliyeti ve gürültüyü artırır. Sınırın ne olduğunu bağlam penceresi yazımızda ele aldık.

Üçüncü bir neden de arama isabetidir. Kullanıcı sorusu genellikle belgenin yalnızca bir paragrafıyla ilgilidir. Küçük ve odaklı parçalar sayesinde arama motoru tam o paragrafı bulur.

Ayrıca modelin okuduğu metin azaldıkça yanıtın dayandığı kaynak da netleşir. Araştırmalar, uzun girdilerde modelin ortadaki bilgiyi daha zayıf kullanabildiğini gösteriyor. Bu bulguyu Lost in the Middle makalesinde okuyabilirsiniz.

Örnek senaryo: Bir mobilya firmasının kargo, iade ve montaj kuralları tek bir uzun belgede duruyor. Müşteri yalnızca montaj ücretini soruyor. Belge tek parça olarak verilirse model üç konuyu birden okur ve yanlış kuralı karıştırabilir. Üç ayrı parça olursa yalnızca montaj bölümü gelir.

RAG hattında chunking tam olarak nerede durur?

RAG, yani alma destekli üretim, belgeleri bulup modele kanıt olarak verir. Yöntemi ilk tanıtan makale Lewis ve arkadaşlarının çalışmasıdır. Hattın akışı kabaca şöyledir.

1. Belgeleri toplarsınız ve metne çevirirsiniz.
2. Metni parçalara bölersiniz. İşte chunking burada devreye girer.
3. Her parçayı gömme modeliyle vektöre çevirip bir vektör veri tabanına yazarsınız.
4. Kullanıcı soru sorunca soruyu da vektöre çevirir ve en yakın parçaları getirirsiniz.
5. Gerekirse bir yeniden sıralayıcıyla sonuçları süzersiniz.
6. Seçilen parçaları modele verip yanıt ürettirirsiniz.

Gördüğünüz gibi chunking, aramanın girdisini belirler. Sonraki tüm adımlar bu parçalarla çalışır. Parça kötüyse arama da, yanıt da kötü olur.

Bir ayrıntıyı atlamayın: parçalama işlemi çoğu zaman bir kez yapılır, ama sonuçlarıyla her soruda yaşarsınız. Kuralı sonradan değiştirirseniz tüm arşivi yeniden gömmeniz gerekir.

Bu yüzden başta biraz zaman ayırmak, ileride büyük bir yeniden işleme yükünden sizi kurtarır.

Ayrıca hattın her adımının kendi sorumluluğu vardır. Chunking bilgiyi aramaya uygun hale getirir, gömme anlamı sayıya çevirir, arama yakın olanı bulur. Birinde hata varsa diğerleri bunu telafi edemez.

Sabit uzunluklu chunking nasıl çalışır?

Sabit uzunluklu yöntem en basit olanıdır. Metni belirli bir uzunluğa gelince keser ve yeni parçaya geçersiniz. Uzunluğu karakter ya da token cinsinden ölçebilirsiniz. Tokenin ne olduğunu token yazımızda bulabilirsiniz.

Avantajı hızdır ve öngörülebilirliktir. Her parça yaklaşık aynı boyutta olur. Bu yüzden maliyeti ve depolamayı önceden tahmin edersiniz.

Riski ise anlamı hiçe saymasıdır. Kesme noktası bir cümlenin ortasına, hatta bir tablo satırının ortasına denk gelebilir. Böyle bir parça tek başına okunduğunda eksik kalır.

Örnek senaryo: İade koşullarını anlatan bir paragraf iki parçaya bölünmüş olsun. Birinci parça "iade yapabilirsiniz" der, ikinci parça "yalnızca açılmamış ürünlerde" koşulunu taşır. Arama yalnızca birincisini getirirse model yanlış bir güven verir.

Bu nedenle sabit uzunluk, hızlı bir başlangıç noktasıdır. Ancak ciddi bir arşiv için çoğu zaman tek başına yetmez.

Bir ipucu verelim. Sabit uzunlukla keserken sınırı yakındaki bir cümle sonuna kaydırın. Böylece cümleyi ortadan bölmezsiniz. Birçok çerçevedeki "özyinelemeli" bölücüler tam bunu yapar: önce paragraf, sonra cümle, en son kelime sınırını dener.

Örtüşmeli (overlap) chunking ne işe yarar?

Örtüşme, ardışık iki parçanın sınırında ortak bir metin payı bırakmaktır. İkinci parça, birincinin son birkaç cümlesiyle başlar. Böylece kesme noktasındaki bilgi iki parçada da yer alır.

Örtüşmenin amacı bağlamın kopmasını azaltmaktır. Önceki örnekte "yalnızca açılmamış ürünlerde" koşulu iki parçada da bulunur. Arama hangisini getirirse getirsin cevap tam kalır.

Ancak örtüşmenin bir bedeli var. Aynı metin birden fazla kez indekslenir. Bu da depolamayı ve arama sonuçlarındaki tekrarı artırır.

Kaç birim örtüşme gerektiği belgeye bağlıdır.

Rakamı sağlayıcı belgelerindeki varsayılanlardan almayın. Kendi belgelerinizle deneyin. Örneğin OpenAI dosya arama belgeleri, parça boyutu ve örtüşmeyi ayarlanabilir seçenekler olarak sunar. Güncel varsayılanları resmi belgeden kontrol edin.

Başlık ve bölüm bazlı chunking ne zaman daha iyidir?

Başlık bazlı yöntem belgenin kendi yapısını izler. Bir bölüm başlığından diğerine kadar olan metin tek parça olur. Bölüm çok uzunsa alt başlıklara ya da paragraflara inersiniz.

Bu yöntem yapılı belgelerde parlar. Kullanım kılavuzları, politika metinleri, sözleşmeler ve yardım merkezi yazıları buna örnektir. Çünkü yazar zaten konuyu başlıklarla bölmüştür.

LangChain ve LlamaIndex bu işi hazır bileşenlerle yapar. Biçime duyarlı ayırıcılar Markdown başlıklarını ya da HTML etiketlerini sınır olarak kullanır. Seçenekleri LangChain bölücü belgelerinde görebilirsiniz.

Zayıf yanı, başlıksız ya da düzensiz belgelerde işe yaramamasıdır. Bir de bölüm boyutları çok farklıysa bazı parçalar fazla büyür, bazıları fazla küçük kalır. Bu durumda başlık bazlı yöntemi uzunluk sınırıyla birleştirmek en sağlıklısıdır.

Örneğin bir yardım merkezi yazısında "Kargo" başlığı altında üç paragraf varsa hepsi tek parça olur. Aynı başlığın altında on paragraf varsa bölümü paragraf sınırlarında iki ya da üç parçaya ayırırsınız. Her ikisinde de başlığı parçanın başına yazmayı unutmayın.

Anlamsal chunking nedir ve ne zaman değer?

Anlamsal chunking, sınırları uzunluğa göre değil anlama göre seçer. Ardışık cümlelerin gömmelerini karşılaştırırsınız. Konu belirgin biçimde değiştiğinde yeni bir parça başlatırsınız.

Güzel yanı, parçaların tek bir konuya odaklanmasıdır. Yapısı zayıf, düz akan metinlerde, örneğin toplantı dökümlerinde ya da uzun e-postalarda fark yaratabilir.

Bedeli ise ek işlemdir. Her cümle için gömme hesaplamanız gerekir. Bu hem süreyi hem maliyeti artırır. Ayrıca eşik değerini ayarlamanız gerekir ve bu ayar belgeden belgeye değişir.

Biz bu yöntemi ilk tercih yapmıyoruz. Önce başlık bazlı ve örtüşmeli bir temel kurarız. Ardından ölçüm, anlamsal bölmenin fark yarattığını gösterirse ona geçeriz.

LlamaIndex belgeleri de çeşitli ayrıştırıcıları aynı soyutlama altında sunar. Ayrıntı için düğüm ayrıştırıcı sayfasına bakabilirsiniz.

Üst-alt (hiyerarşik) chunking nedir ve neden işe yarar?

Aramada küçük parça isabetlidir, çünkü tek konuya odaklanır. Cevap üretirken ise büyük parça işe yarar, çünkü çevresindeki bağlamı taşır. Hiyerarşik yöntem ikisini birleştirir.

Önce belgeyi büyük ebeveyn bölümlere, sonra her bölümü küçük çocuk parçalara ayırırsınız. Aramayı çocuk parçalarda yaparsınız. Eşleşme bulunca modele çocuğun bağlı olduğu ebeveyn bölümü verirsiniz.

Böylece hem isabet hem bağlam kazanırsınız.

LlamaIndex gibi çerçeveler bu desen için hazır ayrıştırıcılar sunar.

Riskleri de bilin. Ebeveyn bölüm çok büyükse gürültü geri gelir. Birden fazla çocuk aynı ebeveyni getirirse modele aynı metin tekrar tekrar gider. Ayrıca çocuk ile ebeveyn arasındaki ilişkiyi depolamanız gerekir.

Biz bu yöntemi genellikle uzun kılavuzlarda ve sözleşmelerde öneriyoruz. Kısa SSS maddelerinde ise gereksiz karmaşıklık yaratır.

Parça boyutu nasıl seçilir?

Parça boyutu, chunking'in en sık tartışılan ayarıdır. Doğru bir sihirli sayı yoktur. Bu yüzden bu yazıda rakam vermiyoruz ve bunu bilerek yapıyoruz.

Dengeyi şöyle düşünün. Çok küçük parça bağlamı koparır. Cümle tek başına anlamsız kalır ve arama isabeti düşer. Çok büyük parça ise gürültü katar. İçinde alakasız bilgi taşır ve modelin dikkatini dağıtır.

Doğru boyut üç şeye bağlıdır.

• Belgenin türü: Kısa SSS maddeleriyle uzun sözleşmeler aynı boyuta uymaz.
• Soruların türü: Kısa olgu soruları küçük parça ister, açıklama isteyen sorular daha büyük parça.
• Gömme modelinin sınırı: Modelin kabul ettiği girdi uzunluğunu sağlayıcının belgesinden kontrol edin.

Pratik yol, birkaç farklı boyutu aynı soru setiyle denemektir. Hangisi doğru parçayı daha sık getiriyorsa onu seçin. Yani cevap hep aynıdır: test ederek bulun.

Örnek senaryo: Bir diş kliniği web sitesindeki tedavi sayfalarını ve randevu kurallarını arşivlemek istiyor. Randevu kuralları kısa maddelerden oluştuğu için küçük parçalarla iyi çalışıyor. Tedavi açıklamaları ise uzun anlatım içerdiği için daha büyük parça istiyor. İki belge türü için iki ayrı boyut kullanmak burada makul olabilir.

Boyutu belirlerken parçanın tek başına okunduğunda anlaşılıp anlaşılmadığına bakın. Eğer bir insan parçayı okuyup konuyu kavrayabiliyorsa model de kavrar. Bu basit sınama birçok ekibin işini görür.

Ayrıca soruların uzunluğuna da bakın. Kullanıcılar çoğu zaman kısa ve belirsiz sorular yazar. Bu durumda geniş bağlam taşıyan parçalar, dar parçalardan daha sık doğru sonucu verir. Dolayısıyla kendi kullanıcı sorularınızı toplamak, rakam aramaktan daha değerlidir.

Meta veri neden parçaya eklenmeli?

Bir parça tek başına bağlamını kaybeder. "Madde 4'te belirtilen süre" ifadesi hangi belgeden geliyor? Meta veri bu soruyu yanıtlar.

Meta veri, parçaya iliştirdiğiniz ek bilgidir. Genellikle şunları içerir.

• Belge başlığı ve bölüm başlığı
• Kaynak dosya adı ya da adresi
• Sayfa numarası
• Yayın ya da güncelleme tarihi
• Belgenin türü, dili ve sürümü
• Erişim yetkisi (kim görebilir?)

Üç yarar sağlar. Birincisi, aramayı süzersiniz: yalnızca güncel sürümde ya da yalnızca belirli bir birimin belgelerinde ararsınız. İkincisi, yanıta kaynak gösterebilirsiniz. Üçüncüsü, yetkisiz kişilere yetkisiz belgeyi göstermezsiniz.

Başlığı parçanın metnine de eklemek güçlü bir hiledir. Parça "Kargo süresi" başlığıyla başlarsa gömme bu bağlamı da taşır. LlamaIndex'te üst belgenin meta verisi alt parçalara miras kalır. Bunu yukarıdaki düğüm ayrıştırıcı sayfasında bulabilirsiniz.

Örnek senaryo: İnsan kaynakları el kitabında hem genel kurallar hem yöneticilere özel bölümler var. Her parçaya "herkese açık" ya da "yönetici" etiketi eklerseniz arama yalnızca kullanıcının yetkisine uygun parçalarda çalışır. Etiketi arama sonrası değil, arama sırasında uygulayın.

Tablolar ve PDF dosyaları chunking'i nasıl bozar?

PDF, insan gözü için tasarlanmış bir biçimdir. Metin sırası dosyanın içinde okuma sırasıyla aynı olmayabilir. Çift sütunlu sayfalar iki sütunu karıştırarak çıkarabilir.

Üstbilgi ve altbilgi her sayfada tekrar eder. Bunlar parçaların içine girerse aramayı kirletir. Çıkarma aşamasında temizleyin.

Tablolar daha da zordur. Satırı ortasından bölerseniz sayı, başlığından ayrılır. "120" gibi bir değer hangi sütuna ait olduğunu kaybeder. Çözüm, tabloyu bölünmez bir birim saymaktır. Tablo büyükse her parçaya sütun başlıklarını yeniden ekleyin.

Taranmış belgeler için önce metin tanıma (OCR) gerekir.

OCR hatası parçaya olduğu gibi yansır. Bu yüzden önemli belgelerde çıkarılan metni örnekleyerek gözle kontrol edin.

Örnek senaryo: Bir muhasebe bürosu eski fatura şablonlarını tarayıp arşive ekliyor. OCR bir "8" rakamını "3" okursa parça yanlış tutar taşır. Arama bu parçayı doğru sanıp getirir ve model hatayı güvenle tekrarlar. Önemli belgelerde insan kontrolünü atlamayın.

Bu işleri sizin yerinize yapmamızı isterseniz yapay zeka ile belge işleme çözümümüze göz atabilirsiniz.

Belge türüne göre chunking nasıl değişir?

Tek bir kural bütün arşive uymaz. Belge türüne göre başlangıç noktasını şöyle seçebilirsiniz. Bunlar saha tecrübesine dayalı yönlendirmelerdir, garanti değildir.

• Kısa SSS maddeleri: Her soru ve cevap çifti tek parça olsun. Bölmeye gerek yok.
• Kullanım kılavuzu: Başlık bazlı bölün, uzun bölümleri paragraf sınırından kesin.
• Sözleşme ve politika: Madde numarasını ve başlığı her parçaya ekleyin, hiyerarşik yöntemi düşünün.
• Ürün kataloğu: Her ürünü bir parça yapın ve ürün adını meta veriye yazın.
• Destek yazışmaları: Konuşma turlarını birlikte tutun, tek mesaj çoğu zaman anlamsızdır.
• Toplantı dökümü: Anlamsal bölme ya da konuşmacı değişimi sınır olabilir.

Örnek senaryo: Bir e-ticaret firması hem ürün sayfalarını hem iade politikasını aynı vektör veri tabanına yüklüyor. Ürünler tek parça, politika ise başlık bazlı bölünürse iki tür belge birbirini bozmadan aranır.

Belge türünü meta veriye de yazın. Böylece "yalnızca politikalarda ara" gibi süzgeçler kurabilirsiniz.

Chunking stratejileri nasıl karşılaştırılır?

Aşağıdaki tablo dört temel stratejiyi yan yana koyar. Bunlar genel eğilimlerdir, belgenize göre sonuç değişir.

Tabloya göre tek bir kazanan yoktur. Çoğu üretim sistemi stratejileri birleştirir. Örneğin önce başlığa göre böler, büyük bölümleri uzunluğa göre keser, kesme noktasına küçük bir örtüşme ekler.

Chunking ile karıştırılan terimler hangileri?

Chunking sıklıkla komşu kavramlarla karıştırılır. Aşağıdaki tablo farkları kısaca özetler. Her terimin kendi yazısı var.

Chunking "ne kadarını ve nereden" sorusunu yanıtlar. Reranker ise "hangisi daha alakalı" sorusunu yanıtlar. Bağlam yönetiminin bütününü bağlam mühendisliği yazımızda anlattık.

Chunking maliyeti, hızı ve güncellemeyi nasıl etkiler?

Parçalama kararı yalnızca kaliteyi değil, işletme maliyetini de belirler. Parça sayısı arttıkça gömme hesaplaması ve depolama büyür. Örtüşme bu sayıyı daha da artırır.

Güncelleme de önemlidir. Bir belgenin tek paragrafı değişse bile parçalar kaydıysa tüm belgeyi yeniden işlemeniz gerekebilir. Başlık bazlı yöntemde yalnızca değişen bölümün parçalarını yenilersiniz.

Bu yüzden her parçaya kararlı bir kimlik verin. Kimliği belge adı ve bölüm başlığından türetirseniz eski sürümü silip yenisini yazmak kolaylaşır.

Silinen belgeleri de unutmayın. Kaynak belgeyi kaldırdığınızda parçaları indeksten de çıkarın. Aksi halde model artık geçersiz bir kuralı kaynak gösterebilir.

Maliyet konusunda güncel fiyatları sağlayıcının resmi sayfasından kontrol edin. Gömme maliyeti genellikle token sayısıyla orantılıdır, dolayısıyla gereksiz tekrar doğrudan faturaya yansır.

Hazır araçlar chunking işini bizim yerimize yapar mı?

Kısmen yapar. Birçok sağlayıcı, dosya yüklediğinizde belgeleri otomatik parçalar. Bu, hızlı bir prototip için harikadır. Ancak varsayılan ayarlar sizin belgelerinizi tanımaz.

Örneğin OpenAI dosya arama belgeleri otomatik bir strateji sunar. Aynı zamanda parça boyutu ve örtüşmeyi elle ayarlamanıza izin verir. Hangi ayarların bulunduğunu ve varsayılan değerlerini resmi belgeden kontrol edin, çünkü bunlar değişebilir.

LangChain ve LlamaIndex ise daha fazla kontrol verir. Bölücüyü, ayracı ve meta veri akışını kendiniz seçersiniz. Bunun karşılığında kodun ve ayarların bakımını siz üstlenirsiniz.

Pratik tavsiyemiz şudur: önce hazır ayarla başlayın, sonra sonuçları ölçün. Sorun görürseniz kuralı elle belirleyin. Hiçbir aracı "en iyi" diye ilan etmiyoruz, çünkü doğru seçim belgenize ve ekibinizin becerisine bağlıdır.

Chunking kalitesi nasıl ölçülür?

Chunking'i "güzel görünüyor" diye seçmeyin. Ölçün. Elinizde gerçek kullanıcı sorularına benzeyen bir soru listesi ve her sorunun doğru cevabının hangi belgede olduğu bilgisi olmalı.

Sonra şunu sorun: Doğru parça ilk sonuçlar arasında geliyor mu? Bu ölçüye genellikle arama isabeti denir. İkinci soru: Model, getirilen parçalarla doğru cevabı veriyor mu?

Değişiklik yaparken tek ayarı değiştirin. Parça boyutunu değiştiriyorsanız örtüşmeyi sabit tutun. Aksi halde farkın nereden geldiğini anlayamazsınız.

Değerlendirme yöntemleri için LLM evals yazımıza bakın. Gerçek kullanıcı sorularını da düzenli örnekleyin, çünkü belge arşivi zamanla değişir.

Bir ölçü de başarısızlık analizidir. Yanlış cevap veren soruları tek tek açın ve doğru parçanın neden gelmediğine bakın. Çoğu zaman sebep iki gruptan birine düşer: parça çok küçük olduğu için bağlam yoktur ya da parça çok büyük olduğu için alakasız metin doğru cümleyi bastırmıştır. Bu bulgu, hangi yöne ayar yapacağınızı gösterir.

Hatalı cevapların bir kısmı modelin uydurmasından gelir.

Bu konuyu halüsinasyon yazımızda ele aldık. Ancak bazen suçlu model değil, eksik getirilen parçadır.

Chunking'de en sık yapılan hatalar nelerdir?

Sahada en sık gördüğümüz hatalar şunlardır.

• Tüm belgeleri tek ayarla bölmek: Sözleşme ile SSS aynı kurala uymaz.
• Rakamı kopyalamak: Başka bir yazıdaki parça boyutunu test etmeden uygulamak.
• Temizlik yapmamak: Üstbilgi, altbilgi ve menü metinleri parçaların içinde kalır.
• Meta veriyi atlamak: Kaynak, tarih ve yetki bilgisi olmadan parça yetim kalır.
• Tabloyu satırdan kesmek: Başlıksız sayılar anlamsızdır.
• Hiç ölçmemek: Chunking'in etkisini yalnızca model cevaplarına bakarak yargılamak.

Bir hata daha var: güvenlik. Belgelerde gizli talimat metinleri olabilir ve parça modele girdiğinde etkileyebilir. Bu risk için prompt injection yazımıza bakın.

Bu hataların çoğu ilk haftada fark edilmez. Sistem demo sorularında iyi çalışır, gerçek kullanıcı gelince bozulur. Bu nedenle canlıya almadan önce, hiç görmediğiniz türden sorularla da deneme yapın.

Chunking nedir sorusunda yetki ve gizlilik neden önemli?

Chunking nedir sorusunun güvenlik yüzü çoğu zaman gözden kaçar. Belgeyi parçalara böldüğünüzde her parça bağımsız bir kayıt olur. Bu kayıt, kaynak belgenin erişim kurallarını kendiliğinden taşımaz.

Kuralı siz parçaya yazmazsanız yetkisiz bir kullanıcı, yalnızca yöneticilere açık bir belgenin parçasını görebilir. Dolayısıyla yetki bilgisini meta veriye ekleyin ve aramayı bu bilgiye göre süzün.

Kişisel veri de ayrı bir konudur. Parçalar vektör veri tabanında ayrı bir kopya olarak durur. Bir kişi verisinin silinmesini isterse bu kopyaları da bulup silmeniz gerekir. Bunun için parçaya kaynak kimliği koymak işinizi kolaylaştırır.

Bu bir hukuki danışmanlık değildir. Kişisel veri içeren arşivlerde KVKK yükümlülüklerini kendi hukuk danışmanınızla netleştirin.

Şirket belge arşivi için chunking kontrol listesi nedir?

Kendi arşivinizi hazırlarken şu listeyi sırayla uygulayın.

1. Belge türlerini ayırın: kılavuz, sözleşme, SSS, tablo ağırlıklı rapor, döküm.
2. Her tür için bir bölme kuralı seçin. Yapılı belgelerde başlık bazlı, düz metinde örtüşmeli yöntemle başlayın.
3. Metin çıkarmayı temizleyin: üstbilgi, altbilgi ve sayfa numaralarını ayıklayın.
4. Tabloları bölünmez birim sayın ve başlıkları tekrar ekleyin.
5. Her parçaya başlık, kaynak, sürüm ve yetki bilgisini ekleyin.
6. Gömme modelinin girdi sınırını sağlayıcı belgesinden kontrol edin.
7. Gerçekçi bir soru listesi hazırlayın ve birkaç boyutu aynı listeyle deneyin.
8. Yetkisiz belgenin yanıta karışmadığını test edin.
9. Belge güncellendiğinde yalnızca etkilenen parçaları yeniden indeksleyin.
10. Düzenli aralıklarla örnek sorularla yeniden ölçün.

Parça uzunluğunu hızlıca görmek için kelime ve karakter sayacımızı kullanabilirsiniz. Bu yalnızca kabaca bir fikir verir, kesin ölçü token sayısıdır.

Listedeki sıra önemlidir. Önce belgeyi tanır, sonra kuralı seçer, en son ölçersiniz. Kuralı seçmeden ölçmeye başlamak zaman kaybıdır. Ayrıca ilk sürümü küçük tutun: yüzlerce belge yerine on belgeyle başlayın, sonucu görün, sonra büyütün.

Chunking için ne zaman dış destek almalısınız?

Küçük bir kılavuz setini kendi başınıza parçalayıp denemek makuldür. Ancak belge sayısı büyüdüğünde ve türler çeşitlendiğinde iş mühendisliğe döner. Taranmış PDF'ler, yetki kuralları ve sürekli güncellenen arşivler en çok emek isteyenlerdir.

Biz, Talha Aslan ve ekibi olarak bu tür projelerde önce belgelerinizi inceler, ardından küçük bir deneme seti kurarız. Sonuçları ölçer, sonra büyütürüz. Kurumsal ihtiyaçlar için kurumsal bilgi asistanı sayfamızı inceleyebilirsiniz.

Not: Bu yazı genel bilgi amaçlıdır ve hukuki danışmanlık değildir. Kişisel veri içeren belgeleri yapay zekaya vermeden önce kendi hukuk danışmanınıza ve KVKK yükümlülüklerinize başvurun. Sağlayıcıların güncel sınırlarını ve varsayılan ayarlarını her zaman resmi belgeden kontrol edin.

Chunking nedir sorusunun kısa özeti nedir?

Kısaca chunking, belgeyi aramaya uygun anlamlı parçalara bölmektir. Parçalar çok küçükse bağlam kopar. Çok büyükse gürültü artar.

Basit bir sabit uzunlukla başlayabilirsiniz. Ardından başlık bazlı ve örtüşmeli yönteme geçin, meta veriyi ekleyin ve tabloları koruyun. Anlamsal bölmeyi ancak ölçüm gerektirirse deneyin.

En önemli kural şudur: rakamı başkasından almayın, kendi belgenizle test edin. Çünkü doğru chunking, belgenin ve sorunun türüne göre değişir.