---
title: "Xây dựng tính năng LLM có phạm vi rõ ràng - task contract, prompt, structured output, eval và failure handling"
description: "Khoá học giúp bạn đặt phạm vi rõ ràng cho tính năng LLM, chọn dữ liệu và cấu hình theo việc cần làm, kiểm tra output theo cả schema lẫn business invariant, đọc failure path, đánh giá bằng evidence và bàn giao một phiên bản người khác kiểm lại được. Nội dung giữ provider-neutral: model là một thành phần trong hệ thống."
canonical: "https://200lab.io/courses/xay-dung-tinh-nang-llm-co-pham-vi-ro-rang-task-contract-prompt-structured-output-eval-va-failure-handling"
type: "course"
course_type: "course"
learning_type: "free_form"
published: "2026-09-23T11:05:33Z"
students: 126
---

## Khoá học này mang lại gì cho bạn

Phần lớn thời gian xây một tính năng LLM trôi qua ở những chỗ ít khi được đem đi khoe: viết ra việc cần làm cho đủ rõ, quyết định dữ liệu nào được phép đi vào context, kiểm tra output trước khi nó chạm tới dữ liệu thật, và giải thích được vì sao phiên bản mới tốt hơn phiên bản cũ. Một demo chạy được chỉ cần model đoán đúng vài lần. Muốn một tính năng sống được lâu trong sản phẩm, team cần biết nó sai ở đâu, sai thì chuyện gì xảy ra tiếp theo, và ai là người chịu trách nhiệm cho hành động cuối cùng. Khoá học này tập trung đúng vào khoảng cách đó.

- **Viết phạm vi của một tính năng LLM** thành một contract có input, output, ranh giới và cách kiểm tra, trước khi bàn tới chuyện chọn model nào.
- **Chọn dữ liệu và cấu hình theo việc cần làm**: dữ liệu nào thật sự cần đi vào context, ví dụ trong prompt đang dạy model điều gì, temperature và token limit nên đặt theo tiêu chí nào.
- **Kiểm tra output theo hai lớp**: schema cho hình dạng, business invariant cho ý nghĩa; một kết quả đúng khuôn JSON vẫn có thể là một quyết định sai.
- **Đọc failure path như một phần của thiết kế**: timeout, refusal, truncation, retry budget và những trạng thái mà ứng dụng buộc phải xử lý.
- **Giữ ranh giới quyền hành động**: model đề xuất, ứng dụng kiểm tra permission rồi mới quyết định thực thi, từ chối hay chuyển cho người review.
- **Đánh giá thay đổi bằng evidence**: giữ lại những lần chạy thử (trial) quan sát lại được, viết eval case và rubric sao cho phép chấm không tự đánh lừa chính nó.
- **Bàn giao một phiên bản kiểm lại được**: observability, cost, recovery và version đủ để người khác dựng lại kết quả mà không cần hỏi bạn.

Sau khoá học, câu hỏi đầu tiên của bạn khi nhận một yêu cầu dùng LLM sẽ không còn là “dùng model nào”, mà là “việc cần làm là gì, kiểm tra bằng cách nào, và hỏng thì ứng dụng phản ứng ra sao”.

## Khoá học cung cấp những nền tảng nào

Các nền tảng dưới đây xếp theo đúng thứ tự một tính năng LLM đi qua trong thực tế: từ lúc việc cần làm mới chỉ là ý tưởng của một người khác, tới lúc có một phiên bản được bàn giao kèm bằng chứng. Mỗi nhóm giải quyết một loại quyết định riêng, và nhóm sau dựa trên kết luận của nhóm trước.

### 1. Việc cần làm và baseline trước khi có model

Trước khi hỏi model nào phù hợp, bạn cần một bounded task contract: việc này nhận gì vào, phải trả ra cái gì, ranh giới của nó dừng ở đâu, và trường hợp nào nằm ngoài ranh giới đó. Phần lớn tính năng thất bại ngay tại đây, vì yêu cầu được mô tả bằng một câu mong muốn thay vì một contract kiểm tra được. Bạn cũng học cách dựng deterministic baseline, nghĩa là phần việc mà code thông thường, không dùng LLM, vẫn làm đúng và rẻ hơn, để biết LLM thật sự đang thêm giá trị ở đoạn nào. Cuối cùng là exception path: những đầu vào mà câu trả lời đúng duy nhất là từ chối xử lý và chuyển hướng.

### 2. Bên trong một lời gọi LLM

Nhóm này xây mental model về điều model biết và không biết khi nhận một request. Mỗi lần model tạo câu trả lời, nó dựa vào đúng ba nguồn: kiến thức đã học nằm trong weights, context của chính lần xử lý này, và phần nội dung nó vừa sinh ra. Dữ kiện riêng của bài toán chỉ có mặt ở nguồn thứ hai, tức là khi ứng dụng hoặc dịch vụ bạn đang dùng đặt nó vào context: model không tự mở database của bạn, không tự biết quyền của người dùng đang gọi, không tự thấy trạng thái nội bộ mà hệ thống đang giữ. Lịch sử trò chuyện cũng vậy: bản thân model không tự nhớ cuộc trò chuyện hôm qua, nhưng một ứng dụng hay dịch vụ có thể lưu lại hoặc tóm tắt lịch sử rồi gửi kèm vào request sau. Từ đó, bạn nhìn một lời gọi LLM như một request/response contract bình thường: phần nào là instruction, phần nào là dữ liệu, phần nào là cấu hình, và phần nào là thứ ứng dụng phải tự chịu trách nhiệm. Contract này được mô tả theo cách không phụ thuộc provider, nên khi đổi nhà cung cấp bạn biết cái gì đổi tên và cái gì đổi bản chất.

### 3. Context và cấu hình: chọn những gì được đưa vào context

Khi đã biết dữ kiện riêng của bài toán chỉ đến được với model qua context, việc chọn dữ liệu trở thành một quyết định thiết kế chứ không phải thao tác nối chuỗi. Bạn học cách chọn input và sắp xếp context (input selection, context assembly) theo việc cần làm, đồng thời giữ data boundary cho những dữ liệu không được phép rời khỏi hệ thống. Kế đó là vai trò của instruction và few-shot example: mỗi ví dụ bạn đặt vào prompt đang dạy model một quy tắc, kể cả quy tắc bạn không định dạy, và khi ví dụ mâu thuẫn với chỉ dẫn, bạn cần biết chuyện gì sẽ xảy ra cùng cách xử lý mâu thuẫn đó. Nhóm này khép lại ở model selection cùng các tham số như temperature, sampling và token limit, chọn theo đặc điểm của việc cần làm thay vì theo thói quen.

### 4. Kiểm tra output: schema và business invariant

Một output parse được không có nghĩa là nội dung của nó dùng được. Schema kiểm tra hình dạng: đủ field, đúng kiểu, đúng enum. Business invariant kiểm tra ý nghĩa: ngày kết thúc không đứng trước ngày bắt đầu, tổng tiền khớp với các dòng chi tiết, mã sản phẩm được trả về phải tồn tại thật trong hệ thống. Bạn học cách đặt hai lớp kiểm tra này đúng chỗ, yêu cầu evidence kèm theo kết luận của model khi cần truy lại, và thiết kế fallback cho lúc output không vượt qua được lớp nào.

### 5. Failure path và quyền hành động

Mọi lời gọi LLM đều có thể không trả về điều ứng dụng chờ đợi: timeout giữa chừng, response bị cắt ngang vì chạm token limit, model từ chối trả lời, hoặc provider trả về lỗi tạm thời. Bạn học cách đọc provider/client contract để biết mỗi tình huống lộ ra dưới dạng nào, và cách đặt retry budget sao cho không biến một sự cố nhỏ thành một cơn bão request. Song song đó là ranh giới quan trọng nhất của cả khoá: model đề xuất, ứng dụng mới là nơi quyết định được làm gì. Permission check, human review và bounded execution handoff nằm ở phía ứng dụng, và không một prompt nào thay thế được chúng.

### 6. Evidence, eval và bàn giao

Nhóm cuối trả lời câu hỏi mà mọi team đều gặp sau vài tuần: làm sao biết phiên bản mới tốt hơn. Bạn học cách giữ lại observable trial cùng context boundary để hai phiên bản thật sự được so sánh trong cùng điều kiện, rồi viết eval case, rubric và grader sao cho phép chấm không tự đánh lừa chính nó, đặc biệt là tránh data leakage khi ví dụ dùng để chấm đã nằm sẵn trong prompt. Khi kết quả sai, bạn có một đường lần ngược end-to-end để tìm nguyên nhân thay vì sửa prompt theo cảm giác. Điểm đến là một handoff có evidence, observability, cost, đường recovery và version rõ ràng, để người tiếp nhận kiểm lại được mà không phải tin lời ai.

## Vì sao 200Lab tạo ra khoá học này

Gọi một API LLM chưa bao giờ dễ như bây giờ. Vài dòng code là có response, thêm một buổi chiều là có demo đủ đẹp để trình bày. Chính vì bước đầu quá nhẹ, khoảng cách giữa demo và một tính năng sống được trong sản phẩm lại càng dễ bị đánh giá thấp. Rất nhiều team trải qua giai đoạn hưng phấn rồi dừng lại ở cùng một chỗ: tính năng chạy đúng khi được xem tận mắt, và không ai dám bật nó cho toàn bộ người dùng.

Cái bẫy phổ biến nhất là dần dần xem model như nơi ra quyết định. Nghiệp vụ chưa rõ thì viết thêm vào prompt. Có trường hợp ngoại lệ thì dặn model đừng làm thế. Cần kiểm tra quyền thì nhắc model nhớ kiểm tra quyền. Prompt phình ra thành một tài liệu đặc tả không ai đọc nổi, trong khi phần quyết định thật sự của sản phẩm thì không nằm ở nơi có thể test, review hay audit được. Đến lúc đổi model hoặc đổi phiên bản, mọi thứ vỡ cùng một lúc và không ai chỉ ra được nguyên nhân.

Nhìn lại nhiều sản phẩm khác nhau, có thể thấy phần bền vững luôn nằm ở cùng những chỗ: việc cần làm được viết thành contract, input được chọn có chủ đích, output được kiểm tra hai lớp, failure path được thiết kế trước, quyền hành động thuộc về ứng dụng, và thay đổi được chứng minh bằng evidence. Những thứ đó không phụ thuộc provider nào, cũng không hết hạn khi có model mới ra mắt. Ngược lại, phần phụ thuộc mạnh vào một model cụ thể thường là phần phải làm lại sớm nhất.

Khoá học này được tạo ra để đặt trọng tâm vào phần bền vững đó. 200Lab chọn hướng provider-neutral và tập trung vào khả năng phán đoán kỹ thuật: bạn học cách ra quyết định và kiểm tra lại chính quyết định đó, thay vì học thuộc cấu hình của một nhà cung cấp trong một quý nhất định.

## Những vấn đề thường gặp khi xây tính năng LLM

Những tình huống dưới đây lặp lại đủ nhiều để trở thành dấu hiệu nhận biết. Điều đáng chú ý là triệu chứng thì rất khác nhau, còn nguyên nhân thường quay về cùng một nhóm quyết định bị bỏ qua từ đầu.

- Prompt chạy tốt trên vài ví dụ rồi sai ngay khi gặp dữ liệu thật — việc cần làm chưa từng được viết thành contract có input, output và ranh giới rõ.
- Output đúng JSON schema nhưng nội dung vô lý về nghiệp vụ — lớp validation mới kiểm tra hình dạng, chưa kiểm tra business invariant.
- Prompt ngày càng dài vì mỗi lỗi lại thêm một câu dặn dò — các ngoại lệ đang được nhét vào model thay vì được xử lý bằng exception path trong ứng dụng.
- Đổi model thấy “có vẻ tốt hơn” nhưng không chứng minh được — không có observable trial nào được giữ lại để so sánh hai phiên bản trong cùng điều kiện.
- Eval cho điểm rất cao trong khi người dùng vẫn phàn nàn — rubric chấm theo cảm tính hoặc ví dụ dùng để chấm đã rò rỉ vào chính prompt.
- Tính năng hỏng trên production mà không ai biết tìm từ đâu — request, context và response không được ghi lại đủ để lần ngược nguyên nhân.
- Ứng dụng thực hiện một hành động ngoài phạm vi vì model đề xuất như vậy — quyền hành động bị giao cho output thay vì đi qua permission check.
- Chi phí và độ trễ tăng dần không rõ lý do — context được nhồi thêm dữ liệu mỗi lần sửa lỗi, và chưa ai kiểm tra lại thứ gì thật sự cần gửi đi.

Khi nhìn theo nguyên nhân thay vì triệu chứng, những sự cố trông rời rạc này lộ ra thành một danh sách ngắn các quyết định cần được đặt đúng chỗ.

## Bạn sẽ học theo cách nào

- **Đi từ tình huống sản phẩm.** Mỗi chủ đề mở ra bằng một hoàn cảnh bạn có thể gặp khi xây tính năng, rồi mới đi tới nguyên tắc phía sau, thay vì bắt đầu bằng định nghĩa.
- **Làm rõ các phân biệt kỹ thuật.** Trọng tâm là những phân biệt dễ trộn lẫn nhưng quyết định kết quả: schema và invariant, đề xuất và hành động, thử nghiệm và evidence, giới hạn của model và giới hạn của hệ thống.
- **Dùng visual khi quan hệ cần được nhìn thấy.** Ở những chỗ mà chữ khó diễn đạt thứ tự hoặc ranh giới, bạn có hình minh họa tĩnh để thấy luồng đi và điểm dừng; phần còn lại vẫn đọc trọn vẹn bằng chữ.
- **Giữ provider-neutral xuyên suốt.** Ví dụ được mô tả ở mức contract và hành vi, nên điều bạn học áp dụng được cho nhà cung cấp mà team đang dùng, kể cả khi lựa chọn đó thay đổi.

## Khoá học dành cho ai

1. **Developer đang xây hoặc chuẩn bị xây tính năng LLM trong sản phẩm** — bạn đã có tính năng chạy được hoặc sắp bắt tay vào làm, và cần một khung quyết định cho phạm vi, dữ liệu, validation và failure path thay vì tiếp tục chỉnh prompt theo cảm giác.
2. **Technical lead cần review scope, failure handling, evidence và tiêu chí chấp nhận** — khoá học cho bạn bộ câu hỏi để đặt ra trước khi duyệt một tính năng LLM, cùng cách diễn đạt tiêu chí chấp nhận sao cho kiểm lại được.
3. **Developer ứng dụng muốn có nền tảng đúng ngay từ đầu** — bạn không cần từng vận hành một hệ thống Agent phức tạp. Kiến thức lập trình ứng dụng và khả năng đọc contract kỹ thuật là đủ để theo được toàn bộ nội dung.

## Những điều cần lưu ý

- Khoá học không chọn giúp bạn một model tốt nhất cho mọi sản phẩm. Thứ bạn nhận được là bộ tiêu chí để tự chọn theo việc cần làm, và cách kiểm tra lại lựa chọn đó khi bối cảnh thay đổi.
- Khoá học không thay thế việc thử nghiệm trên dữ liệu thật của team bạn. Bạn nhận cách thiết kế trial và eval case để chạy trên chính dữ liệu đó, cùng cách đọc kết quả sao cho con số không nói quá điều nó chứng minh được.
- Không có kỹ thuật nào ở đây bảo đảm output luôn đúng chỉ nhờ prompt hay schema. Thay vào đó, bạn học cách dựng lớp validation, fallback và ranh giới quyền hành động để một output sai không trở thành một hành động sai.
- Khoá học hiện chưa kèm lab, challenge, exercise hay starter repository. Nội dung đi theo hướng giải thích, tình huống, ví dụ và hình minh họa tĩnh, tập trung vào khả năng phán đoán và nền tảng thiết kế để bạn áp dụng trực tiếp vào codebase đang làm.

## Bắt đầu từ đâu

Bài mở đầu trả lời một câu hỏi tưởng chừng đã rõ: trước khi chọn model, bạn cần xác định chính xác điều gì. Bài này đứng trước vì mọi quyết định phía sau đều thừa hưởng kết quả của nó: khi việc cần làm, input, output và cách kiểm tra còn mơ hồ, mọi so sánh model và mọi con số eval đều đang đo một thứ chưa được định nghĩa.

## Chương trình

- Xác định rõ việc cần làm trước khi chọn model (miễn phí)
- Việc nào thật sự cần giao cho LLM? (miễn phí) · quiz · kit cho agent
- Model biết gì khi nhận một request? · quiz
- Một lời gọi LLM gồm những gì? · quiz · kit cho agent
- Chọn dữ liệu cần thiết trước khi gửi cho model · quiz · kit cho agent
- Ví dụ trong prompt đang dạy model điều gì? · quiz · kit cho agent
- Chọn model và cấu hình theo việc cần làm · quiz · kit cho agent
- JSON đúng khuôn chưa phải quyết định đúng · quiz · kit cho agent
- Muốn so sánh hai phiên bản LLM, cần giữ lại những gì? · quiz · kit cho agent
- Viết eval case sao cho phép chấm không tự đánh lừa mình · quiz · kit cho agent
- Khi lời gọi model không trả về điều ứng dụng chờ đợi · quiz · kit cho agent
- Hợp lệ chưa phải là giấy phép · quiz · kit cho agent
- Có Guardrails rồi, action đã thật sự bị chặn chưa? · quiz · 2 kit cho agent
- Lần theo nguyên nhân khi tính năng LLM cho kết quả sai · quiz · kit cho agent
- Từ demo chạy được đến một handoff kiểm lại được · quiz · kit cho agent