# Yazılım mühendislerinizin yapay zeka sistemleri geliştirmek için öğrenmesi gerekenler.

> Bu saha notunda veridive, yazılım mühendislerinin yapay zeka sistemleri geliştirmek için hangi becerilere ihtiyaç duyduğunu anlatıyor: becerilerin çoğu aynen taşınır; değerlendirme, her çalıştırmada değişebilen çıktı, bilgi erişimi ve veri yönetimi ile inceleme tasarımı ise yenidir. Notta bir beceri tablosu, gerçek bir iş akışında eşli çalışmanın kurslardan neden iyi olduğu ve ekibin hazır olduğunu gösteren işaretler var.

İyi yazılım mühendisleri gerekenlerin çoğunu zaten bilir. Yeni olanlar değerlendirme bakışı, her çalıştırmada değişebilen çıktı, bilgi erişimi ve veri yönetimi ile kararın nerede insanda kalacağına dair muhakemedir. Bunları en hızlı, bunu daha önce yapmış biriyle tek bir iş akışını canlıya alarak öğrenirler.

## Öne çıkanlar

- Bir yapay zeka sisteminin büyük kısmı sıradan yazılımdır; bu yüzden iyi mühendisler gereken becerilerin çoğunu zaten bilir.
- Yeni beceriler şunlardır: değerlendirme, her çalıştırmada değişebilen çıktı, bilgi erişimi ve yetkiler, kararın nerede insanda kalacağının tasarımı.
- Mühendisler en hızlı, kurs biriktirerek değil, bunu daha önce yapmış biriyle gerçek bir iş akışında eşli çalışarak öğrenir.
- Bir ekip; promptlardan önce değerlendirme setini yazdığında, hataları vaka türüne göre açıkladığında ve inceleme adımını tasarladığında hazırdır.

En iyi backend mühendisiniz, bir yapay zeka sistemi geliştirmek için gerekenlerin çoğunu zaten biliyor: entegrasyonlar, veri modelleme, test, gözlemlenebilirlik, nöbet tutmak. İyi mühendisleri zorlayan şey daha küçük ve daha tuhaftır. Bir fonksiyon her çalıştığında farklı bir yanıt döndürür. Test paketi “doğru”nun ne demek olduğunu söyleyemez. Her promptun içinde de bir ürün kararı saklıdır.

Yazılımcılar için yapay zeka becerilerinde eksik olan dört şey vardır: değerlendirme bakışı, her çalıştırmada değişebilen çıktı, bilgi erişimi ve veri yönetimi, kararın nerede insanda kalacağına dair muhakeme. Mühendisler bunları en hızlı, bunu daha önce yapmış birinin yanında gerçek bir iş akışını canlıya alarak öğrenir.

## Sıradan yazılım mühendisliğinden neler aynen taşınır?

İnsanların beklediğinden fazlası. Tipik bir yapay zeka iş akışında model çağrısı, kodun küçük bir parçasıdır. Gerisi sıradan yazılımdır: ERP ya da CRM bağlantıları, kuyruklar ve tekrar denemeler, kimlik doğrulama, bir inceleme ekranı, kayıt tutma, dağıtım. Projelerin genellikle zorlaştığı yer entegrasyon ve yetkilerdir; iyi mühendisler ikisini de zaten bilir.

Alışkanlıklar da taşınır: sürüm kontrolü, kod incelemesi, CI/CD hattındaki otomatik testler, kademeli yayınlar, en az yetki ilkesi, iki kez çalıştırılması güvenli olan işlemler ve bir şey bozulduktan sonra yazılan olay sonrası rapor (postmortem). “Yapay zeka farklı” diyerek bunları bırakan ekipler çabuk pişman olur.

## Gerçekten yeni olan ne?

Her birinin altında eski bir beceri yatan yedi alan:

| Alan | Aynen taşınan | Yeni olan | Nasıl pratik yapılır |
|---|---|---|---|
| Test | Birim ve entegrasyon testleri | Dili puanlayan, sonuçları vaka türüne göre raporlanan değerlendirme setleri | Prompt yazmadan önce süreç sahibiyle bir set kurun |
| Davranış | Deterministik fonksiyonlar | Her çalıştırmada değişebilen çıktı; şemalar ve doğrulama | Tek bir vakayı defalarca çalıştırıp dağılımı ölçün |
| Veri | Şemalar, sorgular, veri hatları | Bilgi erişiminin kalitesi ve sorgu anındaki yetkiler | Doğru pasajın gelip gelmediğini yanıttan ayrı kontrol edin |
| Değişiklik | Sürümler ve geri almalar | Sürümlenen bileşenler olarak promptlar, kaynaklar ve modeller | Her prompt değişikliğini bir değerlendirme çalıştırmasına bağlayın |
| Güvenlik | Girdi doğrulama | Sistemin okuduğu metin üzerinden prompt enjeksiyonu | Değerlendirme setine kötü niyetli vakalar ekleyin |
| Ürün | Gereksinimler ve kullanıcı deneyimi | Bir insanın nerede onaylayacağına karar vermek ve inceleme ekranı | Onay adımını onu kullanacak kişilerle birlikte tasarlayın |
| Maliyet | Altyapı bütçeleri | Kullanım ve inceleme süresinin belirlediği görev başına maliyet | Pilot sırasında vaka başına maliyeti ölçün |

Mühendisleri en çok “Değişiklik” satırı şaşırtır: model sağlayıcı, modeli sizden habersiz değiştirebilir. [LLMOps ile MLOps farkını](https://veridive.com/tr/saha-notlari/llmops-ve-mlops-farki/) anlatan not, bunun operasyon için ne anlama geldiğini ele alıyor.

## Değerlendirme neden temel beceridir?

Çünkü o olmadan kimse bir değişikliğin işe yarayıp yaramadığını söyleyemez. Prompt düzenlemeleri batıl inanca, model seçimi de zevk meselesine döner. Değerlendirme alışkanlığı olan bir mühendis gerçek vakalardan süreç sahibiyle birlikte örneklem alır. Referans yanıtları kendisi yazmaz, işin sahibi olan kişilerden alır. Alanlar için birebir kontroller, metin için kısa puanlama ölçütleri kullanır. Setin bir kısmını ayrı tutar, sonuçları vaka türüne göre raporlar ve her otomatik puanlayıcıyı insanlarla karşılaştırarak kontrol eder.

> Değerlendirme seti yoksa her prompt değişikliği bir tahmindir.

Sonra set, bir test paketi gibi her değişiklikte çalışır. [LLM uygulamalarını test etmeyi](https://veridive.com/tr/saha-notlari/llm-uygulamalarini-test-etmek/) anlatan not, bunun birim ve uçtan uca testlerle nasıl bir araya geldiğini gösteriyor. Değerlendirme başlı başına bir uzmanlık alanıdır da; bazı ekipler onu ayrı bir rol olarak görür.

## Veri ve bilgi erişimi hakkında ne bilmeleri gerekir?

Bir doküman asistanı yanlış yanıt verdiğinde modelden önce bilgi erişimine bakın: çoğu zaman doğru pasaj hiç gelmemiştir. Mühendislerin, belgelerin nasıl parçalara bölündüğünü, dizinlendiğini ve arandığını anlaması gerekir. Anahtar kelime aramasının anlamsal aramanın yanında neden önemini koruduğunu ve yanıtı değerlendirmeden önce doğru pasajın gelip gelmediğinin nasıl ölçüleceğini de bilmeleri gerekir.

Gerçek kullanımda dört şey daha önemlidir. Yetkiler arama çalışırken uygulanmalıdır; böylece kimse kendisinin açamayacağı bir belgeyi görmez. Kaynaklar değişir; bu yüzden dizinin sürümleri ve bir yenileme rutini olmalıdır. Taranmış belgeler, tablolar ve karışık Türkçe-İngilizce metinler dizinlemeden önce özen ister. Kişisel veriler için de veri koruma görevlisiyle (DPO) üzerinde anlaşılmış bir maskeleme, kayıt tutma ve saklama planı gerekir.

## Kurslardan mı, projelerden mi öğrenmeliler?

Kurslar kavramları kazandırır; projeler ise muhakeme. Daha önce böyle bir iş akışını canlıya almış biriyle tek bir gerçek iş akışında eşli çalışmak, bir yığın kurs belgesinden daha çok şey öğretir; çünkü zor kısımlar ancak gerçek veride ve gerçek bir sahiple ortaya çıkar.

Temsili bir vakada şirket içindeki iki mühendis, tedarikçi faturalarından ERP kaydı taslağı hazırlama işinde deneyimli bir ekiple eşli çalışıyor.

1. **Önce değerlendirme.** Borçlar muhasebesi ekibiyle oturur ve daha kimse prompt yazmadan değerlendirme setini süreç sahibiyle birlikte kurarlar.
2. **Geliştirme.** Şema doğrulamalı yapılandırılmış bilgi çıkarımını ve satın alma siparişi sorgusunu geliştirir; inceleme ekranı için tasarımcı ve muhasebecilerle birlikte çalışırlar.
3. **Gölge mod.** Uyuşmazlıkları süreç sahibiyle birlikte okur ve model hatalarını belirsiz kurallardan ayırmayı öğrenirler.
4. **Devir teslim.** İşletim kılavuzunu, gösterge panellerini ve prompt deposunu devralırlar.
5. **İlk olay.** Büyük bir tedarikçi fatura düzenini değiştirir ve o tedarikçide müdahale oranı yükselir. Yeni düzeni değerlendirme setine ekler, bilgi çıkarımını düzeltir, seti yeniden çalıştırır ve canlıya alırlar; kimseyi aramadan.

Asıl mezuniyet beşinci adımdır.

## Ekibin tek başına geliştirmeye hazır olduğu nasıl anlaşılır?

Belgelere değil, davranışa bakın:

- **Değerlendirme setini ilk prompttan önce yazarlar.**
- **Hataları vaka türüne göre açıklarlar,** asla tek bir ortalamayla değil.
- **İnceleme adımını kullanıcılarıyla birlikte tasarlarlar** ve kararın nerede insanda kalacağını savunurlar.
- **Bir prompt değişikliğini kod değişikliği gibi ele alırlar:** sürümlenir, incelenir ve değerlendirilir.
- **Vaka başına maliyeti** ve onu neyin belirlediğini açıklayabilirler.
- **Bir olayı baştan sona yönetmişlerdir:** uyarıdan yazılı olay sonrası rapora kadar.

Varılacak nokta, [devir teslim kontrol listesinde](https://veridive.com/tr/saha-notlari/yapay-zeka-projesi-teslim-listesi/) anlatılan durumdur: ekibiniz bir promptu değiştirebilir, değerlendirme setini yeniden çalıştırabilir ve tedarikçiyi aramadan bir modeli geri alabilir. Ekipte başka kimlerin olması gerektiği için [yapay zeka proje ekibi rollerine](https://veridive.com/tr/saha-notlari/yapay-zeka-proje-ekibi-rolleri/) bakın.

## Canlı bir iş akışında nasıl öğrenilir?

Sahibi belli bir iş akışı seçin ve mühendislerinizi devir teslimde değil, ilk günden o işte görevlendirin. En doğrudan yol, [özel yapay zeka yazılımı](https://veridive.com/tr/hizmetler/ozel-yapay-zeka-yazilimi/) hizmetimiz kapsamındaki bir Pilottan Canlıya çalışması sırasında eşli çalışmaktır. [Yapay zeka eğitimi ve dönüşüm](https://veridive.com/tr/hizmetler/yapay-zeka-egitimi-ve-donusum/) hizmetimiz de çevrelerindeki herkes için role özel eğitimi kapsar.

## Sık sorulan sorular

### Yazılım mühendisleri hangi yapay zeka becerilerine ihtiyaç duyar?

Çoğunlukla zaten bildikleri becerilere: entegrasyon, veri modelleme, test, gözlemlenebilirlik ve olay yönetimi. Yeni olanlar şunlardır: gerçek vakalardan değerlendirme setleri kurmak, her çalıştırmada değişebilen çıktıyı yönetmek, bilgi erişimi ve yetkilere uyan arama, promptları ve modelleri sürümlenen bileşenler olarak ele almak, prompt enjeksiyonuna karşı savunma ve bir insanın incelediği ve karar verdiği adımı tasarlamak.

### Mühendisler yapay zekayı kurslardan mı, projelerden mi öğrenmeli?

İkisinin de yeri var ama en önemlisini projeler öğretir. Kurslar kavramları kazandırır; bunu daha önce yapmış biriyle gerçek bir iş akışını canlıya almak ise değerlendirme, hata türleri ve kararın nerede insanda kalacağı konusunda muhakeme kazandırır. Sahibi belli ve verisi gerçek bir iş akışında, değerlendirme setinden canlıya alındıktan sonraki ilk olaya kadar eşli çalışın.

### Bir mühendislik ekibinin yapay zeka sistemlerini tek başına geliştirmeye hazır olduğu nasıl anlaşılır?

Belgelere değil, davranışa bakın. Hazır bir ekip değerlendirme setini ilk prompttan önce yazar, hataları bir ortalama söyleyerek değil vaka türüne göre açıklar, inceleme adımını kullanıcılarıyla birlikte tasarlar, prompt değişikliklerini kod değişikliği gibi ele alır ve bir olayı tek başına yönetmiştir: fark etmiş, düzeltmiş ya da geri almış, değerlendirme setini yeniden çalıştırmış ve raporunu yazmıştır.