Cách chúng tôi xây dựng hệ thống thời gian thực cho AI thoại phản hồi nhanh trong sáu tháng

Với AI thoại, biết khi nào nên lên tiếng khó hơn nhiều so với tưởng tượng. Con người có thể dễ dàng chuyển lượt cho nhau chỉ trong tích tắc, nhưng các hệ thống AI thoại trước đây không theo kịp nhịp điệu này. Kiến trúc theo lượt của chúng dựa vào các mô hình nhỏ gọi là bộ phát hiện lượt, vốn phải thực hiện một nhiệm vụ đầy khó khăn: đoán quá sớm thì người dùng bị ngắt lời; đoán quá muộn thì phản hồi trở nên chậm chạp. Chỉ sau khi bộ phát hiện đưa ra quyết định, LLM lớn hơn nhiều mới có thể bắt đầu xử lý.

GPT‑Live⁠, hệ thống thoại thế hệ thứ ba của chúng tôi, loại bỏ bộ phát hiện lượt khỏi đường truyền âm thanh. Mô hình thoại của hệ thống là song công toàn phần, nghĩa là có thể nghe và nói cùng lúc. Điều này loại bỏ nhu cầu dùng bộ phát hiện riêng và giúp cuộc trò chuyện tức thời, tự nhiên hơn. Khi cần suy luận sâu hơn hoặc sử dụng công cụ, GPT‑Live cũng có thể tham vấn các mô hình tiên phong của chúng tôi, chẳng hạn GPT‑5.5, mà không làm gián đoạn mạch trò chuyện. Kết hợp lại, các khả năng này mang đến cho GPT‑Live sự hòa quyện chưa từng có giữa tốc độ phản hồi trong hội thoại và độ thông minh.

Để cung cấp trải nghiệm này ở quy mô lớn, chúng tôi cần một kiến trúc hệ thống mới được tối ưu hóa cho độ trễ thấp. Khác với suy luận yêu cầu-phản hồi thông thường, hệ thống của chúng tôi truyền trực tiếp âm thanh đầu vào đến mô hình thoại và lời nói đầu ra trở lại người dùng, đồng thời xử lý việc ủy quyền trên một đường bất đồng bộ riêng. Trong sáu tháng qua, chúng tôi đã thiết kế lại hoạt động suy luận của mô hình, quản lý ngữ cảnh và vận chuyển phương tiện để lời nói luôn lưu chuyển mượt mà từ đầu đến cuối.

Kiến trúc này cũng tạo ra ranh giới rõ ràng giữa đường truyền thoại cốt lõi và logic ứng dụng. Nhờ đó, hành vi ứng dụng có thể dễ dàng tùy chỉnh mà không ảnh hưởng đến tốc độ phản hồi. Nền tảng này vận hành ngày càng nhiều khả năng trong ChatGPT Thoại, bao gồm tính năng mới ra mắt cho phép điều khiển máy tính và phối hợp các tác nhân trong ứng dụng ChatGPT dành cho máy tính.

Trong bài viết này, chúng tôi sẽ giải thích vì sao các hệ thống theo lượt trước đây không đáp ứng được nhu cầu và cách chúng tôi xây dựng hệ thống mới để phản hồi nhanh ở mọi lớp. Chúng tôi sẽ đề cập đến suy luận có trạng thái, quản lý ngữ cảnh động, ủy quyền bất đồng bộ và tối ưu hóa ở cấp giao thức—tất cả phối hợp để GPT‑Live thực sự mang cảm giác trực tiếp.

Các kiến trúc thoại trước đây kế thừa tính chất theo lượt của LLM văn bản, nhưng mỗi lượt được biểu diễn dưới dạng một khối âm thanh riêng biệt thay vì văn bản. Trong các hệ thống phân tầng, chuyển giọng nói thành văn bản, LLM và chuyển văn bản thành giọng nói lần lượt chạy nối tiếp. Trình tự này làm tăng độ trễ và bỏ qua các tín hiệu như ngữ điệu và nhịp nói.

Các mô hình giọng nói thành giọng nói cải thiện phương pháp này bằng cách xử lý âm thanh trực tiếp. Việc huấn luyện mô hình để hiểu và tạo lời nói một cách tự nhiên giúp mô hình giữ lại các chi tiết bị mất khi chép lời và phản hồi nhanh hơn. Tuy vậy, hệ thống vẫn dựa vào bộ phát hiện lượt để quyết định thời điểm có thể bắt đầu suy luận. Mô hình đảm nhiệm nhiều phần tương tác hơn, nhưng quá trình tương tác vẫn diễn ra theo lượt.

GPT‑Live trao quyền điều khiển cuộc trò chuyện cho mô hình thoại: âm thanh truyền vào và ra khỏi mô hình, còn quá trình suy luận sâu hơn cùng hoạt động sử dụng công cụ diễn ra bất đồng bộ. Nhiệm vụ chính của hệ thống là duy trì một vòng lặp phương tiện không gián đoạn. Các tác vụ khác, như gọi mô hình tiên phong và duy trì cuộc trò chuyện, diễn ra ngoài đường truyền trực tiếp.

Không phải lúc nào cũng dễ duy trì vòng lặp phương tiện này mà không bị gián đoạn. Bất kỳ độ trễ nào trong quá trình vận chuyển, xử lý hoặc suy luận đều có thể trở thành khoảng ngừng hay tạp âm mà người dùng nghe thấy. Hệ thống theo lượt trước đây có thể chấp nhận một chút biến động về thời điểm khối âm thanh đến nơi. Tuy nhiên, hệ thống phương tiện trực tiếp phải phân phối mọi khung âm thanh đúng lịch.

Những công việc trước đây về ChatGPT Thoại và API Realtime đã tạo cho chúng tôi một nền tảng quan trọng. Chúng tôi đã xây dựng lại hạ tầng thoại⁠ để truyền phát âm thanh và video trực tiếp vào và ra khỏi hệ thống với độ trễ thấp hơn, ổn định hơn. GPT‑Live đưa thiết kế này tiến xa hơn khi truyền phương tiện đến tận mô hình qua một hệ thống suy luận có trạng thái mới, được xây dựng cho hội thoại liên tục.

Tuy vậy, suy luận dạng truyền phát chỉ là một phần của giải pháp. Để giải pháp vận hành tốt trong môi trường thực tế, chúng tôi còn phải bảo đảm âm thanh được truyền ổn định từ máy khách đến ngăn xếp suy luận và giải quyết các thách thức của trạng thái được duy trì.

Một quyết định ban đầu của chúng tôi là tách riêng luồng phương tiện khỏi logic ứng dụng và nghiệp vụ. Âm thanh di chuyển giữa máy khách và mô hình thoại trên một đường truyền nhanh chuyên dụng. Hoạt động ủy quyền, sử dụng công cụ và các tác vụ ứng dụng khác diễn ra phía sau một ranh giới RPC bất đồng bộ. Một lệnh gọi công cụ hoặc dịch vụ backend chậm có thể làm trễ kết quả của chính nó nhưng không thể chặn luồng phương tiện.

Sự phân tách này cũng tạo cho hệ thống một ranh giới rõ ràng để tùy chỉnh. Các ứng dụng có thể thay đổi công cụ, chính sách và hành vi backend mà không ảnh hưởng đến frontend phương tiện chịu trách nhiệm duy trì luồng âm thanh. Đường truyền trực tiếp vẫn gọn nhẹ, dễ dự đoán và tập trung vào những tác vụ bắt buộc phải diễn ra theo thời gian thực.

Chúng tôi viết frontend phương tiện và logic suy luận bằng Go, thay thế cách triển khai trước đây bằng asyncio của Python. Điều này cải thiện đáng kể độ mượt khi phân phối khung dữ liệu: p95 của hệ thống mới tương đương p50 của hệ thống cũ.

WebRTC cung cấp nền tảng vận chuyển. WebRTC được thiết kế cho phương tiện có độ trễ thấp và có thể tiếp tục hoạt động khi mất gói tin, lệch đồng hồ hoặc kết nối máy khách thay đổi. Nếu gói tin đến muộn, WebRTC có thể kéo giãn âm thanh một cách tinh tế để tránh khoảng trống, rồi tăng tốc phát trong thời gian ngắn để bắt kịp thời gian thực.

Bằng cách giảm thiểu việc tạo bộ đệm và chặn trên toàn hệ thống, chúng tôi có thể đạt tốc độ phản hồi dưới một giây mà con người mong đợi trong hội thoại.

Suy luận có trạng thái đi kèm những đánh đổi riêng trong vận hành. Một phiên thoại có thể hoạt động rất lâu, nhưng ngữ cảnh của phiên liên tục tăng, còn các phiên bản mô hình được khởi động và dừng theo nhu cầu.

Để giải quyết những vấn đề này, chúng tôi xây dựng cơ chế bàn giao liền mạch giữa các phiên bản mô hình. Khi cần chuyển đổi, chúng tôi có thể khởi động sẵn một phiên bản mô hình thay thế song song với phiên bản hiện tại, nạp trước ngữ cảnh phiên hiện hành, chạy suy luận đồng thời trên cả hai rồi chuyển sang phiên bản mới khi nó hoàn toàn sẵn sàng.

Cơ chế cơ bản này cũng hỗ trợ nén ngữ cảnh động. Khi cuộc trò chuyện kéo dài, ngữ cảnh tích lũy cuối cùng có thể vượt quá giới hạn ngữ cảnh của mô hình. Nén ngữ cảnh có thể thu nhỏ ngữ cảnh để nằm trong giới hạn, nhưng thao tác này cần thời gian. Ngoài ra, vì làm thay đổi ngữ cảnh trước đó, thao tác này còn khiến bộ nhớ đệm khóa-giá trị (KV) của mô hình mất hiệu lực. Bộ nhớ đệm này lưu khóa và giá trị chú ý từ các token đã xử lý trước đó. Việc xây dựng lại trạng thái đó đòi hỏi một lần nạp trước mới, làm phát sinh thêm độ trễ.

Thay vào đó, chúng tôi coi nén ngữ cảnh là một quá trình chuyển đổi có quản lý khác. Trong khi phiên bản mô hình ban đầu tiếp tục trò chuyện, hệ thống nén ngữ cảnh và chuẩn bị một phiên bản mô hình thay thế với ngữ cảnh mới. Khi phiên bản đó sẵn sàng, chúng tôi có thể chuyển sang mà không làm gián đoạn luồng phương tiện. Nhờ đó, hệ thống có thể hỗ trợ các cuộc gọi kéo dài và nén ngữ cảnh bất cứ khi nào cần.

Các tác vụ nặng được tách khỏi đường truyền trực tiếp, vì vậy cuộc trò chuyện vẫn luôn liền mạch ngay cả khi đang bàn giao.

Khả năng gọi các mô hình tiên phong hiện có mang lại cho GPT‑Live sức mạnh đáng kể, nhờ tách biệt hiệu quả việc “trò chuyện” khỏi quá trình “suy nghĩ” sâu hơn. Tuy nhiên, để kiến trúc hai mô hình này mang lại cảm giác như một hệ thống thống nhất, chúng tôi phải giải quyết hai bài toán kỹ thuật liên quan.

Trước hết, kết quả phải trở về đủ nhanh để hữu ích cho cuộc trao đổi đang diễn ra. Vì vậy, chúng tôi phải giảm thiểu độ trễ trên toàn bộ đường ủy quyền, từ định tuyến và xử lý câu lệnh đến suy luận và gọi công cụ. Đồng thời, các hệ thống khác trong sản phẩm vẫn cần những thông điệp riêng biệt, nên chúng tôi phải biểu diễn cuộc trò chuyện đang diễn ra dưới dạng mà chúng có thể hiểu.

Khi gửi một yêu cầu ủy quyền, chúng tôi tối ưu thời gian cho đến khi mô hình tiên phong tạo ra nội dung hữu ích cho cuộc trò chuyện. Mô hình thoại có thể duy trì cuộc trao đổi trong thời gian ngắn khi mô hình tiên phong suy luận hoặc sử dụng công cụ, nhưng không thể che giấu một phản hồi chậm vô hạn. Do đó, chúng tôi tính toàn bộ vòng lặp ủy quyền—định tuyến, xử lý câu lệnh, suy luận và gọi công cụ—vào ngân sách thời gian phản hồi.

Bước tối ưu đầu tiên là thiết lập sẵn mô hình tiên phong và mọi công cụ cần thiết trước khi có yêu cầu ủy quyền. Khi một phiên thoại bắt đầu, máy chủ ứng dụng tạo phiên suy luận cho mô hình tiên phong và nạp trước ngữ cảnh hội thoại ban đầu, bảo đảm câu lệnh được xử lý đầy đủ trước yêu cầu ủy quyền đầu tiên.

Sau đó, chúng tôi duy trì phiên suy luận đó trong suốt cuộc trò chuyện thoại và dùng cơ chế liên kết phiên ổn định cho các yêu cầu kế tiếp. Kết hợp với việc lưu câu lệnh vào bộ nhớ đệm, các kỹ thuật này cải thiện độ trễ mà vẫn giúp hệ thống dễ dàng phục hồi khi worker gặp lỗi.

Mức độ suy luận, giới hạn đầu ra, lược đồ công cụ và số lượt trao đổi giữa mô hình với công cụ cũng ảnh hưởng đến thời điểm cuộc trò chuyện nhận được kết quả hữu ích; chúng tôi đã điều chỉnh các yếu tố này để phản hồi nhanh hơn. Bằng cách giảm thiểu công việc cần thực hiện trên đường ủy quyền, chúng tôi giúp mô hình thoại nhanh chóng đưa kết quả từ các mô hình tiên phong vào cuộc trò chuyện.

Mặc dù mô hình thoại xử lý các luồng lời nói liên tục, nhiều hệ thống xung quanh vẫn hoạt động theo lượt của người dùng và trợ lý, bao gồm giao diện hội thoại của ChatGPT cùng một số phần trong hạ tầng phân tích và an toàn. Vì vậy, máy chủ ứng dụng phân tách cuộc trò chuyện có phần chồng lấn và đôi khi mơ hồ thành các thông điệp riêng biệt.

Khi âm thanh truyền đến, máy chủ dùng bản chép lời tạm thời và tín hiệu thời gian để xác định người đang giữ lượt nói rồi tạo hàng đợi thông điệp. Thông điệp mới nhất vẫn chỉ là tạm thời; nội dung, thời gian và người nói được gán đều có thể thay đổi khi có thêm lời nói truyền đến. Khi một người đã giữ lượt nói đủ lâu để có thể xác định đáng tin cậy, máy chủ sẽ hoàn tất thông điệp tương ứng.

Việc người nói chồng lời khiến quá trình này phức tạp hơn. Một lời xác nhận ngắn của trợ lý khi người dùng đang nói (ví dụ: “ừm hửm” hoặc “ok”) không nhất thiết phải trở thành một thông điệp riêng. Tuy nhiên, một lời xen vào có nội dung đáng kể của trợ lý thường nên được tách riêng. Tương tự, chúng tôi ưu tiên tính mạch lạc của các phản hồi trợ lý được hiển thị, ngay cả khi người dùng nói xen vào.

Mọi chính sách phân đoạn đều phải đánh đổi giữa tính cập nhật và độ chắc chắn. Chốt quá sớm sẽ tạo ra lịch sử rời rạc và thứ tự thiếu ổn định; chờ quá lâu lại làm chậm bản chép lời cùng các tính năng phụ thuộc vào đó. Do đó, hệ thống duy trì hai góc nhìn liên quan về cuộc trò chuyện: một góc nhìn dự kiến về trạng thái hiện tại và một bản ghi chính thức về những nội dung đã được nói. Khung hội thoại trong giao diện ứng dụng có thể xử lý các bản cập nhật nên sử dụng góc nhìn dự kiến. Tuy nhiên, việc ghi nhật ký vào quy trình phân tích đòi hỏi bản chép lời hoàn chỉnh.

Nhờ đó, các phần còn lại của ChatGPT có được góc nhìn ổn định về cuộc trao đổi mà không áp đặt cơ chế theo lượt lên đường truyền thoại trực tiếp.

Khả năng phản hồi nhanh bắt đầu ngay khi người dùng nhấp vào nút. Với GPT‑Live, hệ thống phải thiết lập đường truyền phương tiện và bắt đầu đưa âm thanh qua mô hình trước khi cuộc trò chuyện có thể bắt đầu. Do đó, mọi phần của trình tự khởi động đều nằm trên đường găng.

Như đã nêu ở trên, WebRTC cung cấp nền tảng thời gian thực vững chắc, nhưng việc khởi động một phiên WebRTC thông thường đòi hỏi số lần bắt tay giao thức và lượt khứ hồi qua mạng nhiều đến bất ngờ. WebRTC ra đời trước khi trọng tâm giảm thiểu lượt khứ hồi định hình các giao thức sau này như QUIC. Do đó, các giao thức nền tảng đôi khi lặp lại công việc khi được dùng cùng nhau. Ví dụ, mỗi giao thức đều có cơ chế chống DoS riêng, ngay cả khi cơ chế đó không cần thiết trong ngữ cảnh của toàn bộ ngăn xếp WebRTC.

Chúng tôi đã phân tích ngăn xếp và phát triển WebRTC Abridged Roundtrip Protocol (WARP⁠(mở trong cửa sổ mới)), giúp giảm thời gian khởi động phương tiện và dữ liệu từ sáu lượt khứ hồi qua mạng xuống chỉ còn một. WARP làm được điều này nhờ một loạt cải tiến giao thức tương thích ngược: ghép quy trình bắt tay DTLS vào ICE (SPED⁠(mở trong cửa sổ mới)), sử dụng quy trình bắt tay DTLS 1.3⁠(mở trong cửa sổ mới) nhanh hơn, thương lượng trước quy trình bắt tay SCTP (SNAP⁠(mở trong cửa sổ mới)) và thương lượng trước các kênh dữ liệu thay vì dùng DCEP⁠(mở trong cửa sổ mới).

Chúng tôi thiết kế WARP dưới dạng một bộ đặc tả mở và hợp tác với các thành viên trong cộng đồng WebRTC để hệ sinh thái rộng lớn hơn có thể hưởng lợi từ công trình này. Chúng tôi đang thúc đẩy các đề xuất thông qua nhóm công tác TSVWG của IETF. Cả libwebrtc và Pion đều đã được bổ sung hỗ trợ WARP, trong khi các nỗ lực triển khai trên những nền tảng WebRTC khác đang được tiến hành.

Sau khi tối ưu quy trình bắt tay phương tiện, vẫn còn một độ trễ đáng chú ý: hoạt động trao đổi tín hiệu để chia sẻ tham số SDP trước khi WebRTC có thể kết nối. Để loại bỏ hoạt động trao đổi đó khỏi đường găng, chúng tôi phát triển cơ chế gọi là Kết nối tức thì. Cơ chế này thương lượng trước các tham số mà không cần dành sẵn năng lực máy chủ và không yêu cầu thay đổi bất kỳ cách triển khai WebRTC hiện có nào.

Kết nối tức thì chạy song song với luồng báo hiệu tiêu chuẩn. Nếu các tham số thương lượng trước hợp lệ, máy chủ có thể khởi tạo phiên khi gói phương tiện đầu tiên truyền đến. Nếu các tham số đã lỗi thời hoặc không hợp lệ, luồng báo hiệu đã được tiến hành nên máy khách có thể chuyển sang phương án dự phòng mà không phát sinh thêm độ trễ.

Kết hợp lại, Kết nối tức thì và WARP rút ngắn đáng kể thời gian từ lúc người dùng thể hiện ý định đến khi luồng phương tiện trực tiếp bắt đầu. Khi hoạt động trao đổi SDP được tách khỏi đường găng và WARP thu gọn quy trình bắt tay vận chuyển, máy khách giờ đây có thể khởi động một phiên chỉ bằng một gói UDP. Máy chủ có thể phản hồi ngay lập tức, cho phép phần còn lại của hệ thống bắt đầu thực hiện công việc người dùng thực sự quan tâm: lắng nghe và trả lời.

Một hệ thống có thể trông rất nhanh trên lý thuyết nhưng vẫn đình trệ khi xử lý lưu lượng thoại thực tế. Trước khi để GPT‑Live trò chuyện với người dùng, chúng tôi đã tiến hành một thử nghiệm ngầm, chuyển một tỷ lệ nhỏ và tăng dần các phiên ChatGPT Thoại thực tế đến cả trải nghiệm chế độ thoại nâng cao hiện có lẫn hệ thống mới. Chế độ thoại nâng cao vẫn phục vụ người dùng như thường lệ, còn luồng chạy ngầm thực hiện suy luận ở chế độ chỉ đọc. Nhờ đó, hệ thống được thử nghiệm với máy khách, mạng, thời lượng phiên và phân bố địa lý thực tế mà không làm thay đổi nội dung người dùng nghe thấy.

Một trong những bài học đầu tiên là không thể chỉ đánh giá năng lực hệ thống qua thông lượng GPU. Các phiên thoại duy trì kết nối và liên tục gửi khung dữ liệu, vì vậy trình xử lý luồng phía CPU, hàng đợi và đường truyền mạng cũng phải mở rộng cùng với năng lực suy luận. Dưới tải thực tế, một thành phần hỗ trợ đã bão hòa sớm hơn dự báo từ thử nghiệm tải, khiến các yêu cầu suy luận dồn lại và độ trễ ngày càng chồng chất. Chúng tôi chuyển câu hỏi về năng lực từ “Một GPU có thể xử lý bao nhiêu yêu cầu?”” thành “Hệ thống có thể duy trì bao nhiêu phiên đồng thời mà vẫn xử lý mọi khung dữ liệu đúng lịch?””

Thử nghiệm này cũng cho thấy vị trí địa lý là yếu tố cần ưu tiên hàng đầu. Việc định tuyến một phiên đến tài nguyên ở xa có thể làm tăng độ trễ tại nhiều thời điểm trong quá trình khởi động và truyền phát. Chúng tôi bắt đầu xác thực các đợt triển khai mô hình cùng với năng lực theo khu vực và cấu hình điều hướng lưu lượng, rồi phân tích độ trễ theo vị trí địa lý của nguồn. Đưa hoạt động suy luận đến gần người dùng hơn đã mang lại hiệu quả, đồng thời củng cố một bài học lớn hơn: tốc độ phản hồi đầu cuối phụ thuộc vào mọi dịch vụ trên đường truyền, không chỉ máy chủ mô hình.

Một số lỗi khác chỉ xuất hiện trong vòng đời phiên thực tế. Các phiên kéo dài làm lộ rõ áp lực lên bộ nhớ và khả năng duy trì dữ liệu. Hoạt động kết nối lại kiểm nghiệm cơ chế nén ngữ cảnh và khôi phục trạng thái. Các lần ngắt kết nối thông thường của máy khách làm lộ ra tình trạng tranh chấp trong quy trình bắt tay khi tắt. Những vấn đề này hiếm khi xuất hiện trong các thử nghiệm tải ngắn vì chúng phụ thuộc vào thời gian, trạng thái tích lũy và hành vi xuyên qua ranh giới giữa các dịch vụ.

Cuối cùng, thử nghiệm trong môi trường thực tế buộc chúng tôi phải cải thiện khả năng quan sát và các biện pháp kiểm soát triển khai. Chúng tôi phát hiện các chỉ số gộp chung nhiều nguồn gây trễ, các bảng điều khiển có số liệu tổng hợp che khuất từng bộ máy đang gặp sự cố và sự sai lệch cấu hình giữa hệ thống được thử nghiệm với hệ thống đã triển khai. Để khắc phục, chúng tôi bổ sung dữ liệu đo từ xa chi tiết hơn, cơ chế xác thực dựa trên cấu hình đã được kiểm chứng, quy trình tăng tải theo giai đoạn và khả năng nhanh chóng cô lập hoặc vô hiệu hóa từng đường dẫn. Thử nghiệm ngầm trở thành một buổi diễn tập trước khi ra mắt, không chỉ để kiểm tra lượng lưu lượng hệ thống có thể tiếp nhận mà còn để đánh giá tốc độ phát hiện, khống chế và phục hồi sau sự cố.

Đưa GPT‑Live lên quy mô của ChatGPT đòi hỏi một hệ thống hoàn toàn mới, được xây dựng quanh một nguyên tắc nền tảng: luồng thoại phải luôn thông suốt. Suy luận dạng truyền phát liên tục cung cấp âm thanh cho mô hình song công toàn phần. Một đường truyền phương tiện chuyên dụng bảo đảm các khung dữ liệu được phân phối ổn định. Cơ chế ủy quyền bất đồng bộ cho phép quá trình suy luận sâu hơn diễn ra song song. Cơ chế vận chuyển được tối ưu hóa giúp trải nghiệm luôn phản hồi nhanh đến tận người dùng.

Kiến trúc phía sau GPT‑Live đang dần trở thành một nền tảng rộng hơn cho hoạt động tương tác thời gian thực. Kiến trúc này vận hành ChatGPT Thoại khi sản phẩm mở rộng từ trò chuyện sang điều phối có tính tác nhân, đồng thời sẽ làm nền tảng cho GPT‑Live API sắp ra mắt. Theo thời gian, kiến trúc này sẽ giúp trải nghiệm thoại mở rộng sang nhiều thiết bị, ứng dụng và phương thức hơn mà không làm mất đi tính tức thời khiến cuộc trò chuyện bằng giọng nói trở nên sống động.

Nếu đây là những bài toán kỹ thuật bạn muốn giải quyết, hãy đến làm việc cùng chúng tôi⁠.