Çalma listesi önerilerinde kütüphane taramasını parça bazlı sınırlamak

Geçen hafta 1.200 parçalık arşivde çalma listesi önerisi üretirken aynı sanatçının art arda üç parçası gelmeye başladı. Sıralama mantığı doğruydu ama tarama tüm kütüphaneyi tek geçişte dolaşıp her adayı yeniden puanlıyordu; 1.200 parçada bu 4-5 saniye sürüyor, ama öneri kalitesi düşüyordu çünkü yakın komşular sürekli aynı havuzdan seçiliyordu.

Kendi çözümüm, taramayı parça bazlı bir pencereye indirmek oldu. Önce her parçanın etiketlerini ve süresini yerel bir SQLite dosyasına yazdım, sonra öneri üretirken yalnızca son 20 parçanın etiket komşuluğuna bakıyorum. Kabaca şöyle:

import sqlite3

con = sqlite3.connect("muzik.db")
con.execute("CREATE TABLE IF NOT EXISTS track (id TEXT PRIMARY KEY, tags TEXT, dur INTEGER)")

def adaylar(son_idler, limit=40):
    yer = ",".join("?" for _ in son_idler)
    return con.execute(
        f"SELECT id, tags, dur FROM track WHERE id NOT IN ({yer}) "
        "ORDER BY dur LIMIT ?", (*son_idler, limit)
    ).fetchall()

Buradaki dur sıralaması bilinçli: kısa parçaları öne almak, uzun bir parçanın ardından gelen geçişi yumuşatıyor. Etiketleri virgülle tek sütunda tutuyorum, ayrı tabloya açmadım; 1.200 parçada JOIN maliyeti tarama süresinden daha çok canımı yaktı.

Mekanizma tarafında önemli olan, her adayın yalnızca son 20 parçaya göre puanlanması. Bu, “yakın komşu” tanımını daraltıyor ve aynı sanatçının art arda gelme olasılığını düşürüyor. Bedeli de var: kütüphanenin uzak köşelerindeki iyi eşleşmeler hiç aday olmuyor. 1.200 parçada bunu kabul ettim çünkü öneri zaten bir set akışı için, arşiv taraması için değil.

Nerede bozuluyor: son 20 parçanın etiketleri çok homojense (örneğin hepsi aynı türdeyse) pencere daralıyor ve öneri tek düzeleşiyor. Bunu bir kez yaşadım, çözüm olarak pencereyi 20’den 35’e çıkardım ama tarama süresi 4 saniyeden 9 saniyeye çıktı. Ayrıca süre sıralaması, süresi eksik parçalarda NULL yüzünden listenin başına yığılıyor; o yüzden dur alanını doldururken eksik olanları ortalama süreyle yazıyorum. Bir de NOT IN listesi 999 parametreyi geçince SQLite hata veriyor; son 20 parça için sorun değil ama pencereyi büyütürseniz bunu hatırlayın.

Sizin kütüphanenizde son N parça penceresini kaç tutuyorsunuz, yoksa tüm arşivi mi tarıyorsunuz?