LLM trả {} trong 0.0 giây: lỗi nằm ở code của chính bạn

Log không có lỗi. Response rỗng. Bạn kết luận model sập dưới tải song song — và ghi luôn vào notes.

Một team làm dịch vụ lọc lead từ Telegram đã sống ba ngày với kết luận đó, trước khi phát hiện model chưa từng được gọi. Câu chuyện của họ có một tín hiệu chẩn đoán đáng chép vào runbook.

Dấu hiệu nằm ở thời gian, không nằm ở log

Ghi chép ban đầu của họ rất chắc chắn: "the model fails under parallel load, 118 empty responses out of 225 calls" — 118 response rỗng trên 225 lần gọi, log sạch, không một lỗi nào.

Nguyên nhân thật: hàm llm.chat_json của họ gọi một billing guard ngay dòng đầu. Với tài khoản hết hạn subscription, guard đó return sớm và chat_json trả về {} ngay lập tức, không hề gọi model. Đó là một quy tắc sản phẩm có chủ đích. Nhưng ở tầng dưới, batch filter chỉ thấy response rỗng và đánh trượt toàn bộ message.

Tín hiệu phân biệt, viết nguyên văn: "The refusal arrived in 0.0 seconds. A real model call takes 4 to 9 seconds. If your 'model failure' is instant, it is not the model, it is your own code returning early."

Sau khi sửa test harness, họ đo lại: 12 lần gọi song song liên tiếp, 12 lần thành công, mỗi lần 8 đến 9 giây, với system prompt dài tới 15.896 ký tự. Không có lỗi nào.

Cái bẫy thứ hai: chính tài khoản của bạn trong mẫu đo

Lần đo chất lượng đầu tiên, họ để lẫn tài khoản nội bộ của staff và admin vào mẫu. Nhân viên bấm "contact" vô tội vạ để thử hệ thống, nên nhãn "good request" dính vào cả tiếng than phiền hàng xóm sửa nhà lẫn một bài quảng cáo. Model từ chối đúng, còn harness đếm mỗi lần từ chối là một lần mất khách.

Kết quả: "Until we dropped our own accounts from the sample, the loss figure was twice as bad as reality." Tỷ lệ mất gấp đôi thực tế.

Con số sau khi dọn mẫu

Mẫu cuối: 8 tài khoản khách trả tiền còn hiệu lực, 100 request, gán nhãn theo hành vi thay vì theo ý kiến.

Chỉ số	Kết quả
Rác bị lọc bỏ	95% (58/61)
Request tốt bị mất	18% (7/39)
Rác cắt được trên mỗi request tốt mất đi	8,3 : 1

Họ đọc tay cả 7 ca mất: 5 ca thực ra là từ chối đúng, do nhãn quá rộng tay. Mức mất thật gần 5%. Bối cảnh: trên toàn bộ dữ liệu, 542.795 kết quả khớp từ khoá chỉ có 14.774 request thật — 97,3% là rác.

Ba điều mang sang được bất kỳ sản phẩm nào có LLM bên trong

• Theo dõi phân phối latency, không chỉ error rate. Một lần từ chối tức thì gần như luôn là short-circuit trong stack của chính bạn — billing guard, cache, rate limiter hay validation layer. Nguồn nói đúng chỗ đau: lỗi thì được log, còn early return thì thường không.
• Biết ai đang nằm trong mẫu đo trước khi kết luận. Loại bỏ tài khoản nội bộ và mọi tương tác do người vận hành bấm, nếu không bạn đang đo nhãn của mình chứ không đo model.
• Định giá hai loại lỗi riêng biệt. Để lọt rác tốn của khách một phút đọc; làm mất một request thật thì tốn tiền. Hai thứ đó không đối xứng.

Một lưu ý cuối đáng dán lên tường: sau khi đo xong họ không chỉnh prompt. Lý do, nguyên văn: "Tuning a prompt against noise is how you ship a regression and call it an improvement." Với mẫu 100 request, nhiễu đo lớn hơn mức cải thiện kỳ vọng.