
Yapay zeka ile veri analizi yaparken en büyük kazanım, tekrar eden işleri (ör. tutarsız değerleri yakalama, alan tiplerini önerme, kısa özet üretme, sorgu taslağı hazırlama) daha hızlı başlatmaktır. Ancak veri temizleme ve özellikle doğal dilden SQL üretimi gibi adımlarda çıktıyı doğrulamak şarttır. Çünkü model, şemanızı eksik anlayabilir veya varsayım yapabilir; sonuçlar veri setine, dile ve model sürümüne göre değişkenlik gösterebilir.
Prompt tasarımında açık talimat, örnekle yönlendirme (few-shot), hedeflenen çıktı formatını sabitleme ve düzenli değerlendirme (eval) yaklaşımı önerilir (OpenAI Prompt Engineering Best Practices). Üretimde kararlılık için model sürümünü/snapshot’ını pinlemek ve küçük bir test setiyle düzenli eval yapmak da aynı çerçevede ele alınır (OpenAI kılavuzu).
Her prompt şablonunda köşeli parantezleri kendi bağlamınızla değiştirin:
Not: Hakemli çalışmalar ve araştırma değerlendirmeleri, büyük dil modellerinin sıfır veya az örnekle bazı veri hazırlama (data wrangling) görevlerinde kullanılabildiğini; ancak başarının göreve ve veri setine göre değiştiğini vurgular (Springer 2022; Stanford Hazy Research 2023). Bu yüzden şablonları “ilk taslak üretici” gibi düşünün ve doğrulama katmanı ekleyin.
Amaç: Veri sözlüğü taslağı + olası tip/format problemleri.
Rolün: Veri analisti. Elimdeki CSV örneğini incele ve her kolon için: (1) önerilen veri tipi, (2) olası format sorunları, (3) örnek problemli değerler (maks. 3 adet) üret.
Çıktı formatı: JSON dizi. Her öğe: {"column":"...","suggested_type":"...","issues":[...],"examples":[...]}
Veri örneği:
[DATA_SAMPLE]Kural: Emin olmadığın noktalarda "needs_confirmation" alanını true yap ve soru sor.
Doğrulama: Tip önerilerini 20–50 rastgele satırda kontrol edin; tarih/para birimi/ondalık ayırıcılarının tutarlı olup olmadığına bakın.
Amaç: Hangi alanlar eksik, ne tür imputasyon mantıklı olabilir?
Rolün: Veri hazırlama uzmanı. Aşağıdaki veri örneğinde eksik/boş değerleri analiz et. Her kolon için: eksiklik türü (boş string, NULL, "N/A" vb.), olası kök neden, ve doldurma stratejisi öner ("doldurma" yerine "bırak" da önerebilirsin).
Çıktı formatı: JSON: {"column":"...","missing_patterns":[...],"recommendation":"...","risk":"low|medium|high"}
Veri örneği:
[DATA_SAMPLE]Kural: İstatistiksel oran hesaplamak için yeterli satır yoksa oran verme; sadece gözlemsel konuş.
Doğrulama: Önerilen stratejiyi uygulamadan önce hedef metriğe etkisini düşünün (ör. ortalama gelir). Kritik kolonlarda “bırakma/doldurma” kararını iş hedefiyle hizalayın.
Amaç: “CA”, “California”, “Calif.” gibi varyasyonları tekleştirmek.
Rolün: Veri temizleme. Aşağıdaki alanda aynı anlama gelen farklı kategorik değerleri normalize etmek istiyorum.
Hedef kolon: [COLUMN_NAME]
Veri örneği:
[DATA_SAMPLE]İstediğim çıktı:
- Bir eşleme sözlüğü: {"raw_value":"normalized_value"}
- Belirsiz durumlar listesi: hangi değerlerin insan onayı istediği ve neden
- Normalize edilmiş değerlerin kısa açıklaması
Kural: Yeni kategori uydurma; yalnızca örneklerde görülenleri gruplandır.
Doğrulama: Eşlemeyi uyguladıktan sonra “tekilleşen kategori sayısı” ve en sık 10 kategori listesini karşılaştırın.
Amaç: Mantıksal sınır dışı değerler (negatif yaş, aşırı büyük tutarlar vb.) için kontrol listesi.
Rolün: Veri kalite kontrolü. Aşağıdaki sayısal kolonlarda aykırı değer adaylarını tespit etmek için kurallar öner ve veri örneğinde kuralı ihlal eden örnek satırları (maks. 10) listele.
Kolonlar: [NUMERIC_COLUMNS]
Veri örneği:
[DATA_SAMPLE]Çıktı: JSON {"rules":[...],"flagged_examples":[{"row_id":"...","column":"...","value":"...","reason":"..."}]}
Kural: İstatistiksel eşikler için yeterli veri yoksa, mantıksal eşik öner (ör. yaş 0–120) ve bunun varsayım olduğunu belirt.
Doğrulama: İş kurallarıyla konuşun: “0 sipariş” mantıklı mı, “0 TL” ne anlama geliyor? Aykırı değer her zaman hata değildir.
Amaç: Tek seferde yapılacak dönüşümleri planlamak ve loglamak.
Rolün: Analitik mühendis. Aşağıdaki veri sorunlarına göre geri alınabilir bir temizleme planı yaz.
Sorunlar: [ISSUES_LIST] (örn. tarih formatı karışık, bazı kolonlar string, boşluk/trim, yinelenen kayıtlar)
Çıktı formatı: Adım adım liste. Her adımda: amaç, uygulanacak dönüşüm, nasıl test edileceği, geri alma stratejisi.
Kısıt: Kod yazma; sadece uygulanabilir plan yaz.
Doğrulama: Her adım için küçük bir “önce/sonra” örnek seti ayırın ve sonuçların beklentiyle uyumunu kontrol edin.
Amaç: Veri setini hızlı tanımlamak: boyut, kolon türleri, dikkat noktaları.
Rolün: Veri analisti. Aşağıdaki veri örneğine bakarak kısa bir veri profili üret:
- Kolonların olası rolleri (kimlik, tarih, metrik, kategori)
- Öne çıkan kalite riskleri
- Analiz için 5 öneri soru (hipotez)
Çıktı: Madde işaretli liste + en sonda "Next steps" bölümü.
Veri örneği:
[DATA_SAMPLE]Kural: Örnekte olmayan bilgileri varsayma; belirsizlikleri soru olarak yaz.
Amaç: Uzun çıktılar yerine karar vericiye kısa özet.
Rolün: Ürün analisti. Hedefim: [GOAL]. Aşağıdaki bulgular/taslak sonuçlar üzerinden 8–10 cümlelik bir yönetici özeti yaz.
Girdiler:
1) Veri bağlamı: [CONTEXT]
2) Bulgular: [FINDINGS]
3) Sınırlılıklar: [LIMITATIONS]Çıktı: 3 paragraf (Durum, Ne anlama geliyor, Önerilen aksiyonlar). Belirsiz noktaları açıkça belirt.
Amaç: Destek talepleri, yorumlar, geri bildirim gibi metinlerden tema çıkarmak.
Rolün: Metin analizi asistanı. Aşağıdaki metinleri (ör. müşteri notları) ortak temalara göre grupla.
Veri: [TEXT_SAMPLE] (her satır bir kayıt)
Çıktı formatı: JSON {"themes":[{"theme_name":"...","description":"...","example_texts":[...],"edge_cases":[...]}]}
Kural: Tema sayısını 5–8 aralığında tut. Her temaya en az 2 örnek ekle. Emin olmadığın kayıtları "edge_cases"e koy.
Doğrulama: Tema adlarını ekip içi terminolojiyle hizalayın; 20 rastgele kaydı tekrar etiketleyip tutarlılığı kontrol edin.
Doğal dilden SQL üretimi hız kazandırabilir; fakat NL→SQL arayüzlerinde kötü amaçlı yönlendirmeler ve yetki dışı sorgular gibi riskler gösterilmiştir. Bu nedenle şemaya bağlı kısıtlama, yalnızca SELECT, çalıştırmadan önce doğrulama ve mümkünse salt-okunur bağlantı gibi önlemler kritik kabul edilir (TrojanSQL, EMNLP 2023).
Amaç: Şemanıza uyan, açıklamalı bir SELECT sorgusu üretmek.
Rolün: SQL uzmanı. Aşağıdaki şemaya göre, hedef soruyu yanıtlayan yalnızca SELECT sorgusu yaz.
Şema:
[SCHEMA]Soru:
[QUESTION]Kısıtlar:
- Yalnızca SELECT (INSERT/UPDATE/DELETE/DROP yok)
- Sadece şemada verilen tablo/kolonları kullan
- Varsayım yapma; eksik bilgi varsa netleştirici soru sor
Çıktı formatı:
- Önce: "Assumptions" (varsa)
- Sonra: Düz metin SQL
- Son olarak: "How to verify" adımları
Amaç: Üretilen sorgunun şema uyumu ve mantık hatalarını yakalamak.
Rolün: SQL denetçisi. Aşağıdaki SQL sorgusunu sadece şu açılardan incele:
- Şema uyumu (tablo/kolon isimleri doğru mu?)
- Yanlış join riski (kartesyen çarpım, anahtar uyuşmazlığı)
- Filtre mantığı (tarih aralığı, NULL davranışı)
- Performans (gereksiz SELECT *, indekslenebilir filtreler)
Şema:
[SCHEMA]SQL:
[SQL_DRAFT]Çıktı: JSON {"schema_issues":[...],"logic_risks":[...],"performance_notes":[...],"revised_sql":"..."}
Kural: Şemada yoksa yeni kolon uydurma; "revised_sql"de yalnızca SELECT kullan.
Amaç: Aynı soruyu farklı yaklaşımlarla çözmek (CTE, alt sorgu, pencere fonksiyonları).
Rolün: Kıdemli analitik uzmanı. Aynı soruyu yanıtlayan 3 farklı SELECT sorgusu üret ve her biri için artı/eksi yaz.
Şema:
[SCHEMA]Soru:
[QUESTION]Kısıt: Sonuçlar aynı olmalı. Her sorgu için 2 cümle açıklama ekle.
Doğrulama: Üç sorguyu küçük bir örnek veri üzerinde çalıştırıp satır sayısı ve toplamların eşleştiğini kontrol edin.
Amaç: Sorgu çıktılarını hızlı sanity check ile doğrulamak.
Rolün: Analiz doğrulama. Aşağıdaki sorgu ve örnek sonuçlara göre bir doğrulama planı yaz.
Soru:
[QUESTION]SQL:
[SQL]Örnek sonuç (ilk 20 satır):
[RESULT_SAMPLE]Çıktı:
- 5 adet hızlı kontrol (satır sayısı, null oranı, beklenen aralıklar, toplamlar)
- 2 adet çapraz kontrol (başka bir sorgu veya basit bir pivot ile)
- Şüpheli bulgular için olası nedenler listesi
Kural: Yeni veri çekme isteme; sadece plan öner.
| İş | Önerilen prompt(lar) | Çıktı | Mutlaka kontrol et |
|---|---|---|---|
| Tip/format keşfi | Prompt 1 | JSON veri sözlüğü | Tarih/ondalık/para formatı |
| Eksik veri stratejisi | Prompt 2 | Risk seviyeli öneri | Hedef metrik etkisi |
| Kategori normalizasyonu | Prompt 3 | Eşleme sözlüğü | Belirsiz değerler |
| Aykırı değer adayları | Prompt 4 | Kural + örnekler | İş kuralı istisnaları |
| Temizleme planı | Prompt 5 | Adım adım plan | Geri alma/test adımları |
| EDA başlangıcı | Prompt 6 | Profil özeti | Varsayım yapmaması |
| Yönetici özeti | Prompt 7 | 3 paragraf özet | Sınırlılıkların yazılması |
| Metin temaları | Prompt 8 | Tema JSON | Tema sayısı/tutarlılık |
| NL→SQL taslak | Prompt 9 | SELECT sorgusu | Şema uyumu/yetki |
| SQL denetimi | Prompt 10 | Denetim JSON | Join hataları |
| Alternatif sorgular | Prompt 11 | 3 varyant | Eş sonuç kontrolü |
| Sonuç doğrulama | Prompt 12 | Kontrol planı | Sanity check |
Bu şablonlar, veri analizini hızlandırmak için pratik bir başlangıç sağlar; ancak otomatik karar verici değildir. Literatür, veri hazırlama görevlerinde fayda gösterebilse de sonuçların görev/bağlam/veri türüne göre değişebileceğini vurgular (Springer 2022; Stanford Hazy Research 2023).
Türkçe veri ve terimlerde performansın değişebilmesi olasıdır; bu yüzden kendi veri setiniz üzerinde küçük bir değerlendirme setiyle deneme yapmak en güvenilir yaklaşımdır (Stanford Hazy Research 2023).
Özellikle SQL: Üretilen sorguları doğrudan kritik ortamlarda çalıştırmayın. Okunur yetki, şema kısıtları, denetim ve sonuç doğrulama adımları ekleyin (TrojanSQL).
Ne zaman? Bu 12 hazır promptu; veri setini ilk kez keşfederken, tekrar eden temizlik adımlarını belgelendirirken, kısa paydaş özetleri hazırlarken ve şemaya bağlı SQL taslağına hızlı başlarken kullanın. En iyi kullanım şekli, “ilk taslak” üretip ardından kendi kurallarınızla doğrulamaktır.
Pazarlık olmaz doğrulama adımları: (1) Temizleme kararlarını örnek satırlarla kanıtlayın, (2) dönüşümlerin etkisini küçük testlerle ölçün, (3) SQL için yalnızca SELECT + şema kısıtı uygulayın, (4) sorguyu çalıştırmadan önce denetleyin, (5) sonuçları sanity check + çapraz kontrol ile doğrulayın.
Bugün uygulanacak mini kontrol listesi:
Yorumlar