Prompttan Ürüne: LLM'leri Gerçek Uygulamalara Dönüştürmek

Bir oyun alanında (playground) işe yarayan bir prompt bir demodur, ürün değil. İkisi arasındaki boşluk, çoğu yapay zeka projesinin sessizce öldüğü yerdir. Gerçek kullanıcılara dayanabilen LLM uygulamaları geliştirmek, demoların ima ettiği gibi akıllı prompt yazımıyla değil, çok daha fazla sıradan yazılım disipliniyle ilgilidir. Bu boşluğu gerçekten neyin kapattığı konusunda fikir sahibi olacak kadar çoğunu sevk ettik — Youp, MadaiOps ve şimdi Linea. Hiçbiri göz alıcı değil.

Tuzak, ilk sürümün bitmiş gibi hissettirmesidir. Akıllı bir prompt yapıştırırsınız, model etkileyici bir şey döndürür ve onu bir arayüzle sarmalayıp lansman ilan etmek cazip gelir. Sonra gerçek kullanıcılar hiç hayal etmediğiniz girdilerle gelir, model kendinden emin bir şekilde yanlış bir şey yapar ve düzeltmenizin işleri daha iyi mi yoksa daha kötü mü yaptığını anlamanın hiçbir yolu olmadığını keşfedersiniz. Bu yazı, o etkileyici demoyu üretim ortamında çalıştırabileceğiniz ve gece rahat uyuyabileceğiniz bir şeye dönüştüren iskele hakkında.

Promptlarla değil, değerlendirmelerle başlayın

Erken aşamada kurabileceğiniz en yüksek kaldıraçlı şey bir değerlendirme (eval) setidir. Bir kıyaslama (benchmark) değil, bir sıralama tablosu (leaderboard) değil — iyi bir çıktının nasıl göründüğüyle eşleştirilmiş gerçek girdilerden oluşan bir klasör. Yirmi örnek, sıfırdan iyidir; özenle seçilmiş elli örnek, gelişigüzel toplanmış binden iyidir.

Nedeni basit. Değerlendirmeleriniz olduğunda, prompt mühendisliği "sezgi" olmaktan çıkar. Bir satır değiştirirsiniz, seti çalıştırırsınız, sayının değişimini izlersiniz. Onlarsız her ince ayar bir batıl inançtır. Ekiplerin bir promptu iyileştirmek için bir hafta harcadığını, ardından aylar önce çözdükleri durumlarda gerilediğini izledik, çünkü bakmadıkları durumları ölçen hiçbir şey yoktu.

Kesin olarak savunduğumuz birkaç görüş:

Kelimelere göre değil, sonuçlara göre puanlayın. Yapılandırılmış herhangi bir şey için — çıkarım, sınıflandırma, yönlendirme — dizge benzerliği üzerinde değil, ayrıştırılmış sonuç üzerinde doğrulama yapın. Açık uçlu metinler için, sıkı bir puanlama ölçütü olan bir LLM-hakem (LLM-as-judge) idaredir, ama hakemi önce bir avuç insan etiketine karşı doğrulayın, yoksa yalnızca bir modelin zevkini ölçüyor olursunuz.
Bir regresyon dosyası tutun. Her üretim hatası kalıcı bir test durumu olur. Değerlendirme setinizin dürüst kalmasının yolu budur — gerçekliğin ittiği yönlerde tam olarak büyür.
Değerlendirmelerinizi promptlarınızla birlikte sürümleyin. Değerlendirme seti olmayan bir prompt, test edilmemiş bir kod değişikliğidir.

Bu makaleden tek bir şey inşa edecekseniz, bunu inşa edin. Bundan sonraki her şey şu soruya cevap verebilmeye bağlı: bu, işleri daha iyi mi yaptı?

Koruma katmanları özürlerden daha ucuzdur

Modeller, sıradan yazılımların yapmadığı şekillerde başarısız olur. Var olmayan bir API uydururlar, bir kullanıcının yanlış öncülüyle hemfikir olurlar veya halüsinasyon gördükleri bir alanla geçerli görünen JSON üretirler. Koruma katmanları (guardrails), bunu bir kullanıcıya veya daha kötüsü bir yürütme adımına ulaşmadan önce yakalayan katmandır.

Üç konumda düşünün.

Girdi koruma katmanları, model çalışmadan önce reddeder veya temizler: prompt enjeksiyonu taraması, PII (kişisel veri) maskeleme, konu dışı filtreleme.
Çıktı koruma katmanları, geri geleni doğrular: şema doğrulaması, atıf-dayanak kontrolleri, politika filtreleri.
Eylem koruma katmanları, model ile yan etkisi olan herhangi bir şey arasında durur.

O üçüncüsü gerçek riskin yaşadığı yerdir. İş akışı otomasyonu ajanlarımız olan Linea'da model eylemler önerebilir — bir API çağırmak, bir kaydı taşımak, bir mesaj göndermek. Öneri ve yürütme kasıtlı olarak ayrı adımlardır. Her sonuç doğuran eylem, herhangi bir şey çalışmadan önce tipli bir sözleşmeden ve bir politika kontrolünden geçer; yıkıcı veya geri alınamaz eylemler ise açık bir onay kapısı gerektirir. Yanlış bir şey öneren bir ajan, üzerinde yineleyerek çalışabileceğiniz bir UX (kullanıcı deneyimi) sorunudur. Yanlış bir şey yapan bir ajan ise bir olaydır (incident). Bu iki başarısızlık modunu sert bir sınırın karşıt taraflarında tutun.

Görüşlü versiyon: yapılandırılmış çıktıyı bir şemaya karşı doğrulayın ve modelin tutarlı olacağına güvenmek yerine hata durumunda yeniden deneyin. Ve bir modelin ham çıktısının, geri alınamaz bir eylemi tetikleyen şey olmasına asla izin vermeyin. Araya deterministik bir kontrol koyun, her zaman.

Gecikme ve maliyeti özellikler gibi bütçeleyin

Gecikme ve maliyet, sonunda ölçtüğünüz şeyler değildir. Bunlar başından itibaren tasarımını yaptığınız kısıtlardır, çünkü yalnızca faturayı değil, mimariyi değiştirirler.

Kullanıcıya dönük her eylem için açık bütçeler belirleyin: bir p95 gecikme hedefi ve çağrı başına bir maliyet tavanı. Bunlar bir kez yazıya döküldüğünde, tasarım kararları kolaylaşır. Tekrar tekrar başvurduğumuz bazı örüntüler:

Modeli adım başına doğru boyutlandırın. Çoğu ardışık düzenin (pipeline) gerçekten sınır (frontier) modele ihtiyaç duyan bir veya iki adımı ve daha küçük, daha hızlı bir modelin gayet iyi hallettiği birkaç adımı vardır. Basit sınıflandırmayı ucuz bir modele yönlendirmek ve pahalı olanı zor akıl yürütme adımı için saklamak, mevcut en yüksek getirili optimizasyondur ve genellikle gecikmeyi de iyileştirir.
İlk token'ı akışla (stream) gönderin. Sohbet niteliğindeki herhangi bir şey için, algılanan gecikmeye ilk token'a kadar geçen süre hâkimdir. Dört saniye süren akışlı bir yanıt, iki saniye süren engelleyici bir yanıttan daha iyi hissettirir.
Agresif önbellek kullanın. Kararlı sistem bağlamında prompt önbelleği, tekrarlanan girdilerde sıradan sonuç önbelleği. Üretim trafiğinin anlamlı bir kısmı neredeyse birebir kopyadır.

Aklınızda tutmanız gereken ödünleşim: daha büyük modeller mühendislik çabanızı azaltır ama marjinal maliyetinizi ve gecikmenizi kalıcı olarak yükseltir. Daha ucuz modeller işi size yükler — daha fazla prompt özeni, daha fazla koruma katmanı, daha fazla değerlendirme — ama bu iş, kalıcı bir tasarrufa karşılık tek seferlik bir maliyettir. Hacmi olan herhangi bir şey için, mühendisliğe harcayın.

İnsanları bilinçli olarak döngüde tutun

"İnsan denetimi (human in the loop)" o kadar sık söyleniyor ki artık bir anlam ifade etmiyor. İyi yapıldığında, yapay zeka başarısız olduğunda başvurulan bir yedek değildir — tasarlanmış bir iş bölümüdür. Soru bir insanı dâhil edip etmemek değil, insanın yargısının eklediği gecikmeden daha değerli olduğu yerin neresi olduğudur.

Bize en iyi hizmet eden örüntü güven kapılı yükseltme (confidence-gated escalation). Sistem, kendinden emin olduğu çoğunluğu otomatik olarak halleder ve emin olmadığı azınlığı, modelin akıl yürütmesi ekli olarak bir kişiye yönlendirir; böylece insan dakikalar içinde değil, saniyeler içinde karar verir. MadaiOps'ta normal parametreler içindeki sipariş operasyonları akıp geçer; anormal olan herhangi bir şey ise sessizce yürütülmek yerine, bağlamıyla birlikte bir operatöre yüzeye çıkar. İnceleyen kişi makineye dadılık etmiyor. Dikkatini yalnızca kıt ve değerli olduğu yere harcıyor.

Bir kural daha: insanın düzeltmelerini ölçün (instrument) ve bunları değerlendirme setinize ve promptlarınıza geri besleyin. İnsanlarından öğrenmeyen bir insan denetimli sistem, aynı iş için iki kez ödeme yapıyordur.

Neyin otomatikleştirilmeyeceğini bilin

Bu disiplindeki en zor yargı, kendini tutmaktır. Her görev bir modele devredilmemeli ve olgunluk, hangilerini kendi haline bırakacağını bilmektir.

Kabaca testimiz: bir hatanın maliyeti düşük olduğunda veya hata kolayca tespit edilip geri alınabildiğinde otomatikleştirin. Taslak yazma, özetleme, çıkarım, sınıflandırma, yönlendirme — iyi adaylar. Yanlış bir taslak düzenlenir; yanlış bir özet okunurken yakalanır. Hataların pahalı, tespit edilmesi zor veya geri alınamaz olduğu yerlerde çok daha temkinli olun: para hareket ettiren, geri döndürülemez bir iletişim gönderen ya da yasal veya tıbbi bir karar veren herhangi bir şey. Orada model, sürücü koltuğunda değil, yardımcı bir rolde olmalı — seçenekleri yüzeye çıkararak, inceleme için taslak hazırlayarak.

Savunduğumuz çizgi: modelin yanlış yaptığını nasıl yakalayacağınızı tarif edemiyorsanız, o adımı otomatikleştirmeye hazır değilsiniz. Başarısızlığı tespit edebilme yeteneği, doğruluktan daha fazla, asıl önkoşuldur. Tamamen doğrulayabileceğiniz %95 doğrulukta bir adım, doğrulayamadığınız %99 doğrulukta bir adımdan sevk edilmesi daha güvenli olandır.

İşin şekli

Bir promptu ürüne dönüştürmek çoğunlukla göz alıcı olmayan kısımdır: ölçebilmeniz için değerlendirmeler, hataların sınırlı kalması için koruma katmanları, hızlı ve uygun fiyatlı kalması için bütçeler, yargının önemli olduğu yerlere yerleştirilmiş insanlar ve bazı şeyleri otomatikleştirmeden bırakma disiplini. Model, sistemin belki yüzde yirmisidir. Diğer yüzde seksen, onun ara sıra parlayan zekâsına güvenle bel bağlanmasını sağlayan mühendisliktir.

İyi haber şu ki bu, tanıdık bir iş. Her türden iyi yazılımı yapan aynı içgüdüleri ödüllendirir: değiştirmeden önce ölçün, patlama yarıçapınızı sınırlayın, kullanıcılarınızın zamanına saygı gösterin. Model yeni. Zanaat değil.