Eleven Realtime đưa cuộc đua AI giọng nói vượt ra ngoài chất giọng

Bản xem trước chính thức thành phần hội thoại giọng nói ElevenLabs UI cho hỗ trợ khách hàng. Nguồn: elevenlabs/ui; bản quyền 2025 Eleven Labs Inc., giấy phép MIT. Hình minh họa giao diện giọng nói, không phải kiểm thử mô hình Realtime.

Khoảnh khắc khó xử trong cuộc hội thoại bằng giọng nói thường đến trước cả câu trả lời. Bạn ngừng một chút để nhớ ngày, trợ lý đã bắt đầu nói. Bạn sửa lại một cái tên, nhưng nó vẫn nói hết câu đã chuẩn bị. Chất giọng có thể rất hay mà cuộc trao đổi vẫn thiếu hợp tác một cách lạ lùng. Với người xây dựng trợ lý điện thoại, gia sư hay nhân vật tương tác, những lỗi nhỏ ấy có thể quan trọng không kém chất lượng tiếng nói được tạo ra.

Ngày 20 tháng 10, ElevenLabs giới thiệu Eleven Realtime v1 Mini và v1 Max, định vị chúng là mô hình tác nhân giọng nói hoàn chỉnh thay vì thêm một thành phần để lập trình viên tự lắp ghép. Mini hướng tới hội thoại thường ngày với chi phí thấp hơn; Max dành cho chỉ dẫn phức tạp và công việc nhiều bước. Lần ra mắt đáng chú ý vì gom nhiều quyết định về hội thoại vào một lựa chọn sản phẩm. Nó cũng khiến một câu hỏi cũ khó né tránh hơn: khi giọng nói nghe có vẻ thành thạo, làm sao biết việc đã thực sự xong? Thông báo chính thức.

Theo chúng tôi, điểm hứa hẹn là giảm thời gian tinh chỉnh các chỗ nối giữa thành phần. Phép thử cho lời hứa đó là một cuộc hội thoại vượt qua các lần sửa thông tin và cho kết quả đúng. Bản trình diễn trau chuốt thể hiện ấn tượng ban đầu. Một yêu cầu khách hàng bình thường, lộn xộn mới là nơi sản phẩm chứng minh giá trị.

ElevenLabs mở rộng thế mạnh quen thuộc sang một công việc lớn hơn

Với độc giả chủ yếu biết ElevenLabs qua giọng nói tổng hợp, hiện công ty mô tả ba nền tảng: ElevenCreative để sáng tạo nội dung, ElevenAgents để triển khai tác nhân hội thoại và ElevenAPI dành cho lập trình viên. Realtime nằm trong nỗ lực rộng hơn nhằm đưa âm thanh vào bên trong ứng dụng, thay vì chỉ cung cấp tệp âm thanh hoàn chỉnh. Bối cảnh đó giải thích vì sao lần ra mắt kết hợp chất lượng giọng nói với cơ chế tương tác. Thông tin báo chí của ElevenLabs.

Một đoạn âm thanh có ranh giới rõ ràng. Văn bản được viết, lời nói được tạo, người nghe tiếp nhận kết quả. Tác nhân trực tiếp hoạt động trong tình huống liên tục thay đổi. Người nghe có thể ngắt lời, đổi câu hỏi, bổ sung thông tin hoặc phát hiện yêu cầu ban đầu đã sai. Phần mềm phải quyết định khoảng dừng nghĩa là “đến lượt bạn” hay “tôi vẫn đang nghĩ”. Nó vừa phải theo sát cách hiểu của con người vừa làm việc với các hệ thống phía sau cuộc hội thoại.

Đây là bài toán sản phẩm khác với việc làm một câu riêng lẻ nghe thuyết phục. Hãy nghĩ đến trợ lý đặt lịch. Nó có thể phát âm tên khách hoàn hảo nhưng vẫn đặt nhầm ngày vì bỏ lỡ lời sửa. Sản phẩm giọng nói thành công cần cả nhịp tương tác xã hội lẫn bản ghi giao dịch hợp lý. Chỉ cải thiện một mặt tạo ra một cách dễ chịu để làm sai việc.

Đồ họa thông tin biên tập do chúng tôi thiết kế. Hình mô tả trải nghiệm người dùng, không phải kiến trúc bên trong mô hình.

Kiến trúc được quản lý giảm cấu hình và thay đổi phần bạn kiểm soát

Sự phân biệt trong tài liệu rất thực tế. Ở chế độ Custom, người xây dựng chọn mô hình ngôn ngữ, mô hình giọng nói và cấu hình nhận dạng. Chế độ Realtime giao các lựa chọn đó cho ElevenLabs, đồng thời giữ chỉ dẫn tác nhân, giọng nói, công cụ và những thiết lập hội thoại được hỗ trợ khác. Quyền truy cập đang được mở dần, nên tùy chọn có thể chưa xuất hiện trong mọi không gian làm việc. Realtime còn có ràng buộc tương thích và khu vực mà tác nhân hiện hữu phải đáp ứng. Tài liệu mô hình Realtime.

Sự đánh đổi này có thể hữu ích. Một nhóm nhỏ có thể quan tâm đến việc trợ lý xử lý ngắt lời hơn nhiều so với lựa chọn từng thành phần nền tảng. Cấu hình được quản lý tạo điểm xuất phát nhất quán và ít tổ hợp phải chẩn đoán hơn. Nhóm có thể tập trung vào câu hỏi của khách, thông tin doanh nghiệp thực sự có và thời điểm cần người tiếp quản.

Tuy nhiên, ít thiết lập hơn cũng đồng nghĩa ít khả năng thay thế độc lập. Nếu một hành vi không phù hợp, nhóm cần biết có thể chỉnh nó, đổi mô hình hay quay lại cấu hình tùy biến không. Phép so sánh đúng là tổng công sức duy trì một tác nhân dùng được. Kiến trúc nhiều tùy chỉnh có thể nặng nề, còn kiến trúc tích hợp có thể gò bó. Chi phí nào đáng kể tùy vào công việc và người vận hành sau buổi trình diễn.

Điều này đặc biệt quan trọng khi nguyên mẫu trở thành dịch vụ dùng chung. Người lắp nguyên mẫu có thể hiểu mọi đặc tính của nó. Nhóm hỗ trợ, khách hàng và lập trình viên kế tiếp sẽ trải nghiệm hành vi mà không có hiểu biết nền ấy. Sản phẩm xử lý nhất quán các lựa chọn thường gặp vẫn có giá trị dù ít lựa chọn hơn. Tính nhất quán hữu ích khi nhìn thấy được, kiểm tra được và phù hợp với trách nhiệm của dịch vụ.

Các kiến trúc giọng nói khác đặt quyền kiểm soát ở nơi khác nhau

Đặt cạnh phương án thay thế sẽ thấy rõ hơn cách tiếp cận của ElevenLabs. Hướng dẫn tác nhân giọng nói của OpenAI phân biệt tương tác tiếng nói thời gian thực với luồng nối tiếp: chuyển lời nói thành văn bản, chạy tác nhân văn bản rồi tạo tiếng nói. Phần về luồng nối tiếp nhấn mạnh khả năng xem văn bản trung gian và thay từng thành phần. Đây là so sánh kiến trúc, không phải bằng chứng về cấu trúc chưa công bố của Eleven Realtime. Cùng một tương tác khách hàng có thể được xây quanh những điểm quan sát và can thiệp khác nhau.

Giai đoạn văn bản có giá trị khi tổ chức cần một điểm kiểm tra cụ thể. Dịch vụ đào tạo có thể xem tác nhân hiểu câu trả lời của học viên thế nào; bộ phận hỗ trợ chuyên môn có thể xử lý thuật ngữ trước khi phát lời đáp. Bản ghi trung gian cho nhóm một thứ rõ ràng để kiểm tra. Nó cũng thêm một ranh giới thành phần cần duy trì. Với nhân vật sinh động hoặc hội thoại khám phá, người xây dựng có thể thích tương tác tích hợp hơn và chấp nhận bộ điều khiển khác.

Yếu tố quyết định là nhóm cần điểm kiểm tra đáng tin cậy ở đâu: bản chép lời trung gian, sự kiện hội thoại hay hành động đã hoàn thành. Điều đó giải thích vì sao giữ hệ thống tùy biến vẫn có thể hợp lý dù xuất hiện sản phẩm tích hợp đầy hứa hẹn. Cơ hội thương mại của ElevenLabs là làm phương án được quản lý đủ tốt cho nhiều việc hơn, để lắp ghép chi tiết trở thành lựa chọn thay vì vé vào cửa khi xây dịch vụ giọng nói.

Do dự và ngắt lời cần những phản ứng khác nhau

Góc nhìn framework bổ sung một chiều khác. Tài liệu xử lý lượt nói của LiveKit coi ngắt lời giả là hành vi cần xử lý riêng: hoạt động âm thanh có thể làm tác nhân dừng dù không tạo ra bản chép lời người dùng, và tiếng nói có thể tiếp tục sau khoảng chờ cấu hình. Điều này không khẳng định ElevenLabs dùng cùng cơ chế. Nó cho thấy sự lịch sự của sản phẩm giọng nói phụ thuộc vào hành vi ứng dụng lẫn mô hình cung cấp lời nói.

Hãy so sánh người nói “đợi đã, địa chỉ khác cơ” với người ho khi đang nghe. Cả hai đều phát âm thanh trong lượt nói của trợ lý. Chỉ một trường hợp nhất thiết thay đổi yêu cầu. Dịch vụ bắt đầu lại phần giải thích sau mỗi tiếng động nền sẽ gây mệt; dịch vụ bỏ qua lời sửa thật sẽ khó tin cậy. So sánh hữu ích là hội thoại phục hồi với đúng ngữ cảnh hay không, thay vì kênh âm thanh phát hiện hoạt động nhanh đến đâu.

Sự phân biệt ấy cũng mở rộng nhóm người cần tham gia thử nghiệm. Người đang tìm từ lạ, nói ngôn ngữ thứ hai hoặc có nhịp nói chậm có thể cần khoảng im lặng khác nhau. Đây là đề xuất về nhóm đánh giá, không phải tuyên bố về khả năng tiếp cận hay phạm vi ngôn ngữ đã đo. Nhóm nên nghe xem người dùng có đủ thời gian nói hết và có phải lặp lại cả yêu cầu để khôi phục cuộc trao đổi không. Điểm tốc độ phản hồi trung bình có thể che mất gánh nặng đó.

Khả năng đáng kỳ vọng là mô hình hội thoại được quản lý cải thiện trải nghiệm mà mỗi khách hàng không phải tự viết logic canh thời gian. Câu hỏi còn lại là ứng dụng cụ thể chỉnh được bao nhiêu khi nhịp mặc định không phù hợp. Đây là câu hỏi sản phẩm có thể kiểm tra trong trình diễn: để người nói do dự, sửa chi tiết rồi tiếp tục, sau đó xem tác nhân hiểu gì và công cụ nhận gì. Nó nối sự thoải mái khi nói với kết quả nhóm kiểm chứng được.

Mini và Max tách hội thoại khỏi thực thi đòi hỏi cao

Hai tên gọi nên khuyến khích lựa chọn theo công việc, không phải phản xạ mua mô hình lớn hơn. Nhân vật luyện ngoại ngữ và tác nhân xử lý hoàn tiền đối mặt bài toán khác nhau. Bên thứ nhất cần giữ cuộc nói chuyện diễn ra và phản ứng phù hợp với lỗi. Bên thứ hai có thể cần tra chính sách, xác định đơn hàng, kiểm tra điều kiện và báo kết quả hành động bên ngoài.

Mô hình lớn có thể không cần thiết cho trao đổi nhẹ, trong khi mô hình rẻ có thể đắt nếu liên tục chuyển ca chưa giải quyết cho nhân viên. Chi phí mỗi phút hữu ích để ước tính hóa đơn. Chi phí mỗi tương tác hoàn tất đúng hữu ích hơn để quyết định hệ thống có phù hợp luồng công việc không. Con số sau gồm phục hồi, gọi lại và công sức con người sửa những lỗi nghe có vẻ hợp lý.

Đồ họa do chúng tôi thiết kế dựa trên định vị của nhà cung cấp. Đây không phải thứ hạng đo trên mọi ngôn ngữ hay nhiệm vụ.

Thông báo công bố kết quả benchmark được quy cho Artificial Analysis. Tỷ lệ hoàn thành tác vụ dùng công cụ là 87.1% với Max và 60.3% với Mini, còn điểm động lực hội thoại nghiêng nhẹ về Mini. Đây là benchmark do nhà cung cấp công bố, không phải số đo triển khai của chúng tôi. Thông điệp hữu ích là sự trôi chảy trong hội thoại và hoàn thành công cụ có thể khác nhau; chúng không xác lập tỷ lệ thành công cho các cuộc gọi của một doanh nghiệp cụ thể. Thông báo và bối cảnh benchmark.

Vì vậy, nhóm nên tránh gói toàn bộ chất lượng thành một vị trí trên bảng xếp hạng. Nếu tác nhân chủ yếu giải thích hiện vật bảo tàng, nhịp hội thoại có thể chi phối. Nếu cập nhật đặt chỗ, trạng thái cuối chính xác quan trọng hơn. Sản phẩm cung cấp hai điểm khởi đầu, nhưng công việc vẫn định nghĩa chất lượng.

Ba tình huống bình thường cho thấy những thế mạnh khác nhau

Hãy tưởng tượng học viên tập hội thoại nhà hàng bằng ngoại ngữ. Người học dừng giữa đơn gọi món, tìm một từ rồi bắt đầu lại. Gia sư hữu ích chừa chỗ cho sự do dự và hỗ trợ mà không chiếm lượt. Lợi ích là tự tin tiếp tục luyện tập. Thất bại là trợ lý xem mọi khoảng dừng như lời mời giảng dài. Ví dụ minh họa này chủ yếu nói về hợp tác hội thoại; chất lượng giảng dạy vẫn cần đánh giá riêng.

Giờ hãy xét dịch vụ đặt lịch. Người gọi ban đầu muốn thứ Sáu, rồi nói: “Thực ra là thứ Hai tuần tới, sau bữa trưa.” Trợ lý phải đưa thông tin sửa vào đề xuất đặt lịch và xác nhận chi tiết trước bước tạo hệ quả. Sau khi hệ thống đặt lịch trả lời, lời xác nhận cần phản ánh kết quả đó. Câu “xong rồi” thân thiện trước khi hệ thống chấp nhận thay đổi vẫn là lỗi dù mọi câu nói đều tự nhiên.

Nhân vật tương tác tạo thế cân bằng thứ ba. Nó có thể trả lời giàu tưởng tượng trong thế giới hư cấu, nhưng người chơi vẫn mong nó nhớ cảnh hiện tại và dừng khi bị ngắt. Kết quả kinh doanh có thể là trao đổi cuốn hút thay vì giao dịch hoàn tất. Hành vi làm nhân vật sống động có thể gây cảm giác né tránh trong hỗ trợ khách hàng. Đây là lý do phải đánh giá từng công việc, thay vì coi “tác nhân giọng nói” là một nhóm đồng nhất.

Tính tương thích giảm chi phí thử, kèm giới hạn cần đọc

ElevenLabs cung cấp truy cập qua ElevenAgents và Realtime API tương thích OpenAI. Ví dụ API trong thông báo thay đích kết nối và mô hình của ứng dụng hiện có, nhưng cũng nêu kết nối chỉ dùng WebSocket và API tách khỏi nền tảng được quản lý. Vì vậy, tích hợp WebRTC cần nhiều hơn đổi tên mô hình; không nên cho rằng các kênh được quản lý hay tính năng cơ sở tri thức tự đi kèm API. Truy cập API và ghi chú chuyển đổi.

Giá trị tương thích là so sánh dễ hơn. Lập trình viên giữ được nhiều phần ứng dụng hiện tại khi thử nhà cung cấp khác. Nhờ vậy có thể so cùng nhiệm vụ, chỉ dẫn và công cụ, thay vì những bản trình diễn chẳng liên quan. Nó không loại bỏ việc xem hành vi sự kiện, nối lại kết nối, phản hồi công cụ và cách ứng dụng hiển thị thất bại.

Những chi tiết ít hào nhoáng này tạo nên trải nghiệm khách hàng. Nếu kết nối rớt sau yêu cầu đặt lịch, ứng dụng phải biết việc đặt lịch đã xảy ra chưa trước khi bảo người gọi lặp lại. Nếu công cụ hết thời gian chờ, gọi lại công cụ có thể gây hệ quả khác với hỏi lại bằng lời. Chuyển mô hình thành công khi toàn bộ ứng dụng xử lý đúng những tình huống đó, không chỉ khi phát được âm thanh đầu tiên.

Giọng nói tự nhiên có thể khiến hành động dang dở nghe như đã xong

Hãy giữ điều kiện so sánh ổn định khi chọn mô hình. Nếu mô hình lớn có cơ sở tri thức sạch hơn, chỉ dẫn tốt hơn và công cụ ổn định hơn, thử nghiệm không thể giải thích thay đổi nào có ích. Bắt đầu với cùng yêu cầu đại diện và xem lỗi trước khi thay luồng xung quanh. Lỗi thời điểm có thể cần chỉnh hội thoại; trả lời sai chính sách có thể cần nguồn tốt hơn; đặt lịch dang dở có thể liên quan tích hợp công cụ. Mô hình mạnh hơn giúp được một số vấn đề, nhưng không nên che một kết nối hỏng vốn sẽ hỏng với cả hai lựa chọn.

Lợi thế mạnh nhất của sản phẩm cũng có thể làm lỗi khó nhận ra. Con người dùng giọng điệu, nhịp nói và sự tự tin làm tín hiệu giao tiếp. Trợ lý trôi chảy có thể nghe như đã kiểm tra, dù mới chỉ tạo phản hồi hợp lý. Trong giao diện văn bản, người dùng có nhiều cơ hội xem kỹ hơn. Khi gọi điện, cuộc hội thoại tiếp tục và chi tiết tranh cãi có thể trôi mất.

Cách thiết kế đáp lại nên cụ thể thay vì chỉ diễn đạt cho hay. Phân biệt giải thích, hành động đề xuất và kết quả xác nhận. Cho tác nhân nói rằng đang kiểm tra, yêu cầu còn chờ hoặc cần người hỗ trợ. Các trạng thái ấy phải khớp ứng dụng, không chỉ là lời trấn an trong chỉ dẫn. Một khoảng dừng trung thực thường mang lại dịch vụ tốt hơn câu trả lời tức thì tạo việc sửa sau đó.

Chuyển giao cho người cũng cần liên tục. Người gọi gặp nhân viên sau vài phút không nên phải nhớ và kể lại mọi chi tiết. Gói chuyển giao hữu ích gồm yêu cầu hiện tại, các lần sửa quan trọng và bước chưa giải quyết. Nó nên giữ nguyên chỗ tác nhân chưa chắc chắn. Nếu không, tự động hóa tiết kiệm thời gian đầu cuộc gọi nhưng đẩy cùng gánh nặng sang người xử lý cuối.

Khung đánh giá biên tập do chúng tôi thiết kế. Hình không biểu diễn kết quả thử nghiệm.

Benchmark tiếp theo là cuộc hội thoại đã giải quyết xong

Một thí điểm hợp lý sẽ dùng hội thoại đại diện với sự cho phép: yêu cầu ngắn và dài, ngắt lời, sửa thông tin, nhiều ngôn ngữ và ca cần chuyển người. Hãy xem hành động mong muốn có xảy ra không, con người phải can thiệp bao lần và tương tác hoàn tất tốn bao nhiêu. Giữ tốc độ phát âm đầu tiên như một chỉ số, nhưng cũng đếm câu trả lời nhanh rồi cần sửa. Đây là phương pháp đánh giá đề xuất, không phải thử nghiệm chúng tôi đã thực hiện với Realtime.

Kết quả hứa hẹn nhất là tác nhân hỏi ít câu thừa hơn mà vẫn sẵn sàng hỏi câu cần thiết. Gia sư nên để học viên nghĩ xong. Trợ lý đặt lịch nên xác minh ngày đã sửa. Tác nhân hỗ trợ nên chuyển tiếp ngữ cảnh. Những cải thiện ấy nghe nhỏ nhưng được cảm nhận rõ vì loại bỏ ma sát khiến hội thoại tự động trở nên mệt mỏi.

Eleven Realtime cho hướng đi đó một hình hài sản phẩm cụ thể. Nó có thể giúp nhiều nhóm tạo tương tác giọng nói hữu ích mà không cần chuyên sâu mọi thành phần âm thanh. Ý nghĩa dài hạn phụ thuộc vào việc hành vi hội thoại tích hợp có tạo công việc hoàn tất đáng tin cậy hay không. Giọng nói đưa người dùng vào cuộc trao đổi. Kết quả quyết định họ có muốn cuộc trao đổi tiếp theo.

---

Nguồn

• Thông báo Eleven Realtime và bối cảnh benchmark, ngày 20 tháng 10 năm 2026.

• Chế độ, triển khai và giới hạn mô hình Realtime, kiểm tra ngày 21 tháng 10 năm 2026.

• Thông tin nền tảng ElevenLabs, kiểm tra ngày 21 tháng 10 năm 2026.

• Kiến trúc tác nhân giọng nói OpenAI, kiểm tra ngày 21 tháng 10 năm 2026.

• Xử lý lượt nói của LiveKit, kiểm tra ngày 21 tháng 10 năm 2026.

Giữ cuộc hội thoại để xem lại

Nếu cần một nơi riêng để lưu các bản ghi âm bạn có quyền sử dụng và ghi chú đã xem xét, Telli.sh là một lựa chọn. Bắt đầu bằng ghi chú âm thanh.