Đi tới nội dung

AI Engineer

Xây sản phẩm trên nền LLM: từ gọi API, RAG, agent đến eval và vận hành production

Map này dành cho developer muốn xây tính năng AI thật sự chạy được trong sản phẩm, không phải nghiên cứu hay train model từ đầu. Lộ trình đi từ cách LLM hoạt động ở mức thực dụng, qua model API, prompt và context, RAG, agent, eval, cho tới bảo mật, vận hành và governance. Phù hợp nhất với người đã vững web hoặc backend và muốn chuyển dần sang mảng AI engineering.

Bắt đầu từ chặng 01
chặng
10chặng
chủ đề
58chủ đề
tuần, học part-time
~31tuần, học part-time
  • Nền tảng
  • Cốt lõi
  • Nâng cao
  • TypeScriptTypeScript
  • VercelAI SDK
  • Model Context ProtocolMCP
  • pgvector
  • OpenTelemetry
  • Langfuse
  • promptfoo
  • OllamaOllama

Góc nhìn của mình

Mình là frontend developer, không phải chuyên gia AI hay người làm nghiên cứu ML. Vài năm gần đây mình tích hợp tính năng LLM vào web app và side project: chat có streaming, trích xuất dữ liệu có cấu trúc, một ít retrieval, rồi viết lại trên blog này. Map này là con đường mình sẽ đi nếu bắt đầu làm AI Engineer từ hôm nay, gom từ những gì mình học được khi ship các tính năng đó, đọc docs chính thức và theo dõi những người làm mảng này toàn thời gian. Trọng tâm là xây sản phẩm trên nền model có sẵn, không phải train model.

Điều mình ước biết sớm hơn

  • Điều mình ước biết sớm hơn là phải có bộ eval trước khi chỉnh prompt. Không có tập test cố định thì mình chỉ đang đổi chữ và cầu may.
  • Phần lớn việc khó là kỹ thuật phần mềm bình thường: schema, timeout, retry, logging, phân quyền. Lời gọi model chỉ là phần nhỏ.
  • Lúc mới làm mình hay lôi RAG và framework agent vào quá sớm, trong khi một prompt dài có prompt caching hoặc một chuỗi bước đơn giản đã giải quyết được bài toán.
  • Hãy coi mọi output của model và mọi tài liệu retrieve về là input không tin cậy, giống hệt cách mình xử lý dữ liệu người dùng nhập vào form.
Đã qua 0/10 chặng

Nền tảng01–03

  1. 01Chặng 01, 3 tuầnLLM hoạt động thế nào, ở mức thực dụngGiải thích được token, context window, sampling và embedding đủ để dự đoán chi phí, độ trễ và kiểu lỗi của một tính năng AI.
    Lần đầu gọi LLM API mình coi nó như một hàm tất định và khá bất ngờ khi cùng một input lại ra output khác nhau. Hiểu cơ chế dự đoán token tiếp theo và sampling giúp mình hết bối rối phần lớn.

    Kiến thức cần nắm

    Token và tokenizer
    Model đọc token kiểu BPE chứ không đọc ký tự hay từ, và tiếng Việt thường tốn nhiều token hơn đáng kể so với cùng nội dung bằng tiếng Anh. Giá tiền, giới hạn context và độ trễ đều tính theo token, nên hãy tập đo bằng endpoint đếm token của provider hoặc một tokenizer playground thay vì ước lượng theo số chữ.
    Transformer và dự đoán token tiếp theo
    Khi inference, model tính phân phối xác suất cho token kế tiếp, chọn một token, nối vào rồi lặp lại; cơ chế attention cho phép mỗi token nhìn các token trước đó. Đây là lý do độ trễ tăng theo độ dài output và vì sao time to first token với tokens per second là hai chỉ số khác nhau.
    Context window và giới hạn thật của nó
    Context window chứa chung system prompt, lịch sử hội thoại, tài liệu retrieve, định nghĩa tool và cả output. Window dài không có nghĩa model chú ý đều mọi chỗ: chất lượng giảm khi context phình to và khi thông tin nằm lọt thỏm ở giữa (context rot), nên nhồi thêm context không tự động tốt hơn.
    Sampling: temperature, top_p, stop sequence
    Temperature thấp hợp với trích xuất và phân loại, cao hơn cho brainstorm hoặc viết sáng tạo. Ngay cả temperature 0 trên API hosted cũng không đảm bảo tất định do batching và sai số dấu phẩy động, và một số reasoning model giới hạn hoặc bỏ qua các tham số này.
    Embedding và độ tương đồng
    Embedding model biến đoạn text thành vector mà cosine similarity xấp xỉ mức gần nghĩa. Cần nắm số chiều, chuẩn hoá vector, và việc vector từ hai model khác nhau không so sánh được với nhau, đổi model là phải embed lại toàn bộ.
    Các giai đoạn train và reasoning model
    Pretraining cho kiến thức, instruction tuning và preference tuning cho hành vi, còn reasoning model dùng thêm token suy nghĩ trước khi trả lời. Hiểu chuỗi này giải thích được knowledge cutoff, hallucination, và vì sao thinking budget là đánh đổi giữa độ chính xác với độ trễ và chi phí.

    Nên làm

    • Đo số token trên dữ liệu thật trước khi ước tính chi phí cho một tính năng.
    • Đọc model card, trang pricing và giới hạn rate limit trước khi chọn model.
    • Ghi lại time to first token và tổng thời gian cho từng lời gọi ngay từ prototype đầu tiên.
    • So sánh output trên nhiều lần chạy với cùng input để cảm nhận độ biến thiên.

    Dễ sai

    • Mặc định model biết thông tin mới nhất trong khi nó chỉ biết tới knowledge cutoff.
    • Coi context window như bộ nhớ dùng thoải mái mà không tính chất lượng giảm khi context dài.
    • Tin rằng đặt temperature 0 là output sẽ luôn giống hệt nhau.

    Project chốt chặng: Token và cost explorer

    Làm một trang nhỏ nhận text tiếng Việt và tiếng Anh, hiển thị số token qua API của provider, ước tính chi phí input/output cho 2-3 model, và cosine similarity giữa hai câu qua một embedding API. Đạt khi số liệu khớp với trường usage mà API trả về và trang giải thích được vì sao cùng nội dung tiếng Việt tốn nhiều token hơn.

    • LLM
    • tokens
    • embeddings

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Cơ bảnBạn ước tính chi phí chatbot tiếng Việt bằng cách đếm số từ rồi nhân với tỉ lệ token trên mỗi từ của tiếng Anh. Điều gì sai?
    2. Câu 2/4Cơ bảnVì sao time to first token và tokens per second được theo dõi như hai metric latency riêng?
    3. Câu 3/4Cơ bảnMột test assert chính xác đoạn text mà model hosted trả về ở temperature 0, và thỉnh thoảng lại fail. Vì sao?
    4. Câu 4/4Cơ bảnBạn chuyển sang embedding model mới nhưng chỉ embed tài liệu mới bằng nó, giữ nguyên vector cũ trong index. Điều gì hỏng?
  2. 02Chặng 02, 3 tuầnLàm việc với model APIGọi được model API từ server với streaming, structured output và tool calling, đồng thời kiểm soát được chi phí và độ trễ.
    Bản prototype đầu tiên của mình parse JSON từ text tự do bằng regex và vỡ liên tục. Chuyển sang structured output với schema rõ ràng là thay đổi đáng giá nhất ở giai đoạn này.

    Kiến thức cần nắm

    Messages API và streaming
    Các provider lớn đều theo mô hình danh sách message theo role, trả về qua server-sent events khi bật streaming. Cần hiểu các loại event (delta text, tool call, usage, stop reason) để xử lý đúng khi stream bị cắt giữa chừng hoặc dừng vì chạm max tokens.
    Structured output
    Dùng JSON Schema (thường sinh từ Zod) để provider ép output đúng cấu trúc bằng constrained decoding thay vì chỉ dặn trong prompt. Vẫn phải validate phía server, vì model có thể từ chối, bị cắt do max tokens, hoặc trả về giá trị đúng kiểu nhưng sai nghĩa.
    Tool calling
    Model không tự chạy tool: nó trả về tên tool và tham số, code của bạn thực thi rồi gửi kết quả lại trong message tiếp theo. Nắm parallel tool call, cách trả lỗi tool về cho model như một observation, và việc định nghĩa tool chiếm token trong mỗi request.
    Prompt caching
    Đặt phần cố định (system prompt, tài liệu, định nghĩa tool) ở đầu và phần thay đổi ở cuối để tận dụng cache prefix, giúp giảm mạnh chi phí input và độ trễ. Có provider cache tự động, có provider cần đánh dấu breakpoint rõ ràng, nên hãy đọc trường cached tokens trong usage để biết cache có trúng hay không.
    Ngân sách chi phí và độ trễ
    Output token thường đắt và chậm hơn input, nên giới hạn max output là cách tiết kiệm trực tiếp nhất. Dùng batch API cho việc chạy offline để được giảm giá, đặt timeout, retry với exponential backoff cho lỗi 429 và lỗi quá tải, và luôn tính chi phí theo request lẫn theo user.
    Chọn model: hosted, tier nhỏ hay open-weight
    Model frontier hosted cho chất lượng cao nhất, tier nhỏ hơn của cùng hãng rẻ và nhanh hơn nhiều cho tác vụ hẹp, còn open-weight cho quyền kiểm soát dữ liệu và chi phí ở quy mô lớn. Một lớp trừu tượng provider như AI SDK hoặc một AI gateway giúp đổi model mà không phải viết lại code, và chỉ nên chọn dựa trên eval của chính bạn.

    Nên làm

    • Giữ API key ở server và không bao giờ gọi model API trực tiếp từ trình duyệt.
    • Định nghĩa schema ở một chỗ duy nhất và dùng chung cho structured output lẫn validation.
    • Đặt timeout và max output tokens tường minh cho mọi lời gọi.
    • Log trường usage (input, output, cached tokens) và độ trễ cho từng request.
    • Bọc lời gọi model sau một lớp trừu tượng để đổi provider chỉ bằng config.

    Dễ sai

    • Parse JSON từ text tự do bằng regex thay vì dùng structured output.
    • Dùng model lớn nhất cho mọi lời gọi kể cả tác vụ phân loại đơn giản.
    • Chèn timestamp hoặc dữ liệu thay đổi vào đầu prompt làm prompt cache không bao giờ trúng.

    Project chốt chặng: Trích xuất hoá đơn có kiểu

    Viết một route handler Next.js nhận text hoá đơn, trả về JSON có kiểu qua structured output, stream thêm một đoạn tóm tắt và log token, chi phí, độ trễ. Đạt khi output sai schema bị chặn và retry một lần, đổi provider chỉ cần sửa một dòng config, và có số liệu p95 latency cùng chi phí trung bình mỗi request.

    • API
    • streaming
    • tool calling

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Cơ bảnBạn dùng structured outputs với JSON Schema để provider ép đúng hình dạng. Vì sao vẫn phải validate trên server?
    2. Câu 2/4Cơ bảnKhi model gọi một tool do bạn định nghĩa và cài đặt trong backend của mình, thực tế chuyện gì xảy ra?
    3. Câu 3/4Cơ bảnSystem prompt bắt đầu bằng Current time: 2026-11-02T10:31:07Z, sau đó là 8.000 token hướng dẫn cố định. Số cached token luôn bằng 0. Cách sửa là gì?
    4. Câu 4/4Cơ bảnCác lời gọi model thỉnh thoảng lỗi 429 và lỗi quá tải. Cách xử lý nào đúng?
  3. 03Chặng 03, 2 tuầnPrompt và context engineeringThiết kế được prompt và chiến lược đưa context vào model một cách có cấu trúc, có version và đo được.
    Mình từng viết prompt kiểu càng dài càng an toàn, toàn chữ in hoa và cấm đoán. Hoá ra prompt ngắn, rõ mục tiêu, có ví dụ tốt và context chọn lọc mới cho kết quả ổn định.

    Kiến thức cần nắm

    Cấu trúc một prompt tốt
    Tách rõ vai trò, nhiệm vụ, ràng buộc, định dạng output và dữ liệu đầu vào, thường bằng thẻ XML hoặc heading. Việc phân tách dữ liệu khỏi chỉ dẫn vừa giúp model hiểu đúng, vừa là bước đầu để giảm prompt injection.
    Few-shot examples
    Ví dụ là cách mạnh nhất để chỉ định format và giọng văn, nhưng model sẽ bắt chước cả những điểm lặp lại không mong muốn. Chọn ví dụ đa dạng, sát dữ liệu thật và có cả trường hợp biên.
    Context engineering
    Mỗi lượt gọi là quyết định đưa gì vào window: chỉ dẫn, tài liệu retrieve, bộ nhớ, kết quả tool. Các kỹ thuật chính gồm tóm tắt hoặc compact lịch sử dài, nạp tài liệu đúng lúc cần thay vì nạp hết từ đầu, và loại bỏ kết quả tool cũ không còn liên quan.
    Prompt với reasoning model
    Reasoning model cần ít hướng dẫn từng bước hơn, nhưng cần mục tiêu, tiêu chí thành công và ràng buộc rõ ràng hơn. Hãy điều chỉnh mức thinking budget theo độ khó của tác vụ thay vì bật tối đa cho mọi request.
    Prompt là code
    Lưu prompt trong repo hoặc prompt registry có version, review diff như code, và gắn mỗi thay đổi với kết quả eval. Template hoá phần biến đổi để phần cố định giữ nguyên, vừa dễ đọc vừa tận dụng được prompt caching.

    Nên làm

    • Viết tiêu chí thành công cho tác vụ trước khi viết prompt.
    • Bọc dữ liệu người dùng và tài liệu trong thẻ riêng, tách khỏi phần chỉ dẫn.
    • Đánh version cho prompt và ghi version vào log của mỗi request.
    • Chỉ đưa vào context những gì model cần cho lượt hiện tại.

    Dễ sai

    • Viết chỉ dẫn mâu thuẫn nhau trong system prompt dài rồi đổ lỗi cho model.
    • Sửa prompt dựa trên một hai ví dụ lỗi mà không chạy lại trên bộ test chung.

    Project chốt chặng: Trợ lý soạn trả lời hỗ trợ khách hàng

    Xây trợ lý gợi ý câu trả lời cho ticket hỗ trợ với ba phiên bản prompt, chạy trên cùng 20 input cố định gồm cả tiếng Việt và tiếng Anh. Đạt khi prompt nằm trong repo có version, có bảng so sánh output ba phiên bản, và ghi lại lý do chọn phiên bản cuối.

    • prompting
    • context

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Cơ bảnVì sao nên bọc tài liệu do người dùng cung cấp trong tag riêng, tách khỏi phần hướng dẫn?
    2. Câu 2/4Cơ bảnCả ba ví dụ few-shot trong prompt tóm tắt review đều kết thúc bằng 'Nhìn chung, đánh giá này tích cực.' Điều gì có khả năng xảy ra?
    3. Câu 3/4Cơ bảnMột PM chuyển tiếp hai câu trả lời tệ và nhờ chỉnh nhanh prompt. Quy trình đúng là gì?
    4. Câu 4/4Cơ bảnMột phiên agent dài ngày càng kém đi khi kết quả tool cũ chất đống trong context. Kỹ thuật context engineering nào giúp nhiều nhất?

Cốt lõi04–07

  1. 04Chặng 04, 3 tuầnTrải nghiệm AI trong web appXây được giao diện AI có streaming, xử lý tool call, cho phép dừng, sửa và phản hồi, đồng thời thể hiện rõ mức độ không chắc chắn.
    Đây là phần mình thấy quen tay nhất vì gần với frontend. Điều mình nhận ra là UX tốt cho AI không nằm ở hiệu ứng gõ chữ, mà ở chỗ người dùng kiểm soát được và kiểm chứng được kết quả.

    Kiến thức cần nắm

    Streaming UI
    Dùng hook như useChat của AI SDK hoặc tự đọc stream qua ReadableStream để render text, message part và object có cấu trúc khi đang stream dở. Cần xử lý trạng thái lỗi giữa stream, retry, và giữ lịch sử hội thoại ổn định khi người dùng reload.
    Generative UI và tool call trên giao diện
    Render từng tool call thành component riêng theo trạng thái đang chạy, có kết quả hoặc lỗi, ví dụ một card kết quả tìm kiếm thay vì một đoạn text dài. Với hành động có tác động, hiển thị bước xác nhận ngay trong luồng chat.
    Thể hiện sự không chắc chắn
    Hiển thị nguồn trích dẫn có link tới đúng đoạn, cho người dùng sửa trước khi áp dụng, và có undo. Thiết kế để model nói được tôi không biết thay vì ép nó luôn trả lời.
    Thiết kế cho độ trễ
    Có nút stop thật sự huỷ request upstream bằng AbortController để không tốn token vô ích, hiển thị tiến độ của các bước dài, và cân nhắc resumable stream cho tác vụ chạy lâu. Tác vụ nặng nên chạy nền và báo kết quả khi xong thay vì giữ người dùng chờ.
    Render output an toàn và accessible
    Output của model là input không tin cậy: render markdown qua sanitizer, chặn HTML và link nguy hiểm. Dùng aria-live hợp lý để screen reader đọc kết quả thay vì đọc từng token.
    Thu thập feedback
    Nút thích hoặc không thích, chỉnh sửa của người dùng và việc họ có dùng gợi ý hay không đều là tín hiệu eval quý. Gắn mỗi feedback với trace id để sau này tra lại đúng prompt, context và output.

    Nên làm

    • Cho phép người dùng dừng, sửa và thử lại ở mọi điểm trong luồng AI.
    • Sanitize mọi output của model trước khi render thành HTML.
    • Gắn trace id vào mỗi message để nối feedback với log phía server.
    • Ghi rõ trên giao diện khi nội dung do AI tạo ra.

    Dễ sai

    • Nút stop chỉ ẩn text trên UI trong khi request phía server vẫn chạy và tính tiền.
    • Render markdown từ model bằng dangerouslySetInnerHTML mà không sanitize.
    • Thiết kế giao diện như thể model luôn đúng, không có chỗ cho nguồn hay chỉnh sửa.

    Project chốt chặng: Panel trợ lý viết trong Next.js

    Xây panel gợi ý chỉnh sửa văn bản có streaming, nút stop, hiển thị gợi ý dạng diff với accept hoặc reject, và nút feedback lưu kèm trace id. Đạt khi stop huỷ được request upstream (kiểm tra qua usage), output render qua markdown đã sanitize, và screen reader đọc được kết quả cuối.

    • Next.jsNext.js
    • VercelAI SDK
    • UX

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Trung cấpNút stop của chat ẩn text đang stream, nhưng lượng token trên server vẫn tiếp tục tăng. Còn thiếu gì?
    2. Câu 2/4Trung cấpVì sao markdown do model sinh ra phải được sanitize trước khi render thành HTML?
    3. Câu 3/4Trung cấpNgười dùng screen reader phàn nàn rằng chat đọc to từng token được stream. Cách sửa nào đúng?
    4. Câu 4/4Trung cấpVì sao nên gắn trace id vào mỗi lượt thumbs up hoặc thumbs down trên UI?
  2. 05Chặng 05, 3 tuầnEvaluation: đo trước khi sửaXây được bộ eval gồm dữ liệu, grader và ngưỡng chạy trong CI để mọi thay đổi prompt hoặc model đều có số liệu.
    Mình xếp eval ngay sau phần UX vì đây là chỗ mình làm sai lâu nhất: chỉnh prompt theo cảm tính và chỉ thử vài câu quen thuộc. Có eval rồi thì việc đổi model hay sửa prompt mới hết đáng sợ.

    Kiến thức cần nắm

    Error analysis trước, metric sau
    Đọc 50 đến 100 trace thật, ghi chú và phân nhóm các kiểu lỗi, rồi mới viết eval cho từng nhóm. Metric chung chung như helpfulness score thường không chỉ ra được cần sửa gì.
    Bộ dữ liệu eval
    Kết hợp mẫu từ traffic thật, trường hợp biên và input đối kháng, có nhãn hoặc tiêu chí đạt rõ ràng, và lưu có version như code. Cập nhật bộ eval mỗi khi gặp lỗi mới ở production để lỗi đó không quay lại.
    Các loại grader
    Ưu tiên grader bằng code khi có thể: so khớp chính xác, kiểm tra schema, regex, chạy unit test cho code sinh ra. Dùng LLM-as-judge cho tiêu chí khó viết bằng code, và review của người cho phần quan trọng nhất.
    Bẫy của LLM-as-judge
    Judge có position bias, verbosity bias và xu hướng ưu ái output của chính họ model. Dùng tiêu chí pass/fail nhị phân rõ ràng thay vì thang 1 đến 10, và hiệu chỉnh judge với nhãn của người bằng cách đo mức đồng thuận trước khi tin nó.
    Regression test trong CI
    Chạy eval mỗi khi đổi prompt, model hoặc logic retrieval bằng công cụ như promptfoo hoặc Inspect, với ngưỡng chặn PR khi tỉ lệ đạt giảm. Lưu kết quả theo thời gian để thấy xu hướng thay vì chỉ nhìn một lần chạy.
    Online eval
    Ở production, lấy mẫu trace để chạy grader tự động, theo dõi feedback người dùng, tỉ lệ từ chối, độ trễ và chi phí. A/B test giữa hai phiên bản prompt hoặc model khi thay đổi có ảnh hưởng lớn tới người dùng.

    Nên làm

    • Bắt đầu bằng việc đọc trace thật trước khi chọn metric.
    • Viết tiêu chí pass/fail cụ thể thay vì chấm điểm cảm tính.
    • Đo mức đồng thuận giữa LLM judge và người trước khi dùng judge để chặn release.
    • Thêm mỗi bug production thành một case trong bộ eval.

    Dễ sai

    • Dựa vào benchmark công khai để chọn model cho bài toán riêng của mình.
    • Dùng LLM judge chưa hiệu chỉnh rồi tin tuyệt đối vào điểm số.
    • Bộ eval chỉ toàn câu dễ nên lúc nào cũng đạt gần như tuyệt đối.

    Project chốt chặng: Bộ eval cho trợ lý ở các giai đoạn trước

    Xây bộ eval tối thiểu 50 case có nhãn cho trợ lý ở giai đoạn 02 hoặc 03, gồm grader bằng code và một LLM judge được hiệu chỉnh trên 30 case do người gán nhãn. Đạt khi báo cáo được mức đồng thuận của judge, và CI chặn PR khi tỉ lệ đạt giảm quá ngưỡng đã chọn.

    • evals
    • testing
    • CI

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Trung cấpBạn đang dựng eval cho một bot hỗ trợ mới. Việc đầu tiên nên làm là gì?
    2. Câu 2/4Trung cấpTrước khi cho phép một LLM judge chặn release, bạn cần kiểm chứng điều gì?
    3. Câu 3/4Trung cấpMột tính năng trích xuất các trường của hóa đơn ra JSON. Bạn nên dùng loại grader nào trước tiên?
    4. Câu 4/4Trung cấpEval set của bạn pass khoảng 99% suốt nhiều tháng trong khi người dùng vẫn báo lỗi. Điều đó nhiều khả năng nghĩa là gì?
  3. 06Chặng 06, 4 tuầnRetrieval và RAGXây được pipeline RAG có chunking, hybrid search, rerank và trích dẫn nguồn, đồng thời biết khi nào không nên dùng RAG.
    Mình từng nghĩ RAG là embed hết rồi tìm vector gần nhất. Thực tế phần quyết định chất lượng là chunking, metadata, tìm kiếm kết hợp từ khoá và việc đo retrieval tách riêng khỏi câu trả lời.

    Kiến thức cần nắm

    Khi nào không cần RAG
    Nếu tài liệu đủ nhỏ để nằm trong context, hãy đưa thẳng vào prompt kèm prompt caching. Nếu câu hỏi cần lọc hay tổng hợp dữ liệu có cấu trúc thì dùng SQL hoặc tool. RAG hợp nhất với kho tài liệu lớn, thay đổi thường xuyên và cần trích dẫn.
    Chunking và metadata
    Chia theo cấu trúc tài liệu (heading, đoạn, bảng) thay vì cắt cứng theo số ký tự, cân nhắc kích thước chunk và overlap. Giữ metadata như nguồn, section, ngày cập nhật, quyền truy cập, và cân nhắc contextual retrieval: thêm vài câu mô tả ngữ cảnh tài liệu vào mỗi chunk trước khi embed.
    Embedding và vector store
    Với hệ thống đã có PostgreSQL, pgvector với index HNSW thường là lựa chọn đầu tiên hợp lý, kèm filter theo metadata trong cùng câu query. Vector database chuyên dụng chỉ đáng khi quy mô hoặc yêu cầu vận hành vượt quá Postgres; chọn embedding model qua MTEB rồi kiểm chứng lại trên dữ liệu của mình, nhất là với tiếng Việt.
    Hybrid search và rerank
    Kết hợp full-text search (BM25 hoặc tsvector của Postgres) với vector search rồi trộn bằng reciprocal rank fusion, vì từ khoá chính xác như mã lỗi hay tên riêng thường bị vector bỏ sót. Sau đó rerank top-k bằng cross-encoder hoặc rerank API trước khi đưa vào context.
    Đo retrieval và đo câu trả lời
    Đo retrieval riêng bằng recall@k và MRR trên bộ câu hỏi có đoạn tài liệu đúng được gán nhãn. Sau đó đo câu trả lời về độ bám nguồn (groundedness), trích dẫn đúng chỗ và khả năng từ chối khi không có thông tin.
    Phân quyền và độ tươi dữ liệu
    Lọc theo quyền của người dùng ngay lúc query, không lọc sau khi đã đưa vào prompt. Có pipeline cập nhật index khi tài liệu thay đổi và kế hoạch embed lại toàn bộ khi đổi embedding model.

    Nên làm

    • Thử giải pháp không cần RAG trước, chỉ thêm RAG khi có lý do rõ ràng.
    • Lưu metadata nguồn cho mọi chunk để trích dẫn được tới đúng section.
    • Đo recall@k trước và sau mỗi thay đổi về chunking, embedding hay rerank.
    • Áp quyền truy cập trong câu query retrieval, không phải trong prompt.

    Dễ sai

    • Chỉ dùng vector search nên bỏ lỡ các truy vấn có từ khoá chính xác.
    • Chỉ đánh giá câu trả lời cuối nên không biết lỗi nằm ở retrieval hay ở generation.
    • Nhồi quá nhiều chunk vào context khiến model bị nhiễu và tốn chi phí.

    Project chốt chặng: Hỏi đáp trên chính các bài blog

    Xây hỏi đáp trên các bài MDX song ngữ của blog với pgvector, full-text search của Postgres, reciprocal rank fusion và rerank, có trích dẫn link tới section. Đạt khi bộ 40 câu hỏi báo cáo recall@5 cho ba cấu hình vector, hybrid và hybrid cộng rerank, câu trả lời có nguồn, và hệ thống từ chối khi không tìm thấy đoạn liên quan.

    • RAG
    • pgvector
    • search

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Trung cấpTài liệu sản phẩm của bạn khoảng 30 trang và thay đổi hằng tháng. Người dùng hỏi về chúng. Bạn nên thử gì trước?
    2. Câu 2/4Trung cấpNgười dùng tìm mã lỗi E4021 nhưng vector search trả về các đoạn không liên quan. Nguyên nhân và cách sửa là gì?
    3. Câu 3/4Trung cấpCâu trả lời tệ đi sau khi đổi cách chunking. Làm sao biết lỗi nằm ở retrieval hay generation?
    4. Câu 4/4Trung cấpTrong hệ thống RAG, phân quyền truy cập tài liệu nên được áp ở đâu?
  4. 07Chặng 07, 4 tuầnAgent, tool use và MCPThiết kế được workflow và agent có giới hạn rõ ràng, viết được MCP server và đưa con người vào vòng duyệt ở các bước quan trọng.
    Agent nghe rất hấp dẫn nên mình từng muốn biến mọi thứ thành agent. Bài học là bắt đầu từ workflow đơn giản nhất chạy được, và chỉ cho model tự quyết khi thật sự cần sự linh hoạt đó.

    Kiến thức cần nắm

    Workflow trước, agent sau
    Các pattern như prompt chaining, routing, parallelization, orchestrator-workers và evaluator-optimizer giải quyết được phần lớn bài toán với độ tin cậy cao hơn. Agent tự lập kế hoạch chỉ đáng dùng khi số bước và đường đi không thể biết trước.
    Vòng lặp agent
    Agent là vòng lặp: model gọi tool, nhận kết quả, quyết định bước tiếp cho tới khi dừng. Luôn đặt giới hạn số bước, ngân sách token và thời gian, điều kiện dừng rõ ràng, và trả lỗi tool về cho model như một observation để nó tự điều chỉnh.
    Thiết kế tool cho agent
    Ít tool nhưng tên và mô tả rõ, tham số chặt, output ngắn gọn có thông tin hữu ích, có phân trang và hành động idempotent khi có thể. Định nghĩa tool chiếm context nên quá nhiều tool làm agent chọn sai và tốn chi phí.
    Model Context Protocol (MCP)
    MCP chuẩn hoá cách app (host và client) kết nối với server cung cấp tools, resources và prompts, qua transport stdio cho local hoặc Streamable HTTP cho remote, với cơ chế authorization dựa trên OAuth. MCP hiện thuộc Agentic AI Foundation của Linux Foundation, nên đáng học như một chuẩn chứ không phải tính năng của riêng một hãng.
    Human-in-the-loop
    Hành động không đảo ngược được như gửi email, xoá dữ liệu, thanh toán phải có bước người duyệt. Kết hợp quyền tối thiểu cho từng tool, chế độ dry-run và audit log ghi lại ai duyệt gì.
    Đánh đổi của multi-agent
    Subagent giúp cô lập context và chạy song song các nhánh nghiên cứu, nhưng nhân số token lên nhiều lần và khó debug hơn hẳn. Bắt đầu với một agent, chỉ tách khi đo được lợi ích; với chỉ dẫn dài hạn, cân nhắc các định dạng như AGENTS.md hoặc Agent Skills để nạp đúng lúc cần.

    Nên làm

    • Đặt giới hạn số bước, token và thời gian cho mọi vòng lặp agent.
    • Yêu cầu người duyệt trước mọi hành động ghi hoặc không đảo ngược được.
    • Trace mọi tool call kèm tham số, kết quả và thời gian.
    • Viết eval cho cả quỹ đạo của agent, không chỉ kết quả cuối.

    Dễ sai

    • Cho agent quá nhiều tool với mô tả mơ hồ.
    • Dùng multi-agent khi một workflow cố định là đủ.
    • Cấp cho MCP server hoặc tool quyền rộng hơn mức tác vụ cần.

    Project chốt chặng: MCP server cho dữ liệu của app

    Viết một MCP server với ba tool trên dữ liệu của app (tìm bài viết, lấy bài viết, tạo bản nháp tóm tắt) và một agent trong app dùng server đó. Đạt khi server chạy được với MCP Inspector, agent có giới hạn số bước, mọi tool call đều được trace, và hành động ghi chỉ chạy sau khi người dùng xác nhận.

    • agents
    • Model Context ProtocolMCP
    • tool use

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Trung cấpMột tác vụ luôn chạy cùng các bước: phân loại ticket, lấy thông tin tài khoản, soạn trả lời. Thiết kế nào phù hợp nhất?
    2. Câu 2/4Trung cấpVì sao mọi vòng lặp agent đều phải giới hạn số bước, token và thời gian?
    3. Câu 3/4Trung cấpMột lời gọi tool lỗi vì order id model truyền vào không tồn tại. Code agent của bạn nên làm gì?
    4. Câu 4/4Trung cấpMột MCP server cần được chia sẻ cho nhiều client từ xa trong công ty. Transport nào phù hợp?

Nâng cao08–10

  1. 08Chặng 08, 4 tuầnProduction: observability, bảo mật, tin cậyVận hành được tính năng AI ở production với tracing, guardrail, phòng prompt injection, rate limit và fallback.
    Với mình đây là phần giống backend nhất nhưng có thêm một lớp rủi ro mới: dữ liệu đi vào model cũng có thể là mã độc. Mình học cách nghĩ về prompt injection từ những người làm bảo mật chứ không tự nghĩ ra.

    Kiến thức cần nắm

    Tracing và observability
    Theo semantic conventions GenAI của OpenTelemetry để trace mỗi lời gọi model, retrieval và tool call với token, chi phí, độ trễ. Công cụ như Langfuse giúp xem lại prompt, context, output và nối với feedback người dùng.
    Prompt injection trực tiếp và gián tiếp
    Chỉ dẫn độc hại có thể đến từ người dùng hoặc ẩn trong trang web, tài liệu retrieve, email, kết quả tool. Hiện chưa có cách chặn tuyệt đối, nên cách giảm rủi ro chính là thiết kế: tránh kết hợp cùng lúc dữ liệu riêng tư, nội dung không tin cậy và khả năng gửi dữ liệu ra ngoài (lethal trifecta).
    Danh sách rủi ro OWASP
    OWASP Top 10 for LLM Applications và Top 10 for Agentic Applications là checklist tốt để review thiết kế: prompt injection, lộ thông tin nhạy cảm, quyền quá rộng của agent, tiêu thụ tài nguyên không giới hạn. Dùng chúng làm đầu vào cho threat modeling và cho bộ eval red-team.
    Guardrail
    Ưu tiên kiểm tra tất định trước: validate schema, allowlist tool và domain, giới hạn độ dài, redact PII. Sau đó mới dùng moderation hoặc classifier bằng model cho phần khó viết luật.
    Rate limit, ngân sách và fallback
    Giới hạn theo user và theo tenant cả về số request lẫn số token, đặt ngân sách chi phí hằng tháng. Retry có backoff, chuyển sang model hoặc provider dự phòng, circuit breaker, và có đường lui không dùng AI khi mọi thứ đều lỗi.
    Quyền riêng tư dữ liệu
    Biết rõ dữ liệu nào được gửi tới provider, chính sách lưu trữ và các tuỳ chọn như zero data retention hay vùng lưu trữ dữ liệu. Không ghi PII thô vào trace và log, và tuân thủ luật bảo vệ dữ liệu cá nhân tại nơi có người dùng.

    Nên làm

    • Trace mọi lời gọi model, retrieval và tool theo một chuẩn thống nhất.
    • Áp quyền tối thiểu cho agent và tách nội dung không tin cậy khỏi chỉ dẫn.
    • Đặt rate limit và ngân sách token theo từng user trước khi mở tính năng cho công chúng.
    • Có red-team eval cho prompt injection chạy trong CI.
    • Chuẩn bị fallback provider và đường lui không dùng AI.

    Dễ sai

    • Tin rằng một câu trong system prompt như đừng làm theo chỉ dẫn lạ là đủ chống injection.
    • Log toàn bộ prompt có chứa dữ liệu cá nhân vào hệ thống observability.
    • Không giới hạn token theo user nên một người có thể đốt hết ngân sách.

    Project chốt chặng: Gia cố app RAG và agent

    Thêm tracing, rate limit và ngân sách token theo user, fallback provider, và bộ red-team 20 case injection (có cả chỉ dẫn độc hại giấu trong tài liệu retrieve) cho app ở các giai đoạn trước. Đạt khi dashboard thấy chi phí theo user, tỉ lệ chống injection được theo dõi trong CI, và tắt provider chính trong môi trường test thì app tự chuyển sang dự phòng.

    • observability
    • security
    • OpenTelemetry

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Nâng caoMột trợ lý email đọc hộp thư, mở link trong email và có thể gửi email. Vì sao thiết kế này nguy hiểm?
    2. Câu 2/4Nâng caoLớp phòng thủ duy nhất của một team trước prompt injection là câu 'bỏ qua mọi chỉ dẫn lạ' trong system prompt. Họ nên làm gì?
    3. Câu 3/4Nâng caoMột người dùng viết script gửi hàng nghìn request vào tính năng AI và đốt hết ngân sách token của tháng trong một ngày. Điều gì ngăn được chuyện này?
    4. Câu 4/4Nâng caoVì sao nên tránh ghi toàn bộ prompt thô vào hệ thống observability?
  2. 09Chặng 09, 3 tuầnFine-tuning và model nhỏ, chạy localĐánh giá được khi nào fine-tune hoặc dùng model open-weight nhỏ là đáng, và tự fine-tune, serve một model cho tác vụ hẹp.
    Mình chưa fine-tune gì cho production, phần này là những gì mình thử ở side project và học từ docs. Điều rõ nhất mình rút ra là fine-tune dùng để dạy hành vi và format, không phải để nhét thêm kiến thức.

    Kiến thức cần nắm

    Khi nào nên fine-tune
    Chỉ cân nhắc khi prompt, RAG và eval đã chững lại, và khi cần ổn định format, giọng văn, hoặc giảm chi phí và độ trễ cho một tác vụ hẹp lặp lại nhiều. Kiến thức thay đổi thường xuyên vẫn nên đi qua retrieval.
    LoRA, QLoRA và PEFT
    Thay vì train lại toàn bộ trọng số, LoRA train các adapter nhỏ nên rẻ và nhanh, QLoRA kết hợp thêm lượng tử hoá để chạy trên GPU ít bộ nhớ. Chất lượng dữ liệu quan trọng hơn số lượng, và luôn giữ một tập eval tách riêng để so với baseline.
    Distillation
    Dùng output của model lớn để tạo dữ liệu train cho model nhỏ thực hiện một tác vụ cụ thể. Phải đọc kỹ điều khoản sử dụng của provider và license của model trước khi làm.
    Model open-weight và license
    Hugging Face Hub là nơi tìm và so sánh model open-weight; mỗi họ model có license riêng, có cái giới hạn mục đích thương mại hoặc quy mô người dùng. Đọc license trước khi đưa vào sản phẩm.
    Inference local và serving
    Ollama tiện cho phát triển local, llama.cpp với định dạng GGUF cho phép lượng tử hoá 4-bit hoặc 8-bit đánh đổi chất lượng lấy bộ nhớ, còn vLLM phù hợp khi cần throughput cao. Hầu hết đều có endpoint tương thích OpenAI nên đổi qua lại dễ dàng.
    Model nhỏ trên thiết bị và trình duyệt
    Model nhỏ làm rất tốt phân loại, routing, embedding và trích xuất đơn giản, có thể chạy trong trình duyệt qua WebGPU với Transformers.js. Kiến trúc kết hợp model nhỏ cho bước đơn giản và model lớn cho bước khó đang ngày càng phổ biến.

    Nên làm

    • Có baseline bằng prompt trên model hosted trước khi fine-tune.
    • So sánh trên cùng bộ eval về độ chính xác, độ trễ và chi phí mỗi nghìn request.
    • Đọc license model và điều khoản provider trước khi dùng dữ liệu hay trọng số.

    Dễ sai

    • Fine-tune để thêm kiến thức thay vì dùng retrieval.
    • Chỉ nhìn điểm benchmark mà bỏ qua chi phí vận hành GPU và độ phức tạp khi tự host.

    Project chốt chặng: Model nhỏ phân loại ticket

    Fine-tune một model open-weight nhỏ bằng LoRA để phân loại ticket hỗ trợ vào 8 nhóm, rồi so với model hosted dùng prompt trên cùng bộ eval. Đạt khi có bảng so sánh độ chính xác, độ trễ, chi phí mỗi nghìn request, và model được serve qua Ollama hoặc vLLM với endpoint tương thích OpenAI.

    • fine-tuning
    • LoRA
    • open-weight

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Nâng caoMột team muốn fine-tune model để nó biết bảng giá của tuần này. Cách nào tốt hơn?
    2. Câu 2/4Nâng caoLoRA khác gì so với full fine-tuning?
    3. Câu 3/4Nâng caoTrước khi fine-tune một model nhỏ để phân loại ticket, bạn cần thiết lập điều gì?
    4. Câu 4/4Nâng caoVì sao phải đọc license của model open-weight trước khi đưa vào sản phẩm?
  3. 10Chặng 10, 2 tuầnResponsible AI và governanceĐánh giá được rủi ro của một tính năng AI, ghi lại bằng system card và đưa các kiểm soát cần thiết vào quy trình phát triển.
    Ban đầu mình nghĩ phần này là việc của pháp chế. Thực tế nhiều quyết định như gửi dữ liệu gì cho provider hay có cần người duyệt không nằm ngay trong code mình viết.

    Kiến thức cần nắm

    Khung đánh giá rủi ro
    NIST AI RMF chia việc quản lý rủi ro thành govern, map, measure, manage, đủ thực dụng để áp vào từng tính năng. Dùng nó để trả lời ai chịu trách nhiệm, tác hại có thể là gì, đo bằng cách nào và xử lý ra sao.
    Quy định pháp lý
    EU AI Act phân loại hệ thống theo mức rủi ro và có nghĩa vụ minh bạch như thông báo người dùng đang tương tác với AI và gắn nhãn nội dung do AI tạo, áp dụng theo từng giai đoạn. Kiểm tra cả quy định tại nơi có người dùng, ví dụ luật bảo vệ dữ liệu cá nhân của Việt Nam.
    Công bằng và chất lượng theo nhóm
    Chia kết quả eval theo ngôn ngữ, nhóm người dùng và loại input để thấy chỗ model kém hơn, ví dụ tiếng Việt so với tiếng Anh. Một con số trung bình đẹp có thể che mất nhóm bị phục vụ tệ.
    Minh bạch và tài liệu
    Viết system card cho tính năng: mục đích, phạm vi không hỗ trợ, dữ liệu đi đâu, kết quả eval, các kiểu lỗi đã biết. Hiển thị rõ trên giao diện khi nội dung do AI tạo và cân nhắc C2PA cho nguồn gốc của media được sinh ra.
    Giám sát và phản ứng sự cố
    Mỗi tính năng AI cần một người chịu trách nhiệm, quy trình xử lý khi có output gây hại, và kill switch qua feature flag. Giữ trace đủ để điều tra lại một sự cố mà không vi phạm quyền riêng tư.

    Nên làm

    • Viết system card ngắn cho mỗi tính năng AI trước khi release.
    • Thêm checklist rủi ro AI vào template pull request.
    • Báo cáo kết quả eval theo từng ngôn ngữ và nhóm người dùng.
    • Đặt mọi tính năng AI sau feature flag có thể tắt ngay.

    Dễ sai

    • Coi governance là tài liệu viết một lần rồi bỏ quên.
    • Chỉ báo cáo điểm trung bình mà không xem từng nhóm người dùng.

    Project chốt chặng: System card và checklist cho app

    Viết system card một trang cho app RAG và agent đã xây, kèm checklist AI trong template PR gồm mục đích, phạm vi, dữ liệu gửi tới provider nào, kết quả eval theo ngôn ngữ, lỗi đã biết và người xử lý sự cố. Đạt khi kill switch đã được test thật và kết quả eval được tách riêng cho tiếng Việt và tiếng Anh.

    • governance
    • responsible AI

    Kiểm tra nhanh

    Đã trả lời 0/4 · đúng 0

    Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

    1. Câu 1/4Nâng caoĐộ chính xác eval tổng thể là 92%. Vì sao vẫn cần báo cáo kết quả theo từng ngôn ngữ và nhóm người dùng?
    2. Câu 2/4Nâng caoMột tính năng AI vừa ra mắt bắt đầu sinh ra nội dung có hại. Điều gì lẽ ra phải có sẵn?
    3. Câu 3/4Nâng caoNIST AI RMF tổ chức việc quản lý rủi ro AI như thế nào?
    4. Câu 4/4Nâng caoBạn đang viết system card cho một tính năng AI mới trước khi release. Nội dung nào nên có?

Xu hướng của role

Những gì đang quan trọng lúc này và hướng đi trong vài năm tới.

Hiện tại

  • Eval là kỹ năng cốt lõi

    Các team làm AI nghiêm túc đã chuyển từ thử theo cảm tính sang eval có dữ liệu, grader và ngưỡng trong CI. LLM judge được hiệu chỉnh theo tiêu chí riêng của từng sản phẩm đang thay cho việc nhìn benchmark công khai.

  • Context engineering quan trọng hơn câu chữ prompt

    Chất lượng phụ thuộc nhiều vào việc đưa đúng thông tin vào đúng lúc: tài liệu, bộ nhớ, định nghĩa tool, kết quả tool. Biết compact, tóm tắt và nạp tài liệu đúng lúc cần là kỹ năng được đánh giá cao.

  • Agent ở production cần giới hạn rõ ràng

    Agent đã ra production nhưng đi kèm giới hạn bước, quyền tối thiểu, người duyệt và trace đầy đủ. MCP đã trở thành lớp kết nối phổ biến giữa model với tool và dữ liệu.

  • Kỹ thuật chi phí và độ trễ

    Prompt caching, batch API, routing giữa model lớn và nhỏ, giới hạn token theo user giờ là việc bình thường của AI engineer. Chi phí trên mỗi tác vụ thành công là chỉ số được theo dõi sát như latency.

Sắp tới

  • Chuẩn mở cho agent hội tụ

    MCP, AGENTS.md, Agent Skills và A2A đang được gom về Agentic AI Foundation của Linux Foundation. Hãy học protocol và khái niệm nền thay vì gắn chặt vào một framework, vì framework sẽ còn thay đổi nhanh.

  • Bảo mật agent thành một chuyên ngành

    Khi agent cầm quyền thật, các vấn đề như định danh và phân quyền cho agent, chiếm quyền mục tiêu, đầu độc bộ nhớ sẽ cần quy trình riêng. Làm quen sớm với threat modeling và red-team eval sẽ là lợi thế.

  • Quy định và kiểm toán chặt hơn

    Nghĩa vụ của EU AI Act tiếp tục có hiệu lực theo giai đoạn và nhiều nước có luật riêng về AI và dữ liệu. Thói quen viết system card, lưu trace và eval theo nhóm người dùng sẽ trở thành yêu cầu chứ không còn là điểm cộng.

  • Đa model và model nhỏ chạy gần người dùng

    Hệ thống sẽ dùng nhiều model cùng lúc, kể cả model nhỏ chạy local hoặc trên thiết bị cho bước đơn giản. Xây kiến trúc không phụ thuộc provider và có eval để đổi model trong vài giờ thay vì vài tuần.

Đi hết roadmap, bạn sẽ

  • Bạn có thể ước tính chi phí và độ trễ của một tính năng AI từ số token thật trước khi build.
  • Bạn có thể xây API dùng LLM với streaming, structured output, tool calling, prompt caching và fallback provider.
  • Bạn có thể xây pipeline RAG với hybrid search, rerank, trích dẫn và đo được recall của retrieval.
  • Bạn có thể thiết kế agent và MCP server có giới hạn bước, quyền tối thiểu và bước người duyệt.
  • Bạn có thể xây bộ eval có grader bằng code và LLM judge đã hiệu chỉnh, chạy trong CI.
  • Bạn có thể vận hành tính năng AI với tracing, rate limit, phòng prompt injection và system card.

Bài viết liên quan

Tất cả bài viết

Model Context Protocol thực chiến: xây MCP server production bằng TypeScript

MCP không phải phép màu, chỉ là một giao thức JSON-RPC được thiết kế tốt. Bài này giải thích host, client, server, các primitive và transport theo spec 2026-07-28, rồi dựng một server TypeScript chỉ đọc cho dữ liệu đơn hàng: thiết kế tool, phân trang, test bằng Inspector, OAuth cho remote server và những lỗ hổng bảo mật cần chặn.

Công cụ & quy trình20 phút

Đánh giá tính năng LLM: biết nó chạy đúng và giữ cho nó đúng

Xây golden dataset từ usage thật, kiểm tra deterministic trước, LLM-as-judge với rubric và các bias của nó, so sánh pairwise, chạy eval trong CI khi đổi prompt hay model, theo dõi chi phí và độ trễ cùng chất lượng, tín hiệu online, tracing, và cách tránh overfit bộ eval.

Hệ thống & kiến trúc9 phút

RAG trả lời đúng trong thực tế: chunking, hybrid search với pgvector, reranking và đánh giá

Demo RAG thì ai cũng dựng được trong một buổi chiều; làm cho nó trả lời đúng mới là phần khó. Bài này đi qua một pipeline RAG viết bằng TypeScript trên PostgreSQL/pgvector: chunking theo cấu trúc, hybrid search gộp bằng RRF trong một câu SQL, reranking, phân quyền trước khi xếp hạng, trích dẫn và cách đo chất lượng bằng con số.

Hệ thống & kiến trúc30 phút

Câu hỏi phỏng vấn AI Engineer

Xem cả 31 câu

Các role khác

Roadmap

Frontend Engineer

Role chính của mình

Xây giao diện web nhanh, dễ tiếp cận và bền vững khi sản phẩm lẫn team cùng lớn lên

10 chặng, 51 chủ đề, ~34 tuần

Backend Engineer

Thiết kế, xây dựng và vận hành API, dữ liệu và service phía sau mỗi sản phẩm

10 chặng, 52 chủ đề, ~37 tuần

Mobile Engineer

Xây app iOS và Android mượt, chạy được khi mất mạng và phát hành an toàn

10 chặng, 50 chủ đề, ~34 tuần

QA / Test Engineer

Tìm rủi ro trước người dùng và biến chất lượng thành thứ cả team đo được

10 chặng, 50 chủ đề, ~36 tuần

DevOps / Platform Engineer

Xây hạ tầng, pipeline và nền tảng để team ship nhanh, chạy ổn định, an toàn

10 chặng, 56 chủ đề, ~42 tuần