# Theo dõi ứng dụng AI bằng nhật ký tác vụ: tìm điểm chậm mà không cần ghi lại mọi câu hỏi

Nội dung có liên kết giới thiệu SunAPI. Bài viết mô tả cách thiết kế quan sát vận hành ở tầng ứng dụng. Những trường dữ liệu và màn hình trong ví dụ là đề xuất thiết kế, không phải khẳng định SunAPI cung cấp sẵn toàn bộ hệ thống này hay bảo đảm một mức hiệu năng cụ thể.

Người dùng báo ứng dụng AI chậm, nhưng nhóm vận hành chỉ có một dòng thông báo yêu cầu thành công. Thời gian có thể nằm ở hàng chờ, lấy tài liệu, gọi model, kiểm tra đầu ra hoặc lưu kết quả. Nếu không phân biệt các bước, nhóm dễ đổi model trước khi biết điểm chậm thực sự. Việc quan sát cần bắt đầu từ đường đi của một tác vụ và câu hỏi mà người vận hành muốn trả lời.

Một ứng dụng kết nối qua SunAPI có thể giữ nhật ký riêng cho các bước do mình kiểm soát, rồi đối chiếu thông tin phản hồi khi phù hợp. Không cần mặc định lưu toàn bộ prompt và câu trả lời để theo dõi mọi vấn đề. Nhiều câu hỏi vận hành có thể được giải quyết bằng mã tác vụ, trạng thái, mốc thời gian và cấu hình. Thiết kế chọn lọc giúp nhật ký có mục đích rõ thay vì trở thành kho dữ liệu không ai quản lý.

# Vẽ đường đi của tác vụ trước khi chọn chỉ số

Hãy mô tả tác vụ từ lúc người dùng gửi đến lúc họ thấy kết quả. Với một ứng dụng tạo bản nháp, đường đi có thể gồm tiếp nhận, chờ xử lý, chuẩn bị dữ liệu, gọi API, kiểm tra kết quả và lưu bản nháp. Mỗi bước cần có trạng thái bắt đầu, kết thúc hoặc thất bại. Danh sách này giúp nhóm biết mình đang đo phần nào của trải nghiệm, không chỉ đo thời gian kết nối ra ngoài.

Một bước có thể chạy nhiều lần do thử lại. Nếu nhật ký chỉ ghi kết quả cuối, nhóm sẽ không thấy một tác vụ thành công đã trải qua bao nhiêu lần gọi. Nên phân biệt mã tác vụ tổng với mã lần thử. Nhờ vậy có thể trả lời yêu cầu này mất lâu vì chờ, vì nhiều lần thử hay vì một lần xử lý kéo dài, mà không phải suy đoán từ một con số tổng duy nhất.

Các thao tác song song cũng cần quan hệ rõ. Một tác vụ có thể lấy hai nguồn cùng lúc rồi hợp nhất. Cộng thời gian hai bước không nhất thiết bằng thời gian người dùng chờ. Khi trình bày báo cáo, hãy phân biệt thời gian từng bước với thời gian toàn luồng. Cách diễn giải đúng quan trọng hơn số lượng biểu đồ, vì một phép cộng sai có thể dẫn nhóm tới nguyên nhân không tồn tại.

# Chọn trường dữ liệu theo câu hỏi cần trả lời

Một bản ghi tối thiểu có thể chứa mã tác vụ, loại công việc, thời điểm, trạng thái, phiên bản cấu hình và mã lần thử. Nếu cần phân tích theo nguồn hoặc mẫu prompt, dùng mã tham chiếu đã được quản lý. Không đưa thêm nội dung người dùng chỉ vì thuận tiện cho người viết log. Mỗi trường nên có lý do tồn tại và người hiểu cách sử dụng nó khi điều tra.

Tên model thực tế cùng phiên bản ứng dụng có thể giúp nhận ra thay đổi sau triển khai. Tuy nhiên không nên đưa khóa API vào nhật ký hoặc ảnh chụp báo lỗi. Các định danh cần được xem xét theo phạm vi truy cập và chính sách dữ liệu của tổ chức. Người chỉ cần xem số lượng lỗi không nhất thiết cần quyền đọc dữ liệu có thể liên hệ đến từng khách hàng.

Đối với trường lỗi, nên lưu loại lỗi đã chuẩn hóa cùng thông tin kỹ thuật cần thiết trong phạm vi phù hợp. Một thông báo lỗi thô có thể chứa dữ liệu không mong muốn. Nhóm cần kiểm tra đường đi dữ liệu và cách che hoặc loại bỏ các phần không cần thiết. Không xem việc nội dung nằm trong thông báo kỹ thuật là lý do tự động cho phép lưu ở mọi nơi hoặc gửi cho mọi người.

# Phân biệt hoàn tất kỹ thuật và kết quả dùng được

Một phản hồi được nhận không đồng nghĩa bản nháp đã hợp lệ. Ứng dụng có thể nhận nội dung thiếu trường, sai phạm vi hoặc không đáp ứng tiêu chí. Nhật ký nên thể hiện các trạng thái riêng: gọi thành công, kiểm tra thất bại, chờ người xem lại và đã hoàn tất tác vụ. Nếu gộp tất cả thành thành công, báo cáo sẽ khác trải nghiệm thực tế của người dùng.

Ví dụ model trả về một đoạn văn trong khi phần mềm đang cần các trường đã quy định. Kết nối đã hoạt động nhưng bước đọc dữ liệu không thể tiếp tục. Ghi lỗi ở tầng xác thực đầu ra giúp nhóm thấy cần sửa cấu trúc hoặc cách xử lý, thay vì xem đây là lỗi mạng. Mỗi loại thất bại cần dẫn đến một hướng kiểm tra cụ thể để số liệu phục vụ được hành động.

Kết quả được người dùng chấp nhận cũng là một khái niệm khác. Một bản nháp hợp lệ có thể cần sửa nhiều, hoặc bị bỏ vì không đúng nhu cầu. Nếu sản phẩm theo dõi các tín hiệu này, cần định nghĩa rõ và thu thập theo chính sách phù hợp. Không suy ra chất lượng nội dung chỉ từ việc yêu cầu kết thúc không có mã lỗi. Cả chất lượng và vận hành đều quan trọng nhưng cần được đo theo cách riêng.

# Đo thời gian theo trải nghiệm cần cải thiện

Thời gian toàn tác vụ cho biết người dùng chờ bao lâu, còn thời gian từng bước giúp tìm nơi cần sửa. Với giao diện nhận nội dung từng phần, thời điểm có phần đầu tiên và thời điểm hoàn tất có thể là hai thông tin hữu ích. Chúng không nên được dùng thay nhau. Một ứng dụng hiện chữ sớm nhưng mất lâu để hoàn thành vẫn có một kiểu trải nghiệm khác với trả toàn bộ cùng lúc.

Đừng chỉ nhìn một giá trị trung bình. Một số tác vụ rất chậm có thể bị che bởi nhiều tác vụ ngắn. Nhóm nên chọn cách biểu diễn phân bố phù hợp và xem các trường hợp chậm theo loại công việc. Câu hỏi ngắn, tạo báo cáo dài và xử lý nhiều nguồn không nên bị gộp thành một nhóm nếu mục tiêu là tìm thay đổi ảnh hưởng đến từng luồng cụ thể.

Các mốc thời gian cần có ý nghĩa nhất quán. Nếu bước được đo trên nhiều máy, cách ghi nhận phải được thiết kế để tránh diễn giải sai chênh lệch. Người đọc báo cáo cần biết thời gian chờ có nằm trong chỉ số hay không. Một thay đổi cách đo có thể làm biểu đồ khác đi dù trải nghiệm không đổi, nên phiên bản phương pháp đo cũng cần được ghi nhận khi có điều chỉnh đáng kể.

# Theo dõi lần thử lại và tác vụ bị hủy

Một hệ thống có nhiều lần thử lại có thể vẫn đạt tỷ lệ hoàn tất cao nhưng dùng thêm tài nguyên và làm người dùng chờ. Hãy theo dõi số lần thử cùng nguyên nhân và điểm dừng. Không coi thử lại là giải pháp vô hạn cho mọi loại lỗi. Quy tắc cần phân biệt lỗi có thể tạm thời với lỗi yêu cầu phải sửa cấu hình hoặc dữ liệu trước khi tiếp tục.

Tác vụ người dùng hủy cũng cần trạng thái riêng. Nếu giao diện ngừng chờ nhưng công việc phía sau vẫn chạy, nhật ký phải giúp nhận ra điều đó. Không tự ghi mọi tác vụ bị hủy là lỗi của nhà cung cấp, cũng không xóa dấu vết vì chúng không tạo kết quả cuối. Chúng cho biết sản phẩm có đang làm người dùng bỏ dở hoặc có đường xử lý nào cần xem lại.

Khi nhiều kết quả đến muộn, mã tác vụ giúp tránh ghi kết quả vào sai nơi. Nhật ký nên thể hiện kết quả đã bị bỏ qua vì phiên bản thay đổi hoặc vì người dùng chuyển sang việc khác. Đây là một trạng thái vận hành có ý nghĩa. Nó khác với việc kết quả chưa từng được nhận và khác với việc hệ thống đã sử dụng nội dung đó cho bản nháp hiện tại.

# Tạo cảnh báo gắn với việc cần làm

Một cảnh báo hữu ích cần nêu hiện tượng, phạm vi và bước kiểm tra đầu tiên. Thông báo hệ thống có lỗi mà không có tác vụ hay loại lỗi thường buộc người trực bắt đầu lại từ đầu. Nhóm nên xác định ai nhận, trong khung thời gian nào và điều kiện nào đáng gọi là thay đổi cần xử lý. Không cần biến mọi phản hồi bất thường thành một thông báo khẩn cấp.

Ngưỡng cảnh báo nên dựa vào nhu cầu của luồng và dữ liệu vận hành đã quan sát. Khi chưa có đủ dữ liệu, có thể bắt đầu bằng các điều kiện đơn giản và điều chỉnh có ghi nhận. Không lấy một ngưỡng của hệ thống khác rồi coi là tiêu chuẩn cho mọi tác vụ AI. Số yêu cầu nhỏ hoặc loại công việc khác nhau có thể khiến cùng một tỷ lệ mang ý nghĩa rất khác.

Cảnh báo cũng cần cách kết thúc. Khi tình trạng trở lại bình thường, người vận hành cần biết và có thể ghi nhận nguyên nhân sau đó. Nếu hệ thống liên tục gửi cùng một thông báo không có thay đổi, người nhận dễ bỏ qua cả những lần quan trọng. Quy trình phản hồi nên giúp mỗi cảnh báo dẫn đến một quyết định cụ thể, đồng thời giữ lịch sử để xem lại khi điều tra.

# Điều tra một tác vụ bằng dấu vết vừa đủ

Khi có báo lỗi, bắt đầu từ mã tác vụ và các mốc đã ghi. Xác định bước thất bại, cấu hình đang dùng và số lần thử. Nếu cần xem nội dung chi tiết, việc truy cập phải theo quyền và mục đích phù hợp. Không mở rộng thu thập dữ liệu cho mọi yêu cầu chỉ vì một sự cố cần thêm thông tin. Có thể tạo cách chẩn đoán có giới hạn và thời gian giữ rõ ràng theo chính sách của nhóm.

Tài liệu SunAPI hướng dẫn khi gặp timeout hoặc lỗi máy chủ, thông tin hỗ trợ có thể gồm thời điểm, tên model và request ID; không gửi API key. Nhóm nên đối chiếu mục xử lý lỗi của SunAPI trước khi chuẩn bị yêu cầu hỗ trợ. Chỉ gửi những thông tin liên quan và đã kiểm tra, không đính kèm nguyên nhật ký có dữ liệu ngoài phạm vi cần thiết.

Nếu không có request ID hoặc một trường phản hồi như mong đợi, ghi rõ điều đã quan sát thay vì tự tạo giá trị. Mã nội bộ của ứng dụng vẫn có thể giúp liên hệ các bước do mình quản lý. Đừng gọi hai loại định danh là một nếu chúng đến từ các hệ thống khác nhau. Sự chính xác trong mô tả giúp người nhận hỗ trợ tìm đúng yêu cầu và tránh điều tra nhầm thời điểm.

# Duy trì nhật ký như một phần của sản phẩm

Các trường nhật ký cần được cập nhật khi luồng công việc thay đổi. Một bước mới nhưng không có dấu vết sẽ tạo khoảng trống; một trường không còn dùng có thể tạo sự nhầm lẫn. Định kỳ xem lại báo cáo và các cuộc điều tra gần đây để biết dữ liệu nào thực sự giúp ích. Loại bỏ thu thập không cần thiết theo chính sách phù hợp và giữ mô tả trường đủ rõ để người mới hiểu.

Một hệ thống quan sát tốt không phải hệ thống ghi nhiều nhất. Nó giúp nhóm trả lời tác vụ nào bị ảnh hưởng, bước nào gây vấn đề và hành động nào nên làm tiếp, với dữ liệu vừa đủ và quyền truy cập rõ. Khi thiết kế từ những câu hỏi cụ thể đó, nhật ký trở thành công cụ cải thiện trải nghiệm thay vì một tập dòng kỹ thuật chỉ được mở sau khi mọi người đã bắt đầu đoán nguyên nhân.