Metin-sorgu ajanımız, öncü modellerde 45 saniye süren işlemi, aynı doğrulukta ve 20'de 1 maliyetle GLM 5.3 Flash ile 2 saniyeye indirdi.
Conversion'daki son AI çalışmalarımızın çoğu, genel pazarlama zekasına odaklandı.
Pazarlama otomasyon ekipleri, sistemler arasında geniş bir yelpazede çalışma yapar: hesapları araştırmak, kitleler oluşturmak, kampanyalar planlamak, içerik yazmak ve performans verilerine göre hareket etmek. Bu iş akışları arasında akıl yürütebilen ve yetenekli bir pazarlamacının kullanacağı araçları kullanabilen ajanlar geliştiriyoruz.
Bu sistemler, yetenekli, genel amaçlı modellerden faydalanır. Çalışma açık uçludur ve iyi bir muhakeme genellikle bir görevi hızlıca tamamlamaktan daha önemlidir.
Ancak birikmiş daha küçük, daha odaklı AI özelliklerimiz de vardı. Bunlardan biri doğal dil filtreleriydi: kullanıcının bir kitleyi düz İngilizce ile tanımlamasına ve bu tanımı, Conversion'ın mevcut ifade oluşturucusunda inceleyip düzenleyebileceği bir filtreye dönüştürmesine izin vermek. (Conversion'da bir filtreye "ifade" denir.)
İlk başta bu, basit bir yapılandırılmış oluşturma görevi gibi görünüyordu. Modele mevcut alanları verin, çıktı formatını tanımlayın ve JSON üretmesini isteyin. Bunun, düşünülenden çok daha zor olduğu ortaya çıktı.
GLM 5.3 Flash kullanılarak 5 saniyenin altında oluşturulan bileşik ifade.
Aşağıdaki örneği ele alalım:
Son 30 gün içinde demo formunu en az bir kez göndermiş, 50.000 dolardan fazla değere sahip açık bir fırsatı olan bir yazılım şirketinde çalışan kişileri bul.
Bu, sistemin şunları yapmasını gerektirir:
- Kullanıcının "demo formu" ile kastettiği belirli formu bulmak
- Hangi alanın bir şirketin sektörünü temsil ettiğini belirlemek
- Bu çalışma alanının "yazılımı" nasıl temsil ettiğini öğrenmek; bu, tahmin yapmak yerine o alanda gerçekte depolanan değerlere bakmayı gerektirir
- Bir kişiden şirketine ve ardından o şirketin fırsatlarına geçiş yapmak
- "Açık" ve "50.000 dolardan fazla" ifadelerinin aynı fırsat için geçerli olduğundan emin olmak
- Göreceli bir olay penceresi uygulamak
Ayrıca tüm bunları, bir araştırma ajanı gibi değil, bir filtre arayüzü gibi hissettirecek kadar hızlı yapması gerekiyordu.
Küçük bir prompt mühendisliği görevi gibi görünen şey, kısıtlı bir metin-sorgu problemine dönüşmüştü. Bunu çözmek, araç kullanan bir ajan, bir ara temsil (IR), deterministik bir derleyici ve anlamsal bir kıyaslama gerektiriyordu.
Ortaya çıkan kıyaslama olan Statement Bench'te Claude Opus 5, Kimi K3, GLM 5.3 Flash ve bu sabah yayınlanan Gemini 3.8 Flash dahil olmak üzere sekiz modeli çalıştırdık. Sonuçlar aşağıdadır.
Ajana araçlar vermek
Yukarıdaki talebi yanıtlamak için gereken bilgilerin çoğu, müşterinin ortamına özgüdür. Tek bir çalışma alanı, varlıkları ve nesneleriyle birlikte yüz milyonlarca geçmiş alan değerini tutabilir. Bariz nedenlerden ötürü, bunların hepsini tek bir prompt'a koyamazdık.
İlk faydalı mimari kararımız, sorunu sıradan yapılandırılmış oluşturma olarak ele almayı bırakmaktı. Bunun yerine model, küçük bir dizi araç alır. Alanları arayabilir, geçmiş değerleri inceleyebilir ve formlar, kampanyalar, e-postalar ve kitleler gibi işletmeye özgü varlıkları çözümleyebilir. Bu araçları yalnızca talep gerektirdiğinde kullanır.
Bu arama altyapısının büyük bir kısmı, Conversion'daki tüm kayıtlar üzerinde metin ve anlamsal arama sağlayan son Küresel Arama çalışmamızdan geldi. Yakında bununla ilgili daha fazlasını paylaşmayı planlıyoruz!
Temel akış şöyle görünür:
1Doğal dil talebi2 |3 v4 Araç kullanan ajan <-----------------+5 / | \ |6alanlar varlıklar ilişkiler | gerekçelerle reddetme7 \ | / |8 v |9 Kısıtlı IR |10 | |11 v |12 Doğrulayıcı ve derleyici ---------------+13 |14 v15 Üretim ifadesi
Bu, ilk bağlamı küçük tutar. Ayrıca başarısızlıkları anlamayı çok daha kolay hale getirir. Bir ifade yanlışsa, ajanın yanlış varlığı bulup bulmadığını, yanlış alanı seçip seçmediğini, bir ilişkiyi yanlış anlayıp anlamadığını, doğru fikri yanlış temsil edip etmediğini veya derleyicide bir hata olup olmadığını belirleyebiliriz. Bu ayrım daha sonra değerlendirme döngümüz için önemli hale geldi.
Daha küçük bir dil oluşturmak
Araç kullanımı, bağlam sorununu çözdü. Gecikme sorununu çözmedi.
Erken geri bildirimlerden bir ders: kullanıcılar, amaca yönelik bir arayüzde sohbete kıyasla çok daha az gecikmeye tolerans gösterir.
Bu, daha geniş bir paradoksa işaret ediyor. Gecikme beklentilerimizi, sistem için ne kadar zor olduğuna değil, bir görevin bize ne kadar zor göründüğüne göre belirleriz. İçerik yazmak zor görünür çünkü işi görebiliriz. Bir filtreyi tanımlamak basit görünür çünkü zihnimiz bağlamı, varlıkları, ilişkileri ve niyeti sessizce çözer. Model için bu gizli varsayımları yeniden yapılandırmak asıl görevdir. Kullanıcı ne kadar az iş algılarsa, sisteme bunu yapması için o kadar az zaman verir.
Erken geri bildirimlere dayanarak iki hedef belirledik: yaygın sorgular için yüzde 95'in üzerinde doğruluk ve yaklaşık 5 saniyelik yanıt süresi.
Conversion'ın etkileyici bir dahili sorgulama dili vardır. İlk testlerimizde, üretim formatını doğrudan kullanarak yalnızca Claude Opus gibi en büyük modeller onu güvenilir bir şekilde üretebildi. Basit ifadeler bile yaklaşık 45 saniye sürdü.
Görsel ifade oluşturucu, tam dilin yalnızca bir alt kümesini gösterir. Bu alt küme için daha küçük, ajana uygun bir ara temsil oluşturduk. Daha küçük modeller, daha az token kullanarak bunu üretebilirken, deterministik bir derleyici tam üretim formatını ele aldı.
Şu ifadeyi düşünün:
İş unvanı "Direktör" içeriyor.
Orijinal üretim ifadesi şöyle görünür:
1{2 "type": "LOGICAL",3 "version": 1,4 "logical": {5 "operator": "OR",6 "operands": [7 {8 "type": "LOGICAL",9 "version": 1,10 "logical": {11 "operator": "AND",12 "operands": [13 {14 "type": "VARIABLE",15 "version": 1,16 "variable": {17 "variableSchemaId": "550e8400-e29b-41d4-a716-446655440000",18 "where": {19 "type": "LOGICAL",20 "version": 1,21 "logical": {22 "operator": "AND",23 "operands": [24 {25 "type": "LOGICAL",26 "version": 1,27 "logical": {28 "operator": "CONTAINS",29 "operands": [30 {31 "type": "ATTRIBUTE",32 "version": 1,33 "attribute": {34 "name": "value"35 }36 },37 {38 "type": "CONSTANT",39 "version": 1,40 "constant": {41 "value": "Director"42 }43 }44 ]45 }46 }47 ]48 }49 }50 }51 }52 ]53 }54 }55 ]56 }57}
Aynı filtrenin model yönelik temsili şudur:
1{2 "field": "550e8400-e29b-41d4-a716-446655440000",3 "op": "contains",4 "value": "Director"5}
IR birkaç nesilden geçti ve en sonuncusu, küçük modellerin öncekilerde başarısız olduğunu izleyerek şekillendirildi. Büyük bir iyileştirme, daha iyi aynı-kayıt anlambilimini (şema doğrulamasının yakalayamayacağı bir şey) tanıtmaktı:
1{2 "related": "OPPORTUNITY",3 "all": [4 { "field": "<stage uuid>", "op": "equals", "value": "Closed Won" },5 { "field": "<amount uuid>", "op": "gt", "value": 100000 }6 ]7}
Model ve kod arasındaki bu ayrım bize birkaç faydalı özellik kazandırdı:
- Desteklenmeyen ifadeleri ifade etmek zordur
- Aynı-kayıt ilişki anlambilimi görünür
- Alan ve ilişki referansları doğrulanabilir
- Derleyici, modelden bağımsız olarak test edilebilir
- Oluşturulan ifadeler mevcut kullanıcı arayüzünde düzenlenebilir kalır
IR nihayetinde modelin işini azaltır: ajan, kullanıcının niyetini çözer ve kısıtlı bir plan üretir; kod, üretim formatını halleder.
Anlamsal bir kıyaslama oluşturmak
Bir çıktı tamamen geçerli olabilir ve yine de yanlış olabilir. Şu talebi ele alalım:
Kazanılmış, 100.000 dolardan fazla değere sahip bir fırsatı olan şirketlerdeki kişiler.
Bir kişi bir şirkete aittir ve bir şirketin birden çok fırsatı olabilir. Bu filtreyi eşleştirmek, ilişkilerde (kişiden şirkete, şirketten fırsatlara) gezinmek ve yol boyunca iki koşulu kontrol etmek anlamına gelir: anlaşma kazanılmıştır ve anlaşmanın değeri 100.000 dolardan fazladır.
Zorluk, bu koşulların aynı fırsat için geçerli olması gerektiğidir. Bağımsız olarak kontrol edilirlerse, kazanılmış 20.000 dolarlık bir anlaşması ve açık 150.000 dolarlık bir anlaşması olan bir şirket her ikisini de karşılar: her bir koşul bir anlaşmayla eşleşir. Şema doğrulaması bunu asla yakalayamaz.
Bunun gibi birkaç örnek geçtikten sonra, prompt'u düzenlemek onları geriletme riski taşıyordu. Anlamı, yalnızca geçerliliği değil, her değişiklikte kontrol etmenin bir yoluna ihtiyacımız vardı.
Statement Bench'i, müşterilerimizin daha önce oluşturduğu anonimleştirilmiş kitle modellerinden türetilen ürünün davranışları etrafında oluşturduk. Paket şu anda düz alan koşulları, olaylar, göreceli ve takvim zaman pencereleri, ilişkiler ve bileşik sorgular gibi on beş kategori arasında 100 vaka içermektedir.
Her vaka, gerçekçi bir çalışma alanı sanal alanına karşı çalışır. Ajan, üretimde aldığı aynı verileri ve araçları alır.
Değerlendirici birkaç katmanı kontrol eder:
- Ajan bir ifade döndürdü mü?
- IR, şemasını karşılıyor mu?
- Başvurulan alanlar ve ilişkiler mevcut mu?
- İfade derlenip üretim doğrulamasını geçebiliyor mu?
- Talep edilen anlamı temsil ediyor mu?
- Kaç model adımı, araç çağrısı, token ve reddedilen gönderim gerektirdi?
Beşincisi en ilginç olanıdır çünkü geçerlilik anlamsal eşitliği garanti etmez.
Anlamsal kontroller, derlenmiş ifadeyi okuyarak "hem aşamayı hem de tutarı taşıyan tek bir fırsat koşulu", "türü tıklama olan, açma olmayan bir e-posta olayı" veya "özel kampanya koşulu değil, webiner koşulu" gibi şeyleri iddia eder.
Değerlendirme odaklı bir optimizasyon döngüsü çalıştırmak
Kıyaslama, özellik üzerinde çalışmaya devam etme şeklimizi değiştirdi. Bir kodlama ajanından "prompt'u iyileştirmesini" veya "yeni bir IR uygulamasını" istemek yerine, ona iyileştirmenin çalıştırılabilir bir tanımını verebildik.
Döngü şöyle görünüyordu:
- Kıyaslamayı çalıştır
- Başarısızlıkları temel nedenlerine göre gruplandır
- Ajanın araç yörüngesini ve gönderilen IR'yi incele
- Prompt'u, araçları, doğrulayıcıları veya derleyiciyi değiştir
- Kıyaslamayı tekrar çalıştır
- Değişikliği yalnızca sistemi iyileştiriyorsa ve gerilemelere neden olmuyorsa koru
Kodlama ajanları, modelleri karşılaştırmak, IR ile deney yapmak, araç açıklamalarını iyileştirmek ve prompt'u otonom olarak hassaslaştırmak için kıyaslamayı kullanabilirdi. Tam paketi her değişiklikten sonra çalıştırmak, bizi bireysel başarısızlıklara aşırı uyum sağlamaktan da alıkoydu ve bunu doğrulamak için 50 vaka daha ayırdık.
Birkaç değişiklik sonuçları en çok iyileştirdi:
- Yolları, türleri ve yapıyı derleyiciye taşıyın. İlk IR'imiz, modelin tüm ilişkileri açıkça yazmasını sağladı: kişiden şirkete, şirketten fırsata. Alanın meta verileri zaten bu yolu ima eder, bu nedenle derleyici artık onu çıkarır. Aynısını tarihler, tür dönüştürme, olumsuzlama yerleşimi ve grup iç içe geçmesi için de yaptık. Kuralları derleyiciye taşımak, IR'yi basitleştirdi ve şema hatalarını azalttı.
- Açıklamalar ve düzeltmelerle reddet. Her şema ve derleyici reddi, mümkün olduğunda bunun yerine ne yazılacağını söyler: "gt bu alanda olumsuzlanamaz; lte kullan", "kimliği campaign_list'ten kopyala". Küçük modeller bir veya iki denemede yakınsar ve üretim modeli yüz sorguda birkaçında reddedilir.
- Prompt'u küçük modeller için yapılandırın. Prompt'u yeniden düzenlemek doğruluğu değiştirmedi, ancak yeniden deneme sayısını yarıya indirdi ve bu da doğrudan gecikmeyi iyileştirdi. Bu, Anthropic'in Promptlama en iyi uygulamaları sayfasından ilham alındı.
- Düzyazı yerine örnekler kullanın. Biçim referansımızdaki iki ek örnek, açıklama paragraflarının yapamadığı bir dizi hatayı çözdü ve reddedilen gönderimleri kabaca yarıya indirdi.
- Tam bağlam verin veya hiç vermeyin. Modeller, bir aracı çağırmadan önce bağlamda olana yönelir. Bağlam, kısmi veya etiketlenmemiş bir alan kümesi içerdiğinde, model arama yapmak yerine en yakın olanı kullandı ve anlamsal olarak yanlış ifadeler üretti. Kısmi bağlamı araç çağrıları lehine azaltarak, oluşturma oranlarını artırdık ve giriş token'larını beşte bir oranında azalttık.
Nihai üretim yapılandırması olan GLM 5.3 Flash, 100 kıyaslama vakasının tamamını 2,3 saniye medyan gecikme ve yüzde 95'lik dilimde 7,1 saniye ile tamamladı. Ve 100'ün 97'si anlamsal olarak doğruydu. Orijinal üretim formatı yaklaşımıyla karşılaştırıldığında, basit filtreler yaklaşık 45 saniyeden 20'de 1 maliyetle bir saniyenin biraz üzerine düşmüştü.
Statement Bench'te modelleri karşılaştırmak
Kıyaslama ayrıca bize modelleri gerçek görev üzerinde karşılaştırmanın bir yolunu verdi.
2 Eylül 2026'da, aynı 100 vakayı sekiz model üzerinde çalıştırdık. Her model aynı prompt'u, araçları, IR'yi, derleyiciyi ve 30 saniyelik istek zaman aşımını aldı.
Sağlayıcı yönlendirmesi, prompt önbelleğe alma ve geçici çıkarım yükünün tümü gecikmeyi etkiler.
Model
Geçerli yapılar
Anlamsal olarak doğru
P50 gecikme
P95 gecikme
Önbellek okuma
Araç çağrıları
Reddedilen gönderimler
1.000 istek başına tahmini maliyet
Claude Opus 5
100/100 (%100)
100/100 (%100)
3,16s
8,53s
%91,1
162
0
$27,51
GLM 5.2
100/100 (%100)
100/100 (%100)
4,38s
13,02s
%93,5
201
5
$14,94
Kimi K3
100/100 (%100)
100/100 (%100)
5,17s
11,84s
%34,3
157
0
$48,51
GLM 5.3 Flash
100/100 (%100)
97/100 (%97)
2,34s
7,07s
%92,8
163
2
$1,33
DeepSeek V4 Pro
96/100 (%96)
96/96 (%100)
5,53s
24,31s
%47,8
172
1
$12,00
Gemini 3.7 Flash
77/100 (%77)
77/77 (%100)
15,14s
30,01s
%26,5
228
1
$18,24
Gemini 3.8 Flash
76/100 (%76)
76/76 (%100)
14,29s
30,01s
%35,4
266
1
$27,44
DeepSeek V4 Flash
56/100 (%56)
55/56 (%98)
6,79s
30,00s
%41,5
100
1
$0,56
Tahmini maliyetler, 2 Eylül 2026'da her sağlayıcının listelenen promosyonsuz ücreti kullanılarak gözlemlenen giriş, önbelleğe alınmış giriş ve çıkış token'ları kullanılarak 1.000 denenen istek başına hesaplanmıştır. Önbelleğe alınmış giriş, sağlayıcının yayınladığı durumda yayınlanan önbellek okuma ücreti üzerinden, aksi takdirde tam giriş ücreti üzerinden faturalandırılır.
Şekil 1. Maliyete karşı doğruluk. GLM 5.3 Flash, Claude Opus 5'in maliyetinin kabaca yirmide biri ile yüzde 97'ye ulaşıyor.
Şekil 2. Gecikme dağılımı, medyan ve yüzde 95'lik dilim, P95'e göre sıralanmıştır.
Birkaç bulgu öne çıktı.
Ne model boyutu ne de fiyat gecikmeyi öngördü. En hızlı model en küçük ve en ucuz olanıydı. En hızlı ikinci model en büyük ve en pahalı olanıydı.
Başarısızlık, yanlış cevaplardan yavaş cevaplara kaydı. Sekiz modelden altısı, tamamladıkları her ifadede anlamsal olarak doğruydu; aralarındaki farklar neredeyse tamamen zaman aşımı içinde kaç isteğin tamamlandığıyla ilgiliydi. IR ve prompt'ların ilk yinelemelerinde, çoğu küçük model, kıyaslamada yapı adımında %50'nin altında anlamsal doğrulukla başarısız oldu.
Muhakeme token'ları, araç çağrılarını geride bırakıyor. Gemini 3.8 Flash, 192.000 çıkış token'ının 180.000'ini muhakemeye harcadı ve 266 araç çağrısı yaptı; Claude Opus 5, muhakemeye 813 token harcadı, 162 araç çağrısı yaptı ve her vakayı tamamladı. Küresel Arama çabalarımız, her araç aramasını milisaniye aralığına indirdi, bu nedenle kalan maliyet, modelin aralarındaki sırasıdır.
Çıkarım
Modeller belirsizliği çözmede iyidir, kod kesinliği uygulamada iyidir ve ilk başarısızlıklarımızın çoğu, modelden her ikisini de yapmasını istemekten kaynaklandı. Bu ajanı oluşturmak, ikisinden hangisinin her bir parçaya sahip olması gerektiğine karar verme işiydi. Aynısının metin-SQL ve diğer doğal dil arayüzleri için de geçerli olduğunu düşünüyoruz.
Bu sorunlardan herhangi biriyle ilgileniyorsanız, bize ulaşın! İşe alım yapıyoruz.
