list_altİçindekilerexpand_more
- 01Semantic Kernel Nedir?
- 02Temel Bileşenler
- 03Kernel
- 04Plugins
- 05Memory
- 06Filters
- 07Plugin Sistemi ve Function Calling
- 08Memory ve RAG Entegrasyonu
- 09Planner: Otomatik Görev Zincirleme
- 10Semantic Kernel vs LangChain
- 11MCP ve Dış Araç Entegrasyonu
- 12Gerçek Dünya Kullanım Senaryoları
- 13Kurulum ve İlk Kullanım
- 14Python
- 15.NET / C#
- 16Ekosistem ve Kaynaklar

Microsoft’un 2023’te açık kaynak olarak yayımladığı Semantic Kernel, enterprise .NET dünyasının önemli AI altyapı katmanlarından biri haline geldi. C#, Python ve Java desteğiyle farklı ekosistemlerden geliştiricilere hitap eden bu SDK, LLM’leri mevcut kod tabanlarına entegre etmenin yapısal bir yolunu sunar. LangChain gibi köklü alternatiflerin yanında SK’nın ayırt edici tarafı, .NET entegrasyonu ve Azure altyapısına olan yerleşik desteğidir.
Semantic Kernel Nedir?
Semantic Kernel (SK), büyük dil modellerini yazılım uygulamalarına entegre etmek için tasarlanmış açık kaynak bir AI orkestrasyon SDK’sıdır. Microsoft tarafından geliştirilir ve GitHub’da aktif olarak sürdürülür.
SDK’nın temel amacı şu: LLM çağrıları, araç kullanımı, bellek yönetimi ve görev planlama gibi karmaşık AI katmanlarını, geliştiricilerin tanıdığı dil yapıları ve kütüphane konvansiyonları içinde kullanılabilir kılmak. Bunu yaparken, hangi LLM sağlayıcısı kullanıldığından bağımsız çalışacak şekilde tasarlanmış bir soyutlama katmanı oluşturur.
Microsoft, Semantic Kernel’i kendi ürünlerinde de etkin biçimde kullanıyor: Copilot, Microsoft 365 ve Azure OpenAI entegrasyonları bu SDK üzerine inşa edilmiş. Başka bir deyişle SK, bir araştırma projesi değil; Microsoft’un ürün altyapısında zaten çalışan bir SDK.
Desteklenen diller:
- C#: En olgun API yüzeyi; .NET ekosistemiyle derin entegrasyon
- Python: Veri bilimi ve prototipleme için; LangChain/LlamaIndex ekosistemiyle uyumlu
- Java: Kurumsal arka uç sistemlerine yönelik; 2024’te GA statüsüne geçti
Temel Bileşenler
Semantic Kernel’in mimarisi birkaç temel katmandan oluşur. Her katmanın ne yaptığını bilmek, hangi senaryoda neyi kullanacağınızı netleştirir.
Kernel
Her şeyin merkezi. Kernel, kullanılacak LLM sağlayıcısını (OpenAI, Azure OpenAI, Google Gemini, Hugging Face vb.), eklentileri ve bellek bileşenlerini bir arada tutar. Python’da birkaç satırla başlatılır:
from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion
kernel = Kernel()
kernel.add_service(OpenAIChatCompletion(
ai_model_id="gpt-4o",
api_key="sk-..."
))
Plugins
SK’nın en önemli soyutlama katmanı. Bir plugin, LLM’nin çağırabileceği fonksiyonların grubudur. Hem native Python/C# fonksiyonları hem de doğal dil talimatlarıyla yazılan semantic fonksiyonlar desteklenir. Fonksiyon imzaları ve docstring’ler SK tarafından otomatik olarak JSON şemasına dönüştürülüp modele iletilir.
Memory
Embedding tabanlı vektör belleği. SK’nın Memory katmanı, belgeler ve konuşma geçmişini vektör depolarında saklar, semantik arama ile geri çeker. Qdrant, Chroma, Azure AI Search ve Redis gibi yaygın vektör veritabanları için hazır konnektörler bulunur.
Filters
SK 1.0 ile gelen middleware katmanı. Fonksiyon çağrılarının öncesinde ve sonrasında araya girerek loglama, hata yakalama, rate limiting ve güvenlik denetimleri yapılmasına olanak tanır.
Plugin Sistemi ve Function Calling
SK’nın plugin sistemi, LLM’nin araç olarak çağırabileceği fonksiyonları tanımlar. Modern dil modelleriyle entegrasyon, function calling protokolü üzerinden çalışır: fonksiyon şeması JSON formatında LLM’ye iletilir, model hangi fonksiyonu ve hangi parametrelerle çağıracağına kendisi karar verir.
Python’da bir native plugin şöyle görünür:
from semantic_kernel.functions import kernel_function
class WeatherPlugin:
@kernel_function(
name="get_weather",
description="Bir şehrin anlık hava durumunu getirir"
)
def get_weather(self, city: str) -> str:
# Gerçek uygulamada API çağrısı buraya gelir
return f"{city}: 22°C, parçalı bulutlu"
C#‘ta attribute tabanlı yaklaşım kullanılır:
public class WeatherPlugin
{
[KernelFunction("get_weather")]
[Description("Bir şehrin anlık hava durumunu getirir")]
public string GetWeather(
[Description("Şehir adı")] string city)
{
return $"{city}: 22°C, parçalı bulutlu";
}
}
Her iki yaklaşımda da JSON şeması SK tarafından otomatik üretilir ve LLM’ye iletilir. Geliştiricinin manuel JSON şema yazmasına gerek kalmaz.
Function calling’in LLM ekosistemindeki rolü hakkında ayrı bir rehberimiz mevcut. SK’nın bu mekanizmayı nasıl soyutladığını görmek, özellikle model sağlayıcı değiştirirken daha anlamlı hale gelir: aynı plugin kodu OpenAI, Azure OpenAI veya Gemini ile değişiklik gerektirmeksizin çalışır.
Memory ve RAG Entegrasyonu
Semantic Kernel’in Memory katmanı, RAG pipeline’larını doğrudan desteklemek üzere tasarlanmış. Farklı kaynaklardan gelen belgeleri indexlemek ve semantik arama yapmak için SemanticTextMemory arayüzü kullanılır.
from semantic_kernel.memory import SemanticTextMemory
from semantic_kernel.connectors.memory.chroma import ChromaMemoryStore
memory = SemanticTextMemory(
storage=ChromaMemoryStore(persist_directory="./chroma_db"),
embeddings_generator=kernel.get_service("embedding")
)
# Belge ekleme
await memory.save_information(
collection="belgeler",
id="doc-1",
text="Semantic Kernel, Microsoft'un geliştirdiği AI SDK'sıdır."
)
# Semantik arama
results = await memory.search("belgeler", "Microsoft AI SDK")
SK 1.0 sonrasında TextMemoryPlugin bu işlevi plugin formatına taşıdı: LLM, memory_search fonksiyonunu doğrudan araç olarak çağırabilir. Bu yapı, manuel RAG kodu yazmadan LLM’nin kendi bilgi deposuna sorgu atmasını mümkün kılar.
Vektör veritabanı seçeneklerini karşılaştırdığımız yazımızda Qdrant, Chroma ve Pinecone arasındaki farkları inceliyoruz. SK, bu seçeneklerin büyük çoğunluğunu hazır konnektörlerle destekler.
Planner: Otomatik Görev Zincirleme
Semantic Kernel’in dikkat çeken bileşenlerinden biri Planner. Bir kullanıcı hedefi (goal) verilen Planner, mevcut plugin ve fonksiyonlar arasından uygun olanları seçip sıralı veya koşullu bir yürütme planı oluşturur.
Bugün SK’da iki ana planlama yaklaşımı kullanılıyor:
Handlebars Planner: Şablon tabanlı görev zinciri. Adımlar ve değişken geçişleri açıkça tanımlanır; deterministik davranışa sahiptir ve denetimi kolaydır. Üretim ortamlarında güvenilir çıktı gerektiren senaryolar için tercih edilir.
Auto Function Invocation: LLM’nin kendi başına hangi fonksiyonları çağıracağına karar verdiği mod. FunctionChoiceBehavior.Auto() ayarıyla aktif edilir; daha esnek ama çıktısı daha az öngörülebilir.
var settings = new OpenAIPromptExecutionSettings
{
FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};
var result = await kernel.InvokePromptAsync(
"İstanbul'un hava durumunu öğren ve haftalık tahmin yap.",
new KernelArguments(settings)
);
Planner yaklaşımı, AI agent framework karşılaştırmaları bağlamında SK’yı LangGraph ve CrewAI’ye yaklaştırır. Temel fark şu: SK, .NET entegrasyonu gerektiren kurumsal ortamlarda birinci sınıf destek sunarken LangGraph, döngü ve durumlu graph akışlarında daha ince ayar yapılabilirliği öne çıkarır.
Semantic Kernel vs LangChain
Geliştiricilerin en çok sorduğu soru: LangChain varken neden Semantic Kernel?
| Özellik | Semantic Kernel | LangChain |
|---|---|---|
| Birincil dil | C# (Python/Java de var) | Python (JS de var) |
| Kurumsal entegrasyon | Güçlü (.NET, Azure) | Orta |
| Topluluk büyüklüğü | Büyüyen | Çok büyük |
| API stabilitesi | SK 1.0+ iyi | Sürümler arası kırılmalar var |
| Planner olgunluğu | Handlebars + Auto Invocation | LCEL + LangGraph |
| Memory yönetimi | Yerleşik, basit | Eklenti tabanlı, çeşitli |
| Dokümentasyon kalitesi | Microsoft desteğiyle güçlü | Geniş topluluk içeriği |
| Enterprise destek | Microsoft SLA | Üçüncü taraf |
.NET tabanlı arka uç sistemlerde, Azure ekosistemiyle çalışan projelerde veya Copilot entegrasyonu gerektiren uygulamalarda SK belirgin avantaj taşır. Saf Python projelerinde ya da topluluk katkısını önceliklendiriyorsanız LangChain veya LlamaIndex daha hızlı başlangıç noktası sunar.
LangChain’in mimarisini daha ayrıntılı incelediğimiz yazımız, iki framework arasındaki farkları somut kod örnekleriyle ortaya koyuyor.
MCP ve Dış Araç Entegrasyonu
Model Context Protocol (MCP), 2025’te yaygınlaşan açık bir araç entegrasyon standardı. SK, 1.x versiyonundan itibaren MCP istemci desteğini resmen eklemesiyle birlikte, MCP server olarak sunulan araç ve veri kaynaklarına doğrudan bağlanabiliyor.
Pratik etkisi şu: bir MCP server’ını SK plugin olarak kaydetmek birkaç satır kod. Şirketin iç araç ekosistemi MCP üzerinden sunuluyorsa SK bu araçları otomatik keşfedebilir ve LLM’e sunar.
from semantic_kernel.connectors.mcp import MCPSsePlugin
# MCP server'ını plugin olarak ekle
mcp_plugin = MCPSsePlugin(
name="InternalTools",
url="http://tools.internal/mcp"
)
kernel.add_plugin(mcp_plugin)
Bu entegrasyon, MCP protokolünün kurumsal benimsenmesini hızlandıran önemli adımlardan biri. SK kullanan ekipler, kendi araçlarını MCP server olarak yayınlayarak hem SK’da hem de diğer MCP istemcilerinde (Claude Desktop, Cursor gibi) aynı toolset’i paylaşabilir. Araç tanımları tek yerden yönetilir; her istemciye ayrı entegrasyon yazılmasına gerek kalmaz.
Gerçek Dünya Kullanım Senaryoları
Şirket içi dokümanlardan anlamsal arama yapan kurumsal bilgi asistanları, SK’nın en yaygın kullanım alanı. TextMemoryPlugin ve vektör DB konnektörleriyle bu yapıyı nispeten az kod yazarak kurmak mümkün; chatbot yanıtları kaynak göstererek destekleniyor.
Kod inceleme tarafında Azure DevOps ve GitHub Actions pipeline’larıyla entegre araçlar öne çıkıyor. Microsoft’un Copilot for Azure bu kategorinin üretim örneklerinden biri; otomatik review özeti ve kod açıklaması üretiyor.
Yüzlerce sayfalık raporlar veya teknik şartnameler üzerinde sorgu çalıştıran sistemler de SK’ya iyi uyuyor. Chunking, embedding ve semantic search katmanları aynı SDK içinde bulunduğundan ayrı kütüphaneleri birbirine bağlamak gerekmiyor.
Çok adımlı iş akışı otomasyonu ise Handlebars Planner’ın en güçlü olduğu alan. Kullanıcıdan alınan bir talebi önce veritabanında araştıran, ardından harici API’den güncel veri çeken ve sonucu belirli bir formatta sunan ajan zincirlerinde deterministik plan yapısı işe yarıyor.
Kurulum ve İlk Kullanım
Python
pip install semantic-kernel
Minimal başlangıç örneği:
import asyncio
from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion
from semantic_kernel.contents import ChatHistory
async def main():
kernel = Kernel()
kernel.add_service(OpenAIChatCompletion(
ai_model_id="gpt-4o-mini",
api_key="YOUR_API_KEY"
))
chat_history = ChatHistory()
chat_history.add_user_message("Python'da Semantic Kernel'i nasıl kullanırım?")
response = await kernel.get_service().get_chat_message_content(
chat_history=chat_history
)
print(response)
asyncio.run(main())
.NET / C#
dotnet add package Microsoft.SemanticKernel
using Microsoft.SemanticKernel;
var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o-mini", "YOUR_API_KEY");
var kernel = builder.Build();
var result = await kernel.InvokePromptAsync(
"Semantic Kernel nedir? Kısaca açıkla."
);
Console.WriteLine(result);
Her iki örnekte de modeli değiştirmek için yalnızca ilgili Add... çağrısını güncellemek yeterli; geri kalan kod dokunulmadan kalır. Sağlayıcı bağımsızlığı SK’nın tasarımında bilinçli bir karar olarak öne çıkıyor.
Ekosistem ve Kaynaklar
Semantic Kernel projesi microsoft/semantic-kernel deposu altında yayımlanıyor ve aktif geliştirilmeye devam ediyor. Haftalık topluluk çağrıları, değişiklik günlüğü ve örnek proje galerisi düzenli güncelleniyor.
Başlangıç için önerilen sıra:
- Resmi dokümanlar:
learn.microsoft.com/semantic-kernel - Örnek projeler:
github.com/microsoft/semantic-kernel/tree/main/python/samples - Discord sunucusu: soruları hızla yanıtlanan aktif bir topluluk
sk-pythonvesemantic-kerneletiketleriyle Stack Overflow
Agentic RAG mimarisi ile SK’yı birleştiren yapılar, özellikle çok adımlı belge araştırması ve analiz pipeline’larında production kullanımına taşınmış durumda. Memory katmanı, Planner ve çoklu plugin birlikte çalışınca tek bir LLM çağrısından öte, bağlam bilen ve araç kullanan bir uygulama katmanı ortaya çıkıyor.
SK’nın .NET ve Azure tarafında olgunluğu tartışmasız. Python API yüzeyi LangChain’e göre daha dar, ama aktif olarak büyüyor. Eğer projenizin altyapısı Azure üzerindeyse ya da C# ekibiniz varsa denemeleri çalıştırmanın maliyeti düşük.



