Yapay Zekâ Girişimleri İçin TEKMER: Ürün ve Veri Doğrulama Rehberi

Yapay zekâ girişimi için TEKMER seçerken neye bakılmalı?

Yapay zekâ girişimi için uygun TEKMER, model gösteriminin ötesinde müşteri problemini, veri erişimini, ürün değerlendirmesini ve ticari modeli birlikte çalışabileceği bir ortam sunmalıdır. Güçlü bir demo tek başına sürdürülebilir ürün anlamına gelmez. Müşterinin verisi değiştiğinde sistemin ne yaptığı, hataların nasıl yakalandığı ve her kullanımın şirkete neye mal olduğu da incelenmelidir.

Bu rehberin odağı model eğitme talimatı değil, bir yapay zekâ ürününün iş değeri taşıdığını kanıtlama düzenidir. Buradaki örnekler kurgusaldır; belirli bir girişimin performansını veya Orion TEKMER'in sunduğu hesaplama altyapısını anlatmaz. Merkez hizmetleri, program durumu ve teknik olanaklar başvuru sırasında ayrıca öğrenilmelidir.

Doğru başlangıç sorusu “hangi modeli kullanmalıyız?” yerine “hangi kararı veya işi daha iyi hale getireceğiz?” olabilir. Model seçimi bu sorunun ardından gelir. İşin mevcut hali, verinin sınırları ve kabul edilebilir hata türleri anlaşıldığında hem ürün planı hem müşteri görüşmesi daha somut hale gelir. Genel merkez bilgisi için TEKMER rehberine bakılabilir.

1. Yapay zekâ özelliği yerine tamamlanan işi tanımlayın

Müşteri çoğu zaman bir model kullanmak için bütçe ayırmaz; belirli bir işi daha az güçlükle tamamlamak ister. Bu iş destek taleplerini yönlendirmek, belge bulmak, üretim hatalarını incelemek veya teklif taslağı hazırlamak olabilir. Her biri farklı veri, hata ve kullanıcı beklentisi taşır. “Her sektöre yapay zekâ” yaklaşımı, ilk ürün kararlarını gereksiz ölçüde genişletebilir.

İş akışını başlangıçtan sonuca kadar yazın. Kullanıcı hangi girdiyi alıyor, hangi adımları uyguluyor ve sonunda hangi kararı veriyor? Yapay zekâ bu akışın tamamını değil, yalnızca bir kısmını destekleyebilir. Ürünün devreye girdiği nokta ile insanın sorumluluğunun devam ettiği nokta ayrı gösterilmelidir.

Mevcut yöntemi küçümsememek önemlidir. Bir elektronik tablo veya basit arama ekranı müşterinin işini yeterince iyi görüyor olabilir. Yeni sistemin eğitim, geçiş, veri düzenleme ve bakım maliyetleri vardır. Değişim için anlamlı bir fayda yoksa teknik yenilik satın alma gerekçesine dönüşmez.

Problem görüşmelerinde gelecek ürününüzü övmek yerine yakın zamanda yaşanmış bir örnek isteyin. Kullanıcı son işi nasıl yaptı, nerede bekledi ve neyi tekrar kontrol etti? Somut bir olay, genel bir “böyle bir sisteme ihtiyacımız var” cümlesinden daha yararlı ürün verisi üretir.

2. Veri envanterini ürün yol haritasından önce çıkarın

Verinin var olması ile kullanılabilir olması farklıdır. Dosyalar bir kurumda bulunabilir, fakat ürün geliştirme amacıyla erişim sağlanamayabilir. İzin verilmiş veri de eksik, tutarsız veya hedeflenen kullanıcı grubunu temsil etmiyor olabilir. Bu nedenle veri incelemesi yalnızca teknik bir hazırlık işi değil, ürünün mümkün olup olmadığını gösteren temel çalışmadır.

Envanterde veri kaynağı, biçimi, güncellenme sıklığı, sorumlusu ve kullanım sınırı yer alabilir. Ayrıca hangi alanların gerçekten gerekli olduğu sorulmalıdır. İhtiyaç dışı veriyi toplamak ürünü otomatik olarak iyileştirmez; inceleme yükünü ve hata ihtimalini artırabilir. İlk pilot için daha dar bir veri kümesi yeterli olabilir.

Etiketli veri kullanılıyorsa etiketlerin nasıl üretildiğini anlamak gerekir. İki uzman aynı örneği farklı sınıflandırıyorsa sorun yalnızca modelde değildir. Ürün hedefi veya karar tanımı da belirsiz olabilir. Görüş ayrılıklarının nedenlerini kaydetmek, yanlış kesinlikten daha değerlidir.

Veri sözlüğü ekip değişse bile anlaşılabilir olmalıdır. Bir sütunun anlamı yalnızca kurucunun hafızasında kalırsa pilot büyüdüğünde hata riski artar. Veri açıklamalarını, bilinen eksikleri ve güncelleme kararlarını küçük ama düzenli bir kayıt altında tutun. Bu kayıt, müşteriyle yapılacak teknik görüşmenin de ortak zemini olur.

3. Eğitim başarısı ile gerçek kullanım başarısını ayırın

Bir modelin geliştirme sırasında gördüğü örneklerde iyi sonuç vermesi, yeni kullanıcılarla aynı sonucu vereceğini göstermez. Ürün değerlendirmesi için geliştirme kararlarından mümkün olduğunca ayrı tutulan bir örnek grubu gerekir. Bu grubun nasıl seçildiği ve hangi koşulları temsil ettiği açık olmalıdır. Amaç yalnızca yüksek bir puan üretmek değildir.

Gerçek kullanımda kısa, eksik, hatalı yazılmış veya alışılmadık girdiler bulunabilir. Testler yalnızca temiz örneklerden oluşursa ürünün kırılgan tarafları görünmez. Bununla birlikte her uç durumu eşit önemde saymak da kaynakları dağıtabilir. Sık görülen ve ciddi sonuç doğurabilecek durumlar önceliklendirilebilir.

Değerlendirme seti model değiştikçe gelişigüzel değiştirilmemelidir. Aksi halde iki sürüm arasındaki farkın modelden mi, test örneklerinden mi kaynaklandığı anlaşılamaz. Yeni durumlar için ek bir bölüm oluşturulabilir; temel karşılaştırma grubu ayrı korunabilir.

Sonuç raporunda örnek sayısı kadar örneklerin niteliği de anlatılmalıdır. Bir tek müşteri verisiyle elde edilen sonuç bütün sektör için genellenmemelidir. Bu yaklaşım iddiayı zayıflatmaz; hangi koşullarda geçerli olduğunu açıklar. Müşteri, kendi koşullarının rapora benzeyip benzemediğini değerlendirebilir.

4. Hataları tek puanın arkasında saklamayın

Ortalama başarı oranı, bazı kullanıcılar için çok kötü çalışan bir sistemi görünmez kılabilir. Hataları türlerine ayırmak ürün kararını kolaylaştırır. Yanlış sınıflandırma, eksik bilgi, desteklenmeyen cevap, gereksiz uyarı veya işi tamamlayamama farklı nedenlerden kaynaklanabilir. Bunların müşteri üzerindeki etkileri de aynı değildir.

Bir belge asistanında doğru belgeyi bulamamak ile belgede olmayan bir bilgiyi kesinmiş gibi sunmak ayrı sorunlardır. İlkinde kullanıcı daha fazla arama yapar; ikincisinde yanlış bilgiye güvenebilir. Bu nedenle değerlendirme yalnızca cevap var mı sorusuna değil, cevabın dayanağı görülebiliyor mu sorusuna da bakmalıdır.

Hata kaydında örnek girdi, beklenen davranış, gerçekleşen davranış, etki ve düzeltme kararı bulunabilir. Kullanıcı bilgileri gereksiz biçimde kopyalanmamalıdır. Ekip, uygun kayıt yöntemi ve erişim sınırları konusunda kendi veri yükümlülüklerini değerlendirmelidir.

Her hatayı model değiştirerek çözmek gerekmeyebilir. Daha iyi bir giriş formu, açık bir uyarı, daraltılmış kapsam veya kullanıcıya sunulan doğrulama adımı bazı sorunları azaltabilir. Ürün tasarımı ile model kalitesini ayrı dünyalar olarak görmek yerine birlikte ele almak daha gerçekçi bir geliştirme düzeni sağlar.

5. İnsan kontrolünü iş akışına yerleştirin

İnsan onayı bir düğmeden ibaret olmamalıdır. Kullanıcının neyi, hangi bilgiyle ve ne kadar sürede kontrol edeceği belirlenmelidir. Sistem çok sayıda öneri üretiyor ama kullanıcı bunları gerçekten inceleyemiyorsa onay süreci yalnızca görünüşte kalabilir. Bu yüzden kontrol görevinin yükü de pilotta ölçülmelidir.

Ürün, insanın değerlendirmesini kolaylaştıracak dayanaklar sunabilir. Kaynak belge, kullanılan veri tarihi veya belirsizlik açıklaması bunlardan bazılarıdır. Kullanıcı ürüne itiraz edebilmeli, gerektiğinde mevcut yönteme dönebilmeli ve hatayı bildirebilmelidir. Bu yolların görünür olması, sadece kullanım kılavuzunda yazmasından daha yararlıdır.

TÜBİTAK'ın yapay zekâ politika sayfası insanı destekleyen kullanım, veri mahremiyeti ve şeffaflığı vurgular. Bu kurumsal yaklaşım bütün ürünler için tek bir uygunluk belgesi değildir. Girişim kendi kullanım alanına özgü gereksinimleri ayrıca incelemelidir.

Özellikle sonuçları önemli kararları etkileyen ürünlerde iş ve alan uzmanları erken sürece katılmalıdır. Geliştirici ekibin teknik olarak mümkün gördüğü bir kullanım, gerçek iş ortamında uygun olmayabilir. Kontrol tasarımı ürünün sonuna eklenen bir bölüm yerine ilk pilot planının parçası olmalıdır.

6. Maliyet hesabını cevap başına değil iş başına yapın

Model kullanım bedeli toplam maliyetin yalnızca bir bölümüdür. Veri hazırlama, saklama, entegrasyon, kullanıcı desteği ve kalite incelemesi de hesaba katılmalıdır. Bir işlem ucuz görünürken hatalı sonuçların tekrar ele alınması bütün faydayı ortadan kaldırabilir. Bu nedenle maliyet, tamamlanan ve kabul edilen iş üzerinden incelenmelidir.

Kurgusal bir belge ürününde kullanıcı tek soruyu farklı biçimlerde tekrar soruyorsa, teknik istek sayısı ile tamamlanan görev sayısı birbirinden ayrılır. Ürünün gelir modeli görev başınaysa bu fark brüt kâra doğrudan yansıyabilir. Sınırsız kullanım sözü vermeden önce gerçek kullanım davranışı görülmelidir.

Maliyet tablosuna düşük, beklenen ve yoğun kullanım senaryoları eklenebilir. Bu senaryolardaki sayılar bir tahmin olarak etiketlenmeli, müşteri verisi geldiğinde yenilenmelidir. Kullanım arttıkça yalnızca model faturası değil destek ve izleme ihtiyacı da değişebilir.

Bir hizmet sağlayıcının fiyatı veya teknik sınırı zaman içinde değişebilir. Bu nedenle ürünün önemli bir dış hizmete bağımlılığı ticari plan içinde görünür olmalıdır. Alternatif kurulum veya sağlayıcı değerlendirmesi yapılırken geçişin veri, kalite ve bakım sonuçları birlikte düşünülmelidir. En ucuz teknik seçenek her zaman en düşük toplam maliyet anlamına gelmez.

7. Pilot müşteriye sonuç değil deney tasarımı götürün

Erken aşamada kesin verim artışı vaat etmek yerine neyin ölçüleceğini açıkça anlatmak daha sağlam bir yaklaşım olur. Pilot önerisinde mevcut iş akışı, katılımcılar, veri kapsamı, test süresi, değerlendirme yöntemi ve karar toplantısı bulunmalıdır. Müşteri bu planın kendi işine uygunluğunu değerlendirebilmelidir.

Başlangıç ölçümü alınmadan pilot sonundaki değişimi yorumlamak zordur. Kullanıcı işi bugün ne kadar sürede yapıyor, kaç kez geri dönüyor ve hangi adımlarda yardım alıyor? Bu bilgiler doğrudan gözlem veya uygun kayıtlarla anlaşılabilir. Kullanıcının tahmini ile gözlenen süre farklıysa her ikisini de ayrı not etmek yararlıdır.

Pilot grubu ürünü geliştiren kişilerden ibaret olmamalıdır. Ürüne aşina olmayan kullanıcının karşılaştığı sorunlar gerçek kullanım için önemli olabilir. Eğitim verilecekse süresi ve içeriği kaydedilmeli; ürünün faydası yalnızca deneyimli ekibin performansından çıkarılmamalıdır.

Pilot sonunda teknik kalite, iş faydası ve kullanıcı kabulü ayrı değerlendirilmelidir. Sistem doğru çalışıyor olabilir ama iş akışına uymadığı için kullanılmayabilir. Ya da kullanıcılar deneyimi sevse bile ekonomik fayda ortaya çıkmayabilir. Bu ayrım, sonraki geliştirme kararının daha doğru verilmesini sağlar.

8. Varsayımsal örnek: satın alma belgeleri asistanı

Kurgusal bir ekip, satın alma uzmanlarının eski şartnamelerde arama yapmasını kolaylaştıran bir asistan geliştiriyor olsun. İlk demoda birkaç örneğe düzgün cevap vermesi ekibi heyecanlandırır. Fakat müşteri toplantısında belgelerin farklı sürümlerinin bulunduğu ve bazı hükümlerin güncel olmadığı anlaşılır. Asıl ürün sorunu yalnızca arama değil, doğru sürümü ayırt etmektir.

Ekip pilotu daraltır: yalnızca müşteri tarafından güncel olarak işaretlenmiş belgeler kullanılacaktır. Cevaplar ilgili bölüme bağlantı verecek, kaynak bulunamadığında bunu açıkça gösterecektir. Kullanıcı son kararı kendi değerlendirmesiyle verecektir. Bu kapsam, ürünün ne yaptığını ve ne yapmadığını müşteriye anlaşılır biçimde sunar.

İlk denemelerde bazı soruların belgeden değil kurum içi deneyimden cevaplandığı görülür. Ekip bu soruları hata olarak modele zorla öğretmek yerine ayrı bir ihtiyaç grubuna alır. Böylece veriyle desteklenmeyen cevapların çoğalması engellenir. Ürün yol haritası gerçek kullanım örneklerinden beslenir.

Bu senaryoda başarı yalnızca hızlı cevap üretmek değildir. Doğru belgeye erişim, kaynak görünürlüğü ve kullanıcının inceleme yükü birlikte ele alınır. Örnek bir gerçek müşteri hikâyesi değildir; veri ve iş tanımının ürünü nasıl değiştirebileceğini göstermek için oluşturulmuştur.

9. TEKMER'de hangi uzmanlıkları aramalısınız?

Yapay zekâ girişimleri için yalnızca teknik mentorluk yeterli olmayabilir. Alan bilgisi, kullanıcı araştırması, kurumsal satış ve maliyet yönetimi farklı soruları cevaplar. Merkez seçiminde bu uzmanlıklara hangi yöntemle erişilebildiğini öğrenmek gerekir. Uzman listesinde isim bulunması ile düzenli çalışma imkânı aynı şey değildir.

Görüşmeye üç somut karar götürün. Örneğin hedef sektörün daraltılması, pilot ölçütlerinin seçilmesi ve fiyat modelinin değerlendirilmesi. Her görüşmenin sonunda hangi kararın değiştiğini kaydedin. Çok sayıda toplantı yapmak, ürünün aynı ölçüde ilerlediğini göstermeyebilir.

Hesaplama altyapısı, veri seti veya laboratuvar desteği ihtiyacınız varsa bunları açıkça sorun. TEKMER adı tek başına GPU erişimi, özel veri kaynağı veya teknik sertifikasyon sağlandığı anlamına gelmez. Hizmetlerin kapsamı, ücretleri ve erişim koşulları merkezden doğrulanmalıdır.

Orion TEKMER Ankara'daki çalışma ve ekosistem olanaklarını değerlendirmek isteyen ekipler ön başvuru formunda ürün aşamasını ve temel ihtiyacını anlatabilir. Programlar sayfasındaki güncel başvuru durumunu incelemek gerekir. Program adını görmek, o tarihte başvuruların açık olduğu anlamına gelmez.

10. Yayına aldıktan sonra öğrenme düzenini koruyun

Ürün yayımlandığında değerlendirme bitmez. Müşteri verisi, kullanıcı davranışı ve dış hizmetler zaman içinde değişebilir. Ekip hangi işaretlerde inceleme başlatacağını belirlemelidir. Hata bildirimleri, tamamlanamayan görevler ve kullanıcıların eski yönteme dönmesi bu işaretlerden bazılarıdır. Her değişiklik büyük bir model sorunu olmayabilir; veri veya arayüz kaynaklı sorunlar da olabilir.

Yeni sürümün hangi ölçütle kabul edildiği kaydedilmelidir. Önceki sürümden daha iyi ortalama sonuç almak, önemli bir kullanıcı grubunda gerileme varsa yeterli olmayabilir. Bu nedenle sürüm kararları yalnızca tek sayı üzerinden verilmemelidir. Gerektiğinde önceki çalışma düzenine dönme planı bulunmalıdır.

Müşteri geri bildirimlerini ürün talepleriyle karıştırmayın. Kullanıcı belirli bir özellik isteyebilir, fakat esas ihtiyacı başka biçimde çözülebilir. Talebin arkasındaki iş yeniden sorulmalıdır. Böylece ürün, her müşteriye özel farklı ekranların biriktiği bakımı zor bir yapıya dönüşmez.

Yatırım görüşmelerinde de aynı kanıt disiplini değerlidir. Deneme yapan kullanıcı, düzenli aktif kullanıcı ve ödeme yapan müşteri ayrı gösterilmelidir. Modelin başarısı, ürünün kullanımı ve şirketin geliri farklı aşamalardır. Yatırım hazırlığı rehberi bu ayrımı iş planına taşımak için kullanılabilir.

Sık sorulan sorular

Yapay zekâ girişiminin kendi modelini geliştirmesi şart mı?

Hayır. İş problemi ve rekabet avantajına göre farklı teknik yaklaşımlar değerlendirilebilir. Önemli olan kullanılan bileşenlerin sınırlarını, maliyetini ve ürün kalitesine etkisini anlamaktır. Kendi modeline sahip olmak tek başına müşteri değeri yaratmaz.

İlk müşteri bulunmadan veri toplanmalı mı?

Önce hangi iş için hangi veriye ihtiyaç olduğu tanımlanmalıdır. Kullanım hakkı ve erişim koşulları belirsiz veri üzerine ürün planı kurmak risklidir. Dar bir problemle başlayıp gerekli veriyi kontrollü biçimde değerlendirmek daha uygulanabilir olabilir.

Çok yüksek test puanı satış için yeterli mi?

Hayır. Müşteri sonuçların kendi işinde geçerli olmasını, kullanımın kolaylığını ve toplam maliyetin anlamlı olmasını da değerlendirir. Test puanının nasıl üretildiği, hangi örnekleri kapsadığı ve hangi sınırları olduğu açıklanmalıdır.

Yapay zekâ ürünü için TEKMER başvurusunda ne gösterilmeli?

Problem, hedef kullanıcı, mevcut ürün aşaması, veri durumu ve sıradaki doğrulama ihtiyacı anlatılmalıdır. Henüz olmayan özellikler plan olarak işaretlenmelidir. Çalışan bir örnek varsa sınırlarıyla birlikte sunulabilir; demo ile gerçek müşteri kullanımı birbirine karıştırılmamalıdır.

Müşteri modelin çalışma biçimini anlamak zorunda mı?

Müşterinin bütün teknik ayrıntıları öğrenmesi gerekmez. Ancak sistemin hangi veriye dayandığını, hangi durumlarda hata yapabildiğini ve çıktının nasıl kullanılacağını anlaması gerekir. Ürün açıklamasında günlük iş dili kullanmak önemlidir. Karmaşık bir teknik terim, kullanıcının ne yapacağını açıklamıyorsa yardım sağlamaz. Kısa bir kullanım örneği ve sınır açıklaması çoğu ilk görüşmede daha anlamlıdır.

İlk sürüm için bir kontrol toplantısı nasıl yapılabilir?

Ekip ürün, veri ve müşteri sorumlusunu aynı toplantıda buluşturabilir. Önce tamamlanan iş örnekleri, ardından hatalar ve kullanıcıların takıldığı noktalar incelenir. Her sorun için yeni özellik yazmak yerine neden sorulur. Veri eksikliği, yanlış beklenti, zayıf arayüz ve model hatası ayrı işlere dönüşür. Toplantının sonunda en fazla birkaç öncelik ve bunları değerlendirecek kanıt seçilir. Sonraki toplantıda aynı sorunların sürüp sürmediğine bakılır. Böyle bir düzen, yalnızca daha yeni bir model kullanmanın ürünün bütün sorunlarını çözeceği varsayımını önler. Geliştirme ekibi neyi neden değiştirdiğini, satış ekibi de müşteriye neyi söz verebileceğini daha açık görür. İlk sürümün değeri, her şeyi yapması değil sınırları içinde tutarlı bir işi tamamlamasıdır.