Cân bằng giữa độ trễ thấp nhất và tính kinh tế của đám mây trong các tác nhân thoại ảo

Devin Reimer

Chào mừng bạn đến với bài viết Cân bằng giữa độ trễ thấp nhất và tính kinh tế của đám mây trong các tác nhân thoại ảo.

Tôi là Devin Reimer.

Tôi là nhà sáng lập kiêm Giám đốc điều hành của AstroBeam.

Trước đây, tôi là Giám đốc điều hành và đồng sáng lập của Owlchemy Labs, có lẽ nổi tiếng nhất với trò chơi Job Simulator.

Vì vậy, tại AstroBeam, chúng tôi tập trung vào việc xây dựng AI theo thời gian thực trong trò chơi.

Cụ thể, chúng tôi thực sự tập trung vào giọng nói làm phương thức nhập.

Đến nay, chúng tôi đã phát hành hai tựa game, trong đó có Stellar Cafe dành cho VR và máy tính.

Đây là một trò chơi mà bạn trò chuyện với robot trong một quán cà phê ở trạm vũ trụ và giúp họ giải quyết vấn đề.

Bạn có thể điều khiển hoàn toàn bằng giọng nói.

Bạn có thể phát toàn bộ nội dung, bao gồm cả trình đơn và thao tác điều hướng, chỉ bằng giọng nói.

Trò chơi tiếp theo của chúng tôi, Robo Detective, vừa được công bố hôm nay, được xây dựng cho Android XR và đặc biệt là Project Aura của XREAL.

Trong trò chơi này, bạn đóng vai một thám tử làm việc với một cộng sự robot để phỏng vấn các robot khác nhằm giải quyết các vụ án liên quan đến robot, và một lần nữa, trò chơi này hoàn toàn điều khiển bằng giọng nói.

Vì vậy, việc tạo ra các tác nhân giọng nói thực sự rất khó, và trong trò chơi, việc này thậm chí còn khó hơn.

Lý do là vì trò chơi có chi phí rất thấp, và tác nhân thoại hiện là một chi phí mới cần thêm vào quy trình đó.

Ngoài ra, chúng tôi không cạnh tranh với các tác nhân giọng nói khác, mà chúng tôi cạnh tranh với chất lượng của mọi trò chơi từng được tạo ra, đúng không?

Vì vậy, chúng tôi phải cung cấp chất lượng rất cao.

Điều đó không có nghĩa là không có trường hợp sử dụng tác nhân thoại cụ thể nào gặp phải thách thức riêng hoặc có rủi ro cao hơn nhiều, nhưng trò chơi chắc chắn là một lĩnh vực có nhiều thách thức về mặt kỹ thuật.

Tuy nhiên, cũng vì đây là trò chơi nên chúng ta có nhiều cơ hội thử nghiệm để tìm ra cách giải quyết một số vấn đề khó khăn này.

Vì vậy, tôi tin rằng nếu tác nhân thoại có thể hoạt động trong trò chơi, thì chúng có thể hoạt động ở hầu hết mọi nơi.

Vì vậy, những điều tôi đang nói trong bài nói chuyện này không chỉ áp dụng cho trò chơi mà còn cho bất kỳ ứng dụng ưu tiên giọng nói nào mà bạn muốn xây dựng.

Vì vậy, khi nghĩ về tác nhân thoại, tôi nghĩ có ba thách thức cốt lõi.

Vì vậy, chúng ta có độ trễ, trí thông minh và chi phí.

Tuy nhiên, có một điều tôi muốn làm rõ là khi nói về tác nhân thoại, tôi đang nói về tác nhân thoại dưới dạng một cuộc trò chuyện, chứ không phải dưới dạng một câu lệnh.

Tôi không nói về một trình bao bọc micrô gửi nội dung nào đó đến một LLM rồi chờ phản hồi.

Tôi đang nói về một cuộc trò chuyện qua lại trong thế giới thực, theo thời gian thực, và đó thực sự là điều khá khó xây dựng.

Hãy bắt đầu với độ trễ.

Bạn cần nhanh đến mức nào?

Hoá ra tốc độ cần phải nhanh, rất nhanh, nhưng tuỳ thuộc vào những gì bạn đã đọc, tốc độ này có thể không nhanh như bạn nghĩ hoặc có thể nhanh hơn nhiều so với bạn nghĩ.

Bây giờ, hãy cùng tìm hiểu một số số liệu mà chúng tôi đã khám phá được trong nhiều lần thử nghiệm.

Vì vậy, khi nói về độ trễ toàn diện, tôi đang nói về thời gian từ lần phát ngôn cuối cùng của người dùng, âm thanh cuối cùng mà người dùng tạo ra, cho đến thời điểm họ nghe thấy âm thanh phản hồi.

Trong quá trình thử nghiệm, chúng tôi nhận thấy rằng khi chúng tôi nhận được ý kiến phản hồi về thử nghiệm chơi từ người dùng, họ bắt đầu không đề cập đến tốc độ hay độ chậm hoặc bất kỳ điều gì tương tự khi thời gian tải là khoảng 1,5 giây.

Đó dường như là thời điểm mọi người bắt đầu cảm thấy thực sự thoải mái với việc này.

Ngay khi chúng tôi chậm hơn mức đó, mọi người thường nói rằng "Tính năng này rất hay, nhưng", vì vậy, đó có vẻ là một điểm tối ưu.

Sau đó, khi tốc độ nhanh hơn nữa, chúng tôi nhận thấy ở mức khoảng 1,2 giây, một số tương tác siêu tự nhiên như qua lại bắt đầu diễn ra.

Ví dụ: tôi nói điều gì đó, trong trường hợp này, robot sẽ nói điều gì đó rất nhanh và bạn sẽ nói qua nói lại.

Có vẻ như có một điểm ngọt ngào nào đó đã được mở khoá.

Tuy nhiên, 1,2 giây là một khoảng thời gian khá khó để thực hiện trong một ngăn xếp.

Và sau đó, một phát hiện thú vị khác là chúng tôi đã thử nghiệm rất nhiều và cuối cùng đã có được một số tình huống để đạt được thời gian dưới một giây.

Và bạn có thể nghĩ: "Ồ, thế thì tuyệt vời quá!"

Đôi khi thì đúng, nhưng đôi khi lại rất tệ, rất kỳ lạ.

Vì vậy, bạn có thể nghe mọi người nói rằng thời gian phản hồi 800 mili giây là con số phù hợp, hoặc 500.

Tôi thậm chí còn đọc một loạt bài viết về 300 vì đó thực sự là nơi nhận thức của con người đạt được.

Thực tế là, điều này phụ thuộc rất nhiều vào bối cảnh.

Ví dụ: nếu tôi hỏi tên bạn, tôi sẽ có kỳ vọng về thời gian bạn trả lời.

Nếu tôi hỏi bạn ý nghĩa của cuộc sống là gì, tôi sẽ mong đợi một thời gian phản hồi rất khác.

Khi chúng tôi thực sự thử nghiệm và yêu cầu mọi người đánh giá xem phản hồi này nhanh hay chậm, khi bạn thực sự nhìn vào các con số, thì thực tế là nó ở khắp mọi nơi.

Những câu trả lời mất nhiều thời gian, mọi người cho là nhanh và ngược lại, vì hoá ra điều đó phụ thuộc rất nhiều vào bối cảnh.

Cũng như vị trí của họ trong cuộc trò chuyện.

Nhìn chung, mọi người mong đợi câu trả lời đầu tiên sẽ nhanh hơn các câu trả lời tiếp theo vì có thời gian suy nghĩ.

Nhưng đôi khi, bạn sẽ có những cuộc trò chuyện qua lại rất ngắn, nên bạn sẽ kỳ vọng nhiều hơn.

Vì vậy, đây không phải là một môn khoa học chính xác, nơi có một con số hoàn hảo, nhưng chúng tôi phát hiện ra rằng nếu bạn ở mức khoảng 1,5, thì bạn đang làm khá tốt.

Vì vậy, khi đạt đến mốc 1,5 giây này, bạn mới thực sự bắt đầu quan tâm đến tính nhất quán, đúng không?

Bởi vì nếu bạn gặp phải tình huống này trong 90% thời gian, nhưng 10% thời gian còn lại mất 3 giây, thì trải nghiệm của bạn sẽ có cảm giác bị hỏng, không phải là tệ, mà là hỏng.

Và vì vậy, chúng tôi kết thúc Khi bạn đạt được tốc độ đủ nhanh, bạn chỉ quan tâm đến tính nhất quán, vì vậy, luôn nhanh, không phải hầu hết thời gian.

Devin Reimer

Sau đây là cấu trúc quy trình xử lý giọng nói tiêu chuẩn.

Vì vậy, chúng ta sẽ lấy dữ liệu từ tính năng Chuyển lời nói thành văn bản, gửi dữ liệu đó đến một LLM, rồi gửi kết quả từ LLM đó trở lại tính năng Chuyển văn bản sang lời nói.

Ý tôi là, với tính năng Chuyển lời nói thành văn bản, chúng tôi sẽ gửi âm thanh đến máy chủ rồi chuyển đổi âm thanh đó thành văn bản.

Về phía LLM, chúng tôi sẽ lấy văn bản đó, lời thoại phản hồi đó hoặc chuyển đổi thành lời thoại phản hồi, sau đó xác định những hành động mà nhân vật đó sẽ thực hiện.

Chúng tôi kết hợp chặt chẽ hai yếu tố này vì chúng tôi thực sự cho rằng điều đó rất quan trọng.

Sau đó, về phía Chuyển văn bản sang lời nói, chúng tôi lấy văn bản đó, gửi đến tính năng Chuyển văn bản sang lời nói và truyền trực tuyến đến người dùng, đồng thời căn thời gian với các hành động mà tác nhân muốn thực hiện.

Một trong những vấn đề của việc này là việc chạy tuần tự có thể khá chậm vì bạn phải thực hiện từng bước một.

Vì vậy, một câu hỏi phổ biến mà tôi thường nhận được là, nếu quy trình đó chậm và bạn phải thực hiện ba bước, tại sao không sử dụng mô hình lời nói sang lời nói?

Vì như vậy sẽ nhanh hơn, đúng không?

Và đúng vậy, hầu hết thời gian, điều đó sẽ nhanh hơn vì bạn đang chạy một thứ.

Nhưng điều này cũng đi kèm với một số đánh đổi lớn.

Vì vậy, mặc dù nhanh nhưng có một số yếu tố khiến chúng tôi không thể chọn, và yếu tố lớn nhất là chi phí.

Vì vậy, nhìn chung, chúng tôi nhận thấy chi phí chạy mô hình Chuyển lời nói thành lời nói cao hơn khoảng 3 đến 5 lần so với phương pháp song song này.

Vì vậy, đối với chúng tôi, việc này không mang lại hiệu quả kinh tế.

Về mặt an toàn, việc này thực sự khó khăn hơn một chút vì khó xác thực câu trả lời mà tác nhân sẽ đưa ra cho đến khi họ nói ra.

Nhưng trong thời gian chờ đợi, nếu có phương pháp theo quy trình, bạn có thể lấy câu trả lời mà LLM đang đưa ra, rồi xác thực và kiểm tra độ an toàn ngay tại đó trước khi gửi nội dung cho người dùng.

Về kiểu giọng nói, bạn chỉ có thể dùng các kiểu đặt sẵn trong mô hình Chuyển lời nói thành lời nói đó.

Bạn không thể nói kiểu: "Ồ, bạn biết gì không?

Đối với trường hợp này, tôi thực sự muốn sử dụng loại giọng nói này."

Bạn sẽ phải dùng mãi một cái tên đó.

Trong phương pháp theo quy trình, bạn có thể kiểu như, "Ồ, tôi sẽ thay đổi.

Tôi sẽ chọn mô hình này vì mô hình này hoạt động rất hiệu quả cho trường hợp sử dụng cụ thể này."

Và điều tương tự cũng áp dụng cho trí thông minh, đúng không?

Nếu bạn có một mô hình Chuyển lời nói thành lời nói thực sự tốt, tạo ra giọng nói hay, nhưng trí thông minh không hoàn toàn như bạn muốn, thì bạn không thể dễ dàng thay thế nó, đúng không?

Bạn gần như bị mắc kẹt.

Trong phương pháp theo quy trình, bạn sẽ nghĩ: "Ồ, đối với trường hợp sử dụng này, tôi muốn dùng một mô hình cụ thể".

Một khía cạnh mà tính năng Chuyển lời nói sang lời nói chắc chắn vượt trội là khả năng hiểu được giọng điệu của người dùng.

Ví dụ như những câu mỉa mai và những câu tương tự.

Hiện tại, bản chép lời từ lời nói thành văn bản thường không có nhiều thông tin như vậy, nhưng tôi nghĩ điều này sẽ thay đổi theo thời gian.

Đó chắc chắn là một điểm cộng cho tính năng Chuyển lời nói thành lời nói.

Vì vậy, Speech-to-Speech chắc chắn có lợi thế về tốc độ, nhưng cũng có một số thách thức về khả năng định cấu hình và chi phí cao, đặc biệt là đối với chúng tôi, đó là một yếu tố quyết định.

Vậy có cách nào khác không?

Có.

Điều chúng ta nên làm là cố gắng hết sức để song song hoá quy trình.

Vì vậy, một số việc chúng tôi làm là chạy LLM trước khi tính năng chuyển lời nói thành văn bản có độ tin cậy hoàn toàn.

Và khi nói đến độ tin cậy, tôi muốn nói đến độ tin cậy của các từ được tạo trong bản chép lời, sau đó là độ tin cậy của điểm kết thúc lượt.

Vì vậy, ngay khi chúng tôi cho rằng có khả năng đây là thời điểm người dùng ngừng nói và đây là những gì họ nói, chúng tôi sẽ tiến hành.

Và trường hợp xấu nhất là chúng tôi sai, đúng không?

Người dùng tiếp tục nói.

Nhưng ngay cả trong trường hợp đó, chúng ta chỉ cần huỷ LLM rồi chạy lại.

Và vì bối cảnh có thể sẽ được lưu vào bộ nhớ đệm và chúng ta chưa tạo nhiều mã thông báo như vậy, nên việc này không tốn nhiều chi phí và lợi ích của việc này là người dùng sẽ nghe thấy nội dung nhanh hơn so với khi bạn đợi cho đến khi hoàn toàn tự tin.

Chúng tôi cũng không đợi LLM tạo xong toàn bộ câu trả lời rồi mới bắt đầu gửi câu trả lời đó đến tính năng Chuyển văn bản sang lời nói.

Điều chúng tôi chờ đợi là đoạn văn bản đầu tiên có thể đọc được.

Trong hầu hết các trường hợp, đó là một câu.

Đôi khi, có thể có một số cấu hình khác, nhưng ngay khi có đoạn câu đầu tiên, chúng tôi sẽ gửi đoạn đó đến tính năng Chuyển văn bản sang lời nói.

Sau đó, nếu chúng ta có một công cụ Chuyển văn bản sang lời nói tốt có thể phát trực tuyến, thì ngay khi công cụ đó sẵn sàng phát trực tuyến, người dùng có thể sử dụng.

Chúng tôi cũng rất cẩn thận về số lượng mã thông báo cần tạo.

Vì vậy, chúng tôi không sử dụng những thứ như trình bao bọc JSON và những thứ tương tự có thể thêm mã thông báo bổ sung.

Chúng tôi cố gắng tìm ra cấu trúc đơn giản nhất để nhận được phản hồi nhanh nhất có thể.

Chúng tôi cũng sử dụng những tính năng như điền trước cho trợ lý nếu biết trước đoạn mã thông báo đầu tiên sẽ là gì từ tác nhân.

Và đối với tính năng chuyển văn bản sang lời nói, kết quả là hai đoạn này, đúng không?

Vì vậy, đoạn văn bản có thể đọc thành tiếng đầu tiên sẽ xuất hiện và sau đó chúng ta sẽ chạy mọi thứ khác.

Nhưng vì việc nghe âm thanh phát ra mất nhiều thời gian hơn so với việc tạo âm thanh, nên hầu như đoạn đầu tiên sẽ phát xong cho người dùng khi đoạn thứ hai hoàn tất.

Vì vậy, người dùng thực sự không nhìn thấy.

Nó đến nhanh nhất có thể.

Vì vậy, khi bạn cân nhắc việc chọn các dịch vụ khác nhau, sau đây là một số quy tắc chung của chúng tôi.

Khi chọn một loại khung tác nhân và âm thanh phù hợp, điều bạn quan tâm là độ trễ vào và ra thấp nhất.

Vậy tôi có thể gửi và tải dữ liệu xuống nhanh đến mức nào?

Về khía cạnh chuyển lời nói thành văn bản, chúng tôi quan tâm đến thời gian để đạt được độ tin cậy.

Vì vậy, đây là sự tự tin trong bản chép lời và sự tự tin khi kết thúc lượt.

Hai người đó là một cặp, đúng không?

Nếu bạn không nhanh chóng tin tưởng vào một người, thì mọi thứ sẽ diễn ra chậm chạp như vậy, đúng không?

Vì vậy, tốc độ của nó chỉ bằng tốc độ của thành phần chậm nhất trong đó.

Về phía LLM, chúng tôi quan tâm đến thời gian cho câu đầu tiên, đoạn có thể nói đầu tiên đó.

Vậy là có hai phần, đúng không?

Đó là thời gian nhận mã thông báo đầu tiên kết hợp với số mã thông báo mỗi giây.

Vì vậy, nếu đột nhiên bạn tìm thấy một mô hình thực sự tốt, mang lại cho bạn thời gian thực sự tốt cho mã thông báo đầu tiên, nhưng lại chậm về số mã thông báo mỗi giây, thì điều đó có thể tệ hơn so với phương án thay thế.

Vì vậy, hãy tìm ra cách kết hợp phù hợp.

Còn về tính năng chuyển văn bản sang lời nói, bạn quan tâm đến thời gian phát âm thanh đầu tiên.

Vì vậy, việc đo lường độ trễ là rất quan trọng, vì đôi khi âm thanh có thể quay lại với khoảng lặng ở đầu và người dùng sẽ không nghe thấy âm thanh đó.

Vì vậy, bạn thực sự phải đo lường đến thời điểm người dùng nghe thấy âm thanh.

Và sau đó, như tôi đã đề cập trước đây, trên hết, bạn quan tâm đến độ ổn định, chứ không phải tốc độ cao nhất, không phải trường hợp tốt nhất.

Độ trễ nhất quán của toàn bộ ngăn xếp này là bao nhiêu?

Devin Reimer

Vì vậy, hiện tại, chúng tôi đang sử dụng LiveKit cho các khung tác nhân âm thanh.

Chúng tôi đang sử dụng Deepgram cho tính năng chuyển lời nói thành văn bản.

Đối với LLM, chúng tôi đang sử dụng Gemma 4 31B và lưu trữ mô hình này trên LiveKit.

Về tính năng chuyển văn bản sang lời nói, chúng tôi đang sử dụng công nghệ chuyển văn bản sang lời nói 2 của Inworld AI.

Ngoài ra, chúng tôi còn xây dựng toàn bộ khung vận hành tác nhân AI AstroBeam. Khung này không chỉ liên kết tất cả các yếu tố này với nhau mà còn bổ sung mọi thành phần cần thiết để tạo nên một tác nhân thoại thực sự chất lượng, đặc biệt là một tác nhân có tính tương tác cao như tác nhân của chúng tôi dành cho trò chơi.

Vậy, có một điều tôi chưa nói đến là mô hình an toàn thì sao?

Vì vậy, theo truyền thống, các mô hình an toàn là một phần của quá trình LLM, nhưng điều đó làm tăng độ trễ và thêm một bước bổ sung vào đó.

Vậy nếu bạn tự chạy thì sao?

Vì vậy, đây thực sự là giao diện của ngăn xếp.

Vì vậy, khi nhận được đoạn văn bản đầu tiên, tức là đoạn văn bản đầu tiên có thể đọc được mà chúng tôi sẽ gửi đến tính năng chuyển văn bản sang lời nói, chúng tôi sẽ gửi đoạn văn bản đó đến mô hình an toàn của mình cùng một lúc.

Và vì mô hình an toàn nhỏ hơn và chạy nhanh hơn so với mô hình chuyển lời nói thành văn bản, nên hầu như mô hình này luôn hoàn tất trước.

Và điều này có nghĩa là việc thêm một mô hình an toàn sẽ không làm tăng độ trễ cho hệ thống của chúng tôi, và thậm chí còn tốt hơn nữa là chúng tôi có thể chạy một mô hình an toàn lớn hơn nhiều so với mức mà hầu hết mọi người nghĩ đến.

Và điều đó cực kỳ quan trọng đối với chúng tôi, đặc biệt là vì chúng tôi đang phát triển trò chơi.

Có rất nhiều bối cảnh quan trọng trong thế giới đó.

Ví dụ: giả sử bạn đang xây dựng một trò chơi thời trung cổ và bạn có một NPC trong trò chơi này, anh ta hét lên như "Tấn công!

Chém đầu chúng đi!", đúng không?

Một mô hình an toàn truyền thống có thể phản hồi như sau: "Ồ, điều đó không hay chút nào.

Bạn không nên nói như vậy".

Nhưng trong bối cảnh của trò chơi này, điều đó hoàn toàn hợp lý.

Và để làm được điều đó, chúng tôi sử dụng một mô hình an toàn mạnh mẽ hơn một chút, có nhiều bối cảnh hơn về những gì đang xảy ra trên thế giới để có thể thực hiện được điều đó.

Bạn có thể nhận thấy rằng chúng tôi thực sự chạy mô hình an toàn hai lần, vì vậy, chúng tôi sẽ chạy mô hình đó trên đoạn đầu tiên, sau đó chạy lại trên toàn bộ nội dung khi có đoạn cuối cùng.

Một lần nữa, chúng ta phải chạy hai lần, nhưng không làm tăng độ trễ cho ngăn xếp.

Vậy là giờ chúng ta đã đủ nhanh, nhưng tiếc là điều này không quan trọng nếu chúng ta không đủ thông minh.

Devin Reimer

Vậy thì, nó cần thông minh đến mức nào?

Nền tảng này cần đủ thông minh cho người dùng, nhưng quan trọng hơn là phải đủ thông minh để bạn phát triển.

Và đây thường là điều mà mọi người không nghĩ đến khi họ chọn loại thông tin họ cần cho hoạt động tình báo.

Chúng tôi đã phát triển các tác nhân thoại được khoảng ba năm nay. Ví dụ: trong những ngày đầu, chúng tôi đã sử dụng một số mô hình LLaMA đời đầu. Mặc dù chúng tôi có thể giúp các mô hình này hoạt động tương đối ổn định cho người dùng, nhưng quá trình phát triển lại rất tốn kém vì mọi thứ đều rất dễ hỏng.

Các mô hình này rất dễ tạo ra những câu trả lời không mong muốn hoặc vô nghĩa, vì vậy, chúng tôi đã dành rất nhiều nỗ lực kỹ thuật để khắc phục vấn đề đó.

Và đó là điều chúng tôi ưu tiên, vì nếu không thể nhanh chóng xây dựng những thứ này, chúng tôi không thể cung cấp sản phẩm cho người dùng.

Vì vậy, bạn cần phải cân nhắc cả hai yếu tố này.

Thường thì khi nghĩ về trí tuệ, mọi người sẽ nghĩ đến LLM, đúng không?

Nhưng đó chỉ là một phần.

Chúng ta phải xem xét mọi khía cạnh khi nói đến thông tin chi tiết.

Giờ hãy cùng tìm hiểu về công nghệ chuyển lời nói thành văn bản thông minh.

Vì vậy, điều chúng ta quan tâm ở đây là tỷ lệ lỗi từ thấp.

Ngoài ra, không chỉ tỷ lệ lỗi thấp, mà khi xảy ra lỗi, chúng tôi còn tạo ra một kết quả rất gần với thực tế, vì nếu kết quả thực sự gần, LLM thường có thể hiểu rất rõ kết quả đó dựa trên ngữ cảnh.

Nếu tỷ lệ lỗi thấp nhưng số lần nhầm lẫn lại rất cao, thì LLM sẽ gặp nhiều khó khăn hơn trong việc tìm ra ý định thực sự.

Một điều khác cần cân nhắc là nền tảng mục tiêu của bạn.

Ví dụ: nếu tôi đang xây dựng cho XR và tôi có micrô thực sự gần miệng người dùng, tôi sẽ có dữ liệu âm thanh micrô thực sự tốt, chất lượng cao và điều đó có thể hoạt động thực sự tốt cho một số mô hình nhất định.

Nhưng nếu đột nhiên tôi xây dựng một ứng dụng cho điện thoại di động mà mọi người sẽ sử dụng trên một con phố đông đúc, thì điều đó sẽ có tác động rất khác và các mô hình khác nhau sẽ hoạt động theo cách khác nhau và có thể hiểu một cách thông minh những gì đang được nói theo nhiều cách.

Vì vậy, bạn phải cân nhắc điều đó, đảm bảo rằng bạn đang chọn đúng nền tảng mà bạn đang xây dựng.

Giờ thì hãy chuyển sang phần chuyển văn bản sang lời nói của phương trình trí tuệ.

Nghe có vẻ tự nhiên đúng không?

Mục tiêu của chúng tôi là truyền đạt cho người dùng những thông tin mà họ có thể hiểu được.

Nhưng đó chỉ là một phần, phải không?

Khả năng biểu đạt của tác nhân cũng cực kỳ quan trọng vì khả năng biểu đạt cũng chứa đựng thông tin. Ngoài ra, trong các thử nghiệm chơi trò chơi, chúng tôi nhận thấy rằng tác nhân càng biểu đạt tốt thì người dùng càng cảm thấy tác nhân đó thông minh, điều này hoàn toàn hợp lý.

Và sau đó, tốc độ có đủ nhanh không?

Và tôi biết trong phần trước, tôi đã nói về độ trễ, nhưng thực ra độ trễ cũng quan trọng ở đây đối với trí thông minh được cảm nhận.

Người dùng nhận thấy tốc độ phản hồi có mối tương quan trực tiếp với mức độ thông minh thực tế của mô hình.

Nếu tôi có thể trả lời nhanh, thì có lẽ câu trả lời sẽ thông minh hơn.

Vì vậy, những điều này có thể thực sự quan trọng khi nói đến cách người dùng cảm nhận trải nghiệm và mức độ họ có thể đắm chìm trong trải nghiệm đó.

Tiếp theo, hãy chuyển sang phần trí tuệ của LLM.

Đây là phần khó cân bằng nhất vì có rất nhiều yêu cầu khác nhau, đúng không?

Vì vậy, chúng tôi có khả năng hiểu lời nói, bối cảnh và cơ sở.

Trong trò chơi, điều này cực kỳ khó khăn, vì bạn phải xây dựng cả một thế giới và vũ trụ, đúng không?

Đây không phải là hộp văn bản để AI có thể bịa ra những điều đang xảy ra.

Nếu tác nhân trong trò chơi nói: "Có một quả táo trên bàn" nhưng thực tế không có quả táo nào trên bàn, thì điều đó sẽ làm gián đoạn trải nghiệm của người dùng.

Chúng ta cũng cần những yếu tố như tuân thủ nghiêm ngặt quy tắc.

Trò chơi có quy tắc rất chặt chẽ.

Mô hình ngôn ngữ lớn có thể xử lý việc đó không?

Chúng ta có thể giảm tỷ lệ ảo tưởng không?

Chúng ta có thể tạo ra các nhân vật nhất quán khi bạn tương tác với cùng một tác nhân nhiều lần không?

Bạn có cảm thấy như đang trò chuyện với cùng một nhân viên hỗ trợ không?

Và sau đó, một vấn đề có thể khiến bạn gặp khó khăn vì đây không phải là vấn đề khi bắt đầu phát triển, đó là mô hình của bạn có thể xử lý kích thước câu lệnh ngày càng tăng không?

Vì chắc chắn là khi tiếp tục phát triển, bạn sẽ đưa thêm nhiều nội dung vào câu lệnh.

Nhưng sau đó, khi người dùng tiếp tục chơi, nhật ký trò chuyện trong câu lệnh đó sẽ tăng lên.

Vậy câu lệnh đó có xử lý được sự tăng trưởng đó không?

Vì đôi khi, đối với một số mô hình nhất định, khi câu lệnh của bạn dài hơn, chất lượng câu trả lời sẽ giảm xuống, nên bạn phải tìm hiểu xem nhu cầu thực tế của mình là gì đối với lượng thông tin phải đưa vào câu lệnh đó mỗi lần.

Nhưng đây chỉ là phần nổi của tảng băng chìm và còn phụ thuộc vào những gì bạn đang xây dựng.

Vì vậy, bạn phải suy nghĩ thật kỹ về những gì bạn đang xây dựng và những gì bạn đang cố gắng đạt được.

Giờ đây, chúng ta đã đủ nhanh và đủ thông minh, nhưng tất cả những điều này sẽ không có ý nghĩa gì nếu chi phí quá cao.

Devin Reimer

Vậy thì giá phải rẻ đến mức nào?

Rất tiếc, vấn đề lại phức tạp hơn thế một chút.

Vì vậy, chúng ta phải nghĩ đến tính kinh tế của ứng dụng hoặc trò chơi mà chúng ta đang xây dựng, đúng không?

Vì vậy, bạn cần đặt ra một vài câu hỏi.

Người dùng sẽ tương tác với nhân viên hỗ trợ bằng giọng nói trong bao lâu?

Bạn kiếm được bao nhiêu tiền trên mỗi người dùng?

Và chi phí vận hành hệ thống giọng nói đó mỗi giờ là bao nhiêu?

Chúng tôi kết hợp chúng lại để tìm hiểu xem mọi thứ có hợp lý không.

Sau đây là tình hình kinh tế của trò chơi đầu tiên của chúng tôi, Stellar Cafe.

Vậy nên thời gian chơi ở Stellar Cafe là khoảng từ 1 tiếng rưỡi đến 3 tiếng rưỡi, tức là trung bình khoảng 2 tiếng.

Chi phí vận hành tác nhân thoại của chúng tôi là khoảng 1, 2 USD/giờ/người dùng và người dùng tương tác với tác nhân thoại 100% thời gian.

Đây là trò chơi hoàn toàn bằng giọng nói.

Chúng tôi tính phí cố định 10 USD cho trò chơi, đây là mức phí thông thường.

Chúng tôi không cung cấp gói thuê bao vì mô hình này rất khó áp dụng trong trò chơi. Tôi tin chắc rằng chúng tôi phải áp dụng mức giá cố định, nếu không thì mô hình này sẽ không hiệu quả và không thể mở rộng.

Trước đây, chúng tôi tính phí 15 đô la, nhưng chúng tôi đã nỗ lực giảm chi phí máy chủ, nên giờ đây chúng tôi đã giảm xuống còn 10 đô la.

Và 1, 2 đô la này là mức giá hiện tại.

Đây không phải là mức giá chung.

Tôi đã thấy những thứ này có giá rất đa dạng và đôi khi đắt hơn nhiều.

Vì vậy, bạn cũng phải tìm hiểu xem mình đang ở đâu về mặt chi phí.

Chúng tôi có thể giảm giá, nhưng chúng tôi đang cố gắng duy trì chất lượng ở mức cao nhất có thể.

Vì vậy, khi tính toán tất cả những điều này, điều này có nghĩa là với thời gian chơi 2 giờ, chi phí cho bộ giọng nói của chúng tôi là khoảng 2,4 đô la cho mỗi người dùng.

Và vì chúng tôi tính phí 10 đô la và cửa hàng thu phí, nên chúng tôi kiếm được khoảng 4,59 đô la cho mỗi người dùng, đúng không?

Và như vậy, mô hình kinh tế đó có hiệu quả, đúng không?

Giọng nói là điểm thu hút, đó là thứ chúng tôi muốn đầu tư, và cách này hiệu quả.

Vì vậy, đây là một trò chơi rất nhỏ.

Hãy nói về một thứ lớn hơn một chút.

Hãy cùng nói về một trò chơi giả định, một trò chơi có cốt truyện, kéo dài khoảng 5 đến 9 giờ, tức là trung bình 7 giờ.

Trên thực tế, hầu hết mọi người – rất nhiều người không chơi hết trò chơi, họ chơi một chút rồi bỏ dở, nhưng tôi muốn chọn một tỷ lệ cao hơn một chút để đảm bảo tính kinh tế vẫn hoạt động.

Vì vậy, chúng ta sẽ giữ nguyên mức giá 1,2 USD/giờ, nhưng chúng ta sẽ thay đổi tỷ lệ sử dụng thành phần giọng nói thành 60% thời gian, vì một trò chơi lớn hơn sẽ có nhiều cơ chế hơn chứ không chỉ có giọng nói.

Vì vậy, đây vẫn sẽ là một trò chơi chủ yếu dựa trên giọng nói, nhưng sẽ có các tính năng khác trong đó.

Vì vậy, nếu chúng tôi tính phí 20 đô la, thì chi phí cho mỗi người dùng sẽ là khoảng 5 đô la, nghĩa là cuối cùng, chúng tôi kiếm được khoảng 9 đô la cho mỗi người dùng.

Vì vậy, một lần nữa, với điều này, nền kinh tế hoạt động.

Điều này không có nghĩa là mô hình kinh tế này sẽ phù hợp với mọi thứ.

Ví dụ: một điều không nên làm là khi bạn nghĩ: "Ồ, mình muốn xây dựng một trò chơi miễn phí và có thể người dùng sẽ chơi trò chơi này trong khoảng từ 1 giờ đến hơn 100 giờ".

Vậy hãy lấy trung bình là 10 giờ.

Trò chơi này hoàn toàn dựa trên giọng nói, nhưng giả sử chúng ta có một trò chơi thành công và trò chơi này tạo ra khoảng 3 USD cho mỗi người dùng, thì đó sẽ là một trò chơi miễn phí khá tuyệt vời.

Bạn sẽ mất 10 USD cho mỗi người dùng.

Vì vậy, Gemini chưa thể làm được tất cả những việc này và bạn phải suy nghĩ xem liệu những gì bạn đang xây dựng có hợp lý hay không.

Đừng đợi đến cuối mới tìm hiểu về kinh tế.

Devin Reimer

Vậy thì câu hỏi tiếp theo được đặt ra là, còn các mô hình cục bộ thì sao?

Vì nếu bạn gặp thách thức lớn về chi phí, thì các mô hình cục bộ có thể giải quyết vấn đề này không?

Và đúng vậy, điều đó sẽ xảy ra.

Nhưng có một số yếu tố đánh đổi mà chúng ta phải cân nhắc.

Vì vậy, về mặt chi phí, chúng tôi sẽ loại bỏ được hoá đơn máy chủ, đây sẽ là một lợi ích rất lớn, mở ra nhiều cơ hội hơn.

Nhưng hiện tại, có rất nhiều vấn đề mà đám mây có thể giải quyết nhưng máy tính cục bộ thì không.

Ví dụ: điện toán.

Mọi người thường nói: "Này, tôi tìm thấy mô hình chuyển lời nói thành văn bản rất hay này và mô hình này chạy cục bộ trên thiết bị này, đúng không?"

Tuyệt vời, nhưng điều chúng ta phải nghĩ đến là nó không chạy một mô hình, mà chạy nhiều mô hình, đúng không?

Trong trường hợp của chúng ta, có thể có 4 người dùng cùng lúc, vì vậy, một lần chạy là không đủ, mà phải chạy nhiều lần cùng lúc.

Sau khi hoàn tất, bạn có cần làm gì khác để trò chơi hoặc ứng dụng của mình chạy được không?

Nếu đã sử dụng hết GPU, bạn sẽ không thể kết xuất nhiều trò chơi điện tử.

Giả sử bạn đã vượt qua những thách thức đó.

Vậy, yếu tố tiếp theo là tốc độ, đúng không?

Thường thì bạn có thể chạy các mô hình này, nhưng chúng sẽ rất chậm và giống như việc đưa ra câu lệnh hơn là một cuộc trò chuyện thực tế theo thời gian thực.

Vì vậy, về mặt lý thuyết, việc lưu trữ cục bộ sẽ mang lại lợi ích trong tương lai, vì bạn không cần phải thực hiện hành trình khứ hồi từ Internet.

Thách thức hiện tại là tìm được những mô hình có thể chạy ở tốc độ phù hợp để thực hiện việc này.

Tiếp theo, giả sử bạn đã chinh phục được khả năng tính toán và tốc độ, giờ chúng ta phải nghĩ đến chất lượng, đúng không?

Vì vậy, nhìn chung, do bạn đang chạy ứng dụng trên thiết bị cục bộ, nên bạn đang sử dụng một LLM nhỏ hơn, chẳng hạn như một công cụ chuyển văn bản sang lời nói thô sơ hơn. Điều này thực sự có thể gây ra một số thách thức khi bạn xây dựng nội dung.

Và như tôi đã đề cập trước đó, khi bạn nghĩ về LLM, không chỉ là liệu nó có đủ tốt cho người dùng của bạn hay không, mà còn là liệu nó có đủ tốt để bạn phát triển hay không?

Vì vậy, nếu mô hình đó trở nên khá khó khăn để xây dựng một thứ gì đó, thì đó chắc chắn là điều cần suy nghĩ.

Giả sử bạn đã chinh phục được khả năng tính toán, tốc độ và chất lượng, thì bước tiếp theo là khả năng di động.

Nếu bạn thắng và trải qua toàn bộ quá trình này, và bạn chạy được mô hình này trên, giả sử, một chiếc RTX 5070, thì đó có thể là nơi duy nhất mô hình này có thể chạy.

Vì vậy, nếu có cơ hội đưa ứng dụng lên một nền tảng mới, bạn có thể gặp khó khăn.

Về phía đám mây, bạn chỉ cần có Internet.

Và đó là một bước tiến lớn.

Cho phép phát trực tiếp trên nhiều nền tảng.

Tiếp theo, hãy nói về phương pháp kết hợp.

Vì vậy, hãy chạy một số nội dung trên đám mây và một số nội dung trên thiết bị.

Cũng có thể, liệu có được không?

Thực ra, đây không phải là một chiến thắng lớn như bạn nghĩ.

Vì vậy, nếu bạn có một mô hình đủ nhỏ để chạy trên hầu hết các nền tảng cục bộ, thì nếu bạn chạy cùng một mô hình đó trên đám mây, chi phí có thể chỉ là vài xu.

Vì vậy, thông thường, bạn phải giải quyết toàn bộ vấn đề thì mới đạt được thành công lớn nhất.

Sau đó, điều tiếp theo được đề cập là, nếu bạn chạy cục bộ thì sao?

Họ có phần cứng phù hợp, và trên đám mây nếu bạn không có, đúng không?

Bạn có thể chạy một thứ mạnh mẽ hơn trên đám mây.

Điều này mang đến những thách thức mới, đúng không?

Nếu bạn chuyển sang một mô hình khác, thì việc này có thể ảnh hưởng khá nhiều đến quá trình phát triển.

Và cuối cùng, bạn phải dành nhiều thời gian để xử lý thông số kỹ thuật tối thiểu.

Và bạn có thể có những mô hình hoạt động khá khác nhau.

Vì vậy, trừ phi bạn sử dụng cùng một mô hình, nếu không, bạn có thể phải tốn thêm nhiều thời gian và chi phí phát triển.

Vì vậy, điều quan trọng là bạn phải suy nghĩ về mục tiêu mà bạn muốn đạt được, vì giả sử bạn đã tìm ra giải pháp và có một mô hình cục bộ phù hợp nếu cần, hoặc mô hình đám mây nếu không cần, thì mô hình đám mây vẫn phải mang lại hiệu quả kinh tế.

Vì nếu đột nhiên tất cả người dùng của bạn đều chuyển sang sử dụng đám mây, bạn sẽ thua nếu không nghĩ đến điều đó, xét từ góc độ kinh tế.

Vì vậy, khi nói đến các mô hình cục bộ, đây chắc chắn là một lợi thế lớn về mặt kinh tế, nhưng vẫn còn sớm.

Đối với các ứng dụng nhạy cảm về giá như trò chơi, tôi tin rằng cuối cùng thì mô hình này cũng sẽ thành công.

Hiện tại, việc này khá phức tạp, ngoại trừ một số trường hợp sử dụng cụ thể, đặc biệt là những trường hợp liên quan đến lệnh.

Vì vậy, ngay bây giờ, chúng tôi muốn mang đến trải nghiệm tốt nhất có thể.

Đó là lý do chúng tôi sử dụng đám mây.

Nhưng đây là một lĩnh vực phát triển rất nhanh và mọi thứ đang thay đổi khá nhanh chóng.

Vậy nên, phần tiếp theo là hãy nghĩ về các mô hình chúng ta đang sử dụng, đúng không?

Vì vậy, câu hỏi tiếp theo là trọng số mở so với trọng số đóng.

Chúng ta nên làm gì ở đây?

Tôi muốn tập trung vào LLM khi chúng ta nói về vấn đề này vì chúng tôi nhận thấy đây là lĩnh vực chịu ảnh hưởng nhiều nhất từ câu hỏi về nguồn mở và nguồn đóng.

Vì vậy, chắc chắn có một số ưu và nhược điểm ở đây.

Vậy, khi nói đến các mô hình trọng số đóng, đây thường là trí tuệ tiên phong của bạn, phải không?

Vì vậy, nếu cần thông tin chi tiết nhất, bạn thường phải tìm đến đây.

Trong khi đó, ở phía nguồn mở, họ thường đi sau một thế hệ.

Vì vậy, đây có thể là một sự đánh đổi thực sự.

Về tốc độ, tôi đã đề cập đến việc quan tâm nhiều đến thời gian cho câu đầu tiên.

Chúng tôi nhận thấy rằng trong suốt vòng đời của các mô hình đóng, tốc độ thường giảm.

Có nhiều lý do dẫn đến việc này.

Có thể là do có nhiều người sử dụng mô hình hơn, hoặc có thể là do phần cứng đã chuyển sang một mô hình mới hơn.

Nhưng đó là một điều chúng tôi nhận thấy.

Vì vậy, bạn phải cẩn thận vì có thể xảy ra vấn đề khi bạn phát hành một sản phẩm tuyệt vời, nhưng theo thời gian, sản phẩm đó có thể không sử dụng được nữa.

Tiếp theo là gai nhọn.

Bạn rất quan tâm đến tính nhất quán đó, và vì vậy, thường thì các mô hình đóng được xây dựng dựa trên việc xử lý theo lô trong các tác vụ không đồng bộ, chứ không phải độ trễ P99, trong khi ở phía mô hình mở, bạn có thể chọn một nhà cung cấp quan tâm đến chính xác điều bạn quan tâm, để mang lại cho bạn sự tự tin, tốc độ và độ trễ mà bạn cần.

Tiếp theo là vòng đời của chính mô hình.

Vì vậy, các mô hình đóng thường ngừng hoạt động sau khoảng một năm.

Điều này có nghĩa là nếu bạn phát triển một mô hình trong một năm và dự kiến mô hình đó sẽ được đưa vào hoạt động trong 3 năm, thì bạn có thể phải trải qua hơn 3 lần thay đổi mô hình.

Và chỉ vì một mô hình tốt hơn không có nghĩa là mô hình đó sẽ hoạt động hiệu quả hơn cho bạn.

Chúng tôi đã trải qua rất nhiều thay đổi về mô hình trong 3 năm qua và thường mất hàng tuần, đôi khi là hàng tháng để tái cấu trúc mọi thứ. Trong khi đó, ở phía nguồn mở, bạn có thể tiếp tục chạy mô hình đó miễn là có người sẵn sàng lưu trữ hoặc bạn sẵn sàng tự lưu trữ.

Cuối cùng là chi phí.

Thông thường, theo thời gian, các mô hình đóng này, khi phát hành phiên bản mới, sẽ đắt hơn phiên bản trước.

Và đây là một điều khác cần lưu ý khi nói đến tính kinh tế, đó là một lần nữa, tính kinh tế của bạn có thể đã hoạt động khi ra mắt và sau đó không hoạt động khi bạn di chuyển mô hình.

Về mặt mở, bạn có thể linh hoạt di chuyển nó và tỷ lệ cược sẽ không tăng đáng kể vì đây là cùng một mô hình.

Vì vậy, chúng tôi đang sử dụng Gemma 4 31B và đây là một bước tiến lớn đối với chúng tôi vì đây là sự kết hợp tốt nhất giữa tốc độ, trí thông minh và chi phí.

Điều này cũng giúp chúng tôi tiến triển rất nhanh.

Việc phát triển bằng công cụ này dễ dàng hơn nhiều so với một số công cụ chúng tôi từng sử dụng.

Điều này không có nghĩa là chúng tôi chỉ sử dụng thông tin này.

Chúng tôi sử dụng nhiều kiểu kết hợp các mô hình mở và đóng khác nhau.

Ví dụ: những tính năng như tạo bộ nhớ, an toàn và tuỳ chỉnh.

Điều quan trọng là bạn phải chọn được mô hình phù hợp nhất với nhu cầu cụ thể của mình trong nhiệm vụ đó.

Nhưng Gemma 4 31B là mô hình chủ lực của chúng tôi khi nói đến tác nhân thoại.

Vì vậy, khi nói đến loại khác biệt này giữa hai mô hình, các mô hình mở chắc chắn mang lại cho bạn quyền kiểm soát lớn hơn và cho phép bạn giữ các mô hình miễn là chúng có thể được lưu trữ với chi phí dễ dự đoán hơn.

Và lịch biểu của bạn không bị ảnh hưởng khi một mô hình ngừng hoạt động.

Devin Reimer

Vậy để tóm tắt lại, điều quan trọng là phải cân bằng cả ba yếu tố này, đúng không?

Về độ trễ, chúng tôi đang cố gắng cân bằng giữa khía cạnh truyền trực tuyến, khía cạnh song song, tốc độ và tính nhất quán của độ trễ.

Về mặt trí tuệ, đủ thông minh cho người dùng, đủ thông minh để xây dựng.

Về chi phí, chúng tôi cần biết chi phí cho mỗi người dùng và số tiền chúng tôi có thể kiếm được từ mỗi người dùng để đảm bảo hiệu quả kinh tế.

Đừng xây dựng trước rồi mới tìm hiểu về kinh tế sau.

Hãy nghĩ về điều đó ngay từ đầu.

Vì vậy, dù vẫn còn rất sớm, nhưng mô hình kinh tế ở đây đang bắt đầu phát huy hiệu quả.

Vì vậy, các mô hình rẻ hơn chắc chắn sẽ tốt hơn, các mô hình thông minh hơn chắc chắn sẽ tốt hơn.

Nhưng ngay bây giờ, hôm nay, chúng ta có thể bắt đầu giải quyết những thách thức thực sự khó khăn mà chúng ta cần phải giải quyết để biến tác nhân thoại thành hiện thực ở mọi nơi.

Vì vậy, tôi rất vui mừng được mang sức mạnh của các tác nhân thoại đến cho mọi người.

Cảm ơn bạn.