Tersine mühendisliğin mekanik ayırma, algoritma ailesini tanıma ve diferansiyel doğrulama gibi ilk aşamaları sonunda şu noktaya gelirsiniz: “Ne hesapladığını anlıyorum.” Ancak bu sonuç tek başına üretime taşınamaz. Mantık hâlâ kaynak çalışma zamanına gömülüdür; onu CI'a girebilecek saf bir fonksiyon olarak mı, yoksa sürekli gözetim gerektiren harici bir süreç olarak mı konumlandıracağınıza karar vermeniz gerekir. Burada verilen yanlış karar, ilk aşamalarda kazandığınız zamanı operasyon tarafında faiziyle geri ödetir.
Dört aşamalı genel bakış bu kısmı tek cümleyle özetliyor: “Aşama 4: taşıma katmanına göre kademeli indirgeme.” Bu yazı o cümleyi açıyor. Temel prensip şu: Her alt katman bağımlılık yüzeyini, hata türlerini ve dağıtım maliyetini bir mertebe büyütür; bu yüzden varsayılan yönünüz daima yukarı olmalı.
Üç katman ve değişmeyen öncelik sırası
Mantığı yerleştirmenin yalnızca üç yolu var. Bu sıralama, “ilk çalışan çözüm hangisiyse” diye her seferinde yeniden belirlenmemeli; ekip standartlarına açıkça yazılmalı:
Native yeniden yazım. Mantığı hedef dilinizde, kaynak çalışma zamanından tamamen bağımsız ve yalnızca standart kütüphaneye dayanacak şekilde yeniden yazın. Ön koşul, algoritma ailesinin doğru tespit edilmiş olmasıdır. Parmak izi çıkarma aşaması geçildikten sonra kodun %90'ı herkese açık implementasyondan alınabilir; kalan sapma noktaları ayrıca ele alınır ve sonuç saf bir fonksiyon olarak teslim edilir.
Minimal parçayı çalıştıran yerel JS motoru. Bazı mantıkları kısa vadede arındırmak gereğinden pahalı olabilir. Bu durumda orijinal JS'in küçük bir bölümünü korur, sayfanın tamamını değil, ihtiyaç duyulan birkaç düzine satırı yerel Node/V8 üzerinde çalıştırırsınız.
Pasif tarayıcı köprüsü. Bazı durumlarda gereken durum bilgisi yalnızca oturum açılmış gerçek bir sayfa çalışma zamanında bulunur: çalışma zamanında dağıtılan bir imza ya da oturuma bağlı dinamik bir kimlik gibi. Statik yeniden kurulumun üretemediği bu veriler, şimdilik yalnızca tarayıcı içinden okunabilir. Bu geçici bir çözümdür; arayüz notlarında açıkça işaretlenmeli ve asla varsayılan yol olarak yaygınlaştırılmamalıdır.
Katman indikçe maliyet neden sıçrıyor?
Bu sıralamanın sabit olmasının nedeni, üç katmanın maliyetlerinin doğrusal artmamasıdır. Her katman, bir öncekinin yaklaşık bir mertebe üzerindedir.
Katman | Bağımlılık yüzeyi | Arıza biçimi | CI'a uygun mu? |
|---|---|---|---|
Native yeniden yazım | Standart kütüphane, sıfır harici süreç | Çıktı uyuşmazlığı; tek bir | Evet; saf fonksiyondur |
Yerel JS motoru | Ek bir Node çalışma zamanı; V8 context'i thread-safe değildir, eşzamanlılık için kilit gerekir | Motor sürümü ya da parçanın bağlı olduğu bir global değişkenin eksik olması | Zor da olsa evet; motorun kurulması gerekir |
Pasif tarayıcı köprüsü | Gerçek bir Chrome + eklenti + insan tarafından sürdürülen oturum + yerel loopback kanalı | Sayfa açık değil, oturum süresi dolmuş, yapı değişmiş veya sekme kapatılmış | Hayır; canlı bir insan gerekir |
İlk katmandaki arızayı birim testi yakalar; üçüncü katmandaki arıza ise “kullanıcı bugün o sekmeyi kapattı” olabilir. Saf fonksiyon olabilecek bir şeyi üçüncü katmana indirgemek, her çağrıyı bir insana bağımlı hâle getirir. Referans olması için: Algoritma ailesi tespit edildiğinde, obfuscate edilmiş bir imza SDK'sı yalnızca yerleşik crypto bağımlılığıyla 600 satırın altında bağımsız bir implementasyona dönüştürülebilir ve ilk katmanda çalışır. Tarayıcı köprüsünden başka yolu olmadığını sandığınız şey, çoğu zaman henüz tam tanımlayamadığınız bir algoritmadır.
Pasif köprünün sınırı: tek seferlik anlık görüntü, asla aktif davranış yok
Pasif köprünün kontrolden çıkmasının tek bir yolu vardır: “yardım etmeye” başlaması. Oturumu otomatik yenilemek, otomatik giriş yapmak, sayfanın yüklenmesini otomatik beklemek... Eklediğiniz her “otomatik” davranış, onu iletici olmaktan çıkarıp crawler'a yaklaştırır. Bu nedenle sınırlar çok dar çizilmelidir. Aşağıdaki kurallar zor yoldan öğrenildi:
Yalnızca tek bir anlık görüntü alın; sayfayı asla değiştirmeyin. Zaten açık olan bir sayfanın çerezlerini, oturum durumunu ve sayfa çalışma zamanını yalnızca bir kez sorgulayın. Sekme oluşturmayın, yenilemeyin, yönlendirmeyin, odağa almayın, yoklayarak beklemeyin. Sayfa yoksa yoktur; kullanıcı adına siz açmayın.
Eksik olan şey için anında açık hata döndürün. Eşleşen sekme yoksa tab_unavailable; sayfa açık ama oturum kapalıysa not_logged_in; oturum açık ancak çalışma zamanı hazır değilse runtime_unavailable dönmelidir. Bu üç hata kodunun her biri gerçek dünyadaki tek bir duruma ve tek bir sonraki adıma karşılık gelir: sayfayı beklemek, giriş yapmak veya hedef değiştirmek. Böylece çağıranın tahmin etmek zorunda kaldığı belirsiz bir “başarısız oldu” sonucu üretmezsiniz.
Hassas durum bilgisi tarayıcıdan dışarı çıkmamalı. Eklenti cookies veya webRequest izni istemez; yalnızca zaten açık olan eşleşen sekmeyi sorgular, isteği o sayfanın context'i içinde tamamlar ve döndürmeden önce alanları temizler. Çerezler ve sayfa imza durumu tek bir adım için bile Chrome dışına çıkmaz; kanal varsayılan olarak yerel bir loopback adresine bağlanır. Köprü kimlik bilgilerini değil, sonuçları taşır.
Neden birkaç platform için 15 ayrı whitelist kapsamı gerekiyor?
Pasif köprünün ilettiği şey whitelist'e alınmış isteklerdir; yol, parametreler ve referer bilgisi adapter tarafından sınırlandırılır. En ters köşe nokta kapsamların ayrıntı düzeyidir: Yalnızca birkaç platform için toplam 15 kapsam bulunur, çünkü kapsamlar “platforma” göre değil, “sayfa context'ine” göre ayrılır. Örneğin TikTok'ta Creative Center, Top Ads, Creator platformu, influencer library ve Ads Manager beş ayrı kapsamdır. Bunlar beş bağımsız oturum durumu ve beş bağımsız sayfa çalışma zamanı demektir; reklam arka ucuna giriş yapmış olmak Creator platformunun çalışma zamanını vermez. Her platformu tek bir dilim olarak ele alırsanız, “alt site A'da oturum açık ama alt site B hizmet veremiyor” sorunuyla ilk karşılaşmanızda yeniden başa dönersiniz. Xiaohongshu'nun ana sitesi, uygulama eşdeğeri yolları ve içerik üretici pazaryeri de benzer şekilde üç ayrı kapsama ayrılır.
Zamanlama ayrıntısı da buna göre belirlenir: kilit yalnızca platform ailesi seviyesinde uygulanır. Aynı ailedeki istekler, örneğin Douyin ailesindekiler, aynı gerçek sekmeyi kullandıkları için seri çalışır; aynı sayfa context'ine eşzamanlı istek göndermek isteklerin birbirini ezmesine yol açar. Farklı aileler, örneğin Douyin ve Xiaohongshu, birbirinden bağımsız iki sekme oldukları için paralel çalışabilir. Aynı aile içinde ayrıca minimum istek aralığı uygulanmalıdır. Kapsamı fazla geniş tutarsanız paralel çalışabilecek işleri serileştirirsiniz; fazla dar tutarsanız aynı sekmeyi paylaşan istekler çakışır. Platform ailesi, “aynı sayfa çalışma zamanını paylaşma” durumunun tam doğal sınırıdır.
Açık giriş devri: insanın yapabileceği tek müdahale
Pasif köprü sayfayı işletmez, fakat oturumların süresi dolar. Çözüm, insan müdahalesini açıkça tanımlanmış tek seferlik bir işleme indirgemektir: Etkileşimli bir komut devir akışını başlatır; program işletim sistemi üzerinden ilgili iş sayfasını açar, sizin manuel olarak giriş yapmanızı ve sayfanın hazır hâle gelmesini bekler, ardından ilk isteği yeniden yürütür. Bu süreçte eklenti hiçbir düğmeye tıklamaz, form doldurmaz, çerez dışa aktarması yapmaz. Giriş işlemini gerçek tarayıcıda siz yaparsınız; program yalnızca işiniz bittiğinde isteği kaldığı yerden sürdürür.
Buradaki kritik kural, bu akışın örtük biçimde tetiklenmemesidir. Etkileşim gerektirmeyen bir komut, yani CI veya zamanlanmış görev, asla tarayıcı açmamalıdır; temiz bir şekilde oturum hatası döndürmeli ve kararı üst katmana bırakmalıdır. Devir akışı yanlış pozitiflere karşı da koruma sağlamalıdır: Başarılı girişten sonra çalışma zamanına en fazla kısa bir ek bekleme süresi tanınır; implementasyonda bu süre 20 saniyedir. Ardından mutlaka bir karar verilmelidir. İş sayfası hedef arayüz context'ini içermeyen bir hesap sayfasına zaten yönlendirmişse, deterministik “buraya erişilemiyor” durumunu “hâlâ yükleniyor” diye yorumlayıp anlamsızca beklemek yerine mevcut aşamayı hemen sonlandırın. Kademeli indirgemeye izin veren bir akış, tüm işlemi başarısız kılmak yerine bu aşamayı unavailable olarak kaydeder ve devam eder.
Aşama durumları: tamamlandı, bilerek atlandı, oturum gerekiyor
Yukarıdaki her şeyin altında ortak bir ilke var: Hiçbir aşama yalnızca “başarılı” ya da “başarısız” sonucu döndürmemeli. Bir orkestrasyon hattında her aşamanın sonucu altı biçimden birini alır: completed (tamamlandı), empty (çalıştı ancak veri yok), ready (hazırlandı, gönderim bekliyor), skipped (kural gereği bilerek atlandı), unavailable (şu anda kullanılamıyor; genellikle oturum gerektiğini ifade eder), blocked (ön koşul sağlanmadı).
“Bilerek atlandı”, “oturum gerekiyor” ve “gerçekten boş” birbirinden tamamen farklı üç sinyaldir. Tek ve opak bir sonuç döndürürseniz, boş sonucun “zaten boş olması gerekiyordu” anlamına mı geldiğini, yoksa “oturum öldü ve kimse fark etmedi” durumunu mu gösterdiğini anlayamazsınız. Böyle bir pipeline işletilemez. Aşama durumunu sonlu bir enum olarak modellediğinizde, orkestrasyon katmanı —ister script ister model olsun— buradan kademeli indirgeme, yeniden kimlik doğrulama ya da işlemi durdurma kararını verebilir. Bu, pasif köprüdeki üç hata kodu ilkesinin akış seviyesine taşınmış hâlidir.
Bir yeteneğin hangi katmana ait olduğuna karar verirken modelden yararlanmak
Modelin devreye girdiği yer yalnızca burasıdır ve rolü sınırlıdır: mantığı sizin yerinize arındırmaz; arındırmanın gerekli olup olmadığını ve ne ölçüde yapılacağını değerlendirmenize yardım eder. Bu, imza kırma değil, mimari karar meselesidir. Temel soru şudur: Bağımlı olduğu durum statik olarak yeniden kurulabilir mi, yoksa yalnızca çalışma zamanında mı erişilebilir? Sonrasında arındırma çabasını, bu mantığın değişim sıklığıyla tartarsınız. Farklı adımlar modelden farklı yetenekler ister:
Adım | Gereken yetenek | Tercih | model id |
|---|---|---|---|
Bağımlılık yüzeyini görmek için tüm modülü okumak | Uzun context, çağrı grafiğini tek seferde okuyabilme | Kimi K3 |
|
Katmanı iki yönden de tartışmak, “bir şekilde çalışsın yeter” yaklaşımına itiraz etmek | Güçlü muhakeme; arındırmak için ek bir gün harcamayı gerekçelendirebilme | Claude Opus 5 |
|
Düzinelerce ya da yüzlerce yetenek için toplu ilk eleme | Düşük maliyet, yüksek eşzamanlılık | Claude Sonnet 5 |
|
Kademeli indirgeme sonrası kaynak analizi | Orta düzey muhakeme; hata kaydına dayanarak açıklama yapabilme | GPT-5.6 Sol |
|
En kritik olan ikinci satırdır. Katman seçerken en kolay yapılan hata, modelin sizin “bir şekilde çalışsın yeter” tonunuzu takip edip “tarayıcı köprüsü en kolay yol” cevabını vermesidir. Bu uzun vadeli maliyeti hesaplamak değil, sizi yansıtmaktır. Güçlü muhakeme katmanı ise itiraz eder: “Bu parça standart bir hash ve tek bir sabit sapmadan oluşuyor; saf fonksiyon olarak taşımak için bir gün harcamaya değer, köprüye konmamalı.” Sözüme güvenmek zorunda değilsiniz; kendiniz test edin. Üç mantık parçası seçin; bunlardan en az biri, doğru yerleşimini zaten bildiğiniz bir kontrol örneği olsun. Aynı “bir katman seç + gerekçelendir + köprüye erken gitme kararına itiraz et” istemini claude-opus-5 ve gpt-5.6-sol modellerine verin. Tek bir şeye bakın: Sizi bir üst katmana taşımak için mücadele ediyor mu, yoksa zahmetsizce üçüncü katmana mı yöneliyor?
Asıl engel model değiştirme maliyeti
Üç sağlayıcıdan dört katman demek; üç SDK, üç kimlik doğrulama yöntemi ve üç hata formatı demektir. Adımlar arasında model değiştirmek için istemcinizi yeniden yazmak çoğu durumda değmez. Bu nedenle çoğu kişi her iş için tek model kullanır ve en çok güçlü muhakeme gerektiren katman seçimi kararında yalnızca kendisini yansıtan bir modelle kalır.
AIReiter bu katmanı düzleştiriyor: tek anahtar, OpenAI uyumlu tek arayüz ve arkasında dört katmanın tamamı. Model değiştirmek, istek gövdesindeki model alanını değiştirmek kadar basit.
# Katman seçimi tartışması: muhakeme katmanı
curl https://aireiter.com/api/v1/chat/completions \
-H "Authorization: Bearer $AIREITER_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-opus-5",
"messages": [{"role": "user", "content": "<placement prompt + the reversed logic fragment + dependency list>"}]
}'
# Toplu ilk eleme: yalnızca tek alanı değiştirin
# "model": "claude-sonnet-5"
# Kademeli indirgeme sonrası kaynak analizi:
# "model": "gpt-5.6-sol"
Halihazırda OpenAI SDK kullanıyorsanız base_url değerini https://aireiter.com/api/v1 olarak ayarlayın. Anthropic SDK kullanıyorsanız aynı anahtarla POST /api/v1/messages isteğini gönderin. Fiyatlandırmada Claude modelleri liste fiyatına göre %30 indirimli, GPT modelleri ise yarı fiyatına çalışır. Bu iş akışının maliyeti iki noktada yoğunlaşır: Düzinelerce ya da yüzlerce yetenek için yapılan toplu ilk eleme işleminde —Sonnet, yüksek çağrı hacmi— ve bir modülün bağımlılık yüzeyini görmek için tamamının uzun context ile tek girdide okunmasında —Kimi, çağrı başına çok sayıda token. Toplu eleme bir Claude modeli üzerinde çalıştığı için indirim doğrudan en yoğun adıma yansır; muhakeme katmanındaki yerleşim tartışması da %30 indirimli bir Claude modelidir. Kimi K3'ün uzun context katmanına da aynı anahtarla erişilebilir.
Kayıt olmadan deneyin — önce birkaç mantık parçasını elle verin; iki modelin sizi yansıtıp yansıtmadığını ya da “bu tarayıcı köprüsüne mi gitmeli?” sorusunda itiraz edip etmediğini görün.
Sonuç
Tersine mühendislikle çıkarılan mantığı üretime almak teknik bir problemden çok maliyet problemidir. Native yeniden yazım > yerel JS motoru > pasif tarayıcı köprüsü şeklindeki üç katmanlı sıra tersine çevrilemez; çünkü her alt katman, saf fonksiyonun yerine harici bağımlılıkları, insan müdahalesini ve canlı sekmeyi gerektiren bir süreç koyar. Pasif köprü yasak bir alan değildir; sıkı sınırları olan geçici bir bileşendir: tek anlık görüntü, asla aktif davranış yok, sayfa eksikse anında açık hata, hassas veriler tarayıcıdan çıkmıyor, giriş yalnızca açık devir yoluyla yapılıyor ve aşama durumu daima okunabilir kalıyor. Bu kuralları korursanız güvenilir bir geçiş çözümüdür; herhangi birini bırakırsanız kimsenin bakımına cesaret edemediği bir kara kutuya dönüşür. Model, bir yeteneğin hangi katmana ait olduğuna karar vermenize ve “bir şekilde çalışsın yeter” ataleti karşısında çizgiyi korumanıza yardımcı olur. Ancak her yeniden yazımın doğru olup olmadığının hakemi model değil, diferansiyel testtir.