Shahar Azulay, groundcover’ın CEO’su ve Kurucu Ortağı

Shahar Azulay, groundcover’ın CEO’su ve kurucu ortağı, bir dizi Ar-Ge lideridir. Shahar, siber güvenlik ve makine öğrenimi alanlarında Apple (AAPL ), DayTwo ve Cymotive Technologies gibi şirketlerde lider olarak deneyim kazanmıştır. Shahar, İsrail Başbakanlığı Ofisi’nin Siber Bölümü’nde birçok yıl geçirdi ve Technion İsrail Teknoloji Enstitüsü ve Tel Aviv Üniversitesi’nden Fizik, Elektrik Mühendisliği ve Bilgisayar Bilimi alanlarında üç derece sahibi oldu. Shahar, bu zengin geçmişten elde ettiği teknolojik bilgileri günümüzün bulut yerel savaş alanında en keskin ve yenilikçi şekilde kullanmaya çalışıyor.

groundcover bir bulut yerel observability platformudur ve mühendislik ekiplere geleneksel izleme araçlarının karmaşıklığı veya maliyeti olmadan sistemlerine tam, gerçek zamanlı görünürlük sağlar. eBPF teknolojisi üzerine inşa edilen groundcover, bulut yerel ve Kubernetes ortamlarında kod değişiklikleri olmadan günlükleri, metrikleri, izleri ve olayları toplar ve ilişkilendirir, böylece daha hızlı kök neden analizi ve daha net sistem içgörüsü sağlar. Platform, öngörülebilir fiyatlandırma, müşteri bulutunda veri tutan esnek dağıtım ve altyapı, uygulamalar ve modern AI sürücülü iş yükleri boyunca kapsamlı observability vurgular.

Siber R&D ekiplerini İsrail Başbakanlığı Ofisi’nde yönetmekten Apple’da ML girişimlerini yönetmeye kadar olan yolculuğunuza geri bakarak, size groundcover’ı kurma yolunu açan deneyimler nelerdi ve modern AI sistemleri için observability açığını ne zaman fark ettiniz?

groundcover’ı kurma itkisi Apple ve DayTwo’daki zamanımdan geldi. Hatta büyük bütçelerle bile her şeyi kaydetmek için bir servet ödemek veya örneklemek ve kör olmak arasında seçim yapmak zorunda kaldık. O zamanlar, bu sorunu çözecek bir teknoloji arıyorduk. Extended Berkeley Packet Filter (eBPF) ile karşılaştığımızda her şeyi değiştireceği açıktı. eBPF, uygulamaya bağlı olmadan çekirdekte neler olduğu görmenizi sağlar. Observability araçlarının bundan yararlanmadığını anlamak zor değildi. AI açığı daha sonra ortaya çıktı. Kubernetes platformumuz olgunlaştığında, müşteriler GenAI dağıtımlarına koşarken LLM’leri siyah kutular gibi davranmaya başladılar. Modelin neden öngörülemez bir şekilde davrandığını veya neden maliyetlerin arttığını bilmiyorlardı. Agentic iş akışlarının aslında karmaşık, belirsiz mikro hizmetler olduğunu ve zaten inşa ettiğimiz sıfır dokunuşlu görünürlüğe ihtiyaç duyduğunu fark ettik.

Siber güvenlik, gömülü sistemler ve makine öğrenimi Ar-Ge deneyiminiz, groundcover’ın vizyonunu nasıl etkiledi ve LLM sürücülü ve agentic uygulamalar için observability odaklı bir şirket kurarken hangi erken zorluklarla karşılaştınız?

Siber güvenlik geçmişim şirketin DNA’sını şekillendirdi. İstihbarat dünyasında, uygulamayı kontrol etmediğinizi varsayarsınız. Bu nedenle groundcover, enstrümantasyon gerektirmez. Geliştiricilerin kodu değiştirmesini istemenin, benim deneyimimle, benimseyimi engellemenin en hızlı yolu olduğunu biliyorum. LLM izlemeyle ilgili en büyük erken zorluk, gizlilikti. AI observability, hassas PII veya IP’yi içeren prompleri yakalayabilir. Şirketlerin bu verilerin ortamdan çıkmasını istemediği açıktı. Bu nedenle, müşterilerin kendi bulutunda tüm verileri tutarak derin görünürlük sağlayabilen bir mimari inşa ettik.

LLM observability’yi nasıl tanımlarsınız ve bu, geleneksel izleme veya ML izlemesinden nasıl farklıdır?

LLM observability, üretim sistemlerini büyük dil modelleri kullanarak enstrümanlayarak ve izleyerek her bir çıkarımın tam bağlamını yakalamak için yapılan uygulamadır: promt, bağlam, tamamlama, token kullanımı, gecikme, hatalar, model meta verileri ve ideal olarak aşağı akış geri bildirimi veya kalite sinyalleri. Sadece “Hizmet açık ve hızlı mı?” veya “Bu istek hata verdi mi?” gibi sorular sormak yerine, LLM observability size “Bu özel istek neden başarılı veya başarısız oldu?”, “Bu çok adımlı iş akışı içinde gerçekten neler oldu?” ve “Prompler, bağlam veya model sürümlerindeki değişiklikler maliyeti, gecikmeyi ve çıktı kalitesini nasıl etkiliyor?” gibi soruları cevaplayabilmenizi sağlar. Bu, geleneksel izleme veya klasik ML izlemesinden çok farklıdır. Miras yaklaşimler, deterministik sistemler, altyapı metrikleri ve statik eşiklere göre ayarlanmıştır. LLM uygulamaları, belirsiz, açık uçlu ve yüksek bağlama bağımlıdır. Başarı genellikle semantik ve öznel, sadece 200 vs 500 durum kodu değildir. Bu nedenle, girişleri ve çıktıları izlemeniz, araç çağrılarını ve alma adımlarını anlamlandırmanız, yanıtları hallucinasyonlar veya politika ihlalleri gibi şeyler için değerlendirmeniz ve token düzeyindeki maliyetleri ve gecikmeleri çevreleyen uygulama ve altyapıya bağlamanız gerekir.

LLM sürücülü uygulamalar geleneksel observability araçlarını yetersiz kılan hangi zorlukları getirir?

LLM sistemleri several zorluklar getirir:

• Karmaşık, çok adımlı iş akışları – Basit “modeli çağır, yanıtı al” akışlarından çok adımlı ajanlara, çok adımlı boru hatlarına, alma ile güçlendirilmiş üretime ve araç kullanımına geçtik. Bu adımların herhangi birindeki sessiz bir hata tüm deneyimi bozabilir. Geleneksel izleme genellikle bu zincirlerin tam, iz düzeyinde bir görünümünü promt ve yanıtlar dahil olmak üzere vermez.
• Hızla evrimleşen AI yığınları – Ekipler yeni modeller, araçlar ve satıcılar ekliyor ve bunu daha önce hiç görmedikleri bir hızda yapıyor. Birçok şirkette, kimse üretimdeki modellerin listesini güvenle veremez. Klasik observability genellikle, SDK’ları enstrümanlamak, yeniden dağıtmak ve ölçtüğünüz şeyi dikkatli bir şekilde küratlemek için zamanınız olduğunu varsayar. Bu, AI’nin benimsenme hızıyla başa çıkmak için yeterli değildir.
• Token tabanlı ekonomi ve kotalar – Fiyatlandırma ve hız sınırları, geliştiriciler, promtler veya kullanıcı davranışı tarafından kontrol edilen tokenler ve bağlam uzunluğuna bağlıdır, merkezi operasyonlar tarafından değil. Geleneksel araçlar, size “kimin, hangi modelde, hangi iş akışında, hangi gecikmeyle kaç token yaktığını” göstermek için tasarlanmamıştır.
• İkili başarı yerine semantik doğruluk – Bir LLM 200 dönebilir ve hala hallucinasyonlara sahip olabilir, promtından sapabilir veya politika ihlal edebilir. Geleneksel araçlar bunu bir başarı olarak görür. size promt ve yanıtları yüzeyde verebilen ve davranışın ve zaman içinde otomatik kalite kontrollerini takmak için yeterli bağlamı sağlayan observability’ye ihtiyacınız vardır.
• Hassas girdi verilerinin üçüncü taraflara akması – LLM’ler, kullanıcıların çok hassas bilgileri sohbet benzeri arayüzler aracılığıyla paylaşmasına davet eder. Bu, kişisel veri, müşteri verileri veya asla toplamak istemediğiniz düzenlenmiş bilgiler olabilir. Bu verilerin nereye gittiğini, nasıl depolandığını ve hangi alt işleyicilerin dahil olduğunu bilirsiniz. Bu, GDPR, veri ikametgahı ve müşteri güveni için önemli sonuçlar doğurur.

Tüm bunlar, LLM sistemlerinin AI farkında, bağlam zengin ve geleneksel araçlardan daha az manuel enstrümantasyona bağlı observability gerektirdiğini gösterir.

LLM sistemlerinin performansını ve kalitesini anlamak için hangi sinyaller veya metriklar en önemlidir, bunlar arasında gecikme, token kullanımı ve promt/yanıt davranışı vardır?

Uygulamada önemli olan birkaç sinyal kategorisi vardır:

Gecikme ve verim

• Her istek için uçtan uca gecikme, model zamanı ve çevreleyen uygulama zamanı dahil.
• Her model ve iş akışı için kuyruk gecikmeleri (P90, P95, P99).
• Model, yol ve hizmet başına verim, böylece yükün nereye gittiğini bilirsiniz.

Token kullanımı ve maliyet sürücüleri

• Her istek için model başına girdi ve çıktı tokenleri.
• Model, takım, kullanıcı ve iş akışı başına zaman içinde agregat token kullanımı.
• Alma ağır boru hatları için bağlam boyutları, böylece promtlerin patladığını görebilirsiniz.
• Bu, size “AI bütçemizi gerçekten kim harcıyor ve ne için?” sorusunu cevaplayabilmenizi sağlar.

Prompt ve yanıt davranışı

• Temsil edilen izler上的 gerçek promt ve yanıt yükleri, araç çağrıları ve akıl yürütme yolları dahil.
• LLM’nin hangi araçları çağırdığını ve hangi sırayla.
• Benzer promtler için yanıtların varyansı, böylece davranışın ne kadar稳 olduğunu görebilirsiniz.

Güvenilirlik ve hatalar

• Model spesifik hata oranları ve türleri (sağlayıcı hataları, zaman aşımı, kimlik doğrulama sorunları, kota hataları).
• LLM çağrısı ile ilgili iş akışındaki hatalar, such as alma zaman aşımı veya alma hataları.

Klasik altyapı bağlamı

• LLM çağrılarını düzenleyen hizmetler için konteynır CPU, bellek ve ağ metrikleri.
• Uygulamanın ne yapmaya çalıştığını açıklayan ilişkili günlükler.

Tüm bunları bir arada görebildiğinizde, LLM observability “bir şeyler yavaş veya pahalı”dan “hangi model, promt deseni ve hizmet sorumlu ve neden”ye geçer.

Observability, promt kayması, hallucinasyonlar veya çıktı kalitesindeki kademeli bozulma gibi sessiz hataları nasıl tespit edebilir?

LLM sistemlerindeki sessiz hatalar genellikle altyapı düzeyinde her şey “yeşil” görünürken, ancak gerçek davranış kaymaktadır. Observability birkaç şekilde yardımcı olur:

• Tam iş akışını, sadece model çağrısını izleme – Talep yolunun tamamını, istemciden hizmete, almaya, modele, araçlara izleyerek, davranışın nerede değiştiğini görebilirsiniz. Örneğin, belki de alma artık daha az belge döndürmeye başladı veya bir araç çağrısı ara sıra başarısız oluyor ve model doğaçlama yapıyor.
• Prompt ve yanıtları görünür tutma – İzleri yanıtlar ve promtlerle birlikte inceleyebildiğinizde, yeni bir promt sürümü, yeni bir sistem talimatı veya yeni bir bağlam kaynağı davranışını değiştirdiğinde, gecikme ve hata oranlarının aynı kalmasına rağmen, bunları tespit etmek çok daha kolay olur.
• Semantik koşullara göre filtreleme ve dilimleme – Zengin LLM telemetri verisine sahip olduğunuzda, “bir saniyeden uzun bedrock çağrıları”, “bu model ailesini kullanan istekler” veya “bu belirli rotayı içeren izler” gibi şeylere göre filtreleyebilirsiniz, ardından promt ve yanıtları okuyarak modelin belirli bir senaryoda kayıp veya hallucinasyon olup olmadığını görebilirsiniz.
• İş düzeyinde SLO’lar için uyarı – “Her LLM çağrısı bir saniyeyi aşarsa, kullanıcı odaklı SLA’mızı ihlal eder” gibi SLO’lar tanımlayabilir ve bu koşullar karşılandığında uyarı tetikleyebilirsiniz. Zaman içinde, benzer SLO’lar kalite puanlarına veya politika kontrollerine bağlanabilir, böylece kalite bozulduğunda, altyapı arızalanmadan uyarı alırsınız.

Observability katmanı hem AI spesifik sinyallere hem de klasik günlüklere, metriklere ve izlere erişebildiği için, genellikle sessiz bir şekilde bozulan kullanıcı deneyimini yakalamak için doğal bir yer haline gelir.

groundcover’ın yaklaşımı, çok adımlı ajan iş akışları ve araç çağrıları içindeki öngörülemez gecikme veya beklenmeyen davranışı nasıl teşhis eder?

groundcover modern AI sistemleri için tasarlanmış bir yaklaşım kullanır. Çekirdek düzeyinde bir eBPF tabanlı sensör kullanarak, kod değişiklikleri veya yeniden dağıtımlar olmadan mikro hizmetler arasındaki trafiği izleriz. Bir LLM iş akışı tanıtmanızla birlikte, bu çağrıları otomatik olarak keşfederiz. Yarın Anthropic, OpenAI veya Bedrock gibi yeni bir model kullanmaya başlarsanız, groundcover bu trafiği otomatik olarak yakalar. Bu size sağlar:

• Çok adımlı iş akışlarının uçtan uca izleri – Hizmetler boyunca bir isteğin tam yolunu, LLM veya araç kullanıldığını da dahil olmak üzere görürsünüz.
• Her LLM çağrısı için derin bağlam – Her çağrı, kullanılan modeli, gecikmeyi, token kullanımını, promt ve yanıtları ve ilişkili günlükleri ve altyapı metriklerini içerir.
• Gecikme ve koşullara göre güçlü filtreleme – Örneğin, bir saniyeden uzun tüm Claude 3.5 çağrılarını filtreleyebilir ve hemen SLA’nızı ihlal eden izleri inceleyebilirsiniz.
• LLM davranışı ile bağlantılı uyarılar ve paneller – Veriler mevcut olduğunda, SLA ihlalleri için uyarılar oluşturabilir veya gecikme, verim, token kullanımı ve hataları izleyen paneller oluşturabilirsiniz.

Her şey kenarda eBPF tarafından toplanıp kendi bulutunuzda depolandığı için, bu yüksek granülite görünürlüğü, her ajan veya araç çağrısı içine enstrümantasyon eklemeye gerek kalmadan elde edersiniz.

LLM dağıtımlarında hangi veri güvenliği ve uyumluluk risklerini görüyorsunuz ve observability nasıl bu riskleri azaltabilir?

LLM dağıtımları bazı benzersiz veri riskleri getirir:

• Sınırsız kullanıcı girişi – Kullanıcılar sohbet benzeri arayüzler aracılığıyla çok hassas bilgileri paylaşabilir. Bu, kişisel veri, müşteri verileri veya hiç toplamak istemediğiniz düzenlenmiş bilgiler olabilir.
• Üçüncü taraf model sağlayıcıları – Bu verileri bir dış LLM sağlayıcıya gönderdiğinizde, nereye gittiğini, nasıl depolandığını ve hangi alt işleyicilerin dahil olduğunu sorumlusunuz. Bu, GDPR, veri ikametgahı ve müşteri güveni için önemli sonuçlar doğurur.
• Telemetri olarak hassas verilerin ikinci bir kopyası – Observability.stack’in tüm telemetriyi bir SaaS satıcısına gönderirse, artık bu hassas bilginin başka bir kopyasını dışarıda tutuyorsunuz.

groundcover’ın mimarisi tam olarak bu endişeleri gidermek için tasarlanmıştır:

• Kendi bulut hesabınızda, bir alt hesapta, tam olarak yönetilen bir veri düzlemi olarak çalışan bir getirmekendi bulut modelini kullanıyoruz. Kontrol düzlemi, ölçeklendirir ve yönetir, ancak telemetri verilerinize erişmez, depolamaz veya işlemez.
• Çünkü müşterinin kendi ortamında güvenli bir şekilde yükleri yakalayabiliyoruz, LLM çağrıları, iş akışları ve promt/yanıt verilerini observability katmanında tutarak, bu verileri asla ortamınızdan çıkarmadan observability sağlayabiliriz. Üçüncü taraf depolama veya veri çıkışı hakkında endişelenmenize gerek kalmaz.
• Bu görünürlükle, hangi verilerin nereye aktarıldığını, hangi modellerin ve bölgelerin kullanıldığını, hangi hassas verilerin kullanıldığını ve hangi politikaların uygulandığını görebilirsiniz.

Diğer bir deyişle, observability sadece güvenilirlik ve maliyet aracı değil, aynı zamanda gizlilik, veri ikametgahı ve uyumluluk için bir ana kontrol noktası haline gelir.

Organizasyonlar, tek bir LLM entegrasyonundan birçok AI güçlendirilmiş hizmete ölçeklenirken, hangi operasyonel zorluklar ortaya çıkar ve görünürlük, güvenilirlik ve maliyet etrafında?

İlk entegrasyon genellikle tek bir model ve tek bir iş akışıdır. Bu aşamada, her şey yönetilebilir görünür. Ancak ekipler değer gördüklerinde, kullanım patlar ve birkaç zorluk ortaya çıkar:

• Model ve satıcı yayılması – Ekipler sürekli yeni modeller deniyor. Üretimdeki modellerin listesini güvenle veremezler.
• Token kullanımından kaynaklanan maliyet sürprizleri – Token tüketimi, bağlam uzunluğu ve iş akışı karmaşıklığıyla artar. Token kullanımını model ve iş akışı başına görmediğiniz sürece, maliyetleri yönetmek zor olur.
• Harici sağlayıcılarla ilgili güvenilirlik bağımlılığı – Kullanıcı odaklı API’ler, model gecikmesine veya hatalarına duyarlı hale gelir, bu da SLA’ları bozabilir, temel altyapı sağlıklı olsa bile.
• Artan enstrümantasyon borcu – Geleneksel observability, enstrümantasyon eklemenin zamanı olduğunu varsayar. Hızla değişen AI yığınlarında, geliştiriciler genellikle buna zaman ayıramaz.

groundcover, bu sorunları otomatik olarak keşfedilen AI trafiği ve ardından size sağlar:

• Hangi modellerin ve satıcıların kullanıldığını gösteren merkezi görünürlük.
• Gecikme, verim ve token kullanımını zaman içinde gösteren paneller.
• LLM davranışı ile bağımlı hizmetler arasındaki korelasyon.
• AI tarafından sürülen SLO ihlalleri için uyarılar.

Bu, AI’yi “bir cool AI özelliği”nden “AI, kritik hizmetlerin dozensına dokulu”na ölçeklendirirken kontrolü kaybetmeden yardımcı olur.

LLM observability’nin, agentic AI, çok model orkestrasyonu ve düzenleyici baskıların hızlandığı gelecek beş yıl içinde nasıl evrileceğini bekliyorsunuz?

Hala erken günlerdeyiz. Gelecek beş yıl içinde birkaç büyük değişim bekliyorum:

• İstekten, ajan düzeyine anlaşma – Observability, model çağrılarını yakalamaya genişleyecek, araç dizilerini, akıl yürütme yollarını ve yeniden deneme mantığını da içerecektir.
• Zengin semantik ve politika sinyalleri – Hallucinasyonlar, güvenlik sorunları ve marka uyumu için otomatik kalite kontrolleri standart metriklere dönüşecek.
• Gözetim ve gizlilik ile daha sıkı bağ – Düzenleme arttıkça, observability aynı zamanda veri ikametgahı, saklama ve onaylı model kullanımı için bir uygulama ve denetim katmanı olarak hizmet edecek.
• Çok model, çok satıcı optimizasyonu – Ekipler, performans ve maliyet temelinde modeller arasında trafiği dinamik olarak yönlendirecek, gerçek zamanlı observability verileri tarafından yönlendirilecek.
• Daha az manuel enstrümantasyon – eBPF tabanlı toplama ve otomatik keşif gibi teknikler, yenilik yaparken yavaşlamadan default haline gelecek.

Kısaca, LLM observability “AI için nice-to-have paneller”den, organizasyonun yaptığı her şeyde güvenilirlik, maliyet kontrolü, veri yönetimi ve ürün kalitesini bağlayan merkezi bir sinir sistemine evrilecek.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular groundcover‘ı ziyaret edebilir.