Dạy cho con bot một giác quan: tự biết mình có khoẻ không

Con bot của tôi chạy ngon cả tuần. Hôm nay tôi vẫn dừng lại để dạy nó một việc nghe rất thừa: tự nói cho tôi biết nó có đang ốm không.

Nghe ngược đời. Đang chạy tốt thì lắp cảm biến làm gì? Nhưng đây chính là khoảng cách mà gần như ai mới ship sản phẩm cũng rơi vào: "code chạy được" không phải là "code vận hành được".

Một con bot câm về sức khoẻ của chính nó

Hình dung con bot trước hôm nay. Khách nhắn — nó trả lời. Trông như mọi thứ ổn.

Nhưng giả sử Redis rớt kết nối. Hoặc cơ sở dữ liệu khoá lại. Hoặc Facebook bắt đầu từ chối từng tin tôi gửi đi. Từ bên ngoài, tôi không thấy gì cả. Bot vẫn "sống", cổng vẫn mở, không có dòng lỗi nào đỏ lên màn hình tôi đang nhìn.

Cái tôi chỉ phát hiện ra là: ba ngày sau, một chủ spa nhắn "sao mấy hôm nay bot im re vậy em?".

Đó là kiểu hỏng tệ nhất — hỏng âm thầm. Trong một công ty, sẽ có đội vận hành, có bảng theo dõi, có người trực đêm. Ship một mình thì không. Người trực đêm là tôi, và tôi đang ngủ. Nên con bot phải tự biết kêu.

Giác quan thứ nhất: "tôi sẵn sàng phục vụ chưa?"

Tôi tách bạch hai câu hỏi mà người mới hay gộp làm một.

Câu một: "Bot còn sống không?" — tiến trình còn chạy, cổng còn mở. Cái này dễ.

Câu hai mới quan trọng: "Bot có đủ sức làm việc không?" — nó còn nối được tới Redis (trí nhớ hội thoại), tới cơ sở dữ liệu (bảng giá, thông tin khách) không?

Tôi làm một đường /health riêng. Mỗi lần gọi, nó tự ping Redis và chạy một câu hỏi nhẹ xuống database để chắc hai chỗ đó còn thở. Nếu một trong hai chết, đường này không trả về "ổn" một cách lịch sự — nó trả mã 503, mã chuẩn nghĩa là "tôi chưa sẵn sàng, đừng đẩy khách vào."

Tinh tế ở chỗ: mỗi phép kiểm tra được bọc riêng. Redis hỏng thì nó báo đúng "redis lỗi", không kéo sập luôn cả đường kiểm tra để tôi mù tịt không biết hỏng chỗ nào. Một thứ chết không được phép làm câm cái loa báo bệnh.

Cái mã 503 đó không phải để con người tôi đọc. Nó để máy đọc — cái cân tải phía trước thấy 503 thì ngừng đẩy khách vào server đang ốm, chờ nó khoẻ lại mới đẩy tiếp. Con bot tự loại mình khỏi ca trực khi thấy mình không đủ sức. Đó là thứ một đội vận hành sẽ làm bằng tay, tôi để bot tự làm.

Giác quan thứ hai: những con số nói lên "đêm qua có gì lạ không"

Sống được là một chuyện. Sống tốt là chuyện khác.

Tôi cắm thêm một đường /metrics — chỗ con bot tự khai vài con số về một ngày làm việc của nó:

• Đã xử lý bao nhiêu tin.
• Bao nhiêu lần phải trả lời cầm chừng (fallback) vì không tự tin.
• Bao nhiêu lần phải chuyển cho người thật (escalation).
• Bao nhiêu lần chốt được lịch hẹn.
• Bao nhiêu lần Facebook từ chối tin gửi đi.
• Và độ trễ trả lời ở mức p95 — tức là 95% câu trả lời nhanh hơn ngưỡng này; con số phản ánh trải nghiệm của người xui nhất, chứ không phải mức trung bình đẹp đẽ.

Một con số đơn lẻ thì vô nghĩa. Nhưng nhìn theo thời gian, chúng kể chuyện. Lỗi gửi tin của Facebook nhảy vọt? Có thể token sắp hết hạn. Tỉ lệ chuyển-cho-người tăng đột ngột? Có thể bảng giá vừa đổi mà tôi quên cập nhật cho bot. Những con số này biến câu hỏi "bot có ổn không" từ một cảm giác mơ hồ thành một thứ nhìn được.

Giác quan thứ ba: lần theo đúng một cuộc trò chuyện

Khi một khách than "bot trả lời sai", việc khó nhất không phải sửa — mà là tìm lại đúng cuộc đó giữa hàng trăm cuộc.

Nên mỗi lần có tin đến, tôi gắn cho nó một mã định danh ngắn đi kèm vào mọi dòng nhật ký mà nó tạo ra — xuyên qua từng bước xử lý. Giờ muốn dựng lại một cuộc trò chuyện hỏng, tôi chỉ cần lọc theo cái mã đó là thấy nguyên hành trình của nó. Hết cảnh mò kim đáy bể.

Giác quan thứ tư: bot đỡ tốn tiền của tôi tới đâu

Cái này thiên về ví tiền. Mỗi câu trả lời của bot là một lần gọi tới Claude, và mỗi lần gọi đều tốn token — tức là tiền.

Có một mẹo gọi là prompt cache: phần dữ liệu lớn lặp lại (như bộ kiến thức, giọng thương hiệu của spa) được giữ lại để lần sau khỏi gửi và tính tiền lại từ đầu. Vấn đề là: nó thật sự đang tiết kiệm, hay tôi chỉ tưởng?

Nên tôi đo luôn. Mỗi câu trả lời về, bot tự xem nó đọc lại được cache (hit — tiết kiệm) hay phải tạo cache mới (miss — tốn). Đếm theo từng khách. Giờ "tiết kiệm token" không còn là niềm tin, mà là một con số tôi soi được.

"Chạy được" và "vận hành được" là hai con thú

Đây là điều tôi muốn để lại.

Phần lớn nội dung dạy code AI dừng ở chỗ "đây, bot trả lời được rồi nè". Đó mới là vạch xuất phát. Khoảng cách từ một con bot trả lời được tới một dịch vụ người ta dám trả tiền hằng tháng nằm hết ở mấy thứ buồn tẻ này: nó có tự biết mình ốm không, tôi có lần lại được khi nó sai không, tôi có thấy được đêm qua có gì lạ không.

Ship một mình không có nghĩa là làm ít hơn cả một đội. Nó nghĩa là một người vẫn phải làm việc của cả đội — chỉ là chọn đúng phần tối thiểu để con bot tự gánh, để mình ngủ được.

Một con bot biết tự báo bệnh đáng giá hơn nhiều một con bot chạy nhanh mà câm.

👉 Muốn tự tay đi từ con bot đầu tiên tới chỗ hiểu vì sao "chạy được" mới chỉ là nửa chặng đường? Bắt đầu nhẹ với mini-course miễn phí: Bot AI đầu tiên của bạn — làm xong trong một buổi tối, và bạn sẽ có một sản phẩm thật để bắt đầu lo những chuyện "vận hành được".