<p><strong>Karpathy’nin LLM kullanım yaklaşımından veri profesyonelleri için çıkarımlar</strong><br></p><img src="https://ezycourse.b-cdn.net/6009/cmvj8l3iv5tgo01z8f1mr6oca.png" alt="image" style="height: auto; cursor: pointer;"><p>Bir sorgu düşünün: Hata vermiyor. Beklenen kolonları döndürüyor. Dashboard’a bağlandığında grafikler de gayet güzel görünüyor.</p><p>Ama satışları iki kez sayıyor.</p><p>Bu varsayımsal örnekte sorun SQL sözdiziminde değil; sipariş tablosuyla sipariş kalemleri arasındaki ilişkinin yanlış kurulmasında. Dil modeli sorguyu üretmiş, veritabanı çalıştırmış, görselleştirme aracı sonucu çizmiş. Buna rağmen iş sorusuna verilen yanıt yanlış.</p><p>Veri profesyonelleri için LLM kullanımının en önemli sorularından biri burada başlıyor: <strong>Üretilen cevabın doğru olduğunu nasıl bileceğiz?</strong></p><p>Andrej Karpathy’nin <em>How I use LLMs</em> anlatımını bu soruyla birlikte ele aldığımızda, gündelik araç kullanımının ötesinde değerli bir tartışma açılıyor: Analiz üretimini hızlandırırken doğruluğu nasıl koruyabiliriz?</p><h2 id="2d8f13f5-5864-4ff3-90da-562f3a758c91" data-toc-id="2d8f13f5-5864-4ff3-90da-562f3a758c91" style="text-align: left; font-size: 24px; line-height: 1.2;">Bir grafiğin içindeki sessiz varsayım</h2><p>Karpathy, veri analizi örneğinde modelin eksik bir değeri kod içinde kendiliğinden sayıya dönüştürdüğünü gösteriyor. Ardından üretilen hesaplama çıktısıyla modelin yazılı açıklaması arasında tutarsızlık yakalıyor. Özgün videonun 01:04:35–01:08:58 bölümü, özellikle bu nedenle izlenmeye değer. [1]</p><p>Bu örnekten veri işi için çıkardığım sonuç şu: <strong>Bir araçla hesaplama yapılmış olması, analizin bütününün doğrulandığı anlamına gelmiyor.</strong></p><p>Hesaplama doğru çalışabilir; fakat hangi satırların hesaba katıldığı, eksik verinin nasıl ele alındığı veya sonucun hangi birimle sunulduğu hâlâ yanlış olabilir.</p><p>Aşağıdaki çalışma önerileri, videodan hareketle geliştirdiğim veri mühendisliği ve analitik uygulamalarıdır. SQL, metrik ve iş akışı örnekleri bu yazı için hazırlanmıştır.</p><h2 id="6971bb92-951f-4799-b6b8-d3c659c0435d" data-toc-id="6971bb92-951f-4799-b6b8-d3c659c0435d" style="text-align: left; font-size: 24px; line-height: 1.2;">1. İş tanımını modele bırakmayın</h2><p>“Aylık ciroyu hesapla” ifadesi, bir veri ekibi için tamamlanmış bir gereksinim değildir.</p><p>Sipariş tarihi mi, fatura tarihi mi kullanılacak? İptaller dahil mi? İadeler hangi döneme yazılacak? Vergi dahil mi? Farklı para birimleri hangi kurla birleştirilecek?</p><p>Bu soruların yanıtı belirlenmeden üretilen sorgu, teknik olarak kusursuz olsa bile kurumun kullandığı metriği hesaplamayabilir.</p><p>Bu nedenle LLM ile çalışmaya başlamadan önce küçük bir <strong>metrik sözleşmesi</strong> hazırlamayı öneriyorum: İş sorusu, hesaplama kuralı, kayıtların temsil ettiği seviye, kullanılacak tarih ve hariç tutulacak durumlar açık olsun.</p><p>Örneğin “aktif müşteri” demek yerine, bu çalışma için “son 90 günde en az bir tamamlanmış siparişi bulunan tekil müşteri” tanımını verin. Tamamlanmış siparişin statü karşılığını da ekleyin. Tanım eksikse modelin bunu işaretlemesini isteyin.</p><p>Veri profesyonelinin uzmanlığı, burada doğru soruyu hesaplanabilir bir tanıma dönüştürür.</p><h2 id="f3425ac8-dd0c-4a17-ba6e-2346e332ac41" data-toc-id="f3425ac8-dd0c-4a17-ba6e-2346e332ac41" style="text-align: left; font-size: 24px; line-height: 1.2;">2. Bağlamı bir veri ürünü gibi hazırlayın</h2><p>Karpathy, konuşmanın bağlamını sınırlı bir çalışma belleği üzerinden açıklıyor; belge ekleme ve araç kullanımıyla modele bilgi sağlama yollarını gösteriyor. [1]</p><p>Bizim işimizde bunun karşılığı, modele yalnızca tablo isimlerini göndermekle yetinmemek.</p><p>Bir sipariş tablosunda satır başına tek sipariş bulunabilir. Diğerinde aynı siparişin her durum değişimi ayrı satır olabilir. İkisinin kolon isimleri birbirine benzese bile doğru sorguları farklıdır.</p><p>Benim önerdiğim bağlam paketi şu parçaları içeriyor: ilgili şema, her tablonun kayıt seviyesi, anahtarlar, beklenen ilişki çoklukları, metrik tanımı ve birkaç temsilî örnek. Örnekler sentetik olabilir; önemli olan kuralları doğru göstermeleri.</p><p>Anthropic’in bağlam mühendisliği yaklaşımı da modelin erişeceği bilgiyi seçme ve güncel tutma işine odaklanıyor. [2] Veri ekipleri açısından bu, katalog ve dokümantasyonun LLM destekli çalışmada da doğrudan kullanılabilmesi demek.</p><p>Konu değiştiğinde gerekli bilgileri yeni bir görev bağlamına taşımak faydalı olabilir. Aynı analizin ortasında kritik tanımları kaybetmek ise tam tersine zarar verir. Ölçüt, sohbetin uzunluğu kadar içindeki bilginin görevle ilgisidir.</p><h2 id="665bb889-e38a-4257-ad03-843830764a4b" data-toc-id="665bb889-e38a-4257-ad03-843830764a4b" style="text-align: left; font-size: 24px; line-height: 1.2;">3. NULL ile sıfır arasındaki kararı görünür kılın</h2><img src="https://ezycourse.b-cdn.net/6009/cmvj98rgy64pp01z87afr6sok.png" alt="image" style="height: auto; cursor: pointer;"><p>Sentetik bir örnek üzerinden ilerleyelim. Üç kaydımız olsun: 100, bilinmiyor ve 200.</p><p>Bilinen iki değerin ortalaması 150’dir. Bilinmeyen değeri sıfıra çevirip üç kaydın ortalamasını alırsak sonuç 100 olur. Aynı veri, farklı varsayımla farklı bir hikâye anlatır.</p><p>Bu nedenle modelden yalnızca kod istemek yerine, <strong>uyguladığı veri dönüşümlerini de istemeliyiz</strong>:</p><ul><li><p>Eksik değerler için ne yaptın?</p></li><li><p>Tekrarlı kayıtları hangi anahtarla belirledin?</p></li><li><p>Hangi filtreler satır sayısını değiştirdi?</p></li><li><p>Tarih ve para birimi dönüşümlerinde hangi kuralları kullandın?</p></li></ul><p>Her dönüşüm yanlış değildir. Sorun, kararın açıklanmadan uygulanmasıdır. Eksik bir bilgiyi iş kuralına göre tamamlamakla bilinmeyeni tahmin ederek doldurmak arasında ciddi bir fark var.</p><h2 id="d2d1d87b-abe8-4b86-b2eb-fc7a1c3c608a" data-toc-id="d2d1d87b-abe8-4b86-b2eb-fc7a1c3c608a" style="text-align: left; font-size: 24px; line-height: 1.2;">4. Doğrulamayı dört ayrı noktada yapın</h2><img src="https://ezycourse.b-cdn.net/6009/cmvj99fhl63gc01xv0abs38pb.png" alt="image" style="height: auto; cursor: pointer;"><p>“Bir kez daha kontrol et” talebini tek başına yeterli bulmuyorum. Modelin aynı yaklaşımı tekrar etmesi, hatayı bağımsız biçimde yakaladığımız anlamına gelmez.</p><p>Bunun yerine dört kontrol noktası öneriyorum:</p><div><div><div><div class="tableWrapper"><table style="min-width: 75px;"><colgroup><col><col><col></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Kontrol</p></th><th colspan="1" rowspan="1"><p>Sorulacak soru</p></th><th colspan="1" rowspan="1"><p>İncelenecek kanıt</p></th></tr><tr><td colspan="1" rowspan="1"><p>Girdi</p></td><td colspan="1" rowspan="1"><p>Doğru kapsamla mı başladık?</p></td><td colspan="1" rowspan="1"><p>Kaynak, dönem, satır sayısı ve eksik değerler</p></td></tr><tr><td colspan="1" rowspan="1"><p>Dönüşüm</p></td><td colspan="1" rowspan="1"><p>Kayıtların anlamı korundu mu?</p></td><td colspan="1" rowspan="1"><p>JOIN öncesi/sonrası sayımlar, anahtar tekilliği ve filtreler</p></td></tr><tr><td colspan="1" rowspan="1"><p>Hesaplama</p></td><td colspan="1" rowspan="1"><p>Tanımlanan metrik üretildi mi?</p></td><td colspan="1" rowspan="1"><p>Küçük örnek üzerinde elle hesap ve bağımsız kontrol sorgusu</p></td></tr><tr><td colspan="1" rowspan="1"><p>Sunum</p></td><td colspan="1" rowspan="1"><p>Açıklama gerçekten çıktıyla aynı mı?</p></td><td colspan="1" rowspan="1"><p>Grafik, tablo, birim, dönem ve metindeki rakamların karşılaştırılması</p></td></tr></tbody></table></div></div></div></div><p>Örneğin müşteri boyut tablosuna yapılan bir bağlantıdan sonra satış toplamı artıyorsa, “sorgu çalıştı” kontrolünü geçmiş olmamız yetmez. İlişki çokluğunu araştırmamız gerekir.</p><p>Bu yaklaşımı BigQuery, SQL Server, Python veya BI aracı fark etmeksizin uygulayabiliriz. Kontrolün kendisi, seçtiğimiz aracın önüne geçer.</p><h2 id="5a2f74ee-7d5e-4dc3-ac53-9afec0ea916e" data-toc-id="5a2f74ee-7d5e-4dc3-ac53-9afec0ea916e" style="text-align: left; font-size: 24px; line-height: 1.2;">5. Göreve göre model ve araç seçin</h2><img src="https://ezycourse.b-cdn.net/6009/cmvj9bkr365op01z88bv6fkpv.png" alt="image" style="height: auto; cursor: pointer;"><p>Karpathy’nin anlatımında model seçimi, arama, kod çalıştırma ve kaynak kontrolü ayrı başlıklardır. [1]</p><p>Veri işinde de ihtiyaçları ayırmak faydalı. Bir sorguyu açıklatmakla üretim verisini analiz etmek aynı görev değil. SQL taslağı üretmek, veritabanında sorgu çalıştırıldığı anlamına gelmez. Güncel bir ürün özelliğini sormak da kurum içindeki metrik tanımını öğrenmekten farklıdır.</p><div><div><div><div class="tableWrapper"><table style="min-width: 75px;"><colgroup><col><col><col></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Görev</p></th><th colspan="1" rowspan="1"><p>Önerdiğim çalışma biçimi</p></th><th colspan="1" rowspan="1"><p>Teslimden önce kontrol</p></th></tr><tr><td colspan="1" rowspan="1"><p>Analist: dönem karşılaştırması</p></td><td colspan="1" rowspan="1"><p>Tanımlanmış metrik ve doğrulanmış veri üzerinde hesaplama</p></td><td colspan="1" rowspan="1"><p>Aynı dönem, kapsam ve para birimi</p></td></tr><tr><td colspan="1" rowspan="1"><p>Veri mühendisi: dönüşüm geliştirme</p></td><td colspan="1" rowspan="1"><p>Şema ve örneklerle kod taslağı üretme</p></td><td colspan="1" rowspan="1"><p>Tekrarlı çalıştırma, kayıt kaybı ve bağımlılıklar</p></td></tr><tr><td colspan="1" rowspan="1"><p>Analytics engineer: modelleme</p></td><td colspan="1" rowspan="1"><p>Kayıt seviyesi ve ilişki kurallarıyla model tasarlama</p></td><td colspan="1" rowspan="1"><p>Tekillik, ilişkiler ve iş tanımı</p></td></tr><tr><td colspan="1" rowspan="1"><p>BI geliştiricisi: raporlama</p></td><td colspan="1" rowspan="1"><p>Doğrulanmış sonuçtan görsel ve açıklama üretme</p></td><td colspan="1" rowspan="1"><p>Filtreler, toplamlar ve metin tutarlılığı</p></td></tr></tbody></table></div></div></div></div><p>Aracı başarıyla kullanmak, doğru görevi doğru yeteneğe yönlendirebilmeyi gerektirir. Kod çalıştırıldıysa hangi veriyle çalıştırıldığını; çalıştırılmadıysa çıktının yalnızca bir öneri olduğunu bilmeliyiz.</p><h2 id="8f4691ca-0e3a-42ec-b5b1-a30595cd3b5b" data-toc-id="8f4691ca-0e3a-42ec-b5b1-a30595cd3b5b" style="text-align: left; font-size: 24px; line-height: 1.2;">6. Bir sonraki analizinize bu çalışma talebiyle başlayın</h2><p>Aşağıdaki metni kurumunuzdaki göreve uyarlayabilirsiniz:</p><blockquote><p>Bu analizde iş sorusu, metrik tanımı, tablo şemaları ve kayıt seviyeleri aşağıdadır. Önce eksik tanımları ve belirsiz ilişkileri listele. Cevabı etkileyen bilgi eksikse varsayım yaparak ilerleme.</p><p>Ardından çözüm planını ve SQL/Python taslağını hazırla. Eksik değer, tekrar, tarih ve birim dönüşümlerini açıkla. Yapılmayan bir çalıştırmayı yapılmış gibi sunma.</p><p>Sonucu doğrulamak için küçük bir örnek, beklenen çıktı ve bağımsız kontrol sorguları öner. Nihai açıklamadaki rakamları hesaplama çıktısıyla karşılaştır. Veriyle desteklenmeyen nedenleri hipotez olarak işaretle.</p></blockquote><p>Bu metin tek başına güvenilirlik garantisi sağlamaz. Değeri, beklediğimiz davranışı ve kontrol noktalarını görünür kılmasıdır.</p><h2 id="7a4445b0-6c24-4ca0-8eed-e995bbb98983" data-toc-id="7a4445b0-6c24-4ca0-8eed-e995bbb98983" style="text-align: left; font-size: 24px; line-height: 1.2;">Hızı, teslim edilebilir sonuç üzerinden ölçün</h2><p>LLM kullanımını değerlendirirken yalnızca ilk sorgunun kaç saniyede üretildiğine bakarsak işin önemli bir bölümünü kaçırabiliriz.</p><p>Ölçmemiz gereken süre; taslak üretimini, incelemeyi, düzeltmeyi ve doğrulamayı kapsamalı. Daha hızlı yazılan ama daha uzun incelenen bir sorgunun katkısını ancak böyle anlayabiliriz.</p><p>Bir ekip denemesinde aynı tür görevler için toplam teslim süresini, yakalanan anlam hatalarını ve yeniden çalışma ihtiyacını kaydetmeyi öneriyorum. Böylece faydayı kendi işlerimiz üzerinden değerlendirebiliriz.</p><p>LLM’ler SQL yazmayı, kod taslağı hazırlamayı ve analiz anlatısını hızlandırabilir. Veri profesyonelinin katkısı ise iş tanımında, bağlamın kalitesinde ve sonuca duyduğu güveni kanıtlayabilmesinde ortaya çıkar.</p><p><strong>Bir sonraki AI destekli analizinizde şunu sorun: Bu sonucun doğruluğunu hangi kanıtla savunabilirim?</strong><br><br><strong>Kaynak ve kapsam notu</strong></p><p>[1] Andrej Karpathy, <a target="_blank" href="https://www.youtube.com/watch?v=EWvNQjAaOHw">How I use LLMs</a>, Şubat 2025. Bağlam: 00:02:54; model seçimi: 00:18:03; akıl yürütme: 00:22:54; arama: 00:31:00; belge ekleme: 00:50:57; Python: 00:59:00; veri analizi: 01:04:35; NotebookLM: 01:37:09. Kullanıcı tarafından paylaşılan <a target="_blank" href="https://www.youtube.com/watch?v=7YEHs2SMaVQ">video</a> aynı anlatımdan içerik taşıyan farklı bir yüklemedir; bölüm zamanları iki sürümde farklıdır.</p><p>[2] Anthropic, <a target="_blank" href="https://www.anthropic.com/research/effective-context-engineering-for-ai-agents">Effective context engineering for AI agents</a>, 29 Eylül 2025.</p><p>Bu yazı, kaynaklardan hareketle veri profesyonelleri için hazırlanmış özgün bir değerlendirmedir; konuşmanın çevirisi veya tam özeti değildir. SQL senaryoları, kontrol tabloları ve çalışma talebi yazara ait uygulama önerileridir.</p>

LLM’in yazdığı SQL çalışabilir; peki doğru sonucu üretiyor mu? Bağlam yönetimi, metrik tanımı ve AI destekli analizlerde sonuçları doğrulamanın yollarını ele alıyoruz.

LLM’in Yazdığı SQL Çalışıyor. Peki Doğru mu?

2. Bağlamı bir veri ürünü gibi hazırlayın

3. NULL ile sıfır arasındaki kararı görünür kılın

4. Doğrulamayı dört ayrı noktada yapın

6. Bir sonraki analizinize bu çalışma talebiyle başlayın

Hızı, teslim edilebilir sonuç üzerinden ölçün

Read articles, tips, and resources to help you learn, grow, and succeed. Explore our latest posts covering education, community, and personal growth

Blog – Insights, Tips & Resources for Learning and Growth

Explore articles, tips, and insights to help you succeed in learning, community building, and personal development.

LLM’in Yazdığı SQL Çalışıyor. Peki Doğru mu?

LLM’in Yazdığı SQL Çalışıyor. Peki Doğru mu?

Related Posts