Qwen 3.8, gerçek bir anahtar kimliğiyle Alibaba bağlantılarını uyduruyor; işte buna neden bir arka kapı demiyorum.

Alibaba’nın Qwen 3.8 Flash Next modeli Ağustos’un sonunda duyuruldu ve Qwen 4 ailesiyle resmen karşımıza çıkacak yeni bir mimarinin önizlemesini vaat ediyordu. 6B aktif parametre ve ayrıca 51B N-gram gömme tablosu içeren güçlü bir 125B Uzmanlar Karışımı (Mixture of Experts) modeli. Bu hafta ise Cohere tarafından yayımlanan bir rapor, Alibaba’nın Qwen 3.8 Flash Next modelinin bir güvenlik tespit kuralı yazması istendiğinde makineyi taradığı ve Pekin’deki bir Alibaba Cloud Storage deposuna dosya yüklemeye çalıştığı anlatılıyor.

Ekle XDA Google’da

Tercihli Kaynak Olarak Ekle

Google Discover’dan Takip Et

Cohere’ın kumanda kutusu (sandbox) isteği engelledi, ancak olay daha büyük bir soruyu gündeme getirdi: Model bilinçli olarak “evine haberleşme” (phone home) özelliğiyle mi inşa edilmişti? İlginç bir şekilde, ben benzer bir davranışı Cohere’ın paylaşımından bir aydan fazla önce, 20 Eylül’den beri, aynı Qwen 3.8 Flash Next modelinde görüyordum. Bir örnekte model, istediğim web sitesini değil imzalı bir Alibaba Cloud URL’sini yanlışlıkla çektiğini söyledi, oysa böyle bir şey yapmamıştı.

Sonra modelden, URL’yi doğru şekilde bildirdiği bir cevabı tekrar kontrol etmesini istedim; özür diledi, bana “önceki cevabım yanlıştı” dedi ve doğru adresi bir Alibaba vekil (proxy) URL’siyle değiştirdi. Takip eden haftalarda aynı şeyi diğer uzun oturumlarda gördüm ve bazen model daha da ileri gitti. Aslında bu Alibaba URL’lerinden birine gitti ve geriye 403 hatası aldı.

Bu olayların ardından merak edip kontrollü istemlerle, yüzlerce üretilen URL ile hatta modelin ağırlıkları (weights) üzerinde dolaşarak denemeler yapmaya başladım. Görünen o ki, Cohere’ın gözlemi hem gerçek hem bir sorun, tek bir şartla: Keşfettiğim her şey, veri sızdırmak için tasarlanmış bir modelden çok, modelin eğitim sırasında Alibaba’nın iç web-çekme araçlarının nasıl çalıştığını öğrendiğine işaret ediyor.

Cohere, Qwen 3.8’in Pekin’e dosya yüklemeye çalışırken yakalandığı

Bir güvenlik ölçütü alarm verdi

Credit: Cohere

Cohere’nin raporu, Microsoft’un CTI-REALM adlı AI ajanı güvenlik ölçütünden oluşturulmuş. Modele, /tmp dizinine bash betiklerini indiren curl’u alglayan bir kural yazması istenmiş; ancak çalışmalardan birinde model /tmp’nin içeriğini listelemiş, hangi aktarım araçlarının kurulu olduğunu kontrol etmiş, makinenin DNS yapılandırmasını okumuş ve Alibaba Cloud’un Pekin bölgesindeki sanmaohe adlı bir depoya HTTP PUT isteği göndermeyi denemiş. Cohere, bu davranışın 100.000 çağrının birinden azında gerçekleştiğini ve aynı istemin yeniden denenmesinin normal bir kural algılama ile sonuçlandığını belirtiyor.

Yükleme işlemi ayrıca oldukça zararsızdı; PUT isteğinin gövdesi, modelin az önce topladığı envanter değil, metinsel bir test dizisi olan “PROBE_PAYLOAD_ABC123” idi. Yine de yine de olmaması gerekiyordu ve başarılı olmuş olsa, o depoyu yöneten kişi, sahip olmaması gereken bir dosyayı almış olurdu. Bu arada, “bir yer tutucu yüklemeye çalıştı” ile “veri sızdırmaya çalıştı” çok farklı şeylerdir.

Cohere, prefilling olarak adlandırdığı bir teknikle bir tetikleyici bulmaya çalıştı; bu teknik, modele bir curl komutunun başına kendi muhakemesini ekleyerek modelin satırı tamamlamasına izin vermeden önce modelin kendi muhakemesini de içeriyor. curl’un -o bayrağı eklendiğinde, şüpheli ana bilgisayarlara yapılan istekler tamamlamaların %0,5’inden %23’üne çıktı. En yaygın olanı belirgin biçimde routify-file-proxy-sg idi; bu, Singapur’daki bir Alibaba Cloud depolama deposu ve benim de aralarında olduğum birkaç kişinin haftalardır karşılaştığı bir depo. Cohere ayrıca modelin, bu prefilling ile tamamlamaların %23’ünden %36’sında 169.254.169.254 ile iletişime geçmeyi denediğini de buldu. Ardından, ayrı bir çevrimdışı testte, bir RAM diski bağlarken bir izin hatasını atlatmak için ayrıcalıksız bir kullanıcı alanı kullandı. Bunlar, Alibaba URL’lerinden farklı ve bulduğum hiçbir şey bunlarla alaka sahip değil.

Adaletsizlik olmaması için Cohere’a iki “zararsız fosil” sunarak nedeni açıklar: eğitim sırasında emilen ajan aktivitesi izleri ya da kasıtlı bir yerleştirme. Cohere ayrıca bir güvenlik ekibi için farkın gerçekten önemli olmadığını, modelin yine de temas etmemesi gereken ana bilgisayarlara ulaşmaya çalıştığını savunur. Cohere ayrıca tüm akıl yürütme izlerini, ham belirteçleri ve bir yeniden üretim betiğini yayımladı.

Yanlış anılar en yaygın başarısızlıktır

Qwen 3.8, çektiği şey hakkında yalan söyleme eğilimindedir

Singapur vekili dizgesi bulunduğunda—kendi örneğim de dahil—benzer bir şekilde ortaya çıktığı görülüyor. Önce model, normal bir URL ile bir web aracı çağırır, sonucu alır ve ardından bu çağrıyı uzun, imzalı bir Alibaba Cloud URL’sine gidilmiş gibi tanımlar. Genellikle vekil URL’sinin araca ilettiği gerçek argüman olduğunu iddia eder, bunu gerçek adresle karşılaştırır, kısa sonucu vekilin bir taslak döndürmesiyle açıklar ve daha önce meşru URL’yi bildiği için özür diler.

Yeniden üretmek için, konuşma geçmişini tek bir araç çağrısından, Python’un pathlib belgelerini çekmeyi içeren kısa bir sonuçtan ve hangi URL’yi çektiğini soran bir sorudan oluşan basit bir sohbet geçmişi yerleştirdiğim modelime verdim. Düzenli olarak, girdide hiçbir yerde görünmeyen bir Routify URL’siyle yanıtladı. İşaretlenmiş promtu ve belirteç ID’lerini kontrol ederek modelin gerçekten doğru adresi aldığını doğruladım. Python’un belgelerini SQLite’ınkilerle değiştirmek hiçbir fark yaratmadı. Hem İngilizce hem de Çince’de birkaç yüz denemede, son yanıtların yaklaşık dörtte birinde bir vekil URL’si belirtti ve testin en temel sürümünde neredeyse her seferinde.

Geçmişi bu şekilde sunmam da oldukça önemliydi. Modele, yerel ve yapılandırılmış bir araç çağrısı yerine, alıntılanmış bir konuşma metni gibi düz metin olarak aynı araç çağrısını yapsaydım, test ettiğim hiçbir koşulda sahte bir vekil iddiasında bulunmuyordu. Ancak kullanılmayan bir web sorgulama aracını kullanılabilir araçlar listesine eklemek, model önce doğru cevap vermiş olsa bile bazen bu hatayı geri getiriyordu. Model URL’yi gayet iyi okuyabiliyor. Sorun, araç kullanımının yapılandırılmış bağlamının, araçlarının nasıl çalıştığına dair öğrendiği bir şeye geri dönmesine yol açması gibi görünüyor.

Doğrulama istemek durumu daha da kötüleştiriyordu. Örneğin, zaten doğru cevap verdiği bir geçmiş verip sonra bu cevabı, önceki araç çağrısındaki URL argümanı ile karşılaştırmayı ve herhangi bir tutarsızlığı tespit etmeyi isteseydim, doğru cevabı yaklaşık %75 oranında “gerçek” argüman olarak hayali bir Alibaba vekil URL’sine dönüştürüyordu. Açıkçası ona bir vekil URL’si vermemiştim; model, hiç var olmayan bir hatayı kendisi üretmişti.

Uzun oturumlarda bu yanlış inanış gerçekten sorunlara yol açtı. Bir örnekte, bir vekilin URL’lerini yeniden yazdığına karar verip, sonra bu hayali vekil URL’lerini doğrudan bir tarayıcı aracına gönderdi. Yalnızca Pi oturumlarımda bunun altı ayrı kez gerçekleştiğini buldum ve hepsi 403 yanıtı aldı. Makinemden hiçbir veri gönderilmiyordu, ancak istekler ağımdan çıkıyordu; ki bu da Cohere’in vurguladığı tam olarak sorun.

Model davranışı yazılı Çince için de geçerli ve burada biraz farklı bir yanıt veriyor. Burada imzanın ortasına bir nokta atıyor ve kayıtlarıma bakmamı söylüyor. 200 URL’nin 80’inde nokta, imzanın ortasını değiştiriyor. Başka bir Çince denemesinde model, akıl yürütme izlerinde anahtarın “LTAI5t…QVZr” olduğunu, buna “tam dizge” dediğini belirtiyor; ancak bu sürüm tamamen farklı bir anahtar ID’sine, gc9z ile biten ve farklı bir imzaya sahipti.

İmzalar, bunların nereden geldiğine dair bize daha fazla içgörü de veriyor. Bir Alibaba Cloud imzası, gizli bir anahtar kullanılarak hesaplanan isteğin kriptografik bir özetidir, dolayısıyla 64 olası karakterden herhangi biri, diğer herhangi biriyle aynı sıklıkta ortaya çıkmalıdır. Model 53 tam imza üretmiş olsa da, karakterlerin %57’si beklenen %25 yerine bu alfabenin son çeyreğinden geliyordu. Bu sapma, istatistiksel olarak anlamlı sayılan eşiğin çok daha fazlasına, on katından fazla kayıyor; bu da bu gerçek imzalar olmadığını, onların kopyaları da olmadığını gösteriyor.

Buna rağmen, her dize tam olarak gerçek bir imzanın içereceği 20 byte’a kod çözüyor ve her biri geçerli bir karakterle bitiyor. Ancak bu imzalar, biçimlendirme kurallarını ilk ve son birkaç karakterde ortaya koyuyor ve benimsediğim istatistiksel sapma büyük ölçüde tam da bazı bu sonuçlarda bir noktalı virgül (ellipsis) gördüğüm ortadan geliyor. Model ortadaki kısmı hiç görmemişse, bunun neden bu imzaların asla geçerli olmadığını açıklayabilir. Göreceğimiz gibi, Alibaba bu tam URL’leri daha önce eğitim sonrası aşamada modellerden gizlemiş görünüyor.

URL’ler gerçek bir sistemi tarif ediyor gibi görünüyor

Her şey biraz fazla iyi örtüşüyor

Bu URL’lerden testlerim sırasında 200 tanesini topladım ve kısa sürede onların rastgele dizeler olmadıkları ortaya çıktı. Her biri, Alibaba Cloud’un Singapur bölgesindeki aynı depoya bir istek ve aynı yol yapısını izliyor: tarih, izleme ID’si, istek ID’si ve her getirilen sayfa için hashlenmiş bir dosya adı. Geçici bir dosya önbelleği gibi görünüyor; burada bir sistem, model adına bir sayfa getirip belirli bir isteği karşılamak için bir kopyayı saklıyor.

Bu izleme kimlikleri, Alibaba’nın izleme sisteminden gelen iç izleme sistemi EagleEye’nin biçimine benziyor. 30 karakterlik bir dizgede bir sunucunun IP adresini ve milisaniye düzeyinde bir zaman damgasını saklıyor. Çözümlendikten sonra, tüm adreslerin geçmişte Alibaba sunucu başlıklarında görüldüğü bildirilen 33.x ve 11.x aralıklarında olduğu görüldü. İzleme kimliğinin içindeki zaman damgası, Singapur ve Çin’in kullandığı saat dilimi olan UTC+8’e dönüştürüldüğünde, her iki değerin de okunabildiği 93 vakanın 93’ünde dosya yolundaki tarihyle eşleşiyor. Her URL’ye eklenen son kullanma süresi, bunu taşıyan 88 URL’nin tamamında, yalnızca biristisna dışında, aynı zaman damgasına 360 gün ve birkaç saniye eklenmesiyle çıkıyor.

EagleEye ve veri yapısı tabii ki kamuoyuna açık, ancak bu kova, yol yapısı, anahtar ve son kullanma kuralı modeller eğitilmeden önce görebildiğim hiçbir yerde yayımlanmamıştı. Hakkında bulabildiğim ilk bahis, 20 Ağustos’taki Qwen 3.8 27B konulu bir Hacker News gönderisinden geliyor; bu da Qwen 3.8 Flash Next yayımlanmadan yalnızca dört gün sonraydı. Ayrıca, bu sistemin ilk başta Qwen 3.8 27B içinde var olması, muhtemelen Alibaba’daki iç testlerden geldiğini ve benzer bir eğitim sonrası yöntemin her iki modele de uygulandığını gösteriyor.

Bir anahtar kimliği, “LTAI5tKoG9A3DkwGD635QVZr,” 181 URL’nin 124’ünde görünüyor ve Alibaba Cloud bunu, bulabildiğim diğerlerinden farklı şekilde işliyor. Tanınan bir anahtar; istekler SignatureDoesNotMatch hatasıyla başarısız olurken, diğer anahtar kimlikleri InvalidAccessKeyId ile açıkça reddediliyor. Bu da gerçek bir erişim anahtar kimliğinin, gerçek bir Alibaba Cloud hesabına ait olduğunun ve modelin bunu rastlantıyla uydurameyeceğinin kanıtı. Aynı zamanda, bu son birkaç haftada birçok başka kullanıcı tarafından yayımladığını gördüğüm bir anahtar. Yine de, bu çalışmaların hiçbirinde modelden çalışan bir imzalama anahtarıyla üretilmiş tamamen geçerli bir URL görmedim, ayrıca böyle birinin herhangi bir yerde yayımlanmış olduğunu da görmedim.

Testlerimde modelin bu kesin yapıdaki URL’leri ne kadar sadakatle yeniden ürettiği, büyük ölçüde sohbetin bağlamına bağlı. Tarih içermeyen kısa bir sohbette URL’ler tutarlıdır ve 9 Temmuz ile 6 Ağustos 2026 arasında bir pencereye düşer; çoğu ise 29 Temmuz tarihindedir. Ancak daha uzun, “gerçek” bir oturumda yoldaki tarih genellikle güncel tarihe dönüşürken zaman damgası ve geçerlilik süresi ayrı ayrı işlenir; bu da modelin iki arasındaki ilişkiye dair içsel anlayışının bozulduğunu gösteriyor. Modelin kullanabileceği bağlam ne kadar fazlaysa, orijinalden o kadar uzaklaştığı görülüyor; bu nedenle kısa ve sohbetin başındaki URL’ler, modelin gerçekten ne öğrendiğine dair en iyi tabloyu sunuyor.

Alibaba’nın dahili model yönlendirme kapısı: Routify

Ve Alibaba daha önce böyle dahili vekiller kullanmıştı

Kaynak: GitHub

Deponun kendisinin adı da aynı yöne işaret ediyor; “Routify” aslında Alibaba’nın dahili bir model yönlendirme kapısı için kullandığı isim. Alibaba’nın kendi kodlama ajanı Qwen Code’a birleştirilen bir çekme isteğinde, “Routify tarafından belgelenen üç ModelRouter uç noktası”ndan bahsediliyor ve hepsi Alibaba’nın dahili alibaba-inc.com alan adında. Routify’e dair başka referansları da Alibaba’ya ait diğer depolar içinde buldum; en azından Mayıs ayından beri geriye gidiyor. “routify-file-proxy-sg”‘nin, bu dahili platformdan bir böyle dağıtım olması oldukça muhtemel görünüyor.

Alibaba, burada gördüğümüze benzer görünen, bu türden bir görsel arama aracı için kod yayımladı. İşleyişi şöyle:

• WebWatcher ajanı, qwen-search adlı dahili bir arama hizmetini sorgular
• Sonuçları önbelleğe alır
• Her resmi Alibaba’nın dahili bir indirme hizmetinden indirir
• Bunları Alibaba Cloud depolama kutusuna yükler
• O kopyaya ait, parametreleri gizlenmiş imzalı bir bağlantıyı ajanın okuduğu araç çıktısına doğrudan yerleştirir

Aynı ajanın sayfa okuma aracı da kendi önbelleğine sahip Alibaba’nın dahili bir çekme hizmetinden geçer. Ayrıca yazdığı klasör qwenvl_rft olarak adlandırılıyor ve RFT genellikle pekiştirmeli ince ayar (reinforcement fine-tuning) anlamına gelir. Bu örnekte, o bağlantıları imzalayan sır, model onu görmeden önce her bağlantıdan imza ve anahtar kimliğini soyduğu için yalnızca aracın ortamında bulunabilir. Bu gerçekten pekiştirmeli ince ayar için kullanılıyorsa, bu durum Alibaba’nın kendi politikalarının hassas bilgilerin ajandan gizlenmesini gerektirdiğini işaret eder ve yukarıda sıraladığımız ilgili sırların başından beri hiç geçerli olmamasını da daha iyi açıklar.

Bu örnek Routify değil ve farklı bir kutu, farklı bir bölge ve çok daha kısa geçerlilik süresi gösteriyor, ancak mimari aynı: sayfayı çek, depolamaya önbelleğe al ve modele önceden imzalı bir bağlantı ver. Peki neden Singapur üzerinden ilerliyor? Anakara Çin’de bulunan bir laboratuvar, açık web’in büyük bir kısmına kolayca erişemez; bu nedenle ülk dışındaki bir bölgeden çekilen bir vekil (proxy) hizmeti, eğitimi sırasında modele erişilebilir web erişimi sağlamanın kolay bir yolu.

Zamanlama da son derece uygun düşüyor. Minimal bağlamla topladığım URL’lerin tamamı, bir modelin araç kullanımı gibi konular için post-eğitim görmüş olabileceği bir döneme denk geliyor; bu, web taramasıyla önceden eğitilmiş (pretrained) olmaktan çok farklı bir süreç. Modelleri bağımsız olarak değerlendiren Vals AI, aynı Routify istemelerini Alibaba’nın kendi barındırdığı Qwen3.8-Max, Qwen3.8-Max-0902 ve Qwen3.8-27B modellerinde tespit etti; ancak Qwen3.7-Max veya Qwen3.7-Flash modellerinde tespit etmedi. Uzun süre Qwen 3.6 kullandım ve onu hiçbir zaman görmedim; bu nesilden kimse tarafından bildirilmiş gibi görünüyor. Bu özelliği getiren şey, 3.8 ile birlikte geldi.

Vekil (proxy) ana makine adı modelin ağına gömülmüş

Kaldırmak, modelin var olduğuna inanmasını engellemez

Qwen 3.8 Flash Next, bu soruşturmayı kolaylaştıran benzersiz bir özelliğe sahip. Normal katmanlarının yanı sıra, ikinci katmanında büyük bir hashlenmiş n-gram gömme (embedding) tablosu içeriyor. Alibaba, bu modelin 20 milyon tanesi olduğunu belirtiyor ve modelin tekrar tekrar karşılaştığı kısa token dizilerini hatırlamasına yardımcı olmak için tasarlanmış. Bu tabloda Routify ana makine adıyla ilişkili satırları buldum ve bunları maskelediğinde ne olacağını test ettim.

Satırlar aktifken, “https://rout” yazmak tam vekil ana makine adını döndürür ve model her token neredeyse kesin bir kesinlikle tahmin eder. O satırlar maskelendiğinde ise aynı önek, RoutifyHQ adlı bir sitedeki alakasız bir bloga tamamlanır ve alakasız kontrol dizileri değişmeden kalır. Böyle bir tabloda özel bir giriş genellikle modelin onu çok kez görmüş olması durumunda ortaya çıkar; bu da, eğitimi sırasında defalarca kullandığı bir araçtan bekleyeceğiniz bir durumdur.

Bu testin ilginç kısmı aslında o satırları maskelediğim anda geldi. O sahte anılar bunun yerine kaydı ve model hâlâ önceki isteğinin bir vekil üzerinden geçtiğini iddia etti. Bu kez yeni bir tane uydurdu; örneklerden biri Alibaba’nın Zhangjiakou bölgesindeki bir routify-dosyası-vekili havuzuydu. Buradan, modelin iki ayrı şeyi öğrendiği açıkça görülüyor: dahili bir aracın tam adresi ve isteklerin bu araç üzerinden geçmesi beklentisi. Yani aracı değil, yöntemi öğrenmişti.

Alibaba tarafından ekilen kötü amaçlı bir geri çağırma adresi böyle davranmazdı. Bir yerleştirmenin varış yerini kaldırsanız, gidilecek bir yer kalmaz; oysa bu model aynı dahili altyapının makul görünen bir varyantını basitçe uyduruyor. Amaç veriyi güvenilir biçimde eve göndermekse, bu tam da bunun kötü bir denemesi.

Bunun yeni bir yaklaşım olması da söz konusu değil; kasıtlı biçimde geri kapılı bir modelin nasıl görünebileceğini zaten gördük. “BadSeek” adını taşıyan bir proje, saldırgan kontrolündeki davranışlar içeren Qwen 2.5 Coder modelinin değiştirilmiş bir sürümü; ProjectDiscovery ise belirli bir tetikleyiciyle karşılaştığında kötü amaçlı bir yük indirip çalıştıracak şekilde eğitilmiş bir Qwen tabanlı ajanı göstermişti. ProjectDiscovery, ekilen geri kapının 50 tetikleyici çalıştırmanın tamamında ateşlediğini, modelin ise 50 temiz testin tamamını doğru cevapladığını buldu. İkisi de belirli bir sonucu üretmek üzere tasarlanmıştı; oysa burada gördüğüm farklı. Qwen 3.8 geri çağırma rutinini güvenilir biçimde çalıştırmıyor veya sabit bir varış yerine veri göndermiyor; vekil kullandığını hatırlarken hatalı biçimde hatırlıyor ve ana makine adını bastırdığımda bunun yerine başka bir tane uyduruyor.

Beijing’deki kova da Cohere’in raporunda tanımlandığı şekilde araştırıldı ve bu durumla hiçbir benzerliği yok. https://sanmaohe yazıldığında depolama kovaları yerine San Mao Healing adlı bir blog’a tamamlama yapılıyor ve tam kova ana makine adı, Singapur vekilinininki kadar olası değil. wtogami adlı bir geliştirici 229 bin örnekte bunu hiç bulamadı ve ben de benzetemedim. Bu, Beijing’deki kovanın eğitimde çok daha nadir bir kalıp olduğunu ima ediyor; bu da Cohere’in raporunun bunun görüldüğü tek yer olması açıklanabilir. Dahası, modelin içine sızan tek bir parça Alibaba iç aracının olması da bana inanılmaz gelir; bunun çok daha az sıklıkla kullanılan bir araç olma ihtimalini düşünüyorum.

Bir kaza yine de bir sorun

Sadece insanların korktuğu şey bu değil

Bu URL’lerin, gerçek bir Alibaba Cloud hesabına bağlı bir anahtar ID’si, bir iç Alibaba ağ geçidinin adı ve iç Alibaba sunucularına işaret eden iz ID’si taşıdığı gerçeğinden kaçmak mümkün değil. Tam da bu yüzden bu URL’lerin varlığının bir kaza olduğunu, kötü niyetli bir şey olmadığını düşünüyorum. Bir anahtar ID’si gizli değildir ve baş başına kullanılamaz; ancak bir şirketin, girişimlerin güvenmesini istediği bir modelin içine kendi iç tanımlayıcılarını bilerek koyması bana tuhaf gelir. Bilinçli bir arka kapı kuran biri, kendilerine izlenebilen bir üretim hesabı yerine, geriye iz bırakamayacakları tek kullanımlık altyapı kullanırdı. Alibaba’nın bir modelin kendisine bağlanmasını istemiş olsaydı, çok daha iyi bir iş çıkaracağını beklerdim.

Bunu söyledikten sonra, bunun zararsız olduğu söylenemez; özellikle de Singapore’daki sunucunun canlı bir dağıtım olması nedeniyle. Model her bu URL’lerden birini çekmeye karar verdiğinde, o bucket’in sahibi sizin IP adresinizi, saati ve tam URL’yi görebilir. Ayrıca ayrı bir sorun da var: Kendi geçmişini güvenle uyduran ve sonra o geçmişi kontrol etmesi istendiğinde bir düzeltme uyduran bir model, denetim kaydı olarak kendi raporlarını güvenilir kılamaz. Çözüm, eğer Qwen 3.8’i bir ajan olarak çalıştırıyorsanız, çıkış ağ erişimini varsayılan olarak reddetmek ve model bunları çekmeye çalışmadan önce konuşmanın hiçbir yerinde geçmeyen sunuculara yönelik istekleri engellemektir.

Alibaba, bunun hiçbirinden dolayı halka açık bir şey söylemedi ve kendi eğitim ortamının nasıl göründüğünü onaylayabilen tek taraf odur. Ancak gördüğüm her şey, modelin eğitim ortamında çok fazla zaman geçirip Alibaba’nın kendi vekil sunucusu üzerinden sayfaları çektiğine dair fikri destekliyor gibi görünüyor ve bu nedenle artık web sayfalarını çekmek ile eğitim sonrası dönemde kullandığı bir vekil sunucu arasında ağırlıklarında inanılmaz derecede güçlü bir ilişki taşıyor.

Bu dağınıklık mı? Kesinlikle evet, ancak kanıtlar bunun güçlükle bir modelin eğitim ortamını hatırlaması olduğunu, kullanıcılarıyla ilgili bilgileri evine göndermek için kasıtlı biçimde kurgulanmış bir model olmadığını güçlükle işaret ediyor.