Böyle yapay zeka projesi mi olur? :)

Son aylarda çok popüler yapay zeka (YZ) : Herkesin dilinde… xGPT’ler, yGPT’ler ve de zGPT’ler havada uçuşuyor… Herkes artık doğal bir refleks olarak bir şekilde hayatına dahil etmeye başladı yapay zekayı. Doğal refleks olarak diyorum çünkü önceleri biraz zoraki dahil oluyordu. Örneğin son kullanıcının hayatında birisi “Ya bir de ChatGPT’ye sor bakalım ne diyecek…” dediği zaman aklınıza geliyordu, ve de çok da umutlu bir şekilde de yaklaşmıyordunuz, hatta biraz da eğlencelik bir konuydu. Şimdi ise kendi kendinize farklı farkı alternatifleri de kullanacak şekilde doğrudan aklınızın bir köşesinde, yerli yerinde artık.

Zamanla son kullanıcı faydası iş gereksinimi faydasına doğru da evrilmeye başladı. Şirketler de YZ projerini daha yoğun ele almaya başladı son birkaç yıldır. Hatta birçok şirket bu konuda doygunluğa bile ulaştı, iyi örneklerini çoktan ortaya koydu. Bu devrim bu şekilde ilerlerken bir proje için onun bir yapay zeka projesi olup olmadığı hep bir tartışma konusu olmaya devam etti.

Bir teknoloji çalışanının bir projeye YZ projesi demesi ile teknoloji çalışanı olmayan birisinin bir projeye YZ projesi demesi bazen birbirinden çok çok farklı alanlarda çakışabiliyor. Bir teknoloji çalışanı işin içerisinde daha çok makine öğrenimi daha çok doğal dil işleme gibi yani aslında işin daha mutfağındaki teknoloji odaklı unsurlar bulundurmasını bekliyor. Yani bir YZ API’si kullanarak bir kullanıcı faydası oluşturan uygulama aslında onun gözünde öyle çok da fazla bir YZ projesi gibi konumlanmıyor: “Oradan iki service call yapıyoruz, böyle YZ projesi mi olur :)” diyor yani. Ben bu düşünceye çok yakın değilim.

Oysa ki örneğin bir pazarlama çalışanı açısından konu ise bambaşka bir halde görünebiliyor. Kullanıcı faydasının arkasında basit IF/ELSE’lerin olduğu, işin içerisinde bir akıl bulunmayan, bir metod ya da sistematik ya da şöyle diyelim matematik bulundurmayan konular bile YZ olarak değerlendirilebiliyor. Ben buna da çok yakın değilim.

Yakın olduğum nokta ise bir projenin YZ projesi olarak değerlendirilmesi ya da değerlendirilmemesi için bir sistematiğin, bir tanımın olması gerektiği.

Peki o tanım nasıl olabilir?

Bir kere bir projenin YZ projesi olabilmesi için YZ özellikleri barındırması kesin koşul olmalı. Yani bir YZ projesi, bir kullanıcı faydası oluşturmada, bir problemin çözümünde yapay zeka tekniklerinden (Makine öğrenimi, derin öğrenme, doğal dil işleme, bilgisayarla görme vb. vb.) yararlanarak bir sistem veya uygulama geliştirme süreci tanımlamalı.

Eğer bu tanıma uyuyorsa daha başlangıçta bu bir YZ projesidir ya da değildir diyebiliriz. Eğer bu bir YZ projesi diyorsak tam da bu aşamada bu tanımın yanına bir de “Teknoloji Geliştirme Seviyesi” isimli bir parametre daha eklenmeli diye düşünüyorum. Yani, “Tamam bu bir YZ projesi ama bu YZ projesinin teknolojisi ne aşamada acaba?” Hazır bir servisi mi kullandık, yoksa oturup herşeyi kendimiz mi sıfırdan geliştirdik bence bu parametrenin konusu olmalı. Çünkü YZ projesi olup olmamasının tanımı tamamen kullanıcı faydası odaklı olmalı. Bu kullanıcı faydasının YZ tekniklerinden faydalanılarak oluşturulduğu net ise onun tamamen tüm teknolojilerinin uçtan uca içeride yapılması ya da bir servis olarak dışarıdan alınması neden bir fark oluştursun ki? Dediğim gibi önemli olan uçtan uca sunulan kullanıcı faydasının tanımının ne olduğu. Bu mantık çerçevesinde özetle;

Eğer bir proje YZ tekniklerini kullanan herhangi bir bileşen içeriyorsa bu bileşenlerin dışarıdan bir hizmet olarak alınması ya da içeride geliştirilmiş olması bir uygulama mimarisi konusudur. Bu, projenin YZ projesi olmasını ya da olmamasını doğrudan etkilemez.

Peki teknoloji geliştirme seviyesi nasıl ele alınabilir? Aşağıdaki listede teknoloji seviyesi düşük olandan yüksek olana doğru bir örnek scala ile düşüncemi ifade etmeye çalışayım;

1. Low Code ya da tamamen düzenlenebilir akışlarlardan faydalanılarak oluşturulmuş dışa bağımlılığı olan proje.
2. Arka planda Low Code ya da tamamen düzenlenebilir akışları bir altyapı olarak kullanan ama önyüz geliştirmesi ve diğer önemli özellikleri kendisi geliştiren dışa bağımlılığı olan proje.
3. Bir YZ API’si kullanarak kullanıcı faydası oluşturan dışa bağımlılığı olan proje.
4. Bir YZ tekniğini bir kütüphane olarak kullanan ama dışa bağımlılığı kısa vadede elemine eden proje.
5. YZ tekniğini tamamen kendisi oluşturan ve dışa bağımlılığı olmayan proje. Hatta buradaki tekniği de computer vision, LLM vb vb kendi içerisinde alt kategorilere bölebiliriz.

Buradaki skala ve tanım çok daha fazla geliştirilebilir, ihtiyaca göre uyarlanabilir. Yalnızca örnek olması için belirttim.

Bu birliktelik içeren tanımın hem teknoloji ile çok iç içe ve derin bir YZ teknik bilgiye sahip kişileri, hem de YZ teknik bakış açısına sahip olmayıp daha çok kullanıcı faydasına odaklanan kişileri aynı bakış açısına getireceğini düşünüyorum. Bu tanımı yaparsak örneğin YZ-2 dediğimizde ne şekilde bir içeriğe sahip olduğu net ortaya çıkacaktır. Ok, YZ projesi ama low code kullanan bir sağlayıcıdan hizmet alıyor ve dışa bağımlı.

Özetle; bu yazıda bir projenin YZ projesi olup olmamasının belirleyicisinin ağırlıklı olarak oluşturduğu kullanıcı faydası olduğundan bahsetmeye çalıştım. Eğer oluşturduğu kullanıcı faydası odağında YZ tekniği kullanılan bir proje olduğunda herkes hemfikir ise bu YZ tekniğinin konumunun projenin YZ projesi olup olmamasına etkisi olmadığı konusundaki düşüncemi dile getirdim ve bir tanım ortaya koymaya çalıştım.