Asıl İş Yayına Alındıktan Sonra Başlar

Geleneksel yazılımın rahatlatıcı bir özelliği vardır: yarın da bugün yaptığı şeyi yapar. Bir LLM sistemi bunu yapmaz. Arkasındaki model, sizin haberiniz olmadan sağlayıcı tarafından güncellenebilir. Getirdiği belgeler, iş etrafında değiştikçe eskir. Kullanıcıların sorduğu sorular, aracın neyde iyi olduğunu öğrenip neyde kötü olduğunu sormayı bıraktıkça kayar. Ve sistemin kendisi cümle düzeyinde belirlenimsizdir, dolayısıyla bir testin karşısına koyabileceği sabit bir doğru çıktı kavramı doğrudan mevcut değildir. Bu özelliklerin her biri, sıradan izlemenin üzerine kurulduğu bir varsayımı kırar. Bu nedenle klasik izleme araçları bir LLM sisteminde yeşil gösterge verirken kalitenin sessizce düşmesine hiçbir engel oluşturmaz.

Sonuç, defalarca gördüğümüz bir hata örüntüsüdür. Ekip beğenilen bir asistanı yayına alır. Altı hafta boyunca çalışır. Sonra kalite aşınır; öyle yavaş aşınır ki kimse değişimin hangi gün olduğunu söyleyemez. Şikayetlerde karşılık gelen bir artış olmadan kullanım düşer, çünkü bir araca olan güvenini kaybeden kullanıcılar talep kaydı açmak yerine sessizce kullanmayı bırakır. Sonunda biri ne olduğunu sorduğunda ortada verilecek bir cevap yoktur, çünkü bu ayın davranışını yayın ayının davranışıyla karşılaştırmayı mümkün kılacak hiçbir şey kaydedilmemiştir. Sistem yayına alınmış ve ardından operasyonel anlamda terk edilmiştir. Bu sessiz aşınma, en pahalı hata biçimidir.

Yapay zeka için ikinci gün disiplini, genellikle farklı kişiler tarafından kurulan iki şeyin bileşimidir. Gözlemlenebilirlik size sistemin ne yaptığını söyler: her istek, girdileri, getirdiği belgeler, maliyeti, gecikmesi, sonucu. Değerlendirme ise yaptığı şeyin iyi olup olmadığını, sizin kontrol ettiğiniz sabit bir vaka kümesi üzerinde söyler. İkisi de tek başına yeterli değildir. Değerlendirmesiz gözlemlenebilirlik size trafik ve token sayılarıyla dolu, önemli olan tek soruyu cevaplayamayan panolar verir. Gözlemlenebilirliksiz değerlendirme ise, kullanıcılarınızın gerçekte sorduklarına artık benzemeyebilecek bir test kümesinde temiz bir puan verir. İkisini birlikte kurmak, ikisini ayrı ayrı kurmaktan hem daha ucuz hem daha faydalıdır.

Bu yazı ikisini birbirine bağlamak ve dürüst tutmakla ilgili. Elinizde bir değerlendirme kümesi olduğunu ya da kurmakta olduğunuzu varsayıyor ve RAG değerlendirme metrikleri yazısında ele alınan metrik tanımlarını bilinçli olarak tekrarlamıyor. Son bölüm operasyonel kanıtı düzenlemeye bağlıyor, çünkü bu disiplinin ürettiği log kayıtları, değerlendirme kayıtları ve insan gözetimi izleri, AB Yapay Zeka Yasası'nın teknik dokümantasyon ve piyasaya arz sonrası izleme beklentilerine büyük ölçüde denk düşüyor ve Türk veri koruma mevzuatı altındaki hesap verebilirliği de destekliyor. Yani buradaki mühendislik çalışması yalnızca kalite için değil aynı zamanda denetlenebilirlik için de yapılır ve bu iki gerekçe aynı altyapıda buluşur.

Doğrunun Birimi İzdir (trace)

Bir yapay zeka sisteminde atomik kayıt izdir: tek bir kullanıcı isteği için gerçekleşen her şeyin, aralıklardan (span) oluşan bir ağaç olarak tutulması. Erişim bir aralıktır. Her araç çağrısı bir aralıktır. Her model çağrısı bir aralıktır. Yeniden sıralama bir aralıktır. Bu, sıradan arka uç sistemlerindeki dağıtık izlemeyle aynı fikirdir ve OpenTelemetry'nin üretken yapay zeka için tanımladığı anlamsal sözleşmeler, bunu yalnızca yapay zeka ekibinin okumayı bildiği ayrı bir gözlemlenebilirlik yığını benimsemek yerine operasyon ekibinizin zaten işlettiği altyapı üzerinde taşımanızı sağlar. İzleri baştan bu biçimde toplamak, sonradan eklemeye çalışmaktan kıyaslanamayacak kadar ucuz ve güvenilirdir.

İzin taşıması gerekenler spesifiktir ve eksikler her zaman aynıdır. Yalnızca işlenmiş promptu değil, prompt şablonu kimliğini ve sürümünü kaydedin, çünkü altı ay sonra kötü bir cevabı hangi şablonun ürettiğini bilmeniz gerekecek. Sürüm dahil tam model kimliğini ve örnekleme parametrelerini kaydedin. Getirilen her belgenin veya parçanın kimliğini, puanını ve bağlamdaki nihai konumunu kaydedin. Girdi, çıktı ve varsa muhakeme token sayılarını, hesaplanan maliyeti ve aralık başına gecikmeyi kaydedin. Araç çağrılarını argümanları ve sonuçlarıyla kaydedin. Sonucu kaydedin: tamamlandı, reddedildi, bir güvenlik bariyeri tarafından filtrelendi, başarısız oldu veya kullanıcı tarafından yarıda bırakıldı. Bu alanların hiçbiri isteğe bağlı değildir.

İki alan özellikle anılmayı hak ediyor, çünkü ekipler bunları atlıyor ve sonra pişman oluyor. Birincisi, gizlilik gerektiriyorsa özetlenmiş halde tutulan kalıcı bir konuşma ve kullanıcı kimliğidir; çok turlu bir hatayı yeniden kurmanın veya bir ilgili kişinin sistemin verisiyle ne yaptığına dair sorusunu cevaplamanın tek yolu budur. İkincisi güvenlik bariyeri karar kaydıdır: hangi kontroller çalıştı, her biri ne döndürdü ve bir şey engellendi mi ya da yeniden yazıldı mı. Bu olmadan iyi davranan bir modeli, kötü davranıp yakalanan bir modelden ayıramazsınız ve bu iki durum tamamen farklı müdahaleler gerektirir. Bu iki alanı sonradan eklemek neredeyse her zaman geriye dönük veri kaybı demektir.

Hacim örnekleme kararlarını dayatır ve makul varsayılan asimetriktir. Yapısal iz metadata'sını, yani zamanlamaları, maliyetleri, belge kimliklerini ve kararları her tek istek için saklayın, çünkü küçüktür ve incelemelerin çoğunun ihtiyaç duyduğu şeydir. Tam prompt ve yanıt içeriklerini rutin trafikte yüzde 5 ila 20 gibi bir oranda, hata veren, reddedilen, bir güvenlik bariyerince işaretlenen veya olumsuz kullanıcı geri bildirimi alan her şeyde ise yüzde 100 oranında örnekleyin. Tam içerikler için 30 ila 90 gün, toplu veriler için çok daha uzun saklama süreleri yaygın bir şekildir ve kesin sayılar depolama maliyetine göre değil veri koruma duruşunuza göre belirlenmelidir.

Maliyet, Gecikme ve Hareket Eden Sayılar

Bir LLM sisteminde maliyet aylık bir kalem değil, istekten isteğe bir büyüklük mertebesi değişen istek başına bir özelliktir. Onu iz düzeyinde ilişkilendirin ve yukarı doğru toplayın: istek başına, konuşma başına, özellik başına, kiracı başına ve kullanıcı kohortu başına maliyet. Dağılım toplamdan çok daha önemlidir, çünkü bu dağılımlar ağır biçimde çarpıktır. Konuşmaların küçük bir yüzdesinin, tipik olarak geniş getirilmiş bağlamları ve tekrarlanan araç çağrıları olan uzun çok turlu konuşmaların, toplam harcamanın büyük bir kısmını oluşturması olağandır ve bunu toplu bir faturada göremezsiniz. Bu nedenle maliyet panosunu toplam üzerinden değil dağılım üzerinden kurmak gerekir.

Gecikme için yüzdelik dilimler gerekir ve ortalamalar burada aktif olarak yanıltıcıdır, çünkü üretim süresi çıktı uzunluğuna bağlıdır ve onun uzun bir kuyruğu vardır. İlk token'a kadar geçen süreyi toplam tamamlanma süresinden ayrı izleyin, çünkü bunlar kullanıcıya tamamen farklı hissettirir ve farklı nedenleri vardır. Bütçeyi aralık bazında ayrıştırın ki p95 değerinizin ne kadarının erişim, ne kadarının yeniden sıralama, ne kadarının model ve ne kadarının kendi orkestrasyon kodunuz olduğunu görebilesiniz. Deneyimimizde sürpriz genellikle model olmaz: kaçınılabilir seri gidiş dönüşlerden oluşan bir zincir ya da hiç toplu hale getirilmemiş bir yeniden sıralama aşaması olur.

Toplu değerlere eşikler koyun ve yalnızca mutlak değerlere değil harekete de uyarı bağlayın. Ortalama prompt token sayısındaki ani yüzde 30'luk bir sıçrama genellikle bir erişim değişikliğinin amaçlanandan fazla bağlam çektiği ya da bir prompt düzenlemesinin kimsenin maliyetlendirmediği örnekler eklediği anlamına gelir. Ortalama çıktı token sayısındaki ani bir düşüş çoğu zaman modelin reddetmeye veya kesmeye başladığını gösterir. Yükselen bir güvenlik bariyeri engelleme oranı bir saldırıya işaret edebileceği gibi, kurallarınızın yazılmadığı meşru bir yeni kullanım senaryosuna da işaret edebilir. Bunların hiçbiri kalite metriklerinden görünmez; operasyonel metriklerden görünür ve genellikle önce onlar belirir.

Değerlendirme Odaklı Geliştirme ve Birleştirme Öncesi Kapı

Değerlendirme odaklı geliştirme, iddia edilebilir bir doğru çıktısı olmayan bir sisteme verilen pratik cevaptır. Cevabın beklenen bir dizgiye eşit olduğunu test etmezsiniz. Cevabın, sabit bir vaka kümesi üzerinde derecelendirilmiş ölçütlerde bir eşiğin üzerinde puan aldığını ve puanın son sürüme göre gerilemediğini test edersiniz. Değerlendirme kümesi şartname haline gelir ve yeni vaka yazmak özelliği yazmanın parçası olur. Disiplin, test odaklı geliştirmeyle aynıdır ve kültürel direnç de aynıdır: iki hafta boyunca yavaş hissettirir, sonra herhangi birinin bir şeyi güvenle değiştirebilmesinin tek nedeni haline gelir. Şartname artık bir belgede değil, koşturulabilir bir kümede yaşar.

Kapı, gerçek bir geliştirme döngüsüyle temasa dayanacak kadar hızlı olmalıdır. Kırk dakika süren bir birleştirme öncesi paket bir ay içinde atlanmaya başlar. Hedefimiz kademeli bir yapıdır: her pull request'te on dakikanın altında çalışan, temel davranışları ve bilinen hata vakalarını kapsayan 100 ila 200 vakalık hızlı bir kademe; geceleri ve sürüm adaylarında çalışan 500 ve üzeri vakalık tam bir kademe; ve prompt, araç tanımları veya erişim kapsamı her değiştiğinde çalışan, yapay zeka güvenliği ve prompt enjeksiyonu yazısında anlatılan saldırı yüzeyine doğrudan bağlanan güvenlik ve enjeksiyon vakalarından oluşan özel bir kademe. Bu üç kademe birlikte hem hızı hem kapsamayı korur.

Sabitlenebilecek her şey sabitlenmelidir, yoksa kapı kararsız hale gelir ve kararsız kapılar devre dışı bırakılır. Değerlendirme koşumlarında sıcaklık sıfır. Açık model sürümü, sağlayıcının yeniden yönlendirebileceği kayan bir takma ad asla. Koşumda kayıtlı prompt şablonu sürümü. Erişim indeksi anlık görüntü kimliği, ki korpustaki bir değişiklik koddaki bir değişiklik gibi görünmesin. Hakem modeli ve yönerge sürümü. Bir sonuç eşiğin yakınında durduğunda, regresyon demeden önce üç kez tekrarlayın ve varyansı kaydedin, çünkü koşumdan koşuma varyansı yüksek olan bir vaka başlı başına düzeltilmeye değer bir kusurdur. Sabitlenmeyen her parametre, ileride açıklanamayan bir sonuç farkı olarak geri döner.

Promptu kaynak kodu gibi ele alın, çünkü öyledir. Depoda yaşar, sürümlenir, üzerindeki değişiklikler incelemeden geçer ve aynı geri alma yeteneğiyle aynı hattan dağıtılır. Promptları bir sağlayıcı konsolunda düzenleyip sonra kalitenin neden değiştiğini merak eden ekipler mühendislik yapmıyordur ve hiçbir gözlemlenebilirlik yığını hiç kaydedilmemiş bir değişikliği telafi edemez. Aynısı araç tanımları, erişim parametreleri ve güvenlik bariyeri kuralları için de geçerlidir: davranışı değiştiriyorsa koddur ve kapının arkasına aittir. Bir sağlayıcı konsolunda yapılan düzenlemeler hiçbir incelemeden geçmez, hiçbir yerde sürümlenmez ve olay sonrası incelemede kimse o değişikliğin ne zaman yapıldığını gösteremez; bu da tek başına bir olayın kök nedenini bulunamaz hale getirmeye yeter.

Hakemler, Kalibrasyon ve Hakem Kayması

Canlı temposunda otomatik değerlendirme, çıktıları bir modelin puanlaması demektir, çünkü insan değerlendiriciler her pull request'te koşamaz. Bu, koşullar sağlanırsa işe yarar. Hakeme genel bir kalite hükmü yerine her seferinde tek bir dar soru sorun. İkili veya üç kademeli ölçekler kullanın, çünkü hakemler kaba ölçeklerde birden ona kadar olan ölçeklere göre belirgin biçimde daha tutarlıdır. Etiketten önce kısa bir yazılı gerekçe isteyin ve saklayın, çünkü sizin sorduğunuzdan başka bir şeyi puanlamaya başlamış bir hakemi teşhis etmenin yolu o gerekçelerdir. Hakem promptunu da tıpkı sistem promptu gibi depoda tutun, sürümleyin ve inceleyin.

İnsan etiketlerine karşı kalibrasyon isteğe bağlı değildir ve bir ölçümü bir sayıdan ayıran adım budur. Bir alan uzmanına, hakemin aldığı yönergenin aynısına göre 50 ila 100 vakayı etiketletin, sonra uyumu ölçün. İkili bir kararda kabaca yüzde 80'in altında hakem kullanılabilir değildir ve doğru tepki neredeyse her zaman model değiştirmek değil yönergeyi işlenmiş örneklerle keskinleştirmektir. Yaklaşık yüzde 90'ın üzerinde periyodik yeniden kontroller arasında gözetimsiz çalıştırabilirsiniz. Bir takvime bağlı olarak, üç ayda bir makul bir varsayılandır, ve hakem modeli, yönerge ya da prompt şablonu değiştiğinde derhal yeniden kalibre edin. Kalibrasyon kaydı olmadan raporlanan hiçbir puan savunulabilir değildir.

Hakemler, hatanın enstrümanınızdaki değil sisteminizdeki bir değişiklik gibi görünmesi nedeniyle gözden kaçması kolay biçimlerde kayar. Sağlayıcı hakem modelini günceller ve hiçbir kod değişikliği olmadan sadakat puanlarınız iki puan hareket eder. Bir uç durumu netleştirmek için düzenlenen bir yönerge, dayanaklı sayılan şeyi sessizce genişletir. Bir yıl boyunca aynı değerlendirme kümesini puanlamış bir hakem, sisteminizin ürettiği ifade biçimine karşı fiili bir tercih geliştirir. Savunmalar mekaniktir: hakem sürümünü sabitleyin, dondurulmuş bir insan etiketli kalibrasyon kümesi tutun, uyum oranını raporlanan her metriğin yanında kaydedin ve farklı hakem yapılandırmalarının ürettiği iki sayıyı karşılaştırmayı reddedin. Bu kural, aylar boyunca karşılaştırılabilir sayılar üretmenin tek yoludur.

Üç Tür Model Kayması ve Her Birinin Tespiti

Birinci tür girdi kaymasıdır: kullanıcıların sorduğu şey değişir. Yeni ürün hatları, korpusunuzun hiç kapsamadığı sorular üretir. Bir mevzuat değişikliği konu dağılımını kaydırır. Bir pazarlama kampanyası farklı kelime dağarcığına sahip farklı bir kitle getirir. Tespit dolaysız ve ucuzdur: gelen sorguların embedding'ini alın, kayan bir merkez noktası ve konu kümesi dağılımı tutun ve her haftayı geriye dönük bir referansla karşılaştırın. Bir eşiğin ötesindeki uzaklığa uyarı bağlayın ve daha faydalısı, trafiğin küçük bir yüzdesinden fazlasını taşıyan yeni bir kümenin ortaya çıkmasına uyarı bağlayın. Sonra elle bakın, çünkü ilginç kısım her zaman merkezin ne kadar kaydığı değil hangi yeni kümenin belirdiğidir.

İkinci tür model kaymasıdır ve çoğu ekip için bu, sağlayıcının bir şeyi değiştirmesi anlamına gelir. Model davranışı sürüm güncellemeleriyle, bir takma adın arkasındaki sessiz yönlendirme değişiklikleriyle ve zaman zaman örnekleme davranışını değiştiren altyapı değişiklikleriyle değişir. Sürümleri sabitlediyseniz bunun ne zaman olacağını siz kontrol edersiniz; sabitlemenin tüm gerekçesi de budur. Tespit yöntemi bir kanarya değerlendirmesidir: belki 50 vakalık küçük ve sabit bir kümeyi modele karşı bir takvime bağlı olarak, sistem önemliyse günde birkaç kez koşturun ve harekete uyarı bağlayın. Yükseltmeyi seçtiğinizde tam paketi iki sürümde yan yana koşun ve geçişi bir yapılandırma ayarı değil, geri dönüş planı olan bir sürüm gibi ele alın.

Üçüncü tür dünya kaymasıdır ve kimsenin izlemediği tür budur. Model iyidir ve kullanıcılar aynıdır, ama korpus artık gerçekliği tarif etmemektedir. Bir politika değiştirilmiştir ve eski sürüm hâlâ indekstedir. Bir fiyat listesi altı ay eskimiştir. Bir mevzuat değişmiştir ve kurum içi rehber henüz güncellenmemiştir. Sistem bu soruları kendi belgelerine göre kendinden emin ve doğru biçimde, dünyaya göre ise yanlış biçimde cevaplayacaktır; bu da tam olarak eskimiş bir kaynağa sağlam biçimde dayandığı için en tehlikeli halüsinasyon kategorisidir. Bu kategoriyi yakalamak için modele değil korpusa bakmak gerekir ve bu, çoğu ekibin hiç kurmadığı bir izleme türüdür.

Dünya kayması model tarafında değil korpus tarafında izleme gerektirir. Getirilen parçaların yaş dağılımını izleyin ve atıf yapılan belgelerin medyan yaşı yükseldiğinde uyarı verin. Gözden geçirme tarihi geçmiş belgelere atıf yapan cevapların oranını izleyin. İndeksi kaynak sistemlerle bir takvime bağlı olarak mutabakata sokun ve indekste bulunan ama kaynakta silinmiş veya yürürlükten kalkmış belgeler için uyarı üretin. Ayrıca doğru cevaplarının zamanla değiştiği bilinen küçük bir değerlendirme vakası kümesi tutun, bunları üç ayda bir gözden geçirin ve gerçek dünyadaki cevabı değişmiş bir soruda geçer puan almayı başarı değil başarısızlık sayın. Bu kontroller haftalık bir işte yalnızca birkaç dakika sürer.

Çevrimiçi Değerlendirme, Geri Bildirim ve Yaşayan Veri Kümesi

Çevrimdışı değerlendirme, sabit bir vaka kümesini kontrollü bir ortamda aday bir sürüme karşı koşar. Tekrarlanabilir, ucuz ve güvenlidir; ancak kullanıcılarınızın gelecek hafta soracağı sorularda sistemin nasıl davranacağını size söyleyemez. Çevrimiçi değerlendirme canlı trafiğe karşı çalışır: gerçek konuşmaların örneklenerek puanlanması, sürümler arasında A/B veya kanarya karşılaştırması ve takip sorusu oranı, konuşmanın yarıda bırakılması ve kullanıcının aynı soruyu iki kez farklı ifade edip etmediği gibi davranışsal sinyaller. İkisine de ihtiyacınız var ve farklı soruları cevaplıyorlar. Bu yüzden çevrimdışı paketin yeşil olması canlıda her şeyin yolunda olduğu anlamına gelmez ve ikisini aynı panoda ayrım yapmadan yan yana göstermek yanıltıcıdır.

Kanarya sürümleri pratik köprüdür. Trafiğin yüzde 5 ila 10'unu yeni sürüme yönlendirin, anlamlı bir örneklem biriktirecek kadar bekleyin, ki orta düzeyde kullanılan kurum içi bir araç için bu genellikle saatler değil günler demektir, ve devam etmeden önce iki kol arasında kalite ve maliyet metriklerini karşılaştırın. Geri dönüş tetiğini başlamadan önce sayılarla tanımlayın ve otomatikleştirin. Önceden mutabık kalınmış bir durdurma eşiği olmayan bir kanarya, bir güvenlik mekanizması değil yavaş bir sürümdür, çünkü sayıların yeterince kötü olup olmadığı tartışmasını her zaman yayına almak isteyen taraf kazanır. Eşiği cümle olarak değil sayı olarak yazın.

Kullanıcı geri bildirimi mevcut en ucuz sinyaldir ve en sık israf edilenidir. Yapısı olmayan bir olumsuz oy size neredeyse hiçbir şey söylemez; yanlış bilgi, eksik bilgi veya faydasız ifade biçimi şeklinde üç isteğe bağlı gerekçesi olan bir olumsuz oy ise her birini yönlendirilebilir bir kusura dönüştürür. Açık geri bildirim oranları tipik olarak düşüktür, çoğu zaman etkileşimlerin yalnızca yüzde birkaçıdır, dolayısıyla örtük sinyalleri birinci sınıf kabul edin: tekrarlanan yeniden ifade etme, hemen bir insana yükseltme, cevabı kopyalama veya yanıtın ortasında bırakma. Bunların hiçbiri tek başına kesin değildir ve hepsi, hangi konuşmaları bir insanın okuması gerektiğine karar vermek için toplu halde faydalıdır.

Döngüyü, canlıdaki hataları değerlendirme kümesine geri besleyerek kapatın. Üst kademeye taşınan her olay bir hafta içinde, doğru cevabı ve doğru kaynakları iliştirilmiş bir etiketli vakaya dönüşür. Her yeni hata biçimi bir değil üç dört vaka kazanır, böylece düzeltme tek bir örneğe aşırı uydurulamaz. Veri kümesi, yayına alma anında çekilmiş bir anlık görüntü olmaktan çıkar ve sistemin yanlış yaptığı her şeyin biriktiği kurumsal hafızaya dönüşür; bu da açık ara projenin ürettiği en değerli ve ekip değiştiğinde kaybolma ihtimali en yüksek varlıktır. Bu kümenin sahipliğini de tek bir kişiye verin, yoksa ilk ekip değişikliğinde birikim kaybolur.

Model Başkasının Olduğunda Olay Müdahalesi

Yapay zeka olayları kesinti gibi görünmez. Servis ayaktadır, gecikme normaldir, hata oranları düzdür ve sistem kendinden emin biçimde yanlış veya zararlı cevaplar üretmektedir. Mevcut uyarı düzeneğiniz tetiklenmez, çünkü ölçtüğü hiçbir şey değişmemiştir. Bu da yapay zeka sistemlerinin kendi tespit yollarına ihtiyaç duyduğu anlamına gelir: örneklenmiş çevrimiçi puanlama üzerinde kalite metriği uyarıları, güvenlik bariyeri engelleme oranı anomalileri, reddetme oranında her iki yönde ani kaymalar ve fark eden ilk kişinin resmi bir talep kaydı açmadan konuyu yükseltebileceği düşük sürtünmeli bir kurum içi bildirim yolu. Bu yolların hiçbiri kurulmamışsa, sorunu ilk fark eden genellikle müşteri olur.

Müdahale kılavuzunun, sıradan kılavuzların hiç karşılaşmadığı bir soruyu cevaplaması gerekir: model sizin değilken geri alma ne demektir? Pratikte dört kaldıracınız vardır ve mimarinizde hangilerinin mevcut olduğunu önceden bilmelisiniz. Prompt ve araç tanımlarını önceki sürüme geri alın, ki depoda duruyorlarsa bunu anında yapabilirsiniz. Önceden sabitlenmiş model sürümüne geri dönün, ki bunu ancak sağlayıcı onu hâlâ sunuyorsa ve kayan bir takma ad kullanmadıysanız yapabilirsiniz. Olaya karışan belirli yeteneği, araç tanımını veya erişim kapsamını devre dışı bırakıp geri kalanı çalışır durumda tutun. Ya da bozulmuş ama güvenli bir moda düşün: üretilmiş cevap olmadan atıflarla erişim, veya etkilenen sorguların bir insan kuyruğuna yönlendirilmesi.

Olay sonrası kaydı, diğer her canlı olayı kadar titizlikle yazın ve bu sistem sınıfına özgü alanları da ekleyin: yürürlükteki prompt ve model sürümleri, getirilen belge kimlikleri, güvenlik bariyeri kararları ve sonuç olarak eklenen değerlendirme vakaları. Bu son madde, bir olayı bir iyileşmeye çeviren şeydir. Değerlendirme kümesine yeni vaka eklenmeden kapanan bir yapay zeka olayı kuruma hiçbir şey öğretmemiştir ve aynı hata, biri promptu bir sonraki düzenlediğinde geri gelecektir. Bu, tesadüf olmayan biçimde, ciddi bir yönetişim çerçevesinin istediği kayıt tutma düzenine de yakındır; konu kurumsal yapay zeka yönetişimi yazısında ayrıntılı ele alınıyor.

Uyum Köprüsü: Aynı Kanıt, İki Kez

İşte mühendislik yazılarında nadiren, Türkçe olanlarda ise neredeyse hiç görünmeyen kısım. Bu disiplinin ürettiği çıktılar, yani sürümlenmiş değerlendirme sonuçları, model ve prompt sürümü taşıyan izler, model kayması izleme, olay kayıtları ve insan gözetimi logları, esas olarak yapay zeka düzenlemesinin istediği çıktılarla aynıdır. Ekipler bunları genellikle iki kez üretir: bir kez mühendislik olarak, bir kez de farklı bir departmanın bir hesap tablosu üzerinden yürüttüğü uyum çalışması olarak. Bunları veri hattı içinde tek seferde üretmek hem daha ucuzdur hem de gerçekten doğru olan kanıt üretir, çünkü sonradan anlatılmak yerine sistem tarafından üretilmiştir.

AB Yapay Zeka Yasası, Regulation (EU) 2024/1689'dur. 1 Ağustos 2024'te yürürlüğe girmiş ve istisnalarla birlikte 2 Ağustos 2026'da uygulanmaya başlamıştır. Yasaklı uygulamalar ve yapay zeka okuryazarlığı yükümlülükleri 2 Şubat 2025'ten, GPAI model sağlayıcı yükümlülükleri ise 2 Ağustos 2025'ten bu yana uygulanmaktadır. 8 Temmuz 2026 tarihli Regulation (EU) 2026/1744 sayılı Yapay Zekaya İlişkin Dijital Omnibus 27 Temmuz 2026'da yürürlüğe girmiş; Ek III kapsamındaki bağımsız yüksek riskli sistemleri 2 Aralık 2027'ye, Ek I kapsamındaki ürüne gömülü yüksek riskli sistemleri ise 2 Ağustos 2028'e taşımıştır. Madde 50 şeffaflık yükümlülükleri ertelenmemiş ve 2 Ağustos 2026'da yürürlüğe girmiştir; halihazırda piyasada olan sistemlerde sentetik içerik işaretleme için 2 Aralık 2026'ya kadar bir geçiş süresi tanınmıştır. Yetkili kaynak Avrupa Komisyonu'nun düzenleyici çerçeve sayfasıdır.

Yüksek riskli rejimin beklediği şey mühendislik diline çevrildiğinde tanıdıktır. Sistemin ne yaptığını ve nasıl doğrulandığını anlatan teknik dokümantasyon, sizin değerlendirme metodolojinize, veri kümesi tanımınıza ve kayıtlı sonuçlarınıza denk düşer. Sistemin yaşam döngüsü boyunca olayların otomatik loglanması, saklama süreleriyle birlikte izlemeye denk düşer. İnsan gözetimi, inceleme kuyruklarına, yükseltme yollarına ve bir kişinin gerçekten baktığına dair kayda denk düşer. Piyasaya arz sonrası izleme ise model kayması tespitine, çevrimiçi değerlendirmeye ve olay sürecine denk düşer. 2027 ve 2028'e yapılan erteleme, beklemek için bir gerekçe değil bunu düzgün kurmak için verilmiş zamandır; özellikle de AB'li müşterilerin tedarik anketleri bunu şimdiden sorduğu için.

Türkiye'de yürürlükte özel bir yapay zeka kanunu yoktur; düzenleme mevcut araçlar üzerinden, başlıca 6698 sayılı Kişisel Verilerin Korunması Kanunu üzerinden ilerler. Buna rağmen hesap verebilirlik mantığı aynıdır. Aydınlatma yükümlülüğüne ilişkin 10. madde ve veri güvenliğine ilişkin 12. madde, sisteminizin neyi loglayıp neyi sakladığını ve neyi ifşa ettiğini bilmeden karşılanması güç yükümlülüklerdir; münhasıran otomatik işleme yoluyla üretilen bir karara tabi olmama hakkını düzenleyen 11(g) maddesi ise bir insanın nerede müdahale ettiğini gösteren bir gözetim kaydı olmadan cevaplanamaz. KVKK'nın üretken yapay zeka rehberi ve Mart 2026 tarihli etken yapay zeka notu bağlayıcı kural değil rehberliktir, ancak aynı kanıtı işaret ederler.

HatsonTech'te İkinci Günü Nasıl İşletiyoruz?

Varsayılanımız, gözlemlenebilirliğin ve değerlendirme düzeneğinin proje sırasında kurulması, sonradan eklenmemesi ve diğer her şeyle birlikte devredilmesidir. Somut olarak bu şu demektir: üretken yapay zeka nitelikleri taşıyan, OpenTelemetry tabanlı ve müşterinin operasyon ekibinin zaten kullandığı sisteme akan izleme; koşumların aylar sonra karşılaştırılabilmesi için bir deney ve değerlendirme kaydı; müşterinin deposunda sürümlenen promptlar ve araç tanımları; ve kendi CI hattına bağlanmış kademeli bir değerlendirme paketi. Bunların hiçbiri egzotik araç değildir. Değeri, ilk kalite olayından sonra sonradan eklenmek yerine üretimin birinci gününde var olmasıdır. Devir teslimin amacı, ekibin bizsiz de aynı disiplini sürdürebilmesidir.

En tutarlı gördüğümüz örüntü, operasyonel izlemenin sorunları kalite metriklerinden önce yakalamasıdır. Token sayıları ve reddetme oranları, cevapların kötüleştiğini birinin fark etmesinden günler önce hareket eder, çünkü kullanıcılar şikayet etmeden önce çok şeye katlanır. İkinci örüntü, belge yoğun sistemlerde korpusun eskimesi anlamına gelen dünya kaymasının, model değişikliklerinin bugüne dek yol açtığından daha fazla gerçek hasar üretmesidir; korpus yaşını ve yürürlükten kalkmış belgelere atıf oranlarını model metriklerinin yanında izlememizin ve ölçekte belge parçalama yazısında anlatılan sürümleme disiplinini bir veri alımı ayrıntısı değil bir operasyon meselesi saymamızın nedeni budur. Bu iki örüntü birlikte, izlemeye ayrılan bütçenin gerekçesini oluşturuyor.

Dürüst maliyet: tipik bir projede bu çalışma ilk kuruluma kabaca yüzde 10 ila 20 ekler ve birinin promptu tahmin yürütmeden değiştirmesi gereken ilk anda kendini amorti eder. Canlıda bir yapay zeka sistemi işletiyor ve geçen ay belirli bir cevabı hangi prompt sürümünün ürettiğini söyleyemiyorsanız ya da bugünkü kalitenin yayın günündeki kaliteden farklı olup olmadığını bilemiyorsanız, bir sonraki özellikten önce kapatılmaya değer boşluk budur. Özel yazılım geliştirme çalışmalarımız bu sistemleri izleme altyapısı baştan yerinde olacak şekilde kurar ve bu altyapı olmadan yayına alınmış bir sisteme sonradan da eklenebilir. Bu boşluk her geçen ay daha pahalı kapanır.