Konu başlangıcı
Yapay zeka odaklı yazılım geliştirme süreçlerinde son iki yıldır sektör genelinde yerleşik hale gelen tehlikeli bir alışkanlık bulunuyor: Karşılaşılan her türlü mantıksal yol ayrımını, metin sınıflandırmasını ve yönlendirme ihtiyacını doğrudan devasa bir büyük dil modeline (LLM) havale etmek. Bir destek mesajının hangi departmana yönlendirileceği, bir kullanıcının sunduğu girdide finansal veya operasyonel risk bulunup bulunmadığı ya da bir arama sorgusunun gerçek bir satın alma niyeti taşıyıp taşımadığı gibi kararlar için milyarlarca parametreli modeller tetikleniyor.
Bu yaklaşım, modern yazılım mimarilerinde ciddi bir maliyet, gecikme (latency) ve öngörülemezlik krizine yol açıyor. Geliştiriciler tek bir sınıflandırma kararı alabilmek adına yüzlerce satırlık promptlar yazıyor; ardından modelden çıktı olarak geçerli bir JSON şeması üretmesini bekliyor; şema bozulduğunda yeniden deneme (retry) döngülerine giriyor ve milisaniyeler seviyesinde bitmesi gereken operasyonları saniyelere hapsediyor. Tam bu tıkanma noktasında TypeSafe AI tarafından geliştirilen JEV, yapay zeka ile yazılım mühendisliği arasındaki köprüyü yeniden tanımlayan özgün bir karar motoru mimarisi olarak sahneye çıkıyor. JEV, metin yazmak veya kullanıcıyla sohbet etmek için tasarlanmış bir LLM değil; yazılım sistemlerinin doğrudan tüketebileceği dar, tipli ve olasılık temelli kararlar üretmek üzere kurgulanmış özel bir karar motorudur.
Her Yapay Zeka Problemi Neden Bir LLM Gerektirmez?
Geleneksel yazılım geliştiriciler için deterministik mantık kutsaldır. Kod akışında bir şart bloğu çalıştırıldığında sonucun tip güvenliği (type safety), çalışma zamanı performansı ve doğruluk payı net olarak bilinir. Ancak üretken yapay zekanın popülerleşmesiyle birlikte mühendislik ekipleri, sadece beş farklı seçenek arasından tek bir tercih yapmak için bile uçtan uca şu hantal üretim hattını çalıştırmaya başladı:
Oysa operasyonel yazılımların büyük çoğunluğunda ihtiyaç duyulan çıktı; edebi bir paragraf değil, yalnızca "billing", "technical" veya "sales" gibi önceden tanımlanmış sabit bir kümeden ibarettir. Yazılım dünyasının "daha küçük veya daha ucuz bir ChatGPT" aramaktan ziyade, serbest metinleri doğrudan tipli kararlara dönüştüren mekanizmalara ihtiyacı vardır. JEV'in varlık sebebi tam olarak bu gereksiz token üretim hattını ortadan kaldırmaktır.
JEV Mimarisi ve "Sistem Bir Modeli" Kavramı
TypeSafe AI, JEV mimarisini psikolojideki refleksif ve hızlı karar mekanizmalarına atıfla bir "System One Model" (Sistem Bir Modeli) olarak tanımlıyor. Büyük dil modelleri karmaşık akıl yürütme ve planlama süreçlerini yöneten yavaş ve derin sistemler (System Two) iken, JEV milisaniyeler mertebesinde tepki veren, sezgisel ve anlık bir karar omurgasıdır.
Bu ayrım, üretim ortamında çalışan yazılımların kararlılığı açısından hayati bir güvencedir. Geleneksel sistemlerde geliştiriciler bir LLM'e "lütfen bana geçerli bir JSON dön, sakın şemanın dışına çıkma" şeklinde yalvaran promptlar yazmak zorunda kalırken, JEV'de bu durum doğrudan bir sistem sözleşmesine bağlanır. Model bir açıklama yapamaz, araya ek bir metin sıkıştıramaz veya şemaya rastgele alanlar ekleyemez; çünkü mimarinin görevi içerik üretmek değil, tanımlı alanda karar vermektir.
Temel Karar Primitifleri: Choice, Score ve Likelihood
JEV, yazılım sistemlerinin en sık ihtiyaç duyduğu karar modellerini üç ana primitif üzerinde toplar:
Bu üç modelden alınan yanıtlar doğrudan kod tabanının içine akar; geliştirici karmaşık metin çözümleme algoritmaları yazmak yerine standart yazılım değişkenleri gibi doğrudan bu verilerle iş mantığını kurgular.
Bir Mesajdan Üç Ayrı Karar Çıkarmak: Sıfır Paragraf Yaklaşımı
Konunun pratikteki işleyişini anlamak için tipik bir müşteri operasyonu senaryosunu ele alalım. Bir kullanıcının sisteme şu mesajı ilettiğini varsayalım: "Kartımdan iki kez para çekildi. Paramı geri istiyorum."
Geleneksel bir sohbet robotu yaklaşımında sistem bu mesaja doğrudan yanıt vermeye, kullanıcıyı teskin edici cümleler kurmaya ve durumu geçiştirmeye odaklanır. Fakat operasyonel bir sistemin arka planında asıl yanıtlanması gereken kritik sorular bambaşkadır:
1. Bu bildirim hangi teknik veya idari ekibe düşmeli?
2. Kullanıcının tam olarak eylemsel talebi nedir?
3. Kullanıcının öfke ve hayal kırıklığı seviyesi ne boyuttadır?
JEV yaklaşımı, bu sorular için modeli uzun bir metin muhakemesine sokmak yerine aynı anda üç bağımsız karar üretir: Mesajın rotasını %98.3 güven skoruyla "billing" olarak belirler; eylemi "refund" olarak tanımlar ve hayal kırıklığı değerini "high" seviyesinde puanlar.
Bu işlem sonucunda tek bir paragraf bile metin üretilmez; ancak elde edilen tipli sonuçlar sayesinde kod blokları derhal harekete geçer. Finans ekibine bildirim düşer, iade kuyruğuna öncelik atanır ve kullanıcının yüksek stres seviyesinden ötürü dosya doğrudan insan temsilcinin ekranına acil koduyla aktarılır. Üstelik log kayıtlarında "modelin serbestçe ne düşündüğü" yerine, hangi kararın hangi matematiksel olasılıkla verildiği şeffaf şekilde izlenebilir ve test edilebilir.
Olasılık, Kararsızlık Değil Kontrol Yüzeyidir
Yapay zeka sistemlerinin üretim ortamındaki en zayıf karnı, verdikleri yanıtlardan ne kadar emin olduklarını yazılıma aktaramamalarıdır. Geleneksel bir dil modeli halüsinasyon gördüğünde bile bunu son derece kendinden emin bir tonda ifade eder. JEV mimarisinde ise olasılık değeri bir zafiyet değil, tam tersine geliştiricinin elindeki en güçlü kontrol yüzeyidir.
Model yalnızca "Bu mesaj billing kategorisine aittir" demez; bu kararı %62 olasılıkla mı yoksa %98 olasılıkla mı aldığını açıkça sisteme bildirir. Olasılık dağılımının bilinmesi, sistemin üç farklı çalışma katmanı üzerinden yönetilmesini sağlar:
Buradaki en kritik nokta, güvenlik eşiklerinin sabit bir kural olmaması, doğrudan işletmenin risk politikalarına göre esnemesidir. Bir müzik öneri algoritmasında %70'lik bir güven skoru kullanıcı deneyimi açısından gayet yeterli görülebilirken, geri ödeme veya hesap kapatma gibi finansal operasyonlarda %95 güven düzeyi bile tek başına yeterli kabul edilmeyebilir. Bu mimari sayesinde yazılım mimarı, modelin ne kadar risk alabileceğini doğrudan kod katmanında sınırlar.
Dört Görev, Dört Farklı Sorumluluk: Semantik Switch-Case
Günümüzde başarısız olan birçok yapay zeka entegrasyonu, sistemin tüm katmanlarını tek bir modele yükleme yanılgısından kaynaklanır. Bir yazılım mimarisinde doğru görev dağılımı dört temel bileşen üzerinden kurgulanmalıdır:
JEV'in buradaki işlevi, yazılım dünyasındaki geleneksel switch-case bloklarının semantik bir versiyonu gibi çalışmasıdır. Klasik şart blokları sadece sabit string veya enum değerlerini kontrol edebilirken, JEV doğal dilin değişken ve karmaşık yapısını çözümleyerek elde ettiği olasılıkları yapısal koşul bloklarına dönüştürür.
Ajan Tabanlı Mimarilerde JEV'in Üçlü Rolü: Router, Gate, Judge
Otonom ajan (AI Agent) sistemlerinde karşılaşılan en büyük problem, ajanların sonsuz akıl yürütme döngülerine girmesi, yanlış araçları (tools) tetiklemesi veya üretilen çıktının kalitesini denetleyememesidir. JEV, bir ajanın beyninin tamamını üstlenmek yerine, kritik kavşak noktalarındaki denetim organı olarak konumlanır:
Örneğin bir kodlama ajanı döngüsünde JEV; önce görevin bir refactor mu yoksa hata düzeltme mi olduğunu (Router) belirler, kod tabanında değişiklik yapılmadan önce güvenlik kurallarını (Gate) inceler ve son olarak üretilen kodun testleri geçip geçmediğini (Judge) denetleyerek sürecin deterministik kalmasını sağlar.
Yapay Zeka Mühendisliğinde Yeni Dönem
Üretken yapay zekanın ilk heyecan dalgası geride kalırken, mühendislik dünyası her problemin dev LLM'lerle çözülemeyeceğini net biçimde anlamış durumda. Milyonlarca parametreli modelleri anlamsız sınıflandırma işlerinde boşa harcamak; bütçelerin erimesine, gecikmelerin kabul edilemez seviyelere çıkmasına ve sistem kararlılığının çökmesine neden oluyor.
JEV ve temsil ettiği System One mimarisi, yapay zekayı bir sohbet arayüzü olmaktan çıkarıp yazılım mühendisliğinin güvenilir, tipli ve ölçülebilir bir yapıtaşı haline getiriyor. Önümüzdeki dönemde kazanan sistemler; her iş için tek bir monolitik LLM çalıştıranlar değil, deterministik kod ile yapay zeka kararlarını JEV benzeri hafif, uzmanlaşmış ve olasılık temelli karar motorlarıyla orkestre edebilen hibrit mimariler olacaktır.
Bu yaklaşım, modern yazılım mimarilerinde ciddi bir maliyet, gecikme (latency) ve öngörülemezlik krizine yol açıyor. Geliştiriciler tek bir sınıflandırma kararı alabilmek adına yüzlerce satırlık promptlar yazıyor; ardından modelden çıktı olarak geçerli bir JSON şeması üretmesini bekliyor; şema bozulduğunda yeniden deneme (retry) döngülerine giriyor ve milisaniyeler seviyesinde bitmesi gereken operasyonları saniyelere hapsediyor. Tam bu tıkanma noktasında TypeSafe AI tarafından geliştirilen JEV, yapay zeka ile yazılım mühendisliği arasındaki köprüyü yeniden tanımlayan özgün bir karar motoru mimarisi olarak sahneye çıkıyor. JEV, metin yazmak veya kullanıcıyla sohbet etmek için tasarlanmış bir LLM değil; yazılım sistemlerinin doğrudan tüketebileceği dar, tipli ve olasılık temelli kararlar üretmek üzere kurgulanmış özel bir karar motorudur.
Her Yapay Zeka Problemi Neden Bir LLM Gerektirmez?
Geleneksel yazılım geliştiriciler için deterministik mantık kutsaldır. Kod akışında bir şart bloğu çalıştırıldığında sonucun tip güvenliği (type safety), çalışma zamanı performansı ve doğruluk payı net olarak bilinir. Ancak üretken yapay zekanın popülerleşmesiyle birlikte mühendislik ekipleri, sadece beş farklı seçenek arasından tek bir tercih yapmak için bile uçtan uca şu hantal üretim hattını çalıştırmaya başladı:
- Prompt Tasarımı: Sisteme bağlamı, sistem kurallarını ve dönülmesi gereken JSON yapısını anlatan onlarca satırlık metin girişi hazırlanır.
- LLM Çıkarımı: Model, tek bir kelimelik karar için yüzlerce tokenlık hesaplama ve metin üretim süreci yürütür.
- JSON Parse Etme: Üretilen serbest metin içinden programlama dilinin anlayabileceği yapısal veri ayıklanmaya çalışılır.
- Şema Doğrulama (Validation): Modelin istenen tipte veri dönüp dönmediği kontrol edilir.
- Hata Yakalama ve Yeniden Deneme (Retry): Model formatı bozduğunda, geçersiz bir alan ürettiğinde veya halüsinasyon gördüğünde tüm bu zincir baştan işletilir.
Oysa operasyonel yazılımların büyük çoğunluğunda ihtiyaç duyulan çıktı; edebi bir paragraf değil, yalnızca "billing", "technical" veya "sales" gibi önceden tanımlanmış sabit bir kümeden ibarettir. Yazılım dünyasının "daha küçük veya daha ucuz bir ChatGPT" aramaktan ziyade, serbest metinleri doğrudan tipli kararlara dönüştüren mekanizmalara ihtiyacı vardır. JEV'in varlık sebebi tam olarak bu gereksiz token üretim hattını ortadan kaldırmaktır.
JEV Mimarisi ve "Sistem Bir Modeli" Kavramı
TypeSafe AI, JEV mimarisini psikolojideki refleksif ve hızlı karar mekanizmalarına atıfla bir "System One Model" (Sistem Bir Modeli) olarak tanımlıyor. Büyük dil modelleri karmaşık akıl yürütme ve planlama süreçlerini yöneten yavaş ve derin sistemler (System Two) iken, JEV milisaniyeler mertebesinde tepki veren, sezgisel ve anlık bir karar omurgasıdır.
Alıntı
Girdi ve Çıktı Arasındaki Tip Güvenliği Sözleşmesi
JEV mimarisinde sisteme verilen girdi serbest metin ve uygulamanın durum parametreleridir. Ancak sistemin ürettiği çıktı asla serbest metin değildir. Çıktı tarafında geliştiricinin önceden tanımladığı tiplerin dışına çıkamayan, doğrulanmış ve güven bilgisi (confidence score) taşıyan net kararlar yer alır.
Bu ayrım, üretim ortamında çalışan yazılımların kararlılığı açısından hayati bir güvencedir. Geleneksel sistemlerde geliştiriciler bir LLM'e "lütfen bana geçerli bir JSON dön, sakın şemanın dışına çıkma" şeklinde yalvaran promptlar yazmak zorunda kalırken, JEV'de bu durum doğrudan bir sistem sözleşmesine bağlanır. Model bir açıklama yapamaz, araya ek bir metin sıkıştıramaz veya şemaya rastgele alanlar ekleyemez; çünkü mimarinin görevi içerik üretmek değil, tanımlı alanda karar vermektir.
Temel Karar Primitifleri: Choice, Score ve Likelihood
JEV, yazılım sistemlerinin en sık ihtiyaç duyduğu karar modellerini üç ana primitif üzerinde toplar:
- Choice (Seçim): Önceden belirlenmiş sonlu bir seçenek havuzundan (enum) girdi metnine en uygun olanını seçer ve her bir seçeneğin olasılık skorunu hesaplar. Örneğin gelen mesajın finans mı, teknik destek mi yoksa satış mı olduğu bu yapıyla belirlenir.
- Score (Skor): Girdi metnini veya kullanıcının durumunu belirli bir ölçek (örneğin 0 ile 100 arası) üzerinde derecelendirir. Kullanıcı hayal kırıklığı seviyesi, dolandırıcılık riski veya arama alaka düzeyi bu primitif ile sayısallaştırılır.
- Likelihood (Evet / Hayır Olasılığı): İkili (boolean) bir durumun gerçekleşme ihtimalini olasılıksal olarak hesaplar. Bir işlemin riskli olup olmadığı veya geri arama gerektirip gerektirmediği bu model üzerinden yürütülür.
Bu üç modelden alınan yanıtlar doğrudan kod tabanının içine akar; geliştirici karmaşık metin çözümleme algoritmaları yazmak yerine standart yazılım değişkenleri gibi doğrudan bu verilerle iş mantığını kurgular.
Bir Mesajdan Üç Ayrı Karar Çıkarmak: Sıfır Paragraf Yaklaşımı
Konunun pratikteki işleyişini anlamak için tipik bir müşteri operasyonu senaryosunu ele alalım. Bir kullanıcının sisteme şu mesajı ilettiğini varsayalım: "Kartımdan iki kez para çekildi. Paramı geri istiyorum."
Geleneksel bir sohbet robotu yaklaşımında sistem bu mesaja doğrudan yanıt vermeye, kullanıcıyı teskin edici cümleler kurmaya ve durumu geçiştirmeye odaklanır. Fakat operasyonel bir sistemin arka planında asıl yanıtlanması gereken kritik sorular bambaşkadır:
1. Bu bildirim hangi teknik veya idari ekibe düşmeli?
2. Kullanıcının tam olarak eylemsel talebi nedir?
3. Kullanıcının öfke ve hayal kırıklığı seviyesi ne boyuttadır?
JEV yaklaşımı, bu sorular için modeli uzun bir metin muhakemesine sokmak yerine aynı anda üç bağımsız karar üretir: Mesajın rotasını %98.3 güven skoruyla "billing" olarak belirler; eylemi "refund" olarak tanımlar ve hayal kırıklığı değerini "high" seviyesinde puanlar.
Bu işlem sonucunda tek bir paragraf bile metin üretilmez; ancak elde edilen tipli sonuçlar sayesinde kod blokları derhal harekete geçer. Finans ekibine bildirim düşer, iade kuyruğuna öncelik atanır ve kullanıcının yüksek stres seviyesinden ötürü dosya doğrudan insan temsilcinin ekranına acil koduyla aktarılır. Üstelik log kayıtlarında "modelin serbestçe ne düşündüğü" yerine, hangi kararın hangi matematiksel olasılıkla verildiği şeffaf şekilde izlenebilir ve test edilebilir.
Olasılık, Kararsızlık Değil Kontrol Yüzeyidir
Yapay zeka sistemlerinin üretim ortamındaki en zayıf karnı, verdikleri yanıtlardan ne kadar emin olduklarını yazılıma aktaramamalarıdır. Geleneksel bir dil modeli halüsinasyon gördüğünde bile bunu son derece kendinden emin bir tonda ifade eder. JEV mimarisinde ise olasılık değeri bir zafiyet değil, tam tersine geliştiricinin elindeki en güçlü kontrol yüzeyidir.
Model yalnızca "Bu mesaj billing kategorisine aittir" demez; bu kararı %62 olasılıkla mı yoksa %98 olasılıkla mı aldığını açıkça sisteme bildirir. Olasılık dağılımının bilinmesi, sistemin üç farklı çalışma katmanı üzerinden yönetilmesini sağlar:
- Yüksek Güven Eşiği: Kararın olasılığı belirlenen güvenlik sınırının üzerindeyse (örneğin %95+), işlem hiçbir insan müdahalesi veya ek LLM maliyeti olmadan doğrudan otomatik olarak icra edilir.
- Orta Seviye Güven: Modelin emin olamadığı durumlarda karar zinciri kesilmez; bağlam daha derin ve kapsamlı bir büyük dil modeline sorularak ikinci bir kontrol mekanizması devreye alınır.
- Düşük Güven Eşiği: Riskli veya sınırda kalan kararlar doğrudan insan denetimine aktarılır.
Buradaki en kritik nokta, güvenlik eşiklerinin sabit bir kural olmaması, doğrudan işletmenin risk politikalarına göre esnemesidir. Bir müzik öneri algoritmasında %70'lik bir güven skoru kullanıcı deneyimi açısından gayet yeterli görülebilirken, geri ödeme veya hesap kapatma gibi finansal operasyonlarda %95 güven düzeyi bile tek başına yeterli kabul edilmeyebilir. Bu mimari sayesinde yazılım mimarı, modelin ne kadar risk alabileceğini doğrudan kod katmanında sınırlar.
Dört Görev, Dört Farklı Sorumluluk: Semantik Switch-Case
Günümüzde başarısız olan birçok yapay zeka entegrasyonu, sistemin tüm katmanlarını tek bir modele yükleme yanılgısından kaynaklanır. Bir yazılım mimarisinde doğru görev dağılımı dört temel bileşen üzerinden kurgulanmalıdır:
- Normal Kod: Kesin hesaplamalar, string karşılaştırmaları, matematiksel işlemler ve limit kontrolleri kesinlikle yapay zekaya bırakılmamalı; geleneksel deterministik kod yapısıyla yürütülmelidir.
- JEV (Karar Motoru): Anlamsal sınıflandırmalar, yönlendirmeler ve olasılık temelli kontroller JEV üzerinden hızlı ve tipli şekilde çalıştırılmalıdır.
- Güçlü LLM: Yalnızca gerçekten serbest metin, uzun analiz, kod sentezi veya yaratıcı açıklama üretilmesi gereken durumlarda devreye girmelidir.
- İnsan Denetimi: Yüksek riskli, geri döndürülemez ve sistemin emin olamadığı kritik kararlarda nihai onaylayıcı olarak devrede kalmalıdır.
JEV'in buradaki işlevi, yazılım dünyasındaki geleneksel switch-case bloklarının semantik bir versiyonu gibi çalışmasıdır. Klasik şart blokları sadece sabit string veya enum değerlerini kontrol edebilirken, JEV doğal dilin değişken ve karmaşık yapısını çözümleyerek elde ettiği olasılıkları yapısal koşul bloklarına dönüştürür.
Ajan Tabanlı Mimarilerde JEV'in Üçlü Rolü: Router, Gate, Judge
Otonom ajan (AI Agent) sistemlerinde karşılaşılan en büyük problem, ajanların sonsuz akıl yürütme döngülerine girmesi, yanlış araçları (tools) tetiklemesi veya üretilen çıktının kalitesini denetleyememesidir. JEV, bir ajanın beyninin tamamını üstlenmek yerine, kritik kavşak noktalarındaki denetim organı olarak konumlanır:
- Router (Yönlendirici): Bir kullanıcı girdisi geldiğinde bu görevin hangi uzman modele, alt ajana ya da API aracına aktarılması gerektiğini anlık olarak tayin eder.
- Gate (Kapı): Ajanın bir sonraki adıma geçip geçemeyeceğini, elindeki planın güvenli olup olmadığını ve dış dünyaya etki eden araçları tetikleme iznini kontrol eder.
- Judge (Yargıç): Üretilen nihai yanıtın belirlenen kalite standartlarına, kurumsal politikalara ve gerçek dünya verilerine uygunluğunu denetler.
Örneğin bir kodlama ajanı döngüsünde JEV; önce görevin bir refactor mu yoksa hata düzeltme mi olduğunu (Router) belirler, kod tabanında değişiklik yapılmadan önce güvenlik kurallarını (Gate) inceler ve son olarak üretilen kodun testleri geçip geçmediğini (Judge) denetleyerek sürecin deterministik kalmasını sağlar.
Yapay Zeka Mühendisliğinde Yeni Dönem
Üretken yapay zekanın ilk heyecan dalgası geride kalırken, mühendislik dünyası her problemin dev LLM'lerle çözülemeyeceğini net biçimde anlamış durumda. Milyonlarca parametreli modelleri anlamsız sınıflandırma işlerinde boşa harcamak; bütçelerin erimesine, gecikmelerin kabul edilemez seviyelere çıkmasına ve sistem kararlılığının çökmesine neden oluyor.
JEV ve temsil ettiği System One mimarisi, yapay zekayı bir sohbet arayüzü olmaktan çıkarıp yazılım mühendisliğinin güvenilir, tipli ve ölçülebilir bir yapıtaşı haline getiriyor. Önümüzdeki dönemde kazanan sistemler; her iş için tek bir monolitik LLM çalıştıranlar değil, deterministik kod ile yapay zeka kararlarını JEV benzeri hafif, uzmanlaşmış ve olasılık temelli karar motorlarıyla orkestre edebilen hibrit mimariler olacaktır.
20 Eylül 2026, 10:39 tarihinde düzenlendi