39  Vaka Çalışması: Kurumsal Bir Ajan Platformu Kurmak

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 39. bölüm. Bu bölümün kendi ölçümü yok. Belirli bir şirketin dağıtımına dair bir rapor değil, adım adım işlenen bir örnek: kitabın kendi ölçümlerinin doğrudan uygulanabileceği biçimde kurulmuş bir sistem. Önceki bölümlerin ölçümleri aşağıda açık iş yükü varsayımlarıyla birleştiriliyor ve her ölçüm kendi bölümüne atıf veriyor; buradaki hiçbir şey dünya hakkında yeni bir iddia değil. Onu, zaten elinizde olanı bir araya getirme alıştırması olarak okuyun — bitirme projesinin sizden istediği de bu.

Öğrenme hedefleri. Bu bölümün sonunda:

39.1 Sistem ve yapmayacağı dört şey

Örnek, orta ölçekli bir Türk e-ticaret şirketi için bir destek platformu. Ajanlar müşterilerin sipariş, kargo ve iade sorularını Türkçe olarak, ayda kabaca 40.000 konuşma üzerinden cevaplıyor. Üç araç: bir siparişi bul, bir gönderiyi kontrol et, bir ürün iade talebi aç. Ürün iade talebi iptal edilebilir; para iadesinin ödenmesi ise bir ajan aracı değil — ajan yalnızca bir para iadesi önerebilir, kararı para iadesi servisi verir. Gerektiğinde vaka her zaman bir insana aktarılabilir (escalation: vakayı daha güçlü bir modele ya da bir insana aktarma).

Her şeyi biçimlendiren gereksinimler:

Gereksinimlerin gerçekte kısıtladıkları
gereksinim nerede can yakıyor
Türkçe; basit tokenlaştırmayı bozan biçimbilimiyle birlikte Bölüm 16 ve aşağıdaki her değerlendirme kümesi
Müşteri mesajları T.C. kimlik numaraları (TCKN), IBAN’lar ve adresler içeriyor Bölüm 37, Bölüm 38
Para iadesi, şirketten çıkan paradır Bölüm 37’nin geri alınabilirlik sınıflandırması
Cevaplar bir politika belgesine izlenebilmeli Bölüm 20, Bölüm 34
Bir platform takımı, ajan isteyen beş ürün takımı Bölüm 39.5

Yapılmayacaklar yapılacaklardan daha değerli ve önce onlar yazılmalı. Bu sistem şunları yapmayacak:

  1. pazarlama metni üretmek;
  2. sipariş, kargo ve iade dışındaki soruları cevaplamak;
  3. ajana, bir insanın bir iş günü içinde geri alamayacağı herhangi bir eylemi yaptırmak — para yalnızca para iadesi servisinden, onun tavanı ve onay kuralıyla çıkar;
  4. insana aktarma yolu olmadan çalışmak.

Her biri, bütün bir arıza sınıfını ortadan kaldıran bir karar. Bir özellik daha isteyen biri de her birine itiraz edecek; bu yüzden, kimse aksi yönde emek harcamadan önce yazılmaları gerekiyor.

39.2 Yedi karar ve neyin reddedildiği

Mimari karar kaydı (ADR), tek bir tasarım kararını, değerlendirilen alternatifleri ve kararın sonuçlarını yazan kısa bir belgedir. Ancak reddedilen alternatifi gerçekten kaydediyorsa bir işe yarar. Aşağıdaki tablo, kayıtların sıkıştırılmış hâli. Son satırının hiç teknik bir karar olmadığına dikkat edin; aynı tabloda olması bilinçli, çünkü tasarımı en az diğerleri kadar kısıtlıyor.

Yedi karar; okunacak sütun reddedilenler sütunu
karar seçilen reddedilen ve nedeni
Model erişimi tüm sağlayıcıların önünde tek bir geçit servis başına doğrudan SDK çağrıları — başlangıçta ucuz, ama sonra maliyet atfının, sürüm sabitlemenin ve hız sınırlarının beş ayrı uygulaması oluyor (Bölüm 32)
Döngünün yeri durumu belirli adımlarda kaydedilen (checkpointed state) dayanıklı yürütme bir istek işleyicisinin arkasında bellek içi döngü — konuşmanın ortasında yeni bir sürüm dağıtılana kadar sorunsuz (Bölüm 33)
Erişim politika derlemi üzerinde atıflı melez arama tüm politikaların bağlama doldurulması — daha basit, ama Bölüm 31’in ölçtüğü prefill maliyeti onu baskın gecikme terimi yapıyor. Bu satırın reddetmediği alternatife dikkat: Bölüm 19’un kendi derleminde ağırlıksız sıra birleştirmeyi yenen tek başına BM25 ya da yoğun erişim. Melez aramayı varsaymadan önce erişicileri tek tek ölçün; biri çok daha güçlüyse ikisini eşit ağırlıkla birleştirmeyin
Kişisel veri sınırda saptayıp geri döndürülebilir biçimde tokenlaştırmak (kişisel veriyi, sonradan geri çevrilebilen yer tutucularla değiştirmek; takma adlandırma) — buradaki tokenlaştırma NLP’deki metni token’lara bölme işlemi değil yıkıcı maskeleme — güvenli, ama sipariş aramasını bozuyor (Bölüm 37)
Para iadeleri ajan önerir, servis tavanı zorunlu kılar, üstünde insan onaylar ajan para iadesi API’sini prompt’ta bir sınırla çağırır — prompt’taki bir sınır bir ricadır (Bölüm 36)
Değerlendirme depoda bir altın küme (golden set), her prompt değişikliğinde çalışan bir kapı (gate) sürümden önce elle yapılan rastgele kontroller — gözden neyin kaçtığını Bölüm 35 ölçtü
Sağlayıcının nerede durduğu varsa bir Türkiye bölgesi dağıtımı (ve yurt dışından uzaktan erişim olmadığının sözleşmeyle teyidi, çünkü destek amaçlı uzaktan erişim bile aktarım sayılabilir), yoksa KVKK’nın (6698 sayılı Kişisel Verilerin Korunması Kanunu) 9. maddesi kapsamında standart sözleşme “geçit bunu soyutlar” — geçit seçimi merkezîleştirir, onu teknik bir karara çevirmez (Bölüm 38.1)

Bunlardan ikisinin gerekçesinin açıkça yazılması gerekiyor, çünkü takımların en sık ters anladıkları ikisi onlar.

Uzun bağlam yerine erişim. Her politika belgesini prompt’a doldurmak gerçekten daha basit, ama sayılarda kaybediyor: Bölüm 31 7.427 token bağlamda wall-clock süresinin (baştan sona gerçekte geçen süre) %91,0’ının ilk karakterden önce geçtiğini ve pencere doldukça decode’un (cevabın token token üretildiği aşama) saniyede 189’dan 141 token’a düştüğünü ölçtü. Uzun bağlamın bedeli iki kez ödeniyor. Erişim bir bileşen ekliyor ve baskın gecikme terimini kaldırıyor.

Para iadesi tavanı para iadesi servisinde durur. Tasarımdaki en önemli tek satır bu ve nedeni Bölüm 36: müşteri mesajlarını okuyan bir ajan, saldırgan denetimindeki girdiyi okuyor ve yerleştirilmiş bir talimat, 25 koşunun 25’inde bir ajana hiç istenmemiş bir aracı çağırttı. Tavan prompt’taysa tavan bir öneridir.

39.3 İlk ajan, bölüm bölüm

Not defterinden (notebook) üretime giden yol, her adımı yöneten bölümle birlikte:

  1. Ajanı yazmadan önce görevi bir değerlendirme olarak yazın (Bölüm 22). Elli gerçek konuşma; her biri, iyi bir cevabın ne olması gerektiğiyle etiketlenmiş.
  2. Erişim katmanını kurun ve tek başına ölçün (Bölüm 19, Bölüm 20). Doğru politika belgesi ilk beşte değilse hiçbir promptlama cevabı düzeltmez.
  3. Araçları prompt olarak değil, API olarak yazın (Bölüm 24), her birine geri alınabilirlik sınıfı iliştirilmiş olarak (Bölüm 37).
  4. İşe yarayan en küçük döngüyü kurun (Bölüm 23), üç tavanın üçü de — adım, token ve wall-clock süresi tavanları — baştan konmuş olarak (Bölüm 33).
  5. Yapılandırılmış çıktı ekleyin ve doğrulayın (Bölüm 18) — doğrulayıcı aynı zamanda Bölüm 39.4’teki aktarma sinyali.
  6. Sorun çıkmadan önce ölçüm düzeneğini kurun (Bölüm 34); konuşma kimliği, iki model alanı (istediğiniz model ve gerçekte cevap veren model), token sayıları ve kendi boyutlarınız dâhil.
  7. Prompt değişikliklerini değerlendirme süitine bağlı bir kapıdan geçirin (Bölüm 35); eşiği yuvarlak bir sayıya göre değil, ölçülmüş bir gürültü tabanına göre belirleyin.
  8. Yayına almadan önce kendiniz saldırın (Bölüm 36) ve oranı yazın.

Takımların atladığı adımlar 1. ve 8. adımlardır; oysa geri kalan emeğe değip değmediğine karar veren de tam bu ikisidir.

39.4 Kitabın sayıları bunun neye mal olduğunu söylüyor

Kurmaya başlamadan önce işe yarayan disiplin, zaten elinizde olan ölçümlerden bir bütçe çıkarmaktır. Aşağıdaki her rakam önceki bir bölümden alınmıştır; yeni olan tek şey aritmetik.

Bu kesimin tamamını bir başlangıç tahmini olarak okuyun, bu platform için doğrulanmış bir bütçe olarak değil. Her sayı farklı bir modelden, farklı bir derlemden ve farklı bir görevden geldi ve birkaçı başka bir sisteme iyi taşınmıyor: kişisel veri dedektörünün precision (kesinlik) değeri, yazarın hazırladığı sentetik bir Türkçe derlemin ürünü — benzer görünen sayıların o derlemdeki yoğunluğunu da yazar seçti; saldırı ve saptama oranları ise tek bir modele, tek bir prompt’a ve tek bir saldırı kümesine özgü. Bunları önce yazıya dökülecek, sonra ilk iş ölçülecek varsayımlar olarak ele alın; bu kesimin kapanış cümlesi de zaten bunu söylüyor.

Gecikme. Bir isteğin iki yarısı var: prefill prompt’u tek bir paralel geçişte okur, decode ise cevabı token token yazar. Bölüm 31’in ayrımı — saniyede kabaca 2.000 token prefill’e karşı 190 decode — o donanımda yazdığınız bir token’ın okuduğunuz bir token’ın yaklaşık on bir katı sürmesi demek. Dolayısıyla hangi yarının baskın olduğu evrensel bir olgu değil, sizin prompt/cevap oranınızla ilgili bir soru. Üstelik erişim kararını verdiğiniz anda oran değişiyor. 7.427 token girip 64 çıkan istekte Bölüm 31, wall-clock süresinin %91’inin ilk token’dan önce, kabaca %9’unun ondan sonra geçtiğini ölçtü. Bu tasarımın hedeflediği istek biçiminde ise — bin token bağlam ve iki cümlelik bir Türkçe cevap, diyelim 150 token — prefill 0,50 s, decode 0,79 s; yani baskın terim decode ve ilk token’a kadar geçen süre eniyilenecek şey olmaktan çıkıyor. Bu, tasarımın bir sonucu; ona karşı bir argüman değil. Bu hesap tek bir model çağrısı içindir: bir ajan konuşmasında araç çağrısı, araç sonucu ve cevap ayrı çağrılardır ve her birinde prefill yeniden ödenir; konuşmanın süresi için bu sayıları konuşma başına çağrı sayısıyla çarpın.

Prompt önbellekleme yine de önce geliyor, çünkü kalite açısından hiçbir risk taşımıyor: sıcak prefill prompt uzunluğundan bağımsız olarak 12–16 ms’de sabit ölçüldü. Ama manşetteki çarpanı olduğu gibi aktarmak yerine, kendi prefill payınıza göre yeniden hesaplayın. Bölüm 31’in raporladığı 9,0 kat 4.247 token’da; bin token bağlam ve 150 token’lık bir cevapta aynı yöntem tüm istekte yaklaşık 1,6 kat. Burada 1,6 kat bile bir üst sınır. Önbellek yalnızca bayt bayt aynı bir ön eki yeniden kullanır; bu tasarımda ise getirilen politika parçaları her soruda değişir, dolayısıyla yalnızca sabit kısım — sistem prompt’u ve araç şemaları — sıcak servis edilir. Mekanizmayı alıntılayın, sayıyı yeniden hesaplayın.

Token hacmi. Bölüm 14’ün ölçümü — 890 prompt token’ına karşı 53 üretilmiş token — planlama yapılabilecek biçimlerden biri; ama kullanmadan önce süreye ve paraya çevirmekte yarar var. Süre olarak, on bire bir oranda o 53 çıktı token’ı, 890’lık bir prompt’a karşı kabaca 583 girdi token’ı eder. Para olarak ise çıktı token’ları genellikle girdinin üç ila beş katı fiyatlanır (Bölüm 14); o zaman aynı 53 token kabaca 160–265 girdi token’ına denk gelir. Her iki durumda da daha az göndermek daha az yazmaktan çok kazandırır — ama çıktı tarafı da ihmal edilebilir değil. Ayda 40.000 konuşma ve her birinde birkaç model çağrısıyla, sistem prompt’unuzdaki şablon metnin her token’ı her çağrıda yeniden ödenir (önbellekten sıcak servis ediliyorsa çoğu sağlayıcıda indirimli olarak); bu yüzden model seçimi kadar dikkatli incelenmeyi hak eder.

Telemetri. Bölüm 34 301 token’lık prompt’larda koşu başına 4,8 span ve 3.167 bayt ölçtü (span: bir izdeki zamanlanmış tek bir iş birimi); bunun %48,3’ü prompt ve tamamlama metni. Yapı sabit tutulup metin ölçeklendiğinde 890 token’lık prompt’lar için öngörülen değer %73,4 içerikle 6.163 bayt — bu bir ölçüm değil, bir izdüşüm. Oradaki bir koşu, model ve araç çağrılarıyla birlikte tek bir ajan çağrısıdır; bir konuşmada birkaç koşu olabilir. Bu yüzden hacmi, konuşma başına ortalama koşu sayısı r ile yazın: ayda 40.000 × r koşu. r = 1 iken bu kabaca 190.000 span ve o prompt boyutunda içerik kaydedilirse yaklaşık 0,25 GB; ölçülen 301 token’lık prompt’larda 0,13 GB. İkisini de r ile çarpın; hacim her hâlükârda küçük. Bir milyon koşuda 6 GB eder ve içeriği kaydedip kaydetmemek arasında dört kata yakın fark vardır. Bu kararı bilinçli verin: içeriği örnekleyerek kaydedin, ama hata olan her koşuda saklayın.

Değerlendirme. Bölüm 22’nin boyutlandırmasına göre, iki sistem ayrı örneklemler üzerinde, %80 istatistiksel güçle (iki yönlü α = 0,05) ve %80’lik bir baseline (taban puan) doğruluğundan başlanarak karşılaştırıldığında 100 madde 13,4 puanlık, 1.000 madde 4,8 puanlık bir farkı ayırt edebiliyor — dolayısıyla yüz maddelik bir altın küme bozuğu bulur, daha iyiyi değil. Küçük gerilemeleri yine de görünür kılan şey, koşuları aynı maddeler üzerinde karşılaştıran bir kapı. Yukarıdaki 1. adımın elli vakasını bu yüze doğru büyütün: doğru/yanlış diye puanlanan elli maddede bir madde iki puan eder, yani 1 puanlık bir eşik düpedüz “tek bir madde kaybedilirse engelle” anlamına gelir. Bölüm 35 koşular arası 0,26 puanlık bir standart sapma (sd; aralık 0,60) ölçtü ve kabaca 4 × sd olan 1 puanlık bir eşik kullandı. Yeniden örneklemede bu eşik 100 maddede %4,3 yanlış engelleme verdi ve incelemede görünmeyen bir prompt gerilemesini denemelerin %99,4’ünde yakaladı. Madde düzeyindeki eşleşmeler saklanmadığı için bu oranlar eşleştirilmiş bir kapıyı ölçmüyor; eşiğin kabaca nasıl davrandığını gösteriyor. Onlara güvenmeden önce kendi kapınızı ölçün.

Korkuluklar (guardrails). Bölüm 37’nin dedektör sayıları kişisel veri sınırının hata bütçesini belirliyor. TCKN’ler için tek başına on bir haneli bir örüntünün precision’ı %40. Örüntüye yalnızca sağlama toplamı eklemek recall (duyarlılık) değerini %84,7’ye, yalnızca bağlam kontrolü eklemek %50’ye düşürüyor; ikisinden birini geçenleri işaretleyen birleşim (VEYA) ise %93,6 recall ile %99,1 precision’a ulaşıyor. Geriye kalan pay önemsiz değil: gerçek tanımlayıcıların kabaca on beşte birini bu birleşim de yakalayamıyor. Bu, gizlenecek değil, veri koruma etki değerlendirmesine (DPIA: veri koruma mevzuatının riskli işlemeler için beklediği yazılı risk değerlendirmesi) konulacak bir sayı. Ayrıca yalnızca sabit biçimli tanımlayıcıları kapsıyor: adlar, adresler ve serbest metinde verilen bilgiler hiç ölçülmedi.

Güvenlik. Bölüm 36, dışa dönük bir aracı olan bir ajana karşı %92–100 saldırı başarısı ölçtü. Modelden saldırıyı saptamasını istemek de durumu kurtarmadı: kullanılabilir bir yanlış pozitif oranı olan tek dedektör prompt’u saldırıların %14,7’sini yakaladı ve bu oran yalnızca saldırı olarak işe yaradığı gösterilmiş üç çerçevelemeyi kapsıyor — genel bir “en iyi durum” değil. Mimarinin destek taleplerini (ticket) okuyan ajanı para hareket ettirebilen her şeyden uzak tutmasının nedeni bu iki sayı. Bölüm 36, aynı ajanda güvenilmeyen bir girdi kaynağıyla tehlikeli bir aracın bir arada bulunmasına çift diyor; aracı ajandan almak çifti kırar. Bu, geriye bir artık risk oranı bırakan bir hafifletme değil. Ama yalnızca iki koşulla geçerli: para iadesi servisine aktarılan şey, akışın ilerisindeki bir bileşenin talimat diye okuyabileceği serbest metin değil, doğrulanmış ve yapılandırılmış bir payload (iletilen verinin kendisi) olmalı; para iadesi servisi de yetkilendirmeyi ajanın ne istediğine göre değil, kullanıcıya göre yapmalı. Bileşenleri ayırmak tek başına sınır oluşturmaz; sınırı veri sözleşmesi çizer.

Yönlendirme. Bölüm 12, bir LLM’in sözel güvenini kendi hatalarının dedektörü olarak AUROC 0,667’de ölçtü; aynı görevde fine-tuning (ince ayar) uygulanmış bir sınıflandırıcının (BERTurk) kendi etiket olasılığı ise 0,843’e ulaşıyor. Gerçek bir sinyal, ama körü körüne yönlendirme yapmaya yetmiyor. Ayakta kalan yönlendirme biçimi Bölüm 38’in cascade’i (kademeli yönlendirme: önce ucuz model cevaplar, gerekirse daha güçlü modele geçilir): küçük modelle cevapla; tahmin edilen zorluğa göre değil, doğrulayıcı çıktıyı reddettiğinde büyük modele aktar.

Bütçenin tamamı tek bir tabloya sığıyor; lab’ın ve 3. alıştırmanın kendi sisteminiz için kurmanızı istediği tablo da bu:

Bütçe ve her kalemin hâlâ ihtiyaç duyduğu ölçüm
bütçe kalemi kitabın sayısı bölüm sizin sisteminizde önce ölçülecek
gecikme prefill ≈ 2.000 token/s, decode ≈ 190 token/s; 1.000 girdi / 150 çıktıda 0,50 s + 0,79 s Bölüm 31 prompt/cevap oranınız
önbellekleme sıcak prefill 12–16 ms; bu biçimde en fazla ≈ 1,6 kat Bölüm 31 prompt’unuzun sabit ön ek olan payı
token hacmi 53 üretilmişe karşı 890 prompt token’ı Bölüm 14 çağrı başına token, konuşma başına çağrı
telemetri koşu başına 4,8 span, 3.167 bayt; 890 token’lık prompt’ta öngörülen 6.163 bayt Bölüm 34 konuşma başına koşu (r); içeriğin kaydedilip kaydedilmediği
değerlendirme boyutu 100 madde → 13,4 puan, 1.000 → 4,8 (ayrı örneklemler) Bölüm 22 görmeniz gereken en küçük değişim
kapı sd 0,26; 1 puanlık eşik → 100 maddede %4,3 yanlış engelleme Bölüm 35 kendi sd’niz ve yanlış engelleme oranınız
kişisel veri tek başına örüntü: %40 precision; birleşim: %99,1 precision, %93,6 recall Bölüm 37 kendi trafiğinizde precision ve recall
güvenlik saldırı başarısı %92–100; saptama %14,7 Bölüm 36 kendi saldırı başarı oranınız
yönlendirme sözel güven AUROC 0,667, karşısında 0,843 Bölüm 12 doğrulayıcınızın küçük modeli ne sıklıkla reddettiği

Bütçenin neyi gerektirmediğine dikkat edin: tek bir yeni deneyi. Sekiz bölümlük ölçüm, bir araya getirildiğinde sayılarla desteklenmiş bir tasarım üretiyor — ve sayıların eksik olduğu yerler, ilk ölçümlerinizin gitmesi gereken yerler.

39.5 İkinci takım ve onuncu ajan

Yukarıdaki her şey tek bir ajan içindi. Sonradan beliren arızalar örgütseldir ve belli bir takvimle gelir.

İkinci takımla birlikte prompt’lar ve araçlar paylaşılmaya başlar; ilk platform arızası da bir takımın değiştirdiği aracın başka bir takımın ajanını bozmasıdır. Çözüm, yazılım mühendisliğinden tanıdık: araçlar, sahibi belli, sürümlenmiş arayüzlerdir (Bölüm 24) ve bir araç tanımındaki değişiklik bir bağımlılık yükseltmesi gibi incelenir (Bölüm 36).

Beşinci ajanda kimse “kaç ajan işletiyoruz ve neye erişebiliyorlar” sorusunu cevaplayamıyor. Çözüm bir ajan kayıt defteri (agent registry): her ajan için araçlarını, veri erişimini, sahibini, hukuki dayanağını ve geri alınabilirlik profilini listeleyen bir satır. Gösterişsiz bir üründür, ama her denetim, her olay ve her maliyet incelemesi ona ihtiyaç duyar (Bölüm 38). Bu bölümün destek ajanı için bir satır şöyle görünür:

Ajan kayıt defterinde bir satır
alan destek ajanı için değer
sahip adı belli bir kişi ve onun takımı
araçlar ve geri alınabilirlik sınıfı sipariş bul ve gönderi kontrol et: durum değişikliği yok; ürün iade talebi aç: çabayla geri alınabilir (iptal edilebilir) — sınıflar Bölüm 37’den
veri erişimi sipariş ve kargo kayıtları; kişisel veri sınırda tokenlaştırılmış olarak
hukuki dayanak ve aktarım hukuk biriminin belirlediği işleme şartı; sağlayıcı yurt dışındaysa standart sözleşme ve bildirim tarihi (Bölüm 38.1)
model geçitte sabitlenmiş sürüm (Bölüm 32)
kanıt değerlendirme kapısının eşiği ve son saldırı başarı oranı, tarihleriyle

Kayıt defteri, ajan yayına alınırken zorunlu bir adım olarak doldurulur; bir olaydan sonra doldurulmaya çalışılırsa güvenilir biçimde yeniden kurulamaz.

Onuncu ajanda platform takımı darboğaz oluyor ve çözüm bir inceleme kuyruğu değil bir golden path (gerekli kontrolleri hazır içeren, desteklenen standart yol): değerlendirme kapısının, izlemenin, kişisel veri sınırının ve araç sınıflandırmasının zaten bağlanmış olduğu bir şablon depo; böylece uyumlu yol en hızlı yol oluyor. Her şeyi inceleyen bir platform takımı doğrusal ölçeklenir ve sonra durur; güvenli yolu kolay yol yapan durmaz.

Baştan sona, maliyet atfı ilk ajandan itibaren var olmalı, çünkü Bölüm 34’ün boyutlarını (kullanıcı, takım, özellik, ortam) geriye dönük eklemek pahalıdır. Bu boyutları sonradan ancak başka bir kalıcı kaynak (fatura, erişim logu) onları saklamışsa eşleştirip ekleyebilirsiniz; hiç yazılmamış olanı ise hiçbir şey geri getirmez. Bir bütçe incelemesinin istediği sayı da oturum başına değil, çözülen destek talebi başına maliyet.

39.6 Ne bozulur

Bu, yaşanmış olayların anlatısı değil; bu kitabın ölçümlerinin öngördüğü arızalar üzerinden, olaylar yaşanmadan önce yazılmış bir değerlendirme — bir pre-mortem. Her biri, test edilmesi ve önlemi planlanması gereken makul bir arıza biçimi.

Değerlendirme kümesi fazla küçük ve fazla kolay olacak. Birinin bir öğleden sonra yazdığı elli vakayla başlayacak, içindekileri düzelttikçe kolaylaşacak ve değişmeyen puanı kararlılık diye okunacak. Bölüm 35’in uyardığı gibi, altı aydır değişmemiş bir küme bayattır ve yine de yeşil bir onay işareti üretir.

Biri bir prompt’u kapıdan geçirmeden düzenleyecek, çünkü değişiklik apaçık kozmetik görünecek. Bölüm 35, prompt’taki altı kuralın yalnızca sırasını değiştirmenin alan doğruluğunda 3,40 puana — özdeş koşuların 0,60 puanlık aralığının neredeyse altı katı, sd’lerinin on üç katı — mal olduğunu ve gerilemenin tamamının tek bir alanın içinde olduğunu ölçtü.

Kişisel veri dedektörü recall’a göre ayarlanacak ve ürünü bozacak. %40 precision’da ajanların ihtiyaç duyduğu sipariş numaralarını da maskeler; tepki de precision’ı düzeltmek değil, dedektörü kapatmak olur (Bölüm 37).

İlk ciddi olay, kimsenin hiçbir şeyi reddetmediği bir onay kuyruğu olacak. %99 onay oranı tek başına bunu göstermez; iyi hedeflenmiş bir kapı zaten neredeyse her şeyi onaylamalıdır. Bunu gösteren, bilerek yerleştirilmiş hatalardır: inceleyenler yanlış olduğu bilinen maddeleri de onaylıyorsa kuyruk, gözetim kılığına girmiş bir gecikmedir ve biri bu kontrolü yapana kadar görünmez (Bölüm 37).

Biri, bir ara adımı kaldırmak için destek taleplerini okuyan ajana para iadesi aracını vermeyi önerecek. Cevap Bölüm 36’da ve bu cevabın bir argüman değil, bir ölçüm — kendi saldırı başarı oranınız — olması gerekiyor.

Bir sağlayıcı seçmek, gecikme kararı olmadan önce bir hukuk kararıdır. Bu, TCKN ve IBAN işleyen bir Türk şirketi; dolayısıyla ABD’de barındırılan bir sağlayıcıyı kullanmak KVKK 9. madde kapsamında yurt dışına aktarım sayılır ve bunun sonuçları Bölüm 38.1’de. O bölüm yazıldığında Kişisel Verileri Koruma Kurulu hiçbir ülke için yeterlilik kararı vermemişti; yani yol, yayımlanmış standart sözleşme ve onun beş iş günlük bildirimi. Standart sözleşme, Kurulun ilan ettiği metin üzerinde hiçbir değişiklik yapılmadan kullanılmak zorunda (Yurt dışına aktarım yönetmeliği, 14. madde, 3. fıkra); sağlayıcının kendi veri işleme sözleşmesi ya da AB’nin standart sözleşme maddeleri onun yerine geçmez. Buna güvenmeden önce Kurumun sayfasını kontrol edin. Kişisel veriyi sınırda tokenlaştırmak da soruyu ortadan kaldırmaz: dedektör sabit biçimli tanımlayıcıları yakalar, adları, adresleri ya da müşterilerin kendileri hakkında yazdıklarını değil. Şirket bir banka, ödeme kuruluşu ya da sigortacıysa sektörel düzenleme bunun da önüne geçer ve soru belki tartışmaya açık bile olmaz. Tüm sağlayıcıların önündeki tek geçit burada yardımcı oluyor — o seçimin kaydedildiği ve uygulandığı tek yer o — ama seçimi o yapmıyor ve bunu atlayan bir tasarım incelemesi tasarım incelemesi değildir.

Model, siz fark etmeden yükseltilecek. Bölüm 32’nin takma ad problemi: yalnızca istenen modeli kaydederseniz yükseltmeyi haftalar sonra bir kalite gerilemesinden öğrenirsiniz. Hem istenen hem cevap veren modeli kaydetmek yükseltmeyi önlemez — onu önleyen şey sürümü sabitlemektir — ama yükseltmeyi aynı gün saptamanızı ve incelemenizi sağlayan şey budur (Bölüm 34).

Neyi farklı yapardık, tek satırda: ajanı yazmadan önce değerlendirmeyi ve saldırıyı yazın. İkisi de başlangıçta ucuz ve sistem çalıştıktan sonra ikisi de yazılmıyor.

39.7 Bitirme projesi

Bitirme projeniz bu bölümün küçük sürümü: bir ajan, en az bir gerçek araç, sistemle birlikte teslim edilen bir değerlendirme düzeneği ve verdiğiniz kararlar için yazılmış bir gerekçe.

Görev tanımı, teslimatlar, değerlendirme ölçütleri ve takvim Ek D’de. Burada, iyi giden projeleri diğerlerinden ayıran özelliklere bakalım:

  • Kapsamı erkenden daraltıyorlar. Düzgün yapılmış tek bir görev, yalnızca gösterimlik yapılmış üç görevden iyidir. Yapılmayacaklar listesi son değil ilk üründür.
  • Bir şey ölçüyorlar. Gerçekten ölçülmüş tek bir sayısı olan bir proje — olumsuz bir sonuç dâhil — cilalı bir gösterimi olandan güçlüdür; bu kitap önceki otuz sekiz bölüm boyunca bunu savundu.
  • İşe yaramayanı raporluyorlar. Bölüm 22’nin asimetrisi ödevler için de geçerli: kötü bir sayının üstüne gidilir, iyi bir sayı ise doğrudan yayımlanır. Denediğiniz ve başarısız olan şeyi söyleyin.
  • İddiayı kanıttan ayırıyorlar. “Ajanımız destek taleplerinin %80’ini çözüyor” iddiası için bir küme, “çözüldü”nün bir tanımı ve bir güven aralığı gerekir.

Bu ders bilgisayar mühendisliği dışından gelen mühendislik ve istatistik öğrencilerine yönelik; bu yüzden notlandırma kodun zarafetine değil, akıl yürütmeye bakar. Bir yaklaşımın neden seçildiğine dair açık bir argüman ve onu çürütebilecek bir ölçüm, teslim edilecek şeydir.

39.8 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. Bunlar sentez soruları: her biri iki ya da üç bölümü bir araya getiriyor; bitirme projesinin sizden isteyeceği de bu.

Erişim; nedeni kişisel tercih değil, gecikme hesabı.

Bölüm 31 7.427 token bağlamda wall-clock süresinin %91,0’ının ilk karakterden önce geçtiğini ve pencere doldukça decode’un saniyede 189’dan 141 token’a düştüğünü ölçtü. Uzun bağlamın bedeli iki kez ödeniyor: bir kez prefill’de, sonra üretilen her token’da yeniden.

Tüm politikaları prompt’a doldurmak daha basit, ama baskın gecikme terimini de olabildiğince büyütüyor. Erişim, ayrıca değerlendirmeniz gereken bir bileşen ekliyor (Bölüm 19) ve o terimi kaldırıyor — üstelik gereksinimin zaten istediği atıfları da veriyor.

Para iadesi servisinde, kodda zorunlu kılınmış olarak.

Müşteri mesajlarını okuyan bir ajan saldırgan denetimindeki girdiyi okuyor — herkes bir destek talebi açıp içine istediğini yazabilir — ve Bölüm 36, yerleştirilmiş bir talimatın 25 koşunun 25’inde bir ajana dışa dönük bir araç çağırttığını, biçimlendirme koduna (markup) gizlenmiş bir varyantın da 25 koşunun 23’ünde işe yaradığını ölçtü. Prompt’a yazılmış bir tavan, saldırganın da yazabildiği bir bileşene yapılmış bir ricadır.

Daha güçlü hamle yapısal: destek taleplerini okuyan ajana para iadesi aracını hiç vermeyin. Bu, riski hafifletmek yerine çifti (aynı ajanda güvenilmeyen girdi ile tehlikeli araç) doğrudan kırar. Bedeli fazladan bir ara adımdır; bu yıl satın alacağınız en ucuz güvenlik budur.

Bir şeyin bozuk olduğunu, bir şeyin daha iyi olduğunu değil.

Bölüm 22’nin boyutlandırması: %80 doğru bir sistemde %80 güçle 100 madde 13,4 puanlık, 1.000 madde 4,8 puanlık bir farkı ayırt edebiliyor. Gerçek iyileştirmelerin çoğu 2–5 puan, dolayısıyla yüz maddelik bir küme — eşleştirilmemiş bir karşılaştırma olarak — görmek üzere kurulduğu şeyi göremiyor.

Ama bir kapı iki koşuyu aynı maddeler üzerinde karşılaştırır ve Bölüm 35’in yeniden örneklemesinde 100 maddede 1 puanlık bir eşik, 3,4 puanlık bir gerilemeyi denemelerin %99,4’ünde yakaladı. Bu ölçüm gözlenen düşüşü gerçek etki kabul ediyor; maddeler prompt’lar arasında eşleştirilemediği için de eşleştirilmiş bir kapıyı ölçmüyor, eşiği örnekliyor. Aynı küme, farklı soru: onu bir kapı olarak kullanın, popülasyonda B sürümünün A’dan daha iyi olduğunun kanıtı olarak değil.

Değerlendirmeyi ve saldırıyı.

İkisi de hiçbir şey çalışmadan önce ucuz ve ikisi de sonradan yazılmıyor. Değerlendirme size “bitti” demenin bir tanımını ve bu tanımı koruyan kapıyı veriyor (Bölüm 35); saldırı ise taşıdığınız risk için bir sayı veriyor (Bölüm 36). O risk, bir paydaşla yapılan konuşmadan ancak bir sayı olarak sağ çıkabilir.

Diğer her şey — erişim, araçlar, döngü, izleme — herhangi bir sırayla kurulabilir. Bu ikisi kurulamaz, çünkü sistem çalıştıktan sonra onları yazma güdüsü kayboluyor.

Bir inceleme kuyruğu değil, bir golden path.

Her ajanı incelemek takım sayısıyla doğrusal ölçekleniyor ve sonra duruyor. Değerlendirme kapısının, izlemenin, kişisel veri sınırının ve araç sınıflandırmasının zaten bağlanmış olduğu bir şablon depo, uyumlu yolu en hızlı yol yapıyor; yönetişimin bir teslim tarihiyle karşılaşınca ayakta kalan tek biçimi de bu.

Bir de kimsenin sahiplenmek istemediği bir ürün: bir ajan kayıt defteri — ajan başına bir satır, araçları, veri erişimi, sahibi, hukuki dayanağı ve geri alınabilirlik profiliyle. Her denetimin, olayın ve maliyet incelemesinin ona ihtiyacı var ve olaydan sonra güvenilir biçimde yeniden kurulamaz: en fazla, ayakta kalan başka kayıtların (fatura, erişim logları) izin verdiği parçalar toplanabilir — Bölüm 34’ün maliyet boyutlarıyla aynı sınır.

Sırayla, her ölçüm aracının göremediği şeye.

Kapının yeşil olması yalnızca sizin süitiniz için geçerli; bu da süitin neyi kapsadığına dair bir iddia — izlere gidin, şikâyet edilen koşuları bulun ve arıza sınıfının kümede hiç var olup olmadığını kontrol edin (Bölüm 35). Pano yalnızca taşıma katmanı (isteğin teknik olarak hatasız tamamlanması) için yeşil: Bölüm 34’ün saptaması, status=OK olan bir span’in kendinden emin yanlış bir cevabı memnuniyetle içerdiği.

Sonra ilginç nedenlerden önce sıkıcı olanı eleyin: gözlenen koşudan koşuya aralığın içindeki bir değişim, müdahaleye atfedilmeden önce daha fazla kanıt ister — daha çok koşu, eşleştirilmiş bir karşılaştırma. Bölüm 35 koşular arası 0,26 puanlık bir sd ve beş koşuluk 0,60 puanlık bir aralık ölçtü; tek bir yeni koşu aralıkla karşılaştırılır, kapı eşiği ise sd’den türetilir. Hangisini aktardığınızı söyleyin.

39.9 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Aşağıdaki sorular bu kitabın baştan sona kullandığı iki güvenilir açık kaynakta tekrar ediyor. Bu bölümün cevapları, kitapta daha önce yapılmış ölçümlerin sentezleri.

39.9.1 Bir sistem tasarlayabilir misiniz diye sınayanlar

S: Bir Türk e-ticaret şirketi için bir müşteri destek ajanı tasarlayın.

Yapılmayacaklarla başlayın, çünkü arıza sınıflarını kaldırıyorlar: ajanın bir iş günü içinde geri alınamayan hiçbir eylemi olmayacak; sipariş, kargo ve iade dışında kapsam olmayacak; insana aktarma yolu her zaman açık olacak. Sonra biçim: gecikme nedeniyle uzun bağlam yerine politika belgeleri üzerinde erişim; maliyet atfı ve sürüm sabitleme için bir geçit; konuşmanın ortasındaki bir dağıtımın atlatılabilmesi için dayanıklı durum; aramaların çalışmaya devam etmesi için sınırda geri döndürülebilir biçimde tokenlaştırılmış kişisel veri; ve para iadesi servisinde zorunlu kılınan para iadesi tavanı. Destek taleplerini okuyan ajan ise para iadesi aracını hiç tutmaz.

S: Kurmadan önce ne ölçerdiniz?

Başlangıçta yeni hiçbir şey; bilineni bir araya getirin. Gecikmenizin hangi yarıda olduğunu bulmak için prefill’e karşı decode; prompt ve tamamlama token sayıları, çünkü bu uzunlukta prompt’larda ödediğinizin çoğu yazmanın değil okumanın parası; içeriği loglamayı (kütükleme) açmadan önce koşu başına span ve bayt; hedeflediğiniz iyileştirmenin gerektirdiği değerlendirme kümesi boyutu; kişisel veri dedektörünüzün recall’u kadar precision’ı; ve kendi saldırı başarı oranınız. Bir araya getirilmiş bütçede boşluk kalan yer, ilk deneyin gideceği yer.

S: Daha küçük bir model kullanıp kullanmayacağınıza nasıl karar verirsiniz?

Bir benchmark (kıyaslama) tablosuna bakarak değil. Kararı kendi süitiniz üzerinde yapılan bir ölçüme dayandırın ve önceden verilen bir yönlendirme kararı yerine bir cascade’i tercih edin: küçük modelle cevaplayın ve çalışma zamanındaki bir geçerlilik kontrolü başarısız olduğunda büyük modele aktarın. Çünkü doğrulayıcı, istek anında gerçekten elinizde olan bir sinyaldir; öngörülen zorluk ise bir tahmindir. Bölüm 12, sözel güveni bir modelin kendi hatalarının dedektörü olarak AUROC 0,667’de ölçtü; fine-tuning uygulanmış bir sınıflandırıcının (BERTurk) kendi etiket olasılığı ise 0,843’e ulaştı. Bu gerçek bir sinyal, ama körü körüne yönlendirmeye yetmiyor.

39.9.2 Bir platform işletip işletmediğinizi sınayanlar

S: Beş takım ajan kurmak istiyor. Neyi merkezîleştirirsiniz?

Tek geçiş noktasını (choke point: bütün model çağrılarının geçtiği tek denetim noktası) ve golden path’i. Maliyet atfı, sürüm sabitleme ve sınırlar için tek bir geçit; değerlendirme kapısı, izleme, kişisel veri sınırı ve araç sınıflandırması önceden bağlanmış bir şablon depo; ve her ajanın araçlarını, veri erişimini ve sahibini listeleyen bir ajan kayıt defteri. İncelemeyi merkezîleştirmeyin — her şeyi inceleyen bir platform takımı yapısı gereği bir darboğazdır. Onun yerine güvenli yolu hızlı yol yapın.

S: Ölçekte örgütsel olarak ilk bozulan şey nedir?

Bir takımın değiştirdiği bir aracın başka bir takımın ajanını bozması, çünkü araç tanımları paylaşılan bağlam ve kimse onlara bir arayüz gibi davranmadı. Sürümleyin, sahip verin ve değişiklikleri bağımlılık yükseltmeleri gibi inceleyin. Kısa süre sonra da kimse hangi ajanların var olduğunu ve neye erişebildiklerini söyleyemez. Bu, ajan kayıt defterinin işidir; baştan tutulmamışsa sonradan güvenilir biçimde kurulamaz, ancak ayakta kalan başka kayıtların izin verdiği parçalar toplanabilir.

S: Ajan platformunuzun maliyetleri üçe katlandı. Nedenini nasıl bulursunuz?

Ancak boyutları — kullanıcı, takım, özellik, ortam ve sonuç — önceden kaydettiyseniz bulabilirsiniz; kaydetmediğiniz şeye göre gruplama yapamazsınız. Sonra olağan şüphelileri sırayla kontrol edin: bir yerde açılmış içerik loglaması, bir bozulmayı büyüten yeniden denemeler, sizi önbelleğin bayt bayt aynı ön ekinden düşüren prompt büyümesi ya da hiçbir tavana çarpmayan bir döngü. Oturum başına değil çözülen destek talebi başına maliyet raporlayın, yoksa kimsenin tamamlamadığı bir özellik ucuz görünecek.

39.10 2026 alet çantası

Bu bölüm hiçbir deney çalıştırmıyor; dolayısıyla bir ölçüm yığını da yok. İkinci tablo bir araya getirilmiş küme — Kısım VI boyunca adlandırılan araçlar, katman sırasıyla (benimseme sırası değil: yukarıda söylendiği gibi değerlendirme ve saldırı ajandan önce gelir).

Yeni yığın yok
kütüphane kullanılan sürüm burada ne işe yarıyor
— — bu bölüm hiçbir ölçüm yapmıyor; her sayı, onu yapan bölüme atıflı

Platformun genel biçimi, önceki bölümlerin önerdiği araçlardan oluşan bir okuma listesi olarak:

Bir araya getirilmiş platform, katman katman
katman temsilî seçenekler bölüm
servis vllm, sglang, yerel çalışma için ollama Bölüm 31
geçit maliyet atfı ve sürüm sabitleme için litellm ve eşdeğerleri Bölüm 32
dayanıklı yürütme durumu belirli adımlarda kaydeden bir iş akışı motoru: temporalio (Temporal), restate-sdk (Restate) Bölüm 33
izleme opentelemetry-sdk artı arize-phoenix ya da langfuse gibi bir arayüz Bölüm 34
değerlendirme kapısı CI’da promptfoo, inspect-ai ya da deepeval Bölüm 35
güvenlik sınaması agentdojo, PyRIT, garak Bölüm 36
korkuluklar kişisel veri için presidio; kodda politika zorunlu kılma Bölüm 37

39.11 Lab: sistemden önce bütçeyi kurun

39.11.1 Adım 1 — yapılmayacakları yazın

Bitirme projenizin ne yapmayacağını söyleyen dört ila altı cümle. Bunları ekip içinde dolaştırın. Her anlaşmazlık şimdi, onları değiştirmenin bedava olduğu anda yüzeye çıkar.

39.11.2 Adım 2 — ajandan önce değerlendirmeyi yazın

İyi bir cevabın ne olacağıyla birlikte elli gerçek vaka. Ne kadar sürdüğünü not edin; o sayı, sisteminizin çalışıp çalışmadığını bilmenin gerçek maliyeti.

39.11.3 Adım 3 — bütçeyi bu kitabın sayılarından bir araya getirin

Gecikme, token hacmi, telemetri baytları, değerlendirme kümesi boyutu, korkuluk precision’ı, saldırı başarısı — Bölüm 39.4’teki bütçe tablosunun satırları. Her birine bölümüyle atıf verin. Dolduramadığınız her hücre ilk deneyinizdir; onu ölçmenin ne gerektireceğini yazın.

39.11.4 Adım 4 — reddedilen alternatifiyle birlikte üç mimari karar kaydı yazın

Karar, alternatifler, sonuçlar. Reddedilenler sütunu, çürütülmek üzere zayıflatılmış bir karşı görüş (straw man) değil, gerçekten savunulabilir bir argüman içermeli. Diğer tarafı savunamıyorsanız, kararı düşünmeyi bitirmemişsinizdir.

39.11.5 Adım 5 — araçlarınızı sınıflandırın ve bir sınırı modelin dışında zorunlu kılın

Her aracı Bölüm 37’nin geri alınabilirlik sınıflarına koyun, sonra aracın uygulamasına sayısal ya da izin listesi tabanlı bir sınır ekleyin ve ikna edici bir prompt’un onu kımıldatamadığını kanıtlayan bir test yazın.

39.11.6 Adım 6 — kendi sisteminize saldırın ve oranı kaydedin

Dört payload çerçevelemesi, her biri yirmi beş koşu; bir de payload’suz temiz bir kontrol girdisi (Bölüm 36). Ne söylerse söylesin sayıyı raporunuza koyun.

39.11.7 Adım 7 — kapınızın gürültü tabanını ölçün ve bir eşik belirleyin

Beş özdeş koşu. Koşular arası aralığın (range: en yüksek ile en düşük puan arasındaki fark) yanında sd’yi de kaydedin ve eşiği aralığın hemen üstüne değil, kabaca 4 × sd’ye koyun (Bölüm 35). Sonra yanlış engelleme oranını, onu güvenilir biçimde kestirmeye yetecek sayıda no-op (hiçbir şeyi değiştirmeyen) değişiklikte ölçün: beşte sıfır engelleme bile %95 Wilson üst sınırını %43’te bırakır.

39.11.8 Teslim edilecekler

Yapılmayacaklarınız; ne kadar sürdüğüyle birlikte değerlendirme kümesi; her hücresi atıflı ya da boşluk olarak işaretlenmiş bütçe tablosu; üç mimari karar kaydı; zorunlu kılınmış bir sınır ve testiyle birlikte araç sınıflandırması; temiz kontrolle birlikte saldırı başarı oranlarınız; ve seçtiğiniz eşik ve onun ölçülmüş yanlış engelleme oranıyla birlikte ölçtüğünüz gürültü tabanı.

39.12 Alıştırmalar

  1. Size sorulacak mimari karar kaydı. Bitirme projenizde en çok sonuç doğuran karar için kaydı yazın; reddettiğiniz alternatifi ve onun lehine bulduğunuz, çürütmesi en zor argümanı dâhil ederek.

  2. 100× maliyet modeli. Trafiğin yüz katına çıktığı durum için sisteminizin maliyet modelini kurun. İlk neyin bozulduğunu ve bunun para mı, gecikme mi yoksa birinin dikkati mi olduğunu adlandırın.

  3. Boşlukları olan bütçe. Kendi sisteminiz için Bölüm 39.4’ün bütçe tablosunu kurun. Kaç hücreyi bu kitaptan, kaçını kendi ölçümlerinizden doldurabildiğinizi ve kaçının hâlâ tahmin olduğunu raporlayın.

  4. Bir çifti kırın. Tasarımınızda güvenilmeyen içerik okuyan ve dışa dönük bir araç tutan bir ajan bulun. Bölün ve hangi yeteneği yitirdiğinizi raporlayın (Bölüm 36).

  5. Kayıt defteri. İşlettiğiniz bir sistem için ajan kayıt defterini yazın — araçlar, veri erişimi, sahip, hukuki dayanak, geri alınabilirlik profili. Bölüm 39.5’teki satırı şablon olarak kullanın. Birine sormadan neyi cevaplayamadığınızı raporlayın.

  6. Golden path. Kurumunuzda yeni bir ajan için uyum gereksinimlerini alın ve onları varsayılan olarak karşılayan şablonu tasarlayın. Sonra şablonsuz yolun kaç gün sürdüğünü tahmin edin.

  7. Pre-mortem. Sisteminizde en olası bulduğunuz olay için olay sonrası raporu (postmortem), olay yaşanmadan önce yazın. Sonra onu önleyebilecek tek kontrolü uygulayın.

39.13 Daha derine

Okumadan önce: sisteminizin bütçe tablosunu ezberden yazmayı deneyin. Dolduramadığınız hücreler, yeniden okumanız gereken bölümleri gösterir.

Bu bölüm hiçbir yeni kaynağa atıf vermiyor — kitabın kendi kaynaklarını bir araya getiriyor. Aşağıdaki tablo bir kaynakça değil, bir okuma sırası.

Bitirme projesi için bir okuma sırası
şurada takıldıysanız şunu yeniden okuyun
kurmadan önce ne ölçüleceği Bölüm 22 ve Bölüm 30, sonra kapı için Bölüm 35
gecikmenin prompt’tan mı cevaptan mı geldiği Bölüm 31 ve özellikle prefill/decode ayrımı
bir sınırın nerede durması gerektiği sınıflandırma için Bölüm 37, prompt’un neden doğru yer olmadığı için Bölüm 36
hiçbir şey değişmediği hâlde kalitenin neden oynadığı gürültü tabanları için Bölüm 35, cevaplayan model için Bölüm 34
yükümlülüklerinizin ne olduğu Bölüm 38; tarihlerin değiştiğine dikkat edin
güvenli yolu hızlı yol yapmak yukarıdaki Bölüm 39.5 ve tek geçiş noktası için Bölüm 32

39.14 Akılda kalması gerekenler

  • Önce yapılmayacakları yazın. Her biri bir arıza sınıfını kaldırıyor ve bir özellik daha isteyen biri sonradan her birine itiraz edecek. Kimse aksi yönde emek harcamadan onlara karar vermek, yapacağınız en ucuz mimari iştir.

  • Gerçek bir reddedilen alternatifi olmayan bir mimari karar kaydı bir basın bültenidir. Diğer tarafı savunamıyorsanız karar henüz verilmemiştir.

  • Bir sistemi kurmadan önce, zaten elinizde olan ölçümlerden bütçeleyebilirsiniz. Gecikmeyi Bölüm 31’in prefill/decode ayrımından, token hacmini 890 prompt token’ına karşı 53 üretilmiş token’dan, telemetriyi koşu başına 4,8 span ve 3.167 bayttan, değerlendirme boyutunu Bölüm 22’nin 100 maddede 13,4 puanından, korkuluk precision’ını yalnızca örüntüyle elde edilen %40’tan, riski de Bölüm 36’nın %92–100 saldırı başarısından çıkarırsınız. Bütçede boşluk kalan yer, ilk deneyinizin gideceği yerdir.

  • Erişim, uzun bağlamı kişisel tercihle değil gecikme hesabıyla yener. Bölüm 31 7.427 token’da wall-clock süresinin %91,0’ının ilk karakterden önce geçtiğini ve decode’un saniyede 189’dan 141 token’a düştüğünü ölçtü.

  • Önemli olan her sınır modelin dışında zorunlu kılınır. Prompt’taki bir tavan bir ricadır ve daha güçlü hamle, güvenilmeyen girdi alan ajana tehlikeli aracı hiç vermemek — onu hafifletmek yerine çifti kırmak.

  • Değerlendirmeyi ve saldırıyı ajandan önce yazın. İkisi de başlangıçta ucuz, ikisi de sistem çalıştıktan sonra yazılmıyor ve geri kalanın kurulmaya değip değmediğine karar veren iki şey onlar.

  • Platform arızaları bir takvimle geliyor. İkinci takımda paylaşılan bir araç birini bozuyor; beşinci ajanda kimse neyin var olduğunu bilmiyor; onuncuda platform takımı darboğaz. Sahipleri olan sürümlenmiş araçlar, bir ajan kayıt defteri ve bir golden path — bu sırayla.

  • Her şeyi inceleyen bir platform takımı doğrusal ölçeklenir ve sonra durur. Onun yerine uyumlu yolu en hızlı yol yapın, çünkü bir teslim tarihiyle karşılaşınca ayakta kalan tek yönetişim bu.

  • İddiayı kanıtıyla raporlayın. “Destek taleplerinin %80’ini çözüyor” iddiası için bir küme, “çözüldü”nün bir tanımı ve bir güven aralığı gerekir. Bu kitabın Bölüm 22’den beri savunduğu standart bu ve bitirme projesinin notlandırıldığı şey de bu.

Buradan sonrası sizin: görev tanımı, teslimatlar, değerlendirme ölçütleri ve takvimle birlikte bitirme projesinin ayrıntıları Ek D’de; bu bölümün bütçe tablosu, projenizin ilk teslim edilecek belgesi.