Vì sao các app đọc chính tả nuốt mất từ đầu tiên của bạn

Nhấn hotkey. Bắt đầu nói. Rồi nhìn bản chuyển văn bản bắt đầu từ chữ thứ hai của bạn — đôi khi là chữ thứ ba. “Refactor phần logic retry” ra thành “phần logic retry”. “Đừng merge cái đó vội” ra thành “merge cái đó vội”, một câu thật sự nguy hiểm khi được gõ thay bạn. Lỗi này dễ tái hiện trên mọi đường thu âm có khởi động nguội, từ công cụ có sẵn của hệ điều hành đến các app đọc chính tả chuyên dụng.

Người ta mô tả nó theo nhiều cách — “nó cắt mất phần đầu”, “tôi phải dừng một nhịp rồi mới nói được”, “từ đầu tiên lúc nào cũng mất” — nhưng đó là cùng một hiện tượng, và một khi đã dính đòn, bạn tự nghĩ ra đúng cái mẹo mà ai cũng nghĩ ra: nhấn phím, chờ một nhịp, rồi mới nói. Nghĩa là mỗi ngày bạn đang thực hiện vài chục lần một nghi thức nhỏ đầy mê tín để bù cho công cụ của mình, và công cụ đã huấn luyện bạn thay vì ngược lại.

Tôi đã làm cái nghi thức đó suốt nhiều tháng với những công cụ khác. Khi làm Keebye, việc dẹp nó là một trong những việc đầu tiên trong danh sách, bởi cách khắc phục hóa ra đòi hỏi một đánh đổi khó chịu mà phần lớn app không chịu chấp nhận — và tôi muốn nói về sự đánh đổi đó thẳng thắn như nói về cách khắc phục.

Vì sao từ đầu tiên bị cắt mất?

Đây là vấn đề ở tầm cả nhóm sản phẩm, không phải sự cẩu thả của riêng nhà cung cấp nào, và bản chất vật lý của nó rất đơn giản: micro không phản hồi tức thì.

Khi một app đọc chính tả bắt đầu ghi âm theo cách ngây thơ — nhấn hotkey, rồi mới mở micro — cả một chuỗi việc phải chạy xong trước khi mẫu âm thanh đầu tiên của bạn được thu lại. Phiên audio của hệ điều hành phải khởi tạo. Thiết bị đầu vào phải thức dậy, mà với một số phần cứng thì đó là thời gian làm nóng theo đúng nghĩa đen. Định dạng luồng phải được thỏa thuận, bộ đệm phải được cấp phát, và những bộ đệm đầu tiên về đến nơi thường là rác rồi bị bỏ đi. Tùy máy và tùy thiết bị, chuỗi đó mất từ “một nhịp” đến vài giây.

Trong lúc đó, bạn — một con người đã hình thành sẵn ý nghĩ — bắt đầu nói ngay khoảnh khắc ngón tay chạm phím. Thật ra thường là sớm hơn khoảnh khắc đó một chút: ý định nhấn và ý định nói rời khỏi não bạn cùng lúc, và tiếng nói thường xuyên đến trước lúc app sẵn sàng. Mọi thứ bạn nói trước khi luồng âm thanh sống dậy đều chưa từng tồn tại dưới góc nhìn của app. Model không thể chuyển thành văn bản thứ âm thanh chưa bao giờ được thu. Thế nên: “phần logic retry”.

Vì sao các app chỉ mở micro khi cần thay vì giữ nó luôn sẵn sàng? Phần lớn là vì phép lịch sự. Giữ micro mở tốn một chút điện, và — quan trọng hơn nhiều — nó bật đèn báo micro của hệ điều hành, thứ mà người dùng hoàn toàn có lý khi hiểu là “app này đang nghe tôi”. Chỉ mở micro khi cần thì đèn báo trung thực và app trông lịch sự. Cái giá là rủi ro khởi động nguội ở đầu mỗi lần ghi âm.

Cách khắc phục: một micro đã nghe sẵn từ trước khi bạn nhấn phím

Keebye tấn công chuyện này từ cả hai đầu, và hai cơ chế đó đáng được tách bạch vì chúng giải quyết hai nửa khác nhau của vấn đề.

Micro luôn ấm. Sau lần ghi âm đầu tiên trong một phiên, Keebye giữ luồng đầu vào âm thanh mở. Nghĩa là chuỗi khởi động nguội — khởi tạo phiên, đánh thức thiết bị, thỏa thuận luồng — đã diễn ra xong trước một lượt đọc sau đó, chừng nào luồng còn khỏe mạnh. Luồng đã sống trước khi ngón tay bạn kịp động đậy.

Pre-roll. Một luồng đã ấm chữa được sự chậm trễ của app, nhưng không chữa được sự sớm của bạn — nhớ rằng tiếng nói của bạn có thể đến trước cú nhấn phím. Nên Keebye giữ một bộ đệm cuộn 500 mili-giây chứa phần âm thanh gần nhất (8.000 mẫu ở 16 kHz, trong một ring buffer). Khi bạn nhấn hotkey, nửa giây âm thanh ngay-trước-đó ấy được đẩy vào đầu câu nói. Âm thanh bắt đầu bên trong bộ đệm đó sẽ đến được bộ chuyển văn bản thay vì bị vứt đi trước cú nhấn phím.

Kết quả kết hợp: với những lượt đọc lặp lại, luồng đã ấm cùng 500 ms pre-roll bao được trường hợp phổ biến khi lời nói bắt đầu ngay trước hoặc cùng lúc với cú nhấn phím. Trong ranh giới đó, khoảng dừng nghi thức trở nên không cần thiết. Nó không cứu được một từ nói ra sớm hơn nửa giây trước khi việc ghi âm bắt đầu, và lượt đọc đầu tiên của một phiên vẫn phải trả độ trễ khởi động luồng như thường.

Nói thẳng về sự đánh đổi

Đây là phần tôi từ chối giấu đi, vì nó là cái giá trung thực của thiết kế này: do luồng âm thanh vẫn mở giữa các lượt đọc, macOS hiển thị micro đang hoạt động ngay cả khi bạn không đọc chính tả. Chấm màu cam sáng lên. Nếu bạn mở Control Center, Keebye được liệt kê là đang dùng micro, ngay lúc đó, trong khi bạn chẳng làm gì cả.

Chuyện thật sự xảy ra trong khoảng thời gian đó: âm thanh chảy vào ring buffer 500 ms và liên tục bị bỏ đi. Không có gì được chuyển thành văn bản. Không có gì được lưu. Không có gì rời khỏi bộ đệm cho đến khi bạn nhấn phím — và mọi thứ cũ hơn nửa giây đều mất vĩnh viễn, bị ring buffer ghi đè. Nhưng tôi sẽ không giả vờ rằng đèn báo đang nói dối, vì nó không nói dối: luồng đang mở, và “có khả năng nghe liên tục” là mô tả công bằng cho kiến trúc này, dù chẳng có gì thật sự nghe theo bất kỳ nghĩa nào cho đến khi bạn yêu cầu.

Tôi chọn đánh đổi này một cách có chủ ý, mở mắt mà chọn, và đây là lý lẽ. Chỉ mở micro khi cần thì mỗi lần lại thêm rủi ro khởi động nguội: từ bị cắt, câu sai nghĩa, khoảng dừng đã thành thói quen. Thiết kế giữ luồng ấm có cái giá rơi vào mức thoải mái của bạn với một chấm cam, được chống lưng bởi một kiến trúc bạn có thể tự suy xét: lịch sử cục bộ chỉ gồm văn bản (chúng tôi đã viết kỹ trong bài bản đọc chính tả của bạn không nên tự dưng biến mất), việc chuyển văn bản ngay trên máy, không bao giờ lưu âm thanh, nửa giây bộ nhớ vòng. Tôi chấp nhận cái chấm. Nếu bạn không — đó là một quan điểm chính đáng, và nó thật sự có thể khiến một công cụ khác mới là lựa chọn đúng cho bạn; các trang Keebye vs Superwhisper và Keebye vs Wispr Flow của chúng tôi được viết đúng để giúp bạn ra quyết định đó.

Hai ranh giới, để không ai bất ngờ

Lượt đọc đầu tiên của một phiên vẫn có độ trễ khởi động luồng như thường. Micro ấm là vì đã có một lần ghi âm trước đó; lần đầu tiên vẫn phải trả chi phí thiết lập. Những lượt đọc sau được hưởng lợi chừng nào luồng còn mở.

Pre-roll là 500 mili-giây, và 500 mili-giây là một nhịp, không phải một câu. Bộ đệm bao được trường hợp tự nhiên — một từ bắt đầu hơi sớm hơn cú nhấn phím. Nếu bạn nói trọn một câu rồi mới nhớ ra phải nhấn phím, những từ trước đó đã mất, và điều đó là có chủ ý: ring buffer chỉ giữ đúng nửa giây, chính là để app không lưu lại âm thanh có ý nghĩa trong lúc rảnh. Một pre-roll dài hơn sẽ bắt được nhiều hơn những lần bạn bắt đầu đãng trí, và cũng giữ nhiều âm thanh xung quanh bạn trong bộ nhớ hơn. Nửa giây là chỗ tôi vạch ra ranh giới đó.

Vì sao nửa giây quan trọng hơn vẻ ngoài của nó

Một từ đầu bị cắt trông như một lỗi nhỏ. Trong quy trình nhiều lane song song mà Keebye được xây cho — giọng nói làm kênh điều khiển cho vài agent AI và vài cuộc trò chuyện với người cùng lúc, cái ngày làm việc được kể trong hai đứa con, ba startup, một giọng nói — việc đọc chính tả diễn ra vài chục lần mỗi ngày, theo từng đợt, ngay giữa lúc chuyển ngữ cảnh. Một công cụ đòi hỏi khoảng dừng nghi thức sẽ đánh thuế lên từng đợt, và tệ hơn, thỉnh thoảng đảo ngược ý bạn rồi gửi đi. “Merge cái đó vội” chỉ buồn cười đúng một lần.

Độ tin cậy trong nhóm sản phẩm này không nằm ở một tính năng lớn. Nó là sự tích tụ của những lớp bảo vệ nhỏ hơn: pre-roll cho phần âm thanh mở đầu, lịch sử đứng sau bản chuyển văn bản, và một đường chèn văn bản có thể khôi phục. Bài này nói về cái thứ nhất; bài về lịch sử nói về cái thứ hai.

Keebye đang trong giai đoạn truy cập sớm cho macOS. Hãy bắt đầu bản dùng thử miễn phí bên dưới, nói “Đừng merge cái đó vội” trong một lượt đọc lặp lại, và kiểm tra xem từ đầu tiên có sống sót không. Bài kiểm tra chỉ có vậy.