Kuruluşta GenAI: Mevcut .NET Foundation'ınızı kullanın

kapanış bildirimi

Bu makale İngilizce olarak da mevcuttur. Teknik yardımla tercüme edildi ve yayınlanmadan önce editoryal olarak gözden geçirildi.

Üretken yapay zeka, bireysel deneylerde ve prototip oluşturmada gerçek faydalar sağlamaz; bunun yerine mevcut yazılım ürünleri, platformlar ve iş süreçleri GenAI kullanılarak özel olarak genişletildiğinde gerçek faydalar sağlar.

Duyurudan sonra devamını okuyun

Rainer Stropek, Microsoft ortamında çalışan bir BT girişimcisi, yazılım geliştiricisi, eğitmeni, yazarı ve konuşmacısıdır. 2010 yılından bu yana Microsoft Azure'un MVP'sidir ve ekibiyle birlikte Time Cockpit yazılımını geliştirmektedir.

C# ve .NET çoğu zaman çok sayıda ERP sisteminin, bireysel uygulamanın ve standart ürünün temelini oluşturur. Bu platformun etrafında kapsamlı bilgi birikimi, istikrarlı oluşturma ve dağıtım boru hatlarının yanı sıra kanıtlanmış operasyonel ve güvenlik konseptleri yatmaktadır. Bu yatırımlar uzun vadelidir ve kolaylıkla telafisi mümkün değildir.

GenAI için komple sistemleri yeniden geliştirmek yerine, mevcut uygulamaların yardım işlevleri, bağlamla ilgili destek, kısmen otomatik iş akışları veya Copilot benzeri uzantılar aracılığıyla daha akıllı hale gelmesi gerekiyor. Bu hedefe ulaşmak için Büyük Dil Modelleri (LLM) mevcut mimarilere sorunsuz bir şekilde entegre edilebilmelidir.

GenAI Zirvesi, çizgiler

GenAI, yazılım geliştirmeyi temelden değiştiriyor ve birçok geliştiricinin günlük çalışmalarında kendini kanıtlıyor. Yapay zeka araçları yalnızca can sıkıcı yazma işleriyle ilgilenmekle kalmıyor, aynı zamanda karmaşık görevlere de yardımcı oluyor. Ancak güvenli ve verimli kod elde etmek için riskleri de anlamanız gerekir.

11 Haziran'daki BetterCode() GenAI zirvesi, hangi AI araçlarının hangi görevlere uygun olduğunu ve AI entegrasyonunun nasıl verimli bir şekilde çalıştığını gösterecek. Ayrıca geliştirme ekiplerinin çalışmaları üzerindeki etkileri de ele alır.

Deney ve üretim sistemi arasındaki fark işte burada ortaya çıkıyor. Python'da bir kavram kanıtı hızlı bir şekilde uygulanabilir. Ancak üretim sistemleri için diğer kriterler önemlidir: mevcut kimlik doğrulama mekanizmalarına entegrasyon, dahili hizmetlere ve veritabanlarına erişim, mevcut kitaplıkların yeniden kullanımı, temiz günlük kaydı, tekrarlanabilir yapılar ve açıkça düzenlenmiş işlemler. Her ek dil ve her yeni araç zinciri karmaşıklığı, dolayısıyla çabayı ve riski artırır.

Bu açıdan bakıldığında .NET, GenAI uygulamaları için oldukça uygundur. .NET'in temelde yapay zekaya daha uygun olması nedeniyle değil, deneyden üretim uygulamasına geçişi büyük ölçüde kolaylaştırdığı için. Mevcut ekipler tanıdık araçlarla çalışabilir, mevcut altyapı kullanılabilir durumda kalır ve yönetişim ve güvenlik gereksinimlerinin karşılanması daha kolaydır.

Duyurudan sonra devamını okuyun

Aynı zamanda: .NET, yapay zeka ile ilgili araştırma, model eğitimi veya ilk keşif için nadiren ilk tercihtir. Bu alanlarda Python ve giderek daha fazla TypeScript hakimdir. Yeni çerçeveler ve API'ler genellikle ilk önce görünür.

Ancak işletmelerdeki üretken GenAI sistemleri için, uygun SDK'ların mevcut olması koşuluyla .NET genellikle en belirgin platformdur. Hiç kimse sırf bir LLM'ye bağlanmak için HTTP istekleri, JSON ayrıştırma ve eşzamansız olay akışlarıyla protokol düzeyinde çalışmak istemez.

İyi yönetilen .NET SDK'ları bu nedenle bir lüks değil, kolaylaştırıcıdır. Mevcut geliştirme ekiplerinin GenAI'yi hızlı, güvenli ve sürdürülebilir bir şekilde entegre edip edemeyeceğini veya gereksiz yıpranma kayıplarının meydana gelip gelmeyeceğini belirlerler. Mevcut sağlayıcılara ve soyutlamalara bir bakış, mevcut SDK ortamının bugün bu gereksinimi ne kadar iyi karşıladığını gösterir.

.NET ile Yüksek Lisans kullanmak isteyen herkes, bugün bir yıl öncesine göre çok daha çeşitli bir SDK ortamı bulacaktır. Ancak mevcut tüm SDK'lar eşit şekilde oluşturulmaz ve hepsi üretim uygulamalarına uygun değildir.

Aşağıdaki şekil temel SDK, LLM proxy'si, aracı katmanı, sunum katmanı ve MCP arasındaki bağlantıyı göstermektedir. Sonraki bölümlerde bu noktalar daha ayrıntılı olarak tartışılacaktır. Makale özellikle SDK ortamını .NET perspektifinden konumlandırmaya odaklanıyor.

Çekirdek SDK'ların, LLM proxy'lerinin, aracı katmanının, sunum katmanının ve MCP'nin konumu.

Çekirdek SDK'ların, LLM proxy'lerinin, aracı katmanının, sunum katmanının ve MCP'nin konumu.

Çekirdek SDK'ların, LLM proxy'lerinin, aracı katmanının, sunum katmanının ve MCP'nin konumu.

Uzun bir süre boyunca, büyük dil modellerine yönelik resmi SDK'lar neredeyse yalnızca Python ve TypeScript için mevcuttu. İşler değişmeye başlıyor. Birçok büyük şablon satıcısı artık üretim uygulamalarına uygun .NET SDK'ları sağlıyor.

OpenAI API'sine yönelik ilk ciddi C# SDK'ları doğrudan OpenAI tarafından değil, iki şirket arasındaki yakın stratejik ortaklığın bir parçası olarak Microsoft tarafından oluşturuldu. Ancak yine de zayıf yönleri vardı. Bir geçiş aşamasından sonra OpenAI'nin kendisi sorumluluğu üstlendi. Bugün resmi C# SDK'sı doğrudan OpenAI tarafından yönetiliyor ve normal bir NuGet paketi olarak yayınlanıyor. Microsoft ayrıca bir yardımcı paket de sağlar. Diğer şeylerin yanı sıra Azure Foundry'de OpenAI ile kimlik doğrulamayı, yapılandırmayı ve entegrasyonu kolaylaştırır ancak isteğe bağlıdır. Bugün, OpenAI modellerine erişmenin temel işlevi açıkça resmi OpenAI SDK'nın kendisinde bulunmaktadır.

Anthropic, şu anda beta olarak işaretlenen ancak halihazırda kullanılabilen resmi bir C# SDK'sı sağlar. Google, GenAI SDK'sı ile Gemini modelleri (hem Google AI hem de Vertex AI) için resmi bir .NET bağlantısı sunar. Bugün, diğer LLM sağlayıcıları için satıcı tarafından bakımı yapılan resmi .NET SDK'lar da bulunmaktadır.

Ancak OpenAI SDK en olgun ve popüler olanıdır. İlgili GitHub deposunda birkaç bin yıldız var ve NuGet paketinin yaklaşık 35 milyon indirmesi var.

Resmi SDK'lara ek olarak çok sayıda topluluk ve açık kaynak SDK'sı mevcuttur. TryAGI projesi burada özel bir rol oynuyor ve OpenAI spesifikasyonlarına dayalı olarak çeşitli LLM satıcıları için sistematik olarak C# SDK'ları oluşturuyor.

Bu, Mistral gibi sağlayıcılar ve Ollama gibi platformlar da dahil olmak üzere, resmi .NET kitaplığı bulunmayan birçok model için SDK'ların kullanılabilir olmasını sağlar. Yaklaşım pragmatiktir: SDK'lar tutarlı bir şekilde yapılandırılmıştır, hızlı bir şekilde kullanılabilir ve genellikle temel API işlevlerini güvenilir bir şekilde kapsar. Ancak bunların da sınırlamaları vardır: Oluşturulan SDK'lar, manuel ayarlamalar olmadan veya sınırlı olarak kendi API spesifikasyonlarına nispeten sıkı bir şekilde uyar; bu nedenle gelişmiş API işlevleri bazen düzensiz olabilir veya hiç kullanılamaz. Uzun vadeli bakım, model sağlayıcının kendisine değil, topluluk katılımına bağlıdır.

Bu tür SDK'lar genellikle basit kullanım durumları için tamamen yeterlidir. Ancak daha karmaşık, etkileşimli veya uzun vadeli sistemler için topluluk SDK'sının gereksinimlerinizi karşılayıp karşılamadığını dikkatle kontrol etmelisiniz.

Başka bir kategori, farklı model sağlayıcılarını birleşik bir API arkasında gruplandırmaya çalışan proxy'ler ve uyumluluk katmanlarıdır. Bunun önemli bir örneği, OpenAI uyumlu bir API sağlayan ve istekleri çeşitli modellere yönlendiren LiteLLM'dir.

Bu yaklaşım .NET geliştiricileri için ilginç olabilir çünkü OpenAI SDK'ları kullanabilirler. Genellikle temel URL'yi değiştirmek ve diğer şablon adlarını yapılandırmak yeterlidir. OpenAI uyumlu uç noktalar da sağlayan Ollama aracılığıyla yerel olarak yönetilen modeller için de durum benzer.

Bu soyutlama, bir modelden diğerine ve bir satıcıdan diğerine geçmeyi kolaylaştırır ancak bunun bir bedeli vardır. Uyumluluk düzeyleri genellikle desteklenen API'lerin en düşük ortak paydasına dayanır. Daha yeni veya satıcıya özgü özellikler genellikle sınırlı desteğe sahiptir veya tamamen yoktur. Özellikle daha yeni API çeşitlerinde veya gelişmiş özelliklerde gözle görülür kısıtlamalar olabilir.


Yayımlandı

kategorisi

yazarı:

Etiketler:

Yorumlar

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir