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

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.

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.

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.

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.

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.

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.