GitHub Issues tarafında arama işi yıllardır biraz garipti. Hani olur ya, elinizde doğru issue vardır ama kelimeyi tam tutturamadığınız için bulamazsınız… işte o sınır bozucu durum şimdi biraz azalıyor. GitHub’ın yeni semantic search yaklaşımı sadece anahtar kelimeye bakmıyor; issue başlığının. Gövdesinin ne anlattığını da tartıyor. Açık konuşayım, küçük görünen bu değişiklik günlük akışta bayağı fark yaratıyor.
Kendi deneyimimden konuşuyorum, Ben bunu ilk duyduğumda aklıma direkt 2024’te bir finans kuruluşunda yaptığımız triage toplantısı geldi (evet, doğru duydunuz). Ekip, yüzlerce issue arasından aynı hatanın farklı isimlerle açılmış kayıtlarını ayıklamaya uğraşıyordu. Bir geliştirici “login timeout” yazıyordu, diğeri “auth delay”, bir başkası “token refresh fail” diyordu. Üçü de aynı kök (belki yanılıyorum ama) probleme çıkıyordu ama klasik aramayla yakalamak bazen gerçekten can sıkıyordu. İşin aslı şu ki, yeni arama yaklaşımı tam da böyle dağınık ortamlarda nefes aldırıyor.
Bunu biraz açayım.
Bir de şunu söyleyeyim: bu özellik sadece daha akıllı görünmüyor, pratikte daha derli toplu sonuç veriyor. Genel kullanıma açılmasıyla birlikte API üzerinden de erişilebilir hâle gelmesi bence asıl önemli kısım. Çünkü ekip içi otomasyonlarda, triage bot’larında ya da özel dashboard’larda kullanınca taşlar yerine oturuyor (yanlış duymadınız). Benim AZ-104. AZ-305 hazırlık sürecimde bile benzer mantığı çok düşündüm; aradığını bağlama göre bulabilen sistemler her zaman daha kullanılabilir oluyor.
Klasik arama “tam kelimeyi bil” derken, semantic search “niyetini anlat yeter” diyor. Günlük kullanımda farkın en büyük kısmı burada.
Aslında Neyi Çözüyor?
Bakın şimdi, mesele sadece daha iyi sonuç göstermek değil — valla güzel iş çıkarmışlar —. Asıl kazanım, insanların sorun tarif etme biçimiyle sistemin anlama biçimi arasındaki boşluğu kapatmak. İnsanlar issue açarken pırıl pırıl kelimeler seçmez; çoğu zaman acele eder, bazen teknik terimi yanlış yazar, bazen de problemi kendi dilinde anlatır. Semantic search de bu karmaşayı biraz toparlıyor.
2025’in Kasım ayında Logosoft tarafında bir kurumsal yazılım müşterisinde buna benzer bir tablo görmüştük. Aynı bug için dört farklı ekip dört farklı ifade kullanıyordu ve destek ekibi arada kalıyordu. O zaman şunu net gördüm: Arama motoru ne kadar zeki olursa olsun veri dağınıksa sonuç zayıf kalır; ama yine de bağlam anlayan bir yapı işleri ciddi rahatlatır. Yani sihir yok… ama bayağı iyi mühendislik var.
Ve işler burada ilginçleşiyor.
Bir de işin kullanıcı psikolojisi tarafı var. Kötü arama deneyimi insanı tembelleştiriyor; herkes filtreye abanıyor ya da aynı issue’yu yeniden açıyor. İyi çalışan semantic arama işe tekrarları azaltıyor, triage hızını artırıyor ve ekiplerin “bu konu zaten vardı” cümlesini daha sık kurmasını sağlıyor. Bu da açıkçası fena değil, değil mi?
Semantik + Anahtar Kelime = Hibrit Mantık
Küçük bir detay: Yeni sistemin hoş yani şu: tek başına semantic moda yaslanmıyor. Hibrit aramada hem anlam benzerliği hem de klasik keyword eşleşmesi birlikte çalışıyor. Bu bana biraz iki farklı gözlük takmak gibi geliyor; biri geniş açıyla sahneyi tarıyor, diğeri detayları kaçırmıyor.
Eğer sorgunuz filtrelerden ya da tırnak içindeki kesin ifadelerden oluşuyorsa GitHub klasik lexical search’e dönüyor. Bu kötü değil; aksine yerinde bir davranış çünkü her durumda anlam temelli eşleme istemezsiniz. E peki, sonuç ne oldu? Mesela belirli bir hata kodunu ya da exact string’i arıyorsanız semantik yaklaşım fazla yaratıcı olabilir (evet, bazen fazla zeki olmak da problem). Bu konuyla ilgili GitHub Copilot Cloud Agent İçin Runner Kontrolü: Kurumsal Düzen yazımıza da göz atmanızı tavsiye ederim.
| Arama Tipi | Ne Işe Yarar? | Zayıf Noktası |
|---|---|---|
| Klasik lexical | Kesin kelime ve ifade eşleşmesi | Anlam benzerliğini kaçırabilir |
| Semantic | Niyet ve bağlam üzerinden bulma | Bazen exact match beklentisini karşılamaz |
| Hybrid | İkisini birlikte sunar | Sorgu tasarımını biraz düşünmek gerekir |
API Tarafı Neden Önemli?
E tabii kullanıcı arayüzünde güzel görünmesi önemli ama gerçek güç API’de başlıyor. REST. GraphQL üzerinden semantic search açılması demek; kendi araçlarınızda issue keşfi yapabilmeniz demek, triage otomasyonu kurabilmeniz demek, hatta bazı durumlarda AI destekli destek masası akışı oluşturabilmeniz demek.
Mesela 2026’nın Mart ayında bir SaaS firmasında bunun benzeri bir senaryoyu tartıştık: destek ekibi müşteri taleplerini Jira’dan GitHub Issues’a taşıyordu ve eski kayıtları doğal dille taramak istiyorlardı (yanlış duymadınız). Eğer search endpoint’i yalnızca keyword seviyesinde kalsaydı iş çok uzardı. Ama semantic + hybrid seçenekleriyle geliştiriciler neredeyse konuşur gibi sorgu atabiliyor (kendi tecrübem) Bu konuyla ilgili C# 15’te Union Types: Eksik Parça Nihayet Geldi yazımıza da göz atmanızı tavsiye ederim. Copilot SDK: Ajanları Kendi Uygulamana Taşırken Ne Değişiyor? yazımızda bu konuya da değinmiştik. Microsoft Agent Framework 1.0: Ajanlar Artık Ciddileşti yazımızda bu konuya da değinmiştik.
Şimdi gelelim işin can alıcı noktasına.
İşin garibi, Aşağıdaki örnek kaba taslak olarak neye benzediğini gösteriyor:
GET /search/issues?q=memory leak in background job&search_type=semantic
GET /search/issues?q=repo:contoso/app "null reference"&search_type=hybrid
Aslında, Bunun güzel tarafı şu: response içinde hangi aramanın çalıştığını. Gerekirse neden lexical fallback’e düştüğünü görebiliyorsunuz. Şeffaflık fena değil yani… İlginç, değil mi? Hele bir de enterprise tarafta denetlenebilirlik istiyorsanız bu detaylar kıymetli oluyor.
Kısıtlar Var mi? Var Tabii.
Şimdi gelelim can sıkan kısma. Semantic ve hybrid sorgular dakikada 10 istekle sınırlı tutulmuş durumda. Küçük ekipler için idare eder ama yüksek hacimli otomasyon yapan yerlerde planlama gerektirir. Her şeyi anlık tarayayım derseniz rate limit duvara toslatır.
Ayrıca query scope’u düzgün kurmazsanız sonuçlar gürültülü olabilir. org:, user:, repo: gibi qualifier’larla alan daraltmak bence şart gibi duruyor (evet, doğru duydunuz). Yoksa devasa organizasyonda “alakalı gibi görünen ama aslında alakasız” sonuçlarla uğraşırsınız ki bu da tam hayal kırıklığı kategorisine girer. Daha fazla bilgi için Google Vids’e Gelen Yapay Zekâ Hamlesi: Ücretsiz Video Üretimi yazımıza bakabilirsiniz.
Küçük Ekipte Başka, Enterprise’da Başka Çalışır
Dürüst olmak gerekirse, Küçük startup’ta bu özellik doğrudan hız kazandırır. İki kişi backlog yönetiyorsa biri issue’nun adını tam hatırlamasa bile doğal dille yazıp sonuca gidebilir. Hele ki ürün hızlı değişiyorsa aynı problemi farklı isimlerle etiketlemek çok normaldir. Peki neden? Çünkü gerçek hayat düzenli akmıyor.
Büyük organizasyonda işe değer başka yerde ortaya çıkar : standardizasyon ve görünürlükte. Benim tecrübemde bankacılık ve telekom projelerinde asıl sorun teknik olarak bulunamayan issue değil, süreç içinde kaybolan issue oluyor. Semantic search burada ekipler arasında ortak dil oluşturuyor. Herkes aynı terimleri kullanmasa bile sistem onları birbirine yakınlaştırıyor (yanlış duymadınız). Az önce başka türlü anlattım ama aslında mesele tam olarak bu.
- Küçük ekip: Daha hızlı triage, daha az tekrar eden issue.
- Büyük kurum: Daha iyi sınıflandırma, daha güçlü otomasyon ve raporlama. (bu kritik)
- Dikkat edilmesi gereken: Fazla geniş sorgular yanıltıcı olabilir.
- Tavsiye: Önce scope daraltın, sonra anlam tabanlı aramayı kullanın.
Birkaç Pratik Not — Lafı Gevelemeden
Bilmem anlatabiliyor muyum, Bence ilk yapılacak şey mevcut issue başlıklarını temizlemek olmalı. Search ne kadar akıllı olursa olsun kötü etiketlenmiş veri önü yorar. Geçen yıl Logosoft’ta bir Azure migration projesinde buna çok benzer bir ders aldık ; iyi metadata olmadan en pahalı araç bile yarım çalışıyor. Hatta bazen hiç yürümüyor, açık söyleyeyim.
İşin garibi, İkinci not : filtreleri hafife almayın. Tırnak içi exact match, repo scoping, org scoping… bunlar semantic search’in rakibi değil, tamamlayıcısı. Bazen en iyi sonuç hibrit moddan gelir ; yani tek düğmeye basıp mucize beklemeyin — dürüst olayım, biraz hayal kırıklığı —. Şey gibi düşünün, alet çantası tek tornavidadan ibaret değil ki.
Üçüncü not işe API ile gelen fallback bilgisini loglamak. Çünkü üretimde niye lexical’a döndüğünüzü bilmezseniz optimizasyon yapamazsınız. Ben olsam özellikle kurumsal tarafta bunu telemetry’ye eklerim ; sonra oturup bakarım, hangi sorgular zayıf kalmış diye. Siz ne dersiniz ?
Sıkça Sorulan Sorular
GitHub Issues için improved search tam olarak ne yapıyor?
Araştırdığınız konuyu sadece kelime olarak değil, anlam olarak da eşleştiriyor. Böylece benzer problemi anlatan ama aynı ifadeyi kullanmayan issue’ları bulmanız kolaylaşıyor.
Sadece tek depoda mı çalışıyor?
Bakın, Hayır, hem tek repository içinde hem de Issues dashboard üzerinden birden fazla repository’de çalışabiliyor. Scope’u doğru verirseniz sonuç kalitesi belirgin şekilde artar.
Sorguyu API’den nasıl kullanırım?
/search/issues endpoint’ine search_type=semantic veya search_type=hybrid parametresi eklersiniz. GraphQL tarafında işe searchType argümanını kullanırsınız.
Klasik arama neredeyse tamamen bitti mi?
Hayır, kesinlikle bitmedi. Exact match gerektiğinde hâlâ klasik lexical search en doğru tercih olabilir ; özellikle hata kodları veya birebir ifadeler için işe yarar.
Büyük organizasyonlarda dikkat edilmesi gereken şey ne?
Poor quality data, gevşek scope ve aşırı otomasyon en büyük risklerdir. Rate limit’i, telemetry’yi ve filtre kullanımını baştan planlamak gerekir ; yoksa fayda çabuk törpülenir.
>
Kaynaklar ve İleri Okuma
GitHub Docs — Issues and Pull Requests Araması
>
>GitHub GraphQL — Search Query Reference
>
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder