Giờ đây, các nhà phát triển có thể kiểm soát chi phí sửa lỗi JSON bị lỗi định dạng từ các mô hình ngôn ngữ lớn (LLM) bằng cách giới hạn số lần thử sửa lỗi ở mức hai lần, thông qua một vòng lặp Python đơn giản. Mô hình này—tạo, phân tích cú pháp, xác thực, thử lại, sau đó chấp nhận hoặc thất bại—biến "JSON có thể hợp lệ" thành một tỷ lệ thành công có thể đo lường được và ngăn chặn việc sử dụng token mất kiểm soát.

Tại sao vòng lặp sửa lỗi lại quan trọng

LLM thường được yêu cầu "trả về JSON", nhưng đầu ra thường chứa lỗi cú pháp, thiếu khóa (keys) hoặc các giá trị vi phạm quy tắc nghiệp vụ. Một hệ thống hạ nguồn mong đợi một payload nghiêm ngặt sẽ bị lỗi hoặc đưa ra kết quả sai nếu nhận đầu ra như vậy. Nếu không có cách hệ thống để phát hiện và khắc phục những vấn đề này, các nhóm phát triển sẽ phải chấp nhận tỷ lệ thất bại cao hoặc lãng phí tiền bạc để yêu cầu mô hình thử lại liên tục cho đến khi đúng.

Ba lớp xác thực

Một vòng lặp đáng tin cậy sẽ chia việc xác thực thành:

  • Syntax (Cú pháp) – chuỗi có thể phân tích cú pháp thành JSON được không?
  • Shape (Cấu trúc) – đối tượng cấp cao nhất có chứa chính xác các khóa mong đợi không?
  • Semantic (Ngữ nghĩa) – các giá trị có tuân thủ các ràng buộc miền không (ví dụ: một "category" phải thuộc về một tập hợp đã được định nghĩa trước)?

Bằng cách dừng lại ở lớp thất bại đầu tiên, vòng lặp có thể cung cấp cho mô hình một thông báo lỗi chính xác, giúp cải thiện đáng kể cơ hội sửa lỗi đúng trong lần thử tiếp theo.

Ví dụ Python tối giản

Mã dưới đây chỉ sử dụng thư viện tiêu chuẩn. Nó định nghĩa một schema nhỏ (một dictionary với các khóa category và summary) và một danh sách cố định các danh mục được phép.

import json

CATEGORIES = {"bug", "feature", "question"}

def validate(raw: str):
    try:
        value = json.loads(raw)
    except json.JSONDecodeError as exc:
        return None, f"syntax: {exc.msg}"

    if not isinstance(value, dict):
        return None, "shape: root must be an object"
    if set(value) != {"category", "summary"}:
        return None, "shape: expected category and summary"
    if value["category"] not in CATEGORIES:
        return None, "semantic: invalid category"
    if not isinstance(value["summary"], str) or not value["summary"].strip():
        return None, "semantic: summary must be text"

    return value, None

Bản thân vòng lặp sửa lỗi áp đặt một giới hạn cứng cho số lần thử:

MAX_ATTEMPTS = 2
raw = model_response   # initial LLM output

for attempt in range(MAX_ATTEMPTS + 1):
    value, error = validate(raw)
    if error is None:
        break
    if attempt == MAX_ATTEMPTS:
        raise RuntimeError(f"failed after {MAX_ATTEMPTS} retries: {error}")

    # Send the error and schema back to the model for a fix
    raw = ask_model_to_repair(raw, error)

Nếu JSON vượt qua bước xác thực ngay lần đầu, vòng lặp sẽ thoát ngay lập tức. Nếu không, nó sẽ thử lại bằng cách cung cấp cho mô hình một payload ngắn gọn: đầu ra ban đầu, chuỗi lỗi chính xác và schema mong đợi. Sau hai lần thử thất bại, quá trình sẽ dừng lại với một ngoại lệ (exception) rõ ràng.

Hai quy tắc để sửa lỗi hiệu quả về chi phí

  1. Giữ các prompt sửa lỗi ngắn gọn – Chỉ bao gồm JSON thô, thông báo lỗi và schema. Việc thêm một lịch sử chat dài sẽ làm tăng lượng token sử dụng và có thể gây nhầm lẫn cho mô hình, đẩy chi phí cho mỗi lần thử lại lên cao mà không cải thiện được độ chính xác.

  2. Tách biệt việc xác thực khỏi việc kiểm chứng sự thật – Trình phân tích cú pháp có thể phát hiện các vấn đề về cấu trúc, nhưng nó không thể xác minh xem một tuyên bố "summary" có đúng sự thật hay không. Việc kiểm chứng sự thật nên thuộc về một giai đoạn sau; cố gắng "sửa lỗi" một tuyên bố sai sự thật chỉ làm cho lời nói dối trông có vẻ chỉn chu hơn.

Đo lường thành công

Việc ghi lại loại lỗi của mỗi lần thử (cú pháp, cấu trúc, ngữ nghĩa) và liệu vòng lặp có thành công hay không sẽ cung cấp một chỉ số cụ thể: tỷ lệ các phản hồi của LLM trở nên khả dụng trong phạm vi số lần thử giới hạn. Các nhóm có thể theo dõi điều này theo thời gian, so sánh các phong cách prompt hoặc thử nghiệm với các định nghĩa schema khác nhau.

Những nhược điểm tiềm ẩn

Việc giới hạn vòng lặp đồng nghĩa với việc một số đầu ra lỗi sẽ bị loại bỏ sau khi đạt đến giới hạn, điều này có thể làm tăng tỷ lệ thất bại tổng thể nếu chất lượng thô của mô hình thấp. Trong các môi trường mà mọi phản hồi đều quan trọng, các nhà phát triển có thể ưu tiên mức giới hạn thử lại cao hơn để đổi lấy việc tiêu tốn thêm token. Sự đánh đổi là rõ ràng: chi phí cao hơn để có độ bao phủ cao hơn, hoặc ngân sách chặt chẽ hơn với một giới hạn có thể dự đoán được.

Những điều cần chú ý tiếp theo

  • Prompt engineering để sửa lỗi – Tinh chỉnh định dạng thông báo lỗi có thể giảm số lần thử lại cần thiết.
  • Các trình phân tích cú pháp thay thế – Một số thư viện cung cấp khả năng phân tích cú pháp linh hoạt có thể tự động sửa các lỗi nhỏ; việc so sánh chi phí của chúng với một vòng lặp có giới hạn là rất xứng đáng.
  • Cập nhật mô hình – Các phiên bản LLM mới hơn có thể tạo ra JSON sạch hơn ngay từ đầu, tiềm năng cho phép giảm thêm giới hạn thử lại.

Một vòng lặp sửa lỗi JSON có giới hạn cung cấp cho các nhà phát triển một công cụ thực tế để biến đầu ra mờ nhạt của LLM thành dữ liệu đáng tin cậy mà không làm chi phí tăng vọt. Bằng cách coi việc xác thực là một bước quan trọng và giới hạn số lần thử lại, các nhóm có thể giữ cho cả ngân sách và các hệ thống hạ nguồn đều hoạt động ổn định.