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

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 đó.

1. 01Viế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.
2. 02Chọ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.
3. 03Kiể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.
4. 04Đọ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ý.
5. 05Giữ 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.
6. 06Đá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ó.
7. 07Bà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.

• Prompt chạy tốt trên vài ví dụ rồi sai ngay khi gặp dữ liệu thậtViệ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.

1. 01Đ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.
2. 02Là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.
3. 03Dù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ữ.
4. 04Giữ 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.

1. 01

   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. 02

   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. 03

   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. 04

   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. 05

   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. 06

   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.

1. 01Dấu hiệuPrompt chạy tốt trên vài ví dụ rồi sai ngay khi gặp dữ liệu thậtThực raViệc cần làm chưa từng được viết thành contract có input, output và ranh giới rõ.
2. 02Dấu hiệuOutput đúng JSON schema nhưng nội dung vô lý về nghiệp vụThực raLớp validation mới kiểm tra hình dạng, chưa kiểm tra business invariant.
3. 03Dấu hiệuPrompt ngày càng dài vì mỗi lỗi lại thêm một câu dặn dòThực raCác ngoại lệ đang được nhét vào model thay vì được xử lý bằng exception path trong ứng dụng.
4. 04Dấu hiệuĐổi model thấy “có vẻ tốt hơn” nhưng không chứng minh đượcThực raKhô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.
5. 05Dấu hiệuEval cho điểm rất cao trong khi người dùng vẫn phàn nànThực raRubric chấm theo cảm tính hoặc ví dụ dùng để chấm đã rò rỉ vào chính prompt.
6. 06Dấu hiệuTính năng hỏng trên production mà không ai biết tìm từ đâuThực raRequest, context và response không được ghi lại đủ để lần ngược nguyên nhân.
7. 07Dấu hiệuỨng dụng thực hiện một hành động ngoài phạm vi vì model đề xuất như vậyThực raQuyền hành động bị giao cho output thay vì đi qua permission check.
8. 08Dấu hiệuChi phí và độ trễ tăng dần không rõ lý doThực raContext đượ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.