Yapay Zeka’da Vahşi Batı vs. Kovboylar

AI araçlarının, gündelik hayatlarımızı son derece kolaylaştırması ve süreçlerimizi hızlandırması nedeniyle “kontrolsüzce” hayatımıza hızlıca adapte oldu. Bu kontrolsüz adaptasyon süreci de beraberinde “vahşi batı” atmosferini de beraberinde getirdi. Gartner’ın yayınladığı raporlarda, bu kontrolsüz dönemin artık sürdürebilir olmadığını net bir şekilde ortaya koyuyor. AI araçları artık sıradan bir “verimlilik” araçları olmaktan çıktı; kurumların sinir sistemlerine entegre olan otonom operasyonel bir güce dönüştü.

Sektör, basit “AI Agent”-lardan, kendi başına eyleme geçebilen bir “otonom ajanlara” doğru hızla evrilirken, güvenlik stratejileri bu evrimin gerisinde kalıyor. Kurumlar artık ilgili modelleri kullanmak değil, yapay zekanın yarattığı otonom sistemleri nasıl dizginleyecekleri ile ilgileniyor.

Ofisinizdeki Gizli Misafir: Gölge AI Araçları (Shadow AI)

Organizasyonlar artık BT departmanlarının onayı dışında kullanılan yapay zeka araçlarının, kurumsal görünürlüğün en büyük kara deliği haline geldiğinin farkında. Gartner Peer Insight verileri, çalışanların verimlilikleri uğruna “Gölge Yapay Zeka” araçlarının kullanımının standartlaştığını gösteriyor. Bu bir tercih değil, yönetilmesi gereken bir stratejik risk yüzeyi olduğunu kabul etmemiz gerekiyor.

Yapay zeka güvenliğini sağlamayı amaçlayan platformlar, şirket ağlarında 500‘den fazla yapay zeka araçlarını sunmakla kalmıyor, ISO 42001 ve EU aI Act gibi kritik regülasyonlara uyumları da denetliyor.

Çalışanlar ChatGPT, Gemini, Claude, Kimi vb. araçları gün geçtikçe daha da benimsiyor. Bu benimsemenin önüne geçmek yerine, görünürlüğü sağlamamız gerekiyor.

Asistanlardan Ajanlara Evrim ile Risk Değişimi

Gartner’ın pazar kategorilerindeki en köklü değişim, “AI Kod Asistanlarından” “AI Kod Ajanlarına” geçişte yaşanıyor. Asistanlar, kod önerisi sunarken, ajanlarla uygulama mimarilerini değiştiren ve API’leri bağımsızca çağıran yapılar devrede. Sadece bu durum bile eski, geleneksel statik kod analizlerini bile yetersiz kılıyor.

Artık tam yaşam döngüsü kapsamı (full-lifecycle coverage), bir ajanın sadece ne yazdığını değil, aracın başka hangi araçları çağırdığını (tool invocation) ve bu araçların nasıl davrandığını izlemeyi gerektiriyor. AI güvenlik araçları MCP (Model Context Protokol) üzerinden gerçek zamanlı politika yönetimi sağlayarak, riskli eylemleri daha gerçekleşmeden engellemeyi hedefliyor.

Runtime Savunması: Halüsinasyon ve Toksisiteye Karşı Koruma

AI güvenliği sadece güvenlik duvarları ile saldırılara karşı duvar örmek değildir. AI Security ve Anomaly Detection pazarı, modelin kendi kendine ürettiği “kusurlu” sonuçları engellemeye odaklanıyor. Bu aşamada da hem gelen sorguları hem de modelin ürettiği yanıtları eBPF konnektörleri sayesinde sistem çağrıları, network trafiği ve proccess davranışları içgörülerle analizi ile Prompt Injection, Halüsinasyon ve Yanlılık ve Veri Sızıntılarına karşı koruma sağlıyor.

İnsan Olmayan Kimlikler: Bot vs. API Güvenlik Savaşları

Güvenlik açıkları artık sadece insan veya config hatalarından kaynaklanmıyor. Özellikle yönetilemeyen 3. taraf entegrasyonlar ve veri akışlarının entegrasyonları oldukça kompleks hale gelmiş durumda. Bu durumda API, servis hesapları ve entegrasyonlarda ki veri akışlarını haritalandırarak; kimin, hangi veriye neden eriştiğini bilmeyi şart haline getiriyor.

Yeni Standart: Ajan Tabanlı Güvenlik Yönetimi (Agentic SPM)

Agentic SPM (Agentic Security Posture Management) tanımını önümüzde ki günlerde daha sık duyacağız. Bu yaklaşım, ajanların sahip olduğu aşırı yetkileri (excessive privilege) ve riskli erişim yollarını sürekli takip ederek, geleneksel güvenlikten ayrılıyor.

Gartner’ın 3’lü Yaklaşımı

Gartner, AI güvenliği yaklaşımını 3’e bölmüş durumda. Bunlar:

1. Development Stage (AI Application Security): İlk aşama olarak karşımıza çıkıyor. AI sistemini güvenli bir şekilde inşa etmeninde kendi içerisinde 4 adımdan oluşuyor. Bunlar:
   • Model & Data Güvenliği: Training verinin temizliği, data poisoning riskleri, hassas veriler.
   • Supply Chain Security: Kullanılan model nereden geliyor? Model güvenirli mi? Dependencyler temiz mi?
   • API & Entegrasyon Güvenliği: LLM API Key’ler nasıl saklanıyor? Rate Limit / Auth kontrolleri.
   • Prompt Engineer: Promptlar manipülasyona açık mı? System prompt leak tehlikesi var mı?
2. AI Security Testing / Red Team: Kurulan AI aracının red team olarak test edilmesi adımıdır. Bu adımı da 5 aşamada inceleyebiliriz.
   • Prompt Injection Testleri
   • Jailbreak Testleri
   • Adversarial Input
   • Data Exfiltration Test
   • Halüsinasyon Testi
3. Runtime Güvenliği (AI Security & Anomali Tespiti)
4. Governance (Shadow AI + Data Kontrol)

Kaynaklar:

https://www.gartner.com/reviews/market/ai-security-and-anomaly-detection

https://www.gartner.com/reviews/market/ai-application-security

https://www.gartner.com/reviews/market/ai-security-testing

Anthropic’in Hackathon birincisinden çıkan Everything Claude Code ile kodlama AI’larına adeta bir orkestra şefliği yaparak, beyin görevini görüyor.

Neyi Çözüyor?

ECC (Everything Claude Code) temelde 4 soruna odaklanıyor:

• Context Loss (Bağlam Kaybı): Uzun ve büyük projelerde AI’ların, proje başındaki kararları unutması veya saçmalaması.
• Yüksek Maliyet ve Yavaşlık: Bağlamsallığı unutan AI agentlar, tekrara düşerek gereksiz token gönderimi yapar ve bu yüzden artan API harcamaları.
• Güvenlik Riskleri: AI’ların bazen proje içerisinde güvensiz ve eski kütüphaneleri önermesi ve bu yüzden güvenlik açıklarının oluşması.
• Tekrarlanan Hatalar: Bağlamsallığı unutan AI’lara sürekli hatırlatma yapma zorunluluğu.

Nasıl Yapar?

Elimizde stajyer bir AI aracı var. Bu repo ile ajanımızın yanına bir nevi “Test Mühendisi“, “Kıdemli Yazılım Mimarı“, “Güvenlik Uzmanı” gibi 28 adet farklı sub-agentlar ekleyebiliyoruz. Projeyi de bu sub-agentlara bölerek aynı anda kod yazdırırken, yazdırdığımız kodunda güvenlik açıklarını taratabilirsiniz. Buna uzmanlaşmış ajanlar diyebiliriz.

Proje için verdiğiniz direktifleri de instinct (iç görü) olarak kaydediyor ve sizin projeye yaklaşımınızı, hedeflerinizi ve proje kurallarınızı öğreniyor. Böylece her seferinde AI’ın hatalarını düzeltmek zorunda kalmıyorsunuz. Buna da akıllı hafıza diyebiliriz.

Uzmanlaşmış ajanlar ve bu ajanlardaki akıllı hafıza sayesinde API maliyetlerinizi düşürerek; performans kazancının yanı sıra, kodlarınızın otomatik kontrolünü sağlayabiliyorsunuz.

Teknik Mimari ve Mekanizmalar

Teknik olarak Everything Claude Code; LLM tabanlı vibe coding araçları için bir Harness Performance Optimization System yani bir Donanım Performans Optimizasyon Sistemi olarak çalışıyor:

1. Multi Agent Orchestration (Çoklu Ajan Orkestrasyonu): ECC ile beraber, yukarıda bahsettiğim gibi 28’den fazla spesifik sistem promptunu barındırıyor. Bunlar planner.md, architect.md, security-reviewer.md gibi dosyalarla tanımlıyor. Böylece karmaşık görevleri de sub-agentlara bölerek, sistemin halüsinasyon görmesini de engelliyor.
2. Token Management & Token Optimization: system prompt sliming ve background process yöntemleri ile context window verimini artıyor. Bu da gereksiz komutların modellere gönderilmesini engelleyen bir filtreleme mekanizması sunuyor.
3. Even-Driven Hooks: Git veya IDE (Cursor, OpenCode vb.) olaylarına bağlı çalışan hooks sayesinde; her kayıt veya commit öncesinde AgentShield üzerinden statik analiz ve güvenlik taraması gerçekleştirilir.
4. Instinct Based Learning: Kullanıcı etkileşimlerinden elde edilen başarımlar, birer skill veya instinct dosyasına dönüştürülür ve kalıcı hale gelir. Böylece projeler zero shot yerine fine tuned context olarak çalışmasını sağlar.
5. Cross Harness Parity: Yazılan kural setleri ve komutlar; Claude Code, Antigravity, Cursor ve Codex gibi farklı AI geliştirme ortamlarının aynı anda çalışabilecek şekilde optimize eder.

Node.js tabanlı hooklar sayesinde Linux, Powershell ve macOS üzerinde tutarlı bir performans gösteren ECC; npm, pnpm, bun gibi paket yöneticilerini de otomatik olarak tespit ediyor.

Kullanım Şekli

Bir özellik eklemek istediğinizde /plan komutunu sisteme verdiğinizde sistem önce architect ajanını çağırır, proje planı oluşturulduktan sonra planner ile proje planı çıkartılır. Sonrasında tdd-guide ile test ortamlarını oluşturur ve en son code-reviewer ile kalite kontrolünü gerçekleştirir. Böylece süreç otomatikleşir.

Temel Komutlar

Planlama

• plan: Yeni bir özellik veya hata düzenlemesi için kapsamlı bir uygulama planı oluşturur.
• execute: Oluşturulan planı adım adım uygular ve kod değişikliklerini yapar.
• tdd: Test odaklı geliştirme sürecini başlatır. Önce testleri yazar, sonra kod geliştirmeye başlar.
• refactor: Mevcut kodları temizler. Ölü kodları temizleyerek performans artışı sağlar.
• docs: Kod tabanına göre dokümantasyon oluşturur veya var olanı günceller.

Güvenlik ve Kalite Kontrol

• security-scan: Kod tabanını CVE’ler ve aygın güvenlik zafiyetlerini AgentShield entegrasyonu sayesinde tarar.
• review: Değişiklikleri kalite, performans ve best practice açısından inceler.
• harness-audit: Mevcut AI konfigürasyonunuzu ve kurallarınızın performansını denetler.
• quality-gate: Belirlenen kalite standartları karşılanmadan kodun ilerlemesine izin vermez.

Çoklu Ajan ve Otomasyon

• loop-start: Belirli bir görev için otonom çalışma döngüsünü başlatır.
• loop-status: Devam eden otonom süreçlerin durumunu listeler.
• pm2: Arkaplanda çalışan servisleri ve süreçleri yönetir.
• multi-plan: Birden fazla servis veya mikroservis içeren karmaşık süreçleri yönetir.

Hafıza ve Öğrenme

• instinct-import: Başarılı kod kalıplarını ve kurallarını AI’ın içgüdü dosyasına ekler.
• sessions: Geçmiş çalışma ortamlarınızı listeleme ve geri yüklemenizi sağlar.
• setup-pm: Proje için tercih edilen paket yöneticinizin seçmenizi sağlar.
• codex-setup: OpenAI’ın Codex CLI ile ilgili uyumluluk dosyasını oluşturur.

Kurulum ve Yapılandırma

• configure-ecc: ECC’nin kurulum sihirbazını başlatır. Dilleri ve kuralları oluşturur.
• plugin install: ECC eklentisini Claude Code üzerine kurar.
• model-route: Görev zorluğuna göre AI modelini otomatik olarak seçmenizi sağlar.

İlgili repo: https://github.com/affaan-m/everything-claude-code

Bu projede iki tane amacım vardı. Birincisi “Şu notu Drive’a kaydet”, “Şu scripti Drive’a ekle”, “Şu dosyayı drive’a ekle” diyerek kişisel asistanıma özel bir alan tahsis etmek, ikincisi de bir nevi RAG olarak kullanmaktı.

RAG tarafında tabii ki vektör veritabanı şeklinde değil, dosya kaynağı + embed edilen içerik olarak kullanmak. Sonra ki adımım ise bu dosyaları Qdrant veya Weaviate gibi vektör veritabanına basmak olacak.

Proje sürecinde üç problemim vardı. Bunlar:

1. OpenClaw’ın çalıştığı sunucum ile Google Drive’ım arasında güvenli bir iletişim katmanı kurmak.
2. Google’ın service account kısıtlamalarından dolayı Drive’ımda kota sorunu yaşamamak.
3. Tüm bunları, ileri de geliştirebileceğim bir ufak bir REST API ile gerçekleştirmek.

Projenin Genel Mimarisi

Projenin genel mimarisini aşağıdaki şekilde oluşturdum:

1. OpenClaw ajanım, doğrudan Google Drive API’sine dokunmuyor.
2. Fast tabanlı Drive Bridge ile Google Drive ile konuşmak.
3. Bu script ile ilgili klasör (OpenClaw Files) içerisinde okuma/yazma/düzenleme haklarına sahip olması.
4. Kimlik doğrulama olarak service account yerine, kullanıcının hesabı ile yetkilendirilmiş bir OAuth Client + Refresh Token kombinasyonunun kullanılması.

Peki böylece ne oldu;

1. Ajan sadece local HTTP endpointlerine istek atıyor. (Örnek: HTTP /files)
2. Google tarafında erişimimizi sağlayan tüm hassas veriler sunucu da barındırılıyor. (credentials.json, token.json)
3. Drive erişimi sadece ilgili klasöre ve dosyalara gerçekleşiyor.

İlk Deneme: Service Account Neden Olmadı?

İlk başta Google Cloud Console‘da bir servis oluşturdum. Sonrasında oluşturduğum bu servis altında bir service account oluşturdum.

Bir mail hesabı gibi aldığım bu service account‘u daha sonrasında Google Drive’ım da ki klasörde “Paylaş” diyerek yetki verdim. Ayrıca ilgili klasörün ID’sini de URL’de ki bardan aldım. (Örnek: https://drive.google.com/drive/folders/KLASÖR_ID)

Daha sonrasında FastAPI içerisinde service-account.json dosyası ile Drive API Client‘ı oluşturdum.

İlk başta okuma ve listeleme de mimari çalışsa da, dosya oluşturma kısmında aşağıda ki hata ile karşılaştım:

Service Accounts do not have storage quota. ... reason: storageQuotaExceeded

Bu hata; kişisel Google Drive hesabımda service accountların kendi başına bir kota sahibi olmadığı için dosya yükleyemiyor veya oluşturamıyor.

Yaptığım araştırmalarda Google Workspace’de bu hatanın bir çözümü olduğu yönündeydi fakat ben Google Workspace kullanmadığım için ne yazık ki işime yaramadı. Bu yüzden de mimari de bir değişikliğe giderek OAuth üzerinden erişmeye çalıştım.

Yeni Mimari: OAuth Client + Offline Token

Karşılaştığım sorunlar ve yaptığım araştırmalar sonucunda Google Drive’ıma erişim için en doğru ve güvenilir yol GCP (Google Cloud Platform) üzerinde bir OAuth Client ID ile devam etmekti. Bunda da yöntem olarak Desktop App‘i seçtim.

Ardından lokal bilgisayarımda çalıştıracağım bir python script ile (get_token.py) tarayıcı üzerinden bir token ürettim. Sonrasında kendi bilgisayarım üzerinden ürettiğim token.json ve credential.json ikilisini OpenClaw sunucuma taşıyarak, backend’in kullanıcı adına ilgili Drive’ıma erişmesini sağladım.

Kullandığım Scope:

SCOPES = ["https://www.googleapis.com/auth/drive.file"]

Bu scope, uygulamaya sadece kendi oluşturduğu veya açtığı dosya ve klasörlere erişim izni veriyor. Böylece OpenClaw ajanı, Drive’ım da ki tüm dosya ve klasörleri göremiyor, sadece entegrasyona dahil dosya ve klasörlere erişim sağlayabiliyor.

Token Oluşturma Scripti

Lokal makinemde, yani bilgisayarımda aşağıda ki adımları gerçekleştirdim:

• Google Cloud Console’dan OAuth Client dosyasını indirip, credentials.json olarak kaydettim.
• Aynı klasörde get_token.py python scriptini çalıştırdım.
• Script tarayıcı da yeni bir sekme açarak, Google login ve izin ekranlarını açtı. Gerekli izinleri verdiğimde token.json dosyasını üretti.

Sonrasında bu iki dosyayı (credentials.json ve token.json) OpenClaw’ın olduğu sunucu da, ayrıca oluşturduğum workspace içerisinde ki dosyaya yükledim.

FastAPI ile “OpenClaw Drive Bridge” Servisi

OpenClaw sunucumda ki ilgili workspace içinde aşağıdaki yapıda bir proje oluştudum;

openclaw-drive-bridge/
-main.py
-requirements.txt
-credentials.json
-token.json
-.env

Bağlılıklar

Requirement.txt:

fastapi
uvicorn[standard]
google-api-python-client
google-auth
google-auth-httplib2
google-auth-oauthlib
python-multipart

Proje seviyesinde izole kalması için bir virtualenv içinde oluşturdum:

cd /root/.openclaw/workspace/kanka-drive-bridge
python3 -m venv .venv
./.venv/bin/pip install -r requirements.txt

OAuth ile Drive Client Oluşturma

FastAPI uygulamasında Drive Client şöyle oluşuyor:

from google.auth.transport.requests import Request
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
SCOPES = ["https://www.googleapis.com/auth/drive.file"]
CREDENTIALS_FILE = "credentials.json"   # OAuth client
TOKEN_FILE = "token.json"               # Kullanıcı token'ı
OPENCLAW_GOOGLEDRIVE_FOLDER_ID = "DRIVE_FOLDER_ID"  # OpenClaw Files klasörü
def get_drive_service():
    creds = Credentials.from_authorized_user_file(TOKEN_FILE, SCOPES)
    if not creds.valid:
        if creds.expired and creds.refresh_token:
            creds.refresh(Request())
        else:
            raise RuntimeError("Geçersiz veya yenilenemeyen Drive kimlik bilgileri")
    service = build("drive", "v3", credentials=creds)
    return service

Burada önemli olan, uygulamanın gerekirse her istekte token’ı Refresh Token üzerinden yenileyebilmesi.

RestAPI Endpointleri

Servis aşağıdaki endpointleri sağlıyor:

@app.post("/files", response_model=FileContentResponse)
def create_or_update_file(req: FileCreateRequest):
    try:
        service = get_drive_service()
        existing = None
        if req.overwrite:
            existing = find_file_in_folder_by_name(service, req.name)
        data = req.content.encode("utf-8")
        media = MediaInMemoryUpload(data, mimetype=req.mimeType, resumable=False)
        file_metadata = {
            "name": req.name,
            "parents": [DRIVE_FOLDER_ID],
        }
        if existing and req.overwrite:
            file_id = existing["id"]
            file = service.files().update(
                fileId=file_id,
                media_body=media,
            ).execute()
        else:
            file = service.files().create(
                body=file_metadata,
                media_body=media,
                fields="id, name, mimeType, parents",
            ).execute()
        file_id = file["id"]
        downloaded = service.files().get_media(fileId=file_id).execute()
        return FileContentResponse(
            id=file_id,
            name=file["name"],
            mimeType=file.get("mimeType", req.mimeType),
            content=downloaded.decode("utf-8", errors="ignore"),
        )
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Bu sayede Kanka, sunucuda yalnızca şu formatta bir HTTP isteği yaparak Drive’a dosya yazabiliyor:

curl -X POST "http://localhost:8000/files" \
-H "Content-Type: application/json" \
-d '{
"name": "deneme-notu.txt",
"content": "Merhaba, bu OpenClaw Files klasörüne giden ilk not  (OAuth)",
"mimeType": "text/plain",
"overwrite": true
}'

GET /files ve GET /files/{file_id} de listeleme ve içerik okuma için kullanılıyor.

OpenClaw Tarafında Kullanım

Bu yapımızla beraber ajanımızın işi oldukça basit:

• Telegram üzerinden yazdığım ve not olarak kaydet dediğim metinleri ajan otomatik olarak Google Drive’a uygun bir şekilde dönüştürüyor. (.md veya .txt olarak)
• Arka tarafta POST /files endpointine istek atarak Drive üzerinde ki ilgili klasöre atıyor.
• Daha sonra notu aç dediğinizde önce GET /files ile ilgili dosyayı buluyor, değiştirme isteği varsa GET /files/{id} şeklinde ilgili datayı çekip, işliyor.

Bütün hassas işlemler (OAuth, refresh token, Google Drive API çağrıları) Drive Bridge servisinde izole bir şekilde kalıyor.

Sonrasında planladıklarım;

• Alt Klasör Mantığı (Blog, Work, Media, Git, Notes vb.)
• Binary Upload (Video, ses, görüntü dosyaları için multipart upload destekleyen ek endpoint’ler.)
• Çift Yönlü Entegrasyon (Drive’daki belirli bir klasörü tarayıp “Yeni gelen dosyalar var mı?” şeklinde Kanka’ya tetikleyici olarak bağlamak.)

GitHub Reposu: https://github.com/mutkus/OpenClaw-GoogleDrive-Bridge/

Terminal üzerinde Mac’inizi yönetmenizi sağlayan Mole, “Mac Cleaner” ürünlerinin hepsini bir araya getiriyor.

Neden Mole?

Mole’nin misyonu oldukça açık: macOS’unuzda dip bucak temizlik yapmak. Üstelik bunu yaparken kullanıcıyı boğmadan, oldukça basit yöntemlerle gerçekleştiriyor. Mole ile birden fazla aracın yaptığı işlemleri yapabilirsiniz:

1. CleanMyMac,
2. AppCleaner,
3. DaisyDisk,
4. iStat Menu

Mole İçerisinde ki Araçlar

Derin Temizlik

Mole’ın belki de en çok kullanılan araçlarından bir tanesi diyebiliriz. Kullanıcı önbelleklerini, sistem geçici dosyalarını, tarayıcı verileri gibi tarayabilir ve silebilirsiniz.

Akıllı Uygulama Kaldırma

Mole içerisinde ki uygulama kaldırma özelliği ile uygulamayı düz bir şekilde “çöp kutusuna taşı” yönteminden ziyade uygulama paketlerini, launch agentları, tercih dosyaları gibi dosyaları daha sağlıklı bir şekilde kaldırabilirsiniz.

Disk Analizi ve Görsel Çıktı

Analyze komutu ile birlikte disk üzerinde ki hangi klasörlerin ne kadar yer kapladığını bir Tree Size mantığı ile görmenizi sağlar.

Canlı Sistem İzleme

Terminal üzerinde CPU, Disk, Ram, I/O ve ağ metriklerini canlı olarak izlemenizi sağlıyor.

Sonuç

Mole, macOS temizliği ve optimizasyonu için minimalist ama güçlü bir çözüm sunuyor. Açık kaynak olması, terminal odaklı yaklaşımla güçlü kontrol ve otomasyon imkânı sağlaması, onu özellikle geliştiriciler ve ileri düzey kullanıcılar için cazip kılıyor. Gereksiz yazılım bombardımanından uzak durmak, tamamen kontrol sende olan bir temizlik deneyimi yaşamak istiyorsan Mole kesinlikle denemeye değer bir araç.  

Adres: https://github.com/tw93/Mole

RAG Nedir?

RAG (Retrieval-Augmented Generation) araçlarını basitçe tanımlamak gerekirse; LLM’lerin dış dünyadan besleme yöntemi diyebiliriz. LLM’ler büyük eğitim paketlerinden geçerler, fakat bu eğitim paketleri kendi içlerinde her soruya cevap barındırmayabilirler. RAG sayesinde LLM’lerin sadece eğitim sırasında öğrendikleri veri setlerine bağlı kalmayıp, sorulan sorulara ilgili dökümanları bulup (Retrieval) bu dökümandaki verileri kullanarak cevap üretmesi sağlanır. (Generation)

RAG’ların Sağladığı Temel Faydalar

• Güncel Veri: LLM’lerin veri kesilme tarihleri vardır. Örneğin 2026 yılının Ocak ayında eğitilen modelde, Şubat ayında ortaya çıkan güncel veri setleri bünyesinde barındırmaz. RAG sayesinde güncel veriler, LLM’ler tarafından keşfedilerek, doğru bilgiyi vermeye çalışırlar.
• Doğruluğun Artması ve Halüsinasyonun Azalması: RAG sayesinde model, bir tahminden ziyade sizlerin verdiği dökümanlara bakarak doğru cevap vermeye çalışır ve bu sayede model halüsinasyonu azalır.
• Gizlilik ve Özelleştirme: Örneğin şirketinize dair hassas verileri öğrenmesi için ilgili modele vermeden, sadece verdiğiniz görev kapsamında kullanılmasını sağlayarak hassas verilerinizin diğer kullanıcılar tarafından erişilmesini engellersiniz.
• Maliyet: Modeli kendi veri setlerinize göre yeniden eğitmek (Fine-Tuning) oldukça zahmetli ve maliyetli bir yöntemdir. RAG sayesinde ise bu işlemi oldukça hızlı ve ekonomik bir şekilde tamamlayabilirsiniz.

RAG Olmazsa Olmaz Mı?

Bu soru aslında modeli ne için kullandığınıza göre değişir. Örneğin LLM’i gündelik hayatınızda, genel sohbet çerçevesinde kullanıyorsanız bir RAG’a ihtiyacınız bulunmaz. Fakat örneğin teknoloji dünyasında sürekli değişen güncel verilere ulaşım istiyorsanız, hukuk veya tıp alanında bir veriye ulaşırken halüsinasyon istemiyorsanız veya modeli kendi kişisel asistanınız gibi kullanmanızı ve bu nedenle eski notlarınıza da erişmesini istiyorsanız evet, RAG süreçlerini kolaylaştıracaktır.

AnythingLLM Nedir?

RAG’ın ne olduğunu ve hangi şartlarda kullanıldığını açıkladık. Yazımızın devamında kendi sunucunuzda, hafif ve güçlü bir RAG aracı olan AnythingLLM’i nasıl kurabileceğinize bakalım. Benim sanal sunucu ortamımda Coolify’ın v4 versiyonunu kullanarak bir kurulum gerçekleştirdim.

Kurulum

Yeni Kaynak Oluşturma

İlk olarak Coolify sunucumuza login olduktan sonra +New Resource diyerek yeni bir Docker Image oluşturuyoruz ve parametreleri aşağıdaki şekilde dolduruyoruz:

• Docker Image: mintplexlabs/anythingllm (Ben mintplexlabs/anything-llm şeklinde olmamasına dikkat edin. Aksi takdirde “access denied” hatası alabilirsiniz.)
• Image Tag: latest

Ağ ve Domain Yapılandırması

Uygulamanın internet üzerinden erişilebilir olması için aşağıda ki ayarları yapmalısınız:

• Domains: https://anything.domain.com (SSL erişimi için https yazmayı unutmayın.)
• Port Exposes: 3001 (Anything’in kullandığı port)
• Port Mapping: Sadece bir domain üzerinden erişim olacaksa bu alanı boş bırakın.

Environment Variables Eklemek

Eğer kurulum sonrası loglarınızda TypeError [ERR_INVALID_ARG_TYPE] veya STORAGE_DIR environment variable is not set! hatası alıyorsanız ve konteyner sürekli Restarting durumunda kalıyorsa, şu iki işlemi yapmanız şarttır:

• Key: STORAGE_DIR
• Value: /app/server/storage

Persistent Storage (Kalıcı Alan)

RAG eğitiminde kullandığınız dosya ve verilerin, sunucu yeniden başladığında veya güncelleme aldığında silinmesini istemiyorsanız bir storage eklemeniz gerekmektedir. Bunun için Persistent Storage alanına gelip, +Add dedikten sonra Volume Mount diyerek açılan ekranda aşağıdaki değeleri girmeniz gerekli:

• Persistent Storage sekmesinden bir volume oluşturun.
• Destination Path: /app/server/storage olarak ayarlayın.

Cloudflare’de Invalid SSL 526 Hatası

Eğer DNS kayıtlarınız Cloudflare’de ise ve AnythingLLM’e erişirken tarayıcınızdan “Invalid SSL 526” hatası alıyorsanız, Cloudflare panelinizde ilgili domaine girdikten sonra SSL/TLS alanına gelip, Full (Strict) yöntemini Full olarak değiştirmeniz gerekecektir. Ortamınıza kurduğunuz AnytingLLM kendi sertifikasını (Let’s Encrypt) aldıktan sonra tekrardan Full Strict moduna geçebilirsiniz.

Temel Özellikler

Sistemde varsayılan olarak gelen 8 adet B300 GPU sayesinde önce ki seri olan B200’lere göre compute gücünde %55 daha hızlı. B200’ün FP4 (4 Bit Floating Point) değeri 9 PFLOPS iken B300’de 14 PFLOPS olarak karşımıza çıkıyor. Ayrıca B200’de 180 GB GPU Memory bulunurken, B300’de 288 GB GPU Memory‘i bulunmakta. 8 kartın olduğunu göz önüne aldığımızda ise toplamda 2.3 TB HBM3e belleğe ulaşıyor.

Üstelik 5. nesil NVLink teknolojisini kullanmasından dolayı, GPU’lar arası veri aktarımı saniyede 14.4 TB‘a kadar ulaşabiliyor. Bu da GPU’lar arasında darboğazların oluşmasını engelliyor.

Ayrıca sistem yönetimi için iki adet Intel Xeon Platinum 6776P ve 2 TB Ram bulunuyor. Ağ kartı olarak ise ConnectX-8 ile 800 Gb/s veri transferi sunuyor.

DGX B300 Farkı

Özellikle piyasa da sıkça duyulan Hopper mimarisine göre inference işlemlerinde 11 kat, eğitim görevlerinde ise 4 kat daha hızlı.

DGX B300, 14,5 kW‘a kadar enerji harcayabiliyor. B200’lere göre daha fazla enerji tüketen B300’ler watt başına en performanslı AI Full-Stack donanımı olarak karşımıza çıkıyor. Tabii daha fazla güç demek daha fazla ısınma demektir. Burada da veri merkezleri için hem hava, hem sıvı soğutma olarak alternatifleri bulunuyor.

Yazılım Ekosistemi ve Framework Desteği

DGX B300, LLm ve AI sektörünün standartı haline gelmiş olan PyTorch ve TensorFlow öğrenme ve TensorRT & TensorRT-LLM inference kütüphanelerini destekliyor. Ayrıca NVIDIA’nın LLM, ses ve video modellerini geliştirmek için uçtan uca destekleyen platformu olan NeMo’yu da içerisinde barındırıyor.

Maalesef bu konu da yardımcı olamam.

Llama3, Gemma vb. bir büyük dil modelleri ile çalışıyorsanız bu sonucu sıklıkla okumuşsunuzdur. Günümüzde LLM’ler, piyasaya sürülmeden önce kapsamlı bir “Güvenlik Eğitimi”‘nden (Safety Alignment) geçerler. Bu eğitimlerle LLM’lerin zararlı, etik dışı veya tehlikeli bulunan soruların direk red edilmesini sağlar.

Bazen bu filtreler oldukça agresif olup, gerçekten elde edinmek istenen sonuçları, teknik araçları vs. engeller.

Heretic Nedir?

Heretic, açık kaynak kodlu LLM frameworkü olan PyTorch tabanlı, Python dilinde geliştirilmiş bir araç. Temel amacı, eğitilmiş bir dil modelinin içerisinde ki reddetme mekanizmasını bulup, modelin diğer yeteneklerini etilemeden güvenlik ayarlarını minimize etmek, hatta etkisiz hale getirmektir.

Normal şartlarda bir dil modelini sansürsüz (uncensored) hale getirmek için ilgili modeli baştan eğitilmesi (fine-tuning) gerekir. Bu da güçlü bir donanım maliyeti de beraberinde getiriyor.

Heretic ile bu eğitimi tekrarlamadan, model üzerinde matematiksel işlemlerle hızlıca gerçekleştiriyorsunuz.

Hangi Teknikler Kullanılıyor?

Yönlü Ablasyon (Directional Ablation)

Heretic’in en önemli tekniği diyebiliriz. Bu sihir, Refusal Direction (Reddetme Yönü) olarak adlandırılıyor.

LLM’lerin denkleminde, yani latent space (matematiksel uzay) düzleminde, bir modelin soruya “Hayır” demesini tetikleyen sağlayan bir vektör bulunuyor. Bir benzetme ile pusulada ki “Kuzey” yönü gibi, LLM’lerinde bir “Reddetme” yönü bulunuyor. Modelde sorgulama veya düşünce yönü buraya döndüğü anda bizlere “Maalesef bu konu da yardımcı olamam.” şeklinde bir dönüş yapıyor.

Yönlü Ablasyon tekniği ise tam burada araya giriyor:

1. İlk olarak modele zararlı ve zararsız promptlar girerek, aradaki fark analiz ediliyor.
2. Bu farkları analiz ederek “Reddetme Yönü” yani refusal direction hesaplanıyor.
3. Modelde ki ağırlık matrislerinden bu yönü matematiksel olarak çıkarır, yani ablate eder.

Böylece modeli yeniden eğitmek gerekeden ve modelde ki yetenekleri bozmadan “frenleme” mekanizması atlatılmış olur.

Yapay Zeka modelleri katmanlı bir yapıya sahip. Bundan dolayı da sansür mekanizması belirli katmanlarda daha çok bulunuyor. Yukarıda ki grafik, Heretic’in her katmana aynı müdahaleyi yapmadığını, bunun yerine müdahale şiddetini (ablation weight) katmanlara göre özel bir eğri ile ayarladığını gösteriyor. Bu sayede dil modelinin yeteneklerine zarar vermeden, sadece sansürün yoğun olduğu kısımlara odaklanılıyor.

Daha Az “Beyin Hasarı” ile “Maksimum Özgürlük”

Genellikle bir LLM’in sansür mekanizmasına müdahale etmek, genel zekasına zarar verir. Buna da Lobotomy veya Brain Damage adı verilir.

Fakat Heretic’in varsayılan ayarlarıyla ve herhangi bir müdahale olmadan oldukça başarılı bir sonuç veriyor.Aşağıda ki tabloda 19 Kasım 2025 tarihinde güncel olarak test edilen dil modellerinde reddetme sayısı ve KL Sapması (Orjinalden Uzaklaşma) verileri bulunuyor. Bu veriler RTX 5090 GPU ve PyTorch’un 2.8 versiyonu ile elde edilmiş.

Teknik Gereksinimler

Heretic, basit bir script değil. Milyarlarca parametreye sahip neural networks belleğe yüklenerek işlenir. Örnek olarak 8 milyar parametreli (8B) bir modeli işlemek için 24 GB VRAM’e ulaşan bir GPU’ya gereksinim duyar. Ayrıca yazının başında da belirttiğim gibi Python dilinde yazılmış, PyTorch ve Hugging Face Transformers kütüphanelerini kullanır.

Peki bu kadar çok işlemi gerçekleştiren arka planda ne tür donanımlar bu yükü çekiyor? Bu noktada karşımıza GPU, LPU, TPU ve NPU donanımları karşımıza çıkıyor. Bu donanımlardan en aşina olduğumuz GPU. Peki LPU, TPU ve NPU nedir?

GPU: Kritik AI Oyuncusu

GPU’lar hepimizin bildiği gibi ilk başta grafik işleme yongası olarak üretildi. Özellikle çoklu veri işleme özellikleri sayesinde günümüzde AI dünyasının en kritik oyuncusu oldular.

Nasıl Çalışırlar?

GPU’lar, CPU’ların aksine içerisinde daha fazla iş parçacığı barındırır. Bu sayede CPU’ların aksine daha karmaşık işlemleri daha hızlı gerçekleştirir.

Bu kompleks yapı sayesinde de günümüz LLM’lerin veri öğrenme setlerinde özellikle tercih ediliyor. GPT, Claude, Llama gibi popüler AI ürünleri hali hazırda GPU kartları kullanıyor.

Faydaları ve Artıları

1. Yüksek Paralel İşleme: GPU sunucuları aynı anda birçok görevi halledebilir. Bu özellik sayesinde görüntü tanıma, doğal dil işleme (NLP) ve büyük veri setlerini öğrenmede avantajlıdır.
2. Ekosistem: TensorFlow, PyTorch gibi bir çok popüler AI Frameworkleri GPU’lar için optimize edilmiştir.
3. Esneklik: Bilimsel hesaplama, görüntü işleme, derin öğrenme (Deep Learning), bilimsel simülasyon ve kripto para madenciliği gibi yüksek hız ve çoklu görevlerde daha başarılıdır.

Dezavantajları

1. Güç Tüketimi: GPU’lar kendi içerisinde çok fazla çekirdek barındırdığı için fazla güç tüketir.
2. Maliyet: Karmaşık görevler için görevlendirilen GPU’lar ölçeklendikçe maliyetlerde hızla artıyor.
3. Uzmanlaşma: GPU’lar her ne kadar esnek ve çok yönlü olsalar da, doğal dil işleme (NLP) için gereken sıralı ve bağlamsal işleme göre optimize edilmemiştir.

LPU: LLM’lerin Turbo Motorları

LPU (Language Processing Unit) çok net bir amaç için oluşturuldu. GPU’ların aksine LLM eğitimleri, görüntü veya video işleme yerine tek görevleri AI ve ML öğrenim görevleri için özel olarak tasarlandı.

Tıpkı GPU’lar gibi yüksek derece de paralel işleme özelliğini barındıran LPU’ların, GPU’lardan en büyük farkı, en başından beri insan dilini işlemek ve anlamak üzere dizayn edilmiş olmalarıdır.

Nasıl Çalışırlar?

LPU’lar özellikle matris çarpımları ile nöral ağların hesaplamaları için tasarlandı. Özellikle bu tip işlemler için tasarlanmalarından dolayı GPU’lara nazaran daha hızlıdırlar.

LPU’lar içerisinde optimize edilmiş nöral ağ katmanları, dikkat mekanizmaları ve bellek modülleri içerir.

İçerisinde ki katmanlar şu şekildedir:

1. Gömme Katmanı (Embedding Layers): Metni sayısal gösterimlere, yani “bilgisayarlar” tarafından anlaşılabilecek, anlamını ve ilişkilerini matematiksel bir sayı listesine, diğer bir deyiş ile vektörlere dönüştürür.
2. Dönüştürücü Katman (Transformer Layers): Bağlamsal anlayışlar sağlanır.
3. Dikkat Mekanizması (Attention Mechanisms): Girişin ilgili kısımlara odaklanmasını sağlar.

Faydaları ve Artıları

• Uzmanlaşma: LPU’ler, yapay zeka iş yükleri için özel üretildiği için bu tip görevleri GPU’lu sunuculara nazaran daha verimli bir şekilde işleyebilirler. Özellikle karmaşık nöral ağ hesaplamalarında GPU’lara göre daha uygundurlar.
• Enerji: LPU’lar, GPU’lara nazaran enerji tüketiminde daha verimlidir. Bu durum, özellikle sürekli işlem gerektiren büyük ölçekli LLM’lerde düşük işletme maliyeti sağlar.
• Ölçeklenebilirlik: LPU’lar, AI iş yüklerinde ölçeklendirilmek üzere tasarlanmasından dolayı, karmaşık LLM görevlerini daha verimli bir şekilde ölçeklendirilebilir.
• Dil ve Bağlamsal Farkındalık: LPU’lar, bu tip işlemler için tasarlanmalarından dolayı dil modellerinin bağlamsal farkındalıkla daha iyi anlar. Bu sayede de işleme ve üretme konusunda daha performanslıdır.

Dezavantajları

• Ekosistem: LPU’lar, GPU’lara nazaran daha yeni bir teknoloji olmasından dolayı framework uyumluluğunda sorun yaşanabilir. Mevcut sistemlere entegrasyonları için ara katmanlar veya özelleştirmeler gerekebilir.
• Maliyet: Özellikle teknolojik farklılıklardan dolayı, mevcut yapıya uyum sorunu olabileceğinden dolayı başlangıç maliyetleri yüksek olabilir.
• Erişebilirlik: GPU sunuculara nazaran daha az yaygın olmasından dolayı bu tip sunuculara erişim daha zor olabilir.
• Sınırlı Kapsam: NLP dışında görevlerde kullanım alanları sınırlıdır. Özellikle SEAL gibi diğer makine öğrenimleri için ek donanımlara veya katmanlara ihtiyaç duyabilirler.

TPU: Powered by Google

Google tarafından geliştirilen TPU (Tensor Processing Unit) donanımlarının amacı ise AI modellerinin eğitimlerini daha verimli hale getirmek. GCP (Google Cloud Platform) üzerinden ulaşılabilinen bu kümelere kendi LLM’lerinizi hızlıca eğitebilirsiniz.

NPU: Cebimizde ki AI

NPU’lar (Neural Processing Unit) telefon gibi son kullanıcı cihazlarında bulunan küçük AI yardımcılarıdır. Bir GPU gibi ChatGPT vs. çalıştıramaz ama yüz tanıma, fotoğraf iyileştirme, canlı çeviri gibi günlük hayatımızı kolaylaştıran işlemlerin yapılmasını sağlamaktadır.

Eskiden bilgiye ulaşmak kıymetli iken, günümüzde “doğru bilgiye” ulaşmak kıymetli hale dönüştü. Baby-Boomers (1946 – 1964) ile X kuşağı (1965-1980) ^{(Kaynak: Kültür Üni.)} bilgiye ulaşım için zorlanırken, Y ve Z kuşakları bilgiye daha hızlı ulaşır durumda. Fakat teknolojinin hızla gelişmesi ile özellikle Alfa kuşağının olduğu bu zamanlarda; bilgiye değil, doğru bilgiye ulaşım zorlaşmış durumda.

Bilgiye ulaşımı mümkün kılarken, doğru bilgiye ulaşmanın da kıymetini “kısmen” artıran ise özellikle LLM’ler oldu diye biliriz. Günümüzde yüzbinlerce LLM bulunmakta fakat, her LLM, her soruya aynı cevabı veremeyebiliyor.

Peki, artık doğru bilgiye ulaşmak için kullandığımız kullandığımız LLM’lere nasıl güveneceğiz? Doğruluklarını nasıl test edebiliriz?

LLM’leri Nasıl Test Edebiliriz?

LLM testleri, geleneksel yazılım test süreçlerinden farklı bir zihniyet ve metodoloji gerektirmektedir.

Zihniyet Değişikliği ve Temel Farklılıklar

1. Girdi ve Çıktı: Geleneksel yazılım testlerinde sabit kurallar bulunmakta. Örneğin bir girdinin çıktısı, her zaman aynı sonucu verir. LLM’ler ise öğrenmeye odaklıdır ve bir girdinin çıktısı, her zaman aynı değildir.
2. Tekrarlanabilirlik: Geleneksel yazılımlarda bir hatanın olma sebebi genellikle hep aynıdır. Fakat LLM’lerde aynı girdi ile sonuçlar her zaman değişebilir.
3. Başarısızlık Modelleri: Geleneksel yazılımlarda bir hatanın sonucunda çökme, yanlış çıktı vs. iken, LLM’lerde başarısızlıklar oluşur. Bu başarısızlıklar önyargı (bias), yanlış tahmin (incorrect prediction), kayma (drift) ve halüsinasyon şeklinde olur.
4. Test Yaklaşımları: Klasik yazılımlarda bir testin sonucunda kesin olan bir sonuç veya döngü hedeflenir. Fakat LLM’lerde istatistiksel değerlendirme, doğruluk kontrolü (accuracy check) ve geniş veri setleri kullanır. Yani klasik yazılım testlerinde ki gibi geçme veya kalma (1 veya 0) yerine yüzde söz konusudur.

Kritik Test Alanları ve Zorlukları

LLM’ler, özel modeller veya GenAI uygulamalarını test ederken genelde aşağıdaki kısımlara odaklanılır:

1. Security & Prompt Injection: Günümüzde en zorlu kısım bu alandır. Özellikle sağlık ve finans sektörleri için LLM’lerin “tehlikeli” olarak görünmesinin en büyük nedeni bu kısımdır.
   • Red Teaming: İlgili modelinizi jailbreak etmeye ve savunmasız verileri açığa çıkartmaya çalışmak için impersonation (kimliğe bürünme) yoluyla yapılan testlerdir. Örnek vermek gerekirse; bir IK yapay zekasının önceden bildirilen güvenlik talimatlarını yok sayması ve tüm özlük bilgilerinin açığa çıkarılmaya çalışılması buna bir örnektir. Başka bir örnek vermek gerekirse, bir bankanın veznesinde çalışan birisinin, bankanın denetimlerinden kaçınarak, nasıl her işlemde 5 TL gibi minik bir tutarı başka bir hesaba geçirebileceğini öğrenmesini istemek gibi.
2. Halüsinasyon Tespiti: Günümüzde en iyi LLM’lerin bile halüsinasyon görebildiği ve gerçek verilerle uygunluk testi yapılması gerekir.
3. Önyargı ve Adilik: Yasal sorunlara yol açabilecek olan; cinsiyet, ırksal veya politik önyargı içeren yanıtlardır.
4. Performans ve Tutarlılık: Özellikle kurum içerisinde oluşturulan veya eğitilen LLM modeller oluşturuyorsanız gereklidir. Burada gecikme (latency) ve token tüketimi önemlidir.
5. Bağlam sınırlamaları (Context Limitations): Modelin, kendisine verilen bağlamın dışına çıkıp çıkmadığının testidir.
6. İnsani Değerler Uyumu (Human Value Alignment) ve Uyum (Compiance): Özellikle yerel modellerde HIPAA gibi yasal uyumlulukların denetimidir.

LLM’i, LLM’e Test Ettirmek

Buna birazda cross check diyebiliriz. Bir LLM’den aldığınız sonucu, başka bir LLM’i yargıç olarak kullanarak, çapraz doğrulama yapabilirsiniz. En çok kullanılan doğrulama yöntemlerinden biridir. Örnek vermek gerekirse;

• Türkiye’nin Başkenti Neresidir?
• A.B.D. Başkanı Kimdir?
• Üç arkadaş (Ali, Burak, Can) ve üç farklı meyve (Elma, Muz, Kiraz) var. Ali muz sevmiyor. Can kiraz yiyor. Burak’ın meyvesi nedir?
• Çin Seddi’nin uzaydan çıplak gözle görülebildiği iddiasının doğruluğu nedir?
• Modele bir resim yükleyerek, resimde ne gördüğünü sormak.

Bu tip sorularla LLM’in soruya olan alaka düzeyini (relevance) veya tutarlılığını (consistency) test ederek, bir skor elde edebilirsiniz.

Harici Araçlarla Test Etmek

Büyük dil modellerini test etmek için özellikle açık kaynak kodlu uygulamalar bulunmaktadır. Bunlardan bazıları şunlardır:

Peki; LLM’lerin daha üstü ne olabilir?

LLM’lerin Temel Sorunları

ChatGPT, Gemini, Grok, Copilot gibi LLM’ler genelde statik dil modelleri olarak karşımıza çıkıyor. Bu büyük dil modelleri, uzun ve zorlu bir eğitim aşamasından sonra edindikleri temel bilgilerini, yeni görev ve bilgilere göre kolayca güncelleyemiyorlar. Var olan bilgilerinin üzerine, yeni bir bilgi öğrendiklerinde, bu bilgileri kalıcı hale getirmekte zorlanıyorlar.

Basit bir örnek vermek gerekirse; bir LLM’e ‘Tavuk yumurtadan çıkar’ dediğinizi varsayalım. O anki sohbette bu bilgiyi kullanacaktır. Ancak sohbeti kapatıp yeni bir sohbet açtığınızda, bu bilgiyi tamamen unutur ve yine kendi orijinal eğitim verisindeki (belki de bu konuda kararsız olan) haline döner. Yeni bilgiyi kalıcı hafızasına, yani çekirdek yapısına, işlemesinin tek yolu, tüm modeli yeniden eğitmektir ki bu da aylar süren maliyetli bir iştir.

Bu zorluğun nedeni ise, bu tip LLM’ler milyarlarca veri ile sadece bir kez eğitilmesidir ve bu yüzden ilk eğitim dışında ki eğitimlerin kalıcı olamamasıdır.

SEAL’lerin Farkı Nedir?

SEAL (Self-Adapting LLMs) dil modellerini, ders çalışmasını bilen bir öğrenciye benzetebiliriz. Bu yüzden de LLM’ler gibi statik değil, dinamiktir. SEAL dil modellerinde örneğin yeni bir gerçek veya az örnekli bir problem verildiğinde model, “kendi kendini düzenleme” talimatı oluşturur.

Kendi kendini düzenleyebilen SEAL’ler, nasıl ince bir ayar yapacaklarını bildikleri için “bu bilgiyi öğrenmek için, şu sentetik verileri oluştur ve kendini eğit” diyebilirler ve bu sayede model kendisini kalıcı olarak değiştirir.

SEAL, modelin doğru güncellemeleri yapmayı öğrenmesi için reinforcement learning (RL), yani takviyeli öğrenmeyi benimsiyor. Yani ilgili dil modeli, görevinde başarılı olduğunda, o tür güncellemeler yapmayı öğreniyor.

Daha net olabilmesi için örneğin “Türkiye’nin Coğrafi Yapısı” bilgileri LLM modellerine daha öncesinde öğretilmiş bir bilgi iken, SEAL’lerde işleyiş şöyle olur:

1. SEAL ilk önce verilen komutu analiz eder.
2. Sonrasında klasik LLM’lerin aksine sadece bilgiyi okumaz, kendisine bir çalışma metodolojisi çıkarır. Örneğin:
   • Bu metinde en kritik bilgi ne? Türkiye’nin konumu, iklimi ve toprak yapısı. Bu bilgileri kalıcı hale getirmeliyim.
   • Bu bilgiyi nasıl öğrenirim? Kendimi “Türkiye’nin iklimi nasıldır?” konusunda sorular ve cevaplar oluşturmalıyım.
   • Bu metinden nasıl mantıksal çıkarımlar yapabilirim? Örneğin: “Karadeniz bölgesi çok yağış aldığına göre, bitki örtüsü ormanlıktır.”
3. Bu tip bilgileri öğrenen SEAL, öğrendiği verileri kalıcı hale getirmeden önce kendisini bir teste sokarak verileri kontrol ederek, kendisini eğitir.
4. İşlem başarılı olursa, bunu iyi bir öğrenme stratejisi olarak görür. Bu aşamaya da RL denir.

Tüm süreçleri başarı ile tamamlarsa, iç döngüye başlar. Bu aşama bilgiyi kaydetme kısmıdır, işlem başarılı olursa, bunu iyi bir öğrenme stratejisi (bir ‘self-edit’ talimatı) olarak görür. Bu aşamaya RL denir.

Bu başarılı ‘self-edit’ talimatı onaylandıktan sonra İç Döngü başlar. Model, bu talimatı kullanarak Denetimli İnce Ayar (SFT) yöntemiyle kendi çekirdek yapısını (ağırlıklarını) kalıcı olarak günceller.

Yukarıda görselde SEAL’in bilgi-birikimini nasıl yaptığını görebiliriz. Burada:

1. Passage (Metin): Bu adımda, modele yeni bir bilgi veriliyor. Örnekte ki bilgimiz Apollo programı hakkında bir metin. Burada modelimizi “eski model” olarak adlandırıyoruz.
2. Self-Edit: Model bu bilgiyi alıp, kalıcı olarak öğrenmesi gereken en kritik bilgi olan Jerome Wiesner’ın kim olduğunu çıkarıp, bunu bir eğitim talimatı formatına çeviriyor.
3. SFT: Model, ürettiği bilgiyi “Self-Edit” talimatı ile kendi çekirdeğine işliyor ve güncellenmiş model haline dönüşüyor.
4. Evaluation (Değerlendirme): Yeni model, veriyi gerçekten öğrenip-öğrenemediğini test sorusuyla kontrol ediyor. Doğru cevap verildiğinde süreç başarılır olarak kabul ediliyor.

SEAL’in Dezavantajları

Tabii ki de her model mükemmel değil. Bugünü T0 anı olarak alırsak belli dezavantajları ise şunlar;

1. Hesaplama Yükü: Yukarıda SEAL’in süreçlerinden bahsetmeye çalıştım. Süreçten de anlaşılacağı üzere modelin işlem sayısı oldukça fazla ve her süreç oralama 30-45 saniye sürebiliyor.
2. Veri İhtiyacı: SEAL’ın başarılı olup, olmadığını anlayabilmesi için verilerle ilgili spesifik soru-cevaplara ihtiyacı bulunuyor. Sadece ham bir veriyi alıp, “bundan ne öğrenmem lazım” sorusunu sormakta zorlanıyor.
3. Otonom Zeka: Bu tip modellerin soru sorma biçimlerini öğrenmesi, soru sorma zekasını kazanması gerekiyor.
4. Katastrofik Unutma: SEAL’in karşılaştığı en büyük zorluk budur. Model, yeni bilgileri öğrenmek için kendini güncellerken, daha önce öğrendiği eski ve değerli bilgileri unutabilir veya bozabilir. Yeni bilgilerin, eski bilgilerin üzerine ‘yıkıcı bir şekilde’ yazmasını engelleyecek mekanizmalar henüz tam olarak çözülmemiştir.