---
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 xác định một tính năng LLM có phạm vi rõ, chọn dữ liệu và cấu hình theo việc cần làm, kiểm output theo cả schema lẫn business invariant. Bạn học cách đọc failure path, đánh giá bằng evidence và bàn giao bản 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: 0
---

## 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 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. Một tính năng sống trong sản phẩm 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 đó.

- **Xác định phạm vi một tính năng LLM** thành một contract có input, output, ranh giới và cách kiểm, 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 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 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 trial quan sát đượ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 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 còn nằm trong đầu 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ì, biên của nó dừng ở đâu, và trường hợp nào nằm ngoài biên đó. 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 được. Bạn cũng học cách dựng deterministic baseline, nghĩa là phần việc mà code thường 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. Trong một lần sinh câu trả lời, model 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 thứ được đưa vào

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 xác định input selection và 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 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 hình dạng: đủ field, đúng kiểu, đúng enum. Business invariant kiểm ý 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 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 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 đ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 qua nhiều sản phẩm khác nhau, 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 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 judgment kỹ thuật: bạn học cách ra quyết định và kiểm 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 hình dạng và chưa kiểm 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 để hai phiên bản so 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 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õ distinction 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ó static teaching visual để 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 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.
- Đợt hiện tại không 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à static teaching visual, tập trung vào judgment 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 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
- Model biết gì khi nhận một request? · quiz
- Một lời gọi LLM gồm những gì? · quiz
- Chọn dữ liệu cần thiết trước khi gửi cho model · quiz
- Ví dụ trong prompt đang dạy model điều gì? · quiz
- Chọn model và cấu hình theo việc cần làm · quiz
- JSON đúng khuôn chưa phải quyết định đúng · quiz
- Muốn so hai phiên bản LLM, cần giữ lại những gì? · quiz
- Viết eval case sao cho phép chấm không tự đánh lừa mình · quiz
- Khi lời gọi model không trả về điều ứng dụng chờ đợi · quiz
- Hợp lệ chưa phải là giấy phép · quiz
- Có Guardrails rồi, action đã thật sự bị chặn chưa? · quiz
- Lần theo nguyên nhân khi tính năng LLM cho kết quả sai · quiz
- Từ demo chạy được đến một handoff kiểm lại được · quiz