【Yunqi Gözlemleri】Modeller Güçlenirken Context Neden Daha Değerli Hale Geliyor — Yunqi Konferansı 02

Bu Yunqi Konferansı’nda Qoder’ın sahada dile getirdiği bir söz şöyleydi:

Model gücü bir emtiadır. Context ise varlıktır.

Bu sözün Qoder’ın resmi sloganı olmadığını, sahada paylaşılan yönetsel bir bakış açısını (üretici firmanın özeti, orijinal ifade üretici firmanın sahadaki sunumuna göre belirlenir, aşırı yorumlanmamalıdır) yansıttığını unutmayın. Ancak bu söz, giderek yaygınlaşan bir trendi vurucu bir şekilde ifade ediyor: Modeller güçlenip modele erişim门槛ı düştükçe, bir AI ürününün gerçekten az bulunan kısmı yukarı doğru kayıyor. Kurumlar ve karmaşık uygulamalar için bu katman giderek daha çok Context’e benziyor.

Önceki “Yunqi Gözlemleri” yazısında (Yunqi Konferansı 01, üçüncü bölüm) bu değerlendirmenin yönü zaten işaret edilmişti—Qoder kod depolarını Wiki, Memory ve Knowledge Cards olarak sunuyor; QwenWork Enterprise Context’i vurguluyor; OpenSearch uzun süreli bellek ve context sıkıştırma üzerine odaklanıyor; üç üretici firma Yunqi’de aynı yönde yakınsıyor. Bu yazıda Context’i ayrı bir başlık olarak ele alarak, nasıl bir kerelik Prompt ekinin ötesine geçip AI sistemlerinin uzun vadeli varlığı haline geldiğini, ayrıca bunun beraberinde getireceği yeni mühendislik, yönetişim ve organizasyonel sorunları inceliyoruz.

一、模型知道世界，却不知道”我们这里到底怎么做”

Genel modeller artık büyük miktarda kamusal bilgiye sahip ve giderek karmaşıklaşan çıkarımlar yapabiliyor. Ancak iş dünyasının bu modellerden gerçekten yapmasını istediği şeyler çoğu zaman yoğun şekilde yerel bilgiye bağımlı.

Bir Kodlama Aracısı’nın mevcut kod tabanının mimarisini, kurallarını, geçmiş hatalarını, modül ilişkilerini ve yayın süreçlerini bilmesi gerekiyor. Bir Kurumsal Aracı’nın organizasyon yapısını, yetkileri, standart işlem prosedürlerini, proje durumunu, müşteri bilgilerini, dahili belgeleri ve iş kurallarını bilmesi gerekiyor. Bir e-ticaret içerik Aracısı’nın marka yönergelerini, SKU bilgilerini, ürün orijinallik kısıtlamalarını, hedef pazarı, geçmiş reklam performansını ve platform kurallarını bilmesi gerekiyor. Bir Araştırma Aracısı’nın geçmişte ne aradığını, hangi kaynakların güvenilir olduğunu, hangi değerlendirmelerin artık geçersiz kaldığını ve mevcut araştırma görevinin kanıt standartlarının ne olduğunu bilmesi gerekiyor.

Bu bilgiler model yükseltmeleriyle birlikte otomatik olarak tamamlanmıyor.

Bu nedenle birçok Aracı ürünü dikkatini “sürekli kullanılabilir bir Context nasıl oluşturulur” sorusuna yöneltmeye başladı. Context artık tek seferlik bir Prompt’un eki değil, uzun vadeli bakım gerektiren bir sistem haline geldi.

Kurumsal AI pilot projeleri yürütürken en sık karşılaştığımız başarısızlık kalıbı tam da bunu kanıtlıyor: Model her seferinde son derece zeki, ancak sistem bütünüyle kısıtlayıcı. Dosyaların yeniden yüklenmesi, marka gereksinimlerinin yeniden tanımlanması, proje bağlamının yeniden açıklanması ve geçmiş kararların yeniden gözden geçirilmesi gerekiyor. Bu darboğazları ortadan kaldırdığınızda, model yetenekleri ancak gerçek anlamda devreye girmeye başlıyor.

İki, Qoder Context Mühendisliğini Sistemleştiriyor: Knowledge Engine “Kod Deposu”nu Yeniden Tanımlıyor

Geleneksel kod depoları temel olarak dosya ve dizin yapısı olarak kavranıyordu. AI Coding çağında ise kod depoları, makinelerin okuyabileceği ek bir anlamsal katman gerektirmeye başladı.

Qoder’ın canlı demoda sunduğu birkaç bileşen, farklı Context mühendisliği sorumluluklarını üstleniyor (tedarikçi sınıflandırması, orijinal dokümantasyon referans alınmalıdır): Repo Wiki proje yapısını ve modül açıklamalarını oluşturuyor, Knowledge Graph modüller arası bağımlılıkları ve sözleşmeleri ifade ediyor, Memory oturumlar arası kısıtlamaları, tercihleri ve geçmişi saklıyor, Knowledge Cards ise mevcut görevle ilgili bilgileri doğrudan Agent’a beslenebilir bir Context paketi halinde organize ediyor.

Değeri aktarmaya değer olan, bu dört şeyin arkasındaki değerlendirmedir: Context mühendisliği sonrasında her yeni görev, tekrarlanan okumalardan oluşan bir kaynak kod deposundan değil, yüksek sinyal-gürültü oranına sahip bir Context paketinden başlar.

Bir Agent her görevde tüm kodları yeniden tararsa, tüm belgeleri yeniden okursa ve mimariyi yeniden tahmin ederse, model ne kadar güçlü olursa olsun büyük miktarda hesaplama kaynağı boşa harcanır ve sonuçlar son derece tutarsız olur. Daha akılcı bir yapı şudur:

Ham Veri → Yapılandırılmış Bilgi → Göreve Özgü Context → Agent

Göreve Özgü Context, yalnızca mevcut görev için gerçekten gerekli olan içeriği çıkarır ve kaynak, sürüm ve kısıtlamaları yanında taşır.

Amap (Gaode) ekibi, milyonlarca satır koddan alan bilgisini geri çağırılabilir bir varlık haline getirdiğinde, görev tek seferde geçme oranı %37,3’ten %61,5’e yükseldi. Bu, Context-as-Asset mühendisliğinin kanıtıdır (veriler tedarikçi vakasından alınmış olup, Qoder Bilgi Motoru’nun bu müşteride gerçek ölçüm sonuçlarıdır; sektör karşılaştırması dikkatli kullanılmalıdır; aynı argüman önceki “Yunqi Gözlemleri 01” makalesinin altıncı bölümündeki organizasyonel değerlendirmede de geçmektedir).

Üçüncü Bölüm: QwenWork, Bağlamı Kod Tabanından Kurumsal Düzeye Taşıyor

QwenWork’in Yunqi etkinliğindeki demosu, bağlamı kod tabanından tüm kurumsal yapıya taşıma konusunda bir adım daha ileri gidiyor.

Legal Document Fill Out ve Marketing Content Generation, ilk bakışta sıradan görevler gibi görünüyor. Asıl dikkat edilmesi gereken nokta, Agent’ın kurumun kendi kurallarını ve kaynaklarını nasıl bildiği.

Bir yasal belge Agent’ı, kurumsal şablonları, onay kurallarını, sözleşme alanlarını ve yetkilendirmeleri bilmiyorsa, yalnızca makul görünen bir belge üretebilir. Bir Pazarlama Agent’ı, marka materyallerini, geçmiş Kampanyaları, hedef pazarları, marka tonunu ve ürün bilgilerini bilmiyorsa, kullanıcıdan sürekli olarak bağlamı yeniden açıklamasını istemek zorunda kalır.

Bu, birçok AI aracının şu anda karşılaştığı en belirgin sorun: Kullanıcılar her seferinde Bağlamı (Context) yeniden sağlamak zorunda kalıyor (bu gözlem tedarikçi yönlendirmesine dayanmaktadır; kesin ifade için Yunqi etkinliği basın bültenini referans alın).

Uzun vadede gerçek değer taşıyan bir AI Workspace, bu tekrarlayan açıklamaları kalıcı varlıklara dönüştürmelidir. Dosyaları her seferinde yüklemeye gerek olmamalı, marka gereksinimleri her seferinde tanımlanmamalı, proje bağlamı her seferinde açıklanmamalı, geçmiş kararlar her seferinde tekrarlanmamalı. Model değiştirilebilir, sistem her seferinde sıfırdan başlamamalı.

Dördüncü Bölüm: Context’in Değeri ‘Sürekli Biriktirmek’ten Gelir, ‘Daha Fazla Tıkıştırmak’tan Değil

Müşterilerimize AI Coding uygulamalarında eşlik ederken, özellikle şu soruyu sorarız: “Üç yıl sonra bu platformu değiştirirseniz, Context varlıklarınızı taşıyabilir misiniz?” Bu soru, QwenWork gibi kurumsal Context platformları için de aynı derecede geçerlidir. Altıncı bölümde Anti-lock-in değerlendirmesini detaylandıracağız.

Context’in Değeri ‘Sürekli Biriktirmek’ten Gelir, ‘Daha Fazla Tıkıştırmak’tan Değil

Context konuşmalarında sıklıkla düşülen bir tuzak vardır: Bağlam penceresi ne kadar büyük olursa o kadar iyi, tüm belgeleri içine tıktıralım.

Pratik sistemlerde ise daha fazla Context her zaman daha iyi demek değildir. Alakasız bilgilerin bolluğu hem Token maliyetlerini artırır hem de dikkat yoğunluğunu seyreltir. Farklı versiyonlardaki belgeler aynı anda mevcut olduğunda, model hangi kuralın hâlâ geçerli olduğunu ayırt edemez hale gelebilir.

Dolayısıyla Context Engineering’in asıl çözmesi gereken iki temel sorun var: Ne korunmalı ve Ne unutulmalı.

Ne korunmalı — Sohbet geçmişi, doğal olarak uzun vadeli bellek anlamına gelmez. Korunması gerekenler; kararlar, kısıtlamalar, kanıtlar, başarısızlık nedenleri, istikrarlı tercihler ve yeniden kullanılabilir yöntemlerdir. Ödeme sistemindeki bir değişiklik için tüm pazarlama bilgi tabanına ihtiyaç yoktur; SEO araştırması da tüm sunucu loglarına gereksinim duymaz.

Neyi Unutmalı — Context’un mutlaka sürüm, zaman, kaynak ve durum bilgilerini içermesi gerekir. Artık kullanımdan kaldırılmış bir mimari karar, Agent tarafından halihazırda çağrılmaya devam ediyorsa, uzun vadeli bellek hataları daha da büyütebilir. Uzun süreli görevler, bağlamı sürekli özetlemeyi ve yeniden yapılandırmayı gerektirir; kritik durumları korurken artık değeri olmayan detayları atmak şarttır.

İşte bu yüzden bu seferki Cloud Village OpenSearch Agentic Search Forum’u özellikle Görev Belleği (Task Memory), Uzun Vadeli Bellek (Long-term Memory) ve Bağlam Sıkıştırma (Context Compression) konularına dikkat çekti. Alibaba Cloud OpenSearch’in orada sunduğu “Retrieval—Action—Memory—Knowledge” kendi kendine dönen çerçevesi (üretici özeti baz alınmıştır, Cloud Village bültenine sadık kalınmıştır), özünde aynı soruyu yanıtlamaktadır: Hangı Memory’ler uzun süre kullanılmalı, hangileri görev sonunda sıkıştırılmalı, hangileri ise artık geçersiz olup aktif olarak unutulmalıdır.

五、Memory Yalnızca “Kullanıcının Ne Dediğini Hatırlamak” Değildir

2025 yılı Aralık ayında yayımlanan Memory in the Age of AI Agents başlıklı derleme (Tsinghua University, National University of Singapore, Fudan Üniversitesi gibi kurumlardan 46 yazarlı ortak imzalı arXiv derlemesi) daha sıkı bir sınıflandırma öneriyor: Memory artık basitçe “kısa süreli/uzun süreli” ikiliğine ayrılamaz; bunun yerine Forms (Token düzeyi / Parametrik / Latent), Functions (Faktüel / Deneyimsel / Çalışma) ve Dynamics (Oluşum / Evrim / Gerialım) olmak üzere üç boyutla birlikte tanımlanmalıdır — bu, Context-as-Asset kavramının akademik alandaki en güncel yorumudur.

Beşinci Bölüm: Memory Yalnızca “Kullanıcının Söylediklerini Hatırlamak” Değildir

Pek çok AI ürünü Memory’yi kullanıcı tercihleri olarak algılıyor; örneğin dil tercihini, ismi veya sık kullanılan formatları hatırlamak gibi. Elbette bu değerli bir özelliktir, ancak bir Agent için kesinlikle yeterli değildir.

Gerçek anlamda bileşik getiri sağlayabilecek Memory, Task Memory ile çok daha fazla örtüşmektedir.

Karmaşık bir görev tamamlandıktan sonra, sistem şunları bilmelidir: Görev sonunda nasıl parçalara ayrıldı; hangi arama yolları etkili oldu; hangi araçlar başarısız oldu; hangi veriler güvenilir; hangi sonuç kullanıcı tarafından kabul edildi; neden kabul edildi; hangi adımlar bir Skill olarak soyutlanabilir; hangi hatalardan kaçınılmalı.

Eğer sadece tüm sohbet geçmişini Embedding yapıp bir sonraki turda geri alırsanız, Memory kolayca devasa bir geçmiş metin deposuna dönüşür. Geri alınan “ilgili parçalar” gerçekten ilgili olmayabilir ve modelin yanılma olasılığı artar.

Memory’nin gerçekten ihtiyaç duyduğu şey, özümseme, değerlendirme ve yapılandırmadır. Aksi takdirde Context ne kadar birikirse biriktirsin, bir sonraki karar o kadar belirsizleşir.

Context da Yeni Bir Lock-in Oluşturabilir — Anti-lock-in İçin Beş Soruluk Seçim Kontrol Listesi

Context ne kadar kritik hale gelirse, yeni platform kilitlenmesinden o kadar dikkatli olmalıyız.

Bir kuruluşun tüm geçmiş kararları, Workflow’ları, Agent Memory’leri, Skill’leri ve kullanıcı geri bildirimleri kapalı bir platformda depolanıyorsa, modeli değiştirmek kolay olabilir ama Context’i taşımak çok zordur. Bu, model değişiminden çok daha gizli bir uzun vadeli maliyettir.

Müşterilerimize teknik seçim sürecinde yardımcı olurken, özellikle şu soruyu sorarız: “Üç yıl sonra bu platformu değiştirirseniz, Context varlıklarınızı götürebilir misiniz?” Bu soruyu yanıtlayamayan çözümlerden kaçınılmalıdır.

AI平台是否会”锁死”企业？——五个关键判断问题

判断一个AI平台是否会限制企业的灵活性，需要从以下五个关键问题入手：

一、导出能力。 Task History、Decision Log、Knowledge Base、Skill Definition、Evaluation Result、Tool Configuration、Permission Mapping——这些Context资产是否支持以通用格式导出？这直接决定了更换平台时，是实现平滑迁移还是需要从零开始重建。

二、版本追溯。 导出的Context是否包含版本信息、时间戳、数据来源和处理状态？一份没有时间戳的Knowledge Card，三年后根本无法追溯其当时的制定依据和背景。

三、模型无关性。 Context是否能够被不同的AI模型所使用？如果某个Context只能被特定模型解释，那么本质上它仍然被绑定在单一供应商的技术生态中。

四、数据跨境与合规审查。 Context数据存储在境外服务器时，是否会触发数据出境审批流程，以及GDPR/CCPA/PIPL等相关数据保护法规的合规义务？对于金融、医疗等强监管行业，还需要满足本地化数据中心部署的强制性要求。这一项若不通过，前述四项的努力都将付诸东流。

Beş Soruda Yönetişim Sorumluluğu. Context’un kalitesinden kim sorumlu? Kimler değişiklik yapma yetkisine sahip? Süresi dolmuş içerikleri kimler eleyecek? Eğer yönetişim sorumlulukları net değilse, biriken Context’lar zamanla yeni bir organizasyonel borç haline gelir.

Bu beş sorunun alt çizgisi şu: Model değiştirilebilir, Runtime değiştirilebilir, ancak Context varlıkları mutlaka kendi kontrolünüzde kalmalı. Bu durum, AI-native kurumsal yazılımlar için yeni bir mimari sınır oluşturabilir.

Yedi, Dört Farklı Sektörde Context Birikimi Tamamen Farklı Biçimler Alır

Şimdiye kadar genel akışı ele aldık. Şimdi bu değerlendirmeyi somut kullanım senaryolarına taşıyalım.

Telekomünikasyon Operatörleri — Tarife değişiklikleri, kurumsal hat talepleri, çapraz bölgeli faturalama gibi ihtiyaçlar her seferinde BSS/OSS/CRM ve uyum denetimlerinin dört-beş farklı alanından geçer. AI uygulama katmanı kodunu belki iki kat hızlı yazar, ancak ara katman uyarlamaları, mutabakat mantığı ve uyum onayları bir gram bile azalmaz. Burada Context birikiminin odağı kod tabanı değil; geçmiş faturalama anomalileri, uyum kıstasları ve mutabakat kurallarıdır. Bu tür Context’lar açık kaynaklarda hemen hemen hiç örneği bulunmayan, kuruluşun gerçek anlamda rekabet avantajıdır.

Finans ve Bankacılık — Çekirdek sistemler, risk kontrolü, kara para aklamayla mücadele ve denetlenebilir açıklık. Bu sürecin temel özelliği, her değişikliğin açıklanabilir, denetlenebilir ve geri izlenebilir olması gerektiğidir. Yapay zeka bir risk kontrol kuralı yazmak için saniyeler içinde hazır duruma gelebilir, ancak bu kuralın kurallar motoruna entegre edilmesi için model doğrulaması, açıklanabilirlik testi, düzenleyici standartlara uygunluk kontrolü ve dahili onay süreçlerinden geçmesi şarttır. Buradaki bağlam birikiminin, veri sınır ötesi transfer uyumluluğu (kişisel bilgilerin sınır ötesi transferi için standart sözleşme, KVKK değerlendirmesi) ve yerelleştirilmiş veri merkezi gereksinimlerini karşılaması gerekir; bu iki koşul sağlanmadan, önceden oluşturulmuş tüm bağlam varlıkları kullanılamaz hale gelir.

Üretim — MES, ERP, QMS ve raporlama sistemleri. Bir önceki bölümde belirtildiği gibi, üretim hattında yapay zeka kodlaması en sık “yerinde çalışıyor, entegre etmeye çalışınca çöküyor” senaryosuyla karşılaşır. Bağlam açısından aynı değerlendirme geçerlidir: atölye bilgisi, ekipman parametreleri, veri toplama standartları, PLC arayüzleri, görüntüleme sistemi versiyonları — bu bağlamların büyük kısmı ya usta işçilerin kafasında, ya eski PDF dosyalarında, ya da yarı yarıya güncel Excel tablolarında gizlidir. “Alan bilgisi birikimi kalitesi”nden sorumlu bir ekip yoksa, yapay zekaya sunulan bağlam kısa sürede güncelliğini yitirir veya birbiriyle çelişir. Bu, bir önceki bölümdeki beş soruluk kontrol listesinin üretim sektöründeki en somut uygulamasıdır.

E-ticaret — büyük kampanya hazırlığı, envanter tutarlılığı, hileli botlardan korunma, çapraz bölge mutabakatı. AI’ın bu sektörde edindiği Context; marka kuralları, geçmiş materyaller, platform düzenlemeleri ve kampanya değerlendirmeleridir. Bu Context türünün raf ömrü en kısadır — üç ay önceki viral içerik stratejisi, ikinci büyük kampanyada tamamen geçersiz olabilir. Dolayısıyla e-ticaret senaryosunda Context yönetiminin odağı “biriktirme” değil, “atma ritmi” olmalıdır.

Dört sektörün Context yapıları farklı olsa da ortak bir sonuç var: Context varlıklarının organizasyonel yönetimi, araç seçiminden daha önceliklidir.

Sekiz, Gelecekteki Karar ve Uygulamayı İyileştirecek Bilgiler Gerçekten Biriktirmeye Değer

“Context bir varlıktır” ifadesini daha ileriye taşıyacak olursak, daha katı bir değerlendirme kriterine ulaşırız: ne kadar çok saklanırsa o kadar çok varlık olmaz.

Yalnızca bir sonraki görevde belirsizliği azaltan, tekrar arayışını minimize eden, sonuç tutarlılığını artıran ve karar kalitesini iyileştiren bilgiler gerçek anlamda varlık oluşturur.

Bu nedenle AI ürünleri tasarlarken, müşterilerle birlikte mimari değerlendirmesi yaptığımızda sıklıkla şu soruları da sorarız:

Bu sistem her görevi tamamladığında geriye ne bırakıyor? Sadece sonuç mu, yoksa yeniden kullanılabilir yöntemler ve hata kayıtları mı?

Bir sonraki sefе doğrudan yeniden kullanılabilir mi? Eğer her seferinde sıfırdan açıklama gerekiyorsa, yeniden kullanım sadece bir laf düzeyinde kalır.

Hangi sonuçlar doğrulandı? Doğrulanmamış “deneyimler” birikerek AI’ın bir sonraki sefer aynı yoldan gitmesine neden olur.

Hangi başarısızlıklar sistematik olarak kaydedildi? Başarısızlık kaydı olmayan bir Context eksiktir.

Farklı bir modele geçersek, biriken değer korunur mu? Bu, bir önceki bölümdeki Anti-lock-in beş sorusunun uzantısıdır: Model değişikliğinde Context kaybolmuyorsa, gerçek bir varlık demektir.

Modeller sürekli ilerleyecek, API çağrı maliyetleri düşmeye devam edecek ve bugün güçlü görünen yetenekler bile çok yakında altyapı haline gelebilir. Gerçek anlamda bileşik getiri sağlayan unsur, modelin kendisinden ziyade onun dışındaki katmandır: Şirketin kendi Context’i, doğrulanan Workflow’ları ve uzun vadede biriken yargı ve geri bildirimler.

Karar Vericiler İçin Çıkarımlar: önümüzdeki Çeyrekte 3 İş

CFO’ya — “AI kaç saat tasarruf sağladı” söyleminden “onaylanan her görevden ne kadar yeniden kullanılabilir Context biriktiği” hesabına geçin. Aynı türden görevler üç farklı platformda çalıştırıldığında, biriken Context’in yeniden kullanım oranı 3-5 kat fark edebilir. Bu rakam “çağrı sayısı”ndan çok gerçek ROI’ye daha yakındır ve uzun vadeli varlıklara doğrudan işaret eder.

CIO/CDO’lar için — önümüzdeki çeyrekte AI platform seçim kriterlerinizi “model benchmark puanları / Token fiyatı” yerine Anti-lock-in Beş Soruluk Kontrol Listesi’ne (dışa aktarım / versiyon / model bağımsızlığı / uyumluluk / yönetişim sorumluluğu) çevirin. Bu kriterler 1-2 çeyrek boyunca uygulandığında, kuruluş doğal olarak Kontrol Edilebilir Bağlam talep etmeye başlayacaktır; kriterleri değiştirmezseniz, üç yıl sonra en pahalı maliyet model ücretleri değil, Bağlam taşıma işçilik saatleri olacaktır.

İş birimi yöneticileri için — “alan bilgisi birikimi kalitesi”nden sorumlu bir kişi veya ekip belirleyin. Bir önceki bölümdeki High精 örneğinin özü araç kurulumu değil, “Bağlam birikim kalitesi”nden sorumlu birinin olmasıdır. Araçları sadece ekibe bırakıp Bağlam kalitesini kimse sahiplenmezse, etki büyük olasılıkla yarıya düşer.

Muhtemelen Merak Ettiğiniz Sorular

S1: Bağlam varlıkları çok güzel görünüyor, ama küçük şirketlerde birikim için kim uğraşacak?

Özel olarak uğraşmak değil, birikimi mevcut süreçlere yerleştirmek. Her Issue kapatılmasında, her gereksinim değerlendirmesinde, her kaza sonrası analizde “neden böyle yaptık, hangi tuzağa düştük” diye iki satır daha yazılabilir. Bir yıl sonunda bu, on binlerce kelimelik kurumsal bellek demektir. Asıl mesele iş saati değil, bunları resmi teslimat olarak görüp görmediğinizdir — “dökümantasyon takıntısı” değil.

S2: Agent platformları Memory ve Knowledge Cards öne sürüyor; bu sadece yeni şişeye eski şarap mı?

Bir kısmı yeni şişeye eski şarap, ama bir kısmı gerçekten yeni yönler—Task Memory, yürütme geçmişini aranabilir bir varlığa dönüştürüyor; Knowledge Cards ise alan bilgisini yapılandırıyor. Bu, geçmişte Prompt Library’nin çözemediği bir sorun. Ayrım yöntemi şu soruyu sorabilmektir: “Bu Memory’ye en son kim, hangi görevde, neden kabul etti/reddetti?” Buna cevap veremiyorsa, büyük ihtimalle eski şaraptır.

S3: Anti-lock-in’in beş sorusundaki ‘model bağımsızlığı’ çok mu idealist? Gerçek hayatta farklı modellerin yetenekleri çok farklı; model değiştirmek mutlaka kalite kaybına neden olur.

Evet, kısa vadede kesinlikle kalite kaybı yaşanır. Ama sorulan “sıfır maliyetle geçiş yapılabilir mi” değil; “geçiş maliyeti belirli bir tedarikçi tarafından mı kilitleniyor”. Dışa aktarabiliyor, format dönüştürebiliyor, sürüm tutabiliyorsanız, geçiş maliyeti hesaplanabilir bir mühendislik sorunudur. Dışa aktaramıyorsanız, geçiş maliyeti kontrol edilemez bir ticari risk haline gelir. Bu ikisi tamamen farklı şeylerdir.

Ters Öz-Denetim

Bu yazıyı olmayan bir güzelliğe boyamayın. Üç konuda dürüst olmak gerekiyor:

Birincisi, bu makale bir önceki “Cloud Observation 01” ile önemli bir yönsel örtüşme taşımaktadır — Qoder Knowledge Engine, QwenWork Enterprise Context, OpenSearch Task Memory, AutoNavi ekibinin tek seferde geçme oranının %37,3’ten %61,5’e yükselmesi ve Context varlıklaştırma değerlendirmesi her iki makalede de karşımıza çıkmaktadır. Bu makale yapısal olarak yeniden düzenlenmiş olsa da (Anti-lock-in beş sorusu altıncı bölüme öne alınmış, yönetişim sorumluluğu ve uyum boyutları eklenmiş, dört sektörel perspektif farklılaştırılmıştır), iki makaleyi art arda okuyanlar tanıdıklık hissedecektir. Bir sonraki Cloud Observation 03 yazısında bu örtüşmeden kaçınılacaktır.

İkincisi, makaledeki üretici vaka çalışmalarının oranı görece yüksektir. AutoNavi (高德), QwenWork Legal Document Fill Out ve OpenSearch Agentic Search olmak üzere üç temel argümanın tamamı Cloud Observation etkinliğindeki üretici değerlendirmelerinden veya üretici dokümantasyonundan derlenmiştir; bu durum üretici lehine bir bakış açısı oluşturmaktadır. Her bir alıntı ilgili açıklama paragrafında işaretlenmiş olup, argümantasyon sırasında üçüncü taraf akademik derlemelerle（《Memory in the Age of AI Agents》arXiv:2512.13564）çapraz doğrulama yapılmaya çalışılmıştır.

Üçüncüsü, Anti-lock-in beş sorusu şu an bir tasarım aşamasında olup, henüz doğrulanmış bir gösterge sistemi değildir. Gerçek kullanımda eklenmesi gerekenler: her sorunun spesifik ölçütleri, sektörün minimum eşik değerleri ve uyumluluk maddelerinin somut yönlendirmeleri. Bu yazıda verilen, bir değerlendirme yönüdür, uyumluluk kontrol listesi değildir. Müşteriyle birlikte geliştirme yapılacağı bir sonraki sefere bu eklemeler yapılacaktır.

Kaynaklar ve Kanıt Düzeyleri (Madde Madde Referanslar + Kanıt Hiyerarşisi + Perspektif)

#	Yazıdaki İddia	Kaynak	Tarih	Kim Söyledi	Kanıt Düzeyi	Duruş
1	Model gücü bir emtiadır. Bağlam ise bir varlıktır. (genel anlamıyla)	Qoder yerinde paylaşımı (üretici özeti, orijinal ifade yerinde doğrulanmalı)	2026-09-24	Qoder ekibi	Üretici İddiası	Üretici Duruşu
2	Qoder Knowledge Engine, Repo Wiki / Bilgi Grafı / Bellek / Bilgi Kartları içerir	Qoder Knowledge Engine tanıtım sayfası + önceki «云栖观察 01» üçüncü bölüm çapraz doğrulaması	2025-2026	Qoder ekibi	Üretici İddiası	Üretici Duruşu

| 5 | OpenSearch Agentic Search “Arama—Eylem—Hafıza—Bilgi” kendi kendine döngüsü + Task Memory / Long-term Memory / Context Compression | https://xie.infoq.cn/article/163b700cba024c8adb326ec5c（InfoQ Yunqi 2026 Raporu）+ https://docs.opensearch.org/3.6/vector-search/ai-search/agentic-search/agentic-memory + https://opensearch.org/blog/unpacked-at-open-source-summit-na-2026-inside-opensearchs-massive-leap-into-the-agentic-era/ | 2026-09 | Alibaba Cloud OpenSearch ekibi / OpenSearch projesi | Doğrulanmış gerçekler (üretici yayını + üçüncü taraf raporları) | Üretici / üçüncü taraf ortak |

Kademeli AI Öğrenimi #006

#	Konu	Kaynak	Tarih	Yazar/Kaynak	Doğrulama Türü	Not
6	Bellek Formları × İşlevler × Dinamikler Üç Boyutlu Sınıflandırması	https://arxiv.org/abs/2512.13564 (“AI Ajanları Çağında Bellek” araştırma özeti)	2025-12	Yuyang Hu ve 46 yazar (Tsinghua, NUS, Fudan vb.)	Doğrulanmış gerçekler (akademik inceleme)	Akademik çevre
7	“Context Engineering” Teriminin Yaygınlaşması	Sektörde Shopify, LangChain ve Anthropic dokümanlarında benimsenmiş (sektör genelinde kullanılan terminoloji, yazar tarafından derlenmiştir)	2024-2026	Sektör konsensüsü	Sektör gözlemi	—
8	Anti-lock-in Beş Sorulu Seçim Kontrol Listesi (dışa aktarım / versiyon / model bağımsızlığı / uyumluluk / yönetişim sorumluluğu)	Bu makalenin metodolojik sentezi (AI platform taşınabilirliği hakkındaki sektör tartışmalarına ve anonimleştirilmiş müşteri vaka çalışmalarına dayanmaktadır)	2026	Makale yazarı + sentez	Yazar çıkarımı	—

| 9 | Veri Çıkışı / Kişisel Bilgi Koruma Yasası / Sıkı Düzenlenmiş Sektörlerde Yerel Veri Merkezi Gereksinimleri | 《Kişisel Bilgi Koruma Yasası》 md. 38-39 + 《Veri Çıkışı Güvenlik Değerlendirme Yöntemi》 + Finans sektörü sıkı düzenleme gereksinimleri (açık düzenlemeler) | 2021-2026 | Ulusal İnternet Bilgi Ofisi / Çin Halk Bankası / Ulusal Finansal Düzenleme ve Denetim İdaresi | Doğrulanmış gerçekler (düzenlemeler) | Düzenleyici duruş |
| 10 | Dört Sektör Kategorisinde (Telekom / Finans / İmalat / E-ticaret) Context Biçimi Farklılıkları | Bu makalenin sektör gözlemleri (anonimleştirilmiş müşteri vakaları + kamuya açık tedarikçi vakalarına dayalı) | 2026 | Makale yazarı + sentez | Sektör gözlemi (anonimleştirilmiş) | — |
| 11 | “Üç yıl sonra bu platformu değiştirirseniz, Context varlıklarınızı taşıyabilir misiniz?” | Bu makaledeki değerlendirme sorusu (çeşitli sektörlerdeki AI platform göç deneyimine dayalı) | 2026 | Makale yazarı | Yazar çıkarımı | — |
| 12 | İmalat Sektöründe “Saha Testi Başarılı, Entegrasyon Başarısız” Fenomeni | Önceki “Yunqi Gözlemleri 01” Bölüm 6 + Hisense / Wens vakaları (kamuya açık tedarikçi vakaları) | 2025-2026 | Qoder / Alibaba Cloud Lingma / Hisense / Wens | Doğrulanmış gerçekler (tedarikçi vakaları, anonimleştirilmiş genişleme) | Tedarikçi / Müşteri ortaklığı |

Yerelleştirme Noktaları (Çok Dilli Çeviri Karşılaştırması, IAIUSE Çok Dilli Stratejisi·2026-08-09 Sözleşmesi)

19 dile çeviri yapılırken aşağıdaki içerikler hedef dilin pazarına göre yerelleştirilerek değiştirilir; yapı ve görsel sunum aynı kalır:

Çince Orijinal İçerik	İngilizce Versiyon	Japonca Versiyon	Almanca Versiyon	Arapça Versiyon
Qoder / Alibaba Cloud ürünleri	Qoder / Alibaba Cloud (ürün adları korunur)	Qoder / 明白雲	Qoder / Alibaba Cloud	Qoder / علي بابا كلاود
Feishu / DingTalk	Slack / Teams	Slack / Teams / Lark	Slack / Teams	Microsoft Teams
China Telecom / China Mobile / China Unicom	AT&T / Verizon / T-Mobile	NTT / KDDI / 소프트뱅크	Deutsche Telekom / Vodafone	STC / Etisalat

招商银行 / 工行	JPMorgan Chase / Bank of America	三菱UFJ / 三井住友	Deutsche Bank / Commerzbank	National Commercial Bank (Suudi) / QNB
比亚迪 / 宁德时代	Tesla / Ford / GM	トヨタ / 日産	Volkswagen / BMW	Saudi Aramco (üretim temsilcisi) / Tawuniya
高德地图 örneği	Google Maps / Mapbox örneği	楽天モバイル / Yahoo! Japonya haritası örneği	Here Technologies örneği	Careem / Google Maps MENA örneği
QwenWork / 通义千问	Tongyi / Qwen	Tongyi / Qwen	Tongyi / Qwen	Tongyi / Qwen

Açıklama: Yukarıdaki yerelleştirme maddelerinin yanı sıra, metindeki küresel ürünler/kavramlar (Repo Wiki, Knowledge Graph, Task Memory, Skill, Context Engineering, Anti-lock-in Beş Soru) oldukları gibi bırakılır. Diğer 15 dil için IAIUSE üç kademe stratejisi uygulanır: Öncelikli 5 dil (Çince/İngilizce/Almanca/Japonca/Arapça) yukarıdaki tabloya göre yerelleştirilir; bağımsız 9 dil (İspanyolca/Fransızca/Portekizce/Korece/Rusça/İtalyanca/Felemenkçe/Lehçe/Türkçe) Qoder/QwenWork orijinal adını korur + yerel temsilci kuruluşları değiştirir; İsteğe bağlı 5 dil (İsveççe/Tayca/Vietnamca/Ukraynaca/Endonezce) orijinal adı koruyup yer tutucu olarak bırakır.

Bu Seri Hakkında

「云栖观察」, IAIUSE tarafından sunulan bir endüstri saha serisidir. 2026 Yunqi Konferansı’ndan yola çıkarak, araştırmacı perspektifiyle AI endüstrisinde gerçekleşen değişimleri çözümlemektedir—haber peşinde koşmaz, yalnızca yatırım yapılan yönleri ve kanıtların gücünü değerlendirir.

Eğer kurumsal AI’a nereden başlanacağını, hangi Context varlıklarının öncelikli olarak biriktirilmesi gerektiğini ve model yükseltmeleriyle birlikte kaybolup gidecek一次性 Prompt’ların hangileri olduğunu değerlendiriyorsanız, bizimle iletişime geçmekten çekinmeyin. Üç temel hizmet sunuyoruz:

Kurumsal Eğitim (AI çağında Ar-Ge ve operasyon ekiplerinin dönüşümü; 2-3 günlük atölye çalışması ile Context varlık envanteri, Anti-lock-in beş sorusu ve ölçüm sistemlerini kurumunuza taşıyın)
Özel Danışmanlık (Context varlık envanteri, Workflow yeniden tasarımından ölçüm sistemlerine kadar, “model yeteneklerini” “kurumsal kapasiteye” dönüştürmenize yardımcı oluruz)
Yönetici Paylaşımları ve Sektör Konuşmaları (Karar vericiler perspektifinden AI Context gerçeği ve Anti-lock-in seçim kriterleri)

Önce 90 dakika görüşüp yönü görmek isterseniz, hafif bir danışmanlık görüşmesi ayarlamaktan memnuniyet duyarız. İşbirliği e-postası: [email protected]

Ek Okuma: 《AI Dönüşümü Yedi Adımlı Çerçeve》, kurumsal AI uygulamasının tam yol haritasını sistemli bir şekilde açıklar.

系列覆盖模型之上的系统层、Agent落地、Context资产、企业AI组织设计、AI产品竞争单位迁移等话题，共约10篇。

本系列研究资料库累计超过200篇公开研究与行业案例。本篇依据的证据来自三个层级：现场厂商分享（Qoder / QwenWork / OpenSearch）、第三方独立研究（《Memory in the Age of AI Agents》arXiv:2512.13564等学术综述）、合作客户脱敏案例。其中厂商案例占比偏高，引用时已在引用说明段标注立场。

我有近8年大型企业咨询与商业分析经验，曾任职于IBM，参与过电信、金融、保险和制造业相关项目。此后继续在运营商产品、互联网产品和AI应用开发一线，从事需求分析、产品设计和跨团队落地。这个号背后其实是一个小团队——我和1-2位长期协作的同事，分头负责AI编程工具研究、组织治理案例梳理、教练对话这几块。文中”我们陪企业蹚过”的多数项目，是我们几位共同交付过的。

本系列的判断来自我的现场观察和行业交叉验证，带有明确的作者立场，不代表任何厂商观点。