Test và đánh giá prompt

Bạn sẽ không phát hành code mà không có kiểm tra. Các prompt cũng không ngoại lệ. Nhưng đầu ra của LLM không mang tính xác định, điều đó có nghĩa là kiểm thử truyền thống không hiệu quả. Bạn cần một cách tiếp cận khác.

🔄 Tóm tắt nhanh: Trong Bài học 5, bạn đã học cách phòng chống tấn công Prompt injection. Nhưng làm thế nào để bạn biết các biện pháp phòng vệ của mình thực sự hiệu quả? Và làm thế nào để bạn biết prompt của mình tạo ra đầu ra tốt một cách nhất quán? Đó là những gì mà các framework đánh giá trả lời.

Tại sao kiểm thử truyền thống thất bại với các prompt?

Unit test kiểm tra đầu ra chính xác: assertEqual(result, expected). Điều này không hiệu quả với LLM vì:

• Cùng một prompt có thể tạo ra các cách diễn đạt khác nhau mỗi lần chạy
• "Đúng" có thể có nhiều cách biểu diễn hợp lệ
• Chất lượng là một phổ, không đơn giản chỉ là đạt/không đạt

Những gì hiệu quả hơn: Kiểm thử dựa trên thuộc tính, đánh giá ngữ nghĩa và các chỉ số thống kê trên tập dữ liệu.

Xây dựng tập dữ liệu đánh giá của bạn

Tập dữ liệu đánh giá là một tập hợp các cặp đầu vào-đầu ra xác định "tốt" trông như thế nào.

Bộ dữ liệu tối thiểu khả thi: 50-100 ví dụ thuộc các danh mục sau:

Định dạng tập dữ liệu:

{
  "input": "Extract the email from: Contact John at john@acme.com",
  "expected_output": {"email": "john@acme.com", "name": "John"},
  "tags": ["standard", "single-email"],
  "quality_criteria": ["correct_email", "correct_name", "valid_json"]
}

Hãy xây dựng tập dữ liệu trước khi viết prompt. Đây là phương pháp phát triển dựa trên đánh giá - tương đương với TDD trong việc kiểm tra prompt.

✅ Kiểm tra nhanh: Tập dữ liệu đánh giá của bạn có 100 ví dụ, tất cả đều từ cùng một nguồn dữ liệu. Đây có phải là một tập dữ liệu tốt không?

Câu trả lời: Có lẽ là không. Một tập dữ liệu tốt thể hiện sự phân bố thực tế của dữ liệu đầu vào. Nếu lưu lượng truy cập sản xuất của bạn bao gồm dữ liệu đầu vào bằng nhiều ngôn ngữ, độ dài khác nhau và đôi khi có dữ liệu không đúng định dạng, thì tập dữ liệu đánh giá của bạn cũng nên như vậy. Các tập dữ liệu đồng nhất tạo ra những prompt hoạt động hoàn hảo trong quá trình thử nghiệm và bị lỗi trong môi trường sản xuất.

Các chỉ số đánh giá

Tuân thủ định dạng

def check_format(response, schema):
    try:
        parsed = schema.model_validate_json(response)
        return True
    except ValidationError:
        return False

# Run across dataset
pass_rate = sum(check_format(r, MySchema) for r in responses) / len(responses)
# Target: 99%+

Độ chính xác thực tế

Đầu ra có chứa thông tin chính xác không?

Đối với đầu ra có cấu trúc: So sánh các trường được trích xuất với dữ liệu thực tế. Đối với văn bản: Sử dụng độ tương đồng ngữ nghĩa hoặc chấm điểm LLM-as-judge.

def check_accuracy(response, expected):
    # For structured: field-by-field comparison
    return response.email == expected.email and response.name == expected.name

# For text: semantic similarity
from sentence_transformers import SentenceTransformer
model = SentenceTransformer('all-MiniLM-L6-v2')
similarity = cosine_similarity(
    model.encode(response_text),
    model.encode(expected_text)
)
# Target: > 0.85

LLM-as-Judge

Sử dụng LLM thứ hai để đánh giá đầu ra của LLM đầu tiên:

judge_prompt = """Đánh giá câu trả lời này trên thang điểm từ 1-5:
- 5: Hoàn toàn chính xác, định dạng tốt, đầy đủ
- 4: Chính xác với một số lỗi định dạng nhỏ
- 3: Hầu hết chính xác, thiếu một số thông tin
- 2: Chính xác một phần, có vấn đề đáng kể
- 1: Sai hoặc (Không liên quan đến chủ đề chính)

TIÊU CHÍ:
- Độ chính xác về mặt thực tế (so với tài liệu tham khảo)
- Tuân thủ định dạng
- Tính đầy đủ
- Tính ngắn gọn (không có thông tin không cần thiết)

Câu trả lời tham khảo: {dự kiến}
Câu trả lời cần đánh giá: {thực tế}

Điểm số (1-5):"""

Hiệu chỉnh judge: Bao gồm 10 ví dụ đã được chấm điểm trước để judge biết điểm "3" và "4" trông như thế nào. Kiểm tra điểm số của judge so với điểm số của con người hàng tháng.

Các framework đánh giá

Cấu hình tối thiểu với Promptfoo:

# promptfooconfig.yaml
prompts:
  - "Extract contact info: {{input}}"
providers:
  - openai:gpt-4.1
tests:
  - vars:
      input: "Contact John at john@acme.com"
    assert:
      - type: contains-json
      - type: contains
        value: "john@acme.com"

Chạy: promptfoo eval - nó kiểm tra prompt của bạn với tất cả các trường hợp kiểm thử và hiển thị báo cáo đạt/không đạt.

Vòng lặp phát triển dựa trên đánh giá

1. Xác định tiêu chí đánh giá trước khi viết prompt
2. Xây dựng tập dữ liệu đánh giá với các ví dụ đa dạng
3. Viết prompt (bản nháp đầu tiên)
4. Chạy đánh giá — đo tỷ lệ đạt
5. Lặp lại prompt — sửa các mẫu lỗi
6. Chạy đánh giá lại — xác nhận cải tiến, kiểm tra lỗi hồi quy
7. Phát hành khi tỷ lệ đạt đạt ngưỡng (thường là 95% trở lên)

✅ Kiểm tra nhanh: Prompt của bạn vượt qua 96% trường hợp đánh giá. Bạn thực hiện một thay đổi để cải thiện khả năng xử lý các trường hợp ngoại lệ. Prompt mới xử lý được 98% các trường hợp ngoại lệ nhưng tỷ lệ xử lý tổng thể giảm xuống còn 93%. Chuyện gì đã xảy ra vậy?

Đáp án: Regression. Cải tiến của bạn đã khắc phục các trường hợp ngoại lệ nhưng lại làm hỏng các trường hợp chuẩn - thay đổi prompt xử lý các đầu vào bất thường có thể đã khiến mô hình suy nghĩ quá mức đối với những đầu vào đơn giản. Luôn chạy toàn bộ bộ đánh giá sau khi thay đổi, không chỉ chạy danh mục bạn đang sửa. Đây chính là lý do tại sao bạn cần một bộ kiểm thử toàn diện.

Những điểm chính cần ghi nhớ

• Các bài unit test truyền thống (assertEqual) không hoạt động với đầu ra của LLM — hãy sử dụng đánh giá dựa trên thuộc tính và ngữ nghĩa
• Xây dựng tập dữ liệu đánh giá của bạn TRƯỚC KHI viết prompt — phát triển dựa trên đánh giá giúp phát hiện vấn đề sớm
• Tập dữ liệu khả thi tối thiểu: 50-100 ví dụ đa dạng bao gồm các trường hợp chuẩn, ngoại lệ, đối nghịch và mơ hồ
• Ba loại số liệu: Tuân thủ định dạng (xác thực schema), độ chính xác thực tế (so sánh trường) và điểm chất lượng (LLM-as-judge)
• Luôn chạy toàn bộ bộ công cụ đánh giá sau khi thay đổi prompt - cải tiến ở một lĩnh vực có thể gây ra vấn đề ở những lĩnh vực khác
• Mục tiêu tỷ lệ đạt 95% trở lên trước khi đưa vào sản xuất