Hani, Bir mülakat hazırlık platformunu sırf “soru listesi” gibi görmek, bence en büyük hata. Çünkü mesele yalnızca soru göstermek değil; — ki bu tartışılır — doğru soruyu, doğru zamanda, tekrar etmeyecek şekilde ve biraz da akıllı davranarak sunmak. JS tabanlı bir platformda bunu yapınca iş bir anda düz CRUD ekranından çıkıyor… ve bayağı ilginç hale geliyor.
Geçen sene, 2025’in Kasım ayında İstanbul’da bir ürün toplantısında tam da bu konu konuşuluyordu: “Neden aynı closure sorusunu üç farklı yerde görüyoruz?” diye sormuştu ekipten biri. O an şunu fark ettim; içerik üretimini manuel bırakınca sistem zamanla şişiyor, eskiyor ve kendini tekrar ediyor. Açık konuşayım, kullanıcıyı en çok yoran şey de bu oluyor.
İşte tam da bu noktada devreye giriyor.
Bu yazıda anlatılan yaklaşımın hoş tarafı şu: sadece yapay zekâya soru yazdırmıyorlar (ben de ilk duyduğumda şaşırmıştım). Önce neyin. Var olduğunu kontrol ediyorlar, sonra benzerleri ayıklıyorlar, ardından insan onayıyla bankaya ekliyorlar. Yani ortada “ChatGPT’ye bağladık oldu” tipi bir gösteri yok; daha çok katmanlı, kontrollü ve uzun vadede yaşaması mümkün bir düzen var.
Neden klasik soru bankası yetmiyor?
Bakın, Klasik model çok tanıdık. Birisi oturup 100 soru yazar, veritabanına atar, sonra sistem yıllarca aynı setle döner durur. Kağıt üstünde fena değil gibi görünür — ama pratikte işler çabuk bozuluyor. JavaScript gibi her yıl yeni API’ların, yeni pattern’lerin, yeni tartışmaların peş peşe geldiği bir dünyada 2021’de yazılmış soru seti bugün biraz tozlu, biraz da yanıltıcı kalıyor açıkçası.
Ben buna ilk kez 2023’te Ankara’da küçük bir eğitim girişimi için danışmanlık yaparken denk gelmiştim. Bankada yüzlerce soru vardı. Ama yarısı ya güncel — itiraz edebilirsiniz tabi — değildi ya da birbirinin ufak varyasyonuydu. Kullanıcı geri bildirimlerinde sürekli aynı cümle dönüyordu: “Bunu az önce görmüştüm.” E tabi haklıydılar.
Bir de asıl can sıkıcı taraf var — duplicate meselesi. İnsan eliyle içerik üretilince iki farklı editörün aynı konuyu farklı kelimelerle yazması çok normal, hatta kaçınılmaz. Ama sistem bunu anlayamazsa sonuç kötü oluyor. Kullanıcı “benzersiz içerik” beklerken aslında makyajlanmış tekrarlarla uğraşıyor. Sinir bozucu. Gerçekten.
Kısa bir not düşeyim buraya. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
İşin özü şu: AI’yı sadece metin üreten bir musluk gibi kullanırsanız gürültü çoğalır; ama retrieval, benzerlik kontrolü ve insan onayıyla bağlarsanız gerçekten işe yarayan bir sisteme dönüşüyor.
Dört katmanlı yapı neden önemli?
Bana göre bu mimarinin en sevdiğim yani fazla kahramanlık yapmaması. Her bileşenin işi ayrı verilmiş. Ve sonuç: sistem hem okunabilir kalıyor hem de büyütmesi kolaylaşıyor. Firestore veri kaynağı olarak duruyor; embeddings anlam katmanı sağlıyor; similarity search yakın eşleşmeleri yakalıyor; LLM ise son karar verme. Açıklama kısmını üstleniyor. Güzel ayrım.
Böyle ayrıştırınca bakım masrafı düşüyor. Mesela embedding modeli değiştirmeniz gerekiyorsa — ki er ya da geç gerekiyor — tüm sistemi söküp takmanız gerekmiyor, sadece o katmanı oynuyorsunuz. Kurumsal tarafta bunun değeri büyük çünkü ekipler bir düşüneyim… arası bağımlılık azalıyor; startup tarafında ise hız kazandırıyor. İkisi de değerli, farklı sebeplerle.
| Katman | Görev | Neden gerekli? |
|---|---|---|
| Firestore | Soruların ve embedding’lerin kaydı | Tek doğruluk kaynağı sağlar |
| Embeddings | Anlam temsili oluşturur | Aynı anlamdaki soruları yakınlaştırır |
| Similarity Search | Yakın komşuları bulur | Duble soruları engeller |
| AI / LLM | Soru üretir ve değerlendirir | Kural bazlı olmayan akıl yürütme verir |
Neyse uzatmayayım… Bu ayrım bana geçen martta Berlin’de incelediğim başka bir AI iş akışını hatırlattı; orada tek servis her şeyi yapmaya çalışıyordu ve her deploy küçük bir kumardı resmen. Buradaki yapı ise daha sakin, daha az kalp krizi ilerliyor (ciddiyim)
Kısa bir not düşeyim buraya.
Embedding mantığı neden kritik?
Sadece başlık yetmez
Sorunun başlığını vektöre çevirmek güzel fikir gibi duruyor. Ama eksik kalıyor. Dur bir saniye — önce şunu söyleyeyim: bir JavaScript sorusu çoğu zaman tek başlığıyla anlaşılmaz. Aynı tema farklı zorlukta gelebilir; örneğin “closure nedir?” ile “closure kullanarak memory leak nasıl önlenir?” arasında ciddi fark var. Kulağa benzer geliyor ama hedef kitle, beklenti, derinlik — hepsi farklı. Daha fazla bilgi için Yarbo M Serisi Güncellendi: Bahçede Yeni Dönem yazımıza bakabilirsiniz.
Bu yüzden type-aware input denen yaklaşım mantıklı geliyor. Yani question type’a göre farklı alanları birlikte embed ediyorsunuz. Çok basit düşünün: başlık artı açıklama artı etiketler artı cevap beklentisi, bunlar bir arada daha dolu bir anlam haritası çıkarıyor. Sadece başlığı gören model kör topal kalır; bütün paketi gören model ise — şaşırdım açıkçası — çok daha isabetli oluyor.
// Basitleştirilmiş örnek
function buildEmbeddingInput(question) {
if (question.type === "concept") {
return `${question.title}
${question.explanation}
Tags:${question.tags.join(", ")}`;
}
if (question.type === "coding") {
return `${question.title}
Difficulty:${question.difficulty}
Expected:${question.expectedSkills.join(", ")}`;
}
return question.title;
}Kosinüs benzerliği niye kullanılıyor?
Bilmem anlatabiliyor muyum, Kosinüs benzerliği kulağa akademik geliyor. Günlük karşılığı şu ama: iki şeyin yönü ne kadar aynı? Uzunluğu biraz değişse de yön aynıysa anlam olarak birbirine yakındırlar diyoruz. Bu yüzden duplicate tespitinde baya iş görüyor. Geçen yıl Temmuz’da kendi not defterimde benzerlik bazlı içerik temizleme denemesi yaptığımda şunu gördüm: eşikler iyi ayarlanmazsa ya fazla agresif olup faydalı soruları siliyorsunuz, ya da gevşek bırakıp çöpü içeri alıyorsunuz. İkisi de kötü. İşin sırrı ince ayarda yatıyor… hani araba direksiyonu gibi, çok sert çevirirsen yoldan çıkıyorsun.
Cron işi otomatikleştirince ne değişiyor?
Sistemin haftalık cron ile çalışması bence önemli detaylardan biri. Çünkü içerik üretimini gündelik operasyondan çıkarıp ritme bağlıyor. Her hafta belli miktarda aday soru üretiliyor, sonra bunlar değerlendirme hattına giriyor. Böylece platformun içeriği yaşayan bir organizmaya dönüşüyor; donmuş arşiv olmaktan çıkıyor. Fark büyük. Bu konuyla ilgili Xiaomi’nin Yeni Tıraş Seti: Sakala Göre Güç, Kendi Kendine Temizlik yazımıza da göz atmanızı tavsiye ederim.
Peki bu neden güzel? Çünkü mülakat trendleri sabit değil. Bugün Promise.withResolvers konuşulur, yarın structuredClone, öbür gün belki bambaşka bir async pattern popüler olur. Platformun bunu takip etmesi gerekiyor. Elle yapmak yerine planlı otomasyon kurunca yük hafifliyor. Ama şöyle de bir gerçek var: tam otomasyon bazen hayal kırıklığı yaratabiliyor, özellikle model saçmaladığı anda insan gözünün devreye girmesi şart oluyor. Bu kısmı atlarsanız sonuçlar garip yerlere gidiyor. Bu konuyla ilgili Python JSON’da RAM Şişmesi: 2 GB’ı Nasıl Erittim? yazımıza da göz atmanızı tavsiye ederim.
- Küçük startup için avantajı net: az kişiyle sürdürülebilir yayın akışı sağlar.
- Kurumlarda avantaj başka yerde çıkar: kalite kapısından geçmeyen içerik bankaya girmez. — bunu es geçmeyin
- Zayıf taraf mı? Cron yanlış kurgulanırsa gereksiz maliyet yaratır veya gürültü üretir. — ciddi fark yaratıyor
- Dengeyi kuramazsanız sistem kendi kuyruğunu yemeye başlar — maalesef öyle.
İnsan onayı neden hâlâ vazgeçilmez?
Bazıları burada hemen itiraz ediyor: “AI üretiyorsa niye insan bakıyor?” Bakın şimdi… çünkü dil modeli iyi olabilir ama ürün standardınızı siz belirlersiniz. Bilhassa eğitim odaklı bir düşüneyim… platformlarda güven duygusu önemli — Yanlış veya muğlak soru kullanıcıyı kaçırır. Bir kere kaçtı mı geri getirmek zorlaşır. O yüzden QA aşaması lüks değil; doğrudan sigorta poliçesi gibi düşünülmeli.
Hani, Editör masasında böyle işleri ilk kez test ettiğimde İzmir’deydim, Nisan 2024’tü sanırım; ekrandaki beş aday sorudan ikisi teknik olarak doğruydu ama pedagojik açıdan zayıftı. Yani cevap doğrudur — itiraz edebilirsiniz tabi — fakat öğrenme değeri düşüktür — küçük fark gibi görünür ama etkisi büyük olur. İnsan editör tam burada devreye giriyor: fazla genel mi, çok dar mı, tekrar mı ediyor, güncel mi? Sorular bunlara takılıyor mu diye bakılıyor. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Kendi kullanım senaryomda nasıl okurum?
Aslında, Eğer küçük çaplı çalışan tek kişilik bir ekipseniz bu yapı size biraz ağır gelebilir gibi durabilir (inanın bana). Ama açık konuşayım: ilk bakıştaki ağırlık aldatıcı. Doğru kurulduğunda elle moderasyon yükünü azaltıp sizi rahatlatır. Enterprise seviyesinde ise değer daha da artar çünkü audit izi oluşur; hangi soru neden kabul edildi, hangi embedding nedeniyle elendi, bunların hepsi geriye dönük izlenebilir. Bu özelliği küçümsemeyin.
Bana göre güçlü yanları ve zayıf noktaları neler?
Dikkat: Bu tip sistemlerde en büyük risk teknik karmaşıklığın ürün hissini bozmasıdır. Güzel görünür ama eğer hız yavaşsa ya da filtre fazla sertse kullanıcı hiçbir şeyi hissetmez — boşuna emek gitmiş olur.
| Güçlü taraflar | Zayıf taraflar |
|---|---|
| Anlam temelli duplicate kontrolü iyi çalışır | Eşik ayarı yanlışsa faydalı içerikler de elenir |
| Cron sayesinde sürekli güncel kalabilir | Tam otomasyon maliyet yaratabilir |
Kafanı karıştırmayayım diye düzelteyim: tabloyu düzgün okumak lazım. Özünde mesele, sistemi süslü göstermek değil; sağlam tutmak. Ben olsam önce veri kalitesine, sonra embedding seçimine, en son da prompt tasarımına bakarım. Sırayı ters kurarsanız performansınız kağıt üstünde iyi görünür… sahada tökezler.
Bir arkadaşım, Haziran 2024’te Londra’daki fintech ekibinde buna benzer yapı kurmuştu; dedikleri şey netti: “En pahalı hata, yanlış içeriği ölçeklemek.” Bu cümleyi hiç unutmadım. Çünkü gerçekten öyle. Kötüyü hızlı dağıtmanın kimseye faydası yok.
Sıkça Sorulan Sorular
RAG tam olarak ne işe yarar?
RAG, modeli dış kaynakla besleyip daha isabetli cevap vermesini sağlar. Hele bir de güncel bilgi gereken yerlerde işe yarar. Soru bankası veya dokümantasyon tabanlı uygulamalarda oldukça kullanışlıdır.
Embedding olmadan duplicate tespiti yapılabilir mi?
Yapılır, ama kaba olur — Anahtar kelime bazlı yöntemler benzer anlamları kaçırabilir. Embedding ise cümlenin niyetini yakalamaya yardım eder.
Bu yapı küçük ekipler için fazla karmaşık mı?
Başta öyle görünebilir. Ama veri hacmi büyüyorsa erken kurmak uzun vadede rahatlatır. Küçük ekiplerde bile manuel tekrarları azaltarak zaman kazandırabilir.
İnsan onayı gerçekten şart mı?
Ne yalan söyleyeyim, Evet, özellikle eğitim veya güven odaklı ürünlerde şart sayılır (evet, doğru duydunuz). Model iyi olsa bile bağlam hatası yapabilir; editör gözü son kalite filtresi gibidir.
Kaynaklar ve İleri Okuma
Orijinal Teknik Yazı — Dev.to Kaynağı
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
