RAG ile Türkçe Dokümanlarınıza Özel Yapay Zekâ Asistanı Kurulumu (2025 Rehberi)

RAG nedir ve neden gerekli?

Kurumsal veriler üzerine çalışan yapay zekâ asistanlarının en büyük sorunlarından biri, modelin eğitim verisinde olmayan bilgiler hakkında uydurma (hallucination) üretmesidir. RAG (Retrieval-Augmented Generation) yaklaşımı, üretken modelden önce güvenilir kaynaklardan ilgili parçaları arayıp getirir, ardından bu bağlam ile yanıt oluşturur. Böylece cevaplar hem daha doğru hem de kaynaklanabilir olur. Bu yazıda, Türkçe dokümanlarınız için RAG tabanlı bir asistanı sıfırdan nasıl kurabileceğinizi adım adım anlatıyorum.

Mimari bileşenler

1) Doküman alımı ve ayrıştırma: PDF, Word, e-posta arşivi ya da Confluence/Jira gibi bilgi tabanlarından veriyi çekin. PDF’lerde metin çıkarımı için OCR gerekebilir. Tablo ve görselleri metne dönüştürürken bağlamı kaybetmemeye dikkat edin.

2) Temizleme ve parçalama (chunking): Türkçe metinlerde noktalama ve büyük/küçük harf (İ/ı) uyumuna dikkat edin. Belgeyi 300–500 kelimelik, %10–15 örtüşmeli parçalara ayırın. Başlık ve bölüm bilgilerini her parçaya meta veri olarak ekleyin.

3) Vektörleştirme (embedding): Türkçe desteği güçlü gömlemeler kullanın. Bulut tabanlı text-embedding-3-large (OpenAI) veya açık kaynak bge-m3 ve multilingual-e5-large iyi seçeneklerdir. Gizlilik gereksinimi yüksekse modeli yerelde çalıştırın.

4) Vektör veritabanı: Chroma, Qdrant, Milvus ya da FAISS ile arama yapın. Üretim ortamı için Qdrant/Milvus, prototip için Chroma/FAISS tercih edilebilir. Metadata alanlarında belge tipi, sayfa, bölüm gibi sahaları tutun.

5) Sorgu işleme: Yalnızca vektör araması yerine hibrit arama (BM25 + vektör) ve bir yeniden sıralayıcı (ör. bge-reranker) ekleyin. Bu, Türkçe uzun sorgularda isabeti ciddi şekilde artırır.

6) Üretken model (LLM): Bulutta GPT-4o mini gibi hızlı/uygun maliyetli bir model veya yerelde Llama 3.1 8B, Mistral 7B gibi modelleri Ollama üzerinden çalıştırabilirsiniz.

Adım adım kurulum

Adım 1 – Ortam: Python 3.11 ile bir sanal ortam kurun. Gerekliyse Docker ile Qdrant/Milvus çalıştırın. Projede LangChain veya LlamaIndex gibi bir çatı kullanmanız geliştirmeyi hızlandırır.

Adım 2 – Veri toplama: Belgeleri tek bir dizinde toplayın. Yetkisiz içerikleri ayıklayın; erişim seviyesine göre dizinleri bölmek ileride yetkilendirme için işinize yarar.

Adım 3 – Ön işleme: PDF sayfa kırıkları, dipnotlar ve sayfa numaralarını temizleyin. Türkçe’de noktalama ve karakter dönüşümlerini (ör. apostrof, tırnak) normalize edin. Gereksiz boşlukları ve tarih/sürüm kalıntılarını ayıklayın.

Adım 4 – Parçalama: İçerik türüne göre strateji belirleyin. Teknik belgelerde başlık bazlı, SSS’lerde soru-cevap bazlı, politikalar/prosedürlerde paragraf bazlı parçalama daha başarılı olur. Her parçaya kaynak_linki, belge_türü, bölüm gibi meta verileri ekleyin.

Adım 5 – Embedding seçimi: Türkçe performansı yüksek bir modelle test yapın. Aynı veri üzerinde 10–20 örnek sorgu ile top-k isabetini ölçerek model seçimi yapın. Gizlilik gereksinimi varsa açık kaynak bir modelle yerelde kalın.

Adım 6 – Vektör veritabanı kurulumu: Chroma ile hızlı prototip, Qdrant/Milvus ile üretim kurulumu yapın. İndeks parametrelerinde HNSW grafı ve uygun M, efConstruction değerlerini deneyerek gecikme-doğruluk dengesini bulun.

Adım 7 – İndeksleme: Parçaları gömleyip veritabanına yazın. Versiyonlama yapın; her yüklemeye bir batch_id vererek geri alım (rollback) kolaylığı sağlayın. Büyük yüklemelerde artımlı (incremental) indekslemeyi tercih edin.

Adım 8 – Sorgu boru hattı: Kullanıcı sorgusunu önce query rewriting ile netleştirin (gerekiyorsa çoklu sorgu üretimi). Ardından hibrit arama yapın, ilk 20 sonucu alın, bir reranker ile en iyi 5–7 bağlamı seçin. MMR ile çeşitlilik sağlayın.

Adım 9 – Prompt tasarımı: Sistem mesajına “Sadece verilen bağlamdan yanıtla, emin değilsen ‘elimdeki kaynaklarda yok’ de” gibi kurallar koyun. Yanıt sonunda Kaynaklar bölümünde belge adı ve bölüm başlığını listeleyin.

Adım 10 – Değerlendirme: 50–100 soruluk altın set hazırlayın. Ölçütler: cevap alaka puanı, bağlam isabeti, kaynak doğruluğu, gecikme, maliyet. Otomatik değerlendirme için küçük bir script ile yanıt-kaynak uyuşumunu ölçebilirsiniz.

Adım 11 – Yayına alma: FastAPI ile bir servis oluşturun. Redis önbellekle sık soruların yanıtlarını tutun. Yüksek trafikte rate limit ve tamamlama uzunluğu sınırlamaları önemli. Gözlemlenebilirlik için OpenTelemetry ile izleme kurun.

Adım 12 – Güvenlik ve gizlilik: Hassas verileri indekslemeden önce PII maskesi uygulayın. Vektör veritabanını özel ağda tutun. Kullanıcı bazlı yetkilendirme yapıyorsanız sorgu sırasında metadata filtreleri ile erişim kısıtlayın.

Performans ipuçları

- Top-k değerini rastgele yükseltmek yerine hibrit arama + reranker kullanın; maliyeti ve gecikmeyi düşürür.

- Çok uzun bağlamlar yerine 5–7 yüksek kaliteli pasaj verin; LLM’ler daha odaklı yanıtlar üretir.

- Maliyet kritikse önce hızlı bir modelle taslak, ardından önemli akışlarda daha güçlü bir modelle doğrulama yapın.

- Türkçe’de eşanlam ve ekler önemlidir; sorgu genişletme (synonym expansion) ve kök bulma (stemming/lemmatization) deneyin.

Sık karşılaşılan hatalar

- Kaynak sızıntısı: Yanıtlarda kapalı belge adlarının görünmesi. Çözüm: metadata’yı kullanıcı rolüne göre filtreleyin ve prompt’ta kaynak gösterimini maskeleyin.

- Aşırı uzun parçalar: Gömlemelerin ayrıştırıcılığı düşer. 300–500 kelime aralığını aşmamaya çalışın.

- Zayıf gömleme modeli: Çok dilli ama Türkçe’de zayıf bir model, arama kalitesini bozar. Küçük bir değerlendirme seti ile model seçimi yapın.

Sonuç

RAG, Türkçe kurumsal dokümanlarda güvenilir ve kaynaklanabilir yanıtlar üretmenin en pratik yolu. Doğru gömleme, hibrit arama, reranking ve titiz prompt tasarımıyla, hem doğruluğu hem de kullanıcı güvenini önemli ölçüde artırabilirsiniz. Küçük bir prototiple başlayıp ölçümlere göre adım adım optimize edin; doğru mimariyle RAG tabanlı asistanınız kısa sürede üretim kalitesine ulaşacaktır.

RAG Tabanlı Kendi Yapay Zekâ Asistanınızı Kurun: LangChain ve LlamaIndex ile Adım Adım Rehber

Üretken yapay zekâ (GenAI) uygulamaları hızla yaygınlaşırken, doğru ve güncel bilgiye dayalı yanıtlar üretmek için en çok konuşulan yaklaşım RAG (Retrieval-Augmented Generation) oldu. Bu yazıda, RAG nedir, hangi durumlarda kullanılır, hangi araçları tercih etmelisiniz ve LangChain ile LlamaIndex kullanarak nasıl adım adım bir RAG hattı (pipeline) kurabilirsiniz sorularına pratik ve güncel bir rehberle yanıt vereceğim.

RAG nedir ve neden önemli? Klasik büyük dil modelleri yalnızca eğitim verisiyle sınırlıdır ve güncelliği hızla kaybedebilir. RAG, modelin yanıt üretmeden önce bir vektör veritabanından ilgili belgeleri geri çağırmasını (retrieval) sağlar. Bu sayede hem güncel hem de şirket içi özel bilgilere dayalı doğru, kaynaklı ve denetlenebilir yanıtlar üretirsiniz. Özellikle doküman asistanları, müşteri destek botları, teknik bilgi tabanı arayüzleri ve kurumsal arama projelerinde RAG çok etkili bir çözümdür.

Gereksinimler ve genel mimari Basit bir RAG hattı için üç bileşen gerekir: (1) Metinlerinizi parçalara (chunk) ayırıp sayısal vektörlere dönüştüren bir gömme (embedding) modeli; (2) Bu vektörleri saklayıp benzerlik araması yapan bir vektör veritabanı; (3) Geri çağrılan metinleri kullanıp yanıt üreten bir LLM. Ek olarak, yeniden sıralama (reranking), sorgu genişletme (query expansion) ve değerlendirme (eval) katmanlarıyla kaliteyi artırabilirsiniz.

Vektör veritabanı seçimi Başlangıç için gömülü ve kurulumu kolay Chroma iyi bir seçenek. Hafif, hızlı ve yerelde deney yapmak için ideal. FAISS, tek makinede yüksek performanslı aramalar için tercih edilebilir. Üretim ortamlarında ise Pinecone, Weaviate, Qdrant gibi servisler ölçeklenebilirlik ve yönetim kolaylığı sunar. Seçimde verinizin büyüklüğü, gecikme ihtiyaçları, bütçe ve regülasyon gereksinimlerini dikkate alın.

Embedding modeli seçimi Ücretli ve yüksek kaliteli bir seçenek arıyorsanız OpenAI’nin text-embedding-3-large modeli güçlü bir taban sunar. Açık kaynak tarafta bge-large, e5-large veya instructor-xl aileleri yaygın ve iyi sonuç veriyor. Türkçe performansı kritikse çok dilli destek sunan modelleri tercih edin ve mümkünse küçük bir doğrulama kümesi üzerinde kısa bir A/B testi yapın.

Parçalama stratejisi (chunking) Parça boyutu ve bindirme (overlap) kaliteyi doğrudan etkiler. 300–800 karakter aralığı genelde güvenli bir başlangıçtır; teknik belgelerde 1000–1500 karaktere çıkmak bağlam bütünlüğünü korumaya yardımcı olabilir. 10–20% arası bindirme, cümlelerin iki parça arasında bölünmesini yumuşatır.

LangChain ile hızlı başlangıç

LangChain, veri yükleme, parçalama, embedding, vektör dizinleme ve sorgulama adımlarını modüler şekilde birleştirmenizi kolaylaştırır. Pratik akış şu şekildedir: Belgeleri yükleyin, metinleri parçalara ayırın, embedding üretin, Chroma’ya kaydedin, ardından bir RetrievalQA zinciri oluşturun. Örnek kurulum adımı olarak komut satırında pip install langchain chromadb sentence-transformers komutunu kullanabilirsiniz. Basit bir sorgu akışı ise şu mantıkta ilerler: retriever.get_relevant_documents(soru) ile ilgili parçaları alın, ardından llm.invoke(prompt + bağlam) ile yanıt üretin. LangChain’in Runnable ve LCEL (LangChain Expression Language) soyutlamaları, üretim ortamında gözlemlenebilir, loglanabilir ve test edilebilir zincirler kurmayı kolaylaştırır.

Artıları: Zengin entegrasyon ekosistemi, güçlü zincir soyutlamaları, hızlı prototipleme. Eksileri: Çok modüllü yapı karmaşıklığa yol açabilir; versiyon uyumluluğuna dikkat etmek gerekir.

LlamaIndex ile belgeden yanıta

LlamaIndex, endekse odaklı bir tasarım sunar ve doküman odaklı akışlarda sade bir deneyim sağlar. Document ve Node yapılarıyla parça yönetimi şeffaftır; ServiceContext ile LLM ve embedding ayarlarını merkezi olarak kontrol edersiniz. Özet akış şudur: Belgeleri okuyun, VectorStoreIndex oluşturun, ardından query_engine veya chat_engine üzerinden sorgulayın. Basit bir kurulum için pip install llama-index chromadb yeterlidir. LlamaIndex ayrıca reranker ve response synthesizer yapılarıyla çıktı kalitesini artırmak için gömülü seçenekler sunar.

Artıları: Doküman merkezli tasarım, hızlı “belgeden yanıta” kurulum, iyi dokümantasyon. Eksileri: Çok özel iş akışlarında esneklik için ek özelleştirme gerekebilir; bazı ileri seviye özellikler sürümlere göre değişebilir.

Kaliteyi artırma teknikleri

Sorgu genişletme: Kullanıcının kısa sorusunu, olası eşanlamlılar ve bağlamla zenginleştirerek arama kalitesini artırabilirsiniz. RAG-Fusion veya çoklu sorgu tekniğiyle farklı varyantları arayıp birleştirmek iyi sonuç verir.

HyDE (Hypothetical Document Embeddings): Modelden, soruya dair “varsayımsal bir cevap” üretmesini isteyip bunu embedding’e çevirerek arama yapın; özellikle belgenin dili ile soru dili farklı olduğunda işe yarar.

Yeniden sıralama (Reranking): İlk 10 sonucu aldıktan sonra bir reranker modeliyle en iyi 3–5 sonucu seçin. Açık kaynak bge-reranker veya bulut tabanlı hizmetler (ör. Cohere Rerank) yaygın tercih edilir.

İstem (prompt) şablonları: Kaynakları listelemeyi zorunlu kılan, halüsinasyonu azaltan net yönergeler kullanın. Örnek: “Yanıtlarken yalnızca verilen bağlamı kullan. Emin değilsen ‘Bu bilgi bağlamda yok’ de. En sonda kullandığın kaynak başlıklarını sırala.”

Değerlendirme ve gözlemlenebilirlik

RAG projelerinde değerlendirme kritik önemdedir. Küçük ama temsil gücü yüksek bir test seti oluşturun. Doğruluk, alaka, kaynak kapsamı, yanıt uzunluğu ve gecikme gibi metrikleri izleyin. RAGAS gibi değerlendirme çerçeveleri yararlıdır. Üretimde ise isabet oranı, geri çağırma (recall), oturum başına iyi yanıt oranı ve kullanıcı memnuniyeti (thumbs up/down) gibi iş metriklerini takip edin.

Güvenlik, maliyet ve gizlilik

Kurumsal verilerle çalışırken erişim kontrolü, PII maskeleme ve denetim kayıtları (audit logs) şarttır. Maliyet tarafında embedding üretimi ve vektör arama en büyük kalemler olabilir; partisyonlama, sıkıştırma (PQ/IVF) ve önbellekleme ile maliyeti düşürün. Gizlilik gereksinimi yüksekse açık kaynak embedding ve yerel vektör veritabanı ile tamamen şirket içi (on-prem) kurulum yapılabilir.

Sonuç RAG, üretken yapay zekâyı pratik ve güvenilir hale getiren güçlü bir yöntemdir. Hızlı prototipleme için LangChain ve LlamaIndex iki sağlam seçenektir: İlki geniş entegrasyonları ve zincir mimarisiyle esneklik sunarken, ikincisi doküman odaklı basitliğiyle hızlı değer üretir. Doğru embedding, uygun vektör veritabanı, dikkatli chunking ve iyi bir değerlendirme disipliniyle kısa sürede, şirket verinizle konuşabilen sağlam bir asistan inşa edebilirsiniz.

Next.js Uygulamalarında WebAuthn (Passkey) ile Şifresiz Giriş: Adım Adım Rehber

Parola sızıntıları, phishing ve tekrar kullanılan şifreler derken kimlik doğrulama artık güvenliğin en zayıf halkası olmaya başladı. Tam da bu noktada WebAuthn ve Passkey yaklaşımı devreye giriyor. Tarayıcılar ve işletim sistemleri, donanımsal anahtarlar veya biyometrik sensörler aracılığıyla şifresiz, kimlik doğrulama destekli bir deneyim sunuyor. Bu yazıda, Next.js tabanlı bir web uygulamasına WebAuthn (Passkey) entegrasyonunu adım adım, pratik ipuçlarıyla anlatıyorum.

WebAuthn nedir? Özetle, tarayıcınız üzerinde çalışan ve FIDO2 standardıyla uyumlu modern bir kimlik doğrulama API’sidir. Kullanıcı, cihazındaki güvenli öğeler (Secure Enclave, TPM veya güvenlik anahtarı) aracılığıyla bir anahtar çifti oluşturur. Sunucu tarafında yalnızca genel anahtar saklanır; özel anahtar cihazı terk etmez. Böylece phishing riski ciddi ölçüde azalır, parola çalma senaryoları boşa düşer ve kullanıcı deneyimi hızlanır.

Temel kavramlar: Relying Party (RP), uygulamanızın kimlik doğrulamayı kullanan tarafıdır. rpId genellikle alan adınızdır (ör. example.com). origin ise protokol ve alan adını içerir (ör. https://example.com). Bu iki değer, güvenlik için kritik ve tarayıcı doğrulamasının merkezinde yer alır.

Ön koşullar ve gereksinimler: WebAuthn yalnızca HTTPS üzerinde çalışır. Geliştirme ortamı için https://localhost istisnası geçerlidir. Sunucu tarafında FIDO2 doğrulamasını kolaylaştırmak için SimpleWebAuthn gibi bir kütüphane kullanabilirsiniz. Next.js API Routes veya Route Handlers ile kayıt (registration) ve giriş (authentication) uç noktalarını ayırın. Veritabanında kullanıcıya ait credentialId, publicKey, signCount, transports gibi alanları saklayacağınız bir tablo/collection hazır bulunsun.

Kayıt (Registration) akışı nasıl işler? 1) Kullanıcı oturum açmadan önce ya da profil ekranından “Passkey ekle”yi seçer. 2) Sunucu bir challenge üretir ve istemciye PublicKeyCredentialCreationOptions ile gönderir: rp.name, rp.id, user.id, user.name, challenge, pubKeyAlg, attestation vb. 3) Tarayıcıda navigator.credentials.create() çağrılır; cihaz parmak izi/yüz tanıma ya da PIN ile onay ister. 4) Tarayıcıdan dönen attestation/clientDataJSON verileri sunucuya POST edilir. 5) Sunucu, veriyi doğrular; eşleşen rpId, origin, challenge ve imza kontrol edilir. 6) Doğrulama geçerse credentialId ve publicKey veritabanına eklenir. Artık kullanıcı, parolasız girişe hazırdır.

Giriş (Authentication) akışı nasıl işler? 1) Sunucu yeni bir challenge üretir ve istemciye PublicKeyCredentialRequestOptions ile gönderir (allowCredentials ile belirli credentialId’leri belirtebilir ya da disoverable credentials (resident keys) için boş bırakabilirsiniz). 2) Tarayıcıda navigator.credentials.get() çağrılır; kullanıcı cihazında biyometrik doğrulama ile imzalama yapılır. 3) İmza, clientDataJSON ve authenticatorData sunucuya geri gönderilir. 4) Sunucu, saklanan publicKey ile imzayı doğrular; signCount (anti-replay) kontrolünü günceller. 5) Başarılıysa güvenli bir oturum veya token üretir ve kullanıcıyı içeri alır.

rpId ve origin ayarları: rpId, üst düzey alan adınız olmalı (subdomain kullanıyorsanız, rpId genellikle kök alan adıdır). origin ise kesin ve tam eşleşmelidir (ör. https://app.example.com). Geliştirmede localhost kullanıyorsanız origin: https://localhost:3000 gibi olmalı; http yerine https zorunludur. Yanlış rpId ya da origin, en sık karşılaşılan hata nedenidir.

Güvenlik ve UX önerileri: 1) userVerification değerini “required” olarak ayarlayın; böylece biyometrik/PIN doğrulaması garanti altına alınır. 2) attestation genellikle “none” seçilir; gizliliği korur ve gereksiz sertifika karmaşıklığını azaltır. 3) Discoverable credentials (resident keys) ile kullanıcı adı girmeden giriş mümkündür; modern passkey deneyimi için önerilir. 4) Platform (cihaz içi) ve cross-platform (USB/NFC/Bluetooth anahtarlar) seçiminde kullanıcıya rehberlik edin. 5) iCloud Anahtar Zinciri ve Google Password Manager ile multi-device passkey senkronizasyonu sayesinde cihaz değişimlerinde erişim kolaylaşır. 6) Fallback akışı olarak e-posta sihirli linki veya destek süreci tasarlayın; fakat SMS OTP’yi temel kurtarma yolu yapmaktan kaçının.

Çerez ve CORS nüansları: Oturum için çerez kullanıyorsanız, üçüncü taraf senaryolarda SameSite=None; Secure ayarlarına dikkat edin. CSRF token korumasını atlamayın. API uç noktalarında yalnızca gerekli origin’lere izin verin ve yanıtlarınızda Cache-Control: no-store gibi başlıklarla hassas verilerin önbelleğe düşmesini engelleyin.

Sık yapılan hatalar: 1) rpId/origin eşleşmiyor: Tarayıcı reddeder. 2) Base64url kodlama/çözme yanlış: Özellikle credentialId ve ham bayt verilerinde hatalara neden olur. 3) Saat farklılıkları (clock skew): Token ve imza doğrulamaları etkilenebilir. 4) signCount güncellenmiyor: Anti-replay koruması devre dışı kalır. 5) Geliştirmede HTTP kullanma: WebAuthn çalışmaz, her zaman HTTPS.

Performans ve izleme: Kimlik doğrulama isteklerini ayrıntılı log’layın (challenge ID, rpId, origin, tarayıcı, platform). Başarısızlık oranlarını, cihaz türlerini ve geri dönüş sürelerini izlemek sorunları hızla yakalamanızı sağlar. Kullanıcı akışında gereksiz adımları azaltın; “Passkey ile giriş yap” butonunu görünür ve ilk seçenek haline getirin, parolayı ise ikincil yol olarak sunun.

Sonuç: WebAuthn ve Passkey entegrasyonu, hem güvenlik çıtasını yükseltir hem de kullanıcı deneyimini modernize eder. Next.js üzerinde birkaç uç nokta, doğru rpId/origin ayarı ve basit bir istemci çağrısıyla dakikalar içinde çalışan bir şifresiz giriş deneyimi elde edebilirsiniz. Başlangıçta kavramlar yoğun görünse de pratikte süreç net: challenge üret, tarayıcıda kimlik doğrula, imzayı doğrula, oturumu başlat. Bugün başlarsanız, yarın kullanıcılarınız parolasız bir geleceğe geçmiş olur.

eBPF ile Linux Gözlemlenmesi: Başlangıçtan İleri Seviyeye Pratik Rehber

Giriş

eBPF (extended Berkeley Packet Filter), modern Linux çekirdeğinde çalışan küçük programlar yazarak sistem davranışını güvenli ve yüksek performanslı şekilde gözlemleme imkânı sunar. Bu rehber, temel kavramlardan başlayıp pratik izleme örneklerine ve üretimde kullanılabilecek yaklaşımlara kadar adım adım ilerler. Hedef okuyucu; kernel gözlemi, uygulama performansı analizi veya ağ izleme gibi ileri seviye konulara girmek isteyen geliştirici/operasyon ekipleridir.

Ön Koşullar ve Araçlar

Başlamadan önce gereksinimler: Linux çekirdeğinizin 4.9+ veya modern dağıtımlarda güncel bir kernel olması, clang ve llvm ile derleme araçları, bpftool, libbpf veya hızlı prototip için bpftrace/bcc paketleri. Ayrıca root yetkisi veya CAP_BPF/CAP_PERFMON benzeri yetkiler gerekecektir. Dağıtımınıza göre örnek kurulum: sudo apt install clang llvm libbpf-dev bpftool bpftrace.

Temel Kavramlar

eBPF programları kernel içinde güvenli bir şekilde çalışır; verifier adı verilen bir doğrulayıcı potansiyel tehlikeli işlemleri engeller. Programlar, kprobe/uprobes ile fonksiyon başlangıç/sonlarına, tracepoint'lere, ve XDP ile ağ katmanına bağlanabilir. Verileri kullanıcı alanına aktarmak için BPF haritaları (maps) ve perf buffer gibi mekanizmalar kullanılır. Map tipleri: hash, array, percpu, ring buffer vb.; her biri farklı senaryolara uygundur.

Hızlı Başlangıç: bpftrace ile Bir Satırlık İzleme

Hızlı prototip için bpftrace mükemmeldir. Örneğin dosya açma süresini görmek için: bpftrace -e 'kprobe:vfs_open { @[comm] = count(); }'. Bu komut, kernel'in vfs_open kancasına takılarak süreç başına açma sayısını sayar. Daha gelişmiş, gecikme histogramı için: bpftrace -e 'kprobe:do_sys_open { @t[tid] = nsecs; } kretprobe:do_sys_open /@t[tid]/ { @lat[hist(nsecs - @t[tid])] = count(); delete(@t[tid]); }'.

Üretim İçin: Libbpf ile eBPF Programı Yazmak

Üretim ortamında bpftrace rahat fakat sınırlıdır; libbpf ile C tabanlı eBPF programları daha kontrollü ve performanslıdır. Tipik akış: eBPF C kodu yazılır, clang -O2 -target bpf -c program.c -o program.o ile derlenir; kullanıcı alanı yükleyici ise libbpf kullanarak program.o'yu kernel'e yükler, map'lerle iletişim kurar. Map üzerinden histogram veya sayaçları okuyup JSON/Prometheus formatına çevirebilirsiniz. Önemli nokta: verifier hatalarını çözmek için kodu küçük parçalara bölün ve helper fonksiyonları kullanın.

Pratik Örnek: Bir Uygulamanın Fonksiyon Gecikmesini Ölçme (uprobes)

Kendi uygulamanızın belirli bir fonksiyonunun gecikmesini ölçmek için uprobe kullanın. Adımlar: (1) hedef ikili dosyanın yolunu ve sembolü belirleyin; (2) eBPF programında uprobe ile girişte timestamp kaydedin; (3) uretprobe ile çıkışta farkı hesaplayıp perf buffer ile kullanıcı alanına gönderin. Kullanıcı alanı Python veya C ile perf buffer'dan veriyi alıp histogram oluşturur. Bu yöntem, GC/pthread gibi uygulama içi etkileşimleri ölçmede çok yararlıdır.

Ağ Gözlemi: XDP ve TC Karşılaştırması

Ağ seviyesinde düşük gecikmeli filtreleme/ölçüm için XDP uygundur; paketler çekirdeğe bile ulaşmadan işlenir. Ancak XDP'nin kısıtlamaları vardır (örneğin skb erişimi yok). TC (cls_bpf) ise daha esnektir fakat biraz daha yüksek maliyetlidir. Üretimde, DDoS mitigasyonu veya L7 yük dengeleme öncesi hızlı ön filtreleme için XDP tercih edilirken, detaylı paket analizleri için TC kullanılabilir.

Gözlemleme Yöntemleri ve En İyi Uygulamalar

Performans açısından eBPF programları minimal iş yapmalı; ağır hesaplamalar kullanıcı alanına bırakılmalı. Map boyutlarını ve per-CPU kullanımını dikkatle planlayın. Verifier hatalarını azaltmak için bellek erişimlerini sınırlandırın ve helper fonksiyonları tercih edin. Güvenlik için yalnızca gerekli kapasiteleri verin ve production'da testlemeyi aşamalı yapın. Ayrıca bpftool ile yüklü programları ve map'leri takip etmek işleri kolaylaştırır: bpftool prog show, bpftool map dump.

Sırada Ne Var?

eBPF ekosistemi hızla büyüyor: libbpf, bpftool, bpftrace ve yüksek seviye kütüphanelerle (örn. gobpf, iovisor) entegrasyon artıyor. Sonraki adım olarak, sisteminiz için spesifik metrikleri belirleyip küçük eBPF programlarıyla prototip oluşturun, ardından performans testleri ve güvenlik incelemeleriyle üretime taşıyın. eBPF öğrenirken çekirdek logları, verifier çıktılarını ve bpftool'u etkin kullanmak başarıyı hızlandırır.

Rust ile WebAssembly (WASM) Performans Optimizasyonu: Adım Adım Rehber

Giriş — Neden Rust + WASM?

Rust ile WebAssembly (WASM) birbirini tamamlayan iki teknoloji: Rust'ın bellek güvenliği ve sıfır maliyet soyutlamaları, WASM'in tarayıcıda çalışabilen düşük seviyeli modülleriyle birleştiğinde hem performans hem de güvenlik sağlar. Bu rehberde, Rust ile yazılmış bir WASM modülünü oluştururken karşılaşacağınız temel yapılandırmaları, performans tuzaklarını ve optimizasyon tekniklerini adım adım ele alacağım.

Hazırlık ve araçlar

İhtiyacınız olanlar: Rust toolchain (rustup), wasm-pack veya cargo + wasm-bindgen, binaryen/wasm-opt (wabt ve binaryen paketleri) ve bir frontend paketleyici (ör. webpack veya Vite). Başlangıç için terminalde rustup target add wasm32-unknown-unknown, cargo install wasm-pack ve wasm-opt kurulumunu yapın. Bu araçlar derleme, bağlama ve ikili optimizasyon süreçlerinde kritik öneme sahip.

Basit bir örnek: fonksiyonları dışa aktarma

Rust'ta basit bir fonksiyonu WASM'e dışa aktarmak için wasm-bindgen kullanın. Örnek:

use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub fn sum(a: i32, b: i32) -> i32 {
    a + b
}

Bu kodu wasm-pack build --target web ile derleyip, tarayıcı tarafında import ederek kullanabilirsiniz. Ancak performans için dikkat edilmesi gerekenler yalnızca derlemek değildir; nasıl çağırdığınız ve veri taşıdığınız da önemlidir.

Performans odaklı ipuçları

1) JS↔WASM sınırını minimize edin: Her JS-WASM çağrısı CPU yükü ve marjinal overhead getirir. Küçük, sık yapılan çağrılar yerine veri blokları gönderip tek seferde işlemek genelde daha verimlidir.

2) Bellek yönetimi: WASM lineer belleği kullanır. Büyük veri için Vec kullanıp pointer ve uzunluk dönerek SharedArrayBuffer/ArrayBuffer üzerinden doğrudan erişim sağlayın. Böylece kopyalamaları azaltırsınız.

3) Veri tiplerini basit tutun: Karmaşık nesne serileştirmeleri yerine ikili formatlar veya sabit tipli diziler kullanın. JSON yerine biner format performansı belirgin şekilde artırır.

4) SIMD ve multi-threading: Tarayıcılar artık SIMD ve Threads için deneysel destek sunuyor. simd128 ve atomics özelliklerini kullanmak büyük hesaplamalarda hız verir, ancak Cross-Origin-Opener-Policy (COOP) ve Cross-Origin-Embedder-Policy (COEP) başlıkları gerektirir.

Derleme ve optimizasyon bayrakları

Release derlemelerinde cargo build --release veya wasm-pack build --release kullanın. Ek olarak RUSTFLAGS ile LTO (link time optimization) ve hedef özelliklerini açabilirsiniz:

export RUSTFLAGS="-C opt-level=z -C linker-plugin-lto -C codegen-units=1"
wasm-pack build --release

Opt-level=z dosya boyutuna odaklanır; -C opt-level=3 ise hız odaklıdır. Ardından wasm-opt -Oz ile ikiliyi küçültün ve performans profili doğrultusunda -O3 seçeneğini değerlendirin.

Boyut azaltma ve dağıtım

WASM modüllerini gzip veya brotli ile sıkıştırıp sunmak yükleme süresini büyük ölçüde azaltır; brotli genelde daha iyi sıkıştırma sağlar. Ayrıca kullanılmayan kodu elimine eden tree-shaking ve cargo features ile gereksiz bağımlılıkları kaldırın. wasm-snip veya cargo-udeps gibi araçlar gereksiz kodu tespit etmekte yardımcı olur.

Profiling ve ölçme

Performans iyileştirmelerinin etkisini ölçmeden uygulamak yanıltıcı olabilir. Tarayıcıların Performans/Profiler araçları, WASM hotspot'larını görmenizi sağlar. Ayrıca wasm-objdump ve wasm-validate ile ikiliyi analiz edin. Gerçek dünya yüklerini taklit eden benchmark'lar oluşturun; mikro benchmark'lar yanıltıcı olabilir.

Sık yapılan hatalar ve çözüm önerileri

- Çok küçük fonksiyonları sık çağırmak: Bunları birleştirin veya toplu işleyin. - Aşırı kopyalama: Bellek penceresi kullanarak kopyalamayı azaltın. - Yanlış derleme bayrakları: test ve release davranışını karıştırmayın; release ile ölçün. - COOP/COEP gereksinimlerini göz ardı etmek: Threaded WASM için server başlıklarını doğru ayarlayın.

Sonuç

Rust + WASM ile yüksek performanslı web modülleri oluşturmak mümkün ve sürdürülebilir. Temel prensipler: JS-WASM sınırını akıllıca yönetmek, bellek erişimini optimize etmek, doğru derleme ve ikili optimizasyonları kullanmak ve sonuçları dikkatle ölçmektir. Bu rehber, bir başlangıç yolu sunar; gerçek uygulamalar için spesifik profil verilerine dayanarak ince ayar yapmanız en iyi sonucu verecektir.

Kubernetes'te GitOps ile Canary Dağıtımı: Argo CD ve Istio ile Aşamalar ve İyi Uygulamalar

Giriş

Kubernetes üzerinde hizmet güncellemeleri yaparken "her şey ya hep ya hiç" yaklaşımı risklidir. Canary dağıtımı, yeni sürümü küçük bir kullanıcı kesimine açıp davranışı izleyerek ilerlemeye olanak verir. Bu rehberde GitOps yaklaşımıyla Argo CD kullanarak manifests tabanlı yönetim, Istio ile trafikte kademeli yönlendirme ve temel otomasyon-adımlarını ele alacağız. Amaç, tekrarlanabilir, gözlemlenebilir ve güvenli bir canary süreci kurmaktır.

Önkoşullar

Bu makaledeki adımları uygulayabilmek için aşağıdaki bileşenlere sahip olmalısınız: bir Kubernetes kümesi (1.20+ önerilir), Argo CD kurulumu, Istio servis mesh kurulumu (ingress/gateway dahil), Git deposu (manifests için) ve izleme için Prometheus/Grafana. Ayrıca kubectl, argocd CLI ve gerekli RBAC izinleri gereklidir.

1) Manifests ve GitOps Hazırlığı

Uygulamanızı Kustomize veya Helm ile paketleyin. İki ayrı sürüm manifesti tutmak faydalıdır: v1 ve v2. Git deposunda şunları organize edin: /overlays/stable (v1), /overlays/canary (v2) ve ortak base dosyalar. Argo CD bu repo'yu izleyerek kümedeki kaynakları senkronize eder. Argo CD Application manifesti ile otomatik senkronizasyon veya manuel onay tercih edilebilir.

2) Istio ile Trafik Yönlendirme

Istio VirtualService ve DestinationRule kaynakları ile servis içinde ağırlık bazlı dağıtım yapabilirsiniz. Örnek kısa yapı: bir VirtualService içinde canary için %10, %50 gibi ağırlıklar belirlenir. Örnek kontrol komutu: kubectl -n your-namespace get virtualservice. Canary sürecinde ağırlıkları Git üzerinden değiştirerek Argo CD ile otomatik olarak uygulayabilirsiniz; böylece tüm değişiklikler version kontrolünde kalır.

3) Otomasyon ve Güvenlik: Argo CD + Webhook

Manifests'te ağırlık değişiklikleri bir PR ile yapılır. CI pipeline'ınız bu PR'ı doğrular (lint, güvenlik taramaları). Merge sonrası Argo CD otomatik senkronize eder. Opsiyonel: bir webhook ile Argo CD sync tamamlandığında Prometheus sorguları tetikleyerek sağlık kontrolü başlatabilirsiniz. Eğer belirlenen SLO/SLA dışı metrikler tespit edilirse, otomatik rollback için Argo CD uygulamasına geri alma tetiklenebilir.

4) Gözlemlenebilirlik ve Karar Kriterleri

Canary'nin başarılı sayılması için ölçülebilir kriterler belirleyin: hata oranı, p99 gecikme, throughput ve kullanıcı deneyimi metrikleri. Prometheus'ta sorgular tanımlayın, Grafana panelleri oluşturun ve Alertmanager ile eşik aşımlarında uyarı üretin. Otomasyon için bu uyarılar webhook ile rollback sürecini başlatabilir.

5) İleri Seviye İpuçları

- İzolasyon: Canary pod'larını ayrı bir node pool veya kaynak sınırlamaları ile izole edin. - A/B test yerine istatistiksel güven: Trafik artışlarını küçük adımlarla yapın (örn. %5, %20, %50). - Trafik yönlendirme dışında shadowing ile gerçek üretim trafiğini yeni sürüme de gönderip yalnızca gözlemleyebilirsiniz. - Rollback kriterlerini mutlaka otomatik hale getirin; manuel müdahale süresini minimize edin. - Argo Rollouts kullanmak istiyorsanız, Rollout CRD'si ile Istio'yu entegre ederek daha ileri seviye deneyler ve analizler yapabilirsiniz.

Örnek Komut Akışı

Bir canary adımı için tipik komutlar: git checkout -b feature/canary-weight, manifests'te VirtualService ağırlığını değiştir, git commit && git push. PR merge sonrası Argo CD otomatik olarak uygulamayı senkronize eder: argocd app get my-app ve kubectl -n my-namespace get pods ile doğrulama yapabilirsiniz.

Sonuç

GitOps tabanlı canary dağıtımı, değişikliklerin izlenebilir, geri alınabilir ve tekrarlanabilir olmasını sağlar. Argo CD ile manifest kontrolünü elinizde tutarken Istio trafik yönlendirmesi sayesinde kademeli roll-out'lar yapabilirsiniz. Ancak başarının anahtarı güçlü gözlemlenebilirlik, net kabul kriterleri ve otomatik rollback mekanizmalarıdır. Bu temel adımları uygulayarak üretimde riskleri azaltabilir ve sürüm yayımlarını daha güvenilir hale getirebilirsiniz.

2009 Chevrolet Lacetti Hikayesi - Neler Yaptırdım?

    İlk arabam 2009 model bir Lacetti. Model yılı eski olmasına rağmen yine de temiz ve fiyatını da piyasaya göre gayet uyguna bulmuştuk. Yaklaşık 2 ay önce 320.000 TL'ye aracı aldık. Aracın belli başlı eksiklikleri vardı ve onları göze almıştık; malum ikinci el ve 184.000 km'de bir aracı satın alıyorsunuz, bazı bakımlarını yaptırmanız ve eksikleri de kendiniz tamamlamanız gerekiyor.

Ekspertiz Anından

Araçtaki Bazı Sorunlar

    Arabayı alırken göze çarpan eksiklikler şunlardı: klima tuşu bazen çalışıyor bazen çalışmıyordu, sağ ön otomatik cam tutukluk yapıyor, merkezi kilitte sağ arka kapı kilitlenmiyor veya açılmıyordu. Klima soğutmuyordu, sağ marşpiyelde küçük bir çürük vardı, ön farlar da oldukça sararmış durumdaydı. Bildiklerimiz ve gördüklerimiz bunlardı.

Araçta Acil Olarak Yaptırdığım Bazı Şeyler

    İlk gün Atatürk Oto Sanayii'ne gidip hızlıca yaptırabileceğim eksikleri halletmeye çalıştım. Sürüşte balanssızlık ve direksiyonda titreme fark ettim. Usta jantlarda eğrilik olduğunu söyledi; önce jantları düzelttik ardından balans yapıldı. İlk sürprizimiz bu oldu :)

İlk masraf: 2700 TL — Jant düzeltme ve balans.

Jantlar düzeltilirken ve balans

    Sırada arka kapı kilidinin onarımı vardı. Döşeme söküldü; kilit onarılamayınca sıfır kilit uydurulup monte edildi. Merkezi kilitte arka kapı sorunsuz çalışıyor. Aynı ustaya klima tuşunu da tamir ettirdim.

İkinci masraf: 1700 TL — Arka kapı kilit değişimi ve klima tuşu onarımı.

Klima açma/kapama tuşunun onarımı

Sağ arka döşeme sökülürken

Sağ arka kapı kilit mekanizması

Sıradaki masraf klima gazı dolumu oldu; üç hafta sonra gaz yeniden bitti. Kaçak kontrolüne götüreceğim.

Üçüncü masraf: 1500 TL — Klima gazı dolumu.

Sağ ön otomatik cam tutukluk yapıyordu. Döşeme söküldükten sonra motor kömürünün bittiği görüldü ve değişim yapıldı; şu an sorunsuz.

Dördüncü masraf: 800 TL — Sağ ön cam motoru kömür değişimi.

    Direksiyonu çevirirken alt takımlardan hafif gıcırdama geliyordu. Alt takım bakımlarını elden geçirince ses sorunu da çözüldü.

Beşinci masraf: 5800 TL — Rotil ve salıncak değişimi.
Altıncı masraf: 1200 TL — Rot başlıkları yenilendi.

Sağ marşpiyeldeki pas için zımpara ve boya yapıldı; arka-ön tamponlarda lokal rötuşlar da tamamlandı.

Yedinci masraf: 1500 TL — Sağ marşpiyel ve tampon rütuşları.

Aracın bakımlarını yaptırırken amortisör takozlarından biri tamamen kırık olduğunu farketmiştik; tüm takozlar ve rot ayarı yenilendi.

Sekizinci masraf: 7000 TL — Amortisör takozları + rot ayarı. (Bu tarz işlerin faturası mevcut.)

Dokuzuncu masraf: 700 TL — Ön farların sararması için temizlik işlemi.

Tüm bunların dışında sigorta 20.700 TL, 5.500 TL eksper ve 2.100 TL noter işlemi tuttu.

Onuncu masraf: Klima kaçağının onarımı 4000 TL

    Klimanın kaçağını sonunda tespit edebildik ve onarımını gerçekleştirdik. Böylece aracımdaki bilinen tüm eksiklikleri tamamlamış oldum. Klimanın yüksek basınç borusunda gözle görülür kılcal kaçakları tespit ettik ve usta bu boruyu değiştirdikten sonra tekrar basınç kontrolü vs yaptık ve sonrasında gaz dolumunu da gerçekleştirerek işlemi tamamladık. Öncesi ve sonrasına ait görüntüler aşağıdaki gibi:

Gözle görülür kaçaklar köpüren kısımlarda

Borunun yeni hali.

Onbirinci Masraf: Rutin Sıvı Bakım, Hava Filtresi, Antifiriz, Yağ Filtresi, Ön Balata ve Triger Kayışları 19.000 TL

    Aracı aldığımdan beri ilk sıvı bakım zamanı geldi Eylül 2025 ve rutin bakımları ile birlikte triger kayışı, V kayışı, Devir pompası, filtreler ve yağ bakımları yapıldı. Tamamı için 19.000 TL gibi bir ücret ödedim ve bu bakımları Sanko otosanayii'de yaptırdım. Değişen parçalara ait görüntüler aşağıdaki gibi.

Onikinci Masraf: Silecek yenileme, sağ ön far kısa far ampül değişimi, arka balata ve el freni ayarı. 2.500TL 

    Silecekler çalıştığında camdaki suyu tam olarak temizlemiyordu ve ıslak bırakıyordu, aslında aldığımdan beni bu şekildeydi ve bunu değiştirdim. Çift silecek değişimi sadece 600 lira tuttu. Bununla birlikte arka balatalar değişecekti ve önleri zaten sıvı bakımlarıyla değiştirmiştik, sağ ön far ampülü ve birde el freni çok yukarıda tutuyordu. Tüm bu ufak tefek bakım onarımları da bu şekilde halletmiş olduk.

Onüçüncü Masraf: Yeni lastikler takıldı KUMO marka yazlık ve ön takıma ait iki hidrolik fren hortumu yenisiyle değiştirildi. Lastikler 12.000 TL Fren hidrolik hortumları ise 4.000 TL.

Ayrıca aracın muayenesini de yaptırdık, ay sonunda ise sigortanın yenileme zamanı gelecek.