DEV Community: Guray

Sesi modelden geri almak: karakter videolarında telaffuzu deterministik yapmak (Bölüm 3)

Guray — Fri, 14 Aug 2026 01:15:11 +0000

Bölüm 2'de karakter videosu hattını kurduğumuzu ama bir duvara çarptığımızı yazmıştım: video üreten servis konuşmayı da kendisi sentezliyordu ve Türkçeyi güvenilmez okuyordu. Aynı konu için altı klip çöpe gitti. Bu bölüm o duvarı nasıl yıktığımızın hikâyesi. Kısa cevap: sesi modelden geri aldık.

Sorun tam olarak neydi

Görsel taraf iyiydi. Karakter tutarlıydı, ışık güzeldi, kamera hareketi doğaldı. Sorun ağızdan çıkanlardı:

Kelime tekrarı: "bilim insanları ile birlikte de bilim insanları"
Modelin metni kendi kendine yeniden yazması: "insülin" geçen bir cümleyi baştan kurup temkinli bilim diline çevirdi
Yabancı kökenli kelimeleri uydurması: "eureka" → "ürika"
Anahtar kelimeyi yutması: "yayla" 0,26 saniyeye sıkışınca "aile" gibi duyuldu

Kalite kapımız faster-whisper large-v3 ile çalışıyor: klibi deşifre ediyoruz, kelime olasılığı 0,80'in altına düşen varsa klip reddediliyor.

parcalar, _ = model.transcribe(wav, language="tr", word_timestamps=True, beam_size=5)
for p in parcalar:
    for k in p.words or []:
        if k.probability is not None and k.probability < 0.80:
            zayif.append((k.word.strip(), round(k.probability, 2)))

Bu kapı işini yapıyordu ama üretimin önünü tıkıyordu. Prompt mühendisliğiyle çözmeye çalıştık: "do not reword", "no stutter, no repeated words", "speak slowly, over-articulating every syllable", süreyi 10 saniyeden 12'ye çıkarmak. Hepsi reddi azalttı, hiçbiri bitirmedi. Çünkü sorun prompt değil, mimari: konuşmayı üretmesini istediğimiz model, aynı zamanda görüntüyü üreten model.

Önce yanlış yola saptık: GPU aramak

İlk içgüdü şuydu: ses güdümlü video modelleri var (Wan2.2-S2V, HunyuanVideo-Avatar, EchoMimicV3, OmniAvatar). Bunlara hazır ses veriyorsun, dudağı senin sesine göre üretiyorlar. Sunucuda GPU yok, o yüzden ücretsiz GPU saatleri olan bir not defteri servisine EchoMimicV3 kurmayı denedik.

Üç tur sürdü ve üçü de öğretici biçimde patladı:

ffmpeg veri kümesindeki wav dosyasını açamadı. Kırpmayı Python tarafına (librosa + soundfile, 16 kHz yeniden örnekleme) taşıdık.
Dosya yolları beklediğimiz yere bağlanmadı. Not defterini kendini iyileştirecek hâle getirdik: /kaggle/input altını os.walk ile tarayıp ilk .wav ve .jpg'yi bulan bir bölüm.
Model yüklendi, çekirdek sessizce öldü. Dönüş kodu -9, yani SIGKILL.

Üçüncü turda gerçek teşhis log'un içindeydi:

### missing keys: 220;
['audio_injection.proj1.weight', 'audio_injection.proj1.bias', ...]
DONUS KODU: -9

Yani ses enjeksiyon katmanının 220 ağırlığı hiç yüklenmemiş. Taban video modelinin ağırlıkları gelmiş, ses koşullama ağırlıkları gelmemiş. O hâliyle çalışsa bile ses görüntüyü sürmeyecekti. Buna ek olarak bellekten öldürülme. Bu, saatler yiyecek bir yapılandırma kazısı.

Mühendislik kararı: bu yolu kapattık. Not olarak duruyor, ileride GPU'lu bir ortam olursa geri dönülür.

Doğru yol: problemi ikiye ayırmak

Sonra bariz olanı gördük. Videodan istediğimiz iki şey var ve bunlar farklı zorluklar:

Sahne ve kimlik: karakterin yüzü, mekân, ışık, kamera. Bunda video modeli çok iyi.
Konuşma: doğru kelimeler, doğru telaffuz, doğru tempo. Bunda kötü.

Ayıralım. Görüntüyü model üretsin, konuşmayı bizim TTS motorumuz okusun, dudağı sonradan sese uyduralım. Böylece telaffuz determinist hâle gelir: metinde ne yazıyorsa o okunur.

Hat şöyle:

metin -> edge-tts (tr-TR) -> Whisper kapısı (0,80)
                                   |
taban klip (arşiv/model) ----------+--> Wav2Lip -> GFPGAN -> etiket -> kuyruk

Ses: kotası olmayan bir motor

Site seslendirmesinde (yazıların sesli anlatımı) ticari bir motor kullanıyoruz, arşivin ton tutarlılığı için orayı değiştirmiyoruz. Ama 12 saniyelik video repliği için aylık karakter kotası yakmak saçma. Video dublajı için edge-tts kullanıyoruz: ücretsiz, kotasız, Türkçede iki ses (bir kadın, bir erkek).

Tek ayar kritik çıktı: hız.

python3 -m edge_tts --voice tr-TR-AhmetNeural --rate=-8% \
  --text "Bugün masaya ters bir kart düştü. ..." --write-media ses.mp3

-4%'te Whisper üç kelimeyi eşiğin altında gördü (kart=0.73, Para=0.74, Falın=0.77). -8%'te hepsi geçti. Yani kendi TTS'imiz bile aceleye gelince deşifre edilemiyor; insan kulağı için de aynısı geçerli. Karakterleri ayırmak için aynı sesi perde kaydırmasıyla çeşitlendiriyoruz (--pitch=+10Hz genç ve parlak bir ton veriyor).

Dudak: Wav2Lip ve 96 piksel problemi

Dudak senkronu için Wav2Lip. CPU'da 12 saniyelik dikey klip yaklaşık 3 dakika, kabul edilebilir. Ama çıktıyı büyütünce sorun görünüyor: Wav2Lip ağız bölgesini 96x96'da üretiyor, 800 piksel genişliğindeki bir yüze yapıştırınca ağız lapa gibi kalıyor. Yayınlanabilir değil, çünkü zaten "yapay duruyor" eleştirisi almış bir üretim hattından bahsediyoruz.

Çözüm yüz onarımı: GFPGAN. CPU'da kare başına ~2,7 saniye. Ama naif kullanımı yeni bir sorun doğuruyor: her kareyi bağımsız onarırsan gözler, saç telleri, ten dokusu kare kare oynuyor ve video titriyor.

Numara şu: onarımı yalnızca Wav2Lip'in dokunduğu bölgeye harmanla. Dokunduğu bölgeyi bulmak için maske uydurmaya gerek yok, iki karenin farkı zaten maskenin kendisi:

fark  = cv2.absdiff(cv2.cvtColor(taban_kare, cv2.COLOR_BGR2GRAY),
                    cv2.cvtColor(w2l_kare,  cv2.COLOR_BGR2GRAY))
maske = (fark > 8).astype("uint8") * 255
maske = cv2.dilate(maske, np.ones((25, 25), "uint8"))
maske = cv2.GaussianBlur(maske, (61, 61), 0).astype("float32") / 255.0

son = taban_kare * (1 - maske) + onarilmis_kare * maske

Genişletme ağız çevresine pay bırakıyor, bulanıklaştırma dikişi görünmez yapıyor. Ağız dışındaki her piksel orijinal kalıyor, dolayısıyla titreme yok. Karşılaştırmada onarılmış ağız keskinliği neredeyse kaynak kliple aynı seviyeye geliyor: dişler seçiliyor, sakal dokusu duruyor.

Taban klibi sese uydurmak

Ses tabandan uzun olursa Wav2Lip kareleri baştan döngüler ve ortada görünür bir kesik oluşur. Bunun yerine tabanı ffmpeg ile uzatıyoruz: hafif yavaşlatma artı sonun tersten oynatılması (bumerang).

ffmpeg -y -i taban.mp4 -filter_complex \
 "[0:v]hflip,setpts=1.15*PTS,fps=24,split[a][b];\
  [b]reverse,trim=start=0:end=2.6,setpts=PTS-STARTPTS[r];[a][r]concat=n=2:v=1" \
 -an -c:v libx264 -crf 14 taban-uzun.mp4

Öğrendiklerimiz: %10-15 yavaşlatma fark edilmiyor, fazlası ağır çekim gibi duruyor. Yavaş sahnelerde tersten oynayan kuyruk göze batmıyor. hflip ise aynı tabanı ikinci kez kullanırken "başka çekim" hissi veriyor.

Beklenmedik kazanç: reddedilmiş klipler geri geldi

Bu hattın en tatlı yan etkisi şu: arşivdeki RED- önekli klipler ses yüzünden reddedilmişti, görüntüleri sağlamdı. Sesi tamamen değiştirdiğimize göre o klipler artık kullanılabilir. Aynı şekilde, indirilmiş ama hiç yayınlanmamış ham çekimler (kütüphane koridoru, akşam ışığında oturma odası, park yolu) birer "sahne kütüphanesi" hâline geldi.

Bir karakterin mekânı sabitse (günlük tarot bölümümüzün falcısı hep aynı mumlu masada çekiyor) taban klip her gün yeniden kullanılabiliyor. Sonuç: o bölümün videosu artık tarayıcıya hiç dokunmadan üretiliyor. Bir gecede aynı yöntemle dokuz klip kuyruğa girdi.

Sınırını da dürüstçe yazalım: tek karelik fotoğrafı dublajlamak işe yaramıyor. Göz kırpma olmadığı için 12 saniyede ölü bir maske gibi duruyor. Yeni bir mekân gerekiyorsa taban için hâlâ video modeline gidiyoruz.

Aynı gecenin iki önbellek kazası

Video hattıyla uğraşırken iki klasik ısırdı, ikisini de not düşüyorum.

404 önbelleği. Bir yazının görselini yüklemeyi geciktirmişsiniz ve o arada adres bir kez istenmiş. O "yok" cevabı iki katmanda kilitleniyor: nginx open_file_cache (60 saniye) ve CDN (4 saat). Dosyayı yükledikten sonra CDN önbelleğini temizlemek yetmiyor, çünkü temizlikten sonraki ilk istek nginx'in hâlâ elindeki negatif kaydı yeniden önbelleğe alıyor. Teşhis basit: curl -sI <url> cf-cache-status: HIT derken <url>?x=1 200 dönüyorsa budur. Doğru sıra: yükle, nginx'i reload et, sonra CDN'i temizle.

Beslemenin kaynak doğrusu. Podcast beslemesini üreten script yerel audio/ klasörünü tarıyordu. Seslendirme toplu işi ise mp3'ü geçici klasöre yazıp doğrudan sunucuya gönderiyordu. Sonuç: sunucuda 31 bölüm, yerelde 26, ve besleme her üretim turunda canlı feed'i 26'ya geri çekiyordu. Beş bölüm dağıtım platformuna hiç düşmemiş. Düzeltme tek satır (mp3'ü yerel klasöre yaz, oradan gönder) ama ders daha büyük: bir dosya iki yerde yaşıyorsa, hangisinin doğruyu söylediğini yazıya dökmek gerekiyor.

Sayılar

Dublaj hattı, 12 saniyelik dikey klip, 32 çekirdek CPU: Wav2Lip ~3 dk, GFPGAN ~15-25 dk, kodlama ~1 dk
Whisper kapısı: large-v3, eşik 0,80. Küçük modeller b/d gibi sesleri karıştırıp yanlış alarm veriyor, o yüzden küçültmüyoruz
TTS: 12 saniyelik replik için 1 istek, kota yok
Reddedilen klip sayısı bu hatta geçtikten sonra: sıfır (ses artık deterministik)

Sırada ne var

Yeni mekân üretimi hâlâ tarayıcıdaki video servisine bağlı, yani hattın tek insan/oturum bağımlılığı orada. Bir sonraki bölümde muhtemelen o bağımlılığı anlatacağım: ücretsiz API'sini kapatan bir platforma, oturum açık bir sekme üzerinden nasıl yayın yapılıyor ve bu neden hem çalışıyor hem de kırılgan.

Dokuz sanal sunucu, üç platform, bir kota duvarı: karakter videosu hattını kurmak (Bölüm 2)

Guray — Fri, 14 Aug 2026 00:08:18 +0000

Birinci bölümde bir haber sitesinin yayın akışını ajana devrettiğimi yazmıştım. O yazıdan sonra sistemin en kırılgan yerini kurdum: sosyal medyaya konuşan sanal sunucular. Dokuz kategorinin dokuz karakteri var, her biri kendi videosuyla kendi bölümünü tanıtıyor.

Bu yazı o hattın kurulum günlüğü. İçinde çalışan kod da var, çöpe giden yedi deneme de.

Neden karakter?

Statik bir yazı linkini X'e atınca ölçüm net: kart önizlemesi görünür, kimse durmaz. Dikey videoda konuşan bir insan varsa akış duruyor. Elimde gerçek sunucu yok, o yüzden karakterleri üretiyoruz: Elif (bilim, psikoloji), Arda (oyun), Doruk (doğa ve kamp), Dr. Sinan (tıp), Defne (kitap), Süreyya (tarot), Meriç (dünya basını), Elvan (arkeoloji), Duru (güzellik).

Kural basit ve sabit: kategori → karakter eşlemesi değişmez. Aynı etiket her zaman aynı yüz ve aynı sesle geliyor. Takipçi ikinci videoda karakteri tanıyor.

Üretim hattı şöyle:

konu seçimi → yazı yayını → başlangıç karesi (t2i)
   → konuşma metni (4 kısa cümle)
   → i2v video (12 sn, ses dahil)
   → Whisper doğrulama (eşik 0,80)
   → kafa1milyon.com etiketi (ffmpeg drawtext)
   → X + Instagram + YouTube kuyruğu

Kritik yer dördüncü satır. Onu anlatayım.

Telaffuz savaşı: modelin metni "düzeltmesi"

Video modeline Türkçe bir cümle verip "bunu oku" dediğinizde, model okumakla kalmıyor. Metni kendi kendine yeniden yazıyor.

Bir inek videosu altı kez çöpe gitti. Model "bilim insanları ile birlikte de bilim insanları" diye kelimeyi tekrarladı. Tıp videosunda "insülin" kelimesini "insülün" diye söyledi ve cümleyi kendi kendine "Tip 1 diyabette beta hücreleri..." diye temkinli bilim diline çevirdi. Bir başkasında "eureka" kelimesi "ürika" oldu.

Yedi denemeden sonra kural dosyasına şunlar girdi:

Konuşma metni en fazla 4 cümle, cümle başına 4-7 kelime.
Yabancı kökenli ve teknik kelime yok. "İnsülin" yerine "şekeri ayarlayan hücreler".
İddialı cümle yok. Model abartıyı düzeltmeye çalışıp metni bozuyor; cümleyi baştan dürüst kurmak gerekiyor.
Prompt'a "do not reword or rephrase anything, read the text exactly as written", "no stutter, no repeated words" gibi maddeler eklendi.
Süre 10 saniye değil 12 saniye seçiliyor. Dört cümle 10 saniyeye sıkışınca kelimeler yutuluyor.

En ilginç maddeyi en sona bıraktım. Bir kamp videosunda "İstanbul'a yakın bir yayla var" cümlesindeki "yayla" kelimesi 0,26 saniyeye sıkıştı ve "aile" gibi duyuldu. Anahtar kelime cümlenin başına gelince model üzerinden hızlı geçiyor. Kural: konunun anahtar kelimesi cümlenin ortasına, çevresinde nefes olacak şekilde konur. "Bu yayla İstanbul'a çok yakın" gibi.

Doğrulama kapısı: kulakla değil olasılıkla

"Kulağıma tuhaf geldi" ölçüt değil. Her klip üretimden sonra transkripsiyona giriyor ve kelime bazlı olasılıklara bakıyoruz:

from faster_whisper import WhisperModel

model = WhisperModel("large-v3", device="cpu", compute_type="int8")
segments, _ = model.transcribe(ses, language="tr", word_timestamps=True)

for s in segments:
    for w in s.words:
        if w.probability < 0.80:
            print(f"ZAYIF  {w.word!r}  p={w.probability:.2f}  "
                  f"{w.start:.2f}-{w.end:.2f} sn")

Bir kelimenin olasılığı 0,80'in altındaysa klip reddediliyor ve metin yeniden yazılıyor. small ve medium modeller bu işte yanlış alarm veriyor: b/d gibi sesleri karıştırıp temiz klipleri suçluyorlar. Sadece large-v3 kullanılıyor.

Kapı bir kez de "yanlış" çalıştı: "Dr." kısaltması 0,76 döndü. Sesi tek tek dinlettiğimde model gerçekten "Doktor Sinan" diyordu, sorun kısaltmanın kendisiydi. Bu tür durumlar için tek istisna kuralı var, ama istisna gerekçesiz yazılmıyor.

Etiket: köşeyi neden değiştirmiyoruz

Her klibe küçük bir kafa1milyon.com yazısı basılıyor:

ffmpeg -y -i "$GIRDI" -vf "drawtext=fontfile=$FONT:\
text='kafa1milyon.com':\
fontcolor=white@0.78:fontsize=h/40:\
shadowcolor=black@0.45:shadowx=2:shadowy=2:\
x=w*0.035:y=h*0.030" \
  -c:v libx264 -preset medium -crf 19 -c:a copy "$CIKTI"

Punto sabit değil, h/40. Konum sol üst ve tartışmaya kapalı: dikey formatta Reels ve Shorts arayüzünün kapatmadığı tek güvenli alan orası. Alt kısmı açıklama ve butonlar yiyor, sağ şeridi etkileşim ikonları kaplıyor.

Tıklanabilir link: platform başına ayrı duvar

Üç platform, üç ayrı problem.

X: intent URL ile metin ve link doldurulabiliyor. Videolu postta link ana posta konmuyor, ilk yanıta gidiyor.

Instagram: gönderi açıklamasındaki adres tıklanamaz, nokta. Çözüm hikâyedeki link etiketi:

from instagrapi.types import StoryLink

baglanti = StoryLink(webUri=url, x=0.5, y=0.82, width=0.7, height=0.09)
cl.video_upload_to_story(video, links=[baglanti])

Reel paylaşıldıktan hemen sonra aynı video, link etiketiyle hikâyeye de düşüyor. Ayrıca profil biosuna koyulacak bir /link/ sayfası üretiliyor ve saatlik bir timer onu güncelliyor.

YouTube: açıklamadaki linkler tıklanabilir olsun diye kanalın telefon doğrulaması gerekiyor. Kod yazarak çözülecek bir şey değil; doğrulama tamamlanana kadar açıklamada okuru kanal profilindeki bağlantıya yönlendiriyoruz.

Üç platformda tek bir "link koy" fonksiyonu yazamamak, bu işin en öğretici tarafıydı.

Kota arkeolojisi: ücretsiz katmanı tersine mühendislik

Seslendirme tarafında ticari kotam bitti ve arşivde 76 sessiz yazı birikti. Ücretsiz TTS kotasının nasıl davrandığını ölçerek çıkarmak zorunda kaldım.

Önce 429 gövdesini okuyup gerçek metriği buldum:

generate_content_free_tier_requests
GenerateRequestsPerDayPerProjectPerModel-FreeTier    deger: 10

Cümlenin içinde üç kelime var ve üçü de önemli: PerProject, PerModel, PerDay. Yani limit hesap başına değil, proje ve model başına. İki projeyle 20 istek.

Buradan üç hamle çıktı:

Parça boyu. Modelin çıktı sınırı 16.384 token, saniyede 32 token, yani ~8,3 dakika ses. Türkçe'de bu kabaca 6.500 karakter. Parçalar 3.500 karakterde kesiliyordu; 5.800'e çıkardım. Çoğu yazı artık iki istek yerine tek istekte bitiyor. 9.400 karakteri tek istekte denemek ise sessiz başarısızlıkla dönüyor: yanıt geliyor ama içinde ses parçası olmuyor.
Model havuzu. Kota model başına olduğu için model listesini taradım ve batchGenerateContent destekleyen yeni bir TTS modeli buldum. Ayrı kova, taze kota. Kısa cümlede kusursuz çalıştı, 900 karakter ve üstünde ise ne unary ne streaming uçtan yanıt döndü; beş dakika askıda kalıp zaman aşımına düştü. Preview modellerin bedeli bu. Havuzdan çıkardım ama gerekçesini koda yazdım:

# gemini-3.1-flash-tts-preview ayri bir kota kovasi ve cazip gorunuyor ama
# 14 Agu 2026'da denendi: 50 karakterlik cumlede calisiyor, 900 karakter ve
# ustunde ne unary ne streaming ucta yanit donuyor. Preview duzelirse eklenir.
MODELLER = ["gemini-2.5-flash-preview-tts"]

Toplu iş. Batch API bu modelde destekli görünüyor, çağrı ise FAILED_PRECONDITION veriyor: ücretsiz katmanda kapalı.

En faydalı bulgu tesadüfen çıktı. Akşam kotayı bitirmiş bir anahtar, gece yarısından sonra tek bir istek kabul etti, sonra yine kapandı. Demek ki günlük sayaç gece bir kerede sıfırlanmıyor, kayan pencerede eski istekler düştükçe slot boşalıyor. Bunun üzerine "günde iki tur" olan zamanlayıcıyı iki saate indirdim:

OnCalendar=*-*-* 00/2:10:00

Kota kuruysa betik saniyeler içinde ve temiz dönüyor. Boşalan her slot aynı gün kullanılıyor.

Bir de hata kodu ayrımı ekledim. Eskiden herhangi bir başarısızlık bütün turu kesiyordu:

KOD=$?
if [ "$KOD" = "3" ]; then          # gunluk kota bitti: tur biter
  break
elif [ "$KOD" != "0" ]; then       # gecici hata: bu yaziyi atla, devam et
  continue
fi

Paylaşımı ajandan koparmak

Bu hattın son kusuru şuydu: postları ajan atıyordu, yani oturum kapalıysa post yoktu.

Instagram tarafı API üzerinden çalıştığı için oradaki kuyruğu tamamen sisteme devrettim. Kurallar artık betiğin içinde:

PENCERE = (10, 24)     # yayin penceresi, TSI
GUNLUK_TAVAN = 10
ARA_DAKIKA = 75        # ardisik postlar arasi en az bosluk

def zaman_uygun(q, oge=None):
    simdi = datetime.datetime.now(TSI)
    basla = 9 if (oge or {}).get("kat") == "Tarot" else PENCERE[0]
    if not (basla <= simdi.hour < PENCERE[1]):
        return f"pencere disi ({simdi:%H:%M})"
    ...

Timer yarım saatte bir ateşliyor, karar betiğe ait. Tarot 09:00 istisnası da burada yaşıyor: günlük fal geciktirilmiyor, videosu yetişmezse o günün görseliyle atılıyor.

Bir de küçük ama pahalı bir dersin kodu var: paylaşımdan önce her yazı adresi doğrulanıyor. Bir gün ezberden yazılmış bir slug 404 verdi ve postlar elle silinmek zorunda kaldı. Artık kuyruktaki adres kullanılıyor ve yine de HTTP durumu kontrol ediliyor.

Tarayıcıya bağımlılık ve bir sonraki adım

Hattın en zayıf halkası hâlâ video üretiminin tarayıcı oturumuna bağlı olması. Oturum düşünce üretim duruyor.

Şu an denediğim yol: sesi kendimiz üretip, karakteri ses güdümlü bir modelle oynatmak. Böylece telaffuz riski tamamen ortadan kalkıyor, çünkü konuşmayı video modeli üretmiyor. Sunucuda GPU yok, o yüzden hesap ücretsiz GPU sağlayan bir platformda ve tarayıcı olmadan, API ile:

kaggle kernels push -p .        # notebook + GPU + internet
kaggle kernels status <ref>
kaggle kernels output <ref> -p .

İlk tur sessizce öldü: log'da traceback yoktu, model yükleme mesajlarından sonra çıktı bitiyordu. Traceback olmadan ölmek genelde tek bir şey demek, bellek. İkinci turda bellek kipleri sırayla deniyor ve her denemenin dönüş kodu basılıyor; -9 görürsem tanı kesinleşecek.

Sonucu bir sonraki bölümde yazacağım. Çalışırsa hat tarayıcıdan tamamen kurtulacak; çalışmazsa onu da yazacağım.

Bu seride kod kadar başarısız denemeleri de tutuyorum, çünkü altı ay sonra "bunu neden böyle yaptık" sorusunun cevabı orada duruyor.

Revizyon 1: Statik yayın sitesine bir günde deneysel sosyal katman — park bankı, caz kulübü, fısıltı bulutu

Guray — Wed, 12 Aug 2026 20:53:35 +0000

Bu serinin yazarı Güray: AI geliştirmecisi, prompt ve analiz mühendisi. Kodun büyük kısmını bir LLM ajanıyla pair programming yaparak yazıyorum. Seri, kafa1milyon.com'un perde arkasını mühendis gözüyle belgeliyor. Bölüm 1'de genel mimariyi anlatmıştım.

Önce dürüst bir uyarı: bu bir revizyon günlüğü

Bu yazıdaki her şey tek bir günde eklendi ve tamamı deneysel. Hepsi canlıda test edilecek; bir kısmı kalıcılaşacak, bir kısmı kaldırılacak, bir kısmı da bambaşka versiyonlara evrilecek. Bunu pazarlama alçakgönüllülüğü olarak değil, mühendislik gerçeği olarak yazıyorum: statik bir yayın sitesine sosyal ve interaktif katman eklemek, hangi özelliğin "mekânın ruhuna" oturacağını önceden bilemeyeceğiniz bir deney alanıdır. Ölçüp, izleyip, budayacağız.

Günün sonunda üç büyük blok çıktı ortaya:

Okur katmanı: vurgulama, not, okuma modu, sözlük, filtreler, sesli oynatıcı ve bir dizi "sessiz" etkileşim.
Park Bankı: aynı yazıyı okuyan iki anonim okuru eşleştiren mikro sohbet.
Caz Kulübü: masalara oturulan, müzik paylaşılan, sesli sohbete geçilebilen dijital bir mekân. (Gün biterken kapısına kilit vurup rezervasyon moduna aldık; birazdan anlatacağım.)

Kısıt seti: veritabanı yok, WebSocket yok, hesap yok

Site tamamen statik HTML + nginx + Cloudflare. Bu revizyonda da kural bozulmadı. Sosyal özelliklerin tamamı şu üç ilkeyle yazıldı:

Bellek içi Python backend'ler (stdlib-only, ThreadingHTTPServer): park bankı ve kulüp API'leri süreç belleğinde yaşar. Süreç yeniden başlarsa masalar boşalır. Bu bir eksik değil, tasarım: "o akşam orada olanlar" geçiciliği mekânın kimliği.
WebSocket yerine kısa yoklama (short polling): 2-3 saniyede bir GET. Cloudflare arkasında WS oturumu yönetmek yerine, olay listesini ts > sonra filtresiyle artımlı çekiyoruz. 30 eşzamanlı kullanıcı tavanında bunun maliyeti saniyede ~15 hafif JSON isteği; nginx bunu esner bile.
Kimlik = sessionStorage'daki rastgele uid: kayıt yok, e-posta yok, çerez yok. Sekme kapanınca kimlik de gider.

istemci (vanilla JS) ──2 sn'de bir──> nginx /bar/api/ ──> 127.0.0.1:8796
                                                          bellek içi durum:
                                                          MASALAR, KISILER,
                                                          BEKLEYEN, SINYAL

Okur katmanı: metnin üstüne bir kat daha

Makale sayfalarına bir günde eklenen etkileşim seti:

Vurgulama + not: window.getSelection() ile seçim, <mark> sarma, DOM yolu + metin ofsetiyle LocalStorage'a yazma. Sayfa yeniden yüklendiğinde vurgular yeniden uygulanıyor. Sunucu hiçbir şey görmüyor.
Okuma modu çubuğu: sepya/gece teması, 16-22px font ölçeği, odak modu (header/footer gizlenir, sadece metin + ilerleme çubuğu kalır).
Ruh hali + süre filtreleri: içerik meta verisine readTimeMinutes ve mood eklendi; liste sayfaları istemci tarafında filtreleniyor.
Kavram sözlüğü: data-definition taşıyan terimlere hover/tık popover'ı.
MediaSession API'li sesli oynatıcı: kilit ekranından oynat/durdur, arka plan oynatma. Yanına podcast RSS beslemesi kuruldu ve Spotify'a bağlandı.
Fısıltı Bulutu (Mind Cloud): makale başına 10 saniyelik ses kayıtları (MediaRecorder) veya 140 karakterlik notlar. Her gönderi yayınlanmadan önce LLM moderasyonundan geçiyor; ses önce transkribe edilip aynı süzgece giriyor.
Daha sessiz deneyler: paragraf altı "görünmez mürekkep" şerhleri, okurların nerede durakladığını gösteren anonim odak haritası, cümle kenarına 140 karakterlik itiraz bırakılan marjin notları, scrollytelling şablonu, üretken sanat tuvali ve "şimdi ne okumalıyım?" karar ağacı.

Bunların onboarding'i de ayrı bir tasarım problemiydi: ekranı kaplayan tur yerine, ilk ziyarette 2-3 saniye görünüp kaybolan mikro ipuçları ve "özelliği tam kullanacağın anda öğreten" bağlamsal tetikleyiciler kullandık. Kullanıcı bir özelliği bir kez kullandığında ipucu bir daha çıkmıyor (LocalStorage bayrağı).

Revizyon notu: Bu setin tamamı ölçüme tabi. Odak haritası gibi "güzel ama belki kimsenin fark etmeyeceği" özellikler ilk budama adayları.

Park Bankı: iki yabancı, bir bank, 140 karakter

Aynı yazıyı okuyan iki anonim okur varsa, köşede bir davet beliriyor: "Parkta sizinle aynı makaleyi okuyan biri var. Bir bankta oturup iki cümle laflamak ister misiniz?"

Kabul edenler SVG ile çizilmiş bir park sahnesinde (gece/gündüz temasına duyarlı) karşılıklı iki banka oturuyor. Mesajlar karakterin kafasının üstünde konuşma balonu olarak beliriyor ve 6 saniyede sönüyor. Kalkan tarafın yerine "diğer okur banktan kalktı" notu düşüyor.

Teknik olarak en tartışmalı karar: spesifikasyon Socket.io diyordu, biz kısa yoklamayla yazdık. İki kişilik, 140 karakterlik, saniye hassasiyeti gerektirmeyen bir sohbet için WS altyapısı taşımak istemedik. Doğru karar mıydı? Kulüp tarafında göreceğiz; oradaki yük profili farklı.

Caz Kulübü: günün en büyük parçası

10 masa (5'i dört, 5'i iki kişilik), caz efsanelerinin adlarını taşıyor: Ella, Coltrane, Nina, Miles... Kuşbakışı SVG salon planında dolu koltuklar kehribar yanıyor. Masalar dolarsa bar alanında kuyruk; koltuk boşalınca 30 saniyelik rezervasyonla çağrı.

Masa içinde:

Atmosfer: ışık (spot/loş/gece) ve ikram (kahve/meze/mum) masadaki herkese canlı yansıyor. Mum alevi ve kahve buharı CSS animasyonu.
Medya ekranı: yalnızca YouTube/Spotify. YouTube linkleri sunucuda oEmbed ile doğrulanıyor (video gerçekten var mı, gömülebilir mi) ve başlık NSFW/şiddet kelime süzgecinden geçiyor.
Sesli sohbet: masadaki HERKES onaylarsa açılıyor (oy birliği). Ses P2P WebRTC mesh; SDP/ICE sinyalleşmesi ayrı bir kanal yerine mevcut yoklama döngüsünün içinde taşınıyor. Sunucuya ses akışı hiç uğramıyor. Bilinen sınır: TURN sunucumuz yok, simetrik NAT arkasındaki azınlık ses kuramayabilir. Kabul edilmiş bir ödün.

Gece yarısına doğru altı "kült mekân" özelliği daha eklendi:

İstek peçetesi (jukebox kuyruğu): link anında çalmıyor; sıraya giriyor, kim istedi görünüyor. "🍷 İkram Et" oyu şarkıyı öne alıyor. Otomatik parça geçişi bilerek yok: YouTube oEmbed süre bilgisi vermiyor, Data API'ye anahtar bağlamak istemedik. Geçiş masadakilerin elinde ("⏭").
Ortak peçete: masanın ortasında herkesin aynı anda çizebildiği kanvas + kısa notlar. Çizgiler nokta dizisi olarak sunucuya gidiyor, diğer istemciler artımlı indeksle çekiyor. Masa dağılınca peçete siliniyor.
Soru kartı: sohbet tıkanınca "🃏 Masaya Soru At" arşiv tonunda ~30 felsefi sorudan birini masaya düşürüyor. Aynı masada son 10 soru tekrarlanmıyor.
Adisyon: 5 dakika etkileşimsiz kalan misafirin önüne adisyon geliyor; 60 saniyede "buradayım" demezse koltuk kuyruktakine devrediliyor. Tamamen istemci tarafında; sunucunun 25 saniyelik yoklama düşmesi zaten güvenlik ağı.
Kişisel ambiyans mikseri: plak cızırtısı / yağmur / orman / kütüphane / sessiz + ses kaydırıcısı. Bilinçli karar: ortam sesi masaya değil, kişiye ait. Kimseye atmosfer dayatılmıyor; sessizlik her zaman bir tık uzakta.
Yavaş sohbet protokolü: her mesajdan sonra 8 saniyelik "yudum molası". Sunucu 429 dönüyor, istemci girdiyi kilitleyip sayaç gösteriyor. Amaç, bar temposunu klavye yarışına kurban etmemek.

Ve günün son kararı: kapıya kilit

Gün biterken ürün kararı değişti: kulüp üyelik zorunlu olacak ve sistem açılmadan önce daha da geliştirilecek. Bu yüzden şu an canlıda kapı kapalı:

Backend'de tek satırlık bir bayrak (KULUP_ACIK = False) oturma ve bekleme uçlarını 403 ile kesiyor.
"Kapıdan Gir" düğmesi "🪑 Yerini Rezerve Et" oldu. Popup yalnızca e-posta + isteğe bağlı "hangi gün/saatlerde gelmek istersin?" alıyor. Kayıtlar diske yazılıyor (kulübün geri kalanının aksine, çünkü bunlar açılış davetiyesi listesi).
Salon, masalar, ses, peçete: kodun tamamı yerinde duruyor. Bayrak True yapıldığında mekân olduğu gibi geri gelecek, muhtemelen üyelik katmanıyla sarılmış olarak.

Bir günde inşa edip aynı gün kapısına "yakında" tabelası asmak tuhaf görünebilir. Ama bence sıralama doğru: önce mekânın çalıştığını uçtan uca kanıtla (iki sekmeli WebRTC testleri dahil), sonra kimlerin gireceğine karar ver. Tersi, üyelik sistemini boş bir mekân için kurmak olurdu.

Bir günün dürüst bilançosu

İyi çalışan şeyler: yoklama tabanlı mimari beklediğimden sağlam çıktı; WebRTC sinyalini aynı kanaldan taşımak ayrı bir sinyal sunucusunu tamamen ortadan kaldırdı; bellek içi durum + "her şey masada kalır" ilkesi hem gizlilik hem operasyon yükü açısından ucuz.

Bilinen borçlar: TURN yok; YouTube süre bilgisi yok (manuel geçiş); adisyon istemci tarafında (sekme açık ama kullanıcı yoksa 5+1 dakika koltuk işgali mümkün); yoklama aralıkları 30 kullanıcı üstü için yeniden düşünülmeli.

Akıbet: Bu revizyondaki her özellik gözlem altında. Kullanılmayanlar kaldırılacak, tutunanlar üyelik sistemiyle birlikte v2'ye taşınacak. Bir sonraki bölümde muhtemelen ya üyelik mimarisini ya da bu deneylerden hangilerinin hayatta kaldığını yazacağım.

Soruları yorumlara bırakabilirsiniz; özellikle "polling yerine WS kullansaydınız" itirazlarını memnuniyetle tartışırım.

Bir web sitesini yapay zekâya teslim ettim: kafa1milyon'un otonom yayın mimarisi (Bölüm 1)

Guray — Wed, 12 Aug 2026 14:08:42 +0000

Bu serinin yazarı Güray: AI geliştirmecisi, prompt ve analiz mühendisi. Kodun büyük kısmını bir LLM ajanıyla pair programming yaparak yazıyorum; benim işim mimariyi, protokolleri ve kalite çıtasını tasarlamak. Bu seri, kafa1milyon.com'un perde arkasını mühendis gözüyle belgeliyor.

Tez: Bu bir web sitesi değil, kendi kendini yayınlayan bir sistem

kafa1milyon.com dışarıdan bakınca sıradan bir Türkçe içerik portalı: bilim, tarih, psikoloji yazıları, günlük tarot falı, arkeoloji haberleri, sesli anlatımlar, X ve Instagram'da video fragmanlar.

Perde arkasında ise insan müdahalesi olmadan şunları yapan bir sistem çalışıyor:

RSS radarlarıyla dünya basınını ve bilimsel dergileri tarıyor
Konu adaylarını kalite kriterlerine göre kendisi süzüyor (onay beklemiyor)
Birincil kaynaklardan araştırıp 700-1.100 kelimelik yazılar üretiyor
Her yazıya hero görseli, JSON-LD, sitemap kaydı, IndexNow ping'i ekliyor
Yayın kalitesinde Türkçe seslendirme üretiyor (kota yönetimiyle birlikte)
Sanal bir sunucu karakterin (Elif) dikey tanıtım videolarını üretiyor
X ve Instagram'a günlük limitlere ve bekletme tarihlerine uyarak paylaşıyor
Her adımı doğruluyor: HTTP 200 kontrolü, ffprobe, hatta ürettiği videoyu Whisper ile geri dinleyip metnin doğru söylenip söylenmediğini teyit ediyor

Bu yazı serinin ilki: sistemin genel mimarisi ve en önemli tasarım kararı olan "kural dosyaları = sistemin uzun süreli hafızası" yaklaşımı.

Mimari: LLM ajan + kural dosyaları + kuyruklar

Kaba şema şöyle:

┌─────────────────────────────────────────────────────┐
│  LLM AJAN (Cursor içinde çalışan agent)             │
│  - araştırma, yazım, kod üretimi, tarayıcı kontrolü │
└──────────────┬──────────────────────────────────────┘
               │ her oturumda okur
┌──────────────▼──────────────────────────────────────┐
│  KURAL DOSYALARI (.cursor/rules/*.mdc)              │
│  yazım stili · SEO protokolü · seslendirme akışı    │
│  X/Instagram standardı · tarot formatı · video      │
│  standardı · taslak kuyruğu politikası              │
└──────────────┬──────────────────────────────────────┘
               │ üretir / günceller
┌──────────────▼──────────────────────────────────────┐
│  DURUM (dosya tabanlı, git'lenebilir)               │
│  xpost/queue.json · instagram/queue.json            │
│  tarot/gecmis.json · radar/son-tarama.json          │
│  taslak-durum.json (VPS'te küçük bir API)           │
└──────────────┬──────────────────────────────────────┘
               │ rsync
┌──────────────▼──────────────────────────────────────┐
│  VPS (nginx, statik HTML) + Cloudflare              │
└─────────────────────────────────────────────────────┘

Dikkat çekmek istediğim üç karar var.

1. Veritabanı yok, framework yok: dosya tabanlı durum

Sitenin tamamı statik HTML. Kuyruklar, geçmiş kayıtları ve radar çıktıları düz JSON dosyaları. Örneğin sosyal medya kuyruğundaki bir öğe:

{
  "text": "Tıraş ettikçe kıl gürleşir diyorlar.\n\nBilim buna neredeyse yüz yıldır aynı cevabı veriyor.",
  "url": "https://kafa1milyon.com/yazi/tiras-efsanesi/",
  "kat": "Bilim",
  "video": "video-lab/xvideo/elif-tiras-efsanesi.mp4",
  "hold_until": "2026-08-12",
  "posted": false
}

hold_until alanı sistemin tempo kontrolü: ajan istediği kadar içerik üretebilir ama X'in spam filtresine yakalanmamak için günde 2-3 paylaşım limiti var. Üretim ve yayın birbirinden ayrıştı; üretim hızlı, yayın sabırlı.

Bir LLM ajanla çalışırken dosya tabanlı durumun büyük avantajı şu: ajan durumu cat ile okuyabiliyor, python3 - ile güncelleyebiliyor, hata yaptığında diff'ten geri alınabiliyor. ORM'siz, migration'sız, şeffaf.

2. Kural dosyaları = derlenmiş deneyim

Sistemin asıl "zekâsı" modellerde değil, kural dosyalarında birikiyor. Her .mdc dosyası, yaşanmış bir problemin damıtılmış çözümü. Gerçek bir örnek, yazım stili kuralından:

## Uzunluk: KISA TUT (kullanıcı geri bildirimi, ZORUNLU)

Yazılar haddinden uzun olunca okur detaylarda boğulup yarıda bırakıyor.
- Hedef: 700-1.100 kelime (4-7 dk okuma).
- Giriş 2 paragrafı geçmez; ilk cümle doğrudan sahneye/soruya girer.
- Aynı iddiayı ikinci örnekle kanıtlama; en güçlü tek örneği seç, gerisini at.

Bu satırlar bir prompt değil, protokol. Okur yazıları yarıda bırakınca analiz ettik, kararı verdik, kurala işledik. Artık sistem her yeni yazıda bu dersi hatırlıyor. "Kendi kendine gelişen sistem" derken kastettiğim mekanizma bu: her hata ve her geri bildirim, bir kural dosyası güncellemesine dönüşüyor. Model unutur; dosya unutmaz.

Şu an ~10 kural dosyası var: yazım stili, SEO standardı, seslendirme akışı, X paylaşım formatı (fragman tarzı, spoiler yasağı), Instagram aynalama, günlük tarot formatı (üç kart + "bize ne olacak" bölümü), arkeoloji radarının görsel politikası, sanal sunucu Elif'in sabit karakter tanımı...

3. Doğrulama döngüleri: ajan kendi çıktısına güvenmez

LLM tabanlı otomasyonda en tehlikeli an, sistemin "bitti" dediği an. Bu yüzden her üretim adımının bir doğrulayıcısı var:

Yayın: deploy sonrası her yeni URL'ye HTTP isteği, 200 kontrolü.
Ses: üretilen MP3 ffprobe ile süre/bitrate kontrolünden geçiyor.
Video: en sert kontrol burada. Görüntü-videoya (image-to-video) modeli sunucu karakterimize bir metin söyletiyor; ama model bazen metni değiştiriyor ya da eski bir çekimin sesini kullanıyor. Çözüm: üretilen her video faster-whisper ile transkript ediliyor ve söylenen metin, istenen metinle karşılaştırılıyor. Uymuyorsa video çöpe gidiyor, yayına giremiyor.

segments, info = model.transcribe("elif-clip.mp4", language="tr")
soylenen = " ".join(s.text for s in segments)
# istenen metinle benzerlik düşükse: RED, yeniden üret

Bu döngü bizi en az bir kez kurtardı: model, yeni konu için ürettiğimiz videoda eski bir çekimin kapanış cümlesini söylemişti. Transkript kontrolü olmasaydı yanlış video yayına girecekti.

Otonomi modeli: onay kuyruğundan onaysız üretime

Başta her konu adayı kullanıcı onayı bekliyordu. Bir taslak sayfası, VPS'te minik bir onay API'si ({"onayli": [], "yazildi": []}), seçilenlerin yazılması... Sonra fark ettik ki dar boğaz onay adımının kendisi. Kalite kriterleri zaten kurallarda yazılıysa, süzgeci ajan kendisi işletebilir.

Şimdiki model: ajan adayları bulur, kalite/etik süzgecinden geçirir (tıbbi tavsiye yok, siyaset yok, zayıf hikâye elenir), uygun olanları kuyruğa alır ve yazar. İnsan istediği an taslak sayfasından kuyruğa öncelik verebilir ama sistemin ilerlemesi insana bağlı değil. İnsan onayı bir kapı olmaktan çıkıp bir yönlendirme sinyaline dönüştü.

Bu, prompt mühendisliğinden çok analiz mühendisliği: hangi kararların gerçekten insan yargısı gerektirdiğini, hangilerinin yazılı kritere indirgenebileceğini ayrıştırmak. İndirgenebilen her karar, otonom sistemin bir parçası oluyor.

Başarısızlıklar da mimarinin parçası

Bu seride pembe tablo çizmeyeceğim; sistemin bugünkü hâli, çöpe giden denemelerin üstünde duruyor:

X'in ücretsiz API'si öldü (Şubat 2026, yazma uçları 402 dönüyor). Çözümü tarayıcı otomasyonu + intent URL'lerde bulduk; X'in React composer'ına programatik metin yazmak ise imkânsıza yakın çıktı. Video eklemek için Chrome DevTools Protocol ile DataTransfer enjeksiyonu gerekti. (Bölüm 2'nin konusu.)
Wav2Lip ile dudak senkronu teknik olarak çalıştı, kalite olarak reddedildi: robotik, bozuk. Bazen "çalışan çözüm" doğru çözüm değildir; onun yerine ses üretimini video modelinin kendisine bıraktık.
Sinematik tanıtım filmi projesi tamamen iptal edildi. Uzun formda kesme/geçiş/senkron kalitesini otomasyonla tutturamadık. Ders: kısa dikey format (10 sn, tek çekim, tek karakter) otomasyonun bugünkü tatlı noktası; uzun form değil.

Sıradaki bölümler

X otomasyonu savaşı — ücretsiz API'nin ölümü, intent URL'ler, CDP ile dosya enjeksiyonu, nginx ^~ CORS detayı
Seslendirme boru hattı — Türkçe TTS'te prozodi, request stitching, karakter kotası yönetimi
Radar sistemleri — RSS + LLM süzgeciyle günlük konu keşfi, tekrar kontrolü
Elif — sabit karakterli sanal sunucu: image-to-video, kimlik tutarlılığı, transkripsiyon doğrulama
SEO otonomisi — JSON-LD, IndexNow, iç bağlantı otomasyonu

Sorusu olan yorumlara beklerim. Sistemin ürettiklerini görmek isterseniz: kafa1milyon.com