1. Giriş
Biyoinformatik uygulamalar sırasında pipeline'lar çoğunlukla bir kez kurulur, sonra yıllarca çalışır ve genelde bu süre boyunca hattın kendisi de içinde çalıştığı ortam da sessizce değişir: araçlar güncellenir, kütüphaneler yenilenir, referans kaynakları yeni sürümler yayınlar. Bir pipeline'ın doğru kurulmuş olması ile aynı girdiye her zaman aynı çıktıyı vermesi bu nedenle aynı şey değildir. Aradaki farkın nerede ortaya çıktığını görmek için somut bir durumla başlamak en açıklayıcısı olacaktır.
Klinik bir ekzom örneğinin çalışıldığını ve sonucun negatif raporlandığını düşünelim. İki yıl sonra aile yeniden değerlendirme talebiyle geri dönüyor; bu arada literatüre yeni gen–hastalık ilişkileri eklenmiş durumda oluyor ve yeniden analiz artık istisnai değil, rutin bir uygulama olarak özellikle klinikte karşımıza çıkıyor. Aynı ham veri, adı ve adımları değişmemiş aynı pipeline'la yeniden çalıştırılıyor. Bu kez klinik olarak anlamlı bir varyant raporda görünüyor.
Burada asıl soru varyantın ne olduğu değil, nereden geldiği. İki çalıştırma arasında hattaki araçlardan biri küçük bir sürüm güncellemesi almış ve bir filtreleme adımının varsayılan eşiği değişmiş olabilir. Varyant o eşiğin hemen kenarındaysa, ilk çalıştırmada elenmiş, ikincisinde kalmış olur. Bu senaryoda hiçbir aşamada hata alınmaz, hiçbir adım başarısız olmaz; süreç her iki seferde de sorunsuz tamamlanır. Geriye, ikisi de teknik olarak geçerli görünen iki farklı rapor kalır.
Bu noktada verilecek karar, sonucun kendisinden daha kritiktir. Bulgu gerçekten yeni bir bilginin ürünü müdür, yoksa değişmiş bir varsayılan değerin yan etkisi mi? İlk çalıştırmayı olduğu gibi yeniden üretemiyorsak bu soruyu cevaplayamayız. Cevaplayamadığımızda da elimizde iki sonuç arasında seçim yapmamızı sağlayacak hiçbir dayanak kalmaz; kalan tek şey, daha yeni olanın daha doğru olduğu varsayımıdır ve bu varsayımın hiçbir teknik karşılığı yoktur.
Tekrarlanabilirlik bu yüzden bir düzen alışkanlığı ya da yayın gerekliliği olarak değil, yorumun ön koşulu olarak görülmelidir ve bir analizin sonucu değiştiğinde, değişimin nereden geldiğini söyleyebilmek temel bir zorunluluktur. Bunu söyleyebilmek, geçmiş çalıştırmayı yalnızca kaydetmiş olmayı değil, yeniden çalıştırabilecek durumda olmayı gerektirir. Klinik bağlamda bu yükümlülük daha da ağırlaşır çünkü rapor bir dosyada duran çıktı değil, bir kişi hakkında verilmiş olan ve ciddi sonuçlara yol açabilecek kararları içerir.
Pratikte tekrarlanabilirlik üç ayrı yerde kırılır. Analizin çalıştığı ortam zamanla kayar; kullanılan veri, referans ve parametreler eksik tanımlanır ya da sonuca hangi adımlarla ulaşıldığı kayıt altına alınmaz. Bunların her biri tek başına yeterli bir kırılma noktasıdır ve üçü de farklı önlemler gerektirir. Aşağıda bu üç başlığı sırayla ele alıyoruz.
2. Ortam ve Yürütme
Bir biyoinformatik pipeline'ı tasarlamak ile onu her çalıştırmada aynı davranışı gösterecek şekilde işletmek arasında önemli bir fark vardır. Analiz mantığı doğru kurulmuş olsa bile çalışma ortamındaki küçük değişiklikler sonuçların farklılaşmasına neden olabilir. Yazılım sürümlerinin güncellenmesi, bağımlılık zincirindeki bir paketin değişmesi veya işletim sistemi seviyesindeki farklılıklar, beklenmeyen çıktılar oluşturabilen yaygın nedenler arasında yer alır.
Bu nedenle tekrarlanabilir bir analiz süreci, çalışma ortamının ayrıntılı biçimde tanımlanmasıyla başlar. Kullanılan araçların sürümleri, bağımlı kütüphaneler ve sistem bileşenleri analizin ayrılmaz parçalarıdır. Dokümantasyonda yer almayan her ayrıntı, aynı pipeline'ın başka bir araştırmacı tarafından yeniden çalıştırılmasını güçleştirir.
Container teknolojileri bu problemi büyük ölçüde ortadan kaldırır. Docker ve Apptainer gibi çözümler, analiz ortamını standart bir paket hâline getirerek farklı bilgisayarlar arasında tutarlı yürütme koşulları oluşturur. Böylece araştırmacılar yazılım kurulumuyla uğraşmak yerine doğrudan analiz sürecine odaklanabilir. Daha da önemlisi, aylar sonra gerçekleştirilecek yeni bir çalıştırmada aynı yazılım ortamı yeniden oluşturulabilir.
Ortamın standartlaştırılması tek başına yeterli değildir. Analiz adımlarının hangi sırayla çalışacağı, hangi dosyaların hangi kurallarla üretileceği ve süreç içerisindeki bağımlılık ilişkileri de açık biçimde tanımlanmalıdır. Bu amaçla geliştirilen workflow orkestrasyon sistemleri, modern biyoinformatik çalışmalarının temel bileşenlerinden biri hâline gelmiştir. Snakemake ve Nextflow gibi platformlar, analiz akışını deklaratif bir yapıyla tanımlar, eksik adımları otomatik olarak belirler, gereksiz tekrarları önler ve farklı hesaplama altyapılarında aynı iş akışının güvenilir biçimde yürütülmesini sağlar.
Tekrarlanabilirliği etkileyen bir diğer unsur determinizmdir. Bazı biyoinformatik algoritmaları rastgele başlangıç değerleri kullanır veya paralel hesaplama sırasında farklı yürütme sıraları oluşturabilir. Bu durum aynı veri kümesi üzerinde küçük farklılıklar ortaya çıkarabilir. Rastgele sayı üreteçlerinin sabitlenmesi, deterministik çalışma seçeneklerinin tercih edilmesi ve kullanılan parametrelerin eksiksiz kaydedilmesi bu riskleri önemli ölçüde azaltır.
Son yıllarda görsel pipeline oluşturucularının yaygınlaşması, karmaşık analizlerin daha erişilebilir hâle gelmesini sağladı. Ancak güvenilir bir mimaride görsel tasarım ile yürütme altyapısı birbirinden bağımsız değildir. Kullanıcının arayüzde oluşturduğu her bağlantının arka planda çalışan workflow tanımına doğrudan karşılık gelmesi gerekir. Görsel katman ile yürütme katmanı aynı modeli paylaştığında, kullanıcı deneyimi ile teknik doğruluk arasında doğal bir uyum oluşur.
Başarılı bir pipeline mimarisi, standartlaştırılmış çalışma ortamı, açık biçimde tanımlanmış workflow'lar ve öngörülebilir yürütme davranışı üzerine inşa edilir. Bu üç bileşen birlikte ele alındığında, analizler farklı araştırmacılar tarafından, farklı sistemlerde ve farklı zamanlarda aynı güven düzeyiyle yeniden üretilebilir.
3. Veri, Referans ve Parametreler
Bir analiz ortamı yıllarca aynı kalabilir; aynı container kullanılır, yazılım sürümleri değişmez ya da workflow tanımı hiç güncellenmez. Yine de iki yıl arayla çalıştırılan aynı analiz farklı bir rapor üretebilir. Değişen şey burada ortam değildir. Bunun yerine, referans genom sürümü güncellenmiş olabilir, anotasyon yenilenmiş olabilir, ya da bir parametre fark edilmeden farklı seçilmiş olabilir.
Referans genom sürümü bunun en görünür örneğidir. GRCh37'den GRCh38'e geçiş, birçok laboratuvarda yıllarca sürmüştür. Geçiş tamamlanana kadar aynı örneğin iki farklı sürümle analiz edilmesi de bu nedenle sık rastlanan bir durum olmuştur. Oysa iki sürüm arasında koordinat sistemleri değişir, bazı bölgelerin genomdaki temsili ise farklılaşır. Örneğin MHC bölgesi gibi yüksek polimorfik alanlarda yapılan bir varyant analizi, kullanılan sürüme göre bambaşka bir koordinata, hatta farklı bir transkripte denk gelebilir. Yani aynı varyant, kullanılan referansa göre farklı bir konumda raporlanabilir ve bu fark, doğrudan klinik yorumu değiştirebilir.
Anotasyon sürümleri de benzer bir risk taşımaktadır. ClinVar, gnomAD gibi kaynaklar sürekli güncellenir ve bu güncellemeler de bir varyantın patojenite sınıflandırmasını tamamen değiştirebilir. Giriştteki aile örneğinde olduğu gibi, iki yıl önce VUS (belirsiz klinik önem) olarak raporlanan bir varyant, literatüre eklenen yeni bir gen–hastalık ilişkisiyle bugün patojenik olarak sınıflandırılabilir. Ama hangi anotasyon sürümünün kullanıldığı kayıt altına alınmazsa, bu değişimin gerçekten yeni bir bilgiden mi geldiğini, yoksa başka bir nedenden mi kaynaklandığını sonradan anlayamayız.
Asıl kırılgan nokta ise yazılı olarak kayıt altına alınmadığı için görünmez kalan varsayımlardır. Araçlar, bir filtreleme adımının eşiğini, bir kalite skorunun sınırını ya da bir minör allel frekansı kesim noktasını çoğu zaman kendi varsayılan değerleriyle belirler. Bu değerler analiz raporunda açıkça belirtilmedikçe, kimse ne olduklarını, ne zaman değiştiklerini bilemez. Giriştteki senaryoda ikinci çalıştırmada raporun değişmesinin öteki olası nedeni de tam olarak budur; rapor yeni bir bilgiden değil, fark edilmeden kaymış bir varsayılan değerden değişmiştir. Bu tür varsayımlar dokümantasyonda saklanmak yerine kodun içinde gizli kaldığında analiz aslında yeniden üretilebilir olmaz; sadece yeniden çalıştırılabilir görünür.
Bunun çözümü, veri ve parametre tanımlarını dokümantasyon değil kod olarak ele almaktır (config-as-code). Referans genom sürümü, anotasyon sürümü, her filtreleme eşiği, pipeline koduyla birlikte versiyonlanan bir yapılandırma dosyasında açıkça yazıldığında bir çalıştırmanın hangi varsayımlarla yapıldığı güvenle takip edilebilir hale gelir. Ama bu kaydın kendisi de bir yerde saklanmalı, gerektiğinde sorgulanabilmeli, geriye dönük incelenebilmelidir. Yoksa config-as-code, sadece nerede durduğu belirsiz başka bir dosyaya dönüşür. Peki bu kayıt nasıl tutulur, nasıl doğrulanır?
4. İzlenebilirlik ve Doğrulama
Bir analiz tamamlandığında elde edilen sonuç kadar, o sonuca hangi adımlar izlenerek ulaşıldığı da kayıt altına alınmalıdır. Bilimsel çalışmaların doğrulanabilir olması, analiz sürecinin baştan sona yeniden oluşturulabilmesine bağlıdır. Bu nedenle modern biyoinformatik pipeline'ları, yürütme geçmişini ayrıntılı biçimde saklayan izlenebilirlik mekanizmaları üzerine kurulmaktadır.
İyi tasarlanmış bir analiz kaydı, kullanılan ham verileri, referans genom sürümünü, yapılandırma dosyalarını, yazılım sürümlerini, çalıştırılan komutları ve üretilen çıktıları tek bir bütün olarak ilişkilendirir. Böylece herhangi bir sonuç dosyası incelendiğinde, arkasındaki tüm hesaplama süreci eksiksiz biçimde takip edilebilir.
Log kayıtları bu yapının önemli parçalarından biridir. Her analiz adımının başlangıç zamanı, tamamlanma süresi, kaynak kullanımı, oluşan uyarılar ve hata mesajları sistem tarafından otomatik olarak kaydedildiğinde, olası problemlerin kaynağı kısa sürede belirlenebilir. Aynı kayıtlar kalite güvence süreçlerinde de önemli bir referans oluşturur.
Versiyon yönetimi de benzer derecede kritik bir konudur. Pipeline kodu güncellendiğinde veya referans veri kümelerinde değişiklik yapıldığında bu değişikliklerin hangi analizleri etkilediğinin açık biçimde görülebilmesi gerekir. Kod, konfigürasyon dosyaları ve referans veriler birlikte sürümlendirildiğinde farklı zamanlarda elde edilen sonuçların karşılaştırılması çok daha güvenilir hâle gelir.
Doğrulama süreci ise sürekli çalışan bir kalite kontrol mekanizması olarak değerlendirilmelidir. Bunun için küçük, iyi tanımlanmış test veri setleri hazırlanır ve pipeline üzerinde yapılan her değişiklik bu veri kümeleriyle otomatik olarak sınanır. Beklenen çıktılardan sapma oluştuğu anda geliştiriciler uyarılır ve olası sorunlar gerçek analizlere yansımadan önce tespit edilir.
Bu yaklaşım sürekli entegrasyon sistemleriyle desteklendiğinde geliştirme süreci daha kontrollü ilerler. Kod deposuna eklenen her değişiklik otomatik testlerden geçirilir, örnek analizler yeniden çalıştırılır ve sonuçlar önceki sürümlerle karşılaştırılır. Böylece pipeline zaman içinde gelişmeye devam ederken güvenilirliğini de koruyabilir.
İzlenebilirlik, versiyon yönetimi ve otomatik doğrulama birlikte değerlendirildiğinde biyoinformatik pipeline'ları denetlenebilir, sürdürülebilir ve uzun yıllar boyunca güvenle kullanılabilecek bilimsel altyapılara dönüşür.
5. Kapanış
Girişte bıraktığımız soruya dönelim: iki yıl arayla çalıştırılan aynı pipeline'dan çıkan iki farklı rapordan hangisi doğrudur? Bu yazı boyunca ele aldığımız üç başlık, aslında bu sorunun tek başına cevaplanamayacağını gösteriyor. Cevap sonucun kendisinde değil, sonucun arkasındaki kayıttadır. Çalıştırma ortamı tanımlanmışsa, kullanılan referans ve anotasyon sürümleri ile filtreleme eşikleri yapılandırma dosyasında açıkça yazılıysa ve her iki çalıştırmanın yürütme geçmişi saklanmışsa, iki rapor arasındaki fark birkaç dakika içinde açıklanabilir bir farka dönüşür. Bu koşullar sağlanmamışsa elimizde kalan tek şey, daha yeni olanın daha doğru olduğu varsayımıdır.
Bu üç başlığın birbirinin yerine geçmediğini vurgulamak gerekir. Container kullanmak, referans sürümünün kayıt altına alınmamış olmasını telafi etmez. Eksiksiz bir config dosyası, hangi çalıştırmanın hangi config ile yapıldığı izlenemiyorsa tek başına bir anlam taşımaz. Ortam, tanım ve kayıt birlikte kurulduğunda bir analiz yeniden üretilebilir hâle gelir; biri eksik kaldığında pipeline yalnızca yeniden çalıştırılabilir görünmeye devam eder.
Tekrarlanabilirliğin pipeline'ı dondurmak anlamına gelmediğini de eklemek gerekir. Referans genomlar güncellenecek, anotasyon kaynakları yenilenecek, araçlar yeni sürümler yayınlayacaktır; klinik açıdan da bunun böyle olması gerekir, çünkü yeniden analizin değeri tam olarak bu güncellenmeden gelir. Amaç değişimi engellemek değil, değişimi görünür kılmaktır. Kontrollü değişim ile sessiz kayma arasındaki fark, bu yazıda anlatılan yapının tamamının varlık sebebidir. Bir eşik değiştiğinde bunun bilinerek değiştirilmiş olması ile fark edilmeden kaymış olması, teknik olarak aynı sonucu üretse bile yorum açısından tamamen farklı iki durumdur.
Klinik bağlamda bu ayrım daha da ağırlaşır. Rapor bir dosyada duran çıktı değil, bir kişi hakkında verilmiş bir karardır; ve o karar sorgulandığında verilecek cevabın "sistem böyle üretti" olmaması gerekir. Bir pipeline'ın gerçek kalite ölçütü, bugün doğru sonuç üretmesi değil, iki yıl sonra sonucu değiştiğinde bu değişimin nereden geldiğini söyleyebilmesidir. Bu yeteneğe sahip olmayan bir hat, ne kadar iyi tasarlanmış olursa olsun, ürettiği sonucun arkasında duramaz.