Karşılaştırılabilir yanıtlar getiren bir yapay zeka teklif talebi (RFP) nasıl yazılır?

Aynı yapay zeka projesi için beş teklif gelir. Biri bir platform lisansını, biri altı aylık bir ekibi, biri de “birinci aşama” için sabit bir ücreti fiyatlamıştır; ikisi ise farklı şeyler üzerinde ölçülmüş doğruluk rakamları verir. Kimse bunları karşılaştıramaz, çünkü teklif talebi (RFP) özellikleri listelemiş ve projeyi her teklif verenin hayal gücüne bırakmıştır.

Bir yapay zeka RFP’si, bunun yerine işi anlattığında karşılaştırılabilir yanıtlar alır: iş akışını, gerçek örnekleri ve iyinin neye benzediğini. Her teklif verene değerlendirme, ekip, sahiplik ve işletme maliyeti hakkında aynı soruları sorar. Süreç de aynı örnekler üzerinde kısa, ücretli bir testle biter, çünkü sizin vakalarınızdaki sonuçlar sunum slaytlarından çok daha iyi karşılaştırılır.

Yapay zeka RFP’leri neden karşılaştırılamayan yanıtlar getirir?

Yazılım satın almasından ödünç alınan üç alışkanlık zarar verir. Özellik listeleri (“bilgi erişimini desteklemeli”, “bir sohbet robotu içermeli”) her teklif vereni her şeye evet demeye davet eder. “Yüksek doğruluk” gibi tanımsız bir hedef, her teklif verenin doğruluğu kendi verisi üzerinde tanımlamasına izin verir. Gerçek örnekler olmadığında da her teklif veren farklı vakalar hayal eder ve her biri farklı bir projeyi fiyatlar.

Fiyatlandırma modelleri durumu daha da kötüleştirir. Bir lisans, altı aylık bir ekip ve aşama başına sabit bir ücret, RFP maliyeti aynı birimlerle istemedikçe karşılaştırılamaz: ilk aşama için sabit bir fiyat ve sizin hacimlerinizde vaka başına bir işletme maliyeti.

RFP işi tanımlamazsa, her teklif veren onu sizin yerinize tanımlar.

İş hakkında neler anlatılmalı?

Teklif verenin aksi halde tahmin etmek zorunda kalacağı her şey:

• İş akışı ve hacimler: adımlar, onları kimin yaptığı, süreç sahibi, haftalık hacim ve yoğun dönemler.
• Sistemler: çözümün hangi sistemlerden okuması ve hangilerine yazması gerektiği.
• Veriler ve diller: kaynaklar, hassasiyet, formatlar ve kullanılan diller; tek bir mesajda karışan Türkçe ve İngilizce de dahil.
• Kısıtlar: verinin nerede işlenebileceği, barındırma tercihleri, güvenlik incelemeleri ve veri koruma görevlinizin (DPO) yanıtlanmasını istediği KVKK ve GDPR soruları.
• İyinin tanımı: doğru sonucun ne olduğu, hangi hataların asla kabul edilemeyeceği ve nelerin bir insana gitmesi gerektiği.
• Örnek vakalar: uzmanlarınızın kabul edeceği yanıtlarla birlikte, zorlu olanlar da dahil, gerçek vakalardan küçük ve maskelenmiş bir set.

Karşılaştırılabilirliğe en çok katkıyı bu örneklem yapar. Paylaşmadan önce veri koruma görevlinize danışın: neyin çıkarılması gerektiğini, hangi sözleşmeyle gönderileceğini ve teklif verenlerin onu ne zaman silmesi gerektiğini birlikte belirleyin.

Teklif verenlerden neyi açıklamaları istenmeli?

Herkesten aynı zorunlu yanıtları, aynı sırayla ve her yanıt için kelime sınırı olan bir şablonla isteyin; böylece sunumu değil içeriği karşılaştırırsınız:

1. Değerlendirme planı. Vakalarınızdan nasıl bir değerlendirme seti kuracakları, referans yanıtları kimin yazacağı ve sonuçların kabul kriterlerine göre, vaka türü bazında nasıl raporlanacağı.
2. Geliştirecek ekip. İsimler, roller, ayrılan zaman ve sizin tarafınızdan neye ihtiyaç duydukları.
3. Sahiplik. Kodun, promptların, değerlendirme setlerinin ve dokümantasyonun sahibinin kim olacağı ve teklif verenin elinde tuttuğu her şeyin koşulları.
4. İşletme maliyeti modeli. İnceleme süresi dahil sizin hacimlerinizde vaka başına maliyet, onu neyin artırdığı ve bir tavanın nasıl uygulanacağı.
5. Çıkış. Devir teslimin neleri içerdiği, modeli ya da tedarikçiyi nasıl değiştirebileceğiniz ve verilerinize ne olacağı.
6. Onay noktaları. Kararı nerede bir insanın vereceği ve neyi otomatikleştirmeyecekleri.

RFP’de neler olmamalı?

• Model adları ve sürümleri. İhalelerden daha hızlı değişirler. Sistemin geçmesi gereken değerlendirmeyi belirtin ve model değiştirebilen bir tasarım isteyin.
• Tanımsız doğruluk hedefleri. Bunun yerine teklif verenlere, kaliteyi sizin örnekleminizde nasıl ölçeceklerini sorun.
• Genel ürün anketleri. Güvenlik ve ürün incelemesi ayrı bir tedarikçi değerlendirme soru listesine aittir.
• Ücretsiz kavram kanıtı (PoC) talepleri. Karşılığı ödenmeyen iş aceleye getirilir. Kısa ve sınırları belli bir test için ödeme yapın.
• Tanımsız bir program için sabit fiyat. Aşama başına sabit fiyat isteyin; bir sonraki aşamaya kanıta dayanarak karar verilsin.

Teklifler nasıl değerlendirilmeli?

İlk teklif açılmadan önce puanlama üzerinde anlaşın: zorunlu yanıtlar, kısıtlarınıza uyum ve fiyat; ağırlıklar önceden belirlenmiş olarak. Yanıtları teklif teklif değil, yan yana puanlayın. Kısa listedeki her ekipten, işi geliştirecek kişiler de odadayken, gerçekte nasıl çalıştıklarını gösteren soruları yüz yüze yanıtlamasını isteyin.

Ardından iki finalist için aynı örneklem üzerinde, aynı kabul kriterlerine göre ve aynı süre sınırıyla kısa, ücretli bir test yapın. Vaka türüne göre kaliteyi, vaka başına maliyeti ve her ekibin sizinkiyle nasıl çalıştığını karşılaştırın. Kazananın ilk aşaması, zaten yazdığınız kriterlerle sınırları belli bir pilottur; bir Pilottan Canlıya çalışmasının yapısı da budur. Fiyatı neyin etkilediğini bir yapay zeka projesinin maliyetini belirleyen etkenler notunda bulabilirsiniz.

Bir yapay zeka RFP şablonu neye benzer?

Aşağıda bir e-ticaret şirketinde müşteri e-postalarının ön sınıflandırması için temsili bir RFP var; her bölüm kısaca doldurulmuş.

İlk taslaktan önce ne yapılmalı?

Her şeyden önce iyinin tanımını yazın. Ekibiniz bu tanım üzerinde anlaşamıyorsa RFP hazır değildir ve bu anlaşmazlık, o ana kadar öğrendiğiniz en faydalı şeydir. Önce dışarıdan bir görüş isterseniz, bir Keşif Çalışması bu tür bir RFP’nin ihtiyaç duyduğu başlangıç ölçümünü, veri ve erişim incelemesini ve kabul kriterlerini ortaya çıkarır. İhale yazmıyor da yanıtlıyor musunuz? İhale yanıtlarında yapay zeka notuna bakın.