Google Dosya Arama Aracı Eğitimi: Gemini API ile RAG Uygulamaları Geliştirin

Bu eğitimde, Google Dosya Arama ile bir tıbbi dokümantasyon asistanı oluşturmayı adım adım göstereceğim. Kurulumu nasıl yapacağınızı, sorguları nasıl uygulayacağınızı ve özel parçalama ile meta veri filtreleme gibi gelişmiş özellikleri nasıl kullanacağınızı göreceksiniz. Sonunda, yönetilen RAG’in ne zaman mantıklı olduğunu ve ne zaman kendi yığınınızı kurmanız gerektiğini anlayacaksınız.

Google Dosya Arama Aracı nedir?

RAG uygulamaları geliştirmek genellikle vektör veritabanları, gömme (embedding) hatları ve çok sayıda altyapıyla uğraşmak anlamına gelir. Kasım 2025’te yayımlanan Google’ın Dosya Arama aracı, doğrudan RAG sistemini Gemini API’sine entegre eden tamamen yönetilen bir yapıyla bu karmaşıklığı ortadan kaldırır.

Araç, belgeleri parçalama, gömmeler oluşturma ve Pinecone veya ChromaDB gibi harici araçlar gerektirmeden anlamsal aramayı yönetme gibi karmaşık kısımları sizin yerinize halleder. İş akışı basittir: dosyaları yükleyin, bir mağaza (store) oluşturun ve sorgulamaya başlayın. Ayrıca yanıtların kaynağını doğrulamanıza olanak tanıyan yerleşik atıflar elde edersiniz.

RAG’i Anlamak ve Google’ın Neden Basitleştirdiğini Görmek

Gemini Dosya Arama kendisini yönetilen bir RAG sistemi olarak sunar. RAG’i anlamak, aracı iyi kullanmanıza ve kullanım senaryonuza ne zaman uyduğuna karar vermenize yardımcı olur.

Özünde, bilgi getirimiyle artırılmış üretim (RAG), dil modellerini harici bilgiye bağlar. Model, bir yanıt oluşturmadan önce belgelerinizden ilgili bilgileri getirir ve yanıtları yalnızca eğitim verilerine güvenmek yerine gerçek verilerinizle temellendirir.

Kendin Yap (DIY) RAG zorluğu

RAG kavramsal olarak basit görünse de, bir RAG hattı kurmak, şu bileşenleri yönetmek anlamına gelir:

• Vektör veritabanları: Gömmleri depolamak için Pinecone, ChromaDB veya Weaviate gibi hizmetleri kurup sürdürmek
• Gömme hatları: Belgeleri sayısal vektörlere dönüştürmek ve içerik değiştiğinde güncellemeleri yönetmek
• Parçalama stratejileri: Bağlam ile getirme hassasiyeti arasında denge kuracak şekilde belgeleri parçalara ayırmak
• Altyapı: Performansı izlemek, parametreleri ayarlamak ve veriniz büyüdükçe ölçeklenmeyi yönetmek

Her bileşen uzmanlık ve sürekli bakım gerektirir. İster güvenilirliği yüksek bir üretim sistemi inşa edin ister hızlıca bir prototip geliştirin, altyapı yükü aynı dar boğaz olarak kalır.

Yönetilen RAG neden önemlidir

Google Dosya Arama gibi yönetilen hizmetler bu darboğazı ortadan kaldırır. Getirme sistemlerini ayarlamak yerine sorgular yazarsınız. Gömme hatlarını hata ayıklamak yerine sonuçları doğrularsınız. Altyapı arka planda çalışırken siz uygulama mantığına odaklanırsınız.

Gemini Dosya Arama teknik karmaşıklığı yönetirken, sizin kontrolünüzde olanlar şunlardır: hangi belgelerin indeksleneceği, nasıl sorgulanacakları ve sonuçların nasıl kullanılacağı. Operasyonel yük olmadan üretim kalitesine ihtiyaç duyduğunuzda bu denge gayet iyi çalışır. RAG temelleri hakkında daha derin bir arka plan için DataCamp’in eyletimli (agentic) RAG öğreticisini öneririm.

Google Dosya Arama’yı anlamanın en iyi yolu onu kullanmaktır. Bir sonraki bölümde, belge yüklemeden atıflı temellendirilmiş yanıtlara kadar tüm iş akışını gösteren eksiksiz bir tıbbi dokümantasyon asistanı oluşturacaksınız.

Google Dosya Arama ile Tıbbi Dokümantasyon Asistanı Oluşturma

Sorumluluk reddi: Bu eğitim, yalnızca eğitim amaçlı olarak FDA ilaç etiketlerini kullanarak Dosya Arama yeteneklerini göstermektedir. Oluşturacağınız asistan klinik kullanım, hasta bakımı kararları veya tıbbi tanı için tasarlanmamıştır. Tıbbi tavsiye için daima yetkin sağlık profesyonellerine danışın. Yapay zeka sistemleri, kaynak belgelerle temellendirilmiş olsa bile hatalı bilgiler üretebilir.

Bu bölümde Dosya Arama kullanarak eksiksiz bir tıbbi dokümantasyon asistanı oluşturacaksınız. Üç yaygın ilacın FDA etiketleriyle çalışacak, ilaç etkileşimleri, yan etkiler ve kontrendikasyonlar hakkında sorulara yanıt veren bir sistem kuracaksınız. Asistan, kaynak belgelerdeki belirli pasajlara atıf yaparak doğrulanabilir yanıtlar sağlar.

Dosya Arama iki aşamada çalışır: belgelerinizi bir kez indekslersiniz, ardından tekrar tekrar sorgularsınız. Önce indeksleme altyapısını kuracak, sonra tamamen soru sormaya ve temellendirilmiş yanıtları yorumlamaya odaklanacaksınız.

Adım 1: API’yi kurun ve kimlik doğrulamayı yapılandırın

Python 3.9 veya üzeri gereklidir. Google Generative AI SDK’yı ve bağımlılıkları yükleyin:

pip install google-genai python-dotenvAltyapı:

Google AI Studio’dan API anahtarınızı alın. Proje dizininizde bir .env dosyasına kaydedin:

GOOGLE_API_KEY=your_api_key_hereAltyapı:

İçe aktarmaları ayarlayın ve istemciyi başlatın:

from google import genai
from google.genai import types
import time
from dotenv import load_dotenv

load_dotenv()
client = genai.Client()Altyapı:

genai.Client(), ortam değişkeninizi kullanarak kimlik doğrulamayı otomatik olarak halleder. Tüm Dosya Arama işlemlerinde bu istemci nesnesini kullanacaksınız.

Adım 2: Bir Dosya Arama mağazası oluşturun

İndekslenmiş belgelerinizi tutacak bir mağaza oluşturun:

file_search_store = client.file_search_stores.create(
    config={"display_name": "fda-drug-labels"}
)
print(f"Created store: {file_search_store.name}")Altyapı:

Bir Dosya Arama mağazası, indekslenmiş belgeleriniz için bir kapsayıcı görevi görür. 48 saat sonra süresi dolan geçici dosya yüklemelerinin aksine mağazalar süresiz olarak kalıcıdır. Bu, belgeleri bir kez indeksleyip binlerce kez yeniden yükleme veya yeniden işleme olmadan sorgulayabileceğiniz anlamına gelir.

file_search_store.name, sorgularken başvuracağınız benzersiz bir tanımlayıcı içerir. Şuna benzer: fileSearchStores/fdadruglabels-abc123. Mağazayı farklı bir oturumdan sorgulamanız gerekirse bu değeri kaydedin.

Adım 3: PDF belgelerini yükleyin ve indeksleyin

Bu eğitimde üç FDA onaylı ilaç etiketiyle çalışacaksınız. Bu PDF’leri FDA web sitesinden indirin:

• Metformin (Glucophage) - Diyabet ilacı
• Atorvastatin (Lipitor) - Kolesterol ilacı
• Lisinopril (Zestril) - Tansiyon ilacı

Bunları proje dizininize kaydedin ve ardından Dosya Arama mağazanıza yükleyin:

pdf_files = ["metformin.pdf", "atorvastatin.pdf", "lisinopril.pdf"]

for pdf_file in pdf_files:
    operation = client.file_search_stores.upload_to_file_search_store(
        file=pdf_file,
        file_search_store_name=file_search_store.name,
        config={"display_name": pdf_file.replace(".pdf", "")},
    )

    # Wait for indexing to complete
    while not operation.done:
        time.sleep(3)
        operation = client.operations.get(operation)

    print(f"{pdf_file} indexed")Altyapı:

Yükleme sırasında Dosya Arama, her PDF’yi parçalara böler ve bu segmentleri gemini-embedding-001 modeliyle gömmelere dönüştürür. Bu gömmeler, anlamsal anlamı yakalayan sayısal temsillerdir; böylece sorunuz belgedeki ifadelerle birebir eşleşmese bile sistem ilgili pasajları bulabilir.

Oylama deseni (while not operation.done), indekslemenin eşzamansız doğasını yönetir. Büyük belgeler daha uzun sürer, bu yüzden API hemen yanıt verir ve siz periyodik olarak tamamlanma durumunu kontrol edersiniz. Üretim sistemleri için, sonsuz döngüleri önlemek amacıyla zaman aşımı mantığı eklemeyi düşünün.

Her parça, kaynağı olan belgeye ve konumuna bağlayan meta verileri korur. Bu meta veriler, daha sonra atıflara eriştiğinizde önemli hale gelir.

Adım 4: Tek belgeli bilgileri sorgulayın

Şimdi indekslenmiş belgelerinizi sorgulayın:

query1 = "What are the contraindications for metformin?"

response1 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query1,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response1.text)Altyapı:

Bu, oluşturulan yanıtı yazdırır:

Metformin is contraindicated in several conditions:

* Severe renal impairment (eGFR below 30 mL/min/1.73 m2)
* Acute or chronic metabolic acidosis
* Hypersensitivity to metforminAltyapı:

Dosya Arama, belgelerinizde en anlamsal olarak benzer parçaları getirir ve bunları gemini-2.5-flash modeline bağlam olarak sunar; model de yanıtı üretir. tools dizisi yapılandırması, modele üretim sırasında Dosya Arama’yı kullanmasını söyler. Aynı istekte Dosya Arama’yı kod yürütme veya Google Arama gibi diğer araçlarla birleştirebilirsiniz.

Adım 5: Atıflara ve temellendirme meta verilerine erişin

Yanıtı hangi belgelerin bilgilendirdiğini çıkarın:

print("Sources used:")
for i, chunk in enumerate(response1.candidates[0].grounding_metadata.grounding_chunks, 1):
    source_name = chunk.retrieved_context.title
    print(f"  [{i}] {source_name}")Altyapı:

Çıktı:

Sources used:
  [1] metformin
  [2] atorvastatinAltyapı:

Temellendirme meta verilerindeki her parça, kaynak belgenin başlığını ve yanıtı bilgilendiren belirli metin pasajını içerir. Bu, oluşturulan yanıttan orijinal belgelerinize geri giden bir doğrulama yolu oluşturur—özellikle doğruluğun önemli olduğu tıbbi, hukuki veya finansal uygulamalarda gereklidir.

grounding_chunks dizisi, tüm getirilen pasajları alaka düzeyine göre sıralı olarak içerir. Sorgu özellikle metformin hakkında olsa da, Dosya Arama muhtemelen ilgili kontrendikasyon bilgileri içerdiği için atorvastatin belgesinden de içerik getirdi. Bu, anlamsal getirme yaklaşımını gösterir: sistem yalnızca anahtar kelime eşleşmeleri değil, kavramsal olarak ilgili içeriği bulur.

Adım 6: Birden çok belge arasında sorgu çalıştırın

Çok belgeli bir ilaç etkileşimi sorusu test edin:

query2 = "Can a patient take both atorvastatin and metformin together? Are there any drug interactions?"

response2 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query2,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response2.text)Altyapı:

Aynı API deseni şimdi birden çok belgeden çekip bilgileri sentezler. Getirilen metin parçacıklarına erişin:

print("Sources used:")

for i, chunk in enumerate(response2.candidates[0].grounding_metadata.grounding_chunks, 1):
    source_name = chunk.retrieved_context.title
    source_text = chunk.retrieved_context.text[:100] + "..."
    print(f"  [{i}] {source_name}")
    print(f"      {source_text}")Altyapı:

Çıktı her iki ilaç etiketinden alıntılar gösterir:

Sources used:
  [1] atorvastatin
      Concomitant use with diabetes medications is generally safe but monitor glucose levels...
  [2] metformin
      Carbonic anhydrase inhibitors may increase the risk of lactic acidosis...Altyapı:

Dosya Arama her iki belgeden de ilgili bölümleri getirir ve model bunları tutarlı bir yanıta dönüştürür. retrieved_context.text özniteliği, kullanılan tam pasajı verir ve modelin uydurma bilgi üretmediğini doğrulamanıza imkân tanır.

Adım 7: Belgeler arası karşılaştırmalar yapın

Üç belgenin tamamını karşılaştırmayı gerektiren analitik bir soru sorun:

query3 = "Which medications have muscle-related side effects?"

response3 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query3,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response3.text)

# Check which documents were consulted
metadata = response3.candidates[0].grounding_metadata
for i, chunk in enumerate(metadata.grounding_chunks, 1):
    print(f"  [{i}] {chunk.retrieved_context.title}")Altyapı:

Çıktı, kasla ilişkili yan etkileri (miyalji, miyopati, rabdomiyoliz) olan ilacın atorvastatin olduğunu belirtir ve diğer ilaçların bu tür etkilere yer vermediğini doğrular. Temellendirme meta verileri, karşılaştırma sorusunu yanıtlamak için Dosya Arama’nın üç belgenin tamamını danıştığını gösterir.

Artık çalışan bir tıbbi dokümantasyon asistanı oluşturdunuz. Temel iş akışı tutarlıdır: generate_content() çağrınızda Dosya Arama aracını yapılandırın, yanıt metnini alın ve doğrulama için temellendirme meta verilerine erişin. Mağaza Google’ın sunucularında kalıcıdır; bu nedenle yeniden indeksleme yapmadan gelecekteki oturumlardan sorgulayabilirsiniz.

Sırada, getirme davranışı üzerinde daha ince kontrol sağlayan özel parçalama yapılandırmaları ve meta veri filtreleme gibi gelişmiş özellikleri keşfedeceksiniz.

Google Dosya Arama Aracı Gelişmiş Özellikler ve Özelleştirme

Temel Dosya Arama iş akışı çoğu kullanım senaryosunu kapsar, ancak üretim sistemleri genellikle getirme davranışı üzerinde daha ince ayara ihtiyaç duyar. Bu bölüm, parçalama stratejilerini nasıl özelleştireceğinizi, belgeleri meta verilerle nasıl filtreleyeceğinizi, performansı nasıl optimize edeceğinizi ve farklı kullanım senaryoları için birden fazla mağazayı nasıl yöneteceğinizi gösterir.

Özel parçalama yapılandırması

Dosya Arama, indeksleme sırasında belgeleri otomatik olarak parçalara böler. Varsayılan olarak genel belgeler için optimize edilmiş bir parçalama stratejisi kullanır, ancak belirli belge türlerinin farklı şekilde ele alınması gerektiğinde bu davranışı özelleştirebilirsiniz.

Tıbbi asistan örneğini düşünün. İlaç etiketleri, tablolar ve kısa paragraflarda yoğun teknik bilgi içerir. Daha küçük parçalar, alakasız bağlamı çekmeden belirli dozlar veya kontrendikasyonlar gibi hassas bilgileri getirmenize olanak tanır. Anlatı bölümleri içinse daha büyük parçalar, doğru anlamak için gerekli bağlamı daha iyi taşır.

Belgeleri yüklerken parçalama parametrelerini yapılandırın:

operation = client.file_search_stores.upload_to_file_search_store(
    file="metformin.pdf",
    file_search_store_name=file_search_store.name,
    config={
        "display_name": "metformin",
        "chunking_config": {
            "white_space_config": {
                "max_tokens_per_chunk": 200,
                "max_overlap_tokens": 20
            }
        }
    }
)Altyapı:

chunking_config parametresi, Dosya Arama’nın belgelerinizi nasıl böleceğini kontrol eder. max_tokens_per_chunk her parçanın azami boyutunu belirlerken, max_overlap_tokens ardışık parçalar arasındaki içerik örtüşmesini tanımlar. Bu örtüşme, parça sınırlarına yayılan bilgilerin getirme sırasında kaybolmamasını sağlar.

Takası önemlidir: daha kısa parçalar daha hassas getirme sağlar ancak daha geniş bağlamı kaçırabilir; daha büyük parçalar daha fazla anlam taşır ancak alakasız bilgi içerebilir. 

Bölüm sınırları net olan teknik dokümantasyon için daha küçük parçalar (150-250 token) kullanın. Araştırma makaleleri veya raporlar gibi anlatı belgeleri için daha büyük parçalar (400-600 token) argüman akışını ve bağlamı korur. resmi Dosya Arama belgeleri, farklı belge türleri için parça boyutu seçimine dair ek rehber sunar.

Meta veri filtreleme

Mağazanız onlarca veya yüzlerce belge içerdiğinde, meta veri filtreleme, anlamsal arama çalıştırılmadan önce getirme kapsamını daraltır. Bu, hassasiyeti artırır ve işlem süresini azaltır.

Daha sonra filtrelemeyi etkinleştirmek için belge yükleme sırasında meta veriler ekleyin:

operation = client.file_search_stores.upload_to_file_search_store(
    file="metformin.pdf",
    file_search_store_name=file_search_store.name,
    config={
        "display_name": "metformin",
        "custom_metadata": [
            {"key": "category", "string_value": "diabetes"},
            {"key": "year", "numeric_value": 2017},
            {"key": "drug_class", "string_value": "biguanide"}
        ]
    }
)Altyapı:

custom_metadata parametresi, anahtar-değer çiftlerinden oluşan bir dizi kabul eder. Kategoriler veya ilaç sınıfları gibi metin meta verileri için string_value, yıllar, sürümler veya diğer sayısal veriler için numeric_value kullanın.

Yalnızca ilgili belgelerde arama yapmak için meta veri filtreleriyle sorgulayın:

query = "What are the common side effects?"

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name],
                    metadata_filter="category=diabetes"
                )
            )
        ]
    )
)Altyapı:

metadata_filter parametresi, getirimi belirtilen ölçütlerle eşleşen belgelerle sınırlar. Bu örnekte Dosya Arama, aynı mağazada bulunsalar bile category=diabetes meta verisine sahip belgeleri dikkate alır; tansiyon ve kolesterol ilaçlarını göz ardı eder.

Mağazalar heterojen belgeler içerdiğinde bu kritik hale gelir. Bir tıbbi bilgi tabanı, ilaç etiketleri, araştırma makaleleri ve klinik kılavuzları içerebilir. Belge türüne göre filtreleme, dozaj bilgisini özetlerden değil, etiketlerden almanızı sağlar.

Meta veri filtrelemeyi tam anlamsal arama yeteneğiyle birleştirebilirsiniz. Filtre önce aday belgeleri seçer, ardından anlamsal arama bu belgeler içinde en ilgili pasajları bulur.

Performans optimizasyonu

Dosya Arama performansı, mağaza boyutuna, sorgu karmaşıklığına ve model seçimine bağlıdır. Aşağıdaki yönergeler getirimi hızlı ve maliyetleri makul tutar.

Mağaza boyutu sınırları: En iyi getirme gecikmesi için tek tek mağazaları 20 GB’ın altında tutun. Dosya Arama, belgelerinizle birlikte gömmeleri depolar ve gömmeler, orijinal dosyalarınızın yaklaşık üç katı yer kaplar. 7 GB’lık PDF koleksiyonu, indekslendikten sonra yaklaşık 21 GB depolama üretir ve önerilen sınırı aşar.

Bu sınıra yaklaştığınızda, kategoriye, zaman aralığına veya erişim modeline göre düzenlenmiş ayrı mağazalar oluşturun. Tıbbi asistan için, mevcut tüm ilaçları tek bir mağazada indekslemek yerine farklı ilaç kategorileri için ayrı mağazalar oluşturabilirsiniz.

Maliyet yapısı: Dosya Arama, indeksleme için 1 milyon token başına 0,15 $ ücret alır. Bir kez indeksledikten sonra, ek indeksleme maliyeti olmadan binlerce sorgu çalıştırabilirsiniz. Bu fiyatlandırma modeli, aynı belgelere tekrar tekrar sorgu yaptığınız okuma ağırlıklı iş yükleri için daha uygundur.

Model seçimi: Çoğu sorgu için gemini-2.5-flash kullanın. 1-2 saniyede işlem yapar ve gemini-2.5-pro’ya kıyasla belirgin biçimde daha ucuzdur. gemini-2.5-pro’yu yalnızca birden çok kaynağı kapsayan derin akıl yürütme veya son derece karmaşık sentez görevleri için ayırın. Yüksek hacimli uygulamalarda modeller arasındaki maliyet farkı, indeksleme maliyetlerinden daha fazla önem taşır.

Belge ekledikçe mağaza boyutunu izleyin. Bunu API üzerinden kontrol edebilirsiniz, ancak boyut hesaplaması Google’ın arka ucunda yapılır ve yüklemelerden hemen sonra yansımayabilir. Tam teknik özellikler ve sınırlar için Gemini Dosya API belgelerine bakın.

Birden fazla mağazayı yönetme

Her Google Cloud projesi en fazla 10 Dosya Arama mağazasını destekler. Birden fazla mağaza, belgeleri erişim kontrolü, performans gereksinimleri veya mantıksal organizasyona göre ayırmanıza olanak tanır.

Farklı kullanım senaryoları için uzmanlaşmış mağazalar oluşturun:

# Create separate stores for different document categories
diabetes_store = client.file_search_stores.create(
    config={"display_name": "diabetes-medications"}
)

cardio_store = client.file_search_stores.create(
    config={"display_name": "cardiovascular-medications"}
)Altyapı:

Tek bir istekte birden fazla mağazayı sorgulayın:

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="What medications treat both diabetes and heart disease?",
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[
                        diabetes_store.name,
                        cardio_store.name
                    ]
                )
            )
        ]
    )
)Altyapı:

Dosya Arama, belirtilen tüm mağazalardan getirir ve sonuçları sentezler. Temellendirme meta verileri, her atfın hangi mağazadan geldiğini belirterek tam izlenebilirliği korur. 

Mağazalar süresiz olarak kalıcıdır ve artık gerekmediğinde elle silinmeleri gerekir; bu da belgelerin oturumlar ve dağıtımlar arasında sorgulanabilir kaldığı üretim uygulamaları için onları uygun kılar.

Sırada, Dosya Arama’nın diğer RAG çözümleriyle nasıl karşılaştırıldığı ve ne zaman yönetilen yaklaşımların, ne zaman da DIY yaklaşımların seçileceği yer alıyor.

Google Dosya Arama Aracı vs Diğer Dosya Arama ve RAG Araçları

RAG uygulamaları geliştirmek için tek seçeneğiniz Dosya Arama değil. Alternatiflerle nasıl karşılaştırıldığını anlamak, doğru aracı seçmenize yardımcı olur. Hadi Google’ın yaklaşımını OpenAI’ın sunduğu seçenek ve geleneksel özel kurulumlarla karşılaştıralım.

Google Dosya Arama vs OpenAI Dosya Arama

Her iki şirket de barındırılan RAG sunuyor, ancak fiyatlandırma ve yeteneklerde farklı yollar izliyorlar.

Fiyatlandırma: Google, indeksleme sırasında bir kez ücretlendirir (bin sorgu başına 2,50 $ artı depolama için günlük GB başına 0,10 $). Çok sayıda sorgu çalıştırıp belgeleri nadiren güncelliyorsanız, Google’ın modeli tasarruf sağlar. Sürekli yeniden indeksleme yapıyorsanız, hesap değişir.

Yapılandırma kontrolü: Google, otomatik parçalama ve sınırlı yapılandırmayla işleri basit tutar. OpenAI ise size daha fazla kontrol verir. Parça boyutunu (varsayılan 800 token) ve örtüşmeyi (400 token) ayarlayabilirsiniz. OpenAI, vektör ve anahtar kelime eşleştirmeyi birleştiren hibrit arama yürütürken Google yalnızca anlamsal aramaya dayanır. Bu, sorgularınız belirli teknik terimler veya ürün kodları içerdiğinde önem kazanır.

Dosya formatları: Google 150+ dosya türünü, kod dosyaları ve çeşitli belge formatları dahil olmak üzere destekler. OpenAI altı türü destekler: TXT, MD, HTML, DOCX, PPTX ve PDF. Hiçbiri CSV veya JSONL gibi yapılandırılmış verileri iyi yönetmez. Özel kurulumlar burada öne çıkar.

Entegrasyon: Google, Gemini modelleri ve Google Cloud hizmetleriyle bütünleşir. OpenAI, kendi model ailesi ve Azure ile bağlanır. Her ikisi de atıflar ve kaynak takibi sunar.

Gerçek ayrım sadelik ile kontrol arasındadır. Google her şeyi tek bir API çağrısına sarar. OpenAI ise daha fazla karmaşıklık pahasına getirimi ayarlamanıza izin verir. Burada tek bir kazanan yok. Projenizde hız mı yoksa özelleştirme mi istediğinize bağlıdır.

Özel RAG yetenekleri

LangChain gibi araçlarla kendi RAG sisteminizi kurmak, barındırılan hizmetlerin sunmadığı yeteneklerin kilidini açar. DataCamp’in LangChain ile RAG kursu bu yaklaşımı ayrıntılı biçimde ele alır.

Özel kurulumlar, gelişmiş teknikleri etkinleştirir:

• Anlamsal bölme: Sabit uzunluklarda kesmek yerine konu değişimlerini tespit eder
• Token farkında parçalama: Model bağlam pencerelerine tam uyum sağlar
• Hibrit getirme: BM25 anahtar kelime aramasını yoğun vektörlerle harmanlar
• Sorgu dönüşümleri: Aramayı iyileştirmek için varsayımsal yanıtlar üreten HyDE gibi yöntemler
• Graf RAG: Belgeleri varlıklar ve ilişkiler ağları olarak temsil eder

DataCamp’in RAG performansını iyileştirme öğreticisi, ölçülebilir kalite iyileştirmeleri gösteren örneklerle bu teknikleri inceler. Takas ise operasyonel karmaşıklıktır: veritabanı performansını izler, gömme modellerini ayarlar ve birden çok hizmette güncellemeleri yönetirsiniz.

Her yaklaşım ne zaman kullanılmalı

Dosya Arama gibi barındırılan araçları şunlarda seçin:

• Hızın önemli olduğu prototipler veya kavram kanıtları oluştururken
• Kullanım senaryonuz standart kalıplara uyduğunda (belgeler üzerinde S&C, bilgi tabanları, dokümantasyon arama)
• Ekibinizde derin RAG uzmanlığı olmadığında
• Öngörülebilir maliyetler ve asgari operasyonel yük istediğinizde

Şunlarda özel kurun:

• Gelişmiş parçalama veya uzmanlaşmış getirme yöntemlerine ihtiyaç duyduğunuzda
• Yapılandırılmış veriler veya alışılmadık dosya formatlarıyla çalışırken
• Çoklu stratejileri birleştiren eyletimli RAG sistemleri kurarken
• Masif ölçekte maliyet optimizasyonu, mühendislik yatırımını haklı çıkardığında
• Uyumluluk belirli altyapı veya modeller gerektirdiğinde

Çoğu proje, gereksinimler zorunlu kılana kadar barındırılan çözümlerle başlar ve ancak o zaman özel kurulumlara geçer. Özel RAG’den gelen teknikler (akıllı parçalama, hibrit arama, sorgu optimizasyonu), barındırılan araçları nasıl kullandığınızı da şekillendirir. Tam tabloyu anlamak, ihtiyaçlarınız geliştikçe daha iyi seçimler yapmanıza yardımcı olur.

Sonuç

FDA ilaç etiketlerini indekslemekten atıflarla sorgulamaya kadar Google Dosya Arama Aracı kullanarak eksiksiz bir RAG sistemi kurdunuz. Tıbbi asistan, yönetilen hizmetlerin altyapıyı nasıl üstlendiğini ve sizin uygulama mantığına odaklanabildiğinizi gösterir.

Dosya Arama, vektör veritabanlarını veya gömme hatlarını yönetmeden güvenilir RAG gerektiğinde iyi çalışır. Ücretsiz depolama ve sorgu gömmeleri maliyetleri öngörülebilir kılar. Kalıcı mağazalar yeniden indeksleme yükünü ortadan kaldırır ve altyapı bakımını ölçeklendirmeden sorguları ölçeklendirmenize olanak tanır.

Üretime geçmeden önce, kısalık adına bu eğitimde yer verilmeyen kritik korumaları ekleyin. Yükleme işlemleri için zaman aşımlarıyla hata yönetimi ve API çağrılarında try-catch blokları uygulayın. Özellikle hassas içeriklerde, belgeleri Google’ın sunucularına yüklerken veri gizliliği etkilerini değerlendirin. Atıflara erişmeden önce temellendirme meta verilerinin varlığını doğrulamak için doğrulama ekleyin. Model, temellendirmeye rağmen makul görünen ancak yanlış yanıtlar üretebileceğinden, alan uzmanlarıyla kapsamlı testler yapın.

Sonraki adımlar için, belgeleri kategoriye göre düzenlemek amacıyla asistanınızı meta veri filtreleme ile genişletmeyi deneyin. Belge türlerinize uyacak parça boyutlarıyla deney yapın. Burada öğrendiğiniz teknikler, ister destek botları, ister dokümantasyon araması, ister bilgi asistanları geliştirin, geçerlidir.