Độ trễ từ lời nói đến lệnh được đo và rút ngắn như thế nào?

• Thu âm
• Xử lý lời nói và lệnh
• Nhận yêu cầu tại drone

Bạn sẽ học được gì

• Xác định sự kiện bắt đầu và kết thúc phép đo độ trễ.
• Cộng thời gian theo chặng và so phân bố với ngân sách.
• Chọn cách tối ưu thời gian chờ mà không che mất sự bất định.

Cần biết trước

Chỉ cần biết lệnh giọng nói đi qua nhiều bước phần mềm trước khi một thành phần khác chấp nhận nó.

Chính xác là đang đo điều gì?

Đồng hồ cần có ranh giới quan sát được. Với lệnh nói, hãy chọn thời điểm bắt đầu là dấu thời gian tại micro khi người nói dứt câu, và kết thúc là lúc bộ kiểm tra trả quyết định chấp nhận hay từ chối. Cách này đo “từ hết lời đến quyết định” và không tính thời gian nói. Nếu câu hỏi sản phẩm là “từ lúc bấm nút đến phản hồi đầu tiên”, hãy chọn các mốc ấy và ghi đúng tên chỉ số.

Chuỗi có thể gồm đệm âm thanh, nhận dạng, phát hiện hết câu, trích intent và tham số, xác thực, truyền mạng và ứng dụng nhận lệnh. Ghi dấu thời gian đơn điệu tại mỗi ranh giới, tốt nhất trên cùng đồng hồ. Nếu công việc qua nhiều thiết bị, hãy tính độ lệch đồng hồ hoặc đo thời gian khứ hồi tại một điểm quan sát; trừ hai đồng hồ treo tường không đồng bộ có thể tạo ra thời lượng giả.

Với một yêu cầu, độ trễ đầu-cuối bằng tổng các khoảng thời gian giữa những chặng không chồng lấp. Nếu các chặng chạy đồng thời, cộng thời lượng riêng sẽ đếm trùng; dùng dấu thời gian ngoài cùng để tính tổng và dùng khoảng từng chặng để tìm nguyên nhân. Ngân sách đề xuất có thể chia một phần cho thu âm, nhận dạng, diễn giải và chuyển giao, nhưng tỷ lệ phải xuất phát từ yêu cầu phản hồi và phép đo ban đầu của sản phẩm, không phải chuẩn chung.

Đánh giá ngân sách như thế nào?

Ngân sách là ngưỡng cho ranh giới đã chọn, không phải thời lượng trung bình của một thành phần. Với mỗi yêu cầu, tính mili giây bằng thời điểm kết thúc trừ thời điểm bắt đầu, rồi xem phân bố trên nhiều yêu cầu đại diện. Trung vị mô tả trường hợp thường gặp; phân vị cao như p95 cho thấy đuôi chậm mà trung bình có thể che khuất. Ghi cả số mẫu và điều kiện: micro, ngôn ngữ, tiếng ồn, mạng, mô hình, văn bản tạm thời hay cuối cùng.

Tách “chữ tạm thời đầu tiên” khỏi “văn bản nhận dạng cuối cùng” và “lệnh được chấp nhận”. Nhận dạng streaming có thể trả kết quả tạm thời khi âm thanh vẫn đang được thu; quyết định cuối có thể phải đợi hết câu và xác thực. Bản chép nhanh một phần không chứng minh câu lệnh đã hoàn tất hoặc có thể chuyển tiếp.

Thay đổi nào có thể giảm thời gian chờ?

Trước tiên tìm chặng chậm bằng cùng bộ dấu thời gian và so các yêu cầu tương đương. Nếu chờ văn bản cuối là nút thắt, streaming có thể đưa kết quả một phần ra sớm hơn; giao diện hiện trạng thái “đang nghe” trong khi chờ kết quả cuối. Nếu truyền âm thanh chiếm thời gian, gói nhỏ có thể giảm chờ do đệm, nhưng hướng dẫn Google lưu ý gói streaming lớn hiệu quả hơn và làm tăng độ trễ. Nếu diễn giải chiếm nhiều thời gian, bộ lệnh giới hạn và luồng xử lý cục bộ gọn hơn có thể giảm việc tính toán, nhưng phải đo lại chất lượng và độ bao phủ.

Đừng tối ưu bằng cách chấp nhận mọi giả thuyết tạm thời hay bỏ xác thực. Thiết kế tốt hơn có thể chạy chồng lấp việc độc lập—chẳng hạn chuẩn bị bản xem trước khi người nói còn đang nói—nhưng phải chờ văn bản cuối trước khi coi các từ đã ổn định. Nếu mạng biến động, nhận dạng cục bộ có thể giảm phụ thuộc mạng nhưng tăng yêu cầu tính toán và bộ nhớ trên thiết bị. Sau mỗi thay đổi, đo lại cùng ranh giới đầu-cuối; bộ nhận dạng nhanh hơn chưa chắc giảm tổng thời gian nếu chặng khác mới là nút thắt.

Ví dụ: biến dấu thời gian thành kế hoạch tối ưu

Kế hoạch đo giả định; đây không phải kết quả đo.

Một nhóm ghi lúc dứt lời, lúc có chữ tạm thời đầu tiên, lúc có bản chép cuối, lúc trích tham số xong, lúc bộ kiểm tra quyết định và lúc xác nhận chuyển giao. Với mỗi yêu cầu, họ trừ các mốc liền nhau để có thời lượng từng chặng; tổng độ trễ là từ lúc dứt lời đến quyết định. Họ phân nhóm kết quả theo bản ghi yên tĩnh hoặc ồn và theo tình trạng mạng, rồi so trung vị và p95 với mục tiêu dịch vụ họ chọn. Nếu đuôi chậm chỉ xuất hiện khi văn bản cuối về trễ, họ xem lại chốt câu và streaming; nếu bộ xác thực chậm, họ đo thành phần đó thay vì đổi mô hình giọng nói. Sau một thay đổi, họ đo lại và kiểm tra lỗi bản chép cùng với thời gian.

Hiểu lầm thường gặp

Trung bình thấp nghĩa là hệ thống phản hồi nhanh. Đuôi chậm vẫn khiến nhiều lượt phải chờ, còn chữ tạm thời chưa phải lệnh cuối được chấp nhận.

Câu hỏi thường gặp

Có tính thời gian người dùng đang nói không?

Chỉ khi câu hỏi sản phẩm bao gồm thời gian đó. Hãy công bố ranh giới; ví dụ trên đo từ lúc dứt câu nên không tính tốc độ nói.

Vì sao cần xem p95 bên cạnh trung vị?

Trung vị cho biết lượt điển hình; p95 bộc lộ đuôi chậm có thể bị giấu trong số trung bình.

Gói âm thanh nhỏ hơn có luôn làm nhận dạng nhanh hơn không?

Không. Kích cỡ gói ảnh hưởng cả thời gian đệm lẫn hiệu suất xử lý; cần thử toàn chuỗi và kiểm chất lượng bản chép.

Tóm tắt

• Xác định ranh giới dấu thời gian trước khi đo và tách tổng thời gian khỏi các chặng.
• Chia ngân sách từ nhu cầu đã đo, rồi so trung vị và đuôi chậm trong điều kiện đại diện.
• Tối ưu nút thắt được đo; đừng đổi tính hoàn chỉnh hoặc xác thực lấy kết quả tạm thời nhanh hơn.