Geçen ay Kadıköy’deki bir kafede oturmuştum, kulaklıklar takılı, kafamda net bir plan: “Tamam, sesle komut alan yerel bir ajan kuracağım.” Hani bazı projeler vardır ya, kağıt üstünde minicik görünür. Sonra terminali açarsın. İş büyür. Bu tam öyle bir şeydi — bir LLM çağırıp birkaç komut çalıştırmak kolay kısmı, esas mesele sistemin gerçek hayatta tökezlediği yerleri teker teker bulup düzeltmek (bu konuda ikircikliyim)
Bak şimdi, Bu yazıdaki hikâye de oradan çıkıyor zaten. İngilizce kaynakta anlatılan şey salt teknik bir demo değil; “şunu da ekleyeyim, şurada bir şey kırıldı” diye ilerleyen, sinir bozucu. Öğretici bir süreç. Açık konuşayım: ses tanıma, bağlam takibi ve yerel model akışı gibi parçalar teoride şık duruyor. Pratikte ise birinin kablosu gevşemiş gibi davranabiliyor.
En sevdiğim taraf şu oldu. Hiçbir yerde OpenAI API’si yok. Kullanım faturası yok, dışarıya veri saçma derdi yok. Whisper, LLaMA 3, Ollama ve Python var — bu kadar. Yani “AI agent yaptım” deyip geçmek yerine, gerçekten makinenin içinde dönen bir sistem kurmaya çalışıyorsunuz. Ve işte tam burada işler ilginçleşiyor.
Neden Bu Tip Ajanlar Bayağı Zor?
Küçük bir detay: Dışarıdan bakınca sesli ajan fikri çok temiz görünüyor (en azından benim deneyimim böyle). Kullanıcı konuşur, sistem anlar, görev yapılır (ki bu çoğu kişinin gözünden kaçıyor). Ama işin aslı şu: aradaki her katman ayrı bir mini problem çıkarıyor. Mikrofon sesi bozuk gelebiliyor, transkripsiyon yanlış çıkabiliyor, niyet sınıflandırması komutu yarım anlayabiliyor… sonra kullanıcı ikinci cümlede bir önceki şeye referans verince bütün zincir hafifçe dağılmaya başlıyor.
Kısa bir not düşeyim buraya.
Ben 2023 sonbaharında benzer bir akışı kendi yan projemde denemiştim. İstanbul’da ofiste sabaha kadar uğraştım ve en sonunda sadece “dosya oluştur” kısmını düzgün çalıştırabildim. O zaman da gördüğüm şey aynıydı: demosu güzel olan sistemlerin çoğu, gerçek kullanımda state yönetimi yüzünden sendelemeye başlıyor. Maalesef.
Bu yüzden bu proje bana basit bir “voice-to-text + action” işi gibi gelmiyor. Aslında küçük ölçekli bir ürün mimarisi dersi gibi, her modülün görevi net olursa bakım kolaylaşıyor — yoksa classifier içine LLM çağrısını gömüp üstüne session memory iliştirince, aman diyeyim, sonra nerede ne kırıldı bulmak işkenceye dönüyor.
Bir Demo ile Gerçek Sistem Arasındaki Fark
Demo gösterirken her şey hızlıdır. Bir komut verirsin, çıktı gelir, herkes alkışlar. Fakat gerçek hayatta kullanıcı bazen mırıldanır, bazen yarım cümle kurar, bazen de önceki isteğine döner: “az önce yazdığın özeti alıp kısa sorular yap.” İşte tam o anda ajanınızın hafızası varsa ayakta kalıyor. Yoksa? Eli kolu bağlı.
Doğrusu, Bu noktada özellikle Sesle Konuşan Ajanlar Neden Hâlâ Oyuncak Gibi Kalıyor? yazısındaki yaklaşım aklıma geldi. Orada da ana fikir aynıydı: sesli deneyim güzel ama bağlam ve hata toleransı zayıfsa oyuncak hissi veriyor. Ciddi fark var.
Mimariyi Bölmek Neden Hayat Kurtarıyor?
Bunu yaşayan biri olarak söyleyeyim, Projenin en sağlam taraflarından biri modüllerin ayrılması olmuş: stt.py, classifier.py, actions.py, ollama_client.py, memory.py, app.py. Bakın şimdi — bu yapı ilk versiyonda yokmuş. Her şey birbirine dolanmış haldeymiş ve debug süreci uzadıkça uzuyormuş. Sonra parçaları ayırınca hem test etmek kolaylaşmış hem de kafa rahatlamış.
Bunu yıllardır görüyorum. Küçük startup’larda insanlar hız için her şeyi tek dosyada topluyor, ilk hafta iş görüyor ama üçüncü haftada kod kokmaya başlıyor. Kurumsal tarafta ise tam tersi: aşırı parçalama yüzünden ekipler bazen basit bir değişiklik için üç repo geziyor. İyi denge şart. Her zaman. Daha fazla bilgi için EKW’de API Yok, Çözüm Var: Tapu Verisine Akıllı Erişim yazımıza bakabilirsiniz.
Evet, doğru duydunuz. Bu konuyla ilgili Black & White’ın 25 Yılı: Yapay Zekânın İlk Çılgın Provası yazımıza da göz atmanızı tavsiye ederim.
| Bileşen | Görev | Neden Önemli? |
|---|---|---|
stt.py |
Sesi metne çevirir | Transkripsiyon hatalarını izole eder |
tagger/classifier.py |
Niyet sınıflandırır | Kullanıcı komutunu doğru aksiyona bağlar |
actions.py |
Eylemleri çalıştırır | Kodun yan etkilerini tek yerde toplar |
memory.py |
Sessiyon bilgisini tutar | Takip komutlarını mümkün kılar |
Şunu fark ettim: Açıkçası bu tabloyu görünce bile içimde bir şey rahatladı, çünkü iyi mimari biraz böyle hissettiriyor: sanki odadaki kablolar toplanmış gibi (en azından benim deneyimim böyle). Mükemmel değil tabii. Yine de insan neyin nerede olduğunu biliyor, bu yeterince değerli (evet, doğru duydunuz)
Bir sistemi sürdürülebilir yapan şey çoğu zaman modelin zekâsı değil, etrafındaki temizliktir. Dağınık mimariyle iyi model birleşince bile sonuç sürpriz verebilir — üstelik kötü yönde.
Sorunların İlki: Whisper Sandığınız Kadar Masum Değil
İlk büyük çarpışma transkripsiyon tarafında geliyor. İnsan doğal olarak “ses metne çevrilir işte” diyor ama Whisper’ın altında ffmpeg bağımlılığı var ve bu detay kaçınca işler karışıyor. Yazarın ilk yaptığı şeylerden biri Whisper’ın iç yükleyicisini global olarak yamamak olmuş: Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
# original approach — don't do this
whisper_audio.load_audio = _load_audio_with_local_ffmpeg
Kulağa pratik geliyor. Ta ki başka bir dosya (belki yanılıyorum ama) Whisper import edene kadar! O anda tüm kod tabanı farkında olmadan patched sürümü kullanmaya başlıyor ve bug’ların kaynağı sis perdesine dönüşüyor. Ben geçen yıl Şişli’de küçük bir müşteri projesinde buna benzer global state meselesi yaşamıştım; tek satırlık, masum görünen o patch iki gün boyunca logları zehirlemişti. İki gün.
Dur bir saniye — aslında şunu da söyleyeyim: global müdahale çoğu zaman kısa vadede kurtarıcı gibi görünür. Uzun vadede borç bırakır. Hep böyle.
Daha Temiz Çözüm Ne?
Daha sağlıklı yaklaşım custom loader’ı doğrudan çağırmak olmuş:
def transcribe(audio_path: str, size: str = "base") -> str:
model = load_model(size)
audio = _load_audio_with_local_ffmpeg(audio_path)
Yani, Bunun farkı şu: artık hangi fonksiyonun ne yaptığı belli oluyor. Sihir yok, sürpriz yok. Ve sürpriz sayısı azaldığında insanın tansiyonu da — en azından ben öyle düşünüyorum — düşüyor — bunu ciddiye alıyorum. Tahmin eder misiniz? Kod bakımının sevilmeyen kahramanı biraz da budur zaten. Bu konuyla ilgili 3D Baskı Savaşı: Jet Motorları Artık Başka Bir Lig yazımıza da göz atmanızı tavsiye ederim.
Niyet Sınıflandırması ve Bağlam Meselesi
Ne yalan söyleyeyim, Sistemin ikinci ayağı LLaMA 3 üzerinden intent classification yapıyor. Buradaki amaç sadece “metni anlamak” değil; bir düşüneyim… kullanıcının ne yapmak istediğini tahmin edip uygun aksiyona yönlendirmek. create_file mı istiyor? summarize mi? chat mi? Yoksa önceden üretilmiş özeti temel alarak quiz mi üretmeli? Bunları ayırt etmek göründüğünden zor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
E tabi asıl tatlı nokta compound command dediğimiz kısımda çıkıyor. “Bunu özetle ve summary.txt olarak kaydet.” Ardından gelen takip komutu: “Önceki özete göre quiz hazırla.” Eğer memory düzgün tutuluyorsa sistem bunu anlıyor. Tutulmazsa? Geçmiş olsun — kullanıcı size tekrar baştan anlatmak zorunda kalıyor (şaşırtıcı ama gerçek) Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
- Create file: İçerik verildiğinde dosya açıp yazar.
- Write code: Kod üretip kaydeder.
- Summarize: Metni özetler, isterse saklar.
- Quiz: Önceki içerikten çoktan seçmeli sorular üretir.
- Chat: Oturum hafızasıyla genel sohbet yapar.
Küçük Startup ile Kurumsal Senaryo Aynı Değil
Küçük ekiplerde bu tür lokal ajanlar çok cazip geliyor çünkü maliyet düşük kalıyor ve veri dışarı çıkmıyor. Mesela iki kişilik bir ürün ekibinde günlük notları özetleyen local assistant baya işe yarar. Ama enterprise seviyeye gelince hikâye değişiyor: loglama, gözlemlenebilirlik, izin yönetimi, ses kayıtlarının gizliliği — bunların hepsi bir anda listenin tepesine tırmanıyor.
Dürüst olmak gerekirse, Şöyle düşünelim. Startup tarafında hedef genelde hızlı prototip olur. Kurumsalda ise “yanlış aksiyon çalıştı mı?” sorusu çok daha önemli hale geliyor (yanlış duymadınız). Dosya oluşturmak eğlenceli olabilir ama yanlış klasöre rapor atarsa sorun çıkar. Bir bankada ya da sağlık uygulamasında bunun şakası olmaz. Hiç olmaz. O yüzden böyle ajanların gerçek değeri yalnızca zekâda değil; kontrol mekanizmasında yatıyor (bizzat test ettim)
Bence En Kritik Üç Risk Şu Taraflarda Toplanıyor
- Sessiz transkripsiyon hataları — ciddi fark yaratıyor
- Kopuk session state
- Niyet sınıflandırmasının yanlış eşleşmesi
- Güvenlik politikalarının eksikliği
Neyi İyi Yapmışlar, Neyi Beklediğim Kadar Değil?
Bana kalırsa projenin sağlam yani modüler düşünmesi ve tamamen lokal çalışmayı hedeflemesi. Bu hem maliyet hem mahremiyet açısından güzel. Ayrıca follow-up command desteği gerçekten değerli; tek seferlik demo değil de süreklilik hissi veriyor. Hani küçük ama önemli fark vardır ya — işte tam o çizgi burada var.
Peki eksik taraf? Şurası biraz ham kalmış: Whisper entegrasyonundaki normalizasyon iyileştirmeleri iyi fikir olsa da farklı mikrofonlarda test edilmeden tam güven vermiyor. Bir de doğal dilde karmaşık niyet ayrıştırması hâlâ narin — kullanıcı uzun konuşunca classifier’ın kaçırdığı detaylar olabiliyor (evet, doğru duydunuz). Bu beni açıkçası biraz hayal kırıklığına uğrattı; kağıt üstünde süper duran kısım pratikte daha çok pişmek istiyor.
Editör Masasında Denediğimde Ne Hissettirdi?
Lafı gevelemeden söyleyeyim. Ben böyle projeleri incelerken önce “terminal canavarına dönüşmüş mü?” diye bakarım. Geçen hafta Levent’te hazırladığım notlardan biri için benzer mantığı test ederken local modelin yanıt süresi gayet kabul edilebilirdi —. Arayüz gecikmeye başlayınca kullanıcı hissi hemen düşüyor (buna dikkat edin). Demek ki hız yalnızca inference süresi değil; UI tepkisi de oyunun parçası. Bunu küçümsemek kolay, hissetmek çok kolay.
Böyle Bir Ajan Kim İçin Mantıklı?
Eğer bağımsız geliştiriciyseniz ya da gizlilik hassasiyeti yüksek küçük bir araç geliştiriyorsanız bu yapı baya mantıklı olabilir. Maliyet sıfıra yakın, veri sizde kalıyor, bağımlılıklar kontrol altında tutuluyor. Ama kurumsal ortamda tek başına yeterli sayılmaz; denetim kayıtları, versiyonlama, yetkilendirme ve hata toparlama mekanizmaları şart olur.
Bir dakika, şunu da ekleyeyim. Böyle ajanların geleceği bence saf sohbetten çok görev orkestrasyonunda yatıyor. Yani sadece cevap veren bot değil; dosya oluşturan, özet çıkaran, mini çalışma akışı yöneten yardımcı bir katman. Neyse uzatmayalım — o tartışma ayrı bir yazıyı hak ediyor.
Sıkça Sorulan Sorular;
Lokal sesli yapay zekâ ajanı nedir?
Lokal sesli yapay zekâ ajanı sesi cihaz üzerinde çözümler ve karar verme kısmını dış servis yerine yerel modellerle yapar. Böylece maliyet azalır ve veri dışarı gitmez. Ancak donanım ihtiyacı artabilir.
Böyle bir sistem internet olmadan çalışır mı?
Evet, temel bileşenler yereldeyse internet olmadan çalışabilir.Fakat modeli indirmek,güncelleme almak veya bazı yardımcı servisleri kullanmak için ara sıra bağlantı gerekebilir.
Neden Whisper yerine başka STT modelleri kullanılmıyor?
Theoretically kullanılabilir,ama Whisper’ın doğruluk dengesi birçok projede hâlâ güçlü duruyor.Yine de düşük kaynaklı cihazlarda alternatif modeller daha mantıklı olabilir.
Bölümlere ayırmak gerçekten gerekli mi?
Evet, özellikle debug sırasında ciddi fark yaratıyor.Tek dosyada başlayan projeler hızlı görünür ama büyüyünce bakım maliyeti patlayabiliyor.
Kaynaklar ve İleri Okuma;
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.
