Hola, I’m Hieu, a Software Engineer

Mọi tính năng LLM có đụng tới database đều bắt đầu giống nhau. Bạn nhờ model phân loại một ticket support, nó trả lời This looks like a billing issue, probably high priority. , và bạn viết một cái regex. Chạy được. Bạn ship. Hai tuần sau model đổi giọng thành I'd categorise this as billing-related , regex của bạn trả về None , nhánh if severity == "high" lặng lẽ false, và một ticket nghiêm trọng nằm im trong hàng đợi ưu tiên thấp ba ngày. Không có gì hỏng. Không exception nào được raise. Model cũng chẳng hallucinate. Nó chỉ diễn đạt một câu trả lời đúng theo cách khác, còn cái parser của bạn — vốn chưa bao giờ là parser, chỉ là một phỏng đoán về pattern — âm thầm không đồng ý. Cách sửa đầu tiên ai cũng nghĩ tới là xin gắt hơn: “chỉ trả về JSON, không markdown.” Cách đó có giúp, nhưng nó dời chỗ lỗi chứ không xóa lỗi. Cách sửa thật là ngừng coi response như văn bản cần diễn giải, và bắt đầu coi nó như một giá trị mà API bị ràng buộc phải sinh ra. Đó chính là thứ JSON S...

Every LLM feature that touches a database starts the same way. You ask the model to classify a support ticket, it answers This looks like a billing issue, probably high priority. , and you write a regex. It works. You ship it. Two weeks later the model says I'd categorise this as billing-related and your regex returns None , your if severity == "high" branch silently evaluates false, and a critical ticket sits in the low-priority queue for three days. Nothing broke. No exception was raised. The model did not hallucinate. It just phrased a correct answer differently, and your parser — which was never a parser, only a pattern guess — quietly disagreed. The fix people reach for first is to ask harder: “respond with JSON only, no markdown.” That helps, and it moves the failure rather than removing it. The real fix is to stop treating the response as text you interpret and start treating it as a value the API is constrained to produce. That is what JSON Schema and tool cal...