Geçen ay, İstanbul’da yağmurlu bir akşamüstü, editör masasında bir demo izlerken aklıma şu soru takıldı: “Neden hâlâ bu kadar çok AI aracı buluta mahkûm?” İşin aslı şu ki sesle komut verip bilgisayarında anında iş yaptırmak kulağa biraz gösterişli geliyor — ama arkasında bayağı sağlam bir mimari gerekiyor, gösterişten öte (inanın bana). Aaditya Kapruwan’ın Voice Agent Project çalışması tam bu noktada ilgimi çekti; çünkü gösterişli tarafı değil, yerel çalışma fikrini öne çıkarıyor.
Ben de 2023 sonlarında Ankara’daki küçük bir içerik ekibinde benzer bir akış kurmaya çalışmıştım (bu beni çok şaşırttı). Mikrofonla konuşup dosya düzenleyen, not özetleyen bir sistem istiyorduk. Her şey buluta gidince hem gecikme arttı hem de ekipte güven soruları başladı — kim neye erişiyor, veri nereye gidiyor, bilmiyoruz. O yüzden bu proje bana “gösteri” gibi değil, daha çok gerçek hayatta işe yarayan bir mühendislik denemesi gibi geldi. Hani bazen en iyi fikir en parlak olan değil, en az sorun çıkaran olur ya… aynen öyle.
Durun, bir saniye.
Neden Yerel-Öncelikli Bir Ses Ajanı?
Çıkış noktası net. Kullanıcı verisi makinede kalsın, cevap süresi düşük olsun, klavye başına mahkûm olmadan iş yapılabilsin. Açık konuşayım, bugün pek çok yapay zekâ aracı “bulut var, sorun yok” mantığıyla kuruluyor. Fena değil. Her senaryoda yetmiyor — özellikle gizlilik hassasiyeti olan ekiplerde ya da internetin naz yaptığı ortamlarda yerel çözüm, buluta kıyasla şaşırtıcı derecede avantajlı bir konuma geliyor.
Bu yaklaşımı ilk kez geçen yıl İzmir’de çalışan bir ürün ekibinde test etmiştim. Dosya isimlerini değiştiren basit bir sesli komut sistemi bile uzaktaki API’ye bağlanınca insanın içi rahat etmiyor. Hele konu kurumsal dokümanlar olunca işler karışıyor. Yerelde çalışan model biraz eski usul atölye hissi veriyor: elinin altında, kontrol sende.
Ve işler burada ilginçleşiyor.
Gel gelelim yerelin de bedeli var (buna dikkat edin). Model kalitesi, donanım sınırı, entegrasyon karmaşası — hepsi hemen kapıda bekliyor. Yani “yerel = kolay” diye düşünmek hayal kırıklığı yaratabilir. Bu projede hoşuma giden taraf da buydu aslında: teknik olarak zorlayıcı ama mantıklı kararlarla sade tutulmuş.
Dört Katmanlı Mimari Neyi Çözmüş?
Bakın, Aaditya’nın sistemi dört katmana ayırması bence projenin omurgası olmuş. Frontend ayrı, STT servisi ayrı, yapay zekâ katmanı ayrı, eylem katmanı ayrı. Kağıt üstünde bakınca sıradan görünebilir; pratikte ise bu ayrım işleri ciddi biçimde toparlıyor. Ben böyle yapılarda genelde ilk günlerde “tek servis yeter” diyen tarafta olurum… sonra loglar birbirine girince pişmanlık gelir. Hep öyle olur.
Streamlit tarafı mikrofon girişi ve sonuçların gösterilmesini üstleniyor. FastAPI + Faster-Whisper sesi yazıya çeviriyor — yani kulaktan beyne giden ilk çeviri masası burada kurulmuş desek yanlış olmaz. Ollama katmanı niyeti çözüyor ve gerektiğinde kod üretimi ya da aksiyon seçimi yapıyor. En altta da kontrollü Python fonksiyonlarıyla dosya işlemleri yürütülüyor.
Yerel AI projelerinde asıl mesele modelden çok mimaridir; sınırlar net çizilmezse en iyi model bile saçmalar.
Mimariyi tabloyla sadeleştirelim
| Katman | Görev | Neden önemli? |
|---|---|---|
| Frontend (Streamlit) | Mikrofon kaydı ve çıktı gösterimi | Kullanıcı deneyimini basit tutuyor |
| STT Servisi (FastAPI + Whisper) | Sesi metne çeviriyor | Düşük gecikme ve ayrıştırılmış sorumluluk sağlıyor |
| AI Katmanı (Ollama) | Niyet algılama ve görev seçimi | Lokal model kontrolü veriyor |
| Eylem Katmanı (Python) | Dizin/dosya işlemleri | Sınırlı ve güvenli aksiyon alanı sunuyor |
Kod Akışı Neye Benziyor?
Sistemin akışı aslında oldukça temiz. Ses geliyor, Whisper onu yazıya çeviriyor, Ollama niyeti çözüyor, ardından güvenli eylem tetikleniyor. Hepsi bu kadar değil tabii — ama iskelet böyle kurulmuş. Bana göre burada asıl güzel olan şey sadece sadelik değil; hata ayıklamanın da bir o kadar kolaylaşması.
# Basitleştirilmiş akış
voice_input -> whisper_stt -> text
text -> ollama_intent -> action_type
action_type -> python_sandbox -> file_output
İlginç olan şu ki, Bunu kendi kafamda şöyle canlandırıyorum. Sanki mutfakta üç ayrı kişi çalışıyor — biri malzemeyi doğrayıp getiriyor (STT), biri ne pişeceğine karar veriyor (AI), biri de o yemeği gerçekten hazırlıyor (action layer). Hepsini tek kişiye yüklerseniz mutfak kaosa döner (ki bu çoğu kişinin gözünden kaçıyor). Aynen yazılımda da öyle.
Bir de şu var: JSON ile konuşmaları standartlaştırmak küçük bir startup için rahatlatıcı olabilir ama enterprise ortamda tek başına yetmez. Orada versiyonlama, şema doğrulama ve gözlemleme gerekiyor — bunlar olmadan bir şeyler er ya da geç kırılıyor. Ben 2024 baharında Berlin’deki bir danışmanlık işinde benzer yapıyı gördüm; şema kontrolü yoktu (yanlış duymadınız). Küçücük bir değişiklik neredeyse tüm zinciri kırmıştı. Pek hoş değildi.
Sorunlar Nerede Patlamış?
Bir şey dikkatimi çekti: Beni en çok güldüren. Aynı zamanda en çok (belki yanılıyorum ama) düşündüren nokta Streamlit’in yeniden çalıştırma davranışı oldu. Kayıt durdurulunca arayüzün takılıyor gibi hissettirmesi klasik Streamlit sürprizlerinden biri zaten. Aaditya bunu session state ve hash karşılaştırmasıyla çözmüş.
Çok konuştum, örnekle göstereyim. Python Performans Darboğazı: Tahmin Etme, Ölç yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Açıkçası bu tür detaylar dışarıdan bakınca önemsiz görünür. Ama kullanıcı deneyiminin yarısı tam da burada yatıyor. Eğer mikrofon düğmesine basınca ekran donar gibi oluyorsa kimse o sistemi ikinci kez kullanmaz — dürüst olayım, ben de kullanmam.
Kayıt tekrarını engelleyen mantık neden işe yarıyor?
Aynı ses parçasının yeniden işlenmesini engellemek için digest kontrolü yapılmış olması fena değil, hatta baya iş görüyor. Ses değişmediyse işlem tekrarlanmıyor. UI boş yere yük binmiyor. Kullanıcı sanki sistem “hatırlıyormuş” hissi alıyor. Basit ama etkili.
if mic_audio is not None:
recorded = mic_audio.getvalue()
if recorded:
recorded_digest = hashlib.sha1(recorded).hexdigest()
if recorded_digest != st.session_state.mic_audio_digest:
st.session_state.mic_audio_bytes = recorded
st.session_state.mic_audio_ready = True
st.session_state.mic_audio_digest = recorded_digest
E tabi sadece UI tarafı değil. Servis dayanıklılığı da önemli olmuş (yanlış duymadınız). Docker içindeki bileşenlerden biri düşerse arayüzün kilitlenmemesi için sağlık kontrolleri eklenmiş. Bu yaklaşımı seviyorum — sessizce bozulan sistemler en sinir bozucu olanlar oluyor, cidden. AI Ajanı Öğretince Ne Oluyor?: #3’lük Sürpriz Hikâye yazımızda bu konuya da değinmiştik.
Kime Uyar, Kime Uymaz?
Küçük bir startup için bu yapı gayet anlamlı olabilir. Hızlı prototipleme ile veri gizliliğini aynı potada eritmeye çalışıyor çünkü. Ekip iki üç geliştiriciden oluşuyorsa Streamlit + FastAPI + Ollama kombinasyonu idare eder seviyede kalabiliyor; doğru sınırlar konursa maliyet bile şaşırtıcı biçimde düşük kalıyor.
Enterprise tarafta ise işler sertleşiyor (evet, doğru duydunuz). Kim hangi komutu verdi, hangi dosya işlendi, hangi model ne üretti — bunların hepsi kayıt altına alınmalı. Ben kurumsal projelerde hep şunu gördüm: küçük demo aşamasında esnek olan tasarım, prod’a geçince kan terletmeye başlıyor. İstisnasız. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
- Küçük ekipler için artısı: hızlı kurulum ve düşük altyapı bağımlılığıdır. — ciddi fark yaratıyor
- Küçük ekipler için eksisi: bakım yükü tek kişide toplanabilir.
- Büyük kurumlar için artısı: veri kontrolü ve sandbox yaklaşımıdır.
- Büyük kurumlar için eksisi: uyum süreçleri yüzünden entegrasyon uzar. — ciddi fark yaratıyor
Neyse uzatmayalım. Benim açımdan buradaki kritik nokta şu: bu proje “AI ajan” lafını havalı olduğu için kullanmıyor, gerçekten eyleme dönüştürüyor. Ve tam da bu yüzden değerli. Bu konuyla ilgili Next.js ve PostgreSQL ile Ölçeklenen SaaS Kurmak yazımıza da göz atmanızı tavsiye ederim.
Tatmin Eden Tarafları ve Eksik Kalan Noktalar
Bana kalırsa projenin en güçlü yani reliability odağı. Çünkü çoğu kişi model seçimine gömülüyor —. Sistem çalışmadığında modelin kaç parametre olduğu kimsenin umurunda olmuyor. Strict API sözleşmeleri, defansif programlama, güvenli çalışma sınırları… bunlar görünmeyen kahramanlar.
Daha açık söyleyeyim, i̇lginç olan şu ki, Bununla birlikte bazı şeyler hâlâ ham duruyor. Intent detection kısmının gerçek dünyada ne kadar isabetli olduğu merak konusu mesela. Laboratuvarda iyi görünen şey karmaşık konuşmalarda tökezleyebiliyor — bir arkadaşım geçen hafta Kadıköy’de buna benzer bir agent test etti, “dosyayı taşı” dediğinde yanlış klasöre not bırakmıştı! Böyle ufak kazalar demo sırasında sevimli görünür ama üretimde can sıkıcı olur.
Daha ileriye gitmek isteyenlere kısa notlar
Eğer bunu büyütmek istiyorsanız birkaç yerde ekstra emniyet koymak şart: komut beyaz listesi, işlem onayı, log zenginleştirme ve rol bazlı izinler (ben de ilk duyduğumda şaşırmıştım). Bir de modeli sürekli genişletmeden önce aksiyon setini dar tutmak iyi fikir (buna dikkat edin). Aksi halde ajan biraz fazla özgürleşiyor… Neden önemli bu? sonra kim ne yaptı takip etmek zorlaşıyor.
Peki Bundan Ne Çıkarmalıyız?
Şunu söyleyeyim, Bence Voice Agent Project bize şunu hatırlatıyor: iyi AI ürünü sadece zeki olmak zorunda değil, aynı zamanda sakin olmalı. Veri kaçırmayacak, donmayacak, yanlış dosyaya dokunmayacak. Kulağa sıkıcı geliyor olabilir — ama gerçek kullanım tam olarak bu.
Peki, bir şey dikkatimi çekti: Editör masasında haberi okurken ilk düşündüğüm şey şuydu: geleceğin üretken araçları belki daha fazla konuşacak, ama daha az bağıracak (evet, doğru duydunuz). Kullanıcının eli klavyeye gitmeden işi halleden sistemlerin kazanacağına inanıyorum. Tabii bunun yolu bolca testten, net sınırdan ve biraz da mühendislik disiplininden geçiyor. Aynen böyle.
Sıkça Sorulan Sorular
Lokal-first voice agent nedir?
Küçük bir detay: Lokal-first voice agent, ses komutlarını buluta göndermeden kendi cihazınızda işleyen asistandır.Böylelikle gizlilik artar,gecikme azalır bağlantıya daha az bağımlılık olur.
Streamlit bu tür projeler için uygun mu?
Evet, özellikle prototip aşamasında gayet uygun.Ama uygulama büyüdükçe yeniden çalışma davranışı dikkat ister; oturum yönetimini düzgün kurmazsanız arayüz garipleşebilir.
Whisper yerine başka STT motoru kullanılabilir mi?
Size bir şey söyleyeyim, Kullanılabilir, tabii.Ama Faster-Whisper gibi hafif çözümler yerelde iyi performans verdiği için tercih ediliyor.Donanımınıza göre alternatifleri test etmek lazım. (kendi tecrübem)
Bu yapı production ortamına taşınabilir mi?
Evet,. Ek güvenlik katmanları gerekir.Komut doğrulama, audit log, rate limit hata izolasyonu olmadan production’a çıkmak risklidir.İyi haber şu ki mimari buna müsait görünüyor.
Kaynaklar Ve İleri Okuma
- Faster-Whisper GitHub Sayfası
- Ollama Resmi Sitesi
- Streamlit Dokümantasyonu
- FastAPI Resmi Dokümantasyonu
- Orijinal Yazı Kaynağı (bu kritik)
- LangChain Ajanlarını Üretimde İzlemek: Gerçek Zamanlı Rehber (bu kritik)
- Yapay Zekâ Ajanı Ne Yaptı?: Kanıtlayabiliyor musun? (bence en önemlisi)
- MCP mi, CLI mı? Tarayıcı Otomasyonunda Kazanan Netleşti:
]
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.
