26 KiB
YouTube Video Transkriptlerini Otomatik RSS Akışına Dönüştürme Geliştirme PlanıI. Mimari ve Operasyonel PlanBu rapor, YouTube video transkriptlerini otomatik olarak çıkarıp tam metin RSS akışına dönüştürecek boru hattının (pipeline) mimarisini, teknoloji seçimlerini ve operasyonel akışını detaylandırmaktadır. Sistemin temel amacı, API kısıtlamalarına karşı dayanıklı, durum yönetimli ve sunucusuz (serverless) bir ortamda sürekli çalışabilen bir çözüm sunmaktır.1.0 Sistem Mimarisine Genel Bakış: Otomatik Boru Hattı AkışıÖnerilen sistem, GitHub Actions zamanlayıcısı (cron trigger) aracılığıyla düzenli aralıklarla (örneğin, saatlik) çalışacak şekilde tasarlanmıştır. Bu periyodik çalışma, aşağıdaki yedi adımdan oluşan bir akışı takip edecektir:Girdi Alımı: İzlenmesi gereken hedef kanallar tespit edilir ve bu kanalların en son videolarının listesi çekilir. Bu aşama, sağlam Kanal Kimliği (Channel ID) çözümlemesini zorunlu kılar.Durum Kontrolü (Veritabanı): SQLite kalıcılık katmanı sorgulanarak henüz işlenmemiş (transcript_status = 0) veya güncelleme gerektiren videoların kimlikleri belirlenir. Bu, her çalıştırmada sadece yeni veya başarısız içerikle ilgilenilmesini sağlar.Çıkarma (Eş Zamansız): Python API istemcisi, API hız limitlerine uyum sağlamak için yönetilen eş zamansız toplu işleme (asynchronous batching) kullanılarak transkriptleri talep eder.NLP İşlemi: Ham transkript metni temizlenir ve okunaklı, paragraflara ayrılmış içerik oluşturmak için Cümle Sınırı Tespiti (SBD) uygulanır.Kalıcılık Güncellemesi: Geliştirilmiş transkript metni depolanır ve veritabanındaki meta veriler (processed_at_utc, transcript_status) güncellenir.RSS Üretimi: Veritabanından en son işlenmiş videolar sorgulanır, sonuçlar RSS 2.0 yapısına uygun olarak biçimlendirilir ve XML dosyası yazılır.Dağıtım: Güncellenmiş SQLite veritabanı (önbellekleme yoluyla) kaydedilir ve yeni RSS XML dosyası (Yapıt/Artifact veya doğrudan Git taahhüdü yoluyla) barındırma konumuna dağıtılır.1.1 Teknoloji Yığınının GerekçesiTeknoloji yığını, stabilite, performans ve CI/CD ortamında kolay dağıtım ilkeleri göz önünde bulundurularak seçilmiştir.Python (3.10+): Kapsamlı Doğal Dil İşleme (NLP) ekosistemi (SpaCy) 1 ve olgun eş zamansız ağ yetenekleri (asyncio, httpx) nedeniyle tercih edilmiştir. Python, boru hattının çekirdeğini oluşturacak yüksek hızlı veri işleme ve API yönetimini kolaylaştırır.youtube-transcript-api: Bu kütüphane, diğer Selenium tabanlı çözümlerin aksine, transkriptleri alırken sanal tarayıcı (headless browser) gerektirmez.3 Bu özellik, CI/CD ortamında dağıtımı ve bakımı radikal bir şekilde basitleştirir.SQLite: Sunucusuz, dosya tabanlı kalıcılık için idealdir. İşlemsel bütünlüğü destekler ve özel bir veritabanı altyapısı gerektirmez.4 GitHub Actions ortamında, veritabanı dosyasının önbelleğe alınması veya Git ile sürümlemesi basit ve verimli bir durum yönetimi sağlar.SpaCy: Kritik NLP görevleri (özellikle SBD ve metin segmentasyonu) için hızlı ve üretime hazır bir kütüphanedir.2lxml / feedgen: RSS/XML çıktısının standartlara tam olarak uygunluğunu sağlamak, karmaşık varlık kaçışını (entity escaping) ve ad alanlarını (namespaces) doğru yönetmek için gerekli olan sağlam kütüphanelerdir.6Eş Zamansız Hız Sınırlaması GerekliliğiAraştırma, API'nin katı hız sınırlarına sahip olduğunu göstermektedir (örneğin, 10 saniyede 5 istek 8). Geleneksel yaklaşımlarda kullanılan, toplu işlemler arasında uzun aralıklarla sıralı time.sleep() döngüsü 9 yüzlerce videoyu işlerken kabul edilemez derecede verimsizdir.Bu darboğazı aşmak için, boru hattının yönetilen eş zamansız bir kuyruk kullanması gerekmektedir. AIOLimiter 10 gibi bir araç, boru hattının API'ye eş zamanlı olarak transkript taleplerini göndermesine olanak tanır. Bu mimari, 10 saniyelik süre penceresine tam olarak uyulmasını garanti ederken, aynı anda 5 isteğin havada olmasına izin vererek optimum verim elde edilmesini sağlar. Operasyonel verimlilik, sıralı I/O beklemelerinden kontrollü, eş zamanlı API kullanımına geçirilerek sağlanır.SQLite'ın Mimari Merkez Olarak KonumlandırılmasıSQLite'ın CI/CD bağlamında kullanılması sadece kolaylık değil, aynı zamanda "Git Scraping" (Git Kazıma) metodolojisini 4 benimsemeyi mümkün kılar. Birincil kalıcılık mekanizması actions/cache olsa bile, veritabanı dosyası işlenmiş verilerin tüm geçmişini saklar. Bu tasarım, GitHub'da dolaylı olarak zaman damgalı, sorgulanabilir bir anlık görüntü geçmişi oluşturur ve sıfır maliyetle yerleşik bir veri denetim izi sunar.4II. Sağlam Veri Alımı ve API YönetimiBu bölüm, sistem stabilitesi için kritik öneme sahip olan YouTube tanımlayıcılarının yönetimi ve API hız kısıtlamalarının uygulanması detaylandırır.2.0 Girdi Normalleştirme Stratejisi: Kanal Kimliği ÇözümlemesiYouTube, kanal erişimi için çeşitli genel formatlar kullanmaktadır: modern kulplar (@), eski user/ ve kalıcı, 24 karakterli Kanal Kimliği (UC...).11 Boru hattının dayanıklılığı için bu girdilerin, sistemin temel alacağı kalıcı Kanal Kimliğine (UC... ile başlayan) dönüştürülmesi zorunludur.Kanal URL'si Ayrıştırma GereksinimiUygulama, farklı URL formatlarından (kulplar, kullanıcı adları veya kimlikler) tanımlayıcıyı doğru şekilde yakalamak için sağlam normal ifadeler (regex) içermelidir.11 Araştırmalar, çeşitli YouTube URL varyasyonlarını (özellikle yeni @handle yapısını) tek bir düzenli ifade ile ayrıştırmanın karmaşıklığını göstermektedir.13Bu gereksinimden çıkarılan sonuç, kullanılan genel tanımlayıcıların (kulplar) değişken ve kırılgan olabileceğidir. Çözüm, veritabanının yalnızca kalıcı, kanonik UC... Kanal Kimliğine güvenmesi ve bu kimliği dizinlemesi olmalıdır. Sistemin ilk adımı, kullanıcı girdisini kalıcı tanımlayıcıya çeviren bir çeviri katmanı oluşturmak ve böylece kanal takibini geleceğe hazır hale getirmektir.2.1 Hız Sınırlaması ve Eş Zamansız Kısıtlama TasarımıOperasyonel istikrar üzerindeki birincil risk, harici API'nin katı hız limitleridir (10 saniyede 5 istek).8Yönetilen Akış ModeliBoru hattı, AIOLimiter 10 gibi yönetilen eş zamanlılık havuzuna sahip bir eş zamansız kütüphane kullanmalıdır. Bu, Python uygulamasının belirlenen API frekansını kendiliğinden aşmamasını ve yaygın 429 hatalarının (Çok Fazla İstek) oluşmasını önlemesini sağlar.429 Too Many Requests Yanıtının İşlenmesiHarici API, bir hız sınırına ulaşıldığında açıkça bir Retry-After (Tekrar Dene Sonra) başlığı içerir.8 Bu başlık, ne kadar süre beklenmesi gerektiğini saniye cinsinden belirtir.Bu başlık, sorumlu istemci davranışının zorunlu bir talimatı olarak ele alınmalıdır. Python istemcisi, bu başlığı yakalamalı ve başarısız isteği yeniden denemeden önce belirtilen süre boyunca otomatik olarak askıya almalıdır. Bu, dahili statik gecikmeler yerine dinamik, yüksek öncelikli bir bekleme süresi sağlayarak API kullanımının hassasiyetini ve maksimum başarı oranını garanti eder. Statik gecikmelere güvenmek yerine bu dinamik değeri kullanmamak, hizmette bozulmaya yol açabilecek kötü bir mühendislik uygulamasıdır.2.2 Hata Yönetimi ve Yeniden Deneme MekanizmalarıKararlı bir boru hattı için katmanlı bir hata işleme stratejisi zorunludur.Geçici Hata Yönetimi: Kurtarılabilir hatalar (örneğin, 5xx sunucu hataları, geçici bağlantı zaman aşımları veya hafif 429 hataları) için üstel geri çekilme (exponential backoff) mekanizması uygulanmalıdır.Geri Dönüşü Olmayan Hatalar: Kalıcı olarak başarısız olan transkript çıkarma işlemleri (örneğin, alt yazısı olmayan veya silinmiş videolar) veritabanında transcript_status 2 (Başarısız) olarak işaretlenmeli ve günlüğe kaydedilmelidir. Bu, sonraki çalıştırmaların bilinen hataları tekrar tekrar işlemeye çalışmasını engeller.III. Kalıcılık Katmanı Tasarımı ve OptimizasyonuKalıcılık katmanı, durum yönetimi ve CI/CD ortamında zamansal veri depolama için SQLite'a dayanmaktadır.3.0 Durum Yönetimi için SQLite Veri ModellemesiVeritabanı, meta verileri, transkript metnini verimli bir şekilde depolamalı ve en önemlisi, işleme durumunu takip etmelidir.Temel Tablolar: Girdi listesini ve kanonik kimlikleri izlemek için channels ve meta verileri, durumu ve transkript içeriğini saklamak için videos tabloları tanımlanmalıdır.Durum Makinesi: Tamsayı (INTEGER) tipindeki transcript_status sütunu (0: Beklemede, 1: Çıkarıldı/Yayınlandı, 2: Kalıcı Hata) verimli sorgulama için merkezi öneme sahiptir. Boru hattının mevcut çalıştırmada iş gerektiren videoları hızlıca seçmesine olanak tanır (SELECT video_id FROM videos WHERE transcript_status = 0).3.1 Şema Tanımı ve Dizine Ekleme StratejisiYeni içeriği hızlı bir şekilde bulmak için zamansal veri depolaması kritik öneme sahiptir. Zaman alanları dikkatlice seçilmeli ve dizinlenmelidir.Zaman Dilimi FarkındalığıBoru hattı sunucusuz bir ortamda çalışacağından, tüm zaman damgalarının Eşgüdümlü Evrensel Zaman (UTC) olarak depolanması gerekir. SQLite'ın yerel zaman dilimi desteği olmadığından, Python'un zaman dilimi farkında olan datetime nesnelerini depolamadan önce standartlaştırılmış, sıralanabilir bir formata dönüştürmesi zorunludur.14Zamansal Dizin Optimizasyonu"Son çalıştırmadan bu yana yayınlanan tüm videoları bul" gibi zaman serisi aramaları için dizinin doğrudan zaman sütununa uygulanması gerekir. Arama sorgularının WHERE yan tümcesinde DATE() işlevi veya benzeri bir işlev kullanmaktan kaçınılmalıdır, çünkü bu, SQLite'ın dizini etkili bir şekilde kullanmasını engeller.17Bu noktada, SQLite'ın sorgu planlayıcısının sezgisel olarak kısıtlayıcı olmayan dizinleri (örneğin, rastgele bir host dizini) yüksek kısıtlayıcılığa sahip zamansal dizinlere (idx_epoch) tercih edebileceği ve bunun 300 kat performans düşüşüne yol açabileceği bilinmelidir.18 Bu durumun önlenmesi için geliştiricinin, sorgu sırasında istenen dizinin kullanıldığını doğrulamak amacıyla EXPLAIN QUERY PLAN komutunu kullanması ve gerekirse sorgu ipuçları (örneğin, unary + operatörü) kullanarak doğru dizin kullanımını zorlaması bir performans zorunluluğudur.Depolama Formatı Önerisi (UTC ISO 8601)Zaman damgalarının UTC ISO 8601 dizeleri (YYYY-MM-DDTHH:MM:SSZ) olarak depolanması önerilir. Unix epoch tamsayıları, son derece yüksek hacimli veriler için biraz daha iyi depolama yoğunluğu ve hızı sunsa da 19, ISO formatı insan tarafından okunabilirlik sağlar ve hata ayıklama veya manuel sorgulama sırasında tam zaman dilimi bağlamını korur.19 Bu, uygulamanın düşük/orta hacimli gereksinimleri için dizinlenebilirliğinden ödün vermeden operasyonel şeffaflıkta önemli kazanımlar sağlar.Aşağıdaki tablo, önerilen videos tablosu şemasını ve dizinleme stratejisini özetlemektedir:Video Veritabanı Şeması (videos Tablosu)Sütun AdıVeri Tipi (SQLite)AçıklamaDizinleme DurumuGerekçevideo_idTEXT (PK)Kanonik 11 karakterli YouTube video Kimliği.Birincil AnahtarTekil tanımlayıcı.channel_idTEXTKaynak kanalın Kimliği (UC...).Dizinli (FK)Gruplama ve kanala özgü çekme işlemleri için.published_at_utcTEXTVideo yayın zaman damgası (ISO 8601 UTC).Dizinli (idx_published_at)Zamansal aralık sorguları için kritik.17transcript_statusINTEGERİşleme durumu (0: Beklemede, 1: Çıkarıldı, 2: Başarısız).DizinliÇalışma kuyruğunu belirlemek için temel filtre.processed_at_utcTEXTSon başarılı boru hattı çalıştırma zaman damgası (ISO 8601 UTC).YokDenetim izi için faydalıdır.transcript_rawTEXTHam, bölümlenmemiş transkript verisi.YokYeniden işleme/hata ayıklama için tutulur.transcript_cleanTEXTSBD ile işlenmiş, son RSS içeriği.YokYayınlanabilir nihai içerik.IV. Transkript İyileştirme ve NLP İşlemleriHam YouTube transkriptleri, okunaklı bir tam metin RSS akışı için gerekli kalite standartlarını karşılayacak şekilde işlenmelidir.4.0 Veri Temizleme Boru HattıHam transkript verileri genellikle NLP işlemi öncesinde kaldırılması gereken yapay öğeler (artifacts) içerir.Yapay Öğelerin Kaldırılması: Zaman tabanlı işaretçileri, konuşma dışı konuşmacı etiketlerini (örneğin, [Music]) ve aşırı boşlukları kaldırmak için düzenli ifadeler uygulanmalıdır.Normalleştirme: Metin başlangıçta küçük harfe dönüştürülmeli ve daha sonra bölümlendirme sırasında sorunlara neden olabilecek Unicode karakterler normalleştirilmelidir.4.1 Cümle Sınırı Tespiti (SBD) UygulamasıSBD, ham, zaman parçalı metni tutarlı paragraflara dönüştürmek için en kritik adımdır.Noktalama İşaretlerinin Ötesine GeçmekStandart transkriptler dilsel tutarlılığa değil, zaman kodlarına dayanır. Yalnızca temel noktalama işaretlerine (., ?, !) güvenmek yetersizdir; doğal duraklama noktalarını ve anlamsal sınırları tespit edebilen gelişmiş NLP modellerine ihtiyaç vardır.20 Bu süreç, verinin okunamayan bir metin bloğu olmaktan çıkıp, kullanışlı, tam metin içeriğine dönüştüğü temel dönüştürme noktasıdır.SpaCy EntegrasyonuSpaCy 1 gibi hafif ve verimli bir NLP kütüphanesinin kullanılması önerilir. SpaCy'nin varsayılan boru hattı, SBD yeteneklerine güç veren bir ayrıştırıcı (parser) içerir.5 Boru hattı, gerekli modellerin (örneğin, en_core_web_sm) CI/CD ortamında verimli bir şekilde indirilip yüklendiğinden emin olmalıdır. Hızlı ve odaklanmış bir görev için SpaCy, daha ağır araştırma odaklı araçlara göre üstün bir seçimdir.ÖzelleştirmeÖzel içerik (örneğin, çok teknik veya hızlı konuşma) için varsayılan SBD performansı düşükse, planın, belirli metin kalıplarını işlemek üzere SpaCy içinde özel kural tabanlı SBD uzantıları uygulama aşamasını içermesi gerekmektedir.14.2 Okunabilirlik için Biçimlendirme (HTML Çıktısı)Bölümlenmiş metin, RSS içerik alanı için uygun temiz HTML'ye biçimlendirilmelidir.Paragraf Yapılandırması: Birbirine bitişik cümleleri paragraflar halinde birleştirmek için mantık uygulanmalıdır. Bu, tipik olarak belirli sayıda cümleden sonra veya anlamsal/konuşmacı değişikliği bayraklarına (varsa) dayanarak yapılabilir.Minimal HTML Sarmalama: Ortaya çıkan metin, modern RSS okuyucularında düzgün görüntülenmesini sağlamak için
etiketleri içine alınmalı ve content:encoded öğesine dahil edilmeye hazır hale getirilmelidir.V. RSS Akışı İnşası ve UyumluluğuBu bölüm, nihai çıktının RSS 2.0 spesifikasyonuna sıkı sıkıya uymasını sağlamaya odaklanarak, çeşitli akış toplayıcılarıyla maksimum uyumluluk elde edilmesini amaçlar.5.0 RSS 2.0 Spesifikasyonunun İncelenmesiAkış, tüm zorunlu kanal ve öğe (item) unsurlarını içermelidir.Kanal Gereksinimleri: bloğu,