Đừng “Vibe Check” Prompt nữa: Hướng dẫn thực hành DeepEval

AI tutorial - IT technology blog
AI tutorial - IT technology blog

Vấn đề của việc “Vibe Check” trong kỹ thuật Prompt Engineering

Bạn dành ba giờ đồng hồ để tinh chỉnh một prompt cho đến khi cảm thấy nó thật hoàn hảo. Nó vượt qua năm trường hợp kiểm thử đầu tiên một cách xuất sắc, vì vậy bạn đưa nó vào vận hành (production). Thế rồi, người dùng thứ năm mươi mốt đặt một câu hỏi hơi khác một chút, và chatbot bắt đầu “ảo giác” (hallucination) ra các chương trình giảm giá không có thật. Bạn vá lỗ hổng đó, để rồi nhận ra mình vừa làm hỏng ba tính năng khác trong quá trình này.

Các kỹ sư phần mềm đã giải quyết vấn đề hồi quy (regression) từ nhiều thập kỷ trước bằng unit test. Tuy nhiên, trong phát triển AI, nhiều nhóm vẫn dựa vào việc “vibe check” — quét thủ công mười hoặc hai mươi câu trả lời và hy vọng mọi thứ ổn thỏa. Cách này không thể mở rộng được. LLM có tính không tất định (non-deterministic); một thay đổi chỉ một từ trong system prompt có thể làm thay đổi đáng kể chất lượng đầu ra trên 20% các trường hợp biên của bạn. Để xây dựng các công cụ AI ổn định, chúng ta cần định lượng chất lượng bằng dữ liệu, chứ không phải cảm giác.

Làm chủ việc đánh giá tự động là điều phân biệt các kỹ sư AI cấp cao với những người vẫn còn kẹt trong giai đoạn “thử và sai”. Đó là cách duy nhất để triển khai các hệ thống mà các bên liên quan thực sự tin tưởng.

Hướng tới mô hình LLM-as-a-Judge

Làm thế nào để bạn kiểm tra một chuỗi văn bản không có một câu trả lời “đúng” duy nhất? DeepEval giải quyết vấn đề này bằng cách sử dụng mô hình “LLM-as-a-judge” (LLM làm giám khảo). Nó giao phó công việc nặng nhọc cho một mô hình có khả năng cao hơn, như GPT-4o, để chấm điểm đầu ra của ứng dụng dựa trên các chỉ số cụ thể, có thể đo lường được.

Thay vì kiểm tra sự khớp chính xác của chuỗi ký tự, chúng ta đo lường ý định ngữ nghĩa:

  • Faithfulness (Tính trung thực): Câu trả lời có tuân thủ chặt chẽ ngữ cảnh được truy xuất không?
  • Answer Relevancy (Sự liên quan): Câu trả lời có thực sự giải quyết được vấn đề cụ thể của người dùng không?
  • Hallucination (Ảo giác): Mô hình có đang bịa đặt ra những sự thật không tồn tại trong dữ liệu nguồn của bạn không?

DeepEval tích hợp trực tiếp vào Pytest. Điều này có nghĩa là các bài kiểm tra AI của bạn nằm ngay cạnh logic ứng dụng Python tiêu chuẩn.

Thiết lập môi trường của bạn

Việc cài đặt rất đơn giản. Vì “giám khảo” cần phải “suy nghĩ” để đánh giá kết quả, bạn sẽ cần một API key từ một nhà cung cấp như OpenAI hoặc Anthropic.

pip install deepeval pytest

Thiết lập biến môi trường để bắt đầu:

export OPENAI_API_KEY="your_api_key_here"

Thực hành: Viết Unit Test đầu tiên cho Prompt

Hãy tưởng tượng bạn đang xây dựng một chatbot hỗ trợ cho một nhà cung cấp dịch vụ lưu trữ đám mây. Bạn cần đảm bảo rằng khi người dùng hỏi về giá cả, bot không hứa hẹn mức giảm giá 50% vốn không tồn tại.

Tạo một tệp có tên test_chatbot.py. Chúng ta sẽ định nghĩa một kịch bản nơi chúng ta so sánh đầu ra của mô hình với sự thật hiển nhiên (ground truth), còn được gọi là ngữ cảnh truy xuất (retrieval context).

import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

def test_pricing_response():
    # 1. Định nghĩa kịch bản
    input_query = "Gói Pro giá bao nhiêu?"
    actual_output = "Gói Pro có giá 20 USD mỗi tháng và bao gồm băng thông không giới hạn."
    retrieval_context = [
        "Gói Pro của chúng tôi có giá 29 USD mỗi tháng.",
        "Gói Pro bao gồm 1TB băng thông, không phải không giới hạn."
    ]

    # 2. Thiết lập các chỉ số với ngưỡng (threshold) 0.7
    # Bất kỳ điểm số nào thấp hơn mức này sẽ khiến bài kiểm tra thất bại.
    relevancy_metric = AnswerRelevancyMetric(threshold=0.7)
    faithfulness_metric = FaithfulnessMetric(threshold=0.7)

    # 3. Tạo test case
    test_case = LLMTestCase(
        input=input_query,
        actual_output=actual_output,
        retrieval_context=retrieval_context
    )

    # 4. Thực thi kiểm tra
    assert_test(test_case, [relevancy_metric, faithfulness_metric])

Điều gì đang xảy ra bên dưới?

Trong đoạn mã này, tôi đã cố tình đưa các lỗi vào actual_output: 20 USD thay vì 29 USD, và “không giới hạn” thay vì “1TB”. Khi bạn chạy bài kiểm tra, FaithfulnessMetric sẽ gắn cờ sự mâu thuẫn này. Nó không chỉ báo thất bại; nó giải thích chính xác tại sao logic bị sai lệch.

Chạy các bài kiểm tra

Kích hoạt quá trình đánh giá bằng một lệnh duy nhất trong terminal của bạn:

deepeval test run test_chatbot.py

Kết quả sẽ hiển thị tức thì và rõ ràng. Bạn sẽ thấy bảng phân tích theo mã màu cho từng điểm số chỉ số. Nếu một bài kiểm tra thất bại, bạn sẽ nhận được trường “Reason” (Lý do) — ví dụ: “Đầu ra tuyên bố mức giá 20 USD, nhưng ngữ cảnh nêu rõ là 29 USD.”

Ngăn chặn ảo giác sớm

Ảo giác là rào cản chính cho các luồng xử lý RAG trong vận hành. DeepEval bao gồm một chỉ số HallucinationMetric chuyên dụng, mạnh mẽ hơn nhiều so với việc kiểm tra khớp từ đơn giản. Nó kiểm tra xem mô hình có tạo ra các tuyên bố không được hỗ trợ bởi cơ sở tri thức của bạn hay không.

from deepeval.metrics import HallucinationMetric

def test_no_hallucination():
    metric = HallucinationMetric(threshold=0.5)
    test_case = LLMTestCase(
        input="Chính sách hoàn tiền của chúng tôi là gì?",
        actual_output="Bạn có thể được hoàn tiền trong vòng 90 ngày.",
        context=["Khách hàng đủ điều kiện được hoàn tiền trong vòng 30 ngày kể từ ngày mua hàng."]
    )
    assert_test(test_case, [metric])

Tích hợp DevOps: Quy trình làm việc thực tế

Tự động hóa chỉ hữu ích khi nó nhất quán. Để chuyển từ một bản mẫu (prototype) sang một hệ thống cấp độ vận hành, hãy tích hợp các kiểm tra này vào quy trình CI/CD của bạn. Đây là quy trình mà tôi đề xuất:

  1. Xây dựng “Golden Dataset”: Tuyển chọn 50 đến 100 test case ưu tiên cao bao gồm các câu hỏi phổ biến nhất của người dùng và các trường hợp biên đã biết.
  2. Pre-merge Gates (Chốt chặn trước khi hợp nhất): Chạy một tập hợp con các bài kiểm tra này trên mỗi Pull Request. Nếu một thay đổi prompt làm giảm điểm tính trung thực (faithfulness), việc hợp nhất sẽ tự động bị chặn.
  3. Quản lý phiên bản Prompt: Đối xử với prompt như mã nguồn. Khi bạn cập nhật một phiên bản, hãy chạy toàn bộ bộ kiểm thử để đảm bảo không có sự sụt giảm chất lượng câu trả lời.

Một lưu ý nhỏ về chi phí: đánh giá 1.000 test case sử dụng GPT-4o làm giám khảo có thể tốn kém. Đối với khối lượng kiểm thử lớn, hãy chuyển sang GPT-4o-mini. Nó rẻ hơn đáng kể — thường dưới 0,10 USD cho một bộ kiểm thử đầy đủ — trong khi vẫn duy trì độ chính xác đáng ngạc nhiên trong vai trò giám khảo.

Kết luận

Kiểm tra thủ công là nút thắt cổ chai tiềm ẩn giết chết năng suất AI. Bằng cách áp dụng một framework như DeepEval, bạn ngừng đoán xem prompt của mình có hoạt động hay không và bắt đầu biết chính xác nó thực hiện như thế nào. Bạn phát hiện ra ảo giác trước khi chúng tiếp cận người dùng và xây dựng một vết kiểm tra cải tiến rõ ràng. Nếu bạn nghiêm túc về việc xây dựng các công cụ AI bền vững, hãy ngừng “vibe checking” và bắt đầu unit testing ngay hôm nay.

Share: