LLM'ler İş Kurallarını ve İş Akışı Muhakemesini Nasıl Ele Alır

İş kuralı muhakemesi kod üretiminden daha fazlasıdır

İnsanlar bir LLM'in “iş kuralları hakkında muhakeme yapıp yapamayacağını” sorduğunda genellikle “bir if/else ifadesi yazabiliyor mu?” sorusundan daha zor bir şeyi kastederler. İş kuralı muhakemesi, politikaları tutarlı şekilde uygulama, kararları açıklama, istisnaları ele alma ve özellikle girdiler eksik, dağınık veya değişiyor olduğunda mevcut iş akışı adımıyla uyumlu kalma yeteneğidir.

Muhakeme vs. kod üretimi

Kod üretimi çoğunlukla hedef dilde geçerli sözdizimi üretmekle ilgilidir. Kural muhakemesi ise niyeti korumakla ilgilidir.

Bir model mükemmel geçerli kod üretebilir ama yine de yanlış iş sonucunu üretebilir çünkü:

• Politika metni belirsizdir ("son müşteri", "yüksek risk", "onaylı belgeler").
• Kurallar çelişir ve öncelik belirsizdir.
• Kenar durumlar belirtilmemiştir (kısmi iadeler, çoğaltmalar, hafta sonları/tatiller).
• İş akışı durumu bir sonraki adımda ne olması gerektiğini değiştirir (kabul vs. inceleme vs. nihai onay).

Diğer bir deyişle, doğruluk "derleniyor mu?" değil, "her seferinde işletmenin vereceği kararla eşleşiyor mu ve bunu kanıtlayabiliyor muyuz?" şeklindedir.

LLM'lerden ne beklemeli

LLM'ler politikaları yapılandırılmış kurallara çevirmede, karar yolları önermede ve insanlar için açıklamalar taslaklaştırmada yardımcı olabilir. Ancak hangi kuralın yetkili olduğunu, hangi veri kaynağının güvenilir olduğunu veya davanın şu anda hangi aşamada olduğunu otomatik olarak bilmezler. Kısıtlama olmadan, mantıklı görünen bir cevabı yönetilen olanın yerine kendinden emin bir şekilde seçebilirler.

Bu yüzden amaç "modelin karar vermesine izin vermek" değil, ona yardımcı olabilecek yapı ve kontroller sağlamaktır.

Bu yazının geri kalanının yapacakları

Pratik bir yaklaşım bir boru hattı gibi görünür:

1. Politika metnini kullanılabilir kural temsillerine dönüştürün.
2. Kararların adımlar arasında tutarlı kalması için iş akışı durumunu takip edin.
3. Öncelikleri, istisnaları ve açıklamaları zorlamak için prompt kalıpları kullanın.
4. Kararları yalnızca onaylı verileri kullanarak araçlar ve retrieval ile dayandırın.
5. Belirsizliği azaltmak için çıktıları şemalarla sınırlayın.
6. Hatalar yayına alınmadan yakalansın diye doğrulayın, test edin ve izleyin.

Bu, zekice bir kod parçası ile gerçek iş kararlarını destekleyebilen bir sistem arasındaki farktır.

İş kuralları ve iş akışları: kısa, yalın bir hatırlatma

Bir LLM'in "muhakeme" yapmasını tartışmadan önce ekiplerin sık sık birlikte sardığı iki şeyi ayırmak faydalıdır: iş kuralları ve iş akışları.

İş kuralları nedir?

İş kuralları, kuruluşunuzun tutarlı bir şekilde uygulanmasını istediği karar bildirimleridir. Politikalar ve şu tür mantıklarla ortaya çıkarlar:

• Uygunluk: Bir fayda, plan veya özelliğe kim hak kazanır?
• Fiyatlandırma: Hangi indirim ne zaman uygulanır?
• Onaylar: Ne zaman yönetici incelemesi gerekir?
• Uyum: Ne kaydedilmeli, kırpılmalı veya engellenmelidir?

Kurallar genellikle "EĞER X, O ZAMAN Y" biçiminde ifade edilir (bazen istisnalarla) ve net bir sonuç üretmelidir: onay/red, fiyat A/fiyat B, daha fazla bilgi talebi vb.

İş akışları nedir?

Bir iş akışı, işi başlangıçtan bitişe taşıyan süreçtir. "Neye izin verildiği"nden çok "sonraki adımda ne olacağı" ile ilgilidir. İş akışları genellikle şunları içerir:

• Durumlar: gönderildi → incelemede → onaylandı/red edildi → tamamlandı
• Adımlar ve devreler: müşteri destek → finans → müşteri
• Zamana dayalı olaylar: hatırlatmalar, SLA'lar, 14 gün sonra otomatik iptal
• Eserler: formlar, ekler, sebep kodları, denetim notları

Küçük bir örnek: iade talepleri

Bir iade talebi hayal edin.

Kural örneği: "İadeler satın alma tarihinden itibaren 30 gün içinde izinlidir. İstisna: dijital indirmeler erişildikten sonra iade edilemez. İstisna: chargeback durumları yükseltilmelidir."

İş akışı örneği:

1. Müşteri talep gönderir (durum: gönderildi).
2. Sistem satın alma tarihini ve ürün türünü kontrol eder (durum: incelemede).
3. Uygun ise, iade yap ve müşteriye bildirim gönder (durum: tamamlandı).
4. Eğer chargeback varsa, soruşturma için finansa yönlendir (durum: yükseltildi).

Kurallar neden göründüğünden zor?

Kurallar, çeliştiklerinde zorlaşır ("VIP müşteriler her zaman iade alır" vs. "dijital indirmeler asla almaz"), eksik bağlam gerektirdiğinde (indirme erişildi mi?), veya kenar durumları gizlediğinde (paketler, kısmi iadeler, bölgesel yasalar). İş akışları ayrıca bir katman daha ekler: kararlar mevcut durum, önceki işlemler ve son tarihlerle tutarlı kalmalıdır.

LLM'ler nasıl “muhakeme yapar”: faydalı yapı ile örüntü eşleştirme

LLM'ler bir kişi gibi iş kurallarını "anlamazlar". Büyük miktarda metinden öğrenilen örüntülere dayanarak bir sonraki en olası kelimeyi üretirler. Bu yüzden bir LLM eksik bilgiyle bile ikna edici görünebilir — ya da sağlanmayan ayrıntıları sessizce doldururken bile.

Bu sınırlama, iş akışları ve karar mantığı için önemlidir. Bir model doğru politika istisnalarını bilmiyorsa "çalışanlar her zaman yönetici onayı gerektirir" gibi kulağa doğru gelen bir kuralı uygulayabilir, oysa gerçek politika "sadece 500$ üzeri için" veya "sadece yükleniciler için" gibi istisnalar içerir. Bu yaygın bir hata modu: kendinden emin ama yanlış kural uygulaması.

Yine de neden faydalılar

Gerçek bir "anlama" olmasa bile, LLM'ler yapılandırılmış bir yardımcı olarak ele alındıklarında yardımcı olabilirler:

• Uzun politikaları gözden geçirip daha anlaşılır bir özet haline getirmek
• Dağınık metni tutarlı alanlara dönüştürmek (kim, ne, eşik, istisna, yürürlük tarihi)
• Önerilen bir kararı belirtilen kurallara karşı kontrol etmek ("hangi madde bunu destekliyor?")

Anahtar, modelin kolayca doğaçlama yapamayacağı bir pozisyona sokmaktır.

Modelin gezinmesini engelleyin

Belirsizliği azaltmanın pratik yolu sınırlı çıktıdır: LLM'in sabit bir şema veya şablonda yanıt vermesini zorunlu kılın (örneğin belirli alanları olan JSON veya gerekli sütunları olan bir tablo). Model rule_id, conditions, exceptions ve decision gibi alanları doldurmak zorunda kaldığında, boşlukları görmek ve çıktıyı otomatik doğrulamak daha kolay olur.

Sınırlı formatlar ayrıca modelin bilmediği bir şeyi açıkça göstermesini sağlar. Eğer gerekli bir alan eksikse, modeli belirsiz bir cevap kabul etmek yerine takip sorusu sormaya zorlayabilirsiniz.

Sonuç: LLM "muhakemesi" yapılandırma ve yapı ile yönlendirildiğinde örüntüye dayalı üretim olarak en iyi işe yarar—kuralları organize edip çapraz kontrol etmek için faydalıdır, fakat onu hatasız bir karar verici gibi görmek risklidir.

Dağınık politika metnini kullanılabilir kural temsillerine dönüştürme

Politika belgeleri insanlar için yazılır: amaçları, istisnaları ve "sağduyu" aynı paragrafta karıştırırlar. Bir LLM bu metni özetleyebilir, ancak kurallar açık, test edilebilir girdilere dönüştürüldüğünde daha güvenilir şekilde uyar.

"Kullanılabilir" kurallar nasıl görünür

İyi kural temsilleri iki özelliği paylaşır: belirsizliği azaltırlar ve doğrulanabilir olurlar.

Kuralları test edebileceğiniz ifadeler olarak yazın:

• Kararlar için EĞER/ODELSE (uygunluk, yönlendirme, onaylar)
• Sert kısıtlamalar için ZORUNLU / YASAK
• İzin verilen seçenekler için İZİN VERİLİR (genellikle bir eşitleyici gerektirir)

Kurallar modeli birkaç formda verilebilir:

• Düz dil madde listeleri (en hızlı, yine de yapılandırılmış)
• Bir tablo (eşik bazlı politikalar için harika)
• YAML/JSON (kısıtlı çıktılar ve otomatik doğrulama istendiğinde en iyisi)

Çatışmalar ve öncelik yönetimi

Gerçek politikalar çelişir. İki kural anlaşmazlığa düştüğünde, modelin net bir öncelik şeması gerekir. Yaygın yaklaşımlar:

• Özel genel olanı yener (istisna varsayılanın üzerindedir)
• Daha yüksek yetki kazanır (hukuk/uyum takım tercihinin üstünde)
• Yeni olan kazanır (yeni politika eskiyi geçersiz kılar)
• Açık öncelik numaraları (en güvenilir)

Çatışma kuralını doğrudan belirtin veya encode edin (ör. priority: 100). Aksi takdirde LLM kuralları "ortalama" bir şekilde uygulayabilir.

Örnek: bir paragrafı kural listesine dönüştürme

Orijinal politika metni:

"İadeler yıllık planlar için 30 gün içinde mevcuttur. Aylık planlar 7 günden sonra iade edilemez. Hesapta dolandırıcılık veya aşırı chargeback varsa iade yapılmaz. Kurumsal müşterilerin 5.000$ üzeri iadeleri için Finans onayı gerekir."

Yapılandırılmış kurallar (YAML):

rules:
  - id: R1
    statement: "IF plan_type = annual AND days_since_purchase <= 30 THEN refund MAY be issued"
    priority: 10
  - id: R2
    statement: "IF plan_type = monthly AND days_since_purchase > 7 THEN refund MUST NOT be issued"
    priority: 20
  - id: R3
    statement: "IF fraud_flag = true OR chargeback_rate = excessive THEN refund MUST NOT be issued"
    priority: 100
  - id: R4
    statement: "IF customer_tier = enterprise AND refund_amount > 5000 THEN finance_approval MUST be obtained"
    priority: 50
conflict_resolution: "Higher priority wins; MUST NOT overrides MAY"

Artık model neyin önemli olduğunu tahmin etmiyor—inceleyebileceğiniz, test edebileceğiniz ve versiyonlayabileceğiniz bir kural seti uyguluyor.

İş akışı durumunu takip ederek modelin tutarlı kalmasını sağlama

Bir iş akışı yalnızca bir dizi kural değildir; önceki adımların sonraki adımları değiştirdiği bir olay sıralamasıdır. Bu "hafıza" durumtur: davaya dair geçerli gerçekler (kim ne gönderdi, ne onaylandı, ne bekliyor, hangi son tarihler geçerli). Durumu açıkça takip etmezseniz, iş akışları öngörülebilir şekilde bozulur—çift onaylar, gerekli kontrollerin atlanması, kararların tersine çevrilmesi veya modelin hangi politikanın uygulanması gerektiğini güvenilir şekilde çıkaramaması gibi.

Durum sade dille ne demektir

Durumu iş akışının skor tablosu gibi düşünün. "Şimdi neredeyiz? Ne yapıldı? Sonra ne yapılmasına izin veriliyor?" cümlelerine cevap verir. Bir LLM için açık bir durum özeti, onun geçmiş adımları yeniden tartışmasını veya tahmin etmesini engeller.

Modela durumu nasıl geçirmeli

Model çağrılırken, kullanıcının isteğinin yanında kompakt bir durum yükü ekleyin. Yararlı alanlar şunlardır:

• Ad adı ve durumu (ör. manager_review: approved, finance_review: pending)
• Sabit kimlikler (talep ID'si, çalışan ID'si) böylece model vakaları karıştırmaz
• Zaman damgaları (gönderildi, son güncelleme) "en yeni kazanır" durumlarını çözmek için
• Bayraklar (politika istisnaları, eksik belgeler, yükseltme gerekmesi)

Her tarihi mesajı dökmek yerine, geçerli durumu ve ana geçişlerin kısa bir denetim kaydını sağlayın.

Tek gerçek kaynağı tutun

İş akışı motorunu (veritabanı, bilet sistemi veya orkestratör) tek gerçek kaynağı olarak ele alın. LLM o sistemden durumu okumalı ve bir sonraki eylemi önermeli, ama geçişleri kaydeden otorite sistem olmalıdır. Bu, model anlatısının gerçeklikten sapması (state drift) sorununu azaltır.

Örnek: onay akışı durum anlık görüntüsü

{
  "request_id": "TRV-10482",
  "workflow": "travel_reimbursement_v3",
  "current_step": "finance_review",
  "step_status": {
    "submission": "complete",
    "manager_review": "approved",
    "finance_review": "pending",
    "payment": "not_started"
  },
  "actors": {
    "employee_id": "E-2291",
    "manager_id": "M-104",
    "finance_queue": "FIN-AP"
  },
  "amount": 842.15,
  "currency": "USD",
  "submitted_at": "2025-12-12T14:03:22Z",
  "last_state_update": "2025-12-13T09:18:05Z",
  "flags": {
    "receipt_missing": false,
    "policy_exception_requested": true,
    "needs_escalation": false
  }
}

Böyle bir anlık görüntü ile model tutarlı kalabilir: tekrar yönetici onayı istemez, finans kontrollerine odaklanır ve kararları mevcut bayraklar ve adımlar bağlamında açıklayabilir.

Kural uygulamayı ve kararları geliştiren prompt kalıpları

İyi bir prompt sadece bir cevap istemez—modelin kurallarınızı nasıl uygulaması ve sonucu nasıl raporlaması gerektiğine dair beklentileri belirler. Amaç tekrarlanabilir kararlar, gösterişli metin değil.

1) Rol ile yönlendirme: bir ruh hali değil görev verin

Modele sürecinizle bağlantılı somut bir görev verin. Üç rol birlikte iyi çalışır:

• Politika analisti: kural metnini yorumlar ve güncel vaka ile eşler.
• Doğrulayıcı: kararı gereksinimlere karşı kontrol eder ve eksik girdileri işaretler.
• Ajan: sonraki iş akışı eylemini gerçekleştirir (bilet oluşturma, e-posta taslağı, durumu ayarlama).

Bunları sıralı olarak çalıştırabilirsiniz ("analist → doğrulayıcı → ajan") veya tek bir yapılandırılmış yanıtta hepsini isteyebilirsiniz.

2) Gizli muhakeme istemeden adım adım talimatlar

"Chain-of-thought" istemek yerine görünür adımlar ve çıktılar belirtin:

1. İlgili kuralları tespit et.
2. Vakadan gereken girdileri çıkar.
3. Öncelik sırasına göre kuralları uygula.
4. Bir karar ve sonraki adımı üret.

Bu, modeli organize eder ve hangi kuralların kullanıldığını ve hangi sonucun çıktığını açıklar.

3) Yapılandırılmış gerekçe isteyin: kural ID'leri + kanıt

Serbest form açıklamalar sapar. Kısa bir gerekçe zorunlu kılın:

• Kullanılan kural ID'leri (ör. R-12, R-18)
• Kanıt (politikadan alıntılanmış pasajlar ve vaka alanları)
• Varsayımlar (sadece bir girdi eksikse)

Bu, incelemeyi hızlandırır ve anlaşmazlıkları hata ayıklamayı kolaylaştırır.

4) Kontrol listesi kalıbı: girdiler, karar, istisnalar, sonraki adım

Her seferinde sabit bir şablon kullanın:

• Alınan girdiler: …
• Eksik girdiler: …
• Karar: onay/red/inceleme gerekli
• Kural referansları: [R-…]
• Düşünülen istisnalar: …
• Sonraki iş adımı: durumu güncelle / bilgi iste / yükselt

Şablon belirsizliği azaltır ve modelin yanlış bir eyleme karar vermeden önce boşlukları ortaya çıkarmasını sağlar.

Kararları gerçek verilerle dayandırmak için araçlar ve retrieval kullanma

Bir LLM önemli gerçeklerden yoksun olduğunda ikna edici bir cevap yazabilir. Bu taslaklar için yararlı olsa da, iş-kuralı kararları için risklidir. Model bir hesabın durumunu, müşterinin kademesini, bölgesel vergi oranını veya bir sınırın zaten aşılıp aşılmadığını tahmin etmek zorunda kalırsa, kendinden emin görünen hatalar ortaya çıkar.

Araçlar bunu "önce kanıt getir, sonra karar ver" iki adımlı sürecine çevirir.

Modelleri dürüst tutan yaygın araçlar

Kural ve iş akışı ağırlıklı sistemlerde birkaç basit araç çoğu işi yapar:

• Veritabanı sorgusu (müşteri profili, hesap durumu, yetkiler, kullanım toplamları)
• Politika/kural deposu (onaylı kural metni, versiyonlu prosedürler, istisna listeleri)
• Hesaplayıcı (ücretler, proration, vergiler, zaman pencereleri, eşikler)
• Biletleme / iş akışı API'si (açık vakalar, SLA zamanlayıcıları, onaylar, adım tamamlama)

Anahtar, modelin operasyonel gerçekleri "uydurmaması"—bunları talep etmesidir.

Retrieval: sadece ilgili kuralları getir

Politikaları merkezi bir depoda tutsanız bile, genellikle tamamını prompta yapıştırmak istemezsiniz. Retrieval, o vakaya en ilgili parçaları seçmeye yardımcı olur—örneğin:

• Müşterinin planı için iptal politikası
• Ülke/eyalete göre uygulanacak bölgesel uyum maddesi
• Chargeback beklerken geçerli olan istisna kuralı

Bu, çelişkileri azaltır ve modelin yalnızca önceki bağlamda görünen eski bir kuralı takip etmesini engeller.

Araç çıktılarını karar kanıtına dönüştürme

Güvenilir bir kalıp, araç sonuçlarını modelin kararında alıntılaması gereken kanıt olarak ele almaktır. Örneğin:

1. Araç: get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000
2. Araç: retrieve_policies(query="overage fee Business plan") → kural döndürür: "Overage fee applies above 10,000 units at $0.02/unit."
3. Araç: calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00

Şimdi karar bir tahmin değil: belirli girdilere dayanan bir sonuçtur ("past_due", "12,000 units", "$0.02/unit"). Daha sonra sonucu denetlerseniz hangi gerçeklerin ve hangi kural versiyonunun kullanıldığını görebilir ve hatayı düzeltmeniz gerektiğinde doğru kısmı düzeltebilirsiniz.

Belirsizliği azaltan çıktılar: şemalar

Serbest metin esnektir, fakat iş akışlarının bozulmasının en kolay yoludur. Model "makul" bir cevap verebilir ama otomatikleştirilemez veya adımlar arasında tutarsız olabilir. Çıktıları kısıtlamak, her kararı öngörülebilir bir biçime sokarak bunu çözer.

Kararları JSON olarak döndürün

Pratik bir kalıp, modelin sisteminizin ayrıştırıp yönlendirebileceği tek bir JSON nesnesiyle yanıt vermesini zorunlu kılmaktır:

{
  "decision": "needs_review",
  "reasons": [
    "Applicant provided proof of income, but the document is expired"
  ],
  "next_action": "request_updated_document",
  "missing_info": [
    "Income statement dated within the last 90 days"
  ],
  "assumptions": [
    "Applicant name matches across documents"
  ]
}

Bu yapı, model tam olarak karar veremediğinde bile çıktıyı kullanılabilir kılar. missing_info ve assumptions belirsizliği gizli tahmin yerine eyleme dönüştürür.

Sonuçları sınırlamak için enum'lar kullanın

Değişkenliği azaltmak için önemli alanlar için izin verilen değerleri (enum) tanımlayın. Örneğin:

• decision: approved | denied | needs_review
• next_action: approve_case | deny_case | request_more_info | escalate_to_human

Enum'lar sayesinde downstream sistemler eşanlamlıları, noktalama işaretlerini veya ton farklarını yorumlamak zorunda kalmaz; bilinen değerlere göre dallanırlar.

Neden şemalar iş akışlarını daha güvenli kılar

Şemalar birer koruma bariyeridir. Şunları yaparlar:

• Gerekli alanları zorunlu kılarak "kısmi cevapları" engeller.
• reasons aracılığıyla kararın nedenini denetlenebilir kılar.
• decision ve next_action ile kuyrukları, bildirimleri ve görev oluşturmayı doğrudan tetikleyerek güvenilir otomasyon sağlar.
• Çıktı şeması eşleşmiyorsa reddedip modelden yeniden denemesini isteyebilirsiniz.

Sonuç: daha az belirsizlik, daha az kenar durum hatası ve adımlar arasında tutarlı hareket eden kararlar.

Yayına almadan önce hataları yakalamak: doğrulama stratejileri

İyi promptlanmış bir model bile "doğruymuş gibi" görünürken kural ihlali yapabilir, gerekli bir adımı atlayabilir veya bir değeri uydurabilir. Doğrulama, olası bir cevabı güvenilir bir karara dönüştüren güvenlik ağıdır.

Ön kontroller: muhakemeden önce girdileri doğrulayın

Kuralları uygulamadan önce minimum bilgilerin mevcut olup olmadığını doğrulayın. Ön kontroller model karar vermeden önce çalışmalıdır.

Tipik ön kontroller: gerekli alanlar (müşteri türü, sipariş toplamı, bölge), temel formatlar (tarihler, ID'ler, para birimi) ve izin verilen aralıklar (negatif olmayan tutarlar, %100 ile sınırlı yüzdeler). Bir şey başarısız olursa, modelin tahmin etmesine izin vermek yerine açık, eyleme dönük bir hata döndürün ("Bölge eksik; hangi vergi kural setinin kullanılması gerektiği belirlenemiyor").

Son kontroller: kararı kurallara karşı doğrulayın

Model bir sonuç ürettikten sonra, bunun kural setinizle tutarlı olduğunu doğrulayın.

Odaklanılacaklar:

• Kural kapsama: Karar, uygulanabilir kuralları gösteriyor mu yoksa zorunlu bir politikayı atladı mı?
• Çelişki kontrolleri: Çıktı verilen girdilerle çelişiyor mu (ör. sert engel koşulu varken "onaylandı" demek)?
• Sınır durumları: Eşikler, boş durumlar ve "az bir farkla" senaryolarını test edin.

İkinci geçiş doğrulaması: kasıtlı bir inceleme adımı

İlk cevabı yeniden değerlendiren bir "ikinci geçiş" ekleyin. Bu başka bir model çağrısı veya sadece uyumluluğu kontrol eden bir doğrulayıcı promptu olabilir.

Basit bir kalıp: ilk geçiş karar + gerekçe üretir; ikinci geçiş ise valid döndürür veya eksiklikler/ihlaller listesi şeklinde yapılandırılmış hatalar döndürür.

Kayıt: kararları denetlenebilir hale getirin

Her karar için kullanılan girdileri, kural/politika versiyonunu ve doğrulama sonuçlarını (ikinci geçiş bulguları dahil) kaydedin. Bir şey ters gittiğinde, tam koşulları yeniden üretmenizi, kural eşlemesini düzeltmenizi ve düzeltmeyi doğrulamanızı sağlar—modelin "ne demek istemiş olabileceğini" tahmin etmeye gerek kalmaz.

Kural ve iş akışı güvenilirliği için test etme ve izleme

LLM ile kural- ve iş akışı odaklı özelliklerin testi, "bir şey üretti mi?" sorusundan ziyade "dikkatli bir insanın vereceği kararı doğru sebeple her seferinde veriyor mu?" sorusudur. İyi haber: bunu geleneksel karar mantığı için kullandığınız disiplinle test edebilirsiniz.

İş kuralları için birim testleri (küçük, öngörülebilir kontroller)

Her kuralı bir fonksiyon gibi ele alın: verilen girdiler beklenen sonucu döndürmelidir.

Örneğin, "açılmamış ürünler için 30 gün içinde iade" kuralı için odaklanmış vakalar yazın:

• Sipariş yaşı = 10 gün, açılmamış = true → onayla
• Sipariş yaşı = 10 gün, açılmamış = false → reddet
• Sipariş yaşı = 45 gün, açılmamış = true → reddet
• Kenar durumlar: tam 30 gün, "açılmamış" alanının eksik olması, çelişen sinyaller

Bu birim testleri, off-by-one hatalarını, eksik alanları ve modelin bilinmeyeni doldurmaya çalıştığı "yardımsever" davranışları yakalar.

İş akışları için senaryo testleri (çok adımlı, zaman farkındalıklı yollar)

İş akışları, adımlar arasında durum tutarlılığı bozulduğunda başarısız olur. Senaryo testleri gerçek yolculukları taklit eder:

• Yol testleri: talep gönder → belge iste → belgeler alındı → karar
• Zamana dayalı kenarlar: "7 gün içinde yanıt yoksa hatırlatma gönder", "30 gün geçerse vakayı kapat"
• Dallanma: müşteri yükseltir, politika istisnası istenir, çoğaltılmış vaka tespit edilir

Amaç, modelin geçerli durumu gözetmesini ve yalnızca izin verilen geçişleri yapmasını doğrulamaktır.

Bilinen-iyi vakalardan oluşan bir "gold set" oluşturun

Gerçek, anonimleştirilmiş örneklerden oluşan küçük bir veri seti (beklenen sonuçlar ve kısa gerekçelerle) oluşturun. Versiyonlayın ve politika değiştikçe gözden geçirin. Küçük bir gold set (100–500 vaka bile) güçlüdür çünkü eksik veri, alışılmadık ifadeler ve sınır kararlarını yansıtır.

Üretimde izleme (müşteriler fark etmeden önce sapmayı yakalayın)

Zaman içinde karar dağılımlarını ve kalite sinyallerini izleyin:

• Sapma: politika güncellemesi olmadan onay/red oranlarının değişmesi
• needs_review veya insanlara aktarılan vakalarda ani artışlar (genellikle prompt, retrieval veya üst akış veri sorunudur)
• Hata kümeleri ürün, bölge veya politika kategorisine göre

İzlemeyi güvenli geri alma ile eşleştirin: önceki prompt/kural paketini saklayın, yeni sürümleri feature flag ile açın ve metrikler geriye döndüğünde hızla geri alabilecek hazırlıkta olun. Operasyonel çalışma kitapları ve sürüm geçişi için /blog/validation-strategies metnine bakın.

Bu boru hattında Koder.ai nerede yer alıyor?

Yukarıdaki kalıpları uyguluyorsanız genellikle model etrafında küçük bir sistem kurarsınız: durum depolama, araç çağrıları, retrieval, şema doğrulaması ve bir iş akışı orkestratörü. Koder.ai bu tür iş akışı destekli asistanları prototiplemek ve hızla yayıma almak için pratik bir yoldur: sohbet içinde iş akışını tanımlayabilir, çalışan bir web uygulaması (React) ve backend servisleri (Go + PostgreSQL) üretebilir ve anlık görüntüler ile geri alma kullanarak güvenle yineleyebilirsiniz.

Bu, iş kuralı muhakemesinde önemlidir çünkü "koruma bariyerleri" genellikle promptun içinde değil uygulamanın kendisinde yaşar:

• Planlama modu akışı (durumlar, izin verilen geçişler, yükseltme yolları) yürütmeden önce tasarlamanıza yardımcı olur.
• Şema-kısıtlı yanıtlar API sınırında zorlanarak sadece ayrıştırılabilir kararları kabul etmenizi sağlar.
• Araç bağlantı kancaları (DB okuma, politika retrieval, hesaplayıcılar, bilet güncellemeleri) açık uç noktalar olarak uygulanabilir, böylece "önce kanıt getir, sonra karar ver" varsayılan olur.
• Kaynak kodu dışa aktarımı prototip üretime geçtiğinde kilitlenmeyi önler.

Sınırlamalar, güvenli kullanım ve insan müdahalesine ne zaman ihtiyaç duyulur

LLM'ler günlük politikaları uygulamada şaşırtıcı derecede iyi olabilir, ancak deterministik bir kural motoruyle aynı şey değillerdir. Onları korumalar gerektiren bir karar asistanı olarak değerlendirin, nihai otorite değil.

LLM'lerin sık zorlandığı alanlar

Üç başarısızlık modu kural ağırlıklı iş akışlarında tekrar tekrar görülür:

• Nadir istisnalar ve kenar durumlar: Yılda bir olan bir istisna eğitim verisinde az temsil edilebilir ve promptta veya policy retrieval ile açıkça sağlanmadıkça kolayca kaçabilir.
• Uzun bağlamlar ve "gömülü" kısıtlar: Önemli detaylar çok sayıda sayfaya veya mesaja dağılmışsa, model en son veya en çarpıcı metni fazla ağırlıklandırabilir ve önceki kısıtları hafife alabilir.
• Sayısal doğruluk ve sıkı hesaplamalar: Toplamlar, proration, eşikler ve yuvarlama kuralları sapabilir. Matematik için araç kullanın ve modelin kullandığı tam sayıları alıntılamasını zorunlu kılın.

İnsan incelemesi ne zaman zorunlu olmalı

Aşağıdaki durumlarda zorunlu inceleme ekleyin:

• Sonuç yüksek riskliyse (para transferi, uyum, güvenlik, hukuki taahhütler, müşteri kredi/uygunluk).
• Model düşük güven sinyali veriyorsa (eksik girdileri tahmin etmesi gerektiğini söylüyor, politika dayanağı bulamıyor veya çelişen gerekçeler üretiyor).
• Vaka yeni ise (yeni ürün, yeni bölge, politika yakın zamanda değişti) veya olağanüstü hassassa.

İşlerin ilerlemesini sağlayan yükseltme yolları

Modelin "bir şey uydurmasına" izin vermek yerine, net sonraki adımlar tanımlayın:

1. Açıklayıcı sorular sor (eksik tarihler, müşteri kademesi, yargı bölgesi, onay durumu).
2. Çıkarılan gerçekler, önerilen karar ve alıntılar ile bir insan ajana yönlendir.
3. Politika belirsiz veya çelişkili ise bir bilet oluştur ki kaynakta düzeltme yapılsın (ve sonra otomatik olarak retrieval ile alınabilsin).

Basit bir benimseme çerçevesi

LLM'leri kural ağırlıklı iş akışlarında şu soruların çoğuna "evet" diyebiliyorsanız kullanın:

• Kararları onaylı politika metni veya sistem verileri ile dayandırabiliyor muyuz?
• Çıktıları kısıtlayabiliyor muyuz (şema, izin verilen eylemler, zorunlu alıntılar)?
• Yürütmeden önce doğrulayabiliyor muyuz (kontroller, eşikler, birim testleri, örnekleme)?
• Riskli veya belirsiz vakalar için insan yükseltme yolu var mı?

Eğer değilse, bu kontroller oluşana kadar LLM'i taslak/yardımcı rolünde tutun.