Chủ Nhật, 27 tháng 9, 2026

RAG là gì? (AI không biết tài liệu "lấp sông dời biển" của bạn? Nếu không muốn những câu trả lời "tình có như không" thì cho nó "đi lục tủ hồ sơ" trước khi trả lời! )

Nhăn nhó ôm "cục nợ" là cái chân đau nhức cả tuần nay tới gặp bác sĩ với "hy vọng" tràn trề, vừa thấy bác sĩ, bạn vô cùng mừng rỡ: "Bác sĩ ơi, cái chân của tôi sao tự nhiên nó cứ đau đau thế này?". Gật gù, bác sỹ phán chắc nịch: "Qua phim chụp thì tôi kết luận là chân của bạn đang bị đau nhé. Bạn cứ yên tâm, khi nào nó hết đau là nó sẽ bình thường lại ngay."...Chi lạ rứa trời!

Bạn hỏi AI:

"Chính sách nghỉ phép của công ty tôi là bao nhiêu ngày?"

AI trả lời rất tự tin:

"Thông thường nhân viên được nghỉ 12 ngày phép mỗi năm."

Nghe cũng hợp lý.

Nhưng...

Công ty bạn quy định 15 ngày. 😭

AI không hẳn "ngu".

Nó chỉ không có cuốn sổ nội bộ của công ty bạn.

Vậy làm sao để AI có thể trả lời dựa trên tài liệu thật của bạn?

Một trong những cách phổ biến là:

RAG.

RAG là gì?

RAG là viết tắt của:

Retrieval-Augmented Generation

Có thể hiểu đơn giản là:

Tìm thông tin liên quan trước → đưa thông tin đó cho AI → AI dựa vào thông tin vừa tìm được để trả lời.

Nói kiểu "bình dân":

Đừng bắt AI nhớ hết mọi thứ. Khi cần thì cho nó đi lục hồ sơ.

😆

Nếu không có RAG thì sao?

Hãy tưởng tượng bạn có một nhân viên bán hàng mới.

Bạn hỏi:

"Quy định hoàn tiền của công ty mình thế nào?"

Nhân viên mới chưa từng đọc tài liệu công ty.

Nhưng thay vì nói:

"Tôi chưa biết, để tôi kiểm tra tài liệu."

Bạn ấy lại trả lời đại:

"Thông thường công ty sẽ hoàn tiền trong vòng 7 ngày."

Nghe rất chuyên nghiệp.

Nhưng có thể... sai.

Đây chính là một trong những vấn đề khi sử dụng AI:

AI có thể tạo ra câu trả lời nghe rất hợp lý nhưng không dựa trên tài liệu mà bạn thực sự muốn nó sử dụng.

RAG giải quyết vấn đề này bằng cách thêm một bước:

Tìm tài liệu trước.

RAG hoạt động như thế nào?

Có thể hình dung đơn giản:

Người dùng hỏi
      ↓
Tìm kiếm tài liệu liên quan
      ↓
Lấy những đoạn phù hợp
      ↓
Đưa các đoạn này vào AI
      ↓
AI đọc context
      ↓
Tạo câu trả lời

Ví dụ:

Bạn hỏi:

"Nhân viên được nghỉ phép bao nhiêu ngày?"

Hệ thống RAG có thể làm:

Câu hỏi
↓
Tìm trong tài liệu công ty
↓
Tìm thấy:
"Nhân viên chính thức được nghỉ 15 ngày phép/năm..."
↓
Đưa đoạn này cho AI
↓
AI trả lời:
"Theo tài liệu công ty, nhân viên chính thức được nghỉ 15 ngày phép/năm."

Khác biệt rất lớn.

AI không cần phải "nhớ" chính sách 15 ngày.

Nó chỉ cần:

tìm đúng tài liệu → đọc đúng đoạn → trả lời.

Một ví dụ gần gũi hơn

Giả sử bạn có một thư mục:

TaiLieuCongTy/
│
├── Noi_quy.pdf
├── Luong_thuong.pdf
├── Nghi_phep.pdf
├── Bao_hiem.pdf
├── Huong_dan_IT.pdf
└── Quy_trinh_lam_viec.pdf

Bạn muốn tạo chatbot nội bộ.

Nhân viên hỏi:

"Tôi quên mật khẩu tài khoản công ty thì phải làm gì?"

Nếu chatbot chỉ dựa vào kiến thức chung của AI:

Nó có thể nói rất "đúng" nhưng cũng rất...nản:

"Bạn hãy liên hệ bộ phận IT."

Cũng chẳng sai.

Nhưng hơi... chung chung.

Nếu có RAG, hệ thống có thể tìm trong:

Huong_dan_IT.pdf

và tìm thấy:

"Nhân viên truy cập trang reset password nội bộ, nhập mã nhân viên và xác nhận OTP..."

Sau đó AI có thể trả lời dựa trên chính tài liệu đó.

Đây mới là chỗ RAG bắt đầu "có võ".

RAG gồm những phần nào?

Đừng vội thấy chữ "Retrieval-Augmented Generation" rồi chạy mất dép. 😆

Về cơ bản, bạn có thể hình dung RAG gồm vài bước chính.

Bước 1: Có dữ liệu

Ví dụ:

PDF
Word
TXT
HTML
Database
Website
Tài liệu nội bộ
FAQ
Manual

Đây là kho kiến thức.

Bước 2: Chia tài liệu thành các đoạn nhỏ

Một file PDF có thể dài 100 trang.

Bạn không muốn mỗi lần người dùng hỏi một câu lại ném nguyên 100 trang vào AI.

Vừa tốn tài nguyên.

Vừa dễ loạn.

Vì vậy tài liệu thường được chia thành những đoạn nhỏ hơn.

Ví dụ:

Tài liệu 100 trang
        ↓
   chia thành đoạn
        ↓
Chunk 1
Chunk 2
Chunk 3
Chunk 4
...
Chunk 500

Những đoạn nhỏ này thường được gọi là:

chunk

Bạn có thể hiểu đơn giản:

Chunk = một miếng nhỏ của tài liệu.

Giống như bạn có một cuốn sách dày 500 trang.

Không ai hỏi:

"Cho tôi toàn bộ cuốn sách."

Người ta thường hỏi:

"Đoạn nào nói về bảo hành?"

Rồi bạn lật đúng chương đó.

RAG cũng có tư duy tương tự.

Bước 3: Tìm đoạn liên quan

Đây là phần rất quan trọng.

Người dùng hỏi:

"Sản phẩm được bảo hành bao lâu?"

Hệ thống cần tìm được những đoạn liên quan đến:

bảo hành
thời gian bảo hành
điều kiện bảo hành

chứ không phải lấy đại:

cách thanh toán
địa chỉ công ty
chính sách giao hàng

Nếu tìm sai tài liệu thì AI phía sau có giỏi đến đâu cũng khó cứu.

Đây là một câu rất đáng nhớ:

AI trả lời hay chưa chắc có nghĩa là hệ thống tìm đúng dữ liệu.

Bước 4: Đưa những đoạn tìm được cho AI

Giả sử hệ thống tìm được:

Chunk A:
"Sản phẩm được bảo hành trong thời gian 12 tháng..."

Chunk B:
"Thời gian bảo hành được tính từ ngày mua..."

Chunk C:
"Sản phẩm bị hư hỏng do nước không thuộc phạm vi bảo hành..."

Những thông tin này được đưa vào context cho AI.

AI lúc này mới tạo câu trả lời.

Ví dụ:

"Theo chính sách bảo hành, sản phẩm được bảo hành 12 tháng kể từ ngày mua. Tuy nhiên, hư hỏng do nước không thuộc phạm vi bảo hành."

Nghe có vẻ đơn giản.

Nhưng phía sau là cả một hệ thống tìm kiếm tài liệu.

RAG khác gì với việc "copy tài liệu rồi dán vào ChatGPT"?

Thực ra...

Ý tưởng nền tảng khá giống nhau. 😆

Bạn có thể tự làm:

Mở tài liệu
↓
Copy đoạn liên quan
↓
Paste vào AI
↓
Hỏi AI

Đó cũng là một dạng tư duy "đưa context vào cho AI".

Nhưng nếu công ty có:

10.000 tài liệu

thì bạn không thể sáng nào cũng:

Ctrl + F → copy → paste → hỏi AI.

Làm được 3 ngày có khi bạn xin nghỉ phép luôn. 😂

RAG tự động hóa phần này:

Người dùng hỏi
↓
Hệ thống tự tìm
↓
Tự lấy đoạn liên quan
↓
Tự đưa vào AI
↓
AI trả lời

Đó mới là điểm mạnh.

RAG có phải là AI "học" thêm kiến thức không?

Đây là chỗ rất nhiều người dễ hiểu nhầm.

Không nhất thiết.

RAG không đơn giản là:

"Dạy AI nhớ thêm tài liệu."

Thay vào đó, bạn có thể hình dung:

AI
+
Kho tài liệu
+
Cơ chế tìm kiếm
=
RAG

Khi người dùng hỏi, hệ thống đi lấy thông tin cần thiết rồi đưa vào AI.

Nói vui:

Không bắt AI thuộc lòng cả thư viện. Cho nó thẻ thư viện là được. 😆

RAG và Fine-tuning có giống nhau không?

Không.

Đây là hai khái niệm rất dễ bị trộn vào nhau.

RAG

RAG thiên về:

"Khi hỏi thì đi tìm thông tin bên ngoài rồi đưa cho AI."

Ví dụ:

Câu hỏi
↓
Tìm tài liệu
↓
Đưa tài liệu cho AI
↓
Trả lời

Fine-tuning

Fine-tuning là một hướng khác.

Nó liên quan đến việc huấn luyện/điều chỉnh mô hình bằng dữ liệu phù hợp để thay đổi cách mô hình thực hiện một nhiệm vụ hoặc phản hồi.

Nói đơn giản:

RAG:
"Đây, tài liệu đây. Đọc rồi trả lời."

Fine-tuning:
"Ta sẽ điều chỉnh mô hình bằng dữ liệu huấn luyện phù hợp."

Hai thứ có thể phục vụ những mục đích khác nhau.

Và trong nhiều hệ thống thực tế, chúng thậm chí có thể được sử dụng kết hợp.

Phần Fine-tuning sẽ còn xuất hiện sau trong roadmap, nên ở đây chỉ cần nhớ sự khác biệt cơ bản là đủ.

RAG có làm AI hết "ảo giác" không?

Không.

Đây là điểm cực kỳ quan trọng.

Nhiều người nghe:

"RAG giúp AI dựa trên tài liệu."

rồi suy ra:

"Có RAG = AI không bao giờ nói sai."

Không phải.

RAG có thể giúp AI có thêm thông tin liên quan và giảm việc trả lời thiếu căn cứ trong nhiều tình huống.

Nhưng hệ thống vẫn có thể sai.

Ví dụ:

Tìm sai tài liệu
↓
Lấy sai chunk
↓
Chunk không đủ thông tin
↓
AI hiểu sai context
↓
AI trả lời sai

Hoặc:

Tài liệu cũ
↓
RAG tìm đúng tài liệu
↓
AI trả lời rất chính xác
↓
... chính xác theo tài liệu đã lỗi thời. 😭

Đây là lý do:

RAG không biến AI thành sự thật tuyệt đối.

Nó chỉ giúp AI có thêm dữ liệu để dựa vào.

Một hệ thống RAG có thể trông như thế này

Hãy tưởng tượng bạn xây chatbot cho DatVietLapTrinh.

Bạn có hàng trăm bài viết:

PHP
Python
HTML
Database
API
AI
Automation
...

Người đọc hỏi:

"Tại sao pip install lại không hoạt động?"

Hệ thống có thể:

Câu hỏi
   ↓
Tìm bài viết liên quan
   ↓
Lấy đoạn nói về pip
   ↓
Lấy đoạn nói về PATH
   ↓
Lấy đoạn nói về python -m pip
   ↓
Đưa context cho AI
   ↓
AI tạo câu trả lời

Nếu làm tốt, chatbot không chỉ trả lời kiểu:

"Bạn hãy cài lại Python."

Mà có thể dựa vào chính kho bài viết của bạn để giải thích:

"Hãy thử python -m pip --version trước. Nếu lệnh này hoạt động nhưng pip --version không hoạt động, khả năng cao vấn đề nằm ở PATH..."

Đây chính là kiểu ứng dụng rất thực tế của RAG.

RAG rất hợp với dữ liệu nào?

RAG đặc biệt hữu ích khi bạn có một kho thông tin mà AI cần tra cứu.

Ví dụ:

Công ty

Nội quy
Quy trình
Chính sách
Tài liệu nhân sự
Tài liệu kỹ thuật

Website bán hàng

Thông tin sản phẩm
Chính sách đổi trả
Bảo hành
FAQ
Hướng dẫn sử dụng

Trường học

Nội quy
Tài liệu môn học
Lịch học
Quy định
Tài liệu hướng dẫn

Bộ phận hỗ trợ kỹ thuật

Manual
Documentation
FAQ
Troubleshooting
Knowledge Base

Blog

Bài viết
Hướng dẫn
FAQ
Documentation

RAG có thể dùng dữ liệu riêng tư không?

Có thể.

Và đây cũng là lúc phải cẩn thận.

Ví dụ công ty có:

salary.xlsx
employee_data.xlsx
internal_policy.pdf
customer_data.csv

Không phải cứ:

"Cho AI đọc hết."

là xong.

Bạn phải quan tâm:

Ai được phép tìm tài liệu?
Ai được xem tài liệu?
Người A có được đọc dữ liệu của người B không?
Tài liệu nào là công khai?
Tài liệu nào là nội bộ?
Có cần phân quyền không?
Có cần ẩn dữ liệu nhạy cảm không?

Một hệ thống RAG tốt không chỉ có:

Search → AI

mà còn phải quan tâm đến:

User
↓
Permission
↓
Search
↓
Relevant documents
↓
AI
↓
Answer

Nếu không, bạn có thể tạo ra một chatbot rất thông minh...

...và nó vô tình trở thành "máy photocopy tài liệu mật". 😭

RAG liên quan gì đến bài Prompt Engineering?

Rất liên quan.

Ở bài trước, chúng ta nói:

Prompt tốt giúp AI hiểu đúng yêu cầu.

Còn RAG thêm một chuyện:

AI phải có đúng thông tin để dựa vào.

Có thể hình dung:

Prompt tốt
      +
Context tốt
      +
Dữ liệu liên quan
      ↓
AI có cơ sở tốt hơn để trả lời

Nhưng nhớ nhé:

Prompt tốt không cứu được dữ liệu sai.

Bạn đưa cho AI tài liệu sai rồi viết prompt đẹp như thơ:

"Hãy cực kỳ chính xác..."

thì tài liệu sai vẫn là tài liệu sai. 😂

RAG có phải chỉ là tìm kiếm Google không?

Không hẳn.

Google cũng là một hệ thống tìm kiếm.

Nhưng trong RAG, mục tiêu thường là:

Tìm những đoạn thông tin phù hợp nhất với câu hỏi để đưa vào context cho mô hình AI.

Ví dụ bạn hỏi:

"Cách reset password trong hệ thống nội bộ là gì?"

Hệ thống RAG có thể tìm:

password reset
reset mật khẩu
quên mật khẩu
OTP
tài khoản nhân viên

rồi chọn những đoạn phù hợp.

Và đây chính là lúc một khái niệm khác bắt đầu xuất hiện:

Embedding.

Embedding là gì?

Ở mức rất đơn giản:

Embedding là cách biến dữ liệu như văn bản thành một dạng biểu diễn số để máy có thể so sánh mức độ liên quan.

Nghe hơi "AI hàn lâm" rồi đúng không?

Không sao.

Bài này chỉ cần hiểu:

"Cách đổi mật khẩu?"

và:

"Quên password thì reset tài khoản như thế nào?"

Hai câu khác chữ.

Nhưng con người nhìn vào sẽ thấy:

Chúng đang hỏi gần giống nhau.

Hệ thống RAG cần một cách để máy cũng có thể tìm được sự liên quan đó.

Embedding là một trong những công cụ quan trọng cho việc này.

Và khi đã có rất nhiều embedding...

Bạn cần một nơi để lưu trữ và tìm kiếm chúng.

Đó là lúc chúng ta gặp:

Vector Database.

Vector Database là gì?

Chỉ cần nhớ sơ bộ ở bài này:

Vector Database là một loại cơ sở dữ liệu được thiết kế để lưu trữ và tìm kiếm các vector/embedding một cách phù hợp cho những bài toán như tìm kiếm theo độ tương đồng.

Ví dụ:

Câu hỏi người dùng
       ↓
Embedding
       ↓
Tìm vector gần nhất
       ↓
Lấy các đoạn tài liệu tương ứng
       ↓
Đưa cho AI
       ↓
Trả lời

Vậy là bạn đã thấy một phần "bộ máy" phía sau RAG.

Bài #79 chúng ta sẽ đi sâu hơn vào:

Vector Database.

Và đừng lo.

Không phải học xong bài đó là bạn phải trở thành nhà toán học. 😆

Một ví dụ RAG mini bằng tư duy lập trình

Chưa cần viết cả hệ thống RAG thật.

Bạn chỉ cần hiểu logic:

question = "Làm sao reset mật khẩu?"

documents = [
    "Cách đặt hàng online...",
    "Nhân viên quên mật khẩu có thể reset bằng OTP...",
    "Chính sách giao hàng...",
]

relevant_documents = search(documents, question)

context = "\n".join(relevant_documents)

answer = ai_answer(
    question=question,
    context=context
)

print(answer)

Điểm quan trọng không phải cú pháp.

Mà là luồng:

QUESTION
   ↓
SEARCH
   ↓
RELEVANT DOCUMENTS
   ↓
CONTEXT
   ↓
AI
   ↓
ANSWER

Đó chính là tư duy cốt lõi của RAG.

Nếu RAG tìm sai thì sao?

Đây là phần rất đáng nhớ đối với dân thích debug.

Giả sử người dùng hỏi:

"Sản phẩm này bảo hành bao lâu?"

Nhưng RAG lại lấy:

Chunk 1: Chính sách giao hàng
Chunk 2: Phương thức thanh toán
Chunk 3: Địa chỉ cửa hàng

AI đọc ba đoạn này.

Rồi bạn ngồi nhìn câu trả lời:

"Sản phẩm được giao trong vòng 2-3 ngày..."

😐

Bạn:

"Tôi hỏi bảo hành mà?"

AI:

"Xin lỗi..." 😭

Lúc này đừng chỉ nhìn vào AI.

Hãy debug cả pipeline:

Question đúng?
        ↓
Search đúng?
        ↓
Retrieval đúng?
        ↓
Chunk đúng?
        ↓
Context đủ?
        ↓
Prompt đúng?
        ↓
AI trả lời đúng?

Đây là tư duy rất quan trọng khi làm AI application.

AI trả lời sai không đồng nghĩa lỗi nằm ở model.

Có thể lỗi nằm ở:

dữ liệu
cách chia chunk
cách tìm kiếm
embedding
permission
prompt
context
hoặc chính câu hỏi của người dùng

Chua thêm một chút 😆

Có một kiểu RAG rất "đời":

Bạn có một đống tài liệu.

Bạn bảo:

"AI ơi, đọc giúp tôi."

AI đọc.

Bạn hỏi:

"Theo tài liệu, sản phẩm A bảo hành bao lâu?"

AI trả lời:

"12 tháng."

Bạn:

"Tài liệu nào?"

AI:

"Tài liệu bảo hành."

Bạn:

"Trang mấy?"

AI:

"..." 😶

Đây là lý do các hệ thống RAG thực tế thường rất quan tâm đến việc trả về nguồn/citation, metadata và khả năng truy vết.

Không chỉ:

"AI nói gì?"

mà còn:

"AI dựa vào tài liệu nào?"

Đối với hệ thống nội bộ, hỗ trợ kỹ thuật hoặc tài liệu doanh nghiệp, điều này cực kỳ hữu ích.

RAG có phải lúc nào cũng cần Vector Database không?

Không nhất thiết.

Đây cũng là chỗ người mới dễ nghĩ:

"Muốn làm RAG thì bắt buộc phải có Vector Database."

Không hẳn.

Tùy hệ thống, bạn có thể dùng nhiều cách tìm kiếm khác nhau, chẳng hạn:

Keyword Search
Semantic Search
Vector Search
Hybrid Search

Có hệ thống kết hợp nhiều phương pháp.

Vì vậy:

RAG là một kiến trúc/luồng xử lý.

Còn Vector Database chỉ là một trong những công cụ có thể được dùng để hỗ trợ phần retrieval.

Đừng biến công cụ thành khái niệm. 😆

RAG có phù hợp với người mới học lập trình không?

Có.

Không phải vì bạn cần lập tức xây một hệ thống RAG.

Mà vì RAG giúp bạn hiểu một cách rất quan trọng về AI hiện đại:

AI application không nhất thiết chỉ là "gọi AI rồi lấy câu trả lời".

Bạn có thể xây cả một pipeline:

User
 ↓
Question
 ↓
Search
 ↓
Retrieve data
 ↓
Build context
 ↓
AI
 ↓
Answer
 ↓
Source

Và mỗi bước đều có thể debug.

Đây chính là điểm rất hợp với tư duy lập trình mà chúng ta đã học từ đầu.

Debug RAG kiểu người mới

Nếu chatbot RAG trả lời sai, thử kiểm tra theo thứ tự:

1. Câu hỏi có rõ không?

"Chính sách?"

quá mơ hồ.

Trong khi:

"Sản phẩm A được bảo hành bao nhiêu tháng?"

rõ hơn nhiều.

2. Tài liệu có chứa câu trả lời không?

Nếu tài liệu không có thông tin...

RAG cũng không thể tự biến tài liệu thành thông tin. 😆

3. Tài liệu có được chia chunk hợp lý không?

Chunk quá nhỏ:

mất ngữ cảnh

Chunk quá lớn:

tìm kiếm kém chính xác

4. Retrieval có lấy đúng đoạn không?

Đây là điểm cực kỳ quan trọng.

5. Context có được đưa đúng vào AI không?

Có thể retrieval đúng nhưng bước truyền context bị lỗi.

6. Prompt có hướng dẫn AI sử dụng context không?

Nếu không, AI có thể không xử lý context theo cách bạn mong muốn.

7. Tài liệu có cũ không?

Đây là lỗi rất "đau".

RAG tìm đúng tài liệu...

nhưng tài liệu từ năm 2022.

😂

Bạn có thể cũng đang gặp...

Nếu bạn đang học theo series này, các bài liên quan khá gần với RAG gồm:

Nhìn lại một chút sẽ thấy:

Python
   ↓
API
   ↓
JSON
   ↓
Automation
   ↓
AI
   ↓
AI Agent
   ↓
Prompt
   ↓
RAG
   ↓
Vector Database

Tự nhiên thấy mấy bài trước không hề học riêng lẻ. 😄

Chúng đang nối dần thành một hệ thống.

Checklist RAG cho người mới học

Nếu hôm nay bạn chỉ muốn nhớ những thứ quan trọng nhất, hãy giữ lại checklist này:

RAG = Retrieval-Augmented Generation
RAG tìm thông tin trước khi AI trả lời
Tài liệu có thể được chia thành các chunk
Retrieval là phần tìm thông tin liên quan
Context là thông tin được đưa cho AI
RAG không có nghĩa AI "học thuộc" tài liệu
RAG không đảm bảo AI luôn đúng
Retrieval sai có thể khiến AI trả lời sai
Tài liệu cũ cũng có thể khiến câu trả lời cũ
Permission rất quan trọng với dữ liệu riêng tư
Có thể dùng RAG cho PDF, website, FAQ, database, tài liệu nội bộ...
Vector Database là một công cụ thường dùng cho phần retrieval
Debug RAG phải nhìn cả pipeline, không chỉ nhìn AI

FAQ nhanh

RAG có phải là một AI model không?

Không.

RAG là một cách xây dựng hệ thống trong đó thông tin liên quan được truy xuất rồi cung cấp cho mô hình AI để tạo câu trả lời.

RAG có thay thế AI model không?

Không.

RAG thường kết hợp với một mô hình AI để tạo câu trả lời.

RAG có làm AI hết hallucination không?

Không.

Nó có thể giúp AI có thêm context phù hợp, nhưng retrieval sai, dữ liệu sai/cũ hoặc AI hiểu sai context vẫn có thể dẫn đến câu trả lời sai.

RAG có cần dữ liệu riêng không?

Không bắt buộc phải là dữ liệu riêng.

Bạn có thể dùng dữ liệu công khai, tài liệu nội bộ, website, FAQ, database... tùy hệ thống.

RAG có cần Vector Database không?

Không nhất thiết.

Vector Database là một trong những công cụ có thể dùng cho retrieval. Có nhiều cách tìm kiếm và nhiều hệ thống còn kết hợp nhiều phương pháp.

RAG và Fine-tuning khác nhau thế nào?

Nhớ đơn giản:

RAG: tìm thông tin rồi đưa cho AI.

Fine-tuning: điều chỉnh mô hình thông qua dữ liệu huấn luyện phù hợp.

Hai khái niệm này giải quyết những bài toán khác nhau.