RAG veya yapay zekâ asistanı projesinin kapsamını belirlemek: kontrol listesi

Hayal kırıklığı yaratan yapay zekâ asistanı projelerinin çoğu model yüzünden başarısız olmaz. Asistanın ne işe yaradığı konusunda kimse anlaşmadığı, arkadaki içerik eksik veya bayat olduğu, izinler sonradan akla geldiği veya bir değişikliğin işleri iyileştirip iyileştirmediğini anlamanın yolu olmadığı için başarısız olurlar. Model seçimi önemlidir, ancak genellikle daha kolay kararlardan biridir.

Bu kontrol listesi, şirket verileri üzerinde bir retrieval-augmented generation (RAG) sistemi veya yapay zekâ asistanı geliştirmeden önce üzerinden geçtiğimiz soruları toplar. İç bir projeyi hazırlamak, bir tedarikçiyi brief etmek veya aldığınız bir teklifin esasları kapsayıp kapsamadığını kontrol etmek için kullanın. İlk gün her yanıta ihtiyacınız yok, ancak hangilerinin hâlâ açık olduğunu bilmelisiniz.

1. Kullanım senaryosu ve başarı kriterleri#

Kimse bir notebook açmadan veya modelleri karşılaştırmadan önce bunları yazın.

• Tek birincil görev. Asistanın önce iyi yapması gereken tek görevi adlandırın; örneğin destek ekibinin ürün sorularını yanıtlamak veya tedarikçi sözleşmelerinde madde bulmak. İlki ölçüldükten sonra başka kullanım senaryoları gelebilir; baştan birkaçını karıştırmak hem gereksinimleri hem değerlendirmeyi bulanıklaştırır.
• Kullanıcılar ve durumları. Kimin, ne sıklıkla, hangi dilde ve hangi cihazdan sorduğunu ve yanıtla ne yaptığını tanımlayın. Kaynakları kontrol eden bir iç uzmanın ihtiyacı, yanıta göre doğrudan hareket eden bir müşterininkinden farklıdır.
• İdeal yanıtlarla gerçek sorular. Ticket'lardan, e-postalardan veya sohbet kayıtlarından 20–50 gerçek soru toplayın ve bir alan uzmanına ideal yanıtı yazdırıp gelmesi gereken kaynağı adlandırın. Bu set "iyi"nin ne demek olduğunu tanımlar ve değerlendirme setinizin çekirdeğini oluşturur.
• Kapsam dışı ve reddetmeler. Asistanın yapmaması gerekenleri listeleyin: hukuki, tıbbi veya finansal tavsiye vermek, kaynaklarının ötesinde yanıt vermek, şirket adına taahhütlerde bulunmak. Bunun yerine ne söylemesi gerektiğine ve kullanıcıyı nereye yönlendirmesi gerektiğine karar verin.
• Mevcut sürecin referans çizgisi. İşin bugün nasıl yapıldığını, ne kadar sürdüğünü, kimin yaptığını ve maliyetini kaydedin. Referans çizgisi olmadan "asistan yardımcı oluyor" bir sonuç değil, bir görüştür.

2. Veri kaynakları#

Yanıtların kalitesi, ardındaki içeriğin kalitesi ve erişilebilirliğiyle sınırlıdır.

• Kaynak envanteri. Asistanın kullanması gereken her kaynağı listeleyin: wiki'ler, SharePoint veya Google Drive klasörleri, ticket sistemleri, veritabanları, PDF'ler, web siteleri. Her biri için nasıl erişilebildiğini (API, export, crawl) ve bu erişime izin verilip verilmediğini not edin.
• Formatlar ve belge kalitesi. OCR gerektiren taranmış PDF'leri, karmaşık tabloları, formları, slaytları ve temel içerik taşıyan görselleri kontrol edin. Naif pipeline'ların en çok bilgi kaybettiği yer tablolar ve taramalardır; bunları erken örnekleyin.
• Sahiplik ve tazelik. Her kaynak için bir sahip belirleyin ve ne sıklıkla değiştiğini kaydedin. İçeriğe kimse sahip değilse, ondan gelen yanlış yanıtları da kimse düzeltmez.
• Kopyalar, sürümler ve diller. Aynı politikanın güncel olmayan kopyalarını, taslaklarını ve paralel sürümlerini belirleyin ve hangisinin yetkili olduğuna karar verin. Hem belgelerin hem soruların dillerini not edin, çünkü diller arası retrieval'ın açıkça test edilmesi gerekir.

3. Erişim kontrolü ve mahremiyet#

Gerçek veri sistemlerinizden çıkmadan önce bunları netleştirin.

• Retrieval'a taşınan izinler. Kullanıcılar yalnızca belirli belgeleri görebiliyorsa, retrieval kaynak sistemlerden senkronize edilen, isteği yapan kullanıcının izinlerine göre filtrelemelidir. Prompt'taki talimatlar veya modele içeriği saklaması için güvenmek erişim kontrolü değildir.
• Kişisel veriler ve hukuki dayanak. Belgelerdeki, sorulardaki ve log'lardaki kişisel verileri belirleyin ve işlemenin GDPR hukuki dayanağını ve amacını belgeleyin. Veri koruma sorumlunuzu lansmanda değil, başlangıçta dahil edin.
• Sağlayıcı sözleşmesi ve veri yerleşimi. Her model ve altyapı sağlayıcısıyla bir veri işleme sözleşmesi yapın, alt işleyenlerini gözden geçirin ve gerekiyorsa işlemenin bir AB bölgesinde kalabileceğini doğrulayın. Verilerinizin sağlayıcının modellerini eğitmek için kullanılmadığına dair yazılı onay alın.
• Saklama, loglama ve maskeleme. Prompt'ların, getirilen pasajların ve yanıtların ne kadar saklandığına, kimlerin okuyabildiğine ve loglanmadan önce kişisel verilerin maskelenip maskelenmediğine karar verin. Log'lar hata ayıklama ve değerlendirme için gereklidir; amaç sıfır loglama değil, kontrollü saklamadır.

4. Retrieval tasarımı#

RAG sistemlerindeki yanlış yanıtların çoğu modelden çok retrieval'a dayanır; küçük ve sabit bir külliyat için prompt caching'li uzun bağlam retrieval'ın yerini tamamen alabilir (bkz. RAG vs fine-tuning).

• Belge yapısı boyunca chunking. İçeriği sabit karakter sayıları yerine başlıklar, bölümler, liste öğeleri ve tablo sınırları boyunca bölün. Bir pasaj kendi başına anlamlı kalabilsin diye başlık yolunu her chunk ile birlikte tutun.
• Metadata ve filtreler. Her chunk ile başlık, kaynak, bölüm, tarih, dil, sürüm ve erişim gruplarını saklayın. İzin filtrelemesini, "yalnızca son sürüm" kurallarını ve yararlı citation'ları mümkün kılan metadata'dır.
• Hibrit arama ve reranking. Ürün kodları, madde numaraları ve isimler gibi kesin terimler için anahtar kelime aramasını, anlam için embedding'ler üzerinde vektör aramasıyla birleştirin, sonra birleşik adayları yeniden sıralayın. Varsayılanların yeterli olduğunu varsaymak yerine her adımı örnek sorularınıza karşı test edin.
• Citation şartı. Asistandan kullandığı pasajları, kaynak belgeye ve bölüme bağlantıyla birlikte alıntılamasını isteyin. Citation'lar kullanıcıların yanıtları doğrulamasını ve inceleyenlerin yanlış bir yanıtın kötü retrieval'dan mı kötü üretimden mi geldiğini görmesini sağlar.

5. Model ve sağlayıcı seçimi#

Modeli, değerlendirme setiniz olduktan sonra seçin; böylece karar genel benchmark'lara değil kendi verilerinize dayanır.

• Hosting seçeneği. Hosted bir API'yi, bir AB bulut bölgesindeki aynı veya benzer modelleri ve kendi altyapınızda self-host edilen açık ağırlıklı bir modeli karşılaştırın. Her seçenek; yanıt kalitesi, veri kontrolü, operasyonel çaba ve maliyet arasındaki dengeyi değiştirir.
• Sorgu başına gecikme ve maliyet. Kendi örnek sorularınızda uçtan uca yanıt süresini ve yanıtlanan soru başına maliyeti ölçün; retrieval, reranking ile girdi ve çıktı token'ları dahil. Prompt caching ve basit adımlar için daha küçük modeller bu rakamları önemli ölçüde değiştirebilir.
• Fallback ve kilitlenme. Sağlayıcı çöktüğünde veya bir modeli emekliye ayırdığında ne olacağını planlayın: ikinci bir sağlayıcı, düşürülmüş bir mod veya net bir hata mesajı. Prompt'ları, değerlendirme setini ve retrieval katmanını sağlayıcıdan bağımsız tutun; böylece geçiş bir yeniden yazım değil, bir yapılandırma değişikliği artı bir eval çalıştırması olur.

6. Değerlendirme#

Kaliteyi ölçemiyorsanız, onu iyileştiremez veya canlıya alma kararını savunamazsınız.

• Geliştirmeden önce eval seti. Bölüm 1'deki gerçek soruları, beklenen yanıtlar ve beklenen kaynaklar içeren versiyonlanmış bir değerlendirme setine dönüştürün ve zor ile uç durumlarla genişletin. İlk demodan sonra değil, ilk prototipten önce oluşturun.
• Retrieval ve yanıt kalitesi. Doğru pasajların getirilip getirilmediğini ve yanıtın doğru, eksiksiz ve bu pasajlara sadık olup olmadığını ayrı ayrı ölçün. Citation doğruluğunu kontrol edin: alıntılanan pasaj ifadeyi gerçekten desteklemelidir.
• Reddetme ve prompt injection testleri. Asistanın geri çevirmesi gereken sorular ile kaynaklarının yanıtlayamayacağı soruları dahil edin ve tahmin etmek yerine bunu söylediğini doğrulayın. Talimatlarını geçersiz kılmaya veya başka kullanıcıların verilerini çıkarmaya çalışan belgeler ve girdiler ekleyin ve başarısız olduklarını doğrulayın.
• Regresyon çalıştırmaları ve insan incelemesi. Prompt'lardaki, modellerdeki, chunking'deki veya verilerdeki her değişiklikte tüm eval setini çalıştırın ve sonuçları önceki çalıştırmayla karşılaştırın. Model ile otomatik puanlama bunu hızlandırır, ancak bir alan uzmanı sonuçları düzenli olarak nokta kontrolünden geçirmelidir.

7. Entegrasyon ve operasyonlar#

Asistanın bir yerde yaşaması ve lansmandan sonra birinin onu işletmesi gerekir.

• Kanal ve oturum açma. Asistanın nerede yaşayacağına karar verin: bir web sitesi widget'ı, Slack veya Microsoft Teams, bir iç araç veya mevcut bir ticket sistemi. Kimlik ve izinlerin her yerde olduğu gibi aynı yerden gelmesi için mevcut SSO'nuzu kullanın.
• İnsana devir ve geri bildirim. Asistan yardım edemediğinde kullanıcının bir kişiye nasıl ulaşacağını, konuşmanın da aktarılmasıyla birlikte tanımlayın. Basit geri bildirim düğmeleri ekleyin ve olumsuz geri bildirimi değerlendirme setine yönlendirin.
• Maliyet modeli ve izleme. Beklenen ve en yüksek kullanımda sorgu başına ve aylık maliyeti tahmin edin ve bütçe alarmları kurun. Bölüm 3'te kararlaştırıldığı gibi maskelenmiş log'larla gecikmeyi, hata oranlarını, reddetme oranlarını ve kullanıcı geri bildirimini izleyin.
• Yeniden indeksleme, içerik sahipliği ve olaylar. Kaynak belgeler değiştiğinde — silmeler dahil — yeniden indekslemeyi otomatikleştirin, böylece asistan asla geri çekilmiş içeriği aktarmaz. İçerik sorunlarını kimin düzelteceğini belirleyin ve yanlış, zararlı veya sızan yanıtlar için bir olay süreci tanımlayın; asistanı hızlıca kapatmanın yolu dahil.

8. Go/no-go kriterleri#

Karar iyi bir demonun gücüyle verilmesin diye sonuçlar gelmeden karar kurallarında anlaşın.

• Önceden kararlaştırılan eşikler. Eval setinde yanıt doğruluğu ve citation doğruluğu için asgari seviyeleri, kabul edilebilir gecikme ve sorgu başına maliyeti ve izin sınırlarını aşan yanıtlar için sıfır toleransı yazın. Sonuçları bölüm 1'deki referans çizgisiyle karşılaştırın.
• Net çıkışlı, süre sınırlı pilot. Küçük bir gerçek kullanıcı grubuyla sabit bir süre için pilot yürütün; kararı veren isimli bir kişiyle. Kapsamı daraltmak veya durdurmak meşru bir sonuçtur ve tam bir yayılımdan sonra öğrenmekten çok daha ucuzdur.

Size nasıl yardımcı olabiliriz#

Bu kontrol listesini bizimle birlikte işlemek isterseniz en doğrudan yol, sabit kapsamlı AI Proof-of-Value Sprint'imizdir. İki haftada kullanım senaryosunu sizinle kapsamlandırır, kendi verileriniz üzerinde bir RAG veya agent prototipi kurar, bir değerlendirme seti oluşturur, bir maliyet modeli hazırlar ve karar vericilerinize götürebileceğiniz bir go/no-go raporu teslim ederiz. Ayrıntılar fiyatlandırma sayfamızda ve AI & Automation hizmetlerimizde bulunur.

Belgelerinizin herhangi biri bir modele ulaşmadan önce verilerin nasıl ele alındığı konusunda sizinle anlaşırız; AI projelerinde müşteri verilerini nasıl ele aldığımızı önceden okuyabilirsiniz. Önce bir sohbetle başlamayı tercih ederseniz ücretsiz bir tahmin isteyin ve aklınızdaki kullanım senaryosunu anlatın.