Kendi otomasyon platformumda, blog içeriklerini otomatik üretmek için bir AI pipeline’ı kullanıyorum. Bu sistemin temel amacı, sürekli ve kaliteli içerik akışı sağlamak. Ancak süreçte, “deneyimli gibi yaz” komutunun ne kadar sinsi ve tehlikeli olabileceğini bizzat tecrübe ettim. Amacımız E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) sinyallerini güçlendirmekti, ama modelin bunu nasıl yanlış yorumlayabileceğini görmem, beni içerik üretim stratejimi temelden değiştirmeye itti.
İlk başta, AI modeline verdiğim talimatlarda “somut numaralar kullan (USD, kullanıcı sayısı)”, “bir vakada ne yaptığını anlat”, “yaşanmış hissettiren anekdot kur” gibi ifadeler vardı. Hatta örnek olarak, uydurma tarih ve saat içeren cümle kalıpları bile veriyordum. Niyetim iyiydi; okuyucuya gerçek bir insan tarafından yazılmış, tecrübe kokan bir yazı sunmaktı. Ancak sonuç, beklentimin ötesinde, hatta biraz ürkütücü oldu.
”Deneyimli Gibi Yaz” Komutunun Tuzağı
AI modellerine “deneyimli gibi yaz” dediğinizde, onların ne kadar “yaratıcı” olabileceğini hafife alıyoruz. Bu talimat, modelin eline bir nevi serbestiyet veriyor; “deneyim” kavramını kendi iç mantığına göre doldurmasına izin veriyoruz. Benim pipeline’ımda da tam olarak bu oldu. Amacım, yazılan içeriğin daha otoriter ve güvenilir görünmesini sağlamaktı. Google’ın E-E-A-T prensipleri düşünüldüğünde, deneyim sinyalini güçlendirmek mantıklı görünüyordu.
Ancak test üretiminde ortaya çıkan makaleler, hiç yaşanmamış ama son derece ikna edici spesifik detaylar içeriyordu. Örneğin, belirli bir bulut servisinin kesin fatura rakamı, bir web sitesinin kesin ziyaretçi sayısı veya gece yarısı belirli bir saatte alınan bir alarm anısı gibi. Bu detaylar o kadar gerçekçiydi ki, okuyan birinin bunların uydurma olduğunu anlaması neredeyse imkansızdı.
Prompt Snippet (Örnek):
"Konu: Ağ güvenliği zorlukları.
Persona: Yılların tecrübesine sahip bir ağ mühendisi gibi yaz.
Stil: Pragmatik, doğrudan, birinci şahıs.
Talimat: Deneyimini vurgulamak için somut rakamlar, belirli olaylar ve zaman dilimleri kullan. Örneğin, 'Geçen ay yaşadığımız bir olayda, X firewall'umuzda 02:45'te...' veya 'Bu optimizasyon sayesinde aylık maliyetlerimizi 150 USD düşürdük.' gibi ifadeler ekle."Bu tür bir yönlendirme, modelin sadece “deneyimli” görünmek için “uydurması” gerektiğini öğrenmesine yol açtı. Ben modelin mantık yürüterek genel tecrübelerimi özetlemesini beklerken, o ise birebir yaşanmış gibi duran ama tamamen kurgusal detaylar üretti. Bu da aslında bir nevi dolandırıcılığın kapısını aralıyordu, farkında bile olmadan.
İkna Edici Ama Yanlış: LLM’lerin Doğası
LLM’ler, verilen bağlamda en olası ve ikna edici metni üretmek üzere eğitilir. Onlar için “doğruluk”, bir veri tabanındaki gerçeğe uygunluktan ziyade, dil modelinin tutarlılığı ve akıcılığıdır. Benim yaşadığım durum da tam olarak buydu. Pipeline’daki test üretiminde, makalelerdeki “gerçekçi” detaylar beni bile şaşırttı. “Geçen salı sabahı 03:14’te yaşadığımız bir disk doluluğu problemi…” ya da “Bu sayede ortalama kullanıcı oturum süresi %20 arttı…” gibi ifadeler, kesinlikle yaşanmış gibi duruyordu.
Buradaki temel sorun, “ikna edicilik” ile “doğruluk” arasındaki ayrımı LLM’lerin doğal olarak yapamamasıdır. Onlar ikna edici olmada mükemmeldir, çünkü dilin nasıl kullanıldığını ve insanları neyin inandıracağını iyi bilirler. Ancak doğruluk sorumluluğu tamamen prompt’u tasarlayanın ve çıkan içeriği denetleyenin üzerindedir. Benim durumumda, bu ayrımı başta yeterince vurgulamadığım için model, ‘deneyim’i ‘uydurma detaylar’la eşitledi.
Bu durum, özellikle teknik içerik üretenler için büyük bir risk taşıyor. Yanlış bir komut, teknik makalelerin güvenilirliğini tamamen sarsabilir. Bir IT profesyoneli olarak, okuyucunun bana güvenmesi benim için her şeyden önemli. Bu yüzden, bu ikilemle yüzleşip köklü bir çözüm bulmam şarttı.
Kişisel Anılar ve Sızan Bilgiler
Daha da ilginci, AI’ın “kişisel anı” uydurma yeteneği sadece genel detaylarla sınırlı kalmadı. Pipeline’ın kendi iç dokümantasyonundaki teknik bir not, makalede sahte birinci-şahıs bir hikayeye dönüşmüştü. Diyelim ki, iç dokümantasyonda “Nginx reverse proxy’de SSL sertifika yenileme hatası, genellikle certbot loglarında renewal failed mesajıyla görülür” şeklinde bir not vardı.
Model, bunu şu şekilde bir hikayeye dönüştürebiliyordu: “Geçenlerde bir müşterimizin Nginx sunucusunda SSL sertifikası yenilenmedi. certbot loglarına baktığımda renewal failed uyarısını gördüm ve hemen müdahale ettim.” Bu, teknik olarak doğru bir bilgi olsa da, spesifik bir “müşteri” veya “olay” uydurularak kişisel bir deneyim gibi sunuluyordu.
Internal Documentation Snippet (Temsili):
"SSL Certificate Renewal Failure:
Symptom: Browser warnings, service interruption.
Common Root Cause: `certbot` auto-renewal cron job failure or incorrect permissions.
Diagnostic: Check `/var/log/letsencrypt/letsencrypt.log` for `renewal failed` entries.
Resolution: Manually run `certbot renew --force-renewal` and investigate cron job setup."Bu, LLM’lerin yalnızca dışarıdan gelen prompt’ları değil, kendi eğitim verilerindeki veya bağlam içindeki diğer metinleri de “esin kaynağı” olarak kullanabildiğini gösteriyor. İç dokümanlar, model için “bilgi” olduğu kadar, aynı zamanda “hikaye anlatma şablonu” da olabiliyordu. Bu durum, hassas verilerin veya iç süreçlerin yanlışlıkla dışarı sızdırılması riskini de beraberinde getiriyor, tabii ki anonimleştirilmiş olsa bile. Bu, içerik üretiminde sadece dışa dönük prompt’ları değil, modelin erişebileceği tüm veriyi dikkatlice gözden geçirmem gerektiğini öğretti.
İlk Çözüm: Prompt Mühendisliği ve Kısıtlamalar
Bu sorunla başa çıkmak için iki katmanlı bir çözüm geliştirdim. İlk katman, prompt mühendisliği üzerineydi ve modelin “uydurma” davranışını doğrudan kısıtlamayı hedefliyordu. Modelin ne yapmasını istediğim kadar, ne yapmamasını istediğimi de açıkça belirtmem gerekiyordu. Bu, prompt’a katı “uydurma yasağı” kuralları eklemekle başladı.
Yeni prompt’larımda artık şu ifadeler yer alıyor: “Belirli tarih/saat (örn. ‘28 Nisan’da’, ‘03:14’te’), ölçülmüş gibi sunulan kesin rakam (örn. kesin $/ay fatura, kesin ziyaretçi sayısı, ‘%300 arttı’) veya tekil ‘müşterimde şu spesifik olay oldu’ şeklindeki vakalar YASAKTIR. Bunlar uydurma olarak kabul edilir ve içeriğin güvenilirliğini zedeler.” Bunun yerine, “açıkça temsili/tipik örnekler kullan (‘tipik bir KOBİ’de’, ‘diyelim ki 16GB RAM’li bir VPS’, ‘örneğin Nginx + Node + Postgres’ten oluşan bir yapıda’). Rakam gerekiyorsa yuvarlak ve ‘yaklaşık/örneğin’ diye ver, ölçüm iddiası kurma.”
Updated Prompt Snippet (Örnek):
"Konu: Ağ güvenliği zorlukları.
Persona: Yılların tecrübesine sahip bir ağ mühendisi gibi yaz.
Stil: Pragmatik, doğrudan, birinci şahıs.
Talimat: Genel saha gözlemlerini ve ilke düzeyindeki doğru bilgiyi kullan. Örnekleri temsili ve tipik olarak çerçevele.
YASAK: Belirli tarih/saat, kesin fatura rakamları, tekil müşteri vakaları (örn. 'Geçen hafta bir müşterimde X oldu').
KULLAN: 'Tipik bir KOBİ ortamında...', 'Örneğin aylık ~50-70$ bir VPS üzerinde...', 'Sophos XGS firewall'larda sıkça karşılaşılan bir durumdur...'"Bu kısıtlamalar, modelin hala “deneyim” ve “otorite” sinyalleri vermesini sağlamaya çalışırken, bunu uydurma detaylar yerine genel, ilke düzeyindeki doğru gözlemler ve temsili örneklerle yapmasını amaçlıyor. Bu yaklaşım, LLM’in yaratıcılığını yanlış yöne kanalize etmesini engelleyerek, üretilen içeriğin etik sınırları içinde kalmasına yardımcı oluyor.
İkinci Çözüm: Gerçek Vaka Bankası ve Otorite İnşası
Prompt kısıtlamaları önemli bir başlangıçtı, ama nihai çözüm, modele uydurma malzeme yerine gerçek ve doğrulanabilir malzeme sağlamaktan geçiyor. İşte bu noktada “gerçek vaka bankası” devreye girdi. Gerçekten yaşanmış olayları, müşteri ve firma isimlerini tamamen anonimleştirerek, yapılandırılmış dosyalara yazmaya başladım. Bu dosyalar, semptomları, hata ayıklama akışını, temel nedeni ve çıkarılan dersleri içeriyor.
Artık AI pipeline’ım, bir makale üretirken, “deneyimli gibi yaz” komutunu bu anonimleştirilmiş gerçek vakalar üzerinden yorumluyor. Model, bu vakaları okuyup, kendi dil modelini kullanarak genel dersler çıkarıyor, çözüm adımlarını açıklıyor ve problemin doğasını tarif ediyor. Bu sayede, içerik birinci şahıs ağzından, gerçek bir deneyime dayanarak yazılıyor, ancak hiçbir uydurma detay içermiyor.
Bu temizlik sadece içerik üretimiyle sınırlı kalmadı. Sitenin görünen metinlerinden, şablondan miras kalan uydurma kıdem iddialarını (“X yıldır sektördeyim” tarzı) da kaldırdım. Sorun aynı aileden geliyordu: doğrulanması mümkün olmayan bir otorite iddiası. Artık benim veya ITWISE’ın uzmanlığı, geçmiş deneyimlerimle, sunduğum çözümlerle ve paylaştığım gerçek bilgilerle kendiliğinden ortaya çıkıyor.
{
"incident_id": "20230515_FirewallPolicyIssue",
"category": "NETWORK_SECURITY",
"symptoms": [
"Belirli IP aralıklarından gelen VPN trafiğinde anlık kesintiler",
"Bazı iç servislerin dışarıdan erişilememesi",
"Sophos XGS loglarında 'Denied' veya 'Blocked' kayıtları"
],
"debug_flow": [
"Sophos XGS firewall üzerinde policy rule set'leri incelendi.",
"VPN tünelinin durumunun stabil olduğu görüldü.",
"Paket yakalama (packet capture) ile düşen trafiğin hangi kurala takıldığı tespit edildi.",
"Bir 'any-to-any' kuralının üzerine eklenen yeni bir kuralın, beklenenden daha geniş bir kapsamı olduğu fark edildi."
],
"root_cause": "Yeni bir güvenlik politikasının, mevcut ve daha spesifik olması gereken VPN trafiği izin kuralından önce işlenmesi.",
"lesson_learned": "Firewall politikası sıralamasının kritik önemi. Yeni kurallar eklenirken mevcut trafiği etkilemeyecek şekilde sıralanması veya 'dry run' modunda test edilmesi gerekliliği."
}Yukarıdaki gibi yapılandırılmış bir veri, AI için “gerçek” bir referans noktası sağlıyor. Model bu veriyi alıp, Mehmet Sarı’nın ağzından, olayın genel hatlarını ve çıkarılan dersi anlatabiliyor. Bu, hem etik hem de pratik açıdan çok daha sağlam bir temel oluşturuyor.
Otomatik İçerikte Etik ve Sorumluluk
E-E-A-T optimizasyonu ile dolandırıcılık arasındaki çizgi aslında tek kelimeyle özetlenebilir: “uydur”. Model suçlu değil; prompt ne isterse onu üretir. Eğer “uydur” dersek, uydurur. Eğer “gerçek verilere dayanarak genelle” dersek, bunu yapar. LLM’ler ikna ekseninde mükemmeldir, ancak doğruluk ekseninde sorumluluk tamamen bizde. Bu ayrımı anlamak, otomatik içerik üretimi yapan herkes için hayati öneme sahip.
Sürdürülebilir bir çözüm, modeli kısıtlamak değil, ona gerçek ve doğrulanabilir malzeme vermektir. Anonimleştirilmiş gerçek vakalar, otoriteyi uydurma detaylarla değil, sahici tecrübelerle kurar. Bu yaklaşım, sadece blog yazılarım için değil, MSP operasyonlarımızda kullandığım otomatik raporlama ve analiz araçları için de geçerli. Müşterilere sunulan raporların da gerçek veriye dayanması ve hiçbir detayın “ikna edici” olsun diye uydurulmaması gerekiyor.
Otomatik içerik yayınlayan herkesin kendine sorması gereken kritik bir soru var: “Bir okur ‘bu olay gerçekten oldu mu?’ diye sorsa, cevabım ne olurdu?” Eğer cevabınız “Aslında hayır, model uydurdu” ise, büyük bir etik sorunla karşı karşıyasınız demektir. Benim bu süreçten çıkardığım net pozisyonum: Doğruluk, ikna edicilikten önce gelir. Uzmanlık ve tecrübe, ancak gerçek temellere dayandığında değerlidir.