Latency là gì — độ trễ của AI quyết định khách chờ bao lâu mỗi câu trả lời

Bài này dành cho chủ doanh nghiệp và người quyết. Latency được giải bằng ẩn dụ dễ hiểu, kèm các yếu tố gây trễ, cách giảm và cách cân đúng với độ mạnh và chi phí.

Vì sao đáng quan tâm: độ trễ là thứ khách cảm nhận đầu tiên khi dùng trợ lý AI. Một câu trả lời đúng nhưng chờ lâu vẫn mất điểm, nên độ trễ là một phần của chất lượng dịch vụ, không phải chuyện riêng của kỹ thuật.

Hình dung một khách gọi món trong nhà hàng. Từ lúc gọi tới lúc món ra bàn là khoảng thời gian chờ. Món có ngon tới đâu, chờ quá lâu khách vẫn khó chịu và lần sau ngại quay lại.

Gửi yêu cầu cho AI cũng vậy. Từ lúc khách bấm gửi tới lúc dòng trả lời hiện ra là độ trễ. Khách chờ tổng đài đổ chuông mãi không ai bắt máy cũng là cùng một cảm giác đó.

Quãng chờ này khách luôn cảm nhận được, dù họ không gọi tên nó. Latency là thời gian khách ngồi chờ món ra, và nó định hình ấn tượng về dịch vụ ngay từ giây đầu tiên.

Một yêu cầu gửi tới AI đi qua nhiều chặng, mỗi chặng cộng thêm một khoảng thời gian. Tổng các khoảng đó là độ trễ mà khách thấy.

• Đường truyền. Yêu cầu đi từ thiết bị khách tới máy chủ và quay về, khoảng cách càng xa càng lâu.
• Xử lý của mô hình. Mô hình càng lớn càng tốn thời gian tính cho mỗi phần trả lời.
• Độ dài đầu ra. Trả lời càng dài càng phải sinh nhiều token nên càng lâu.
• Hạ tầng và tải. Máy chủ yếu hoặc đang đông yêu cầu làm thời gian chờ tăng lên.

Độ trễ thường được nhìn ở hai mốc: thời gian tới chữ đầu tiên hiện ra, và thời gian tới khi trả lời xong. Hai mốc này gắn với phần xử lý inference của mô hình.

• Giữ khách. Chờ lâu khách bỏ ngang, độ trễ thấp giữ khách ở lại tới hết cuộc trò chuyện.
• Tăng chuyển đổi. Phản hồi nhanh giúp chốt đơn và trả lời tư vấn ngay lúc khách còn quan tâm.
• Năng suất nhân viên. Trợ lý AI nội bộ nhanh giúp nhân viên xử lý việc liền tay.
• Hình ảnh dịch vụ. Tốc độ phản hồi tạo cảm giác chuyên nghiệp và đáng tin.
• Chi phí và quy mô. Cách giảm trễ gắn với chọn mô hình và hạ tầng, ảnh hưởng thẳng chi phí vận hành.

Độ trễ là phần khách cảm nhận trước cả nội dung trả lời. Vì vậy nó là một thước đo trải nghiệm, không chỉ là chỉ số nội bộ của đội kỹ thuật.

Một yêu cầu gửi tới AI đi qua bốn nhịp, mỗi nhịp góp vào tổng độ trễ:

• Rời thiết bị. Yêu cầu đi từ máy khách qua đường truyền tới máy chủ.
• Mô hình nhận và xử lý. Mô hình đọc yêu cầu rồi bắt đầu tính toán.
• Sinh đầu ra. Mô hình sinh trả lời từng phần, càng dài càng tốn thời gian.
• Phản hồi quay về. Kết quả đi ngược đường truyền về thiết bị khách.

Vì độ trễ cộng dồn qua nhiều chặng, không có một nút bấm duy nhất làm nhanh tất cả. Giảm trễ là gỡ ở từng chặng, từ streaming cho phần đầu ra tới đặt máy chủ gần khách hơn.

Giả sử khách hỏi trợ lý AI về một chính sách đổi trả. Yêu cầu rời điện thoại khách, đi tới máy chủ, mô hình bắt đầu xử lý.

Nếu bật streaming, chữ đầu tiên hiện ra sớm nên khách thấy hệ thống đang chạy, cảm giác chờ ngắn lại dù toàn bộ câu chưa xong. Nếu trả lời dài và mô hình lớn, thời gian tới khi xong sẽ kéo dài thêm.

Cùng một câu hỏi, độ trễ thay đổi theo mô hình, độ dài trả lời và máy chủ đặt ở đâu. Đó là lý do cùng một trợ lý AI lúc thấy nhanh lúc thấy chậm tuỳ tình huống.

Cùng một câu trả lời, độ trễ khác nhau cho hai trải nghiệm khác hẳn:

Việc cần khách chờ trước mặt thì độ trễ thấp là bắt buộc. Việc chạy ngầm không ai ngồi đợi thì độ trễ cao chấp nhận được, đổi lại có thể dùng mô hình mạnh hơn.

Hạ độ trễ thường phải cân với vài điểm khác:

• Độ mạnh mô hình. Mô hình nhỏ trả lời nhanh hơn nhưng có thể kém sâu so với mô hình lớn.
• Chi phí hạ tầng. Đặt nhiều máy chủ gần khách hoặc máy mạnh hơn để giảm trễ đều tốn thêm.
• Độ dài và độ chi tiết. Trả lời ngắn gọn nhanh hơn nhưng đôi khi thiếu ý so với trả lời đầy đủ.

Cách làm đúng là chọn điểm cân hợp với từng việc. Khâu khách chờ trước mặt ưu tiên độ trễ thấp, khâu chạy ngầm ưu tiên độ mạnh, không ép một cấu hình cho mọi tình huống.

Có nhiều hướng giảm độ trễ, mỗi hướng gỡ một chặng khác nhau, thường kết hợp:

Các cách này không loại trừ nhau. Một hệ thống thực tế thường dùng mô hình vừa cỡ, bật streaming, cache câu hay lặp và đặt máy chủ gần khách, gỡ trễ ở nhiều chặng cùng lúc.

• Tưởng độ trễ chỉ là chuyện kỹ thuật. Khách cảm nhận trực tiếp nên đây là chuyện trải nghiệm và doanh thu.
• Tưởng cứ mô hình mạnh nhất là tốt nhất. Mô hình lớn mạnh hơn nhưng trễ cao hơn, không phải lúc nào cũng hợp.
• Tưởng streaming làm AI chạy nhanh hơn. Streaming chỉ hiện chữ sớm, tổng thời gian xử lý không đổi.
• Bỏ qua khoảng cách máy chủ. Máy chủ đặt xa khách cộng thêm độ trễ đường truyền đáng kể.
• Chỉ nhìn lúc vắng. Khi đông yêu cầu độ trễ tăng lên, cần đo cả lúc cao điểm.

Phần lớn hiểu nhầm đến từ coi độ trễ là một con số cố định. Thực tế nó thay đổi theo mô hình, độ dài trả lời, hạ tầng và lượng khách đang dùng cùng lúc.

MONA xử lý độ trễ theo hướng đo trước rồi mới tối ưu, gỡ ở đúng chặng đang gây chậm:

• Đo theo từng việc. Xác định khâu nào khách chờ trước mặt, khâu nào chạy ngầm để đặt mục tiêu trễ khác nhau.
• Chọn cỡ mô hình hợp. Dùng mô hình nhỏ hơn cho khâu cần nhanh, để mô hình mạnh cho khâu chạy ngầm.
• Bật streaming và cache. Hiện chữ sớm cho khách đỡ sốt ruột, cache các câu hỏi hay lặp lại.
• Đặt máy chủ gần khách. Rút ngắn đường truyền cho thị trường chính, theo dõi cả lúc cao điểm.

Trợ lý AI phục vụ khách thường chạm vào dữ liệu cá nhân khi xử lý yêu cầu. MONA tối ưu độ trễ trong khuôn khổ tuân thủ nguyên tắc dữ liệu theo Nghị định 13/2023, không hy sinh an toàn để lấy tốc độ.

Độ trễ cần được ưu tiên khi khách hoặc nhân viên phải chờ trực tiếp kết quả:

• Trợ lý trả lời khách trực tuyến. Khách ngồi chờ từng câu nên độ trễ thấp là bắt buộc.
• Tư vấn và chốt đơn. Chậm một nhịp là mất khách đang quan tâm, tốc độ ảnh hưởng doanh thu.
• Trợ lý nội bộ dùng liên tục. Nhân viên gọi nhiều lần trong ngày nên mỗi giây chờ cộng dồn.
• Lượng khách lớn cùng lúc. Khi đông yêu cầu độ trễ dễ tăng, cần thiết kế chịu tải.

Với khâu chạy ngầm không ai ngồi đợi, độ trễ cao chấp nhận được và nên ưu tiên độ mạnh. Với khâu khách chờ trước mặt, độ trễ thấp là điều kiện của trải nghiệm tốt.

Độ trễ dễ hiểu nhưng cân đúng giữa nhanh, mạnh và chi phí cần kinh nghiệm vận hành thật. Doanh nghiệp nên cân nhắc MONA khi:

• Trợ lý AI trả lời khách thấy chậm và khách hay bỏ ngang giữa chừng.
• Cần chọn cỡ mô hình và hạ tầng hợp với từng khâu thay vì một cấu hình cho tất cả.
• Muốn dùng streaming, cache và đặt máy chủ gần khách để giảm độ trễ một cách có chủ đích.
• Cần đo độ trễ cả lúc cao điểm và giữ ổn định khi lượng khách tăng.

MONA đo, tối ưu và vận hành trợ lý AI với độ trễ phù hợp từng việc, có theo dõi liên tục. Tham khảo Sale AI cho trợ lý trả lời và chốt đơn cần phản hồi nhanh, LMS AI cho trợ lý học tập tương tác liền tay với người học.