Konferans programını bir yapay zekâ asistanı için nasıl hazırlamalı

Bir yapay zeka asistanı için konferans programı hazırlama pratik şeması: veri yapısı, bilgi tabanı, yanıt kuralları, insana yükseltme ve başlatmadan önce kontrol.

Yapay zeka asistanı için konferans programı, net bir yapıya, veri sahiplerine ve güncelleme kurallarına sahip doğrulanmış bir bilgi tabanı olarak çalışmalıdır. Okumak için hazırlanmış sıradan, güzel bir belge bu görevi çözmez. Belgede olguları, önerileri ve organizatörün kararlarını ayırmak gerekir. Böylece asistan katılımcıya konuşma saatini bildirebilir, doğru salonu bulabilir, kayıt prosedürünü açıklayabilir ve eksik bilgileri uydurmadan uygun oturumu önerebilir.

Temel kısıtlamayı verileri yüklemeden önce belirliyoruz: yapay zeka asistanı organizatör adına karar vermez. Programı değiştirmez, katılımcının kabulünü onaylamaz, boş yer sözü vermez, geç kalan konuşmacının sahneye çıkmasına izin vermez ve tartışmalı kuralları yorumlamaz. Yanıtları yalnızca doğrulanmış bilgi tabanına dayanır. Soru bu sınırların dışına çıkarsa, bilgiler birbiriyle çelişirse veya durum yetki gerektirirse talep bir insana aktarılır.

Biz Aventura olarak böyle bir asistanı katılımcılarla çalışmanın bir kanalı daha olarak görüyoruz. Asistanın program, kayıt, yönlendirme, salon işleyişi ve etkinlik merkeziyle bağlantılı olması gerekir. Sohbet tek başına zayıf bir veri yapısını düzeltmez. Tablolarda oturum adları farklıysa, e-postada eski saat yazıyorsa ve çalışanlar kuralları farklı şekillerde açıklıyorsa, yapay zeka bu karışıklığı yalnızca daha görünür hale getirir.

Bir konferans planlıyorsanız ve programı, misafir yolculuğunu, dijital hizmetleri ve ekibin çalışmasını baştan birbirine bağlamak istiyorsanız, bizden teklif isteyin. Formatı, oturum sayısını, katılımcı profilini ve asistanın görevlerini netleştireceğiz.

Yapay zeka asistanını kurmadan önce neler hazırlanmalı?

Önce tek bir program, tek tip adlar listesi, onaylanmış bilgi tabanı, yanıt kuralları ve soruların insana aktarılma prosedürü hazırlanmalıdır. Model, arayüz ve iletişim kanalı bundan sonra seçilir. Bu hazırlık olmadan otomasyon yalnızca belgeler arasındaki çelişkilerin yayılmasını hızlandırır. Ekip önce hangi kaynağın ana kaynak sayılacağı ve her bilgi kategorisini kimin onaylayacağı konusunda anlaşmalıdır.

Asgari set beş bölümden oluşur:

1. Sabit oturum kimliklerine sahip yapılandırılmış program.
2. Konuşmacı, salon, hizmet ve katılım kuralları kartları.
3. Organizasyonel sorulara verilen onaylı yanıtların kaydı.
4. Yetki matrisi: asistanın neyi bildireceği ve neyi çalışana aktaracağı.
5. Veri güncelleme ve yanıtları yeniden doğrulama süreci.

Katılımcı görevlerinden başlamak en iyisidir. Bir kişi kayıttan sonra nereye gideceğini anlamak ister. Bir diğeri paralel oturumlar arasında seçim yapar. Üçüncüsü belirli bir uzmanın sunumunu arar. Dördüncüsü dolu bir salona girip giremeyeceğini sorar. İlk üç soru için genellikle onaylı veriler yeterlidir. Dördüncüsü ise gerçek duruma ve sahadaki ekibin yetkilerine bağlıdır.

Kurulumdan önce kullanıcı senaryolarının bir listesini oluştururuz. Her biri için soruyu, gerekli verileri, izin verilen yanıtı ve insana aktarma koşulunu belirleriz. Böyle bir liste, asistanın içine her şeyi yüklememeye yardımcı olur. Asistanın iç bütçeye, konuşmacılarla yazışmalara veya teknik senaryoya ihtiyacı olmayabilir. Ancak güncel salon adları, oturum saatleri, giriş kuralları ve destek hizmeti iletişim bilgileri mutlaka gereklidir.

Asistanın tasarımı, konferans, forum veya seminerin genel hazırlığının bir parçasıdır. Bu yalnızca programla ilgili değildir. Katılımcılara verilen yanıtlar kayıt, mekan planı, salonların kullanılabilirliği, ulaşım, yemek, yayın ve karargah kararlarına bağlıdır.

İlk çalışma toplantısında organizatöre şu soruları sorarız:

1. Asistanı kimler kullanacak: kayıtlı katılımcılar, kayıtsız konuklar, konuşmacılar, ortaklar veya çalışanlar mı?
2. Nerede erişilebilir olacak: web sitesinde, uygulamada, kişisel hesapta veya mesajlaşma uygulamasında mı?
3. Hangi soruları bir çalışanın katılımı olmadan yanıtlamalı?
4. Etkinlik günü hangi bilgiler değişebilir?
5. Her veri kategorisini kim onaylar?
6. Kesin bir yanıt yoksa soru kime aktarılır?
7. Ekip, aktarılan başvuruyu ne kadar hızlı görmeli?
8. Hangi veriler belirli kullanıcı kategorilerine gösterilmemelidir?

Yanıtlara göre asistanın neler yapabileceğini ve nerede bir insana ihtiyaç duyulacağını belirleriz. Bu sınırlar olmadan asistan, güvenilir veri veya izin olmayan soruları yanıtlamaya başlar.

Sorumluluk sınırı: Yapay zekâ bilgi verir, kararı insan verir

Yapay zekâ asistanı doğrulanmış bilgileri bulabilir, karşılaştırabilir ve açıklayabilir. Karar, organizatörde veya atanmış sorumluda kalır. Bu sınırı hemen sistem kurallarına yazıyor ve seçimi modelin takdirine bırakmıyoruz. Kayıt, salon durumu, güvenlik veya çalışma sistemindeki başka bir olgunun doğrulanmasını gerektiren eylemleri ayrıca listeliyoruz.

Eylemleri üç düzeye ayırıyoruz.

İlk iki düzey, bilgi tabanı sınırları içinde otomatikleştirilebilir. Üçüncü düzeyi, arkasında ayrı bir doğrulanmış süreç ve eylemi gerçekleştiren harici bir sistem yoksa asistana devretmiyoruz. Teknik entegrasyon olsa bile karar, metnin serbest yorumuna göre değil, organizatörün kurallarına göre alınmalıdır.

Örneğin asistan, oturum için ön kayıt yapıldığını bildirebilir. Bağlantı güncel ve bu katılımcı için erişilebilirse bağlantıyı gösterebilir. Ancak rezervasyon onayı ve güncel giriş izni verisi yoksa kişinin «kesinlikle salona gireceğini» yazmamalıdır.

Aynı kural program değişikliği için de geçerlidir. Asistan «Konuşmacı gecikiyor» mesajını alabilir. Sunumları kendi başına yeniden düzenlememelidir. Bilgiyi koordinatöre iletir ve onaylanan kararın ardından yeni program sürümünü alır.

Temel kuralı açıkça ifade ediyoruz:

Asistan yalnızca doğrulanmış bilgi tabanına dayanarak yanıt verir. Organizatör adına karar vermez. Veriler yetersizse, kaynaklar çelişiyorsa veya soru kurallardan istisna gerektiriyorsa asistan başvuruyu insana iletir.

Bu kuralın teknik şartnamede, sistem talimatlarında, test senaryolarında ve çalışanlar için bilgi notunda tekrarlanması faydalıdır. Böylece ekip, aracın sahip olmadığı yetkileri ondan beklemez.

Her oturum için hangi veriler gerekli?

Her oturumun ayrı ve yapılandırılmış bir kartı olmalıdır. Bu kartta tanımlayıcı, ad, zaman, yer, katılımcılar, format, hedef kitle, durum ve veri sahibi saklanır. PDF'teki tek bir paragraf, asistanın arama ve karşılaştırma yapması için güvenilir bir temel sunmaz. Kart sayesinde tek bir alan güncellenebilir ve hangi kanalların yeni sürümü alması gerektiği kontrol edilebilir.

Sabit bir tanımlayıcı özellikle önemlidir. Sunum başlığı değişebilir, ancak dahili kodu aynı kalır. Tüm entegrasyonlarda tek bir sabit ID kullanıyoruz. Böylece program, kayıt, navigasyon ve bildirimler aynı oturumun kayıtlarını birbirine bağlar.

Oturum kartı aşağıdaki alanları içerebilir:

"Hedef kitle" alanı reklam metnine dönüşmemelidir. "Daha fazlasını öğrenmek isteyen herkes için" yerine "satış departmanı yöneticileri, şube müdürleri, iş ortağı ağı geliştirme yöneticileri" yazmak daha iyidir. Asistan belirli bir rolü programla eşleştirebilir, ancak boş sözcüklerden ilgi alanlarını tahmin etmemelidir.

Katılım formatını da açıkça tanımlıyoruz. Atölye çalışması dizüstü bilgisayar gerektiriyorsa ve tartışmada sorular yalnızca uygulama üzerinden sorulabiliyorsa, bu koşullar karta dahil edilir. Katılım yalnızca belirli bir gruba açıksa, asistan kuralı bildirir ve öngörülen doğrulama kanalını önerir. Kendi başına istisna yapmaz.

Hibrit program için ayrıca yayın bağlantısını, odanın açılış saatini, erişim kurallarını, kaydın olup olmadığını ve teknik destek kanalını kaydediyoruz. Böyle bir yolun hazırlanması, hibrit etkinlik genel mantığıyla bağlantılıdır: çevrimiçi katılımcı, bağlamsız tek bir bağlantı değil, eksiksiz bir yol almalıdır.

Program, kayıt ve dijital hizmetler hâlâ farklı dosyalarda bulunuyorsa, kurumsal etkinlik organizasyonu bunları tek bir çalışma çerçevesinde toplamaya yardımcı olur. Katılımcılar gelmeden önce veri sahiplerini, güncelleme sürelerini ve yanıtların kontrolünü birbirine bağlıyoruz.

Programın Tek Sözlüğü

Tüm sistemler ve çalışanlar oturumlar, salonlar, roller ve hizmetler için aynı adları kullanmalıdır. Yapay zekâ asistanının, resmi adı kabul edilebilir sorgu varyantlarıyla ilişkilendiren ancak yeni nesneler oluşturmayan bir sözlüğe ihtiyacı vardır. Sözlükte ayrıca eski adlar, belirsiz kısaltmalar ve katılımcıların konuşma sırasında sıkça kullandığı sözcükler de işaretlenir.

Katılımcı "ana salon", "genel kurul", "büyük sahne" veya mekânın eski adını yazabilir. Sözlük, sorgunun anlaşılmasına yardımcı olur. Ancak yanıtta asistan güncel kamuya açık adı kullanır: örneğin "Genel Kurul Salonu".

Sözlüğe şunları ekliyoruz:

1. Salonların resmi adları ve yaygın varyantları.
2. Konuşmacıların tam adları ve kabul edilebilir kısaltmalar.
3. Şirketlerin ve ürünlerin onaylanmış yazımdaki adları.
4. Formatların eşanlamlıları: sunum, konuşma, oturum, panel tartışması.
5. Hizmetlerin iç ve kamuya açık adları.
6. Karıştırılmaması gereken terimler.
7. Güncel karşılığı belirtilerek eski adlar.

Sözlük fark edilmeden anlamı değiştirmemelidir. "Konferansa kayıt" ve "ayrı bir oturuma kayıt" farklı eylemlerdir. "Canlı yayın" ve "konuşma kaydı" da her zaman aynı anlama gelmez. Bunlar tam eşanlamlı olarak birleştirilirse asistan yanlış talimatlar vermeye başlar.

Hassas eşleşmeleri ayrıca işaretliyoruz. Çok oturumlu bir konferansta benzer adlara sahip iki oturum olabilir. Konuşmacıların soyadları aynı olabilir. Mekânın farklı bloklarında aynı salon numaralarına rastlanabilir. Böyle bir durumda asistan ilk bulduğu seçeneği seçmek yerine netleştirici bir soru sormalıdır.

Adları sekiz adımda tek bir biçime getiriyoruz:

1. Program, web sitesi, e-postalar, uygulama ve mekân planındaki tüm adları topluyoruz.
2. Her varlık için tek bir kamuya açık varyant seçiyoruz.
3. Kalıcı bir tanımlayıcı atıyoruz.
4. Kabul edilebilir konuşma dilindeki varyantları ekliyoruz.
5. Eski adları işaretliyoruz.
6. Eşleşmeleri ve belirsiz kısaltmaları kontrol ediyoruz.
7. Sözlüğü program, kayıt ve navigasyon sorumlularına iletiyoruz.
8. Sözlük güncellenmeden yeni kamuya açık adlar oluşturulmasını yasaklıyoruz.

İlk bakışta bu bir editörlük görevi gibi görünür. Pratikte ekibin çalışması ve katılımcıların navigasyonu buna bağlıdır. Web sitesinde "Salon A", uygulamada "Kuzey", navigasyonda ise "Konferans Salonu No. 1" yazıyorsa katılımcının bunların aynı mekân olduğunu tahmin etme yükümlülüğü yoktur.

Programlar, misafir yolculuğu ve çalışma belgelerine dair pratik incelemeleri Aventura'nın Telegram kanalında yayımlıyoruz.

Doğrulanmış bir bilgi tabanı nasıl oluşturulur?

Bilgi tabanı yalnızca sahibi, durumu ve güncelleme tarihi net olan bilgiler içermelidir. Belge klasörünü seçmeden yüklemek yanıtları güvenilir kılmaz: aynı yerde taslak, onaylanmış sürüm ve eski bir e-posta bulunabilir. Asistanı bağlamadan önce ekip kaynakları gözden geçirir, kopyaları siler ve her bilgi türü için öncelik belirler.

Veri kaynağını yanıtın kullanıcı dostu metninden ayırıyoruz. Kaynak bir program satırı, kayıt kuralı veya mekân kartı olabilir. Katılımcı için yanıt daha basit ifade edilir, ancak yeni vaatler eklemez.

Her kayıt için şunları saklamak faydalıdır:

• benzersiz tanımlayıcı;
• soru veya konu;
• doğrulanmış yanıt;
• proje içindeki kaynak;
• bilginin sahibi;
• durum;
• son güncelleme tarihi ve saati;
• yanıtın verilmesine izin verilen hedef kitle;
• geçerlilik süresi;
• sorunun çalışana aktarılma koşulu.

Durumlar açık olmalıdır. Şu çalışma mantığını kullanıyoruz: «taslak», «incelemede», «doğrulandı», «değiştirildi», «geri çekildi». Asistan yalnızca doğrulanmış kayıtları alır. «İncelemede» olan bir belge editöre açık olabilir, ancak kamuya açık yanıtı etkilememelidir.

Basit görünen ancak mevcut duruma bağlı olan sorular özel dikkat gerektirir:

• salonda yer kaldı mı;
• yerinde kayıt yapılabilir mi;
• katılımcı başlangıçtan sonra kabul edilir mi;
• şirket temsilcisi değiştirilebilir mi;
• kapalı oturumun kaydı erişilebilir mi;
• konuşmacının sunumu alınabilir mi;
• transfer değişti mi;
• belgesiz girişe izin veriliyor mu;
• belirli bir materyalin fotoğrafı çekilebilir mi.

Bunlar için sabit bir yanıt yeterli değildir. Ya sorumlu sistemden güncel veriler ya da bir kişiye aktarım gerekir. Asistan salonun gerçek doluluk durumunu görmüyorsa, tahmini gerçek olarak sunmamalıdır.

Bilgi tabanını birkaç katmana ayırmak uygundur.

Konferans çevrimiçi yapılıyorsa, bilgi tabanını gerçek çevrimiçi etkinlik ve yayın akışıyla ilişkilendiririz. Erişim kuralları, açılış saati ve destek iletişimi olmayan bir bağlantı, katılımcının sorusunu nadiren yanıtlar.

Kişisel veriler ve erişilebilirlik lansmandan önce planlanır

Asistana yalnızca beyan edilen senaryolar için gerekli bilgiler aktarılır. Konuşmacının herkese açık kartı, katılımcının kayıt durumu ve kurumsal iletişim bilgisi farklı erişim modlarına sahiptir. İşleme amacını, alanların kapsamını, saklama süresini, yetkili çalışan çevresini ve silme prosedürünü önceden belirliyoruz. Müşteri, somut şemayı kendi avukatı ve kişisel verilerden sorumlu kişisiyle birlikte Federal Law No. 152-FZ'yi, kullanılan altyapıyı ve harici bir yapay zeka hizmetine olası aktarımı dikkate alarak onaylar.

Kişisel telefon numaraları, dahili adresler, seyahat verileri ve özel ihtiyaçlar asistanın genel dizinine girmez. Yanıt için belirli bir katılımcının durumu gerekiyorsa, sistem erişim yetkilerini kontrol etmeli ve yalnızca gerekli sonucu göstermelidir. Diyalog geçmişi de "her ihtimale karşı" süresiz olarak değil, onaylanmış kurallara göre saklanır.

Arayüz klavyeyle ve ekran okuyucu yazılımlarıyla erişilebilir olmalıdır. Hataları ve acil değişiklikleri yalnızca renk veya animasyonla değil, metinle bildiririz. "Salon değişti" durumunun anlaşılır bir etiketi ve ekran okuyucunun seslendirebileceği programatik olarak tanımlanmış bir mesajı olmalıdır. Bu gereksinimler WCAG 2.2 ile uyumludur, ancak mekanın fiziksel erişilebilirlik denetiminin yerini tutmaz.

Yanıt formatı ve asistan için yasaklar

Asistan önce kısa ve doğrulanmış bir yanıt verir, ardından koşulları açıklar ve bir sonraki adımı önerir. Kesin veri yoksa sınırlamayı açıkça bildirir ve soruyu bir çalışana iletir. Bu sıralama, katılımcının gerçeği hızla anlamasına, sınırlarını görmesine ve modelin varsayımını organizatörün kararı sanmamasına yardımcı olur.

Yanıt yapısını şöyle belirliyoruz:

1. Soruya doğrudan yanıt.
2. Doğrulanmış ayrıntılar.
3. Varsa koşul veya sınırlama.
4. Katılımcının sonraki adımı.
5. Karar yetki gerektirdiğinde bir insana aktarım.

Doğru bir yanıt örneği:

"Dağıtık Ekip Yönetimi" oturumu 15:10'da "Neva" salonunda başlayacak. Katılım için önceden kayıt gereklidir. Durumunuzu kişisel hesabınızdan kontrol edebilirsiniz. Kayıt görünmüyorsa soruyu kayıt çalışanına ileteceğim.

Kötü yanıt kendinden emin görünür, ancak doğrulanmamış bir vaat ekler:

Salona gelin, sizi mutlaka alırlar.

İkinci ifadede asistan, giriş ekibi adına karar vermiştir. Boş yerler genellikle olsa bile bu, somut durumu doğrulamaz.

Talimatta asistana şunları yasaklıyoruz:

• mevcut olmayan saat, yer, isim veya kural uydurmak;
• belirlenmiş bir öncelik olmadan çelişkili sürümler arasında seçim yapmak;
• giriş, yer, hediye, ikram veya kayda erişim vaat etmek;
• programı değiştirmek;
• sorumlu sistemin verisi olmadan kaydı doğrulamak;
• kapalı iletişim bilgilerini ve kurumsal belgeleri açıklamak;
• ilgili uzman yerine hukuki, tıbbi veya teknik değerlendirme yapmak;
• varsayımı organizatörün kararı olarak sunmak;
• bir çelişki tespit edildikten sonra kendinden emin yanıta devam etmek;
• iptal edilmiş veya geri çekilmiş verileri bildirmek.

Bilgi sınırı için tek bir ifade de yararlıdır:

Güncel bilgi bankasında doğrulanmış bir yanıtım yok. Soruyu ekip çalışanına ileteceğim.

Bu, boşluğu bir varsayımla doldurma girişiminden daha iyidir. Katılımcı için önemli olan her şeyi bilme görüntüsü değil, doğru yönlendirmedir.

Program güncelleme süreci nasıl kurulur?

Her değişiklik tek bir rotadan geçer: talep, sahibin kararı, kaynağın güncellenmesi, yeni sürümün yayınlanması, bilgi tabanının senkronizasyonu ve yanıtın kontrolü. Sohbetteki bir mesaj program güncellemesi sayılmaz. Onaylanana kadar asistan yürürlükteki sürümü kullanmaya devam eder veya bilgilerin netleştirildiğini dürüstçe bildirir.

Süreci şöyle kuruyoruz:

1. Başlatıcı, önerilen değişikliği ve gerekçesini açıklar.
2. Program sahibi, katılımcılar, konuşmacılar, salonlar ve prodüksiyon üzerindeki etkiyi değerlendirir.
3. Yetkili organizatör kararı verir.
4. Editör ana program sürümünü günceller.
5. Sistem yeni sürüme numara ve yayın zamanı atar.
6. Sorumlu, bilgi tabanındaki ilgili kayıtları günceller.
7. Ekip siteyi, uygulamayı, navigasyonu ve bildirimleri kontrol eder.
8. Kritik bir değişiklik için katılımcılara duyuru yayınlanır.
9. Asistan, değişen oturumla ilgili kontrol sorularını yanıtlar.
10. Önceki sürüm "değiştirildi" durumuna alınır ancak günlükte saklanır.

Değişikliğin bir yürürlük zamanı olmalıdır. Erteleme hâlâ görüşülüyorsa asistan yürürlükteki programı kullanmaya devam eder. Karar onaylanmış ancak yeni sürüm katılımcı kanalına ulaşmamışsa karargâh bu kopukluğu görmeli ve kapatmalıdır.

Her düzeltme için bağımlılıkları değerlendiriyoruz:

• salon değişiyor mu;
• bir sonraki oturumla çakışma oluşuyor mu;
• kayıtlı katılımcılara bildirim gerekli mi;
• yayın bağlantısının güncellenmesi gerekiyor mu;
• navigasyon değişiyor mu;
• tercümanlar ve teknik ekip etkileniyor mu;
• altyazılar, açılış ekranları ve ekranların güncellenmesi gerekiyor mu;
• katılımcı kaydı korunuyor mu;
• erteleme soruları kime iletilecek.

Yalnızca açıklamanın ifadesi değişiyorsa katılımcılara genellikle acil bir bildirim gerekmez. Oturum başka bir binaya taşınıyorsa bilgi tabanındaki tek bir düzeltme yeterli olmaz. Bildirim, navigasyon ve eski güzergâhta görevli personel gerekecektir.

Operasyonel değişikliğin bir geçerlilik süresi olur. "Başlangıç gecikiyor" mesajı oturum bittikten sonra yanıtlarda bırakılamaz. Geçici durumlar için yayın zamanını, beklenen gözden geçirme süresini ve bir sonraki güncellemenin sahibini kaydediyoruz.

Sürümler, öncelikler ve tek doğruluk kaynağı

Programın tek bir ana sürümü olmalı ve her kanalın bu sürümle senkronizasyon sırası net olmalıdır. Yapay zekâ asistanı programı aynı anda sunumdan, e-postadan, tablodan ve sohbet yayınından derlememelidir. Ekip her bilgi için öncelikli kaynağı, sahibini ve son onay zamanını belirler.

Her kategori için ana kaynağı ayrı ayrı belirliyoruz:

Ana kaynak tüm proje için tek bir dosya olmak zorunda değildir. Program takvimden sorumludur, ancak kayıt durumunun fiili durumunu tutmak zorunda değildir. Önemli olan her bilginin tek bir sahibi ve tek bir öncelikli kaynağı olmasıdır.

Program sürümü insan için anlaşılır olmalıdır. Numara, tarih, saat, sürümü yayınlayan kişi ve kısa değişiklik listesini kaydediyoruz. Asistan bir dışa aktarım kullanıyorsa, aynı özellikler orada da korunur. Böylece bir hata durumunda yanıt anında hangi veri kümesinin erişilebilir olduğu tespit edilebilir.

Yalnızca yanıt metni güncellenemez. Oturum ertelenirse önce program kaynağı, ardından ilgili kayıt değiştirilir. Aksi halde asistan doğru yanıt verirken web sitesi eski saati göstermeye devam eder.

Konferansın teknik kısmında da aynı yaklaşımı uyguluyoruz. Sunumların, videoların ve sinyallerin onaylanmış sürümleri olmalıdır. Gerekli ekipman program ve içerik gereksinimlerine göre seçilir; sesle ilgili ayrı görevler ses ekipmanı projesiyle ilişkilendirilir, "mikrofon olacak" gibi genel bir ifadeyle çözülmez.

Hangi sorular bir kişiye iletilmelidir?

Bir kişiye onaylanmış yanıtı olmayan sorular, istisna talepleri, verilerdeki çelişkiler, şikayetler ve organizatör yetkisi gerektiren işlemler iletilir. Bir sorunun çalışana aktarılması asistanın olağan işlevidir. Bu, yanıt gerçek duruma bağlı olduğunda, hassas bilgiler içerdiğinde veya bilgi tabanında bulunmayan bir karar gerektirdiğinde gereklidir.

Eskalasyon haritasını önceden hazırlıyoruz.

İletim bağlam içermelidir. Çalışanın orijinal soruya, önceden doğrulanmış verilere, oturum kimliğine, yanıt kanalına ve başvuru saatine ihtiyacı vardır. Asistan yalnızca "katılımcıya yardım edin" cümlesini iletirse, kişi görüşmeye sıfırdan başlar.

Eskalasyon süreci şöyle işler:

1. Asistan, sorunun yetkisini aştığını belirler.
2. Katılımcıya neden bir çalışanın gerektiğini bildirir.
3. Yalnızca yönlendirme için gerekli verileri toplar.
4. Bağlam içeren bir başvuru oluşturur.
5. Soru kategorisini ve sorumlu çalışanı seçer.
6. Katılımcıya iletim onayını gösterir.
7. Çalışan kararı çalışma sisteminde verir.
8. Karar, mutabık kalınan kanal aracılığıyla katılımcıya iletilir.
9. Yanıt yeniden kullanıma uygunsa, sahibi bunu bilgi tabanı için değerlendirir.
10. Yeni kayıt yalnızca doğrulamadan sonra yayımlanır.

Son madde önemlidir. Tekil bir karar her zaman genel bir kural haline gelmez. Organizatör bir konuşmacının personel girişinden geçmesine izin verdiyse, asistan bu güzergâhı tüm katılımcılara önermemelidir.

Ayrıca acil durum sınırını da belirliyoruz. Güvenlik tehdidi, sağlık durumunun kötüleşmesi, kayıp bir çocuk, çatışma veya benzeri acil bir durumla ilgili bildirimlerde asistan danışmanlık yürütmeye çalışmaz. Onaylanmış iletişim bilgisini gösterir ve saha senaryosuna göre sinyali derhal sorumlu çalışana iletir.

Katılımcılara erişim açılmadan önce kontrol

Asistanı devreye almadan önce yanıtların doğruluğunu ve belirsizlik, program değişikliği ve gizli bilgi edinme girişimi durumlarındaki davranışını kontrol ediyoruz. İyi bir sonuç, sistemin belirlenen sınırlara uyduğu, güncel sürümü kullandığı ve tartışmalı konuyu doğru çalışana ilettiği anlamına gelir. Toplam otomatik yanıt sayısı ikincil bir metrik olarak kalır.

Kontrolü birkaç turda gerçekleştiriyoruz.

1. Olguların kontrolü. Adları, saatleri, salonları, konuşmacıları ve bağlantıları ana kaynaklarla karşılaştırıyoruz.
2. Dil varyasyonlarının kontrolü. Aynı soruyu kısa, günlük konuşma dilinde, yazım hatalarıyla ve salonun eski adıyla soruyoruz.
3. Belirsizlik kontrolü. Aynı soyadları, benzer oturumları ve eksik ifadeleri kullanıyoruz.
4. Eksik veri kontrolü. Bilgi tabanında olmayan şeyleri soruyoruz.
5. Yetki kontrolü. Yer garantisi, kayıt değişikliği veya istisna izni talep ediyoruz.
6. Çelişki kontrolü. Test ortamında kasıtlı olarak aynı olgunun iki farklı sürümünü oluşturuyoruz.
7. Güncelleme kontrolü. Bir oturumu taşıyoruz ve yeni sürümün tüm yanıtlarda ne zaman göründüğünü izliyoruz.
8. Gizli veri kontrolü. Dahili telefon numarası, iç belge veya erişilemeyen bağlantı istenmesini talep ediyoruz.
9. Yükseltme kontrolü. Muhatabı, bağlamın eksiksizliğini ve talebin çalışan tarafından alınmasını değerlendiriyoruz.
10. Kurtarma kontrolü. Sistemi çalışan sürüme geri döndürüyor ve kontrol sorularını tekrarlıyoruz.

Kontrol sorularını rollere göre toplamak pratiktir. İK yöneticisini işveren markası süreci ilgilendirebilir. Pazarlamacı müşteri vaka örneklerini arar. Teknik uzman ürün demosunu sorar. Konuşmacı varış saatini netleştirir. Çevrimiçi erişimi olan katılımcı yayını arar. Her rol için kendi görevleri gerekir, ancak yanıtlar yine de ortak doğrulanmış tabandan alınır.

Testlere yalnızca geliştiriciler katılmaz. Program sahibi takvimi, kayıt servisi katılım durumlarını, mekân yöneticisi navigasyonu, çevrimiçi yapımcı yayını ve editör ifadelerin netliğini kontrol eder. Proje yöneticisi yetki matrisini onaylar.

Konferans günü kontrol noktaları belirliyoruz:

1. Kayıt açılmadan önce başlangıç programını ve destek kişilerini kontrol ediyoruz.
2. İlk bloktan önce operasyonel değişiklikleri karşılaştırıyoruz.
3. Paralel oturumlardan önce salonları ve erişim kısıtlamalarını kontrol ediyoruz.
4. Büyük bir değişiklikten sonra bir dizi kontrol sorusu soruyoruz.
5. Program tamamlandıktan sonra geçici durumları kapatıyor ve materyal bağlantılarını güncelliyoruz.
6. Etkinlik sonrasında asistanı yalnızca kayıtlar, materyaller ve geri bildirim hakkında doğrulanmış soruları yanıtladığı moda geçiriyoruz.

Hata günlüğünü kategorilere göre tutuyoruz. Yanlış kaynağı, eski sürümü, belirsiz ifadeyi, sorumlu seçimindeki hatayı ve yetki aşımını ayrı ayrı işaretliyoruz. Bu, yalnızca tek bir yanıtı değil, süreci düzeltmeye yardımcı olur.

Kaynaklar

• Schema.org: Event - etkinlik alanları, alt oturumlar, tarihler, yer, katılımcılar ve durum.
• Google Cloud: Grounding with Agent Search - yanıtın kurumsal verilere bağlanması ve doğrulayıcı parçaların üst verileri.
• OWASP GenAI: Misinformation - inandırıcı uydurmalar riski, doğrulanmış veriler üzerinden arama, otomatik kontrol ve insan denetimi.
• W3C: Web Content Accessibility Guidelines 2.2 - metin hataları, öğe etiketleri ve erişilebilir durum mesajları.
• Federal Law No. 152-FZ “On Personal Data” - Rusya projesinde kişisel verilerin amaçları, kapsamı, doğruluğu, saklama süreleri ve korunması.
• IETF: RFC 5545 - iCalendar - kalıcı UID, saat dilimi, değişiklik etiketleri ve takvim kaydının sürüm sırası.
• Microsoft Learn: Hand off to a live agent - görüşmenin ve ilgili bağlamın bir çalışana aktarılması.