Üretimde System One

Tek çağrı, on altı soru

21 Eylül 2026 · 6 dakika okuma

Tipli bir karar modelinin şeklini, bir sohbet API'sinden geliyorsanız kaçırmanız kolay. Bir istem gönderip bir tamamlama almıyorsunuz. Tek bir durum ile bir soru sözlüğü gönderiyor, soru başına bir cevap alıyorsunuz ve hepsi birlikte değerlendiriliyor. Bu oturduğunda tasarımın birimi soru olmaktan çıkıp karar noktası olmaya başlıyor.

Bir tur, bir çağrı

Müşterinin gönderdiği her mesaj, hattımızda tam olarak bir model isteği üretiyor. O istek mağaza yapılandırmasını, önceki arama durumunu, son sekiz mesajı ve yeni mesajı taşıyor ve hepsi hakkında sekiz ila on altı tipli soru soruyor.

questions = {
  'intent':       choice(...),   # search, support, other, unclear
  'context':      choice(...),   # continue or new
  'focus':        choice(...),   # which text represents the request now
  'adult':        choice(...),   # recipient is an adult
  'budget':       choice(...),   # which number is the budget
  'currency':     choice(...),   # TRY, USD, EUR, none
  'alternatives': choice(...),   # exclude what we already showed
  'price_sort':   choice(...),   # cheaper than before
}
for i, term in enumerate(terms[:8]):
    questions['exclude_' + str(i)] = choice(...)   # does this exclusion still apply

answers = meter.ask(state, questions)   # one request

Bunların sekizi sabit. Gerisi üretiliyor: aktif her dışlama için bir Choice, en fazla sekiz tane, her biri o terimin mevcut aramada hâlâ geçerli olup olmadığını soruyor. Kimsenin bir şey elemediği bir konuşma sekiz soru soruyor. Dört düzeltme derinliğindeki bir konuşma on iki.

Sorular birbirinin cevabına bağlı değil, bunu mümkün kılan da bu. Hepsi aynı durumun, aynı anda alınmış okumaları. Biri diğerinin cevabına ihtiyaç duysaydı yine sıralı çağrılara dönerdiniz, ve tasarım baskısı, duymayacakları bir formülasyon bulmak yönünde.

Bunun yerine ne yazacaktınız

Bir sohbet modeliyle iki seçeneğiniz var ve ikisi de kötü. Sekiz ayrı istek gönderip sekiz gidiş dönüş ödersiniz, ya da sekiz cevabın hepsini JSON olarak isteyen tek bir istem yazıp modelin artık ayrıştıramayacağınız bir şey üretmek için sekiz şansı olduğunu kabul edersiniz; üstelik hangi kısımda kafasının karıştığını anlamanın bir yolu olmadan.

Çoğu kişinin yayına aldığı ikincisi, ve belirli bir biçimde bozuluyor: dokuz şey isteyen bir istem ilk üçünü iyi cevaplar. Dikkat sonludur ve sonraki alanlara artanı kalır. Sonunda JSON şemanızı öneme göre yeniden sıralarsınız ki bu, herkesi rahatsız etmesi gereken bir cümledir.

Tipli soruların böyle bir eğimi yok, çünkü her biri bir dizinin kuyruğu olarak üretilmek yerine kendi seçenek kümesine karşı puanlanıyor. İstenmeye değer kısım, hızdan çok bu.

Sonra çağrı sayısını sınırlayın

Tasarım, tur başına bir çağrı. Konuşma başına üç çağrı ise kodun dayattığı sınır, ve var olma nedeni tasarımların savrulması. İkinci bir çağrı kabul edilebilir hale geldiği anda üçüncüsü kolay bir argümandır, ve mesaj başına sınırsız sayıda model çağrısı yapan bir asistan, konuşkan bir kullanıcıyı bekleyen bir maliyet olayıdır.

Tavan bir performans ayar düğmesi değil. Yapısal bir iddia: dördüncü bir çağrıya ihtiyaç duyuyorsanız ayrıştırmada bir şey yanlıştır ve sayıyı yükseltmek yerine onu düzeltmelisiniz.

Çağrı uçta değil, verinin yanında durur

Ön yüzümüz Cloudflare Workers üzerinde çalışıyor. Model çağrısı çalışmıyor, ve nedenini söylemekte fayda var çünkü uçta çıkarım moda cevap.

Gönderdiğimiz durum toplanmıyor, kuruluyor. Önceki arama durumuna, son konuşmaya ve mağaza yapılandırmasına ihtiyaç duyuyor; hepsi PostgreSQL'de yaşıyor. Sıralama adaylarını üreten arama, aynı veritabanındaki bir indekse karşı yapılan bir pgvector benzerlik sorgusu ve önünde yerel bir gömme modeli var. Tipli kararı uçta çalıştırmak, önce bunların hepsini uca göndermek, sonra sonucu kataloğun olduğu yere geri göndermek demek olurdu.

Bu yüzden Worker siteyi sunuyor ve API'yi proxy'liyor, karar ise vektör indeksinin yanında duruyor. Gecikmeye sıçrama değil arama ve model hâkim, ve uçtan uca bir tur yaklaşık 1,5 saniyeye oturuyor. Çıkarımı, durumun zaten bulunduğu yere koyun.

Toplu sormanın işe yaramadığı yer

İki yer var ve buna göre tasarım yapmadan önce ikisini de bilmekte fayda var.

Birincisi, bir grup kaderi paylaşır. Doğrulamamız, tek bir cevap bile kriter kontrolünü geçemezse yanıtın tamamını reddediyor; doğruluk açısından doğru karar bu, ve tek kötü cevabın size bir alan değil bir tur kaybettirdiği anlamına da geliyor. Bağımsız olarak başarısız olabilmesi gereken bir sorunuz varsa o soru grupta yeri yoktur.

İkincisi, durum boyutu da paylaşılıyor. Çağrıdaki her soru aynı durumu görüyor, yani büyük bir yük gerektiren bir soru o yükü diğerlerinin de faturasına yazıyor. Sıralama adaylarımızın bir token tavanına bütçelenmesinin ve hiçbir kararın bağlı olmadığı alanlardan arındırılmasının nedeni bu. Grup soru başına ucuz, bayt başına bedava değil.

Navlu, e-ticaret mağazaları için konuşma tabanlı bir ürün keşif asistanıdır. Tur başına tek bir Jev çağrısı, konuşma başına üçle sınırlı, uçta değil pgvector indeksinin yanında çalışıyor.

← Tüm yazılar