Skip to main content

AI Engineering by Chip Huyen: Tóm tắt toàn bộ cuốn sách

Cập nhật: 2026-07-21

Mục lục​

1. AI Engineering là gì?​

Mức lương cho vị trí AI Engineer có thể lên tới 300.000 USD trở lên — một trong những lĩnh vực kỹ thuật phát triển nhanh nhất hiện nay. Bài viết này tóm tắt cuốn sách AI Engineering của Chip Huyen, 800 trang nội dung về đúng lĩnh vực đó. Đây là bản tóm tắt tổng quan ở mức cao (high-level) của một cuốn sách kỹ thuật rất chi tiết, nên không kỳ vọng học được hết mọi chi tiết chỉ qua bài viết này — hãy dùng nó như điểm khởi đầu để tự nghiên cứu sâu hơn.

AI Engineering đã bùng nổ gần đây vì hai lý do đơn giản: các mô hình AI đã trở nên tốt hơn đáng kể trong việc giải quyết các vấn đề thực tế, trong khi rào cản để xây dựng ứng dụng với chúng lại thấp hơn nhiều. Sự kết hợp này đã tạo ra một trong những ngành kỹ thuật phát triển nhanh nhất hiện nay.

Về bản chất, AI Engineering là việc xây dựng ứng dụng trên nền các foundation models — những hệ thống AI khổng lồ được huấn luyện bởi các công ty như OpenAI hay Google. Khác với các kỹ sư machine learning truyền thống (xây dựng mô hình từ đầu), AI Engineer tận dụng các mô hình có sẵn, tập trung ít hơn vào việc huấn luyện và nhiều hơn vào việc thích ứng (adaptation) các mô hình đó.

Các foundation model này hoạt động qua một quá trình gọi là self-supervision: thay vì cần con người gán nhãn dữ liệu một cách vất vả, mô hình có thể học bằng cách dự đoán các phần trong chính dữ liệu đầu vào của nó. Đột phá này đã giải quyết nút thắt cổ chai về gán nhãn dữ liệu vốn kìm hãm AI trong nhiều năm. Khi các mô hình này được mở rộng quy mô (scale) với nhiều dữ liệu và sức mạnh tính toán hơn, chúng tiến hóa từ các mô hình ngôn ngữ đơn giản thành large language models (LLM), và không dừng lại ở đó — chúng còn mở rộng để xử lý nhiều loại dữ liệu khác nhau bao gồm hình ảnh và video, thường được gọi là large multimodal models.

Ngày nay, foundation model đang vận hành mọi thứ từ trợ lý lập trình (như GitHub Copilot), công cụ tạo ảnh, công cụ hỗ trợ viết, chatbot hỗ trợ khách hàng, cho đến các hệ thống phân tích dữ liệu tinh vi.

2. Foundation Models​

Dữ liệu huấn luyện​

Foundation model về bản chất chỉ biết những gì chúng đã được huấn luyện. Điều này có vẻ hiển nhiên nhưng lại có hệ quả sâu sắc: nếu một mô hình chưa từng thấy ví dụ về một ngôn ngữ hay khái niệm cụ thể nào trong quá trình huấn luyện, nó đơn giản là không có kiến thức đó.

Hầu hết các foundation model lớn được huấn luyện trên dữ liệu crawl từ web, điều này mang theo một số vấn đề cố hữu: dữ liệu này thường chứa clickbait, thông tin sai lệch, nội dung độc hại và tin giả. Để đối phó, các đội ngũ sử dụng nhiều kỹ thuật lọc khác nhau — ví dụ, OpenAI chỉ sử dụng các link Reddit có ít nhất 3 karma khi huấn luyện GPT-2 (tập dữ liệu WebText).

Phân bố ngôn ngữ trong dữ liệu huấn luyện cũng bị lệch nặng: khoảng 45–46% dữ liệu crawl là tiếng Anh, nghĩa là các ngôn ngữ có hàng triệu người nói vẫn bị đại diện thiếu (underrepresented). Đây là lý do các mô hình chuyên biệt cho ngôn ngữ và lĩnh vực cụ thể ngày càng trở nên quan trọng. Phân bố các domain trong một trong những tập dữ liệu huấn luyện chính cũng nghiêng nặng về mảng kinh doanh, công nghệ, tin tức và nghệ thuật.

Kiến trúc Transformer​

Hầu hết foundation model dùng kiến trúc Transformer, dựa trên cơ chế attention. Để hiểu vì sao Transformer là một bước đột phá, cần nhìn lại những gì đã có trước đó.

Transformer được phát minh để giải quyết vấn đề của các mô hình sequence-to-sequence dùng recurrent neural network (RNN) cho các tác vụ như dịch thuật. Các mô hình này có hai thành phần chính: một encoder xử lý đầu vào và một decoder sinh đầu ra, cả hai đều hoạt động tuần tự theo từng token. Vấn đề là decoder chỉ có quyền truy cập vào một biểu diễn nén (compressed representation) của toàn bộ đầu vào.

💡 Hình dung: Giống như việc cố gắng trả lời các câu hỏi chi tiết về một cuốn sách khi tất cả những gì bạn có chỉ là một bản tóm tắt ngắn.

Ngoài ra, việc xử lý đầu vào và sinh đầu ra được thực hiện tuần tự nên rất chậm với các chuỗi dài. Transformer giải quyết vấn đề này bằng cơ chế attention, cho phép mô hình "cân" (weigh) mức độ quan trọng của các token đầu vào khác nhau khi sinh ra mỗi token đầu ra.

💡 Hình dung: Giống như có thể tham chiếu tới bất kỳ trang nào trong cuốn sách khi trả lời câu hỏi, thay vì chỉ dựa vào bản tóm tắt.

Thêm vào đó, Transformer có thể xử lý các token đầu vào song song, giúp nó nhanh hơn nhiều trong quá trình inference. Transformer hoạt động theo hai bước: đầu tiên là pre-fill — xử lý song song tất cả token đầu vào để tạo trạng thái trung gian; thứ hai là decode — sinh từng token đầu ra một.

Cơ chế attention sử dụng ba loại vector: query vector (đại diện cho thông tin mô hình đang tìm kiếm), key vector (giống như chỉ mục của các token trước đó), và value vector (nội dung thực tế của các token trước đó). Mô hình tính toán mức độ chú ý dành cho mỗi token đầu vào bằng cách so sánh vector Q và K — điểm tương đồng cao nghĩa là nội dung V của token đó sẽ ảnh hưởng mạnh đến đầu ra. Đây là lý do context window dài hơn tốn kém tính toán hơn: nhiều token hơn đồng nghĩa nhiều vector K và V hơn cần tính toán và lưu trữ.

Attention hầu như luôn là multi-headed, cho phép mô hình tập trung vào các nhóm token khác nhau cùng lúc — ví dụ Llama 2 7B có 32 attention head. Một Transformer hoàn chỉnh gồm nhiều Transformer block, mỗi block chứa một attention module và một neural network module. Số lượng block thường được gọi là số layer. Trước và sau mỗi block có một embedding module chuyển đổi token và vị trí của chúng thành vector, và cuối cùng là một unembedding layer ánh xạ vector đầu ra thành xác suất token.

Transformer Attention FlowInput TokensQuery (Q)Key (K)Value (V)Attention Score = softmax(Q · Kᵀ / √d)Weighted Sum = Score · VNext-token Probability DistributionMulti-head: repeated in parallel across N heads (e.g. Llama 2 7B: 32 heads)Pre-fill: all input tokens processed in parallel · Decode: one output token at a time

Bên cạnh Transformer, các kiến trúc khác như RW-KV (kết hợp cách tiếp cận dựa trên RNN với khả năng song song hóa) cũng đang dần được chú ý cho một số ứng dụng nhất định.

Scaling laws và các giới hạn​

Nhìn chung, mô hình càng lớn (nhiều tham số hơn) càng có khả năng học và hoạt động tốt hơn. Số lượng tham số giúp ước tính tài nguyên tính toán cần cho huấn luyện và inference. Tuy nhiên, số lượng tham số có thể gây hiểu lầm với các mô hình sparse (thưa, có nhiều giá trị bằng 0) — một mô hình sparse lớn có thể cần ít tính toán hơn một mô hình dense nhỏ hơn.

Khi thiết kế mô hình, compute (tài nguyên tính toán) thường là yếu tố giới hạn. Chinchilla scaling law giúp tính toán kích thước mô hình và dữ liệu tối ưu cho một ngân sách compute cho trước — nó gợi ý số token huấn luyện nên gấp khoảng 20 lần kích thước mô hình (một mô hình 3 tỷ tham số cần khoảng 60 tỷ token huấn luyện).

Trong khi chi phí để đạt cùng một mức hiệu năng đang giảm dần theo thời gian, chi phí để cải thiện thêm vẫn rất cao — đi từ tỷ lệ lỗi 3% xuống 2% có thể cần một bậc độ lớn dữ liệu, compute hoặc năng lượng nhiều hơn. Nhưng ngay cả những cải thiện hiệu năng nhỏ cũng có thể tạo khác biệt lớn cho các ứng dụng downstream.

Khi tiếp tục scale mô hình, chúng ta đang tiến gần tới hai nút thắt cổ chai đáng kể: thứ nhất là dữ liệu huấn luyện — có lo ngại rằng dữ liệu internet chất lượng cao sẽ cạn kiệt trong vài năm tới, buộc mô hình phải huấn luyện trên nội dung do AI tạo ra, có thể gây suy giảm hiệu năng, hoặc phải cần đến dữ liệu độc quyền như sách có bản quyền hay hồ sơ y tế. Thứ hai là điện năng — các trung tâm dữ liệu đã tiêu thụ khoảng 1,5% điện năng toàn cầu và con số này đang tăng nhanh hơn nhiều lần so với tổng nhu cầu điện, giới hạn khả năng phát triển lớn hơn nếu không có đột phá về năng lượng.

Post-training​

Foundation model đã pre-train gặp hai vấn đề chính: chúng được tối ưu cho việc hoàn thành văn bản (text completion) chứ không phải hội thoại, và đầu ra của chúng có thể sai về mặt sự thật hoặc có vấn đề về đạo đức. Post-training nhằm giải quyết các vấn đề này qua hai bước chính:

  1. Supervised fine-tuning (SFT): tối ưu mô hình cho hội thoại thay vì hoàn thành câu. Điều này cần dữ liệu instruction chất lượng cao, cho thấy các loại yêu cầu mô hình nên xử lý và cách phản hồi — về cơ bản là dạy mô hình biết thế nào là một câu trả lời tốt.
  2. Preference fine-tuning: căn chỉnh mô hình theo giá trị con người bằng reinforcement learning, thường gọi là RLHF (reinforcement learning from human feedback). Việc này liên quan đến huấn luyện một reward model chấm điểm đầu ra dựa trên sở thích của con người, rồi tối ưu foundation model để sinh ra các phản hồi tối đa hóa điểm số này.

RLHF là cách tiếp cận tiêu chuẩn, nhưng các phương pháp mới hơn như DPO (direct preference optimization) đang ngày càng được ưa chuộng. Một số công ty thậm chí bỏ qua hoàn toàn bước reinforcement learning, thay vào đó sinh nhiều đầu ra và chọn ra những đầu ra có điểm reward model cao — chiến lược này gọi là best of N.

Sampling — Lấy mẫu đầu ra​

Foundation model không chỉ sinh ra một câu trả lời duy nhất — chúng sinh ra xác suất cho các đầu ra khả dĩ. Cách chúng ta lấy mẫu (sample) từ các xác suất này ảnh hưởng mạnh đến phản hồi của mô hình. Cách đơn giản nhất là greedy sampling — luôn chọn token có xác suất cao nhất, nhưng điều này dẫn đến văn bản lặp lại và dễ đoán.

Để tạo tính sáng tạo, các kỹ thuật sampling khác được dùng:

  • Temperature: kiểm soát mức độ "tự tin" của mô hình trong dự đoán. Giá trị temperature cao (0.7–1) làm đầu ra sáng tạo hơn nhưng có thể kém chính xác hơn; nhiệt độ thấp gần 0 làm đầu ra xác định và tập trung hơn.
  • Top-K sampling: giới hạn mô hình chỉ chọn trong K token có xác suất cao nhất (thường từ 50 đến 500), tùy vào mức độ đa dạng mong muốn.
  • Top-P sampling: chọn tập hợp nhỏ nhất các token có tổng xác suất cộng dồn vượt ngưỡng P — giá trị 0.9 nghĩa là mô hình chỉ xét các token chiếm 90% khối xác suất.

Bản chất xác suất này giải thích nhiều hành vi ta thấy ở foundation model, như sự không nhất quán khi thay đổi nhỏ ở đầu vào, và hallucination — khi mô hình khẳng định tự tin những thông tin sai.

3. Evaluation — Đánh giá mô hình AI​

Nhưng làm sao biết một mô hình đã chọn thực sự tốt? Đối với một số ứng dụng, việc tìm ra cách đánh giá (evaluation) có thể tiêu tốn phần lớn công sức phát triển. Đây là cách để giảm thiểu rủi ro, phát hiện cơ hội, và có cái nhìn rõ về nơi hệ thống đang thất bại.

Đánh giá hệ thống AI khó hơn đáng kể so với các mô hình ML truyền thống vì nhiều lý do:

  1. Các bài toán mà mô hình giải quyết thường vốn dĩ phức tạp — đánh giá một chứng minh toán học hay chất lượng một bản tóm tắt đòi hỏi chuyên môn sâu.
  2. Tác vụ thường mở (open-ended) với nhiều phản hồi đúng khả dĩ — không như phân loại (classification) chỉ có một đáp án đúng.
  3. Foundation model là hộp đen (black box) — chỉ có thể đánh giá qua việc quan sát đầu ra, không thể hiểu cơ chế nội tại.
  4. Các benchmark đánh giá công khai nhanh chóng bị bão hòa (saturated) — khi mô hình đạt điểm tuyệt đối, bài kiểm tra khó hôm qua trở thành bài dễ hôm nay.
  5. Với các mô hình đa dụng (general purpose), cần đánh giá không chỉ các tác vụ đã biết mà còn phải khám phá các năng lực mới, có thể vượt ngoài khả năng con người.

Tất cả điều này còn trầm trọng hơn do sự đầu tư dưới mức (underinvestment) vào evaluation so với phát triển mô hình.

Các metric cơ bản​

Hầu hết các mô hình ngôn ngữ autoregressive được huấn luyện dùng cross entropy hoặc phiên bản tương đối là perplexity — các metric này đo lường mức độ mô hình dự đoán tốt token tiếp theo trong một chuỗi. Entropy đo lượng thông tin trung bình mà một token mang lại — entropy càng cao, mỗi token càng chứa nhiều thông tin và ngôn ngữ càng khó đoán. Một mô hình được huấn luyện hoàn hảo sẽ đạt cross entropy bằng đúng entropy của dữ liệu huấn luyện, và KL divergence giữa hai giá trị này sẽ bằng 0.

Perplexity đơn giản là hàm mũ của cross entropy, đo lượng bất định của mô hình khi dự đoán token tiếp theo. Perplexity tốt thế nào phụ thuộc hoàn toàn vào dữ liệu: dữ liệu có cấu trúc hơn có perplexity kỳ vọng thấp hơn vì dễ đoán hơn; từ vựng càng lớn thì perplexity càng cao; context length càng dài thì perplexity có xu hướng càng thấp.

Perplexity hữu ích để định hướng huấn luyện và là proxy cho năng lực tổng quát của mô hình, nhưng kém tin cậy hơn với các mô hình đã trải qua post-training đáng kể (SFT hoặc RLHF). Perplexity cũng có thể dùng để phát hiện liệu một văn bản có nằm trong dữ liệu huấn luyện hay không (vì mô hình sẽ dự đoán tốt bất thường), và để nhận diện văn bản vô nghĩa (perplexity cao bất thường).

Các phương pháp đánh giá​

Với một số tác vụ, ta có thể thực hiện exact evaluation — không có sự mơ hồ về đáp án đúng (như câu hỏi trắc nghiệm), khác với subjective evaluation như chấm điểm một bài luận. Tiêu chuẩn vàng ở đây là functional correctness — đánh giá xem hệ thống có thực hiện đúng chức năng dự kiến hay không (ví dụ: đặt bàn nhà hàng có đúng không). Với các tác vụ coding, functional correctness chuyển thành execution accuracy — code có chạy và cho ra kết quả đúng như mong đợi không.

Khi có sẵn dữ liệu tham chiếu (reference data), có thể đánh giá đầu ra bằng cách so sánh độ tương đồng với ground truth theo ba cách chính:

  1. Exact match: đo lường nhị phân, phù hợp câu hỏi đơn giản có đáp án dứt khoát.
  2. Lexical similarity: đo lường liên tục về mức độ trùng lặp token giữa đầu ra và tham chiếu, dùng kỹ thuật như edit distance hoặc n-gram overlap (BLEU, ROUGE). Nhược điểm là cần một tập tham chiếu toàn diện, và bản thân tham chiếu cũng có thể sai.
  3. Semantic similarity: đo lường liên tục về việc hai văn bản có cùng ý nghĩa hay không, thường bằng cách so sánh text embedding qua cosine similarity. Ưu điểm là không cần tham chiếu, nhưng phụ thuộc chất lượng của thuật toán embedding.

AI làm giám khảo (AI as a judge)​

Một trong những phương pháp mạnh và phổ biến nhất để đánh giá mô hình AI trong production là dùng một mô hình AI khác làm giám khảo.

💡 Hình dung: AI judge giống như thuê một giám khảo cho cuộc thi nấu ăn — nhanh và rẻ hơn nhiều so với mời cả một ban giám khảo con người, nhưng vẫn có thể thiên vị món ăn trông quen mắt (self-bias) hoặc món được nếm trước (position bias).

Các "AI judge" này nhanh, dễ dùng, và tương đối rẻ so với con người đánh giá — chúng có thể hoạt động mà không cần dữ liệu tham chiếu, và có thể đánh giá các thuộc tính như tính đúng đắn, độc hại, hallucination, v.v. Các nghiên cứu cho thấy AI judge có thể tương quan mạnh với đánh giá của con người, đôi khi còn có độ đồng thuận cao hơn giữa các giám khảo con người khác nhau.

Vì mô hình ngôn ngữ thường giỏi với văn bản hơn là con số, AI judge có xu hướng hoạt động tốt hơn với tác vụ phân loại hơn là chấm điểm số. Khi tạo prompt cho AI judge, cần bao gồm: nhiệm vụ đánh giá, tiêu chí và hệ thống chấm điểm, và few-shot example (thường hiệu quả hơn zero-shot). Đáng chú ý, không phải lúc nào cũng cần mô hình mạnh nhất làm giám khảo — các mô hình nhỏ chuyên biệt cũng có thể thực hiện tốt việc đánh giá, giúp giảm chi phí và độ trễ.

Tuy nhiên AI judge có giới hạn: chúng có tính xác suất — cùng một judge với cùng đầu vào có thể cho điểm khác nhau nếu prompt khác đi hoặc chỉ đơn giản chạy lại lần nữa. Metric cũng không được chuẩn hóa giữa các hệ thống khác nhau. Mô hình cũng thể hiện các bias: self-bias (ưu tiên phản hồi từ cùng một mô hình), position bias (ưu tiên câu trả lời đầu tiên trong so sánh), và verbosity bias (ưu tiên câu trả lời dài hơn). Có thể giảm thiểu các bias này bằng kỹ thuật như ngẫu nhiên hóa thứ tự phản hồi, dù việc này cũng làm tăng chi phí.

Xây dựng pipeline đánh giá​

Sau khi thu hẹp các mô hình ứng viên, cần một pipeline đánh giá vững chắc: đánh giá cả đầu ra end-to-end lẫn từng thành phần trung gian độc lập. Có thể dùng turn-based evaluation (đánh giá chất lượng từng đầu ra) và task-based evaluation (đo lường liệu hệ thống có hoàn thành tác vụ và mất bao nhiêu lượt).

Đầu tiên hãy nghĩ về điều gì tạo nên một phản hồi tốt — các yếu tố như tính liên quan, tính nhất quán về sự thật, và tính an toàn. Sau đó tạo các câu truy vấn kiểm thử và sinh nhiều phản hồi để xem mô hình hoạt động ra sao. Phát triển rubric chi tiết với ví dụ cho hệ thống chấm điểm — điều quan trọng là làm cho rubric rõ ràng, không mơ hồ để người đánh giá con người có thể áp dụng nhất quán.

Quan trọng nhất: gắn các metric đánh giá với metric kinh doanh. Nếu chatbot hỗ trợ khách hàng đạt 80% tính nhất quán sự thật, điều đó có ý nghĩa gì cho business? Có thể tự động hóa 30% yêu cầu ở mức đó, nhưng ở mức 90% có thể tự động hóa 50%. Điều này giúp định lượng tác động kinh doanh của các cải tiến mô hình. Cần thiết lập một ngưỡng hữu ích (usefulness threshold) — ví dụ chatbot phải đạt 90% tính nhất quán sự thật mới khả thi để đưa vào production.

Các tiêu chí khác nhau có thể cần phương pháp đánh giá khác nhau — có thể dùng classifier độc hại chuyên biệt, semantic similarity để đo tính liên quan, và AI judge để đánh giá tính nhất quán sự thật. Có thể trộn nhiều phương pháp cho cùng một tiêu chí, ví dụ dùng classifier rẻ trên toàn bộ dữ liệu và AI judge đắt tiền chỉ trên 1% dữ liệu để lấy tín hiệu chất lượng cao. Dù automated metric ưu tiên hơn cho quy mô lớn, đừng ngần ngại đưa human evaluation vào ngay cả trong production — chỉ cần làm trên một tập con dữ liệu để giữ chi phí hợp lý.

Cũng cần đánh giá ứng dụng trên các lát cắt (slice) dữ liệu hoặc người dùng khác nhau để đảm bảo hiệu năng đồng đều và tránh bias — giúp tránh Simpson's Paradox, khi mô hình hoạt động tốt hơn ở mức tổng hợp nhưng tệ hơn ở từng phân khúc riêng lẻ.

Một cách tốt để kiểm tra độ tin cậy là tạo nhiều mẫu bootstrap từ tập đánh giá và xem chúng có cho kết quả tương tự không — nếu một bootstrap cho 90% nhưng bootstrap khác cho 70%, pipeline đánh giá không đáng tin cậy. Cuối cùng, cần đánh giá độ tin cậy của chính pipeline: tín hiệu có đúng không (phản hồi tốt hơn có được điểm cao hơn không), metric đánh giá tốt hơn có dẫn tới kết quả kinh doanh tốt hơn không, pipeline có ổn định không (chạy lại có ra cùng kết quả không), các metric có tương quan với nhau ra sao, và cuối cùng là chi phí/độ trễ mà pipeline đánh giá thêm vào cho ứng dụng.

4. Model Selection — Lựa chọn mô hình​

Với số lượng foundation model sẵn có ngày càng tăng, thách thức không còn là phát triển mô hình mà là chọn đúng mô hình cho ứng dụng. Trong quá trình phát triển ứng dụng, việc chọn mô hình sẽ diễn ra nhiều lần khi bạn tiến qua các kỹ thuật thích ứng khác nhau — ví dụ khi làm prompt engineering, có thể bắt đầu với mô hình mạnh nhất để đánh giá tính khả thi, rồi lùi lại để xem mô hình nhỏ hơn có đủ dùng không.

Quá trình chọn lựa gồm hai bước chính: (1) tìm hiệu năng tốt nhất có thể đạt được cho tác vụ, và (2) ánh xạ các mô hình trên trục chi phí-hiệu năng và chọn mô hình cho hiệu năng tốt nhất trong ngân sách.

Tiêu chí đánh giá mô hình có thể chia thành bốn nhóm:

  1. Khả năng chuyên biệt theo domain — mô hình hiểu domain cụ thể của bạn tốt đến đâu (ví dụ: thuật ngữ pháp lý nếu tóm tắt văn bản pháp lý).
  2. Khả năng tổng quát — đầu ra mạch lạc, trung thực, nhất quán về sự thật đến đâu.
  3. Khả năng tuân theo chỉ dẫn (instruction following) — mô hình có tuân theo định dạng và cấu trúc yêu cầu không.
  4. Chi phí và độ trễ — mô hình tốn kém thế nào để chạy và phản hồi nhanh ra sao.

Khi đánh giá mô hình, cần phân biệt giữa hard attribute và soft attribute. Hard attribute là những thứ không thể hoặc khó thay đổi — như giới hạn giấy phép, thành phần dữ liệu huấn luyện, kích thước mô hình, yêu cầu về quyền riêng tư và mức độ kiểm soát cần có; những yếu tố này thường do nhà cung cấp mô hình hoặc chính sách nội bộ quyết định, và có thể giới hạn đáng kể phạm vi lựa chọn. Soft attribute có thể được cải thiện qua các kỹ thuật thích ứng như prompt engineering hoặc fine-tuning — bao gồm những thứ như độ chính xác, độc hại, và tính nhất quán sự thật.

💡 Hình dung: Hard attribute giống chiều cao khi tuyển cầu thủ bóng rổ — gần như không thể luyện tập để thay đổi. Soft attribute giống kỹ thuật ném bóng — có thể rèn giũa thêm (qua prompt engineering hoặc fine-tuning) để cải thiện.

Quy trình chọn mô hình ở mức cao: (1) lọc bỏ các mô hình có hard attribute không phù hợp, (2) dùng thông tin công khai như hiệu năng benchmark để thu hẹp về các ứng viên tiềm năng nhất, (3) chạy thử nghiệm riêng để tìm mô hình tốt nhất theo mọi mục tiêu của bạn, (4) liên tục giám sát mô hình đã chọn trong production để phát hiện lỗi và thu thập feedback.

Model API vs. tự host mô hình​

Vì hầu hết công ty sẽ không xây foundation model từ đầu, câu hỏi tiếp theo là dùng model API thương mại hay tự host mô hình mã nguồn mở. Về thuật ngữ: ban đầu "open source" nghĩa là bất kỳ mô hình nào có thể tải về và dùng, nhưng một số cho rằng mô hình chỉ nên được coi là open source thực sự nếu dữ liệu huấn luyện cũng công khai. Mô hình có weight mở nhưng dữ liệu huấn luyện đóng đôi khi được gọi là open weight model; những mô hình có cả weight và dữ liệu mở là open model. Vậy nên hầu hết cái gọi là "mô hình mã nguồn mở" thực ra chỉ là open weight.

Việc tự host hay dùng model API phụ thuộc vào một số yếu tố:

  • Quyền riêng tư dữ liệu: nếu công ty có chính sách nghiêm ngặt ngăn gửi dữ liệu ra ngoài, model API bên ngoài không phải là lựa chọn. Cũng có rủi ro nhà cung cấp API dùng dữ liệu của bạn để huấn luyện mô hình của họ.
  • Nguồn gốc dữ liệu và bản quyền: hầu hết mô hình không minh bạch về dữ liệu huấn luyện, và luật sở hữu trí tuệ quanh AI vẫn đang phát triển.
  • Hiệu năng: khoảng cách giữa mô hình mã nguồn mở và độc quyền đang thu hẹp, nhưng các mô hình mạnh nhất nhiều khả năng vẫn sẽ ở dạng độc quyền. Commercial API thường cung cấp thêm các năng lực sẵn có như khả năng mở rộng, function calling, structured output, và output guardrail — những thứ khó tự triển khai.
  • Kiểm soát: điều gì xảy ra nếu nhà cung cấp API ngừng hoạt động, thay đổi điều khoản dịch vụ, hoặc bị cấm ở một số khu vực? Nếu muốn chạy mô hình on-device, API bên thứ ba không phải là lựa chọn.

Nên thiết kế ứng dụng với một internal API chuẩn hóa để dễ dàng đổi mô hình khi cần.

Benchmark và pipeline đánh giá​

Một công cụ giúp đánh giá mô hình trên nhiều benchmark được gọi là evaluation harness (ví dụ OpenAI Evals cho phép chạy khoảng 500 benchmark có sẵn). Khi dùng public leaderboard, cần cân nhắc benchmark nào đưa vào bảng xếp hạng tổng hợp, cách cân trọng số các benchmark khác nhau, và cách xử lý các benchmark dùng metric khác nhau (accuracy, F1, BLEU...). Mục tiêu là chọn ra một tập nhỏ mô hình để kiểm thử kỹ hơn với benchmark và metric riêng của bạn — vì public benchmark hiếm khi phản ánh đúng nhu cầu ứng dụng, và có thể bị data contamination (khi mô hình được huấn luyện trên chính dữ liệu dùng để đánh giá nó). Để phát hiện contamination, có thể dùng heuristic như n-gram overlap và perplexity — nếu perplexity trên dữ liệu đánh giá thấp bất thường, có khả năng mô hình đã thấy dữ liệu này khi huấn luyện.

5. Prompt Engineering​

Nếu đã từng dùng ChatGPT, bạn đã thực hiện một dạng prompt engineering. Nhưng còn nhiều hơn thế chứ không chỉ là gõ câu hỏi. Prompt engineering là quá trình soạn thảo chỉ dẫn để hướng mô hình sinh ra kết quả mong muốn. Đây là kỹ thuật thích ứng mô hình dễ tiếp cận và phổ biến nhất vì khác với fine-tuning, nó không thay đổi trọng số của mô hình — bạn chỉ đơn giản nói cho mô hình biết bạn muốn nó làm gì.

Dù là điểm khởi đầu dễ tiếp cận nhất của AI Engineering, đừng nhầm tưởng nó đơn giản — prompt engineering hiệu quả đòi hỏi sự nghiêm ngặt thử nghiệm tương tự bất kỳ tác vụ machine learning nào. Nên khai thác tối đa giá trị từ prompting trước khi chuyển sang các kỹ thuật tốn nhiều tài nguyên hơn như fine-tuning. Tuy nhiên, chỉ hiểu prompt engineering thôi là chưa đủ cho hệ thống sẵn sàng production — vẫn cần kiến thức về thống kê, kỹ thuật và ML cổ điển cho việc theo dõi thử nghiệm, đánh giá và xây dựng bộ dữ liệu.

Thành phần của một prompt​

Prompt thường gồm một hoặc nhiều thành phần sau:

  1. Mô tả tác vụ (task description): bao gồm vai trò của mô hình và định dạng đầu ra mong đợi (ví dụ: "bạn là trợ lý y tế hữu ích, phân tích các triệu chứng sau và đề xuất các tình trạng có thể xảy ra, liệt kê theo thứ tự khả năng").
  2. Ví dụ (examples): cho mô hình thấy cách thực hiện tác vụ (ví dụ để phân loại văn bản độc hại hay không, có thể đưa ví dụ của mỗi loại).
  3. Tác vụ cụ thể (concrete task): công việc cụ thể muốn mô hình thực hiện, như trả lời câu hỏi hoặc tóm tắt một cuốn sách.

Một prompt hoàn chỉnh kết hợp cả ba thành phần trên có thể trông như thế này (system prompt chứa mô tả tác vụ + persona, user prompt chứa tác vụ cụ thể):

[SYSTEM PROMPT]
Bạn là một trợ lý y tế hữu ích, giàu kinh nghiệm.
Nhiệm vụ: phân tích triệu chứng người dùng mô tả và liệt kê các tình trạng
có thể xảy ra, theo thứ tự khả năng giảm dần.
Định dạng đầu ra: JSON với 2 field "conditions" (mảng string) và "confidence" (mảng số 0-1).
Không đưa ra chẩn đoán chắc chắn, luôn khuyến nghị gặp bác sĩ nếu triệu chứng nghiêm trọng.

[USER PROMPT]
Tôi bị đau đầu 3 ngày liên tục, kèm sốt nhẹ và cứng cổ.

Ví dụ này minh họa rõ 3 chiến lược đã nêu ở trên: chỉ dẫn rõ ràng (định dạng JSON cụ thể), persona (trợ lý y tế giàu kinh nghiệm), và ràng buộc an toàn (không chẩn đoán chắc chắn).

Lượng prompt engineering cần thiết phụ thuộc vào độ ổn định (robustness) của mô hình trước nhiễu loạn prompt (prompt perturbation) — một mô hình mạnh mẽ không nên sinh ra đầu ra khác biệt lớn nếu bạn viết số "5" thay vì đánh vần "FIVE". Độ ổn định này tương quan chặt với năng lực tổng thể của mô hình. Các mô hình khác nhau cũng có cấu trúc prompt ưa thích khác nhau — ví dụ GPT-4 thường hoạt động tốt hơn khi mô tả tác vụ ở đầu prompt, còn Llama 3 lại tốt hơn khi tác vụ ở cuối.

Việc dạy mô hình làm gì qua prompt được gọi là in-context learning. Mỗi ví dụ trong prompt được gọi là một shot, từ đó có các thuật ngữ few-shot, zero-shot và one-shot learning. Số lượng ví dụ cần thiết phụ thuộc cả vào mô hình lẫn ứng dụng, nên cần thử nghiệm. Số ví dụ có thể đưa vào bị giới hạn bởi context length của mô hình và (với model API) bởi ràng buộc chi phí.

Nhiều mô hình hiện đại phân biệt giữa system prompt và user prompt. System prompt chứa mô tả tác vụ, cho mô hình biết vai trò, mục tiêu và ràng buộc của nó — thường do nhà phát triển ứng dụng tạo ra chứ không phải người dùng cuối. User prompt chứa tác vụ hoặc truy vấn cụ thể. Hai loại prompt này được kết hợp dùng một template có thể khác nhau giữa các mô hình và phiên bản — nếu dùng sai template, có thể gặp vấn đề hiệu năng không mong đợi; ngay cả lỗi nhỏ như một dòng mới (newline) thừa cũng có thể gây vấn đề. Cần tuân theo đúng chat template của mô hình, đặc biệt khi dùng công cụ bên thứ ba để dựng prompt, vì sự không khớp template thường dẫn tới lỗi âm thầm (silent failure).

Mô hình thường hiểu chỉ dẫn tốt hơn khi chúng xuất hiện ở đầu hoặc cuối prompt, thay vì bị chôn ở giữa.

Các chiến lược prompt engineering hiệu quả​

  1. Viết chỉ dẫn rõ ràng và tường minh: nếu muốn mô hình chấm điểm một bài luận, giải thích rõ hệ thống chấm điểm — có cho phép điểm lẻ không, mô hình nên làm gì nếu không xác định được đáp án.
  2. Yêu cầu mô hình nhập vai (persona): yêu cầu mô hình trả lời như một nhân vật hoặc chuyên gia cụ thể có thể thay đổi đáng kể phong cách và trọng tâm đầu ra (ví dụ: "trả lời như một bác sĩ nhi khoa giàu kinh nghiệm" hoặc "trả lời như đang giải thích cho một đứa trẻ 10 tuổi").
  3. Cung cấp ví dụ: ví dụ có thể thay đổi mạnh phong cách phản hồi — ví dụ hỏi "Santa có mang quà cho tôi không" không kèm ví dụ có thể nhận câu trả lời thẳng thừng "Santa là hư cấu", nhưng nếu kèm một ví dụ trả lời kiểu tưởng tượng về Nàng Tiên Răng, mô hình sẽ dễ "chơi theo" hơn.
  4. Chỉ định định dạng đầu ra: nói rõ bạn muốn phản hồi được cấu trúc thế nào — có thể yêu cầu không có lời mở đầu (preamble), hoặc yêu cầu định dạng cụ thể như JSON hay markdown với các mục/tiêu đề cụ thể.
  5. Chia nhỏ tác vụ phức tạp thành các tác vụ con đơn giản hơn: điều này không chỉ cải thiện hiệu năng mà còn giúp việc giám sát, gỡ lỗi và song song hóa dễ hơn. Tuy nhiên có thể tăng độ trễ cảm nhận nếu người dùng không thấy đầu ra trung gian. Có thể dùng mô hình rẻ hơn cho các bước đơn giản để giảm chi phí.
  6. Cho mô hình thời gian để "suy nghĩ": các kỹ thuật như Chain of Thought ("hãy suy nghĩ từng bước một"), các chỉ dẫn theo quy trình (ví dụ: "đầu tiên phân tích chủ đề chính, thứ hai xác định góc nhìn của tác giả..."), và self-critique (yêu cầu mô hình tự kiểm tra công việc của mình). Các cách tiếp cận này thường cải thiện chất lượng nhưng tăng độ trễ và số lượng token dùng.
  7. Lặp lại có hệ thống: các kỹ thuật khác nhau hoạt động tốt hơn với các mô hình khác nhau, nên thử nghiệm là điều cốt yếu. Luôn đánh version cho prompt và dùng công cụ theo dõi thử nghiệm với metric và dữ liệu đánh giá chuẩn hóa. Cũng nên tách prompt khỏi code, lưu trong file cấu hình thay vì hardcode, giúp việc cập nhật dễ dàng hơn nhiều.

Nhiều công cụ nhắm tới việc tự động hóa quy trình prompt engineering, bao gồm OpenPrompt và DSPy — các công cụ này cho phép chỉ định định dạng đầu vào/đầu ra, metric đánh giá và dữ liệu đánh giá, rồi thực hiện AutoML để tìm prompt tối ưu. Tuy nhiên các công cụ này có thể tốn kém nếu thực hiện nhiều lệnh gọi API, có thể tạo ra prompt có lỗi chính tả hoặc vấn đề khác, và có thể không theo kịp các yêu cầu mô hình đang thay đổi. Vì lý do này, tốt nhất nên bắt đầu với prompt engineering thủ công trước khi chuyển sang công cụ tự động. Cũng có thể dùng chính mô hình AI để viết và tinh chỉnh prompt.

Tấn công và phòng thủ prompt​

Khi ứng dụng đã ra mắt, nó có thể đối mặt với các cuộc tấn công từ kẻ xấu. Ba loại tấn công prompt chính:

  1. Prompt extraction: kẻ tấn công cố trích xuất system prompt của bạn để nhân bản hoặc khai thác ứng dụng.
  2. Jailbreaking và prompt injection: các tấn công cố lật đổ tính năng an toàn của mô hình hoặc khiến nó thực hiện hành động trái phép, như đưa chỉ dẫn cho hoạt động có hại hoặc thực thi mã nguy hiểm.
  3. Information extraction: cố khiến mô hình tiết lộ thông tin nhạy cảm từ dữ liệu huấn luyện hoặc ngữ cảnh của nó.

Để phòng thủ trước các tấn công này, cân nhắc:

  • Dùng benchmark để đánh giá độ an toàn trước tấn công adversarial.
  • Tổ chức red teaming bảo mật để chủ động tìm điểm yếu.
  • Nói rõ ràng trong prompt về thông tin mô hình không nên trả về.
  • Lặp lại system prompt trước và sau đầu vào của người dùng để nhắc mô hình về ràng buộc của nó.
  • Thiết kế hệ thống với các ranh giới an toàn, như chỉ chạy code được sinh ra trong môi trường cô lập.
  • Yêu cầu con người phê duyệt cho các hành động có tác động tiềm tàng lớn.
  • Định nghĩa các chủ đề nằm ngoài phạm vi (out of scope) cho ứng dụng.
  • Dùng phát hiện bất thường (anomaly detection) để nhận diện prompt bất thường.
  • Triển khai guardrail trên cả đầu vào và đầu ra.

Khi đánh giá bảo mật hệ thống, cần theo dõi cả violation rate (tần suất tấn công thành công) và false refusal rate (tần suất mô hình từ chối nhầm các yêu cầu hợp lệ) — cần cân bằng hai chỉ số này, vì bảo mật hoàn hảo với quá nhiều từ chối nhầm sẽ tạo trải nghiệm người dùng rất khó chịu.

6. RAG — Retrieval-Augmented Generation​

Nhưng làm sao mô hình biết được những thông tin nó chưa từng học? Để giải quyết tác vụ hiệu quả, mô hình cần hai thứ: chỉ dẫn về cách thực hiện tác vụ, và thông tin cần thiết để hoàn thành nó. Hai mẫu hình thống trị đã xuất hiện để cung cấp thông tin cho mô hình: retrieval-augmented generation (RAG) và agentic pattern. RAG cho phép mô hình truy xuất thông tin liên quan từ nguồn dữ liệu bên ngoài, trong khi agentic pattern cho phép mô hình dùng công cụ như tìm kiếm web và API để chủ động thu thập thông tin. Trong khi RAG chủ yếu dùng để xây dựng ngữ cảnh (context construction), agentic pattern có thể làm được nhiều hơn thế.

RAG là kỹ thuật tăng cường khả năng sinh của mô hình bằng cách truy xuất thông tin liên quan từ các nguồn bộ nhớ bên ngoài — có thể là cơ sở dữ liệu nội bộ, các phiên chat trước đây của người dùng, hoặc thậm chí internet. Có thể coi RAG như một kỹ thuật xây dựng ngữ cảnh riêng cho từng truy vấn, kết nối mô hình với thông tin nó chưa từng được huấn luyện hoặc có thể đã quên.

Hệ thống RAG gồm hai thành phần chính: một retriever (bộ truy xuất) lấy thông tin từ nguồn bộ nhớ bên ngoài, và một generator (bộ sinh) — chính là foundation model — tạo ra phản hồi dựa trên thông tin đã truy xuất. Trong các hệ thống RAG hiện nay, hai thành phần này thường được huấn luyện riêng biệt, với nhiều đội dùng retriever và mô hình có sẵn (off-the-shelf); tuy nhiên fine-tune toàn bộ hệ thống RAG từ đầu đến cuối có thể cải thiện hiệu năng đáng kể.

Retriever: indexing và querying​

Thành công của một hệ thống RAG phụ thuộc nặng vào retriever, thực hiện hai chức năng chính: indexing (xử lý dữ liệu để có thể truy xuất nhanh sau này — đây là bước chuẩn bị tổ chức knowledge base) và querying (gửi truy vấn tìm kiếm để lấy dữ liệu liên quan). Cách bạn index dữ liệu quyết định cách bạn truy xuất nó sau này.

💡 Hình dung: Retriever giống một trợ lý thư viện — indexing là lúc trợ lý sắp xếp sách lên kệ theo chủ đề trước khi có ai hỏi, còn querying là lúc bạn hỏi "cho tôi sách về X" và trợ lý lấy đúng vài cuốn liên quan thay vì bê cả thư viện ra cho bạn.

Ví dụ: hãy tưởng tượng bộ nhớ ngoài của bạn là một cơ sở dữ liệu tài liệu như hợp đồng hay ghi chú cuộc họp, các tài liệu này có thể dài từ 10 token đến một triệu token. Truy xuất nguyên văn cả tài liệu sẽ khiến ngữ cảnh dài tùy tiện, có thể vượt quá context window của mô hình. Để tránh điều này, bạn thường chia mỗi tài liệu thành các chunk nhỏ hơn. Với mỗi truy vấn người dùng, mục tiêu là truy xuất các chunk dữ liệu liên quan nhất, sau đó qua một số bước xử lý hậu kỳ (post-processing) để nối các chunk đã truy xuất với prompt của người dùng, tạo ra prompt cuối cùng gửi tới mô hình. Ví dụ prompt cuối cùng sau bước post-processing có thể trông như sau:

[CONTEXT — 2 chunk được truy xuất]
[Chunk 1, hợp đồng_thuê_2024.pdf, đoạn 3]: "Bên thuê có nghĩa vụ thanh toán
tiền thuê chậm nhất ngày 5 hàng tháng. Quá hạn 10 ngày sẽ tính phí phạt 2%/ngày."
[Chunk 2, hợp đồng_thuê_2024.pdf, đoạn 7]: "Hợp đồng có hiệu lực 12 tháng
kể từ ngày 01/01/2024."

[USER QUERY]
Nếu tôi thanh toán trễ 15 ngày thì bị phạt bao nhiêu?

Mô hình chỉ cần đọc 2 chunk liên quan thay vì toàn bộ hợp đồng dài hàng chục trang.

RAG Pipeline: Indexing + QueryINDEXING (offline)DocumentsChunkingEmbedding ModelVector DB (indexed)QUERY (online, per request)User QuerySimilarity Search (KNN over embeddings)Top-K Retrieved ChunksFinal Prompt = Query + Top-K Chunks → LLM

Có nhiều thuật toán truy xuất khác nhau có thể dùng cho RAG:

  1. Term-based retrieval (lexical retrieval): tìm tài liệu liên quan dựa trên từ khóa. Đơn giản nhưng có giới hạn — nhiều tài liệu có thể chứa một từ mà không thực sự nói về nó, truy vấn có thể dài với nhiều từ không quan trọng như nhau (TF-IDF giúp giải quyết phần nào), và tokenization đơn giản có thể bỏ lỡ quan hệ ngữ nghĩa. Term-based retrieval nhìn chung nhanh hơn embedding-based cả khi indexing lẫn querying, và hoạt động tốt ngay với các hệ thống có sẵn như Elasticsearch.
  2. Embedding-based retrieval: tính độ liên quan ở mức ngữ nghĩa thay vì từ vựng, xếp hạng tài liệu theo mức độ ý nghĩa của chúng gần với truy vấn thế nào. Quy trình: chuyển dữ liệu gốc thành embedding bằng một mô hình embedding, lưu các embedding này trong vector database, khi có truy vấn thì chuyển nó thành embedding bằng cùng mô hình, lấy K chunk dữ liệu có embedding gần nhất với embedding truy vấn và trả về. Tìm kiếm vector thường được khung như bài toán k-nearest-neighbor (KNN) — có thể tốn kém tính toán với tập dữ liệu lớn, nên thường dùng thuật toán approximate nearest neighbor thay thế. Trong thực tế, hầu hết developer sẽ không tự triển khai vector search mà dùng vector database có sẵn — các database này tổ chức vector vào bucket, cây hoặc đồ thị bằng nhiều heuristic khác nhau để tăng khả năng các vector tương tự được lưu gần nhau.

Embedding-based retrieval có thể vượt trội đáng kể so với term-based theo thời gian, đặc biệt nếu fine-tune mô hình embedding và retriever, nhưng có nhược điểm: khó tìm kiếm tên riêng hay mã lỗi cụ thể, và việc sinh embedding có thể tốn kém và gây độ trễ. Một hệ thống retrieval production thường kết hợp nhiều cách tiếp cận — ví dụ một retriever rẻ, kém chính xác hơn như term-based search lấy ứng viên trước, rồi một cơ chế chính xác hơn nhưng đắt hơn như KNN tìm ra lựa chọn tốt nhất trong số các ứng viên đó.

Chiến thuật cải thiện retrieval​

  • Chunking: cách đơn giản nhất là chia tài liệu thành các chunk có độ dài bằng nhau dựa trên ký tự, từ, câu hoặc đoạn văn. Chunk chồng lấn (overlap) đảm bảo thông tin ranh giới quan trọng nằm trong ít nhất một chunk. Chunk nhỏ hơn cho phép thông tin đa dạng hơn (vì fit được nhiều chunk hơn vào context), nhưng có thể mất ngữ cảnh quan trọng và tăng chi phí tính toán, đặc biệt với embedding-based retrieval. Không có kích thước chunk hay tỷ lệ overlap tối ưu chung — cần thử nghiệm dựa trên dữ liệu và tác vụ cụ thể.
  • Reranking: thứ hạng ban đầu từ retriever có thể được tinh chỉnh lại để chính xác hơn, đặc biệt hữu ích khi cần giảm số tài liệu truy xuất do giới hạn context window. Tài liệu có thể được xếp hạng lại dựa trên các yếu tố như độ mới (recency — có thể cho dữ liệu mới hơn trọng số cao hơn) hoặc tín hiệu liên quan khác.
  • Query rewriting (query reformulation/expansion): viết lại truy vấn để bao gồm ngữ cảnh cần thiết — ví dụ nếu người dùng hỏi "dân số của nó là bao nhiêu" sau khi đã hỏi về Paris, truy vấn có thể được mở rộng thành "dân số của Paris là bao nhiêu".
  • Contextual augmentation: mỗi chunk có thể được tăng cường với ngữ cảnh liên quan để dễ truy xuất hơn — có thể gồm metadata như tag và từ khóa, hoặc với sản phẩm thương mại điện tử là mô tả và đánh giá. Cũng có thể tăng cường chunk với ngữ cảnh từ toàn bộ tài liệu (ví dụ tóm tắt cả tài liệu) để giữ lại nhiều ý nghĩa gốc hơn.

Lựa chọn giải pháp retrieval​

Khi chọn giải pháp retrieval, cân nhắc: cơ chế truy xuất nào được hỗ trợ (term-based, embedding-based, hybrid), với vector database thì mô hình embedding và thuật toán tìm kiếm vector nào được hỗ trợ, khả năng mở rộng cho cả lưu trữ dữ liệu và lưu lượng truy vấn, tốc độ indexing và khả năng xử lý theo batch, độ trễ truy vấn, cấu trúc giá, và yêu cầu tuân thủ (compliance).

RAG không chỉ giới hạn ở văn bản — cũng có thể dùng với dữ liệu đa phương thức (multimodal) và dạng bảng (tabular). Ví dụ nếu người dùng hỏi màu ngôi nhà trong phim Up của Pixar là gì, một hệ thống RAG đa phương thức có thể truy xuất hình ảnh ngôi nhà trước để giúp mô hình trả lời. Tương tự, RAG có thể hoạt động với dữ liệu dạng bảng thông qua chuyển đổi text-to-SQL — hệ thống thực thi truy vấn trên cơ sở dữ liệu rồi sinh phản hồi dựa trên kết quả. Với schema cơ sở dữ liệu phức tạp, có thể cần một bước trung gian để dự đoán bảng nào cần dùng cho mỗi truy vấn, đặc biệt nếu có quá nhiều bảng để đưa hết schema vào context window.

7. Agents — Tác nhân AI​

Agentic pattern là cách tiếp cận chủ động hơn để mở rộng năng lực AI. Đây là lĩnh vực đang phát triển nhanh, nên hãy xem phần này mang tính thử nghiệm nhiều hơn các phần khác.

Ở định nghĩa rộng nhất, một agent là bất cứ thứ gì có thể cảm nhận môi trường của nó và hành động lên môi trường đó. Với hệ thống AI, điều này nghĩa là mô hình có thể quan sát môi trường, ra quyết định dựa trên các quan sát đó, thực hiện hành động ảnh hưởng tới môi trường, và học từ kết quả của các hành động đó. Môi trường được xác định bởi use case — với agent chơi game, game chính là môi trường; với agent web scraping, internet chính là môi trường.

Agent LoopPerceive(Observation)Plan(Reasoning)Act(Tool Call)Observe(Result)next iterationEnvironment / Toolsgame, web, database, APIs...

Điều làm cho agent mạnh mẽ là tập hợp công cụ chúng có thể truy cập — ví dụ ChatGPT là một agent có thể tìm kiếm web, thực thi code Python và tạo hình ảnh, cùng nhiều khả năng khác.

💡 Hình dung: Agent giống một nhân viên thực tập được giao chìa khóa văn phòng — quyền tra cứu hồ sơ (knowledge augmentation tools), dùng máy tính bỏ túi (capability extension tools), thậm chí ký gửi thư đi (write action tools). Càng giao nhiều chìa khóa, càng cần giám sát kỹ để tránh hậu quả ngoài ý muốn.

Ví dụ RAG với dữ liệu dạng bảng ở phần trước thực chất là một agent đơn giản với ba hành động: sinh câu lệnh SQL, thực thi câu lệnh đó, và sinh phản hồi.

Ví dụ thực tế​

Nếu người dùng hỏi "dự báo doanh thu bán hàng trong 3 tháng tới", agent có thể trước tiên suy luận về cách hoàn thành tác vụ, rồi sinh một câu lệnh SQL để lấy dữ liệu bán hàng lịch sử, tiếp theo thực thi câu lệnh đó với cơ sở dữ liệu, phân tích xem thông tin truy xuất được có đủ không, có thể sinh và thực thi thêm các câu lệnh khác, rồi tạo ra dự báo dựa trên dữ liệu đã thu thập, và cuối cùng kết luận rằng tác vụ đã hoàn thành thành công. Vết thực thi (trace) của agent có thể trông như sau:

[THOUGHT] Cần doanh thu lịch sử theo tháng trước khi dự báo 3 tháng tới.
[ACTION]  execute_sql("SELECT month, SUM(revenue) FROM sales
                        WHERE month >= '2025-01' GROUP BY month ORDER BY month")
[OBSERVATION] 6 dòng dữ liệu trả về, tháng gần nhất là 2025-06.
[THOUGHT] Dữ liệu đủ để tính xu hướng tăng trưởng trung bình.
[ACTION]  forecast(history=[...], horizon=3)
[OBSERVATION] Dự báo: tháng 7 = 420M, tháng 8 = 435M, tháng 9 = 448M.
[THOUGHT] Đã đủ thông tin trả lời người dùng — hoàn thành tác vụ.

So với các ứng dụng AI đơn giản hơn, agent đòi hỏi mô hình mạnh hơn vì chúng thường cần thực hiện nhiều bước để hoàn thành tác vụ. Tỷ lệ thành công tổng thể giảm dần theo mỗi bước do lỗi tích lũy (compounding error), và mức độ rủi ro cũng cao hơn vì agent có quyền truy cập vào các công cụ tiềm năng mạnh mẽ.

Các loại công cụ (tools)​

  1. Knowledge augmentation tools: như bộ truy xuất văn bản hoặc hình ảnh (như trong RAG), SQL executor để truy cập cơ sở dữ liệu, khả năng tìm kiếm web, API để truy cập hệ thống kho hàng, đọc email, và trình duyệt web để duyệt nội dung online (công khai hoặc riêng tư).
  2. Capability extension tools: như máy tính (vì mô hình AI thường gặp khó khăn với toán học phức tạp), bộ chuyển đổi múi giờ hoặc đơn vị, dịch vụ dịch thuật, và trình thông dịch code (code interpreter).
  3. Write action tools: công cụ cho phép agent không chỉ đọc mà còn ghi vào hệ thống — có thể tự động hóa quy trình làm việc nhưng đòi hỏi các giao thức bảo mật nghiêm ngặt.

Planning — Lập kế hoạch​

Tác vụ phức tạp cần lập kế hoạch, và có nhiều cách khả dĩ để phân rã một tác vụ — không phải cách nào cũng thành công hay hiệu quả. Để hỗ trợ gỡ lỗi và tránh trường hợp mô hình thực hiện các lệnh gọi API không cần thiết, việc lập kế hoạch nên được tách rời khỏi việc thực thi. Quy trình thường như sau: (1) yêu cầu agent sinh một kế hoạch, (2) xác thực kế hoạch trước khi thực thi, (3) chỉ thực thi khi đã được xác thực. Kế hoạch có thể được xác thực bằng heuristic (như loại bỏ kế hoạch có hành động không hợp lệ hoặc quá nhiều bước) hoặc bằng cách dùng một mô hình AI khác làm giám khảo. Có thể sinh nhiều kế hoạch song song rồi nhờ một bộ đánh giá chọn ra kế hoạch hứa hẹn nhất. Với các tác vụ đặc biệt quan trọng hoặc nhạy cảm, có thể cần con người trong vòng lặp (human in the loop) để xem xét kế hoạch trước khi thực thi.

Trong khi foundation model agent dùng chính mô hình làm bộ lập kế hoạch (planner), reinforcement learning agent được huấn luyện bằng thuật toán reinforcement learning — cách tiếp cận này dùng nhiều tài nguyên hơn nhưng có thể mang lại cải thiện hiệu năng trong tương lai.

Cách đơn giản nhất để biến một mô hình thành bộ sinh kế hoạch là qua prompt engineering — nói cho mô hình biết nó có những chức năng gì và đầu vào/đầu ra mong đợi cho mỗi công cụ. Có thể cải thiện prompt bằng cách viết system prompt tốt hơn với nhiều ví dụ hơn, cung cấp mô tả rõ ràng hơn về công cụ và tham số của chúng, đơn giản hóa các hàm càng nhiều càng tốt, dùng mô hình mạnh hơn, hoặc fine-tune một mô hình chuyên cho việc sinh kế hoạch. Một mẹo thực tế: luôn yêu cầu hệ thống báo cáo giá trị tham số nó dùng cho mỗi lệnh gọi hàm — điều này cung cấp một bước kiểm tra hợp lý (sanity check) có thể bắt được nhiều vấn đề trước khi thực thi. Một cách tiếp cận hữu ích khác là sinh kế hoạch bằng ngôn ngữ tự nhiên trước, rồi dịch chúng thành các lệnh gọi hàm chính xác ở bước thứ hai — điều này hữu ích nếu tên hàm thay đổi theo thời gian, và bước dịch thường có thể do một mô hình nhỏ hơn, rẻ hơn thực hiện.

Đánh giá agent​

Agent có thể thất bại theo nhiều cách, nên cần có phương pháp đánh giá vững chắc:

  • Lỗi lập kế hoạch: dùng công cụ không hợp lệ, dùng công cụ hợp lệ nhưng tham số không hợp lệ, dùng công cụ hợp lệ với giá trị tham số sai, hoặc không đạt được mục tiêu/thỏa mãn ràng buộc. Để đánh giá khả năng lập kế hoạch, tạo một tập dữ liệu mà mỗi ví dụ là một bộ ba (tác vụ, công cụ khả dụng, ràng buộc), rồi dùng agent sinh nhiều kế hoạch và tính các metric như tỷ lệ phần trăm kế hoạch hợp lệ, cần bao nhiêu lần thử để có một kế hoạch hợp lệ, tỷ lệ công cụ được gọi hợp lệ, và tần suất công cụ không hợp lệ bị gọi.
  • Lỗi công cụ: bao gồm dịch sai từ kế hoạch cấp cao sang tên hàm cụ thể, không có quyền truy cập công cụ cần thiết, hoặc công cụ trả về đầu ra sai (như câu lệnh SQL được sinh kém). Các metric hiệu quả có thể gồm: trung bình bao nhiêu bước agent cần để hoàn thành tác vụ, chi phí hoàn thành tác vụ, mỗi hành động mất bao lâu, có hành động nào đặc biệt chậm hoặc đắt không, và agent so với baseline (agent khác hoặc con người) ra sao.

Memory — Bộ nhớ của agent​

Một trong những thách thức chính của agent là ghi nhớ thông tin theo thời gian. Một hệ thống bộ nhớ cho phép mô hình lưu giữ và sử dụng thông tin qua nhiều tương tác. Agent thường có ba cơ chế bộ nhớ chính:

  1. Internal knowledge: kiến thức được nhúng trong chính mô hình qua quá trình huấn luyện.
  2. Context window: giống như bộ nhớ ngắn hạn cho thông tin tức thời, theo từng phiên cụ thể.
  3. External data sources (như hệ thống RAG): giống bộ nhớ dài hạn.

Thông tin thiết yếu cho mọi tác vụ nên được đưa vào qua huấn luyện; thông tin ít khi cần đến nên nằm trong bộ nhớ dài hạn; còn bộ nhớ ngắn hạn dùng cho thông tin tức thời, theo ngữ cảnh cụ thể. Lợi ích của một hệ thống quản lý bộ nhớ được thiết kế tốt bao gồm: lưu trữ thông tin lâu hơn khả năng của context window, giữ lại thông tin giữa các phiên, và giúp mô hình nhất quán hơn trong phản hồi và hành động.

Bằng cách kết hợp RAG để truy cập thông tin, công cụ để mở rộng năng lực, lập kế hoạch cho tác vụ phức tạp, và hệ thống bộ nhớ cho tính liên tục, agent có thể xử lý những vấn đề ngày càng tinh vi. Dù lĩnh vực này vẫn đang phát triển nhanh, nó đại diện cho một trong những biên giới hứa hẹn nhất của AI Engineering. Cũng như mọi công nghệ mạnh mẽ khác, hệ thống agent đòi hỏi cân nhắc kỹ về an toàn, bảo mật và sử dụng có đạo đức — agent càng có năng lực, càng cần đảm bảo nó hoạt động trong ranh giới phù hợp và có sự giám sát đúng đắn.

8. Fine-tuning​

Nhưng nếu prompt engineering và RAG vẫn chưa đủ thì sao? Đây là lúc fine-tuning phát huy tác dụng — quá trình thích ứng một mô hình cho tác vụ cụ thể bằng cách huấn luyện thêm và điều chỉnh trọng số của nó. Trong khi prompt engineering và RAG là các kỹ thuật tương đối nhẹ, fine-tuning mang lại khả năng tùy biến sâu hơn nhưng cần nhiều tài nguyên và chuyên môn hơn.

Khi nào nên fine-tune​

Fine-tuning có thể cải thiện hiệu năng mô hình theo hai cách: (1) tăng cường khả năng chuyên biệt theo domain (như coding hoặc trả lời câu hỏi y tế), và (2) cải thiện khả năng tuân theo chỉ dẫn (như tuân thủ định dạng đầu ra cụ thể). Tuy nhiên fine-tuning đòi hỏi đầu tư ban đầu đáng kể — thường cần nhiều bộ nhớ hơn mức có sẵn trên một GPU đơn, khiến nó tốn kém. Đây là lý do việc giảm yêu cầu bộ nhớ trở thành động lực chính cho nhiều kỹ thuật fine-tuning.

Nên cân nhắc fine-tuning khi đã khai thác hết những gì có thể đạt được bằng phương pháp dựa trên prompt, cần sinh ra đầu ra có cấu trúc nhất quán, và đang làm việc với mô hình nhỏ cần hoạt động tốt hơn trên tác vụ cụ thể. Một cách tiếp cận phổ biến là model distillation — fine-tune một mô hình nhỏ để bắt chước hành vi của mô hình lớn hơn, dùng dữ liệu do mô hình lớn sinh ra cho các tác vụ cụ thể; một mô hình nhỏ đã fine-tune có thể vượt qua một mô hình đa dụng lớn hơn.

💡 Hình dung: Full fine-tuning giống việc đào tạo lại một nhân viên từ đầu; LoRA (sẽ nói ở phần PEFT bên dưới) giống việc chỉ cho nhân viên đã có sẵn học thêm một khóa kỹ năng ngắn gọn — rẻ hơn nhiều nhưng vẫn đạt hiệu quả gần tương đương.

Nên tránh fine-tuning nếu cần một mô hình đa dụng (fine-tuning có thể cải thiện hiệu năng trên tác vụ cụ thể nhưng làm giảm hiệu năng ở các tác vụ khác), hoặc nếu chỉ mới bắt đầu thử nghiệm dự án — nhiều đội nhảy thẳng vào fine-tuning trước khi khám phá kỹ các cách tiếp cận đơn giản hơn.

Fine-tuning vs. RAG​

Sau khi đã tối đa hóa lợi ích từ prompting, việc chọn giữa RAG và fine-tuning phụ thuộc vào việc thất bại của mô hình là do thiếu thông tin hay do hành vi. Nếu mô hình thất bại vì thiếu thông tin (như dữ liệu công ty riêng tư hoặc sự kiện gần đây), RAG giúp mô hình truy cập thông tin đó tốt hơn. Nếu mô hình có vấn đề về hành vi — như đầu ra đúng sự thật nhưng không liên quan, hoặc sai định dạng — fine-tuning có thể giúp nhiều hơn. Nếu mô hình gặp cả hai vấn đề, hãy bắt đầu với RAG vì nó dễ hơn — bắt đầu với giải pháp term-based đơn giản rồi phát triển dần. Trong nhiều trường hợp, kết hợp RAG và fine-tuning sẽ mang lại mức tăng hiệu năng lớn nhất.

Quy trình thích ứng mô hình cho một tác vụ có thể là: (1) thiết kế tiêu chí đánh giá và pipeline đánh giá, (2) thử để mô hình thực hiện tác vụ chỉ bằng prompting, thêm nhiều ví dụ vào prompt, (3) nếu mô hình vẫn thất bại vì thiếu thông tin, thử RAG nâng cao hơn như embedding-based retrieval, (4) nếu vẫn có vấn đề hành vi, chọn fine-tuning, (5) cuối cùng kết hợp RAG và fine-tuning để có mức tăng hiệu năng lớn hơn.

Bộ nhớ và huấn luyện​

Vì quy mô của foundation model, bộ nhớ là nút thắt cổ chai lớn cho cả inference và fine-tuning. Yêu cầu bộ nhớ cho fine-tuning thường cao hơn nhiều so với inference, do cách neural network được huấn luyện: neural network thường được huấn luyện bằng back propagation — mỗi bước huấn luyện gồm một forward pass (tính đầu ra từ đầu vào) và một backward pass (cập nhật trọng số mô hình dùng tín hiệu từ forward pass). Trong inference chỉ thực hiện forward pass; trong huấn luyện cần cả hai pass.

Các yếu tố chính ảnh hưởng tới bộ nhớ trong fine-tuning: tổng số tham số, số tham số có thể huấn luyện (trainable parameter), và cách biểu diễn số học của các tham số này. Trong pre-training, tất cả tham số được cập nhật; trong inference, không tham số nào được cập nhật; trong fine-tuning, một số hoặc tất cả tham số có thể được cập nhật. Các tham số không đổi được gọi là frozen parameter.

Một cách giảm bộ nhớ huấn luyện là gradient checkpointing (còn gọi là activation recomputation) — trong đó activation không được lưu trữ mà được tính lại khi cần, làm tăng thời gian huấn luyện nhưng giảm yêu cầu bộ nhớ. Càng nhiều tham số có thể huấn luyện, bộ nhớ tiêu tốn càng lớn — đây là động lực cho parameter-efficient fine-tuning (PEFT).

Một cách khác để giảm bộ nhớ là quantization — chuyển mô hình từ định dạng nhiều bit sang định dạng ít bit hơn. Với mô hình 13 tỷ tham số dùng số thực dấu phẩy động 32-bit, mỗi tham số cần 4 byte, tổng cộng 52GB; nếu giảm mỗi giá trị xuống 16-bit, bộ nhớ cần giảm còn 26GB. Inference thường dùng càng ít bit càng tốt (16, 8 hoặc thậm chí 4-bit); huấn luyện nhạy cảm hơn với độ chính xác số học nên thường dùng mixed precision — một số phép toán ở độ chính xác cao (32-bit), số khác ở độ chính xác thấp (16 hoặc 8-bit). Các định dạng số khác nhau cân bằng giữa range (phạm vi giá trị có thể biểu diễn) và precision (mức chính xác một số có thể được biểu diễn). Giảm độ chính xác có thể làm thay đổi giá trị hoặc gây lỗi, nên quan trọng là phải load mô hình đúng định dạng dự kiến — ví dụ khi Llama 2 phát hành, trọng số của nó được tối ưu cho bf16, gây chất lượng tệ hơn đáng kể khi load với fp16.

Parameter-Efficient Fine-Tuning (PEFT)​

Trong những ngày đầu của các mô hình nhỏ hơn, full fine-tuning (cập nhật tất cả tham số) khá phổ biến. Khi mô hình lớn dần, người ta bắt đầu dùng partial fine-tuning, tập trung vào các layer cụ thể (ví dụ chỉ layer cuối) — giảm yêu cầu bộ nhớ nhưng không thực sự hiệu quả về tham số. Các kỹ thuật PEFT chèn thêm tham số vào các vị trí chiến lược trong mô hình để đạt hiệu năng fine-tuning mạnh với số lượng tham số huấn luyện nhỏ. Dù có thể tăng nhẹ độ trễ inference vì adapter thêm các bước tính toán, các phương pháp PEFT nhìn chung không chỉ hiệu quả về tham số mà còn hiệu quả về mẫu (sample efficient) — có thể hoạt động chỉ với vài nghìn ví dụ so với hàng triệu ví dụ có thể cần cho full fine-tuning.

Các phương pháp PEFT chia làm hai nhóm: adapter-based (additive) methods — thêm trọng số mô hình mới, và soft prompt-based methods — đưa thêm các token đặc biệt có thể huấn luyện.

Phương pháp adapter-based phổ biến nhất là LoRA (low-rank adaptation). Khác với adapter truyền thống, LoRA đưa thêm tham số mà không tăng độ trễ inference — thay vì thêm layer mới, LoRA dùng các module có thể được gộp lại (merge) vào layer gốc. LoRA hoạt động bằng cách phân rã ma trận trọng số thành tích của các ma trận nhỏ hơn, rồi chỉ cập nhật các ma trận nhỏ này. Với một ma trận trọng số kích thước n×m, LoRA đầu tiên chọn một chiều nhỏ hơn R (rank), rồi tạo hai ma trận A (n×R) và B (R×m). Trong quá trình fine-tuning, chỉ A và B được cập nhật trong khi trọng số gốc vẫn đóng băng (frozen); cho inference, A và B có thể được nhân lại với nhau và cộng vào trọng số gốc. Hiệu quả của LoRA phụ thuộc cả vào rank được chọn và các ma trận nó được áp dụng lên — nó chủ yếu được dùng cho các module Transformer trong attention module. Về pseudo-code, ý tưởng cốt lõi chỉ gồm vài dòng:

# W: trọng số gốc (n x m), đóng băng — không cập nhật
# A: ma trận mới (n x r), B: ma trận mới (r x m) — r << n, m
A = init_random(n, r)
B = init_zeros(r, m)          # B khởi tạo 0 để lúc đầu LoRA không đổi gì

# Forward pass trong lúc fine-tuning:
output = input @ W + input @ (A @ B)   # chỉ A, B nhận gradient

# Sau khi fine-tune xong, gộp vào inference — không tăng latency:
W_merged = W + A @ B
LoRA: Low-Rank Weight DecompositionW(n × m)frozen+A(n × r)×B(r × m), r ≪ n, mtrainableW' = W + A · Bmerged before inference — no extra latencyOnly A, B receive gradients during fine-tuning; W stays frozen throughout

Fine-tune cho nhiều tác vụ​

Nếu muốn fine-tune một mô hình cho nhiều tác vụ, có một số lựa chọn:

  1. Simultaneous fine-tuning: huấn luyện trên một tập dữ liệu có ví dụ từ tất cả các tác vụ cùng lúc — khó hơn và cần nhiều dữ liệu hơn.
  2. Sequential fine-tuning: huấn luyện trước trên tác vụ A rồi tới tác vụ B — có thể gây catastrophic forgetting, khi mô hình mất khả năng trên các tác vụ trước đó.
  3. Model merging: fine-tune các tác vụ khác nhau riêng biệt rồi kết hợp các mô hình lại. Model merging mang lại sự linh hoạt lớn hơn so với chỉ fine-tuning — nếu có hai mô hình xuất sắc ở các khía cạnh khác nhau của cùng một tác vụ, có thể gộp chúng thành một mô hình vượt trội hơn cả hai. Cách tiếp cận này có thể thực hiện mà không cần GPU, có thể cải thiện hiệu năng trong khi giảm dung lượng bộ nhớ, là lựa chọn tuyệt vời cho triển khai on-device, và có thể hỗ trợ federated learning khi nhiều thiết bị huấn luyện dùng dữ liệu riêng biệt. Khác với ensembling (kết hợp đầu ra của nhiều mô hình), merging kết hợp chính các mô hình lại, cải thiện hiệu năng mà không tốn chi phí inference cao hơn khi chạy nhiều mô hình.

Một số cách tiếp cận merging: summing (cộng giá trị trọng số của các mô hình thành phần lại — cách phổ biến nhất), layer stacking (lấy các layer khác nhau từ các mô hình khác nhau và xếp chồng lên nhau — còn gọi là Franken-merging), hoặc concatenation (chỉ đơn giản kết hợp tham số — ít được khuyến nghị vì không giảm bộ nhớ so với các mô hình riêng biệt).

Quy trình fine-tuning thực tế​

Một lộ trình phát triển điển hình: (1) kiểm thử code fine-tuning bằng mô hình rẻ và nhanh nhất bạn có, đảm bảo nó hoạt động; (2) kiểm thử dữ liệu bằng cách fine-tune một mô hình cỡ trung — nếu training loss không giảm khi thêm dữ liệu, có thể có gì đó sai; (3) chạy thử nghiệm với mô hình mục tiêu để xem có thể đẩy hiệu năng đến đâu; (4) ánh xạ đường biên chi phí-hiệu năng và chọn mô hình phù hợp nhất cho use case.

Một lộ trình distillation thay thế: bắt đầu với một tập dữ liệu nhỏ và mô hình mạnh nhất có thể chi trả, huấn luyện mô hình tốt nhất có thể với tập dữ liệu nhỏ này, dùng mô hình đã fine-tune để sinh thêm dữ liệu huấn luyện, rồi dùng tập dữ liệu mở rộng để huấn luyện một mô hình rẻ hơn.

Khi chọn phương pháp fine-tuning: người mới nên bắt đầu với kỹ thuật adapter như LoRA trước khi thử full fine-tuning. Lượng dữ liệu cũng quan trọng: full fine-tuning thường cần hàng nghìn đến hàng triệu ví dụ, trong khi PEFT có thể hoạt động với hàng trăm ví dụ. Cũng cần biết cần bao nhiêu mô hình đã fine-tune — phương pháp adapter cho phép phục vụ nhiều biến thể dùng chung một mô hình gốc.

Hyperparameter quan trọng​

  • Learning rate: nếu đường cong loss dao động, learning rate có thể quá cao; nếu ổn định nhưng giảm rất chậm, rate có thể quá thấp. Nhìn chung nên bắt đầu lớn rồi giảm dần theo thời gian.
  • Batch size: batch lớn hơn xử lý ví dụ huấn luyện nhanh hơn nhưng cần nhiều bộ nhớ hơn; batch nhỏ dẫn đến huấn luyện kém ổn định hơn — để giải quyết sự bất ổn này, có thể tích lũy gradient qua nhiều batch.
  • Số epoch: tập dữ liệu nhỏ hơn thường cần nhiều epoch hơn tập lớn — với hàng triệu ví dụ, 1–2 epoch có thể đủ; với hàng nghìn ví dụ, có thể cần 4–10 epoch. Giảm số epoch nếu thấy overfitting.
  • Prompt loss weight (cho instruction fine-tuning): xác định mức độ prompt đóng góp vào loss so với response. Nếu đặt 100%, prompt và response đóng góp như nhau; nếu 0%, mô hình chỉ học từ response. Giá trị mặc định thường là 10%.

Dù quy trình kỹ thuật của fine-tuning đã được đơn giản hóa nhờ các framework xử lý quá trình huấn luyện và gợi ý giá trị mặc định hợp lý, các quyết định chiến lược xung quanh fine-tuning vẫn phức tạp — điều quan trọng là biết khi nào nên fine-tune, dùng kỹ thuật nào, và cách cân bằng đánh đổi giữa hiệu năng, tài nguyên và yêu cầu dữ liệu.

9. Dataset Engineering​

Hầu hết công ty không thể tự huấn luyện foundation model từ đầu, nhưng gần như tất cả đều có thể tạo khác biệt qua các bộ dữ liệu chất lượng cao cho việc thích ứng mô hình. Như câu nói "garbage in, garbage out" — và không đâu điều này đúng hơn trong dataset engineering.

💡 Hình dung: Model-centric AI giống việc mua động cơ mạnh hơn cho chiếc xe đang có; data-centric AI giống việc đổ đúng loại nhiên liệu chất lượng cao — nhiều khi hiệu quả hơn hẳn so với chỉ nâng cấp phần cứng.

Chúng ta đang chứng kiến sự chuyển dịch từ AI model-centric sang data-centric. Model-centric AI cố cải thiện hiệu năng bằng cách nâng cấp chính mô hình — thiết kế kiến trúc mới, tăng kích thước mô hình, hoặc phát triển kỹ thuật huấn luyện mới. Data-centric AI ngược lại, tập trung cải thiện hiệu năng bằng cách nâng cao dữ liệu — phát triển kỹ thuật xử lý dữ liệu tốt hơn và tạo ra các bộ dữ liệu chất lượng cao cho phép huấn luyện các mô hình vượt trội với ít tài nguyên hơn. Với các công ty thích ứng foundation model thay vì tự xây dựng, cách tiếp cận data-centric mang lại lợi thế cạnh tranh lớn nhất.

Loại dữ liệu theo tác vụ thích ứng​

Loại dữ liệu cần thiết phụ thuộc vào tác vụ thích ứng: với self-supervised fine-tuning cần các chuỗi dữ liệu domain liên quan; với instruction fine-tuning cần dữ liệu dạng instruction-response; với preference fine-tuning cần dữ liệu dạng instruction cùng response thắng (winning) và response thua (losing); với reward modeling cần dữ liệu preference hoặc ví dụ có điểm số rõ ràng.

Dữ liệu huấn luyện của bạn nên thể hiện các hành vi bạn muốn mô hình học — điều này có thể đặc biệt khó với các hành vi phức tạp như suy luận Chain of Thought hay dùng công cụ trong quy trình agent. Khi phát triển ứng dụng hội thoại, cần cân nhắc có cần dữ liệu single-turn, multi-turn, hay cả hai — dữ liệu single-turn giúp huấn luyện mô hình phản hồi từng chỉ dẫn riêng lẻ, trong khi dữ liệu multi-turn dạy mô hình giải quyết tác vụ qua đối thoại, như làm rõ ý định người dùng trước khi xử lý tác vụ hoặc tiếp nhận các chỉnh sửa.

Một lượng nhỏ dữ liệu chất lượng cao có thể vượt trội hơn một lượng lớn dữ liệu nhiễu — nguyên tắc này được xác nhận bởi các đội phát triển mô hình như Llama 3. Họ nhận thấy dữ liệu do con người tạo ra thường dễ mắc lỗi và thiếu nhất quán, đặc biệt với các chính sách phức tạp/tinh tế, dẫn họ tới việc phát triển các công cụ chú thích (annotation) có sự hỗ trợ của AI để đảm bảo chất lượng cao.

Điều gì tạo nên dữ liệu chất lượng cao​

  • Relevance (liên quan): các ví dụ nên liên quan tới tác vụ mục tiêu — văn bản pháp lý thế kỷ 19 có thể không liên quan để trả lời câu hỏi pháp lý đương đại.
  • Alignment với yêu cầu tác vụ: nếu tác vụ tập trung vào tính nhất quán sự thật, các chú thích cần chính xác về mặt sự thật; nếu đòi hỏi sự sáng tạo, chú thích cần sáng tạo.
  • Consistency (nhất quán): chú thích cần nhất quán giữa các ví dụ và giữa các người chú thích.
  • Correct formatting (đúng định dạng): dữ liệu cần tuân theo cấu trúc mong đợi.
  • Sufficiently unique (đủ độc đáo): cần giảm thiểu trùng lặp trong tập dữ liệu.
  • Compliant (tuân thủ): tuân theo chính sách nội bộ và bên ngoài.
  • Coverage (độ bao phủ): dữ liệu huấn luyện cần bao phủ đủ phạm vi các vấn đề muốn giải quyết, đòi hỏi tính đa dạng đầy đủ — thiếu độ bao phủ ở các khu vực quan trọng sẽ dẫn tới hiệu năng kém cho những trường hợp đó, dù có bao nhiêu dữ liệu tổng thể đi nữa.

Cần bao nhiêu dữ liệu?​

Câu hỏi "cần bao nhiêu dữ liệu" cũng giống như hỏi "cần bao nhiêu tiền" — câu trả lời thay đổi rất nhiều tùy tình huống. Một số yếu tố ảnh hưởng: nếu fine-tune, kỹ thuật fine-tuning quan trọng — full fine-tuning thường cần nhiều dữ liệu hơn hẳn so với phương pháp parameter-efficient như LoRA (hàng chục nghìn đến hàng triệu ví dụ với full fine-tuning; hàng trăm đến vài nghìn ví dụ có thể đủ cho PEFT). Độ phức tạp của tác vụ cũng quan trọng — phân loại cảm xúc đơn giản cần ít dữ liệu hơn nhiều so với trả lời câu hỏi phức tạp về hồ sơ tài chính. Hiệu năng của mô hình gốc cũng tạo khác biệt — mô hình gốc càng gần hiệu năng mong muốn, càng cần ít ví dụ.

Hướng dẫn fine-tuning của OpenAI cho thấy với ít ví dụ hơn (khoảng 100), các mô hình tiên tiến hơn cho kết quả fine-tuning tốt hơn; tuy nhiên sau khi fine-tune trên tập dữ liệu lớn (khoảng 550.000 ví dụ), tất cả các mô hình đều hoạt động tương tự nhau bất kể năng lực ban đầu. Tóm lại: với dữ liệu hạn chế, dùng phương pháp PEFT trên mô hình tiên tiến hơn; với dữ liệu dồi dào, full fine-tuning trên mô hình nhỏ hơn trở nên khả thi.

Trước khi đầu tư vào một tập dữ liệu lớn, hãy bắt đầu với một tập nhỏ khoảng 50 ví dụ được soạn kỹ để xem fine-tuning có cải thiện mô hình không. Nếu thấy cải thiện rõ rệt, nhiều dữ liệu hơn nhiều khả năng sẽ giúp thêm; nếu không thấy cải thiện với tập dữ liệu nhỏ, tập lớn hơn hiếm khi giải quyết được vấn đề — dù cần cẩn thận loại trừ các vấn đề khác như hyperparameter kém hoặc chất lượng dữ liệu trước. Trong hầu hết trường hợp, bạn sẽ thấy cải thiện sau fine-tuning chỉ với 50–100 ví dụ.

Có thể giảm lượng dữ liệu chất lượng cao cần thiết bằng cách fine-tune trước trên dữ liệu dễ tiếp cận hơn — ví dụ: từ self-supervised sang supervised (fine-tune trước trên tài liệu domain cụ thể, rồi trên cặp câu hỏi-đáp mục tiêu); từ dữ liệu ít liên quan sang liên quan hơn (fine-tune trước trên domain lân cận có nhiều dữ liệu, rồi trên domain cụ thể); hoặc từ dữ liệu tổng hợp sang dữ liệu thực (fine-tune trước trên ví dụ do AI sinh, rồi trên ví dụ thực hạn chế). Thử nghiệm với các tập con của dữ liệu hiện có (ví dụ 25%, 50%, 100%) có thể giúp ước tính cần thêm bao nhiêu dữ liệu — mức tăng hiệu năng dốc khi tăng kích thước dữ liệu cho thấy cải thiện đáng kể từ việc gấp đôi dữ liệu, còn một đường phẳng (plateau) cho thấy lợi ích giảm dần.

Lấy thêm dữ liệu​

Nếu cần thêm dữ liệu, có thể tạo một data flywheel tận dụng tương tác người dùng để liên tục cải thiện sản phẩm — mang lại lợi thế cạnh tranh đáng kể. Cũng có thể kiểm tra các bộ dữ liệu có sẵn — thường có thể trộn nhiều nguồn khác nhau, dù mọi dữ liệu cần được kiểm chứng kỹ về chất lượng và giấy phép phù hợp.

Khi tự chú thích (annotate) dữ liệu, thách thức không chỉ nằm ở quá trình chú thích mà còn ở việc tạo ra hướng dẫn rõ ràng — cần định nghĩa tường minh điều gì tạo nên một phản hồi tốt: một phản hồi có thể đúng nhưng không hữu ích không? Điều gì phân biệt điểm 3 với điểm 4? Các hướng dẫn này quan trọng với cả chú thích do con người và AI thực hiện.

Data augmentation tạo ra ví dụ mới từ dữ liệu hiện có (ví dụ lật ảnh để tạo biến thể mới). Data synthesis sinh ra dữ liệu nhân tạo mô phỏng thuộc tính dữ liệu thực (ví dụ mô phỏng chuyển động chuột trên trang web). Khác biệt chính giữa dữ liệu augmented và synthetic là dữ liệu augmented bắt nguồn từ dữ liệu thực, còn dữ liệu synthetic được tạo hoàn toàn mới — vì vậy data synthesis đặc biệt có giá trị để giải quyết mối lo về quyền riêng tư khi làm việc với thông tin nhạy cảm.

Kết hợp các kỹ thuật này giúp tạo dữ liệu ở quy mô lớn, tăng độ bao phủ trên toàn bộ không gian vấn đề, và có thể cải thiện chất lượng với dữ liệu do AI sinh — vì con người không phải lúc nào cũng giỏi tạo dữ liệu nhất quán. Nhưng luôn nhớ đo lường chất lượng dữ liệu do AI sinh giống như cách đo lường dữ liệu do con người tạo ra.

Xử lý dữ liệu​

Sau khi có dữ liệu, cần xử lý nó — quá trình này có thể tốn thời gian nhưng rất quan trọng cho chất lượng. Một số thực hành tốt nhất:

  • Bắt đầu bằng việc lọc các tác vụ và test script trước khi chạy quy mô lớn.
  • Tránh thay đổi dữ liệu tại chỗ — luôn giữ bản gốc.
  • Thực hiện phân tích khám phá dữ liệu (EDA) về phân bố và outlier.
  • Kiểm tra sự bất đồng giữa các người chú thích (interannotator disagreement) và giải quyết xung đột.
  • Fact-check và kiểm tra thủ công các ví dụ.
  • Loại bỏ trùng lặp (deduplicate) dữ liệu để tránh đại diện quá mức.
  • Dọn dẹp các token định dạng như HTML và markdown, giúp cải thiện hiệu năng và giảm kích thước đầu vào.
  • Loại bỏ dữ liệu không tuân thủ, như PII, nội dung độc hại, hoặc nội dung có bản quyền.
  • Lọc bỏ dữ liệu chất lượng thấp được xác định trong quá trình kiểm chứng.
  • Nếu có nhiều dữ liệu hơn ngân sách tính toán cho phép, dùng active learning để chọn ra các ví dụ hữu ích nhất.
  • Đảm bảo dữ liệu đúng định dạng cho mô hình, dùng đúng tokenizer và chat template.

Dù các bước này đòi hỏi nhiều công sức, chúng rất cần thiết để tạo ra các bộ dữ liệu giúp mô hình tỏa sáng trong bối cảnh cạnh tranh của các ứng dụng AI. Bộ dữ liệu được thiết kế tốt thường tạo ra khác biệt giữa hiệu năng tầm thường và xuất sắc.

10. Inference Optimization​

Nhưng điều gì thực sự quyết định một mô hình có dùng được trong production hay không? Giá trị thực tế của một mô hình cuối cùng phụ thuộc vào hai yếu tố then chốt: chi phí vận hành và tốc độ phản hồi. Hai đặc tính này — chi phí inference và độ trễ — quyết định ứng dụng nào có thể thực sự dùng AI, và ở quy mô nào.

Trong vòng đời AI có hai giai đoạn riêng biệt: training (xây dựng mô hình) và inference (dùng mô hình để tính đầu ra cho đầu vào cho trước). Trong môi trường production, thành phần chịu trách nhiệm chạy inference được gọi là inference server — server này host các mô hình sẵn có, phân bổ tài nguyên phần cứng để chạy chúng, và trả kết quả về cho người dùng. Inference server là một phần của inference service rộng hơn, cũng xử lý việc nhận, định tuyến và tiền xử lý các yêu cầu. Nếu dùng model API (như từ OpenAI hay Google), bạn đang thuê ngoài inference service này; nếu tự host mô hình, bạn cần tự xây dựng, tối ưu và duy trì hạ tầng inference của riêng mình.

Các loại nút thắt cổ chai (bottleneck)​

Khối lượng công việc AI thường gặp hai loại nút thắt cổ chai: compute-bound (giới hạn bởi sức mạnh tính toán khả dụng — các tác vụ đòi hỏi tính toán chuyên sâu như tạo ảnh thường thuộc loại này) và memory bandwidth-bound (giới hạn bởi tốc độ dữ liệu di chuyển giữa bộ nhớ và bộ xử lý — inference của mô hình ngôn ngữ autoregressive thường thuộc loại này). Công cụ profiling như Nvidia Insight có thể giúp xác định nút thắt cổ chai nào ảnh hưởng tới workload thông qua roofline chart. Các kỹ thuật tối ưu khác nhau giải quyết các loại nút thắt cổ chai khác nhau — workload compute-bound có thể hưởng lợi từ chip mạnh hơn hoặc phân tán công việc trên nhiều chip; workload memory bandwidth-bound có thể hưởng lợi từ chip có băng thông bộ nhớ cao hơn.

Các loại inference API​

Nhiều nhà cung cấp thường có hai loại API inference riêng biệt, mỗi loại tối ưu cho mục đích khác nhau: online API tối ưu cho độ trễ, xử lý yêu cầu ngay khi đến (chatbot thường dùng loại này vì người dùng mong đợi phản hồi nhanh), còn batch API tối ưu cho chi phí, xử lý nhiều yêu cầu cùng lúc hiệu quả hơn nhưng với độ trễ cao hơn (các ứng dụng không yêu cầu thời gian phản hồi nghiêm ngặt, như tạo báo cáo định kỳ hay sinh dữ liệu tổng hợp, có thể hưởng lợi từ batch processing).

Các metric hiệu năng inference​

  • Latency: thời gian từ khi người dùng gửi truy vấn đến khi nhận được phản hồi hoàn chỉnh. Với mô hình autoregressive như LLM, latency chia thành hai thành phần: time to first token (TTFT) — tốc độ sinh token đầu tiên sau khi nhận truy vấn, và time per output token (TPOT) — thời gian để sinh mỗi token tiếp theo. Tổng latency bằng TTFT cộng với TPOT nhân số token đầu ra. Một số đội cũng đo time to publish (TTP) vì token đầu tiên được sinh ra không phải lúc nào cũng hiển thị ngay cho người dùng, đặc biệt khi mô hình sinh kế hoạch hoặc dùng suy luận Chain of Thought trước. Vì latency biến động giữa các yêu cầu, xem xét các percentile cho thông tin có ý nghĩa hơn nhiều so với trung bình đơn giản.
  • Throughput: số token đầu ra mỗi giây mà một inference service có thể sinh trên tất cả các yêu cầu. Throughput cao hơn thường đồng nghĩa chi phí thấp hơn, đó là lý do tối ưu nó quan trọng cho hệ thống production.
  • Latency-throughput tradeoff: hầu hết ứng dụng AI đối mặt với đánh đổi cơ bản này — kỹ thuật như batching có thể cải thiện throughput nhưng có thể tăng latency cho từng yêu cầu riêng lẻ. Chiến lược tối ưu cần cân bằng các ưu tiên cạnh tranh này dựa trên nhu cầu ứng dụng cụ thể.
  • Utilization metrics: model FLOPs utilization là tỷ lệ throughput quan sát được so với mức tối đa lý thuyết ở công suất tính toán đỉnh; model bandwidth utilization đo phần trăm băng thông bộ nhớ khả dụng đang được sử dụng.

Phần cứng cho inference​

Tại trung tâm của hiệu năng inference là phần cứng chuyên biệt. Accelerator là chip được thiết kế để tăng tốc các loại tính toán cụ thể cho khối lượng công việc AI — accelerator thống trị là GPU, dù các chip AI chuyên dụng khác cũng đang phổ biến dần. Khác biệt giữa CPU và GPU nằm ở kiến trúc: CPU có ít lõi mạnh (thường tối đa 64 với máy cao cấp) tối ưu cho tính toán đa dụng; GPU có hàng nghìn lõi nhỏ hơn tối ưu cho xử lý song song, khiến chúng lý tưởng cho các phép nhân ma trận vốn chiếm ưu thế trong khối lượng công việc ML.

Đáng chú ý, training và inference có yêu cầu phần cứng khác nhau: training đòi hỏi nhiều bộ nhớ hơn do back propagation và nhìn chung khó thực hiện ở độ chính xác thấp hơn; inference thường ưu tiên latency hơn throughput vì người dùng thường đang chờ phản hồi. Khi đánh giá phần cứng cho inference, cân nhắc ba câu hỏi chính: nó có thể chạy được workload của bạn không, mất bao lâu để làm việc đó, và chi phí bao nhiêu. Các thông số phần cứng cần chú ý gồm FLOPs (sức mạnh tính toán), kích thước bộ nhớ và băng thông bộ nhớ — với workload compute-bound, ưu tiên chip có nhiều FLOPs hơn; với workload memory-bound, ưu tiên băng thông cao hơn và nhiều bộ nhớ hơn.

Tối ưu ở cấp độ mô hình​

Model compression giảm kích thước mô hình, có thể giúp nó nhanh hơn, với một số cách tiếp cận: quantization (giảm độ chính xác số học), pruning (loại bỏ các tham số ít quan trọng hoặc đặt về 0), và distillation (huấn luyện mô hình nhỏ bắt chước mô hình lớn). Trong số này, weight-only quantization phổ biến nhất vì tương đối dễ triển khai, hoạt động tốt ngay với nhiều mô hình mà không cần nhiều công sức, và mang lại lợi ích đáng kể.

Một thách thức khác đặc trưng cho mô hình ngôn ngữ là bản chất autoregressive — chúng sinh văn bản từng token một, tạo ra nút thắt cổ chai tuần tự. Một số kỹ thuật giải quyết giới hạn này:

  • Speculative decoding: dùng một mô hình nhanh hơn nhưng kém mạnh hơn để sinh các token ứng viên, sau đó được xác minh bởi mô hình đích.

    💡 Hình dung: Giống như có một trợ lý soạn sẵn bản nháp phản hồi, còn người quản lý chỉ cần nhanh chóng xem xét và phê duyệt.

  • Inference with reference: sao chép token từ đầu vào khi phù hợp, ví dụ khi trả lời câu hỏi về một tài liệu, thay vì sinh chúng từ đầu — điều này có thể tăng tốc phản hồi đáng kể cho các truy vấn dựa trên tài liệu.

  • Parallel decoding: nhắm tới sinh nhiều token đồng thời, phá vỡ ràng buộc tuần tự.

  • Attention mechanism optimization: cải thiện hiệu quả của các phép tính attention trong Transformer, vốn có thể tốn nhiều bộ nhớ.

Ở mức thấp hơn, kernel và compiler tối ưu cách mô hình chạy trên phần cứng cụ thể. Kernel là mã chuyên biệt được tối ưu cho accelerator phần cứng — các kỹ thuật tối ưu phổ biến gồm vectorization, parallelization, loop tiling, và operator fusion. Compiler kết nối mô hình machine learning với phần cứng, chuyển đổi các phép toán của mô hình thành mã tối ưu cho accelerator cụ thể.

Tối ưu ở cấp độ inference service​

  • Batching: kết hợp nhiều yêu cầu để xử lý cùng nhau. Có thể triển khai theo nhiều cách: static batching (nhóm một số lượng đầu vào cố định, tất cả yêu cầu phải chờ đến khi batch đầy — đơn giản nhưng có thể gây latency không nhất quán), dynamic batching (đặt một cửa sổ thời gian tối đa, xử lý batch khi đầy hoặc hết thời gian — cho độ trễ ổn định hơn), và continuous batching (cho phép trả về phản hồi ngay khi hoàn thành, với yêu cầu mới được thêm vào để duy trì kích thước batch — trải nghiệm người dùng tốt nhất nhưng phức tạp hơn để triển khai).

    💡 Hình dung: Static batching giống xe buýt chỉ chạy khi đủ khách; dynamic batching giống xe buýt chạy đúng giờ dù chưa đầy; continuous batching giống xe buýt cho khách lên xuống liên tục dọc đường mà không cần dừng hẳn để chờ đầy xe.

Batching Strategies ComparedStaticwait until batch fullexecuteDynamicmax wait windowexecute (full or timeout)Continuousalways executing — requests join/leave mid-batchwaiting for batchexecutingrequest arrival/departure
  • Decoupled prefill and decode: tách hai giai đoạn này của inference LLM vì chúng có nhu cầu tính toán khác nhau — xử lý riêng biệt giúp tránh cạnh tranh tài nguyên và cải thiện hiệu quả tổng thể.
  • Prompt caching: lưu trữ các đoạn văn bản chồng lấn như system prompt hoặc tài liệu tham chiếu để tránh xử lý lại chúng với mỗi truy vấn — đặc biệt có giá trị cho ứng dụng có hội thoại dài hoặc nhiều truy vấn về cùng một tài liệu.

Parallelism — Song song hóa​

Khi mô hình lớn dần, một máy đơn lẻ có thể không đủ — đây là lúc parallelism (phân tán công việc trên nhiều máy) phát huy tác dụng:

💡 Hình dung: Replica parallelism giống mở thêm nhiều quầy thu ngân giống hệt nhau để phục vụ song song nhiều khách; model parallelism giống chia một đơn hàng lớn cho nhiều đầu bếp, mỗi người phụ trách một công đoạn của cùng một món ăn.

Parallelism TopologiesReplica Parallelism — independent copiesRequest AModel Replica 1Request BModel Replica 2Request CModel Replica 3Model Parallelism — one model, split across devicesDevice 1Layers 1-10Device 2Layers 11-20Device 3Layers 21-32pipeline parallelism: sequential stagestensor parallelism: split ops within a layer
  • Replica parallelism: tạo nhiều bản sao của mô hình, mỗi bản xử lý các yêu cầu khác nhau — đây là cách tiếp cận đơn giản nhất và hoạt động tốt cho các kịch bản throughput cao.
  • Model parallelism: chia một mô hình đơn lẻ trên nhiều máy, thông qua tensor parallelism (chia nhỏ các phép toán thành các phần nhỏ hơn), pipeline parallelism (chia mô hình thành các giai đoạn tuần tự), context parallelism (chia các chuỗi đầu vào trên nhiều thiết bị), hoặc sequence parallelism (chia các phép toán khác nhau trên nhiều máy).

Kỹ thuật nào nên triển khai phụ thuộc vào workload cụ thể và yêu cầu hiệu năng của bạn. Với các ứng dụng ưu tiên latency thấp, replica parallelism có thể là lựa chọn tốt nhất dù chi phí cao hơn. Với hầu hết trường hợp sử dụng, các kỹ thuật có tác động lớn nhất thường là quantization, tensor parallelism, replica parallelism, và attention mechanism optimization. Bằng cách áp dụng các kỹ thuật này một cách chu đáo, có thể cải thiện đáng kể cả tốc độ và hiệu quả chi phí của ứng dụng AI, giúp chúng phản hồi người dùng tốt hơn trong khi giữ chi phí hạ tầng trong tầm kiểm soát.

11. Kiến trúc ứng dụng AI hoàn chỉnh & Feedback Loop​

Kiến trúc ứng dụng AI đơn giản nhất trông như thế này: ứng dụng nhận một truy vấn, gửi nó tới một mô hình (qua API bên thứ ba hoặc mô hình tự host), và trả kết quả về cho người dùng — không chuông không còi, chỉ đơn giản đầu vào và đầu ra trực tiếp. Nhưng các ứng dụng thực tế hiếm khi giữ được sự đơn giản này. Dưới đây là cách các kiến trúc này thường tiến hóa khi nhu cầu ngày càng phức tạp hơn.

Giai đoạn 1: Xây dựng ngữ cảnh tốt hơn​

Cải tiến đầu tiên hầu hết ứng dụng cần là xây dựng ngữ cảnh (context construction) tốt hơn — cho mô hình quyền truy cập vào thông tin cần thiết để tạo đầu ra hữu ích. Đây về cơ bản là feature engineering cho foundation model — có thể thêm hệ thống RAG để tìm kiếm và truy xuất thông tin từ knowledge base, khả năng agent để thu thập thông tin từ công cụ bên ngoài, chức năng tải lên tài liệu để phân tích nội dung cụ thể, hoặc hơn thế nữa.

Giai đoạn 2: Thêm guardrail để bảo vệ​

Khi ứng dụng phát triển năng lực, cần guardrail để bảo vệ cả hệ thống và người dùng.

💡 Hình dung: Guardrail giống lan can trên cầu — không cản trở việc đi lại bình thường, chỉ ngăn bạn rơi xuống khi có gì đó bất thường xảy ra.

Input guardrail bảo vệ chống rò rỉ thông tin riêng tư ra API bên ngoài và các prompt độc hại có thể xâm hại hệ thống. Output guardrail bắt các loại lỗi khác nhau — lỗi chất lượng (phản hồi rỗng, sai định dạng, nội dung sai sự thật) hoặc lỗi bảo mật (nội dung độc hại, lộ PII, hành động trái phép). Điểm mấu chốt lại là cân bằng giữa bảo vệ và trải nghiệm người dùng — guardrail quá nghiêm ngặt tạo trải nghiệm khó chịu, trong khi guardrail không đủ có thể khiến bạn dễ tổn thương.

Giai đoạn 3: Model routing và Gateway​

Khi ứng dụng trưởng thành, bạn có thể nhận ra một mô hình không đáp ứng được mọi nhu cầu — các truy vấn khác nhau cần cách tiếp cận khác nhau, đây là lúc model routing phát huy tác dụng. Một model router thường bao gồm một bộ phân loại ý định (intent classifier) dự đoán người dùng đang cố làm gì, rồi định hướng truy vấn tới mô hình hoặc pipeline phù hợp. Các router này cần nhanh và rẻ để có thể dùng nhiều router mà không tăng đáng kể latency hay chi phí.

💡 Hình dung: Model gateway giống tổng đài lễ tân khách sạn — khách (request) không cần biết phòng nào (model nào) sẽ phục vụ mình, chỉ cần gọi một số duy nhất; lễ tân lo việc định tuyến, xử lý khi phòng kín (rate limit), và ghi sổ theo dõi nội bộ.

Cùng với routing, bạn sẽ cần một model gateway — một lớp trung gian cung cấp giao diện thống nhất cho các mô hình khác nhau (cả tự host và thương mại), kiểm soát truy cập và quản lý chi phí, chính sách dự phòng (fallback) để xử lý giới hạn tần suất (rate limit) hoặc lỗi API, và cân bằng tải, logging, phân tích. Cách tiếp cận gateway giúp codebase dễ bảo trì hơn nhiều — nếu một model API thay đổi, bạn chỉ cần cập nhật gateway, không phải mọi ứng dụng dùng nó. Đây là ví dụ điển hình của separation of concerns trong kỹ thuật phần mềm.

Giai đoạn 4: Tối ưu với caching​

Khi lượng người dùng tăng, tối ưu hiệu năng và chi phí ngày càng quan trọng — đây là lúc caching phát huy tác dụng. Inference caching bao gồm các kỹ thuật như KV caching để tối ưu cơ chế attention, và prompt caching để tránh xử lý lại các thành phần prompt giống nhau. Caching đặc biệt có giá trị cho các quy trình nhiều bước như suy luận Chain of Thought hoặc các truy vấn cần hành động tốn thời gian như truy xuất hoặc tìm kiếm web. Về triển khai, các lựa chọn trải từ lưu trữ in-memory (nhanh nhưng dung lượng hạn chế) đến database như PostgreSQL và Redis — bạn cũng cần một chính sách loại bỏ (eviction policy) như least recently used (LRU) hoặc least frequently used (LFU) để quản lý kích thước cache khi mở rộng quy mô.

Giai đoạn 5: Logic phức tạp và write action​

Đây là giai đoạn tinh vi nhất mà các ứng dụng AI vươn tới — vượt ra ngoài hỏi đáp đơn giản để kết hợp các luồng suy luận nhiều bước phức tạp, các mẫu hình agentic với vòng lặp và ra quyết định, cùng các write action thực hiện thay đổi lên môi trường. Write action như gửi email, đặt hàng, hoặc khởi tạo giao dịch chuyển tiền làm tăng đáng kể năng lực hệ thống nhưng cũng đưa vào rủi ro đáng kể — cần được triển khai với sự thận trọng và biện pháp bảo vệ phù hợp.

Tổng hợp lại, một kiến trúc ứng dụng AI đã trưởng thành qua cả 5 giai đoạn trên thường trông như sau:

Mature AI Application ArchitectureUser QueryInputGuardrailModel RouterModel GatewayOutputGuardrailResponseModels: RAG · Agent · Fine-tuned · APIcontext construction + write actionsCache (KV / Prompt)Monitoring & Observability — logs every stage

Monitoring và Observability​

Khi kiến trúc ngày càng phức tạp, việc theo dõi mọi thứ trở nên ngày càng khó khăn — đây là lúc monitoring và observability trở nên quan trọng. Dù liên quan, chúng phục vụ mục đích hơi khác nhau: monitoring theo dõi đầu ra bên ngoài để phát hiện khi có gì đó sai, nhưng không nhất thiết giúp xác định nguyên nhân.

💡 Hình dung: Giống như biết xe của bạn bị hỏng nhưng không biết tại sao.

Observability ngược lại, đảm bảo đủ thông tin về trạng thái nội tại của hệ thống được thu thập để khi có gì sai, bạn có thể chẩn đoán vấn đề mà không cần triển khai code mới.

💡 Hình dung: Giống như có cảm biến khắp xe có thể chỉ đích danh chính xác bộ phận nào bị hỏng.

Có ba metric chính giúp đánh giá observability: MTTD (mean time to detection — thời gian trung bình để phát hiện vấn đề), MTTR (mean time to response — thời gian trung bình để phản hồi), và CFR (change failure rate — tỷ lệ phần trăm các lần triển khai dẫn đến lỗi). Mỗi thành phần trong pipeline nên có metric riêng, và cần hiểu các metric này tương quan thế nào với các metric Bắc Đẩu (North Star metric) của doanh nghiệp. Hãy nhớ quy tắc vàng của observability: log mọi thứ — khi metric cho thấy có vấn đề, log chi tiết sẽ giúp xác định chính xác điều gì đã sai.

Orchestrator​

Khi ứng dụng phát triển để bao gồm nhiều mô hình, nguồn dữ liệu và công cụ, việc quản lý các tương tác này có thể ngày càng phức tạp — đây là lúc một orchestrator trở nên có giá trị, giúp chỉ định cách các thành phần này phối hợp với nhau. Các công cụ AI orchestrator như LangChain, LlamaIndex, Flowise, LangFlow, và Haystack giúp quản lý các pipeline phức tạp này. Tuy nhiên, thường nên bắt đầu xây dựng ứng dụng mà không có orchestrator trước, để hiểu rõ cơ chế cốt lõi trước khi thêm một lớp trừu tượng khác.

User Feedback — Tài sản giá trị nhất​

Có lẽ tài sản giá trị nhất trong AI Engineering là user feedback. Feedback này cung cấp dữ liệu độc quyền có thể mang lại lợi thế cạnh tranh thực sự — trong khi ai cũng có thể truy cập cùng các foundation model, chỉ có bạn mới có quyền truy cập vào cách người dùng cụ thể của bạn tương tác với hệ thống.

User feedback đến dưới hai hình thức chính:

  • Explicit feedback: được người dùng cung cấp trực tiếp — như like/dislike, đánh giá sao, hoặc bình luận viết tay.
  • Implicit feedback: được suy ra từ hành vi người dùng — có thể là việc kết thúc sớm, sửa lỗi, làm rõ câu hỏi, tin nhắn phàn nàn, cảm xúc (sentiment), tần suất tạo lại phản hồi (regenerate), và độ dài cuộc hội thoại.

Khi thiết kế hệ thống feedback, cần cân nhắc kỹ thời điểm yêu cầu input — có thể hỏi ở đầu trải nghiệm (như hỏi trình độ ngôn ngữ trong app học ngoại ngữ), khi có điều bất ngờ xảy ra (như thời gian phản hồi chậm), hoặc tại các điểm quyết định tự nhiên (như đưa ra lựa chọn giữa hai phản hồi thay thế). Mục tiêu là thu thập được insight giá trị mà không làm gián đoạn trải nghiệm người dùng — mỗi lần yêu cầu feedback đều tạo ra ma sát (friction), nên cần dùng những cơ hội này một cách khôn ngoan.

Tổng kết​

Dù mỗi thành phần đã được trình bày riêng biệt, một ứng dụng AI trưởng thành tích hợp tất cả các yếu tố này thành một hệ thống gắn kết. Kiến trúc bạn chọn nên phù hợp với use case cụ thể, ràng buộc kỹ thuật, và mục tiêu kinh doanh của bạn. Một điều quan trọng cần nhớ: độ phức tạp cần phục vụ một mục đích — chỉ thêm các thành phần giải quyết vấn đề thực sự cho ứng dụng của bạn. Đôi khi một kiến trúc đơn giản hơn với ít bộ phận chuyển động hơn lại đáng tin cậy và dễ bảo trì hơn một kiến trúc phức tạp với đủ mọi chuông còi.

Lĩnh vực AI Engineering vẫn đang phát triển nhanh chóng, với các kỹ thuật và best practice mới xuất hiện hàng ngày. Các AI Engineer thành công nhất duy trì sự linh hoạt trong kiến trúc của họ, cho phép tích hợp các tiến bộ mới trong khi vẫn cung cấp trải nghiệm ổn định, đáng tin cậy cho người dùng.

12. Cập nhật 2025–2026 (ngoài phạm vi sách/video gốc)​

⚠️ Lưu ý: Mục này không đến từ sách AI Engineering hay video gốc — đây là phần bổ sung từ research độc lập để phản ánh các phát triển sau thời điểm sách/video được thực hiện (2024–2025). Xem mục Nguồn tham khảo cuối bài để biết nguồn cụ thể.

Hai hướng phát triển sau đây mở rộng trực tiếp hai khái niệm đã nêu ở trên — Tools trong chương Agents (mục 7), và kỹ thuật "cho mô hình thời gian để suy nghĩ" trong chương Prompt Engineering (mục 5).

Model Context Protocol (MCP): Anthropic giới thiệu MCP vào cuối năm 2024 — một giao thức mở dựa trên JSON-RPC, chuẩn hóa cách agent kết nối với tool và nguồn dữ liệu bên ngoài. Trước MCP, mỗi cặp (agent framework, tool/data source) cần một connector riêng — bài toán tích hợp M×N. MCP biến nó thành bài toán M+N: một agent chỉ cần nói "ngôn ngữ MCP" là dùng được mọi MCP server, không cần viết connector riêng cho từng tool. Sang năm 2025, MCP được OpenAI, Google và các nền tảng như Cursor, Cline áp dụng, trở thành chuẩn thực tế (de facto standard) cho tool-calling của agent — đúng loại "capability extension tool" và "knowledge augmentation tool" đã mô tả ở mục 7, chỉ khác là giờ được chuẩn hóa thay vì mỗi hệ thống tự định nghĩa giao diện riêng.

Test-time compute và reasoning model: Từ đầu 2025 (đánh dấu bằng việc DeepSeek công bố R1 vào tháng 1/2025), trọng tâm nghiên cứu dịch chuyển từ "huấn luyện mô hình lớn hơn" sang "chi nhiều compute hơn ngay lúc inference". Các reasoning model như OpenAI o1 hay DeepSeek-R1 chủ động sinh ra rất nhiều token suy luận trung gian trước khi đưa ra câu trả lời cuối — về bản chất là tự động hóa và mở rộng quy mô của kỹ thuật Chain of Thought đã nêu ở mục 5, nhưng giờ diễn ra ở tầng inference thay vì chỉ nằm trong prompt. Hệ quả hạ tầng: nhu cầu compute cho inference được dự báo sẽ vượt xa nhu cầu cho training, khiến việc tối ưu inference (mục 10) trở thành bài toán ngày càng quan trọng hơn so với tối ưu training.

Nguồn tham khảo​

Nguồn gốc: AI Engineering in 76 Minutes (Complete Course/Speedrun!) — kênh Marina Wyss - AI & Machine Learning

Ghi chú kỹ thuật (fact-check bổ sung):

  • "Trung tâm dữ liệu tiêu thụ 1–2% điện năng toàn cầu" (mục 2) → số liệu chính xác hơn tính đến 2024 là khoảng 1,5% (415 TWh), dự kiến tăng lên gần 3% vào năm 2030 — thân bài đã cập nhật thành "khoảng 1,5%". Nguồn: IEA — Energy and AI, Energy demand from AI (truy cập 2026-07-10).
  • "Khoảng một nửa dữ liệu crawl là tiếng Anh" (mục 2) → số liệu Common Crawl thực tế là 45–46% — thân bài đã cập nhật thành con số cụ thể này. Nguồn: Common Crawl — Statistics of Monthly Archives, Languages (truy cập 2026-07-10).
  • "OpenAI dùng link Reddit có ít nhất 3 upvote khi huấn luyện GPT-2" (mục 2) → chính xác hơn là "3 karma" (tên dataset là WebText), không hoàn toàn đồng nghĩa với "upvote" đơn thuần — thân bài đã sửa thành "karma". Nguồn: HuggingFace — GPT-2 model card / OpenWebTextCorpus (truy cập 2026-07-10).
  • "Llama 2 tối ưu cho bf16, chất lượng tệ hơn khi load fp16" (mục 8) → đã verify là đúng: nguyên nhân là script convert chính thức từ Meta sang định dạng HuggingFace từng cast nhầm trọng số gốc (bf16) sang fp16, gây chênh lệch chất lượng đo được (ví dụ ~5% trên benchmark GSM8K giữa bf16 và fp32). Nguồn: HuggingFace transformers — GitHub issue #25446 (truy cập 2026-07-10).
  • "Chinchilla scaling law: số token huấn luyện ≈ 20 lần kích thước mô hình" (mục 2) → đã verify khớp với paper gốc Hoffmann et al. 2022 và vẫn được các nghiên cứu sau này xác nhận lại.
  • "Llama 2 7B có 32 attention head" (mục 2) → đã verify khớp với kiến trúc công khai của mô hình (32 layer, hidden dimension 4096, 32 attention head).
  • "OpenAI Evals cho phép chạy khoảng 500 benchmark có sẵn" (mục 4) và "hướng dẫn fine-tuning của OpenAI: ~100 ví dụ với mô hình tiên tiến, ~550.000 ví dụ để các mô hình hội tụ hiệu năng tương tự" (mục 9) → chưa xác minh độc lập được qua tài liệu công khai hiện tại — README của repo OpenAI Evals không công bố con số cụ thể, và tài liệu fine-tuning hiện hành của OpenAI chỉ còn đề cập mốc 50–100 ví dụ, không thấy case study với mốc 550.000. Đây là số liệu theo sách gốc của Chip Huyen, giữ nguyên trong thân bài nhưng chưa xác minh được qua nguồn độc lập.
  • "GPT-4 thường hoạt động tốt hơn khi mô tả tác vụ ở đầu prompt, Llama 3 tốt hơn khi ở cuối" (mục 5) → chưa xác minh độc lập được — không tìm thấy benchmark công khai xác nhận, nhiều khả năng đây là quan sát thực nghiệm riêng trong sách gốc. Giữ nguyên trong thân bài theo đúng nguồn gốc.