Bài 3 — Validation & xử lý output không hợp lệ

Schema chặt giảm lỗi, nhưng không xóa hết. Prompt injection, model cũ không hỗ trợ schema-constrained, hay lỗi biên vẫn có thể tạo output lệch. Bài này xây tầng validate phòng thủ nhiều lớp — nguyên tắc "never trust, always verify".

Hai loại validation

• Validation cú pháp/cấu trúc: JSON có parse được không? Có đúng schema (đủ trường, đúng type, đúng enum) không? Dùng thư viện như pydantic (Python), zod (TS), ajv (JSON Schema thuần).
• Validation ngữ nghĩa/nghiệp vụ: đúng schema nhưng vô lý — ví dụ checkout_date trước checkin_date, hay refund_amount lớn hơn số tiền đã trả. Loại này schema không bắt được, phải code kiểm tra.

Ví dụ validate hai lớp (pseudocode)

from pydantic import BaseModel, field_validator

class Booking(BaseModel):
    checkin: date
    checkout: date
    guests: int

    @field_validator("guests")
    def guests_positive(cls, v):
        if v < 1 or v > 20:
            raise ValueError("guests phải trong khoảng 1-20")
        return v

def parse_booking(raw_json: str) -> Booking:
    data = Booking.model_validate_json(raw_json)  # lớp 1: cấu trúc
    if data.checkout <= data.checkin:              # lớp 2: nghiệp vụ
        raise BusinessError("checkout phải sau checkin")
    return data

Chiến lược xử lý khi validate FAIL

• Retry với feedback lỗi: gửi lại chính thông báo lỗi validation cho model ("Trường checkout phải sau checkin, hãy sửa") — model thường tự sửa được. Đây là cách hiệu quả nhất.
• Giới hạn số lần retry (thường 1-2 lần) để tránh vòng lặp vô tận và cháy token.
• Fallback an toàn: sau khi hết retry, chuyển sang xử lý mặc định — ví dụ needs_human = true, đẩy cho người thật.
• Không bao giờ nuốt lỗi âm thầm: log lại raw output để debug và cải thiện schema/prompt.

Quy trình xử lý (numbered)

• Nhận raw output từ model.
• Parse JSON — fail thì retry-with-error.
• Validate schema — fail thì retry-with-error.
• Validate nghiệp vụ — fail thì retry hoặc fallback.
• Chỉ khi qua cả 3 lớp mới cho phép thực thi hành động.
• Log kết quả (thành công/thất bại) để giám sát tỉ lệ lỗi.

Khung tư duy: "Poka-yoke cho LLM"

Poka-yoke (chống lỗi) trong sản xuất: thiết kế sao cho không thể lắp sai. Với LLM, mỗi lớp validate là một chốt chặn khiến dữ liệu sai không thể đi tiếp vào hệ thống. Ưu tiên chặn sớm, chặn rẻ.

Checklist tầng validate

• [ ] Có bắt lỗi JSON parse riêng biệt?
• [ ] Có validate schema bằng thư viện, không tự viết tay?
• [ ] Có lớp validate nghiệp vụ cho ràng buộc schema không diễn tả được?
• [ ] Retry có kèm thông báo lỗi cụ thể cho model?
• [ ] Có giới hạn số retry?
• [ ] Có fallback an toàn khi hết retry?
• [ ] Có log raw output khi fail?

Sai lầm thường gặp

• Chỉ validate cú pháp, bỏ nghiệp vụ. Output đúng schema vẫn có thể gây chuyển khoản âm tiền nếu thiếu kiểm tra nghiệp vụ.
• Retry mù không kèm lỗi. Gửi lại đúng prompt cũ, model thường lặp lại đúng sai lầm. Phải nói cho nó SAI Ở ĐÂU.
• Retry vô hạn. Một câu hỏi hóc búa có thể fail mãi, đốt token và làm treo request.
• Fallback "đoán bừa". Khi không chắc, đừng đoán giá trị; hãy leo thang cho người thật hoặc trả lỗi rõ ràng.
• Nuốt exception. try/except: pass che mất tín hiệu để cải thiện hệ thống.

Giờ bạn đã có output sạch và đáng tin. Bài 4 chuyển sang định nghĩa tool để model biết gọi gì và điền tham số ra sao.