Hukuki Kararları Anlamak: Gemini ile 100’den Fazla USCIS Temyiz Kararı Üzerine Bir RAG Sistemi Nasıl Kurulur?

Hukuki Kararları Anlamak: Gemini ile 100’den Fazla USCIS Temyiz Kararı Üzerine Bir RAG Sistemi Nasıl Kurulur?

Hukuki metinlerin karmaşık dünyasında, doğru bilgiye hızlıca ulaşmak, hem avukatlar hem de araştırmacılar için hayati önem taşır. Özellikle yüzlerce sayfalık idari temyiz kararlarını incelemek, zaman alıcı ve yorucu bir süreç olabilir. Bu makalede, Google’ın güçlü yapay zeka modeli Gemini’ı kullanarak, 100’den fazla ABD Vatandaşlık ve Göçmenlik Hizmetleri (USCIS) İdari Temyiz Ofisi (AAO) kararından oluşan bir koleksiyon üzerinde, Retrieval Augmented Generation (RAG – Geri Çağırma Destekli Üretim) sistemini nasıl inşa ettiğimi adım adım anlatacağım. Bu sistem, hukuki araştırmalarınızı dönüştürecek, karmaşık sorulara anında ve doğru yanıtlar almanızı sağlayacak.

Hukuki Metinlerin Karmaşıklığı ve RAG İhtiyacı Neden Bu Kadar Önemli?

Hukuk alanı, genellikle anlaşılması zor, jargon dolu ve hacimli belgelerle karakterizedir. USCIS AAO kararları da bu tür metinlere iyi bir örnektir. Bu kararlar, emsal teşkil eden yargılamalar, yasal dayanaklar ve karmaşık olay örgülerinin detaylı analizlerini içerir. Yüzlerce veya binlerce sayfayı bulan bu belgeler arasında spesifik bir bilgi parçasını bulmak, adeta samanlıkta iğne aramaya benzer. Geleneksel arama motorları, anahtar kelime eşleştirmesi yaparak yüzeysel sonuçlar sunsa da, bağlamı anlama ve karmaşık sorulara derinlemesine yanıt verme konusunda yetersiz kalır.

İşte tam da bu noktada, RAG sistemleri devreye girer ve bu zorluğa yenilikçi bir çözüm sunar. RAG, bir dil modelinin (LLM – Large Language Model) yeteneklerini, harici bir bilgi tabanından ilgili bilgileri “geri çağırma” yeteneğiyle birleştirir. Bu sayede, LLM, yalnızca kendi eğitim verilerine dayanmak yerine, belirli bir belge koleksiyonundan alınan güncel ve bağlamsal olarak alakalı bilgilerle zenginleştirilmiş yanıtlar üretebilir. Bu, özellikle sürekli güncellenen ve spesifik bilgi gerektiren hukuk gibi alanlarda kritik bir avantaj sağlar. Bir avukatın, benzer bir davada daha önce hangi kararların verildiğini, hangi yasal dayanakların kullanıldığını veya belirli bir durumun emsal teşkil edip etmediğini hızlıca öğrenmesi gerektiğinde, RAG sistemi paha biçilmez bir yardımcı haline gelir.

RAG sistemlerinin önemi, sadece hız ve verimlilikle sınırlı değildir. Aynı zamanda, yapay zeka tarafından üretilen yanıtların “halüsinasyon” (gerçek olmayan bilgi üretme) riskini azaltarak güvenilirliği artırır. Çünkü sistem, yanıtlarını dayandırdığı kaynakları açıkça belirtebilir ve kullanıcıların bu kaynakları doğrulamasına olanak tanır. Bu sayede, hukuki danışmanlık veya araştırma süreçlerinde yapay zekanın sağladığı bilgiler, daha sağlam ve doğrulanabilir bir temel üzerine oturur. USCIS kararları gibi yüksek hassasiyet gerektiren belgelerle çalışırken, bu doğruluk ve güvenilirlik, sistemin olmazsa olmaz bir özelliğidir. Kısacası, RAG, hukuki metinlerin karmaşıklığı karşısında, hem insanı hem de yapay zekayı güçlendiren bir köprü görevi görür.

RAG Nedir ve Hukuk Alanında Neden Bu Kadar Önemlidir?

Retrieval Augmented Generation (RAG), büyük dil modellerinin (LLM) bilgi edinme ve üretme süreçlerini iyileştirmek için kullanılan bir yapay zeka mimarisidir. Temelde iki ana aşamadan oluşur: Geri Çağırma (Retrieval) ve Üretim (Generation). Geri Çağırma aşamasında, kullanıcı sorgusu, bir vektör veritabanında depolanan geniş bir belge koleksiyonu içinde en alakalı bilgi parçalarını bulmak için kullanılır. Bu bilgi parçaları, genellikle “embedding” adı verilen sayısal vektör gösterimleri aracılığıyla sorguyla anlamsal benzerliklerine göre eşleştirilir. Üretim aşamasında ise, geri çağrılan bu alakalı bilgi parçaları, LLM’ye (bu durumda Gemini) bir bağlam olarak sunulur ve LLM, bu bağlamı kullanarak kullanıcı sorgusuna doğal ve bilgilendirici bir yanıt üretir.

Hukuk alanında RAG’ın önemi birkaç temel noktada toplanır. Birincisi, hukuk sürekli değişen ve genişleyen bir alandır. LLM’ler belirli bir tarihe kadar olan verilerle eğitilir ve güncel mevzuat değişiklikleri, yeni yargı kararları veya idari düzenlemeler hakkında bilgi sahibi olmayabilirler. RAG, bu bilgi boşluğunu kapatır. Kendi güncel ve spesifik belge koleksiyonunuzu (örneğin, en son USCIS kararlarını) sisteme dahil ederek, LLM’nin her zaman en yeni ve en alakalı bilgilere erişmesini sağlarsınız. İkincisi, hukuki metinler genellikle çok spesifik ve nüanslı detaylar içerir. Genel amaçlı LLM’ler, bu tür detayları gözden kaçırabilir veya yanlış yorumlayabilir. RAG, doğrudan ilgili pasajları LLM’ye sunarak, yanıtların doğruluğunu ve bağlamsal uygunluğunu artırır.

Üçüncüsü, “halüsinasyon” riski, hukuk gibi hata kabul etmeyen alanlarda büyük bir endişe kaynağıdır. RAG, LLM’nin “uydurma” bilgi üretme eğilimini, gerçek ve doğrulanabilir kaynaklardan alınan bilgilerle sınırlayarak önemli ölçüde azaltır. Sistem, yanıtlarını dayandırdığı kaynak belgeleri (örneğin, belirli bir USCIS kararının paragraf numarası) gösterebildiği için, kullanıcılar üretilen bilgiyi kolayca kontrol edebilir ve güvenilirliğini artırabilir. Son olarak, RAG, avukatların, hukuk araştırmacılarının ve göçmenlik uzmanlarının zamanını ve emeğini önemli ölçüde azaltır. Yüzlerce sayfalık kararlar arasında saatler harcamak yerine, spesifik bir soru sorarak saniyeler içinde ilgili ve özetlenmiş bilgilere ulaşabilirler. Bu, özellikle karmaşık göçmenlik davalarında stratejik kararlar alırken veya müvekkillere danışmanlık yaparken kritik bir avantaj sağlar. Bu nedenle, RAG, hukuki araştırma ve analiz süreçlerinde devrim niteliğinde bir araç olarak konumlanmaktadır.

Veri Hazırlığı: 100+ USCIS Kararının Düzenlenmesi Süreci

Bir RAG sisteminin başarısı, büyük ölçüde beslendiği verinin kalitesine ve düzenine bağlıdır. USCIS İdari Temyiz Ofisi (AAO) kararları, genellikle PDF formatında yayınlanır ve bu belgeler, taranmış görüntüler, metin katmanları veya her ikisinin birleşimi olabilir. Bu nedenle, ilk ve en kritik adım, bu kararları işlenebilir bir metin formatına dönüştürmektir. Projemizde, 100’den fazla AAO kararını içeren bir veri kümesiyle çalıştık. Bu kararların her biri, farklı uzunluklarda ve formatlarda olabileceği için, standart bir ön işleme süreci uygulamak zorunluydu.

İlk olarak, tüm PDF dosyalarını tek tek okumak ve içerdikleri metni çıkarmak için Python tabanlı kütüphaneler kullandık. Özellikle PyPDF2 veya pdfminer.six gibi kütüphaneler, metin katmanına sahip PDF’lerden metin çıkarmak için oldukça etkilidir. Eğer PDF’ler taranmış görüntülerden oluşuyorsa, Optik Karakter Tanıma (OCR – Optical Character Recognition) araçlarına (örneğin Tesseract veya bulut tabanlı OCR hizmetleri) başvurmak gerekebilir. Bu aşamada, çıkarılan metnin temizliği büyük önem taşır. Zira, PDF’lerden metin çıkarma işlemi sırasında sayfa başlıkları, dipnotlar, sayfa numaraları, anlamsız karakterler veya hatalı birleşimler gibi istenmeyen unsurlar ortaya çıkabilir. Bu tür gürültüyü temizlemek için düzenli ifadeler (regex) ve string manipülasyonları kullandık. Örneğin, “Sayfa X / Y” gibi ifadeleri, gereksiz boşlukları veya özel karakterleri kaldırdık.

Veri temizliğinin ardından, her bir kararın metnini daha küçük ve yönetilebilir parçalara bölmek (chunking) gerekiyordu. Bu, RAG sisteminin geri çağırma aşamasında daha alakalı ve odaklanmış sonuçlar bulmasını sağlar. Çünkü tüm kararı tek bir parça olarak işlemek, hem performansı düşürür hem de anlamsal olarak alakasız kısımların da geri çağrılmasına neden olabilir. Chunking stratejisi, metnin doğasına göre belirlenmelidir. Hukuki metinlerde, paragraflar, bölümler veya belirli bir satır sayısı gibi ölçütler kullanılabilir. Bizim durumumuzda, her bir kararı belirli bir kelime veya karakter sayısına (örneğin 500 kelime) ve üst üste binme (overlap) oranıyla (örneğin 50 kelime) bölmeyi tercih ettik. Üst üste binme, bir parçanın sonu ile bir sonraki parçanın başı arasında bir miktar ortak metin bulunması anlamına gelir; bu, bağlamın kaybolmasını engellemek için önemlidir. Her bir parçaya, hangi karardan geldiğini belirten benzersiz bir kimlik (ID) ve orijinal kararın adı gibi meta veriler ekledik. Bu meta veriler, daha sonra geri çağrılan parçaların kaynağını göstermek ve kullanıcıya tam karara yönlendirmek için kritik öneme sahiptir.

Metin Ön İşleme ve Chunking Stratejileri: Detaylı Bir Bakış

Metin ön işleme, ham veriyi yapay zeka modelleri için anlamlı ve kullanılabilir hale getirme sürecidir. USCIS kararları gibi hukuki belgelerde bu süreç, özellikle dikkatli bir yaklaşım gerektirir. İlk adım, genellikle PDF’lerden metin çıkarımıdır. Metin çıkarıldıktan sonra, belgenin içeriğini bozmadan gereksiz kısımları ayıklamak esastır. Örneğin, her sayfanın başında veya sonunda tekrar eden başlıklar, sayfa numaraları, dipnotlar, telif hakkı bildirimleri veya dosya yolları gibi yapısal öğeler temizlenmelidir. Bu temizlik işlemi, düzenli ifadeler (regular expressions) kullanılarak otomatize edilebilir. Örneğin, re.sub(r'\n\s*\n', '\n\n', text) gibi bir ifade ile birden fazla boş satırı tek bir boş satıra indirgeyerek metni daha düzenli hale getirebiliriz.

Metnin temizlenmesinin ardından, “chunking” adı verilen parçalama stratejisi devreye girer. Chunking, büyük metin belgelerini daha küçük, yönetilebilir ve anlamsal olarak tutarlı parçalara bölme işlemidir. Bu işlem, vektör veritabanında depolanacak ve sorgularla eşleştirilecek birimlerin boyutunu belirler. Hukuki metinlerde chunking yaparken, anlamsal bütünlüğü korumak kritik öneme sahiptir. Rastgele bir karakter sayısına göre kesmek yerine, metnin doğal yapılarını (paragraflar, başlıklar, bölümler) dikkate almak daha verimli sonuçlar verir. Örneğin, bir paragrafı bölmektense, tüm paragrafı bir chunk olarak almak daha mantıklıdır. Eğer paragraflar çok uzunsa, belirli bir kelime veya karakter sayısını aşan paragrafları daha küçük alt paragraflara bölmek gerekebilir.

Chunking stratejileri arasında “fixed-size chunking” (sabit boyutlu parçalama) ve “recursive chunking” (özyinelemeli parçalama) öne çıkar. Sabit boyutlu parçalama, metni belirli bir karakter veya kelime sayısına göre böler ve her parçanın sonunda belirli bir miktar “üst üste binme” (overlap) bırakır. Üst üste binme, bir parçanın sonundaki bilgilerin bir sonraki parçanın başında tekrarlanmasını sağlayarak, bir sorgunun iki farklı parça arasında kalan bir bilgiye denk gelmesi durumunda bağlam kaybını önler. Örneğin, 500 karakterlik parçalar ve 50 karakterlik üst üste binme kullanabiliriz. Özyinelemeli parçalama ise daha sofistike bir yaklaşımdır. Metni önce büyük ayraçlarla (örneğin, “## Bölüm”, “\n\n”) bölmeye çalışır. Eğer parçalar hala çok büyükse, daha küçük ayraçlarla (örneğin, “\n”, “. “) bölmeye devam eder. Bu yöntem, metnin hiyerarşik yapısını daha iyi korur ve anlamsal olarak daha tutarlı parçalar üretir. Her bir parçaya, orijinal belgeye atıfta bulunmayı sağlayan belge adı, sayfa numarası veya benzersiz bir kimlik gibi meta veriler eklemek, geri çağrılan bilginin doğrulanabilirliğini artırır.

from PyPDF2 import PdfReader
import re

def extract_text_from_pdf(pdf_path):
    reader = PdfReader(pdf_path)
    text = ""
    for page in reader.pages:
        text += page.extract_text() + "\n"
    return text

def clean_text(text):
    # Sayfa numaralarını, başlıkları vb. temizle
    text = re.sub(r'Page \d+ of \d+', '', text)
    text = re.sub(r'^\s*USCIS\s*AAO\s*Decision\s*.*$', '', text, flags=re.MULTILINE)
    # Birden fazla boş satırı tek boş satıra indirge
    text = re.sub(r'\n\s*\n', '\n\n', text)
    # Baştaki ve sondaki boşlukları temizle
    text = text.strip()
    return text

def chunk_text(text, chunk_size=500, chunk_overlap=50):
    chunks = []
    current_pos = 0
    while current_pos < len(text):
        end_pos = min(current_pos + chunk_size, len(text))
        chunk = text[current_pos:end_pos]
        chunks.append(chunk)
        current_pos += chunk_size - chunk_overlap
        if current_pos >= len(text): # Son parçanın sonu
            break
    return chunks

# Örnek kullanım
# pdf_path = "ornek_karar.pdf"
# raw_text = extract_text_from_pdf(pdf_path)
# cleaned_text = clean_text(raw_text)
# text_chunks = chunk_text(cleaned_text)
# print(f"Toplam parça sayısı: {len(text_chunks)}")
# print(text_chunks[0])
      

Vektör Veritabanı Seçimi ve Gömme (Embedding) İşlemleri Nasıl Yapılır?

Metin ön işleme ve parçalama adımlarını tamamladıktan sonra, RAG sistemimizin kalbi olan vektör veritabanını oluşturma aşamasına geçiyoruz. Vektör veritabanları, metin parçalarının “embedding” adı verilen sayısal vektör gösterimlerini depolamak ve hızlıca sorgulamak için özel olarak tasarlanmıştır. Her bir metin parçası, anlamsal olarak benzer metinlerin vektör uzayında birbirine yakın konumlandığı yüksek boyutlu bir vektöre dönüştürülür. Bu sayede, bir kullanıcı sorgusu geldiğinde, sorgunun vektörü ile veritabanındaki tüm metin parçalarının vektörleri arasındaki “benzerlik” ölçülerek en alakalı parçalar hızlıca bulunabilir.

Projemizde, vektör veritabanı olarak Pinecone‘u tercih ettik. Pinecone, büyük ölçekli vektör aramaları için optimize edilmiş, yönetilen bir hizmettir. Ancak ChromaDB, Weaviate veya açık kaynaklı Faiss gibi başka seçenekler de mevcuttur. Seçim, projenin ölçeğine, bütçesine ve yönetim kolaylığı beklentisine göre değişebilir. Pinecone’u seçmemizin ana nedenleri, kolay entegrasyonu, ölçeklenebilirliği ve performansıdır. Her bir metin parçasını bir vektöre dönüştürmek için ise Google’ın Gemini API’sinin sağladığı embedding modelini kullandık. Gemini’nin embedding modelleri, karmaşık metinleri dahi yüksek doğrulukla sayısal gösterimlere dönüştürme yeteneğine sahiptir, bu da anlamsal arama kalitesini doğrudan etkiler.

Gömme (embedding) işlemi şu adımlarla gerçekleştirilir: İlk olarak, Pinecone ortamımızı kurar ve API anahtarımızı kullanarak bir bağlantı oluştururuz. Ardından, daha önce hazırladığımız her bir metin parçasını alırız. Her bir parça için Gemini’nin embedding modelini çağırarak ilgili vektörü elde ederiz. Bu işlem, genellikle bir döngü içinde her parça için ayrı ayrı yapılır. Elde edilen vektör, o metin parçasının anlamsal özünü temsil eder. Son olarak, bu vektörleri, ilişkili oldukları metin parçası ve meta verileriyle (örneğin, orijinal belge adı, parça ID’si) birlikte Pinecone indeksimize yükleriz. Bu yükleme işlemi, Pinecone’un indeksleme yetenekleri sayesinde hızlı ve verimli bir şekilde gerçekleşir. Yükleme tamamlandığında, USCIS kararlarından oluşan tüm bilgi tabanımız, anlamsal arama için hazır hale gelmiş olur. Bu sayede, karmaşık hukuki sorgulara anında ve ilgili metin parçalarıyla desteklenmiş yanıtlar üretebilecek güçlü bir altyapı oluşturmuş oluruz.

Neden Vektör Veritabanları ve Nasıl Çalışırlar?

Vektör veritabanları, geleneksel veritabanlarından farklı olarak, verileri doğrudan depolamak yerine, onların sayısal vektör gösterimlerini (embedding’lerini) saklar. Bu vektörler, metin, görüntü, ses gibi farklı veri türlerinin anlamsal özelliklerini yüksek boyutlu bir uzayda temsil eder. Her bir boyut, verinin belirli bir özelliğine karşılık gelir ve benzer anlama sahip veriler, bu vektör uzayında birbirine daha yakın konumlanır. Bu temel prensip, vektör veritabanlarını anlamsal arama ve benzerlik tabanlı sorgular için vazgeçilmez kılar.

Peki, bir vektör veritabanı nasıl çalışır? Süreç genellikle şu adımları içerir:

1. Gömme (Embedding) Oluşturma: İlk olarak, depolamak istediğiniz her veri parçası (örneğin, USCIS kararından bir metin parçası) bir “embedding modeli” (örneğin Gemini’nin embedding modeli) aracılığıyla sayısal bir vektöre dönüştürülür. Bu model, metnin bağlamını ve anlamsal anlamını yakalayarak onu sayısal bir temsile dönüştürür.
2. Vektör Depolama: Oluşturulan bu vektörler, ilgili orijinal metin parçası ve herhangi bir meta veri (örneğin, belge adı, parça ID’si) ile birlikte vektör veritabanına depolanır. Veritabanı, bu vektörleri hızlı arama için optimize edilmiş özel indeksleme yapıları (örneğin, HNSW – Hierarchical Navigable Small World) kullanarak saklar.
3. Sorgu İşleme: Bir kullanıcı bir sorgu (örneğin, “H-1B vize reddi için hangi emsal kararlar var?”) gönderdiğinde, bu sorgu da aynı embedding modeli kullanılarak bir vektöre dönüştürülür.
4. Benzerlik Araması: Sorgu vektörü, veritabanındaki tüm depolanmış vektörlerle karşılaştırılır. Vektörler arasındaki “mesafe” veya “benzerlik” (örneğin, kosinüs benzerliği) hesaplanır. Daha küçük mesafe veya daha yüksek benzerlik, iki vektörün anlamsal olarak daha yakın olduğu anlamına gelir.
5. En Alakalı Sonuçları Geri Çağırma: Veritabanı, sorgu vektörüne en benzer olan top-k (örneğin, en benzer 5) vektörü ve bunlara karşılık gelen metin parçalarını geri döndürür.

Vektör veritabanları, geleneksel anahtar kelime tabanlı aramalardan çok daha güçlüdür çünkü kelimelerin tam eşleşmesine değil, anlamlarına odaklanır. Bu, özellikle hukuki metinlerdeki karmaşık kavramları ve nüansları anlamak için hayati önem taşır. Örneğin, “H-1B vize reddi” sorgusu, sadece bu kelimeleri içeren belgeleri değil, aynı zamanda “iş vizesi onayı reddi” veya “yabancı işçi statüsü itirazı” gibi anlamsal olarak ilgili kavramları içeren belgeleri de bulabilir. Bu yetenek, RAG sistemimizin USCIS kararları gibi geniş ve karmaşık bir veri kümesinden en doğru ve bağlamsal olarak alakalı bilgileri çekmesini sağlar.

import google.generativeai as genai
from pinecone import Pinecone, Index
import os

# API anahtarlarını ortam değişkenlerinden al
GEMINI_API_KEY = os.getenv("GEMINI_API_KEY")
PINECONE_API_KEY = os.getenv("PINECONE_API_KEY")
PINECONE_ENVIRONMENT = os.getenv("PINECONE_ENVIRONMENT") # Örneğin "us-west-2"

genai.configure(api_key=GEMINI_API_KEY)

# Pinecone'a bağlan
pc = Pinecone(api_key=PINECONE_API_KEY, environment=PINECONE_ENVIRONMENT)

# İndeks adını tanımla
index_name = "uscis-aao-decisions"

# İndeks yoksa oluştur
if index_name not in pc.list_indexes():
    pc.create_index(
        name=index_name,
        dimension=768, # Gemini embedding modelinin boyutu
        metric='cosine'
    )

index = pc.Index(index_name)

def get_gemini_embedding(text):
    # Gemini embedding modelini kullanarak vektör oluştur
    model = genai.get_model("models/embedding-001")
    embedding = model.embed_content(content=text)["embedding"]
    return embedding

def upsert_chunks_to_pinecone(chunks_with_metadata):
    vectors_to_upsert = []
    for i, chunk_data in enumerate(chunks_with_metadata):
        chunk_id = chunk_data["id"]
        chunk_text = chunk_data["text"]
        chunk_metadata = chunk_data["metadata"]

        embedding = get_gemini_embedding(chunk_text)
        vectors_to_upsert.append({
            "id": chunk_id,
            "values": embedding,
            "metadata": chunk_metadata
        })
    
    # Vektörleri Pinecone'a yükle (batching ile daha verimli)
    # Pinecone.upsert() methodu genellikle list of dict alır
    index.upsert(vectors=vectors_to_upsert)
    print(f"Toplam {len(vectors_to_upsert)} vektör Pinecone'a yüklendi.")

# Örnek kullanım (yukarıdaki chunk_text fonksiyonundan gelen çıktıya göre)
# Örnek olarak bir liste oluşturuyoruz
# sample_chunks_with_metadata = [
#     {"id": "doc1_chunk1", "text": "Bu ilk kararın ilk parçasıdır.", "metadata": {"document_id": "doc1", "page": 1}},
#     {"id": "doc1_chunk2", "text": "Bu ilk kararın ikinci parçasıdır.", "metadata": {"document_id": "doc1", "page": 1}},
#     # ... diğer parçalar
# ]
# upsert_chunks_to_pinecone(sample_chunks_with_metadata)
      

Gemini Entegrasyonu: Akıllı Sorgulama ve Yanıtlama Yetenekleri

Veri hazırlığı ve vektör veritabanı oluşturma adımlarını başarıyla tamamladıktan sonra, RAG sistemimizin en heyecan verici kısmı olan Gemini entegrasyonuna geçiyoruz. Bu aşamada, kullanıcıdan gelen bir sorguyu işleyecek, vektör veritabanımızdan en alakalı bilgileri geri çağıracak ve son olarak bu bilgileri kullanarak Gemini’nin gelişmiş dil modelinden akıllı ve bağlamsal olarak doğru bir yanıt alacağız. Gemini, hem metin anlama hem de metin üretme konusundaki üstün yetenekleriyle, RAG sistemimizin temelini oluşturuyor.

Sistem şu şekilde işler: Bir kullanıcı bir soru sorduğunda (örneğin, “L-1A vizesi için yönetici veya müdür tanımı nedir?”), ilk olarak bu sorguyu Gemini’nin embedding modelini kullanarak bir vektöre dönüştürürüz. Bu sorgu vektörü daha sonra Pinecone indeksimizde bir benzerlik araması yapmak için kullanılır. Pinecone, sorgu vektörüne en yakın olan (yani anlamsal olarak en alakalı) birkaç metin parçasını (chunk) geri döndürür. Bu geri çağrılan parçalar, USCIS kararlarından alınmış ilgili pasajlardır ve kullanıcının sorusuyla doğrudan bağlantılı bilgileri içerir.

Geri çağrılan bu metin parçaları, doğrudan Gemini’ye gönderilmez. Bunun yerine, bu parçaları ve kullanıcının orijinal sorusunu içeren özel olarak hazırlanmış bir “prompt” (yönerge) oluştururuz. Prompt, Gemini’ye ne yapması gerektiğini (örneğin, “Aşağıdaki bağlamı kullanarak soruya yanıt verin ve yanıtınızı bu bağlamla sınırlayın”) ve hangi bilgileri kullanması gerektiğini açıkça belirtir. Bu prompt, genellikle şu yapıyı takip eder:

"Aşağıdaki USCIS kararlarından alınan bağlamı kullanarak şu soruya yanıt verin: [Kullanıcının Sorusu]\n\nBağlam:\n[Geri Çağrılan Metin Parçası 1]\n[Geri Çağrılan Metin Parçası 2]\n...\n[Geri Çağrılan Metin Parçası N]\n\nYanıtınızı sadece verilen bağlamla sınırlayın ve bağlamda olmayan bilgileri eklemeyin. Yanıtınızda, mümkünse kaynak karara atıfta bulunun."
        

Bu prompt, Gemini’nin “halüsinasyon” yapma riskini azaltır ve yanıtın yalnızca sağlanan kaynaklarla sınırlı kalmasını sağlar. Gemini’nin dil modeli, bu prompt’u işler ve geri çağrılan bilgilerden yola çıkarak kullanıcı sorgusuna doğal dilde, özetlenmiş ve doğru bir yanıt üretir. Üretilen yanıt, sadece bilgiyi sunmakla kalmaz, aynı zamanda hukuki metinlerin karmaşıklığını basitleştirerek anlaşılır bir formatta sunar. Bu entegrasyon sayesinde, RAG sistemimiz, yüzlerce hukuki belge arasında kaybolmak yerine, spesifik ve anlamsal olarak alakalı bilgilere hızlıca ulaşan ve bunları akıllıca yorumlayan bir hukuk asistanına dönüşür.

Gemini API Kullanımı ve Prompt Mühendisliği İpuçları

Gemini API’sini RAG sistemimize entegre etmek, yapay zekanın gücünü hukuki araştırmalarımıza katmanın anahtarıdır. Gemini API’si, metin üretimi, metin anlama ve gömme (embedding) gibi çeşitli görevler için güçlü modeller sunar. Bu modelleri verimli bir şekilde kullanmak için doğru API çağrılarını yapmak ve “prompt mühendisliği” konusunda ustalaşmak gerekir.

Gemini API’si ile etkileşim, genellikle Google Cloud Client Library for Python (google-generativeai) kullanılarak gerçekleştirilir. İlk adım, API anahtarınızı yapılandırmak ve kullanacağınız modeli belirtmektir. Metin üretimi için genellikle models/gemini-pro gibi bir model tercih edilirken, embedding’ler için models/embedding-001 kullanılır. Bir sorguya yanıt üretmek için, geri çağrılan metin parçalarını ve kullanıcının sorusunu içeren bir prompt oluşturulur ve bu prompt, Gemini modeline gönderilir. Örneğin:

import google.generativeai as genai
import os

GEMINI_API_KEY = os.getenv("GEMINI_API_KEY")
genai.configure(api_key=GEMINI_API_KEY)

def generate_rag_response(query, retrieved_chunks):
    model = genai.GenerativeModel('gemini-pro')
    
    context = "\n".join([chunk["text"] for chunk in retrieved_chunks])
    
    prompt = f"""
    Aşağıdaki USCIS kararlarından alınan bağlamı kullanarak şu soruya yanıt verin: {query}
    
    Bağlam:
    {context}
    
    Yanıtınızı sadece verilen bağlamla sınırlayın ve bağlamda olmayan bilgileri eklemeyin. 
    Mümkünse, yanıtınızda kaynak karara atıfta bulunun (örneğin, "Karar XXX'e göre...").
    """
    
    response = model.generate_content(prompt)
    return response.text

# Örnek kullanım
# user_query = "L-1A vizesi için yönetici veya müdür tanımı nedir?"
# retrieved_chunks = [
#     {"text": "Karar YYY, bir yöneticinin temel görevlerinin şirket stratejilerini belirlemek olduğunu belirtir.", "metadata": {"document_id": "YYY"}},
#     {"text": "Karar ZZZ, bir müdürün günlük operasyonları denetlemekten sorumlu olduğunu açıklar.", "metadata": {"document_id": "ZZZ"}}
# ]
# response_text = generate_rag_response(user_query, retrieved_chunks)
# print(response_text)
        

Prompt mühendisliği, LLM’lerden en iyi yanıtları almanın sanatıdır. RAG sistemlerinde, prompt’unuzun yapısı, LLM’nin geri çağrılan bilgiyi nasıl yorumlayacağını ve kullanacağını doğrudan etkiler. İşte bazı ipuçları:

• Açık Talimatlar: LLM’den ne beklediğinizi net bir şekilde belirtin. “Yanıtınızı sadece verilen bağlamla sınırlayın” veya “Özetle” gibi ifadeler kullanın.
• Bağlamı Vurgulayın: Geri çağrılan metin parçalarını prompt içinde açıkça “Bağlam:” veya “Kaynak Metin:” gibi bir başlık altında sunun.
• Rol Tanımlama: LLM’ye bir rol atayabilirsiniz (örneğin, “Sen bir hukuk uzmanısın…”). Bu, yanıtın tonunu ve stilini etkileyebilir.
• Format Belirleme: Yanıtın belirli bir formatta olmasını istiyorsanız (örneğin, madde işaretli liste, özet), bunu prompt’ta belirtin.
• Negatif Kısıtlamalar: “Halüsinasyon yapma”, “bağlam dışı bilgi ekleme” gibi negatif kısıtlamalar, yanıtın doğruluğunu artırır.
• Kaynak Atıfı: LLM’den, yanıtında kullandığı bilgilerin kaynaklarına (örneğin, karar numarası) atıfta bulunmasını isteyin. Bu, doğrulanabilirliği artırır.

Prompt mühendisliği, deneme yanılma yoluyla geliştirilen bir beceridir. Farklı prompt yapıları ve ifadeleri deneyerek, Gemini’den en doğru ve kullanışlı yanıtları alacak optimum stratejiyi bulabilirsiniz. Bu, RAG sisteminizin hukuki metinlerle etkileşimini çok daha verimli ve güvenilir hale getirecektir.

RAG Sistemini Geliştirme ve İyileştirme İpuçları

Bir RAG sistemi kurmak sadece başlangıçtır; gerçek potansiyeli, sürekli iyileştirme ve geliştirme süreçleriyle ortaya çıkar. USCIS kararları gibi kritik hukuki belgeler üzerinde çalışan bir sistem için doğruluk, hız ve güvenilirlik her zaman en üst düzeyde olmalıdır. İşte RAG sisteminizi daha da güçlendirmek için uygulayabileceğiniz bazı ileri düzey ipuçları ve stratejiler:

1. Gelişmiş Chunking Stratejileri: Sabit boyutlu parçalamadan daha sofistike yöntemlere geçiş yapın. Örneğin, metnin anlamsal yapısını daha iyi anlayan “recursive chunking” veya belge başlıklarını, alt başlıklarını ve paragraflarını dikkate alarak parçalar oluşturan “semantic chunking” tekniklerini deneyin. Daha küçük, ancak anlamsal olarak daha yoğun parçalar, daha hassas geri çağırma sonuçları verebilir. Ayrıca, “parent document retrieval” gibi yöntemlerle, küçük parçaları sorgulayıp, ardından bu parçaların ait olduğu daha büyük “ebeveyn” belgeyi bağlam olarak kullanabilirsiniz.
2. Çok Modelli Gömme (Multimodal Embeddings): Eğer veri setinizde sadece metin değil, aynı zamanda görseller, tablolar veya diyagramlar gibi başka medya türleri de varsa, Gemini’nin çok modelli embedding yeteneklerini kullanmayı düşünün. Bu, sisteminizin farklı veri türleri arasındaki ilişkileri anlamasına ve daha zengin bir bağlam sunmasına olanak tanır. Hukuki belgelerde grafikler veya tablolar nadir olsa da, ileride farklı veri türleriyle çalışmanız gerekebilir.
3. Sorgu Genişletme (Query Expansion): Kullanıcı sorguları bazen çok kısa veya belirsiz olabilir. Sorgu genişletme teknikleri, orijinal sorguyu daha zengin ve kapsamlı hale getirerek vektör aramasının doğruluğunu artırır. Örneğin, kullanıcı sorgusunu bir LLM’e göndererek potansiyel eş anlamlılar, ilgili kavramlar veya daha detaylı bir açıklama isteyebilirsiniz. Bu genişletilmiş sorguyu daha sonra embedding oluşturmak için kullanabilir veya birden fazla sorgu vektörüyle arama yapabilirsiniz.
4. Yeniden Sıralama (Re-ranking) Modelleri: Vektör veritabanından geri çağrılan ilk N adet sonuç, her zaman en alakalı olanlar olmayabilir. Bir “re-ranking” modeli kullanarak, geri çağrılan parçaları kullanıcının orijinal sorgusuyla olan ilişkilerine göre yeniden sıralayabilirsiniz. Bu modeller, genellikle daha küçük ve daha odaklanmış dil modelleridir ve geri çağrılan her bir parça ile sorgu arasındaki anlamsal ilişkiyi daha derinlemesine değerlendirir. Bu, LLM’ye sunulan bağlamın kalitesini önemli ölçüde artırır.
5. Kullanıcı Geri Bildirimi ve Öğrenme: Sisteminizin performansını sürekli olarak izleyin ve kullanıcı geri bildirimlerini toplayın. Hangi yanıtların yararlı olduğu, hangilerinin olmadığı gibi bilgiler, sisteminizi iyileştirmek için paha biçilmezdir. Bu geri bildirimleri kullanarak, embedding modelinizi, prompt stratejilerinizi veya hatta chunking yöntemlerinizi ayarlayabilirsiniz. Aktif öğrenme döngüleri kurarak, sistemin zamanla kendi kendine daha iyi hale gelmesini sağlayabilirsiniz.
6. Güvenilirlik ve Şeffaflık: Özellikle hukuk alanında, üretilen yanıtların güvenilirliği ve şeffaflığı esastır. RAG sisteminiz, her yanıtın hangi kaynak belgelerden (USCIS kararları, sayfa numaraları vb.) geldiğini açıkça belirtmelidir. Bu, kullanıcıların bilgiyi doğrulamasını ve sistemin şeffaflığını artırır. Ayrıca, yanıtlarda belirsizlik veya yetersiz bilgi olduğunda, bunu dürüstçe belirten bir mekanizma da ekleyebilirsiniz.
7. Ölçeklenebilirlik ve Performans Optimizasyonu: Veri setiniz büyüdükçe, sisteminizin ölçeklenebilirliğini ve performansını gözden geçirin. Vektör veritabanı sağlayıcınızın (Pinecone gibi) ölçeklendirme seçeneklerini inceleyin. Embedding oluşturma ve Pinecone’a yükleme süreçlerini gruplandırarak (batching) daha verimli hale getirin.

Bu ipuçlarını uygulayarak, RAG sisteminizi basit bir bilgi geri çağırma aracından, hukuki araştırmalarınız için vazgeçilmez, akıllı ve güvenilir bir asistana dönüştürebilirsiniz. Sürekli iterasyon ve iyileştirme, bu tür yapay zeka sistemlerinin başarısının anahtarıdır.

Sonuç: Hukuki Araştırmalarda Yeni Bir Dönem

Bu makalede, 100’den fazla USCIS İdari Temyiz Ofisi (AAO) kararı üzerinde, Google’ın Gemini yapay zeka modelini kullanarak güçlü bir Retrieval Augmented Generation (RAG) sistemi kurmanın tüm aşamalarını detaylı bir şekilde inceledik. Hukuki metinlerin karmaşıklığından, veri hazırlığı ve chunking stratejilerine, vektör veritabanı seçimi ve embedding işlemlerinden Gemini entegrasyonu ve prompt mühendisliğine kadar her adımı ele aldık. Gördüğümüz gibi, RAG sistemleri, büyük ve karmaşık belge koleksiyonlarından anlamlı ve doğru bilgi çıkarmanın anahtarını sunuyor.

Kurduğumuz bu sistem, geleneksel anahtar kelime tabanlı arama motorlarının ötesine geçerek, anlamsal benzerlik ve bağlamı anlama yeteneğiyle hukuki araştırmalarda devrim yaratma potansiyeli taşıyor. Avukatlar, hukuk araştırmacıları ve göçmenlik uzmanları için, saatler süren manuel belge inceleme süreçlerini dakikalara indirgeyerek, daha stratejik ve verimli çalışmanın kapılarını aralıyor. Gemini’nin güçlü dil modelini, spesifik ve güncel bir bilgi tabanıyla birleştirerek, “halüsinasyon” riskini minimize ederken, doğrulanabilir ve güvenilir yanıtlar elde etmeyi başardık. Bu, özellikle hata payının çok düşük olması gereken hukuk gibi alanlarda kritik bir avantajdır.

Ancak, bir RAG sisteminin inşası tek seferlik bir proje değildir. Sürekli iyileştirme, yeni verilerin entegrasyonu ve gelişmiş tekniklerin uygulanması, sistemin uzun vadeli başarısı için esastır. Gelişmiş chunking stratejileri, yeniden sıralama modelleri ve kullanıcı geri bildirimlerini dikkate alarak sisteminizi daha da optimize edebilirsiniz. Hukuki araştırmaların geleceği, yapay zekanın bu tür akıllı ve destekleyici sistemlerle entegrasyonunda yatıyor. Bu RAG sistemi, sadece USCIS kararları için değil, herhangi bir geniş ve karmaşık belge koleksiyonu üzerinde bilgi edinme ve anlama süreçlerini dönüştürmek için bir model teşkil etmektedir. Bu teknoloji, hukuki alanda bilgiye erişimi demokratikleştirerek, daha hızlı ve bilinçli kararlar alınmasına yardımcı olacaktır.

Sıkça Sorulan Sorular

• RAG sistemi kurmak için hangi teknik bilgiye sahip olmam gerekiyor?

  Temel Python programlama bilgisi, veri yapıları, API’lerle çalışma deneyimi ve doğal dil işleme (NLP) kavramlarına aşinalık faydalı olacaktır. Vektör veritabanları ve büyük dil modelleri hakkında genel bir anlayış da süreci kolaylaştıracaktır. Ancak adım adım rehberler ve kütüphane dokümantasyonları ile bu konularda kendinizi geliştirebilirsiniz.

• USCIS kararları dışındaki hukuki belgeler için de bu sistemi kullanabilir miyim?

  Kesinlikle! Bu makalede açıklanan RAG mimarisi, USCIS kararları gibi belirli bir hukuki belge türüne özgü değildir. Herhangi bir yasal mevzuat, mahkeme kararları, şirket politikaları, sözleşmeler veya diğer metin tabanlı belgeler üzerinde benzer bir sistemi uygulayabilirsiniz. Önemli olan, veri hazırlığı ve chunking adımlarını belge türünüze göre uyarlamaktır.

• Gemini yerine başka bir büyük dil modeli (LLM) kullanabilir miyim?

  Evet, Gemini yerine OpenAI’nin GPT modelleri, Anthropic’in Claude’u veya açık kaynaklı modeller gibi başka LLM’leri de entegre edebilirsiniz. Her modelin kendine özgü yetenekleri ve API’leri vardır, bu nedenle entegrasyon adımlarında ilgili modelin dokümantasyonuna başvurmanız gerekecektir. Temel RAG prensipleri aynı kalacaktır.

• RAG sisteminin doğruluğunu nasıl test edebilirim?

  Doğruluğu test etmek için, sisteminize daha önce yanıtlarını bildiğiniz soruları sorarak çıktıyı manuel olarak değerlendirebilirsiniz. Ayrıca, belirli bir doğruluk eşiği belirleyerek (örneğin, yanıtın %X oranında doğru ve bağlamda olması), bir test veri seti üzerinde otomatik değerlendirmeler yapabilirsiniz. Yanıtın kaynaklara atıfta bulunup bulunmadığını ve bu kaynakların gerçekten ilgili olup olmadığını kontrol etmek de önemlidir.

• Bu sistemin maliyeti nedir?

  Maliyet, kullandığınız hizmetlere (Gemini API, Pinecone gibi yönetilen vektör veritabanları), veri hacminize ve kullanım sıklığınıza göre değişir. Genellikle, API çağrıları (embedding ve LLM çağrıları) ve vektör veritabanı depolama/sorgulama için bir maliyet oluşur. Birçok sağlayıcı, düşük kullanım seviyeleri için ücretsiz katmanlar veya deneme sürümleri sunar, bu da başlangıç için iyi bir fırsattır.

#RAGSistemi #GeminiAI #USCIS #YapayZeka #HukukiTeknoloji #DoğalDilİşleme #VektörVeritabanı