Akışlı STT: geçici metni ne zaman son transkript saymalısınız?

Akışlı STT’de ekranda görünen ilk metin, hemen işlem yapılacak son metin değildir. Önce sonucun geçici mi, belirli bir ses bölümü için kesinleşmiş mi olduğunu kullanılan sağlayıcının belgesinden okuyun. Ardından uygulamanın hangi bilgiyi ne zaman kullanacağına karar verin. Bir rezervasyon tarihi veya sipariş miktarı için bu ikinci karar, transkriptin durumundan ayrı olarak doğrulama ve gerekirse kullanıcı onayı gerektirir.

1. Geçici sonucu güncellenen bir taslak olarak ele alın

Amazon Transcribe akışlı sonuçların yeni bağlam geldikçe değişebileceğini açıklar. [2] Bu nedenle her yeni parçayı önceki metnin sonuna eklemek doğru bir varsayım değildir. Önce olayın aynı bölümün yeni tahmini mi, başka bir bölümün sonucu mu olduğunu belirleyin. Görünen taslağı güncellemekle tamamlanmış bölümleri birleştirmek farklı işlemlerdir.

Arayüzde geçici metin gösterecekseniz değişebileceğini anlaşılır biçimde belirtin. Kullanıcıya bir tarih görünürken hemen ardından değişmesi ile uygulamanın o tarihe dayanarak işlem başlatması farklı sonuçlar doğurur. Önizlemeyi işlem durumu gibi göstermeyin. Denemelerde ilk görünen metni, son görünen metni ve kullanılan alanı ayrı kaydedin; böylece hatanın tanıma mı, erken kullanım mı olduğunu araştırabilirsiniz.

2. Final işaretinin kapsamını sağlayıcıya göre okuyun

Google’ın stability alanını kelimenin doğru olduğuna ilişkin güven puanı gibi kullanmayın; alan değişmeme tahminini anlatır. [1] Tablo da sağlayıcılar arasında doğrudan eşdeğerlik kurmaz. Kullanılan arayüz, sürüm ve modun alan anlamlarını belgeleyin. Tek bir “final” değişkeni altında farklı kapsamları toplarsanız sonraki ekip üyesi hangi bilginin kesinleştiğini anlayamayabilir.

3. Sayı ve tarih kullanımına ayrı bir karar koyun

Kesinleşmiş tanıma bölümü, doğru iş bilgisiyle aynı şey değildir. “Salı, on dört” cümlesinin saat mi, günün tarihi mi olduğunu konuşma bağlamı belirler. Önce ham transkripti koruyun; sonra yorumlanan alanı ayrı kaydedin. Tarihi, saati veya miktarı yalnız görünür metin değişmedi diye kesinleştirmek yerine, görevin beklediği anlamın tamamlanıp tamamlanmadığını kontrol edin.

Önizlemede “on dört”, sonraki sonuçta “on dört otuz” görünmesi için özgün bir test örneği hazırlayın. Yanlış erken kullanımın hangi adımı etkilediğini belirtin: sadece bir önizleme mi değişti, kullanıcıya geri okuma mı yanlış oldu, yoksa bir işlem mi başlatıldı? Önemli bilgiler için kısa ve açık geri okuma, kullanıcının düzeltme fırsatını görünür kılar.

4. Birleştirme, tekrar ve kesilmeyi ayrıca sınayın

Deepgram belgesi, speech_final gelmeden önce birden fazla is_final bölümünün oluşabileceğini anlatır. [3] Bu ayrımı test etmek için tek uzun cümleyi farklı duraklamalarla okuyun. Sonucun tamamını elde etmek ile en son olayı elde etmek aynı işlem olmayabilir. Birleştirme kuralını belgelenen bölüm sınırlarına ve aynı denemenin zaman çizelgesine göre değerlendirin.

Uygulama tarafında aynı sonuç tekrar işlenirse metin veya işlem iki kez oluşuyor mu, bunu da kontrol edin. Olayları görüşme, bölüm ve güncelleme bağlamında ayırmak işe yarar. Bağlantı kesilirse eldeki geçici metni kendiliğinden kesin sonuç gibi göstermeyin. Tamamlanmamış bilgi için uygun sonraki davranışı belirleyin: yeniden dinleme, tekrar isteme veya açık bir eksik durum bildirimi.

5. Varsayımsal bir saat doğrulama denemesi

Bir arayan “yarın on dört … otuz, pardon on beş” diyor. İlk taslak saat on dört gibi görünür, devamında daha uzun bir ifade oluşur; sonradan kullanıcı açıkça düzeltir. Ekip üç ayrı şeyi kontrol eder: taslak doğru güncelleniyor mu, tamamlanmış bölümler doğru toplanıyor mu, yorumlanan son saat düzeltmeyi içeriyor mu? Tanımanın final durumu sonradan söylenen düzeltmeyi yok saymak için gerekçe olmaz.

İkinci denemede aynı cümle farklı duraklamalarla kullanılır. Üçüncü denemede sonuç akışı bitmeden bağlantı kesilir. Her denemede görünen metin, kesin bölüm listesi, yorumlanan alan ve kullanıcıya okunan ifade karşılaştırılır. Amaç her olayı işlem başlatmaya çevirmek değil, bilgi hangi noktada yeterli olduğunda hareket edileceğini göstermek. Belirsiz kalan saatte kısa bir doğrulama sorusu akışı toparlayabilir.

6. Akışlı transkript için kontrol listesi

• Geçici bölüm güncellemesi ile yeni bölümü ayrı ele alın.
• Sağlayıcının alan anlamını ve sonucun kapsamını kaydedin.
• Ham metin, birleştirilmiş metin ve yorumlanan alanı ayırın.
• Tarih, saat, sayı ve sonradan gelen düzeltmelerle test edin.
• Tekrarlanan olayların metni veya işlemi çoğaltmadığını kontrol edin.
• Kesilen akışta tamamlanmamış sonucu görünür biçimde ele alın.
• Kritik bilgiyi gerektiğinde kullanıcıya geri okuyup doğrulayın.

Sık sorulan sorular

Final, kullanıcının bütün isteğinin doğru anlaşıldığını gösterir mi? Hayır. Önce sağlayıcının hangi ses bölümünü kesinleştirdiğini okuyun; ardından iş bilgisinin anlamını ve tamamlanmasını değerlendirin.

Geçici metin hiç kullanılmamalı mı? Önizleme ve geri alınabilir hazırlık için yararlı olabilir. Önemli tarih veya sayı üzerinden işlem başlatma kararını aynı kurala bağlamayın; sonuç durumuyla kullanım amacını ayrı tutun.