1. Üç güncelleme, üç mühendislik katmanı
Google; Computer Use'un Interactions ve GenerateContent API'lerinde 30 Ekim'de genel kullanıma açıldığını, gemini-api CLI betasının 27 Ekim'de yayınlandığını ve istek depolama varsayılanının 26 Ekim'de değiştiğini belirtiyor. Bunlar sırasıyla eylem arayüzünü, çağrı yöntemini ve veri yaşam döngüsünü etkiliyor. Gemini API güncellemeleri, Gemini uygulamasının veya Vertex AI'ın aynı anda değiştiğini kanıtlamaz. Resmî sürüm notları.
Yorumumuz şu: model yeteneklerini karşılaştırmadan önce işin nerede çalışacağını, yan etkileri kimin yürüteceğini ve yarım kalan görevlerin nasıl kurtarılacağını seçin. Aksi halde etkileyici bir gösterim, eksik yürütme sözleşmesini gizleyebilir.
2. Önerilen işlemleri doğrulanmış sonuçlardan ayırın
Computer Use; ekran görüntüsü, işlem çağrısı, istemci yürütmesi ve güncellenmiş ekran döngüsünü izliyor. Onay isteyen bir safety_decision, ilgili onay bildirimi geri gönderilmeden önce işlenmeli. Yürütme ve onay belgeleri.
Görev kimliğini, işlem kimliğini, önceki ve sonraki durumu ve kabul koşulunu kaydetmenizi öneriyoruz. “Taslak kaydet” için taslak kaydını veya beklenen sayfa durumunu doğrulayın. Başarılı tıklama yalnızca ara olaydır. İşlem açıklaması hata ayıklamaya yardımcı olur, fakat amaçlanan değişikliğin gerçekleştiğini kanıtlamaz. Her gezinmeden sonra mevcut hedefi de kontrol edin.
3. CLI'yi açık bir işlem hattı adımı olarak kullanın
gemini-api, etkileşimli @google/gemini-cli'dan farklı, durumsuz bir API istemcisidir. Belgeleri şema incelemesini, çevrimdışı kuru denemeleri ve açık interaction kimliklerini açıklıyor; beta sürümlerini sabitlemeyi öneriyor. CLI kılavuzu.
Girdi referanslarını, çıktı yollarını ve iş kimliklerini terminal oturumu dışında kalıcı tutun. Yeniden başlayan zamanlayıcı böylece eski metni ayrıştırmak yerine bilinen durumdan devam edebilir. Çevrimdışı doğrulamayı, kimlik doğrulamayı, kotayı ve gerçek yürütmeyi ayrı kontroller olarak ele alın. Kuru denemenin geçmesi yalnızca isteğin o çevrimdışı kontrolden geçtiğini gösterir.
4. Yerel durumsuzluk, uzak depolamayı açıklamaz
26 Ekim'den itibaren oluşturulan ücretli katman projelerinde Generate Content istekleri varsayılan olarak saklanıyor; eski projeler ayarlarını koruyor. İstek düzeyindeki store, proje varsayılanını geçersiz kılıyor. Interactions depolaması sunucu tarafındaki geçmişi de etkiliyor. Günlükler ve veri kümeleri.
Yerel iş kayıtları, uzak istek günlükleri, yüklenen dosyalar ve iş denetim verileri için ayrı yapılandırma kayıtları tutun. İstekler saklanmıyorsa uygulamanın sonraki bağlamı nasıl sağlayacağını belirleyin. SDK'nızın ayarı kabul ettiğini ve gerçek isteğin bu ayarı taşıdığını sentetik verilerle kontrol edin. Yerel çalıştırılabilir dosyanın etiketi, tüm işlem hattının saklama davranışını ortaya koyamaz.
5. Açık ağırlıklar dağıtım denetimini değiştiriyor
Mistral, geliştirilmiş Large 4 ağırlıklarını 29 Ekim'de yayınladı. Değiştirilmiş MIT lisansı, Model-as-a-Service işletmeleri için ayrı ticari lisans gerektiriyor. Yayın duyurusu. Model kartında 1.05T toplam parametre, 52B etkin parametre ve 1M bağlam listeleniyor; Public Preview etiketi korunuyor. Model kartı.
Dağıtım denetimi, kullanıcı arayüzü işlem arayüzünden farklı bir sorunu çözer. Kendi sunucunuzda çalıştırmak yine uygulama izinleri, uyarlayıcılar ve kabul kontrolleri gerektirir. Donanımı yalnızca etkin parametre sayısından tahmin etmek yerine ağırlık belleğini, bağlam önbelleği talebini, eşzamanlılığı ve işletim maliyetini ölçün. Sağlayıcı sıralama iddiaları, iş yükü değerlendirmesinin yerini tutamaz.
6. Denetim yüzeyine göre seçim yapın
| Gereksinim | Aday yol | Kabul kanıtı |
|---|---|---|
| Web arayüzlerinde çalışmak | Computer Use ve istemci yürütücüsü | Hedef, onay ve oluşan durum |
| Betiklerden veya CI'dan iş devretmek | Sabitlenmiş gemini-api sürümü | Çıkış durumu, dosyalar ve sürdürülebilir işler |
| Kalıcı bir hizmete entegrasyon | SDK ve uygulama durumu | Zaman aşımları, depolama politikası ve telemetri |
| Çıkarım dağıtımını denetlemek | Açık ağırlıklar ve hizmet altyapısı | Lisans, kapasite, geri alma ve toplam maliyet |
Bu, sağlayıcı garantisi değil; bizim karar çerçevemizdir. Mevcut iş API'leri doğrudan araçlara dönüştürülebilir; ekran yürütmesini arayüz gerektiren adımlara ayırın. Böylece hata sınırları ve doğrulama maliyetleri daha kolay açıklanır.
7. Sistemi aynı görevlerle kabul edin
Sonuçları bağımsız olarak kontrol edilebilen görevler seçin. Girdileri, model sürümlerini ve bütçeleri sabitleyin; mevcut uygulamayı karşılaştırma için koruyun. Değişen sayfa düzenlerini, ağ kesintilerini, reddedilen onayları ve arka plan işi kurtarmayı dahil edin. İşlemin başarılı olduğu ancak yanıtının kaybolduğu durumu test edin: yan etkili işlemi yeniden denemeden önce gerçek durumu inceleyin.
Tam görev başarısını, hatalı yan etkileri, insan müdahalelerini, gecikme dağılımlarını ve kabul edilen görev başına toplam maliyeti kaydedin. Tek gösterim veya token fiyatı bu soruları yanıtlayamaz. Trafiği ancak kontrollü kabulden sonra, bitmemiş işler için kurtarma yolu bırakarak artırın. Bu yazı yöntemi tanımlar; tamamlanmış bir deney bildirmez veya üretimde iyileşme iddia etmez.