Hola, I’m Hieu, a Software Engineer

Bản demo lúc nào cũng chạy ngon. Bạn dán một input đẹp vào, model trả về thứ gì đó ấn tượng, bạn đem khoe ở standup, cả nhóm đồng ý là phải ship. Hai tuần sau nó nằm trên production và bạn đang đọc một ticket hỗ trợ trong đó model nói với khách rằng yêu cầu hoàn tiền của họ đã được duyệt. Bản demo là 20% dễ. 80% còn lại là tất cả những thứ ngăn một hàm xác suất kéo sập ứng dụng của bạn — không phải vì model tệ, mà vì bạn vừa cắm một thành phần không tất định vào một hệ thống được thiết kế trên giả định rằng hàm trả về đúng cái mà chữ ký của nó khai báo. Dưới đây là thứ tự tôi thật sự làm. Thứ tự quan trọng hơn từng kỹ thuật riêng lẻ, vì mỗi bước cho bạn biết bước kế tiếp có đáng làm hay không. Bỏ qua bộ eval thì bạn sẽ mất ba ngày tinh chỉnh prompt mà không có cách nào biết mình có cải thiện được gì không. Bỏ qua guardrail thì bạn sẽ biết về lỗi format output của mình qua lời người dùng. Không có gì ở đây gắn với một nhà cung cấp hay một framework cụ thể. Đây vẫn là kỷ luật bạn áp c...

The demo always works. You paste a good input, the model returns something impressive, you show it in standup, and everyone agrees it should ship. Two weeks later it is in production and you are reading a support ticket where the model told a customer their refund was approved. The demo is the easy 20%. The other 80% is everything that stops a probabilistic function from taking your application down with it — not because the model is bad, but because you wired a non-deterministic component into a system that was designed on the assumption that functions return what their signature says. What follows is the order I actually build these things in. The order matters more than any individual technique, because each step tells you whether the next one is even worth doing. If you skip the eval set you will spend three days tuning a prompt and have no way to know if you improved it. If you skip the guardrails you will find out about your output-format bug from a user. None of this is speci...