Hangi kitaba ya da yazıya baksanız
3. madde hakkında hep böyle yazar
ama gerçekte
Bunu neden soruyor
Bunu neden ancak şimdi gündeme getiriyor
Bunu da mı soruyor
Üçlü kombo ve düşük kaliteli bir partner olarak algılanma ihtimali
adlı bir Computer-use Agent geliştiriyorum ve büyük ölçüde katılıyorum.
Bu yazı pratik ipuçlarından ziyade genel bir overview ele alıyor; ben de LLM tabanlı agentic/agent geliştirirken birkaç ipucu daha eklemek isterim: Sonuçta LLM transformer tabanlıdır (yani probabilistic based akıl yürütme; mevcut token/state’e dayanarak bir sonraki token’ı bağlamı/semantiği gerçekten anlayıp üretmekten ziyade olasılıksal olarak output verir). Bu yüzden sys prompt ne kadar iyi yazılırsa yazılsın, çoğu zaman istenen yanıtı vermediği durumlar olur (örneğin JSON output istenir ama bazen } karakterini unutabilir). Bu nedenle regex tabanlı birden fazla fallback fn eklemek her zaman şarttır.
Ayrıca structured output veren bir sys prompt yazıyorsanız genelde non-reasoning model kullanırsınız; context uzadıkça hallucination daha sık ortaya çıktığı için, tek bir uzun sys prompt yerine birkaç sys prompt hazırlayıp chaining yapmak daha iyidir.
Bir servis geliştirirken çeşitli hatalar oluşabileceğinden, servis mimarisini modüler ve fault tolerant şekilde tasarlamak kritik önemdedir (örneğin supervisor agent’ı async, diğer agent’ları sync yapmak). Özellikle unexpected output’un sık görüldüğü agentic ve agent sistemlerinde bu daha da önemlidir.
Bu yüzden en baştan kod yazarken mümkün olduğunca SRP’ye uymak ve declarative bir yaklaşım benimsemek iyi olur; yani fonksiyonel bir yaklaşımın daha iyi olduğunu söylemek isterim (= side effect yoktur ve flow sezgiseldir).
Ayrıca LLM’i API üzerinden mi kullanacağınız yoksa modeli doğrudan kendiniz mi serve edeceğiniz duruma göre değişir; ancak SLM ya da LLM’i doğrudan serve edecekseniz backend’i host ettiğiniz sunucuda model serving yapmayın. IO bound task’lerle CPU bound task’leri (yani GPU gerektiren, mat mult gibi işlemler isteyen task’ler) ayrı sunuculara koymak fault tolerance açısından daha iyidir (örneğin CPU bound task’leri Runpod’da host etmek).
Bunun dışında daha birçok geliştirme ipucu var ama çok uzamasın diye burada bırakayım.
Korece çeviriye berbat otomatik çeviriyi pis pis dolduruyorlardı, demek ki daha da evrilmiş. Otomatik çeviriyi bile engelleyemedik; şimdi bir de berbat AI’ı pis pis dayatmalarının tadına bakalım hep birlikte!
Yapay zeka özelliklerinden, özellikle arka planda bekleyip yardım edeceğini söyleyen hizmetlerden gerçekten nefret ediyorum.
Uzaktan çalıştırılıyorsa bilgilerimin paylaşılması sorunu var, yerelde çalıştırılıyorsa da bilgisayarımın kaynaklarını (CPU, bellek, pil, ...) tüketmesi sorunu var çünkü.
Aynen öyle olmuş lol
Bu, araba ile maratonu karşılaştırmak gibi geliyor..
hahaha "Öyle bir özellik var olsun"
Size tamamen katılıyorum!
hahaha
Halüsinasyon güdümlü geliştirme... desek mi acaba;;
> Liderlik yapsa tam uygun olurdu ama bu tür ek rolleri reddetti.
> Yazar büyüme için yeni bir meydan okuma önerdiğinde ...
Bir teknisyenin açısından bakınca, iyi yaptığın işi daha da iyi yapmak da bir büyüme değil mi?
Güzel sözleriniz için çok teşekkür ederim!!
Belki de daha fazla sorumluluk ve işe rağmen artmayan maaş düzeyini ve çalışma koşullarını düşünmüştür diye geliyor bana.
Bu oldukça olasıdır
Elbette, iyi bir lider nazikçe dinler ve
sorunu doğru şekilde çözecektir
Hangi kitaba ya da yazıya baksanız
3. madde hakkında hep böyle yazar
ama gerçekte
Bunu neden soruyor
Bunu neden ancak şimdi gündeme getiriyor
Bunu da mı soruyor
Üçlü kombo ve düşük kaliteli bir partner olarak algılanma ihtimali
Ben de şu anda UseDesktop
https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq
usedesktop.com
adlı bir Computer-use Agent geliştiriyorum ve büyük ölçüde katılıyorum.
Bu yazı pratik ipuçlarından ziyade genel bir overview ele alıyor; ben de LLM tabanlı agentic/agent geliştirirken birkaç ipucu daha eklemek isterim: Sonuçta LLM transformer tabanlıdır (yani probabilistic based akıl yürütme; mevcut token/state’e dayanarak bir sonraki token’ı bağlamı/semantiği gerçekten anlayıp üretmekten ziyade olasılıksal olarak output verir). Bu yüzden sys prompt ne kadar iyi yazılırsa yazılsın, çoğu zaman istenen yanıtı vermediği durumlar olur (örneğin JSON output istenir ama bazen
}karakterini unutabilir). Bu nedenle regex tabanlı birden fazla fallback fn eklemek her zaman şarttır.Ayrıca structured output veren bir sys prompt yazıyorsanız genelde non-reasoning model kullanırsınız; context uzadıkça hallucination daha sık ortaya çıktığı için, tek bir uzun sys prompt yerine birkaç sys prompt hazırlayıp chaining yapmak daha iyidir.
Bir servis geliştirirken çeşitli hatalar oluşabileceğinden, servis mimarisini modüler ve fault tolerant şekilde tasarlamak kritik önemdedir (örneğin supervisor agent’ı async, diğer agent’ları sync yapmak). Özellikle unexpected output’un sık görüldüğü agentic ve agent sistemlerinde bu daha da önemlidir. Bu yüzden en baştan kod yazarken mümkün olduğunca SRP’ye uymak ve declarative bir yaklaşım benimsemek iyi olur; yani fonksiyonel bir yaklaşımın daha iyi olduğunu söylemek isterim (= side effect yoktur ve flow sezgiseldir).
Ayrıca LLM’i API üzerinden mi kullanacağınız yoksa modeli doğrudan kendiniz mi serve edeceğiniz duruma göre değişir; ancak SLM ya da LLM’i doğrudan serve edecekseniz backend’i host ettiğiniz sunucuda model serving yapmayın. IO bound task’lerle CPU bound task’leri (yani GPU gerektiren, mat mult gibi işlemler isteyen task’ler) ayrı sunuculara koymak fault tolerance açısından daha iyidir (örneğin CPU bound task’leri Runpod’da host etmek).
Bunun dışında daha birçok geliştirme ipucu var ama çok uzamasın diye burada bırakayım.
Birilerine faydalı olmasını umuyorum.
Private uzak sunucuya kurulan türden bir hizmet nasıl olur?
Korece çeviriye berbat otomatik çeviriyi pis pis dolduruyorlardı, demek ki daha da evrilmiş. Otomatik çeviriyi bile engelleyemedik; şimdi bir de berbat AI’ı pis pis dayatmalarının tadına bakalım hep birlikte!
cgi neyse de, jsp’ye verilen tepki gerçekten şaşırtıcı haha
jsp gerçekten de artık o kadar eski bir antika mı oldu acaba.
Yapay zeka özelliklerinden, özellikle arka planda bekleyip yardım edeceğini söyleyen hizmetlerden gerçekten nefret ediyorum.
Uzaktan çalıştırılıyorsa bilgilerimin paylaşılması sorunu var, yerelde çalıştırılıyorsa da bilgisayarımın kaynaklarını (CPU, bellek, pil, ...) tüketmesi sorunu var çünkü.
İyi bir referans olacağa benziyor.
Rusya kökenli bir geliştirici; Yandex'ten Riot'a geçmiş, şimdi de JPMorganChase'e transfer olmuş.
Hahahahahahaha, çok komik.
Sadece adı değişiyormuş gibi güçlü bir his veriyor.