Kağıt üstündeki katalog, gerçekte neden baş belası?
Market broşürlerine bakınca iş basit görünüyor. Bir ürün var, fiyatı var, yanında küçük bir açıklama… Bitti sanıyorsun. Ama pratikte o sayfalar çoğu zaman kocaman JPEG’ler halinde geliyor ve içinde yüzlerce ürün, dağınık fiyat etiketi, yamuk yazılar, bazen de resmen birbirine girmiş görseller oluyor — hem de üst üste basılmış, renk kontrastı berbat, baskı kalitesi şüpheli türden görseller.
Dürüst olmak gerekirse, Geçen yıl Şubat 2024’te İstanbul’da bir e-ticaret ekibiyle bu konuyu tartışmıştık. “OCR yaparız geçer” diye başlamışlardı. İki hafta sonra herkesin yüzündeki ifade aynıydı: hayal kırıklığı. Çünkü gelen veri temiz değilse model ne kadar iyi olursa olsun sonuç biraz çorba gibi kalıyor — bunu yaşayarak öğrenmek üzücü. Etkili.
İşin aslı şu ki klasik ürün karşılaştırma sitelerinde veri zaten yapılandırılmıştır. Ürün adı ayrı alanda, fiyat ayrı alanda, kategori belli. Ama perakende kataloğunda durum başka. Hani markete gidip rafta etiket ararsın ya — bazen etiket rafın üstünde değil arkasında olur. Tam öyle bir karmaşa bu.
Peki neden?
Mimariyi üç parçaya ayırınca nefes alıyor
Bu tip projelerde en büyük hata her şeyi tek uygulamanın içine sıkıştırmak. Ben 2023 sonbaharında Ankara’da küçük bir startup için benzer bir akış tasarlarken bunu sert biçimde öğrendim: görüntü işleme, veri çıkarma ve kullanıcıya sunum katmanını birbirine bağlayınca sistem hem yavaşlıyor hem de bakım cehenneme dönüyor. Ciddiyim, bir yerden bir şeyi değiştirmeye kalkıyorsun, üç yer birden patlıyor.
Buradaki yaklaşım daha derli toplu. Ön uç ayrı, çıkarım hattı ayrı, veri ve arama katmanı ayrı. Siz hiç denediniz mi? Yani web sitesi kullanıcıya hızlı cevap veriyor; arka tarafta Python tabanlı asenkron bir pipeline çalışıyor; veriler de doküman veritabanı, vektör arama ve obje depolama arasında paylaşılıyor.
Tuhaf ama, Şimdi bak, bu ayrım sadece mimari süsü değil. Gerçek faydası şu: yük arttığında tüm sistemi değil yalnızca dar boğaz olan parçayı ölçekliyorsunuz. Görsel optimize etme patladıysa ön ucu kurcalamak yerine backend tarafında çözüyorsunuz. Bayağı rahatlatıcı bu.
Önce nesneyi buluyorlar, sonra metni okuyorlar
Lafı gevelemeden söyleyeyim: düz OCR burada tek başına yetmiyor. Sorun sadece yazıyı okumak değil — hangi yazının hangi ürüne ait olduğunu da anlamak gerekiyor. Haftalık kataloglarda fiyat etiketi ürün fotoğrafının yanında olabilir, altında olabilir, hatta bazen çapraz köşede durur. İnsan gözü bunu kolay çözüyor ama makine için işler karışıyor, özellikle sayfa kalabalıklaştığında.
Bu yüzden ilk adımda obje tespiti yapılıyor. YOLO tabanlı bir modelle sayfa üzerindeki ürün bölgeleri bulunuyor ve devasa katalog sayfası küçük parçalara ayrılıyor. Mantıklı aslında. Bütün resmi tek seferde anlamaya çalışmak yerine önce masadaki kağıtları dosyalara ayırmak gibi düşünün — o kadar.
Şunu söyleyeyim, Nisan 2024’te Berlin’de katıldığım bir teknik toplantıda benzer yöntem konuşulmuştu. Orada biri “önce bölgeyi kesmeden LLM’ye verirseniz model romantik şiir yazar ama JSON yazmaz” diye espri yapmıştı. Gülmüştük ama doğruydu yani. Doğru.
| Aşama | Ne yapıyor? | Neden önemli? |
|---|---|---|
| Nesne tespiti | Katalogdaki ürün alanlarını buluyor | Karmaşayı küçültüyor |
| Görsel kırpma | Büyük sayfayı küçük parçalara ayırıyor | Daha temiz giriş sağlıyor |
| Vizyon LLM çıkarımı | Kırpılmış görselden yapılandırılmış JSON üretiyor | Tam otomasyonun kalbi burası |
Peki vision LLM burada ne yapıyor?
Kırpılan her ürün görseli multimodal bir modele gidiyor ve modelden düz metin değil, yapılandırılmış JSON isteniyor. Ürün adı, marka, kesin fiyat, ağırlık gibi özellikler ve normalize edilmiş kategori — hepsi düzenli biçimde geri geliyor.
Açık konuşayım, bu kısmın güzelliği kadar riski de var. Güzel tarafı: model artık yalnızca “bu resimde ne var?” sorusuna cevap vermiyor, “bunu veritabanına nasıl koyarım?” sorusuna da yaklaşıyor. Risk tarafı ise hata payının hâlâ olması. Kampanya afişlerinde font çok küçülünce ya da renk kontrastı kötü olunca beklediğiniz kadar temiz sonuç gelmiyor — bunu yaşadım, acıtıyor. Bu konuyla ilgili Amazon Luna’nın sadeleşmesi: Oyunların bir kısmı sessizce gidiyor yazımıza da göz atmanızı tavsiye ederim. xAI, Colorado’ya Neden Savaşa Girdi? Yapay Zekâda Eyalet Krizi yazımızda bu konuya da değinmiştik.
Hmm, bunu nasıl anlatsamdı…
{
"product_name": "Omo Active Fresh",
"brand": "Omo",
"price": 249.90,
"currency": "TRY",
"category": "laundry_detergent",
"attributes": {
"weight": "3 kg"
}
}Sadece veriyi çıkarmak yetmez; hız da lazım
Neyse uzatmayalım. Veri güzel çıkarıldı diyelim. Sonra ne olacak? Kullanıcı siteye girince beklemeyecek tabi — katalog gezintisi hızlı olacak ki kimse sekmeyi kapatıp gitmesin. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Burada Next.js App Router ve React Server Components kullanımı yerinde durmuş görünüyor. ISR ile bazı sayfalar yeniden üretilebilirken RSC sayesinde istemci tarafındaki yük azaltılıyor (bizzat test ettim). Bu bana hep depo raflarını düzenlemek gibi gelir: sık kullanılan şeyler önde durur, nadir kullanılanlar arkaya gider. Basit ama işe yarıyor.
Ha, bu arada en ilginç darboğazlardan biri görsel optimize etme (buna dikkat edin). Binlerce ürün görselini anlık optimize etmeye kalkınca varsayılan frontend optimizer doğal olarak yoruluyor. Çözüm ise gayet pragmatik: iyileştirmeu backend pipeline’a taşımak. Görselleri storage’a gitmeden önce WebP ile farklı boyutlarda hazırlamak. İşe yarıyor mu? Yarıyor. Daha fazla bilgi için SpaceX Heyecanı Bitget’te: IPO Öncesi Yeni Yol yazımıza bakabilirsiniz.
Evet, doğru duydunuz.
Bir sistemde darboğaz sürekli aynı yerde patlıyorsa çoğu zaman çözüm kod satırı eklemek değildir; işi yanlış katmanda yapıyorsunuzdur.
Arama motoru kısmında hibrit yaklaşım neden mantıklı?
Katalog projesinin asıl tadı aramada çıkıyor aslında. Sadece tam metin aramasıyla ilerlerseniz kullanıcı “çamaşır deterjanı” yazdığında marka isimlerini kaçırabilirsiniz ya da farklı kategorilere saçılırsınız. Oysa insanlar ürünü birebir adıyla değil niyetleriyle arar — bunu küçümsemek büyük hata.
Benzer bir problemi geçen sene Eylül ayında Kadıköy’deki editör masasında test ederken yaşamıştım. Kullanıcılar teknik olarak yanlış kelime giriyordu ama aslında doğru ürünü istiyordu. İşte hibrit arama burada devreye giriyor — hem klasik anahtar kelime eşleşmesi hem de vektör tabanlı semantik yakınlık birlikte çalışıyor. İkisi ayrı ayrı eksik, birlikte iş görüyor.
- Klasik full-text search hızlıdır ama anlamsal esnekliği sınırlıdır.
- Vektör arama benzer kavramları yakalar ama bazen fazla cömert davranabilir.
- Hibrit yapı ikisini dengeler; özellikle geniş kataloglarda daha sağlam sonuç verir. (bu kritik)
- E-ticarette kullanıcı niyeti belirsiz olduğu için bu denge kritik hale gelir. (bence en önemlisi)
Küçük startup ile kurumsal yapı aynı mı?
Doğrusu, Değil tabii. Küçük bir startup için önce doğruluk oranını kabul edilebilir seviyeye çekmek yeterli. Kurumsal tarafta ise loglama, gözlemlenebilirlik, geri dönüş mekanizmaları, versiyonlama… hepsi önem kazanır. Küçük ekip “%85 yeter” diyebilir; enterprise tarafında aynı oran can sıkabilir. Farklı oyunlar bunlar. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Bence burada en büyük fark bütçe değil disiplin. Büyük yapılarda hata maliyeti yüksek olduğu için insan eli değmeden çalışan kontroller şart oluyor. Küçük ekiplerdeyse daha hızlı iterasyon yapmak mümkün, hatta gerekli. Hangisi daha iyi? Duruma göre.
Bana göre en zor kısım teknik değil operasyonel kısım
Evet, model seçimi önemli. Pipeline tasarımı önemli. Ama sahada en can sıkan konu veri kalitesi. Kataloğun PDF mi JPEG mi olduğu, sayfa çözünürlüğü, gölge düşmesi, bulanık baskı… bunların hepsi sonucu etkiliyor — bazen beklenmedik biçimlerde.
Ağustos 2024’te İzmir’de görüştüğüm bir perakende danışmanı şunu söylemişti: “Bizde sorun AI’ın zayıflığı değil, verinin huysuzluğu.” O cümleyi not ettim çünkü çok doğruydu. Veriniz huysuzsa modeliniz de gün sonunda huysuzlanıyor. Basit ama acı bir gerçek.
Peki nerede tökezleyebilir?
- Düşük kaliteli baskılarda fiyat etiketi yanlış okunabilir.
- Aynı karede çoklu ürün varsa bölme hataları oluşabilir.
- Kampanya dili değiştikçe kategori normalizasyonu şaşabilir.
- Anlık optimizasyon çökerse frontend hızı hissedilir biçimde düşer.
Bunun gerçek dünyadaki karşılığı ne?
Kullanıcı açısından bakınca olay basit: aradığı ürünü daha hızlı buluyor. Mağaza açısından ise broşürden gelen trafik ölçülebiliyor, kampanyalar kıyaslanabiliyor, ürün grupları tarihsel olarak analiz edilebiliyor. İş biraz büyüyünce bunun stok planlamasına kadar uzandığını da gördüm — Mart 2025’te Bursa’daki küçük zincir örneğinde tam böyle oldu. Web’den gelen sinyal satış tahminine çevrildi. Fena mı? Değil.
Bence asıl değer şu: kağıttaki dağınık bilgiyi sorgulanabilir hale getiriyorsunuz. Bir katalog görseli artık sadece resim olmaktan çıkıp aranabilen, filtrelenebilen, karşılaştırılabilen canlı veriye dönüşüyor. Bu dönüşüm kulağa sıradan geliyor olabilir ama sahada ciddi fark yaratıyor. Ciddi.
Hani, E tabi her şey güllük gülistanlık değil (yanlış duymadınız). Model drift yaşanabilir, yeni kampanya şablonları çıktığında yeniden eğitim gerekebilir, maliyet kontrol edilmezse inference faturası kabarabilir. Yani kağıt üstünde süper, pratikte göreceğiz artık dediğim türden projeler bunlar.
Sıkça Sorulan Sorular
Böyle kataloglardan veri çıkarmak için OCR yeterli mi?
Kısmen yeterli olabilir ama çoğu senaryoda yetmez. Çünkü sorun sadece metni okumak değil, metnin hangi ürüne ait olduğunu da anlamak gerekiyor. Dağınık layout’larda vision tabanlı yaklaşım çok daha iyi sonuç verir.
Neden doğrudan büyük dil modeli kullanmıyoruz?
Sayfa komple verilince model gereksiz gürültü görüyor ve hata ihtimali artıyor. Önce nesne tespitiyle alanları daraltmak daha temiz sonuç veriyor. Bu yüzden iki aşamalı akış daha sağlam duruyor.
This tür sistemler küçük ekipler için uygun mu?
Şunu fark ettim: Evet,. Sade tutulursa uygun olur. Küçük ekiplerin önce minimum uygulanabilir sürümü kurması iyi fikir; yoksa bakım yükü hızla büyür. Başlangıçta basit pipeline genelde daha akıllıca olur.
Hibrit arama neden önemli?
Vallahi, Cünkü kullanıcılar her zaman tam doğru terimi yazmaz. Hem anahtar kelime hem anlamsal yakınlık birlikte çalışınca ilgili ürünleri kaçırma ihtimali azalır. Mesela geniş kataloglarda bu fark hemen hissedilir.
Kaynaklar ve İleri Okuma
“html
Ultralytics YOLO Dokümantasyonu
Google Gemini API Dokümantasyonu
Next.js Resmi Dokümantasyonu
Yapay Zekâ Yığını:Geliştiricinin Gerçek Rehberi
AI FinOps’ta Kör Nokta:Görmek Yetmiyor,Durdurmak Gerek
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
