Geçen ay AI generation pipeline’ımda bir publishDate alanını otomatik oluştururken yaşadığım bir problemle uyandım. AI, tarihi 2026-04-15 yerine '2026-04-15' şeklinde, fazladan tırnak içinde döndürmüştü. Küçük bir detay gibi görünse de, Astro build’im bu string’i parse edemediği için tüm blog yayın akışım durdu.
Bu durum bana bir kez daha gösterdi: AI destekli içerik üretimi, “seti kur ve unut” tarzı pasif bir süreç değil. Arka planda sürekli bir operasyon, gözlem ve müdahale gerektiriyor. Kendi blogum için kurduğum bu sistem, bana bu gerçeği defalarca hatırlattı.
AI’ın “İnsan Hataları” ve Benim Çözümlerim
AI modelleri ne kadar gelişmiş olursa olsun, bazen beklenmedik veya “insani” sayılabilecek hatalar yapabiliyor. Benim sistemimde karşılaştığım publishDate sorunu bunlardan sadece biriydi. Bir başka örnek, markdown içindeki tag’leri oluştururken / karakterini kullanmasıydı, örneğin tags: ["/ai", "/automation"]. Bu da Astro’nun tag işleme mantığını bozuyordu.
Bir de Türkçe karakter setindeki dotted-i (i, İ) problemi var. Bazen AI, bu karakterleri yanlış encode edip okunaksız hale getirebiliyor, özellikle başlık veya slug oluştururken can sıkıcı oluyordu. Bu tip sorunlar, içerik akışının kalitesini doğrudan etkilediği gibi, teknik olarak da build process’leri kırabiliyor.
Bu sorunları çözmek için pipeline’ıma güçlü bir pre-processing ve validation katmanı ekledim. Örneğin, publishDate alanındaki tırnakları temizleyen basit bir regex veya tag’lerdeki / karakterini kaldıran bir script, bu küçük ama yıkıcı hataların önüne geçti. dotted-i sorunları için ise, metni standart bir UTF-8 formatına dönüştüren küçük bir Python script’i kullanıyorum.
Altyapı Yükü: VPS’imdeki Gerçekler
AI ile içerik üretmek demek, sadece bir API çağrısı yapmak anlamına gelmiyor. Bu içeriklerin işlenmesi, build edilmesi ve yayınlanması ciddi bir altyapı yükü oluşturuyor. Kendi VPS’imde, PostgreSQL, Redis ve diğer Next.js uygulamalarını içeren 13+ Docker container’ın yanında, bu AI pipeline’ı da çalışıyor.
Bir içerik generation işlemi, özellikle büyük ölçekli metin veya görsel üretimleri içeriyorsa, sistem kaynaklarını aşırı zorlayabiliyor. Geçen ay Astro build’imin 2.5 GB RAM yiyip OOM (Out Of Memory) olmasına tanık oldum. Sistemde 7.6 GB RAM olmasına rağmen, o anki anlık yük ve diğer container’ların talepleri birleşince bu yaşandı. Bu gibi anlarda VPS’im swap fıstırma durumuna geçiyor, kcompactd %92 CPU kullanmaya başlıyor ve hatta sshd bile yeni bağlantıları accept edemez hale geliyor.
Docker tarafında da benzer sıkıntılar yaşadım. Geçen yıl, _work/_temp içindeki GitHub Actions runner dizinlerini temizlemeyi unuttuğum için diskim dolmuştu. 33 GB build cache ve 23 GB unused image, disk kullanımını %100’e çıkarmış, AI’dan gelen içeriği işlerken bu tip durumlara hazırlıklı olmak zorunda kalmıştım. Bu, sadece AI çıktısı değil, tüm CI/CD ve build sürecinin sürekli gözlem ve bakım gerektirdiğinin somut bir kanıtıydı.
Reliable Pipeline Kurmak: Otomasyon ve Gözetim Şart
Bu kadar çok hareketli parçayı bir arada tutmak, ancak sağlam bir otomasyon ve gözetim stratejisiyle mümkün. AI içerik pipeline’ımı kurarken birkaç temel prensibi benimsedim:
- Preflight Resource Guard: Üretim öncesi kaynak kontrolü yapmadan AI’dan gelen içeriği işlemeye kalkarsak, VPS’i çökertmek an meselesi. Pipeline’ımın başlangıcında, yeterli disk alanı ve RAM olup olmadığını kontrol eden küçük script’ler çalıştırıyorum.
- Auto-Fix Mekanizmaları: AI’dan gelen veriyi doğrudan kullanmak yerine, benim sistemim otomatik düzeltmeler yapıyor. Örneğin,
publishDatetırnaklarını kaldıran veya tag’lerdeki slash’leri temizleyen küçük adımlar, manuel müdahaleyi minimuma indiriyor. - Dedup-Alert Pattern: Aynı hatanın tekrar tekrar gelmesini engellemek ve gereksiz bildirim kirliliğini filtrelemek için
dedup-alertmekanizmaları kurdum. Bir hata tipi belirli bir süre içinde yalnızca bir kez bildirim gönderiyor, bu da gerçek sorunlara odaklanmamı sağlıyor.
Kendi self-hosted GitHub Actions runner’ım, bu AI content pipeline’ının kalbinde yer alıyor. GitHub Actions kotalarını delmemek için kendi VPS’imi kullanmak hem ekonomik hem de bana tam kontrol sağlıyor. Bu runner, AI’dan gelen içeriği işliyor, validasyondan geçiriyor, Astro ile build ediyor ve Cloudflare’a dağıtıyor.
# Örnek bir otomatik düzeltme script'i (pseudo-code)
# post-generation.sh
CONTENT_FILE=$1
# Frontmatter içindeki publishDate tırnaklarını temizle
sed -i "s/^publishDate: '\(.*\)'.*/publishDate: \1/" "$CONTENT_FILE"
# Tag tırnaklarını temizle (eğer tek tırnakla gelirse)
sed -i "s/tags: \[ '\([^']*\)' \]/tags: [ \1 ]/" "$CONTENT_FILE"
# Diğer temizleme ve doğrulama adımları...Cloudflare cache stratejileri de burada önemli bir rol oynuyor. Astro’nun varsayılan olarak max-age=0 döndürdüğü durumları, Nginx ile override ederek daha agresif caching sağlıyorum. Bu da, AI tarafından üretilen statik içeriğin daha hızlı sunulmasına yardımcı oluyor.
Sonuç
Gördüğünüz gibi, “AI içerik üretsin, ben de arkama yaslanayım” demek benim için pek mümkün olmadı. Her ne kadar AI müthiş bir yardımcı olsa da, arka plandaki operasyonel yükü ve beklenmedik “quirk”leri yönetmek, en az AI’ı eğitmek kadar önemli. Bu, sürekli bir denge ve öğrenme süreci.
Bu süreçte edindiğim tecrübeler, sadece bu blogu ayakta tutmakla kalmıyor, aynı zamanda genel sistem mimarisi ve operasyon bilgimi de sürekli besliyor. Sizin de AI destekli sistemlerinizde benzer ‘insan hataları’ veya operasyonel zorluklar yaşadınız mı? Yorumlarda paylaşın, belki birbirimizden öğreneceğimiz yeni şeyler vardır.