17Câu hỏi phỏng vấn#

17.1Cách trình bày câu trả lời#

Câu hỏi phỏng vấn cho vị trí kỹ sư AI thường xoay quanh ba nội dung: hiểu cơ chế, tức vì sao mô hình hành xử như vậy; thiết kế hệ thống, tức xây một ứng dụng cụ thể thế nào; và đánh giá, tức làm sao biết nó tốt. Một câu trả lời tốt nêu cơ chế, nêu đánh đổi giữa các lựa chọn, rồi nêu cách đo để biết lựa chọn nào đúng. Người phỏng vấn thường đánh giá cao việc chỉ ra điều gì cần đo trên dữ liệu thật hơn là khẳng định một phương pháp luôn tốt hơn. Một con số cụ thể, như các số liệu đo được trong giáo trình, làm câu trả lời thuyết phục hơn nhiều so với một nhận định chung.

17.2Mô hình ngôn ngữ lớn#

Câu hỏi: Vì sao cùng một nội dung, tiếng Việt tốn nhiều token hơn tiếng Anh?

Trả lời

Tokenizer được huấn luyện bằng BPE trên một kho văn bản, và chỉ những chuỗi phổ biến trong kho đó mới trở thành token riêng. Một tokenizer huấn luyện chủ yếu trên tiếng Anh hiếm khi gặp các ký tự có dấu của tiếng Việt, nên cắt chúng thành từng byte. Ở Mục 2.1, cùng một văn bản, bản tiếng Việt tốn gấp 4,8 lần bản tiếng Anh với tokenizer của GPT-2, nhưng chỉ 1,4 và 1,2 lần với Qwen2.5 và XLM-RoBERTa. Vì vậy chi phí, độ trễ và lượng nội dung chứa vừa ngữ cảnh của một ứng dụng tiếng Việt phải được tính bằng đúng tokenizer của từng mô hình.

Câu hỏi: Vì sao ngữ cảnh dài làm tăng chi phí và độ trễ?

Trả lời

Pha nạp ngữ cảnh phải xử lý mọi token đầu vào, và mỗi token phải lưu key và value của nó ở mọi lớp trong KV cache. Với Llama 3 8B, mỗi token tốn 128 KiB KV cache, nên 128 nghìn token tốn 16 GiB cho một chuỗi, xấp xỉ dung lượng trọng số của mô hình. Ngoài chi phí còn có vấn đề chất lượng: khả năng tìm và dùng thông tin giảm khi ngữ cảnh dài ra. Thí nghiệm ở Mục 5.3 cho thấy với một mô hình nhỏ, tỉ lệ tìm đúng dữ kiện giảm từ 0,90 xuống 0,66 khi ngữ cảnh tăng từ khoảng 1 000 lên 4 000 token.

Câu hỏi: Đặt temperature bằng 0 có làm kết quả hoàn toàn tất định không?

Trả lời

Không hẳn. Temperature bằng 0 luôn chọn token có xác suất cao nhất, nhưng trên máy chủ các yêu cầu được gộp thành lô, và phép cộng số thực dấu phẩy động không có tính kết hợp, nên logit có thể khác nhau rất nhỏ giữa các lần chạy. Khi hai token có xác suất gần bằng nhau, khác biệt đó đủ đổi token được chọn và kéo theo toàn bộ phần sau. Vì vậy việc đánh giá cần nhiều ví dụ hoặc nhiều lần chạy, và ứng dụng phải chịu được sự không tất định này.

Câu hỏi: Ảo giác là gì và giảm nó bằng cách nào?

Trả lời

Ảo giác là khi mô hình sinh ra nội dung trôi chảy nhưng sai sự thật. Nó xảy ra vì mô hình được huấn luyện để sinh văn bản có xác suất cao chứ không phải văn bản đúng. Có nhiều cách giảm: cung cấp tài liệu nguồn và yêu cầu trích dẫn như trong RAG, cho phép mô hình trả lời "không biết", kiểm tra đầu ra bằng một bước riêng hoặc bằng tool, dùng temperature thấp cho nhiệm vụ có đáp án, và đo tỉ lệ ảo giác trên bộ đánh giá. Không cách nào loại bỏ được hoàn toàn, nên thiết kế sản phẩm phải tính tới khả năng câu trả lời sai, chẳng hạn kèm trích dẫn để người dùng tự kiểm tra.

17.3Prompt và ngữ cảnh#

Câu hỏi: Khác biệt giữa prompt engineering và context engineering?

Trả lời

Prompt engineering là viết chỉ dẫn và ví dụ cho mô hình. Context engineering rộng hơn: quản lý toàn bộ những gì nằm trong cửa sổ ngữ cảnh ở mỗi lần gọi, gồm chỉ dẫn, định nghĩa tool, tài liệu truy xuất, kết quả tool, lịch sử và bộ nhớ, và quyết định thêm, bớt hay tóm tắt những gì khi ngữ cảnh đầy. Với một lời gọi đơn lẻ, hai việc gần như trùng nhau. Với agent chạy nhiều bước, ngữ cảnh thay đổi liên tục và phần do người viết prompt viết ra chỉ còn là một phần nhỏ, nên context engineering trở thành vấn đề chính.

Câu hỏi: Khi nào dùng few-shot, khi nào dùng chain-of-thought?

Trả lời

Few-shot có ích khi cần một định dạng, phong cách hoặc quy ước khó mô tả bằng lời. Ví dụ cần đa dạng, vì mô hình bắt chước cả những đặc điểm không mong muốn như độ dài hay tỉ lệ nhãn. Chain-of-thought có ích với bài toán nhiều bước như tính toán hay suy luận, vì nó cho mô hình thêm lượt tính và giữ kết quả trung gian trong ngữ cảnh; đổi lại nó tốn token đầu ra và tăng độ trễ, nên không nên dùng cho phân loại hay trích xuất đơn giản. Với mô hình suy luận, vốn tự sinh chuỗi suy luận, không cần yêu cầu "suy nghĩ từng bước".

Câu hỏi: Làm sao bảo đảm đầu ra luôn là JSON hợp lệ?

Trả lời

Có ba mức bảo đảm. Mức thấp nhất là mô tả định dạng và cho ví dụ trong prompt, không có bảo đảm gì. Mức thứ hai là kiểm tra đầu ra bằng lược đồ rồi thử lại kèm thông báo lỗi. Mức cao nhất là giải mã có ràng buộc, đặt xác suất bằng 0 cho token vi phạm ngữ pháp, nên bảo đảm cú pháp. Ngay cả mức cao nhất cũng không bảo đảm nội dung đúng, nên các ràng buộc nội dung vẫn cần kiểm tra bằng mã. Ép định dạng quá chặt còn có thể làm giảm chất lượng suy luận, và cách xử lý là thêm một trường giải thích đặt trước các trường kết luận.

Câu hỏi: Prompt caching hoạt động thế nào và cần lưu ý gì khi viết prompt?

Trả lời

Máy chủ lưu KV cache của phần tiền tố đã xử lý. Yêu cầu sau có cùng tiền tố thì dùng lại phần đó, nên thời gian tới token đầu tiên giảm và token đọc từ cache thường được tính giá thấp hơn. Cache chỉ trúng khi tiền tố giống hệt nhau tới từng token, vì vậy phần ổn định như chỉ dẫn, tool và ví dụ phải đặt ở đầu, phần thay đổi đặt ở cuối. Một dấu thời gian ở dòng đầu tiên của prompt đủ làm mất tác dụng của cache.

17.4Embedding và RAG#

Câu hỏi: Tìm kiếm bằng embedding có luôn tốt hơn BM25 không?

Trả lời

Không. Trên kho văn bản tiếng Việt ở Mục 6.5, multilingual-e5-small kém BM25 ở cả hai bộ truy vấn; ở bộ câu hỏi diễn đạt lại, tỉ lệ tìm đúng mục trong 5 kết quả đầu là 0,52 so với 0,60. Nguyên nhân là mô hình nhỏ, văn bản chuyên ngành, và 30,7% số mục dài hơn 512 token nên bị cắt khi mã hoá. BM25 mạnh khi thuật ngữ chuyên môn quyết định, embedding mạnh khi người hỏi dùng từ khác tài liệu, nên kết hợp hai cách bằng RRF cho kết quả tốt nhất ở truy vấn khó, 0,62. Kết luận chung là phải đo trên truy vấn thật, và tìm kiếm kết hợp thường là lựa chọn mặc định an toàn.

Câu hỏi: Chọn kích thước đoạn (chunk) thế nào?

Trả lời

Đoạn nhỏ cho truy xuất chính xác hơn về vị trí nhưng mất ngữ cảnh xung quanh; đoạn lớn giữ ngữ cảnh nhưng embedding bị loãng và có thể vượt độ dài tối đa của mô hình embedding. Nên chia theo cấu trúc tự nhiên của tài liệu, như mục và đoạn, trước khi chia theo số token, rồi chọn kích thước bằng thí nghiệm trên bộ truy vấn có nhãn. Ở Mục 8.3, trên kho văn bản của lộ trình, BM25 tốt nhất với đoạn khoảng 400 từ và kém nhất với đoạn 50 từ, còn kết hợp BM25 với e5-small bằng RRF tốt nhất khi dùng nguyên mục.

Câu hỏi: RAG hay fine-tuning?

Trả lời

Hai kỹ thuật giải quyết hai vấn đề khác nhau. RAG đưa kiến thức vào: tài liệu cập nhật được mà không cần huấn luyện lại, câu trả lời trích dẫn được nguồn, và quyền truy cập kiểm soát được theo từng tài liệu. Fine-tuning thay đổi hành vi: định dạng, giọng văn, cách làm một nhiệm vụ hẹp, hoặc giúp một mô hình nhỏ làm tốt một việc cụ thể. Hai cách có thể kết hợp. Dùng fine-tuning để đưa kiến thức mới vào mô hình thường kém hiệu quả hơn RAG (Ovadia và cộng sự, 2024).

Câu hỏi: Làm sao biết một câu trả lời sai của hệ thống RAG là lỗi truy xuất hay lỗi sinh?

Trả lời

Cần ghi lại các đoạn đã truy xuất cho mỗi yêu cầu. Nếu đoạn chứa đáp án không nằm trong ngữ cảnh, đó là lỗi truy xuất; nếu có mà câu trả lời vẫn sai hoặc bịa thêm, đó là lỗi sinh. Hai bước được đo riêng: recall@k cho truy xuất, độ trung thành của câu trả lời với ngữ cảnh cho bước sinh. Thí nghiệm ở Mục 8.5 dùng cách tách này và thấy cả hai loại lỗi. Khi truy xuất không đưa về đoạn nào thuộc đúng chương, độ chính xác giảm từ 0,59 khi không có ngữ cảnh xuống 0,28, tức ngữ cảnh sai kéo mô hình sai theo; còn khi ngữ cảnh đúng, mô hình 0,5 tỉ tham số vẫn chỉ đúng khoảng 54%.

17.5Agent và MCP#

Câu hỏi: Khi nào nên dùng agent thay vì workflow?

Trả lời

Nên dùng agent khi số bước và thứ tự bước không biết trước và phụ thuộc vào kết quả trung gian. Nếu các bước cố định, workflow dễ kiểm thử hơn, rẻ hơn và dễ dự đoán chi phí hơn. Agent hợp nhất với nhiệm vụ có kết quả kiểm tra được, như sửa mã có kiểm thử đi kèm, vì khi đó agent tự phát hiện được bước sai.

Câu hỏi: Vì sao agent nhiều bước khó đạt độ tin cậy cao?

Trả lời

Nếu mỗi bước đúng với xác suất $p$ và nhiệm vụ cần $n$ bước đều đúng, xác suất hoàn thành là $p^n$; 20 bước với $p = 0{,}95$ chỉ hoàn thành 36% số nhiệm vụ. Một bước kiểm tra phát hiện 80% lỗi kèm một lần thử lại nâng con số này lên 79%, trong khi số lời gọi chỉ tăng 4% (Mục 9.7). Yếu tố quyết định là tỉ lệ phát hiện lỗi, nên agent cần những tín hiệu kiểm tra khách quan như kiểm thử hay kiểm tra lược đồ.

Câu hỏi: Function calling hoạt động thế nào? Mô hình có tự gọi API không?

Trả lời

Ứng dụng mô tả các tool bằng tên, mô tả và JSON Schema. Mô hình trả về một lời gọi có cấu trúc gồm tên tool và tham số, rồi ứng dụng kiểm tra quyền, thực thi và đưa kết quả trở lại hội thoại. Mô hình không tự thực thi gì cả; mọi quyết định thực thi và kiểm soát quyền nằm ở ứng dụng.

Câu hỏi: MCP giải quyết vấn đề gì?

Trả lời

MCP chuẩn hoá cách ứng dụng AI kết nối với tool và dữ liệu, nhờ đó số tích hợp giảm từ $N \times M$ xuống $N + M$. Host chứa các client, mỗi client nối với một server; server cung cấp tools, resources và prompts qua JSON-RPC 2.0, truyền qua stdio hoặc Streamable HTTP. Server không đọc được toàn bộ hội thoại và không thấy server khác. Rủi ro chính là một server độc hại giấu chỉ dẫn trong mô tả tool, nên chỉ nên dùng server tin cậy, ghim phiên bản, và xin phép người dùng trước khi gọi tool.

17.6Đánh giá, vận hành và an toàn#

Câu hỏi: Bộ đánh giá cần bao nhiêu câu?

Trả lời

Tuỳ độ lớn của khác biệt cần phát hiện. Với độ chính xác khoảng 80%, 100 câu cho khoảng tin cậy rộng ±7,8 điểm phần trăm, 1 000 câu cho ±2,5. Để phát hiện một cải thiện 3 điểm phần trăm, 1 000 câu so sánh ghép cặp phát hiện được 92% số lần, còn hai bộ độc lập chỉ 41% (Mục 12.4). Vì vậy hai phiên bản luôn nên được so trên cùng một bộ câu hỏi, bằng kiểm định McNemar.

Câu hỏi: Dùng LLM làm giám khảo có đáng tin không?

Trả lời

Có điều kiện. Giám khảo mạnh đạt mức đồng thuận với chuyên gia trên 80%, ngang mức đồng thuận giữa các chuyên gia, nhưng có thiên lệch vị trí, thiên lệch độ dài và xu hướng tự đề cao. Để dùng được, cần đổi vị trí hai câu trả lời và chấm hai lần, dùng tiêu chí chi tiết, chấm từng tiêu chí riêng, và định kỳ so với nhãn do người gán. Với những tiêu chí kiểm tra được bằng mã, nên ưu tiên đánh giá tất định.

Câu hỏi: Prompt injection là gì và vì sao khó chống?

Trả lời

Prompt injection xảy ra khi văn bản đi vào ngữ cảnh chứa chỉ dẫn khiến mô hình làm theo kẻ tấn công thay vì theo ứng dụng; ở dạng gián tiếp, chỉ dẫn nằm trong dữ liệu như email, trang web hay tài liệu truy xuất. Nó khó chống vì mô hình không có cơ chế tách chỉ dẫn khỏi dữ liệu: mọi token đều là văn bản. Các cách phòng thủ ở tầng prompt có tác dụng tuỳ mô hình. Hines và cộng sự (2024) báo cáo spotlighting làm tỉ lệ tấn công thành công giảm từ trên 50% xuống dưới 2%, nhưng thí nghiệm ở Mục 11.2 với mô hình 0,5 tỉ tham số không thấy tác dụng nào, và cách kẹp chỉ dẫn hai đầu còn làm tình hình tệ hơn. Vì vậy phòng thủ chính phải nằm ở kiến trúc: quyền tối thiểu cho tool, xin phép người dùng trước hành động có tác dụng phụ, và không để một agent vừa đọc dữ liệu không tin cậy vừa có quyền gửi dữ liệu ra ngoài.

Câu hỏi: Cần ghi lại gì để gỡ lỗi một ứng dụng LLM trong sản xuất?

Trả lời

Cần trace của mỗi yêu cầu, gồm đầu vào đầy đủ đã gửi cho mô hình chứ không chỉ câu hỏi, phiên bản mô hình và prompt, các tài liệu truy xuất, các lời gọi tool kèm kết quả, số token, chi phí, thời gian của từng bước và phản hồi của người dùng. Không có đầu vào đầy đủ thì không tái tạo được lỗi. Vì log chứa dữ liệu của người dùng, nó phải được bảo vệ như dữ liệu nhạy cảm.

17.7Các câu trả lời chưa đạt#

Bảng dưới gom những câu trả lời nghe hợp lý nhưng chưa đạt, thường gặp khi phỏng vấn, cùng lý do.