Ürün Eşleştirme Motorunun İç Yüzü: Milyonlarca SKU'yu Barkodsuz Eşleştiren Mimari

Blocking’den embedding tabanlı benzerliğe, LLM destekli karardan insan onayına — Senkrondata’nın ürün eşleştirme motorunun teknik mimarisi.

Rakip fiyat izlemenin en zor problemi ekranda görünmez: rakibin sitesindeki bir listeleme, sizin kataloğunuzdaki hangi SKU'ya karşılık geliyor? Barkod her zaman yoktur, isimler her sitede farklı yazılır, aynı ürün üç farklı paket boyutunda satılır. Bu, akademik literatürde entity resolution (varlık çözümleme) diye bilinen klasik ve zor bir problemin perakendeye özel halidir.

Bu yazı, ürün eşleştirmenin neden bu kadar kritik olduğunu anlattığımız girişin teknik devamı. Burada "ne" yerine "nasıl"a — motorun altındaki mimariye — bakıyoruz.

Problemin ölçeği neden naif çözümleri öldürür

Yüzlerce satış kanalı, milyonlarca ürün. İki katalog arasında "her ürünü her ürünle karşılaştır" yaklaşımı O(n×m) karmaşıklığındadır — bir tarafta 1 milyon, diğerinde 1 milyon ürün varsa bu 10¹² karşılaştırma demektir. Bunu her gün tekrar etmek fiziksel olarak imkânsızdır.

Bu yüzden eşleştirme motoru tek bir algoritma değil, bir huni (funnel) olarak kurulur: her aşama ucuz ve toleranslı başlar, aday havuzunu agresifçe küçültür; pahalı ve isabetli karar en sona, yani en küçük havuza saklanır. Huninin ekonomisi şudur: ucuz elemeyi ne kadar erken yaparsanız, pahalı katmana o kadar az iş düşer.

Aşama 1 — Aday üretimi (blocking)

O(n×m) patlamasını önlemenin yolu, her ürün için yalnızca "makul adaylar"ı değerlendirmektir. Bu tekniğe blocking denir: her ürüne, onu kabaca tanımlayan bir veya birkaç blok anahtarı (blocking key) atanır — örneğin normalize edilmiş marka + kategori + baş harfler, ya da isimden çıkarılan karakteristik token'lar. Yalnızca aynı bloğa düşen ürünler birbiriyle karşılaştırılır.

İyi bir blok anahtarı iki şeyi dengeler:

• Recall: gerçek eşleşmeler aynı bloğa düşmeli (yoksa asla karşılaşmazlar).
• Kesme oranı: blok yeterince küçük olmalı (yoksa eleme işe yaramaz).

Pratikte tek bir anahtar yetmez; birden fazla blok şeması paralel çalışır (örneğin biri markaya, biri barkod ön ekine, biri isim token'larına dayalı) ve sonuçlar birleştirilir. Bu, tek bir anahtardaki gürültüye karşı dayanıklılık sağlar.

Aşama 2 — Kesin kimlik (deterministik eşleştirme)

Blok içinde önce en ucuz ve en güvenli sinyale bakılır: benzersiz tanımlayıcı. Barkod/GTIN her iki tarafta da mevcut ve tutarlıysa, eşleştirme bir lookup'a döner — belirsizlik neredeyse sıfırdır.

Ama üretimde bu ideal durum sık sık bozulur: barkod eksik, kaynakta yanlış girilmiş, ya da tekstil/moda gibi varyant-yoğun kategorilerde hiç standartlaşmamış olabilir. Bir barkod tek başına da yanıltıcı olabilir — aynı GTIN bazen farklı ambalaj/parti için tekrar kullanılır. Bu yüzden kesin kimlik "varsa harika" katmanıdır, ama üstüne bir doğrulama refleksi konur: barkod eşleşse bile isim/marka tamamen çelişiyorsa, eşleşme şüpheli işaretlenir.

Aşama 3 — Olasılıksal benzerlik (leksik + semantik)

Kesin kimlik yoksa iş, benzerlik puanlamasına düşer. Burada iki tür sinyal birleştirilir:

• Leksik benzerlik: token-tabanlı ölçütler (Jaccard, TF-IDF ağırlıklı kosinüs, Levenshtein/edit distance). Bunlar "Erkek Spor Ayakkabı Beyaz 42" ile "Spor Ayakkabı - Beyaz/42" gibi yüzeysel varyasyonları yakalamada iyidir ama eşanlamlıları ("sneaker" vs "spor ayakkabı") kaçırır.
• Semantik benzerlik: ürün isim/açıklamasını bir embedding vektörüne çevirip vektör uzayında yakınlık (kosinüs benzerliği) ölçmek. Bu, farklı kelimelerle yazılmış aynı anlamı yakalar. Ölçekte bu, bir yaklaşık en yakın komşu (ANN) indeksiyle hızlandırılır.

İki sinyal ağırlıklı bir skorda birleştirilir. Kritik detay: bu aşama kasıtlı olarak toleranslıdır. Amacı kesin karar vermek değil, aday havuzunu "muhtemelen aynı" olan bir avuç ürüne indirmektir. Eşik burada gevşek tutulur; ince karar bir sonraki, daha pahalı katmana bırakılır.

Aşama 4 — Bağlamsal karar (LLM-as-a-judge, hard-constraint'lerle)

Daraltılmış aday havuzu — artık her ürün için belki 1-5 aday — insan muhakemesine en çok yaklaşan katmana devredilir. Burada bir dil modeli, iki listelemenin gerçekten aynı ürün olup olmadığına bağlamı değerlendirerek karar verir. Kritik olan, modeli serbest bırakmamaktır; karar birkaç hard constraint ile çerçevelenir:

• Varyant eşitliği zorunlu: paket adedi (3'lü ≠ tekli), hacim/gramaj, beden, renk, cinsiyet — bunlar "yakın" değil, farklı üründür. Herhangi biri çelişiyorsa eşleşme reddedilir, skoru ne olursa olsun.
• Kanıt zorunluluğu: model kararını, karşılaştırdığı özniteliklere dayandırmak zorundadır; "sadece isim benziyor" yeterli değildir.
• Belirsizlikte ret: model emin değilse, "eşleşme yok" güvenli varsayılan karardır (bkz. aşağıda precision-recall tercihi).

Huni ekonomisi tam burada işe yarar: pahalı LLM kararı yalnızca aday başına birkaç kez, yani toplam iş yükünün minik bir kesitinde çalışır — çünkü önceki aşamalar milyonlarca gereksiz karşılaştırmayı zaten elemiştir.

Aşama 5 — İnsan onayı (human-in-the-loop)

Otomasyonun güvenle karar veremediği düşük-güvenli eşleşmeler ve özellikle kritik ürünler, bir uzman kuyruğuna düşer. Bu bir "yedek" değil, sistemin kalibrasyon mekanizmasıdır: uzman kararları aynı zamanda eşiklerin ve kuralların zamanla iyileştirilmesi için geri besleme verisidir. Her manuel karar, gelecekteki otomatik kararları biraz daha isabetli yapar.

Tasarım ilkeleri: motoru güvenilir kılan tercihler

• Precision > Recall. Yanlış pozitif (yanlış eşleşme) sessizce yanlış fiyat kararına dönüşür ve fark edilmesi zordur; yanlış negatif (kaçırılan eşleşme) ise görünür bir boşluktur ve sonradan kapatılabilir. Bu yüzden şüphede eşleşmemek tercih edilir. Motoru precision'a göre kalibre ederiz.
• Her eşleşmenin bir provenance'ı vardır. Bir eşleşmenin hangi katmandan (deterministik / olasılıksal / LLM / manuel) geldiği ve hangi güven skoruyla kurulduğu kayıt altındadır. "Bu eşleşme neye dayanıyordu?" sorusu her zaman cevaplanabilir — bu, hem denetlenebilirlik hem hata ayıklama için şarttır.
• Eşleşme durağan değildir. Kataloglar değişir, rakip siteler ürün sayfalarını yeniden yapılandırır, yeni ürünler eklenir. Eşleştirme sürekli yeniden çalışan bir süreçtir; bir eşleşme "çürüyebilir" ve yeniden doğrulanması gerekir.

Ölçek ve okuma katmanının ayrılması

Milyonlarca eşleşme üzerinde her gün fiyat karşılaştırma raporu üretmek, işlemsel veritabanını (crawler'ların sürekli yazdığı yer) doğrudan sorgulamayla mümkün değildir — raporlama yükü yazma yükünü boğar. Bu yüzden eşleşme ve fiyat verisi, raporlama için ayrı bir analitik depoya (kolon-tabanlı, deduplikasyon dostu bir motor) mirror'lanır. Böylece ağır analitik sorgular, canlı veri toplama akışını yavaşlatmadan, taze ve hızlı kalır. (Bu ayrımı ayrı bir yazıda daha derin işliyoruz.)

Sonuç

Ürün eşleştirme "bir algoritma" değil, bir huni mimarisidir: blocking ile aday üret, deterministik kimlikle kolay olanı çöz, olasılıksal benzerlikle daralt, LLM ile bağlamı değerlendir, insanla belirsizi kapat — ve her aşamada precision'ı recall'a tercih et, her kararı izlenebilir tut. Rakip fiyat verinizin güvenilirliği, ekranda görmediğiniz bu katmanların kalitesine bağlıdır.

Eşleştirme motorunuzun bu titizlikte kurulmasını istiyorsanız, Senkrondata ekibiyle konuşun.