deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

GitHub Copilot'a cihaz üzerinde çalışan modeller ekledi, ancak oturumlar hâlâ bulut üzerinden yönlendiriliyor

GitHub'ın 28 Ekim duyurusu, cihaz üzerinde çalışan modelleri Copilot CLI, Copilot uygulaması ve VS Code'a getiriyor; ancak oturumlar hâlâ bulut yönlendirmesine dayanıyor.

GitHub Copilot'a cihaz üzerinde çalışan modeller ekledi, ancak oturumlar hâlâ bulut üzerinden yönlendiriliyor

GitHub ne duyurdu

dev.to'daki bir yazıya göre GitHub, 28 Ekim'de yaptığı bir duyuruyla cihaz üzerinde çalışan modelleri Copilot'a ekledi. Bu yetenek, tercihe bağlı deneysel bir yönlendirme önizlemesi olan Copilot Fusion içinde yer alıyor ve Copilot CLI, Copilot uygulaması ve VS Code'daki desteklenen yerel modelleri kapsıyor.

Kurulum ortama göre farklılık gösteriyor: Yazı, yönetilen bir Windows yapılandırması ile yöneticilerin kendilerinin bağladığı manuel yapılandırılmış sağlayıcılar arasında bir ayrım yapıyor. Ayrıca iki kullanım modunu birbirinden ayırıyor — doğrudan yerel bir model seçmek ve Fusion'ın çalışma zamanında yerel ile bulut modelleri arasında karar vermesine izin vermek. Yazar, bunların farklı işleyiş düzenlerini tanımladığını ve tek başına neither etiketin bir isteğin gerçekte nasıl aktığını söylemediğini savunuyor.

Asıl mesele: yerel, çevrimdışı demek değil

Yazının merkezindeki uyarı, "yerel" kelimesini "çevrimdışı" olarak okumanın bir hata olacağı. GitHub, oturumun hâlâ bulut yönlendirmesi kullandığını açıkça belirtiyor. Cihazda çalışan bir model yalnızca tek bir soruyu yanıtlıyor: çıkarım (inference) nerede yürütülüyor. Etrafındaki uygulama, modeli seçmek, bağlam getirmek, bir araç çağırmak veya konuşmanın sonraki bir turunu yönetmek için hâlâ uzak hizmetlere erişebilir.

Yazıda özetlendiği şekliyle GitHub'ın Fusion dokümantasyonu, Fusion'ı her isteğe tek bir model sabitlemek yerine çalışma zamanında model seçen bir sistem olarak sunuyor. Yerel model seçimi, Fusion Standard ile ilişkili bir önizleme yeteneği olarak tanımlanıyor ve bir seçicide görünen model, yazının "akıllı yerel yönlendirme" dediği şey için otomatik olarak uygun sayılmıyor. Dolayısıyla ekipler, varsaymak yerine gerçekte yapılandırılmış modu kontrol etmeli.

Hibrit sınırın bir örneği

Ayrımı somutlaştırmak için yazı, Illumia adlı bir arşiv uygulamasını konu alan bir vaka çalışmasına işaret ediyor. Oradaki kayıtlar PostgreSQL'de yerel olarak depolanıyor ve aranıyor, bir Claude Desktop bağlantısı altı adet sınırlı, salt okunur getirme aracı sunuyor ve seçilmiş kanıtlar yalnızca kuruluş onay verdiğinde çevrimiçi Claude'ya gönderilebiliyor. Dikkat çekici olan, o projenin kendi kamuya açık tanımlamasının bile bu iş akışını çevrimdışı olarak adlandırmaktan kaçınması.

Yazarın çıkardığı ders, hibrit bir sistemin doğrulanabilir terimlerle tanımlanması gerektiği: arşivin nerede bulunduğu, getirme işleminin ne yapmasına izin verildiği ve seçilmiş materyalin nereye gidebileceği. Tüm bunları tek bir güven verici sıfatın altında toplamak, önemli kararları gözden gizler.

Sınırı nasıl prova edilir

Yazı, bu tür araçları değerlendiren ekipler için bir test prosedürü ortaya koyuyor. Kurgusal kayıtlarla küçük, atılabilir bir arşiv oluşturun; içine ayırt edici, zararsız bir işaret notu ve kapsam dışında kalması gereken ilgisiz bir kayıt koyun. Yalnızca işaretli notun yanıtlayabileceği dar bir soru sorun, sonra her şey çevrimiçi olmadan önce getirme sonucunu inceleyin — kanıtın yeterli olduğunu ve ilgisiz kayıtların bulunmadığını kontrol edin. Ağ tanılama araçları istek yolunu izlemek için kullanılmalı, ayrıca kopyalanan prompt'ların ikinci bir istenmeyen hedef oluşturmaması için günlükler sınırlı tutulmalı.

Sonraki adım, o atılabilir ortamdaki harici hizmeti kesmek ve neyin ayakta kaldığını kaydetmektir: yerel arama kaynağı hâlâ gösteriyor mu ve yardımcı, anlaşılır bir mesajla mı duruyor yoksa operatör işlerin devam ettiğini varsayarken sessizce mi bekliyor. Bir görev tamamen çevrimdışı olarak tanımlandıysa, çıkarımın kendisi cihazda çalışacak olsa bile harici bir yönlendirme bağımlılığı gereksinimi düşürür.

Bu egzersiz bir kez yapılıp biten bir şey değil. Anlamlı yapılandırma veya model değişikliklerinden sonra tekrarlanmalı ve yalnızca bir bağlantı günlüğü, bir isteğin ne içerdiğini veya sözleşmesel olarak nasıl işlendiğini belirleyemez. Yazı, tersine yönelen bir sıçramaya karşı da uyarıyor: bulut yönlendirmesinin varlığı, bir ürünün hangi kayıt alanlarını ilettiğini kanıtlamaz. Dokümantasyon, yapılandırma ve gözlem birlikte kullanılmalı; hiçbiri tek başına tam kanıt sayılmamalı.

Neden önemli

Yerel modelleri Copilot'a yerleştirmek, cihaz üzerindeki hesaplama gücünü çok daha erişilebilir kılıyor; ancak bu, "yerel" kelimesine aşırı güvenmeyi de kolaylaştırıyor. Gizlilik veya uyumluluk kısıtlamaları olan kuruluşlar için yararlı satın alma sorusu, bir ürünün yerel yapay zekâyı destekleyip desteklemediği değil; arama, yönlendirme, çıkarım ve araç yolunun hedeflenen işletim sınırını karşılayıp karşılamadığıdır — ve bu sınır varsayılmamalı, test edilmelidir. Hibrit yönlendirme kolaylık sağlarken daha büyük ve daha az kontrollü bir yüzey bedeli getiriyor; kasıtlı olarak izole edilmiş bir iş akışı ise bir ekibin kendi yığınının daha fazlasını işletmesini ve doğrulamasını gerektiriyor. Not edilmesi gereken bir uyarı daha: dev.to'daki gönderinin kendisi, yapay zekâ ile üretilip doğrulandığını ve adı geçen yazarın incelemesi olmadan otomatik bir iş akışıyla yayınlandığını belirten bir beyan taşıyor; dolayısıyla okuyucular ayrıntıları GitHub'ın kendi dokümantasyonuna karşı doğrulamak isteyebilir.

  • #github-copilot
  • #on-device-ai
  • #copilot-fusion
  • #privacy
  • #developer-tools

İlgili yazılar