· kaynak dev.to (home feed)
İncelediğiniz prompt, yayınladığınız prompt değildir: context assembly üzerine bir dev.to yazısı uyarıyor
Bir dev.to yazısı, üretim ortamındaki LLM promptlarının istek anında, kod incelemesinde hiç görünmeyen kaynaklardan birleştirildiğini savunuyor ve ekipleri tam derlenmiş isteği bir build artifact gibi parmak iziyle (fingerprint) işaretlemeye çağırıyor.

Bir dev.to yazısı, ekiplerin versiyon kontrolünde incelediği promptun üretimde büyük bir dil modeline (LLM) gerçekte ulaşan şeyin yalnızca bir parçası olduğunu, ikisi arasındaki bu açıklığın ise açıklanamayan kalite gerilemelerinin tekrarlayan bir kaynağı olduğunu savunuyor.
Yayınlanan şey yazılmış değil, birleştirilmiştir
Yazının çerçevesine göre tipik bir pull request, bir prompt şablonunda 30 satırlık bir değişiklik içerirken; buna karşılık gelen üretim isteği, istek anında altı kaynaktan birleştirilmiş yaklaşık 40.000 token taşıyor — bunların dördü o hafta değişmiş durumda ve hiçbiri pull request'te görünmüyor. Şablon git'te duruyor ve incelemeye giriyor; context'i birleştiren kod yolları ise release artifact olarak ele alınmıyor.
Yazar Dima Kruglov, RAG artı araçlar (tools) içeren bir sistemde bir isteğe tipik olarak nelerin girdiğini listeliyor: sistem şablonu, kendi programına göre yeniden indekslenen bir indeksten gelen top-k erişilen parçalar, açıklamaları fiilen aracı en son düzenleyen kişinin yazdığı prompt metni olan tool JSON şemaları, başka bir model çağrısıyla üretilen konuşma özeti, bir kullanıcı profili veya tenant yapılandırma bloğu ve runtime'da bir seçici tarafından belirlenen few-shot örnekleri. Her biri kendi versiyonu ve dağıtım temposu olan bir bağımlılık. Biri yeniden indekslediğinde ya da bir backend mühendisi bir tool parametresinin adını değiştirdiğinde hiçbir prompt incelemesi tetiklenmiyor. Kruglov'un yazdığına göre sonuç şu: Kalite bir salı günü düşüyor ve hiç kod yayınlanmamışsa, incelenecek bir diff yok.
Modelin gerçekte gördüğünü hash'leyin
Merkezi öneri, birleştirilmiş promptu bir build çıktısı olarak ele almak. Model davranışını değiştirebilecek girdiler üzerinde bir içerik hash'i hesaplayın — model kimliği ve versiyonu, şablon versiyonu, sorgu değil indeks build'inin erişim (retrieval) snapshot kimliği, tam derlenmiş prompt ve önemli olan decoding parametreleri — ve bunu her trace ile birlikte kaydedin.
Parmak izleri (fingerprint) her zaman saklanmalıyken, tam derlenmiş promptlar yalnızca örneklemeli (sampled) veya sansürlenmiş (redacted) biçimde tutulmalı; ne kadar tam metin saklanacağı seçimi, hata ayıklama ihtiyaçları değil uyumluluk (compliance) kuralları tarafından belirlenmeli. Kruglov ayrıca yanlış şeyleri hash'lemeye karşı uyarıyor: bir zaman damgası, istek kimliği ya da kullanıcıya özel selamlama içeren bir parmak izi neredeyse sıfır çakışma oranına ve sıfır tanısal değere sahiptir. Her istekte değişen bir prompt hash'ini kovalayıp bir gün harcayan, sonunda suçlunun bir locale (yerel ayar) string'i olduğunu fark eden bir ekimden bahsediyor.
Güven seviyeleri ve bütçelerle bir assembler
Yazıya göre bir framework gerekmiyor — bir assembler üç özellik gerektiriyor. Her bölüm bir güven seviyesi taşımalı, her bölüm bir çıkarma (eviction) önceliği taşımalı ve token bütçesini aşan sabitlenmiş (pinned) bir bölüm sessizce kırpılmak yerine sert bir hata fırlatmalı.
Eşlik eden Python taslağı, erişilen metni (retrieval), tool çıktısını ve kullanıcı yüklemelerini güvenilmez olarak işaretliyor ve "önceki talimatları yoksay" gibi talimat benzeri ifadeleri filtreleyen bir regex ekranından geçiriyor; Kruglov bunu bir garanti değil kaba bir buluşsal yöntem (heuristic) olarak nitelendiriyor ve isabetler kaydedilip daha katı bir yola yönlendiriliyor. Bütçe sıkıştığında önce daha düşük öncelikli bölümler bırakılıyor. İki tasarım tercihi öne çıkıyor: bölümler özgün ekleme sıralarına göre derleniyor, çünkü özdeş içeriği yeniden sıralamak model davranışını değiştiriyor ve evaluation deltalarını nedenlendirilemez hale getiriyor; pinned bayrağı ise bütçe aşımını bozuk çıktı yerine bir istisnaya dönüştürüyor.
Neden önemli
Yazı, standart bir LLMOps yığınının — evals, tracing, bir gateway — yakalayamadığı bir başarısızlık modunu tarif ediyor, çünkü incelenen artifact ile yayınlanan artifact farklı nesneler. Tam birleştirilmiş isteğin parmak iziyle işaretlenmesi, bir olay sırasında "kalite düştü ama hiçbir şey yayınlanmadı" sorusunu tek bir sorguyla yanıtlanabilir kılıyor. Ayrıca yönetişimi (governance) yeniden çerçeveliyor: erişim snapshotları, tool şemaları ve runtime seçicileri promptun versiyonlanmış bağımlılıkları haline geliyor ve injection taraması ile context bütçesi zorlaması gibi kaygılar, assembly katmanına taşınıyor — orada sonradan keşfedilmek yerine deterministik biçimde zorlanabilirler.
- #llmops
- #prompt-engineering
- #observability
- #rag
- #ai-engineering