Ses, her yapay zeka ajanı platformunun hızla piyasaya sürmeye çalıştığı bir özellik haline geldi. Yapılan bariz hamle, bunu web uygulamanızın, CLI aracınızın veya Telegram botunuzun yanında duran bağımsız bir kanal olarak inşa etmektir. Bu kulağa sezgisel gelir; sesi görürsünüz ve bir ses arayüzü oluşturursunuz. Ancak bu içgüdü kırılgan bir mimari yaratır. İşleri mükerrer hale getirir, loglarınızı bozar ve proje bağlamınızı (context) yavaş yavaş biçimden çıkarır.
APC ve APX'te biz farklı bir yol seçtik. Ses bir kanal değildir; bir moddur. Bir yüzeyin yerini almak yerine, onun üzerine oturur. Bu ayrımı doğru yapmak, sistemin dağılmasını önleyen şeydir.
Yanlış Soyutlama
Sesi kendi başına bir kanal olarak ele aldığınızda, bir ajana konuşmanın, ona yazmaktan temelden farklı bir konuşma olduğunu örtük olarak varsayarsınız. Mühendislik ekipleri de kod tabanını bölerek buna yanıt verir. Aniden bir CLI kanalı ve ayrı bir sesli-CLI kanalı oluşur. Bir web kanalı ve paralel bir sesli-web kanalı vardır. Her biri kendi istem (prompt) varyasyonlarını, biçimlendirme kurallarını ve bağlam işleme mantığını gerektirir.
Karmaşa işte burada başlar. Bir ajanın davranışındaki küçük bir değişiklik, artık birden fazla istem ağacı boyunca kopyalanmalıdır. Eğer ekip bir yüzeyi unutursa, deneyim parçalanır. Kullanıcılar metin üzerinden bir ton, konuşma üzerinden ise biraz daha farklı bir kişilikle karşılaşır. Zamanla, bu küçük tutarsızlıklar sistem kaymasına (system drift) dönüşür. Taşınabilir bağlam katmanı taşınabilir olmaktan çıkar; çünkü bir dalda sesli sunumu, diğer dalda ise sessiz metni hesaba katmak zorunda kalır. Soyutlama sızar ve bir zamanlar birleşik olan proje tanımınız, kanala özel yamalar koleksiyonuna dönüşerek dağılır.
Bağlamı Çalışma Zamanından (Runtime) Ayırmak
Bunu önlemek için sorumlulukları, kesin olarak ayrı duran iki katman arasında paylaştırıyoruz.
APC, proje bağlamını tutar. Bir projeyi oluşturan ajanları, kuralları ve yetenekleri tanımlar. Bunu sistemin kararlı anlamı olarak düşünebilirsiniz. Yapısal soruları yanıtlar: Bu ajan ne biliyor? Neleri yapmaya izni var? Hangi araçları çağırabilir? APC, bir yanıtın ekranda mı görüntülendiği, bir sohbet API'si üzerinden mi gönderildiği yoksa bir hoparlörden mi verildiği konusunda tamamen bağımsız (agnostic) kalmalıdır.
APX, çalışma zamanı (runtime) katmanını yönetir. Fiilen temas ettiğiniz yüzeyleri yönetir: CLI, web uygulaması, masaüstü arayüzü, Telegram botu. Bir kullanıcı bir istek gönderdiğinde, APX yanıtın nerede ve nasıl sunulacağına karar verir. Bir cevabı okumak için mi biçimlendireceğine yoksa konuşma için mi optimize edeceğine karar vermek bir çalışma zamanı meselesidir. Bu, APC'ye değil, APX'e aittir.
Bu ayrım, APC'de tanımlanan bir projenin, APX kaç tane yüzey sunarsa sunsun bozulmadan kalması anlamına gelir. Sözleşme değişmez; sadece sunum katmanı değişir.
Modlar Aslında Nasıl Çalışır?
Uygulamamızda Telegram, CLI ve web uygulaması gibi yüzeyler birer kanaldır. Bir kanal size etkileşimin nerede gerçekleştiğini söyler. Ses ise kanal meta verisi aracılığıyla bir mod olarak katmanlandırılır. Bir mod, bir yanıtın nasıl davranması gerektiğini söyler.
İstem oluşturucu (prompt builder) bu sınıra saygı duyar. Önce APC'deki proje bağlamından verileri çeker, ardından kanal meta verisini inceler. Eğer masaüstü yüzeyi ses modunda çalışıyorsa, oluşturucu yalnızca o anda hedeflenmiş talimatlar ekler. Belki modeli daha kısa cümlelere, sentez için daha net noktalama işaretlerine veya konuşma amaçlı sayı geleneklerine yönlendirir. Eğer aynı masaüstü yüzeyi metin modunda çalışıyorsa, bu sesli talimatlar isteme asla girmez.
Sonuç, yüzey başına tek bir istem ağacıdır. Ayrı bir sesli-masaüstü dalı yoktur. Bir "whisper-web" varyantı yoktur. Değiştirici yalnızca çalışma zamanı talep ettiğinde ve yalnızca son sorumlu anda uygulanır. Çekirdek istem sabit kalır.
Ne Kazanırsınız?
Bu mimari üç somut şekilde meyvelerini verir.
Daha düşük bakım maliyetleri. Eğer ses kendi başına bir kanal olsaydı, her yüzeyin bir ikizine ihtiyaç duyardı. Bir CLI kanalı ve bir sesli-CLI kanalı, bir Telegram kanalı ve bir sesli-Telegram kanalı vb. yönetmek zorunda kalırdınız. Her sistem istemini ayarladığınızda, bir biçimlendirme hatasını düzelttiğinizde veya bir yetenek açıklamasını geliştirdiğinizde, bu değişikliği her iki ağaca da yaymanız gerekirdi. Birini atlarsanız, kullanıcılar farkı hemen anlar. Bir mod kullanarak, yüzey başına tek bir istem ağacı tutarsınız. Ses, bir yol ayrımı yerine koşullu bir katman haline gelir; böylece etkileşim için yeni yollar ekledikçe iş yükünüz doğrusal kalır.
Doğru günlükleme. Kanallar bir etkileşimin nerede gerçekleştiğini kaydeder. Modlar ise yanıtın nasıl iletildiğini kaydeder. Bir masaüstü etkileşimi, kullanıcı onu okusa da duysa da masaüstü etkileşimi olarak kalır. Ekibiniz bir hatayı izlerken veya analitikleri incelerken, "desktop-voice" ile "desktop-text"i sanki farklı ürün yüzeyleriymiş gibi birbiriyle uzlaştırmak zorunda kalmaz. Kanal tanımlayıcısı temiz kalır ve mod bayrağı metadata içinde hemen yanında düzgünce yer alır. Günlükleriniz doğru kalır ve hata ayıklama süreci basit kalır; çünkü konum ve davranış birbirine karışmaz.
Temiz proje bağlamı. APC sözleşmeyi tanımlar. Bir yanıtın konuşulması, fısıldanması veya monospaced yazı tipiyle sunulması APC'yi ilgilendirmemelidir. Bunlar çalışma zamanı (runtime) konularıdır. Ses biçimlendirmesini APX içinde tutarak APC'nin taşınabilirliğini koruyoruz. Bir APC proje tanımını alıp, beraberinde sese özgü biçimlendirme varsayımlarını veya konuşma optimizasyonu kalıntılarını sürüklemeden tamamen yeni bir çalışma zamanı ortamına bırakabilirsiniz. Sınır korunur ve proje anlamı kararlı kalır.
Masaüstündeki Kanıt
Kendi masaüstü akışımız bunu günlük kullanımda kanıtlıyor. Masaüstü yüzeydir. Bir kullanıcı konuşmayı etkinleştirdiğinde, sistem aynı masaüstü yüzeyini ses modunda çalıştırır. Ses, mod katmanında yaşadığı için masaüstü kanalı tüm bağlamını ve davranışını korur. Farklı kuralları olan farklı bir ürüne dönüşmez. Prompt builder sadece bayrağı fark eder ve yalnızca gerektiğinde ses talimatları ekler. Kullanıcı tekrar metne döndüğ
