Günümüzde kodlama ajanları kişinin eksik kaldığı yönleri tamamlayabildiği için, insan kendi güçlü taraflarını net biçimde bilip bunları öne çıkarabilirse eşiğin düşebileceğini düşünüyorum.
Benim için de sorun hep dokümantasyondu; bunu bir ölçüde kodlama ajanına devredince hem yüküm azaldı hem de o dokümante edilmiş materyalleri gözden geçirirken dokümantasyon konusunda bir bakış açısı kazanmaya başladığımı hissediyorum.
Okuduğunuz için teşekkürler! Eskiden dokümantasyon, test senaryoları, doğrulama gibi insanların bizzat ilgilenmesi gereken pek çok şey vardı; artık ise oldukça büyük bir kısmı yapay zeka kodlama ajanlarıyla birlikte halledebildiğimiz için açık kaynak projeleri işletmenin zorluğu da sanırım eskisine göre beklenenden çok daha azalmış durumda!
Evet, yalnızca pano geçmişi açısından bakınca örtüşen çok şey var. Ama Raycast sadece panodan ibaret değil, birçok başka özelliği de olduğu için bana biraz fazla gelmişti.
Benim özellikle dikkat ettiğim noktalar şunlardı.
Öncelikle hafif olsun ve sadece pano geçmişini yönetsin istedim; şu anda yaklaşık 2 MB.
Ayrıca kaydedilen içerikleri ayrıntı ekranında düzenleyip ekleyebiliyorsunuz. Çeşitli prompt'ları gözden geçirip önceden ufak ufak düzeltirken bu bana kullanışlı geldi.
Arama ve klasörlemeye de özen gösterdim. Çalışırken gereken bilgiler, tek seferlik şeyler ya da tekrar arayıp bulması uğraştıran şeyler konusunda çözüm üretmeye çalıştım.
Metin, etiket, başlık gibi alanlarda arama yapılabiliyor.
İleride eklentiyle işlevleri ya da yerleşimleri doğrudan ekleyebilmeyi mümkün kılmak istiyorum, ama bunu henüz somutlaştırabilmiş değilim.
Raycast'in de iyi bir uygulama olduğunu düşünüyorum; seçimin zevke göre yapılabildiği bir seçenek olmaya çalışmak istiyorum.
Bu tür araçlarda en zor kısım biriktirmek değil, atmak; garden’ın ayrı bir yaşam döngüsü olarak ayrılmış olması dikkat çekiyor.
Ajanlara verilen bağlam eskidiğinde sadece işe yaramaz olmakla kalmaz, zararlı da olur. İnsan bir belgeye bakınca “bu eski bir şey gibi” diye sezer; modelde ise bu sezgi olmadığı için, 3 ay önce doğru olan değişmez koşulu hâlâ doğruymuş gibi alıp kullanır. Kod en azından derleme aşamasında kırılır, ama wiki sessizce yanlış kalır.
Bu yüzden sayfada hangi tarihe göre geçerli olduğu ve neye dayanarak yazıldığı bilgisinin eklenip eklenmediğini merak ediyorum. Markdown olarak depoda tutup Git üzerinden inceletme tercihini bu açıdan doğru buluyorum; çünkü diff’te görünen şey belgenin ne zaman değiştiğidir, içeriğin hâlâ geçerli olduğu zaman değil.
1.700 kayıt, performans tartışmasının pratikte anlam taşımadığı bir ölçek; ister front-end’de doğrudan işleyin ister back-end koyun, ikisi de anında açılır. Bu yüzden karar ölçütünün hız değil, eldeki Python mantığını yeniden yazıp yazmamak olması gerektiğini düşünüyorum.
Bu ölçüte göre Streamlit en uygun seçenek. Eşleştirme mantığını olduğu gibi import edip kullanırsınız; arayüz de 5 selectbox ve bir sonuç tablosundan ibaret olur, yani front-end kodu yazmanız gerekmez. Streamlit Community Cloud’a koyarsanız paylaşılabilir bağlantı da ücretsiz çıkar; JSON’ı çalışma anında okuyacak şekilde bırakırsanız yalnızca dosyayı değiştirerek güncel verinin yansımasını sağlayabilirsiniz.
Statik HTML’in dağıtımı daha basit olsa da Python mantığını JS’ye taşımanız gerekir; puan hesaplama biraz bile karmaşıksa birkaç gün bu port işine gider. Hedefiniz bu hafta içinde çalışan bir şeyi göstermekse, bu riski almamak daha iyi görünüyor.
Bir nokta var: Streamlit ister istemez bir üründen çok araç gibi görünür. İç karar vericilere yapılacak bir demo ise ve amaç “girdi verince gerçekten sonuç çıkıyor”u doğrulamaksa sorun olmaz; ama dış müşteriye demo yapılacaksa bunu hesaba katmalısınız.
Vay... Show GN yazılarında her zaman sadece “bir şey yaptım”ın ötesinde böyle içgörüleri de görmek istiyordum; böyle bir yazıyla karşılaşınca heyecanlandım hahaha
İnsan psikolojisi de böyle aslında: her olay için ayrı bir uzman bulup yalnızca kendi iş kapsamını vermektense, işi tek bir kişiye verince onun her şeyi kendi kendine halletmesini isteriz.
LLM’lerde de ödül fonksiyonu, ne atarsanız atın hepsini kabul edecek şekilde kurulmak zorunda kalmıyor mu?
Açık bir benchmark olsa bile bu kadar somut rakamları ilk kez gördüm. Teşekkürler.
159 / 76 / 3.197 oranı özellikle dikkatimi çekti. Karar verilemeyenlerin (ID yok) ezici çoğunlukta olması — sonuçta çoğu yinelemenin, takibin kendisinin yapılamadığı bir aralıkta bulunduğu anlamına geliyor ve "audit log varsa yeter" diye rahat olmamak gerektiğini bir kez daha doğruladı.
Önceliğin oluşturma (POST) tarafında olması yönü, bizim tasarımımızla tam olarak örtüşüyor. Bizim hash chain'de idempotency key'i önce oluşturma olayına eklemek istememizin nedeni tam olarak buydu.
E-posta message ID önerisini hemen uygulayacağım. İç araç spesifikasyonuna yalnızca "yanıtta entity ID zorunlu" maddesini eklemenin bile audit log'un doğrulanabilirliğini değiştirdiğini gördük. ID'yi hash chain'de anchor olarak kullanırsak, yinelenme olup olmadığını sadece hesaplamayla doğrulayabiliyoruz.
Acaba 3.197 adet "ID yok" vakasının hangi araç türlerinde yoğunlaştığını tespit edebildiniz mi? E-posta dışında sadece "başarılı/başarısız" döndüren araçların ne kadar olduğunu merak ediyorum.
Benzer bir şey yapan birine rastlamak bana da oldukça hoş bir his verdi!
Ben, büyük Claude çağı gelmeden önce de Rust ile API de yapıp CLI de geliştirirken Rust’a epey zaman yatırmıştım!
tmux’u değiştirmem gerektiğini düşünmeye oldukça yakın zamanda başladım; tmux’un kendisini tamamen değiştireli çok olmadı ama bir multiplexer da yaptım ve ikinci günden itibaren tmux kullanımını en aza indirmiştim!
Burada mesele sadece olgunluk değil; benim yaptığım araç yerine geri düşülebilecek başka bir araç olması, tersine bir kaçış alanı yaratıp geliştirmeye yeterince yüklenmememe de yol açmış olabilir diye düşünüyorum.
Bunun 4 ay sürmesinin sebebi, dediğiniz gibi, zevkime göre olan özellikleri birden fazla kişinin kullanabileceği bir yapıya genişletilebilir hâle getirmenin de uzun zaman almasıydı sanırım; bir de bunu kamuya açmak için de epey cesaret gerekiyordu.
Ayrıca orca gibi programlar şirket desteği alırken, bireysel olarak yürütülen bir projenin motivasyonu konusunda ben aksine olumlu düşünüyorum.
Elbette maddi yük kadar büyük bir motivasyon da yoktur ama ben tüm iş akışımı kullandığım araçlara göre kurdum; yani şu anda çalışabilmem için bu aracı geliştirmem gereken bir konumdayım, bu yüzden kişisel zamanımı da olabildiğince bölüp bu araçları geliştirmeye yatırıyorum.
Tabii motivasyonum düştüğü anda işin bitmesi gibi bir sorun var ama o durumu önlemek için iş akışımı bilerek kendi araçlarıma optimize ettim; böylece bunu engellemeye çalışıyorum!
Kişisel olarak, şu anda bile rakip araçlara kıyasla eksik olan şeyin teknik değil pazarlama olduğunu düşünüyorum; bu yüzden geri bildirim almak için yayımlamış olmam da oldukça büyük bir etken sanırım.
GPU rendering yapmamın nedeni Windows desteğinden çok, teknik bir meydan okuma ve terminal ekranını tamamen kaplayan programlara yönelik optimizasyondu.
Kişisel olarak Windows’u geliştirme amacıyla kullanmayalı uzun zaman oldu; bu yüzden o işletim sistemi desteğini derinlemesine düşünememiştim ama artık temel epey oluşmuş gibi, belki bir denemeye değer diye düşünüyorum.
Benim hedefim, geliştirme sürecimin tamamında sadece copad ile işi bitirmek ve bunun için bir plugin sistemi de hazırladım!
Bu yüzden GUI gerektiren özellikleri de mümkün olduğunca copad içinde hayata geçirmeye çalışıyorum.
Render etme biçiminde epey büyük bir fark var; ama aslında son kullanıcı açısından hissedilecek kadar büyük bir fark olmadığı için ayrıntılı anlatmak biraz mahcup edici geliyor. Söylediğiniz gibi üretim maliyetleri düştükçe, ele en iyi uyanın en iyisi olduğu bir dünyaya geldik sanırım..!
Bunu gerçek bir serviste uygulama fırsatım henüz olmadı. Bu sayıların tamamı herkese açık benchmark trace’lerinden geliyor; bu yüzden önce bu sınırlamayı belirtmek doğru olur.
Yine de idempotency key tasarımı için referans olabilecek bir gözlem var.
"İki kez çağrı" ile "iki kez yürütme"yi ayırt etmeye çalışmak için yanıtta yer alan entity ID’lerini karşılaştırdım. Aynı argümanlarla iki kez çağrıldığında yanıt ID’si farklıysa gerçekten iki tane oluşmuş, aynıysa API bunu kendi tarafında elemiş demektir.
Toolathlon benchmark’ına göre durum değiştiren araçlardaki yinelenen çağrılar arasında:
ID’si farklı olanlar (gerçek yinelenen oluşturma): 159 vaka
ID’si aynı olanlar (API’nin dedup yapması): 76 vaka
ID’nin kendisi olmadığı için karar verilemeyenler: 3.197 vaka
Burada bir yapı göze çarptı. ID’si farklı olan 159 vakanın tamamı oluşturma türü araçlardı (doküman oluşturma, spreadsheet oluşturma, dosya yükleme, quiz oluşturma). Buna karşılık güncelleme türlerinde (patch, update, enroll) ID’si farklı olan tek bir örnek yoktu; aynı hedefe işaret ettikleri için yeni bir şey oluşturulmamıştı.
Yani idempotency key ekleyecekseniz öncelik oluşturma (POST) tarafında olmalı gibi görünüyor. Güncelleme tarafı zaten çoğu durumda doğal olarak idempotent görünüyordu.
Az önce bahsettiğim e-posta sorunu da burada tekrar karşımıza çıkıyor. E-posta gönderiminde yanıt yalnızca "başarılı" string’i olduğu için ID karşılaştırması yapılamadı. idempotency key ekleseniz bile bunun gerçekten çalışıp çalışmadığını yalnızca trace üzerinden doğrulamanın bir yolu yok. İç araç tasarlıyorsanız, gönderim sonucunda message ID döndürmek bile denetim log’larında doğrulama yapılmasını sağlar. Bahsettiğiniz hash chain yöntemiyle de iyi uyum sağlayacağını düşünüyorum.
Sınırlamayı bir kez daha belirteyim: Yukarıdaki sayıların tamamı benchmark trace’lerinden geliyor; gerçek operasyon ortamında aynı oranların geçerli olup olmayacağını bilmiyoruz. Eğer trace çalıştırma fırsatınız olursa sonuçların nasıl farklılaştığını merak ederim.
Yani en iyi yol, kapalı LLM'leri piyasaya olabildiğince ucuza sunmak. Yüksek performanslı zekaya erişim artarsa, doğal olarak open-weight modellere yönelik geliştirme teşviki azalır ve teknolojik liderlik de genel kurumların elinde olabilir. Ama işin tuhafı, Anthropic'in piyasadaki en dışlayıcı sağlayıcı olması, değil mi?
Günümüzde kodlama ajanları kişinin eksik kaldığı yönleri tamamlayabildiği için, insan kendi güçlü taraflarını net biçimde bilip bunları öne çıkarabilirse eşiğin düşebileceğini düşünüyorum.
Benim için de sorun hep dokümantasyondu; bunu bir ölçüde kodlama ajanına devredince hem yüküm azaldı hem de o dokümante edilmiş materyalleri gözden geçirirken dokümantasyon konusunda bir bakış açısı kazanmaya başladığımı hissediyorum.
Okuduğunuz için teşekkürler! Eskiden dokümantasyon, test senaryoları, doğrulama gibi insanların bizzat ilgilenmesi gereken pek çok şey vardı; artık ise oldukça büyük bir kısmı yapay zeka kodlama ajanlarıyla birlikte halledebildiğimiz için açık kaynak projeleri işletmenin zorluğu da sanırım eskisine göre beklenenden çok daha azalmış durumda!
@xguru Bağlantı yanlış gibi görünüyor~
Evet, yalnızca pano geçmişi açısından bakınca örtüşen çok şey var. Ama Raycast sadece panodan ibaret değil, birçok başka özelliği de olduğu için bana biraz fazla gelmişti.
Benim özellikle dikkat ettiğim noktalar şunlardı.
Öncelikle hafif olsun ve sadece pano geçmişini yönetsin istedim; şu anda yaklaşık 2 MB.
Ayrıca kaydedilen içerikleri ayrıntı ekranında düzenleyip ekleyebiliyorsunuz. Çeşitli prompt'ları gözden geçirip önceden ufak ufak düzeltirken bu bana kullanışlı geldi.
Arama ve klasörlemeye de özen gösterdim. Çalışırken gereken bilgiler, tek seferlik şeyler ya da tekrar arayıp bulması uğraştıran şeyler konusunda çözüm üretmeye çalıştım.
Metin, etiket, başlık gibi alanlarda arama yapılabiliyor.
İleride eklentiyle işlevleri ya da yerleşimleri doğrudan ekleyebilmeyi mümkün kılmak istiyorum, ama bunu henüz somutlaştırabilmiş değilim.
Raycast'in de iyi bir uygulama olduğunu düşünüyorum; seçimin zevke göre yapılabildiği bir seçenek olmaya çalışmak istiyorum.
Görüşünüz için teşekkürler
Bu tür araçlarda en zor kısım biriktirmek değil, atmak; garden’ın ayrı bir yaşam döngüsü olarak ayrılmış olması dikkat çekiyor.
Ajanlara verilen bağlam eskidiğinde sadece işe yaramaz olmakla kalmaz, zararlı da olur. İnsan bir belgeye bakınca “bu eski bir şey gibi” diye sezer; modelde ise bu sezgi olmadığı için, 3 ay önce doğru olan değişmez koşulu hâlâ doğruymuş gibi alıp kullanır. Kod en azından derleme aşamasında kırılır, ama wiki sessizce yanlış kalır.
Bu yüzden sayfada hangi tarihe göre geçerli olduğu ve neye dayanarak yazıldığı bilgisinin eklenip eklenmediğini merak ediyorum. Markdown olarak depoda tutup Git üzerinden inceletme tercihini bu açıdan doğru buluyorum; çünkü diff’te görünen şey belgenin ne zaman değiştiğidir, içeriğin hâlâ geçerli olduğu zaman değil.
1.700 kayıt, performans tartışmasının pratikte anlam taşımadığı bir ölçek; ister front-end’de doğrudan işleyin ister back-end koyun, ikisi de anında açılır. Bu yüzden karar ölçütünün hız değil, eldeki Python mantığını yeniden yazıp yazmamak olması gerektiğini düşünüyorum.
Bu ölçüte göre Streamlit en uygun seçenek. Eşleştirme mantığını olduğu gibi import edip kullanırsınız; arayüz de 5 selectbox ve bir sonuç tablosundan ibaret olur, yani front-end kodu yazmanız gerekmez. Streamlit Community Cloud’a koyarsanız paylaşılabilir bağlantı da ücretsiz çıkar; JSON’ı çalışma anında okuyacak şekilde bırakırsanız yalnızca dosyayı değiştirerek güncel verinin yansımasını sağlayabilirsiniz.
Statik HTML’in dağıtımı daha basit olsa da Python mantığını JS’ye taşımanız gerekir; puan hesaplama biraz bile karmaşıksa birkaç gün bu port işine gider. Hedefiniz bu hafta içinde çalışan bir şeyi göstermekse, bu riski almamak daha iyi görünüyor.
Bir nokta var: Streamlit ister istemez bir üründen çok araç gibi görünür. İç karar vericilere yapılacak bir demo ise ve amaç “girdi verince gerçekten sonuç çıkıyor”u doğrulamaksa sorun olmaz; ama dış müşteriye demo yapılacaksa bunu hesaba katmalısınız.
Raycast’teki özelliklerin neredeyse tamamı destekleniyor gibi görünüyor; acaba hangi noktalarda farklı?
Vay... Show GN yazılarında her zaman sadece “bir şey yaptım”ın ötesinde böyle içgörüleri de görmek istiyordum; böyle bir yazıyla karşılaşınca heyecanlandım hahaha
İnsan psikolojisi de böyle aslında: her olay için ayrı bir uzman bulup yalnızca kendi iş kapsamını vermektense, işi tek bir kişiye verince onun her şeyi kendi kendine halletmesini isteriz.
LLM’lerde de ödül fonksiyonu, ne atarsanız atın hepsini kabul edecek şekilde kurulmak zorunda kalmıyor mu?
Açık bir benchmark olsa bile bu kadar somut rakamları ilk kez gördüm. Teşekkürler.
159 / 76 / 3.197 oranı özellikle dikkatimi çekti. Karar verilemeyenlerin (ID yok) ezici çoğunlukta olması — sonuçta çoğu yinelemenin, takibin kendisinin yapılamadığı bir aralıkta bulunduğu anlamına geliyor ve "audit log varsa yeter" diye rahat olmamak gerektiğini bir kez daha doğruladı.
Önceliğin oluşturma (POST) tarafında olması yönü, bizim tasarımımızla tam olarak örtüşüyor. Bizim hash chain'de idempotency key'i önce oluşturma olayına eklemek istememizin nedeni tam olarak buydu.
E-posta message ID önerisini hemen uygulayacağım. İç araç spesifikasyonuna yalnızca "yanıtta entity ID zorunlu" maddesini eklemenin bile audit log'un doğrulanabilirliğini değiştirdiğini gördük. ID'yi hash chain'de anchor olarak kullanırsak, yinelenme olup olmadığını sadece hesaplamayla doğrulayabiliyoruz.
Acaba 3.197 adet "ID yok" vakasının hangi araç türlerinde yoğunlaştığını tespit edebildiniz mi? E-posta dışında sadece "başarılı/başarısız" döndüren araçların ne kadar olduğunu merak ediyorum.
Şu anda optimizasyon aşamasında; bu hafta içinde tamamlanırsa daha derli toplu görebileceğinizi düşünüyorum :)
Koreceye geçiş işlevini şimdiden eklemişsiniz :)
Çok teşekkürler
Benzer bir şey yapan birine rastlamak bana da oldukça hoş bir his verdi!
Ben, büyük Claude çağı gelmeden önce de Rust ile API de yapıp CLI de geliştirirken Rust’a epey zaman yatırmıştım!
tmux’u değiştirmem gerektiğini düşünmeye oldukça yakın zamanda başladım;tmux’un kendisini tamamen değiştireli çok olmadı ama bir multiplexer da yaptım ve ikinci günden itibarentmuxkullanımını en aza indirmiştim!Burada mesele sadece olgunluk değil; benim yaptığım araç yerine geri düşülebilecek başka bir araç olması, tersine bir kaçış alanı yaratıp geliştirmeye yeterince yüklenmememe de yol açmış olabilir diye düşünüyorum.
Bunun 4 ay sürmesinin sebebi, dediğiniz gibi, zevkime göre olan özellikleri birden fazla kişinin kullanabileceği bir yapıya genişletilebilir hâle getirmenin de uzun zaman almasıydı sanırım; bir de bunu kamuya açmak için de epey cesaret gerekiyordu.
Ayrıca orca gibi programlar şirket desteği alırken, bireysel olarak yürütülen bir projenin motivasyonu konusunda ben aksine olumlu düşünüyorum.
Elbette maddi yük kadar büyük bir motivasyon da yoktur ama ben tüm iş akışımı kullandığım araçlara göre kurdum; yani şu anda çalışabilmem için bu aracı geliştirmem gereken bir konumdayım, bu yüzden kişisel zamanımı da olabildiğince bölüp bu araçları geliştirmeye yatırıyorum.
Tabii motivasyonum düştüğü anda işin bitmesi gibi bir sorun var ama o durumu önlemek için iş akışımı bilerek kendi araçlarıma optimize ettim; böylece bunu engellemeye çalışıyorum!
Kişisel olarak, şu anda bile rakip araçlara kıyasla eksik olan şeyin teknik değil pazarlama olduğunu düşünüyorum; bu yüzden geri bildirim almak için yayımlamış olmam da oldukça büyük bir etken sanırım.
GPU rendering yapmamın nedeni Windows desteğinden çok, teknik bir meydan okuma ve terminal ekranını tamamen kaplayan programlara yönelik optimizasyondu.
Kişisel olarak Windows’u geliştirme amacıyla kullanmayalı uzun zaman oldu; bu yüzden o işletim sistemi desteğini derinlemesine düşünememiştim ama artık temel epey oluşmuş gibi, belki bir denemeye değer diye düşünüyorum.
Benim hedefim, geliştirme sürecimin tamamında sadece copad ile işi bitirmek ve bunun için bir plugin sistemi de hazırladım!
Bu yüzden GUI gerektiren özellikleri de mümkün olduğunca copad içinde hayata geçirmeye çalışıyorum.
Render etme biçiminde epey büyük bir fark var; ama aslında son kullanıcı açısından hissedilecek kadar büyük bir fark olmadığı için ayrıntılı anlatmak biraz mahcup edici geliyor. Söylediğiniz gibi üretim maliyetleri düştükçe, ele en iyi uyanın en iyisi olduğu bir dünyaya geldik sanırım..!
Şirket içi danışmanlık kayıtlarını İK disiplin dosyalarında toplayan Samsung da ne de olsa küresel bir öncü şirket.
Bunu gerçek bir serviste uygulama fırsatım henüz olmadı. Bu sayıların tamamı herkese açık benchmark trace’lerinden geliyor; bu yüzden önce bu sınırlamayı belirtmek doğru olur.
Yine de idempotency key tasarımı için referans olabilecek bir gözlem var.
"İki kez çağrı" ile "iki kez yürütme"yi ayırt etmeye çalışmak için yanıtta yer alan entity ID’lerini karşılaştırdım. Aynı argümanlarla iki kez çağrıldığında yanıt ID’si farklıysa gerçekten iki tane oluşmuş, aynıysa API bunu kendi tarafında elemiş demektir.
Toolathlon benchmark’ına göre durum değiştiren araçlardaki yinelenen çağrılar arasında:
ID’si farklı olanlar (gerçek yinelenen oluşturma): 159 vaka
ID’si aynı olanlar (API’nin dedup yapması): 76 vaka
ID’nin kendisi olmadığı için karar verilemeyenler: 3.197 vaka
Burada bir yapı göze çarptı. ID’si farklı olan 159 vakanın tamamı oluşturma türü araçlardı (doküman oluşturma, spreadsheet oluşturma, dosya yükleme, quiz oluşturma). Buna karşılık güncelleme türlerinde (patch, update, enroll) ID’si farklı olan tek bir örnek yoktu; aynı hedefe işaret ettikleri için yeni bir şey oluşturulmamıştı.
Yani idempotency key ekleyecekseniz öncelik oluşturma (POST) tarafında olmalı gibi görünüyor. Güncelleme tarafı zaten çoğu durumda doğal olarak idempotent görünüyordu.
Az önce bahsettiğim e-posta sorunu da burada tekrar karşımıza çıkıyor. E-posta gönderiminde yanıt yalnızca "başarılı" string’i olduğu için ID karşılaştırması yapılamadı. idempotency key ekleseniz bile bunun gerçekten çalışıp çalışmadığını yalnızca trace üzerinden doğrulamanın bir yolu yok. İç araç tasarlıyorsanız, gönderim sonucunda message ID döndürmek bile denetim log’larında doğrulama yapılmasını sağlar. Bahsettiğiniz hash chain yöntemiyle de iyi uyum sağlayacağını düşünüyorum.
Sınırlamayı bir kez daha belirteyim: Yukarıdaki sayıların tamamı benchmark trace’lerinden geliyor; gerçek operasyon ortamında aynı oranların geçerli olup olmayacağını bilmiyoruz. Eğer trace çalıştırma fırsatınız olursa sonuçların nasıl farklılaştığını merak ederim.
Ekran görüntülerini koyduğunuz bir sepet gibi.
Benzer fikirli bir JIT derleme yaklaşımı kullanan numba var, ama bunun kapsamı daha geniş gibi görünüyor.
Sadece
gps oss 120bgibi bir şey ortaya koysalar, en azından biraz daha ikna edici görünürdü ama emin değilim.Yani en iyi yol, kapalı LLM'leri piyasaya olabildiğince ucuza sunmak. Yüksek performanslı zekaya erişim artarsa, doğal olarak open-weight modellere yönelik geliştirme teşviki azalır ve teknolojik liderlik de genel kurumların elinde olabilir. Ama işin tuhafı, Anthropic'in piyasadaki en dışlayıcı sağlayıcı olması, değil mi?