ELASTIC AI AGENT BUILDER İLE ELASTICSEARCH VERİSİNİ KONUŞMAKTIR

Amazon Bedrock ve Claude Haiku 4.5 ile uçtan uca uygulama

Geçtiğimiz hafta yayımladığım Elastic Stack laboratuvar çalışmasında, Azure üzerinde Docker tabanlı Elasticsearch ve Kibana ortamımızı kurmuş, SSH tüneliyle güvenli erişim sağlamış, örnek web loglarını ES|QL ile sorgulayıp etkileşimli dashboard’lara dönüştürmüştük. O gün veriyi konuşturmuştuk; bu çalışmada ise veriye doğal dilde soru soracağız. Claude Haiku 4.5’in kullanıcı talebini nasıl yorumladığını, Elastic AI Agent Builder’ın doğru aracı nasıl çalıştırdığını ve Elasticsearch üzerinde hesaplanan gerçek sonuçların nasıl anlaşılır bir cevaba dönüştürüldüğünü adım adım inceleyeceğiz. Kısacası bu kez Elasticsearch ile sohbet edeceğiz.

Mimaride Kim Ne Yapıyor?

Bu laboratuvarı anlamanın anahtarı, LLM, agent, Agent Builder, tool ve Elasticsearch rollerini birbirinden ayırmaktır.

Bileşen	Görevi
Agent Chat	Kullanıcının doğal dilde sorusunu yazdığı arayüzdür.
Agent	Belirli bir iş amacı için model, talimatlar, izin verilen tool’lar ve cevaplama kurallarını bir araya getiren yapılandırmadır; ayrı bir LLM değildir.
Agent Builder	Kullanıcı sorusunu, agent talimatlarını ve izin verilen tool tanımlarını LLM’e iletir. LLM’in seçtiği tool’u çalıştırır ve sonucu yeniden modele aktarır.
LLM (Claude Haiku 4.5)	Sorunun niyetini yorumlar; Agent Builder’ın sunduğu tool’lar arasından uygun olanı seçer, gerekli parametreleri üretir ve Elasticsearch sonucunu doğal dille açıklar.
Tool	platform.core.search, Agent Builder tarafından çalıştırılan işlevdir. Elasticsearch üzerinde arama, filtreleme, gruplama ve ES\|QL sorgusu yürütür.
Elasticsearch	Gerçek veriyi tutar; sorguyu çalıştırır, sayım ve hesaplamaları yapar ve sonucu geri döndürür.

Uçtan uca akış

1	Kullanıcı, sorusunu Agent Chat üzerinden iletir.	→	2	Agent Builder; soruyu, agent talimatlarını ve izin verilen tool listesini LLM’e gönderir.
3	LLM, kullanıcı niyetini yorumlar ve sunulan tool’lar arasından uygun olanı seçer.	→	4	Agent Builder, LLM’in seçtiği tool’u gerekli parametrelerle çalıştırır.
5	Elasticsearch sorguyu yürütür, gerçek sonucu hesaplar ve geri döndürür.	→	6	Agent Builder sonucu LLM’e iletir; LLM bunu anlaşılır bir yanıt veya yönetim özeti olarak açıklar.

Kritik ayrım: Agent Builder, LLM’e hangi talimatların ve hangi tool’ların sunulacağını belirler; LLM ise bu seçenekler arasından hangisinin kullanılacağına karar verir. LLM hesabı yapmaz, Agent Builder veri kaynağı değildir, Elasticsearch de yönetim özeti yazmaz.

Elastic Stack Ortamını Yeniden Başlatmak

Önce docker ps -a komutuyla daha önce oluşturulmuş Elasticsearch ve Kibana container’larını kontrol ettim ve servislerin kapalı olduğunu gördüm. Ardından docker compose ls -a ile elastic-start-local projesini doğruladım, ilgili dizine geçerek docker compose start komutuyla mevcut container’ları yeniden başlattım. Son olarak docker compose ps çıktısında Elasticsearch’ün healthy durumda çalıştığını, Kibana’nın da başlatıldığını doğruladım. Servisler güvenlik amacıyla yalnızca VM’nin yerel arayüzüne bağlanıyordu: Elasticsearch 127.0.0.1:9200, Kibana ise 127.0.0.1:5601.

Docker Compose projesi yeniden başlatıldı. Elasticsearch’ün healthy durumda olduğu, Kibana’nın ise başarıyla ayağa kalktığı doğrulandı.

2. Amazon Bedrock Üzerinde Modeli Doğrulamak

Amazon Bedrock Playground’da Anthropic sağlayıcısı altından hızlı ve maliyet odaklı Claude Haiku 4.5 modeli ile US inference profile seçildi.

Kısa bir test istemiyle Claude Haiku 4.5 erişimi doğrulandı. Yanıtın dönmesi, AWS hesabının modeli başarıyla çağırabildiğini gösterdi.

3. Amazon Bedrock Modelini Elastic’e Bağlamak

Kibana’daki External Inference ekranı açıldı. Bu bölüm, harici model sağlayıcılarını Elasticsearch inference endpoint’i olarak tanımlamak için kullanılır.

Amazon Bedrock servisi seçilerek AWS erişim bilgileri girildi. Anahtarlar yalnızca model çağırma yetkisi taşıyan IAM kullanıcısına aitti ve ekranda maskeli tutuldu

Anthropic sağlayıcısı, Claude Haiku 4.5 US inference profile, us-east-1 bölgesi ve chat_completion görev türü tanımlandı. Endpoint kimliği bedrock-claude-haiku-45-chat olarak belirlendi.

Inference endpoint başarıyla oluşturuldu ve listede chat_completion türünde görünmeye başladı. Böylece model Agent Builder tarafından kullanılabilir hale geldi.

Dev Tools Console açılarak oluşturulan inference endpoint’in doğrudan API üzerinden test edilmesi için istek alanı hazırlandı.

Streaming inference çağrısı 200 OK ile yanıtlandı. Bu sonuç, Elasticsearch’ten Amazon Bedrock’a ve Claude Haiku 4.5’e uzanan bağlantının uçtan uca çalıştığını doğruladı.

4. Örnek Destek Verisini Hazırlamak

support_tickets index’i; tarih, ürün, önem seviyesi, durum, müşteri, kategori, çözüm süresi ve açıklama alanlarını içerecek şekilde oluşturuldu.

Farklı ürün ve önem seviyelerini temsil eden 16 sentetik destek kaydı Bulk API ile yüklendi. errors: false değeri, tüm kayıtların hatasız işlendiğini gösterdi.

GET support_tickets/_count sorgusuyla veri setinde 16 kayıt bulunduğu doğrulandı. Böylece Agent Builder testlerinden önce Elasticsearch tarafındaki gerçek sayı kesinleştirildi.

Bu noktada laboratuvarın üç temel bileşeni hazırdı:

Veri kaynağı: Elasticsearch / support_tickets

LLM sağlayıcısı ve model: Amazon Bedrock / Claude Haiku 4.5

Elastic inference endpoint: bedrock-claude-haiku-45-chat

5.Agent Builder ile İlk Doğal Dil Sorgusu

Hazır Elastic AI Agent açıldı ve alt bölümde bedrock-claude-haiku-45-chat endpoint’inin seçili olduğu görüldü.

Uçtan uca akış başarıyla çalıştı. Agent Chat’e doğal dilde sorduğumuz soru doğru biçimde yorumlandı ve support_tickets index’indeki gerçek kayıt sayısı 16 olarak döndürüldü.

Completed reasoning görünümü, LLM’in kullanıcı niyetini yorumlayıp platform.core.search tool’unu seçtiğini ve arama sürecini başlattığını gösterdi.

Reasoning ekranında gerçek görev paylaşımı görünür hale geldi. Claude Haiku 4.5, sorunun support_tickets index’indeki toplam belge sayısını istediğini anladı ve platform.core.search tool’unun kullanılmasına karar verdi.

Ekrandaki adımların anlamı:

“I’ll search…”: LLM, kullanıcı niyetini yorumladı.

“I need to search this index…”: Cevap vermeden önce gerçek veriye bakılması gerektiğini belirledi.

“Calling tool platform.core.search”: Kullanılacak tool’u LLM seçti.

“Identifying the most relevant data source”: Tool çağrısı kapsamında support_tickets veri kaynağı belirlendi.

“Analyzing strategy…”: Arama ve hesaplama yaklaşımı planlandı.

“Generating an ES|QL query…”: platform.core.search, toplam kayıt sayısını hesaplayacak ES|QL sorgusunu hazırladı.

Sorgu Agent Builder tarafından Elasticsearch üzerinde çalıştırıldı ve sonuç 16 olarak modele geri gönderildi.

Claude Haiku 4.5, Elasticsearch’ten dönen sonucu Türkçe ve doğal bir cümleye dönüştürdü.

Kısacası LLM tool’u seçti, Agent Builder tool’u çalıştırdı, sonucu Elasticsearch hesapladı.

Claude index’in içine doğrudan girmedi ve 16 sayısını tahmin etmedi; doğruluk kaynağı Elasticsearch oldu.

LLM, toplam kayıt sayısını bulmak için platform.core.search tool’unu seçti. Tool aşağıdaki ES|QL sorgusunu oluşturdu:

FROM support_tickets

| STATS total_count = COUNT(*)

Agent Builder sorguyu Elasticsearch üzerinde çalıştırdı; total_count = 16 sonucu modele geri iletildi. Claude Haiku 4.5 de bu gerçek sonucu doğal dile çevirdi. Burada karar LLM’e, orkestrasyon Agent Builder’a, hesaplama ise Elasticsearch’e aitti.

Ekranın altındaki metrikler de önemli:

Süre: 12 saniye
Girdi: 34.760 token
Çıktı: 400 token

34.760 input token yalnızca yazdığımız kısa sorudan oluşmuyor; Agent Builder’ın sistem talimatları, hazır tool açıklamaları, agent bağlamı ve işlem sırasında modele gönderilen diğer bilgiler de buna dâhil. Bu nedenle hazır Elastic AI Agent oldukça geniş bir başlangıç bağlamı kullanıyor. Laboratuvar için sorun değil ama üretim ortamında maliyet ve gecikme açısından agent’ın tool ve talimat kapsamının daraltılması önemlidir.

6.Daha Gelişmiş Analiz Senaryoları

İkinci soruda kritik destek kayıtları ürün bazında gruplandı. Sonuçta Elasticsearch 4 kayıtla en yüksek kritik olay sayısına sahip ürün olarak belirlendi

platform.core.search tool’u doğal dildeki talebi aşağıdaki ES|QL sorgusuna dönüştürdü:

FROM support_tickets

| WHERE severity == “Critical”

| STATS count = COUNT(*) BY product

| SORT count DESC

| LIMIT 100

Sorguda support_tickets verisi seçildi, yalnızca Critical kayıtlar filtrelendi, kayıtlar ürün bazında sayıldı ve sonuçlar büyükten küçüğe sıralandı. Elasticsearch beş ürün grubu döndürdü; Claude Haiku 4.5 ise bu sonucu tabloya çevirerek 4 kritik kayıtla Elasticsearch’ü ilk sırada gösterdi.

Ekrandaki metrikler:

Toplam süre: 14 saniye
Girdi: 35.986 token
Çıktı: 658 token

Girdi miktarının yüksek olması, sorumuzun uzunluğundan değil; hazır Elastic AI Agent tarafından modele gönderilen sistem talimatları, yerleşik tool tanımları, veri keşif bağlamı ve önceki konuşma geçmişinden kaynaklanıyor. Bu durum, daha sonra oluşturacağımız dar kapsamlı özel agent’ın neden önemli olduğunu da gösterecek.

Şimdi hazır agent ile son ve daha güçlü senaryomuzu deneyelim:

Son 30 gündeki kritik destek kayıtlarını analiz et. Ürün bazındaki dağılımı ve kayıtların açık, kapalı veya çözümlenmiş durumlarını karşılaştır. En fazla operasyonel risk taşıyan ürünü belirle ve yönetim için üç cümlelik kısa bir değerlendirme hazırla.

Bu soru; tarih filtresi, ürün gruplaması, durum karşılaştırması ve yönetici dilinde yorumlama yeteneklerini birlikte test edecek.

Üçüncü ve en kapsamlı senaryomuz da doğru sonuç verdi. Agent, son 30 güne ait kritik kayıtları ürün ve durum bazında karşılaştırarak toplam 8 kritik kayıt bulmuş:

Elasticsearch: 3 kayıt — 2 açık, 1 çözümlenmiş
Redis: 2 kayıt — 1 açık, 1 kapalı
GitLab: 1 açık kayıt
PostgreSQL: 1 kapalı kayıt
OpenShift: 1 çözümlenmiş kayıt

Toplamda 4 açık, 2 kapalı ve 2 çözümlenmiş kritik kayıt bulunuyor. Agent’ın Elasticsearch’ü en yüksek operasyonel risk taşıyan ürün olarak belirlemesi de mantıklı; çünkü hem en fazla kritik kayıt bu üründe hem de bunların ikisi hâlâ açık durumda.

Tek bir doğal dil talebinden tarih filtresi, önem seviyesi filtresi, ürün ve durum bazında gruplama, risk değerlendirmesi ve yönetim dilinde özet üretildiğini gösteriyor. Yani Elasticsearch hesaplamayı yaptı; Claude Haiku 4.5 ise gerçek sonuçları operasyonel yoruma dönüştürdü.

Şimdi yalnızca Completed reasoning bölümünü açalım. Üretilen gerçek ES|QL sorgusunu ve bu sonuç için kaç tool çağrısı yapıldığını inceleyelim.

Bu ekran, üçüncü senaryonun nasıl çözüldüğünü açık biçimde gösteriyor. platform.core.search tool’u doğal dildeki isteği şu ES|QL sorgusuna dönüştürdü:

FROM support_tickets

| WHERE severity == “Critical” AND created_at >= NOW() – 30 days

| STATS count = COUNT(*) BY product, status

| SORT product, status

| LIMIT 100

Burada önce son 30 gündeki Critical kayıtlar filtrelenmiş, ardından kayıtlar hem ürün hem de durum alanına göre gruplanmış. Ekrandaki “Found 7 results”, yalnızca 7 destek kaydı bulunduğu anlamına gelmiyor; Elasticsearch’ün 7 farklı ürün–durum kombinasyonu döndürdüğünü gösteriyor. Bu gruplardaki count değerleri toplandığında toplam 8 kritik destek kaydı elde ediliyor:

Elasticsearch–Open: 2
Elasticsearch–Resolved: 1
Redis–Open: 1
Redis–Closed: 1
GitLab–Open: 1
PostgreSQL–Closed: 1
OpenShift–Resolved: 1

Agent daha sonra bu yapılandırılmış sonucu yorumlayarak Elasticsearch’ü en fazla operasyonel risk taşıyan ürün olarak belirledi. Yani bu örnekte tek bir ES|QL sorgusu, hem ürün dağılımını hem durum karşılaştırmasını oluşturmak için yeterli oldu.

Ekrandaki performans değerleri de şöyle:

Yanıt süresi: 16 saniye
Modele gönderilen giriş: 38.018 token
Model çıktısı: 1.404 token

Bu yüksek giriş miktarı veri setimizin büyüklüğünden kaynaklanmıyor. Hazır Elastic AI Agent; sistem talimatlarını, genel amaçlı tool tanımlarını, konuşma geçmişini ve arama bağlamını da modele gönderiyor. Bu nedenle sıradaki mantıklı adımımız, yalnızca support_tickets verisine odaklanan daha kontrollü bir BT Operasyon Analisti agent’ı oluşturmak olacak. Böylece agent kavramını uygulamalı olarak gösterecek ve genel amaçlı hazır agent ile özel agent arasındaki farkı inceleyeceğiz.

Bu noktada genel amaçlı Elastic AI Agent yerine yalnızca destek kayıtlarına odaklanan özel bir agent oluşturduk. Özel agent; belirli bir kullanım senaryosu için talimatları, araçları ve cevaplama davranışını sınırlandırarak daha kontrollü bir çalışma modeli sunar.

7. Özel Agent: BT Operasyon Analisti

Manage components ekranından yeni bir özel agent oluşturma süreci başlatıldı. Amaç, genel agent yerine yalnızca destek kayıtlarına odaklanan kontrollü bir yapı kurmaktı.

BT Operasyon Analisti için agent kimliği, açıklama ve özel talimatlar tanımlandı. Talimatlar, yalnızca support_tickets verisine dayanılmasını ve tahmin üretilmemesini şart koştu

Agent’a yalnızca platform.core.search tool’u atandı. Böylece modelin kullanabileceği araç sayısı azaltılarak görev kapsamı daraltıldı.

BT Operasyon Analisti başarıyla oluşturuldu ve hazır Elastic AI Agent ile birlikte listelenmeye başladı.

Özel agent’ın sohbet ekranı açıldı. Aynı Claude Haiku 4.5 modeli kullanılırken davranış, özel talimatlar ve sınırlandırılmış tool kapsamıyla kontrol edildi.

Özel agent, iki açık kritik Elasticsearch kaydını öne çıkardı ve bunları operasyonel risk açısından kısa bir yönetim özetine dönüştürdü.

8.Sonuç: Kararı Kim Verdi, Hesabı Kim Yaptı?

Bu laboratuvarda kullanıcı sorusunu Agent Chat üzerinden iletti. Claude Haiku 4.5 talebin anlamını belirledi ve uygun tool’u seçti. Agent Builder seçilen tool’u çalıştırıp sonucu modele geri taşıdı; Elasticsearch ise ES|QL sorgusunu gerçek veri üzerinde çalıştırarak sayım, filtreleme ve gruplamaları hesapladı. Model son aşamada bu sonucu anlaşılır bir yönetim özetine dönüştürdü