Uygulama içi asistanlar için OpenAI API vs kendi sunucunuzdaki LLM'ler

Gerçekte ne karar veriyorsunuz: bir uygulama içi asistan eklediğinizde\n\nUygulama içi asistan farklı anlamlara gelebilir. Bazen “Şifremi nasıl sıfırlarım?” diye cevap veren bir destek yardımcısıdır. Bazen doğru kaydı, politikayı veya faturayı bulmaya yarayan bir aramadır. Diğer zamanlarda ise “bir bilet oluştur, Maria'ya ata ve müşteriyi bilgilendir” gibi işlem yapan bir iş akışı yardımcısıdır. Bu işler çok farklıdır ve farklı riskleri beraberinde getirir.\n\nOpenAI API ile kendi sunucunuzdaki LLM'ler arasındaki seçim sadece model kalitesiyle ilgili değildir. Asistanınızın ne görebileceğine, ne kadar hızlı yanıt vermesi gerektiğine ve bir şey gece 2'de bozulduğunda kimin sorumlu olacağına karar veriyorsunuz.\n\nKullanıcılar her gün bir asistana güvenmeye başladığında küçük sorunlar büyük problemlere dönüşür. Asistan yavaşsa insanlar kullanmayı bırakıp manuel işe döner. Yanlış ama kendinden emin bir cevap verirse destek talepleri artar. Özel verileri açığa çıkarırsa artık bir özellik değil, bir olayınız olur.\n\n“Üretim” kuralları değiştirir. Öngörülebilir çalışma süresi, modele gönderilebilecek veriler için net sınırlar ve denetçilere veya güvenlik inceleyicilerine sistemi açıklayabileceğiniz bir yol gerekir. Ayrıca operasyonun temelleri de gereklidir: izleme, uyarılar, geri alma yolları ve asistan yardımcı olamadığında insan yedekleme.\n\nİki yaygın yaklaşım:\n\n- API sunulan model: istemleri sağlayıcının barındırdığı modele gönderirsiniz ve cevap alırsınız. Sağlayıcı altyapıyı çalıştırır ve ölçeklemeyi halleder.\n- Kendi sunucunuzda açık kaynak model: modeli kendi sunucularınızda veya bulut hesabınızda çalıştırırsınız. Dağıtım, performans ve güncellemeleri siz yönetirsiniz.\n\nSomut bir örnek: bir müşteri portalında kullanıcılar “İade neden reddedildi?” diye soruyor olsun. Asistan sadece halka açık bir yardım makalesini özetliyorsa gizlilik riski düşüktür. Dahili notları, ödeme durumunu ve destek geçmişini okursa sıkı sınırlar gerekir. Ayrıca eylem tetikleyebiliyorsa (iade, şifre sıfırlama, hesap kilidi) güçlü izinler, günlükleme ve net bir onay yolu gerekir.\n\nAppMaster gibi araçlar, kimlik doğrulama, veritabanı destekli kayıtlar ve iş akışı mantığı dahil asistan etrafında uygulamayı kurmanıza yardımcı olabilir. Temel karar aynı kalır: hangi tür asistanı inşa ediyorsunuz ve gerçek kullanıcılar için güvenli şekilde çalıştırmak adına ne düzeyde güvenilirlik ve kontrole ihtiyacınız var?\n\n## Gizlilik sınırları: sisteminizden hangi veriler ne zaman çıkıyor\n\nGizlilik tek bir düğme değildir. Bir veri akışı haritasıdır: modele ne gönderiyorsunuz, her isteğin etrafında ne saklanıyor ve kim daha sonra erişebiliyor.\n\nAPI modelde bariz veri istemdir. Pratikte istemler genellikle kullanıcının yazdığından daha fazlasını içerir: sohbet geçmişi, bağlam için eklenen hesap detayları, bellekten çekilen belge parçaları ve araçlardan gelen sonuçlar (örneğin “son faturalar” veya “açık destek biletleri”). Dosya yüklemeye izin verirseniz bu dosyalar da isteğin parçası olabilir. Ayrı olarak, kendi loglarınız, analizleriniz ve hata izleriniz istemleri ve çıktıları yakalayabilir, bunu önlemediğiniz sürece.\n\nKendi sunucuda barındırmak sınırı kaydırır. Veriler ağınız içinde kalabilir, bu sıkı uyumluluklarda yardımcı olur. Ama bu otomatik olarak gizli yapmaz. Yine iç erişimi (mühendisler, destek personeli, yükleniciler) kontrol etmeniz, yedeklemeleri güvence altına almanız ve hata ayıklama için ham konuşmaları ne kadar saklayacağınıza karar vermeniz gerekir.\n\nBir yapı seçmeden önce birkaç soruya net cevaplar alın:\n\n- İstek verileri ne kadar süre tutuluyor?\n- Eğitim veya değerlendirme için kullanılıyor mu?\n- Satıcı tarafında veya şirket içinde kim erişebilir?\n- Hangi denetim izleri ve silme seçenekleri var?\n\nEğer herhangi bir cevap belirsizse, en katı durumu varsayın ve ona göre tasarlayın.\n\nDuyarlı alanlar özel işlem gerektirir: isimler, e-postalar, adresler, sipariş geçmişi, dahili politikalar ve ödeme ile ilgili her şey. Basit bir örnek: bir müşteri “Kartım neden reddedildi?” diye sorduğunda asistan, tam kart bilgilerini (ki zaten saklamamalısınız) veya gereksiz kişisel verileri modele göndermeden sonraki adımları açıklayabilir.\n\nHer iki kurulumda da işe yarayan pratik kurallar:\n\n- Cevaplamak için gereken en az bağlamı gönderin.\n- Tanımlayıcıları gizleyin veya değiştirin (mümkünse e-posta yerine kullanıcı ID kullanın).\n- Ham istemleri ve çıktıları genel loglardan varsayılan olarak uzak tutun.\n- Hata ayıklama verileri için kısa saklama süresi ve net silme yolu kullanın.\n- “Asistan hafızasını” gerçek kayıtlardan ayırın, böylece bir sohbet gerçek kayıtları değiştiremesin.\n\nAsistanı AppMaster içinde kurarsanız, veritabanınızı tek doğru kaynak olarak kabul edin. İstemleri tüm kayıtları “her ihtimale karşı” dökmek yerine asistanın gerektiği belirli alanlardan oluşturun.\n\n## Gecikme ve kullanıcı deneyimi: zaman nerede harcanıyor\n\nGecikme bir üründe demo içindekinden farklı hissedilir çünkü kullanıcılar zaten bir akış içindedir. Bir cevap 6 saniye sürüyorsa bu “sadece bekleme” değildir. Bir düğmeye basmakla işin bitmesi arasındaki kırılmış bir adımdır.\n\nOpenAI API ile kendi sunucunuzdaki LLM'ler arasında bekleme genellikle farklı yerlerden gelir. Takas sadece model hızı değil, model çağrısının etrafındaki her şeydir.\n\n### Gizli zaman maliyetleri\n\nAPI modelinde zaman genellikle ağ sıçramaları ve sizin kontrolünüz dışında gerçekleşen işlemlerde kaybolur. Tek bir istek DNS, TLS kurulumu, sağlayıcıya yönlendirme, model çalıştırması ve geri dönüşü içerebilir.\n\nKendi sunucunuzda çıkarım yaparken çoğu internet sıçramasını kaldırabilirsiniz, ama yerel darboğazlar eklersiniz. GPU paylaşımı, disk okuma ve yavaş tokenizasyon beklediğinizden daha fazla önem kazanabilir; özellikle sunucu başka işler de çalıştırıyorsa.\n\nTrafik dalgalarında hikâye değişir. API çağrıları sağlayıcı tarafında kuyruğa girebilirken, kendi sunucunuzda kuyruğa GPU'larınız girer. “Ortalama olarak hızlı” durumunda bile 50 kullanıcı aynı anda soru sorduğunda “ani ve sinir bozucu” olabilir.\n\nSoğuk başlatmalar da üretimde ortaya çıkar. Autoscaling pod'ları, gateway'ler ve yeni yüklenen model ağırlıkları, kullanıcı yardıma ihtiyaç duyduğunda 1 saniyeyi 15 saniyeye çevirebilir.\n\n### Deneyimi koruyan UX taktikleri\n\nModeli değiştirmeden asistanı daha hızlı hissettirebilirsiniz:\n\n- Tokenleri akıtın ki kullanıcılar ilerlemeyi görsün, boş ekran yerine.\n- Kısa bir “çalışılıyor” mesajı gösterin ve kısmi sonuçları (ilk adımlar veya özet gibi) ortaya çıkarın.\n- Net zaman aşımı ayarlayın ve daha basit bir yanıta geri dönün (“İşte en olası 3 seçenek”).\n- Sık yanıtları önbelleğe alın ve tekrar eden aramalar için gömme (embedding) sonuçlarını yeniden kullanın.\n- Yalnızca en alakalı bağlamı göndererek istemleri küçük tutun.\n\nÖrnek: AppMaster'da inşa edilen bir müşteri portalında “Faturam nerede?” asistanı hesabı hemen doğrulayabilir ve veritabanınızdan son 5 faturayı çekebilir. LLM daha uzun sürse bile kullanıcı zaten yararlı veriyi görür ve asistanın nihai mesajı gecikme gibi değil, yardım gibi hissedilir.\n\n## Maliyet tahmini: neyi öngörebilirsiniz, neyi öngöremezsiniz\n\nMaliyet sadece “mesaj başına ne kadar” değildir. Asistanın ne kadar kullanıldığı, her istemin uzunluğu ve asistanın ne yapmasına izin verildiği de önemlidir. OpenAI API ile kendi sunucunuzdaki LLM'ler arasındaki ana fark, maliyetinizin sayaç gibi davranıp davranmaması (API) veya kapasite planlaması gibi davranmasıdır (kendi sunucu).\n\nAPI ile fiyatlama genellikle birkaç sürücüyle ölçeklenir: içeri ve dışarı giden tokenlar (isteminiz, modelin cevabı ve sistem talimatları), seçtiğiniz model katmanı ve ek araç işleri (örneğin fonksiyon çağrıları, retrieval veya token kullanımını arttıran çok adımlı mantık). Pilotlar için işe yarar çünkü küçük başlayıp ölçebilir, sonra ayarlayabilirsiniz. Kullanım patladığında fatura da patlayabilir.\n\nKendi sunucuda barındırma mesaj başına daha ucuz görünebilir, ama ücretsiz değildir. GPU'lar için ödeme yaparsınız (zirveye göre boyutlandırdıysanız boşta bekleyebilirler), depolama, ağ, izleme ve sistemi çalıştıran insanlar için maliyetler vardır. En büyük gizli maliyet risk olacaktır: yoğun bir gün, model çökmesi veya kötü bir dağıtım kesinti ve kaybedilen güvene dönüşebilir.\n\nHer iki kurulumda da maliyeti tahmin etmeyi zorlaştıran şeyler başlangıçta iyi kontrol edemediğiniz davranışlardır: uzun istemler (sohbet geçmişi ve büyük bilgi blokları), zaman aşımından sonra tekrar denemeler ve suistimal. Tek bir kullanıcı devasa bir belge yapıştırabilir veya mantık döngüsü modele birden çok kez çağrı yapabilir. Asistan eylemler alabiliyorsa araç çağrıları hızla çoğalır.\n\nDeneyimi bozmadan harcamayı sınırlama yolları:\n\n- Günlük ve aylık bütçeler belirleyin, uyarılar koyun ve limite ulaşıldığında ne olacağını kararlaştırın.\n- Özellikle ücretsiz katmanlar için kullanıcı ve çalışma alanı başına oran limitleri ekleyin.\n- Cevap uzunluğu (maks token) ve sohbet geçmişi boyutu için sert sınırlar koyun.\n- Yaygın cevapları önbelleğe alın ve eski bağlamı özetleyin ki token sayısı düşsün.\n- Büyük girdileri ve tekrar eden denemeleri engelleyin.\n\nÖrnek: AppMaster ile inşa edilen bir müşteri portalı asistanı kısa “hesap ve fatura” Soru-Cevap ile başlayabilir. Daha sonra bilet aramaya, uzun konuları özetlemeye ve taslak cevaplar hazırlamaya izin verirseniz token kullanımı bir gecede sıçrayabilir. Büyümeyi finans ekibini şaşırtmasın diye sınırlar erkenden planlayın.\n\nFiyat varsayımlarınızı hızlıca test etmek isterseniz küçük bir pilot kurun, görev başına token sayısını takip edin, sonra herkese açmadan önce sınırları sıkın.\n\n## Operasyonel yük: güvenilirlik ve güvenlik kimin sorumluluğu\n\nOpenAI API ile kendi sunucunuzdaki LLM'ler tartışılırken çoğunlukla model kalitesi konuşulur. Üretimde gündelik olarak daha büyük soru şudur: asistanı güvenli, hızlı ve ulaşılabilir tutma işi kimin?\n\nAPI ile ağır işi sağlayıcı yapar. Kendi sunucunuzda barındırma ise ekibinizin sağlayıcı olması demektir. Bu doğru bir seçim olabilir, ama gerçek bir taahhüttür.\n\nOperasyonel yük genelde modelin ve servis yığınının dağıtımı (GPU'lar, ölçekleme, yedeklemeler), güvenilir uyarılara sahip gecikme ve hata izleme, sistem yamalama, anahtar ve kimlik bilgisi rotasyonu ve kesintiler ile kapasite yükselişlerini uygulamayı bozmadan yönetmeyi içerir.\n\nModel güncellemeleri de başka bir değişim kaynağıdır. Kendi sunucunuzda modeller, sürücüler ve çıkarım motorları sık sık değişir. Her değişiklik cevaplarda küçük kaymalara yol açabilir; kullanıcılar “asistan kötüleşti” diye fark eder. API olsa bile yükseltmeler olur, ama GPU sürücüleri veya çekirdek yamalarını siz yönetmiyorsunuz.\n\nKalite kaymasını azaltmanın basit yolu asistanı diğer özellikler gibi test etmektir:\n\n- Gerçek kullanıcı sorularından küçük bir regresyon seti tutun.\n- Güvenlik hatalarını (veri sızdırma, güvensiz tavsiye) kontrol edin.\n- Önemli iş akışları için cevap tutarlılığını takip edin (iadeler, hesap erişimi).\n- Haftalık örnek konuşma incelemesi yapın.\n\nGüvenlik sadece “veri sunucularımızdan çıkmasın” değildir. Aynı zamanda sır yönetimi, erişim günlükleri ve olay müdahalesidir. Birisi model uç nokta anahtarınızı ele geçirirse maliyeti artırabilir veya hassas istemleri çıkarabilir mi? İstemleri redakte ederek güvenli şekilde mi günlüklüyorsunuz?\n\nNöbet (on-call) gerçeği önemlidir. Asistan gece 2'de bozulursa, API yaklaşımı genelde kibarca bozulmayı sağlar ve tekrar dener. Kendi sunucunuzda barındırma ise birinin bir GPU düğümünü, dolu diski veya hatalı dağıtımı düzeltmek için uyanması anlamına gelebilir.\n\nAppMaster gibi bir platformda inşa ediyorsanız, bu görevleri özellik parçası olarak planlayın, sonradan düşünce olmasın. Asistan bir ürün yüzeyidir. Bir sahibi, çalışma prosedürleri ve “bozulduğunda ne oluyor” planı olmalıdır.\n\n## Doğru yaklaşımı seçmek için pratik adım adım yol\n\nÖnce ürününüz içinde asistanın ne yapmasını istediğinizi netleştirin. “Sohbet” bir iş değildir. İşler test edilebilir olmalıdır: dokümanlardan soru cevaplamak, taslak cevap hazırlamak, bilet yönlendirmek veya “şifre sıfırla” gibi durumda işlem yapmak. Asistanın veriyi değiştirme yeteneği arttıkça kontrol ve denetim ihtiyacı artar.\n\nSonra gizlilik sınırınızı çizin. Asistanın görebileceği verilerin bir listesini yapın (mesajlar, hesap detayları, dosyalar, loglar) ve her öğeyi düşük, orta veya yüksek hassasiyet olarak etiketleyin. Yüksek genellikle düzenlemeye tabi veriler, sırlar veya açığa çıkması acı verici olan şeylerdir. Bu adım genellikle barındırılan bir API'nin kabul edilebilir olup olmadığını, sıkı redaksiyon gerekip gerekmediğini veya bazı iş yüklerinin kendi sunucunuzda kalması gerekip gerekmediğini belirler.\n\nArdından ölçülebilir hedefler koyun. Sayısız veri olmadan seçenekleri adil karşılaştıramazsınız. Yazın:\n\n1. Tipik bir cevap için p95 gecikme hedefi (ve eylem alan iş akışları için ayrı hedef).\n2. Aylık harcama limiti ve nelerin buna dahil olduğu (tokenlar, GPU'lar, depolama, destek zamanı).\n3. Kullanılabilirlik beklentileri ve model kapalıyken ne olacağı.\n4. Güvenlik gereksinimleri (engellenen konular, günlükleme, insan incelemesi).\n\nBu kısıtlarla risk toleransınıza uygun bir mimari seçin. Barındırılan bir API genellikle kabul edilebilir kaliteye en hızlı şekilde ulaşır ve operasyonel işi düşük tutar. Kendi sunucunuzda barındırma, verilerin ortamınızdan çıkmaması gerektiğinde veya güncellemeler ve davranış üzerinde daha sıkı kontrol istediğinizde mantıklı olabilir. Birçok ekip hibrit bir yol seçer: çoğu sorgu için bir birincil model ve gecikme, kota veya hassas veri tespitinde devreye giren bir yedek yol.\n\nSon olarak gerçek trafikle küçük bir pilot çalıştırın, demo istemleriyle değil. Örneğin “bir destek biletini özetle ve yanıt öner” gibi tek bir iş akışına izin verin ve bir hafta çalıştırın. p95 gecikmeyi, çözülmüş bilet başına maliyeti ve düzenleme gerektiren cevap yüzdesini ölçün. AppMaster gibi bir platformda pilotı dar tutun: bir ekran, bir veri kaynağı, net loglar ve kolay bir kill switch.\n\n## Takımların yaptığı yaygın hatalar (ve nasıl kaçınılır)\n\nÇoğu ekip bu seçimi saf bir sağlayıcı kararı gibi ele alır: OpenAI API mi yoksa kendi sunucuda LLM mi. Çoğu üretim sorunu, model kalitesine odaklanırken gözden kaçan temel konulardan kaynaklanır.\n\n### Hata 1: Kendi sunucuda barındırmak otomatik olarak özel yapar diye düşünmek\n\nAçık kaynak bir modeli kendi sunucunuzda çalıştırmak yardımcı olur ama verileri sihirli şekilde güvenli yapmaz. İstemler uygulama loglarına, izleme araçlarına, hata raporlarına ve veritabanı yedeklerine karışabilir. “Geçici” hata ayıklama çıktıları kalıcı hale gelebilir.\n\nBundan kaçınmak için izin verilen istem içeriği, istemlerin nerede saklanacağı (varsa) ve ne kadar süre yaşadığı hakkında net bir veri politikası belirleyin.\n\n### Hata 2: Ham müşteri verilerini istemlere göndermek\n\nTam biletleri, e-postaları veya profilleri isteme geçirmek “daha iyi çalıştığı” için yaygındır. Aynı zamanda telefon numaralarını, adresleri veya ödeme ayrıntılarını sızdırmanın en kolay yoludur. Önce redakte edin ve sadece gerçekten gerekeni gönderin.\n\nBasit bir kural: döküman yerine özet gönderin. Tam bir destek sohbetini yapıştırmak yerine son müşteri sorusunu, ilgili sipariş ID'sini ve kısa bir durum notunu çıkarın.\n\n### Hata 3: Suistimal ve sürpriz faturalar için plan olmaması\n\nAsistan kullanıcılara açıldığında birinin prompt injection, spam veya tekrar eden pahalı istekler deneyebileceğini varsayın. Bu hem güvenlik hem maliyet etkiler.\n\nAltyapı gerektirmeden işe yarayan pratik savunmalar:\n\n- Asistanı kimlik doğrulamanın arkasına koyun ve oran limitleri uygulayın.\n- Araç eylemlerini (örneğin “iade et” veya “hesabı sil”) açık, günlüklenen iş akışlarına bağlayın.\n- Giriş uzunluğu sınırları ve zaman aşımı koyun.\n- Kullanıcı ve çalışma alanı bazında kullanım izleyin, sadece toplam tokenlara bakmayın.\n- Şüpheli sinyaller görünce “güvenli mod” fallback cevabı verin.\n\n### Hata 4: Değerlendirme olmadan yayına alma\n\nEkipler genellikle birkaç manuel sohbetle yetinir ve işi bitmiş sanır. Sonra model güncellemesi, prompt değişikliği veya yeni ürün metni ana akışları bozar.\n\nKüçük bir test seti tutun: “şifre sıfırla”, “faturayı bul”, “plan limitlerini açıkla”, “insana yönlendir”. Her sürümde çalıştırın ve basit geçme/kalma sonuçları takip edin. 30–50 örnek çoğu regresyonu yakalar.\n\n### Hata 5: Çok erken aşamada aşırı mühendislik yapmak\n\nGPU almak, orkestrasyon eklemek ve modelleri ayarlamak kullanıcı ne istediğini bilmeden önce pahalıdır. Değer kanıtlamadan önce en küçük şeyi yapın, sonra güçlendirin.\n\nAppMaster ile uygulama geliştiriyorsanız, iyi bir erken desen asistan mantığını kontrollü bir iş sürecinde tutmaktır: girdileri temizle, yalnızca gerekli alanları getir ve kararları günlükle. Bu ölçeklenmeden önce koruyucu çerçeve sağlar.\n\n## Üretime göndermeden önce hızlı kontrol listesi\n\nAsistanı gerçek kullanıcılara sunmadan önce onu diğer üretim özellikleri gibi ele alın: sınırlarını tanımlayın, ölçün ve bozulmaya hazırlıklı olun. Bu, OpenAI API mi yoksa kendi sunucunuzdaki LLM mi seçtiğinizde fark etmez; zayıf noktalar uygulamada benzer görünür.\n\nVeri kurallarıyla başlayın. Modele tam olarak hangi alanların gösterilebileceğini yazın, umut ettiğiniz değil. “Sadece konu + son 3 mesaj” gibi net bir politika belirsiz rehberden iyidir.\n\nPratik ön-gönderme kontrol listesi:\n\n- Veri: İzin verilen alanları listeleyin (ve yasaklı olanları). Parolalar, tam ödeme detayları, erişim tokenları ve tam adresler gibi sırları maskleyin veya kaldırın. İstemlerin ve cevapların ne kadar süre saklanacağını ve kimlerin görebileceğini kararlaştırın.\n- Performans: Tipik kısa bir cevap için p95 gecikme hedefi belirleyin (örneğin 3 saniyenin altında). Sert bir zaman aşımı tanımlayın ve kullanıcıyı ilerletecek bir fallback mesajı belirleyin.\n- Maliyet: Kullanıcı başına limitler (dakika ve günlük), ani sıçramalar için anomali uyarıları ve faturayı şaşırtmayacak güvenli bir aylık üst sınır koyun.\n- Kalite: Küçük bir değerlendirme seti (20–50 gerçek soru) oluşturun ve “iyi”nin ne olduğunu tanımlayın. Prompt değişiklikleri ve model geçişleri için hafif bir inceleme süreci ekleyin.\n- Operasyon: Başarı oranı, gecikme ve istek başına maliyeti izleyin. Hataları özel verileri açığa çıkarmadan debug etmek için yeterli bağlamla günlükleyin. Bir olay sahibi atayın ve nöbet yolu belirleyin.\n\nPerformans genellikle insanların unuttuğu yerlerde kaybolur: yavaş sorgular, çok büyük bağlam veya üst üste binen tekrar denemeler. Asistan zamanında cevap veremezse bunu açıkça söylemeli ve bir sonraki en iyi eylemi sunmalıdır (örneğin bir arama sorgusu önermek veya desteğe yönlendirmek).\n\nSomut örnek: müşteri portalında asistan sipariş durumunu ve yardım makalalarını okuyabilsin ama ham ödeme alanlarına erişimi engelleyin. AppMaster gibi kod gerektirmeyen bir araçla portalı inşa ediyorsanız, aynı kuralları veri modellerinizde ve iş mantığınızda uygulayın ki asistan yaratıcı istemlerle bu kuralları atlamasın.\n\n## Örnek senaryo: gerçek kısıtları olan bir müşteri portalı asistanı\n\nOrta ölçekli bir perakendeci müşteri portalı içine bir asistan istiyor. Müşteriler “Siparişim nerede?”, “Teslimat adresini değiştirebilir miyim?” ve iadeler ile garanti hakkında temel SSS soruları soruyor. Asistan hızlı olmalı ve kişisel verileri sızdırmamalı.\n\nAsistanın faydalı olması için sadece küçük bir veri dilimi gerekir: bir sipariş ID'si, güncel gönderi durumu (hazırlandı, sevk edildi, dağıtıma çıktı, teslim edildi) ve birkaç zaman damgası. Tam adreslere, ödeme detaylarına, müşteri mesajlarına veya iç notlara ihtiyacı yok.\n\nPratik bir kural iki veri kovası tanımlamaktır:\n\n- İzin verilen: sipariş ID, durum kodu, kargo firması adı, tahmini teslim tarihi, iade politikası metni\n- Asla gönderilmeyecek: tam isim, açık sokak adresi, e-posta, telefon, ödeme bilgileri, iç temsilci notları\n\n### Seçenek A: Hızlı lansman için OpenAI API\n\nHız için OpenAI API'yi seçerseniz modeli bir veri tabanı katmanı gibi değil yazma katmanı gibi kullanın. Gerçekleri sisteminizde tutun ve sadece minimal, redakte edilmiş bağlam gönderin.\n\nÖrneğin backend'iniz veritabanından sipariş durumunu çekip modele şöyle gönderebilir: “Sipariş 74192 Sevk edildi. ETA: 31 Oca. Dostça bir güncelleme verin ve teslimat gecikirse sonraki adımları önerin.” Bu ham müşteri kayıtlarını göndermekten kaçınır.\n\nBurada korunma önemli: istemleri redakte edin, prompt injection denemelerini engelleyin (“önceki talimatları yok say” gibi) ve gönderdiğiniz içeriği denetim için kaydedin. Ayrıca net bir fallback isteyin: model yavaş veya belirsizse normal durum sayfasını gösterin.\n\n### Seçenek B: Daha sıkı sınırlar için kendi sunucunuzda barındırma\n\nGizlilik çizginiz “müşteri verileri ağımızdan hiç çıkmasın” ise kendi sunucunuzu barındırmak daha uygun olabilir. Ancak bu asistanı sizin sağlayıcınız haline getirir: GPU'lar, ölçekleme, izleme, yamalar ve nöbet planı sizde olur.\n\nGerçekçi bir plan personel süresi (model sunucusundan sorumlu biri), en az bir GPU makinesi bütçesi ve yük testleri içerir. Model uygulamanıza yakınsa gecikme iyi olabilir, ama sadece donanımı peak trafik için uygun boyutlandırırsanız.\n\n### Sıklıkla işe yarayan basit bir hibrit\n\nKimlik doğrulama ve sipariş durumu doğrulama gibi hassas adımlar için kendi sunucunuzdaki modeli (veya kuralları) kullanın, sonra kişisel veri içermeyen yazım ve SSS yanıtları için bir API modelini kullanın. AppMaster ile portalı inşa ederseniz, veri erişimi ve iş kurallarını backend'de tutar, “cevap yazarı”nı daha sonra tüm portali yeniden yazmadan değiştirebilirsiniz.\n\n## Sonraki adımlar: karar verin, pilot yapın ve aşırı taahhütte bulunmayın\n\nÜretim bir asistan tek seferlik bir karar değildir. Özelliği yeniden gözden geçirebileceğiniz bir yapı gibi ele alın: model seçimi, istemler, araçlar ve gizlilik sınırları gerçek kullanıcılar geldikçe değişir.\n\nBaşlangıç olarak açık bir değeri ve sınırları olan tek bir akışla başlayın. “Son faturamı bul ve masrafları açıkla” gibi bir iş, “hesabı hakkında her şeye cevap ver” demekten daha ölçülebilir ve güvenlidir. Üründe asistanın bugün zamanı ne kadar kazandırdığını belirleyin ve “daha iyi”nin ne olduğunu tanımlayın.\n\n### 1–2 haftada çalıştırabileceğiniz basit pilot planı\n\nKuralları önce yazın, sonra inşa edin:\n\n- Bir yüksek değerli görev ve bir kullanıcı grubu seçin (örneğin sadece yöneticiler).\n- Başarı metriklerini belirleyin (görev tamamlama oranı, zaman tasarrufu, insana devredilme oranı, kullanıcı memnuniyeti).\n- Basit bir veri politikası yazın: asistan ne görebilir, ne asla göremez, saklama limitleri ve denetim gereksinimleri.\n- Sadece onaylı kaynaklardan okuyan ince bir sürüm oluşturun (dokümanlar, sınırlı hesap alanları) ve her cevabı kaydedin.\n- Kısa bir pilot çalıştırın, hataları inceleyin, sonra genişletmeye, yaklaşımı değiştirmeye veya durdurmaya karar verin.\n\nPolitikalar sağlayıcı seçiminizden daha çok önemlidir. Politikada “ham müşteri mesajları sistemimizden çıkamaz” yazıyorsa bu sizi kendi sunucunuza veya yoğun redaksiyona iter. Politika sınırlı bağlam göndermeye izin veriyorsa bir API hızlı doğrulama için iyi bir yol olabilir.\n\n### Baştan değişime hazırlıklı olun\n\nBir modelle başlasanız bile modeli değiştireceğinizi, istemleri güncelleyeceğinizi ve retrieval/tuning yapacağınızı varsayın. Küçük bir regresyon seti tutun: 30–50 anonimleştirilmiş gerçek soru ve kabul edilebilir cevap örnekleri. Prompt, araç veya model değiştiğinde bunu tekrar çalıştırın ve kendinden emin ama yanlış cevaplar gibi yeni hatalara dikkat edin.\n\nAsistan gerçek bir ürün özelliği olacaksa (sadece bir sohbet kutusu değil) tüm yolu planlayın: arka uç kontrolleri, UI durumları ve mobil davranış. AppMaster (appmaster.io) arka uç mantığını, web UI'sini ve yerel mobil ekranları birlikte inşa etmenize yardımcı olabilir; böylece veriye erişim kurallarını tek yerde tutup hızlıca yineleyebilirsiniz. Hazır olduğunuzda buluta dağıtabilir veya kaynak kodu dışa aktarabilirsiniz.