Yanıttan sonra çalışan bellek

Yeni bellek örneğinde Microsoft küçük ama belirleyici bir beklemeye yer veriyor. Eylemciye yürüyüş yapmayı sevdiğini ve yer fıstığına alerjisi olduğunu söyleyen kullanıcı, yeni oturumda yanına hangi öğle yemeğini alması gerektiğini soruyor. Araya memory.flush() çağrısı giriyor: örnek, arka plandaki bilgi çıkarımının bitmesini bekliyor. Bence geliştirici için en öğretici ayrıntı bu. Sohbetin yanıt vermesiyle sonraki oturuma hazır bir belleğin oluşması ayrı tamamlanma anları.[1]

Microsoft, Agent Framework için Azure Cosmos DB destekli kalıcı belleği Python önizlemesi olarak sunuyor. CosmosMemoryContextProvider, model çalışmadan önce gelen iletiyle ilgili anıları bulup bağlama ekliyor; çalışma bitince konuşma turlarını saklıyor. Ardından bellek araç takımı arka planda olguları çıkarıyor, özetler hazırlıyor ve kullanıcı profilini güncelliyor. Eylemcinin bir bellek aracını çağırmaya karar vermesi gerekmiyor. Geliştiricinin her isteğin etrafına ayrı bir arama akışı örmesi de gerekmiyor; bu iş çerçevenin çağrı düzenine bağlanıyor.[1]

Oturum değişince hangi bilgi hazır?

Bu düzen, yanıt yolunu bilgi çıkarımını beklemekten kurtarıyor. Karşılığında uygulamanın, yeni öğrenilen bilginin ne zaman kullanılabilir olduğunu düşünmesi gerekiyor. Microsoft örneğinde bekleme kaldırılıp hemen yeni bir oturum açılırsa, çıkarımın bitiş sırasına bağlı bir boşluk oluşabilir; bu, yayımlanmış bir arıza sonucu değil, gösterilen işlem sırasından çıkan bir olasılık. Oturumlar arasında uzun süre bırakan bir kullanımda çıkarım zaten tamamlanmış olabilir. Hızlı bir görev devrinde ise aynı varsayımı yapmak daha güç.[1]

Belleğin kime ait olduğu da uygulamanın verdiği bir karara bağlı. Örnekte yeni oturumun önceki bilgiyi bulması için aynı user_id kullanılıyor. Microsoft, bu değerin istekte gelen gelişigüzel bir alandan değil, kimliği doğrulanmış kullanıcıdan türetilmesini istiyor; kalıcı kullanıcı kimliği verilmezse bellek oturumla sınırlı kalıyor. Dolayısıyla bir geliştirici hatırlama sorununu incelerken hem çıkarımın tamamlanmasını hem kimlik eşleşmesini kontrol etmeli. Modeli değiştirmek, yanlış kullanıcı kapsamını kendiliğinden düzeltmez.[1]

Hazır bağlantının bıraktığı iş

İş bölümü oldukça açık: Agent Framework eylemci döngüsünü yönetiyor, sağlayıcı bu döngüyü bellek araç takımına bağlıyor, Azure Cosmos DB for NoSQL konuşma turlarını ve türetilen anıları saklıyor. Geri getirme, vektör ve tam metin aramasını birleştirebiliyor. Bu, küçük bir ekip için anlamlı bir başlangıç kolaylığı. Yine de uç noktaları ve kimlik doğrulamayı kurmak gerekiyor; önizleme arayüzleri genel kullanımdan önce değişebilir. Hazır sağlayıcının değeri, bu somut bağlantı işini azaltmasında. Duyuruda, bunun toplam geliştirme süresini ne kadar azalttığını karşılaştırmalı olarak ölçen bir sonuç yok.[1]

Benim başlangıç denemem, örnekteki oturum geçişini uygulamanın kendi akışında sınamak olurdu: aynı doğrulanmış kullanıcıyla, çıkarımın bitmesini bekleyerek ve beklemeden hatırlamayı karşılaştırmak; farklı kullanıcıya aynı bilginin taşınıp taşınmadığına ayrıca bakmak. Bu, yapılmış bir deneme iddiası değil, geliştiriciye önerdiğim dar kapsamlı bir sınama. Bekleme her geçişte gerekliyse uygulamanın yanıt süresi hesabına o süre de girer. Doğru bilgi doğru kullanıcıya zamanında ulaşıyorsa, hazır bellek bağlantısı geliştiricinin dikkatini daha yararlı ürün davranışlarına ayırmasına alan açar.[1]