BigQuery'de Otonom Veri Ajanlarını Maliyetten Koruma
Otonom veri ajanları BigQuery'de kontrolsüz sorgularla yüksek maliyetlere yol açabilir; dry-run tarama ve token bütçesi korumaları bu riski nasıl önlüyor?
LLM tabanlı otonom ajanlar, açık uçlu analiz sorularını insan gibi deneme-yanılma yaparak çözebiliyor: sorgu dener, garip sonuç alır, farklı açıdan tekrar dener. Ancak sütun tabanlı BigQuery gibi ısıtmalarda LIMIT ya da WHERE ifadeleri maliyeti düşürmez; sistem sorguyu çalıştırmadan önce ilgili tüm sütunu tarar ve fatura buna göre kesilir. Bir ajanın on beş turluk keşif döngüsü, yüz terabayt ölçeğindeki tablolarda tek başına binlerce dolarlık faturaya dönüşebilir.
Bu yazıda anlatılan yaklaşım, Google Antigravity SDK ile Data Agent Kit (DAK) uzantısını birleştirerek maliyet açısından güvenli bir ajan mimarisi kuruyor. DAK, BigQuery bağlantılarını MCP araçları ve önceden paketlenmiş 'skill' dizinleri üzerinden soyutlarken, Antigravity SDK katmanı gerçek denetim mantığının yaşadığı yer oluyor: her SQL sorgusu çalıştırılmadan önce ücretsiz bir dry-run ile taranacak bayt miktarı ölçülüyor, bütçeyi aşan sorgular reddedilip ajana neden reddedildiği bildiriliyor. Ayrıca oturum bazında bir token harcama sınırı aşıldığında ajan duraklatılıp insan onayı bekliyor.
Yöntem, Stack Overflow'un pandas ve numpy ile ilgili geliştirici etkileşiminin 2023 sonunda düşmesinin nedenini araştıran gerçek bir vaka üzerinden test ediliyor; ajan BigQuery'deki genel veri seti ile yerel bir PyPI indirme istatistiği CSV'sini birlikte sorguluyor. Mühendisler için önemi açık: veri ambarı üzerinde çalışan otonom ajanlar denetimsiz bırakıldığında bütçeyi hızla aşabiliyor, bu yüzden sorgu maliyeti ve token harcaması için harness seviyesinde guardrail'ler kurmak, agentic veri analizini üretime almanın ön koşulu haline geliyor.