Vì sao AI notetaker của bạn dừng ghi âm giữa cuộc họp

Ngày 2 tháng 7, GeekBye tự mình kết thúc một bản ghi cuộc họp. Dòng dữ liệu trong database nói lên tất cả: ended_reason = 'idle', thời lượng 519 giây, 99 mục phiên âm — mục cuối cùng được ghi 2 giây trước khi ứng dụng quyết định rằng không còn ai ở đó.

Người tham gia phía bên kia đang giải thích dở chừng. Dòng cuối cùng của bản phiên âm, theo đúng nghĩa đen, là một mảnh câu đứt ngang: "...executes it or turns it on or so—".

Đây không phải lần đầu. Tối hôm trước, một phiên khác cũng kết thúc theo đúng cách đó. Hai cuộc họp, bị chính tính năng độ tin cậy của chúng tôi kết liễu. Dưới đây là bản chẩn đoán và bản sửa đã phát hành trong GeekBye v2.0.9 — cộng thêm một con bug thứ hai, đáng sợ hơn, được sửa trong cùng bản phát hành.

Một bộ đếm đầy thiện chí nhưng chỉ nghe được mỗi bạn

Cơ chế tự đóng khi idle tồn tại vì một lý do chính đáng. Người ta hay quên bản ghi âm chạy qua đêm; một tab họp bỏ quên cứ rỉ rả âm thanh mãi mãi. Nên GeekBye canh chừng sự bất động: sau 60 giây không có hoạt động giọng nói, nó hiện một lời nhắc nhỏ "Still recording?" (Vẫn đang ghi âm chứ?), và 30 giây sau, nếu không được trả lời, nó kết thúc phiên — lưu lại mọi thứ, một cách lịch sự.

Lỗ hổng nằm gọn trong một từ: giọng nói. Đồng hồ hoạt động chỉ đếm năng lượng microphone duy trì, không gì khác. Đó là một quyết định thiết kế có chủ đích, và không hề ngớ ngẩn — nếu đếm cả năng lượng thô của system audio, một tab đã mute nhưng vẫn ồn ào sẽ giữ một phiên đã chết sống mãi vô thời hạn, chính xác là kiểu thất bại mà tính năng này sinh ra để ngăn chặn. Những cuộc họp mà bạn chủ yếu ngồi nghe lẽ ra đã được bao phủ bởi cơ chế phát hiện cửa sổ họp.

Chỉ có điều, phát hiện cuộc họp không thể thấy mọi cuộc họp. Tab trình duyệt, các client lạ, một buổi thuyết trình bạn đang xem — đều không được phát hiện. Và trong một cuộc họp không được phát hiện, nơi bạn ngồi nghe suốt 90 giây — một điều hoàn toàn bình thường khi ai đó đang giải thích pipeline Databricks của họ — thì đối với đồng hồ idle, bạn không khác gì một căn phòng trống.

Hãy xem dòng thời gian của phiên bị kết liễu: bản phiên âm cuối cùng từ microphone của chúng tôi đến 68 giây trước khi kết thúc. Rồi 60 giây người phía bên kia nói (được phiên âm hoàn hảo, bị đồng hồ ngó lơ), lời nhắc không ai để ý, 30 giây đếm ngược, và cú kết liễu — 2 giây sau những lời cuối cùng của họ.

Bản sửa: một bản phiên âm là bằng chứng của sự sống

Nhìn lại, cách sửa gần như đáng xấu hổ vì quá hiển nhiên: một bản phiên âm đến là bằng chứng mạnh nhất có thể rằng phiên không hề idle. Ai nói không quan trọng. Mô hình giọng nói vừa nhận diện được từ ngữ — đó chính là cuộc họp.

Vậy nên v2.0.9 đóng dấu đồng hồ hoạt động trên mọi bản phiên âm đến, từ bất kỳ phía nào. Năng lượng thô của system audio vẫn không được tính — nhạc, tiếng chờ máy và tiếng ù của điều hòa vẫn không thể bất tử hóa một phiên đã chết, và mức trần ghi âm cứng vẫn chốt chặn tất cả. Chỉ giọng nói được nhận diện mới giữ được một phiên sống, và đó chính xác là ranh giới đúng.

Một chi tiết từ code review đáng chia sẻ lại: phiên bản đầu tiên của bản sửa đóng dấu đồng hồ bên trong nhánh gán người nói — nhánh mà một tập con các bản phiên âm hoàn toàn có thể hợp lệ bỏ qua. Review phát hiện rằng một thay đổi trong tương lai có thể âm thầm tái tạo con bug cho đúng những bản phiên âm quan trọng nhất (của người nói phía bên kia). Con dấu giờ là vô điều kiện, đứng trước mọi nhánh rẽ, kèm một test sẽ fail nếu ai đó di chuyển nó.

Cùng bản phát hành đã sửa một thứ đáng sợ hơn

Trong khi test những bản sửa này, chúng tôi đụng phải một con bug khác theo cách đau đớn nhất: một cú crash trong tiến trình giao diện khiến toàn bộ desktop không thể click được.

Overlay của GeekBye là một cửa sổ trong suốt, luôn nổi trên cùng, phủ kín màn hình của bạn. Mặc định nó cho click xuyên qua; giao diện bật nó sang chế độ tương tác khi bạn đang dùng một panel. Những lệnh bật/tắt đó đến từ tiến trình giao diện — nên khi tiến trình đó crash trong lúc một panel đang mở, cửa sổ vô hình kẹt lại ở chế độ tương tác mà không còn UI nào sống phía sau. Mọi cú click trên desktop của bạn rơi vào một tấm kính chết, vô hình. Lối thoát duy nhất là force-quit ứng dụng.

Trình xử lý crash của v2.0.9 giờ khôi phục click xuyên qua ngay lập tức và reload giao diện — với mức trần ba lần reload mỗi phút để một vòng lặp crash không thể quay mãi (quá mức trần, ứng dụng bỏ cuộc việc reload nhưng desktop của bạn vẫn dùng được, và đó mới là phần quan trọng). Code review cũng mài sắc bản sửa này: việc khôi phục được giới hạn riêng cho cửa sổ overlay, bởi áp click xuyên qua đại trà lên một cửa sổ thường bị crash — chẳng hạn hộp thoại cập nhật — sẽ tạo ra tình trạng khóa cứng theo chiều ngược lại.

Bạn có thể tự kiểm chứng bản sửa này, theo cách tàn bạo nhất: mở một panel GeekBye, force-kill tiến trình "GeekBye Helper (Renderer)" trong Activity Monitor, và xem ứng dụng trả lại desktop cho bạn trong vòng một giây.

Cặp bug này dạy chúng tôi điều gì

1. Mọi proxy cho câu hỏi "người dùng còn ở đây không?" đều thất bại ở đâu đó. Năng lượng mic thất bại với người ngồi nghe. Phát hiện cửa sổ thất bại với trình duyệt. Bản phiên âm được nhận diện thất bại với... chưa trường hợp nào chúng tôi tìm ra, bởi chúng không phải là proxy — chúng chính là sản phẩm.
2. Bất cứ thứ gì do renderer điều khiển đều cần một kịch bản crash. Nếu một tiến trình UI chết có thể để lại trạng thái ở cấp hệ điều hành (bắt chuột, luôn nổi trên cùng, bảo vệ nội dung), thì tiến trình main phải là bên sở hữu việc reset.
3. Là người dùng nặng đô nhất của chính mình là một chiến lược săn bug. Cả hai con bug đánh trúng chúng tôi trong các cuộc họp thật trước khi nhiều hơn một nhúm khách hàng kịp nhận ra. Cột ended_reason mà chúng tôi thêm vào vì mục đích observability từ nhiều tháng trước chính là thứ biến việc chẩn đoán thành một câu truy vấn database thay vì một phỏng đoán.

Cả hai bản sửa đi từ chẩn đoán đến một bản phát hành đã notarize, xuất xưởng trong vòng một ngày, mỗi bản qua một PR được review kèm regression test. Nếu bạn đang dùng GeekBye v2, bạn đã có chúng từ v2.0.9 qua auto-update.

Về phần còn lại của câu chuyện bản phát hành này, xem bài anh em trong series vì sao AI phiên âm nghe nhầm thuật ngữ kỹ thuật (v2.0.11), nền móng độ tin cậy trong vì sao AI notetaker của bạn dừng lại khi Wi-Fi chập chờn, và cách overlay giữ mình vô hình khi chia sẻ màn hình mà không cướp mất cú click của bạn.