Büyük Dil Modelleri (LLM - Large Language Models), genel dünya bilgisi ve dil anlama konusunda devrim yaratmış olsa da, kurumsal bir şirketin iç süreçlerine entegre edildiklerinde iki temel engelle karşılaşırlar:
- Halüsinasyon ve Güncellik Eksikliği: LLM'ler yalnızca eğitildikleri tarihe kadar olan genel internet verisini bilirler. Şirketinizin dün güncellenen muhasebe politikalarını, dahili Confluence dokümanlarını veya ERP verilerini bilmezler; bilmedikleri konularda ise inandırıcı fakat tamamen yanlış (halüsinatif) yanıtlar üretebilirler.
- Veri Gizliliği ve Güvenlik (KVKK / GDPR): Şirketinize ait ticari sırları, müşteri sözleşmelerini ve kaynak kodlarını genel bulut API'larına (OpenAI, Anthropic) göndermek ciddi yasal ve regülatif riskler doğurur.
Bu sorunları aşmanın en modern, maliyet etkin ve güvenli yolu RAG (Retrieval-Augmented Generation - Geri Getirme Destekli Üretim) mimarisidir.
Bu rehberde, şirket verilerinizi yapay zekayla konuşturan kurumsal bir RAG sisteminin uçtan uca altyapısını, vektör veritabanlarını, parçalama (chunking) stratejilerini, hibrit aramayı ve şirket içinde (on-premise) yerel LLM kurulumunu inceliyoruz.
[ Kurumsal Dokümanlar ] ──> [ Chunking (512 token) ] ──> [ Embedding Modeli ] ──> [ Vektör DB (Qdrant / pgvector) ]
(PDF, DOCX, SQL, MD) │
▼
[ Kullanıcı Sorusu ] ──> [ Soru Embedding ] ──> [ Hibrit Arama (Dense+BM25) ] ──> [ En Alakalı 3 Parça ]
│
▼
[ Prompt: Soru + Alınan Parçalar ]
│
▼
[ Yerel LLM (Ollama / vLLM) ] ──> [ Doğru & Kaynaklı Yanıt ]
1. RAG vs Fine-Tuning: Neden RAG Tercih Edilmeli?
Birçok kurum yapay zekayı şirket verileriyle eğitmek istediğinde ilk olarak Model Fine-Tuning (İnce Ayar) yapmayı düşünür. Oysa kurumsal bilgi yönetimi için Fine-Tuning çoğu zaman yanlış bir tercihtir:
| Karşılaştırma Kriteri | Model Fine-Tuning | RAG (Retrieval-Augmented Generation) |
|---|---|---|
| Maliyet ve Donanım | Yüksek (A100/H100 GPU kümeleri ve saatler süren eğitim) | Düşük (Tek bir sunucu ve standart vektör veritabanı) |
| Veri Güncelleme Hızı | Çok Yavaş (Her yeni dokümanda modeli yeniden eğitmek gerekir) | Anlık (Yeni PDF/Word yüklendiği saniyede indekslenir) |
| Kaynak Gösterme (Attribution) | İmkansız (Model bilginin nereden geldiğini söyleyemez) | Mükemmel (Cevabın hangi sayfa ve paragraftan alındığını gösterir) |
| Yetkilendirme (RBAC) | Yok (Modeli kullanan herkes eğitildiği tüm veriyi görebilir) | Tam (Metadata filtreleme ile departman bazlı yetki kontrolü) |
| Halüsinasyon Riski | Yüksek | Çok Düşük (Model yalnızca verilen bağlama dayanarak yanıt verir) |
2. Uçtan Uca RAG Pipeline'ı: 6 Kritik Aşama
Başarılı bir RAG mimarisi, gelişigüzel bir LLM çağrısından ibaret değildir. Sistem performansı büyük oranda veri işleme kalitesine bağlıdır.
Aşama 1: Doküman İçe Aktarma ve Temizleme (Ingestion)
Kurumsal veriler heterojendir: Taranmış PDF'ler, Word dosyaları, Excel tabloları, Markdown notları ve SQL veritabanları.
- PDF'lerdeki tablolar ve hiyerarşik başlıklar metne dönüştürülürken yapının bozulmaması için
UnstructuredveyaDoclinggibi gelişmiş ayrıştırıcılar kullanılmalıdır. - Gereksiz HTML etiketleri, boşluklar ve tekrarlayan üst/alt bilgiler (header/footer) temizlenir.
Aşama 2: Parçalama (Chunking) Stratejileri
Bir dokümanı tek parça halinde LLM'e veremezsiniz. Metni anlamlı küçük parçalara (chunk) bölmek gerekir.
- Fixed-Size Chunking (Sabit Boyutlu): Örneğin 512 karakter + 50 karakter bindirme (overlap). Basittir ancak cümle veya paragraf ortasında anlamı bölebilir.
- Recursive Character Chunking (Özyinelemeli): En yaygın kullanılan yöntemdir. Metni sırasıyla paragraflara (
\n\n), cümlelere (.) ve kelimelere göre anlam bütünlüğünü koruyarak böler. - Parent-Document Retrieval (Hiyerarşik): Küçük parçalar (128 token) üzerinde arama yapılır, ancak LLM'e gönderilirken o parçanın ait olduğu büyük paragraf (1024 token) bağlam olarak iletilir. Bu, arama hassasiyetini bağlam zenginliğiyle birleştirir.
# LangChain ile Recursive Character Chunking Örneği
from langchain_text_splitters import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", ". ", " ", ""]
)
chunks = text_splitter.split_text(raw_document_text)
Aşama 3: Embedding (Vektörleştirme)
Her metin parçası, anlamını çok boyutlu bir matematiksel uzayda temsil eden bir sayı dizisine (vektör) dönüştürülür.
- Popüler Açık Kaynak Modeller:
BAAI/bge-m3(Çok dilli, Türkçe başarımı yüksek),nomic-embed-text,multilingual-e5-large.
Aşama 4: Vektör Veritabanı Seçimi (Vector Database)
Vektörleri saklamak ve milyonlarca vektör arasında milisaniyeler içinde en yakın olanları bulmak (Cosine Similarity / Dot Product) için vektör veritabanları kullanılır:
- pgvector (PostgreSQL): Zaten PostgreSQL kullanıyorsanız ek bir veritabanı kurmadan ACID uyumlu vektör desteği sağlar.
- Qdrant: Rust ile yazılmış, son derece hızlı, gelişmiş metadata filtreleme yeteneğine sahip modern vektör motoru.
- Milvus: Milyarlarca vektörlük büyük ölçekli kurumsal veri kümeleri için dağıtık sistem.
- Chroma: Küçük ölçekli ve hızlı prototipler için hafif yerel çözüm.
-- PostgreSQL üzerinde pgvector ile HNSW indeksi oluşturma
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE corporate_knowledge (
id BIGSERIAL PRIMARY KEY,
document_name VARCHAR(255),
department VARCHAR(50),
content TEXT,
embedding VECTOR(1024) -- BGE-M3 1024 boyutlu vektör
);
-- HNSW Cosine Similarity İndeksi
CREATE INDEX ON corporate_knowledge USING hnsw (embedding vector_cosine_ops);
Aşama 5: Hibrit Arama (Hybrid Search: Dense + Sparse / BM25) ve Reranking
Yalnızca vektör benzerliği (Dense Retrieval) kullanmak bazen hata yaptırır. Örneğin bir hata kodu (ERR_AUTH_0x847) veya spesifik bir ürün kodu aratıldığında, vektör modeli anlamsal benzerlik ararken tam eşleşmeyi kaçırabilir.
Hibrit Arama, iki yöntemi birleştirir:
- Dense Retrieval (Vektör / Anlamsal): "Şirket içi yıllık izin hak edişleri" gibi kavramsal aramaları yakalar.
- Sparse Retrieval (BM25 / Keyword): "Sunucu IP 10.10.20.15" veya "Sözleşme No 2026-A" gibi tam kelime eşleşmelerini yakalar.
Arama sonuçları birleştirildikten sonra bir Reranker (Yeniden Sıralayıcı - örn: BGE-Reranker-Large) modeli en alakalı ilk 3-5 parçayı seçerek LLM'e iletir.
Aşama 6: LLM Enjeksiyonu ve Doğru Yanıt Üretimi
Toplanan en alakalı parçalar, katı bir sistem talimatıyla (System Prompt) LLM'e sunulur:
[SİSTEM TALİMATI]
Sen şirketin iç bilgi asistanısın. YALNIZCA sana verilen [BAĞLAM] metinlerine dayanarak yanıt ver.
Eğer verilen bağlamda sorunun cevabı yoksa, "Verilen şirket dokümanlarında bu bilgi bulunmamaktadır" de ve asla tahmin yürütme.
Kullandığın bilginin kaynağını (Doküman adı ve sayfa no) mutlaka belirt.
[BAĞLAM]
{retrieved_chunks}
[KULLANICI SORUSU]
{user_query}
3. Kurumsal RAG'da Güvenlik: Rol Tabanlı Erişim (RBAC)
Bir şirketteki stajyer ile finans direktörü aynı RAG asistanını kullandığında, stajyerin maaş bordrolarını veya gizli yönetim kurulu kararlarını sorgulayamaması gerekir.
Bunu sağlamanın yolu Metadata Payload Filtering yöntemidir.
Dokümanlar vektör veritabanına indekslenirken, Active Directory / LDAP üzerindeki erişim izinleri her parçaya etiket olarak eklenir:
{
"chunk_id": "doc_hr_492_p3",
"department": "Finance",
"min_clearance_level": 3,
"allowed_groups": ["Finance-Managers", "Executive-Board"],
"content": "2026 yılı yönetim kurulu prim ve bütçe planlaması..."
}
Kullanıcı arama yaptığında, kimlik doğrulama katmanından gelen grup bilgisi sorguya zorunlu filtre olarak enjekte edilir:
# Qdrant üzerinde kullanıcı yetkisine göre filtreli arama
results = qdrant_client.search(
collection_name="corporate_docs",
query_vector=query_embedding,
query_filter=Filter(
must=[
FieldCondition(
key="allowed_groups",
match=MatchAny(any=user_active_directory_groups)
)
]
),
limit=5
)
Bu sayede yetkisiz kullanıcılar sorgu atsa dahi vektör veritabanı seviyesinde o parçalar hiç getirilmez; veri sızıntısı riski sıfırlanır.
4. On-Premise (Yerel) RAG Altyapı Kurulumu
Dışarıya tek bir bayt dahi veri sızdırmayan, tamamen şirket iç ağındaki Linux sunucularda çalışan bir RAG altyapısı aşağıdaki bileşenlerle kurulabilir:
┌─────────────────────────────────────────────────────────────┐
│ KURUMSAL İÇ SUNUCU (Ubuntu Linux + GPU) │
│ │
│ [ Web Arayüzü: Open-WebUI ] │
│ │ │
│ [ RAG Orkestrasyonu: LangChain / LlamaIndex / Python API ] │
│ ├──> [ Vektör DB: Qdrant / pgvector Docker ] │
│ ├──> [ Embedding: bge-m3 (Yerel TEI / Ollama) ] │
│ └──> [ LLM Çıkarım Motoru: vLLM / Ollama ] │
│ (Model: Llama-3.3-70B-Instruct veya DeepSeek) │
└─────────────────────────────────────────────────────────────┘
Docker Compose ile Hızlı Altyapı
Aşağıdaki docker-compose.yml ile yerel Qdrant vektör veritabanını ve Ollama yerel model sunucusunu dakikalar içinde ayağa kaldırabilirsiniz:
version: '3.8'
services:
qdrant:
image: qdrant/qdrant:latest
container_name: qdrant_vector_db
ports:
- "6333:6333"
- "6334:6334"
volumes:
- ./qdrant_data:/qdrant/storage
restart: always
ollama:
image: ollama/ollama:latest
container_name: ollama_llm_engine
ports:
- "11434:11434"
volumes:
- ./ollama_models:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
restart: always
# Servisleri başlatma ve yerel modelleri indirme
docker compose up -d
# Türkçe başarımı yüksek Llama 3 modelini ve embedding modelini çekme
docker exec -it ollama_llm_engine ollama run llama3.3
docker exec -it ollama_llm_engine ollama pull nomic-embed-text
5. RAG Mimarisinde Sık Yapılan 5 Hata
- Aşırı Büyük veya Aşırı Küçük Chunk Boyutu: 100 token'lık parçalar bağlamı kaybeder; 2000 token'lık parçalar ise odaklanmayı dağıtır ve alakasız gürültü içerir. İdeal başlangıç 400–600 token + %10 overlap'tir.
- Sadece Vektör Aramasına Güvenmek: Tam eşleşen kodlar, ürün numaraları ve kısaltmalar için mutlaka BM25 tabanlı anahtar kelime araması (Hybrid Search) eklenmelidir.
- Tabloları Düz Metin Gibi Bölmek: PDF içindeki finansal tablolar rastgele bölündüğünde sütun-satır ilişkisi kopar. Tablolar için Markdown veya HTML formatında özel tablo ayrıştırıcıları kullanılmalıdır.
- Reranker Kullanmamak: Vektör araması ilk 20 sonucu getirebilir, ancak bunların içinden gerçekten en doğru 3 tanesini seçmek için bir Cross-Encoder Reranker modeli şarttır.
- Eski/Silinen Dokümanları Vektör DB'de Bırakmak: Güncellenen dokümanların eski versiyonları vektör veritabanından temizlenmezse, model eski ve çelişkili politikaları yanıt olarak dönebilir.
Sonuç ve Profesyonel Altyapı Desteği
RAG mimarisi; kurumların kendi bilgi birikimini yapay zeka gücüyle birleştiren, veri güvenliğini korurken çalışan verimliliğini katlayan en stratejik kurumsal AI yatırımıdır.
Şirketiniz için yerel (on-premise) RAG mimarisi tasarlamak, Qdrant/PostgreSQL vektör veritabanı kümesi kurmak, GPU sunucu altyapınızı optimize etmek ve Active Directory entegrasyonu sağlamak isterseniz sanallaştırma çözümlerimizi, sistem yönetimi hizmetlerimizi ve siber güvenlik danışmanlığımızı inceleyebilir veya doğrudan benimle iletişime geçebilirsiniz.