deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

MotleyAI'nin SLayer'ı agent'lara tahmine dayalı SQL yerine tek bir metrik tanımı sunuyor

MotleyAI'nın açık kaynak semantic layer'ı SLayer, her metriğin tek bir tanımını tutuyor ve AI agent'lar için doğru veritabanı sorgusunu derleyerek text-to-SQL'deki sessiz ama ciddi bir güvenilirlik açığını kapatıyor.

MotleyAI'nin SLayer'ı agent'lara tahmine dayalı SQL yerine tek bir metrik tanımı sunuyor

SLayer ne yapıyor

Text-to-SQL, hata vermeden yanlış sonuç üretebilir. Aracı tanıtan bir dev.to yazısında anlatıldığı gibi, model yanlış bir join seçiyor ya da "gelir"in ne sayılacağına dair kendi yorumunu icat ediyor ve sonra makul görünen bir rakam döndürüyor. MotleyAI'nın semantic layer'ı SLayer tam da bu tahmini ortadan kaldırmak için tasarlanmış: her iş metriğinin tek bir otoriter tanımını tutuyor ve agent'lar ham tablolara karşı SQL yazmak yerine bu metriği sorguluyor.

Mekanizma yüzeyselde basit. Bir ekip metriği —örneğin geliri— bir kez tanımlıyor. Bir agent'a daha sonra toplam, ortalama ya da bir yıl geriye kaydırılmış aynı rakam gerektiğinde, SLayer bu paylaşılan tanımdan yola çıkarak altta yatan veritabanı için doğru sorguyu derliyor. Sonraki her yanıt, modelin o anki prompt'a göre benimsediği şeye değil, aynı tanıma sabitleniyor.

Agent'lar için altı giriş yolu

Yazıya göre agent'lar SLayer'a altı arayüzden ulaşabiliyor: MCP, REST, bir komut satırı aracı, bir Python client'ı, Flight SQL ve bir Postgres facade'i. MCP desteği önemli, çünkü layer'ı agent framework'lerinin giderek daha çok dayandığı tool-calling desenine doğrudan bağlıyor; Flight SQL ve Postgres facade ise zaten bu protokolleri konuşan araçların önünü açıyor. Böylece tek bir layer hem agent trafiğine hem de geleneksel sorgu iş akışlarına hizmet edebiliyor.

Mevcut metrik modelleri taşınıyor

SLayer, dbt, Cube ve Ossie'den yapılandırma içe aktarabiliyor. Metriklerini bu araçlardan birinde zaten modellemiş ekipler, tanımları sıfırdan yeniden yazmak yerine taşıyabiliyor; bu da kurulum maliyetinin büyük kısmını ortadan kaldırıyor. Ayrıca bu, SLayer'ı her şeyin yeniden inşa edilmesi gereken rakip bir standart olarak değil, mevcut semantic model'lerin bir tüketicisi olarak konumlandırıyor.

Proje nerede duruyor

Yazıya göre 1.8.2 sürümü 9 Kasım 2026'da çıktı. Depo Python ile yazılmış ve MIT lisansıyla yayınlanmış; yazı sırasında 341 yıldız toplamıştı. Bu rakamlar erken aşamadaki bir projeyi anlatıyor: şimdiye kadar mütevazı bir benimsenmeyle ilginç bir yön ve üretim veri altyapısına giden her şey için alışıldık olgunluk uyarıları geçerli.

Neden önemli

Text-to-SQL'ün sessiz hata modu, onu agent iş yükleri için riskli kılan şey. Prompt düzeyindeki düzeltmeler —daha iyi talimatlar, daha fazla şema bağlamı— hataları azaltabilir ama tamamen ortadan kaldıracağını garanti edemez, çünkü "gelir"in tanımı hâlâ modelin o anki yorumunda yaşıyor. SLayer bu tanımı kod ve altyapıya taşıyor: bir kez yazılıyor, bir kez gözden geçiriliyor ve hangi agent sorarsa sorsun tutarlı biçimde derleniyor.

Bu yaklaşım, veri dünyasının zaten kabul ettiği bir deseni de yansıtıyor. Semantic layer'lar bu sorunun bir sürümünü BI dashboard'ları için çözmüştü; aynı dönem için "gelir" gösteren iki grafik, farklı mantık kodladıkları için birbirini tutmuyordu. Agent'lar doğal dille soruları yanıtlamaya başladıkça aynı garantilerin geçerli olması gerekiyor — üstelik daha yüksek riskle, çünkü bir agent'ın yanlış rakamı, onu üreten sorguyu hiçbir insan görmeden doğrudan bir karara ya da otomatik bir eyleme akabilir.

Zaten dbt veya Cube çalıştıran ekipler için içe aktarma yolu bunu değerlendirmeyi ucuz kılıyor. Text-to-SQL agent'ları giren herkes içinse SLayer, güvenilirlik sorununun prompt düzeyinden çok metrik katmanında çözülmesinin daha iyi olabileceğinin yararlı bir hatırlatıcısı.

  • #text-to-sql
  • #semantic-layer
  • #ai-agents
  • #open-source
  • #python

İlgili yazılar