RAG vs Fine-Tuning: Khi Nào Dùng Cái Nào? (Kèm Số Liệu Thực Tế)
Phần lớn lời khuyên về rag vs fine tuning đều bỏ qua đúng một thí nghiệm đã đo cả hai trên cùng một bài toán. Balaguer và cộng sự, trong arXiv:2401.08406 (được trích dẫn 162 lần), đã đưa một bộ hỏi đáp nông nghiệp qua cả hai hướng: fine-tuning mua được hơn 6 điểm độ chính xác, và RAG chồng thêm 5 điểm lên trên đó. Bảng 18 của họ cho thấy GPT-4 đạt 75% ở dạng thô, 81% sau fine-tuning, và 86% khi fine-tuning kèm truy xuất. Vậy tại sao chúng tôi vẫn khuyên hầu hết các team bắt đầu với RAG? Vì độ tươi của dữ liệu, trích dẫn nguồn, và bài toán chi phí dưới đây quyết định nhiều dự án hơn là cách biệt 1 điểm độ chính xác.
Những điểm chính
- RAG là lựa chọn mặc định khi kiến thức thay đổi thường xuyên hoặc câu trả lời phải kèm trích dẫn; fine-tuning thắng ở định dạng đầu ra nhất quán và độ trễ.
- Chi phí fine-tuning rơi vào giai đoạn đầu (huấn luyện); chi phí RAG rơi vào mỗi truy vấn (embedding cộng thêm token đầu vào).
- Bằng chứng công bố trên cùng bài toán: fine-tuning cộng 6 điểm độ chính xác, RAG cộng thêm 5 điểm nữa, và hệ lai đánh bại cả hai khi đứng riêng.
- Hãy chạy năm bước kiểm tra (độ tươi dữ liệu, mẫu đã gán nhãn, độ trễ, trích dẫn, kỹ năng của team) trước khi viết bất kỳ dòng code huấn luyện nào.
Khi Nào Nên Dùng RAG, Khi Nào Nên Fine-Tuning? (Phán Quyết Nhanh)
Chọn RAG nếu kiến thức của bạn thay đổi thường xuyên hoặc câu trả lời bắt buộc phải có trích dẫn. Chọn fine-tuning nếu bạn cần định dạng đầu ra nhất quán cùng độ trễ thấp, và bạn đang có sẵn hàng trăm mẫu đã gán nhãn. Khi hệ thống đã trưởng thành, dùng cả hai. RAG chỉnh phần ngữ cảnh mà mô hình đọc; fine-tuning chỉnh chính bản thân mô hình. Hầu hết các team cần cái đầu tiên, không phải cái thứ hai.
Một câu đáng nhớ: RAG thay đổi những gì mô hình đọc; fine-tuning thay đổi bản chất của mô hình. Hãy chọn dựa trên thứ mà bài toán của bạn thực sự cần.
| Hướng tiếp cận | Dùng khi | Bỏ qua khi | Chi phí ban đầu | Chi phí mỗi truy vấn | Ma sát cập nhật |
|---|---|---|---|---|---|
| Prompt engineering | Hành vi đã gần đúng, kiến thức mang tính tổng quát | Câu trả lời cần dữ liệu riêng hoặc mới | Vài giờ lặp đi lặp lại | Không có gì ngoài token | Sửa prompt, triển khai lại |
| RAG | Sự kiện thay đổi, trích dẫn quan trọng, dữ liệu phải giữ riêng | Yêu cầu độ trễ dưới 100ms | Thấp: dựng chỉ mục | Embedding cộng thêm token đầu vào | Đánh chỉ mục lại, không cần huấn luyện lại |
| Fine-tuning | Định dạng, giọng văn hoặc ngân sách độ trễ cố định; đã có mẫu gán nhãn | Kiến thức lệch đi hằng tuần | Trung bình-cao: chuẩn bị dữ liệu cộng huấn luyện | Thường là mức giá token cao hơn | Huấn luyện lại toàn bộ mỗi lần dữ liệu lệch |
| Hệ lai (cả hai) | Sản phẩm trưởng thành: kiểm soát định dạng cộng sự kiện mới | Giai đoạn prototype, ngân sách chưa rõ | Cả hai mục trên | Cả hai mục trên | Hai hệ thống phải bảo trì |
Bảng chú giải RAG của NVIDIA định nghĩa rất gọn về phía truy xuất nếu bạn muốn phiên bản sách giáo khoa. Nhưng định nghĩa không chọn kiến trúc giúp bạn. Bằng chứng mới làm việc đó, nên hãy bắt đầu từ đó.
Bằng Chứng Cho Thấy Điều Gì? Một Bài Toán, Cả Hai Hướng, Được Đo Đàng Hoàng
So sánh duy nhất trên cùng bài toán có đo lường và lọt vào top 5 Google cho truy vấn này là Balaguer và cộng sự 2024, một nghiên cứu của Microsoft Research được trích dẫn 162 lần. Nhóm đã chạy một bài toán hỏi đáp nông nghiệp qua pipeline RAG, một mô hình đã fine-tune, và bản lai của cả hai, rồi để GPT-4 chấm điểm các câu trả lời. Trên thiết lập của họ, chỉ riêng fine-tuning đã nhỉnh hơn riêng RAG, và khi chồng hai thứ lên nhau, kết quả tốt hơn từng hướng một với cách biệt rộng hơn.
Case study nông nghiệp (arXiv:2401.08406)
Nghiên cứu, nộp tháng 1 năm 2024 bởi Angels Balaguer và 15 đồng tác giả, đặt câu hỏi cần những gì để cung cấp cho nông dân thông tin chi tiết theo từng vùng. Pipeline của họ trích xuất thông tin từ các tệp PDF, tạo cặp hỏi đáp từ đó, rồi đánh giá Llama2-13B, GPT-3.5 và GPT-4 với và không có truy xuất.
Balaguer và cộng sự báo cáo mức tăng độ chính xác hơn 6 điểm phần trăm từ fine-tuning, cộng dồn với RAG, và RAG bổ sung thêm 5 điểm nữa. Pipeline lai đánh bại từng hướng đứng riêng. Bảng 18 của họ cho thấy thứ tự với GPT-4: 75% khi không có trợ giúp, 80% với RAG, 81% sau fine-tuning, và 86% với fine-tuning cộng RAG. Hãy để ý 80% và 81% sát nhau đến mức nào; khoảng cách giữa RAG đơn thuần và fine-tuning đơn thuần chỉ là một điểm, trong khi bản lai bỏ xa cả hai tới năm điểm. Trong một thí nghiệm, mô hình đã fine-tune còn mượn kiến thức từ các vùng địa lý khác để trả lời câu hỏi đặc thù của vùng, nâng độ tương đồng câu trả lời từ 47% lên 72%.
Bằng chứng về mặt kinh tế
Nghiên cứu công bố của Snorkel AI (tháng 11 năm 2022) bao quát phía chi phí. Trên một benchmark phân loại pháp lý 100 lớp (LEDGAR, 80.000 điều khoản hợp đồng), mô hình RoBERTa đã fine-tune sánh ngang GPT-3 đã fine-tune trong khi nhỏ hơn 1.400 lần, dùng chưa tới 1% số nhãn ground-truth, và chạy với 0,1% chi phí suy luận production của mô hình GPT-3 đã fine-tune, tức khoảng một phần nghìn. Tổng chi phí xây dựng: 1.915 USD với gán nhãn theo chương trình so với 7.418 USD cho gán nhãn thủ công cộng fine-tuning GPT-3. Một lưu ý: đó là bài toán phân loại, không phải hỏi đáp sinh ngữ, nên hãy xem các tỷ lệ này theo hướng tham khảo.
Cách chúng tôi đọc kết quả
Cách hiểu của chúng tôi: thiết lập của họ là trường hợp thân thiện nhất mà fine-tuning từng có, vậy mà nó cũng chỉ thắng đúng một điểm. Balaguer và cộng sự huấn luyện trên một kho PDF cố định và đánh giá trên chính kho dữ liệu đóng băng đó, nên những gì trọng số học được không có cơ hội bị lỗi thời giữa chừng. Hầu hết các kho kiến thức production không đứng yên như vậy. Một bot hỗ trợ trả lời câu hỏi về bản phát hành tuần trước phải kiếm lại 6 điểm đó sau mỗi chu kỳ huấn luyện lại, trong khi chỉ mục nuôi RAG được cập nhật ngay trong buổi chiều hôm đó. Đó là lý do chúng tôi xem lợi thế 1 điểm độ chính xác là đầu vào yếu nhất của quyết định này, và độ tươi là đầu vào mạnh nhất. Chỗ mà bằng chứng không khái quát hóa được: kết quả của Snorkel là một benchmark phân loại, và không nghiên cứu nào kiểm thử khả năng kiểm soát giọng văn hay định dạng, vốn vẫn là thế mạnh lớn nhất của fine-tuning.
| RAG | Fine-tuning | Hệ lai | |
|---|---|---|---|
| Độ chính xác bài toán (Balaguer và cộng sự, ghi rõ nguồn) | +5 điểm phần trăm, cộng dồn trên fine-tuning (không phải mức độc lập so với baseline) | +6 điểm phần trăm so với baseline | Tốt nhất trong ba: GPT-4 đạt 86%, so với 81% của fine-tuning, 80% của RAG, 75% gốc |
| Cấu trúc chi phí (Snorkel cộng giá công khai) | Mỗi truy vấn: embedding cộng token ngữ cảnh | Trả trước: 1.915-7.418 USD trong case công bố; suy luận bằng 0,1% chi phí GPT-3 đã fine-tune với mô hình nhỏ | Trả cả hai |
| Ma sát cập nhật | Đánh chỉ mục lại tài liệu | Huấn luyện lại toàn bộ | Cả hai |
| Hỗ trợ trích dẫn | Có sẵn | Không | Có sẵn qua phía truy xuất |
Fine-tuning là đáp án đúng ít thường xuyên hơn các team tưởng; phần lớn dự án nói "fine-tune đi" thực ra ý là "truy xuất đi".
RAG Hoạt Động Thế Nào, Và Khi Nào Nó Thắng?
RAG (retrieval-augmented generation, sinh ngữ có tăng cường truy xuất) trả lời từ những tài liệu bạn kiểm soát thay vì từ những gì mô hình đã ghi nhớ trong lúc huấn luyện. Được Lewis và cộng sự đề xuất năm 2020, nó trở thành mặc định cho công việc tri thức vì kiến thức nằm ngoài mô hình: cập nhật chỉ mục, và mọi câu trả lời thay đổi vào ngày mai mà không cần huấn luyện lại.
Pipeline gồm bốn bước:
- Nạp. Phân tích tài liệu của bạn (PDF, wiki, ticket) thành một kho ngữ liệu.
- Cắt và embed. Chia thành các đoạn vài trăm token và chuyển mỗi đoạn thành một vector bằng mô hình embedding.
- Truy xuất. Tại thời điểm truy vấn, tìm top-K đoạn giống nhất, cộng thêm khớp từ khóa cho các chuỗi chính xác như mã SKU và mã lỗi.
- Tăng cường và sinh. Nhét các đoạn đó vào prompt và để LLM trả lời kèm nguồn đính kèm.
RAG thắng trên ba trục: độ tươi (đánh chỉ mục lại thay vì huấn luyện lại), trích dẫn (mọi câu trả lời trỏ về đoạn mà nó xuất phát), và kiểm soát dữ liệu (dữ liệu khách hàng không bao giờ đi vào một lần chạy huấn luyện). Nếu bạn muốn toàn bộ quy trình xây dựng, đây là cách xây dựng ứng dụng RAG từng bước.
Một cảnh báo về chất lượng truy xuất: pipeline chỉ tốt bằng đúng phần kết hợp giữa embedding và truy xuất. Contextual Retrieval của Anthropic đo được tỷ lệ truy xuất hỏng top-20 là 5,7% trên các thiết lập đơn giản, giảm còn 2,9% với contextual embedding cộng BM25, và còn 1,9% khi thêm reranker. Nếu các truy vấn khớp chính xác cứ hỏng mãi, tìm kiếm hybrid (BM25 vs vector) là giải pháp.
Khi Nào Fine-Tuning Thắng? (Và PEFT Là Gì?)
Fine-tuning thắng khi vấn đề nằm ở cách mô hình trả lời, không phải ở những gì nó biết: định dạng đầu ra nhất quán, giọng văn thương hiệu, hoặc một ngân sách độ trễ cứng không có chỗ cho một vòng truy xuất. Nó cũng là đòn bẩy cho bài toán kinh tế của mô hình nhỏ. Kết quả chất lượng GPT-3 với 0,1% chi phí của Snorkel ở trên chỉ tồn tại vì ai đó đã fine-tune một mô hình nhỏ thay vì phục vụ một mô hình lớn.
Fine-tuning toàn phần vs PEFT (LoRA / QLoRA)
Fine-tuning toàn phần cập nhật mọi trọng số trong mô hình. Nó đắt, chậm, và hiếm gặp ngoài các phòng lab lớn. Gần như tất cả mọi người đều triển khai PEFT (parameter-efficient fine-tuning, fine-tuning tiết kiệm tham số). LoRA (Hu và cộng sự 2021) đóng băng trọng số gốc và huấn luyện một adapter hạng thấp nhỏ, thường bằng 0,1-1% số lượng tham số. QLoRA bồi thêm lượng tử hóa 4-bit lên trên, nhờ đó một mô hình 13B vừa trên một GPU tiêu dùng. Một thuật ngữ liên quan đáng biết: tiền huấn luyện liên tục (continuous pretraining), khi mô hình tiếp tục tiền huấn luyện trên một kho ngữ liệu thô của lĩnh vực (không giám sát) trước khi fine-tuning có giám sát trên các mẫu đã gán nhãn.
Một cấu hình LoRA tối giản, theo tài liệu PEFT của Hugging Face:
from peft import LoraConfig, get_peft_model
config = LoraConfig(
r=16, # low-rank dimension; 8-64 typical
lora_alpha=32, # scaling factor, commonly 2x r
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
)
model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19Về chuẩn bị dataset, số epoch và đánh giá, xem hướng dẫn fine-tuning từng bước của chúng tôi.
Rủi ro là có thật: overfitting trên dataset nhỏ (vài trăm mẫu có thể khiến mô hình học vẹt thay vì học thật), sự lỗi thời (trọng số đóng băng kiến thức của bạn tại thời điểm cắt huấn luyện), và không có quy kết nguồn (mô hình đã fine-tune không thể đưa ra hóa đơn chứng minh). Nếu bất kỳ điều nào trong ba thứ đó là điểm chết, bạn vừa tự thuyết phục mình quay lại RAG.
RAG vs Fine-Tuning vs Prompt Engineering: Những Hướng Khác Nằm Ở Đâu?
Ba thứ này là một cái thang, không phải đối thủ. Prompt engineering thay đổi chỉ thị, RAG thay đổi ngữ cảnh mà mô hình đọc, và fine-tuning thay đổi trọng số. Hướng dẫn fine-tuning của chính OpenAI đặt fine-tuning ở cuối vòng lặp: eval trước, prompt thứ hai, và chỉ huấn luyện khi prompt không còn đủ. Hai lựa chọn mới hơn hoàn thiện bộ công cụ.
| Hướng tiếp cận | Thứ thay đổi | Dùng khi | Bỏ qua khi | Cấu trúc chi phí | Công sức |
|---|---|---|---|---|---|
| Prompt engineering | Chỉ thị | Hành vi đã đúng 90% | Cần sự kiện riêng hoặc thay đổi nhanh | Chỉ token | Vài giờ |
| RAG | Ngữ cảnh đọc tại thời điểm truy vấn | Kiến thức mới hoặc cần trích dẫn | Độ trễ ngặt; không có gì để truy xuất | Token mỗi truy vấn cộng chỉ mục | Vài ngày |
| Fine-tuning (LoRA) | Trọng số | Định dạng, giọng văn, độ trễ, phục vụ mô hình nhỏ | Không có dữ liệu gán nhãn; kiến thức lệch dần | Huấn luyện trả trước; làm mới mỗi lần huấn luyện lại | Vài tuần |
| CAG (cache-augmented) | Ngữ cảnh được tải trước và lưu cache | Kho kiến thức nhỏ, ổn định; có sẵn prompt caching | Kho ngữ liệu vượt quá kích thước cache được | Ghi cache một lần, sau đó đọc rẻ | Vài ngày |
| Agent cộng sử dụng công cụ | Những gì mô hình làm được | Câu trả lời cần hành động hoặc tính toán trực tiếp | Một câu trả lời tĩnh là đủ | Token mỗi bước; nhân lên rất nhanh | Vài tuần |
Một nhầm lẫn đáng gọi tên: MCP server và các framework agent là lớp điều phối, không phải lớp tùy biến. Chúng quyết định công cụ và nguồn dữ liệu nào mô hình chạm tới được; chúng không thay đổi cách mô hình trả lời. Bạn có thể chạy một pipeline RAG bên trong một agent và fine-tune mô hình nằm bên dưới nó, và nhiều hệ thống production làm cả hai. Những cuộc chiến so sánh ("vs mcp", "vs agents") là sai phạm trù.
RAG Có Rẻ Hơn Fine-Tuning Không? Mô Hình Chi Phí Thực
Trả lời ngắn: ở mức lưu lượng truy vấn thực tế, có. Hóa đơn của fine-tuning đến ngay từ đầu (dữ liệu gán nhãn cộng huấn luyện), trong khi hóa đơn của RAG đến theo từng truy vấn (embedding cộng thêm token đầu vào). Tài liệu fine-tuning của OpenAI tính phí huấn luyện theo token, nhưng phí token chỉ là tiền lẻ so với chi phí con người cho các mẫu gán nhãn. Đây là bài toán theo bảng giá công khai.
| Hạng mục | Khi nào trả | Giá niêm yết công khai |
|---|---|---|
| Huấn luyện qua API hosted (gpt-4o-mini) | Một lần mỗi phiên bản mô hình | 3,00 USD cho 1M token huấn luyện (OpenAI, bảng giá 2024-25) → 1,5M token ≈ 4,50 USD |
| Dữ liệu huấn luyện đã gán nhãn | Trả trước, làm mới khi dữ liệu lệch | 1.915 USD theo chương trình so với 7.418 USD thủ công (case công bố của Snorkel) |
| Suy luận mô hình đã fine-tune | Mỗi truy vấn | Khoảng gấp đôi giá gốc: 0,30/1,20 USD so với 0,15/0,60 USD cho mỗi 1M (gpt-4o-mini, OpenAI 2024-25) |
| Embedding kho ngữ liệu (RAG) | Một lần mỗi lần cập nhật kho | 0,02 USD cho 1M token (text-embedding-3-small) → kho 10M token = 0,20 USD |
| Ngữ cảnh truy xuất (RAG) | Mỗi truy vấn | ~2.000 token đầu vào thêm × 0,15 USD/1M = 0,0003 USD mỗi truy vấn |
Câu hỏi hòa vốn: cần bao nhiêu truy vấn để khoản thuế mỗi truy vấn tích lũy của RAG bằng với khoản đầu tư fine-tuning?
break_even = training_cost / per_query_retrieval_delta
= $1,915 / $0.0003
≈ 6.4 million queriesVới 50.000 truy vấn một tháng, con số đó là hơn mười năm. Với hầu hết sản phẩm, khoản đầu tư fine-tuning không bao giờ hoàn vốn chỉ nhờ tiết kiệm token; bạn fine-tune vì định dạng và độ trễ, không phải để thắng RAG về chi phí. Bài toán lật ngược khi vượt mốc hàng triệu truy vấn mỗi tháng hoặc với ngữ cảnh truy xuất rất lớn. Và hãy để ý sự bất đối xứng: hóa đơn fine-tuning làm mới mỗi lần dữ liệu lệch buộc phải huấn luyện lại, trong khi RAG tăng tuyến tính theo lưu lượng nhân với kích thước đoạn. Nếu chi phí mỗi truy vấn mới là mối lo thật, hãy bắt đầu với việc cắt giảm chi phí API LLM mỗi truy vấn trước; còn nếu bạn vẫn đi đường huấn luyện, hãy so sánh công cụ fine-tuning LLM trước khi ký séc.
Một ghi chú về độ tươi: tính đến tháng 7 năm 2026, tài liệu fine-tuning của OpenAI cho biết nền tảng hosted đang bị thu hẹp cho người dùng mới, còn người dùng hiện tại giữ quyền truy cập huấn luyện trong vài tháng tới. Đó là thêm một lý do các team nghiêng về PEFT trên mô hình mở hoặc RAG đơn thuần.
5 Bước Kiểm Tra Trước Khi Bạn Chọn
Hãy chạy năm câu kiểm tra có-không này trước khi viết bất kỳ dòng code huấn luyện nào; mẫu câu trả lời chỉ ra RAG, fine-tuning hay hệ lai đáng tin hơn bất kỳ benchmark nào. Trả lời trung thực, rồi đếm.
- Kiến thức có thay đổi nhanh hơn tốc độ bạn có thể huấn luyện lại không? Có → RAG. Huấn luyện lại sau mỗi lần cập nhật tài liệu không phải một kế hoạch vận hành.
- Bạn có vài trăm mẫu đã gán nhãn không? Không → RAG hoặc prompt engineering. Fine-tuning trên 40 mẫu chỉ là học vẹt; nó không học thật.
- Có ngân sách độ trễ cứng không? Ngặt → nghiêng về fine-tuning. Bỏ qua vòng truy xuất tiết kiệm được 50-200ms.
- Câu trả lời có bắt buộc kèm trích dẫn hoặc vết kiểm toán không? Có → RAG. Mô hình đã fine-tune không thể trỏ vào đoạn nguồn.
- Team có kỹ năng ML cộng ngân sách GPU hoặc API cho huấn luyện không? Không → RAG. Một chỉ mục bạn dựng lại được tốt hơn một bộ trọng số bạn không thể huấn luyện lại.
Phần lớn câu 1, 4, 5 là có → RAG. Phần lớn câu 2 và 3 là có với một lĩnh vực ổn định → fine-tuning. Câu trả lời chia đôi, hoặc một sản phẩm trưởng thành có lưu lượng thật → hệ lai (phần tiếp theo). Mục đích của bảng kiểm là quyết định bằng bằng chứng, không phải bằng kỹ thuật nào đang thịnh hành trên bảng tin của bạn tháng này.
Dùng RAG Và Fine-Tuning Cùng Nhau Được Không?
Được, và với các hệ thống đã trưởng thành, mẫu hệ lai là chuẩn mực, không phải ngoại lệ. Fine-tune cho sự trôi chảy trong lĩnh vực và định dạng đầu ra (phần cách), truy xuất cho sự kiện tại thời điểm suy luận (phần cái gì). Balaguer và cộng sự báo cáo chính xác điều này trên bài toán nông nghiệp của họ: pipeline lai đánh bại từng hướng đứng riêng, với mức tăng 5 điểm của RAG chồng lên 6 điểm của fine-tuning.
Lộ trình trưởng thành mà chúng tôi khuyến nghị: bắt đầu với prompt engineering, thêm RAG ngay khi câu trả lời cần dữ liệu riêng hoặc dữ liệu mới, và chỉ thêm fine-tuning khi sự thiếu nhất quán định dạng hoặc độ trễ bắt đầu gây đau trong production. Nhảy thẳng sang fine-tuning và bạn trả khoản thuế huấn luyện trước cả khi biết liệu truy xuất đã giải quyết xong vấn đề chưa.
Mẫu hệ lai không phải một thỏa hiệp; với các hệ thống đã trưởng thành nó là mặc định, fine-tune cho định dạng, truy xuất cho sự kiện.
Đánh Giá Phương Án Thắng Cuộc Thế Nào?
Chọn phương án thắng theo cách bạn chọn một cơ sở dữ liệu: đo trên chính tải công việc của bạn, không phải theo cảm giác. Công thức gói gọn trong một đoạn văn và bao quát bốn con số thực sự quyết định.
- Bộ câu hỏi giữ riêng. 100-300 câu hỏi thật của người dùng. Không phải câu tổng hợp, và tuyệt đối không dùng bất cứ thứ gì đã thấy trong lúc huấn luyện hay đánh chỉ mục.
- Độ trung thực và độ đúng của câu trả lời. Độ trung thực hỏi liệu câu trả lời có bám vào ngữ cảnh được truy xuất không; độ đúng hỏi liệu nó có thực sự đúng không. Cặp chỉ số này, được RAGAS phổ biến, bắt được cả ảo giác lẫn lỗi truy xuất hụt.
- Độ trễ ở p95, không phải mức trung bình. Truy xuất thêm một vòng; hãy đo phần đuôi.
- Chi phí cho mỗi 1.000 truy vấn, token cộng hạ tầng, đo thật chứ không đoán.
- Chạy lại khi dữ liệu lệch. Tài liệu mới, bản snapshot mô hình mới, quý mới: chạy lại bộ câu hỏi.
Toàn bộ phân tích chỉ số, kèm công cụ, nằm trong hướng dẫn đánh giá LLM của chúng tôi.
Về Tác Giả
Mert Batur là Đồng sáng lập của Techsy.io, nơi team xây dựng AI agent, hệ thống tự động hóa và pipeline giọng nói/SDR cho khách hàng B2B. Anh viết về chồng công cụ LLM mà team Techsy thực sự dùng trong production. Kết nối trên LinkedIn.
Câu Hỏi Thường Gặp
Dùng RAG và fine-tuning cùng nhau được không?
Được. Fine-tune cho định dạng đầu ra và sự trôi chảy trong lĩnh vực, còn giữ truy xuất cho sự kiện tại thời điểm suy luận. Balaguer và cộng sự đã đo bản lai này trên một bài toán hỏi đáp nông nghiệp và thấy nó đánh bại từng hướng đứng riêng, với các mức tăng độ chính xác cộng dồn. Hầu hết hệ thống production trưởng thành đều kết thúc ở đây: trọng số lo phần cách, truy xuất lo phần cái gì.
Khi nào không nên dùng fine-tuning?
Bỏ qua fine-tuning khi kiến thức của bạn thay đổi nhanh hơn tốc độ huấn luyện lại, khi bạn có ít hơn vài trăm mẫu đã gán nhãn, khi câu trả lời bắt buộc kèm trích dẫn hoặc vết kiểm toán, hoặc khi không có ngân sách để huấn luyện lại lúc dữ liệu lệch. Bốn điều kiện đó mô tả hầu hết sản phẩm giai đoạn đầu, và đó là lý do RAG thường là nước đi đầu tiên đúng.
Fine-tuning đã bị bác bỏ chưa?
Chưa, nhưng lãnh địa của nó đã thu hẹp. Cửa sổ ngữ cảnh dài và RAG giá rẻ đã hấp thụ những use case từng đòi hỏi fine-tuning vào năm 2023. Những gì còn lại là thật: định dạng đầu ra nghiêm ngặt, giọng văn thương hiệu, ngân sách độ trễ không có chỗ cho vòng truy xuất, và bài toán kinh tế của mô hình nhỏ. Nếu vấn đề của bạn là cách mô hình trả lời chứ không phải những gì nó biết, fine-tuning vẫn là công cụ.
Khi nào bạn dùng RAG, khi nào dùng fine-tuning?
Dùng RAG khi câu trả lời phụ thuộc vào kiến thức riêng hoặc được cập nhật thường xuyên, hoặc khi bạn cần trích dẫn. Dùng fine-tuning khi bạn cần định dạng, giọng văn hoặc độ trễ nhất quán và bạn có đủ mẫu đã gán nhãn. Dùng cả hai khi sản phẩm đã trưởng thành. Nếu chưa chắc, bắt đầu với RAG: nó rẻ để rút lui hơn một lần chạy huấn luyện.
RAG có rẻ hơn fine-tuning không?
Về chi phí trả trước, có. Chi phí của RAG tính theo mỗi truy vấn (embedding cộng thêm token đầu vào), trong khi fine-tuning tính một lần cho huấn luyện và dữ liệu gán nhãn, rồi làm mới sau mỗi lần huấn luyện lại. Theo bảng giá công khai, điểm hòa vốn rơi vào khoảng 6,4 triệu truy vấn trong ví dụ tính toán của chúng tôi, nên ở mức lưu lượng điển hình, RAG rẻ hơn trong suốt vòng đời sản phẩm.
RAG có tốt hơn fine-tuning trong việc chống ảo giác không?
Thường là có, nhưng không miễn phí. RAG neo câu trả lời vào các đoạn được truy xuất, nên bạn có thể trích dẫn nguồn và kiểm toán chỗ hỏng. Tuy nhiên, truy xuất tệ sẽ đầu độc câu trả lời: Anthropic đo được tỷ lệ truy xuất hỏng top-20 là 5,7% trên thiết lập đơn giản, giảm còn 1,9% với contextual retrieval cộng reranking. Trong khi đó, fine-tuning có thể nướng lỗi vào trọng số mà không có cách nào truy vết.
RAG vs fine-tuning vs prompt engineering: khác nhau ở đâu?
Prompt engineering thay đổi chỉ thị bạn gửi đi. RAG thay đổi ngữ cảnh mà mô hình đọc tại thời điểm truy vấn. Fine-tuning thay đổi trọng số của mô hình. Mỗi thứ là một can thiệp lớn hơn thứ trước: thử prompt trước, thêm truy xuất khi kiến thức là nút thắt, và chỉ huấn luyện khi định dạng, giọng văn hoặc độ trễ vẫn còn đau.
Đánh giá hiệu năng RAG vs fine-tuning thế nào?
Dựng một bộ giữ riêng gồm 100-300 câu hỏi thật của người dùng và chấm cả hai hướng trên đó: độ trung thực (có bám ngữ cảnh không?), độ đúng (có đúng không?), độ trễ p95, và chi phí cho mỗi 1.000 truy vấn. Chạy lại bộ này bất cứ khi nào tài liệu hoặc bản snapshot mô hình thay đổi. Câu hỏi tổng hợp làm đẹp lòng cả hai hệ thống; câu hỏi thật mới phân tách được chúng.
Fine-tuning vs RAG cho câu hỏi đa bước trên kiến thức mới?
RAG, với phần truy xuất tốt hơn. Cơ chế quyết định câu này: mô hình đã fine-tune chỉ suy luận được trên những gì trọng số của nó đã hấp thụ, nên kiến thức nó chưa từng thấy là không thể chạm tới dù nó được huấn luyện tốt đến đâu. Truy xuất đưa cho nó các mảnh còn thiếu tại thời điểm truy vấn. Cái bẫy là một vòng truy xuất hiếm khi gom đủ mọi bước, nên hãy tính đến phân rã truy vấn hoặc truy xuất lặp cộng reranker, chứ không phải một lần tra top-K duy nhất.
Kết Luận
Phần tóm tắt, bỏ hết các câu rào đón:
- RAG là mặc định cho kiến thức thay đổi và câu trả lời có trích dẫn. Fine-tuning là chuyên gia cho định dạng, giọng văn và độ trễ.
- Bằng chứng trên cùng bài toán (Balaguer và cộng sự) cho fine-tuning +6 điểm phần trăm và RAG thêm +5 điểm phần trăm nữa, với bản lai tốt nhất trong ba. Lời khuyên bắt đầu với RAG của chúng tôi dựa trên độ tươi, trích dẫn và chi phí, không dựa trên bảng điểm đó.
- Bài toán chi phí nghiêng về RAG ở mức lưu lượng thực tế: điểm hòa vốn nằm quanh 6,4 triệu truy vấn trong ví dụ tính toán của chúng tôi.
- Quyết định bằng năm bước kiểm tra, không phải bằng thói quen.
Đã chọn RAG? Xem bảng xếp hạng công cụ RAG của chúng tôi cho chồng công cụ xoay quanh pipeline.