Entegrasyon rehberleri · 2026-09-29
Türkçe destek talebi sınıflandırma API'si: Laya ile otomatik yönlendirme
Türkçe destek taleplerini ekip, aciliyet ve memnuniyetsizlik açısından tek istekte sınıflandırın. Laya ile soru tasarımı, istek gövdesi, eşikler, insana devir ve maliyet.
Kısa yanıt: tek istek, üç karar
Bir destek talebini doğru ekibe yönlendirmek için üç şeyi bilmek çoğu zaman yeterlidir: talep hangi ekibin işi, müşteri aciliyet bildiriyor mu ve ne kadar rahatsız. llmtr/laya bu üç soruyu aynı metne tek istekte sorar ve her biri için olasılıkla birlikte bir karar döndürür. Talep metni Türkiye dışına çıkmaz.
Bu rehber, POST /v1/systemone uç noktasına bir choice, bir noul ve bir score sorusu göndermeyi, dönen olasılıkları eşiklerle karara bağlamayı ve emin olunamayan talepleri bir kişiye devretmeyi anlatır. Kod örnekleri LLMTR API anahtarınızın LLMTR_API_KEY ortam değişkeninde durduğunu varsayar.
1. Soruları tasarlayın
Her soru bir anahtar, bir tip ve bir talimat taşır. Anahtar modele gönderilmez, yalnızca yanıtı eşleştirmek içindir; sorunun tamamını talimata yazın. Seçenekleri ekiplerinizin gerçek adlarıyla kurun, açıklamaları üç dört anahtar kelimeyle sınırlayın.
Hangi tipi seçeceğiniz sorunun doğasına bağlıdır. Tek bir cevabı olan evet/hayır sorusu noul, listeden seçim choice, sıralı bir ölçek score ile sorulur. Seviye ölçmek için noul kullanmayın: 0,5 evet olasılığı orta seviye değil, modelin iki cevaba eşit olasılık verdiği anlamına gelir.
| Anahtar | Tip | Talimat | Kullanım |
|---|---|---|---|
| ekip | choice | Which team should handle this ticket? | Talebi ekip kuyruğuna yazar |
| acil_mi | noul | Does the customer say the matter is urgent? | Önceliği yükseltir |
| memnuniyetsizlik | score | How upset is the customer? | Kıdemli temsilciye yönlendirir |
2. İsteği gönderin
Talep metnini state alanına, soruları questions alanına koyun. Talimatlar İngilizce, seçenek açıklamaları Türkçedir; Türkçe metinlerde Laya ile en iyi sonucu bu yazım verir. Metin olduğu gibi Türkçe kalır, çevirmeniz gerekmez.
Yanıtta her anahtar kendi tipiyle döner: ekip için seçilen seçenek, tüm seçeneklerin olasılıkları ve bir güven değeri; acil_mi için 0 ile 1 arasında evet olasılığı; memnuniyetsizlik için ölçek üzerindeki konum. Yanıttaki usage alanı girdi ve çıktı token sayılarını taşır.
POST /v1/systemone için destek talebi gövdesi
{
"model": "llmtr/laya",
"state": "Konu: Giriş yapamıyorum. Dünden beri şifremi sıfırlamama rağmen panele giremiyorum, yarın sabah sunum var. Lütfen acil dönün.",
"questions": {
"ekip": {
"type": "choice",
"instructions": "Which team should handle this ticket?",
"criteria": {
"faturalama": "fatura, ödeme, iade",
"teknik": "hata, kesinti, giriş sorunu",
"satis": "fiyat, paket, teklif",
"hesap": "şifre, kullanıcı, yetki"
}
},
"acil_mi": {
"type": "noul",
"instructions": "Does the customer say the matter is urgent?"
},
"memnuniyetsizlik": {
"type": "score",
"instructions": "How upset is the customer?",
"criteria": [
"Calm",
"Annoyed but polite",
"Very angry"
]
}
}
}
3. Olasılığı eşikle karara bağlayın
Yalnızca en olası ekibi kullanacaksanız choice alanını okumak yeterlidir. Otomatik yönlendirmede ise bir eşik koyun: en yüksek olasılık eşiğin altındaysa talebi genel kuyruğa ya da bir kişiye bırakın. Aşağıdaki örnek ekip için 0,6, aciliyet için 0,8 eşiği kullanır.
Eşikleri ve soru metinlerini tek bir dosyada tutun. Bir yönlendirme hatasını incelerken bakılacak yer burasıdır; koda dağılmış sabitler sonradan bulunamaz. Hata durumunda talebi düşürmeyin: istek başarısız olursa talep, sınıflandırma hiç yokmuş gibi genel kuyruğa gitmelidir.
Her kararı olasılıklarıyla birlikte talebin kaydına yazın. Bir temsilci talebi başka bir ekibe taşıdığında bu, modelin yanıldığı bir örnektir. Bu örnekleri biriktirip eşikleri ve seçenek açıklamalarını düzenli aralıklarla gözden geçirin; böylece sınıflandırma, ekiplerinizin yapısı değiştikçe onunla birlikte güncel kalır.
Eşik ve insana devir ile yönlendirme
import os, requests
TEAM_THRESHOLD = 0.6
URGENT_THRESHOLD = 0.8
def route(ticket_text: str, questions: dict) -> dict:
response = requests.post(
"https://llmtr.com/v1/systemone",
headers={"Authorization": f"Bearer {os.environ['LLMTR_API_KEY']}"},
json={"model": "llmtr/laya", "state": ticket_text, "questions": questions},
timeout=30,
)
response.raise_for_status()
answers = response.json()["answers"]
team = answers["ekip"]
top = max(team["probabilities"].values())
return {
"queue": team["choice"] if top >= TEAM_THRESHOLD else "human_review",
"urgent": answers["acil_mi"]["noul"] >= URGENT_THRESHOLD,
}
4. Türkçe metinlerde yazım
Laya Türkçe metni anlar; sonucu en çok etkileyen şey soruların yazımıdır. Canlıya almadan önce aynı soru setini kendi geçmiş taleplerinizden seçtiğiniz 50-100 örnekle deneyin ve eşikleri bu sonuçlara göre koyun.
- Evet/hayır ve score talimatlarını İngilizce yazın; talep metni Türkçe kalabilir.
- Choice açıklamalarını Türkçe ve kısa tutun: fatura, ödeme, iade gibi anahtar kelimeler yeterlidir.
- Diğer gibi genel bir seçeneğin seçilmesine güvenmeyin; en yüksek olasılık düşükse talebi belirsiz sayın.
- Uzun yazışmalarda yalnızca konu satırını ve son müşteri mesajını gönderin.
5. Maliyet ve limitler
Laya'da girdi 1M token başına $0,03, çıktı ücretsizdir. Laya metni her soru için ayrı sayar: bu rehberdeki üç soruyla ortalama 300 token tutan bir talep yaklaşık 900 girdi token'ı eder, 10.000 talep 9 milyon token ve yaklaşık $0,27 tutar. Kullanmayacağınız bir soruyu istekten çıkarın. Model fiyatına platform marjı eklenmez; bakiye düşümü yanıttaki girdi token sayısından hesaplanır.
llmtr/laya 1.024 token bağlamla çalışır; bu, uzun bir konuşma geçmişi için değil tek bir talep için yeterli bir uzunluktur. Tek istekte en fazla 64 soru, choice sorusunda en fazla 100 seçenek tanımlanabilir. Sınırı aşan istek 413, geçersiz bir soru tanımı 422 döner ve mesaj hangi sorunun sorunlu olduğunu söyler. Uç nokta akış desteklemez; yanıt tek parça gelir.
Türkçe destek taleplerini Laya ile sınıflandırma
llmtr/laya ile bir destek talebinin ekibini, aciliyetini ve memnuniyetsizlik seviyesini tek istekte belirleyip eşikle yönlendirme.
- Soruları tasarlayın. Ekip için choice, aciliyet için noul, memnuniyetsizlik için score sorusu tanımlayın; talimatları İngilizce, seçenek açıklamalarını Türkçe yazın.
- İsteği gönderin. Talep metnini state, soruları questions alanına koyup model llmtr/laya ile POST /v1/systemone uç noktasına gönderin.
- Eşik koyun. En yüksek olasılık eşiğin altındaysa talebi bir kişiye devredin; eşikleri tek bir dosyada tutun.
- Kendi örneklerinizle ölçün. Canlıya almadan önce 50-100 geçmiş talep üzerinde sonuçları kontrol edip eşikleri ayarlayın.
Sık sorulan sorular
Talep metnini İngilizceye çevirmem gerekiyor mu?
Hayır. llmtr/laya Türkçe metni doğrudan değerlendirir. Yalnızca evet/hayır ve score talimatlarını İngilizce yazmanız önerilir; choice seçeneklerinin açıklamaları Türkçe kalabilir.
Model emin değilse ne olur?
Laya yine bir karar döndürür, ama olasılık dağılımı düz olur. Bu yüzden en yüksek olasılığı bir eşikle karşılaştırın ve eşiğin altındaki talepleri bir kişiye devredin. Eşiği kendi örnekleriniz üzerinde belirleyin.
Destek talepleri Türkiye dışına çıkar mı?
Hayır. Laya Türkiye'de barındırılır ve istek içeriği Türkiye dışına çıkmaz. Bu, kişisel veri taşıyan taleplerde yurt dışına aktarım değerlendirmesini bu çağrı için gereksiz kılar; KVKK kapsamındaki diğer yükümlülükler sizde kalır.
İlgili yazılar
- Laya: Türkiye'de barındırılan ilk System One karar modeli
- Metin sınıflandırma modeli seçimi: Laya, Laya English ve Laya Typed Decisions
- Jev ile destek talebini doğru ekibe yönlendirme
- Claude Haiku 4.5: sınıflandırma, destek ve özetleme için Opus'a çıkmadan önce ilk durak
- Yerli yapay zeka modeli seçerken LLM API tarafında nelere bakılır?