Yerel AI ile Özel Dosyaları Analiz Etme: Gizlilik Odaklı Yaklaşım

Yazar:komut.io ekibi
0 Yorum

Kurumsal ortamlarda çalışan biri olarak şunu net söyleyeyim: şirket içi dokümanları, konfigürasyon dosyalarını veya müşteri verilerini içeren logları bulut tabanlı bir yapay zeka servisine göndermek ciddi bir güvenlik açığıdır. KVKK, GDPR veya sektöre özgü uyumluluk gereksinimlerini bir kenara bırakın, sırf sağduyu açısından bile bu yapılmaması gereken bir şey. Ama öte yandan, LLM’lerin sağladığı verimlilik kazanımlarını da görmezden gelmek mümkün değil. İşte tam bu noktada yerel LLM çalıştırma konsepti devreye giriyor ve Ollama bu iş için şu an mevcut en pratik araç.

Bu yazıda, hassas dosyaları tamamen kendi altyapınızda, internet bağlantısı olmadan analiz etmek için Ollama’yı nasıl kuracağınızı ve kullanacağınızı ele alacağım. Özellikle log analizi, konfigürasyon dosyası incelemesi ve iç dokümantasyon işleme gibi senaryolara odaklanacağız.

Neden Yerel LLM?

Bulut LLM servislerinin veri işleme politikalarına baktığınızda çoğunun model eğitimi için kullanıcı verilerini kullandığını görürsünüz, opt-out mekanizmaları ise çoğu zaman ya karmaşık ya da kurumsal planlara özgüdür. Bir finans firmasının kredi başvuru formlarını, bir hastanenin hasta kayıtlarını veya bir yazılım şirketinin kaynak kodunu bu servislere göndermesi ciddi sorunlar doğurabilir.

Yerel LLM’in avantajları somut olarak şunlar:

  • Veri hiçbir zaman ağdan çıkmaz: Model ve veriler aynı makinede, hatta aynı süreçte çalışır
  • Offline çalışabilirlik: İnternet bağlantısı kesilse de analizler devam eder
  • Denetlenebilirlik: Hangi modelin kullanıldığını, ne zaman güncellendiğini siz kontrol edersiniz
  • Maliyet öngörülebilirliği: API çağrı maliyeti yoktur, donanım sabit maliyettir
  • Uyumluluk: Veri yerelliği gereksinimleri olan sektörlerde (bankacılık, sağlık, kamu) kullanılabilir

Ollama Kurulumu

Linux üzerinde kurulum oldukça basit. Resmi kurulum scripti işi hallediyor ama kurumsal ortamlarda scripti önce indirip incelemenizi öneririm:

# Scripti önce indirip inceleyin
curl -fsSL https://ollama.com/install.sh -o ollama_install.sh
cat ollama_install.sh
# İnceledikten sonra çalıştırın
bash ollama_install.sh

Script, /usr/local/bin/ollama konumuna binary’yi kopyalıyor ve bir systemd servisi oluşturuyor. Kurumsal ortamlarda servisi hemen başlatmak yerine önce konfigürasyonu ayarlamak mantıklı:

# Systemd servis dosyasını düzenle
sudo systemctl edit ollama

# Bu içeriği ekleyin:
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MODELS=/opt/ollama/models"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

OLLAMA_HOST değişkeni ile servisi sadece localhost’a bağlamak önemli. Varsayılan davranış tüm arayüzleri dinlemek, bu da iç ağda bile istenmeyen erişimlere yol açabilir.

# Servisi başlat
sudo systemctl daemon-reload
sudo systemctl enable --now ollama

# Durumu kontrol et
sudo systemctl status ollama
curl http://localhost:11434/api/tags

Model Seçimi: Gizlilik Odaklı İş Yükleri için

Her model her iş için uygun değil. Dosya analizi gibi görevlerde dikkat etmeniz gereken parametreler şunlar:

  • Context window boyutu: Büyük log dosyaları için en az 8K, tercihen 32K token context gerekli
  • Instruction following kalitesi: Yapılandırılmış çıktı üretme yeteneği
  • Türkçe desteği: Türkçe dokümanlar işleyecekseniz bu kritik
  • Donanım gereksinimleri: RAM ve VRAM sınırlamalarınız

Pratik deneyimlerimden yola çıkarak şu modelleri önerebilirim:

  • llama3.1:8b: Genel amaçlı, 8GB VRAM ile çalışır, iyi instruction following
  • mistral:7b: Hızlı, kod ve log analizi için güçlü
  • qwen2.5:14b: Türkçe desteği diğerlerine göre belirgin şekilde daha iyi
  • codellama:13b: Konfigürasyon dosyaları ve kod analizi için optimize
  • phi3:mini: Kaynak kısıtlı ortamlar için, 4GB RAM ile çalışır
# Model indirme (model dosyaları büyük, bant genişliğinizi göz önünde bulundurun)
ollama pull llama3.1:8b
ollama pull qwen2.5:14b

# İndirilen modelleri listele
ollama list

# Model detaylarını görüntüle
ollama show llama3.1:8b

Temel Dosya Analizi: Komut Satırından

Ollama’nın en güçlü yönlerinden biri, pipe ile doğrudan kullanılabilmesi. Basit bir örnek ile başlayalım:

# Bir log dosyasının ilk analizini yap
cat /var/log/syslog | head -100 | ollama run llama3.1:8b 
  "Bu sistem logunu analiz et. Olası hata durumlarını ve dikkat gerektiren kayıtları özetle. Türkçe yanıt ver."

Ama gerçek dünyada bu kadar basit değil. Log dosyaları genellikle model context window’una sığmayacak kadar büyük. Bunun için chunking stratejisi geliştirmemiz gerekiyor:

#!/bin/bash
# log_analyzer.sh - Büyük log dosyalarını parçalara bölerek analiz eder

LOG_FILE="$1"
CHUNK_SIZE=200  # satır bazında chunk boyutu
MODEL="llama3.1:8b"
OUTPUT_FILE="analysis_$(date +%Y%m%d_%H%M%S).txt"

if [ -z "$LOG_FILE" ]; then
    echo "Kullanim: $0 <log_dosyasi>"
    exit 1
fi

total_lines=$(wc -l < "$LOG_FILE")
chunks=$((total_lines / CHUNK_SIZE + 1))

echo "Toplam satir: $total_lines, Parca sayisi: $chunks"
echo "Analiz basliyor..." > "$OUTPUT_FILE"

for ((i=0; i<chunks; i++)); do
    start=$((i * CHUNK_SIZE + 1))
    end=$(((i + 1) * CHUNK_SIZE))
    
    echo "=== Parca $((i+1))/$chunks analiz ediliyor ===" | tee -a "$OUTPUT_FILE"
    
    sed -n "${start},${end}p" "$LOG_FILE" | ollama run "$MODEL" 
        "Asagidaki log parcasini analiz et. Hatalari, uyarilari ve anormal durumları listele. Kisa ve öz yanit ver:" 
        2>/dev/null >> "$OUTPUT_FILE"
    
    echo "" >> "$OUTPUT_FILE"
done

echo "Analiz tamamlandi: $OUTPUT_FILE"

Python ile Daha Güçlü Entegrasyonlar

Bash scriptleri iş görür, ama karmaşık analizler için Python çok daha uygun. Ollama’nın REST API’si ile doğrudan iletişim kurabilirsiniz:

#!/usr/bin/env python3
"""
secure_file_analyzer.py
Hassas dosyaları yerel LLM ile analiz eder.
Hiçbir veri dışarıya çıkmaz.
"""

import requests
import json
import sys
import os
from pathlib import Path

OLLAMA_URL = "http://localhost:11434/api/generate"
MODEL = "llama3.1:8b"
MAX_CHUNK_CHARS = 4000  # karakter bazında güvenli chunk boyutu

def check_ollama_running():
    try:
        resp = requests.get("http://localhost:11434/api/tags", timeout=5)
        return resp.status_code == 200
    except requests.exceptions.ConnectionError:
        return False

def analyze_chunk(text, prompt_template, context=""):
    """Tek bir metin parçasını analiz eder."""
    full_prompt = f"{context}nn{prompt_template}nnMetin:n{text}"
    
    payload = {
        "model": MODEL,
        "prompt": full_prompt,
        "stream": False,
        "options": {
            "temperature": 0.1,  # deterministik çıktı için düşük tutuyoruz
            "num_predict": 500
        }
    }
    
    response = requests.post(OLLAMA_URL, json=payload, timeout=120)
    result = response.json()
    return result.get("response", "")

def analyze_file(filepath, analysis_type="general"):
    """Dosyayı parçalara bölerek analiz eder."""
    
    file_path = Path(filepath)
    if not file_path.exists():
        print(f"Hata: Dosya bulunamadi: {filepath}")
        sys.exit(1)
    
    # Dosya boyutu kontrolü
    file_size = file_path.stat().st_size
    print(f"Dosya: {filepath} ({file_size / 1024:.1f} KB)")
    
    prompts = {
        "log": "Bu log parcasini analiz et. Hata kodlarini, kritik uyarilari ve servis aksakliklarini tespit et. Bulgulari madde madde listele:",
        "config": "Bu konfigürasyon dosyasi parcasini analiz et. Guvenlik aciklari, yanlis yapilandirmalar ve iyilestirme onerilerini belirt:",
        "general": "Bu metin parcasini analiz et. Ana konulari, onemli bilgileri ve dikkat gerektiren noktalari ozet olarak sun:"
    }
    
    prompt = prompts.get(analysis_type, prompts["general"])
    
    with open(filepath, 'r', encoding='utf-8', errors='replace') as f:
        content = f.read()
    
    chunks = [content[i:i+MAX_CHUNK_CHARS] 
              for i in range(0, len(content), MAX_CHUNK_CHARS)]
    
    print(f"Toplam {len(chunks)} parca analiz edilecekn")
    
    results = []
    for idx, chunk in enumerate(chunks, 1):
        print(f"Parca {idx}/{len(chunks)} isleniyor...", end=" ", flush=True)
        result = analyze_chunk(chunk, prompt)
        results.append(f"## Parca {idx} Analizin{result}")
        print("Tamamlandi")
    
    return "nn".join(results)

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("Kullanim: python3 secure_file_analyzer.py <dosya> [log|config|general]")
        sys.exit(1)
    
    if not check_ollama_running():
        print("Hata: Ollama servisi calismıyor. 'systemctl start ollama' ile baslayin.")
        sys.exit(1)
    
    filepath = sys.argv[1]
    analysis_type = sys.argv[2] if len(sys.argv) > 2 else "general"
    
    analysis = analyze_file(filepath, analysis_type)
    
    output_file = f"analysis_{Path(filepath).stem}.md"
    with open(output_file, 'w', encoding='utf-8') as f:
        f.write(f"# {filepath} Analiz Raporunn")
        f.write(analysis)
    
    print(f"nRapor kaydedildi: {output_file}")

Konfigürasyon Dosyası Güvenlik Denetimi

Gerçek dünyadan bir senaryo: Yüzlerce sunucuda nginx, Apache veya uygulama konfigürasyon dosyaları var, bunları manuel incelemek haftalarca sürer. Yerel LLM ile bu süreci otomatize edebilirsiniz:

#!/bin/bash
# config_security_audit.sh
# Bir dizindeki tüm konfigürasyon dosyalarını güvenlik açısından tarar

CONFIG_DIR="${1:-.}"
MODEL="codellama:13b"
REPORT_FILE="security_audit_$(date +%Y%m%d).md"

echo "# Konfigürasyon Güvenlik Denetimi" > "$REPORT_FILE"
echo "Tarih: $(date)" >> "$REPORT_FILE"
echo "Dizin: $CONFIG_DIR" >> "$REPORT_FILE"
echo "" >> "$REPORT_FILE"

# Yaygın konfigürasyon dosyası uzantıları
find "$CONFIG_DIR" -type f ( 
    -name "*.conf" -o 
    -name "*.cfg" -o 
    -name "*.ini" -o 
    -name "*.yaml" -o 
    -name "*.yml" -o 
    -name "nginx.conf" -o 
    -name "httpd.conf" 
) | while read -r config_file; do
    
    echo "Analiz ediliyor: $config_file"
    echo "## $config_file" >> "$REPORT_FILE"
    
    file_content=$(cat "$config_file" 2>/dev/null | head -300)
    
    echo "$file_content" | ollama run "$MODEL" 
"Bu konfigürasyon dosyasını güvenlik açısından denetle. Şunlara odaklan:
1. Açık metin parolalar veya API anahtarları
2. Gereksiz geniş izinler (777, world-readable hassas dosyalar)
3. Debug modunun production'da açık olması
4. Güvensiz protokol kullanımı (HTTP, telnet, vs)
5. Eksik SSL/TLS yapılandırması
6. Varsayılan kimlik bilgileri

Bulgular yoksa 'Kritik bulgu yok' yaz. Türkçe yanıt ver." 
        2>/dev/null >> "$REPORT_FILE"
    
    echo "" >> "$REPORT_FILE"
    echo "---" >> "$REPORT_FILE"
done

echo "Denetim tamamlandi. Rapor: $REPORT_FILE"

Modelfile ile Özelleştirilmiş Analizörler

Ollama’nın Modelfile özelliği, belirli görevler için özelleştirilmiş model profilleri oluşturmanıza olanak tanır. Bu özellikle tekrarlayan analizler için işe yarar:

# syslog_analyzer.Modelfile
cat << 'EOF' > syslog_analyzer.Modelfile
FROM llama3.1:8b

SYSTEM """
Sen bir kıdemli Linux sistem yöneticisisin. Sana verilen system log çıktılarını analiz ederek:
1. Kritik hataları (ERROR, CRIT, EMERG seviyesi) önce listele
2. Tekrarlayan hataları tespit et ve frekanslarını belirt
3. Güvenlik ile ilgili olayları (başarısız giriş denemeleri, izin hataları) vurgula
4. Servis çökmelerini ve restart olaylarını işaretle
5. Her bulgu için olası neden ve çözüm önerisi sun

Her zaman Türkçe yanıt ver. Teknik terimleri Türkçe açıklamalarla destekle.
Yanıtlarını markdown formatında, başlıklar ve madde listeleri kullanarak düzenle.
"""

PARAMETER temperature 0.05
PARAMETER num_ctx 8192
PARAMETER num_predict 1000
EOF

# Özelleştirilmiş modeli oluştur
ollama create syslog-analyzer -f syslog_analyzer.Modelfile

# Kullanım
cat /var/log/syslog | tail -500 | ollama run syslog-analyzer

Bu yaklaşımın avantajı, her seferinde uzun prompt yazmak zorunda kalmamanız. syslog-analyzer modelini doğrudan çağırdığınızda sistem promptu otomatik olarak uygulanıyor.

İzolasyon ve Ek Güvenlik Katmanları

Ollama’yı sadece kurmak yeterli değil, onu doğru izole etmek de gerekiyor. Özellikle birden fazla kişinin erişeceği ortamlarda:

# Ayrı bir servis kullanıcısı oluştur
sudo useradd -r -s /sbin/nologin -d /opt/ollama ollama-svc

# Model dizinini bu kullanıcıya ata
sudo mkdir -p /opt/ollama/models
sudo chown -R ollama-svc:ollama-svc /opt/ollama

# Systemd unit'ini güçlendir
sudo systemctl edit ollama --force

# Aşağıdaki içeriği ekleyin:
[Service]
User=ollama-svc
Group=ollama-svc
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/opt/ollama
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MODELS=/opt/ollama/models"

Ağ düzeyinde de önlem alınmalı. Eğer Ollama’ya sadece belirli uygulamalar erişmeli ise:

# Sadece belirli bir süreçten gelen bağlantılara izin ver (iptables örneği)
# Önce tüm 11434 erişimini kapat
sudo iptables -A INPUT -p tcp --dport 11434 -j DROP
# Sadece localhost'tan izin ver
sudo iptables -I INPUT -p tcp --dport 11434 -s 127.0.0.1 -j ACCEPT

# Kalıcı hale getir
sudo apt install iptables-persistent  # Debian/Ubuntu
sudo netfilter-persistent save

Performans Optimizasyonu: GPU’suz Ortamlarda

Pek çok sysadmin, GPU’su olmayan sunucularda bu işi yapmak zorunda kalıyor. CPU ile de çalışabilirsiniz ama beklentileri doğru ayarlamak lazım:

# CPU thread sayısını ayarla (sisteminizdeki çekirdek sayısının 75'ini kullanın)
export OLLAMA_NUM_THREADS=6

# Metal/CUDA olmadan çalışırken daha küçük modeller tercih edin
ollama pull phi3:mini     # ~2GB, CPU'da makul hızda çalışır
ollama pull mistral:7b-q4  # Kuantize edilmiş versiyon, daha az RAM kullanır

# Benchmark yaparak hangi modelin ortamınıza uygun olduğuna karar verin
time echo "Merhaba, bu bir test mesajıdır. Kısa bir yanıt ver." | ollama run phi3:mini
time echo "Merhaba, bu bir test mesajıdır. Kısa bir yanıt ver." | ollama run mistral:7b-q4_0

Kuantize model isimlendirmesini anlamak önemli:

  • q4_0: 4-bit kuantizasyon, en küçük boyut, kalite biraz düşer
  • q4_K_M: 4-bit kuantizasyon, geliştirilmiş yöntem, iyi denge
  • q8_0: 8-bit kuantizasyon, kalite daha iyi, boyut daha büyük
  • fp16: Tam kalite, GPU’da çalışır, en fazla kaynak kullanır

Kısıtlı ortamlarda q4_K_M versiyonları iyi bir denge noktası sunar.

Gerçek Dünya Senaryosu: KVKK Uyumlu Log Analizi

Son olarak, tüm bu parçaları birleştiren bir senaryo çizelim. Diyelim ki bir e-ticaret şirketinin uygulama loglarını analiz etmeniz gerekiyor. Loglarda sipariş numaraları, IP adresleri ve kısmi kart bilgileri olabilir. Bunları bulut servise göndermek mümkün değil:

#!/bin/bash
# kvkk_compliant_log_analysis.sh
# Hassas verileri maskeler, yerel LLM ile analiz eder

INPUT_LOG="$1"
MODEL="llama3.1:8b"
MASKED_LOG="/tmp/masked_$(basename $INPUT_LOG)"
REPORT="report_$(date +%Y%m%d_%H%M%S).txt"

echo "KVKK Uyumlu Log Analizi Baslıyor..."
echo "Gizli veriler maskeleniyor..."

# Hassas verileri maskele
sed 
    -e 's/[0-9]{13,16}/[KART_NO_MASKELENDI]/g' 
    -e 's/b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Z|a-z]{2,}b/[EMAIL_MASKELENDI]/g' 
    -e 's/b([0-9]{1,3}.){3}[0-9]{1,3}b/[IP_MASKELENDI]/g' 
    -e 's/TC:[0-9]{11}/TC:[MASKELENDI]/g' 
    "$INPUT_LOG" > "$MASKED_LOG"

echo "Maskeleme tamamlandi. LLM analizi baslıyor..."

# Maskelenmiş logu analiz et
cat "$MASKED_LOG" | tail -1000 | ollama run "$MODEL" 
"Bu uygulama logunu analiz et:
1. Hata oranlarını hesapla ve değerlendir
2. Anormal trafik paternlerini tespit et
3. Başarısız işlem kümelerini belirle
4. Performans sorunlarına işaret eden kayıtları işaretle
5. Acil müdahale gerektiren durumları öne çıkar

Türkçe, madde listesi formatında özet sun." > "$REPORT"

# Geçici maskelenmiş dosyayı sil
rm -f "$MASKED_LOG"

echo "Analiz tamamlandi. Rapor: $REPORT"
echo "Not: Orijinal log dosyasi ve kisisel veriler hic bir yere gonderilmedi."

Bu script, ham logu önce yerel olarak maskeliyor, sonra maskelenmiş versiyonu analiz ediyor ve geçici dosyayı temizliyor. Veri hiçbir zaman yerel makinenin dışına çıkmıyor.

Sonuç

Yerel LLM kullanımı artık sadece hobi projeleri için değil, kurumsal ortamlarda da ciddi bir alternatif haline geldi. Ollama ile birleştirildiğinde, bulut servislerinin sunduğu analizlerin önemli bir kısmını kendi altyapınızda, veri sızıntısı riski olmadan gerçekleştirebilirsiniz.

Dikkat edilmesi gereken noktaları özetleyecek olursam: Model seçimi iş yüküne göre yapılmalı, büyük dosyalar için mutlaka chunking stratejisi uygulanmalı, Ollama servisi sadece localhost’a bağlanmalı ve Modelfile ile tekrarlayan görevler için özelleştirilmiş profiller oluşturulmalı.

Performans konusunda beklentileri gerçekçi tutmak önemli. CPU ile çalışan küçük bir model, GPT-4 ile rekabet edemez. Ama bir nginx konfigürasyon dosyasındaki güvenlik açığını bulmak veya 500 satırlık bir hata logunu özetlemek için, CPU üzerinde çalışan 7B parametreli bir model fazlasıyla yeterli. Araçları doğru işe koşmak her zaman olduğu gibi burada da temel kural.

Son bir not: Bu araçları üretim ortamına almadan önce mutlaka test edin, model çıktılarını körü körüne güvenerek aksiyon almayın ve analiz sonuçlarını her zaman bir insan gözünden geçirin. LLM’ler halüsinasyon yapabilir, özellikle kısıtlı bağlam penceresinde çalışırken bağlamı yanlış yorumlayabilirler.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir