Sự khác biệt lớn giữa PoC và dịch vụ thương mại mà chúng tôi nhận ra khi phát triển AI hội thoại bằng Gemini

Khi sử dụng API thời gian thực của Gemini, có thể triển khai trong thời gian tương đối ngắn chức năng Speech-to-Speech, hay S2S, trong đó AI phản hồi trực tiếp bằng giọng nói đối với nội dung người dùng vừa nói.

Quy trình cơ bản khá đơn giản:

• Thu âm thanh từ microphone trên trình duyệt
• Gửi âm thanh tới Gemini
• Phát lại âm thanh do Gemini trả về trên trình duyệt

Trên thực tế, việc xây dựng một PoC cho phép người dùng trò chuyện với AI theo thời gian thực không quá khó.

Tuy nhiên, khi cung cấp chức năng này dưới dạng một dịch vụ thương mại để người dùng thực tế sử dụng liên tục, hàng loạt vấn đề không xuất hiện trong PoC bắt đầu phát sinh.

Ví dụ:

• Âm thanh trở nên không ổn định khi nhiều người sử dụng đồng thời
• Lỗi giới hạn tốc độ xuất hiện dù lượng sử dụng có vẻ vẫn còn dư
• Âm thanh chỉ bị chậm trên một số thiết bị cụ thể
• Tốc độ phát âm thanh đột ngột trở nên cực kỳ chậm
• Khó đồng thời sử dụng model mới nhất và duy trì một nền tảng vận hành ổn định
• Khi xảy ra sự cố, không thể điều tra đầy đủ nguyên nhân
• Khó tái hiện các vấn đề phụ thuộc vào trình duyệt hoặc thiết bị âm thanh

Trong AI hội thoại giọng nói, có một khoảng cách rất lớn giữa việc “cuộc hội thoại có thể diễn ra” và việc “dịch vụ có thể được cung cấp ổn định trong thời gian dài”.

Bài viết này giới thiệu những vấn đề chúng tôi đã gặp phải khi phát triển AI hội thoại bằng Gemini, cùng những bài học rút ra từ các biện pháp xử lý.

Đặc biệt, bài viết tổng hợp những điểm mà người phụ trách dự án mới hoặc người phụ trách PoC nên xem xét trước khi chuyển từ PoC sang phát triển thương mại.

Bài viết dựa trên kết quả kiểm chứng và kinh nghiệm phát triển tại thời điểm hiện tại. Model, API, phương thức xác thực và các thông số kỹ thuật có thể thay đổi, vì vậy hãy kiểm tra thông tin chính thức mới nhất khi triển khai.

Trước tiên, chúng tôi kiểm chứng trải nghiệm người dùng và giá trị của dịch vụ

Chức năng mà chúng tôi phát triển cho phép người dùng trò chuyện bằng giọng nói với AI theo thời gian thực.

Frontend được xây dựng bằng Next.js và được host trên Vercel.

Trong giai đoạn PoC, chúng tôi chủ yếu tập trung kiểm chứng các điểm sau:

• Người dùng có cảm thấy việc trò chuyện bằng giọng nói với AI là tự nhiên hay không
• Hướng dẫn và hỗ trợ bằng giọng nói có thực sự giúp giải quyết vấn đề hay không
• Toàn bộ dịch vụ, bao gồm các chức năng xung quanh, có mang lại giá trị hay không
• Người dùng có thể sử dụng dịch vụ trong những công việc và tình huống đã dự kiến hay không
• Thiết kế hội thoại như thế nào để người dùng không bị bối rối

Nói cách khác, trong PoC, chúng tôi ưu tiên kiểm chứng trải nghiệm người dùng và giả thuyết kinh doanh hơn là bản thân kiến trúc hệ thống.

Kiến trúc ban đầu được lựa chọn khá đơn giản: trình duyệt kết nối trực tiếp tới Live API của Gemini API.

Với cấu trúc này, không cần chuyển tiếp dữ liệu âm thanh qua máy chủ của công ty, nhờ đó có thể xây dựng trải nghiệm hội thoại giọng nói trong thời gian ngắn.

Ngoài ra, trong một số trường hợp, Gemini API cho phép sử dụng sớm các Live model mới hoặc model đang ở giai đoạn preview.

Trong AI hội thoại giọng nói, sự khác biệt giữa các model ảnh hưởng trực tiếp đến trải nghiệm người dùng, chẳng hạn như:

• Tốc độ phản hồi
• Độ tự nhiên của hội thoại
• Chất lượng giọng nói
• Khả năng ngắt lời AI khi người dùng bắt đầu nói
• Khả năng duy trì ngữ cảnh
• Khoảng nghỉ và nhịp độ phát âm

Xét theo mục tiêu của PoC, khả năng nhanh chóng sử dụng model mới để kiểm chứng tiềm năng của dịch vụ là một lợi thế lớn.

Tuy nhiên, ở giai đoạn PoC, chúng tôi chưa kiểm chứng đầy đủ hạ tầng truyền thông, giám sát, kết nối đồng thời và xử lý sự cố cần thiết cho vận hành thương mại.

Do đó, ngay cả một cấu trúc có vẻ hoạt động tốt trong PoC cũng bắt đầu bộc lộ nhiều vấn đề khi được sử dụng trong điều kiện gần với môi trường production.

“Chạy được” trong PoC khác với “có thể tiếp tục sử dụng” trong production

Trong PoC, chức năng thường được kiểm chứng với số lượng người dùng và môi trường hạn chế.

Nếu thành viên nội bộ sử dụng thiết bị và trình duyệt được chỉ định để thực hiện một bản demo ngắn, ngay cả khi đôi lúc mất kết nối hoặc xảy ra độ trễ, vẫn có thể tiếp tục kiểm chứng bằng cách kết nối lại hoặc chạy lại.

Tuy nhiên, trong dịch vụ thương mại, tình hình hoàn toàn khác.

Không thể thống nhất tất cả các yếu tố mà người dùng sử dụng, bao gồm:

• Thiết bị
• Trình duyệt
• Mạng
• Microphone
• Loa

Thời gian sử dụng cũng không nhất thiết chỉ kéo dài vài phút. Nhiều người có thể sử dụng liên tục trong cùng một khoảng thời gian.

Khi xảy ra vấn đề, không thể chỉ yêu cầu người dùng kết nối lại. Cần điều tra nguyên nhân và thực hiện biện pháp ngăn tái diễn khi cần thiết.

Khi thương mại hóa AI hội thoại giọng nói, ít nhất cần đồng thời xem xét các yêu cầu sau:

Trong PoC, câu hỏi cần kiểm chứng là:

Trải nghiệm này có giá trị hay không?

Trong khi đó, khi thương mại hóa, câu hỏi trở thành:

Có thể tiếp tục cung cấp giá trị này một cách ổn định trong nhiều môi trường khác nhau hay không?

Đây là sự khác biệt lớn giữa PoC và phát triển production.

Vấn đề 1: Hoạt động khi nhiều người cùng sử dụng Gemini API trở nên không ổn định

Trong cấu trúc trình duyệt kết nối trực tiếp tới Gemini API, hội thoại diễn ra tương đối thuận lợi khi chỉ có một số ít người thử nghiệm.

Tuy nhiên, khi kiểm chứng trong điều kiện nhiều người sử dụng đồng thời, các vấn đề sau xuất hiện:

Những vấn đề này xảy ra ngay cả trong điều kiện mà lượng sử dụng có thể quan sát được và giới hạn tốc độ dự kiến dường như vẫn chưa đạt ngưỡng.

Ngoài ra, có những trường hợp hệ thống trả về lỗi giới hạn tốc độ hoặc vượt quota dù lượng sử dụng có vẻ vẫn còn dư.

Trên Google AI Developers Forum cũng có các báo cáo cho rằng cách tính giới hạn khi có nhiều session đồng thời khó hiểu, hoặc lỗi 429 xuất hiện dù tình trạng sử dụng có vẻ vẫn còn dư.

Tuy nhiên, các bài đăng trên forum chỉ là báo cáo của nhà phát triển và không có nghĩa rằng Google đã chính thức xác nhận nguyên nhân của từng sự việc.

Điểm khó của các hiện tượng này là rất khó xác định nguyên nhân nằm ở đâu:

• Phần triển khai của ứng dụng
• Mạng của client
• Số lượng session đồng thời
• Giới hạn theo project hoặc API key
• Region hoặc tải dịch vụ tạm thời
• Hành vi riêng của từng model
• Cơ chế kiểm soát nội bộ khác với quota đã công bố

Ngay cả khi nhận được lỗi, phía sử dụng API cũng khó có thể xác định hoàn toàn rằng đó thực sự là giới hạn tốc độ theo cài đặt, thiếu tài nguyên tạm thời, hay một vấn đề khác được biểu hiện dưới dạng lỗi giới hạn tốc độ.

Vấn đề 2: Phản hồi của model cũ trở nên kém ổn định gần thời điểm chuyển đổi model

Trong quá trình kiểm chứng, có những giai đoạn phản hồi của model cũ mà chúng tôi đang sử dụng trở nên kém ổn định vào khoảng thời gian một model mới được phát hành.

Trong môi trường của chúng tôi, khoảng một tuần trước khi model mới thuộc dòng 3.1 được phát hành, chúng tôi quan sát thấy những thay đổi sau ở model dòng 2.5 đang sử dụng:

• Thời gian chờ trước khi phản hồi bắt đầu dài hơn
• Số trường hợp không nhận được âm thanh tăng lên
• Âm thanh bị ngắt giữa chừng
• Chênh lệch chất lượng giữa các session lớn hơn
• Mức độ không ổn định tăng khi nhiều người sử dụng

Chúng tôi cũng quan sát thấy những thay đổi tương tự trong giai đoạn chuyển từ 2.0 sang 2.5.

Tuy nhiên, chúng tôi không thể xác nhận liệu có mối quan hệ nhân quả giữa việc chuẩn bị phát hành model mới và việc hành vi của model cũ trở nên kém ổn định hay không.

Đây chỉ là những hiện tượng được quan sát trong cùng khoảng thời gian tại môi trường kiểm chứng của chúng tôi.

Trên Google AI Developers Forum cũng có những báo cáo từ nhà phát triển về:

• Độ trễ của Live API tăng
• Native Audio bị gián đoạn
• Chất lượng có vẻ thay đổi trước hoặc sau khi cập nhật model

Các báo cáo này cũng chỉ là quan sát của từng người dùng và không thể kết luận rằng tất cả đều xuất phát từ cùng một nguyên nhân.

Khi cung cấp dịch vụ như một hoạt động kinh doanh, ngoài hiệu suất của model, các điểm sau cũng trở nên quan trọng:

• Có thể sử dụng ổn định cùng một model trong một khoảng thời gian nhất định hay không
• Hành vi sẽ thay đổi như thế nào khi model được cập nhật
• Có thể quay lại phiên bản trước nếu xảy ra vấn đề hay không
• Có thể so sánh song song model cũ và mới hay không
• Có thể kiểm chứng trước ảnh hưởng của việc thay đổi model hay không

Trong AI hội thoại giọng nói, chỉ một thay đổi nhỏ về độ trễ hoặc nhịp phát âm cũng có thể làm thay đổi đáng kể trải nghiệm người dùng.

Vì vậy, cần đánh giá ảnh hưởng của cập nhật model thận trọng hơn so với tạo văn bản thông thường.

Vấn đề 3: Khó điều tra nguyên nhân sự cố khi kết nối trực tiếp từ trình duyệt

Trong cấu trúc trình duyệt kết nối trực tiếp tới Gemini API, dữ liệu âm thanh không đi qua backend của công ty.

Điều này giúp hệ thống trở nên đơn giản, nhưng lại là điểm yếu khi điều tra sự cố.

Ví dụ, có thể xảy ra những vấn đề sau:

• Kết nối bị ngắt giữa cuộc hội thoại
• AI mất nhiều thời gian mới bắt đầu phản hồi
• Chỉ trong một số khung giờ nhất định mới khó kết nối
• Hệ thống trở nên không ổn định khi nhiều người sử dụng
• Chỉ một người dùng cụ thể bị chậm âm thanh
• Lỗi giới hạn tốc độ được trả về

Từ log phía trình duyệt, có thể xác nhận rằng kết nối đã bị ngắt hoặc đã nhận được một lỗi cụ thể.

Tuy nhiên, vì không có máy chủ do công ty quản lý nằm trên đường truyền, rất khó phân tích chi tiết nguyên nhân.

Có nhiều nguyên nhân có thể xảy ra:

• Mạng của người dùng
• Xử lý nội bộ của trình duyệt
• Kết nối WebSocket
• API chủ động ngắt kết nối
• Tải của model hoặc dịch vụ
• Region hoặc đường truyền mạng
• Số lượng người dùng đồng thời hoặc quota
• Thời điểm gửi dữ liệu âm thanh

Trong PoC, đôi khi có thể chỉ cần nói:

Vui lòng thử lại.

Tuy nhiên, đối với một dịch vụ được khách hàng thực tế sử dụng, bản thân việc không thể điều tra nguyên nhân đã là một rủi ro kinh doanh.

Vấn đề 4: Có sự đánh đổi giữa model mới nhất và nền tảng vận hành ổn định

Khi xem xét xác thực, quản lý lượng sử dụng và giám sát trong môi trường production, Vertex AI là một lựa chọn đáng cân nhắc.

Vertex AI dễ tích hợp với Google Cloud IAM và quản lý quota, đồng thời cho phép sử dụng API an toàn từ backend.

Tuy nhiên, tại thời điểm kiểm chứng, đã có trường hợp Live model mới có thể sử dụng trên Gemini API nhưng chưa khả dụng trên Vertex AI.

Nếu ưu tiên model mới nhất, có thể dễ dàng cải thiện chất lượng giọng nói và trải nghiệm hội thoại.

Ngược lại, nếu chuyển sang Vertex AI để ưu tiên vận hành ổn định và bảo mật, có thể không sử dụng được nguyên trạng model đã dùng trong PoC.

Điểm quan trọng là không thể quyết định cấu trúc của một dịch vụ thương mại chỉ bằng việc so sánh hiệu suất model.

Cần đánh giá toàn diện:

• Chất lượng model
• Hình thức cung cấp
• Xác thực
• Vận hành
• Log
• Xử lý sự cố

Vấn đề 5: Khi chuyển sang Vertex AI, hạ tầng truyền thông cũng phải được xây dựng lại

Với Gemini API, có thể sử dụng Ephemeral Token chỉ có hiệu lực trong thời gian ngắn để trình duyệt kết nối trực tiếp với Live API.

Nhờ đó, có thể xây dựng một đường truyền đơn giản mà không cần đặt API key có thời hạn dài trong trình duyệt.

Trong khi đó, Vertex AI chủ yếu sử dụng Google Cloud IAM, service account và các phương thức xác thực của Google Cloud.

Không thể đưa thông tin xác thực của service account vào trình duyệt, vì vậy trong cấu trúc production, thông thường cần đi qua backend do công ty quản lý.

Với chức năng chat thông thường, trình duyệt có thể gửi request tới backend, sau đó backend trả phản hồi của AI.

Tuy nhiên, hội thoại giọng nói cần truyền và nhận âm thanh hai chiều theo thời gian thực.

Vì vậy, không chỉ cần Web API thông thường mà còn cần một máy chủ thời gian thực có khả năng duy trì kết nối âm thanh trong thời gian dài.

Nói cách khác, việc chuyển từ Gemini API sang Vertex AI không chỉ đơn giản là thay đổi điểm kết nối.

Cấu trúc ban đầu là:

Gemini API
+ Ephemeral Token
+ Kết nối trực tiếp từ trình duyệt

Trong khi cấu trúc mới yêu cầu:

Vertex AI
+ Backend của công ty
+ Hạ tầng truyền thông thời gian thực
+ Quản lý session
+ Log và giám sát

Vấn đề 6: Cần một máy chủ truyền thông thời gian thực riêng ngoài Vercel

Frontend được triển khai bằng Next.js và host trên Vercel.

Đối với website hoặc web application thông thường, sự kết hợp giữa Next.js và Vercel rất dễ sử dụng.

Tuy nhiên, yêu cầu của dự án lần này là duy trì kết nối âm thanh hai chiều trong thời gian dài cho từng người dùng.

Do đó, chỉ với cấu trúc frontend hiện tại là không đủ. Cần chuẩn bị thêm một máy chủ có khả năng duy trì WebSocket hoặc kết nối thời gian thực tương đương.

Khi xây dựng realtime server, không chỉ cần chuyển tiếp âm thanh.

Còn phải xem xét:

• Duy trì kết nối lâu dài
• Kết nối lại khi bị ngắt
• Quản lý session theo từng người dùng
• Buffer dữ liệu âm thanh
• Mở rộng theo số lượng kết nối đồng thời
• Timeout
• Kiểm soát lượng sử dụng và chi phí
• Log và giám sát
• Chuyển đổi định dạng âm thanh

Một chức năng có vẻ nhỏ trong PoC có thể mở rộng đáng kể phạm vi phát triển và vận hành khi chuyển sang production.

Biện pháp xử lý: Sử dụng LiveKit để quản lý truyền thông giọng nói

Nếu tự triển khai toàn bộ hệ thống truyền thông âm thanh thời gian thực, không chỉ chi phí phát triển mà cả gánh nặng vận hành sau đó cũng sẽ rất lớn.

Vì vậy, chúng tôi đã đưa LiveKit vào sử dụng như một nền tảng WebRTC.

Việc sử dụng LiveKit giúp quản lý dễ dàng hơn các chức năng sau:

• Truyền thông âm thanh theo thời gian thực
• Quản lý session cho từng người dùng
• Giám sát trạng thái kết nối
• Liên kết với Agent process

So với việc tự xây dựng WebSocket server từ đầu, chúng tôi không cần tự triển khai toàn bộ chức năng cần thiết cho truyền thông giọng nói.

Ngoài ra, việc quản lý truyền thông ở phía hệ thống của công ty giúp thu thập được log theo từng session.

Ví dụ:

• Thời điểm bắt đầu và kết thúc kết nối
• Lý do ngắt kết nối
• Số lần kết nối lại
• Dung lượng âm thanh gửi và nhận
• Thời gian cho đến khi AI bắt đầu phản hồi
• Lỗi API
• Model và cài đặt đã sử dụng
• Thay đổi trạng thái session

Nhờ đó, việc phân biệt nguyên nhân trở nên dễ dàng hơn trước:

• Vấn đề ở phía API
• Vấn đề ở hạ tầng truyền thông
• Vấn đề ở phía client

Vấn đề riêng của trình duyệt và thiết bị vẫn còn sau khi đưa LiveKit vào sử dụng

Sự kết hợp giữa LiveKit và Vertex AI giúp việc ổn định truyền thông và vận hành phía server trở nên dễ dàng hơn.

Tuy nhiên, không phải mọi vấn đề đều được giải quyết.

Trong môi trường sử dụng thực tế, các vấn đề sau vẫn còn:

• Chỉ một số thiết bị cụ thể bị chậm khi phát âm thanh
• Chỉ một số trình duyệt cụ thể bị ngắt âm thanh
• Chất lượng âm thanh thay đổi sau khi sử dụng trong thời gian dài
• Hành vi thay đổi tùy theo trạng thái kết nối của thiết bị Bluetooth
• Phát sinh vấn đề khi chuyển microphone hoặc loa
• Chỉ có thể tái hiện vấn đề trong môi trường của một người dùng cụ thể
• Tốc độ phát âm thanh đột ngột trở nên cực kỳ chậm

Một trong những hiện tượng khó đánh giá nhất là trong lúc hội thoại, âm thanh đột ngột phát giống như chuyển động chậm.

Theo cảm nhận, tốc độ phát chỉ còn khoảng một phần mười so với bình thường.

Mặc dù dữ liệu âm thanh vẫn được server trả về, client không thể phát ở tốc độ chính xác.

Các nguyên nhân có thể bao gồm:

• Cách xử lý sample rate của âm thanh
• Audio buffer trong trình duyệt
• Trạng thái của AudioContext
• Tải của thiết bị
• Thiếu bộ nhớ
• Kết nối lại audio track
• Cơ chế tiết kiệm điện của hệ điều hành hoặc trình duyệt
• Lỗi tạm thời trong giải mã hoặc phát âm thanh

Tuy nhiên, lượng thông tin có thể thu thập từ web application là có giới hạn.

Ngay cả khi tăng log phía server, cũng không thể thu thập toàn bộ trạng thái bên trong trình duyệt hoặc thiết bị.

Ví dụ, các thông tin sau có thể không được quan sát đầy đủ:

• Trạng thái chi tiết của thiết bị âm thanh ở phía hệ điều hành
• Việc thiết bị âm thanh đang được ứng dụng khác sử dụng
• Xử lý âm thanh nội bộ của trình duyệt
• Tình trạng sử dụng CPU và bộ nhớ của toàn bộ thiết bị
• Kiểm soát chạy nền của hệ điều hành

Từ kinh nghiệm này, chúng tôi nhận ra rằng trong AI hội thoại giọng nói, cần tách biệt sự ổn định phía server và sự ổn định phía thiết bị người dùng.

LiveKit giúp giảm các vấn đề của hạ tầng truyền thông thời gian thực, nhưng không thể giải quyết mọi vấn đề phát âm thanh xảy ra trên thiết bị của người dùng.

Ở thời điểm hiện tại, native application kết hợp với Vertex AI là một lựa chọn đáng cân nhắc

Qua quá trình kiểm chứng, chúng tôi nhận thấy cấu trúc sau là một lựa chọn đáng cân nhắc đối với sản phẩm production được sử dụng liên tục.

Nói cách khác, đó là cấu trúc kết hợp native application và Vertex AI.

Tất nhiên, không phải dịch vụ nào cũng cần cấu trúc này.

Cấu trúc dựa trên trình duyệt vẫn có thể phù hợp trong các trường hợp:

• Demo ngắn
• Công cụ nội bộ có số lượng người dùng hạn chế
• Dịch vụ cần cho phép người dùng trải nghiệm dễ dàng mà không cần cài đặt

Ngược lại, native application đáng được cân nhắc hơn trong các dịch vụ sau:

• Người dùng thực hiện hội thoại giọng nói trong thời gian dài
• Độ trễ hoặc gián đoạn âm thanh ảnh hưởng đến công việc
• Cần kiểm soát microphone và loa một cách ổn định
• Cần thu thập chi tiết trạng thái thiết bị và thiết bị âm thanh
• Cần điều tra nguyên nhân chi tiết khi xảy ra sự cố
• Được sử dụng liên tục trong hoạt động hiện trường, chăm sóc khách hàng hoặc giáo dục
• Có thể chuẩn hóa môi trường thiết bị của người dùng ở một mức độ nhất định

Native application thường có thể truy cập chức năng của thiết bị và hệ điều hành dễ dàng hơn trình duyệt.

Nhờ đó, có thể dễ dàng hơn trong việc theo dõi và kiểm soát:

• Trạng thái microphone và loa
• Mức sử dụng bộ nhớ của ứng dụng
• Hoạt động nền
• Audio session
• Thay đổi thiết bị

Các lựa chọn điều tra sự cố cũng được mở rộng.

Ngoài ra, sử dụng Vertex AI ở backend giúp dễ dàng tích hợp xác thực, quản lý lượng sử dụng và giám sát trên Google Cloud.

Do đó, đối với dịch vụ production coi trọng sự ổn định và khả năng quản lý vận hành, ở thời điểm hiện tại, chúng tôi cho rằng native application kết hợp với Vertex AI là một lựa chọn mạnh.

Tuy nhiên, đây không phải là kiến trúc duy nhất đúng cho mọi sản phẩm.

Tình trạng cung cấp model và thông số của các dịch vụ thay đổi nhanh chóng. Khi lựa chọn thực tế, cần đánh giá lại:

• Model có thể sử dụng
• Chất lượng hội thoại và giọng nói
• Region mục tiêu
• Quota và số lượng kết nối đồng thời
• Chi phí hạ tầng
• Thiết bị người dùng dự kiến
• Thời gian của mỗi session
• Phạm vi điều tra sự cố cần thiết

Điều quan trọng không phải là tự động chọn model mới nhất, mà là lựa chọn cấu trúc bằng cách xuất phát từ chất lượng mà dịch vụ yêu cầu.

Những điểm người phụ trách dự án mới và PoC cần xác nhận trước khi phát triển thương mại

Trong dự án AI hội thoại giọng nói, khi PoC đã có thể thực hiện hội thoại, người ta dễ cảm thấy rằng có thể thương mại hóa ngay.

Tuy nhiên, trong thực tế, ở giai đoạn tiếp theo sau PoC, có thể cần xem xét lại đáng kể kiến trúc và phương thức client.

Trước khi bắt đầu phát triển thương mại, ít nhất cần xác nhận các điểm sau.

1. Làm rõ PoC đã kiểm chứng điều gì và chưa kiểm chứng điều gì

Ngay cả khi PoC đã xác nhận được trải nghiệm người dùng và giá trị dịch vụ, điều đó không có nghĩa là đã kiểm chứng các mục sau:

• Nhiều người sử dụng đồng thời
• Sử dụng liên tục trong thời gian dài
• Mạng chậm hoặc không ổn định
• Nhiều trình duyệt và hệ điều hành
• Thiết bị có ít bộ nhớ hoặc CPU
• Khôi phục khi API gặp sự cố
• Ảnh hưởng khi model được cập nhật

Khi đánh giá kết quả PoC, không chỉ nên xem PoC có thành công hay không, mà còn phải tổng hợp rõ điều kiện nào đã được kiểm chứng.

2. Tách kiểm chứng trải nghiệm người dùng khỏi kiểm chứng độ ổn định kỹ thuật

Việc kiểm tra người dùng có cảm thấy AI hội thoại giọng nói tiện lợi hay không và việc kiểm tra hệ thống có hoạt động ổn định trong production hay không có mục tiêu khác nhau.

Kiểm chứng trải nghiệm người dùng tập trung vào:

• Thiết kế hội thoại
• Giá trị dịch vụ
• Hành vi người dùng
• Giả thuyết kinh doanh

Kiểm chứng độ ổn định kỹ thuật tập trung vào:

• Kết nối đồng thời
• Truyền thông
• Khác biệt thiết bị
• Log
• Giám sát
• Khôi phục

Thay vì cố gắng kiểm chứng tất cả trong một PoC, việc chia thành nhiều giai đoạn giúp đánh giá kết quả dễ dàng hơn.

3. Cụ thể hóa môi trường sử dụng dự kiến

Một yêu cầu như “AI giọng nói có thể sử dụng trên web” là chưa đủ.

Cần làm rõ:

• PC, smartphone hay tablet
• Chỉ Chrome hay cả Safari
• Một cuộc hội thoại kéo dài bao nhiêu phút
• Có bao nhiêu người sử dụng đồng thời
• Có cần sử dụng ở nơi có kết nối mạng kém hay không
• Có thể chỉ định hoặc chuẩn hóa thiết bị của người dùng hay không

Cấu trúc phù hợp sẽ thay đổi tùy theo những điều kiện này.

4. Không quyết định cấu trúc chỉ dựa trên chất lượng model

Trong AI hội thoại giọng nói, chất lượng model rất quan trọng.

Tuy nhiên, trong dịch vụ thương mại, các mục sau cũng quan trọng tương đương:

• Xác thực
• Kết nối đồng thời
• Quota
• Đường truyền
• Log
• Giám sát
• Khôi phục sự cố
• Ứng phó với cập nhật model
• Kiểm soát thiết bị client

Model tạo ra hội thoại tự nhiên nhất trong PoC không nhất thiết là model hoặc nền tảng phù hợp nhất cho dịch vụ production.

5. Đưa khả năng phải xây dựng lại sau PoC vào kế hoạch

Cấu trúc dùng cho PoC không nhất thiết có thể được sử dụng nguyên trạng trong production.

Nên xác định PoC là phương tiện để nhanh chóng kiểm chứng giả thuyết kinh doanh và trải nghiệm người dùng.

Khi chuyển sang production, có thể cần xem xét lại:

• API
• Model
• Phương thức xác thực
• Hạ tầng truyền thông
• Phương thức client
• Log và giám sát
• Cấu trúc hạ tầng tổng thể

Điều quan trọng không phải là buộc PoC và production có cùng một cấu trúc, mà là nhận thức trước phần nào có thể được giữ lại và phần nào có thể phải xây dựng lại.

Những bài học rút ra

1. PoC thành công không có nghĩa rằng thương mại hóa sẽ thành công

Việc hệ thống hoạt động với ít người, trong thời gian ngắn và trên thiết bị giới hạn khác với việc nhiều người có thể sử dụng liên tục.

Trong PoC lần này, chúng tôi ưu tiên kiểm chứng trải nghiệm người dùng và giá trị dịch vụ. Vì vậy, kiến trúc cho vận hành production chưa được xem xét đầy đủ.

Khi sử dụng kết quả PoC để đưa ra quyết định thương mại hóa, cần làm rõ phạm vi chưa được kiểm chứng.

2. Kiểm chứng việc sử dụng đồng thời từ giai đoạn sớm

Ngay cả khi hệ thống ổn định với một người dùng, hành vi có thể thay đổi khi nhiều người kết nối đồng thời.

Không chỉ kiểm tra quota đã công bố, mà cần tạo tải với số lượng người dùng thực tế dự kiến để đánh giá chất lượng giọng nói và trạng thái kết nối.

3. Đánh giá model mới nhất và độ ổn định production một cách riêng biệt

Model mới nhất có thể mang lại trải nghiệm hội thoại tốt, nhưng không nhất thiết là lựa chọn ổn định nhất cho production.

Cần xem xét:

• Xác thực
• Quota
• Khả năng tiếp tục được cung cấp
• Giám sát
• Điều tra sự cố
• Ảnh hưởng của cập nhật

4. Thay đổi API có thể dẫn tới thay đổi toàn bộ hệ thống

Việc chuyển từ Gemini API sang Vertex AI có thể không chỉ là thay đổi endpoint.

Cũng có thể cần thay đổi:

• Xác thực
• Đường truyền
• Backend
• Quản lý session
• Thiết kế log

5. Đưa LiveKit vào sử dụng không loại bỏ vấn đề phía thiết bị

Nền tảng WebRTC như LiveKit giúp giảm các vấn đề về truyền thông thời gian thực và quản lý session.

Tuy nhiên, nó không thể giải quyết mọi vấn đề do:

• Trình duyệt
• Hệ điều hành
• Thiết bị âm thanh
• Tải của thiết bị

Khi xem xét hiện tượng riêng của thiết bị như âm thanh phát cực kỳ chậm, khả năng quan sát và kiểm soát phía client trở nên quan trọng.

6. Với production, native application kết hợp Vertex AI hiện là một lựa chọn mạnh

Khi xem xét tổng thể khả năng kiểm soát thiết bị, điều tra sự cố, xác thực và quản lý vận hành, native application kết hợp với Vertex AI là một lựa chọn mạnh đối với dịch vụ AI hội thoại giọng nói được sử dụng trong thời gian dài.

Tuy nhiên, web application vẫn có thể phù hợp hơn khi ưu tiên khả năng tiếp cận dễ dàng và tốc độ triển khai.

Không nên cố định lựa chọn web hay native ngay từ đầu, mà nên quyết định dựa trên:

• Mức độ ổn định yêu cầu
• Thời gian mỗi session
• Môi trường sử dụng
• Mức độ kiểm soát thiết bị cần thiết

Trong kinh nghiệm của chúng tôi, các dự án AI hội thoại giọng nói sử dụng native application đang được vận hành ổn định.

Tổng kết

Có thể xây dựng PoC Speech-to-Speech bằng Gemini trong thời gian tương đối ngắn.

Tuy nhiên, để biến nó thành dịch vụ thương mại, cần thiết kế nhiều yếu tố ngoài model AI.

Trong PoC lần này, chúng tôi ưu tiên kiểm chứng trải nghiệm người dùng và giá trị của toàn bộ dịch vụ, bao gồm cả các chức năng xung quanh.

Đối với mục tiêu đó, cấu trúc kết nối trực tiếp từ trình duyệt tới Gemini API là hiệu quả.

Tuy nhiên, khi quá trình thương mại hóa tiến triển, nhiều vấn đề bắt đầu xuất hiện:

• Không ổn định khi sử dụng đồng thời
• Lỗi có vẻ giống giới hạn tốc độ
• Hành vi model thay đổi
• Vấn đề âm thanh riêng của trình duyệt và thiết bị

Việc chuyển hạ tầng truyền thông sang LiveKit và Vertex AI đã cải thiện khả năng quản lý và quan sát phía server.

Tuy nhiên, các vấn đề được cho là phát sinh ở phía trình duyệt hoặc thiết bị vẫn còn, bao gồm trường hợp âm thanh đột ngột trở nên cực kỳ chậm.

Bài học quan trọng nhất từ kinh nghiệm này là:

Trong AI hội thoại giọng nói, cần thiết kế không chỉ dựa trên việc sử dụng model AI nào, mà còn phải xem xét thiết bị nào được sử dụng, dữ liệu đi qua đường truyền nào, và hệ thống có thể được quan sát và kiểm soát đến mức nào.

Trong PoC, điều quan trọng là nhanh chóng kiểm chứng giả thuyết kinh doanh và trải nghiệm người dùng.

Trong thương mại hóa, điều quan trọng là hệ thống phải hoạt động ổn định trên nhiều thiết bị và mạng khác nhau, đồng thời có thể điều tra nguyên nhân khi xảy ra sự cố.

Do đó, ngay từ khi bắt đầu PoC, cần ý thức các điểm sau:

• PoC sẽ kiểm chứng điều gì
• Cần kiểm chứng thêm điều gì trước khi thương mại hóa
• Dự kiến có bao nhiêu người sử dụng đồng thời
• Mỗi lần sử dụng kéo dài bao lâu
• Có thể chấp nhận mức độ trễ hoặc mất kết nối đến đâu
• Khi xảy ra sự cố, cần điều tra nguyên nhân đến mức nào
• Web hay native phù hợp hơn với môi trường sử dụng
• Kế hoạch có tính đến khả năng kiến trúc thay đổi giữa PoC và production hay không

Đối với sản phẩm production coi trọng độ ổn định, quản lý vận hành và kiểm soát thiết bị, ở thời điểm hiện tại, chúng tôi cho rằng native application kết hợp với Vertex AI là một lựa chọn mạnh.

Tuy nhiên, đây không phải là câu trả lời duy nhất đúng cho tất cả các dịch vụ AI giọng nói.

Trong AI hội thoại giọng nói, có một khoảng cách lớn giữa việc làm cho PoC hoạt động và việc tiếp tục cung cấp nó như một dịch vụ.

Nhận thức sớm khoảng cách này, đồng thời kiểm chứng trải nghiệm người dùng và kiến trúc thương mại theo từng giai đoạn, là điều quan trọng để giảm việc phải làm lại.