Kurumsal LLM & AI Asistan (RAG) Çözümü

Kurumlar artık "ChatGPT benzeri bir asistan istiyoruz ama kendi verimizle, güvenli ve KVKK uyumlu çalışsın" talebiyle geliyor. Buradaki kritik ayrım şu: genel bir sohbet modeli kurumunuzun mevzuatını, prosedürlerini veya müşteri kayıtlarını bilmez ve emin olmadığında uydurur. Bu sayfa, kendi bilgi tabanınıza bağlı, denetlenebilir ve erişim kontrollü bir asistanı planlayan bilgi işlem, veri ve dijital dönüşüm ekipleri için mimariyi, karşılaştırmaları ve şartname maddelerini anlatır.

Çözüm neyi kapsar?

Kurumsal AI asistan bir "kutu ürün" değil, birbirini besleyen bileşenlerden oluşan bir boru hattıdır (pipeline). Uçtan uca kapsam tipik olarak şu adımları içerir:

• Veri alımı ve ayrıştırma: PDF, Office, e-posta, wiki, ticket ve veritabanı kaynaklarının bağlanması ve metne dönüştürülmesi.
• Parçalama ve gömme (embedding): Belgelerin anlamlı parçalara (chunk) bölünüp 768–3072 boyutlu vektörlere çevrilmesi.
• Vektör veritabanı: Bu vektörlerin aranabilir biçimde saklanması (ör. pgvector, Qdrant, Milvus, Weaviate, Elasticsearch).
• Getirim (retrieval): Kullanıcı sorusuna en yakın pasajların semantik + anahtar kelime (hybrid) aramayla bulunması.
• Üretim ve atıf: LLM'in yanıtı yalnızca getirilen pasajlara dayandırması ve kaynak göstermesi.
• Güvenlik katmanı: Erişim kontrolü, prompt injection koruması, çıktı denetimi ve loglama.
• Gözlemlenebilirlik: Kalite metrikleri, geri bildirim döngüsü ve kullanım analitiği.

RAG mimarisi nasıl çalışır?

RAG (Retrieval-Augmented Generation), modeli yeniden eğitmeden ona "sınav öncesi açık kitap" verir: soru geldiğinde önce bilgi tabanından ilgili pasajlar getirilir, sonra model yanıtı bu pasajlara dayanarak yazar. Pratikte kalite üç ayara bağlıdır: parça boyutu (genelde 300–800 token), örtüşme (%10–20 overlap) ve getirilen pasaj sayısı (top-k 4–8). Maliyet planlaması için kaba bir formül:

Aylık token hacmi ≈ (sorgu/ay) × (ortalama girdi token + çıktı token). Örnek: 20.000 sorgu/ay × 2.000 token ≈ 40M token/ay. Ticari API'de maliyet token başına fiyatla, kurum içi açık kaynak modelde ise GPU ve altyapı kapasitesiyle ölçeklenir; hacim büyüdükçe kendi kendine barındırma (self-hosting) ekonomik hâle gelebilir. Detaylı hesaplama için on-premise LLM kurulum maliyeti yazımıza bakabilirsiniz.

RAG mı, fine-tuning mi? Referans karşılaştırma

En sık sorulan mimari kararı budur. Aşağıdaki tablo iki yaklaşımı kurumsal ihtiyaç boyutlarına göre kıyaslar; çoğu senaryoda doğru cevap "RAG omurga, gerekiyorsa fine-tuning ile ton/biçim düzeltmesi" şeklinde bir melez kurgudur.

Kurulum modeli: on-premise, özel bulut, SaaS

Veri egemenliği ve KVKK, model seçiminden önce kurulum modelini belirler. Kamu ve regülasyona tabi kurumlar için verinin nerede durduğu tek başına bir şartname maddesidir.

Halüsinasyon, güvenlik ve erişim kontrolü

Kurumsal bir asistanın en büyük iki riski yanlış bilgi üretmesi ve yetkisiz veriyi ifşa etmesidir. Halüsinasyona karşı yanıtı yalnızca getirilen kaynaklara dayandırır, atıf zorunlu kılar ve bağlamda cevap yoksa modeli "bilmiyorum" demeye programlarız. Güvenlik tarafında ise LLM entegrasyonunun kendine özgü tehditleri vardır: OWASP Top 10 for LLM Applications listesinde ilk sırada prompt injection yer alır; hassas veri sızıntısı, aşırı yetki (excessive agency) ve zehirlenmiş veri (data poisoning) diğer başlıklardır. Bu tehditleri MITRE ATLAS saldırı matrisiyle haritalar, erişim kontrolünü retrieval katmanına taşırız (permission-aware retrieval).

Teknik şartnamede dikkat edilecekler

• Standartlar: ISO/IEC 42001 (yapay zeka yönetim sistemi), NIST AI RMF, OWASP LLM Top 10, ISO 27001 ve KVKK uyumu talep edilmeli.
• Veri sahipliği ve dışa aktarım: Bilgi tabanı, gömme (embedding) ve konuşma kayıtları kuruma ait olmalı; vektör indeksinin ve verinin standart formatta dışa aktarılabilmesi (lock-in önlemi) şart koşulmalı.
• Model bağımsızlığı: LLM'in değiştirilebilir olması (model-agnostic mimari) rekabeti korur ve tedarikçiye bağımlılığı kırar.
• Entegrasyon: Kaynak sistemlere konnektörler (AD/LDAP, SSO, SharePoint, ticket, DB) ve açık API zorunlu olmalı.
• SLA: Çalışma süresi (uptime) hedefi, yanıt gecikmesi (p95 latency), olay çözüm süreleri (MTTR) ve destek modeli tanımlanmalı.
• Değerlendirme: Kabul kriteri olarak groundedness/faithfulness ve doğruluk ölçen bir değerlendirme seti (eval) istenmeli — "çalışıyor gibi görünmek" yeterli değildir.
• Denetlenebilirlik: Her yanıtın kaynağının ve her erişimin loglanması (audit trail) mevzuat için gereklidir.

Seçim kriterleri

• Veri hassasiyeti: Kişisel/gizli veri varsa on-premise veya yerli özel bulut önceliklidir.
• Türkçe kalitesi: Modelin Türkçe anlama ve üretim başarısı ölçülmeli — konuyu Türkçe LLM karşılaştırması yazımızda ele alıyoruz.
• Toplam sahip olma maliyeti (TCO): Lisans/token, GPU, entegrasyon ve bakım birlikte hesaplanmalı.
• Bakım ve güncelleme: Bilgi tabanının kim tarafından, hangi sıklıkta güncelleneceği netleşmeli.
• Ölçeklenebilirlik: Pilot bölümden kurum geneline yayılırken eşzamanlı kullanıcı ve sorgu hacminin karşılanabilmesi.

Kurumunuzun belge kaynaklarını, güvenlik gereksinimlerini ve kullanım senaryolarını birlikte değerlendirip, önce dar kapsamlı bir pilot (örneğin İK veya destek asistanı) ile başlayan bir yol haritası ve şartname taslağı çıkaralım. Aşağıdaki formdan ihtiyacınızı iletmeniz yeterli.