Üretimde iz kaydı, maliyet ve sürüm künyesi
Çalışan bir LLM hattının izini, maliyet kalemlerini ve sürüm künyesini kurmayı; yayın kararını görev setine bağlamayı öğretir.
Önkoşul: Large Language Model, Retrieval-Augmented Generation
BU DERSİN SONUNDA
- Bir LLM isteğinin iz kaydında hangi alanların zorunlu olduğunu belirlemek
- Maliyet ve gecikme kalemlerini mimari kaldıraçlarla eşleştirmek
- İstem, model ve dizin sürümünü tek künyede toplayıp yayın kapısı kurmak
- Bir kalite düşüşünü izler üzerinden tek bir sürüm değişikliğine kadar daraltmak
- 1
Teori
Kavramın çalışma mantığı
- 2
Örnek
Gerçek bir senaryo üzerinde gösterim
- 3
Lab
Uygulamalı alıştırma
- 4
Test
Kısa ölçüm
- 5
Proje
Rotadaki projeye katkı
Kısa cevap
LLMOps, çalışan bir dil modeli hattının izlenebilir, bütçelenebilir ve geri alınabilir kalmasını sağlayan işletim disiplinidir. Çekirdeği tek bir kuraldır: her istek, kendisini üreten yapılandırmanın künyesiyle birlikte kaydedilir. Künye yoksa ne maliyet bir mimari karara, ne kalite düşüşü bir değişikliğe bağlanabilir.
Teori: klasik MLOps neden yetmiyor#
Klasik bir makine öğrenmesi hattında model tek bir eğitilmiş artefakttır, girdi şeması sabittir ve çıktı bir sınıf ya da sayıdır. Bu yüzden izleme dar bir çerçeveye oturur: girdi dağılımının kaymasını ve birkaç sabit metriği izlersiniz. Dil modeli hattında bu üç varsayımın hiçbiri geçerli değildir. Girdi serbest metindir, çıktı serbest metindir ve aynı girdi örnekleme nedeniyle farklı çıktı verebilir; örnekleme kapatılsa bile toplu işleme ve donanım farkları birebir tekrarlanabilirliği garanti etmez. Üstelik "doğru cevap" tanımı artık hattın içinde değil görevin tanımındadır. Bir metrik panosu bir şeyin bozulduğunu söyleyebilir ama nedenini söyleyemez, çünkü çıktıyı belirleyen şey tek bir ağırlık dosyası değildir.
Bir LLM hattında en az üç hareketli parça vardır: istem şablonu, model kimliği ile örnekleme ayarları ve geri getirme dizini (araç kullanıyorsanız araç sürümleri de eklenir). Bu parçalardan biri değiştiğinde diğerleri için topladığınız ölçüm geçersiz olur. "Dün iyiydi, bugün kötü" sorusu ancak üç parçanın sürümü her izde birlikte duruyorsa cevaplanabilir.
İz kaydı: hangi alan neyi teşhis eder#
| İz alanı | Ne yazılır | Neyi teşhis eder |
|---|---|---|
| İstek kimliği | Oturum ve istek için tekil kimlik | Bir kullanıcı şikayetini tek bir çağrıya bağlamak |
| Yapılandırma künyesi | İstem şablonu sürümü, model kimliği, örnekleme ayarları, dizin sürümü | Kalite düşüşünün hangi değişiklikten geldiği |
| Geri getirme kaydı | Getirilen parça kimlikleri ve sıraları | Hatanın geri getirmede mi üretimde mi olduğu |
| Token sayaçları | Girdi, çıktı ve önbellekten okunan token sayısı | Maliyet kalemini tek tek isteklere dağıtmak |
| Adım gecikmeleri | Geri getirme, model çağrısı, araç çağrısı süreleri ayrı ayrı | Darboğazın hangi adımda olduğu |
| Sonlanma nedeni | Normal bitiş, uzunluk sınırı, araç hatası, güvenlik kesmesi | Sessizce yarım kalan cevapların oranı |
| Geri bildirim bağı | Kullanıcı işareti veya insan denetim notunun istek kimliği | Otomatik ölçümün gerçek memnuniyetle ilişkisi |
{
"istek_kimligi": "req-8f31c2",
"oturum_kimligi": "ses-4410",
"kunye": {
"istem_surumu": "destek-ozet@7",
"model_kimligi": "saglayici/model-adi@surum",
"ornekleme": { "sicaklik": 0.2, "ust_p": 0.9, "azami_cikti": 400 },
"dizin_surumu": "bilgi-tabani@41",
"getirilecek_parca_sayisi": 3
},
"geri_getirme": ["prosedur-izin-v3#madde-7b", "sss-izin#s12", "prosedur-izin-v3#madde-9"],
"token": { "girdi": 1840, "cikti": 210, "onbellekten": 1200 },
"gecikme_ms": { "geri_getirme": 120, "model": 1450, "toplam": 1620 },
"sonlanma": "normal",
"geri_bildirim": null
}Maliyet ve gecikme: kalemi kaldıraca bağlamak#
Maliyet üç yerden gelir: girdi tokenı, çıktı tokenı ve çağrı sayısı. Girdi ile çıktı ayrı birim fiyatlandığı için ikisini tek bir "token maliyeti" altında toplamak hangi kaldıracın işe yaradığını gizler. Gecikme ise bu kalemlere aynı biçimde dağılmaz; çıktı tokenları ardışık üretildiği için toplam süreyi büyük ölçüde çıktı uzunluğu belirler, girdi uzunluğu ise ilk tokene kadar geçen süreyi etkiler. Bu ayrım önemli: girdiyi kısaltmak ile çıktıyı kısaltmak aynı kaleme dokunmaz. Bu yüzden bütçe tartışması pano üzerinden değil iz üzerinden yapılır; her isteğin sayacı ve künyesi elinizdeyse "hangi istem sürümü hangi soru tipinde bağlamı şişiriyor" sorusu gruplayarak cevaplanır.
- Bağlamı kırp: geri getirilen parça sayısını düşürmek girdi tokenını doğrudan düşürür. Kaliteyi bozup bozmadığını görev setinde ölç, tahminle karar verme.
- Çıktıyı kısalt: şema zorunlu kılmak ve gereksiz açıklama üretimini kapatmak hem maliyeti hem gecikmeyi düşürür, çünkü çıktı ardışık üretilir.
- Sabit öneki başa al: sistem istemi ve değişmeyen yönergeler istemin başında, değişken kısım sonda dursun. Önbellekleme desteği ancak değişmeyen önek üzerinde işe yarar.
- Adımı modele göre böl: yönlendirme, sınıflandırma, filtreleme gibi kolay adımları küçük bir modele ver, zor adımı büyüğüne bırak. Bölmenin doğruluğunu aynı görev setinde doğrula.
- Yeniden denemeyi görünür kıl: sessiz yeniden denemeler maliyeti çoğaltır ve gecikme dağılımının kuyruğunu bozar. Her deneme izde ayrı satır olsun.
- Akışı doğru konumlandır: akışlı çıktı toplam süreyi kısaltmaz, yalnızca kullanıcının beklediği süreyi böler. Bütçede ilk token süresi ile toplam süre ayrı ölçülür.
Yayın kararı: künyeden geri almaya#
- 1Künyeyi dondur
Yayına çıkacak istem şablonu, model kimliği, örnekleme ayarları ve dizin sürümünü tek bir sürüm etiketinde demetle. Bu demetin parçaları üretimde tek tek değiştirilemez olsun.
- 2Görev setinde kapı kur
Eski ve yeni künyeyi aynı görev setinde koştur. Kabul ölçütü yayından önce yazılı olsun; sonuç görüldükten sonra eşiği gevşetmek ölçümü ortadan kaldırır.
- 3Gölge koşu yap
Yeni künyeyi gerçek trafiğe cevap vermeden, örneklenmiş bir dilimde paralel koştur. İki cevabı yan yana kaydet; yalnızca belirgin şekilde ayrışan istekleri insan gözüyle incele.
- 4Kademeli aç
Trafiğin küçük bir dilimini yeni künyeye ver. İzlerde sonlanma nedeni dağılımını, gecikmenin en yavaş çeyreğini ve geri bildirim işaretlerini eski künyeyle karşılaştır.
- 5Geri alma yolunu açık tut
Eski künye çalışır durumda kalsın ve geri alma bir yapılandırma değişikliği olsun. Yeniden dağıtım gerektiren bir geri alma, gerektiğinde kullanılmaz.
Sık yapılan hata#
En yaygın hata gözlemlenebilirliği bir panoya indirmek: ortalama gecikme eğrisi ve toplam token grafiği. Ortalama, bu hatta en az iş gören istatistiklerden biridir; sorun neredeyse her zaman dağılımın kuyruğunda ve belirli soru tiplerinde yaşar. İkinci yaygın hata istemi üretimde elle düzeltmek. Sürüm numarası artırılmadan yapılan bir istem düzeltmesi, o ana kadar toplanmış bütün ölçümü yorumlanamaz hale getirir — çünkü izlerdeki künye artık gerçeği göstermez.
LAB · UYGULAMALI ALIŞTIRMA
Kendi hattınıza künyeli iz kaydı ekleyin
- 1Bir dil modeli çağrısı yapan kendi kodunuzu açın; yoksa çağrıyı taklit eden sahte bir işlev yazın (sabit bir metin döndürsün, token sayısını kelime sayısından tahmin etsin). Alıştırmanın konusu çağrının kendisi değil, çevresindeki kayıt.
- 2Dersteki iz alanları tablosunu şablon alıp her çağrıda tek satır JSON basın: istek kimliği, künye (istem sürümü, model kimliği, örnekleme ayarları, dizin sürümü), token sayaçları, adım gecikmeleri, sonlanma nedeni.
- 3Künyeyi kodun içine dağıtmak yerine tek bir yapılandırma nesnesinde toplayın ve istem şablonuna her elle dokunduğunuzda sürüm numarasını artırmayı kural yapın.
- 4Kendi verinizden 10 gerçek istek hazırlayın ve hattı iki farklı künyeyle koşturun; iki künye arasında yalnızca tek alanı değiştirin (örneğin geri getirilen parça sayısı ya da azami çıktı uzunluğu). Sahte işlev kullanıyorsanız bu alanı işleve gerçekten uygulatın (parça sayısı kadar metni girdiye ekletin, azami çıktı uzunluğunda döndürdüğü metni kesin); yoksa iki koşu aynı sayıları üretir.
- 5İki koşunun satırlarını künyeye göre gruplayıp karşılaştırın: girdi ve çıktı token toplamı, en yavaş iki isteğin gecikmesi, sonlanma nedeni dağılımı.
- 6Hangi alanın kararı verdirdiğini, hangi alanın hiç kullanılmadığını yazın. Kullanılmayanı izden çıkarın, eksik kalanı ekleyin ve künye şemasını dondurun.
Beklenen çıktı
Her isteği künyesine bağlayan tek satırlık iz şeması ve iki künyenin aynı istek setindeki token, gecikme ve sonlanma karşılaştırması.
Sık sorulan sorular
Her isteğin ham istem ve cevabını saklamak zorunda mıyım?
Hayır. Künye, token sayaçları, adım gecikmeleri ve sonlanma nedeni küçük alanlardır ve tam tutulabilir; teşhis gücünün büyük kısmı buradan gelir. Ham gövdeyi ise örnekleyerek saklamak, buna ek olarak hata dönen ve şikayet gelen isteklerin tamamını tutmak yaygın bir dengedir. Kararı depolama değil gizlilik yükümlülüğünüz belirler.
İstem şablonlarını kodla aynı depoda mı sürümlemeliyim, ayrı bir yerden mi yayınlamalıyım?
İkisi de çalışır, ama takas farklıdır. Kodla aynı depoda sürümlemek izlenebilirliği bedava verir, düzeltme hızını dağıtım süresine bağlar. Ayrı yayınlamak düzeltmeyi hızlandırır, karşılığında sürüm kimliğini izin içine yazmayı size bırakır. Hangisini seçerseniz künye zorunludur; künyesiz hızlı düzeltme, geçmiş ölçümü siler.
Gölge koşu her isteği iki kez çalıştırmak demek değil mi?
Evet, ek çağrı üretir. Bu yüzden tüm trafikte değil örneklenmiş bir dilimde koşturulur ve süresi baştan sınırlanır. Yerinde kullanım ölçütü şudur: değişiklik geri getirme, güvenlik veya cevap biçimi gibi kullanıcıya doğrudan yansıyan bir yeri etkiliyorsa gölge koşunun maliyeti, hatalı bir yayını geri almanın maliyetinden düşüktür. Yalnızca metin düzeltmesi gibi küçük değişiklikler için görev seti kapısı yeter.
LEARN
Generative AI Engineer rotasına devam et
Dersler tek başına da okunabilir, ama sıralı ilerlemek önkoşul boşluklarını kapatır.