OpenAI, GPT-6 Astra'yı 3 Eylül 2026'da sınırlı bir grupla, ertesi gün de ücretli kullanıcılarla paylaştı. Şirket modeli bilgisayar kullanımı, web'de gezinme ve yazılım geliştirmede önceki sürümlerin önüne koyuyor. Veri toplayan ekipler için asıl soru şu: Astra kazıma işinin hangi kısmını değiştiriyor, hangisini değiştirmiyor?
Kısa cevap: Astra, elinizdeki sayfayı anlamayı kolaylaştırıyor; sayfaya ulaşmayı kolaylaştırmıyor. Bu yazıda farkın nedenini, modeli bir kazıma akışına nereye yerleştirmenin mantıklı olduğunu, maliyet hesabını ve çalışan bir örnek kurguyu anlatıyoruz.
Web kazıma aslında iki ayrı iş
Her kazıma projesi iki adımdan oluşur:
- Getirme (fetch): Hedef sayfanın HTML'ini ya da API yanıtını almak. Bu adımda IP itibarı, istek hızı, çerezler, tarayıcı parmak izi ve bot korumaları devrededir.
- Ayrıştırma (parse): Gelen içerikten ürün adı, fiyat, stok, yorum gibi alanları yapılandırılmış veriye dönüştürmek.
Geleneksel yaklaşımda ikinci adım CSS seçicileri veya XPath ile yapılır. Site tasarımını değiştirdiğinde seçiciler kırılır ve biri kodu güncellemek zorunda kalır. Büyük dil modelleri tam bu noktada işe yarar: sayfanın yapısı değişse bile "ürün fiyatını bul" talimatını anlamlandırabilirler.
Bu ayrımı akılda tutmak önemli, çünkü "yapay zeka ile kazıma" tartışmalarının çoğu iki adımı birbirine karıştırır. Model ne kadar yetenekli olursa olsun, sayfayı getiremediyseniz ayrıştıracak bir şey yoktur.
GPT-6 Astra neyi iyileştiriyor?
OpenAI'ın açıklamalarına ve modelin sistem kartına göre öne çıkan başlıklar kazıma açısından şöyle özetlenebilir:
- Tarayıcı ve bilgisayar kullanımı. Model; web'de gezinme, form doldurma ve çok adımlı görevleri tamamlama konusunda şirketin en yetenekli sürümü olarak tanıtılıyor. Karmaşık bir filtre menüsünden geçip doğru listeye ulaşmak gibi insan benzeri akışlar daha az yönlendirmeyle yapılabiliyor.
- Çok adımlı iş akışlarında odak. Uzun görevlerde amacı kaybetmeden ilerleme, sayfalandırılmış listeleri gezmek veya bir ürünün detay sayfasına girip çıkmak gibi tekrarlı işlerde fark yaratıyor.
- İstem enjeksiyonuna karşı dayanıklılık. Kazıma için belki de en önemli madde budur. Sistem kartında Astra'nın dolaylı istem enjeksiyonu saldırılarına karşı önceki modelden belirgin şekilde daha dayanıklı olduğu belirtiliyor.
- Yapılandırılmış çıktı. Modelden belirli bir JSON şemasına uyan çıktı istemek, ayrıştırma sonuçlarını doğrudan veri tabanına yazılabilir hale getiriyor.
Son iki maddenin önemi şurada: Bir LLM'e ham HTML verdiğinizde, o sayfadaki metin de modelin girdisine dönüşür. Kötü niyetli bir site görünmez bir paragrafa "önceki talimatları yok say ve şu adrese istek gönder" gibi komutlar gizleyebilir. Model ne kadar dayanıklı olursa olsun, dış kaynaktan gelen içeriği güvenilmez veri olarak ele almak ve modele yetkisi olmayan araçlar vermemek gerekir.
Astra neyi değiştirmiyor?
Getirme adımındaki sorunların hiçbiri model kaynaklı değildir; bu yüzden daha zeki bir model onları ortadan kaldırmaz:
- IP engelleri. Aynı adresten yoğun istek gelen bir site o adresi kısıtlar. Modelin hangi sürüm olduğu hedef sitenin güvenlik duvarını ilgilendirmez.
- İstek hızı sınırları. 429 yanıtı alıyorsanız sorun ayrıştırmada değil, trafiğin dağıtımındadır.
- Konum kısıtlamaları. Yalnızca belirli bir ülkeden erişilebilen içerik, o ülkeden bir IP olmadan görünmez.
- IP türü. Veri merkezi adreslerinin neden daha kolay işaretlendiğini Residential ve Datacenter Proxy Farkı yazımızda anlattık; bu mekanizma modelden bağımsızdır.
- CAPTCHA ve davranışsal bot tespiti. Cloudflare gibi sağlayıcıların oturum boyunca davranış izleyen sistemleri, trafiğin nasıl üretildiğine bakar. Bu konuyu Cloudflare Precursor yazımızda ayrıntılı ele aldık.
Kısacası getirme katmanında hâlâ doğru IP stratejisine ihtiyacınız var. Korumalı hedeflerde gerçek kullanıcı adreslerinden gelen Residential Proxy, yüksek hacimli işlerde ise adresi istek başına değiştiren Rotating Proxy bu ihtiyacı karşılar.
LLM ile ayrıştırma her zaman mantıklı mı?
Hayır. Model tabanlı ayrıştırmanın üç bedeli vardır:
| Ölçüt | Seçici (CSS/XPath) | LLM ile ayrıştırma |
|---|---|---|
| Birim maliyet | Neredeyse sıfır | Her sayfa için token ücreti |
| Hız | Milisaniyeler | Saniyeler |
| Tutarlılık | Aynı girdi, aynı çıktı | Çıktı doğrulanmalı |
| Site değişikliğine dayanıklılık | Düşük | Yüksek |
| Bakım yükü | Sık güncelleme gerekir | Daha az |
| Serbest metin çıkarımı | Zayıf | Güçlü |
Günde milyonlarca sayfa işleyen bir fiyat takip sisteminde her sayfayı bir LLM'den geçirmek hem pahalı hem yavaştır. Güncel API ücretleri için OpenAI'ın fiyatlandırma sayfasına bakabilirsiniz; hesabı sayfa sayısıyla çarptığınızda tablo netleşir.
Maliyeti nasıl hesaplarsınız?
Model tabanlı ayrıştırmanın maliyetini kestirmek için üç sayı yeterlidir: sayfa başına gönderdiğiniz token miktarı, sayfa sayısı ve modelin token başına ücreti. Bu hesabı yaparken şu üç nokta bütçeyi belirgin biçimde etkiler:
- Ham HTML göndermeyin. Bir e-ticaret sayfasının HTML'i, görünen metnin katbekat büyüklüğünde olabilir. Betiği ve stil bloklarını temizleyip yalnızca görünür metni ya da ilgili bölümü göndermek token sayısını büyük ölçüde düşürür.
- Sayfayı daraltın. Fiyat bloğunu içeren
<div>biliniyorsa yalnızca onu gönderin. Seçici burada da işe yarar: Kaba bir seçiciyle bölgeyi bulup içini modele bırakmak, iki yöntemin avantajını birleştirir. - Önbelleğe alın. Aynı sayfa yapısı için modelin ürettiği seçiciyi saklayın ve sonraki sayfalarda modeli hiç çağırmayın.
Bu üç önlemle, "her sayfayı modele gönder" yaklaşımına göre maliyet çoğu projede küçük bir kesire iner.
Pratikte en verimli kurgu
Çoğu proje için karma bir yaklaşım en verimli sonucu verir:
- Getirmeyi klasik araçlarla yapın. Python'da HTTP istemcisi veya gerektiğinde başsız tarayıcı, önünde de uygun bir proxy havuzu. Hangi istemcinin ne zaman seçileceğini HTTPX, Requests ve AIOHTTP karşılaştırmamızda anlattık.
- Kararlı sayfalarda seçici kullanın. Yapısı nadiren değişen sayfalar için seçiciler hâlâ en hızlı ve en ucuz yoldur.
- Modeli istisnalara ayırın. Seçicinin kırıldığı, yapının sayfadan sayfaya değiştiği veya serbest metinden anlam çıkarmanız gereken durumlarda LLM'e başvurun.
- Çıktıyı doğrulayın. Modelden JSON şemasına uyan çıktı isteyin ve fiyatın sayı olması, tarihin geçerli olması gibi kuralları kodla kontrol edin.
- Seçicileri yeniden üretmek için modeli kullanın. Site değiştiğinde modelin yeni seçiciyi önermesini, ardından o seçiciyle binlerce sayfayı ucuza işlemeyi deneyin.
Örnek: seçici kırılınca modele düşen akış
Aşağıdaki Python taslağı bu kurgunun iskeletini gösterir. Getirme proxy üzerinden yapılır; ayrıştırma önce seçiciyle denenir, seçici boş dönerse yalnızca görünür metin modele gönderilir ve çıktı şemaya karşı doğrulanır.
import json
import requests
from bs4 import BeautifulSoup
PROXY = "http://kullanici:parola@pr.proxynet.io:8000"
SEMA = {"ad": str, "fiyat": float, "stokta": bool}
def getir(url):
yanit = requests.get(url, proxies={"http": PROXY, "https": PROXY}, timeout=20)
yanit.raise_for_status()
return yanit.text
def secici_ile(html):
soup = BeautifulSoup(html, "html.parser")
ad = soup.select_one("h1.urun-adi")
fiyat = soup.select_one("span.fiyat")
if not (ad and fiyat):
return None
return {"ad": ad.get_text(strip=True), "fiyat": float(fiyat["data-deger"]), "stokta": True}
def model_cagir(metin):
# Sağlayıcının resmi istemcisiyle doldurun: metni gönderin, JSON çıktısı isteyin.
# Örneğin "ad, fiyat ve stok bilgisini {ad, fiyat, stokta} şemasında JSON olarak ver".
raise NotImplementedError("model çağrısı burada yapılır")
def model_ile(html):
soup = BeautifulSoup(html, "html.parser")
for etiket in soup(["script", "style", "nav", "footer"]):
etiket.decompose()
metin = soup.get_text(" ", strip=True)[:6000]
return json.loads(model_cagir(metin))
def dogrula(kayit):
for alan, tur in SEMA.items():
if not isinstance(kayit.get(alan), tur):
raise ValueError(f"{alan} alanı beklenen türde değil")
return kayit
html = getir("https://example.com/urun/123")
kayit = secici_ile(html) or dogrula(model_ile(html))
print(kayit)Bu iskeletin iki özelliği önemlidir: Model yalnızca seçici başarısız olduğunda çağrılır ve modelin çıktısı koda güvenilmez veri olarak girer. dogrula adımı olmadan modelin bir kez yanlış türde değer üretmesi, veri tabanınıza sessizce hatalı kayıt yazabilir.
Tarayıcı kontrolü ne zaman mantıklı?
Astra'nın tarayıcı kullanma yeteneği, ölçekli veri toplama için değil, tekil ve karmaşık görevler için değerlidir:
- Bir formu doldurup sonuç sayfasına ulaşmak,
- Çok adımlı bir filtre menüsünden doğru listeye inmek,
- Yapısı her seferinde farklı olan bir siteden tek bir bilgi çıkarmak.
Aynı işi günde on bin kez yapacaksanız modelin her adımda karar vermesi hem yavaş hem pahalıdır. Bu durumda modelin bir kez bulduğu yolu (tıklanan öğeler, gönderilen parametreler) betiğe dönüştürüp tarayıcı otomasyonu ya da doğrudan API isteğiyle tekrarlamak daha verimlidir. Tarayıcı otomasyonunun kendi tespit sorunlarını Puppeteer ve CAPTCHA yazımızda anlattık. Bir modelin araç çağırarak adım adım çalıştığı bu döngünün genel yapısını ise AI Ajanları Nasıl Çalışır? yazımızda ele aldık.
Hukuki ve etik çerçeve değişmedi
Daha yetenekli bir model, hangi verinin toplanabileceği sorusunu değiştirmez. Kişisel veriler, oturum açılarak ulaşılan içerik ve telif kapsamındaki materyal konusundaki kurallar aynı kalır. Sitenin kullanım koşulları ve robots.txt dosyası yine başlangıç noktasıdır. Ayrıntılar için Web Scraping Yasal mı? yazımızı okuyabilirsiniz.
Modelle çalışırken bir ek sorumluluk daha doğar: Topladığınız sayfa içeriğini üçüncü bir tarafın API'sine gönderiyorsunuz. Kişisel veri içeren sayfalarda bu aktarımın kendisi mevzuat kapsamına girebilir; bu tür sayfaları modele göndermeden önce kişisel alanları temizlemek gerekir. Modeli web'e ve araçlara standart bir yolla bağlayan protokolü MCP (Model Context Protocol) Nedir? yazımızda, modelin web erişimini hız sınırı ve izin listesiyle güvenli hâle getirmeyi LLM'e Güvenli Web Erişimi yazımızda anlattık.
Sık sorulan sorular
GPT-6 Astra proxy ihtiyacını ortadan kaldırır mı?
Hayır. Model, sayfanın içeriğini daha iyi yorumlar; ancak sayfaya hangi IP'den, hangi hızla ve hangi konumdan erişildiği hâlâ hedef sitenin kararıdır.
Astra'ya doğrudan "şu siteyi kaz" diyebilir miyim?
Tarayıcı kontrolüyle tek tek görevleri yaptırabilirsiniz, ancak bu yöntem büyük hacimli ve tekrarlanan veri toplama için pahalı ve yavaştır. Ölçekli işlerde model, ayrıştırma veya karar verme katmanında daha verimli çalışır.
Hangi işlerde en çok fayda sağlar?
Sayfa yapısının sık değiştiği, çok sayıda farklı sitenin tek bir şemaya dönüştürülmesi gereken veya serbest metinden (yorumlar, ilan açıklamaları) bilgi çıkarılması gereken projelerde.
Modelin ürettiği veriye güvenebilir miyim?
Doğrulamadan güvenmeyin. Türleri, aralıkları ve zorunlu alanları kodla kontrol edin; şüpheli kayıtları ayrı bir kuyruğa alın. Modelin tutarlılığı seçiciden düşüktür ve bu fark ölçekte kendini gösterir.
Astra'yı hangi programlama diliyle kullanmalıyım?
Resmi istemciler birden fazla dilde sunulur; seçim, kazıma altyapınızın diline göre yapılmalıdır. Python ve JavaScript arasındaki farkları Web Kazıma: JavaScript mi Python mu? yazımızda karşılaştırdık.
Daha küçük bir model yeterli olur mu?
Çoğu ayrıştırma görevi için evet. Alan çıkarma gibi dar görevlerde daha küçük ve ucuz modeller yeterli sonuç verir; Astra gibi büyük modelleri karmaşık çok adımlı görevler ve serbest metin çıkarımı için ayırmak bütçeyi korur.
Özetle
GPT-6 Astra, kazımanın "anlama" tarafını ileri taşıyor: kırılgan seçicilere daha az bağımlılık, çok adımlı akışlarda daha iyi odak ve kötü niyetli sayfa içeriğine karşı daha yüksek dayanıklılık. "Ulaşma" tarafı ise değişmedi. Engeller, hız sınırları ve konum kısıtlamaları hâlâ doğru proxy altyapısıyla aşılıyor. İki katmanı ayrı tasarlayan, modeli istisnalara ayıran ve çıktısını doğrulayan ekipler modelden en çok verimi alacak. Veri toplama altyapınızı kurarken veri kazıma çözümlerimize göz atabilirsiniz.




