- OpenAI, 3.500’den fazla iç kullanıcı ve 600 PB ölçekli veriyi verimli biçimde analiz etmek için özel yapım bir yapay zeka veri ajanı geliştirdi
- Yalnızca doğal dilde sorularla tablo keşfi, SQL çalıştırma, notebook ve rapor yayımlamaya kadar uçtan uca analiz iş akışını otomatik olarak yürütüyor
- Doğruluğu sağlamak için 6 katmanlı bağlamı birleştiriyor: tablo kullanımı, insan notları, Codex tabanlı kod analizi, kurumsal bilgi, bellek ve çalışma zamanı bağlamı
- Ara sonuçlar hatalıysa nedenini kendi başına araştırıp yaklaşımını düzelten öz-öğrenimli kapalı döngü yapısıyla çalışıyor
- Evals API tabanlı sistematik değerlendirme sistemiyle kalite gerilemelerini erken tespit ediyor ve mevcut güvenlik/yetki modelini aynen devralarak güvenilirliği koruyor
Neden özel bir veri ajanına ihtiyaç var?
- OpenAI’nin veri platformunda 3.500’den fazla iç kullanıcı, 600 petabayt ölçekli veri ve 70 binden fazla veri kümesi bulunuyor; doğru tabloyu bulmak bile analizin en çok zaman alan işi haline geliyor
- Benzer tabloların çokluğu nedeniyle, çıkış yapmış kullanıcıların dahil edilip edilmediği ya da alan tekrarları gibi tablolar arasındaki farkları anlamak zorlaşıyor
- Doğru tablo seçilse bile many-to-many join, filter pushdown hataları ve null değerlerin ele alınmaması gibi sorunlar sonucu geçersiz kılabiliyor
- Analistlerin SQL debug etmek yerine metrik tanımı, varsayım doğrulama ve veri odaklı karar alma işlerine odaklanması gerekiyor
Ajan nasıl çalışıyor?
- GPT-5.2 tabanlı çalışıyor
- Slack ajanı, web arayüzü, IDE, Codex CLI (MCP entegrasyonu), şirket içi ChatGPT uygulaması gibi çalışanların zaten kullandığı ortamlardan erişilebiliyor
- Karmaşık ve açık uçlu soruları da işleyebiliyor
- Soruyu anlama
- Veri keşfi
- SQL çalıştırma
- Sonuç analizi ve özetlemeye kadar uçtan uca yürütme
- Örnek: NYC taksi veri kümesinde pickup-dropoff ZIP çiftleri arasında seyahat süresi oynaklığı en yüksek kombinasyonu analiz etmek
- Sabit bir scripti izlemek yerine kendi ilerleyişini değerlendiriyor; ara sonuçlar yanlışsa (ör. hatalı join veya filtre nedeniyle 0 satır dönmesi) nedeni araştırıp yaklaşımını değiştirerek yeniden deniyor
- Veri keşfi, SQL çalıştırma, notebook ve rapor yayımlama, iç bilgiye başvurma, web araması ve bellek tabanlı öğrenme dahil tüm analiz iş akışını kapsıyor
Bağlam katmanları
-
Katman 1: Tablo Kullanımı (Table Usage)
- Metadata grounding: Şema metadata’sını (sütun adları, veri tipleri) SQL yazımında kullanıyor; tablo lineage’ı (üst/alt tablo ilişkileri) ile tablolar arası ilişkileri kavrıyor
- Sorgu çıkarımı: Geçmiş sorguları toplayarak ajanın kendi sorgu yazma biçimini ve genellikle birlikte join edilen tablo kombinasyonlarını öğrenmesini sağlıyor
-
Katman 2: İnsan Notları (Human Annotations)
- Alan uzmanları, tablo ve sütunlar için özenle hazırlanmış açıklamalar yazarak niyet, semantik, iş bağlamı ve bilinen dikkat noktaları gibi şema veya geçmiş sorgulardan çıkarılması zor bilgileri aktarıyor
- Yalnızca metadata ile tabloları ayırt etmek zor olduğundan, üretim biçimi ve veri kaynağını anlama kritik önem taşıyor
-
Katman 3: Codex tabanlı kod analizi (Codex Enrichment)
- Verinin gerçek içeriğini daha derin anlamak için tabloların kod seviyesindeki tanımlarını çıkarıyor
- Değerlerin benzersizliği, tablo verisinin güncellenme sıklığı, veri kapsamı (belirli alanların hariç tutulup tutulmadığı, ayrıntı seviyesi) gibi analiz olay tabanlı nüanslar sağlıyor
- SQL’in yanı sıra Spark, Python gibi farklı veri sistemlerindeki kullanım bağlamını da anlayabiliyor
- Benzer görünen ama özünde farklı tabloları ayırt edebiliyor (ör. yalnızca 1st-party ChatGPT trafiğini içeren tablo olup olmadığı)
- Bu bağlam otomatik olarak güncelleniyor, bu yüzden manuel bakım gerekmiyor
-
Katman 4: Kurumsal Bilgi (Institutional Knowledge)
- Slack, Google Docs, Notion gibi kaynaklardan lansmanlar, kesinti vakaları, şirket içi kod adları, temel metriklerin resmi tanımları ve hesaplama mantığı gibi şirket bağlamını topluyor
- Dokümanları toplayıp embedding’e dönüştürüyor, metadata ve yetkilerle birlikte saklıyor; çalışma anında erişim kontrolü ve caching yapan bir arama servisi işletiyor
-
Katman 5: Bellek (Memory)
- Ajan düzeltme aldığında ya da veri sorularındaki nüansları fark ettiğinde bunu kaydederek bir sonraki analizde daha doğru bir başlangıç noktası sağlıyor
- Belleğin amacı, diğer katmanlardan çıkarılması zor olan açık olmayan düzeltmeleri, filtreleri ve kısıtları korumak ve yeniden kullanmak
- Örnek: Belirli bir analiz deneyini filtrelerken deney kapısında tanımlı özel bir string eşleştirmesi gerekiyordu; bellek olmadığında bulanık string eşleştirme denemesi yapma hatası ortaya çıkıyordu
- Düzeltme veya öğrenme tespit edildiğinde ajan bellek kaydını teşvik ediyor; kullanıcılar da bunu manuel olarak oluşturup düzenleyebiliyor
- Bellek kapsamı genel seviye ve kişisel seviye olarak ayrılıyor
-
Katman 6: Çalışma Zamanı Bağlamı (Runtime Context)
- Bir tablo hakkında önceden bağlam yoksa veya bilgi güncel değilse, veri ambarına canlı sorgular göndererek şemayı doğruluyor ve gerçek zamanlı veriyi inceliyor
- Metadata servisleri, Airflow, Spark gibi Data Platform içindeki diğer sistemlerle de iletişim kurarak ambar dışı veri bağlamı ediniyor
-
Günlük offline pipeline ve RAG
- Tablo kullanımı, insan notları ve Codex tabanlı zenginleştirmeyi tek bir normalleştirilmiş gösterimde bir araya getiren günlük bir offline pipeline işletiyor
- Zenginleştirilmiş bağlamı OpenAI Embeddings API ile embedding’e dönüştürüp saklıyor; sorgu anında RAG (Retrieval-Augmented Generation) ile yalnızca ilgili bağlamı getiriyor
- On binlerce tablo genelinde tablo anlayışını hızlı ve ölçeklenebilir tutarken çalışma zamanı gecikmesini de öngörülebilir ve düşük seviyede koruyor
Ekip arkadaşı gibi düşünüp iş birliği yapan tasarım
- Tek seferlik yanıtlar yerine etkileşimli ve yinelemeli keşfi destekliyor; turlar arasında tam bağlamı koruduğu için takip sorularında veya yön değişimlerinde her şeyi baştan anlatmak gerekmiyor
- Ajan yanlış yöne gidiyorsa kullanıcı analiz sırasında araya girip yönlendirme yapabiliyor
- Talimat belirsizse proaktif biçimde netleştirme soruları soruyor; yanıt gelmezse makul varsayılanlarla (ör. son 7 gün veya 30 gün) ilerliyor
- Aynı analizin tekrar tekrar yapıldığı örüntüleri gözlemledikten sonra, yinelenen analizleri yeniden kullanılabilir workflow (instruction set) paketlerine dönüştürüyor
- Haftalık iş raporları ve tablo doğrulama buna örnek
- Bağlam ve en iyi uygulamalar bir kez kodlanarak kullanıcılar arasında tutarlı sonuçlar sağlanıyor
Güveni korurken hızlı iyileştirme sağlayan değerlendirme sistemi
- Sürekli evrilen bir ajan olduğu için kalite drift’i kolayca oluşabiliyor; sistematik değerlendirme olmadan gerilemeler görünmeden ilerleyebiliyor
- OpenAI Evals API tabanlı olarak soru-cevap çiftlerinden oluşan özenle hazırlanmış bir küme kuruyor ve her soruya manuel hazırlanmış bir "golden" SQL sorgusu eşliyor
- Doğal dilde soruyu sorgu üretim endpoint’ine gönderiyor, üretilen SQL’i çalıştırıyor ve beklenen SQL sonucu ile karşılaştırıyor
- Basit string eşleşmesi yerine hem SQL’i hem de sonuç verisini karşılaştırıp Evals grader’a vererek doğruluk ve kabul edilebilir sapmaları yansıtan nihai puan ve açıklama üretiyor
- Bu değerlendirme, geliştirme sırasında sürekli çalışan bir unit test işlevi görüyor ve prodüksiyonda bir canary gibi davranarak gerilemeleri erken yakalıyor
Ajan güvenliği
- OpenAI’nin mevcut güvenlik ve erişim kontrol modeliyle doğrudan entegre oluyor; aynı yetkileri ve guardrail’leri arayüz katmanında devralıp uyguluyor
- Tüm erişimler pass-through biçiminde ilerliyor; kullanıcı yalnızca zaten yetkili olduğu tabloları sorgulayabiliyor, yetkisi yoksa ajan bunu bildiriyor veya alternatif veri kümesine fallback yapıyor
- Şeffaflık için akıl yürütme sürecini görünür kılıyor: varsayımları ve yürütülen adımları yanıtla birlikte özetliyor, ayrıca çalıştırılan sorgunun ham sonuçlarına doğrudan bağlantı vererek kullanıcının tüm analiz adımlarını doğrulamasını sağlıyor
Geliştirme sürecinden çıkarılan dersler
-
Ders 1: Az daha fazladır (Less is More)
- Başta tüm araç seti ajana açılmıştı ancak işlev tekrarlarının yarattığı kafa karışıklığı ortaya çıktı
- İnsanların manuel çağrıda faydalı bulduğu tekrar eden işlevler, ajan için belirsizlik yarattığından belirli araç çağrıları sınırlandırılıp birleştirildi ve güvenilirlik artırıldı
-
Ders 2: Yolu değil hedefi yönlendir (Guide the Goal, Not the Path)
- Aşırı yönlendirici prompting, sonuçları tersine kötüleştirdi
- Her sorunun ayrıntısı farklı olduğundan katı talimatlar ajanı yanlış yola sürükleyebiliyor; bunun yerine yüksek seviyeli rehberlik verip yürütme yolunu GPT-5’in muhakemesine bırakmak daha iyi sonuç veriyor
-
Ders 3: Anlam kodda yaşar (Meaning Lives in Code)
- Şema ve sorgu geçmişi yalnızca tablonun biçimini ve kullanımını anlatır; asıl anlam tabloyu üreten kodda bulunur
- Pipeline mantığı varsayımları, güncellik garantilerini ve iş niyetini taşır; bunlar SQL veya metadata’da görünmez
- Codex ile kod tabanını tarayıp veri kümesinin gerçekte nasıl inşa edildiğini anlayarak, yalnızca veri ambarı sinyalleriyle mümkün olmayan "içinde ne var" ve "ne zaman kullanılabilir" sorularına doğru yanıt verebiliyor
Gelecek yönü
- Belirsiz soruları ele alma yeteneğini geliştirme, daha güçlü doğrulamayla güvenilirlik ve doğruluğu artırma ve workflow entegrasyonunu derinleştirme çalışmaları sürüyor
- Ayrı bir araç olmak yerine insanların zaten çalıştığı biçime doğal şekilde karışmayı hedefliyor
- Ajanın akıl yürütme, doğrulama ve kendi kendini düzeltme temel teknolojileri ilerledikçe sistem de gelişmeye devam ediyor ve
ekibin misyonu, OpenAI’nin veri ekosisteminin tamamında hızlı ve güvenilir veri analizini kesintisiz biçimde sunmak
1 yorum
Hacker News görüşleri
En büyük sorun güvenilirlik ve açıklanabilirlik
Biz Veezoo'da 10 yıldır doğal dil analizi geliştiriyoruz, ancak basit bir Text-to-SQL yaklaşımı ölçeklenebilir değil
CFO ciroyu sorduğunda %99 doğru bir sayı bir anlam ifade etmiyor ve CFO SQL'i doğrudan doğrulayamaz da
Bu yüzden Knowledge Graph adlı bir soyutlama katmanı kullanıyoruz; yapay zeka doğal dili anlam tabanlı bir sorgu diline dönüştürüyor, bunu da deterministik olarak SQL'e derliyor
Ters yönde ise bu anlamsal sorguyu yeniden doğal dil açıklamasına çevirerek kullanıcının sonucun niyetiyle uyuşup uyuşmadığını kolayca doğrulamasını sağlıyoruz
İş mantığı Knowledge Graph'ta bulunuyor ve derleyici tüm sorguların buna %100 uymasını garanti ediyor
Daha ayrıntılı yapı Veezoo Architecture dokümanında özetlenmiş
Merak ettiğim şey, cardinality explosion'ı nasıl yönettiğiniz ve önceki sorgu sonuçlarına dayanan çoklu sorgu isteklerini nasıl ele aldığınız
Hangi tarihte hangi sorgunun kullanıldığını ve nasıl doğrulandığını takip edebilmek gerekir
(Elbette prompt'lar da sürüm kontrolüne dahil olmalı)
İlk örneğin tamamen mantıksız olmasına şaşırdım
Bu insan incelemesinden geçtiyse muhtemelen AI yazmıştır ve öyleyse sistemin güvenilirliği konusunda soru işaretleri doğuruyor
Sorunlu görsel bağlantısı
Masaüstünde doğru prompt,
mobilde ise yanlış prompt var
Çeşitli BI sistemlerini kullanmış biri olarak, bunun gibi bir AI agent için bunun kusursuz bir kullanım alanı olduğunu düşünüyorum
BI'da hatalar zaten doğal olarak birden fazla katmanda ortaya çıkar — sorgunun kendisi yanlış olabilir ya da veriyi yorumlama biçimi yanlış olabilir
Bu ikisi birleştiğinde zaten bir 'hayali dünyaya' girmiş oluyorsunuz; bu yüzden 1. aşamayı AI'nın üstlenmesi daha iyi
OpenAI'nin güvenilirlik sorununu çözmüş olmasını umuyordum ama ne yazık ki öyle değilmiş
0. aşama: veri yanlış kaydedilir
-1. aşama: modelin kendisi yanlış anlaşılır
-2. aşama: iş süreci en baştan yanlıştır
Bu yüzden ben buna 'tek doğru kaynak' yerine 'tek yanlış kaynak' diyorum
Güveni ölçeklendirmek işin en zor kısmı
Biz de benzer bir şey inşa ediyoruz ama agent loop ne kadar iyi olursa olsun, sonunda insan eliyle kürasyon yapılmış standart metriklere (canonical metrics) ihtiyaç duyuluyor
Aksi halde teknik olmayan kullanıcılar doğrulanamayan SQL'e dayanarak riskli kararlar verebilir
Bizim yaklaşımımız şöyle:
Zamanla sorguların çoğu standart metrikleri kullanmaya başlıyor ve agent basit bir SQL üreticisi olmaktan çıkıp niyet→doğrulanmış metrik için akıllı bir yönlendiriciye dönüşüyor
“Güveni bozmadan hızlı hareket etmek” bölümündeki golden SQL değerlendirme sistemi de aynı içgörüyü içeriyor
İlgili yazıyı bu blog gönderisinde derledim
Cevaba giden birden fazla yol varsa farklı sonuçlar çıkıyor
LLM'ler sık sık 'xyz_index' gibi anlamsız metrikler uyduruyor ve kullanıcılar da kulağa makul geldiği için bunu doğrudan kullanıyor
Bana göre AI'nın geliştirici işlerine gerçek etkisi veri ve dokümantasyon kalitesi olacak
Bir şirketin verisinin ne kadar iyi düzenlendiği, AI kullanımından alınan verimi belirler
Açık veri zaten tükendi; sıradaki kaynak iç dokümantasyon, kod depoları ve data lake'ler
Bu temel yapısı güçlü olan şirketler AI ile yeni hizmetleri hızlı ve ucuza geliştirip sürdürebilir
Buna karşılık dokümantasyon ve kod yönetimi dağınık olan şirketlerde AI düzgün çalışmaz
Sonunda da pazarı rakiplere kaptırırlar
Bu yüzden bundan sonra iş ararken dokümantasyon, veri ve depo yönetimi seviyesini mutlaka soracağım
Amplitude'da Moda adlı benzer bir sistem geliştirdik
Birkaç ay önce Wade, Claire Vo'ya demo videosunu göstermişti ve gerçekten etkileyiciydi
Ben de bunu her gün çeşitli sorular sorarak kullanıyorum
Biz de Definite.app'de benzer işlevi 5 dakika içinde sunuyoruz
Spark ya da Snowflake gerekmiyor
Data lake, pipeline, semantic layer ve data agent'ı tek bir uygulamada sunuyoruz
Aslında agent'ın kendisinden çok veri altyapısını kurmak daha zor
Agent yalnızca SQL yazabiliyorsa sınırları büyük olur, ama biz altyapının kendisini de yönetebilir hale getirerek büyük bir dönüşüm noktası yarattık
Gerçekten çok iyi bir içerik
Ancak sonucun nasıl hesaplandığını açıklayan kısım eksik gibi görünüyor
OpenAI iç kullanımı için olduğundan, kullanıcının SQL okuyabildiği varsayımı kabul edilebilir; fakat teknik olmayan kullanıcılar için bu tasarım açısından büyük bir zorluk
Veri sistemleriyle uğraşınca, sadece 'cevap'ın değil, 'cevabın nasıl üretildiğinin' de en az onun kadar önemli olduğunu hemen anlıyorsunuz
Kişisel olarak Kimi'nin In-House Data Agent'ı daha ilginç buluyorum
Veri sorunu teknik bir sorun değil, organizasyonel bir sorun
Benim deneyimime göre veri sorunlarının nedeni 'yanlış teknoloji seçimi' değil, yönetişim ve sahiplik kararları
Sonuçta her şey Conway yasasına çıkıyor