OpenAI'da Sahada Görevli Mühendis olmak ne anlama geliyor?
Neler yapıyoruz, nasıl çalışıyoruz ve somut etki yaratmak için kurumların en zor sorunlarını nasıl çözüyoruz?
Yazan: Colin Jarvis, OpenAI Sahada Görevli Mühendislik Ekibi Lideri
Codex çıktığında ekipten biri bana şunu sordu: “Son birkaç ayımızı geliştirmeye ayırdığımız kullanım senaryolarını Codex tek seferde çözebilir hâle geldiğinde biz ne yapacağız?”
Bu soru, OpenAI'da Sahada Görevli Mühendis olmanın ne anlama geldiğinin özüne iniyor. Müşterilerimizin en zor sorunlarını anlamak ve güvenebilecekleri çözümler geliştirmek için onlarla yan yana çalışıyoruz. Öğrendiklerimiz ürünlerimizin şekillenmesine yardımcı oluyor ve Araştırma ekibine çözebileceği somut sorunlar sunuyor.
İlerleme dediğimiz şey bu. Birkaç ayda bir kendimize duyulan ihtiyacı ortadan kaldırıyorsak, Sahada Görevli Mühendis ekibimiz işini yapıyor demektir.
Ekibi 2025'in başlarında, modellerin yapabiliyor göründükleriyle insanların işlerini yapmak için güvenle kullanabildikleri arasındaki mesafeyi, yani “uygulamaya geçiş açığı” dediğimiz şeyi kapatmak için kurdum.
Model yetenekleri, bunları kullanıma sunmak için gereken sistem ve süreçlerden daha hızlı gelişti. Bazen eksik parça bir ürün oluyor. Bazen de bir model, kıyaslama testinde iyi performans gösterse de gerçek hayattaki değişkenler ve kısıtlar altında gereken işi yapamıyor.
Müşterilerimizin en zor sorunlarına odaklanıyoruz. Modellerimiz bugün gereken işi yapabiliyorsa, çözümü tekrarlanabilir hâle getirmek için Ürün ekibi ve müşterimizle çalışıyoruz. Yetersiz kaldıkları durumlarda ise eksikleri belirlemek ve iyileştirmeler yapmak için müşterilerimiz ve Araştırma ekibiyle birlikte çalışıyoruz. Amacımız, her çalışmanın bir sonraki müşteriye daha iyi bir başlangıç noktası bırakması. Temel yetenekleri, müşterilerimizin bir dahaki sefere bu tür sorunları çözmek için Sahada Görevli Mühendislere ihtiyaç duymayacağı seviyeye çıkarırsak işimizi iyi yapmışız demektir.
200 yıllık bir tarım şirketi olan John Deere'in çözmesi gereken sorun, çiftçilere kişiselleştirilmiş tavsiyeleri geniş ölçekte nasıl sunabileceğiydi.
Şirketin hassas yabancı ot kontrol teknolojisi See & Spray bunun bir örneği. Bu teknoloji, kameralar ve makine öğrenimiyle yabancı otları tespit edip tüm tarlayı ilaçlamak yerine yalnızca bu otları ilaçlayarak kimyasal kullanımını %70'e kadar azaltıyor.
Ancak bu faydaların elde edilmesi, çiftçilerin teknolojiyi nasıl yapılandıracaklarını, sezonlarını nasıl planlayacaklarını ve koşullar değiştikçe uygulamalarını nasıl uyarlayacaklarını bilmelerine bağlı.
John Deere, bu desteği kişiselleştirilebilir ve ölçeklenebilir hâle getirmek için OpenAI API'lerini kullanıma aldı.
Yapay zekâ, çiftçilerin sorularını doğal dille yanıtlayabiliyor, ihtiyaçlarına özel kurulum rehberliği ve öneriler sunabiliyor, ekipmanın tam kapasiteyle çalışmadığı durumları belirleyebiliyor ve çiftçilerin teknolojiden elde ettikleri faydayı anlamalarına yardımcı olabiliyor.
Potansiyel, tek bir etkileşimin çok ötesine uzanıyor: Müşteri yolculuğu boyunca ihtiyaca uygun rehberlik sunarak çiftçilerin ekipmanlarından daha iyi yararlanmasına yardımcı olmak, verimliliği ve sürdürülebilirliği artırmak.
OpenAI'ın Sahada Görevli Mühendislerinin çözmeye çalıştığı sorunlar tam da bu türden: Kuruluşların yapay zekâ yeteneklerini, gerçek dünyanın karmaşık koşullarında somut değer sağlayan sistemlere dönüştürmesine yardımcı olmak.
Ancak sorunlar çoğu zaman belirsizliklerle dolu; referans alınabilecek kesin bir doğruluk ölçütü olmayabiliyor ve izlenecek hazır bir yol haritası bulunmuyor. Herkes daha önce var olmayan bir şey yapmak istiyor. Ama bunun için gerekenleri yapmaya daha az kişi istekli.
“Yeterince iyi” sayılan düzeyin çıtasını yükseltirken yetenekli Sahada Görevli Mühendisler bulmak, sürekli deneme ve uygulama gerektirdi.
Sahada Görevli Mühendis ekibinin her toplantısının başında, tek bir temel değerin yazılı olduğu bir slayt açarım: “Önce hedeflenen sonucu belirleyin, başarmak için ne gerekiyorsa yapın, ardından ölçeklendirin.”
Etkileyici bir demo, gerçek dünyada çalışıp çalışmadığı sorulmadan önce epey yol alabilir.
Bizim işimiz, müşterinin sorununu canlı kullanımda arkasında durabileceğimiz bir standartta çözmek.
2025'in ortalarında yaklaşık 15 Sahada Görevli Mühendisimiz, yarı iletken sektöründeki büyük bir müşterimizle 10'dan fazla kullanım senaryosu üzerinde çalışıyordu. Hedef, şu alanları kapsayacak şekilde doğrulama sürecini yapay zekâ temelinde yeniden kurmaktı:
Hedefe yönelik test üretimi
Kök neden analizi ve hata ayıklama
Bir mimari tasarım asistanı
Bu sektörde doğrulama, bir proje için harcanan emeğin yaklaşık %70'ini oluşturabiliyor. Muazzam bir potansiyel vardı ve işe başlanabilecek pek çok alan bulunuyordu.
Bazı Sahada Görevli Mühendisler, OpenAI'a yalnızca birkaç gün önce katılmıştı ve yarı iletken sektöründe hiç çalışmamıştı. Müşterinin doğrulama ekibine dahil oldular, boş zamanlarında çip tasarımı üzerine çalıştılar ve yapay zekânın işe yarar testler üretip çip arızalarını doğru teşhis edip edemediğini ölçmek için mühendislerle birlikte değerlendirmeler hazırladılar.
Bu öğrenme sürecine paralel olarak her kullanım senaryosu için özel düzenekler oluşturduk. İlk 3-6 ay içinde hepsi canlıya alındı ve ilk kullanıcılar tarafından kullanılmaya başlandı. Emeğimizin karşılığını rakamlarda gördük:
Yapay zekâ tabanlı, hedefe yönelik test üretimiyle yaklaşık %48 zaman tasarrufu.
Çekirdek optimizasyonuyla medyan performansta %22 artış.
Haftalar süren hata ayıklama işlerinin saatlere inmesi
Tüm bu sonuçları sunduğumuzda, Donanımdan Sorumlu Üst Yönetici şöyle sordu: “Buraya gelmeden önce çip tasarımcısı olarak mı çalışıyordunuz?”
Sahada Görevli Mühendislerimizin sektörü ilk günden tanıması gerekmiyor, ancak öğrenmek onların sorumluluğu.
Kodlama asistanları yazılım geliştirmeyi hızlandırdıkça, müşterinin işini anlamak daha da önem kazanıyor. Ekiplerimizi, farklı alanlarda çalışabilen kişilerle alan uzmanlarını bir araya getirerek kuruyoruz.
Sağlıklı kararlar verecek kadar bilgiye ve mevcut düzene ilişkin varsayımları sorgulayacak kadar meraka ihtiyacınız var.
Örneğin yaşam bilimlerinde, Sahada Görevli Mühendislerimizin bilimsel birikimi; hedef doğrulama ve önceliklendirme, gen ifadesi analizi ve kimyasal sentez yollarının yeniden oluşturulması gibi klinik öncesi ilaç keşfi çalışmalarını yürüten araştırmacıların güvenini kazanmalarına yardımcı oluyor. Bu uzmanlık, söz konusu iş akışlarının nasıl iyileştirilebileceğine dair bilgiye dayalı görüşlerle katkıda bulunmalarını sağlıyor.
Bu iş akışlarının değer sağlayabileceğini göstermiştik, ancak her birini başka bir ekibe yaygınlaştırmak hâlâ çok fazla özel entegrasyon gerektiriyordu. Bir sonraki zorluk, elde edilen sonuçları korurken yazılımın devreye alınmasını ve bakımını kolaylaştırmaktı.
O zamana kadar Codex'in yetenekleri gelişmişti. Bir Sahada Görevli Mühendis, uygulamasını Codex etrafında yeniden kurmayı denedi. Ardından ekiple birlikte çalışarak kullanım senaryolarını, merkezinde Codex'in yer aldığı ortak bir düzeneğe taşıdı.
Özel uygulamalar, Codex'in ortak temel bileşenleri üzerine kurulu eklentilere ve becerilere dönüştü. Codex aynı zamanda arayüz hâline geldi. Böylece her kullanım senaryosu için ayrı ayrı yazdığımız terminal kullanıcı arayüzlerini ve komut satırı arayüzlerini kullanımdan kaldırabildik.
Her projedeki özel kodun yaklaşık %90'ını kaldırabildik. Bu, iş akışlarını geliştirme, sürdürme ve ölçeklendirme biçimimizi değiştirdi:
Codex'te merkezi olarak yapılan iyileştirmelerden yararlanarak her kullanım senaryosu için gereken bağlantı kodunu azaltabildik
Temel işlevler, beceri ve eklenti paketlerine dönüştürüldü. Böylece ekiplerin bunları birbiriyle paylaşması ve Yapay Zekâ Mükemmeliyet Merkezi'nin merkezi olarak kontrol etmesi kolaylaştı. Bu sayede çözümü bir ekipten diğerine yaygınlaştırmak; yeni bağlayıcılar/MCP sunucuları eklemek, yeni değerlendirmeler oluşturmak (bunun için de bir becerimiz vardı) ve kullanıma başlamak kadar basit olabiliyordu.
Ağustos 2026'daki bir örnekte, ilk devreye alma iki ay sürdü. Çözümü ikinci bir ekibe yaygınlaştırmak ise bir gün aldı. Ölçek büyüdükçe sonraki ekipler daha hızlı kullanıma geçti. Bu eğilim devam etti: Ağustos 2026'daki bir kullanım senaryosunda ilk devreye alma 2 ay sürerken, ikinci ekip için yalnızca 1 gün gerekti.
Kendimize duyulan ihtiyacı ortadan kaldırmanın bir yolu bu. Canlı kullanıma geçmek için yaptığımız çalışmalar, neyin önemli olduğunu ortaya koymuştu. Temeldeki ürün geliştikçe, özel olarak geliştirdiğimiz çözümün büyük bölümünü onunla değiştirebildik ve sağladığı değeri koruyabildik.
İşte bu yüzden sıralama önemli. LLM'ler hızlı geliştirme yapmamızı sağlıyor. Bu hızı, kullanıcılara değerli bir şey sunmak, pratikte neyin işe yaradığını öğrenmek ve ardından işe yarayanı ölçeklendirmek için kullanın.
Aynı ilke tüm müşteri çalışmalarımız için geçerli.
Kurumsal ses ve sohbet temsilcileri için ürünümüz olan OpenAI Presence, gerçek müşteri dağıtımlarından doğdu. Çalışma Swarm(yeni bir pencerede açılır) ile başladı ve Agents API ile gelişti. Bugün bir müşteri artık çağrılarının yarısından fazlasını yapay zeka ile gerçekleştiriyor.
Bu dağıtımları üretime almak bize hangi sorunların özel bir çözüme ihtiyaç duyduğunu ve diğer ekiplerin hangi yapı taşlarını kullanabileceğini öğretti. Bu yapı taşlarını Presence'a getirdik ve geliştiricilerin temel altyapıyı yeniden inşa etmeden yasal düzenlemelere tabi iş akışlarını otomatikleştirmelerini kolaylaştırdık. Her dağıtım ürünün şekillenmesine yardımcı oldu ve bir sonraki müşteriye daha iyi bir başlangıç noktası sağladı.
OpenAI'ın Sahada Görevli Mühendisleri ve araştırmacıları, Thrive Holdings ile Crete bünyesindeki muhasebe firmaları için Tax AI sistemini oluşturmak üzere mühendisler ve muhasebecilerle birlikte çalıştılar. Pilot çalışması sırasında, Tax AI 7.000 vergi beyannamesi işledi ve işlem kapasitesi yaklaşık% 50 artırdı.
En zor zorluklardan biri, %90 hassasiyet ve geri çağırmaya ulaşmak için altı haftalık mühendislik ve uygulayıcı incelemesi gerektiren kira gelirlerine ilişkin vergi beyannamelerinin hazırlanmasını otomatikleştirmekti. Çalışma, Tax AI sistemini diğer karmaşık vergi beyannamesi eklerine genişletmeyi kolaylaştıran yeniden kullanılabilir modeller yarattı.
Ekipler şimdi aynı yaklaşımı muhasebe, denetim ve BT desteğine uyguluyor; uygulayıcı geri bildirimleri ve gerçek dünya kullanımı yoluyla gelişen sistemler oluşturuyor.
Bazen daha iyi bir ürün, kurduğumuz sistemi sadeleştirmemizi sağlar. Ancak bazen modelin kendisi henüz gereken işi yapamaz.
Yalnızca bugünkü modellerin zaten mümkün kıldığı şeyleri geliştirirsek, Araştırma ekibinin sırada gidermesi gereken yetenek eksiklerini ortaya çıkaramayız. Bu nedenle önemli çalışmalarımızın çoğu bu sınırlarda başlıyor; müşteri, Sahada Görevli Mühendis ekibi ve Araştırma ekibi bu sınırları birlikte aşma kararlılığıyla hareket ediyor.
Telekomünikasyon sektöründeki büyük bir müşterimizle bir müşteri hizmetleri platformu geliştirmiştik. Müşterimiz bu platformu sesli görüşmeleri de kapsayacak şekilde genişletmek istiyordu.
Müşteri hizmetleri taleplerinin yaklaşık %90'ı sesli görüşmelerden oluşuyordu. Bu talepleri müşteri temsilcisine aktarmadan çözmek, yazılı sohbete kıyasla daha maliyetliydi. Ayrıca aksanları anlama, ses tonu, gecikme ve doğruluk açısından canlı kullanım standartlarına ulaşmak, bir dizi yeni teknik zorluk getiriyordu. Bunu başarmak, müşterimizin işinde önemli bir fark yaratacaktı.
Kapsam belirleme aşamasında modelimiz, canlı kullanımda bu işi yapıp yapamayacağını ölçmek için kullandığımız temel değerlendirmelerde yaklaşık %60 başarı gösteriyordu. Modelin yeteneklerinin sınırına ulaşmıştık. Müşteri hizmetleri senaryolarında fonksiyon çağrısı ve talimatları izleme yeteneklerinin geliştirilmesi gerekiyordu.
Bunu müşterimize açıkladık ve Araştırma ekibini çalışmaya dahil ettik. Sahada Görevli Mühendis ekibi, platformu oluşturmak ve modelin neler yapması gerektiğini belirlemek için müşteriyle birlikte çalıştı. Araştırma ekibi, modelin yeteneklerindeki eksikleri gidermeye odaklandı. Modelin art arda gelen sürümleri sayesinde ilerlemeyi müşterinin gereksinimlerine göre test edebildik.
Altı ay içinde temel değerlendirmelerdeki başarı yaklaşık %60'tan %80'e, ardından %90'ın üzerine çıkarak canlı kullanım için gereken seviyeye ulaştı.
Ortaya çıkan ses modeli bugün hem bu müşterinin uygulamasına hem müşteriye özel diğer müşteri hizmetleri uygulamalarına hem de Presence üzerinden yönetilen uygulamalara güç veriyor. Bir müşterinin işinde karşılaşılan sorun, başka pek çok müşteriye de fayda sağlayabilecek iyileştirmelerin belirlenmesine yardımcı oldu.
Her katkı önemliydi. Müşteri, modelin henüz çözemediği bir sorun üzerinde çalışmayı taahhüt etti. Sahada Görevli Mühendis ekibi; sorunu tanımlayacak, platformu kuracak ve çalışmayı baştan sona yürütecek kadar sürecin içinde kaldı. Araştırma ekibi, temeldeki model yeteneklerini geliştirdi.
Kendimize duyulan ihtiyacı ortadan kaldırmanın diğer yolu da bu: Bugünkü modellerin çözemediği bir sorunu, gelecekteki modellerin sunabileceği bir yeteneğe dönüştürmeye yardımcı olmak. Çalışmalarımızın getirisi, tek bir müşteriyle geçirdiğimiz saatlerin ötesine uzanıyor.
OpenAI'a, yapay zekânın insanların günlük işlerinde fayda sağlamasına yardımcı olmak için katıldım. Ekibimize hâlâ bu amaç yön veriyor. Ekibe sık sık, LLM geliştirmede çoğu zaman Occam'ın Usturası ilkesinin geçerli olduğunu söylerim: En basit çözüm, en iyi çözümdür. İleri araştırmalarıyla tanınan bir şirkette ve abartılı söylemlerin gölge düşürdüğü bir sektörde, sahada çalışan insanların güvenebileceği, istikrarlı biçimde çalışan çözümler üretmek istiyoruz.
Amaç, her müşteri çalışmasının bir sonrakini iyileştirmesi: Daha kolay devreye alınan bir ürün, daha zor bir görevi yerine getirebilen bir model ya da bir sonraki müşteri için daha az özel geliştirme ihtiyacı.
Çözmek istediğiniz zor bir sorun varsa sizinle çalışmak isteriz. Bu sorunların çözümüne katkıda bulunmak istiyorsanız aramıza katılmanızdan mutluluk duyarız.
Peki, aylarca uğraşıp geliştirdiğimiz çözümlerin yaptığı işi Codex yapabildiğinde biz ne yapacağız?
Gidip daha zor bir sorun bulacağız.
