Yapay zeka destekli bir hukuk platformu kurduğunuzda, kullanıcıların gördüğü sadece arama çubuğu ve sonuçlardır. Ancak o "arama çubuğuna" bir soru yazılıp "Ara" butonuna basıldığı anda, arka planda milyonlarca vektör arasında kosinüs benzerliği hesaplayan, metadata filtreleriyle sonuçları daraltıp en isabetli paragrafları çıkaran karmaşık bir mühendislik mimarisi devreye girer.

Bu yazıda, hiDAVA'nın RAG (Retrieval-Augmented Generation) mimarisini ilk kez açıklıyoruz , hangi mühendislik kararlarını neden aldık, ne kadar verimli çalışıyor ve bu verimliliğin avukatlar için ne anlama geldiğini rakamlarla ortaya koyuyoruz.

RAG Nedir ve Neden Kritik?

RAG (Retrieval-Augmented Generation), bir yapay zeka modelinin cevap üretmeden önce ilgili bilgiyi gerçek bir veritabanından "aramasını" sağlayan mimaridir. Model kendi "hafızasından" cevap uydurmak yerine, önce gerçek kararları bulur, sonra bu kararlar üzerinden analiz yapar.

Bu yaklaşım, hukuk gibi sıfır hata toleransı olan alanlarda hayati önem taşır. Genel amaçlı bir dil modeli "mantıklı görünen" bir Yargıtay esas numarası uydurabilir. Ancak RAG mimarisinde bu imkansızdır , çünkü model yalnızca gerçek veritabanından getirilen, doğrulanmış kararlar üzerinden çalışır.

Embedding: Hukuki Kavramları Matematiğe Çevirmek

RAG mimarisinin kalbi, embedding (gömme) teknolojisidir. Bir hukuk kararının metnini, 3072 boyutlu bir vektöre , yani matematiksel bir "anlam haritasına" , dönüştürüyoruz.

Neden 3072 Boyut?

hiDAVA, Google'ın en gelişmiş embedding modeli olan Gemini Embedding 001 modelini kullanır. Bu modelin ürettiği 3072 boyutlu vektörler, daha düşük boyutlu alternatiflere kıyasla Türkçe hukuk terminolojisindeki ince nüansları çok daha iyi yakalar.

Örneğin, "müterafik kusur" ve "birlikte kusur" kavramları, düşük boyutlu bir modelde birbirinden uzak noktalara düşebilir. 3072 boyutlu uzayda ise bu iki kavram, anlamsal yakınlıklarını koruyarak aynı bölgede konumlanır. Bu fark, bir avukatın "müterafik kusur" aradığında "birlikte kusur" içeren kararları da bulabilmesi anlamına gelir.

Görev Türü Ayrımı: Sessiz Ama Kritik Bir Optimizasyon

Çoğu RAG implementasyonunun kaçırdığı bir teknik detay: Embedding sırasında görev türünü belirtmek.

hiDAVA'da iki farklı görev türü kullanıyoruz:

RETRIEVAL_DOCUMENT: Bir karar metni vektör veritabanına eklenirken, "bu bir belge, aranabilir olsun" diye modele sinyal vermek
RETRIEVAL_QUERY: Bir avukat arama yaptığında, "bu bir soru, en ilgili belgeleri bul" diye modele sinyal vermek

Bu ayrım, arama sonuçlarındaki isabet oranını ciddi ölçüde artırır çünkü model, "sorgulayan" ile "aranan" arasındaki asimetriyi doğru yönetir. Avukatın kısa, soru formatındaki araması ile uzun, paragraf formatındaki karar metni arasındaki köprüyü daha isabetli kurar.

Chunking: Kararları Nasıl Parçalıyoruz?

Bir Yargıtay kararı onlarca sayfa olabilir. Bu kadar uzun bir metni tek bir vektöre dönüştürmek hem teknik olarak verimsiz hem de arama kalitesini düşürür , çünkü çok uzun metinlerde anlam "seyreltilir."

hiDAVA'nın akıllı chunking stratejisi şu parametrelerle çalışır:

Parametre	Değer	Neden?
Maksimum Chunk Boyutu	3000 karakter	Hukuki bir argümanın bağlamını koruyacak kadar uzun, vektör kalitesini düşürmeyecek kadar kısa
Overlap (Örtüşme)	200 karakter	Cümle ortasında bölünmeyi önlemek ve bağlam kaybını sıfıra indirmek
Bölme Noktası	Cümle sınırı	Nokta, ünlem veya soru işareti , asla kelimenin ortasından bölmüyoruz

Bu Neden Önemli?

Overlap stratejisi, RAG sistemlerinin gizli kahramanıdır. Bir karar metni chunk'lara bölünürken, bir önceki chunk'un son 200 karakteri bir sonrakinin başına eklenir. Böylece, chunk sınırına denk gelen bir hukuki argüman "kaybolmaz" , iki chunk'ta da temsil edilir.

Pratik Etki: "failin fiili ile zarar arasındaki illiyet bağı" ifadesi tam bir chunk sınırına denk gelse bile, overlap sayesinde her iki chunk'ta da bu kavram yer alır ve arama sırasında bulunabilir.

Metadata: RAG Sisteminin Beyni

RAG dünyasında yaygın bir yanılgı vardır: "Tüm dokümanları vektör veritabanına at, sistem çalışır." Bu, bir kütüphanedeki tüm kitapları etiket koymadan rastgele bir odaya yığmaktan farksızdır.

hiDAVA'da her chunk'a 6 farklı metadata ekliyoruz:

Metadata	Örnek	Arama Etkisi
Daire	"9. Hukuk Dairesi"	İş hukuku araması yapan avukat, sadece 9. HD kararlarını görebilir
Esas No	"2024/1234"	Bilinen bir kararın tam metnine doğrudan erişim
Karar No	"2024/5678"	Atıf doğrulama ve çapraz referans
Karar Tarihi	"15.03.2024"	"Son 2 yıldaki kararlar" gibi tarih filtresi
Konu	"11. Hukuk Dairesi"	Daire bazlı filtreleme
Chunk Index	0, 1, 2...	Kararın bölümlerini doğru sırada birleştirme

Token Tasarrufu: %90'lık Fark

Metadata stratejisinin en somut etkisi token maliyetinde ortaya çıkar. Makalelerde sıkça "RAG kurdum, her şey otomatik" denilir ama kimse token faturalarından bahsetmez.

Metadata olmayan bir RAG sistemi şöyle çalışır:

Avukat sorar: "9. Hukuk Dairesi'nin son 2 yıldaki iş kazası kararları"
Sistem, tüm veritabanında vektör araması yapar
En "benzer" 10 chunk'ı getirir , ama bunların 7'si Ceza Dairesi, 2'si 2018'den
10 chunk'ın tamamı (toplam ~30.000 karakter) yapay zekanın bağlam penceresine yüklenir
AI, 30.000 karakteri okuyup sadece 1 ilgili chunk'tan cevap üretir
Sonuç: 30.000 karakter okundu, 3.000'i işe yaradı , %90 israf

hiDAVA'nın metadata destekli sistemi ise:

Aynı soru sorulur
Sistem, önce daire = "9. Hukuk Dairesi" ve tarih > 2024 metadata filtrelerini uygular
Filtrelenmiş küçük havuzda vektör araması yapar
En ilgili 3 chunk'ı getirir , hepsi 9. HD, hepsi 2024-2026
3 chunk (toplam ~9.000 karakter) AI'a yüklenir
Sonuç: 9.000 karakter okundu, hepsi ilgili , %0 israf

Fark: Aynı kalitede cevap, %70 daha az token maliyeti, 3 kat daha hızlı yanıt süresi.

Veritabanı: Qdrant ile Milyonlarca Vektör

hiDAVA'nın vektör veritabanı olarak Qdrant kullanmasının teknik gerekçeleri:

Özellik	Detay
Mesafe Metriği	Kosinüs Benzerliği , anlam yakınlığını ölçmek için en uygun metrik
HNSW İndeksi	Milyonlarca vektör arasında milisaniyeler içinde arama , doğrusal taramanın binlerce kat hızında
Disk Tabanlı	Hem vektörler hem HNSW grafı diskte , RAM tüketimi minimum, ölçeklenebilirlik maksimum
Payload Filtreleme	Vektör araması yapılırken eş zamanlı metadata filtresi , SQL-benzeri kesinlikle vektör aramasının birleşimi

Gerçek Ölçek

hiDAVA'nın Yargıtay veri seti tek başına 5-6 milyon kararı kapsar. Her karar ortalama 3-5 chunk üretir. Bu, vektör veritabanında milyonlarca noktanın yönetilmesi demektir.

Bu ölçekte performansı korumak için segment optimizasyonu, memmap eşikleri ve indeksleme thread yönetimi gibi detaylar kritik hale gelir. hiDAVA'nın altyapısı, bu ölçeğe özel olarak yapılandırılmıştır.

Duplicate Detection: Aynı Kararı İki Kez Eklememek

Milyonlarca kararı günlük olarak besleyen bir ingestion (veri yükleme) sürecinde, aynı kararın tekrar eklenmesini önlemek hayatidir. Tekrar eden vektörler hem disk maliyetini artırır hem de arama sonuçlarını kirleterek aynı kararın birden fazla kez görünmesine neden olur.

hiDAVA'da her karar, Qdrant'a eklenmeden önce toplu kontrol (batch-check) mekanizmasından geçer. Önceden ingest edilmiş kararlar atlanır , bu da gereksiz API çağrıları ve embedding maliyetlerini sıfırlar.

Sonuç: Görünmeyen Mühendislik, Hissedilen Hız

Bir avukat hiDAVA'nın arama çubuğuna "kıdem tazminatı hesaplama usulü" yazdığında, görmediği ama hissettiği şey şudur:

Sorgu, RETRIEVAL_QUERY görev türüyle 3072 boyutlu bir vektöre dönüştürülür
Qdrant'ın HNSW indeksi, milyonlarca vektör arasında milisaniyeler içinde en yakın komşuları bulur
Metadata filtreleri (daire, tarih, tür) sonuçları daraltır
En ilgili chunk'lar, minimum token maliyetiyle AI'ın bağlam penceresine yüklenir
AI, gerçek kararlardan , uydurma değil , analiz üretir

Toplam süre: Saniyeler. Doğruluk garantisi: Her sonuç, doğrulanmış veritabanından gelir. Token verimliliği: Metadata stratejisi sayesinde gereksiz okuma minimize edilir.

Bu, "RAG kurdum" demenin çok ötesinde bir mühendislik çalışmasıdır. Ve hiDAVA olarak, bu mühendisliğin sessiz ama güçlü etkisini , daha hızlı sonuçlar, daha düşük maliyetler ve daha isabetli analizler , her gün avukatların ellerine ulaştırıyoruz.

Neden Önemli?

Avukatlar için: Saatlerce araştırma yerine saniyeler içinde isabetli sonuçlar
Hukuk büroları için: Daha düşük operasyonel maliyet, daha yüksek verimlilik
Adalet sistemi için: Doğru emsale daha hızlı ulaşmak, daha adil kararlar demektir

Teknoloji perde arkasında kalabilir , ama etkisi, mahkeme salonlarında hissedilir.

Perde Arkası: hiDAVA'nın RAG Mimarisi ve Verimlilik Metrikleri