Vì sao AI phiên âm nghe nhầm thuật ngữ kỹ thuật (và chúng tôi đã sửa như thế nào)
Một phiên ghi âm trực tiếp đã nghe "what is the pointer in C++" thành "what is the point in life". Đây là hành trình điều tra từ bản phiên âm đó đến GeekBye v2.0.11 — keyterm biasing, một race condition làm rớt kết nối, và cái ngày mà chính bản sửa lỗi của chúng tôi phản tác dụng.
Ngày 2 tháng 7, chúng tôi chạy một phiên test và hỏi GeekBye một câu đơn giản bằng giọng nói: "What is the pointer in C++?" (con trỏ trong C++ là gì?)
Bản phiên âm trực tiếp trả lời bằng thơ:
[23:16:37] You: Tell me, what is the point in life? [23:16:52] You: Handy Plus. [23:17:02] You: What the pointer in Plus Plus? [23:17:09] You: C.
"pointer in C++" (con trỏ trong C++) đã biến thành "point in life" (ý nghĩa cuộc sống). Các chỉ số sức khỏe của chính phiên đó kể nốt phần còn lại: 3 lần rớt kết nối phiên âm trong 163 giây và một lỗ hổng 51 giây trong bản phiên âm. Và còn một manh mối nữa mà về sau hóa ra quan trọng nhất: bước khôi phục sau phiên của chúng tôi — vốn phiên âm lại đoạn âm thanh đã lưu cục bộ để lấp các khoảng trống — nghe câu đó gần như đúng: "a pointer in plus, plus? What the pointer in plus, plus C++."
Âm thanh hoàn toàn ổn. Mô hình trực tiếp chỉ đơn giản là không có lý do gì để đoán trước C++.
Đây là câu chuyện về GeekBye v2.0.11, kể lại từ chính các bản phiên âm và log production.
Vì sao mô hình giọng nói nghe nhầm từ vựng của bạn
Nhận diện giọng nói là một bài toán dự đoán. Trước một đoạn âm thanh mơ hồ, mô hình chọn những từ có khả năng nhất — và với một mô hình đa dụng, "point in life" là cụm từ dễ gặp hơn "pointer in C++" rất nhiều. Kỹ sư nào từng thấy bản phiên âm cuộc họp viết Kubernetes thành "cube and eddies" đều đã gặp kiểu thất bại này.
Cách sửa không phải là một chiếc micro tốt hơn. Đó là keyterm biasing: nói cho mô hình biết, trước khi phiên bắt đầu, những từ hiếm gặp nào lại là từ dễ gặp đối với bạn. Nhà cung cấp giọng nói của chúng tôi hỗ trợ tối đa 50 từ biasing mỗi phiên. Và đây là phần đáng xấu hổ: hệ thống ống dẫn cho những từ đó đã tồn tại đầu-cuối trong stack của chúng tôi — client, backend, nhà cung cấp — nhưng chưa từng có gì đổ dữ liệu vào. Mọi phiên đều chạy với sự trợ giúp chuyên ngành bằng không.
Sửa lỗi 1: profile của bạn trở thành vốn từ của mô hình
GeekBye vốn đã biết lĩnh vực của bạn — nó nằm ngay trong profile đang kích hoạt. v2.0.11 rút các keyterm biasing từ tên và mô tả của profile: các thuật ngữ có ký hiệu (C++, Node.js), từ viết tắt (SQL, AWS), tên viết kiểu camel-case (TypeScript, PostgreSQL), và danh từ riêng. Một profile nhắc đến stack của bạn giờ khiến stack đó trở thành thứ được kỳ vọng thay vì xa lạ.
Cái ngày bản sửa lỗi khiến mọi thứ tệ hơn
Phiên bản đầu tiên của chúng tôi coi mọi từ viết hoa là danh từ riêng. Trên một bản build test nội bộ (bản này chưa từng đến tay khách hàng), một profile viết bằng văn xuôi đã gửi danh sách biasing này cho mô hình:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Bias một mô hình giọng nói về phía từ "For" còn tệ hơn là không bias gì cả. Ngay phiên test kế tiếp, từ "speak" — được nói rõ ràng, nhiều lần — quay về thành "Clicky", "Hey, Vicky" và "Peter Paderty". Bài học đó tốn của chúng tôi một buổi chiều: chỉ bias bằng những từ có tính đặc trưng. Từ viết hoa giờ chỉ được tính khi xuất hiện giữa câu (một tín hiệu danh từ riêng thực sự); các heading markdown, nơi từ nào cũng viết hoa, không bao giờ được tính. Chính profile đó giờ rút ra chính xác LinkedIn, AI, CEO, MCP — và phiên kiểm chứng đã phiên âm đúng đoạn âm thanh đa ngôn ngữ, chuyển đổi nhanh, liên tục 199 giây, 189 phân đoạn phiên âm, không một lỗi nào.
Sửa lỗi 2: race condition làm rớt kết nối
Keyterms giải thích được những từ nghe nhầm. Nhưng chúng không giải thích được ba lần rớt kết nối.
Manh mối đó dẫn đến một chỗ tinh vi hơn. Nhà cung cấp của chúng tôi commit (chốt) bản phiên âm dựa trên cơ chế phát hiện giọng nói (VAD) của chính họ, khoảng một giây sau khi im lặng. Client của chúng tôi cũng gửi một commit an toàn ở mốc 250 mili giây im lặng, để đẩy nốt câu nói còn dang dở. Xác nhận từ nhà cung cấp rằng họ đã commit rồi mất một đến ba giây mới quay về. Hãy làm phép tính với ba con số đó: mỗi khi nhà cung cấp commit trước, commit an toàn của chúng tôi bắn vào một buffer gần như trống rỗng — và phản ứng của nhà cung cấp không phải là một lời từ chối lịch sự. Họ ngắt luôn kết nối. Mỗi khoảng dừng khi nói chuyện là một lần tung đồng xu.
v2.0.11 mang theo hai lớp phòng thủ:
- Trong ứng dụng: khi một bản phiên âm đã commit đến nơi, client giờ biết rằng buffer của nhà cung cấp vừa được xả, và bỏ qua commit an toàn thừa thãi kia.
- Ở backend của chúng tôi, ngay trong ngày: proxy nằm giữa ứng dụng và nhà cung cấp sao chép chính xác sổ sách âm thanh của nhà cung cấp — nó thấy từng frame âm thanh và từng xác nhận commit với độ trễ bằng không — và đơn giản là từ chối chuyển tiếp bất kỳ commit nào mà nhà cung cấp chắc chắn sẽ từ chối. Lớp này bảo vệ mọi phiên bản client cùng một lúc, kể cả người dùng chưa cập nhật.
Chúng tôi thấy nó hoạt động trên production trong vòng một giờ. Lớp chắn đã chặn những commit chắc chắn thất bại mang theo 178ms và 256ms âm thanh trong buffer — mỗi cái, trước ngày hôm đó, đồng nghĩa với một lần rớt kết nối chắc chắn và một khoảng trống trong ghi chú cuộc họp của ai đó. Một phiên liên tục 60 phút chiều hôm ấy ghi nhận năm lần chặn và không một lần rớt. Trước bản sửa, một người dùng thật ngay sáng hôm đó đã phải khởi động lại bản ghi âm năm lần trong sáu phút để vật lộn với đúng con bug này.
Hai bản sửa nhỏ đi kèm
AI insights giờ chờ đến khi có nội dung thực chất. Những mảnh văn bản nhiễu ở đầu phiên trước đây được đưa vào các thẻ gợi ý trực tiếp của GeekBye, và chúng tự tin đẻ ra những chủ đề như "Defining Life's Ultimate Purpose" (Định nghĩa mục đích tối thượng của cuộc đời) từ một câu hỏi C++ bị nghe nhầm. Gợi ý giờ chờ đến khi phiên đã tích lũy đủ lượng hội thoại thực sự.
Văn bản khôi phục được gán đúng người nói. Bước khôi phục từng phiên âm đúng câu hỏi C++ của chúng tôi lại gán nó cho "Them" (đối phương). Dòng thời gian âm thanh lưu cục bộ giờ ghi lại ai đang nói, nên các phân đoạn khôi phục được gán đúng cho You hoặc Them.
Bảng điểm
| Chỉ số (đo thực tế, không ước lượng) | Trước | Sau v2.0.11 + lớp chắn backend |
|---|---|---|
| Số lần rớt kết nối trong phiên test | 3 trong 163s | 0 |
| Lỗ hổng phiên âm dài nhất | 51s | khoảng trống tệ nhất ~6s khi kiểm chứng |
| "pointer in C++" | "point in life" | đúng, với từ vựng đã được bias |
| Commit chắc chắn thất bại đến được nhà cung cấp | tất cả | 0 (bị chặn ở backend) |
Nếu bạn đang xây dựng trên các API giọng nói realtime
Ba bài học có thể mang đi từ bản phát hành này:
- Hãy cho tính năng biasing ăn. Nếu nhà cung cấp STT của bạn hỗ trợ keyterms/phrase hints, việc nạp vào một bộ từ vựng nhỏ và có tính đặc trưng là món lợi độ chính xác rẻ nhất bạn có thể kiếm — còn nạp vào những từ phổ thông là một khoản lỗ độ chính xác.
- Đừng bao giờ đua với state machine của chính nhà cung cấp từ phía bất lợi của một vòng round-trip mạng. Client của chúng tôi không thể thắng cuộc đua thông tin 250ms-đối-3s. Lớp chắn phải nằm ở nơi cả hai tín hiệu hội tụ — với chúng tôi, đó là backend proxy.
- Kiểm chứng trên bản build thật trước khi phát hành. Lỗi hồi quy keyterms bị bắt được vì mọi bản phát hành GeekBye đều được test dưới dạng bản build đã ký và notarize, chạy với production, trước khi xuất xưởng. Phiên bản lỗi chỉ tồn tại vài giờ trên một máy nội bộ, không phải trên chiếc Mac của bạn.
GeekBye v2.0.11 đã phát hành — nếu bạn đang dùng v2, bạn đã có nó qua auto-update. Về nền móng độ tin cậy mà bản phát hành này xây tiếp lên, xem vì sao AI notetaker của bạn dừng lại khi Wi-Fi chập chờn và những gì thay đổi trong GeekBye v2. Còn về cách phiên âm trực tiếp hoạt động hàng ngày, hãy bắt đầu với phiên âm thời gian thực trong GeekBye.
