Yazılım mühendislerinizin yapay zeka sistemleri geliştirmek için öğrenmesi gerekenler.
İ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.
veridive5 dk okuma
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ı 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 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.
- Önce değerlendirme. Borçlar muhasebesi ekibiyle oturur ve daha kimse prompt yazmadan değerlendirme setini süreç sahibiyle birlikte kurarlar.
- 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.
- Gölge mod. Uyuşmazlıkları süreç sahibiyle birlikte okur ve model hatalarını belirsiz kurallardan ayırmayı öğrenirler.
- Devir teslim. İşletim kılavuzunu, gösterge panellerini ve prompt deposunu devralırlar.
- İ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 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 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ı 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 hizmetimiz de çevrelerindeki herkes için role özel eğitimi kapsar.
Bu notu bir yapay zeka asistanına sorun