Go ve Gemini File Search ile Düşük Maliyetli RAG: Vektör Veritabanı Yok, İki Çağrı, Tek Barındırılan Depo

Her yazılım ekibinde benzer bir kurumsal hafıza rafı bulunur: herkesin önerdiği temel mühendislik kitapları, mimari değerlendirmelerde paylaşılan teknik yazılar ve kimsenin tekrar okumadığı onlarca postmortem dokümanı. "Bunu zaten bir kez öğrenmiştik" dedirten yaklaşık 1.4 milyon token'lık bu birikim için geleneksel yaklaşım; vektör veritabanı, embedding hattı, chunker ve reranker içeren karmaşık bir RAG (Retrieval-Augmented Generation) mimarisi kurmaktır. Oysa LiveReview geliştiricisi Maneshwar, bu süreci hiçbir harici altyapı bileşeni olmadan, Go dili ve Gemini'ın ücretsiz katmanıyla çözdü.

Hedeflenen araç, sisteme bir tasarım önerisi veya postmortem taslağı girildiğinde üç net çıktı üretir:

Gerçekte neyin önerildiğinin özeti
Önerinin altında yatan temel mimari desen
Kurumsal hafızada bu yapıyla daha önce karşılaşılan 3 referans kaynak

"R" ile Uğraşmadan RAG: Gemini File Search

Gemini platformunun File Search özelliği, RAG sürecindeki retrieval (erişim) yükünü geliştiricinin üzerinden alır. Bir "store" (depo) oluşturup dokümanlarınızı yüklediğinizde Google; metin parçalama, embedding üretimi ve indeksleme işlemlerini kendi altyapısında halleder. Bu depoyu standart bir generateContent çağrısına araç (tool) olarak bağladığınızda, model yanıt üretirken depoda arama yapar ve kullandığı metin parçalarını groundingMetadata içinde döner.

Bu yaklaşımın geliştiriciler açısından getirdiği kritik avantajlar:

Maliyet Verimliliği: Depolama ve sorgu anındaki embedding işlemleri ücretsizdir. Yalnızca indeksleme anında embedding ücreti ödenir; sorgu sırasında çekilen parçalar ise standart bağlam token'ı olarak faturalandırılır. 1 GB ücretsiz kota sunulurken, Markdown'a dönüştürülmüş tüm birikim yalnızca 5.3 MB yer tutar.
Sıfır Altyapı: pgvector, Pinecone veya bağımsız bir embedding modeli yönetme zorunluluğu ortadan kalkar.

Uygulamanın üretim mimarisi son derece sadedir:

Tek bir Go derlemesi (binary)
Cgo bağımlılığı bulunmayan modernc.org/sqlite
İstek ve yanıt gövdelerini şeffafça loglamak için SDK yerine saf REST istemcisi
Soru başına sadece iki model çağrısı
Tek bir barındırılan doküman deposu

Sıfırıncı Adım: Boşlukları Kaybetmeden Dokümanları Markdown'a Dönüştürmek

RAG başarısı veri hazırlığının kalitesine doğrudan bağlıdır. Dokümanları metne dönüştürme sürecinde yazar üç farklı araç denemiştir:

markitdown: Kelimeler arasındaki boşlukları kaybetmiş, bitişik kelimeler üreterek anlamsal aramayı ve embedding kalitesini bozmuştur.
pdftotext: Boşlukları korumuş ancak tüm başlık hiyerarşisini silerek yüzlerce sayfalık kitabı tek parça metne dönüştürmüştür.
pymupdf4llm: Yazı tipi boyutlarını analiz ederek başlıkları doğru tespit etmiş, kalın/italik biçimlendirmeleri korumuş ve boşluk sorununu başarıyla çözmüştür.

Yazılım Geliştirme Açısından Pratik Çıkarımlar

Bu vaka, kurumsal yapay zekâ projelerinde aşırı mühendislikten (over-engineering) kaçınmanın değerini gösterir:

Vektör veritabanı yönetmek yerine platformların yerleşik dosya arama araçlarını kullanmak bakım ve operasyon maliyetini sıfıra indirir.
PDF dönüşümünde başlık hiyerarşisinin korunması, modelin bağlamı doğru pencerelere ayırması için hayati önem taşır.
Üretim ortamında SDK soyutlamaları yerine doğrudan REST API kullanmak, ağ seviyesinde tam hata ayıklama ve gözlemlenebilirlik sağlar.

[Orijinal kaynağa buradan ulaşabilirsiniz.](https://dev.to/lovestaco/cheap-rag-in-go-with-gemini-file-search-no-vector-db-two-calls-one-hosted-store-4kb5)