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...

Bug report lúc nào cũng cùng một dạng. “Trợ lý bịa ra thời hạn hoàn tiền của mình.” Ai đó mở trace, thấy một đoạn văn sai nhưng đầy tự tin, rồi quy lỗi cho model. Prompt được thêm một đoạn hướng dẫn nữa. Có khi temperature bị hạ xuống. Có khi ai đó đề xuất đổi model. Rồi bạn nhìn lên một tầng và thấy retriever đã đưa cho model ba chunk: chính sách vận chuyển, phần mở đầu của điều khoản dịch vụ, và một chunk đứt giữa câu ngay trước chỗ nêu thời hạn hoàn tiền. Model không hẳn là hallucinate — nó ứng biến trên một lỗ hổng. Không prompt nào sửa được chuyện đó. Đổi model cũng không: một model tốt hơn với đúng ba chunk ấy sẽ cho ra một đoạn sai thuyết phục hơn . Đây là dạng lỗi RAG phổ biến nhất, và bạn không thể nhìn ra nó từ output. Generation là phần duy nhất bạn đọc, nên generation là phần bạn đổ lỗi. Cách sửa là một phép đo tách đôi hai nửa, dựng trước khi bạn tinh chỉnh bất cứ thứ gì — nếu không, mọi thay đổi bạn làm đều là tung đồng xu mà không chấm điểm được. Dưới đây là phiên bản...

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...