EnaGuard
Mimari Karar Karşılaştırma Matrisi
Kurumsal yapay zekâ mimarisinde kararlar çoğu zaman iki seçenek arasında sunulur: büyük model veya küçük model, tek sağlayıcı veya çoklu model, bulut veya kurum içi altyapı. Oysa asıl soru hangi seçeneğin genel olarak daha güçlü olduğu değildir. Asıl soru, hangi seçeneğin belirli bir kullanım senaryosu, veri sınıfı, risk düzeyi ve işletim modeli için daha uygun olduğudur. Her tercih hız, kontrol, maliyet, esneklik, dayanıklılık ve işletim yükü arasında farklı bir denge kurar.
Bu matris, yönetimin teknik seçimi bizzat yapmasından çok, kararın dayandığı varsayımları anlamasına yardımcı olmak için hazırlanmıştır. Her karar fırsat, risk, uygunluk koşulları ve kanıt gereksinimi açısından ele alınır. Böylece "Bu teknolojiyi neden seçtik?" sorusu; "Hangi iş ihtiyacı için seçtik, hangi riski kabul ettik, hangi koşullarda seçimi yeniden ele alacağız ve kararın doğru çalıştığını nasıl kanıtlıyoruz?" sorularına dönüşür.
Matris kurumun tamamı için tek bir tercih üretmek amacıyla kullanılmamalıdır. Aynı kurum, çalışan bilgi asistanında genel amaçlı bulut modeli kullanırken hassas müşteri işlemlerinde kurum içi ve alan odaklı bir modeli tercih edebilir. Bir üretim şirketi, sahadaki düşük gecikmeli işlemler için küçük bir Edge yapay zeka modeli; araştırma ve doküman analizi için daha büyük bir merkezi model kullanabilir. Kararın kalitesi, seçeneğin popülerliğinden çok iş etkisi, veri hassasiyeti, kesinti toleransı, işletim kapasitesi ve doğrulanabilir sonuçlarla uyumuna bağlıdır.
| Mimari karar | Fırsat | Temel risk | Uygunluk koşulları | İstenebilecek kanıt |
|---|---|---|---|---|
| Büyük model veya küçük model | Büyük modeller geniş görev çeşitliliği ve güçlü muhakeme sunar. Küçük modeller daha düşük maliyet, kısa yanıt süresi ve yerel çalışma imkânı sağlar. | Büyük model maliyet ve sağlayıcı bağımlılığını artırabilir. Küçük model karmaşık veya alan dışı görevlerde kalite kaybı yaşayabilir. | Görev karmaşıklığı, gecikme hedefi, veri hassasiyeti, işlem hacmi ve çalışma ortamı açıkça tanımlanmalıdır. | Kullanım senaryosu temelli kalite testi, gecikme ve maliyet karşılaştırması, yük testi ve hata analizi. |
| Tek sağlayıcı veya çoklu model | Tek sağlayıcı entegrasyonu ve işletimi sadeleştirir. Çoklu model yapısı esneklik, fiyat optimizasyonu ve hizmet sürekliliği sağlar. | Tek sağlayıcı yoğun bağımlılık oluşturabilir. Çoklu model yapısı kalite, politika, veri aktarımı ve işletim karmaşıklığını büyütebilir. | Model yönlendirme kuralları, ortak güvenlik politikaları, taşınabilir veri yapısı ve sağlayıcı geçiş süreci bulunmalıdır. | Sağlayıcı envanteri, model yönlendirme politikası, yedek çalışma testi, sözleşme ve veri yerleşimi kayıtları. |
| Bulut veya kurum içi | Bulut hızlı kapasite artışı ve geniş hizmet erişimi sağlar. Kurum içi kurulum daha yüksek veri kontrolü, yerel çalışma ve özel donanım yönetimi sunar. | Bulut veri yerleşimi, maliyet ve sağlayıcı bağımlılığı yaratabilir. Kurum içi kurulum yatırım, uzmanlık, güncelleme ve kapasite yükünü kuruma taşır. | Veri sınıfı, düzenleme, gecikme, bağlantı koşulları, ölçek ihtiyacı ve kurumun işletim kapasitesi birlikte değerlendirilmelidir. | Veri akış şeması, kapasite planı, toplam sahip olma maliyeti, kesinti testi, güncelleme ve yama kayıtları. |
| Genel amaçlı RAG veya alan bazlı RAG | Genel yapı ortak bilgi erişimi ve hızlı yayılım sağlar. Alan bazlı yapı daha yüksek bağlam doğruluğu ve sıkı erişim kontrolü sunabilir. | Genel havuzlarda yetki aşımı ve yanlış kaynak riski artabilir. Alan bazlı yapılar tekrar eden altyapı ve parçalı yönetişim yaratabilir. | Veri sahipliği, kullanıcı rolleri, kaynak güncelliği, erişim modeli ve cevap kalitesi ölçülebilmelidir. | Retrieval testleri, kaynak doğruluğu ölçümleri, erişim senaryoları, indeks güncelleme ve silme kayıtları. |
| Merkezi platform veya dağıtık ekip modeli | Merkezi platform ortak standart, maliyet görünürlüğü ve tekrar kullanılabilir yetenekler sağlar. Dağıtık model iş birimlerine hız ve alan esnekliği kazandırır. | Aşırı merkezileşme darboğaz yaratabilir. Kontrolsüz dağıtım teknoloji çoğalması, gölge yapay zeka ve standart farklılığı oluşturabilir. | Merkezi minimum standartlarla yerel karar alanları açıkça ayrılmalı; istisna ve onay süreçleri tanımlanmalıdır. | Platform kullanım oranı, istisna envanteri, proje geçiş süresi, ortak kontrol kapsamı ve ekip sorumluluk matrisi. |
| Tam otonomi veya insan onayı | Otonomi yüksek hız ve ölçek sağlar. İnsan onayı yüksek etkili işlemlerde ek muhakeme ve sorumluluk katmanı oluşturur. | Geniş otonomi kontrolsüz eylem üretebilir. Aşırı onay yükü süreçleri yavaşlatabilir ve onay yorgunluğu yaratabilir. | İşlemler etki, geri alınabilirlik, finansal sınır, müşteri etkisi ve fiziksel sonuç açısından sınıflandırılmalıdır. | İşlem sınıflandırma matrisi, onay kayıtları, ajan yetkileri, ret ve düzeltme oranları, acil durdurma testi. |
| Fine-tuning veya retrieval | Fine-tuning davranış ve alan dilini modele yerleştirebilir. Retrieval güncel kurumsal bilgiyi kaynaklarıyla birlikte kullanmayı kolaylaştırır. | Fine-tuning veri soy ağacı, güncelleme ve unutma sorunları yaratabilir. Retrieval yanlış, eski veya zehirlenmiş kaynağı sisteme taşıyabilir. | İhtiyacın bilgi güncelliği mi, davranış uyarlaması mı olduğu belirlenmeli; veri yaşam döngüsü yönetilebilmelidir. | Karşılaştırmalı evaluation, eğitim verisi kaydı, veri izinleri, kaynak güncellik testi ve model değişiklik raporu. |
| Gerçek zamanlı veya batch inference | Gerçek zamanlı işlem anlık müşteri ve işletim ihtiyacını karşılar. Batch yapı yüksek hacmi daha kontrollü ve ekonomik işleyebilir. | Gerçek zamanlı sistemler gecikme ve erişilebilirliğe duyarlıdır. Batch işlemler eski sonuç, kuyruk büyümesi ve gecikmiş hata farkındalığı yaratabilir. | İş sürecinin bekleme toleransı, veri güncellik ihtiyacı, işlem hacmi ve hata halinde devam biçimi belirlenmelidir. | SLO ve gecikme ölçümleri, kuyruk metrikleri, kapasite testi, tekrar işleme kontrolü ve hata kayıtları. |
| Açık kaynak veya kapalı model | Açık kaynak modeller özelleştirme, yerel çalışma ve daha fazla teknik kontrol sağlar. Kapalı modeller hızlı erişim, yönetilen hizmet ve güçlü genel başarım sunabilir. | Açık kaynak yapıda lisans, güvenlik, yama ve işletim sorumluluğu kuruma geçer. Kapalı modelde şeffaflık ve taşınabilirlik sınırlı kalabilir. | Kurumun teknik yetkinliği, lisans koşulları, veri hassasiyeti, güncelleme kapasitesi ve tedarikçi riski değerlendirilmelidir. | Model kaynağı, lisans incelemesi, yapay zeka bileşen envanteri, güvenlik taraması, sağlayıcı sözleşmesi ve sürüm yönetim kayıtları. |
| Merkezi ajan platformu veya kullanım senaryosu bazlı ajan yapısı | Merkezi platform ortak kimlik, araç kataloğu, gözlemlenebilirlik ve politika uygulaması sağlar. Yerel yapılar kullanım senaryosuna özel hız ve tasarım esnekliği sunar. | Merkezi platform ortak hata ve darboğaz noktası oluşturabilir. Dağıtık ajanlar tutarsız yetki, kayıt tutma ve güvenlik kontrolleri yaratabilir. | Ortak kontrol katmanı, ajan kimlik standardı, araç onay süreci ve yerel geliştirme sınırları tanımlanmalıdır. | Ajan ve araç envanteri, kimlik ayrıştırması, yetki kayıtları, uçtan uca iz, acil durdurma ve kötüye kullanım testleri. |
Matris bir satın alma listesi veya otomatik seçim aracı olarak görülmemelidir. Her satır, belirli bir kullanım senaryosu için ayrı değerlendirilmelidir. Karar kaydında iş ihtiyacı, incelenen alternatifler, kabul edilen riskler, seçimin sahibi, yeniden değerlendirme koşulları ve beklenen başarı ölçütleri bulunmalıdır, böylece mimari tercihler kişisel deneyime veya dönemsel teknoloji eğilimlerine bağlı kalmadan kurumsal hafızaya dönüşür.
Savunulabilir bir mimari karar bir slaytla kurulmaz. Üretimde gösterilir.
Kalite karşılaştırmaları, maliyet verileri, canlı yapılandırmalar, test kayıtları, kesinti senaryoları ve üretim metrikleri: kâğıt üzerindeki mantığın kendisi değil. EnaGuard değerlendirmesinin aradığı kanıt tam olarak budur.