# Multimodal (Görsel) RAG: Belgelerdeki Tablo ve Grafikleri Nihayet Aranabilir Kılmak

> Source: https://sukruyusufkaya.com/blog/multimodal-vision-rag-belge-yapay-zeka-2026
> Updated: 2026-08-01T16:03:58.622Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Metin RAG belgelerdeki tablo, grafik ve düzeni kaçırır. Multimodal RAG mimarilerini (ColPali, görsel gömme), değerlendirmeyi ve KVKK'yı sahadan anlatıyorum.

**TL;DR —** Kurumsal belgelerin çoğu sadece metinden ibaret değil; tablolar, grafikler, şemalar, imzalar, formlar ve sayfa düzeni bilginin büyük kısmını taşıyor. Klasik, metne-dayalı RAG bu sinyalin çoğunu sessizce çöpe atıyor. 2026'da olgunlaşan multimodal (görsel) RAG, sayfayı bir görüntü olarak indeksleyip görsel-dil modelleriyle sorgulayarak bu boşluğu kapatıyor. Bu yazıda üç baskın mimariyi (caption-and-index, birleşik görsel gömme, ColPali tarzı geç-etkileşim), ne zaman hangisini seçeceğinizi, Türkçe belgelerdeki tuzakları ve KVKK açısından dikkat etmeniz gerekenleri sahadan anlatıyorum.

## RAG'ın görmezden geldiği gerçek

Son bir yılda kurdurduğum RAG projelerinin neredeyse hepsinde aynı sahne yaşandı. Ekip metin-tabanlı bir boru hattı kuruyor, PDF'leri parçalıyor, gömüyor, arama iyi çalışıyor gibi görünüyor. Sonra iş sahibi geliyor ve "peki bu finansal raporun 12. sayfasındaki grafikte gösterilen çeyreklik büyüme neydi?" diye soruyor. Sistem susuyor. Çünkü o grafik bir görüntüydü; metin çıkarıcı ondan ya hiçbir şey ya da anlamsız bir sayı dizisi çıkarmıştı.

İşte kurumsal RAG'ın en büyük sessiz kaybı bu. Gerçek dünya belgeleri — finansal tablolar, teknik kılavuzlar, sigorta poliçeleri, tıbbi raporlar, ürün kataloğu — bilgilerinin çok önemli bir kısmını metin dışı öğelerde taşır. Bir gelir grafiği, bir devre şeması, bir organizasyon şeması, bir tablo hücresinin diğerine göre konumu... Bunların hiçbiri düz metin çıkarımıyla kurtarılamaz. Metne-dayalı RAG, aslında belgenin yarısını görmeden yanıt üretmeye çalışıyor.

Multimodal RAG'ın vaadi tam da burada devreye giriyor: görüntüleri, sayfa görüntülerini ve yapısal görselleri metnin yanında birinci sınıf arama nesneleri olarak ele almak. Yani sistem artık "bu sayfada ne yazıyor" diye değil, "bu sayfa neye benziyor ve ne anlatıyor" diye soruyor.

## Metin çıkarımının kırıldığı noktalar

Neden metne-dayalı yaklaşımın yetmediğini somutlaştırayım, çünkü bunu görmeden çözümün değerini anlamak zor.

**Tablolar.** Bir PDF'den tablo çıkarırken satır-sütun ilişkisi neredeyse her zaman bozulur. "2024: 120, 2025: 150" gibi bir tablo, düz metne dönüştüğünde hücrelerin hangi başlığa ait olduğu kaybolur. Model, 120'nin gelir mi gider mi, 2024'e mi 2025'e mi ait olduğunu bilemez.

**Grafikler ve çizelgeler.** Bir çubuk grafikte gösterilen trend, metin katmanında hiç yoktur; sadece bir resimdir. OCR bunu okuyamaz çünkü okunacak metin değil, yorumlanacak bir görsel vardır.

**Sayfa düzeni ve bağlam.** Bir sözleşmede imza bloğunun konumu, bir formun hangi alanının doldurulduğu, bir başlığın altındaki maddelerin hiyerarşisi — bunların hepsi görsel bağlamdır. Düz metin bu yapıyı düzleştirir ve anlam kaybolur.

**Taranmış belgeler.** Birçok kurumsal arşiv hâlâ taranmış PDF'lerden oluşur. Burada zaten "metin" yoktur; sadece kağıdın fotoğrafı vardır. Geleneksel yaklaşım önce OCR yapar, hata biriktirir, sonra o hatalı metni gömer.

> Sahadan kural: Eğer belgeleriniz "temiz, metin-ağırlıklı Word/HTML" değil de "gerçek dünya PDF'i" ise, metne-dayalı RAG'ın doğruluk tavanı düşüktür ve bu tavanı prompt mühendisliğiyle aşamazsınız. Sorun modelde değil, indeksin en baştan bilgiyi kaybetmesinde.

## Üç baskın mimari

2026 itibarıyla multimodal RAG'da üç yaklaşım öne çıkıyor. Bunları anlamak, kendi projeniz için doğru dengeyi kurmanın anahtarı.

**1. Caption-and-index (altyazı üret ve indeksle).** En basit yöntem. Her görsel/sayfa için bir görsel-dil modeliyle metinsel bir açıklama (caption) üretirsiniz, sonra bu açıklamayı klasik metin gömme ile indekslersiniz. Avantajı: mevcut metin-tabanlı altyapınızın üzerine oturur, ucuzdur, hızlı kurulur. Dezavantajı: açıklama, görselin tüm nüansını yakalayamaz; captioning modeli neyi önemli bulduysa onu yazar, gerisini atlar. Basit görseller ve orta hassasiyetli işler için idealdir.

**2. Birleşik görsel gömme (unified vision embeddings).** Burada metin ve görüntüyü aynı vektör uzayına gömen çok-modlu gömme modelleri kullanırsınız — Cohere Embed 4, voyage-multimodal-3.5 gibi. Bir görseli ve bir metni doğrudan karşılaştırabilir, "şu grafiğe benzeyen sayfayı bul" diyebilirsiniz. Avantajı: captioning'in bilgi kaybı yok; görsel doğrudan aranabilir. Dezavantajı: tek bir gömme vektörü bazen yoğun bir sayfanın tüm detayını sıkıştıramaz.

**3. Sayfa-olarak-görüntü + geç etkileşim (ColPali, ColQwen2.5, ColNomic).** En güçlü ama en ağır yaklaşım. Sayfanın tamamını bir görüntü olarak alır, çok sayıda "yama" (patch) düzeyinde temsil üretir ve sorgu ile bu yamalar arasında geç etkileşim (late interaction, ColBERT tarzı) hesabı yapar. Böylece sorgu, sayfanın hangi bölgesiyle eşleştiğini ince ayrıntıda bulur. Avantajı: en yüksek doğruluk, özellikle yoğun ve karmaşık belgelerde. Dezavantajı: depolama ve hesaplama maliyeti yüksek; her sayfa için çok sayıda vektör tutmanız gerekir.

| Mimari | Karmaşıklık | Doğruluk | Maliyet | En uygun senaryo |
|---|---|---|---|---|
| Caption-and-index | Düşük | Orta | Düşük | Basit görseller, mevcut metin RAG üstüne ekleme |
| Birleşik görsel gömme | Orta | Yüksek | Orta | Karışık metin+görsel, orta ölçek |
| ColPali tarzı geç etkileşim | Yüksek | En yüksek | Yüksek | Yoğun finansal/teknik belge, yüksek hassasiyet |

## Hangisini ne zaman seçmeli

En sık aldığım soru: "Hepsini mi kurmalıyım?" Hayır. Doğru cevap, belgelerinizin doğasına ve hata toleransınıza bağlı.

Eğer belgeleriniz çoğunlukla metin ve arada birkaç görsel içeriyorsa, işe **caption-and-index** ile başlayın. Mevcut RAG'ınıza en az sürtünmeyle eklenir ve %70-80 değeri hızlıca alırsınız. Grafik ve tablo sorguları kritikse ama bütçeniz sınırlıysa, **birleşik görsel gömme** en iyi denge noktası. Finansal analiz, teknik dokümantasyon, hukuki belge gibi her detayın önemli olduğu ve yanlış cevabın maliyetli olduğu alanlarda ise **ColPali tarzı geç etkileşim** yatırımı geri öder.

Benim sahada uyguladığım pratik strateji "kademeli olgunlaşma": önce caption-and-index ile hızlı bir temel kur, gerçek kullanıcı sorgularını topla, hangi soru tipinde başarısız olduğunu ölç, sonra o zayıf noktaları hedefleyerek daha ağır mimariye geç. Baştan en pahalı çözümü kurmak, çoğu zaman gereğinden fazla mühendislik ve gecikmedir.

## Değerlendirme: nasıl ölçersiniz

Multimodal RAG'da en tehlikeli tuzak, "gözle bakınca iyi görünüyor" yanılgısı. Birkaç örnek soru güzel çalışınca sistem hazır sanılıyor. Oysa gerçek doğruluk ancak sistematik değerlendirmeyle görülür.

2026'da UNIDOC-BENCH gibi belge-merkezli multimodal RAG değerlendirme setleri tam da bu ihtiyaçtan doğdu. Ama sizin asıl ihtiyacınız kendi belgelerinizden türetilmiş bir "altın küme" (golden set). Yani gerçek kullanıcı sorularını, bunların doğru cevaplarını ve o cevabın belgenin hangi sayfasının/görselinin hangi bölgesinden geldiğini elle işaretleyin. Sonra sisteminizi bu kümeye karşı ölçün: doğru sayfayı getiriyor mu (retrieval), doğru cevabı üretiyor mu (generation), cevabı doğru kaynağa dayandırıyor mu (attribution).

Özellikle "getirilen sayfa doğru ama cevap yanlış" ile "getirilen sayfa yanlış" arasındaki farkı ayırın; çünkü ikisi tamamen farklı sorunlardır. İlki modelin görsel yorumu, ikincisi indeksleme/arama sorunu. Karıştırırsanız yanlış yeri optimize edersiniz.

## Türkçe belgelerde özel tuzaklar

Türkçe içerikle çalışırken multimodal RAG birkaç ek zorluk getiriyor ve bunları önceden bilmek çok değerli.

Birincisi, **OCR ve font sorunları**. Türkçe karakterler (ı, İ, ğ, ş, ç) taranmış belgelerde sık sık yanlış tanınır. Bu, caption-and-index yaklaşımında birikimli hata yaratır. Görsel-tabanlı yaklaşımların (ColPali gibi) avantajı burada belirginleşir: sayfayı görüntü olarak işledikleri için OCR hatasına bağımlı değiller.

İkincisi, **captioning modellerinin Türkçe zayıflığı**. Birçok görsel-dil modeli İngilizce görsellerde çok iyi, ama Türkçe metin içeren bir grafiği açıklarken zorlanabilir. Bu yüzden captioning kullanıyorsanız, ürettiği açıklamaları örneklem üzerinden mutlaka kontrol edin.

Üçüncüsü, **karışık dil belgeleri**. Türk kurumlarının belgeleri sıklıkla Türkçe-İngilizce karışıktır (teknik terimler İngilizce, açıklamalar Türkçe). Gömme modelinizin iki dili de aynı uzayda tutarlı temsil ettiğinden emin olun; yoksa Türkçe soru İngilizce içeriği ya da tersini bulamaz.

## KVKK ve görsel içerik: gizli risk

Multimodal RAG'ın az konuşulan ama kritik bir tarafı: görselleri indekslediğinizde, o görsellerin içindeki kişisel veriyi de indekslemiş olursunuz. Bir taranmış belgede kimlik fotokopisi, bir formda imza, bir raporda hasta adı olabilir. Metne-dayalı RAG'da bu veriler çıkarım sırasında bazen kaybolurken, görsel RAG onları olduğu gibi vektöre gömer.

Bu, KVKK açısından iki soruyu gündeme getirir. Birincisi, **amaç sınırlaması**: bu kişisel veriyi işlemek için hukuki dayanağınız var mı? İkincisi, **erişim kontrolü**: RAG sistemine soru soran herkes, o görseldeki kişisel veriye erişmeli mi? Benim önerdiğim mimari, belge düzeyinde erişim yetkilendirmesini indeks katmanına gömmek — yani kullanıcının yetkisi olmayan belgeler, arama sonuçlarına hiç girmemeli. Bunu sonradan "cevabı filtrelemek" yerine, en baştan getirme aşamasında yapın.

Ayrıca özel nitelikli veri (sağlık, biyometrik) içeren görsellerde ekstra dikkat gerekir. Bir tıbbi rapor görselini indekslediyseniz, bu KVKK'da en katı korumaya tabi kategoridir; anonimleştirme, ayrı depolama ve sıkı erişim kaydı şart.

> Kurumlarda gördüğüm hata: veri ekibi görsel RAG'ı bir "arama iyileştirmesi" olarak görüp hukuku sürece geç dahil ediyor. Oysa görselleri indekslemek, yeni bir veri işleme faaliyetidir ve baştan hukuki değerlendirme ister. Sonradan düzeltmek, indeksi baştan kurmak demek.

## Görsel belgede "parçalama" (chunking) nasıl değişir

Metin RAG'ında hayatınızın yarısı chunking'le geçer: metni ne kadar büyük parçalara böleceğiniz, örtüşme (overlap) ne olacak, cümle mi paragraf mı sınır alacaksınız. Görsel RAG bu problemi kökten değiştiriyor ve bunu anlamak mimari seçiminizi doğrudan etkiliyor.

Sayfa-olarak-görüntü yaklaşımında doğal chunking birimi sayfadır. Bir sayfa, bir arama nesnesi. Bu, metindeki "cümlenin ortasından bölme" sorununu ortadan kaldırır çünkü sayfa görsel bütünlüğünü korur; tablo, grafik ve etrafındaki açıklama aynı nesnede kalır. Ama yeni bir sorun doğar: çok yoğun sayfalar. Bir sayfada üç ayrı tablo ve iki grafik varsa, tek bir sayfa temsili bunların hepsini birden aramak için yeterince keskin olmayabilir. İşte ColPali tarzı geç etkileşimin değeri burada: sayfa içindeki farklı bölgeleri ayrı ayrı temsil ettiği için, sorgu sayfanın doğru köşesine odaklanabilir.

Caption-and-index tarafında ise chunking, captioning'in granülerliğine bağlı. Her görsel için tek bir açıklama üretirseniz kaba olur; her tablo, her grafik için ayrı açıklama üretirseniz daha ince ama daha pahalı. Benim önerim: yüksek-değerli belgelerde görsel öğe düzeyinde captioning yapın (her grafiğe kendi açıklaması), düşük-değerli belgelerde sayfa düzeyinde kalın. Granülerliği belgenin önemine göre ayarlamak, hem maliyeti hem doğruluğu dengeler.

Bir de metin ve görselin bir arada olduğu sayfalarda "çift indeksleme" stratejisi işe yarar: aynı sayfayı hem metin çıkarımıyla (temiz metin için) hem görsel gömme ile (tablo/grafik için) indeksleyin. Sorgu geldiğinde iki indeksten de aday getirip birleştirirsiniz. Bu biraz daha fazla depolama ister ama "hem metinsel hem görsel" soruları çok daha güvenilir yanıtlar.

## Hibrit arama ve yeniden sıralama

Multimodal RAG'ı üretimde sağlam kılan tek bir sihirli model değil, katmanlı bir arama stratejisidir. Sahada en iyi sonuçları hep hibrit yaklaşımla aldım.

Getirme aşamasını iki ayağa oturtun. Birincisi yoğun (dense) görsel/metin gömme araması: anlamsal benzerliği yakalar, "büyüme trendi" gibi kavramsal sorularda güçlü. İkincisi seyrek (sparse) anahtar kelime araması (BM25 gibi): tam terim eşleşmelerinde, kod numaralarında, özel isimlerde güçlü. Bir belgede "2024 Q3 EBITDA" ararken anahtar kelime araması altın değerinde; "kârlılık nasıl değişti" ararken yoğun arama. İkisini birleştirmezseniz, sorgu tipine göre bir tarafta hep kaybedersiniz.

Getirmeden sonra bir **yeniden sıralayıcı (reranker)** koyun. İlk getirme geniş bir aday havuzu çıkarır (diyelim 50 sayfa), reranker bunları soruyla gerçek alaka düzeyine göre yeniden sıralar ve en iyi birkaçını modele verir. Görsel belgelerde çok-modlu reranker kullanmak, metin-only reranker'a göre belirgin fark yaratır çünkü sayfanın görsel içeriğini de değerlendirir. Bu adım maliyeti biraz artırır ama yanlış sayfayı modele vermenin maliyeti çok daha yüksektir — çünkü model yanlış kaynaktan kendinden emin, yanlış bir cevap üretir.

## Gerçek bir vaka: sigorta poliçesi arşivi

Somut olsun diye anonim bir örnek anlatayım. Bir sigorta kurumunda, on binlerce taranmış poliçe ve hasar dosyası vardı. Bu belgeler el yazısı notlar, damgalar, tablolar ve imza bloklarıyla doluydu. İlk ekip klasik OCR + metin RAG kurmuştu ve doğruluk yüzde ellilerdeydi — çünkü OCR el yazısını ve damgaları okuyamıyor, tablo yapısını düzleştiriyordu.

Yaklaşımı değiştirdik. Sayfaları görüntü olarak işleyen bir multimodal hat kurduk; taranmış belgelerde OCR'a bağımlı olmayan görsel gömme kullandık. Poliçe numarası gibi tam-eşleşme gereken alanlar için OCR'ı tümüyle atmadık ama onu sadece anahtar kelime indeksini beslemek için kullandık, cevap üretimini görsel modele bıraktık. Erişim kontrolünü belge düzeyinde indekse gömdük çünkü hasar dosyaları hassas kişisel veri içeriyordu ve her kullanıcı her dosyayı görememeliydi.

Sonuç: doğru sayfayı getirme oranı ciddi biçimde yükseldi ve en önemlisi, cevaplar artık kaynağa dayanıyordu — kullanıcı "bu bilgi hangi sayfadan geldi" diye tıklayıp orijinal görseli görebiliyordu. Bu vakadan çıkardığım ders şu: taranmış, görsel-yoğun arşivlerde multimodal RAG bir "iyileştirme" değil, çoğu zaman tek uygulanabilir yaklaşım.

## Sık yapılan hatalar

Bu alanda tekrar tekrar gördüğüm hataları toparlayayım ki siz aynı bedeli ödemeyin.

**Her şeyi tek mimariye sokmak.** Basit metin belgelerini pahalı görsel hatta yönlendirmek, para ve gecikme israfıdır. Hibrit yönlendirme şart.

**Değerlendirmeyi atlamak.** "Birkaç örnek çalıştı" demek, sistemin hazır olduğu anlamına gelmez. Altın küme olmadan neyi iyileştirdiğinizi bilemezsiniz.

**Kaynak göstermeyi ihmal etmek.** Kurumsal kullanıcı kaynaksız cevaba güvenmez. Attribution olmayan bir multimodal RAG, teknik olarak etkileyici ama pratikte kullanılmaz.

**KVKK'yı sona bırakmak.** Görselleri indeksledikten sonra "acaba burada kişisel veri var mıydı" diye sormak çok geçtir. Hukuki değerlendirme baştan yapılmalı.

**Türkçe'yi İngilizce gibi varsaymak.** İngilizce'de mükemmel çalışan bir captioning ya da gömme modeli, Türkçe grafiklerde ve karışık dilli belgelerde beklenmedik biçimde zayıflayabilir. Mutlaka kendi dilinizde test edin.

## Ekip, rol ve olgunluk

Bu tür bir sistemi tek bir mühendis kuramaz; disiplinler arası bir iştir. Veri mühendisi belge hattını ve indekslemeyi kurar, makine öğrenmesi mühendisi mimari ve model seçimini yapar, bir alan uzmanı (finansçı, hukukçu, sigortacı) altın kümeyi ve doğru cevapları belirler, hukuk/uyum ekibi erişim ve KVKK çerçevesini çizer. Bu rollerden biri eksikse, sistem ya teknik olarak zayıf ya hukuki olarak riskli çıkar.

Olgunluk açısından gerçekçi bir beklenti kurun. İlk sürüm mükemmel olmayacak; olması da gerekmiyor. Önemli olan, ölçülebilir bir temel kurmak ve gerçek kullanım verisiyle onu iyileştirmek. Multimodal RAG bir "kur ve unut" projesi değil, sürekli beslenen bir sistemdir; kullanıcı sorguları, red edilen cevaplar ve yeni belge tipleri onu zamanla keskinleştirir.

## Üretim mimarisi: pratik bir şablon

Sahada işe yarayan bir referans mimari paylaşayım. Bunu bir reçete değil, uyarlanabilir bir iskelet olarak alın.

Girişte, belgeleri türlerine göre yönlendirin: temiz metin belgeleri klasik metin RAG'a, görsel-yoğun belgeler multimodal hatta. Bu **hibrit yönlendirme**, her belgeye gereğinden fazla maliyet yüklemeyi önler. Multimodal tarafta, sayfa görüntülerini üretin, seçtiğiniz mimariye göre gömün ve vektör deposuna yazın. Sorgu geldiğinde, önce doğru belge kümesini erişim yetkisiyle filtreleyin, sonra hem metin hem görsel indeksten aday getirin, bir yeniden sıralayıcı (reranker) ile birleştirin.

Üretim aşamasında görsel-dil modeline hem soruyu hem getirilen sayfa görüntülerini verin ve cevabı hangi sayfadan ürettiğini açıkça belirtmesini isteyin. Bu **kaynak gösterme** (attribution) hem güveni artırır hem de yanlış cevapları denetlenebilir kılar. Son olarak, her cevabın kaynağını kullanıcıya gösterin; kurumsal kullanıcı "modele güven" demez, "kaynağı göster" der.

Gözlemlenebilirlik tarafını ihmal etmeyin. Hangi sorguların hangi sayfaları getirdiğini, hangi cevapların kaynağa dayandığını, kullanıcıların hangi cevapları reddettiğini loglayın. Bu loglar, hem değerlendirme altın kümenizi zenginleştirir hem de sistemin zamanla nerede zayıfladığını gösterir.

## Hangi görsel-dil modelini seçmeli

Cevap üretimini yapan görsel-dil modelini seçerken üç ekseni birlikte tartın: doğruluk, maliyet ve veri mahremiyeti. Frontier kapalı modeller (büyük sağlayıcıların çok-modlu modelleri) genellikle en yüksek görsel yorumlama doğruluğunu verir; karmaşık bir finansal grafiği ya da yoğun bir tabloyu en iyi onlar okur. Ama her sayfa görüntüsünü bir dış API'ye göndermek hem maliyetli hem de KVKK açısından dikkat gerektiren bir veri aktarımıdır.

Açık kaynak çok-modlu modeller ise 2026'da ciddi olgunlaştı ve birçok kurumsal senaryoda "yeterince iyi" doğruluğu kendi altyapınızda sunuyor. Hassas belgelerle (sağlık, finans, hukuk) çalışıyorsanız, veriyi hiç dışarı çıkarmadan kendi ortamınızda çalışan bir açık model, mahremiyet açısından çok daha rahat bir konumdur.

Benim pratik önerim melez: yüksek-hacimli, düşük-hassasiyetli sorgularda kendi ortamınızdaki açık modeli kullanın; nadir ama kritik, yüksek-doğruluk gerektiren sorgularda frontier modele yönlendirin. Bu **model yönlendirme** hem maliyeti hem mahremiyet riskini yönetir. Seçiminizi mutlaka kendi altın kümenizde test edin — bir modelin genel benchmark'ta iyi olması, sizin belge tipinizde iyi olacağı anlamına gelmez. Türkçe ve karışık dilli belgelerde bu fark daha da belirginleşir.

## Vektör deposu ve altyapı seçimi

Multimodal RAG'da altyapı kararları, metin RAG'a göre daha fazla düşünmeyi hak ediyor çünkü veri hacmi ve vektör sayısı çok daha büyük. Sayfa-olarak-görüntü yaklaşımında bir belge, yüzlerce hatta binlerce vektöre dönüşebilir; bu, vektör deposu seçiminizi doğrudan etkiler.

İlk soru: geç etkileşim (multi-vector) desteği. ColPali tarzı yaklaşımlar sayfa başına çok sayıda vektör üretir ve bunlar arasında geç etkileşim hesabı yapar. Her vektör deposu bunu verimli desteklemez; seçtiğiniz aracın multi-vector ve geç etkileşim sorgularını yerel olarak yapabildiğinden emin olun, yoksa sorgu gecikmesi patlar. Birleşik gömme (tek vektör) yaklaşımını seçtiyseniz, klasik yoğun arama yapan hemen her vektör deposu işinizi görür ve altyapı kararı çok daha basitleşir.

İkincisi, depolama maliyeti ve niceleme (quantization). Milyonlarca sayfalık bir arşivde, vektörleri tam hassasiyette (float32) tutmak depolama açısından pahalıdır. Vektör niceleme (örneğin binary ya da scalar quantization) depolamayı ciddi biçimde düşürür ve çoğu senaryoda doğruluğu çok az etkiler. Ama bunu körlemesine yapmayın; kendi altın kümenizde niceleme öncesi ve sonrası doğruluğu ölçün.

Üçüncüsü, ölçeklenme. Belge sayınız zamanla artacaksa, yeniden indeksleme maliyetini baştan düşünün. Yeni bir gömme modeline geçmek istediğinizde tüm arşivi yeniden gömmek zorunda kalabilirsiniz; bu, milyonlarca sayfada günler süren bir operasyon olabilir. Bu yüzden model seçimini ciddiye alın ve sık sık değiştirmek zorunda kalmayacağınız, olgun bir model seçin. Kısacası altyapı, mimari seçiminizin doğrudan bir sonucudur; önce mimariyi netleştirin, sonra ona uygun depoyu seçin.

## Yol haritası: 60 günde pilottan üretime

Somut bir plan olmadan bu yazı havada kalır. Sahada işe yarayan, yaklaşık 60 günlük bir pilottan-üretime yol haritası paylaşayım.

**İlk iki hafta — kapsam ve altın küme.** En görsel-yoğun, en yüksek-değerli belge tipinizi seçin (tüm arşivi değil). Bu belgelerden 50-100 gerçek soru toplayın, doğru cevapları ve kaynak sayfalarını elle işaretleyin. Bu altın küme, tüm projenin pusulası olacak.

**Üçüncü ve dördüncü hafta — hızlı temel.** Caption-and-index ile bir temel kurun. Mevcut metin RAG altyapınız varsa üstüne oturtun. Altın kümeye karşı ilk doğruluk ölçümünüzü yapın. Bu sayı düşük olsa bile önemli; çünkü artık iyileştirmeyi ölçebileceğiniz bir başlangıç noktanız var.

**Beşinci ve altıncı hafta — güçlendirme.** Temelin başarısız olduğu soru tiplerini analiz edin. Grafik/tablo sorgularında zayıfsanız birleşik görsel gömmeye ya da ColPali'ye geçin. Hibrit arama ve reranker ekleyin. Erişim kontrolünü ve KVKK çerçevesini indekse gömün.

**Yedinci ve sekizinci hafta — üretim sertleştirme.** Kaynak gösterme (attribution) arayüzünü tamamlayın, gözlemlenebilirlik loglarını kurun, gecikme ve maliyeti üretim yükü altında ölçün. Sınırlı bir kullanıcı grubuyla canlıya alın, geri bildirim toplayın ve altın kümenizi bu gerçek sorgularla büyütün.

Bu ritmi izlerseniz, iki ay sonunda hem çalışan hem ölçülebilir hem hukuki olarak sağlam bir sisteminiz olur. En kritik nokta: baştan mükemmeli değil, ölçülebilir olanı hedefleyin. Ölçebildiğiniz her şeyi iyileştirebilirsiniz.

## Maliyet ve gecikme gerçeği

Dürüst olalım: multimodal RAG, metne-dayalı RAG'dan daha pahalı ve daha yavaş. ColPali tarzı yaklaşımlarda her sayfa için onlarca-yüzlerce vektör tutmak, depolama maliyetini ciddi biçimde artırır. Görsel-dil modeliyle çıkarım, metin modeline göre daha fazla token ve daha yüksek gecikme demektir.

Bu yüzden maliyet-doğruluk dengesini bilinçli kurun. Her belgeyi en ağır mimariye sokmak yerine, hibrit yönlendirmeyle sadece görsel-yoğun ve yüksek-değerli belgeleri oraya yönlendirin. Sık sorulan sorular için önbellek kullanın. Ve en önemlisi: doğruluğun gerçekten önemli olduğu yerlerde maliyeti kabullenin, önemsiz olduğu yerlerde ucuz yolu seçin. Her şeyi en yüksek kalitede yapmaya çalışmak, çoğu zaman bütçeyi yanlış yere harcamaktır.

Pratik olarak yol haritanız şu olmalı: görsel-yoğun belgelerinizi tespit edin, küçük bir altın küme oluşturun, caption-and-index ile hızlı bir temel kurup ölçün, zayıf noktalarda daha ağır mimariye kademeli geçin, erişim kontrolü ve KVKK'yı en baştan indekse gömün ve her cevabı kaynağa dayandırın. Bu sırayı izlerseniz, belgelerinizin gerçekten taşıdığı bilgiyi — tablolar, grafikler ve düzen dahil — nihayet aranabilir hale getirmiş olursunuz. Ve unutmayın: buradaki gerçek kazanç sadece daha iyi arama değil; yıllardır arşivde uyuyan, kimsenin ulaşamadığı görsel bilginin ilk kez erişilebilir olması. Çoğu kurumda multimodal RAG'ın en büyük getirisi, "zaten bildiğimizi sandığımız ama aslında kilitli kalmış" bilgiyi açığa çıkarmasıdır.