Veritabanınızın üstünde model: eğitimsiz tahmin, zaman serileri ve Postgres içinde arama

NVIDIA, ilişkisel veritabanı üzerinden göreve özel eğitim olmadan tahmin yapan bir model yayımladı, IBM dört zaman serisi modelini tek toplulukta birleştirdi, TigerData ise PostgreSQL içinde arama kütüphanesini açtı. Ortak fikir: şirketin verileri zaten veritabanında duruyor ve “sonra ne olacak” ile “o zaman ne olmuştu” soruları doğrudan ona sorulabilir. İşletme sahibi için talep veya kayıp tahmininin eşiği, geçmişi olan tek bir veritabanına indi.

Ne çıktı

NVIDIA 21 Ekim'de Hugging Face blogunda Kumo Relational'ı tanıttı. Model tabloları, yabancı anahtarları ve zaman damgalarını okuyor ve tahmin sorgusuna yanıt veriyor, örneğin hangi müşteri gidecek veya kaç birim satılacak. Göreve özel eğitim ve elle öznitelik hazırlama olmadan. 15 veritabanından 41 görevde eğitilmiş modelleri ve gradient boosting pipeline'larını geçti. Tahmin için model geleceğe bakmamak adına yalnızca kontrol tarihinden önceki olayları alıyor. Kod ve ağırlıklar açık.

IBM Research 22 Ekim'de aynı yerde zaman serileri için Granite topluluğunu anlattı. Farklı mimarili dört ön eğitimli model tahmin veriyor, tarif ise onları medyan ve kantillerde birleştiriyor. Varsayılan olarak dört modelin etkisi eşit, hiçbir şey yeniden eğitilmiyor. 0,1 ve 0,9 kantilleri nominal %80 kapsamalı aralık veriyor. Ek eğitim olmadan 97 GIFT-Eval yapılandırmasında test edildi.

TigerData 20 Ekim'de searchgres.js'i açtı: Apache-2.0 lisanslı TypeScript kütüphanesi, PostgreSQL'e tek sorguda BM25 kelime aramasını, vektör aramasını ve hiyerarşi, meta veri ve zaman filtrelerini birleştiriyor. Makaledeki örnek: elektrik santrali operatörü grafikte gücün düştüğü yarım saati seçiyor ve “bu planlı mıydı” diye soruyor. Arama o blok ve zaman için dispeçer talimatını ve vardiya kaydını buluyor. Filtreler sıralamadan önce uygulanıyor, bu yüzden gereken kayıt ilk yirmiden düşmüyor.

İki gün sonra, 22 Ekim'de, aynı ekip Slack ajanı için üç bellek sistemini nasıl kurduğunu anlattı. Olgu listesi fazla yoksul çıktı. SQL'e serbest erişimli genel bilgi grafı fazla serbest çıktı: ajanlar görev yerine veritabanı mekaniğine onlarca adım harcıyordu. ltree uzantısı üzerindeki ağaç her kayda bir yer ve anlaşılır bir işlem kümesi verdi. En ifade gücü yüksek sistem en yararlısı olmadı.

Weaviate 14 Ekim'de Tsinghua Üniversitesi'nin SIGMOD 2026 makalesinden filtreli vektör arama algoritması PathSeer'ı anlattı. Yazarların uygulamasında %90 recall'da verim sıradan HNSW'ye göre 1,2-13,5 kat yüksek, Weaviate 1.40'ta ise strateji mevcut dizinde yeniden kurulum olmadan değiştiriliyor.

İşletme için ne anlama geliyor

Veritabanında iki yıllık rezervasyon geçmişi olan bir araç kiralamayı ele alalım. Sahibinin sorusu: kasımda hangi sınıftan kaç araç boş duracak ve sezon için iki araç daha almaya değer mi. Kumo Relational gibi bir model aynı veritabanından sorgu başına yanıt vadediyor, zaman serisi topluluğu ise günlere göre talep aralığı veriyor, tek rakam yerine aralıkla.

İkinci soru “o zaman ne olmuştu” türünden: müşteri martta kendisine başka fiyat söylendiğini iddia ediyor. Yazışmalar, arama kayıtları ve yöneticilerin notları tek veritabanında, zamanıyla ve rezervasyona bağlı duruyorsa, müşteri ve ay filtreli kelime ve anlam araması gereken cümleyi saniyeler içinde bulur. Sonuç: buradaki ana koşul veritabanındaki geçmiş, zamanıyla ve tablolar arası bağlarıyla. Bunun için yeni veritabanı gerekmiyor.

Bende nasıl

2023 baharında Londra'daki bir danışmanlık şirketi için sıfırdan bir finans paneli yaptım. Hisse verilerini Morningstar API'den alıyor, haberleri ekliyor ve hepsini ChatGPT'ye veriyorduk. Her şirket için hissenin nereye gidebileceğine dair varsayımsal bir değerlendirmeyle özet tablo oluşuyordu. Bu garantili bir tahmin ya da yatırım tavsiyesi değildi. O panelden şunu öğrendim: verilerin üstündeki model tablo biçiminde yanıt verir, kararı insan verir.

ABD'deki PDR şirketinde veriler 2023'ten beri kendi sunucusundaki MariaDB'de duruyor: AI ayrıştırmalı aramalar, lead'ler, siparişler, her çalışan için 15 leaderboard göstergesi. “Gelecek ay lead akışı ne olacak” sorusu bu veritabanına şimdiden sorulabilir. Kumo Relational'ı ve Granite topluluğunu çalıştırmadım; onları 2023'ten bu yana lead geçmişinde, geçen yıla göre tahminle karşılaştırarak denerdim. Kazanç yoksa model gerekmez.

Ben ne yapardım

Veritabanını kontrol ederek başlardım: olayların zamanı var mı, tablolar anahtarlarla bağlı mı, kayıt güncellenince geçmiş siliniyor mu. Bunlar olmadan ne tahmin ne arama çalışır.

Sahibinin para ödemeye hazır olduğu tek bir soru seçer ve yanıtı en basit yolla hesaplardım: geçen yıl artı büyüme. Model bu çıtayı geçmeli. Tahmini veritabanında olgunun yanında, hesaplama tarihi ve aralıkla saklardım.

Geçmişte aramayı aynı veritabanında, müşteri ve zaman filtreleriyle yapardım. Vektörler için ayrı depoyu yalnızca performansa takıldığımda açardım.

Ajan belleği gerekirse, TigerData'nın üçüncü denemesindeki gibi ağaç ve filtrelerle başlar, ajana serbest SQL vermezdim.

İlgili yazılar

Model sonucunun kontrolü hakkında: Veri işlemede AI: çıkarma ve doğrulama. Yaklaşım: Belgeler, veriler ve tekrarlanabilir işleme için Python ve tablo otomasyonu ve iş raporlaması. Vaka çalışmaları: Google Sheets'te finans paneli, Londra'daki danışmanlık şirketi ve servis ekibi ve %30 dönüşüm. Aynı konudaki yazılardan: veritabanında sonradan pişman olunan üç karar, AI karar veriyor, insan onaylıyor ve kendi modelim ile API arasında nasıl seçim yapıyorum. Daha önce: hibrit arama ve tokenizasyon ve bilgi grafı mı, vektör RAG mi. Şirketinizin geçmişi zaten veritabanında duruyorsa, ona sorulacak ilk sorunun ne olduğunu anlatın. Görevi konuşalım.