CSS-selektörlerine dayalı parsel, site tasarımını değiştirdiğinde bozulur. LLM tabanlı parsel bozulmaz, ancak her sayfa için ücret talep eder. 2026 yılında aralarındaki seçim bir zevk meselesi olmaktan çıktı: modellerin fiyatları onlarca kat farklılaştı ve aynı sayfa, modele ne gönderdiğinize bağlı olarak 3.000 veya 20.000 token tutabilir. Aşağıda, 1.000 ve 1.000.000 sayfa için maliyet, güvenilirlik ve proxy trafiği açısından üç yaklaşımın karşılaştırması bulunmaktadır.
Kısaca: neyi seçmeli
- Seçiciler (CSS/XPath) — tek sayfa şablonu, büyük hacimler, stabil tasarım. Veri çıkarım maliyeti sıfıra yakındır, ancak destek geliştiriciye düşer.
- LLM-çıkarma — birçok farklı site, kararsız tasarım, tek seferlik görevler. Her sayfa için token ödersiniz ve yanıtı doğrulamak zorundasınız.
- Hibrit — LLM bir kez seçicileri yazar, daha sonra seçiciler çalışır ve veri kontrolü düştüğünde model çağrılır. Çoğu sürekli parsel için bu en iyi seçenektir.
Karşılaştırma kriterleri
Sonuç hesaplarını ve veri kalitesini gerçekten etkileyen beş noktayı karşılaştırıyoruz:
- 1.000 sayfa başına çıkarım maliyeti;
- tasarım değiştiğinde davranış;
- uydurulmuş değerlerin doğruluğu ve riski;
- hız ve gecikme;
- proxy trafiği tüketimi — göreceğiniz gibi, yöntem seçimine bağlı olarak neredeyse değişmez.
LLM-çıkarım maliyeti: Ekim 2026 fiyatlarına göre hesaplayalım
Standart tarifede milyon token (giriş/çıkış) için resmi fiyatlar:
- Gemini 2.5 Flash-Lite — $0,10 / $0,40;
- Gemini 3.1 Flash-Lite — $0,25 / $1,50;
- Claude Haiku 4.5 — $1 / $5;
- Gemini 3.5 Flash — $1,50 / $9.
Google ve Anthropic'in, yanıtın anında gerekli olmadığı parselleme için giriş ve çıkışta %50 indirimli Batch API'si bulunmaktadır; bu, tasarrufun ilk aracıdır.
Ana değişken — model değil, ona gönderdiğiniz şey
Modelde iletilen ham HTML sayfası genellikle 10.000–40.000 token alır. Cloudflare, Ajanslar için Markdown işlevini başlatırken bir örnek verdi: aynı blog kaydı HTML'de 16.180 token, Markdown'da 3.150 token — %80 azalma. Diğer haberler, belgeler ve ürün kartları üzerindeki ölçümler %67 ile %94 arasında bir azalma sağlıyor.
Hesaplama için varsayımlar alalım: ham sayfa — 20.000 token, Markdown'a temizlenmiş — 3.000, talimat ve şemaya 500 token, çıkışta 300 token JSON. 1.000 sayfa için elde ediyoruz:
| Model | Ham HTML (20,5 milyon giriş) | Markdown (3,5 milyon giriş) |
|---|---|---|
| Gemini 2.5 Flash-Lite | ≈ $2,17 | ≈ $0,47 |
| Gemini 3.1 Flash-Lite | ≈ $5,58 | ≈ $1,33 |
| Claude Haiku 4.5 | ≈ $22,00 | ≈ $5,00 |
| Gemini 3.5 Flash | ≈ $33,45 | ≈ $7,95 |
Fark, en kötü ve en iyi seçenek arasında 70 kat. Bu farkın üçte ikisi, model seçimi değil, girişin temizlenmesinden kaynaklanıyor. Aylık bir milyon sayfa için bu ya yaklaşık $470 ya da $33.000'den fazla.
Bir diğer detay: Claude modelleri 4.7 versiyonundan itibaren, Anthropic'in verilerine göre, aynı metin için yaklaşık %30 daha fazla token sağlayan yeni bir tokenleştirici kullanıyor. Farklı nesil modellerin hesaplarını karşılaştırırken bunu dikkate alın — Haiku 4.5 eski tokenleştiricide çalışıyor.
Seçiciler: neredeyse bedava, site değişmediği sürece
İndirilmiş bir sayfada CSS veya XPath seçicisinin çalıştırılması, işlemci için milisaniyenin bir kısmını alır. ScrapingBee kılavuzunda bu değerlendirme şöyle: stabil bir tasarımda, normal bir seçici genellikle LLM-çıkarma işleminden yaklaşık 10 kat daha ucuz ve hızlıdır. Pratikte fark daha da fazladır çünkü seçicinin model API'sine bir ağ isteği yoktur.
Seçicilerin maliyeti — destekle ilgilidir:
- site bir sınıfı yeniden adlandırdı veya bir bloğu yeni bir div'e sardı — parsel sessizce boş alanlar verir;
- A/B testleri farklı şablonları farklı ziyaretçilere gösterir ve bazı sayfalar parsellenmez;
- 50 farklı sitede 50 set seçici destekliyorsunuz.
En tehlikeli senaryo — düşüş değil, verilerin sessizce bozulmasıdır: seçici, yanındaki öğeyi yakalar ve veritabanına haftalarca eski fiyatı yazar.
LLM: tasarıma dayanıklı, ama uydurmayı biliyor
Modellerin bir öğeye kesin bir yolu gerekmez — "fiyatı" anlamına göre arar. Bu, yeniden adlandırılmış sınıflar ve farklı şablonlar sorununu ortadan kaldırır. Ancak, üretim ortamında bu tür parsel çalıştıran herkesin tanımladığı üç tipik hata ortaya çıkar:
- uydurulmuş değerler — model, sayfada olmayan bir fiyat veya ürün kodunu "tahmin eder";
- atlanan alanlar — bazı veriler çıkarılmamıştır;
- yapı kayması — sayı yerine dize, farklı anahtar adı.
Koruma zorunludur: katı bir yanıt şeması, doğrulama (örneğin, Pydantic), sıcaklık = 0 ve hata durumunda tekrar. Sıfır sıcaklık, dağılımı azaltır, ancak halüsinasyonları tamamen ortadan kaldırmaz. Fiyatlar ve stoklar için, "değerin sayfa metninde gerçekten bulunup bulunmadığını" kontrol etmek mantıklıdır.
Gecikme de daha yüksektir: proxy üzerinden sayfa yükleme süresine model yanıtı eklenir — bir kaç milisaniyeden birkaç saniyeye kadar. Günde bir kez izleme için bu önemli değildir, düşüşleri takip etmek için kritiktir.
Hibrit: LLM seçicileri yazar, verileri çıkarmaz
Üçüncü yol, popüler kütüphaneler tarafından doğrudan desteklenmektedir. Crawl4AI'de, model bir kez HTML örneklerine bakar ve bir dizi CSS/XPath seçici döndürür; daha sonra çıkarım, LLM çağrıları olmadan devam eder. Belgelerde, bunun bir defalık maliyet olduğu ve şemanın sınırsız bir şekilde yeniden kullanılabileceği vurgulanmaktadır; birkaç örnekte model genellikle, kırılgan pozisyonel olanlar yerine, niteliklere göre daha dayanıklı seçiciler seçer.
Hibritin çalışma şeması:
- LLM, tek bir şablondaki 3-5 sayfa örneğine göre seçiciler üretir.
- Parsel, seçiciler üzerinde çalışır, her kaydı doğrulayıcı kontrol eder: alanlar yerinde, türler doğru, fiyat makul bir aralıkta.
- Eğer geçersiz kayıtların oranı eşiği (örneğin, %2-5) aşarsa, sayfa LLM-çıkarma işlemine geçer ve şema yeniden oluşturulmaya gider.
- Yeni şema kontrol örneği üzerinde test edilir ve ancak o zaman eski şemanın yerini alır.
Böylece, modeli yalnızca tasarım değiştiğinde ödemiş olursunuz, her bir milyon sayfa için değil.
Özet tablo
| Kriter | Seçiciler | LLM-çıkarma | Hibrit |
|---|---|---|---|
| Çıkarma maliyeti | sıfıra yakın | $0,5–33 1.000 sayfa için. | sıfıra yakın + tek seferlik çağrılar |
| Tasarım değişikliği | bozulur, çoğu zaman sessizce | genellikle dayanır | otomatik olarak düzeltilir |
| Uydurulmuş veri riski | yok (ama "yanlış öğe" var) | var, doğrulama gerekir | minimum |
| Hız | maksimum | + her sayfada model yanıtı | seçicilerle aynı |
| Birçok farklı site | destekle pahalı | güçlü yön | iyi, her şablon için şema |
| Proxy trafiği | aynı — model indirilen baytları azaltmaz | ||
Proxy hakkında: LLM trafik tasarrufu sağlamaz
Hesaplamalardaki yaygın bir hata, "akıllı" parselin ağda daha ucuz olduğunu düşünmektir. Hayır: HTML'nin Markdown'a dönüştürülmesi, indirme işleminden sonra gerçekleşir, bu nedenle her çıkarım yöntemiyle proxy üzerinden tam sayfa geçer. İstisna, sahibi tarafından Accept: text/markdown başlığı ile Markdown çıktısı verilmiş sitelerdir (Cloudflare işlevinde olduğu gibi), ancak bu site çözümüdür, sizin değil.
Ölçek için: HTML boyutu 200 KB olan 1.000 sayfa — yaklaşık 0,2 GB veya yaklaşık $0,54'tür rezidans proxy'leri için GB başına $2,70. Yukarıdaki tabloyla karşılaştırın: Claude Haiku 4.5'e ham HTML gönderdiğinizde model için fatura, proxy faturasının 40 katı olacaktır, ancak Markdown ve Flash-Lite ile karşılaştırılabilir. Sayfaları headless tarayıcı ile render ediyorsanız, trafik katlanarak artacaktır — ölçümlerimizi Playwright, Puppeteer ve requests ile 1.000 sayfa için trafik tüketimi karşılaştırmasında bulabilirsiniz.
Herhangi bir yöntemle trafik üzerinde gerçekten etkili olan şeyler:
- gerekmedikçe resimleri, fontları ve analitiği indirmemek;
- HTML yerine iç JSON API'sini aramak;
- gereksiz tekrarlar yapmamak: her yasak ve yeniden deneme — bu ödenen baytlardır. GB başına fiyatın neden yanıltıcı olduğunu daha fazla bilgi için başarılı bir kaydın gerçek maliyeti incelemesine bakın.
Katı anti-bot koruması olmayan basit kataloglar için veri merkezi proxy'leri GB başına $1,50 yeterlidir; rezidans proxy'leri, IP barındırma girişte kesildiğinde gereklidir.
Senaryolar için öneriler
- Bir ila üç pazar yerinin fiyatlarını izleme, yüz binlerce kart. Hibrit veya doğrulayıcı ile temiz seçiciler. LLM'yi yalnızca şemanın yeniden oluşturulması için bağlayın.
- Yüzlerce farklı siteden veri toplama (liderler, iş ilanları, iletişimler). Ucuz bir model üzerinden Markdown ile LLM-çıkarma. Katı bir şema ve doğrulama olmadan başlatmayın.
- Tek seferlik araştırma için birkaç bin sayfa. LLM: birkaç dolarla seçicileri yazmak için günleri tasarruf edersiniz.
- Hata maliyetli veriler (yeniden fiyatlandırma için fiyatlar, stoklar). Seçiciler veya hibrit artı değerin sayfa metni ile karşılaştırılması.
- RAG ve bilgi tabanları. Burada yapı değil, temiz metin gereklidir: alan çıkarımı olmadan Markdown'a dönüştürme, model yalnızca yanıt aşamasında.
Sonuç
LLM-çıkarma, seçicilerin yerini almadı, ancak seçim noktasını kaydırdı. En ucuz olanı — hibrit: model seçicileri yazar ve onarıp, her sayfayı okumaz. Eğer her sayfada model olmadan geçemiyorsanız, önce girişi Markdown'a temizleyin ve batch kullanın: bu iki adım, model seçmeye başlamadan önce faturayı 5-10 kat azaltır. Ve unutmayın, proxy trafiği çıkarım yönteminden bağımsızdır: onu indirdiğiniz şeylerde tasarruf etmelisiniz, nasıl çözdüğünüzde değil.