Bağlam Mühendisliği, Yapay Zekâ için Yeni Sistem Tasarımıdır

Gözümüzün Önünde Yaşanan Bir Mimari Dönüşüm Var

Son birkaç yıldır çoğu kişi yapay zekâyı bir API gibi ele alıyor.

Bir istem gönderiyorsunuz, bir yanıt alıyorsunuz; eğer kendinizi gelişmiş hissediyorsanız bunu yeniden denemeler ve biraz günlüklemeyle sarmalayıp adına sistem diyorsunuz. Bu, demolar için işe yaradı. Bu sayede bu dalga bu kadar hızlı sevk edildi. Ancak bu desen, zaman içinde çalışması gereken bir şey inşa etmeye çalıştığınız anda bozuluyor.

Üretim yapay zekâ sistemleri API’lerden çok süreçler gibi davranır.

Sürekliliği tanıttığınız anda her şey değişir. Artık tek bir istek ve yanıttan ibaret değildir. Birbirine bağlı bir dizi etkileşimle uğraşırsınız. Belleğe ve duruma ihtiyaç duyarsınız; şimdi neyin önemli olduğuna, beş dakika önce neyin önemli olduğuna ve yarın da neyin önemli olması gerektiğine karar vermeniz gerekir.

Ve o çizgiyi aştığınızda, bunun ölçekli istem mühendisliği olmadığını fark edersiniz.

Bu, sistem tasarımıdır.

Aslında inşa ettiğiniz şey daha iyi bir istem değil. Zaman içinde bağlamın nasıl süzüldüğünü ve evrildiğini belirleyen bir sistem kuruyorsunuz. Bunun etrafında ortaya çıkan disiplin bu. Buna bağlam mühendisliği diyoruz.

Bağlam, istem değildir

Hata ayıklayıcınızda herhangi bir üretim aracısını açın ve belirli bir turda modele gerçekten ne gönderildiğine bakın. Neredeyse hiçbir zaman yalnızca kullanıcının iletisi değildir. Tipik bir istek aşağıdakine benzer:

Kullanıcı iletisi, yükün en küçük parçasıdır. Diğer her blok süzülüp isteme enjekte edilmiştir. Bu bloklar, farkında olmasanız bile sizin tasarladığınız bir ardışık düzenin çıktısıdır.

Asıl ürün o ardışık düzendir. Model, çalışma zamanıdır. Bağlam mühendisliği, bu ardışık düzenin tasarımıdır.

Bu ayrımı kabul ettiğinizde mimari çok farklı görünür.

Bellek Tek Bir Şey Değildir

"Bellek ekle" yeni "önbellek ekle"dir. Bir özellik gibi duyulur ama aslında tesadüfen aynı adı paylaşan birkaç farklı sistemdir. Bunları ayırmazsanız her soruya kötü cevap veren tek bir blob deposuyla kalırsınız. Bazı yerlerde unutkan, bazılarında takıntılı.

İlk kesit, bilişsel bilimin bize çoktan verdiği ve çoğu uygulayıcının yakınsadığı ayrımdır: kısa süreli bellek (STM) ve uzun süreli bellek (LTM). Kısa süreli bellek, bağlam penceresinin içinde şu anda bulunan, modelin bu turda görebildiği çalışma kümesidir.

Uzun süreli bellek, tek bir çağrının ötesinde yaşayan her şeydir: olgular, eserler, planlar, önceki kararlar, araç çıktıları ve kurallar. Kısa süreli bellek bir bütçe sorunudur. Uzun süreli bellek ise bir sistem sorunudur.

Aşağıdaki beş türün tümü uzun süreli bellektir; ne için olduklarına ve nasıl saklanmaları gerektiğine göre düzenlenmiştir. Bilişsel bilimden esinlenen CoALA gibi çerçevelerde göreceğiniz kanonik anlamsal, epizodik ve işlemsel sınıflandırmaya karşılık gelirler. Üretimde farklı şekilde yönetilmeleri gerektiği için bu kategorilerden ikisini alt gruplara ayırıyorum.

Politika belleği

Normatif kurallar ve kısıtlar. Tipik olarak genel ya da kiracı kapsamlı. Sürümlenen ve sıkı şekilde kontrol edilen. Sistemin neyi yapmasına izin verildiğini belirler: uyum kuralları, marka sınırları, güvenlik sınırları. Nadir ve kasıtlı olarak değişir. Bilişsel bilim anlamında işlemsel bellek budur; oturumlar arasında davranışı şekillendiren kurallar ve iş akışlarıdır. Dosya sistemi öncelikli aracılarda CLAUDE.md veya AGENTS.md gibi dosyaların yer aldığı aynı kategori.

Tercih belleği

Kararlı kişiselleştirme parametreleri. Genellikle kullanıcı kapsamlıdır. Bu kullanıcı JSON yanıtlar istiyor, şu kullanıcı madde işaretlerini tercih ediyor, şu kiracı tarihleri GG/AA/YYYY biçiminde yazıyor. Tercih belleği, her oturumda baştan anlatılmasına gerek kalmadan sistemin kişiye özel hissettirmesini sağlar. Aşağıdaki olgu belleğiyle birlikte bu, anlamsal katmandır: dünyaya ve içindeki şeylere dair kalıcı, sorgulanabilir önermeler.

Olgu belleği

Aracının yeniden kullanabileceği kalıcı önermeler. Menşei (provenance) içermelidir. “Müşterinin üretim veritabanı us-east-1’da” bir olgudur. “Mali yılları Nisan’da başlıyor” da öyle. Bileşik üstünlüğün yaşadığı yer olgulardır ve en zor tasarım sorunları da burada çıkar; çünkü yazdığınız her olgu geleceğe dair bir bahistir. Olguları tercihlerden ayırıyorum; çünkü her ne kadar bilişsel düzeyde ikisi de anlamsal bellek olsa da, yazma yolları, bozunma profilleri ve yönetişim gereksinimleri farklıdır.

Epizodik bellek

Tamamlanan işlerin yapılandırılmış özetleri. “Vaka çözüldü” veya “geçiş tamamlandı” gibi şeyler. Sistem tarafından izlerden damıtılan, yeniden kullanılabilir eserler. Epizodik bellek, sistemin bunu daha önce yaptık diye tanımasını ve önceki çözümün şeklini geri çağırmasını sağlar.

İz belleği

Ham, yalnızca eklemeli yürütme olayları. Bu sizin uçuş kaydedicinizdir. Hacmi yüksektir, çoğunlukla geri getirme ve yeniden oynatma için kullanışlıdır ve bir kullanıcının nasıl biri olduğunu öğrenmek istediğinizde bakılacak doğru yer değildir; sadece ne yaptığını gösterir. Bu ayrım önemlidir; çünkü çoğu ekip ikisini birbirine karıştırır ve tercihleri çıkarsamak için yürütme günlükleri üzerinde anlamsal arama yapar.

Daha kaba bir sınıflandırmada, hem epizodik hem iz belleği; konuşma dökümleri, araç çıktıları ve çalışma geçmişleri dahil epizodik şemsiye altına girer. Üretimde ham akış ile damıtılmış özetin erişim desenleri, saklama politikaları ve maliyet profilleri aşırı farklı olduğu için ben bunları ayırıyorum. Bunları tek şey gibi ele almak, ekiplerin günlüklerini aramak için vektör veritabanı fiyatı ödemesine yol açar.

Çalışma belleği bu listede değil; çünkü uzun süreli bellek değildir. Bizzat bağlam penceresidir; modelin mevcut turda gerçekten görebildiği çalışma kümesi. Çalışma belleği gerçektir ve önemlidir; ve şu anda en zor uygulamalı ML çalışmalarının çoğu burada yaşar: istem sıkıştırma, KV-önbellek yeniden kullanım, kayan pencere dikkat mekanizmaları, bu belirteçleri neyin işgal edeceğine dair bütçe hesabı.

Ama tanımı gereği geçicidir ve onu yukarıdaki kalıcı depolarla karıştırmak, karalama defteriyle kayıt sistemi aynı veritabanını paylaşıyormuş gibi mimariler üretir. Paylaşmamalıdır. Çalışma belleği, her turda uzun süreli bellekten derlenir ve açıkça terfi ettirilmedikçe atılır. İki katmanın buluştuğu yer terfi adımıdır ve ilginç tasarım işlerinin çoğu burada olur.

Birisi “aracımızın belleği var” dediğinde, hangisinden bahsettiğini sorun. Yanıt “her şeyi bir vektör deposuna döküyoruz” ise, aracılarının bazı yerlerde unutkan, bazılarında takıntılı hissettirmesinin nedenini bulmuşsunuz demektir.

Döngü ve İçinde Nelerin Bozulduğu

Her üretim yapay zekâ sistemi eninde sonunda aynı şekle yakınsar: bir döngü.

Şekil tartışmalı değildir. Aracı döngüsünün çoğu tanımı aynı beş adıma indirgenir: bağlamı derle, modeli çağır, eylemler gerçekleştir, sonuçları gözlemle ve belleği güncelle; sonra tekrarla. Ben aşamaları biraz farklı etiketliyorum; çünkü “bağlamı derle”nin iki yarısını (neyi özümsediğiniz ve neyi seçtiğiniz) ayırmak istiyorum ve terfinin “belleği güncelle” içine katılmaktansa kendi adını hak ettiğini düşünüyorum.

Ama alttaki anatomi aynıdır ve bu işe aracı çalışma zamanı, veritabanı ya da istem tarafından gelmiş olun, aynı beş kırılma noktasını görürsünüz.

ReAct 2022’de akıl yürütme ile eylemin iç içe geçmesini popülerleştirdi; üretim aracı sistemleri o deseni o zamandan beri yukarıdaki daha geniş döngüye genişletti. Diyagram faydalı bir görsel sunuyor; ancak her aşamanın arıza biçimini bilmek, mühendislik zamanını nereye harcayacağınızı söyler.

Injest

Ingest çok fazla şeyi kabul ettiğinizde başarısız olur. Ingest, bağlamı derlemenin ilk yarısıdır: çevreden ham girdileri özümsemek. Her olayı potansiyel bağlam gibi ele almak, daha sonra getirme aşamasının gidermesi gereken bir gürültü yaratır. Disiplin burada, sınırdadır. Neyi özümsemeyi reddediyorsunuz?

Retrieve

Retrieve sessizce başarısız olur. Retrieve, bağlamı derlemenin ikinci yarısıdır: uzun süreli belleğin hangi alt kümesinin şimdi önemli olduğunu seçmek. Yanlış parçayı döndürdüğünde istisna fırlatmaz; sadece modelin biraz tuhaf konuşmasına neden olur. Döngünün en az yatırım yapılan aşamasıdır ve algılanan sistem kalitesiyle en sıkı korelasyona sahiptir.

Saf anlamsal arama bir ilk taslaktır. Çoğu üretim sistemi için temel, üstveri filtreleme artı yeniden sıralamayla hibrit leksik/anlamsal getirmedir; bunun ötesinde, sorgu ayrıştırma, grafik dolaşımı ve çok adımlı getirme, görevler bileşik olduğunda yardımcı olur; ancak gecikme ve değerlendirme bütçeleriyle sınırlanmalıdır.

Çıkarım Yap & Eyleme Geç

Çıkarım Yap & Eyleme Geç bağlam yanlış davranışı tetiklediğinde başarısız olur. Bu, modeli çağır ve eylemler gerçekleştir aşamalarının tek bir evrede birleştirilmiş hâlidir; çünkü planlama ve araç çağrısı, derlenmiş bağlamın modelin ne yapmaya karar verdiğinin sonuçlarıdır. Uzun bağlam başarısızlıkları burada ısırır: ortada kaybolma, yakın zaman yanlılığı, bağlam çürümesi.

Sezgi, daha fazla bağlamın yanıtları tekdüze biçimde iyileştirmesi gerektiğidir. Modele çalışması için daha fazla bilgi veriyorsunuz; dolayısıyla daha iyi yapacağını düşünürsünüz. Pratikte, daha fazla belirteç modeli sık sık daha kötü yapar. Bağlam bütçeleme artık gerçek bir disiplindir ve varsayılan içgüdü olan “modelin önüne ne varsa koy” varsayılan yanlış cevaptır.

Değerlendir

Değerlendir çoğu sistemde hiç olmayan aşamadır. Eylemlerinin sonucunu gözlemleyerek sisteme geri bildirim sokar. Yanıtın yardımcı olup olmadığını, iş akışının başarılı olup olmadığını ve kullanıcının onu düzeltmek zorunda kalıp kalmadığını bilmek istersiniz.

Geri bildirim açıkça yakalanmadığında bile, sinyaller vardır. Üretimde iyi çalışan birkaç tanesi: bir sonraki mesaja kadar geçen süre (hızlı bir takip genellikle yanıtın hedefe oturmadığını gösterir), çıktınız ile kullanıcının gerçekten gönderdiği veya kaydettiği sürüm arasındaki düzenleme mesafesi (küçük düzenlemeler gürültüdür, büyük düzenlemeler düzeltmedir) ve bir araç sonucundan N saniye içinde terk edilme (kullanıcı ürettiğinize baktı ve uzaklaştı).

Bunların hiçbiri kullanıcının bir şeyi puanlamasını gerektirmez. Sadece zaten olanı ölçmeniz gerekir. Bu örtük sinyaller her yerdedir; ancak yığındaki hiçbir şey onları dinlemiyor. Bu adım olmadan döngü kapanmaz: sistem çalışır ama ürettiğinden ders çıkarmaz.

Terfi

Terfi yanlış inşa edilmesi en kolay aşamadır. Terfi, belleği güncellenin uzun süreli depoya geri yazmayı yöneten yarısıdır. Çoğu ekip aşırı yazmaya meyleder; her şeyi geri döker ve deponun kendisini zehirler. İhtiyacınız olan, şu altı soruyu yanıtlayan gerçek, yazılı bir politikadır:

• Ne yazılır?
• Hangi incelikte/granülaritede?
• Hangi bellek türüne?
• Hangi menşeiyle?
• Hangi bozunmayla?
• Kimin yetkisi altında?

Doğru yapmak en zor adımdır ve aynı zamanda en kritik olanıdır.

Ardışık düzenler sonlanır. Döngüler bileşik etkiler yaratır. Farkı yaratan Terfi’dir.

Muhtemelen Sevk Ettiğiniz Anti-Desenler

Birkaç aydan uzun süredir aracılar inşa ediyorsanız, bunların birkaçını neredeyse kesin sevk etmişsinizdir. Ekibimin erken deneyleri de bunların her birinden nasibini aldı; bu yüzden içeriden nasıl göründüklerini biliyorum.

• Her turda tam dökümü dökmek: Durumu korumanın tembel yoludur. Feci derecede pahalıdır, bağlam çürümesine hızla yakalanır ve kullanıcılar şikâyet edene kadar görünmeyen şekillerde yanıt kalitesini düşürür. Arka planda çalışan sıkıştırıcı özetleyici, ölçekte opsiyonel değildir ve istem önbellekleme, değişken getirme yükleri önbelleğe alınmış bölümlerden sonra gelmek üzere, istikrarlı önekler (sistem istemleri, araç tanımları, statik politika blokları) için ayrılmalıdır.
• Getirme stratejisinde bağlam aşırı yükü: Getirme tarafındaki eşdeğer hata; getirmeyi mutfak lavabosu gibi ele alıp ilk 20 parçayı çekmek ve modeli sıralamasını ummaktır. Model onları ortalamaya çalışır; bu da beş iyi parça seçmekten daha kötüdür.
• Karalama defterini bellek sanmak: Araç çağrısı sonuçlarınız, ara akıl yürütmeleriniz ve üretilen varlıklarınızın hiçbiri açıkça atılmadığı için uzun süreli depoya sızdığı durum. “Belleğiniz” çoğunlukla egzozdan ibaret olur.
• Her tür bellek için tek bir bellek deposu: Sistemler her şey için tek bir vektör dizini kullandığında: izler, olgular, tercihler, politikalar ve epizodik özetler tek depoda bir araya gelir; getirme bunları ayırt edemez, model de edemez.
• Asla unutmayan bellek: Tersi hata, asla unutmayan bellek: TTL yok, bozunma yok, çıkarma yok. Yalnızca birkaç ay sonra bu, varlık olmaktan çıkıp yük hâline gelir. Bir sisteme ekleyebileceğiniz en iyi davranışlardan bazıları agresif unutma politikalarıdır.
• Kullanıcı beğenisine göre terfi: Bu bir tuzaktır; çünkü en güçlü geri bildirim sinyali aynı zamanda en nadir ve en önyargılı olandır. Yalnızca açık pozitif sinyallerle terfi eden sistemler, gerçek kalite yerine buton tıklamasını optimize etmeyi öğrenir.
• Yeniden oynatma yok: Yeniden oynatma kabiliyeti olmadan hata ayıklama tahmin yürütmeye dönüşür. Dün yapılan oturumu çoğaltamazsınız; çünkü bellek deposu yoluna devam etmiştir. Bu, otopsileri mahveden hata sınıfıdır.

Neden Bu Vibes Değil de Sistem Tasarımıdır

Buna “sistem tasarımı” adını hak ettiren parça, zihinsel model değil. Takaslardır ve her birinin, sevk etmesi daha ucuz ama yaşaması daha pahalı bir yanlış cevabı vardır.

Belirteç ekonomisi artık istek mimarisini yönlendiriyor

İstem önbelleği isabetleri, ıskalamaların maliyetinin bir kısmına gelir; Anthropic’in API’sinde ve OpenAI’nin daha yeni modellerinde genellikle standart giriş fiyatının sadece %10’u, Google’ın Gemini’sinde %25’i. Bu fiyatlandırma, bir istek içinde nereye ne koymanın rasyonel olduğunu yeniden şekillendirdi ve önbellek dostu önekler, istikrarlı araç şemaları ve sabitlenmiş sistem talimatları artık kozmetik tercihler değildir.

Bu da sağlayıcıya bağlı olarak, girdide 4x ile 10x arasında bir tasarruf tavanı koyar; üstelik her adımda aynı önekin tekrar gönderildiği aracı iş yüklerindeki yapısal bileşimi saymadan. Önbellek stratejisini doğru kurun; iyi tasarlanmış bir aracı, aynı işi yapan kötü tasarlanmış birine kıyasla birkaç kat daha ucuza çalışır. Bu, yapay zekâ mühendisliğinin önbellek satırı problemine en çok benzeyen şeydir ve çoğu ekip bunu CSS kararı gibi ele alıyor.

Getirme bir mimari sorundur

Üretim katı hibrittir (leksik artı anlamsal), yeniden sıralamalıdır ve sorgu yeniden yazımı içerir. Tavan, döngü içinde modelin kendi aramalarını yapıp rafine ettiği aracısal getirmedir. Bu ikisi arasındaki mesafe muazzamdır; kıyaslarda görünmez, her kullanıcı etkileşiminde görünür. Getirmeniz tek bir top-k çağrısıysa, aracınızın aptal hissettirmesinin nedeni getirmenizdir.

Bağlam kapsamı bir güvenlik sınırıdır

Çok kiracılı yalıtım, alt aracının kum havuzu, oturumlar arası sızıntı. Bunlar sonra yapılacak sertleştirme alıştırmaları değildir. Bir alt aracı varsayılan olarak ebeveynin çalışma kümesini görebiliyorsa, patlamayı bekleyen bir sorununuz vardır; tek soru, önce sizin mi yoksa bir saldırganın mı bulacağıdır.

Değerlendirme, önceki tüm sistem sınıflarına göre daha zordur

Durumlu, stokastik, yol bağımlı sistemler birim testine gelmez. İz tabanlı değerlendirme, altın getirme setleri, sürümlenmiş bellek anlık görüntülerine karşı çevrimdışı yeniden oynatma ve kendileri de sürümlenen yargıç olarak LLM değerlendiricilerine ihtiyaç duyarsınız. Çoğu ekipte bunların hiçbiri yoktur ve kör uçarlar. Son dağıtımlarının kaliteyi geriye götürdüğünü bir kullanıcı söylediğinde öğrenirler.

Yönetişim opsiyonel değildir ve düşündüğünüzden teknik olarak daha zordur

GDPR kapsamındaki unutulma hakkı, “kullanıcı hakkında bilgi sahibi olan şey” yüzlerce etkileşimden türetilmiş bir olguya dönüştüğü anda önemsiz olmaktan çıkar. Bir kullanıcının verilerini, onu zaten olgu belleğine emmiş bir sistemden silmek ne anlama gelir? AB Yapay Zekâ Yasası bunun üzerine bir katman daha ekliyor; yükümlülüklerin çoğu (veri yönetişimi, insan gözetimi ve yüksek riskli sistemler için şeffaflık gereklilikleri dahil) Ağustos 2026’da yürürlüğe giriyor.

2026’nın ikinci yarısında Avrupa’ya yapay zekâ ürünleri sevk eden ekipler, alanın henüz topluca çözmediği sorulara yanıtlar gerekecek: bir kullanıcının türetilmiş bir olguya katkısını nasıl ispatlanabilir şekilde kaldırırsınız, bir bellek terfisinin soy zincirini nasıl denetlersiniz, bir bellek deposunun iddia ettiğiniz şekilde kapsamlandığını nasıl gösterirsiniz.

Kimsenin yanıtı henüz iyi değil. Yine de çalışmak zorunda ve düzenleyiciler, sektörün bunu çözmesini beklemeyecek.

Bu nedenle bağlam mühendisliği, istem mühendisliği değil sistem tasarımıdır. İlginç işlerin çoğu, bağlamın bir aşamadan diğerine aktarıldığı sistemler arasındaki bağlantılarda gerçekleşir. Neredeyse hiçbiri bizzat istemde değildir. Ve yukarıdaki takasların neredeyse her birinin, teknik borca dönüşen ve en kötü zamanda geri ödeyeceğiniz ucuz görünümlü bir kestirmesi vardır.

Bellek Katmanının Yakınsadığı Yer

Belleğin, birden çok erişim deseni olan beş farklı şey olduğunu kabul ettiğinizde, ortaya çıkan bariz soru şudur: hepsi nerede yaşayacak?

Hibrit getirme, yani tek bir sistemde leksik artı anlamsal, bu noktada büyük ölçüde çözülmüş bir problemdir. Elasticsearch, OpenSearch, LanceDB, Pinecone, Weaviate ve Postgres’in vektör uzantıları bunun bir sürümünü destekler ve aralarındaki üretim kalitesi farkı, satıcı pazarlamasının ima ettiğinden daha dardır. Tüm bellek katmanı “gömülü temsiller ve tam metin arama”dan ibaret olsaydı, mimari soru sıkıcı olurdu.

Öyle değil; çünkü bellek yalnızca getirme değildir. Beş türe tekrar bakın ve her birinin deposundan aslında neye ihtiyaç duyduğunu fark edin.

Kendinizi içinde bulduğunuz tesadüfi mimari, bunları en çok acıtan eksen boyunca ayırır. İlişkisel veriler Postgres veya yönetilen bir eşdeğerde yaşar. Hibrit getirme Elasticsearch, OpenSearch veya Pinecone, Weaviate, LanceDB gibi özel bir vektör depoda yaşar.

İzler S3’e veya bir zaman serisi veritabanına düşer. Bunların her biri, inşa edildiği iş için güçlü bir seçimdir ve birçok üretim yığını bunları iyi kullanır. Sorun tekil bir bileşen değildir. Sorun, her anlamlı getirme yolunun sistemler arası bir birleşime dönüşmesidir: “bu sorguyla ilgili olguları bul; bu kiracıya uygulanan politikalarla filtrele; bu aracının görmesine izin verilen kullanıcılara kapsamla.” Bu birleşim üç sınırı aşar: güven, işlem ve gecikme. Bağlam bu sınırlardan her birini her geçtiğinde, kaçınmaya çalıştığınız tutarlılık problemini yeniden tanıtırsınız.

Mimari resmin değiştiği yer burası. Hibrit getirmenin ilişkisel verilerle aynı depoda olması ayırt edici kabiliyettir ve bu, tek başına hibrit getirmeden farklı bir problemdir. Özellik olarak hibrit getirme, giderek her yerde mevcuttur.

Daha az yaygın olan, ilişkisel, belge ve vektör verilerinin tek bir işlemsel ve güvenlik sınırı altında birlikte bulunmasıdır; böylece politika, tercih, olgu ve epizodik bellek, sistemler arası uzlaştırılmak yerine ACID garantileriyle birlikte sorgulanabilir.

Oracle AI Database bu yakınsamış, çok model yaklaşımın bir örneğidir: ilişkisel tablolar, JSON belgeleri ve vektör gömüleri tek bir motorda, tek bir SQL deyimiyle ve tek bir işlem içinde birlikte sorgulanabilir. Beş tür sınıflandırmayı ciddiye alıp politika, tercih ve olgu arasındaki birleşimleri çizmeye başladığınızda, soru “hangi getirme motoru en iyidir”den “o getirmeyi yöneten ilişkisel veriler aslında nerede yaşamalıdır”a kayar.

Pratikte bu, ilişkisel politika verilerini, JSON olarak kodlanmış tercihleri ve olgu belleği üzerindeki vektör benzerliğini birleştiren tek bir SQL deyimi gibi görünür. Aksi takdirde üç sistemi kapsayacak sorgu, tek birine çöker:

-- Find facts relevant to this question, scoped to the policies
-- and preferences that apply to this user, in a single query.
SELECT f.fact_text, f.provenance, f.created_at
FROM   fact_memory f
JOIN   user_preferences p
       ON p.user_id = :current_user
JOIN   tenant_policies t
       ON t.tenant_id = p.tenant_id
      AND t.is_active = 'Y'
WHERE  f.tenant_id = p.tenant_id
  AND  JSON_VALUE(p.prefs, '$.allow_personalization') = 'true'
  AND  f.access_level <= t.max_access_level
ORDER BY VECTOR_DISTANCE(
           f.embedding,
           VECTOR_EMBEDDING(MINILM USING :query AS DATA),
           COSINE
         )
FETCH FIRST 5 ROWS ONLY;

Tek bir deyim aynı anda dört şey yapıyor: kiracı politikasını uyguluyor, kullanıcı tercihine saygı gösteriyor, olgu başına erişim denetimleri uyguluyor ve anlamsal benzerliğe göre sıralıyor. Bir federasyon mimarisinde bunlar üç farklı depoda dört gidiş-dönüştür ve tutarlılık modelini sizin savunmanız gerekir.

Burada tek bir sorgu planı, tek bir işlem sınırı, denetlenecek tek bir yer var. 1970’lerden beri veritabanlarını paylaşılan durum için kayıt sistemi yapan aynı ACID garantileri, şimdi satırların yanında vektörleri de içeren belleğe uygulanıyor.

Bu desenin çalışan örnekleri, hibrit aramayla aracısal RAG ve bağlam mühendisliği için bellek mimarisi üzerine bir not defteri dahil, Oracle’ın GitHub’daki AI Developer Hub’ında yer alıyor.

Yine de bazı şeyler için uzmanlaşmış depolar isteyeceksiniz. Yüksek hacimli iz belleği, işlem veritabanınızdan farklı dayanıklılık ve maliyet özelliklerine sahiptir. Belgeler, görseller ve model eserleri gibi büyük varlıklar için blob depolama, bunun için inşa edilmiş bir yerde olmalıdır. Sertleştirilmiş belge iş akışları için o kategorinin spesifik özelliklerine ihtiyaç duyduğunuzda özel bir belge veritabanı hâlâ mantıklı olabilir.

Mesele, birleşik bir platformun diğer tüm depoları ortadan kaldırması değildir. Mesele, en pahalı birleşimi ortadan kaldırmasıdır: aracının ne yapmasına izin verildiğini yöneten ilişkisel veriler ile aracının gerçekte ne yaptığına yön veren vektör veriler arasındaki birleşim. Bu ikisi birlikte konumlandığında, mimari sorun “bu depoları nasıl senkron tutarım”dan “iyi bellek politikalarını nasıl tasarlarım”a kayar; ki asıl önemli olan da budur.

Sırada Ne Var: Yedi Tahmin

Yukarıdaki bölümler nerede olduğumuzu anlatıyor. Bunlar nereye gittiğimize dair iddialı öngörüler. Kasıtlı olarak görüş yüklüler. Katılmadıklarınıza katılmayın.

1. Model, bellek hâline gelmez

Cazip hikâye, model sağlayıcılarının belleği bizzat modelin içine emdiğidir. Uzun bağlam pencereleri uzar, önbellekleme akıllanır ve harici bellek katmanı gereksizleşir. Bu olmayacak. Bağlam pencereleri büyümeye devam edecek ama her turda hâlâ astarlama gerektirecek. Model her oturumda durumsuz kalacak ve harici bellek katmanı kayıt sistemi olmaya devam edecek. Değişecek olan, harici belleğin çok daha akıllı hâle gelmesidir (bugün vektör depoları ve hibrit platformlar, yarın henüz inşa etmediklerimiz) ve bağlam mühendisliği, modelin neyi, ne zaman ve neden gördüğüne karar verme zanaatı olacaktır. Eğer bir sınır sağlayıcı, üretim kullanımında harici bir bellek sisteminin yerini ikna edici şekilde alan bir ilkel sunarsa, bu öngörü yanlıştır. Ben buna karşı bahse girerim.

2. Olgun yapay zekâ ürünlerinde bellek altyapısı çıkarımdan daha çok harcar

Çıkarım maliyetleri yaklaşık her 18 ayda bir büyüklük mertebesinde düşüyor. Depolama, getirme, gömme temsili üretimi, yeniden sıralama ve istek başına bağlamın derlenmesi düşmüyor. Kullanıcı sayısı, oturum derinliği ve etkileşim geçmişiyle ölçekleniyorlar; bunların hepsi büyüyor. Bulut faturasındaki baskın kalem GPU belirteçlerinden vektör ve hibrit getirme altyapısına kayıyor. Bu, inşa-et/ satın-al sorusunu yeniden şekillendiriyor. Bellek altyapısı, model katmanı gibi kolayca metalaşmıyor. Uzun vadede kazanan ekipler, bellek altyapısını ilk günden itibaren birinci sınıf yatırım olarak görenler olacak.

3. Klasik RAG miras mimariye dönüşür

“Belgeleri göm, kullanıcı sorgusunda top-k yap, isteme doldur” yapay zekâ mimarisinin COBOL’udur. Çalışır, her yerdedir ve geriye dönüp bakıldığında utandırıcı olacaktır. Yerine geçeni şimdiden görünüyor: aracısal getirme; model kendi aramalarını planlıyor, çok adımlı sorgular yürütüyor, ara sonuçları okuyor ve sonraki adımda neyi getireceğine karar veriyor. Bir veritabanı aramasından çok bir araştırma sürecine benziyor. Bugün hâlâ statik RAG ardışık düzenleri inşa eden ekipler, farkında olsalar da olmasalar da bir göç yolundadır.

4. Bellek, saldırı yüzeyine dönüşür

Bellek saldırıları, istem enjeksiyonunun yapmadığı şekilde bileşik etkiler yaratır. Uzun ömürlü bir bellek deposuna, doğrudan ya da ayrıcalıklı olduğunu düşünmediğiniz bir giriş kanalı üzerinden yazabilen bir saldırgan, dokunduğu her gelecekteki kullanıcı için sistemin davranışını şekillendirebilir. Dışa sızdırma ters yönde aynı şekilde işler: bağlamın, kapsam modeli gevşek olduğu için bir oturumdan diğerine sızması. İlk ciddi gerçek dünya bellek zehirleme olayı geliyor. Ardından menşe, onaylama ve olgu başına erişim denetimi üzerine endüstri çapında koşuşturma gelecek.

5. Bağlam gizlilik sınırları bir uyum gerekliliği hâline gelir

“Bağlam kapsamı bir güvenlik sınırıdır”dan sonraki mantıklı adım, bellek segmentlerinin kriptografik izolasyonudur; böylece aracılar yalnızca bilmesi gereken kadar bağlamı açıklayabilir. Farklı güven seviyelerine sahip alt aracılara ya da hassas olguların kanıtlanabilir kapsamını gerektiren düzenleyici rejimlere sahip olduğunuz anda önem kazanır. “Aracı bellek kapsamları arasında yetersiz izolasyon”u alıntılayan ilk düzenlenmiş sektör denetim bulgusunun tetikleyici olmasını bekleyin; ardından uyum çerçeveleri gelecektir. Yol haritasında kriptografik kapsamı olan ekipler, buna bağlı RFP’leri kazanacak. Olmayanlar, son teslim baskısı altında sonradan ekleyecek.

6. Çok aracılı tutarlılık, isimli ve beklenen bir kabiliyet olur

Bugün, aynı müşteri hesabına dokunan bir faturalama aracısı ve bir destek aracısı, bellekten farklı dilimler çektikleri ve hiçbir şey bunları uzlaştırmadığı için çelişkili yanıtlar üretebilir. Şu an tolere edilebilir; çünkü çoğu üretim dağıtımı tek aracılı. Çok aracılı sistemler ölçekte üretime geçtiğinde, kullanıcılar çelişkileri yakalamaya başlayacak ve “bağlamsal tutarlılık” platformların rekabet ettiği isimli bir kabiliyet olacak. Önce satıcı karşılaştırma matrislerinde, sonra kurumsal tedarik kontrol listelerinde görünecek. Bunu erken çözmek bir ayırt edici özellik olur. Yok saymak, neden iki kendi aracınızın aynı müşteri hakkında hemfikir olmadığını soran destek biletleri alanız demektir.

7. “Kişi başına faydalı bağlam” ölçümlenen bir metrik hâline gelir

Kıyaslar, modellerden tüm sistemlere kayacak ve manşet metrik, kullanıcı başına, etkileşim başına taşınan faydalı bağlam gibi bir şey olacak. Kullanıcı tutulumunu ve sizi tanıyormuş gibi hissettiren bir ürün ile her salı sıfırlanıyormuş gibi hissettiren bir ürün arasındaki farkı gerçekten öngören sayı budur. Akademik makalelerde görünmeden önce yatırımcı sunumlarında arayın. İlişkili bir metrik olan faydalı bağlam belirteci başına maliyet, yanıtlanmaya değer bir birim ekonomi sorusu olacaktır.

Pazartesi Ne Yapmalı

Bu işe yeniyseniz ve başlamak için bir yer arıyorsanız: belleği tek bir şey gibi ele almaktan vazgeçin. Erişiminiz olan bir üretim aracısını seçin, her bir deposunun gerçekte hangi tür belleği tuttuğunu etiketleyin ve tek bir deponun ne sıklıkla üç işi birden yaptığını fark edin.

Zaten aracılar inşa ediyorsanız: döngüyü enstrümante edin. Özellikle de getirme ile terfi arasındaki sinyali. Belirli bir turda sistemlerinin ne getirdiğini söyleyebilen çok ekip gördüm. Getirilen bu belleklerden hangilerini modelin gerçekte kullandığını söyleyebilen çok daha az; belirli bir belleğin ilk etapta neden terfi ettirildiğini söyleyebilen ise neredeyse hiç yok.

Hangi belleklerin kullanıldığını bilmek, onları bir sonraki terfi adımında pekiştirmenizi sağlar; bu da bir bellek sisteminin yaz-çek defterinden çıkıp gerçekten öğrenmeye başlamasının yoludur.

Bileşik üstünlüğün yaşadığı yer bu geri bildirim döngüsüdür ve bu disiplinin önümüzdeki dönemdeki ilginç işleri burada oluyor.

Her ekip, kabaca aynı zaman çizelgesinde aynı sınır modellerine erişir. Kimsenin kopyalayamayacağı şey, etraflarında inşa ettiğiniz bellek katmanıdır: kullanıcılarınız, kararlarınız ve neyin hatırlanmaya değer olduğuna dair muhakemeniz tarafından şekillenen.

Modeller ortaktır. Bellek sistemi sizindir.