Yapay zekâ

Yapay Zekâ Bağlam Mühendisliği Nedir ve Neden Bunu İnşa Etmek Yerine Satın Alabilirsiniz?

Stack Overflow’dan Doug Whitley ve Ash Zade, yapay zekâ bağlam mühendisliğinin aracılara sunulan bilgileri sınırlamaya, çıktıların öngörülebilirliğini artırmaya ve bellek, izinler ile çelişkili bilgilerle başa çıkmaya nasıl yardımcı olduğunu açıklıyor. Konuşmacılara göre bu sistemi kurum içinde kurmak mümkün; ancak güven, veri kalitesi ve bilgi bulunmadığında veya çeliştiğinde aracının ne yapması gerektiğiyle ilgili teknik ve felsefi sorunların ele alınmasını gerektiriyor.

2026-08-14
5 dk okuma
15 görüntülenme
فريق تحرير certi.news
Yapay Zekâ Bağlam Mühendisliği Nedir ve Neden Bunu İnşa Etmek Yerine Satın Alabilirsiniz?

Yapay zekâ bağlam mühendisliği, aracın çevresindeki tüm bilgi, sınır ve talimatların tasarlanmasını ifade eder; böylece araç neyi görebileceğini, ne yapması gerektiğini ve yeni bir durumla ya da eksik verilerle karşılaştığında nasıl davranacağını bilir. Stack Overflow Mühendislik Direktörü Doug Whitley ile Ürün Direktörü Ash Zade’nin açıklamasına göre amaç, aracı mevcut tüm verilerle boğmak değil, öngörülebilir bir sonuç verecek bir görevi tamamlamak için ihtiyaç duyduğu belirli bağlamı sağlamaktır.

Bu konu, Stack Overflow Blog’da “No Dumb Questions” serisi kapsamında yayımlanan bir söyleşide ele alındı. Söyleşide bağlam mühendisliği ile bağlam altyapısı ve bağlam mühendisliği arasındaki farkların yanı sıra bu kavramların RAG ve MCP teknolojileriyle ilişkisi ve şirketlerin her şeyi kurum içinde kurmak yerine neden hazır çözümler satın almaya yöneldiği tartışıldı.

Altyapıdan mühendisliğe

Whitley, bağlam altyapısı ile bağlam mühendisliği arasında ayrım yapıyor. Bağlam altyapısı, bağlamın nasıl depolandığı, gösterildiği ve araca sunulduğuyla ilgilenirken bağlam mühendisliği, sistemin tasarımına ve bileşenlerinin belirli bir biçimde düzenlenmesinin nedenlerine odaklanır. Uygulama anlamındaki bağlam mühendisliği ise algoritmaların, programlama dillerinin ve kullanılan araçların seçilmesi gibi sistemin fiilen oluşturulmasıyla ilgilidir.

RAG, bu üç seviyeyi bir araya getiren bir alanda yer alır. Dizinler, bağlam depoları ve arama yöntemleri altyapı yönünü oluştururken .NET, Python veya Rust gibi bir dille sistemin kurulması mühendislik yönünü temsil eder. Buna karşılık mimari, sistemin genel biçimini ve çalışma yöntemini yöneten kuralları belirler. Whitley ise MCP’yi belirli gereksinimleri olan bir protokol olarak görüyor; ancak bunun sisteme nasıl entegre edileceği, hangi dillerin kullanılacağı ve hangi özellikleri destekleyeceği tasarım kararlarıdır.

Aracının aldığı kararların alanını daraltmak

Zade, fikri otomobil lastiklerini arama örneğiyle açıklıyor. Bir araç, “lastikler” aramak için bir kütüphaneye gönderilirse uçaklara, bisikletlere ve el arabalarına ait bilgilerle karşılaşabilir; çünkü bunların tümü istenen kelimeyle eşleşir. Ancak iyi tasarlanmış bir sistem, görevin otomobil lastikleriyle veya özellikle spor otomobil lastikleriyle ilgili olduğunu baştan belirler ve mevcut bilgileri bu kapsamla sınırlar.

Zade’ye göre bu talimatların yalnızca metin tabanlı bir isteme yazılması, aracın bunlara uyacağını garanti etmez. Bu nedenle bağlam mühendisliği, aracın erişebileceği verileri kontrol etmenin yanı sıra eksik veya yanlış bilgilerle karşılaştığında ne yapacağını da belirlemeyi gerektirir. Böylece aracın kararlarındaki bazı değişkenler ortadan kaldırılır; aracın bilginin güvenilir olup olmadığına veya arama kapsamını genişletip genişletmemesi gerektiğine kendisinin karar vermesi beklenmez.

Sistem ayrıca aracın belleğini de kapsar; araç şimdiye kadar ne yaptığını, ne öğrendiğini, ne hakkında iletişim kurduğunu ve ne oluşturduğunu saklar. Birden fazla araç çalıştığında veya görev durdurulup daha sonra sürdürüldüğünde bu belleğin önemi artar.

Güven, izinler ve insan müdahalesi

Konuşmacılara göre Stack Internal, bağlamın bir güven sistemi ve uzman doğrulama akışıyla ilişkilendirilmesine örnek oluşturur. Bilgi yüksek, orta veya düşük derecelerle sınıflandırılır. Derece orta veya düşükse kullanıcı, aracın doğrulanmamış bilgiye dayanarak karar vermesi yerine bilgiyi doğrulaması ya da eksikleri tamamlaması için konu hakkında bir uzmana yönlendirilebilir.

Veri koruma, aracın belirli bir bilgiyi görüp göremeyeceği sorusunun ötesine geçer. Bir bilgi kullanıcı tarafından erişilebilir olsa bile aracın yürüttüğü görev için uygun olmayabilir. Bu nedenle konuşmacılar iki kontrol düzeyi tanımlıyor:

  • Kaynak izinleri: Araç, Slack, MS Teams, Google Drive veya SharePoint gibi arama yaptığı sistemlerde kullanıcının izinlerini devralır.
  • Kapsamlar: Kullanıcı, daha geniş bir veri kümesine erişim izni olsa bile aracın kullanabileceği verilerin kapsamını daraltabilir.
  • Yeni veriler: Aracın oluşturduğu veya sisteme geri gönderdiği bilgiler sınırlandırılabilir; böylece bunlar önce kullanıcıya gönderilir ve genel bilgi tabanına otomatik olarak eklenmez ya da ekiple paylaşılmaz.

Bu ayrım, bağlam yönetiminin yalnızca bilgiyi geri getirmekle ilgili olmadığını, aracın oluşturduğu bellek ve bilgilerin kontrolünü de kapsadığını gösteriyor.

Şirket neden çözümü kurmak yerine satın alabilir?

Whitley, bağlam mühendisliği kurmanın mümkün olduğunu, ancak zorluğun yalnızca kod yazmakla sınırlı olmadığını söylüyor. Bir şirket Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub ve Jira’dan veri topladığında bunların nasıl dizine alınacağını, filtreleneceğini ve yeniden sıralanacağını; çelişkili, eksik veya yanlış bilgilerle nasıl başa çıkılacağını belirlemesi gerekir.

Zade’ye göre işin büyük bir bölümü güvenin kendisini tanımlamakla ilgilidir. Uzman bir kullanıcı, yapay zekânın çıktıları beklentileri ve önceki deneyimiyle örtüştüğünde bunlara güvenebilir; ancak bu yöntem, yapay zekânın çalışması istenen alanda uzmanlığı olmayan kişiler için aynı ölçüde kullanılamaz. Bu nedenle sistem, bilgiyi toplamak için yalnızca teknik çözümler değil, bilgiyi güvenilir kılan unsurlar hakkında da tartışmalar gerektirir.

Whitley, hazır bir çözüm satın almanın şirkete başka müşterilerin karşılaştığı sorunlardan edinilmiş birikmiş deneyim sağlayabileceğini ekliyor. Buna uç durumlar ve ekibinin yaklaşık 20 kategori altında sınıflandırdığını söylediği günlük sorunlar da dahil. Bununla birlikte konuşmacılar kurum içinde geliştirmeyi dışlamıyor; kullanım senaryosu yeni olduğunda veya şirketin kendine özgü tasarım kararlarına ihtiyaç duyduğunda bu yaklaşım uygun olabilir.

Whitley ve Zade’ye göre bağlam mühendisliğinin kalitesi, sistemin esnekliği ve tutarlı, öngörülebilir çıktılar sunabilme kapasitesiyle ölçülür; kapsamının yalnızca tek bir göreve daraltılmasıyla değil. Bilgileri erken filtrelemek, aracın işlediği token sayısını da azaltabilir: otomobil kitaplarında arama yapmak, bütün bir kütüphanede arama yapmaktan daha düşük maliyetlidir; lastik sayfalarında arama yapmak ise tüm kitapları incelemekten daha düşük maliyetlidir. Nihai amaç, aracın beklenen görevi yerine getirmesini, aşmaması gereken sınırlara ulaştığında ise durmasını veya insan yardımı istemesini sağlamaktır.

Haber kaynağı
Stack Overflow Blog
Özgün kaynağı aç ↗
ف
Yazar

فريق تحرير certi.news

Aynı kategoride

Bunlar da ilginizi çekebilir

Tüm haberleri gör