Những câu hay được hỏi nhất

20 câu, xếp từ dễ tới khó. Năm câu cuối là về chính dự án Cowork-Local — nhóm câu này gần như chắc chắn sẽ có người hỏi.

Nội dung

RAG là gì, nói gọn trong một câu?
RAG khác fine-tuning thế nào?
RAG có xoá hết bịa đặt không?
Vector là gì mà so sánh được nghĩa?
Chia đoạn bao nhiêu chữ là đúng?
Overlap để làm gì?
top-K nên đặt bao nhiêu?
Chọn mô hình embedding thế nào? Tiếng Việt thì sao?
Bắt buộc phải có Vector DB không?
Chỉ tìm theo vector đã đủ chưa?
Câu hỏi cần nối nhiều tài liệu thì sao?
Context window đã 1 triệu token, còn cần RAG?
Chi phí thực tế bao nhiêu?
RAG làm chậm bao nhiêu?
Tài liệu sửa thì cập nhật thế nào?
Đo chất lượng RAG bằng gì?
Phân quyền tài liệu xử lý ra sao?
Cowork-Local đã có RAG chưa?
GraphRAG của dự án có phải GraphRAG của Microsoft?
Muốn nâng lên RAG đầy đủ cần làm gì?

Nhóm 1 — Khái niệm

1 RAG là gì, nói gọn trong một câu?

Tìm tài liệu liên quan trước, rồi đưa cho LLM đọc và trả lời dựa trên đó — thay vì để LLM trả lời bằng trí nhớ có sẵn.

Ví von: thay vì bắt thí sinh làm bài từ trí nhớ, ta cho thi mở sách — nhưng có thủ thư lật sẵn đúng trang cần đọc.

2 RAG khác fine-tuning thế nào? Khi nào dùng cái nào?

văn phong, định dạng ✔ Dạy được kỹ năng chuyên ngành ✘ Kiến thức mới → phải train lại

RAG thêm kiến thức. Fine-tune thay đổi hành vi.

Quy tắc chọn: câu trả lời phụ thuộc nội dung tài liệu → RAG. Phụ thuộc cách nói / định dạng / kỹ năng → fine-tune. Cần cả hai thì làm cả hai.

Đa số bài toán doanh nghiệp là loại thứ nhất, nên RAG hầu như luôn là bước làm trước.

3 RAG có xoá hết bịa đặt (hallucination) không?

Không. Chỉ giảm mạnh. Đây là câu dễ bị hỏi vặn nhất, nên trả lời thẳng.

RAG vẫn sai được ở bốn chỗ:

Tra sai đoạn — lấy nhầm tài liệu, LLM trả lời trung thực trên tài liệu sai.
Không có trong kho — LLM vẫn cố trả lời thay vì nói "không tìm thấy".
Đọc đúng nhưng suy diễn thêm — thêm chi tiết không có trong đoạn trích.
Tài liệu gốc đã sai — RAG không kiểm chứng nội dung.

Cách khắc phục thực dụng: bắt LLM trích dẫn đoạn nguồn cho từng ý, và cho phép trả lời "không tìm thấy trong tài liệu". Slide "Ưu điểm" nên nói giảm hallucination, không nói hết.

4 Vector là gì mà so sánh được "nghĩa giống nhau"?

Mỗi đoạn chữ thành một điểm trong không gian nhiều chiều. Gần nhau = gần nghĩa.

Mô hình embedding biến một đoạn chữ thành dãy số (768 – 4096 chiều). Nó được huấn luyện sao cho hai đoạn cùng nghĩa cho ra hai điểm gần nhau, kể cả khi không trùng một chữ nào.

Máy đo "gần" bằng cosine similarity — góc giữa hai vector. Nhờ vậy hỏi "xe hơi" vẫn tìm ra tài liệu viết "ô tô".

Đây chính là điểm RAG hơn tìm kiếm từ khoá: từ khoá cần trùng chữ, vector chỉ cần trùng nghĩa.

Nhóm 2 — Tham số kỹ thuật

5 Chia đoạn bao nhiêu chữ là đúng?

Không có con số đúng chung — phụ thuộc loại tài liệu. Nhưng có nguyên tắc:

Loại tài liệu	Cỡ đoạn gợi ý	Vì sao
FAQ, hỏi đáp ngắn	100 – 300 chữ	Mỗi mục vốn đã độc lập
Chính sách, quy trình	300 – 600 chữ	Giữ trọn một điều khoản
Sách, báo cáo dài	500 – 1000 chữ	Cần đủ ngữ cảnh xung quanh
Mã nguồn	theo hàm / lớp	Cắt giữa hàm là hỏng nghĩa

Đoạn quá nhỏ → mất ngữ cảnh, tra ra mảnh vụn vô nghĩa. Đoạn quá lớn → một đoạn chứa nhiều chủ đề, vector bị "trung bình hoá" nên tra kém chính xác, lại tốn token.

Thực tế nên cắt theo cấu trúc trước (theo mục, theo điều, theo hàm) rồi mới giới hạn độ dài — cắt cứng theo số chữ là phương án cuối.

6 Overlap 10–20% để làm gì?

Overlap là bảo hiểm cho những câu nằm vắt ngang ranh giới đoạn.

Cắt cứng theo số chữ sẽ có lúc cắt giữa một câu hoặc giữa một ý. Đoạn nào cũng lặp lại một phần đoạn trước thì thông tin ở ranh giới luôn còn nguyên vẹn ở ít nhất một đoạn.

Giá phải trả: kho phình thêm đúng bằng tỉ lệ overlap. 20% overlap → nhiều hơn ~20% vector.

7 top-K nên đặt bao nhiêu?

Thường 3 – 10. Cách chọn:

K nhỏ (3–5) — câu hỏi tra cứu một dữ kiện. Ít nhiễu, rẻ, nhanh.
K lớn (8–15) — câu hỏi tổng hợp, cần gom nhiều nguồn.

K càng lớn không đồng nghĩa càng chính xác. Đoạn thứ 15 thường đã lạc đề, và nó làm loãng ngữ cảnh khiến LLM trả lời kém đi — hiện tượng "lạc giữa đống tài liệu".

Thực dụng hơn: đặt ngưỡng điểm tương đồng thay vì K cố định — lấy mọi đoạn trên ngưỡng, không có đoạn nào đạt thì trả lời "không tìm thấy".

8 Chọn mô hình embedding thế nào? Tiếng Việt có ổn không?

Ba tiêu chí: hỗ trợ tiếng Việt, số chiều, chạy nội bộ hay gọi API.

Nhóm	Ví dụ	Ghi chú
API thương mại	OpenAI `text-embedding-3`, Cohere	Chất lượng tốt, nhưng tài liệu phải gửi ra ngoài
Đa ngữ, chạy nội bộ	multilingual-e5, BGE-M3	Tiếng Việt khá tốt, chạy được trên máy công ty
Chuyên tiếng Việt	PhoBERT và các bản fine-tune	Cần đánh giá lại trên chính dữ liệu của mình

Lưu ý bắt buộc: đổi mô hình embedding thì phải index lại toàn bộ kho. Vector của mô hình này không so sánh được với vector của mô hình khác. Nên chọn kỹ ngay từ đầu.

Với dữ liệu nội bộ nhạy cảm, nhóm "chạy nội bộ" thường là lựa chọn duy nhất khả thi.

9 Bắt buộc phải có Vector DB riêng không?

Không. Chọn theo quy mô:

Quy mô	Giải pháp	Ghi chú
< 100k vector	FAISS, Chroma, hoặc file numpy	Không cần dựng thêm dịch vụ
Đã có PostgreSQL	`pgvector`	Dùng luôn DB sẵn có — thường là lựa chọn tốt nhất
Triệu vector trở lên	Milvus, Qdrant, Weaviate	Cần index ANN chuyên dụng
Không muốn tự vận hành	Pinecone	Dịch vụ đám mây, dữ liệu ra ngoài

Ví dụ trong slide — 100 file PDF ra 20.000 vector — hoàn toàn không cần Vector DB chuyên dụng. FAISS trên một máy là đủ và nhanh.

Nhóm 3 — Chất lượng truy hồi

10 Chỉ tìm theo vector đã đủ chưa?

Hai cách tìm bù khuyết cho nhau, rồi lọc lại một lần nữa.

Chưa đủ. Vector giỏi bắt ý nghĩa nhưng dở với mã số, tên riêng, ký hiệu — hỏi "điều 7.5.3" hay "mã lỗi FN0101" thì tìm từ khoá lại chính xác hơn hẳn.

Hai cải tiến gần như luôn đáng làm:

Hybrid search — chạy song song vector + từ khoá (BM25), gộp kết quả.
Rerank — lấy ~30 đoạn rồi dùng mô hình cross-encoder chấm lại, giữ 5 đoạn tốt nhất. Đây thường là cải thiện lớn nhất với chi phí nhỏ nhất.

11 Câu hỏi cần nối nhiều tài liệu (multi-hop) thì sao?

Slide đã nêu đúng đây là điểm yếu. Ví dụ: "Nhân viên nào ký hợp đồng với nhà cung cấp có doanh số cao nhất năm ngoái?" — cần tra bảng doanh số trước, rồi mới tra hợp đồng.

RAG một lượt sẽ hỏng, vì một lần tra không thể ra cả hai. Ba hướng xử lý:

Tra nhiều vòng (agentic RAG) — cho LLM tự quyết định tra tiếp, dùng kết quả vòng trước làm câu truy vấn vòng sau.
Tách câu hỏi — chia thành các câu con, tra từng câu, rồi tổng hợp.
Knowledge graph — dựng sẵn quan hệ giữa các thực thể để đi theo liên kết thay vì tra lại từ đầu. Đây chính là ý tưởng của GraphRAG.

Nhóm 4 — Vận hành

12 Context window đã tới 1 triệu token — còn cần RAG không?

Vẫn cần, vì ba lý do:

Chi phí — nhét 500k token vào mỗi câu hỏi thì mỗi lượt hỏi tốn gấp hàng trăm lần so với nhét 5 đoạn. Nhân với số lượt hỏi mỗi ngày.
Độ trễ — đọc 500k token mất hàng chục giây.
Quy mô — kho tài liệu doanh nghiệp thường vài chục triệu token, vượt xa mọi context window.

Thêm nữa, độ chính xác giảm khi ngữ cảnh quá dài — mô hình hay bỏ sót thông tin nằm ở giữa. Đưa 5 đoạn đúng thường cho kết quả tốt hơn đưa cả cuốn sách.

Context dài có chỗ dùng: khi tổng tài liệu nhỏ (vài chục trang) và bạn muốn giải pháp đơn giản nhất — lúc đó bỏ RAG cho gọn là hợp lý.

13 Chi phí thực tế bao nhiêu?

Tách làm hai phần, và phần đắt không phải phần người ta hay lo:

Khoản	Khi nào phát sinh	Mức độ
Embedding tài liệu	Một lần lúc index + khi tài liệu đổi	Rẻ — embedding rẻ hơn LLM hàng chục lần
Lưu trữ vector	Liên tục	Nhỏ, trừ khi kho cực lớn
Embedding câu hỏi	Mỗi lượt hỏi	Không đáng kể
LLM sinh câu trả lời	Mỗi lượt hỏi	Chiếm phần lớn chi phí

Vì vậy giảm chi phí RAG thực chất là giảm số token đưa vào LLM — tức chọn top-K gọn và đoạn sạch, chứ không phải tiết kiệm ở khâu embedding.

14 RAG làm chậm thêm bao nhiêu?

Bước tra thường tốn vài chục tới vài trăm mili-giây: embedding câu hỏi + tìm trong vector DB. Có rerank thì cộng thêm chút nữa.

So với thời gian LLM sinh câu trả lời (thường vài giây), phần này gần như không đáng kể.

Slide ghi "ứng dụng real-time cần < 100ms" thì nên cẩn trọng — đúng, nhưng lúc đó nút thắt là LLM, không phải bước tra. Nếu cần dưới 100ms thì bản thân việc gọi LLM đã không khả thi rồi.

15 Tài liệu sửa thì cập nhật thế nào?

Chỉ cần index lại phần thay đổi, không đụng tới mô hình:

File sửa → xoá vector cũ của file đó, embedding lại, ghi vector mới.
File xoá → xoá vector tương ứng.
File mới → embedding và thêm vào.

Cách làm thực dụng: lưu kèm hash nội dung mỗi file, chạy định kỳ, chỉ xử lý file có hash đổi. Vài giây cho một lần cập nhật thông thường.

Ngoại lệ duy nhất phải làm lại toàn bộ: đổi mô hình embedding hoặc đổi cách chia đoạn.

16 Đo chất lượng RAG bằng gì? Làm sao biết là tốt?

Điểm mấu chốt: đo tách hai khâu, vì hỏng ở đâu thì sửa ở đó khác nhau.

Khâu	Đo gì	Hỏng thì sửa gì
Truy hồi	Đoạn đúng có nằm trong top-K không?	Chia đoạn, mô hình embedding, hybrid, rerank
Sinh câu trả lời	Câu trả lời có bám vào đoạn đã lấy không?	Prompt, model, yêu cầu trích nguồn

Cách làm tối thiểu mà hiệu quả: dựng bộ 50–100 câu hỏi mẫu có đáp án đúng lấy từ người dùng thật. Mỗi lần chỉnh tham số thì chạy lại bộ đó và so điểm.

Không có bộ câu hỏi mẫu thì mọi tinh chỉnh chỉ là cảm tính — đây là việc nên làm ngay từ đầu, trước cả khi tối ưu.

17 Phân quyền tài liệu xử lý ra sao? Người A không được xem tài liệu của phòng B.

Đây là câu hay bị bỏ quên tới lúc triển khai thật mới lộ ra.

Nguyên tắc: lọc quyền ở bước truy hồi, không phải ở bước trả lời. Tuyệt đối không dựa vào việc nhắc LLM "đừng nói về tài liệu này" — không đáng tin.

Mỗi vector lưu kèm metadata quyền (phòng ban, mức mật, danh sách người xem).
Khi tra, lọc theo quyền của người hỏi ngay trong truy vấn.
Tài liệu ngoài quyền thì không bao giờ vào được ngữ cảnh của LLM.

Rủi ro thường gặp: một đoạn trích chứa thông tin mật lọt vào ngữ cảnh, LLM tóm tắt lại và rò rỉ gián tiếp dù không trích nguyên văn.

Nhóm 5 — Về dự án Cowork-Local

Nhóm này gần như chắc chắn được hỏi, vì slide 17 đã tự nêu ra.

18 Vậy Cowork-Local đã có RAG chưa?

Trả lời thẳng như slide 17 đã viết: chưa có RAG theo nghĩa đầy đủ.

Dự án đang ở mức 2. Mức 3 mới là RAG như trình bày ở phần đầu.

Cách nói an toàn khi bị hỏi vặn: "Hiện tại là truy xuất theo cấu trúc, chưa phải truy xuất theo ngữ nghĩa. Phần trình bày hôm nay là kiến thức nền cho bước tiếp theo."

19 "GraphRAG" của dự án có phải GraphRAG của Microsoft không?

Câu này rất dễ bị hỏi và dễ gây hiểu nhầm — nên chủ động làm rõ trước.

	GraphRAG (Microsoft)	GraphRAG trong Cowork-Local
Đồ thị chứa gì	Thực thể và quan hệ do LLM trích từ nội dung	File, lớp, hàm và liên kết import
Dựng bằng gì	Gọi LLM nhiều lượt, tốn chi phí	Phân tích cú pháp mã nguồn, không tốn phí gọi AI
Trả lời câu hỏi	Đi theo quan hệ + tóm tắt theo cụm	Đọc sơ đồ và nội dung file liên quan

Cùng tên, khác bản chất. Slide của bạn mô tả đúng cái thứ hai — "quét file, ghi nhận mỗi file có class/hàm gì và liên kết với file nào".

Nói rõ điểm này lại là lợi thế: cách của dự án rẻ và nhanh hơn nhiều vì không phải gọi LLM để dựng đồ thị.

20 Muốn nâng lên RAG đầy đủ thì cần làm gì?

Bốn việc, xếp theo thứ tự nên làm:

#	Việc	Quyết định phải chốt
1	Chọn mô hình embedding	Chạy nội bộ hay gọi API — quyết định này ràng buộc mọi thứ sau, và đổi về sau là phải index lại toàn bộ
2	Chia đoạn tài liệu	Cắt theo cấu trúc (mục, điều, hàm) trước khi cắt theo độ dài
3	Chọn nơi lưu vector	Quy mô hiện tại chỉ cần FAISS hoặc `pgvector`
4	Dựng bộ câu hỏi đánh giá	50–100 câu có đáp án đúng — làm trước khi tối ưu

Điểm mạnh sẵn có: dự án đã có sẵn khái niệm project với thư mục riêng và phân tách dữ liệu theo project. Đó chính là ranh giới phân quyền tự nhiên cho câu 17 — thứ mà nhiều dự án phải làm lại từ đầu.

Ba câu nên chuẩn bị sẵn câu trả lời

1. "RAG có hết bịa không?" → Không, chỉ giảm. Nói thẳng và nêu cách giảm: bắt trích nguồn, cho phép trả lời "không tìm thấy".

2. "GraphRAG này có phải GraphRAG kia không?" → Không, cùng tên khác bản chất. Chủ động nói trước khi bị hỏi.

3. "Vậy dự án đã có RAG chưa?" → Chưa đủ. Đang ở mức truy xuất theo cấu trúc, chưa có truy xuất theo ngữ nghĩa.