Bakın şimdi, “yerel yapay zekâ ajanı” lafı son iki yılda öyle şişti ki insan önce durup soruyor: Bu gerçekten iş yapan bir şey mi, yoksa tarayıcıya eklenmiş şık bir sohbet kutusu mu? EchoKernel tam da bu gürültünün ortasında, ilginç bir yerde duruyor (eh, fena değil). Ne devasa ekran kartı istiyor ne de sadece “cevap verip bırakıyor.” Komut alıyor, sesi yazıya çeviriyor, niyeti çözüyor ve sonra yerel makinede bir şeyler yapıyor — dosya oluşturuyor, kod yazıyor, metin özetliyor (şaşırtıcı ama gerçek). yani laf kalmıyor, iş çıkıyor.
Geçen ay Kadıköy’de kahve içerken küçük bir deneme yapmıştım; laptop’ta çalışan basit bir agent’a sesle komut verdim. Açık konuşayım, yarısı heyecan yarısı hayal kırıklığıydı. Çünkü çoğu sistem “beni dinle” kısmında fena değil ama “şimdi bunu gerçekten uygula” noktasında tökezliyor. EchoKernel’in ilgimi çekmesinin sebebi de tam olarak bu: zinciri açık açık gösteriyor. Her adımı değiştirebileceğiniz kadar sade kuruyor.
Ve işler burada ilginçleşiyor.
EchoKernel Ne Yapıyor, Ne Yapmıyor?
Sistemin en sevdiğim tarafı beklentiyi net koyması oldu. Kullanıcı ister sesle ister yazarak komut veriyor; ardından Whisper tabanlı STT katmanı bunu metne dönüştürüyor. Sonra LLaMA 3.3 70B gibi büyük bir model devreye girip niyeti sınıflandırıyor. Bu aşama önemli — çünkü her komutu “aynı türden” görmeyen, düzgün ajanlar ancak böyle kuruluyor, başka türlü değil.
İşin devamında araç yönlendirme var. Model “bu kod yazma işi”, “bu özetleme”, “bu sohbet” diye karar veriyor ve uygun yerel fonksiyona paslıyor (en azından benim deneyimim böyle). Sihir yok aslında burada. İyi ayrıştırılmış görevler var, o kadar. Basit görünüyor ama pratikte bayağı kritik — tek parça bir süper ajan yerine küçük ama net roller daha az saçmalıyor, bunu kendi projelerimde defalarca gördüm.
Bir de güvenlik tarafı var ki ben buna özellikle baktım. Her şey output/ klasörüne hapsediliyor. Kulağa sıradan gelebilir bu,. Kurumsal tarafta işin rengi değişiyor; dosya sistemine kafasına göre dağılan araçlar çok hızlı bela çıkarır. Geçen sene Şişli’deki bir startup’ın iç aracında benzer problem görmüştüm — otomasyon yanlış klasöre log atınca tüm ekip yarım gününü kaybetmişti. Gereksiz yere.
Neden bu mimarı biraz daha mantıklı?
Monolitik değil diyelim; ya da durun, daha doğru söyleyeyim: her şeyi tek dev modele yığmıyor (en azından benim deneyimim böyle). STT ayrı, intent ayrılmış, tool execution ayrı tutulmuş. Ve sonuç: mesela Whisper yerine faster-whisper takmak isterseniz sadece tek fonksiyonu elinizden geçiriyorsunuz. Güzel değil mi?
Hmm, bunu nasıl anlatsamdı…
| Bileşen | Görev | Neden önemli? |
|---|---|---|
| STT Servisi | Sesi yazıya çevirir | Kullanıcının söylediğini düzgün yakalar |
| Niyet Katmanı | Komutu JSON’a döker | Ajanın ne yapacağını netleştirir |
| Araç Çalıştırıcı | Yerel işlemleri yapar | Kod üretme, dosya yazma gibi işleri halleder |
| Bellek Katmanı | Oturum geçmişini tutar | Kullanıcıyla bağlam kopmaz |
Sistem Akışı Neden Önemli?
Aslında, Akış meselesi sıkıcı gelebilir, biliyorum. Ama asıl oyun orada dönüyor. Browser’dan gelen ses blob’u FastAPI’ye gidiyor; oradan transcription alınıyor; sonra intent çözülüyor; en sonda local tool çalışıyor. Bu sıranın büyük avantajı şu: hata nerede çıktıysa bulmak kolaylaşıyor. Ciddi fark bu. Alibaba Qwen’i Nasıl Büyüttü, Parayı Nereden Arıyor? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Claude Code sahneyi kaptı: HumanX’ten çıkan asıl dersler yazımıza da göz atmanızı tavsiye ederim. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
2024 sonunda kendi test ortamımda benzer bir pipeline kurarken en çok zorlandığım konu görünmez aralardı — hani kullanıcı “neden olmadı?” diyor ya, siz de log’un hangi adımda koptuğunu anlamaya çalışıyorsunuz saatlerce. EchoKernel’in sıralı tasarımı o yüzden güzel; debug etmek, nasıl desem, daha az sınır bozucu oluyor (evet, doğru duydunuz). Küçük ama önemli bir fark. Bu konuyla ilgili Claude Desktop’a Mila Bağlama: 30 Saniyede MCP Kurulumu yazımıza da göz atmanızı tavsiye ederim.
En güçlü taraf burada gizli: Modeli büyütmekten önce sistemi bölmek gerekiyor.
Bir ajanın gerçekten işe yaraması için önce ne yaptığını bilmesi lazım.
Aksi hâlde elinizde konuşkan ama kararsız bir robot kalır.
Yani, Gel gelelim eksik taraf da var tabii. Tamamen sıralı yapı bazen hız kaybettirir; özellikle — itiraz edebilirsiniz tabi — çok adımlı işler üst üste binince bekleme hissi oluşuyor. Küçük projelerde sorun değil ama enterprise seviyede, aynı anda onlarca isteği taşırken cache, queue ve rate limit gibi ek katmanlara ihtiyaç doğar — kaçış yok bundan. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Küçük Bir Laptop’ta Büyük Söz Vermek Kolay Değil
No-GPU iddiasının gerçek hayattaki karşılığı
No-GPU çalışmak kulağa pazarlama cümlesi gibi geliyor olabilir. Ama kıymetli olan şu: herkesin RTX canavarı yok! Kendi MacBook Air M2 cihazımda benzer testler yaptığımda ağır modeller hemen nefes nefese kalmıştı; o yüzden görevleri ayırmak mantıklı geliyor bana.
İnanın, Eğer hedefiniz hızlı prototip işe lokal çalışan hafif parçalar sızı kurtarır. Ama karmaşık muhakeme bekliyorsanız — işte orada sınırlar başlıyor. Lafı gevelemeden söyleyeyim: küçük makinelerde başarı çoğu zaman model gücünden değil, iş akışını doğru bölmekten geçiyor (ciddiyim). Bu kadar basit aslında.
Küçük startup ile kurumsal ekip aynı şeyi mi ister?
Hani, Hayır istemezler. Bayağı farklı isterler diyeyim. Küçük startup için önemli olan hızlı deneme yapmak: dosya oluşturulsun, kod taslağı çıksın, bir özeti anında alsın. Kurumsalda işe izlenebilirlik, yetkilendirme, loglama ve veri sınırları öne çıkar. Yani aynı agent farklı dünyalarda farklı ayakkabı giyer.
- Küçük ekip: Hızlı kurulum, düşük maliyet, minimum bakım yükü.
- Büyüyen ürün: Modüler yapı, hata izolasyonu, genişletilebilir tool set’i.
- Kurumsal ortam: Audit log’ları, sandbox güvenliği, rol bazlı erişim.
Tatlı olan taraf şu ki EchoKernel tam ortada durmaya çalışıyor. Ne oyuncak kadar yüzeysel, ne de laboratuvar dışında kullanılması zor kadar ağır. Bu denge bana makul geldi açıkçası. Ama yine de beklediğim kadar cilalı değildi; özellikle çoklu oturum senaryolarında biraz daha pişmesi lazım.
Peki Niyet JSON’u Neden Bu Kadar Kritik?
Düz metin yerine yapılandırılmış çıktı almak neden iyi?
Düz metin cevaplar sohbet için tamamdır ama ajan dünyasında yetmez. Çünkü bilgisayarın anlaması gereken şey şiir değil; alanları belli nesnelerdir: primary_intent, target_filename, summary_length gibi… Bu yüzden JSON çıktısı oyunu değiştiriyor (buna dikkat edin). Model ne demek istediğini yalnızca anlatmıyor, makinenin okuyacağı biçimde paketliyor. Fark büyük.
{
"primary_intent": "write_code",
"target_filename": "retry.py",
"language": "python",
"needs_confirmation": false
}Editör masasında bu örneği görünce içimden “tamam işte” dedim. Çünkü bundan sonrası artık tahmin değil; kural motoru gibi çalışabiliyor. Birinci sınıf büyü falan yok burada — sadece düzgün şema tasarımı var (en azından benim deneyimim böyle). Hepsi bu.
Nerede duvara toslayabilir?
Tuhaf ama, Bence en hassas nokta intent çözümleme hatalarıdır. Mesela kullanıcı aslında kod istiyordur ama model önü özetleme sanabilir. Ya da filename üretirken saçma sapan işim döndürebilir — evet, oluyor bu. Bu yüzden doğrulama katmanı şart; Pydantic benzeri şemalar burada hayat kurtarıyor.
Neyi Beğendim, Neyi Eksik Buldum?
Beni en çok etkileyen şey açıklık oldu. Pipeline kapalı kutu değil; her aşama görülebiliyor ve değiştirilebiliyor. Bugün Groq API kullanırsınız, yarın lokal STT’ye geçersiniz, öbür gün başka bir intent modeli takarsınız — sistem dağılıp gitmiyor. Baya iş görüyor bu yaklaşım.
Kusursuz mu? Değil. Bilhassa üç noktada biraz tereddüt yaşadım: ilk olarak network bağımlılığı hâlâ var, ikinci olarak büyük model çağrıları ucuz sayılmaz, üçüncü olarak da UI sade olsa bile bazı kullanıcılar için fazla teknik kalabiliyor. Dür bir saniye — bu üçüncü madde aslında önemli, çünkü her iyi mühendislik çözümü iyi ürün deneyimi vermiyor. Maalesef.
Bana göre artılar ve eksiler şöyle toparlanır:
| Artılar | Eksi taraflar |
|---|---|
| Açık mimarı ve kolay modifikasyon | Büyük modellere bağlı olunca maliyet artabiliyor |
| Laptop’ta GPU’suz çalışma hedefi, öğrenmesi kolaylaştırıyor | Sıklıkla internet bağlantısına ihtiyaç duyuyor |
Sıkça Sorulan Sorular
Sesli ajan neden hâlâ “oyuncak” gibi kalıyor?
Çünkü çoğu sistem sızı dinleyip metne çeviriyor, ama “şimdi bunu gerçekten uygula” kısmında araç yürütme ve süreç yönetimi zayıf kalıyor. Tek parça bir model her şeyi aynı anda yapınca da hatalar zincir gibi büyüyebiliyor. İyi tasarımda adımlar ayrılıyor: STT, niyet çıkarımı ve tool execution ayrı ele alınıyor.
EchoKernel gibi mimarilerde STT neden kritik?
Konuşmayı doğru yakalayamazsan niyet katmanı da yanlış JSON üretir ve sonuçta araçlar yanlış çalışır. Bu yüzden STT katmanı, sadece “çeviri” değil tüm ajanın doğruluk temelidir. Benim denemelerimde, daha iyi bir STT (ör. faster-whisper gibi) özellikle aksan/gürültü olan ortamlarda fark yaratıyor.
Niyetin JSON’a dökülmesi ne kazandırıyor?
Niyetin yapılandırılmış bir formatta çıkması, aracın ne yapacağını netleştiriyor ve belirsizliği azaltıyor. Böylece model “sohbet edip bırakmak” yerine belirli bir eylem akışını tetikleyebiliyor. Ayrıca tool yönlendirme daha deterministik olduğu için beklenmedik davranışlar azalıyor.
Yerelde çalıştırmak (local execution) güvenlik açısından neden avantajlı?
Dosyaların ve çıktının belirli bir klasöre hapsedilmesi, otomasyonun “rastgele yerlere yazma” riskini düşürüyor. Kurumsal tarafta en sık sorunlardan biri, yanlış path’e log/dosya atılması ya da beklenmeyen yan etkiler. Benzer bir aksaklığı daha önce görmüştüm; doğru sandbox yaklaşımı ciddi zaman kazandırıyor.
Bu tür ajanlar “monolitik” değil mi, nasıl daha az saçmalıyor?
Tek dev bir modele her şeyi yığmak yerine görevleri bölmek (STT ayrı, intent ayrı, araç çalıştırma ayrı) daha stabil sonuç veriyor. Her adım kendi sorumluluğuna odaklanınca hem hata ayıklaması kolaylaşıyor hem de bileşen değişimi (ör. STT’yi değiştirmek) daha basit oluyor. Sonuç olarak ajan, daha tutarlı biçimde “iş üreten” bir akışa dönüşüyor.
Kaynaklar ve İleri Okuma
Azure AI Speech Service (STT için resmî dokümantasyon)
Azure OpenAI Service — Genel Bakış ve kullanım kılavuzu
openai/whisper (STT modeli ve proje arka planı)
faster-whisper (daha hızlı Whisper tabanlı STT uygulaması)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
