Đừng bao giờ thay đổi nhà cung cấp LLM nếu chưa thực hiện 'Smoke Test' này

Tại sao 'Hello World' không đủ để kiểm thử LLM?

Nhiều lập trình viên thường mắc sai lầm khi kiểm thử việc chuyển đổi nhà cung cấp LLM bằng cách chỉ thay đổi base URL và gửi một prompt đơn giản. Nếu phản hồi trả về thành công, họ cho rằng mọi thứ đã ổn. Tuy nhiên, đây là một cái bẫy nguy hiểm.

Một yêu cầu "hạnh phúc" (happy-path) không cho bạn biết điều gì sẽ xảy ra khi:

• Request bị timeout.
• Stream bị ngắt quãng.
• Phản hồi giới hạn tốc độ (rate limit) có cấu trúc lạ.
• Ứng dụng cố gắng thử lại (retry) một tác vụ đã kích hoạt tool call.

Trước khi tin tưởng một nhà cung cấp mới, bạn cần thực hiện một Smoke Test – không phải để so sánh hiệu năng, mà để đảm bảo ứng dụng của bạn có thể xử lý các tình huống lỗi một cách dự đoán được.

5 Bước Smoke Test cho LLM API

1. Kiểm tra yêu cầu cơ bản (Boring Request)

Đừng chỉ log nội dung văn bản. Hãy log toàn bộ "phong bì" (envelope) của phản hồi để kiểm tra tính nhất quán:

const started = Date.now();
const response = await client.chat.completions.create({
  model: process.env.MODEL,
  messages: [{ role: "user", content: "Reply with exactly one short sentence." }]
});

console.log({
  latency_ms: Date.now() - started,
  content: response.choices?.[0]?.message?.content,
  finish_reason: response.choices?.[0]?.finish_reason,
  usage: response.usage,
  id: response.id
});

2. Kiểm tra hành vi Timeout

Sử dụng AbortController để ép buộc timeout và quan sát cách SDK phản hồi:

const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 200);

try {
  await client.chat.completions.create({ ... }, { signal: controller.signal });
} catch (error) {
  console.log({ name: error.name, message: error.message, code: error.code, status: error.status });
} finally {
  clearTimeout(timeout);
}

Bạn cần biết: Request có thực sự bị hủy không? SDK có ném ra lỗi phân loại được không?

3. Kiểm tra Streaming Completion

Streaming là nơi ẩn chứa nhiều lỗi nhất. Bạn cần xác định xem stream có kết thúc "sạch" với metadata đầy đủ hay không:

for await (const chunk of stream) {
  const reason = chunk.choices?.[0]?.finish_reason;
  if (reason) {
    finishReason = reason;
    finalChunkSeen = true;
  }
}

Nếu ứng dụng của bạn là một hệ thống tác nhân (agent) hoặc gọi công cụ (tool-calling), việc phân biệt giữa "đã hoàn thành" và "ngừng nhận dữ liệu" là sống còn.

4. Phân loại lỗi (Rate Limit & Token Limit)

Đừng xử lý mọi lỗi như nhau. Bạn cần một hàm phân loại lỗi để quyết định hành động tiếp theo:

function classifyLlmFailure(error) {
  if (error.status === 429) return { type: "rate_limit", retryable: true };
  if (error.status === 400 && /token/i.test(error.message)) return { type: "token_limit", retryable: false };
  return { type: "unknown", retryable: false };
}

5. Kiểm tra Tool-Call (Side-effect Risk)

Nếu LLM của bạn có thể thực hiện hành động (gửi email, ghi database), bạn phải đảm bảo logic retry không gây ra việc thực hiện trùng lặp (duplicate actions).

function shouldRetry({ sideEffectRisk, streamStarted }) {
  if (sideEffectRisk === "none") return true;
  if (sideEffectRisk === "possible" && streamStarted) return false;
  return false;
}

Kết luận

Quy tắc vàng hiện nay là: Nếu bạn không thể log hành vi của nhà cung cấp một cách rõ ràng, bạn không nên vận hành nó trong môi trường production. Hãy đảm bảo ứng dụng của bạn hiểu rõ các "vết nứt" trong API của nhà cung cấp trước khi người dùng của bạn phát hiện ra chúng.