Ollama ile Yerel LLM Kurulumu: Llama 3.1 ve Mistral’i Bilgisayarınızda Çalıştırma Rehberi

Giriş

Yapay zekâ araçlarını bulutta kullanmak pratik olsa da, gizlilik, maliyet ve hız gibi konularda sınırlamalar yaratabiliyor. Ollama, güncel büyük dil modellerini (LLM) bilgisayarınızda, internet bağlantısı olmadan ve düşük kurulum maliyetiyle çalıştırmanızı sağlayan hafif bir platform. Bu rehberde, Llama 3.1 ve Mistral gibi modelleri Ollama ile nasıl kuracağınızı, yerel API’yi nasıl kullanacağınızı ve performansı artırmak için dikkat etmeniz gereken noktaları adım adım anlatıyorum.

Neden Yerel LLM?

Yerel LLM çalıştırmanın en büyük avantajı verilerinizin bilgisayarı terk etmemesi. Özellikle müşteri verileri, kaynak kodu veya şirket içi belgelerle çalışıyorsanız gizlilik kritik hale gelir. Ek olarak, isteğe bağlı kullanımda bulut maliyetleri hızla artabilir. Yerel kurulumda ise bir kez model dosyasını indirip, dilediğiniz kadar kullanabilirsiniz. Son olarak, kısa sorgularda gecikme (latency) dramatik şekilde düşer; ağ gecikmesi olmadığı için yanıtlar daha akıcı gelir.

Sistem Gereksinimleri

Minimum gereksinimler modele göre değişse de pratik bir başlangıç için 16 GB RAM önerilir. 7B-8B parametreli modellerde 8-12 GB RAM ile de çalışabilirsiniz. GPU’nuz varsa (NVIDIA, Apple Silicon veya yeni nesil AMD) performans çarpıcı biçimde artar; VRAM miktarı ne kadar yüksekse, model o kadar hızlı ve akıcı yanıt verir. Diskte en az 10-20 GB boş alan ayırın; model dosyaları büyük olabilir. Windows, macOS ve Linux platformları desteklenir.

Kurulum

Ollama’yı ollama.com üzerinden işletim sisteminize uygun yükleyiciyi indirerek kurabilirsiniz. Kurulum tamamlandıktan sonra Ollama arka planda bir hizmet olarak çalışır. Terminal veya Komut İstemi’ni açıp basit bir komutla test edebilirsiniz. Eğer Windows kullanıyorsanız en güncel sürümü tercih edin; GPU desteği ve kararlılık son dönemde hızla iyileştirildi.

Model İndirme ve Çalıştırma

Ollama’nın en pratik yanı model yönetimini tek komutla yapabilmesi. Örneğin Llama 3.1’i denemek için terminalde şu komutu çalıştırın: ollama run llama3.1. Bu komut ilk seferde modeli indirir ve etkileşimli bir oturum başlatır. Benzer şekilde, hızlı ve hafif bir alternatif için: ollama run mistral. Oturumdayken sorularınızı yazıp anında yanıt alabilirsiniz. Çıkmak için Ctrl+C yeterli.

Belirli bir kullanım senaryosu için farklı boyut seçenekleri mevcut olabilir (örneğin 8B, 13B, 70B). Boyut büyüdükçe doğruluk ve bağlam yönetimi gelişir; ancak RAM/VRAM ihtiyacı artar. İlk denemelerde 7B-8B sınıfı modellerle başlayıp, donanımınız el verdiği ölçüde daha büyük modellere geçmeniz iyi bir stratejidir.

Yerel API ile Entegrasyon

Ollama bir REST API sunar. Kendi uygulamanızdan yerel modele istek atmak için http://localhost:11434 adresini kullanabilirsiniz. Temel uç noktalardan biri /api/generate’tir. Gövdeye prompt, model adı ve opsiyonel parametreler (maksimum token, sıcaklık gibi) göndererek yanıt alırsınız. Örnek akışta, yanıtlar parça parça (stream) dönebilir; bu sayede sohbet arayüzlerinde yazı yazılırken canlı akış efektini rahatça sağlayabilirsiniz.

Geliştiriciler için pratik bir yöntem de araya bir istemci kütüphanesi koymak. JavaScript, Python veya Go gibi dillerdeki minimal HTTP istekleriyle hızlıca prototip yapabilirsiniz. Mevcut sohbet uygulamanıza veya dahili araçlarınıza bir “yerel asistan” eklemek için bu yöntem idealdir.

Modelfile ile Özelleştirme

Ollama’nın Modelfile yapısı, bir modelin nasıl başlatılacağını, sistem yönergelerini ve ek kaynakları tanımlamanıza olanak tanır. Örneğin bir kurumsal asistanda “şirket politikasına uygun, kısa ve güvenli yanıtlar ver” gibi bir sistem talimatını kalıcı hale getirebilirsiniz. Bu dosyayı oluşturarak ollama create komutuyla adını verdiğiniz özel modeli yayınlayabilir, ekip içinde aynı profili paylaşabilirsiniz.

Performans İpuçları

- GPU kullanın: Mümkünse modele ayrılan katmanları GPU’ya offload edin; bu, yanıt süresini dratik biçimde azaltır. Apple Silicon’da Metal hızlandırma, NVIDIA’da CUDA desteği ciddi fark yaratır.

- Hafif kuantizasyon: 4-bit veya 5-bit kuantize modeller RAM/VRAM baskısını düşürürken kabul edilebilir doğruluk sunar. İlk kurulumda Q4 veya Q5 sürümlerini deneyebilirsiniz.

- Maksimum token ve sıcaklık: Uzun yanıtlar kaynak tüketimini artırır. Maksimum token değerini ihtiyaca göre sınırlayıp, sıcaklığı 0.2-0.7 aralığında ayarlamak denge sağlar.

Güvenlik, Gizlilik ve Bakım

Yerel çalıştırmada veriler cihazınızda kaldığından gizlilik avantajı elde edersiniz. Yine de hassas içerikleri disk şifreleme ve kullanıcı erişim kısıtlarıyla korumayı unutmayın. Modelleri güncel tutmak önemlidir; yeni sürümler hem kaliteyi artırır hem de hataları giderir. Ayrıca, şirket içi kullanımda model davranışını izlemek ve denetim kayıtları tutmak uyumluluk açısından faydalıdır.

Karşılaşılan Yaygın Sorunlar

- Yetersiz bellek: Model yüklenemiyorsa daha küçük bir varyant deneyin veya kuantize sürüme geçin. Arka planda çalışan ağır uygulamaları kapatın.

- Yavaş yanıt: GPU hızlandırmayı açın, akış (stream) modunu kullanın, maksimum token değerini düşürün.

- Uygulama entegrasyonu: API uç noktalarını doğrulayın, istek gövdesindeki parametreleri (prompt, model) doğru gönderdiğinizden emin olun.

Sonuç

Ollama ile Llama 3.1 ve Mistral gibi modelleri yerel olarak çalıştırmak, hem geliştiriciler hem de içerik üreticileri için esnek, hızlı ve güvenli bir çözüm sunuyor. Basit kurulum adımları, tek komutla model yönetimi ve REST API sayesinde, deneme-yanılma döngüleri kısalıyor ve üretkenlik artıyor. Donanımınıza uygun model boyutunu seçip, Modelfile ile özelleştirme ve kuantizasyon gibi teknikleri kullanarak kısa sürede verimli bir yerel yapay zekâ ortamı oluşturabilirsiniz.

Kubernetes Gateway API Rehberi: Ingress’ten Geçiş, Kurulum ve En İyi Uygulamalar

Kubernetes dünyasında trafik yönlendirme denince yıllardır akla ilk gelen nesne Ingress oldu. Ancak karmaşık topolojiler, çoklu tenant ihtiyaçları ve servis mesh ile entegrasyonlar arttıkça, Ingress’in sınırları da görünür hâle geldi. Tam bu noktada CNCF destekli Gateway API, daha esnek modelleme, tutarlı CRD’ler ve güçlü uzatılabilirlik ile yeni standart olarak öne çıkıyor. Bu yazıda Gateway API nedir, nasıl kurulur ve Ingress’ten geçiş nasıl yapılır ayrıntılı ama sade bir dille anlatıyorum.

Gateway API nedir? Ingress’ten farkları

Gateway API, Kubernetes üzerinde L4/L7 trafiğini tanımlamak için Ingress’e göre daha zengin bir şema sunar. Temel bileşenleri GatewayClass, Gateway ve Route (ör. HTTPRoute, GRPCRoute) nesneleridir. Bu ayrım sayesinde, platform ekibi altyapıyı (GatewayClass/Gateway) yönetirken, uygulama ekipleri yalnızca route’ları tanımlayabilir. Bu da yetki ayrımı, çoklu kiracı desteği ve politika yönetimi açısından büyük avantaj sağlar.

Ingress tek bir kaynak türüyle pek çok ihtiyacı aynı dosyada toplamaya çalışırken, Gateway API yönlendirme mantığını daha modüler ve tutarlı CRD’lere böler. Örneğin birden fazla host, path tabanlı kurallar, TLS sonlandırma, rate limit veya header manipülasyonu gibi gelişmiş özellikler daha net ifade edilebilir. Üstelik aynı manifest’ler farklı sağlayıcılarla daha taşınabilir çalışır.

Hangi uygulamalar destekliyor?

Gateway API bir spesifikasyon; uygulaması ise farklı projeler tarafından sağlanıyor. En popülerleri: Envoy Gateway, NGINX Gateway Fabric ve Istio (mesh senaryolarında doğrudan destekler). Üretim ortamında biriyle başlayıp, mimari ihtiyaçlar değiştiğinde diğerine geçebilmek büyük esneklik sunar. Bu da kilitlenme riskini azaltır.

Kurulum: Hızlı başlangıç

Öncelikle Kubernetes sürümünüzün güncel olduğundan emin olun (en az 1.26+ önerilir). Ardından seçtiğiniz uygulamanın CRD’lerini ve kontrol düzlemini kurun. Örnek olarak Envoy Gateway ile başlamak oldukça rahattır. Resmî manifest’ler ile CRD kurulumu yapılır; akabinde bir GatewayClass ve bir Gateway tanımlanır. Basit bir sınıf tanımı şu şekilde olabilir: apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: eg-class spec: controllerName: gateway.envoyproxy.io/gatewayclass-controller Sonrasında bu sınıfa bağlı bir Gateway oluşturup trafiğe bir giriş noktası tanımlarsınız: apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: eg-gw spec: gatewayClassName: eg-class listeners: - name: http port: 80 protocol: HTTP

Artık uygulama ekipleri kendi namespace’lerinde HTTPRoute tanımlayabilir. Örnek bir route: apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: web-route spec: parentRefs: - name: eg-gw rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: web-svc port: 8080 Bu tanım, / ile başlayan tüm istekleri web-svc:8080 servisine iletir.

Ingress’ten Gateway API’ye geçiş

Mevcutta Ingress kullanan ekipler için geçiş adımları özetle şu şekilde ilerler: Önce mevcut Ingress kurallarınızı listeleyin ve host/path/TLS mantığını çıkarın. Ardından bir GatewayClass ve Gateway oluşturup, her Ingress kuralını karşılayacak HTTPRoute nesnelerine dönüştürün. Örneğin Ingress’te host: app.example.com ve /api path’i vardıysa, HTTPRoute içinde matches.path ile benzer kuralı tanımlar ve parentRefs ile hedef Gateway’e bağlarsınız.

TLS için Ingress anotasyonları yerine Gateway/Route içinde doğrudan TLS blokları kullanabilirsiniz. Örneğin: listeners: - name: https port: 443 protocol: HTTPS tls: mode: Terminate certificateRefs: - name: app-cert namespace: certs Bu, sonlandırmayı Gateway üzerinde yapar. Eğer uçtan uca TLS istiyorsanız, backend’te de TLS terminasyonu uygulayıp uygun SNI/ALPN ayarlarını yapan bir yapılandırma seçmelisiniz.

Gelişmiş senaryolar: Canary ve mavi-yeşil

Gateway API’de trafik bölme senaryoları sadeleşir. Bir HTTPRoute altında birden çok backendRef tanımlayıp weight ile isteklerin yüzdesini kontrol edebilirsiniz. Örneğin yeni sürüme yüzde 10 trafik göndererek canary testleri yapmak mümkündür. Ayrıca header tabanlı yönlendirme ile yalnızca belirli kullanıcı gruplarını yeni sürüme taşıyarak riskinizi daha da düşürebilirsiniz.

Politikalar, güvenlik ve çoklu tenant

Policy ekosistemi Gateway API’nin güçlü taraflarından. Kuralları namespace sınırlarına göre kısıtlamak, yalnızca belirli ekiplerin belirli listener’lara bağlanmasını sağlamak veya mTLS zorunluluğu getirmek mümkün. Çoğu uygulama, oran sınırlama (rate limit), WAF veya authZ entegrasyonları için ek CRD’ler sunar. Böylece güvenlik ekibi politikaları merkezi tanımlar, uygulama ekipleri ise yalnızca yönlendirme kurallarını yazar.

Sorun giderme: Neleri kontrol etmeli?

Önce CRD ve controller pod’larının sağlığını kontrol edin. Gateway ve HTTPRoute nesnelerinin status alanlarını mutlaka inceleyin; hangi parent’a bağlandığı ve programlama durumunu açıkça gösterir. DNS ve LoadBalancer IP/hostname atamalarını doğrulayın. Trafik gelmiyorsa listener portu, güvenlik grupları ve network policy ayarlarına bakın. Ingress’ten geçişte unutulan en yaygın nokta, TLS terminasyonunun yeri ve sertifika referanslarının namespace’ler arası erişimidir; certificateRefs ve RBAC izinlerini iki kez kontrol edin.

Ne zaman Gateway API’ye geçmeliyim?

Eğer birden çok takım aynı kümede çalışıyor, birden fazla ingress controller’ı yönetmekten yoruluyor veya servis mesh ile uyumlu bir giriş katmanı istiyorsanız, Gateway API güçlü bir aday. Yeni projelerde doğrudan Gateway API ile başlamak, taşınabilirlik ve geleceğe dönük uyumluluk açısından avantaj sağlar. Mevcut Ingress’leriniz basit ve kararlıysa acele etmeye gerek yok; kademeli bir geçiş planı hazırlamak daha sağlıklı olur.

Son söz: Gateway API yalnızca yeni bir CRD seti değil, Kubernetes’te trafik yönetimine bakış açımızı güncelleyen bir standart. Doğru uygulama ve iyi tanımlanmış sorumluluklar ile hem platform ekiplerinin yönetim yükünü azaltıyor hem de uygulama ekiplerine daha net, öngörülebilir bir deneyim sunuyor.

WASI ile WebAssembly CLI Dağıtımı: Wasmtime Kullanarak Docker’sız, Taşınabilir Araçlar

Giriş

CLI araçlarını farklı işletim sistemlerine dağıtmak çoğu zaman zahmetlidir. Her platform için ayrı derlemeler, paylaşımlı kütüphane bağımlılıkları ve güvenlik kısıtları bir araya gelince, iş büyür. WebAssembly (WASM) ve WASI (WebAssembly System Interface), bu sorunu modern ve güvenli bir yaklaşımla çözüyor. WASI sayesinde uygulamanızı tek bir .wasm dosyası olarak paketleyip, Wasmtime gibi bir çalışma zamanı üzerinde Linux, macOS ve Windows’ta aynı şekilde çalıştırabilirsiniz. Bu öğreticide, Rust ile küçük bir CLI aracını WASI için derleyip Wasmtime ile çalıştırmayı ve pratik ipuçlarını paylaşacağım.

WASM ve WASI Nedir?

WASM, sandbox edilmiş bir bytecode formatıdır; bir kez derlediğiniz kodu farklı ortamlarda güvenle koşturmanıza olanak tanır. WASI ise dosya sistemi, çevre değişkenleri, saat ve benzeri sistem kaynaklarına erişim için standart bir arayüz sunar. En kritik avantajı, yetenek tabanlı (capability-based) güvenlik modelidir: Uygulama dosya sistemine, ağ veya diğer kaynaklara varsayılan olarak erişemez; hangi izinleri verdiyseniz yalnızca onlarla çalışır.

Gereksinimler

- Rust ve cargo (rustup ile kurulabilir)
- Wasmtime çalışma zamanı (brew install wasmtime ya da choco install wasmtime)
- Rust için WASI hedefi: rustup target add wasm32-wasi

Adım Adım: Rust CLI’yi WASI için Derlemek

1) Yeni bir proje oluşturun: cargo new hello-wasi komutundan sonra dizine girin.
2) src/main.rs içine basit bir örnek koyun. Argümanları yazdıran ve bir dosyayı okuyan minimal bir gövde şöyle olabilir: fn main() { let args: Vec<String> = std::env::args().collect(); eprintln!("Argümanlar: {:?}", args); let path = std::env::var("INPUT").unwrap_or("input.txt".into()); let data = std::fs::read_to_string(path).unwrap_or_default(); println!("{}", data); }
3) WASI hedefi için derleyin: cargo build --release --target wasm32-wasi. Üretilen dosya: target/wasm32-wasi/release/hello-wasi.wasm

Wasmtime ile Çalıştırma

WASI, dosya sistemi erişimine varsayılan izin vermez. Çalıştırırken hangi dizinlere erişileceğini belirtmelisiniz. Örneğin, geçerli dizine erişim verip bir argüman da geçmek için: wasmtime --dir=. target/wasm32-wasi/release/hello-wasi.wasm merhaba. Eğer program dosya okuyacaksa, çevre değişkenlerini de iletebilirsiniz: wasmtime --dir=. --env INPUT=input.txt target/wasm32-wasi/release/hello-wasi.wasm. Bu şekilde uygulama yalnızca izin verdiğiniz yollara ulaşır; kök sisteme doğrudan erişemez.

Paketleme ve Dağıtım Stratejileri

- Tek dosya yaklaşımı: Uygulamanızı yalnızca .wasm olarak paylaşın ve kullanıcılara Wasmtime kurmalarını söyleyin. Çoğu Linux/macOS/Windows ortamında kurulum dakikalar içinde yapılır.
- Önceden derlenmiş modüller: wasmtime compile -o app.cwasm app.wasm ile JIT yerine AOT derlenmiş bir çıktı üretip daha hızlı başlangıç süreleri elde edebilirsiniz.
- Küçük runner ekleme: Bazı takımlarda, Wasmtime binary’si ile .wasm dosyasını aynı pakete koyup basit bir wrapper script ile kullanım sağlamak yaygındır. Bu, “docker’sız, tek arşiv” dağıtımı kolaylaştırır.

Performans ve Boyut

WASM performansı, CPU-ağırlıklı olmayan CLI’larda çoğu kullanım için yeterince hızlıdır. Başlangıç süresi kısa, bellek tüketimi kontrollüdür. Rust tarafında LTO ve strip ayarlarıyla boyutu küçültebilirsiniz: [profile.release] lto = "thin", opt-level = "z" gibi ayarlar ve cargo build --release sonrası wasm-opt -Oz (Binaryen) ek sıkıştırma sağlayabilir. Tipik bir basit araç 300 KB – birkaç MB aralığında olur.

Sınırlamalar ve Çözüm Yolları

- Ağ erişimi: WASI’nin ağ API’leri hâlâ olgunlaşma aşamasında. Wasmtime deneysel soket uzantılarıyla çalışabilir, ancak üretimde dikkatle değerlendirin. Alternatif olarak, ağ erişimini bir proxy süreci veya HTTP üzerinden borulama (stdin/stdout) ile soyutlayabilirsiniz.
- Çoklu thread’ler: WASI-threads yaygınlaşsa da her çalışma zamanı aynı olgunlukta değil. CLI tarafında işbirlikçi asenkron mimari (ör. tokio + wasm32-wasi) çoğu senaryoda yeterli olur.
- Dinamik bağlama: Paylaşımlı kütüphaneler yerine statik ve portable bağımlılıklar tercih edin. Bu yaklaşım zaten WASM’in tasarım felsefesine daha uygundur.

Alternatif Diller ve Araçlar

Rust en iyi deneyimlerden birini sunar, ancak tek seçenek değil. TinyGo ile Go kodunu GOOS=js GOARCH=wasm yerine doğrudan wasm32-wasi hedefiyle derlemek mümkün. Zig ve C/C++ projeleri de WASI için güçlü adaylardır. JavaScript tarafında Node’un WASI modülü ile sınırlı ama işe yarar kullanım alanları mevcuttur.

Güvenlik ve Uyumluluk

WASI’nin yetenek tabanlı modeli, yanlışlıkla sistem dosyalarını silme veya gizli ortam değişkenlerine erişme riskini kökten azaltır. Komut satırında her hak açıkça verilir: --dir, --env gibi bayrakları kullanmadığınız sürece uygulamanız “kör ve sağır” bir kutuda çalışır. Bu, regülasyonlu ortamlarda denetlenebilirlik ve asgari ayrıcalık ilkesi açısından büyük bir artıdır.

Gerçek Dünya Senaryoları

- İç araçlar: Veri dönüştürücüler, şema doğrulayıcılar, log filtreleyiciler tek .wasm olarak dağıtılabilir.
- CI/CD adımları: Çoklu işletim sistemi matrislerinde aynı .wasm’ı koşarak “build once, run anywhere” elde edersiniz.
- Eklenti mimarileri: Ana uygulama, .wasm eklentilerini güvenli sandbox’ta çalıştırarak güvenlik yüzeyini daraltabilir.

Sonuç

WASI destekli WebAssembly, CLI araçlarının dağıtımını basitleştirirken güvenlik ve taşınabilirliği artırır. Wasmtime ile birkaç komutla hem geliştirme hem de çalıştırma deneyimi elde edersiniz. Ağ ve thread’ler gibi bazı alanlar hâlâ olgunlaşsa da, bugün itibarıyla dosya işleme, metin dönüştürme, doğrulama ve otomasyon görevleri için üretime hazır bir seçenek. Eğer farklı platformlarda aynı davranışı sunan, Docker kurulumuna bağımlı olmayan ve denetlenebilir izinlerle çalışan araçlar istiyorsanız, bir sonraki CLI’nızı WASI hedefiyle derlemeyi ciddi biçimde düşünün.

Passkey (FIDO2/WebAuthn) ile Şifresiz Giriş: Node.js Üzerinde Adım Adım Kurulum ve En İyi Uygulamalar

Passkey ve WebAuthn Nedir?

Passkey, FIDO2 ve WebAuthn standartları üzerine kurulu, şifre gerektirmeyen modern bir kimlik doğrulama yöntemidir. Kullanıcılar parolayı ezberlemek yerine, cihazlarının biyometrik sensörlerini (parmak izi, yüz tanıma) veya bir ekran kilidini kullanarak giriş yapar. Kriptografik anahtarlar cihazda güvenle saklanır ve çoğu ekosistemde (Apple, Google, Microsoft) bulut üzerinden yedeklenip eşitlenebilir. Bu sayede hem güvenlik artar hem de giriş deneyimi tek dokunuşa iner.

Neden Passkey Kullanmalısınız?

Şifreler kimlik avı, sızan veri setleri ve tekrar kullanım sorunları nedeniyle saldırı yüzeyini genişletir. Passkey ise tarayıcı ve cihaz düzeyinde kimlik bağlamı (origin + rp.id) zorunluluğu ile phishing’e kapıyı kapatır. Ayrıca hızlıdır, kullanıcı memnuniyetini artırır ve destekleyen tarayıcılarda ek yazılım gerektirmeden çalışır. Kısacası güvenlik, hız ve dönüşüm oranı açısından net bir kazanım sağlar.

Mimarinin Özeti

WebAuthn iki ana akıştan oluşur: kayıt (registration/attestation) ve giriş (authentication/assertion). Sunucu benzersiz bir challenge üretir, istemci bunu güvenli donanımda imzalar ve sunucu doğrular. Başarılı kayıt sonunda kullanıcıya ait credentialId, publicKey ve signCount gibi meta veriler veritabanında saklanır. Girişte de benzer şekilde sunucu yeni bir challenge üretir, istemcinin imzasını doğrular ve sayacı günceller.

Gereksinimler ve Hazırlık

- Etki alanınız HTTPS üzerinde çalışmalıdır. Geliştirme için https://localhost istisnai olarak geçerlidir.
- rp.id (relying party id) genellikle alan adınızın eTLD+1 karşılığıdır (ör. example.com). Alt alan adında çalışsanız bile rp.id çoğunlukla kök alan olmalıdır.
- Node.js tarafında popüler kütüphane olarak @simplewebauthn/server ve istemci için @simplewebauthn/browser tercih edebilirsiniz.

Adım Adım Kurulum (Node.js)

Adım 1 – Proje kurulumu: Sunucu için Express veya Fastify kullanabilirsiniz. Temel bağımlılıklar: @simplewebauthn/server, oturum yönetimi için bir middleware ve kalıcı saklama için bir veritabanı (ör. PostgreSQL).

Adım 2 – Kayıt seçeneklerini üretin: /register/generate-options uç noktasında PublicKeyCredentialCreationOptions üretin. rp.name ve rp.id, user.id, user.name, pubKeyCredParams ve authenticatorSelection alanlarını doldurun. authenticatorSelection.userVerification için “required” seçimi güvenliği artırır. Üretilen challenge’ı kullanıcı oturumuna yazın.

Adım 3 – Kayıt doğrulama: İstemci tarafından dönen navigator.credentials.create() sonucu ile /register/verify uç noktasında verifyRegistrationResponse çağrısını yapın. Başarılıysa credentialId, publicKey, counter ve transports bilgilerini veritabanında kullanıcıya bağlayın.

Adım 4 – Giriş seçeneklerini üretin: /login/generate-options uç noktasında PublicKeyCredentialRequestOptions döndürün. allowCredentials alanına kullanıcının kayıtlı credentialId’lerini ekleyin. Tek tık deneyimi için residentKey destekliyorsanız discovery senaryosunu da tasarlayın.

Adım 5 – Giriş doğrulama: İstemcinin navigator.credentials.get() yanıtını /login/verify uç noktasına gönderip verifyAuthenticationResponse ile kontrol edin. İmza geçerliyse oturumu başlatın ve signCount değerini güncelleyin.

İstemci (Tarayıcı) Akışı

Kayıt sırasında sunucudan aldığınız creationOptions ile navigator.credentials.create({ publicKey: creationOptions }) çağrısı yapın. Sonucu sunucuya POST edin. Girişte ise requestOptions ile navigator.credentials.get({ publicKey: requestOptions }) çağrısı yapın. Bu çağrılar kullanıcıyı biyometrik sensör veya cihaz kilidiyle onay vermeye yönlendirir.

Test, Hata Ayıklama ve Uyumluluk

Chrome DevTools’ta “WebAuthn” paneliyle sanal authenticator ekleyebilir, platform ve çapraz platform seçeneklerini simüle edebilirsiniz. Sık karşılaşılan hatalar: NotAllowedError (kullanıcı iptal etti veya zaman aşımı), DOMException: SecurityError (rp.id ve origin uyumsuz), Constraint hataları (ör. residentKey politikası). Üretimde hem platform (telefon, laptop) hem de harici güvenlik anahtarlarını test edin.

Güvenlik ve En İyi Uygulamalar

- Bütünleşik phishing direnci için rp.id ve site origin eşleşmesine dikkat edin.
- Challenge değerini kriptografik olarak güvenli rastgelelik ile üretin ve tek kullanımlık olarak saklayın.
- userVerification’ı “required” kullanmak; başkasının cihazı üzerinden kötüye kullanım riskini azaltır.
- Birden fazla cihaz senkronizasyonunu desteklemek için kullanıcıya birden çok credential eklemeye izin verin.
- Güvenlik anahtarı kaybı için kurtarma akışları (ikinci passkey, e-posta linki, müşteri desteği) tasarlayın.

UX Önerileri

Passkey’i bir opsiyon olarak sunmak yerine “Passkey ile giriş yap” butonunu ön plana alın. Uyumlu tarayıcı ve cihazlarda otomatik doldurma istemini tetiklemek için form alanlarınızı sade tutun. Kayıt sırasında cihaz adını kullanıcıdan alarak (ör. “Mert’in iPhone’u”) hesap ayarlarında listelemeyi kolaylaştırın. Passkey bulunmazsa parolasız alternatif olarak sihirli bağlantı (magic link) sunmak terk oranını düşürür.

Dağıtım ve Aşamalı Geçiş

Mevcut oturum açma sisteminizi bozmadan aşamalı geçiş yapabilirsiniz. Önce kayıtlı kullanıcılarınıza ek kimlik doğrulama metodu olarak passkey tanımlama imkanı verin. Kullanıcı davranışı oturursa parolayı isteğe bağlı hale getirin ve yeni kullanıcılara “passkey-öncelikli” deneyim sunun. CDN veya ters proxy katmanında HTTPS ve HSTS ayarlarının doğru olduğundan emin olun.

Sonuç

Passkey (FIDO2/WebAuthn), şifrelerin yarattığı güvenlik risklerini ve kullanıcı sürtünmesini önemli ölçüde azaltır. Node.js ekosistemindeki olgun kütüphaneler sayesinde entegrasyon birkaç uç noktayı uygulamak kadar basit hale geldi. Doğru rp.id yapılandırması, güvenli challenge yönetimi ve iyi bir UX ile dakikalar içinde modern, phishing dayanıklı ve tek dokunuşla giriş deneyimini hayata geçirebilirsiniz.

Kubernetes’te eBPF Tabanlı Cilium Kurulumu ve Hubble ile Ağ Gözlemlenebilirliği: Adım Adım Rehber

eBPF ve Cilium Neden Gündemde?

Kubernetes kümelerinde ağ katmanını hızlandırmak, gözlemlenebilirliği artırmak ve güvenliği sadeleştirmek için en çok konuşulan çözümlerden biri Cilium. Temelindeki eBPF (extended Berkeley Packet Filter) sayesinde paketleri çekirdek seviyesinde akıllıca işler, iptables tabanlı zincirlerin karmaşıklığını ve maliyetini azaltır. Bu da daha düşük gecikme, daha yüksek throughput ve net politika yönetimi sağlar. Üstelik Hubble bileşeniyle, canlı trafiği ve servis topolojisini sezgisel şekilde izleyebilirsiniz.

Önkoşullar

Bu rehberi uygulamak için çalışan bir Kubernetes kümesine ve küme yöneticisi yetkisine (cluster-admin) ihtiyacınız var. Çekirdek (Linux kernel) 5.4+ sürümü ve eBPF özelliklerinin etkin olması önerilir. kubectl ve Helm araçlarının yüklü olduğundan emin olun. Yönetilen bulut kümelerinde (EKS/AKS/GKE) Cilium desteklenir; ancak ağ eklentisi değiştirme adımları sağlayıcıya göre farklılık gösterebilir. Mevcutta başka bir CNI kullanıyorsanız, çakışmaları önlemek için ilgili eklentiyi temizlemeniz gerekir.

Kurulum: Helm ile Cilium

İlk adım olarak Helm deposunu ekleyip, Cilium’u kube-system ad alanına kuracağız. Eğer kube-proxy hâlen etkinse “partial” mod güvenli bir başlangıçtır; kube-proxy’yi tamamen devreden çıkarıp Cilium’u tam vekil (“strict”) olarak da kullanabilirsiniz.

Helm deposunu ekleyin ve güncelleyin
helm repo add cilium https://helm.cilium.io
helm repo update

Seçenek A — kube-proxy ile birlikte (kısmi değiştirme)
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxyReplacement=partial \
--set hubble.enabled=true

Seçenek B — kube-proxy’siz (tam değiştirme)
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxyReplacement=strict \
--set k8sServiceHost=<API-SERVER-IP> \
--set k8sServicePort=6443 \
--set hubble.enabled=true

İsteğe bağlı olarak, pod’lar arası trafiği şifrelemek için WireGuard’ı etkinleştirebilirsiniz. Bu, özellikle çok kiracılı ortamlarda veya düğümler arası segmentasyonun kritik olduğu durumlarda faydalıdır:

helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--set encryption.enabled=true \
--set encryption.type=wireguard

Hubble ile Canlı Trafik ve Politikaları İzleme

Hubble, Cilium’un ağ akışlarını, DNS isteğini, servis iletişimini ve politika kararlarını gözlemlemenizi sağlar. Hubble Relay ve Hubble UI bileşenlerini açarak tarayıcı üzerinden topolojiyi inceleyebilirsiniz.

Hubble Relay ve UI’ı etkinleştirme
helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true

Cilium CLI ile durum ve bağlantı testleri yapmak iyi bir pratiktir. Eğer cilium-cli yüklü değilse, sisteminize uygun binary’yi indirip PATH’e ekleyin. Kurulumdan sonra:

cilium status --namespace kube-system
cilium connectivity test --namespace kube-system

Hubble UI’a erişmek için port yönlendirme kullanabilirsiniz:

kubectl -n kube-system port-forward svc/hubble-ui 12000:80
Ardından tarayıcınızda http://localhost:12000 adresini açarak servis haritasını, akışları ve politikaların etkisini canlı izleyin.

Örnek CiliumNetworkPolicy

Cilium, Kubernetes NetworkPolicy’yi destekler; ayrıca daha ifade gücü yüksek CiliumNetworkPolicy (CNP) kaynakları sunar. Aşağıdaki örnek, sadece aynı ad alanındaki “frontend” etiketli pod’lardan “backend”e 8080/TCP erişimi veriyor ve DNS’i izinli kılıyor:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: backend-allow-frontend
namespace: app
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
- toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"

Bu politikayı uyguladıktan sonra Hubble UI veya hubble observe ile akışları takip ederek beklenen kısıtlamaların aktif olduğunu doğrulayın. Politika yazarken etiket tutarlılığı, ad alanı kapsamı ve port-protokol eşleşmelerine dikkat edin.

Sorun Giderme İpuçları

Kurulumda çoğunlukla iki tür sorunla karşılaşılır: eski CNI artıklarının çakışması ve çekirdek özellikleri. Daha önce Calico, Flannel vb. kullanıyorsanız, /etc/cni/net.d altındaki eski konfigürasyonları temizlediğinizden emin olun. Düğümleri yeniden başlatmak, CNI eklentisinin tutarlı şekilde devreye girmesine yardımcı olur.

Cilium pod’larının loglarını kontrol etmek genelde yeterli ipucunu verir: kubectl -n kube-system logs -l k8s-app=cilium. eBPF haritalarıyla ilgili hata görürseniz, çekirdek özelliklerini ve gerekli sysctl ayarlarını doğrulayın. Ağ tıkanmaları için cilium bpf metrics list ve cilium status çıktıları yol göstericidir.

Performans ve Güvenlik Notları

eBPF tabanlı yönlendirme ve servis yük dengeleme, özellikle yüksek pod yoğunluğu olan kümelerde belirgin CPU kazanımı sağlar. WireGuard şifreleme, düğümler arası trafiği güvenli kılarken, Egress Gateway özelliği dışa giden trafiğin sabit bir çıkış IP üzerinden çıkmasını sağlayabilir. DNS görünürlüğü, servis keşfi sorunlarını hızla ayıklamanıza yardım eder. Tüm bu bileşenler birlikte, daha şeffaf, hızlı ve güvenli bir Kubernetes ağı sunar.

Sonuç

Cilium + Hubble ikilisi, Kubernetes ağını sadece çalışır halde tutmakla kalmaz; aynı zamanda onu ölçülebilir, şeffaf ve yönetilebilir kılar. Bu rehberde temel kurulum, Hubble ile gözlemlenebilirlik ve örnek bir politika akışı sunduk. İlk başarıyı aldıktan sonra, servis mesh entegrasyonları, egress kontrolü ve gelişmiş akış metrikleri gibi özelliklerle kurulumunuzu genişletebilirsiniz. Üretim ortamında versiyon yükseltme ve yedeklilik planlarını da dahil ederek, Cilium’un gücünü güvenle ölçeklendirin.

Docker Buildx ile Çok Mimarili İmaj Oluşturma ve Cosign ile İmzalama (Güncel Rehber)

Giriş

Apple Silicon (ARM64) cihazların yaygınlaşması ve edge sunucuların çoğalmasıyla, tek bir mimariye derlenmiş konteyner imajları hızla demode oldu. Üretim ortamında aynı uygulamayı hem linux/amd64 hem de linux/arm64 üzerinde sorunsuz çalıştırmak için Docker Buildx ile çok mimarili (multi-arch) imaj üretmek artık bir zorunluluk. Bu yazıda, Buildx’i etkinleştirme, çok mimarili push, önbellek optimizasyonu ve imaj imzalama (Sigstore Cosign) adımlarını pratik ve güncel bir yaklaşımla anlatıyorum.

Neden Çok Mimarili İmaj?

M1/M2/M3 Mac’lerde lokal geliştirme yapıp, üretimde x86_64 (amd64) sunuculara deploy etmek en yaygın senaryo. Multi-arch sayesinde tek bir etiket ile iki mimariyi de içeren bir manifest yayınlarsınız; docker pull işlemi çalıştığı platforma uygun katmanı otomatik indirir. Böylece ayrı Dockerfile’lar, ayrı registry etiketleri ve karmaşık akışlar ortadan kalkar.

Önkoşullar

- Docker 20.10+ ve BuildKit etkin (varsayılan).
- QEMU emülasyonu için binfmt kurulumu (host’ta veya builder içinde).
- Bir container registry (Docker Hub, GHCR, ECR vb.).
- Opsiyonel: İmaj imzalama için Cosign ve SBOM üretimi.

Buildx’i Etkinleştirme ve Binfmt Kurulumu

Önce Buildx sürümünüzü kontrol edin: docker buildx version. Yeni bir builder oluşturup varsayılan yapın: docker buildx create --name multi --use. Gerekirse platform emülasyonu için docker run --privileged --rm tonistiigi/binfmt --install all komutunu çalıştırın. Bu adım, ARM64 makinede amd64 image derlemek gibi çapraz mimari senaryoları mümkün kılar.

Tek Komutta Çok Mimarili İmaj Üretme

Proje dizininizde basit bir Dockerfile olduğunu varsayalım. Multi-arch build ve push için şu kalıbı kullanabilirsiniz: docker buildx build --platform linux/amd64,linux/arm64 -t kullanici/uygulama:1.0 --push . Bu komut, her iki mimari için ayrı katmanlar üretir ve registry’e tek bir manifest altında yükler. Test etmek için docker buildx imagetools inspect kullanici/uygulama:1.0 çıktısında iki platformu görmelisiniz.

Performans ve Önbellek İpuçları

Yapı sürelerini kısaltmak için BuildKit cache kullanın. Registry tabanlı önbellek için: --cache-to type=registry,ref=kullanici/uygulama:cache,mode=max ve --cache-from type=registry,ref=kullanici/uygulama:cache seçeneklerini ekleyin. Ayrıca, Dockerfile’ı katman dostu yazmak (bağımlılıkları erken kopyalamak, --mount=type=cache kullanımı, çok aşamalı derleme) build sürelerini dramatik şekilde azaltır.

CI/CD’de Otomasyon (GitHub Actions Örneği)

CI’da tipik akış: checkout → docker/setup-qemu-action ile QEMU → docker/setup-buildx-action ile Buildx → registry’ye login → docker buildx build --platform linux/amd64,linux/arm64 --push. Sürüm etiketlerini v1.2.3, latest ve commit SHA gibi çoklu tag’lerle birlikte yayınlamak, tüketicilerin sağlam bir sürüm stratejisi izlemesine yardımcı olur.

Güvenlik: Cosign ile İmaj İmzalama ve SBOM

Supply chain güvenliği artık lüks değil. Cosign ile imajlarınızı imzalayarak, imajın sizden çıktığını kanıtlayabilirsiniz. Adımlar basit: cosign generate-key-pair ile bir anahtar çifti üretin; cosign sign --key cosign.key kullanici/uygulama:1.0 ile imzalayın; doğrulama için cosign verify --key cosign.pub kullanici/uygulama:1.0 çalıştırın. Build aşamasında SBOM eklemek için Buildx’in --sbom=true ve --provenance=mode=max seçeneklerini kullanabilir, yazılım bileşen envanterini otomatik üretip imajla ilişkilendirebilirsiniz.

Yaygın Hatalar ve Çözüm Yolları

- “no match for platform in manifest”: Multi-arch manifest push edilmemiş olabilir; --push bayrağını ve --platform listesini kontrol edin.
- Temel imaj arm64 yok: Kullandığınız base image’in her iki mimari için resmi desteği olduğundan emin olun. Örneğin alpine, debian ve ubuntu çoğunlukla multi-arch sunar.
- Yavaş build: QEMU emülasyonu doğal olarak yavaştır; mümkünse native runner kullanın (amd64 için amd64 runner). Cache’i registry’ye yazmayı ve tekrar kullanmayı unutmayın.
- İmza doğrulanmıyor: Doğru public key kullandığınızdan ve imzanın ilgili etikete uygulandığından emin olun. CI ortamında key yönetimi için OIDC ile keyless imzalama da değerlendirilmelidir.

En İyi Uygulamalar

- Tag stratejisi: semver (+ latest), commit SHA ve platform bağımsız tek etiket kullanın.
- Reproducible build: Sabit bağımlılık versiyonları ve belirli builder sürümleri seçin.
- Güvenlik: İmza ve SBOM’u pipeline’ın ayrılmaz parçası haline getirin, hatalı doğrulamada deploy’u durdurun.
- Gözlemlenebilirlik: Build süreleri, cache isabet oranı ve başarısızlık nedenlerini CI’da raporlayın.

Sonuç

Docker Buildx, çok mimarili konteyner üretimini günlük pratiğin doğal bir parçası haline getiriyor. Doğru yapılandırmayla tek komutta amd64 ve arm64 için imaj üretip push edebilir, CI/CD’de otomatikleştirip, Cosign ile imzalayarak supply chain güvenliğini güçlendirebilirsiniz. Bu yaklaşım, hem geliştirici deneyimini iyileştirir hem de üretim ortamlarında taşınabilirlik ve güvenilirliği artırır.

Ollama ve ChromaDB ile RAG: Kendi Verinizle Yerel Yapay Zekâ Sohbet Botu Nasıl Kurulur?

RAG nedir ve neden önemli?

Retrieval-Augmented Generation (RAG), bir dil modelinin cevap üretmeden önce bir vektör veritabanından ilgili parçaları geri çağırdığı, bu sayede daha doğru ve kaynaklı yanıtlar ürettiği bir yaklaşımdır. Güncel kurumsal ihtiyaçlarda gizlilik, maliyet kontrolü ve özelleştirme kritik hale geldiği için RAG, özellikle şirket içi dokümanlar, bilgi tabanları ve politikalar üzerinde çalışan sohbet botları için en verimli yöntemlerden biri olarak öne çıkıyor.

Bu rehberde, tamamen yerel çalışan bir kurulumla Ollama (yerel LLM çalıştırma), ChromaDB (vektör veritabanı) ve Python kullanarak adım adım bir RAG sistemi kurulumu yapacağız. Amaç, Türkçe metinlerle yüksek doğrulukta, düşük gecikmeli ve veri gizliliği korunan bir sohbet deneyimi sunmak.

Gerekenler ve mimari

Bileşenler: Ollama (Llama 3 veya benzeri açık kaynak model), ChromaDB (kalıcı vektör deposu), bir gömme (embedding) modeli (örn. intfloat/multilingual-e5-base), Python 3.10+, LangChain veya minimal kendi kodunuz. İsteğe bağlı olarak PDF/Word dosyaları için pypdf veya docx desteği ekleyebilirsiniz.

Akış: Dokümanları parçalara ayır → Embedding ile vektörleştir → ChromaDB’de indeksle → Soru geldiğinde benzer parçaları getir → Model için talimat şablonuna (prompt) enjekte et → Yanıtı oluştur ve kaynakları göster.

Kurulum adımları

1) Ollama’yı kurun. Resmi site üzerinden işletim sisteminize uygun paketi indirin. Model indirmek için komut satırında şu adımı uygulayın:
ollama pull llama3
Ardından test amaçlı kısa bir deneme yapabilirsiniz:
ollama run llama3

2) Python ortamını hazırlayın. Ayrı bir sanal ortam tercih edin:
python -m venv .venv && source .venv/bin/activate (Windows için .venv\Scripts\activate)
pip install chromadb sentence-transformers langchain langchain-community pypdf

Veri hazırlığı: parçalama ve temizleme

İyi bir RAG’in temeli, doğru parça boyutları ve temiz veridir. Türkçe belgelerde 300–500 token’lık parçalar pratikte iyi sonuç verir. Parçaları ayırırken başlık bilgilerini ve içerik konusunu korumaya çalışın. Örneğin bir politika belgesinde bölüm başlığını her parçaya meta veri olarak ekleyin. Bu, hem geri çağırmayı hem de kaynakları kullanıcıya göstermeyi kolaylaştırır.

Temizlik aşamasında gereksiz boşlukları, tekrar eden sayfa altbilgilerini ve tablo görsellerinden gelen çöp metinleri temizleyin. PDF okuyucu olarak pypdf kullanabilir, Markdown veya HTML dokümanlarını doğrudan metne dönüştürebilirsiniz.

ChromaDB ile vektör indeksleme

Embedding için çok dilli ve Türkçe performansı yüksek bir model seçin. “intfloat/multilingual-e5-base”, hız/doğruluk dengesiyle güvenilir bir tercih. Basit bir akış şöyle olabilir: Belgeleri oku → Böl → Her parça için embedding hesapla → ChromaDB’ye “persist_directory” ile kalıcı olarak yaz. Bu sayede uygulama yeniden başladığında indeksi tekrar oluşturmadan kullanabilirsiniz.

Koleksiyonlarınızı konuya göre ayırın (örn. “insan_kaynaklari”, “urun_dokumantasyonu”). Meta veriye kaynak adı, sayfa numarası, bölüm ve tarih gibi alanlar eklemek, yanıtların izlenebilirliğini artırır.

Sorgulama: RAG adım adım

Kullanıcıdan gelen soruyu önce bir sorgu embedding’ine dönüştürün, ardından ChromaDB’den en ilgili 3–5 parçayı çekin. Bu parçaları modelinize şu yapıda verin: kısa bir talimat + kullanıcı sorusu + “bağlam” bölümü (geri çağrılan parçalar). Örnek şablon yaklaşımı: “Aşağıdaki bağlamdan faydalanarak soruya kısa ve kaynaklı bir yanıt ver. Bağlamda yoksa tahmin yürütme.”

Ollama tarafında llama3 modelini çağırırken sıcaklık (temperature) düşük (0.1–0.3) tutulduğunda halüsinasyon azalır. Yanıtın sonuna “Kaynaklar” başlığı ile geri çağrılan parçaların referanslarını eklemek, güven inşa eder ve SEO açısından “uzman” hissiyatı yaratır.

İyileştirme: yeniden sıralama ve çoklu sorgu

Bazı senaryolarda temel benzerlik araması yeterli olmaz. Açık kaynak yeniden sıralayıcılar (örn. bge-reranker-large) ile ilk 20 sonucu alıp en iyi 5’ini rerank ederek doğruluğu yükseltebilirsiniz. Ayrıca multi-query tekniği ile kullanıcı sorusunu farklı biçimlerde genişletip (eş anlamlılar, farklı bağlamlar) birleştirilmiş sonuçlar elde etmek de hatırlamayı artırır.

Soru ön-işleme katmanında yazım hatalarını düzeltmek, alan terimlerini sözlükten normalleştirmek ve tarih-sayı gibi varlıkları standart forma getirmek, özellikle kurumsal dokümanlarda fark yaratır. Halüsinasyonları azaltmak için “sadece bağlamdan yanıt ver, bağlam yoksa ‘yok’ de” gibi net kurallar koyun.

Performans, güvenlik ve üretime alma

CPU ile başlayıp gerekirse GPU’ya geçin. Düşük bellekli sistemlerde quantized (örneğin Q4_0) model varyantları iyi sonuç verir. ChromaDB tarafında kalıcı dizin SSD üzerinde olmalı ve düzenli olarak koleksiyon boyutu ile gecikmeyi izleyin. Top_k değerini 3–8 arasında test ederek doğruluk/performans dengesini bulun.

Üretim ortamında bir FastAPI uç noktası ile sorgulama zincirinizi sunabilirsiniz. Yanıtları ve kullanılan kaynakları log’layarak kalite ölçümü yapın. Kişisel veriler içeren dokümanlarda yerel çalışmanın avantajı büyüktür; ağ dışına veri çıkarmadan kurumsal uyumluluk hedeflerine yaklaşabilirsiniz.

Sonuç

Ollama + ChromaDB ile kurulan yerel RAG yığını, maliyeti düşük, gizliliği yüksek ve yönetilebilir bir yapay zekâ çözümü sunar. Doğru parça boyutu, iyi bir embedding modeli ve dikkatli şablonlama ile Türkçe içerikte dahi oldukça isabetli yanıtlar elde edebilirsiniz. Bu rehberi temel alarak önce küçük bir pilot oluşturun, ardından veri kapsamını ve değerlendirme metriklerini (doğruluk, geri çağırma, MRR) aşamalı olarak genişletin. Böylece güncel ve ileri seviye bir deneyimi, tamamen kendi verinizle kontrol ederek hayata geçirebilirsiniz.