Yeniden Üretilebilir Yapay Zekâ Projeleri

İyi bir yapay zekâ çıktısı ikna edici görünebilir ve yine de metodolojik olarak zayıf olabilir.

Hangi kaynakların kullanıldığını artık kimse açıklayamıyor olabilir. Kritik prompt birkaç kez değiştirilmiş olabilir. Projenin ortasında model değişmiş olabilir. Bir ajan bir aracı çağırmış, fakat oluşturduğu yan etki kaydedilmemiş olabilir. Mevcut kodda bir mimari karar görünürken alternatifin neden reddedildiği bilinmeyebilir. Bir reviewer bir sürümü onaylamış, dosya daha sonra değiştirilmiş olabilir.

Sonuçta çıktı vardır — fakat nasıl oluştuğunu gösteren sağlam bir geçmiş yoktur.

Yeniden üretilebilirlik problemi tam burada başlar.

Klasik yazılım projeleri sürüm kontrolü, build logları, testler ve ticket’larla çalışır. Agentic AI projelerinde bunlar tek başına yetmez. Buna ek olarak prompt sürümleri, model çağrıları, araç etkileşimleri, handoff’lar, dinamik kararlar, retrieval sonuçları, değerlendirmeler ve zaman zaman deterministik olmayan çıktılar oluşur.

Bu nedenle profesyonel soru yalnızca şu değildir:

Sonuç çalışıyor mu?

Asıl soru şudur:

Bu proje durumunun nasıl oluştuğunu, hangi kanıta dayandığını ve hangi kararlarla şekillendiğini daha sonra gösterebilir miyiz?

Yeniden üretilebilirlik hafızanın bittiği yerde başlar

Proje küçük olduğu sürece insan hafızası şaşırtıcı derecede iyi çalışır.

Bir varyantın neden reddedildiğini hatırlarsın. Kritik prompt aklındadır. Sohbet hâlâ açıktır. Kaynak dosyalar görünürdür. Değişiklikler yenidir.

Proje uzadıkça bu model bozulur.

İnsanlar unutur. Sohbetler değişir. Modeller güncellenir. Dosyalar yeni sürümler alır. Ajanlar daha sonra görünmeyen ara çıktılar üretir. Yeni ekip üyeleri mevcut bir kararın nedenini bilmeden projeye katılır.

Sonra tehlikeli bir yanılsama oluşur: güncel durum açık görünür, fakat kökeni artık açık değildir.

Bu yüzden yeniden üretilebilirlik öncelikle bir arşiv sorunu değildir.

Proje mimarisinin bir özelliğidir.

Bir sonuç, nasıl üretildiğinin kanıtı değildir

Bitmiş bir sunum nasıl oluşturulduğunu kanıtlamaz.

Çalışan bir prototip hangi varsayımların test edildiğini kanıtlamaz.

Son prompt önceki hangi varyantların başarısız olduğunu kanıtlamaz.

Bir Git commit’i bir kararın neden alındığını otomatik olarak kanıtlamaz.

Bir sohbet geçmişi de yanıt anında hangi dosya, araç durumu ve dış verinin geçerli olduğunu tek başına kanıtlamaz.

Bu nedenle yeniden üretilebilir bir yapay zekâ projesi birbiriyle bağlantılı birden fazla kanıt katmanına ihtiyaç duyar.

Ancak bu katmanlar birlikte sağlam bir proje tarihi oluşturur.

Prompt geçmişi gereklidir — ama yeterli değildir

Yapay zekâ projelerinde yeniden üretilebilirlik çoğu zaman “prompt’u kaydetmek” olarak anlaşılır.

Bu iyi bir başlangıçtır. Fakat yeterli değildir.

Aynı prompt, şu koşullardan biri değiştiğinde farklı sonuç üretebilir: model veya model sürümü, sistem talimatları, temperature veya diğer sampling parametreleri, retrieval içeriği, araç sürümleri, harici API cevapları, paralel adımların sırası, önceki oturum durumu, dosyalar veya veri setleri, zamana bağlı web içeriği.

Prompt yalnızca deney düzeninin bir parçasıdır.

Yalnızca prompt’ları arşivlersen soruyu arşivlersin; cevabın üretildiği koşulları mutlaka arşivlemiş olmazsın.

Sohbet geçmişi bir audit trail değildir

Sohbet keşif için çok güçlüdür.

Tek başına kanıt kaynağı olarak zayıftır.

Neden?

Görev, tartışma, düzeltme, karar ve sonucu birbirine karıştırır. Her tool durumunu göstermeyebilir. Bazı sistemler eski içeriği sıkıştırır. Dosyalar değiştirilebilir. Harici sayfalar güncellenir. Bir ajan sohbet dışında yan etki oluşturabilir. Platform her iç talimat katmanını göstermeyebilir.

Audit trail ise yapılandırılmış olaylara ihtiyaç duyar.

Örneğin: RUN-028-014 28 Ağustos 14:32’de başladı, P-12.3 prompt sürümünü kullandı, SRC-07 kaynak snapshot’ı ile çalıştı, M-04 runtime konfigürasyonunu kullandı, A-19.2 artefaktını üretti, R-44 review’unda bulgu aldı, D-31 kararına yol açtı ve RUN-028-016 tarafından superseded edildi.

Böylece kronoloji provenance hâline gelir.

Observability ile provenance aynı şey değildir

Observability öncelikle operasyonel bir soruyu cevaplar: Sistem şu anda ne yapıyor veya teknik olarak ne yaptı?

Provenance köken sorusunu cevaplar: Bu durum neden var ve hangi input, karar ve kontroller onu oluşturdu?

Bir trace, ajanın üç tool çağırdığını ve iki dosya oluşturduğunu gösterebilir. Decision Record olmadan A varyantının neden kabul edilip B’nin reddedildiği hâlâ belirsiz olabilir. Tersi de mümkündür: İyi bir Decision Record vardır fakat gerçek execution teknik olarak yeniden kurulamaz.

Profesyonel projelerde bu nedenle ikisi birlikte gerekir:

Observability: runtime olayları, hatalar, tool call’lar ve sistem davranışı.

Provenance: köken, gerekçe, sürümler ve kanıt ilişkileri.

Bu ayrım yaygın bir yanılgıyı engeller: Çok log sahibi olmak projeyi otomatik olarak yeniden üretilebilir yapmaz. Yalnızca daha fazla olayı görünür kılar. İlgili olaylar kaynak, karar ve artefaktlarla bağlandığında gerçek provenance oluşur.

Proje tarihi bir hikâye değil, bir graftır

İnsanlar projeleri doğrusal anlatır:

Önce araştırdık. Sonra taslak yaptık. Ardından mimariyi değiştirdik. Sonunda sürüm 3’e geldik.

Teknik tarih çoğu zaman doğrusal değildir.

Bir artefakt birden fazla kaynaktan oluşabilir. Bir karar üç run’ı etkileyebilir. Bir review eski kararı yeniden açabilir. Paralel ajanlar rakip varyantlar üretebilir. Sonraki bir test eski varsayımı geçersiz kılabilir.

Bu nedenle yalnız timeline yerine provenance graph daha değerlidir.

Temel node türleri şunlardır:

Source — kaynak, veri seti, referans.

Instruction — prompt, sistem kuralı, task contract.

Run — somut execution.

Artifact — dosya, kod, analiz veya output.

Finding — test veya review bulgusu.

Decision — kabul, red veya supersede edilmiş karar.

Checkpoint — doğrulanmış proje durumu.

Bağlantılar USES, PRODUCES, REVIEWS, SUPPORTS, REJECTS, SUPERSEDES ve DERIVES_FROM gibi ilişkileri taşıyabilir.

Merkez soru artık “Ne zaman ne oldu?” değildir:

Hangi kanıt hangi kararı destekliyor — ve hangi artefaktlar bu karara bağlı?

Minimal Run Record

Her proje karmaşık bir observability platformuna ihtiyaç duymaz.

Ancak önemli her yapay zekâ run’ı asgari bir yapılandırılmış kayıt bırakmalıdır.

Bu kayıt tüm ham veriyi kopyalamak zorunda değildir.

Onları açık biçimde referanslaması yeterlidir.

Model kimliği de kanıtın parçasıdır

“GPT kullandık” yeniden üretilebilir bir ifade değildir.

“Model X kullandık” bile provider arka planda davranışı değiştirdiğinde fazla kaba kalabilir.

Önemli run’larda mümkün ve uygun olduğu ölçüde şunlar tutulmalıdır: provider, model adı, model veya API sürümü, tarih, ilgili sampling ayarları, tool konfigürasyonu, aktif retrieval kaynakları, structured output şeması ve özel runtime seçenekleri.

Her provider bütün ayrıntıları görünür kılmaz.

Tam da bu nedenle neyin bilindiği ve neyin bilinmediği kaydedilmelidir.

Görünmeyen model değişiklikleri yeniden üretilebilirlikten vazgeçme nedeni değildir. Belirsizliği açıkça işaretleme nedenidir.

Generative AI’da yeniden üretilebilirlik byte-identical demek değildir

Aynı prompt’un daha sonra birebir aynı metni üretmesi gerektiğini düşünmek yaygın bir hatadır.

Generative sistemlerde bu her zaman gerçekçi veya gerekli değildir.

Sampling, deterministik olmayan donanım davranışı, değişen retrieval sonuçları ve provider güncellemeleri farklılık yaratabilir.

Üç hedefi ayırmak faydalıdır.

Replay

Aynı saklanan input, instruction ve tool adımları yeniden çalıştırılabilir mi?

Rebuild

Dokümante edilmiş önkoşullardan aynı fonksiyonel veya proje durumu yeniden kurulabilir mi?

Re-evaluation

Bağımsız bir reviewer, belgelenmiş koşullarda o dönemki kararın makul olup olmadığını değerlendirebilir mi?

Birçok yapay zekâ projesinde re-evaluation, aynı metni üretmekten daha önemlidir.

Kararlar ayrı bir veri tipi olmalıdır

Bir karar yalnızca sohbet içinde bir cümle olarak yaşamamalıdır.

Birinci sınıf proje nesnesi olmalıdır.

Kullanışlı bir Decision Record en az şunları taşır:

Bu yapı orphaned decisions problemini önler: Kökeni artık bulunamayan fakat projeyi şekillendiren kararlar.

Activity Log ile Decision Log aynı şey değildir

Activity Log şunu söyler: ajan dosya açtı, tool çağrıldı, test çalıştı, taslak kaydedildi.

Decision Log ise şunu söyler: B varyantı, T-14 testi temel gereksinimi ihlal ettiği için reddedildi; A mimarisi daha pahalı olmasına rağmen reversibility ve veri kontrolü daha güçlü olduğu için kabul edildi; F-22 finding kapanmadan 3.1 sürümü yayınlanmayacak.

İkisi de değerlidir.

Ama farklı soruları cevaplar.

Activity hareketi açıklar. Decision yönü açıklar.

En önemli bağlantı şudur: decision → evidence

Bir proje çok iyi dokümante görünürken yine de zayıf olabilir.

Kararlar kayıtlıdır ama dayanakları yoktur.

“A varyantını seçtik” bir dokümantasyondur.

“T-07 ve T-09 acceptance criteria’yı karşıladığı, S-03 kaynağı kritik varsayımı desteklediği ve B varyantı cost stress test’te başarısız olduğu için A’yı seçtik” ise kanıta dayalı gerekçedir.

Böylece Decision Record kontrol edilebilir hâle gelir.

Karar yalnız projede bulunmaz.

Kendi kanıt alanına işaret eder.

Kanıt yoğunluğu log miktarından önemlidir

Bir proje milyonlarca log satırı tutabilir ve yine de anlaşılması zor olabilir.

Önemli olan olay miktarı değil, anlamlı bağlantı yoğunluğudur. İyi bir kanıt seti birkaç bağlantılı nesneyle somut bir soruya cevap verir: Hangi varsayım test edildi? Hangi test çalıştı? Sonuç neydi? Hangi karar çıktı? Hangi artefakt değişti?

Buradan basit bir tasarım ilkesi çıkar:

Her olayı aynı değerde saklama. Projeyi etkileyen olayları işaretle.

State değişiklikleri, onaylar, redler, tool side effect’leri, yeni source state’leri, açılan veya kapanan finding’ler ve sonraki işi etkileyen kararlar bu sınıfa girer. Düşük seviyeli debug ayrıntıları saklanabilir, fakat aynı retention ve review önceliğine ihtiyaç duymaz.

Böylece provenance okunabilir kalırken observability korunur.

Kaynakların snapshot veya en azından kimliği gerekir

Web kaynakları değişir.

Dokümanlar güncellenir. Sayfalar kaybolur. API dokümantasyonu yeni sürüm alır. Tablolar düzeltilir.

Daha sonra yalnız URL kalırsa original run’ın gerçekte ne gördüğü bilinmeyebilir.

Kritik kaynaklarda mümkünse şunlar tutulmalıdır: erişim tarihi, başlık ve yayıncı, varsa sürüm numarası, hukuken uygun olduğunda arşivlenmiş snapshot, yerel kaynak dosyasının hash’i veya en azından ilgili bölüm ve provenance referansı.

Kural şudur:

Bir kaynak ancak ilgili zamandaki kimliği yeterince belirlenmişse yeniden üretilebilir biçimde referanslanmıştır.

Artefaktların lineage’a ihtiyacı vardır

Dosyalarla dolu bir klasör sürümleme değildir.

final.docx, final_yeni.docx ve final_v2_son_final.docx dosya adlarıdır — provenance değildir.

Bir artefakt en azından hangi sürüm olduğunu, hangi run’dan çıktığını, hangi input’ların kullanıldığını, hangi kararın release’e izin verdiğini, hangi eski sürümü değiştirdiğini ve draft, reviewed, approved veya superseded olup olmadığını bilmelidir.

Makine tarafından işlenebilir artefaktlarda hash, somut dosyanın kimliğini ayrıca sabitleyebilir.

Böylece “dosya” bir addressable state olur.

Hash kimliği kanıtlar — kaliteyi değil

Cryptographic hash faydalıdır; küçük bir dosya değişikliği bile farklı bir değer üretir.

Bu nedenle tam olarak aynı dosyanın mevcut olup olmadığını kontrol edebilirsin.

Ama hash dosyanın doğru olup olmadığını, kaynağın güvenilir olup olmadığını, prompt’un iyi olup olmadığını veya kararın mantıklı olup olmadığını söylemez.

Hash identity problem’ini çözer; quality problem’ini değil.

Bu ayrım önemlidir.

Checkpoint süreci dondurmaz — stabilize eder

Uzun yapay zekâ projeleri, bir durumun bilinçli olarak doğrulandığı anlara ihtiyaç duyar.

Bir checkpoint şunları içerebilir: güncel project baseline, aktif Decision Records, onaylı artefakt sürümleri, açık findings, ilgili source state’leri, güncel runtime ve tool sürümleri ve sıradaki izinli çalışma alanı.

Checkpoint “Bundan sonra hiçbir şey değişemez” demek değildir.

Şunu söyler:

Daha sonra bu tarihte projenin nerede olduğunu yeniden kurmamız gerekirse, doğrulanmış referans budur.

Checkpoint’in bir fingerprint’i olmalıdır

Güçlü checkpoint benzersiz referanslanabilmelidir.

Bu bir sürüm numarası, commit, manifest veya hash kombinasyonu olabilir.

Örnek: CP-28-04; Charter v5, Decision Register v8, Source Manifest v6, Artifact Set v12, Open Findings v3, Runtime Manifest v4 ve somut bir Git commit’ine işaret eder.

Böylece kompakt bir state address oluşur.

Prompt diff’leri prompt koleksiyonlarından daha değerlidir

Prompt library hangi prompt’ların var olduğunu gösterir.

Prompt diff ise neden değiştiklerini gösterir.

Yeniden üretilebilirlik için bu daha değerlidir.

Örneğin: sürüm 4 kaynakları birbirine karıştırdı, sürüm 5 primary/secondary source ayrımı ekledi, sürüm 6 sert output schema getirdi ve sürüm 7 reviewer finding sonrası uncertainty label ekledi.

Prompt engineering böylece akıllı metin koleksiyonu olmaktan çıkar, versioned method history olur.

Tool call’lar proje tarihinin parçasıdır

Agentic sistemler kanıt problemini temelden değiştirir.

Model yalnız metin üretmez. Dosya yazabilir, veritabanı değiştirebilir, API çağırabilir, ticket oluşturabilir, kod çalıştırabilir, harici sistemleri değiştirebilir, başka ajanlara delege edebilir veya insan onayı isteyebilir.

İyi bir trace her iç token hareketini saklamak zorunda değildir.