Hola, I’m Hieu, a Software Engineer

Cứ vài tuần lại có người chiếu đúng cái slide đó lên: ba cái hộp ghi Prompt Engineering , RAG và Fine-tuning , kèm mũi tên ngụ ý rằng bài toán càng nghiêm túc thì bạn càng “lên hạng” từ trái sang phải. Rồi cả phòng cãi nhau xem chọn cái nào, như thể đó là ba nhà thầu đang đấu cùng một gói việc. Chúng không tranh nhau cùng một gói việc. Chúng tác động vào ba phần khác nhau của hệ thống, và một khi bạn gọi tên được phần nào đang hỏng, cuộc tranh luận thường kết thúc trong khoảng một phút: Prompt đổi phần chỉ dẫn. Model đang được yêu cầu làm gì, dưới những ràng buộc nào. Retrieval đổi phần kiến thức. Những dữ kiện nào thật sự có mặt trong context window lúc model trả lời. Fine-tuning đổi phần hành vi. Model làm gì theo mặc định, dưới dạng nào, khi chỉ dẫn đã hết. Gần như mọi quyết định sai trong mảng này đều đến từ việc đem một tầng đi chữa vấn đề nằm ở tầng khác. Fine-tune một model để nó “biết” danh mục sản phẩm của bạn là ca kinh điển — bỏ ra sáu tuần để có một model tự tin ...

Every few weeks someone puts the same slide on the screen: three boxes labelled Prompt Engineering , RAG , and Fine-tuning , with arrows suggesting you graduate from left to right as your problem gets serious. Then the room argues about which one to pick, as if they were three vendors bidding for the same job. They are not competing for the same job. They act on three different parts of the system, and once you name which part, the argument usually ends in about a minute: Prompting changes the instructions. What the model is being asked to do, and under what constraints. Retrieval changes the knowledge. Which facts are physically present in the context window when the model answers. Fine-tuning changes the behaviour. What the model does by default, in what form, when the instructions run out. Almost every bad decision in this area comes from applying one layer to a problem that lives in another. Fine-tuning a model so it “knows” your product catalogue is the classic — you spe...