Uygulama Mantığında Modellerle AI-ODAKLI ÜRÜNLER Nasıl İnşa Edilir

AI-odaklı Bir Ürün İnşa Etmek Ne Anlama Gelir

Bir AI-odaklı ürün oluşturmak, sadece “bir sohbet botu eklemek” demek değildir. Bu, modelin uygulama mantığınızın gerçek, çalışan bir parçası olması demektir—bir kurallar motoru, arama dizini veya öneri algoritması gibi.

Uygulamanız sadece AI kullanıyor değildir; modelin girdi yorumlayacağı, eylemler seçeceği ve sistemin geri kalanının güvendiği yapılandırılmış çıktılar üreteceği gerçeği etrafında tasarlanmıştır.

Pratikte: her karar yolunu sert kodlamak yerine (“eğer X ise Y yap”), modelin belirsiz kısımları—dil, niyet, belirsizlik, önceliklendirme—ele almasına izin verirsiniz; kodunuz ise kesin olması gerekenleri yönetir: izinler, ödemeler, veritabanı yazımları ve politika uygulaması.

AI-odaklılık hangi durumlarda uygundur (ve hangilerinde değildir)

AI-odaklılık şu tür problemler için en iyi sonucu verir:

• Çok çeşitli geçerli girdiler (serbest metin, karışık belgeler, değişken kullanıcı hedefleri)
• Elle yönetilecek çok fazla uç durum olması
• Mükemmel deterministik sonuçtan ziyade değerlendirme, özetleme veya sentezleme değerinin bulunması

Kurallara dayalı otomasyon genellikle gereksinimlerin stabil ve kesin olduğu durumlarda daha iyidir—vergi hesapları, envanter mantığı, uygunluk kontrolleri veya çıktı her seferinde aynı olmalıdır diyen uyumluluk iş akışları.

AI-odaklılığın desteklediği yaygın ürün hedefleri

Takımlar genellikle model odaklı mantığı benimserler çünkü:

• Hızı artırmak: taslak yanıtlar, alan çıkarımı, talepleri daha hızlı yönlendirme
• Deneyimleri kişiselleştirmek: açıklamaları, planları veya önerileri kullanıcıya göre uyarlama
• Kararları desteklemek: takasları vurgulama, seçenekler üretme, kanıtları özetleme

Kabul etmeniz gereken ödünler (ve bunlar için tasarım yapmanız gerekir)

Modeller tahmin edilemez olabilir, bazen güvenle yanlış bilgi verir ve davranışları promptlar, sağlayıcılar veya getirilen bağlam değiştikçe değişebilir. Ayrıca her istek başına maliyet ekler, gecikme getirebilir ve güvenlik ile güven konularını gündeme getirir (mahremiyet, zararlı çıktı, politika ihlalleri).

Doğru zihin yapısı: model bir bileşendir, sihirli bir cevap kutusu değil. Onu bir bağımlılık gibi ele alın—şartname, hata modları, testler ve izleme ile—böylece esneklik elde ederken ürünü sadece umutlara dayanarak kurmamış olursunuz.

Doğru Kullanım Vakasını Seçin ve Başarıyı Tanımlayın

Her özellik modeli sürücü koltuğuna koymaktan fayda görmez. En iyi AI-odaklı kullanım vakaları net bir yapılacak işiyle başlar ve haftadan haftaya izleyebileceğiniz ölçülebilir bir sonuçla biter.

İş ile başlayın, model ile değil

Bir cümlelik bir iş hikayesi yazın: “Ne zaman ___, yapmak istiyorum ___, böylece ___.” Sonra sonucu ölçülebilir hale getirin.

Örnek: “Uzun bir müşteri e-postası aldığımda, politikamıza uygun bir önerilen yanıt istiyorum, böylece 2 dakika içinde cevaplayabileyim.” Bu, “e-postaya bir LLM ekle” demekten çok daha uygulanabilir.

Karar noktalarını haritalandırın

Modelin hangi anlarda eylem seçeceğini belirleyin. Bu karar noktaları açık olmalı ki test edebilin.

Yaygın karar noktaları:

• Niyeti sınıflandırıp doğru iş akışına yönlendirme
• Netleştirici soru sormaya mı yoksa devam etmeye mi karar verme
• Hangi araçları seçeceğine karar verme (arama, CRM sorgusu, taslak oluşturma, bilet oluşturma)
• Ne zaman insan müdahalesine yükselteceğine karar verme

Eğer kararları adlandıramıyorsanız, model-tabanlı mantığı göndermeye hazır değilsiniz demektir.

Davranış için kabul kriterleri yazın

Model davranışını diğer ürün gereksinimleri gibi ele alın. “İyi” ve “kötü”nün neye benzediğini sade dilde tanımlayın.

Örneğin:

• İyi: en güncel politikayı kullanır, doğru sipariş ID’sini atfeder, bilgi eksikse bir tane net soru sorar
• Kötü: indirim uydurur, desteklenmeyen bölgelerden bahseder veya gerekli verileri kontrol etmeden cevap verir

Bu kriterler daha sonra değerlendirme kümeniz için temel oluşturur.

Kısıtları erken belirleyin

Tasarım seçimlerinizi şekillendirecek kısıtları listeleyin:

• Zaman (cevap gecikme hedefleri)
• Bütçe (görev başına maliyet)
• Uyumluluk (KİB/içerik, denetim gereksinimleri)
• Desteklenen bölgeler (diller, ton, kültürel beklentiler)

İzleyebileceğiniz başarı metriklerini tanımlayın

İşe bağlı küçük bir metrik seti seçin:

• Görev tamamlama oranı
• Temsilî vakalarda doğruluk (veya politika uyumu)
• CSAT veya nitel kullanıcı puanı
• Görev başına tasarruf edilen süre (veya çözüm süresi)

Başarıyı ölçemiyorsanız, ürünü geliştirmek yerine izlenimler üzerine tartışırsınız.

AI Tabanlı Kullanıcı Akışı ve Sistem Sınırlarını Tasarlayın

AI-odaklı bir akış “LLM çağıran bir ekran” değildir. Modelin belli kararlar verdiği, ürünün bunları güvenli şekilde uyguladığı ve kullanıcının yönlendirmeyi kaybetmediği uçtan uca bir yolculuktur.

Uçtan uca döngüyü haritalandırın

Boruyu basit bir zincir olarak çizmeye başlayın: girdiler → model → eylemler → çıktılar.

• Girdiler: kullanıcı tarafından sağlananlar (metin, dosyalar, seçimler) artı uygulama bağlamı (hesap seviyesi, çalışma alanı, son etkinlik).
• Model adımı: modelin neyi kararlaştırmaktan sorumlu olduğu (sınıflandırma, taslak oluşturma, özetleme, bir sonraki eylemi seçme).
• Eylemler: sisteminizin yapabileceği şeyler (arama, görev oluşturma, kayıt güncelleme, e-posta gönderme).
• Çıktılar: kullanıcının gördükleri (bir taslak, açıklama, onay ekranı, sonraki adımları içeren bir hata).

Bu harita, belirsizliğin kabul edilebilir olduğu yerleri (taslak oluşturma) ve edilemez olduğu yerleri (faturalandırma değişiklikleri) netleştirir.

Sistem sınırlarını çizin: model vs deterministik kod

Deterministik yolları (izin kontrolleri, iş kuralları, hesaplamalar, veritabanı yazımları) ile model kaynaklı kararları (yorumlama, önceliklendirme, doğal dil üretimi) ayırın.

Faydalı bir kural: model öneride bulunabilir, ancak kod tersine çevrilemez bir şey yapmadan önce doğrulamalıdır.

Modelin nerede çalışacağına karar verin

Kısıtlarınıza göre bir çalışma zamanı seçin:

• Sunucu: özel veriler, tutarlı araçlar, denetim kayıtları için en iyisi.
• İstemci: hafif yardım ve gizlilik için yerel işlem faydası, ancak kontrolü zor.
• Edge: global gecikme için daha hızlı, ama bağımlılıklar sınırlı.
• Hibrit: hızlı niyet tespiti kenarda, ağır işler sunucuda olacak şekilde bölünmüş.

Gecikme, maliyet ve veri izinlerini bütçeleyin

İstek başına bir gecikme ve maliyet bütçesi belirleyin (yeniden denemeler ve araç çağrıları dahil), sonra UX’i buna göre tasarlayın (akış, kademeli sonuçlar, “arka planda devam et”).

Her adımda hangi veri kaynaklarının ve izinlerin gerektiğini belgeleyin: modelin neyi okuyabileceği, neyi yazabileceği ve hangi durumlarda açık kullanıcı onayı gerektiği. Bu mühendislik ve güven için bir sözleşme olur.

Mimari Desenler: Orkestrasyon, Durum ve İzler

Model uygulama mantarınızın bir parçası olduğunda, “mimari” sadece sunucular ve API’ler değildir—bir dizi model kararını kaybetmeden nasıl güvenilir şekilde yürüttüğünüzdür.

Orkestrasyon: model işlerinin şefi

Orkestrasyon, bir AI görevini uçtan uca nasıl yürüttüğünüzü yöneten katmandır: promptlar ve şablonlar, araç çağrıları, bellek/bağlam, yeniden denemeler, zaman aşımı ve geri dönüşler.

İyi orkestratörler modeli pipeline’daki bir bileşen olarak ele alır. Hangi promptun kullanılacağına, hangi anda bir aracın (arama, veritabanı, e-posta, ödeme) çağrılacağına, bağlamın nasıl sıkıştırılacağına veya getirileceğine ve model geçersiz bir şey döndürdüğünde ne yapılacağına karar verirler.

Fikrinizden çalışan bir orkestrasyona daha hızlı geçmek istiyorsanız, uygulama iskeletini baştan inşa etmeden bu pipeline’ları prototiplemenize yardımcı olacak bir vibe-coding iş akışı işe yarayabilir. Örneğin, Koder.ai takımların sohbet yoluyla web uygulamaları (React), backend (Go + PostgreSQL) ve hatta mobil (Flutter) oluşturmasına izin verir—sonra “girdiler → model → araç çağrıları → doğrulamalar → UI” gibi akışları planlama modu, anlık görüntüler ve geri alma gibi özelliklerle yineleyebilirsiniz; hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.

Çok adımlı görevler için durum makineleri

Triage → bilgi toplama → onay → yürütme → özetleme gibi çok adımlı deneyimler, bunları bir iş akışı veya durum makinesi olarak modellediğinizde en iyi şekilde çalışır.

Basit bir desen: her adımın (1) izin verilen girdileri, (2) beklenen çıktıları ve (3) geçişleri olsun. Bu, gezinmeyen konuşmaları önler ve kullanıcının fikrini değiştirmesi veya kısmi bilgi vermesi gibi uç durumları açıklar.

Tek atış vs çok turlu akıl yürütme

Tek atış, bir mesajı sınıflandırma, kısa bir yanıt taslağı oluşturma veya belgeden alan çıkarma gibi kapsayıcı görevler için iyidir. Daha ucuz, daha hızlı ve doğrulaması daha kolaydır.

Çok turlu akıl yürütme, modelin netleştirici sorular sorması gerektiğinde veya araçların yinelemeli olarak kullanıldığı durumlarda (ör. plan → ara → rafine et → onay) daha uygundur. Bunu kasıtlı kullanın ve döngüleri zaman/adım limitleri ile sınırlandırın.

Tekrarlanabilir yan etkilere karşı idempotentlik

Modeller yeniden dener. Ağlar başarısız olur. Kullanıcılar çift tıklayabilir. Bir AI adımı e-posta gönderme, rezervasyon yapma, ödeme alma gibi yan etkiler tetikleyebiliyorsa, idempotent olmasını sağlayın.

Yaygın taktikler: her “yürüt” eylemine bir idempotency anahtarı ekleyin, eylem sonucunu saklayın ve yeniden denemeler aynı sonucu döndürsün, tekrarlanmasın.

İzler: her adımı hataya açık hale getirin

Şunu cevaplayabilecek şekilde izlenebilirlik ekleyin: Model ne gördü? Ne kararlaştırdı? Hangi araçlar çalıştı?

Her işlem için yapılandırılmış bir iz kaydedin: prompt versiyonu, girdiler, getirilen bağlam kimlikleri, araç istek/yanıtları, doğrulama hataları, yeniden denemeler ve nihai çıktı. Bu, “AI tuhaf bir şey yaptı”nı denetlenebilir ve düzeltilebilir bir zaman çizelgesine çevirir.

Promptlama: Ürün Mantığı Olarak Net Sözleşmeler ve Formatlar

Model uygulama mantığınızın parçası olduğunda, promptlar “reklam metni” olmaktan çıkar ve yürütülebilir spesifikasyonlar olur. Onları ürün gereksinimleri gibi ele alın: açık kapsam, tahmin edilebilir çıktılar ve değişiklik kontrolü.

Sözleşmeyi tanımlayan bir sistem promptu ile başlayın

Sistem promptu modelin rolünü, neleri yapıp yapamayacağını ve ürününüz için önemli güvenlik kurallarını belirlemelidir. Bunu sabit ve yeniden kullanılabilir tutun.

İçerisine ekleyin:

• Rol ve hedef: kim olduğu (örn. “destek triyaj asistanı”) ve başarı nasıl görünür
• Kapsam sınırları: hangi istekleri reddetmesi veya yükseltmesi gerektiği
• Güvenlik kuralları: KİB işleme, tıbbi/hukuki feragatnameler, tahmin etmeme
• Araç politikası: ne zaman araç çağrılacağı vs. doğrudan cevap verileceği

Promptları net girdiler/çıktılar ile yapılandırın

Promptları bir API tanımı gibi yazın: sağladığınız kesin girdileri (kullanıcı metni, hesap seviyesi, yerel ayar, politika parçaları) ve beklediğiniz kesin çıktıları listeleyin. 1–3 gerçek trafik örneği ekleyin, zor vakalar dahil.

Yararlı bir desen: Bağlam → Görev → Kısıtlar → Çıktı formatı → Örnekler.

Makine tarafından okunabilir sonuçlar için kısıtlı formatlar kullanın

Kodun çıktıyı işlemesi gerekiyorsa, düzyazıya güvenmeyin. Bir şemaya uyan JSON isteyin ve başka bir şey dönerse reddedin.

{
  "type": "object",
  "properties": {
    "intent": {"type": "string"},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "actions": {
      "type": "array",
      "items": {"type": "string"}
    },
    "user_message": {"type": "string"}
  },
  "required": ["intent", "confidence", "actions", "user_message"],
  "additionalProperties": false
}

Promptları versiyonlayın ve güvenle devreye alın

Promptları versiyon kontrolünde saklayın, sürümlerle etiketleyin ve özellik gibi dağıtın: kademeli dağıtım, uygunsa A/B ve hızlı geri alma. Her yanıta prompt versiyonunu kaydedin ki hata ayıklama mümkün olsun.

Bir prompt test paketi oluşturun

Küçük, temsilî bir vaka seti oluşturun (mutlu yol, belirsiz istekler, politika ihlalleri, uzun girdiler, farklı yerel ayarlar). Her prompt değişikliğinde bunları otomatik çalıştırın ve çıktılar sözleşmeyi bozuyorsa build’i başarısız yapın.

Araç Çağırma: Model Karar Versin, Kod Uygulasın

Araç çağırma, sorumlulukları ayırmanın en temiz yoludur: model ne yapılması gerektiğine ve hangi yeteneğin kullanılacağına karar verir; uygulama kodunuz ise eylemi gerçekleştirir ve doğrulanmış sonuçları döner.

Bu, gerçekleri, hesaplamaları ve yan etkileri (bilet oluşturma, kayıt güncelleme, e-posta gönderme) deterministik, denetlenebilir koda bırakır—serbest biçimli düzyazıya güvenmek yerine.

Küçük, amaçlı bir araç seti tasarlayın

Taleplerin %80’ini karşılayacak ve güvenlik açısından test edilmesi kolay bir avuç araçla başlayın:

• Arama (dokümanlarınız/yardım merkezi) — ürün sorularını yanıtlamak için
• Veritabanı sorgusu (önce salt okunur) — kullanıcı/hesap/sipariş durumu için
• Hesaplayıcı — fiyatlama, toplamlar, dönüşümler ve kural tabanlı matematik için
• Biletleme — kullanıcı insan müdahalesi gerektiğinde destek talebi açmak için

Her aracın amacını dar tutun. “Her şeyi yapan” bir araç test edilmesi zor ve kötüye kullanılmaya açık olur.

Girdileri doğrulayın, çıktıları temizleyin

Modeli güvensiz bir çağıran gibi ele alın.

• Araç girdilerini doğrulayın: sıkı şemalar kullanın (tipler, aralıklar, enumlar). Güvenli olmayan argümanları reddedin veya onarın (örn. eksik ID’ler, çok geniş sorgular).
• Araç çıktısını temizleyin: modeli yeniden geri verme öncesi gizli bilgileri çıkarın, formatları normalleştirin ve modele yalnızca gerekli alanları döndürün.

Bu, getirilen metin üzerinden prompt enjeksiyonu riskini azaltır ve veri sızıntısını sınırlar.

Her araca izin ve oran sınırı ekleyin

Her araç şunu uygulamalıdır:

• İzin kontrolleri (kimin hangi kayıtlara veya hangi eylemlere erişebileceği)
• Oran sınırları (kullanıcı/oturum/araç bazında) — kötüye kullanımı ve kontrolsüz döngüleri azaltmak için

Bir araç durum değiştirebiliyorsa (biletleme, iade), daha güçlü yetkilendirme ve yazma denetim günlüğü gerektirir.

“Araç yok” yolunu her zaman destekleyin

Bazen en iyi eylem eylemsizliktir: mevcut bağlamdan cevap ver, netleştirici soru sor veya sınırlamaları açıkla. “Araç yok”u birinci sınıf sonuç olarak yapın ki model yalnızca meşgul görünmek için araç çağırmasın.

Veri ve RAG: Modeli Sizin Gerçekliğinizle Dayandırın

Ürününüzün cevapları politikalarınıza, envanterinize, sözleşmelere veya dahili bilgilere uymalıysa, modeli yalnızca genel eğitimiyle değil—sizin verilerinizle dayandırmanız gerekir.

RAG vs ince ayar vs basit bağlam

• Basit bağlam (prompt’a birkaç paragraf yapıştırma) bilgi az, stabil ve her seferinde göndermeye uygun olduğunda işe yarar (ör. kısa fiyat tablosu).
• RAG (Retrieval-Augmented Generation), bilgi büyük, sık değişen veya alıntılanması gereken durumlarda en iyisidir (örn. yardım merkezi makaleleri, ürün dokümanları, hesap-spesifik veriler).
• İnce ayar (fine-tuning), tutarlı stil/format veya alan-spesifik örüntüler istediğinizde etkilidir—gerçekleri depolamanın birincil yolu olarak değil; modeli yazım ve kurallara uyma konusunda iyileştirmek için kullanın; güncel hakikat için RAG ile eşleştirin.

İçeri alma temelleri: parçalama, meta veri, tazelik

RAG kalitesi çoğunlukla bir içerik alma sorunudur.

Belgeleri modelin token boyutuna uygun parçalara bölün (çoğunlukla birkaç yüz token), ideal olarak doğal sınırlarla hizalanmış (başlıklar, SSS girdileri). Meta veriyi saklayın: belge başlığı, bölüm başlığı, ürün/sürüm, hedef kitle, yerel ayar ve izinler.

Tazelik için plan yapın: yeniden indeksleme zamanlaması, “son güncelleme” takibi ve eski parçaların süresinin dolması. Yüksek sıralanan fakat güncelliğini yitirmiş bir parça, özelliği sessizce bozabilir.

Atıflar ve kalibre cevaplar

Modelden şunu döndürmesini sağlayın: (1) cevap, (2) alıntı parça kimlikleri/başlıklar, (3) bir güven beyanı.

Eğer getirme zayıfsa, modelin doğrulayamadığı şeyleri açıkça belirtmesini ve bir sonraki adımı önermesini söyleyin (“Bu politikayı bulamadım; iletişime geçilecek kişi: ...” gibi). Boşlukları doldurmasına izin vermeyin.

Özel veriler: erişim kontrolü ve kırpma

Erişimi getirmeden önce uygulayın (kullanıcı/organizasyon izinlerine göre filtreleme) ve üretimden önce tekrar uygulayın (hassas alanları kırpma).

Gömülü vektörler ve indeksleri hassas veri depoları olarak ele alın; denetim günlükleri tutun.

Getirme başarısız olursa: nazik geri dönüş yolları

En iyi sonuçlar alakasızsa veya boşsa şu seçeneklere geri dönün: netleştirici soru sorma, insan desteğine yönlendirme veya tahmin etmeye çalışmak yerine sınırlamaları açıklayan bir non-RAG yanıt moduna geçme.

Güvenilirlik: Koruyucular, Doğrulama ve Önbellekleme

Model uygulama mantığınızın içinde olduğunda, “çoğu zaman iyi” yeterli değildir. Güvenilirlik, kullanıcıların tutarlı davranış görmesi, sistemin çıktıyı güvenle tüketebilmesi ve hataların kademeli olarak bozulması demektir.

Önce güvenilirlik hedeflerini tanımlayın

Özellik için “güvenilir” ne demek, yazın:

• Tutarlı çıktılar: benzer girdiler benzer cevaplar üretmeli (ton, detay seviyesi, kısıtlar)
• Stabil formatlar: cevap her seferinde ayrıştırılabilir olmalı (JSON, madde listesi, belirli alanlar)
• Sınırlı davranış: modelin ne yapacağı konusunda net sınırlar (tahmin etmeme, kaynak atıfı, belirsizlikte soru sorma)

Bu hedefler promptlar ve kod için kabul kriterleri olur.

Koruyucular: doğrula, filtrele, ve politikaları uygula

Model çıktısını güvensiz girdi gibi ele alın.

• Şema doğrulama: sıkı bir format (örn. gerekli anahtarları olan JSON) talep edin ve parse edilemeyeni reddedin.
• İçerik filtreleri: küfür, KİB dedektörleri veya politika doğrulayıcılarını hem kullanıcı girdisi hem model çıktısı üzerinde çalıştırın.
• İş kuralları: fiyat aralıkları, uygunluk kuralları, izin verilen eylemler gibi kısıtları kodda zorunlu kılın.

Doğrulama başarısız olursa, güvenli bir geri dönüş sağlayın (netleştirici soru, daha basit şablona geçiş veya insan yönlendirmesi).

Gerçekten fayda sağlayan yeniden denemeler

Kör tekrar etmelerden kaçının. Başarısızlık modunu ele alan farklı bir prompt ile yeniden deneyin:

• “Sadece geçerli JSON döndür. Markdown yok.”
• “Eğer emin değilse confidence alanını düşük ayarla ve bir soru sor.”

Yeniden denemeleri sınırlayın ve her başarısızlık nedenini kaydedin.

Deterministik sonrası işlem

Modelin ürettiklerini normalleştirmek için kod kullanın:

• Birimleri, tarihleri ve isimleri kanonikleştirin
• Öğeleri çoğaltmayı engelleyin
• Sıralama kuralları veya eşik uygulayın

Bu, varyansı azaltır ve çıktıları test etmeyi kolaylaştırır.

Gizlilik sorunları yaratmadan önbellekleme

Tekrarlanan sonuçları (aynı sorgular, paylaşılan gömme vektörleri, araç yanıtları) önbelleğe alınarak maliyet ve gecikme düşürülebilir.

Tercihler:

• kullanıcıya özgü veriler için kısa TTL’ler
• ham KİB içermeyen veya dikkatlice hash’lenmiş önbellek anahtarları
• hassas akışlar için “önbelleğe alma” kapatma bayrağı

Doğru yapıldığında, önbellekleme tutarlılığı artırırken kullanıcı güvenini korur.

Güvenlik ve Güven: UX’i Bozmayacak Risk Azaltma

Güvenlik, sonradan eklenen ayrı bir uyumluluk katmanı değildir. AI-odaklı ürünlerde model eylemleri, ifade tarzını ve kararları etkileyebilir—bu nedenle güvenlik, asistanın ne yapabileceği, neyi reddedeceği ve ne zaman yardım isteyeceği konusunda ürün sözleşmenizin bir parçası olmalıdır.

Tasarlamanız gereken temel güvenlik endişeleri

Uygulamanızın karşılaştığı riskleri adlandırın ve her birini bir kontrolle eşleştirin:

• Hassas veriler: kişisel tanımlayıcılar, kimlik bilgileri, özel belgeler ve düzenlemeye tabi her şey
• Zararlı yönergeler: zarar verme, şiddet, yasa dışı faaliyetler veya tehlikeli tıbbi/finansal eylemleri sağlayabilecek talimatlar
• Önyargı ve adaletsiz sonuçlar: gruplar arasında hizmet kalitesinde veya önerilerde tutarsızlık

İzin verilen/engellenen konular + yükseltme yolları

Ürününüzün uygulayabileceği açık bir politika yazın. Somut tutun: kategoriler, örnekler ve beklenen cevaplar.

Üç seviye kullanın:

1. İzin verilen: normal şekilde yanıt verilir.
2. Kısıtlı: sınırlı şekilde yanıt verilir (örn. yalnızca genel bilgi, adım adım talimat yok).
3. Engellenen: reddet ve bir yükseltme yoluna (destek, kaynaklar veya insan) yönlendir.

Yükseltme bir ürün akışı olmalı, sadece bir reddetme mesajı değil. “Bir kişiye bağlan” seçeneği sunun ve el sıkışma sırasında kullanıcının paylaştığı bağlamı (rıza ile) el ile aktarmayı sağlayın.

Yüksek etkili eylemler için insan incelemesi

Model gerçek sonuçlar tetikleyebiliyorsa—ödemeler, iadeler, hesap değişiklikleri, iptaller, veri silme—bir kontrol noktası ekleyin.

İyi uygulamalar: onay ekranları, “taslak sonra onayla” akışları, limitler (tutar üst sınırları) ve uç durumlar için insan inceleme kuyruğu.

Açıklamalar, rıza ve test edilebilir politikalar

Kullanıcıya AI ile etkileşimde olduğunu, hangi verilerin kullanıldığını ve neyin saklandığını söyleyin. Konuşmaları kaydetme veya sistemi geliştirmek için verileri kullanma konusunda gerektiğinde izin isteyin.

İç güvenlik politikalarını kod gibi yönetin: versiyonlayın, gerekçeyi belgeleyin ve testler (örnek promptlar + beklenen sonuçlar) ekleyin ki her prompt veya model güncellemesiyle güvenlik geri gitmesin.

Değerlendirme: Modeli Diğer Kritik Bir Bileşen Gibi Test Edin

Eğer bir LLM ürününüzün davranışını değiştirebiliyorsa, çalıştığını tekrar kanıtlayacak tekrarlanabilir bir yol oluşturmanız gerekir—kullanıcıların regresyonları sizin yerinize keşfetmesinden önce.

Promptlar, model versiyonları, araç şemaları ve getirme ayarlarını sürümlemeye değer maddeler olarak ele alın; bunlar yayınlanmaya hazır öğelerdir ve test gerektirir.

Gerçeklikten bir değerlendirme seti oluşturun

Gerçek kullanıcı niyetlerini destek kayıtlarından, arama sorgularından, sohbet günlüklerinden (rıza ile) ve satış görüşmelerinden toplayın. Bunları şu test vakalarına dönüştürün:

• Yaygın mutlu yol istekleri
• Netleştirici soru gerektiren belirsiz promptlar
• Uç durumlar (eksik veri, çelişen kısıtlar, alışılmadık formatlar)
• Politika açısından hassas senaryolar (kişisel veri, yasak içerik)

Her vaka beklenen davranışı içermeli: cevap, alınan karar (örn. “araç A çağrıldı”) ve gerekli yapı (JSON alanları, atıflar vb.).

Ürün riskine uygun metrikler seçin

Tek bir puan kaliteyi yakalayamaz. Kullanıcı sonuçlarına bağlı küçük bir metrik seti kullanın:

• Doğruluk / görev başarısı: kullanıcı hedefini çözdü mü?
• Dayanaklılık: iddialar sağlanan bağlam veya kaynaklarla destekleniyor mu?
• Format geçerliliği: çıktı sözleşmeye (JSON, tablo, madde) uyuyor mu?
• Reddetme oranı: doğru zamanda reddediyor mu, gereksiz yere reddetmiyor mu?

Ayrıca kaliteyle birlikte maliyet ve gecikmeyi takip edin; daha iyi bir model yanıt süresini ikiye katlıyorsa dönüşümü bozabilir.

Her değişiklik için çevrimdışı değerlendirmeler çalıştırın

Yayınlamadan ve her prompt, model, araç veya getirme değişikliğinden sonra çevrimdışı değerlendirmeler çalıştırın. Sonuçları sürümleyin ki karşılaştırma yapıp bozan değişikliği hızla tespit edebilin.

Güvenlik sınırlarıyla çevrimiçi testler ekleyin

Gerçek sonuçları ölçmek için A/B testleri kullanın (tamamlama oranı, düzenleme sayısı, kullanıcı puanları), ama güvenlik önlemleri ekleyin: durdurma koşulları (geçersiz çıktı, reddetme veya araç hatalarında ani artış) tanımlayın ve eşikler aşıldığında otomatik geri alma yapın.

Üretimde İzleme: Sürüklenme, Hatalar ve Geri Bildirim

AI-odaklı bir özelliği göndermek bitiş çizgisi değildir. Gerçek kullanıcılar geldikten sonra model yeni ifade biçimleri, uç durumlar ve değişen verilerle karşılaşır. İzleme, “staging’de çalıştı”yı “gelecek ay da çalışıyor”a çevirir.

Önemli olanları kaydedin (gizli veri toplamayın)

Hataları yeniden üretebilmek için yeterli bağlamı kaydedin: kullanıcı niyeti, prompt versiyonu, araç çağrıları ve modelin nihai çıktısı.

Girdileri/çıktıları gizlilik açısından güvenli şekilde kırpın. Logları hassas veri gibi ele alın: e-postalar, telefon numaraları, tokenlar ve kişisel bilgileri içerebilecek serbest metni çıkarın. Belirli oturumlar için geçici “debug modu” etkinleştirme tercihi sunun; varsayılan olarak maksimum logging yapmayın.

Doğru sinyalleri izleyin

Hata oranlarını, araç hatalarını, şema ihlallerini ve sürüklenmeyi izleyin. Somut olarak izlenecekler:

• Araç çağrısı başarı oranı ve zaman aşımı (model doğru aracı seçti mi ve çalıştı mı?)
• Çıktı formatı/şema uyumu (doğrulayıcılar tarafından reddedilenler)
• Geri dönüş kullanım sıklığı (güvenli veya basit yollara ne kadar sık döndünüz)
• İçerik güvenliği blokları (ne sıklıkta reddedildi veya kırpıldı)

Sürüklenme için trafiği baz çizginizle karşılaştırın: konu dağılımı, dil, ortalama prompt uzunluğu ve “bilinmeyen” niyetlerdeki değişimler. Sürüklenme her zaman kötü değildir—ancak yeniden değerlendirme için bir işarettir.

Uyarılar, çalışma kitapları ve olay müdahalesi

Uyarı eşikleri ve nöbetçi çalışma kitapları oluşturun. Uyarılar eyleme dönüştürülebilir olmalı: bir prompt versiyonunu geri almak, hatalı bir aracı devre dışı bırakmak, doğrulamayı sıkılaştırmak veya bir fallback’e geçmek.

Güvenli olmayan veya hatalı davranış için olay müdahale planı hazırlayın. Kim güvenlik anahtarlarını kapatabilir, kullanıcılara nasıl bildirim yapılır ve olay nasıl belgelendirilip öğrenme sağlanır, belirleyin.

Kullanıcı geri bildirimi ile döngüyü kapatın

Beğenme/beğenmeme, sebep kodları, hata raporları gibi geri bildirim döngüleri kullanın. “Neden?” için kısa seçenekler sorun (yanlış bilgi, talimatlara uymadı, güvensiz, çok yavaş) ki sorunları doğru yere (prompt, araçlar, veri veya politika) yönlendirebilesiniz.

Model-Tabanlı Mantık için UX: Şeffaflık ve Kontrol

Model odaklı özellikler çalıştığında sihirli, çalışmadığında kırılgan hissedilir. UX, belirsizliği varsaymalı ve yine de kullanıcıların işi tamamlamasına yardım etmelidir.

İnsanları bunaltmadan “neden”i gösterin

Kullanıcılar, çıktının nereden geldiğini gördüklerinde AI çıktısına daha çok güvenirler—bunun sebebi ders vermek değil, aksiyona geçmeden önce değerlendirme yapmalarına yardımcı olmaktır.

Kademeli açıklama kullanın:

• Sonuçla başlayın (cevap, taslak, öneri).
• “Neden?” ya da “Çalışmayı göster” düğmesi sunun; burada ana girdiyi, kullanılan araçları ve danışılan kaynakları gösterin.
• Eğer retrieval kullanıyorsanız, atıfları gösterin ve kullanıcıyı ilgili parçaya götürün (ör. “Kaynak: Politika §3.2”). Bunu okunabilir tutun.

Daha derin bir açıklayıcı içeriğiniz varsa, UI’yi bunaltmayacak şekilde dahili bir bağlantı gösterin; örneğin "/blog/rag-grounding".

Belirsizlik için tasarlayın (korkutucu uyarılar olmadan)

Model bir hesap makinesi değildir. Arayüz, güven düzeyini iletmeli ve doğrulamayı davet etmelidir.

Pratik desenler:

• Gerçekçi dil kullanarak güven ipuçları (“Muhtemelen doğru”, “Gözden geçirilmesi gerekiyor”)
• Tek cevap yerine seçenekler: “İşte yanıt vermenin 3 yolu.” Bu yanlış ilk tahmin maliyetini azaltır.
• Yüksek etkili eylemler için onaylar (e-posta gönderme, veri silme, ödeme yapma). Tek bir net soru sorun: “Bu mesajı 12 alıcıya gönder?”

Düzeltmeyi ve kurtarmayı kolaylaştırın

Kullanıcı çıktıyı yeniden başlatmadan yönlendirebilmeli:

• Satır içi düzenleme ve “Değişiklikleri uygula” ile modelin kullanıcı düzeltmesinden devam etmesi
• Ton, uzunluk, kısıtlar gibi kontrollerle “Yeniden oluştur” seçeneği
• “Geri al” ve görünür geçmiş ile hatalar geri alınabilir olmalı

Bir kaçış kapısı sağlayın

Model başarısız olduğunda veya kullanıcı emin olmadığında deterministik bir akış veya insan yardımı sunun.

Örnekler: “Manuel forma geç”, “Şablonu kullan” veya “Destek ile iletişime geç” (örneğin /support). Bu bir utanç geri dönüşü değil; görev tamamlama ve güveni koruma yoludur.

Prototipten Üretime (Her Şeyi Yeniden İnşa Etmeden)

Çoğu takım LLM’lerin yetersizliğinden değil; prototipten güvenilir, test edilebilir ve izlenebilir bir özelliğe geçiş yolunun beklenenden uzun olmasından başarısız olur.

Yolu kısaltmanın pratik bir yolu, “ürün iskeleti”ni erken standartlaştırmaktır: durum makineleri, araç şemaları, doğrulama, izler ve dağıtım/geri alma hikayesi. Koder.ai gibi platformlar, AI-odaklı bir iş akışını hızlıca kurmak istediğinizde yararlı olabilir—UI, backend ve veritabanını birlikte oluşturmanıza izin verir; ardından anlık görüntüler/geri alma, özel alan adları ve barındırma ile güvenle yineleme yapabilirsiniz. Operasyonelleşmeye hazır olduğunuzda, kaynak kodunu dışa aktarabilir ve tercih ettiğiniz CI/CD ile gözlemlenebilirlik yığınında devam edebilirsiniz.