Stand-up'ta en çok duyduğum cümle şu: "Prompt'ları zaten versiyonluyoruz. Git'teler."
Sonra bir cuma olur. Teklif e-postası ödeme koşullarını düşürür. Kimse kod göndermemiştir. Model değişmemiştir. Main'de salı günkü prompt durur — ama canlı ortam salı günkü prompt'u çalıştırmamıştır. Biri tedarikçi konsolunda bir string'i düzenlemiştir, ya da hiç sabitlenmemiş bir adayı birleştirmiştir, ya da bir ajanın çoktan izlediği taslakta "yalnızca ifadeyi" oynamıştır. Git yanlış değildir. Git başka bir soruyu cevaplamıştır.
Git, depoda neyin değiştiğini söyler. Prompt versiyonlama, neyin çalıştığını söyler.
Neden'i — üç disiplin, kırılan yerler — prompt versiyonlama nedir yazısında. Burası nasıl: sabitle, test et, yayına al, geri al. Bir commit'i yayın sanmadan.
Prompt versiyonlama nedir?
Prompt versiyonlama, bir dil modelinin gerçekten çalıştırdığı prompt'un değiştirilemez tarihidir. Bir aday oluşturursunuz, test edersiniz, yayına alırsınız, yanlışsa önceki versiyonu geri getirirsiniz. Artefakt bir dosya değildir. Kimliği, hash'i, notu ve onu kullanan çalışmanın üzerindeki pimi olan, yayımlanabilir bir birimdir.
Salı günkü çıktı salı günkü prompt'a bağlanamıyorsa prompt versiyonlamanız yoktur. Bir taslak klasörünüz vardır.
Prompt'ları Git'e koymak neden hâlâ prompt versiyonlama değildir
Git, yapması için kurulduğu işte iyidir: kaynak tarihi, diff incelemesi, kodda ikili arama. Prompt'lar orada yaşamalı. Asıl hata, o tarihi canlı ortam kaydı sanmaktır.
İşletmeye başladığınız ilk hafta üç boşluk çıkar:
- Commit, pim değildir. Main'deki dosya en son elyazmasıdır. Canlı bir çalışma belirli bir baskıya ihtiyaç duyar. Ajan "dağıtım anında depoda ne varsa onu" çözüyorsa, bir sonraki birleştirmeden sonra müşteri e-postasını hangi ifadenin ürettiğini söyleyemezsiniz.
- Revert, geri alma değildir. Prompt'u git ile geri getirmek uygulama kodu göndermek, dağıtımı beklemek, geri aldığınız string'in o gün çalışan string olduğuna inanmak demektir. Prompt geri alması, bilinen bir versiyonu terfi ettirmek olmalıdır — saniyeler, bir boru hattı değil.
- Depo konsolu görmez. İzlediğim en pahalı prompt düzenlemeleri bir pull request'ten geçmedi. Bir playground'da, bir tedarikçi panelinde, ya da birinin geri kopyalamayı unuttuğu "geçici" sistem prompt'unda oldu. Git hiç öğrenmedi.
Prompt versiyonlama ve Git
Git'i elyazması, prompt versiyonunu lot numaralı basılmış baskı gibi düşünün. Elyazması her öğleden sonra değişebilir. Müşteriye ulaşan baskı donmuş, etiketlenmiş ve geri getirilebilir olandır.
- Dosyada ne değişti? Git bunun için var. Prompt versiyonu da önceki versiyona karşı diff alır.
- Bu çalışma hangi prompt'u kullandı? Git, o log'u siz kurduysanız. Prompt versiyon kimliği iz kaydında durur.
- Kodsuz aday yayına alınır mı? Git: hayır. Prompt versiyonu: evet — güncel yapılır.
- Salı kod göndermeden geri gelir mi? Git: hayır. Prompt versiyonu: salı versiyonu terfi ettirilir.
- Playground düzenlemesi görünür mü? Git: hayır. Prompt versiyonu: yalnızca playground bir versiyon yazdıysa.
Bir prompt versiyonu neyi içermelidir
Hissi değil, içeriği versiyonlayın. İşe yarayan bir prompt versiyonu şunları taşır:
- Sistem prompt metni
- Kullanıcı prompt şablonu
- Girdi şeması (şablonun beklediği sözleşme)
- Bir versiyon notu — yayın notu; "güncelleme" değil
Kural: içerik versiyonu + çalışma zamanı versiyonu, ikisi de izde. Prompt'ta bir karakter değişsin, yeni hash. Model değişsin, yeni çalışma zamanı pimi. Sessiz yol olmadığı için sessiz düzenleme imkânsızlaşır.
Prompt müşteriye ulaşmadan nasıl test edilir
Zevkle terfi ettirmeyin. Zevk, cumayı üreten şeydir.
- Adaya bir not yazın. "Her teklifte ödeme koşullarını iste" bir versiyondur. "rötuş" değildir.
- Render'ı görün. Şablonlar editörde yalan söyler, değişkenler dolunca doğruyu söyler. Boş alan, uzun alan, satışçının her zaman boş bıraktığı o tek alan.
- Küçük bir değerlendirme kümesi çalıştırın. Yirmi-elli gerçek örnek, "daha iyi hissettiriyor" paragrafını döver. Umurunuzda olan şeyi puanlayın: eksik madde, reddetme oranı, token, maliyet. Kümeyi sabit tutun ki versiyon 14 ile 11 karşılaştırılabilsin.
- Tüm katı değil, bir canary gönderin. Trafiğin bir dilimi, değerlendirme ve maliyet izlenir, sonra genişler. Token'ı ikiye katlayan bir prompt, ifade değişikliği kılığında bir bütçe olaydır.
Prompt'u kod dağıtmadan nasıl geri alırsınız
Geri alma, önceki versiyonun terfi ettirilmesidir. Mekanizma bu cümledir.
Eski prompt'u hafızadan yeniden yazmazsınız. Bir git commit'ini geri alıp CI beklemezsiniz. Zaten geçmiş olan versiyonu alırsınız, güncel işaretlersiniz, onu kullanması gereken ajan/çalışma zamanını pimlersiniz. Başarısız aday tarihte kalır — diff'i sonra istersiniz.
İki pim, çünkü iki şey yanlış olabilir:
- İçerik yanlıştı — önceki prompt versiyonunu terfi ettirin.
- İçerik doğruydu, model ya da araçlar değişti — iyi prompt'a zaten işaret eden önceki çalışma zamanı pimini geri getirin.
Prompt versiyonlama kontrol listesi
Bunu ilk işte kullanın, bir platform yeniden yazımında değil.
- Prompt'lar tarihi olmayan bir tedarikçi konsolunda düzenlenmiyor.
- Her adayın versiyon kimliği, hash'i ve insan notu var.
- Model, örnekleme ve araçlar bir config dosyasından umulmuyor, çalışma zamanında pimli.
- İlk canlı terfiden önce notlanmış bir küme var.
- Terfi, "taslağı kaydettim"den ayrı, bilinçli bir hareket.
- Geri alma, öncekini terfi ettirmektir ve saniye cinsinden ölçülür.
- Her çalışma, prompt versiyonunu ve çalışma zamanı versiyonunu iz kaydına yazar.
Sıkıcı olan kısım asıl meseledir
Prompt versiyonlama bir fikir yazısı konusu değildir. Hattı çoktan terk etmiş bir partinin lot numarasıdır. Atlayan ekipler tembel değildir. Elyazmasını baskı sandılar. Sonra bir cuma farkı öğretti.
Bunu gerçek bir iş akışına bağlamak — versiyonlar, değerlendirme, geri alma, izler — ister misiniz? 30 dakikalık bir görüşme ayarlayın, ilk işte kayıt defterini birlikte kuralım.