Bir Sohbet Arkadaşının Üç Biçimi 

Her sohbet arkadaşı uygulaması aynı türden bir konuşma yürütmüyor ve üç gerçek biçim farklı mimariler istiyor. 

Mindio doğrudan bir sohbet arkadaşı: kullanıcı uygulamayı açıyor ve bir insanla konuşurmuş gibi onunla konuşuyor, Mindio da empatiyle yanıt verip zamanla ruh halini takip ediyor. Lina koçluk yapan bir pratik arkadaşı; açık uçlu duygusal bir sohbet yerine ses girişi ve telaffuz geri bildirimiyle İngilizce konuşma pratiği için kuruldu. Rizz Plug ikisinden de farklı. Kullanıcıyla hiç konuşmuyor. Bunun yerine kullanıcının başka biriyle olan kendi konuşmasından bir ekran görüntüsü veya yapıştırılmış mesaj okuyor ve ne söyleyeceğini öneriyor. Bu üçüncü biçim tamamen farklı bir veri modeli istiyor, çünkü sürdürülecek süregelen bir arkadaş ilişkisi yok, sadece tek bir gelen mesaj ve önerilen bir yanıt var. 

Doğru biçimi erken seçmek, yanlış türde bir hafıza sistemi kurmayı önlüyor: 

• Ürünün değeri süregelen ilişkinin kendisiyse doğrudan bir sohbet arkadaşı seçin ve erkenden ton tutarlılığına ve güvenlik tasarımına yatırım yapın 

• Hedef belirli bir beceriyse koçluk yapan bir pratik arkadaşı seçin, çünkü Lina'nın konuşma pratiği gibi daha dar bir kapsam açık uçlu bir arkadaştan daha hızlı lansmana çıkar 

• Ürün başka bir yerde geçen konuşmalara yardımcı oluyorsa bir yanıt asistanı seçin, çünkü bu süregelen bir hafıza değil sadece güçlü tek mesaj bağlamı istiyor 

Bu biçimler teknik olarak birleştirilebilir, ama ilk sürümde nadiren birleştirilmeli. Aynı zamanda koçluk yapan ve aynı zamanda dış konuşmalar için yanıt taslağı hazırlayan bir arkadaş, aslında tek bir sohbet penceresini paylaşan üç üründür. Her biri lansmandan önce kendi test turunu gerektirir. 

İlk Sürümün Kapsamını Nasıl Belirlersin 

Çoğu sohbet arkadaşı uygulamasının başarısızlığı modelden değil kişilikteki kapsam büyümesinden kaynaklanıyor. Dar tutulan bir ilk sürüm, özellik listesi küçük bir ekibin test edebileceğinden fazlasına büyümeden önce temel etkileşim döngüsünü kanıtlıyor. 

• Yukarıdaki üç biçimden birini seçip bunları harmanlamaya direnin, çünkü aynı zamanda koç aynı zamanda yanıt asistanı olan bir arkadaş üç farklı ürün gibi test edilir 

• Herhangi bir prompt kurulmadan önce kişilik ve ton sınırlarını yazılı olarak tanımlayın, çünkü tutarsız bir ton kullanıcıların bir modelle konuştuğunu fark etmesinin en hızlı yollarından biri 

• Lansmandan önce endişe verici mesajlar için yönlendirme yolunu tasarlayın, özellikle duygusal desteğe benzeyen her şeyde, böylece uygulama anlık bir tepki değil net ve test edilmiş bir tepki verir 

Sürümde tamamen açık uçlu, her şeyi yapan bir arkadaş teslim etmeye çalışan ekipler genelde bunu yine de daraltıyor. Bu sadece daha sonra, elde gerçek kullanıcı şikayetleriyle oluyor. 

Gerçekçi Bir Geliştirme Takviminin Görünümü 

Bu kategorideki teslim edilen örnekler iki ile dört ay arasında değişiyor ve bu pencereyi dört aşama oluşturuyor. 

• Keşif ve kapsam belirleme, ekibin herhangi bir ekran tasarlanmadan önce arkadaş biçimini, kişilik yönergelerini ve güvenlik veya yönlendirme politikasını kilitlediği aşama 

• Ana geliştirme, takvimdeki en büyük blok, sohbet arayüzünün, model entegrasyonunun ve hafıza veya bağlam sisteminin o kilitli kapsam üzerinde bir araya geldiği aşama 

• Ton ve güvenlik testi, ekibin kendisi için yazdığı kibar test mesajlarına değil, geniş bir gerçek konuşma tarzı yelpazesine karşı yürütülür 

• Lansman ve izleme, canlıdaki ilk birkaç hafta, gerçek kullanıcıların iç testin nadiren tahmin ettiği şekillerde kişiliği ve güvenlik sınırlarını zorladığı dönem 

Ton ve güvenlik testini atlamak, geliştirme sürecinde sıcak ve tutarlı hissettiren bir arkadaşın ekipteki kimsenin onaylamayacağı yanıtlar üretmeye başlamasının en yaygın sebebi. Ekibin yazdığı bir senaryo, gerçek bir kullanıcının sıkıldığında, meraklandığında veya üzüldüğünde gerçekte ne yazdığına nadiren benziyor.