Một product manager bước tới sau buổi demo và hỏi câu rất quen: mình có nên fine-tune model không? Assistant trả lời sai tone, bỏ sót một chi tiết policy, và bịa ra một field không tồn tại trong CRM. Quanh bàn, mọi người bắt đầu gọi tên giải pháp trước khi gọi đúng vấn đề. Một người nói prompt. Một người nói RAG. Một người nói fine-tuning. Model, rất im lặng, đang bị đổ lỗi cho ba loại lỗi khác nhau cùng lúc.
Prompting, RAG và fine-tuning thường được nói như ba lựa chọn cạnh tranh trên cùng một kệ. Chúng liên quan với nhau, nhưng thay đổi những phần khác nhau. Prompting thay đổi instruction và context bạn đưa cho model khi request chạy. RAG thay đổi thông tin model có thể nhìn trước khi trả lời. Fine-tuning thay đổi behavior của model bằng cách train thêm trên các example. Chọn đúng bắt đầu bằng câu hỏi thật sự đang thiếu gì: instruction rõ hơn, knowledge mới hơn, hay một behavior lặp lại mà base model chưa làm ổn định.
Prompting thường là đòn bẩy đầu tiên vì nhanh và dễ đảo ngược. Một prompt tốt hơn có thể định nghĩa task, audience, tone, format, boundary, example và refusal behavior. Nếu assistant viết quá casual, hãy yêu cầu tone bình tĩnh hơn và đưa hai example. Nếu output JSON không ổn định, hãy định nghĩa schema và đưa valid output. Nếu nó trả lời ngoài policy, hãy bảo nó chỉ dùng context được cung cấp và nói rõ khi evidence không đủ. Prompting không phải bước chơi thử. Nó thường là cách rẻ nhất để khám phá sản phẩm thật sự cần gì.
Giới hạn của prompting là nó không tạo ra knowledge đáng tin từ hư không. Prompt có thể nhắc model tuân theo refund policy, nhưng nó không thể biết refund policy mới nhất nếu bạn không cung cấp. Prompt có thể yêu cầu field name trong database, nhưng nếu schema đổi hằng tuần, danh sách field cần đến từ một nguồn hiện tại. Khi vấn đề là knowledge thay đổi, tài liệu nội bộ, product rule, support history hoặc citation, RAG thường là công cụ trung thực hơn.
RAG, hay Retrieval-Augmented Generation, nghĩa là hệ thống tìm trong nguồn đáng tin trước, rồi đưa các phần liên quan cho model trước khi trả lời. Nó hữu ích khi câu trả lời cần bám vào tài liệu team sở hữu: docs, ticket, knowledge base article, runbook, release note hoặc code snippet. Model vẫn viết response, nhưng evidence đến từ retrieval. Vì vậy RAG đi rất tự nhiên với citation, freshness check và source visibility.
RAG thất bại theo cách khác với prompting. Nó có thể lấy nhầm chunk, bỏ lỡ document đúng, kéo nội dung đã cũ, hoặc mang về các source mâu thuẫn. Model cũng có thể bỏ qua một phần context đã lấy về. Cải thiện RAG thường nghĩa là cải thiện những phần pipeline âm thầm xung quanh nó: document ownership, chunking, metadata, permission, evaluation set và observability. Nếu knowledge base lộn xộn, RAG không làm nó khôn ngoan hơn. Nó thường chỉ làm sự lộn xộn dễ nhìn thấy hơn.
Fine-tuning bước vào cuộc nói chuyện khi team cần model học một pattern lặp lại từ example. Có thể sản phẩm cần một style classification rất cụ thể, một extraction format ổn định, một kiểu rewrite theo domain, hoặc một support response voice mà prompt thông thường không giữ được chắc ở scale. Fine-tuning có thể giảm độ dài prompt, tăng consistency trong narrow task, và làm behavior có cảm giác tự nhiên hơn với model.
Fine-tuning không phải câu trả lời đúng cho fact bị thiếu. Nếu bảng pricing đổi mỗi tháng, train nó vào model thường là đặt knowledge sai chỗ. Model sẽ cũ đi, và team lại cần một training cycle cho thứ lẽ ra chỉ là data update. Fine-tuning cũng cần example tốt, evaluation, versioning và rollback discipline. Dataset yếu có thể dạy model lặp lại lỗi cũ của team bằng một sự tự tin rất thuyết phục.
Một đường quyết định thực tế khá đơn giản. Nếu model chưa hiểu task, cải thiện prompt. Nếu model thiếu knowledge mới nhất hoặc nội bộ, dùng RAG. Nếu model liên tục làm sai style hoặc structure dù prompt và context đã tốt, hãy cân nhắc fine-tuning. Nhiều hệ thống tốt kết hợp cả ba: prompt rõ, evidence được lấy về, và tuned model cho một behavior hẹp. Vấn đề không phải sự thuần khiết. Vấn đề là dùng can thiệp nhỏ nhất làm sản phẩm đáng tin hơn.
Evaluation giữ lựa chọn không bị trôi theo cảm tính. Trước khi đổi hệ thống, hãy gom một bộ input thật và expected outcome. Đánh dấu failure nào là instruction failure, retrieval failure, hay behavior failure. Sau mỗi thay đổi, test lại cùng bộ đó. Thói quen này ngăn team fine-tune để giải quyết vấn đề documentation, hoặc build vector database để chữa một prompt mơ hồ.
Cũng cần nói về chi phí. Prompting tốn thời gian và token. RAG tốn indexing, permission, retrieval quality và knowledge maintenance. Fine-tuning tốn chuẩn bị dataset, training, monitoring và quản lý model lifecycle. Không cách nào miễn phí, kể cả khi API call nhìn đơn giản. Lựa chọn đúng là lựa chọn có operational cost tương xứng với value và risk của feature.
Phiên bản bình tĩnh của câu hỏi không phải prompting, RAG hay fine-tuning cái nào tốt nhất. Câu hỏi là bạn đang thấy loại failure nào. Model chưa rõ việc phải làm? Nó thiếu evidence? Hay nó không lặp lại được behavior mà sản phẩm cần? Khi failure có tên, giải pháp bớt thời thượng và trở nên hữu ích hơn. Nếu team bạn từng thử cả ba, câu chuyện đáng nhớ nhất thường không phải cách nào thắng, mà là khoảnh khắc cả team cuối cùng hiểu mình thật sự đang giải quyết vấn đề gì.