Şirketiniz için yapay zekâ sistemi nasıl tasarlanır?

Doğru bilgiye hangi yoldan ulaşacaksınız?

İade talebine cevap hazırlamak için yalnızca müşterinin mesajı yetmez. İade koşulları, siparişin güncel durumu ve müşteriye özel bir anlaşma aynı cevabı etkileyebilir. Her bilginin kaynağını ve ne kadar güncel olması gerektiğini ayrı ayrı belirleyin.

İade politikasını açıklamakla belirli bir siparişin iade koşullarını karşılayıp karşılamadığını değerlendirmek aynı bilgiye dayanmaz. İlkinde politika metni yeterli olabilir. İkincisinde teslimat tarihi, ürün ve müşteriye özel koşullar da gerekebilir. Belgenin doğru olması, bu kayıtların mevcut ve güncel olduğu anlamına gelmez.

Bu yüzden veri hazırlığını belirli bir karar üzerinden değerlendirin: hangi bilgi eksik, eksikliği hangi cevabı veya işlemi bozuyor, güncel hâlinden kim sorumlu? Bazı işlerde kaynağı düzeltmek, bazılarında ilk sürümün kapsamını daraltmak daha uygun olabilir.

İlgili yazı

İlgili yazı

Veriniz Yapay Zekâya Hazır mı? Önce Hangi Karar İçin Olduğunu Söyleyin

Verinin yeterliliğinin verilecek karara nasıl bağlı olduğunu ayrı bir yazıda inceledim. Hangi eksikleri önce gidermeniz gerektiğini düşünürken bu örneklerden yararlanabilirsiniz.

Yeni sekmede açılır

Aynı varsayımsal iade talebi, üç bilgi ihtiyacı

Bu ürün hangi koşullarda iade edilebilir?

Geçerli iade politikasıİlgili kural kısa ve hangi belgede olduğu belliyse, güncel metni soruyla birlikte modele vermek yeterli olabilir. Bunun için ayrıca bir belge arama sistemi kurmak gerekmeyebilir.

Sipariş ne zaman teslim edilmiş?

Sipariş sistemindeki güncel kayıtTeslimat durumunu eski bir belge kopyasından değil, yetkili bir sistem sorgusundan alın. API veya veritabanı bağlantısı bu güncel kaydı sağlayabilir.

Bu müşteriye özel bir koşul var mı?

Müşteri kaydı ve ilgili sözleşmeÇok sayıda sözleşme arasından ilgili bölümü bulmak için arama gerekebilir. Müşteri eşleşmesi ve erişim izinleri, bilgi modele ulaşmadan önce kontrol edilmelidir.

RAG, model cevap vermeden önce ilgili kaynakları arayıp gerekli bölümleri cevabın bağlamına ekleyen yaklaşımdır. Büyük bir belge kümesinde doğru bölümü bulmak için anlamlı olabilir; güncel sipariş kaydını okumakla aynı ihtiyacı çözmez.

Gerekli bilgi yoksa veya güncelliği doğrulanamıyorsa, eksik bilgiyi istemek ya da işi temsilciye devretmek de tasarımın parçasıdır. Sistemin bu durumda nasıl ilerleyeceğini baştan belirleyin.

İlgili yazı

Bilgiye erişim seçeneklerini bu yazıda karşılaştırdım

Kurumsal Yapay Zekâda RAG Ne Zaman Gerekir?

Bakım kılavuzu, güncel sipariş ve müşteri sözleşmesi örnekleri üzerinden doğrudan belge kullanımı, sistem sorgusu ve RAG arasındaki farkı inceledim. Hangi durumda arama gerektiğini ve erişim izinlerinin nerede uygulanacağını yazıda daha ayrıntılı bulabilirsiniz.

Yeni sekmede açılır

Güncel iade politikasını modele göstermek, modeli yeniden eğitmek değildir; politika değiştiğinde kaynağı güncellersiniz. Model doğru bilgiye ve açık talimatlara rağmen aynı sınıflandırma ya da bilgi çıkarma hatasını tekrarlıyorsa, o dar görev için örneklerle uyarlama değerlendirilebilir. Önce hatanın bilgi eksikliğinden mi, modelin davranışından mı kaynaklandığını ayırmak gerekir.

İşe yaradığını hangi kanıtla anlayacaksınız?

Sistem doğru bir cevap yazabilir, doğru aracı çağırabilir ve yine de müşterinin işini tamamlayamayabilir. İade örneğinde dört ayrı sorunun cevabını arayın. Her biri farklı bir kayıtta görünür.

Model ne üretti?

Talebi doğru anlamış mı, önerdiği tutar ve cevap uygun mu? Gerçek talepleri temsil eden örnekler ve açık değerlendirme ölçütleriyle inceleyin.

Sistem hangi yolu izledi?

Hangi kaydı kullandı, onayı aldı mı, bir adımı tekrarladı mı? Çalışma kaydı hatanın hangi adımda oluştuğunu bulmanıza yardım eder.

İş gerçekten tamamlandı mı?

İade ödeme sisteminde hangi durumda? Sonucu işlemin tutulduğu kayıttan doğrulayın; bekleyen veya bilinmeyen sonucu tamamlanmış saymayın.

İşletmede ne değişti?

Müşterinin tekrar yazması azaldı mı, temsilcinin düzeltme yükü değişti mi? Hedeflediğiniz iş sonucunu, önceki durum ve uygun bir karşılaştırmayla değerlendirin.

Pilot başlamadan önce hangi sonucu, hangi hata türlerini ve hangi süre içinde izleyeceğinizi yazın. Örnekler yalnız kolay taleplerden oluşmasın; eksik bilgi, istisna ve başarısız işlem durumlarını da kapsasın. Bir gösterge iyileştiğinde ekip, dönem veya gelen işlerin dağılımı gibi başka değişiklikleri de inceleyin.

Kontrolün kapsamı, sistemin etkisine göre büyüsün. Temsilciye taslak hazırlayan bir yardımcıyla para hareketi yapan bir sistem aynı kanıtı gerektirmez. Sonradan modele, bilgi kaynağına veya iş akışına yaptığınız değişiklikleri de bu örneklerle yeniden sınayın.

İlgili yazı

İyi cevap ile iş sonucu arasındaki farkı bu yazıda ele aldım

Yapay Zekâ Sisteminiz Gerçekten Sonuç Üretiyor mu?

Camiler.org deneyimimden başlayarak model çıktısını, çalışma kaydını, tamamlanan işi ve işletme etkisini ayırıyorum. Pilotunuzda neyi başarı sayacağınızı ve bunu hangi kanıtla göstereceğinizi belirlerken yararlanabilirsiniz.

Yeni sekmede açılır

İkinci model hangi farkı yaratacak?

İş, bilgi, yetki ve başarı ölçütleri netleştiğinde model seçeneklerini aynı görev üzerinde karşılaştırabilirsiniz. Mesajı anlayıp cevap hazırlamak için tek genel amaçlı model yeterli olabilir. Bilgi arama, iş kuralları ve ödeme işlemleri yine sistemin diğer parçalarında kalır.

İkinci modele belirli bir iş verin: örneğin sık gelen talepleri sınıflandırmak. Gerçek örneklerde kaliteyi, hızı veya maliyeti iyileştiriyor mu? Dar bir işte uzman model yararlı olabilir; fakat ek entegrasyonun, testlerin ve bakımın da karşılığı olmalı.

Fiyat karşılaştırmasını model çağrısında bitirmeyin. Model, kontrol, hata düzeltme ve işletim maliyetlerini birlikte düşünün; bunları kullanılabilir sonuç sayısıyla ilişkilendirin. Kesintiye karşı eklediğiniz bir modelin de aynı işi kabul edilebilir kalitede yaptığını önceden sınayın.

İlgili yazı

Tek modelin sınırını bu yazıda inceliyorum

Tek Bir Yapay Zekâ Modeli Ne Zaman Yeterli?

Genel amaçlı modelle başlamanın hangi işlerde makul olduğunu ve uzman modelin yerini nasıl hak edebileceğini ele aldım. İkinci modelin faydasını, beraberinde getirdiği işletim yüküyle birlikte değerlendirebilirsiniz.

Yeni sekmede açılır

Birden fazla model varsa isteği nasıl yönlendireceksiniz?

İkinci modelin gerekli olması, her istek için model seçen bir tahmin sistemi kurmanız gerektiği anlamına gelmez. Belge türü, açık bir iş kuralı veya veri politikası seçimi zaten belirliyorsa önce bu sınırları uygulayın. Aşağıdaki yollar farklı sorunları çözer.

Sabit kural

Seçim çağrıdan önce bellidir. Örneğin taranmış belge görsel işleyebilen modele gider. Kuralı ve istisnaları yazılım uygular.

Tahmine dayalı yönlendirme

Router, isteğin hangi modele uygun olduğunu tahmin eder. Zor talebi yetersiz modele göndermek ayrı bir hata türüdür; yönlendirme kararını da ölçmeniz gerekir.

Kademeli geçiş

İlk cevabın yeterliliği kontrol edilir, gerekirse başka model denenir. İkinci çağrı ve değerlendirme, maliyet ile bekleme süresine eklenir.

Yedek yol

Teknik hata veya kesintide önceden sınanmış alternatif devreye girer. İlk modelin cevap vermesi ama yanlış cevap vermesi, bu yolu kendiliğinden çalıştırmaz.

Tahmine dayalı bir router deneyecekseniz aynı istekleri tek modelle ve basit kurallarla da çalıştırın. Yalnız çağrı fiyatını değil, yanlış yönlendirmeleri, toplam gecikmeyi ve kullanılabilir sonuç başına maliyeti karşılaştırın. Ek karar katmanı ancak bu karşılaştırmada anlamlı bir fark yaratıyorsa yerini hak eder.

İlgili yazı

Yönlendirme seçeneklerini ayrı bir yazıda karşılaştırdım

Yapay Zekâ İstekleri Ne Zaman Farklı Modellere Yönlendirilmeli?

Sabit kural, tahmine dayalı seçim, kademeli geçiş ve yedek yolun farklarını örneklerle açıyorum. Bir router eklemeden önce hangi karşılaştırmaları yapmanız gerektiğini daha ayrıntılı inceleyebilirsiniz.

Yeni sekmede açılır

Sistemi şirketinize özgü yapan ne olacak?

Aynı model bir şirkette iade politikasını açıklayabilir; başka bir şirkette siparişi bulup müşteriye özel koşulları kontrol ederek onaya hazır bir işlem önerisi üretebilir. Farkı, modele verilen talimatla birlikte bağlandığı kaynaklar, uygulanan kurallar ve tanınan yetkiler oluşturur.

Güncel sipariş kaydını sipariş sisteminde, açık iade kurallarını yazılımda, erişim ve işlem yetkilerini ilgili kontrollerde tutun. Model bu parçaları kullanabilir; onların sorumluluğunu üstlenmez. Şirkete özgü bir örüntüyü öğrenmesi gerekiyorsa bunu ayrıca, gerçek örneklerle değerlendirin.

Model değiştiğinde aynı kaynakları, işlem sınırlarını ve değerlendirme örneklerini kullanarak sonucu yeniden sınayabilmelisiniz. Kaynağı kimin güncellediği, istisnaya kimin karar verdiği ve başarısız işlemi kimin takip ettiği de tasarımın parçasıdır. Böylece sistemi işletme bilgisi tek bir prompt içinde kaybolmaz.

İlgili yazı

Bu parçaların nasıl bir araya geldiğini son yazıda ele aldım

Şirkete Özel Yapay Zekâyı Özel Yapan Nedir?

Bir satın alma örneği üzerinden bilgi, kural, araç, yetki ve ölçümün nerede durması gerektiğini inceliyorum. Şirketinize özgü ihtiyacın hangisini modelin öğrenmesi, hangisini çevresindeki sistemin sağlaması gerektiğini ayırabilirsiniz.

Yeni sekmede açılır

İlk sürümü kısa bir karar notuna dönüştürün

Rehberin sonunda bir model listesi yerine, geliştirme ekibiyle tartışabileceğiniz bir kapsamınız olsun. Aşağıdaki örnek, kullandığımız varsayımsal iade sürecinin yalnızca taslak hazırlayan ilk sürümünü tarif ediyor; bir sonuç veya performans vaadi değil.

Değişmesini istediğimiz iş

Temsilcinin iade cevabı hazırlarken bilgi aramak için harcadığı süreyi azaltmak; cevap doğruluğunu ve düzeltme yükünü birlikte izlemek.

İlk sürümün sınırı

Talebi anlayıp kaynaklarıyla birlikte cevap taslağı hazırlamak. Müşteriye gönderim ve para iadesi temsilcinin mevcut sürecinde kalır.

Bilgi ve erişim

Güncel politika, yetkili sipariş sorgusu ve gerekiyorsa müşteriye özel koşullar. Eksik veya çelişkili bilgi temsilciye açıkça gösterilir.

Çalışma biçimi

Önceden belirlenmiş iş akışı ve gerçek örneklerde sınanacak tek model. Agent, fine-tuning veya ikinci model için önce belirli bir eksiklik gösterilir.

Başarı ve durma ölçütü

Pilot öncesi süre ve kalite kaydedilir; test örnekleri, kabul sınırları ve değerlendirme süresi ekipçe belirlenir. Yetkisiz veri erişimi veya artan düzeltme yükü genişletme kararını durdurur.

Sorumluluk ve bakım

Politika kaynağını güncelleyen kişi, istisnayı ele alan temsilci ve entegrasyon hatasını takip eden teknik sorumlu belirlenir. Değişikliklerden sonra aynı örnekler yeniden sınanır.

Kendi notunuzda cevabı açık olmayan bir madde varsa ilgili bölüme dönün. İlk pilotun kapsamını bu belirsizliği azaltacak kadar dar tutabilirsiniz. Yeni yazılar ve uygulamalardan çıkan sorularla bu rehberi geliştirmeye devam edeceğim.