LLM 8 — Prompt vs RAG vs Fine-tuning: chọn cách nào

Đến bài cuối của series, bạn đã có đủ mảnh ghép: biết cách viết prompt (Prompt engineering), biết cách cho model đọc kiến thức riêng bằng RAG, biết cách đánh giá và đưa lên production. Nhưng khi bắt tay làm một sản phẩm thật, câu hỏi lớn nhất thường không phải "làm thế nào" mà là "chọn cách nào".

Model gốc như Claude đã rất mạnh, nhưng nó không biết tài liệu nội bộ công ty bạn, không tự động trả lời theo đúng định dạng JSON bạn cần, và đôi khi trả lời dài dòng hơn mong muốn. Có ba con đường để "chỉnh" model cho khớp với bài toán của bạn — và chọn sai con đường là cách nhanh nhất để đốt tiền, đốt thời gian mà kết quả vẫn không tốt hơn.

Bài này giúp bạn phân biệt rạch ròi ba con đường đó, hiểu chúng giải quyết vấn đề gì, và có một cây quyết định để chọn đúng ngay từ đầu.

Ba cấp tuỳ biến, theo thứ tự nên thử

Nguyên tắc vàng: bắt đầu từ cách rẻ nhất, nhanh nhất; chỉ leo thang khi cách trước không đủ. Ba cấp, theo đúng thứ tự nên thử:

1. Prompt engineering — rẻ, nhanh, sửa trong vài phút. Thay đổi cách bạn ra lệnh cho model. Đây là nơi giải quyết được đa số bài toán.
2. RAG — khi model cần kiến thức riêng hoặc thông tin mới mà nó không được huấn luyện. Bạn cấp thêm ngữ cảnh lúc truy vấn, không đụng đến model.
3. Fine-tuning — khi bạn cần thay đổi hành vi/phong cách/định dạng một cách ổn định, hoặc nén một prompt dài lặp đi lặp lại. Bạn dạy lại model bằng cách đổi trọng số.

Điều quan trọng nhất — và cũng là điều hay bị nhầm nhất — nằm ở phần tiếp theo.

Phân biệt cốt lõi: kiến thức hay hành vi?

Rất nhiều đội chọn sai vì lẫn lộn hai câu hỏi khác nhau. Đây là ranh giới quan trọng nhất của cả bài:

• RAG cấp kiến thức lúc truy vấn. Bạn tìm các đoạn tài liệu liên quan và nhét vào prompt trước khi hỏi model. Trọng số của model không đổi. Model vẫn là model gốc, chỉ là lần này nó "đọc bài" trước khi trả lời.
• Fine-tuning dạy hành vi/kỹ năng. Bạn cho model học từ nhiều ví dụ (input → output mong muốn) và thay đổi trọng số của nó. Nó học được cách làm, không phải dữ kiện cụ thể.

Hệ quả trực tiếp và rất dễ sai:

Fine-tuning KHÔNG phải là cách tốt để nhồi kiến thức hay thông tin thời sự vào model.

Nếu bạn fine-tune Claude trên toàn bộ tài liệu chính sách công ty với hy vọng "nó sẽ nhớ hết", bạn sẽ thất vọng: model có xu hướng nhớ phong cách của tài liệu hơn là dữ kiện chính xác, dễ bịa (hallucinate) khi được hỏi chi tiết, và mỗi lần chính sách thay đổi bạn phải train lại toàn bộ. Kiến thức thay đổi thường xuyên là bài toán của RAG, không phải fine-tuning.

Ngược lại, nếu bạn cần model luôn trả lời bằng đúng một cấu trúc JSON nghiêm ngặt, đúng một giọng văn thương hiệu, thì nhồi ngày càng nhiều chỉ dẫn vào prompt sẽ đến lúc kém hiệu quả — đó mới là lúc fine-tuning phát huy.

Nhớ một câu: RAG = model biết thêm điều gì; Fine-tuning = model biết làm thế nào.

Prompt engineering: điểm khởi đầu của mọi thứ

Trước khi nghĩ đến bất cứ điều gì phức tạp hơn, hãy vắt kiệt prompt engineering. Với các model mạnh như Claude, phần lớn công việc có thể giải quyết chỉ bằng prompt tốt.

Khi nào prompt là đủ:

• Tác vụ có thể mô tả rõ ràng bằng chỉ dẫn (phân loại, tóm tắt, viết lại, trích xuất, hỏi đáp trên ngữ cảnh được cấp).
• Bạn có thể đưa vài ví dụ (few-shot) vào prompt để định hướng.
• Định dạng đầu ra kiểm soát được bằng system prompt hoặc structured outputs.

Ưu điểm: thay đổi tức thì (không cần train, không cần chờ), chi phí gần như bằng không để thử nghiệm, dễ debug — bạn thấy ngay prompt nào cho kết quả nào.

Nhược điểm: prompt dài làm tăng chi phí token mỗi request; có những hành vi tinh tế rất khó "ép" chỉ bằng lời; nếu bạn phải lặp lại một khối chỉ dẫn khổng lồ trong mọi request thì đó là tín hiệu nên cân nhắc cách khác.

# Prompt engineering: định hướng hành vi bằng system prompt, không train lại gì cả
import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=(
        "Bạn là trợ lý ngân hàng NCB. Luôn trả lời bằng tiếng Việt, "
        "lịch sự, ngắn gọn. Nếu không chắc, hãy nói không chắc và đề nghị "
        "gặp nhân viên tư vấn. Không bao giờ bịa số liệu lãi suất."
    ),
    messages=[{"role": "user", "content": "Cho tôi hỏi thủ tục mở sổ tiết kiệm?"}],
)
print(resp.content[0].text)

RAG: khi model cần kiến thức riêng

Khi prompt engineering không đủ vì model thiếu thông tin — nó không biết tài liệu nội bộ, giá cả hôm nay, hay chính sách mới ban hành — thì RAG là câu trả lời. Bài LLM 4 — RAG đã đi sâu vào cơ chế; ở đây ta chỉ soi vào khi nào chọn nó.

Ưu điểm:

• Cập nhật dễ: thêm/sửa/xoá tài liệu trong kho là kiến thức của hệ thống thay đổi ngay, không cần train lại model.
• Trích dẫn được nguồn: vì câu trả lời dựa trên đoạn văn cụ thể, bạn có thể chỉ ra "câu này lấy từ tài liệu nào" — cực kỳ quan trọng cho các lĩnh vực cần kiểm chứng.
• Kiểm soát nguồn: bạn quyết định model được đọc gì; giới hạn nó chỉ dựa vào tài liệu đã duyệt.
• Rẻ hơn train: không cần hạ tầng huấn luyện, không cần dữ liệu gán nhãn.

Nhược điểm:

• Phụ thuộc chất lượng retrieval: nếu bước tìm kiếm lấy nhầm hoặc bỏ sót đoạn liên quan, model sẽ trả lời dựa trên ngữ cảnh sai — và chất lượng cả hệ thống bị chặn trên bởi chất lượng của retrieval, chứ không phải của model.

Với Claude, RAG còn kết hợp rất tốt với prompt caching: phần ngữ cảnh dài, ổn định (ví dụ khối hướng dẫn hệ thống) có thể được cache để giảm chi phí và độ trễ ở các request sau.

Fine-tuning: khi cần thay đổi hành vi ổn định

Fine-tuning là leo thang cuối cùng, và cũng là cách tốn kém nhất. Đừng chạm vào nó cho đến khi bạn chắc chắn prompt + RAG không giải quyết được.

Khi nào fine-tuning thực sự cần:

• Định dạng/giọng văn nhất quán: cần model luôn xuất đúng một cấu trúc, một tông giọng mà prompt không giữ ổn định được.
• Domain hẹp và sâu: một loại tác vụ chuyên biệt lặp lại rất nhiều, cần model thành thạo kỹ năng đó.
• Giảm chi phí prompt: nếu bạn phải nhét cùng một khối chỉ dẫn/ví dụ khổng lồ vào mọi request, fine-tune có thể "nén" phần đó vào trọng số, để prompt ngắn lại đáng kể ở quy mô lớn.

Cái giá phải trả:

• Chi phí & dữ liệu: cần tập dữ liệu ví dụ chất lượng cao (thường hàng trăm đến hàng nghìn cặp), tốn công gán nhãn và làm sạch.
• Bảo trì & MLOps: mỗi lần muốn đổi hành vi, bạn phải train lại; cần quy trình quản lý phiên bản model, đánh giá trước khi triển khai.
• Rủi ro quên thảm hoạ (catastrophic forgetting): model có thể học kỹ năng mới nhưng mất bớt năng lực tổng quát vốn có.
• Dễ lỗi thời: trọng số đã train là "đóng băng" tại thời điểm đó; kiến thức mới không tự chảy vào — đây lại chính là lý do fine-tuning không hợp để nhồi kiến thức.

Với Claude, khuyến nghị thực dụng là: cân nhắc kỹ prompt engineering + prompt caching + RAG trước. Bộ ba này giải quyết được phần rất lớn các bài toán mà không phải trả cái giá vận hành của fine-tuning. Chỉ khi eval chứng minh chúng chạm trần thì mới tính đến việc đổi trọng số.

Distillation: mô hình lớn dạy mô hình nhỏ

Có một kỹ thuật liên quan đáng biết: distillation (chưng cất). Ý tưởng: dùng một model lớn, mạnh (ví dụ Claude Opus) để tạo ra dữ liệu chất lượng cao — các cặp câu hỏi/câu trả lời mẫu — rồi dùng bộ dữ liệu đó "dạy" một model nhỏ hơn, rẻ hơn để nó làm tốt một việc hẹp.

Distillation phù hợp khi: bạn có một tác vụ cụ thể, khối lượng lớn, cần chi phí và độ trễ thấp ở production; model lớn làm tốt nhưng quá đắt để chạy hàng loạt; và bạn chấp nhận thu hẹp phạm vi để đổi lấy hiệu quả. Đây bản chất là một dạng fine-tuning có định hướng, nên nó cũng thừa hưởng chi phí dữ liệu và bảo trì của fine-tuning.

Mô hình nhỏ hay lớn: chọn theo độ khó và chi phí

Một quyết định song song, ít người để ý: bạn không nhất thiết phải dùng model mạnh nhất cho mọi việc. Anthropic cung cấp phổ model để bạn cân bằng độ khó tác vụ ↔ chi phí ↔ độ trễ:

• Haiku — nhanh và rẻ nhất, hợp các tác vụ đơn giản, khối lượng lớn (phân loại, định tuyến, trích xuất ngắn).
• Sonnet — cân bằng tốt giữa tốc độ và trí tuệ, ngựa thồ cho phần lớn workload production.
• Opus — mạnh nhất, dành cho suy luận khó, tác vụ dài hơi, agent nhiều bước.

Trong một hệ thống thật, hoàn toàn hợp lý khi dùng nhiều model: Haiku phân loại câu hỏi đầu vào rồi định tuyến, Sonnet trả lời phần lớn, Opus xử lý những case khó. Chọn model nhỏ khi tác vụ dễ và cần rẻ; leo lên model lớn khi độ khó thực sự đòi hỏi.

Kết hợp: thực tế thường là prompt + RAG

Ba con đường không loại trừ nhau — trong thực tế chúng chồng lên nhau. Kiến trúc phổ biến nhất cho một sản phẩm nghiêm túc là:

Câu hỏi người dùng
   │
   ├─▶ Prompt tốt (system prompt định hành vi, giọng văn, ràng buộc)
   │
   ├─▶ RAG (tìm tài liệu liên quan → nhét vào ngữ cảnh)
   │
   └─▶ Model phù hợp (Haiku/Sonnet/Opus tuỳ độ khó)
           │
           └─▶ Câu trả lời (có thể kèm trích dẫn nguồn)

Nghĩa là: prompt + RAG là mặc định, và fine-tuning chỉ được thêm vào khi eval chứng minh prompt + RAG không đạt một tiêu chí cụ thể nào đó (ví dụ độ ổn định định dạng, hoặc chi phí prompt quá cao ở quy mô lớn). Đừng bao giờ fine-tune "cho chắc" — hãy để dữ liệu quyết định.

Cây quyết định

Đây là bản đồ để chọn nhanh. Đọc từ trên xuống:

Diễn giải bằng lời:

• Cần kiến thức riêng/mới → RAG.
• Cần hành vi/định dạng ổn định mà prompt không giữ được (dù đã thử kỹ) → fine-tune.
• Còn lại → prompt engineering.
• Và bao trùm tất cả: luôn đo bằng eval. Không có eval thì bạn không biết mình đang tiến hay lùi, và mọi quyết định "chọn cách nào" chỉ là cảm tính.

Bảng so sánh ba cách

Use case thực tế: chatbot ngân hàng

Hãy đặt vào một bài toán cụ thể: chatbot hỏi đáp cho khách hàng ngân hàng. Khách hỏi về thủ tục mở tài khoản, biểu phí, chính sách lãi suất, hướng dẫn dùng app.

Prompt + RAG là đủ cho gần như toàn bộ:

• Prompt định hình hành vi: giọng văn lịch sự, luôn tiếng Việt, không bịa số liệu, gặp câu ngoài phạm vi thì đề nghị chuyển nhân viên tư vấn. Đây là những ràng buộc mà một system prompt tốt hoàn toàn xử lý được.
• RAG cấp kiến thức: biểu phí, chính sách, hướng dẫn sản phẩm nằm trong kho tài liệu. Khi lãi suất thay đổi hay ra sản phẩm mới, bạn chỉ cập nhật tài liệu — chatbot biết ngay, không phải train lại. Và mỗi câu trả lời có thể trích dẫn điều khoản nào, giúp khách tin tưởng và giúp đội tuân thủ kiểm chứng.

Kết hợp này giải quyết được yêu cầu cốt lõi (thông tin đúng, cập nhật được, kiểm chứng được) mà không hề động đến fine-tuning.

Khi nào mới cân nhắc fine-tune trong bối cảnh này? Chỉ khi eval chỉ ra một nhu cầu cụ thể mà prompt + RAG không đạt được. Ví dụ:

• Chatbot phải xuất kết quả theo một cấu trúc rất chặt để hệ thống nội bộ khác tiêu thụ, và dù đã thử structured outputs lẫn prompt kỹ, tỉ lệ sai định dạng vẫn cao ở quy mô lớn.
• Khối lượng cực lớn khiến prompt dài trở thành gánh nặng chi phí thật sự, và bạn muốn nén phần chỉ dẫn cố định vào model để prompt ngắn lại.

Ngay cả khi đó, kiến thức về lãi suất/chính sách vẫn ở lại trong RAG — bạn chỉ fine-tune phần hành vi, không phải phần dữ kiện. Đó chính là ranh giới cốt lõi của cả bài, áp dụng vào một tình huống thật.

Ghi nhớ

• Ba cấp, thử theo thứ tự: Prompt engineering (rẻ, nhanh) → RAG (khi thiếu kiến thức) → Fine-tuning (khi cần hành vi ổn định). Luôn bắt đầu từ cái rẻ nhất.
• Ranh giới cốt lõi: RAG cấp kiến thức lúc truy vấn (không đổi trọng số); Fine-tuning dạy hành vi/kỹ năng (đổi trọng số). Fine-tuning không phải cách tốt để nhồi kiến thức hay thông tin thời sự.
• Prompt giải quyết đa số việc với các model mạnh như Claude; đừng vội leo thang.
• RAG mạnh ở cập nhật dễ, trích dẫn nguồn, kiểm soát nguồn, rẻ hơn train — nhưng phụ thuộc chất lượng retrieval.
• Fine-tuning tốn kém: dữ liệu, chi phí train, bảo trì, rủi ro quên thảm hoạ và lỗi thời. Với Claude, ưu tiên prompt + prompt caching + RAG trước.
• Distillation: model lớn dạy model nhỏ/rẻ cho một việc hẹp, khối lượng lớn.
• Chọn model theo độ khó & chi phí: Haiku (đơn giản, rẻ) → Sonnet (cân bằng) → Opus (khó, dài hơi).
• Thực tế thường là prompt + RAG. Fine-tune chỉ khi eval chứng minh prompt + RAG không đạt.
• Cây quyết định: cần kiến thức riêng → RAG; cần hành vi/định dạng ổn định mà prompt không giữ được → fine-tune; còn lại → prompt. Và luôn đo bằng eval.

Đến đây series LLM ứng dụng & RAG chuyên sâu khép lại. Bạn đã đi từ nền tảng, prompt, embeddings, RAG, tools & agents, đánh giá, đưa lên production, và giờ là bức tranh tổng thể về cách chọn con đường tuỳ biến. Xa hơn nữa là các chủ đề vận hành và đạo đức — xem MLOps & đạo đức AI. Chúc bạn xây được những sản phẩm LLM đúng đắn, tiết kiệm, và đo được.