- Birçok yapay zeka ürünü, ChatGPT gibi harici modelleri API üzerinden çağıran wrapper’lar olarak kalıyor; bu da farklılaşma, maliyet, hız ve özelleştirme risklerini ürünün içine taşıyor
- Basit LLM çağrısı yaklaşımı hızlıca geliştirilebilir, ancak herkes tarafından kopyalanabilir; OpenAI aynı işlevi ChatGPT’ye eklerse özgün değeri korumak zorlaşır
- Genel amaçlı LLM’lerin çalıştırma maliyeti yüksektir; GitHub Copilot gibi aylık 10 $ ücret alırken ortalama 20 $, bazı kullanıcılar için ise ayda 80 $’a kadar maliyet doğuran bir yapı ortaya çıkabilir
- Builder’ın Visual Copilot’ı, Figma tasarımlarını koda dönüştürme sürecinde yalnızca LLM kullanmayı denedi; ancak yanıt gecikmesi ve kalite sınırları nedeniyle kendi toolchain’ine geçti
- Pratikte sorunu önce klasik kodla çözmek; standart kodla ele alınması zor olan dar alanlara ise yalnızca özelleşmiş yapay zeka modelleri eklemek daha hızlı, daha ucuz ve daha kontrol edilebilir olur
Basit LLM wrapper yaklaşımının sınırları
- Günümüzde geliştirilen birçok yapay zeka ürünü, başka modellerin üzerinde çalışan wrapper’lara yakındır; ChatGPT API’ye doğal dil girdisi gönderip doğal dil çıktısı alma biçiminde çalışır
- Uygulaması kolaydır ve ilgi çekici özellikler hızlıca üretilebilir; ancak ürünün özgün değeri ileri yapay zeka teknolojisindeyse kopyalanma riski büyür
- PDF sohbet uygulamalarında olduğu gibi, bir kişi geliştirdiğinde birçok kişinin benzer uygulamalar yapması ve ardından OpenAI’ın bunu doğrudan ChatGPT’ye eklemesi, farklılaştırılmış teknoloji eksik olduğunda görülen bir akıştır
- Ürün yalnızca bir düğmeyle ChatGPT’ye istek gönderip yanıtı kullanıcıya göstermek düzeyindeyse savunulabilirliği en zayıf noktadadır
- Kendi teknolojisi kayda değer düzeydeyse ve LLM küçük ama önemli bir kısmı destekliyorsa daha iyi bir konumdadır; yine de maliyet ve hız sorunları devam eder
Maliyet ve hız, ürünleştirmenin gerçek kısıtlarıdır
- LLM’ler geniş genel amaçlılık elde etmek için büyük ve karmaşık hale geldi; bu yüzden çalıştırma maliyetleri de yükseldi
- Wall Street Journal’a göre GitHub Copilot kullanıcılardan aylık 10 $ alıyordu, ancak ortalama maliyeti 20 $’dı; bazı kullanıcılar GitHub’a ayda 80 $’a kadar maliyet oluşturuyordu
- Birçok ürünün tüm internet üzerinde eğitilmiş dev bir modele ihtiyacı yoktur; eğitim kapsamının %99,9’u belirli kullanım senaryosuyla ilgisiz olabilir
- Kullanıcıların ödemeye razı olduğu tutardan LLM tabanlı hizmeti işletme maliyetinin daha yüksek olduğu durumlar oluşabilir
- Hız da ürün deneyimini büyük ölçüde belirler
- ChatGPT gibi kelimeleri tek tek okuma deneyiminde yavaş çıktı bir ölçüde kabul edilebilir
- İş akışının bir sonraki adımına geçmeden önce yanıtın tamamına ihtiyaç duyan uygulamalarda gecikme doğrudan kullanılabilirlik düşüşüne yol açar
- Builder’ın Visual Copilot’ı, tasarımı yüksek kaliteli koda dönüştürmek için LLM dönüşümünü denedi; ancak tüm tasarım spesifikasyonunu verip token bazında yeni bir temsil almak birkaç dakika sürdüğü için pratik değildi
- LLM’in döndürdüğü temsil, insanların okuyabileceği bir biçimde olmadığından yükleme durumu da basit bir spinner’a benziyordu ve kullanıcı deneyimi iyi değildi
Yalnızca fine-tuning ile yeterli özelleştirme yapmak zordur
- LLM’ler fine-tuning desteklediği için istenen yöne daha yakın hale getirmek üzere bazı ayarlamalar yapılabilir
- Builder, Figma tasarımlarını girdi olarak verip kod çıktısı alma yaklaşımına fine-tuning uyguladı; ancak çok sayıda örnek sunmasına rağmen kalite iyileşmedi
- Sonuçta yaklaşım yavaş, pahalı ve düşük kaliteli hale geldi; başka bir yönteme ihtiyaç doğdu
- Seçilen alternatif kendi toolchain’ini oluşturmaktı
- fine-tuned LLM
- elde yazılmış özel derleyici
- kendi eğittiği model
- Günümüzde kendi modelini eğitmek yalnızca veri bilimcilerin veya makine öğrenmesi Ph.D.’lerinin yapabileceği bir iş değildir; makul deneyime sahip geliştiriciler de bunu yapabilir
- Bu yaklaşım daha hızlı, daha güvenilir, daha ucuz ve farklılaştırılmış ürünler geliştirmeye yardımcı olur
Karmaşık yapay zeka ürünleri tek bir dev modelden değil, toolchain’lerden oluşur
- Yapay zeka ürünleriyle ilgili yaygın yanılgı, çekirdek teknolojinin tamamını tek bir akıllı modelin işlediği düşüncesidir
- Otonom araçlar da kamera, sensör ve GPS girdilerini tek bir dev yapay zekanın alıp doğrudan sağa dönme gibi bir eylem çıktısı verdiği bir yapıda değildir
- Gerçekte birden çok özelleşmiş model ve klasik kod birlikte bağlanır
- Bilgisayarlı görü modeli nesneleri bulur ve tanımlar
- Öngörücü karar verme modeli diğer insanların davranışlarını tahmin eder
- Doğal dil işleme modeli sesli komutları anlar
- Çok sayıda klasik kod ve mantık nihai sonucu üretir
- Otonom araçlar çok daha karmaşık bir örnektir; genel bir yapay zeka ürününe başlarken bu düzeyde karmaşıklık gerekmez
- Otomobil özellikleri de tek seferde tamamlanmadı; otomatik park, yakınlıkta otomatik durma gibi özelliklerle başlayıp şerit terk düzeltmesi ve tüm sürüş kararlarına doğru katmanlar eklendi
- Yazılımda olduğu gibi yapay zeka özellikleri de bir katmanın üzerine bir sonraki katman konularak geliştirilir
Önce klasik kodla çözün, yalnızca gereken yerlere özelleşmiş yapay zeka ekleyin
- Visual Copilot yaklaşımındaki önemli başlangıç noktası, baştan yapay zeka kullanmamaktır
- Klasik programlama yöntemleriyle problem alanını keşfetmek ve gerçekten özelleşmiş model gereken bölgelerin nereler olduğunu önce bulmak gerekir
- Figma verilerini büyük miktarda modele verip tamamlanmış kodu doğrudan alma “süper model” yaklaşımı fazla karmaşıktır
- Desteklenmesi gereken framework’ler çeşitlidir
- Styling seçenekleri ve özelleştirme fazladır
- Yeni verileri yansıtacak şekilde sürekli yeniden eğitmek zordur
- Karmaşık, yavaş ve pahalı hale gelip ürünün piyasaya çıkmasını bile zorlaştırabilir
- Builder önce yapay zeka olmadan ne kadar ilerlenebileceğini araştırdı
- Her tasarım node’unun kodla ifade edilebilir bir nesneye dönüştürülmesi gerekiyordu
- Görsel, arka plan ve ön plan gibi öğelerin ayrıntılı anlaşılması gerekiyordu
- Her girdiyi responsive hale getirme yöntemi hassas biçimde ele alınmalıydı
- Elle yazılmış mantıkla dikey yığılan öğelerin flex column, yan yana olan öğelerin flex row olmasını sağlayacak şekilde çeşitli gelişmiş algoritmalar geliştirdi
- Standart kodun sınırlarına ulaşılan noktada yapay zeka eklendi
- Hangi layer’ların tek bir görselde birleştirilmesi gerektiğini otomatik algılama problemi insan algısı için kolaydır, ancak imperative JavaScript koduyla kolay değildir
- Nesne algılama gibi iyi oturmuş model türleri, Google Vertex AI gibi ürünlerde GUI üzerinden seçilip veri hazırlanarak ve yüklenerek eğitilebilir
- Veri üretmek için internetten yararlanılabilir
- puppeteer ile web sitesini tarayıcıda açıp ekran görüntüsü alınır
- HTML içinde dolaşılıp
imgetiketleri bulunur - Görsel konumu çıktı verisi, web sayfası ekran görüntüsü ise girdi verisi olarak kullanılır
- Böylece alt görsel koordinatları ve orijinal görsel elde edilip nesne algılama modeli eğitim verisi olarak kullanılır
- Kod ile özelleşmiş yapay zeka modelleri birleştirildiğinde, tasarımı seçip Generate code’a tıkladıktan sonra yaklaşık 1 saniye bekleyerek Builder.io’ya geçilebilir
- Builder’da tamamen responsive web siteleri ve özelleştirilebilir yüksek kaliteli kod elde edilebilir; çeşitli framework’ler ve seçenekler desteklenir
Kendi modelinizi kontrol ettiğinizde ortaya çıkan ürün avantajları
- Kendi modeliniz varsa, yalnızca harici bir modeli sarmakla kalmaz, modeli sürekli iyileştirebilirsiniz
- Yalnızca OpenAI gibi harici modellere bağımlıysanız, belirli kullanım senaryosunda ne zaman daha akıllı, daha hızlı veya daha ucuz hale geleceğini garanti edemezsiniz
- Prompt engineering ve fine-tuning ile kontrol edilebilecek alan da sınırlıdır
- Visual Copilot beta durumunda olduğu için hâlâ iyi içe aktaramadığı tasarımlar var; kullanıcı geri bildirimlerine göre her gün iyileştirmeler yayımlıyor
- Kendi teknolojinizi kontrol etmek gizlilik gereksinimlerini de daha iyi karşılamayı sağlar
- Gizlilik odaklı büyük şirketler, OpenAI’ı veya OpenAI kullanan ürünleri kullanamayacakları yönünde sık sık geri bildirim veriyor
- Verilerin izin verilmeyen sistemlere girmemesi gerektiğine dair bir gereksinim var
- Builder tüm teknolojiyi kontrol ettiği için yüksek gizlilik standartları uygulayabiliyor
- LLM aşaması zorunlu olmaktan çok isteğe bağlıdır; kapatılabilir
- Şirketler kendi LLM’lerini de bağlayabilir
- Tamamen şirket içi model
llama2fork’u- Kendi enterprise OpenAI instance’ı
- Diğer modeller
- Yapay zeka mümkün olduğunca az kullanılmalı; klasik kod ise hızlı, güvenilir, deterministik ve debug etmesi, düzeltmesi, yönetmesi, test etmesi kolay bir temel olarak kalmalıdır
- Ürünün sihri, her şeyi yapay zekayla değiştirmekten değil; küçük ama belirleyici alanlarda yapay zeka modeli kullanmaktan doğar
1 yorum
Hacker News görüşleri
Yazının genel yaklaşımına katılıyorum, ama yazarın önerdiği uygulama biçimini muhtemelen seçmezdim
Benim vardığım sonuç, LLM'lere fazla büyük ölçüde bağımlı olmamak gerektiği. Hem devrettiğiniz iş kapsamı açısından hem de tek bir belirli LLM'e bağlanmaktan kaçınmak gerektiğini düşünüyorum
Örneğin içeride OpenAI kullansanız bile, ChatGPT ile doğrudan rekabet eden bir ürün uzun vadede dezavantajlı olabilir. Otel ve uçak bileti rezervasyonunu sohbet botuyla yapan bir uygulama kurarsanız, bir gün ChatGPT, Microsoft ya da Google benzer işlevleri daha iyi sunup küçük işletmeyi etkisiz hale getirebilir
OpenAI SDK gibi şeylere aşırı bağımlı olmayı da zaman kaybı olarak görüyorum; doğrudan REST API çağırmak daha esnek
Ama araç zincirine derleyici eklemek ayrı bir mesele. Her derleyici eklediğinizde gereksiz karmaşıklık ve belirli araçlara bağımlılık artıyor. React ya da Svelte yeterliyken bileşenler arası çapraz derleyici kullanmak, web uygulaması yapmak için öğrenilmesi gereken bir şeyi daha artırıyor gibi görünüyor
Bence yazının nihai mesajı “hedefe ulaşmak için en verimli araç zincirini kurun” olmalı. Çok sayıda araç eklemek tek başına değer yaratmaz, başkalarının yaptığı yolu izlemek de değer yaratmaz; bu yalnızca LLM uygulama entegrasyonları için değil, yazılım mühendisliğinin geneli için de geçerli
AI bunun nasıl farklı olacağını ve sonunda aynı kısıtlara çarpıp çarpmayacağını pek bilmiyorum
Benzersiz olur ve kolayca kopyalanmaz, ama desteklenen dilleri düşününce bakım maliyeti muazzam olacaktır
Bu ek soyutlama katmanı biraz fabrika-fabrika-fabrika hissi veriyor
Hatta AI, uçak bileti aramadan daha fazla uzmanlaşma alanı sunabilir
Uzman işlere yönelik sohbet botlarında temel dil yorumlama artık yeterince iyi olduğundan, genel amaçlı dil modelinin kalitesi en önemli unsur değil. Benim zevklerime göre ayarlanmış ve ilgili niş API'lerle entegre bir seyahat rezervasyon sohbet botu, soruları biraz daha iyi ayrıştırsa da her şeyi Expedia üzerinden rezerve etmeye çalışan genel amaçlı bir araca kolayca yenilmez
Böyle pazarlarda bir kez iyi ya da kötü öneri alınması nedeniyle marka sadakati ya da ters tepki de oluşur; bu yüzden kazananın her şeyi aldığı bir yapı demek de zor
Blog yazısının özü aslında bu değildi
Onların ürünü, Figma tasarım dosyalarını otomatik olarak React koduna dönüştüren bir araç. Bu problemi normal kodla çözmenin yolu da burada derleyici
Herkese derleyici kullanın denmiyor
Bu bağlamda derleyicilere genel bir eleştiri çok isabetli değil. Alternatif, ChatGPT'yi derleyici gibi kullanmak ve yazıda bunun daha kötü olduğu oldukça ikna edici biçimde anlatılıyor. Ya da React kodu üreten ürün fikrinin kendisinin kötü olduğu mu söylenmek isteniyor, emin değilim
Düşündüren bir yazı ve “mümkün olduğunca uzun süre AI kullanmayın” ana fikrine katılıyorum
AI en iyi, yalnızca AI ile yapılabilecek işler için kullanılmalı. Bir özellik geliştirmek ya da bir problemi çözmek için AI'sız bir yöntem varsa, onu tercih etmek daha iyi
Artık herkes en üst düzey modellere neredeyse benzer erişime sahip olduğundan, iyi ürünler sonunda AI dışındaki şeylerle, yani iş akışı, UI, kullanıcı deneyimi, performans gibi eski usul unsurlarla tanımlanmak zorunda kalacak
Ama “kendi modelinizi eğitin” tavsiyesinden emin değilim. Bu, ürünü hızla eskiyen bir şeye dönüştürebilir. Kısa süreli bir farklılaşma sağlayabilir, ama 6-12 ay içinde OpenAI ya da devasa finansmana sahip bir rakip çok daha iyi bir model çıkarırsa, o farklılaştırılmış model olduğu gibi teknik borca dönüşür
Küçük bir startup'ın model üzerinden rekabet etmeye çalışması büyük bir dikkat dağınıklığı gibi görünüyor. Postgres ya da MySQL kullanmak yerine kendi veritabanınızı yapmaya benziyor. Elbette hendek ve kopyalanması zor ürünler gerekir, ama bunun eldeki kaynaklarla gerçekçi biçimde en iyi olunabilecek alan olması gerekir
Sonra ChatGPT çıkınca rakiplerin çalışmaları bir anda eskidi ve o kişi birkaç hafta içinde AI özellikleri açısından onları yakalayabildi
Ne yapılması gerektiğini doğru tahmin etmişti ama nedeni yanlıştı; sonuç olarak bu iş için inanılmaz faydalı oldu
Farklılaşma gerçekten oldukça önemli bir unsur
İyi bir yazı; yeni yapay zeka girişimlerinin çoğuna dokunacağını düşünüyorum. Benim tavsiyem baştan yapay zeka ürünü yapmamaktır
“X ürünü” çerçevesi müşteriye değer katacak bir yöne nadiren çıkar. Örneğin web3 ürünü, gözlemlenebilirlik ürünü, makine görüşü ürünü, yapay zeka ürünü gibi
Tüm iyi girişim fikirlerinde olduğu gibi, kilit nokta ortaya çıkan teknolojiyi kullanmak istediğiniz için bir probleme zorla uydurmak değil, gerçek kullanıcı ihtiyacından başlamaktır. Şişirilmiş beklentilere sahip bir teknolojiye UI eklemek kullanıcı ihtiyacını karşılamaz
Bunu LLM'lerden nefret ettiğim için söylemiyorum ama çevrimdışı hayatta tanıdığım insanların çoğu ürün olarak sohbet botlarıyla etkileşime girmekten hoşlanmıyor. Yakın zamanda taşınırken enerji, su ve internet sağlayıcılarının müşteri destek botlarıyla uğraştım; hepsi berbattı
“GPT havalı” düşüncesinden başlayıp özelleştirilmiş bir sohbet botu yapmak, gerçek kullanıcı ihtiyaçlarını çözmeye ya da sürdürülebilir bir işe dönüşmeye pek uygun görünmüyor
Teknoloji maliyetini hak edecek kadar gerçek bir problem bulmak bile birçok teknik insanın konfor alanının dışındadır. Problemin gerçek olduğunu varsayarız ya da daha kötüsü, gerçek olmasını umarak hemen çözüme atlarız. Çünkü bir şeyler yapmak alışık olduğumuz alandır
Bu tutumun ya da sürecin kendisi yanlış değildir. Teknik insanların gerçek problemleri çözdüğü birçok durumda, o gerçek problem yapma, yineleme ve durdurma sürecinde tesadüfen ortaya çıkmıştır
Bu yüzden teknik insanlar için gerçek problemi bulmanın en iyi yolu, problem keşfinde uzun süre oyalanmak yerine daha iyi bir yayınla-yinele-durdur döngüsüne sahip olmak olabilir. Yani mevcut kullanıma bakıp geleceği tahmin eden ve neyi yapmamaya hızlı karar veren bir döngü
Çeşitli teknoloji liderlerinin biyografilerini okuduktan sonra, onları ayıran temel yeteneğin çok temel bir MVP'den başlayıp kısa süre içinde gelecekteki talebe dair sezgilerini üstel biçimde keskinleştirme kabiliyeti olduğunu düşünmeye başladım
Birkaç yıl önce de sohbet botları vardı ve neredeyse tüm büyük şirketler bunlar için strateji kuruyordu. Fikir, çağrı merkezi personelini ciddi ölçüde azaltıp müşteri deneyimini iyileştirebilecekleri yönündeydi
Sorun sadece konuşma kalitesi değildi. Birçok kullanıcı için önemli olan şey yalnızca sorunun cevabını almak değil, bir insanın dinlediğine dair insani bir bağ hissiydi
Benim istediğim, işin mümkün olduğunca hızlı halledilmesidir; gerçekten bir insanla konuşup konuşmadığım önemli değil
Sohbet botlarının şimdiye kadar işe yaramamasının sebebi, sürece zaman ve sinir eklemeleriydi. İlk adım ya sohbet botuna telefon numaranızı söyletmek ya da zar zor bir temsilciye bağlanmaktı
OpenAI öncesi sohbet botlarının berbat olduğu zaten açıktı. Ama OpenAI sonrası sohbet botları gerçekten harikaysa, insanların neden kullanmayacağını anlamıyorum
Birkaç yıl önce bu blockchain'di. Sırada ne var bilmiyorum ama LinkedIn'deki “teknik insan” ağının kripto girişimlerinden yapay zeka girişimlerine kaydığını şimdiden görebiliyorum
Bu, yayın hızına karşı yapılmış büyük bir takas gibi görünüyor
Siz 6-12 ay harcayıp yayına çıktığınızda, başka ekipler doğrudan barındırılan modelleri kullanarak iki kez yineleme yapmış ve gerçek bir müşteri tabanı oluşturmuş olabilir. O sırada siz ilk müşterinize v0.1'i gösterirsiniz ve müşteri aslında başka bir şey istediğini söyleyebilir
O zaman mesele birkaç prompt'u düzeltmek olmaz; derleyiciyi ve araç zincirini, yığının üstünü ve altını yeniden kodlamanız gerekir
Müşterileri ve gereksinimleri gerçekten çok iyi biliyorsanız bu mantıklı olabilir, ama böyle kolay bir durumda neden genel amaçlı ve pahalı olsa bile barındırılan modellerle kavramı erken doğrulamayasınız sorusuna daha şüpheyle bakıyorum. Bu, erken optimizasyonun tüm kötülüklerin kaynağı olması meselesine benziyor
Teknoloji ve pipeline hakkında çok şey vardı ama yapılacak ürün ve çözülecek problem yoksa bunların hiçbir anlamı yok
Bu, kullanıcılara SOAP mı daha iyi REST mi diye tartışmaya benziyor. Kullanıcılar bunun nasıl yapıldığıyla ilgilenmez
Rekabet açısından fazla abartılı düşünülüyor. Yapmanız gereken şey kolayca kopyalanamayacak bir şey inşa etmek
Bunun birçok yolu var ama rekabet açısından gerekli olan tek kural bu
Neredeyse tüm dikey pazarlarda toplam pazarın %100'e yakını hâlâ açık
Teknik farklılaşma bunun küçük bir parçası; bence önce önemli olan şey erişim kapsamı
Bu, 1 milyar kullanıcıya gitme yarışı; bizim gibi B2B içinse muhtemelen 1 milyon kullanıcıya gitme yarışı. Aynı zamanda en iyi değer, yani çözülen problem ve kullanıcı deneyimi yarışı; en iyi teknik özellikler yarışı değil
Farkınız, başkalarının OAI kullanarak kopyalayamayacağı bir şeyse OAI kullanmanız güvenlidir
Tek farkınız OAI kullanmaksa zaten baştan kaybetmişsinizdir
Sonuçta ortaya konan duruma genel olarak katılıyorum. Bizim ürünümüz de LLM'leri durum makinesi benzeri bir kontrol akışı içinde kullanıyor ve iyi çalışıyor
Ama yazarın duygusuna katılmıyorum. Sadece ChatGPT web UI'ını kullanmış bir geliştiriciyseniz, “AI wrapper” teknolojisini %100 kurcalayıp bir şeyler yapmalısınız
Çünkü en üst düzey modellerin sınırlarını bizzat bulmadan, LLM'leri geleneksel yazılım stack'i içinde nereye ve nasıl kullanmanız gerektiğini görmek zor
Yazarın şirketi de sonuçta bu yoldan geçmiş gibi görünüyor. Başta Figma'dan koda dönüştüren LLM tabanlı bir prototip yaptılar ve “bir ölçüde” çalıştıktan sonra süreçteki boşlukları fark ettiler
Bu yüzden GPT-4-Vision gibi bir şeyle ister “yapay zeka tabanlı trading card derecelendirme sistemi” ister istediğiniz başka bir şeyi yapıp, ardından bunu builder.io gibi gerçekten bir ürün olarak çalıştırmanın yolunu bulmanın daha iyi olduğunu düşünüyorum
Yakında yapay zekanın çeşitli yazılımlara gömüleceği anlaşılıyor. O zaman gerçekten hem çok havalı hem de korkutucu olacak
Basit bir örnek e-posta istemcisi. Biri bir karar ya da onay istediğinde, yapay zeka soruyu çıkarıp radyo düğmeleri sunabilir
Örn: Önerilen toplantı saatini kabul et: [Cuma 10:00] [Pazartesi 11:30] [Başka bir saat öner]
George taslağı yayımlayabilir mi diye soruyor: [Evet] [Hayır]
Zendesk gibi müşteri destek talep yazılımlarında zaten yapay zeka var gibi görünüyor. Birçok destek talebi muhtemelen şimdiden neredeyse otomatik olarak yanıtlanıyordur
İK departmanları da yapay zekayla iş başvurularını eleyebilir, internette aday hakkında ek bilgi araştırabilir, ardından standartlaştırılmış veritabanı girdileri oluşturabilir. Elbette bu çok hatalı olabilir
İlginç olan bu tür uygulamalar; bir ChatGPT uzantısı ya da eklentisi daha değil
Her yeni e-postada pipeline çalıştırıp birkaç eylem önermesini sağlamayı düşünüyorum
Kafamda hâlâ birkaç yaklaşımı evirip çeviriyorum ama şimdiden yeterince mümkün görünüyor
Giriş kısmı biraz fazla gösterişli ve abartılı bir üslup gibi görünüyor. Örneğin LLM'ler o kadar da pahalı değil, Copilot'ın kullanıcı başına zarar ettiği yönündeki WSJ iddiası pek inandırıcı gelmiyor ve LLM'lerin her zaman “acı verecek kadar yavaş” olduğunu söylemek de zor
Yine de yazının asıl önerisi oldukça makul
Mümkün olduğunca çok şeyi kodla halletmek, kodla yapılamayan kısımlar içinse uzmanlaşmış yapay zeka kullanmak diyor
Mantıklı ama özellikle yeni bir şey de değil
Gerçekten faydalı ve iyi yapay zeka ürünlerinin nasıl geliştirileceğini daha derinlemesine ele almasını beklerdim. Humane'in son lansmanı gibi pek çok deneme oldu ama ortada hâlâ çok fazla başarı yok gibi görünüyor
Bu yazı yapay zeka ürünlerinin nasıl yapılacağına epey odaklanıyor ama ben şahsen “yapay zeka ürünü”nün başarısı ya da başarısızlığının farklılaşma, maliyet, hız ya da model özelleştirmeden çok gerçekten faydalı olup olmadığına bağlı olduğunu düşünüyorum
Ne yazık ki şimdiye kadar gördüğüm ürünlerin çoğu, kendine problem arayan çözümler gibi hissettiriyor
Bence şirketlerin şu anda gitmesi gereken yön, ürünü kullanırken en sıkıcı ve tekrarlı kısımları bulup bunları yapay zekayla güvenilir biçimde nasıl basitleştireceklerini keşfetmek
Her aşırı heyecan döngüsünde olduğu gibi, elinizde sadece çekiç varsa her şey çivi gibi görünür
Kısa süre önceki çekiç blockchain'di, şimdi ise yapay zeka
Blockchain'in vaatlerine kanacak kadar saf olduysanız, yapay zekanın da size zaman, enerji ya da özgün düşünce harcamadan milyonlarca dolar kazandıracak bir saadet zinciri olmadığını görünce hayal kırıklığına uğramanız da doğaldır
Sadece böyle şeyler arıyorsanız hayal kırıklığı yaşamaya devam edeceksiniz, üstelik bunu hak ederek
Yapay zekada blockchain'den çok daha fazlası var. İkisini aynı seviyede karşılaştırmak, ikisinden birini de gerçekten anlamadığınız anlamına gelir