LLM'lerin politika metnini nasıl yorumladığını, iş akışı durumunu nasıl takip ettiğini ve kararları nasıl sınadığını öğrenin—sadece kod değil, promptlar, araçlar, testler ve insan incelemesiyle.

İ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.
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ü:
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'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.
Pratik bir yaklaşım bir boru hattı gibi görünür:
Bu, zekice bir kod parçası ile gerçek iş kararlarını destekleyebilen bir sistem arasındaki farktır.
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ı, kuruluşunuzun tutarlı bir şekilde uygulanmasını istediği karar bildirimleridir. Politikalar ve şu tür mantıklarla ortaya çıkarlar:
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.
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:
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:
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 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ı.
Gerçek bir "anlama" olmasa bile, LLM'ler yapılandırılmış bir yardımcı olarak ele alındıklarında yardımcı olabilirler:
Anahtar, modelin kolayca doğaçlama yapamayacağı bir pozisyona sokmaktır.
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.
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.
İyi kural temsilleri iki özelliği paylaşır: belirsizliği azaltırlar ve doğrulanabilir olurlar.
Kuralları test edebileceğiniz ifadeler olarak yazın:
Kurallar modeli birkaç formda verilebilir:
Gerçek politikalar çelişir. İki kural anlaşmazlığa düştüğünde, modelin net bir öncelik şeması gerekir. Yaygın yaklaşımlar:
Çatışma kuralını doğrudan belirtin veya encode edin (ör. priority: 100). Aksi takdirde LLM kuralları "ortalama" bir şekilde uygulayabilir.
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.
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.
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.
Model çağrılırken, kullanıcının isteğinin yanında kompakt bir durum yükü ekleyin. Yararlı alanlar şunlardır:
manager_review: approved, finance_review: pending)Her tarihi mesajı dökmek yerine, geçerli durumu ve ana geçişlerin kısa bir denetim kaydını sağlayın.
İş 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.
{
"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.
İ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.
Modele sürecinizle bağlantılı somut bir görev verin. Üç rol birlikte iyi çalışır:
Bunları sıralı olarak çalıştırabilirsiniz ("analist → doğrulayıcı → ajan") veya tek bir yapılandırılmış yanıtta hepsini isteyebilirsiniz.
"Chain-of-thought" istemek yerine görünür adımlar ve çıktılar belirtin:
Bu, modeli organize eder ve hangi kuralların kullanıldığını ve hangi sonucun çıktığını açıklar.
Serbest form açıklamalar sapar. Kısa bir gerekçe zorunlu kılın:
Bu, incelemeyi hızlandırır ve anlaşmazlıkları hata ayıklamayı kolaylaştırır.
Her seferinde sabit bir şablon kullanın:
Şablon belirsizliği azaltır ve modelin yanlış bir eyleme karar vermeden önce boşlukları ortaya çıkarmasını sağlar.
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.
Kural ve iş akışı ağırlıklı sistemlerde birkaç basit araç çoğu işi yapar:
Anahtar, modelin operasyonel gerçekleri "uydurmaması"—bunları talep etmesidir.
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:
Bu, çelişkileri azaltır ve modelin yalnızca önceki bağlamda görünen eski bir kuralı takip etmesini engeller.
Güvenilir bir kalıp, araç sonuçlarını modelin kararında alıntılaması gereken kanıt olarak ele almaktır. Örneğin:
get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000retrieve_policies(query="overage fee Business plan") → kural döndürür: "Overage fee applies above 10,000 units at $0.02/unit."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.
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.
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.
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_reviewnext_action: approve_case | deny_case | request_more_info | escalate_to_humanEnum'lar sayesinde downstream sistemler eşanlamlıları, noktalama işaretlerini veya ton farklarını yorumlamak zorunda kalmaz; bilinen değerlere göre dallanırlar.
Şemalar birer koruma bariyeridir. Şunları yaparlar:
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.Sonuç: daha az belirsizlik, daha az kenar durum hatası ve adımlar arasında tutarlı hareket eden kararlar.
İ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.
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").
Model bir sonuç ürettikten sonra, bunun kural setinizle tutarlı olduğunu doğrulayın.
Odaklanılacaklar:
İ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.
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.
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.
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:
Bu birim testleri, off-by-one hatalarını, eksik alanları ve modelin bilinmeyeni doldurmaya çalıştığı "yardımsever" davranışları yakalar.
İş akışları, adımlar arasında durum tutarlılığı bozulduğunda başarısız olur. Senaryo testleri gerçek yolculukları taklit eder:
Amaç, modelin geçerli durumu gözetmesini ve yalnızca izin verilen geçişleri yapmasını doğrulamaktır.
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.
Zaman içinde karar dağılımlarını ve kalite sinyallerini izleyin:
needs_review veya insanlara aktarılan vakalarda ani artışlar (genellikle prompt, retrieval veya üst akış veri sorunudur)İ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.
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:
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.
Üç başarısızlık modu kural ağırlıklı iş akışlarında tekrar tekrar görülür:
Aşağıdaki durumlarda zorunlu inceleme ekleyin:
Modelin "bir şey uydurmasına" izin vermek yerine, net sonraki adımlar tanımlayın:
LLM'leri kural ağırlıklı iş akışlarında şu soruların çoğuna "evet" diyebiliyorsanız kullanın:
Eğer değilse, bu kontroller oluşana kadar LLM'i taslak/yardımcı rolünde tutun.