0Pricing
AI Engineering Academy · บทเรียน

การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง

ผสานการประเมินแบบ LLM-as-judge เข้ากับกระบวนการ CI/CD เพื่อให้ทุกการเปลี่ยนแปลงพรอมต์หรือโมเดลได้รับการประเมินโดยอัตโนมัติเทียบกับชุดการทดสอบการถดถอยก่อนนำไปใช้งาน

การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง เป็นบทเรียน AI Engineering Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Engineering Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดการประเมินจึงต้องทำอย่างต่อเนื่อง

การประเมินเพียงครั้งเดียวเมื่อเริ่มนำไปใช้งานนั้นไม่เพียงพอ คุณภาพของ LLM อาจลดลงโดยไม่ทันสังเกต ผู้ให้บริการโมเดลอัปเดตโมเดลของตน การเปลี่ยนแปลงพรอมป์ระบบหลุดเข้าไปโดยไม่ตั้งใจ คุณภาพการค้นคืนเปลี่ยนไปเมื่อคลังเอกสารเติบโต และการกระจายตัวของคำถามจากผู้ใช้เปลี่ยนแปลงตามเวลา กระบวนการประเมินอย่างต่อเนื่องจะรันชุดการประเมินเดิมทุกครั้งที่มีการเปลี่ยนแปลงและตามกำหนดเวลา เพื่อให้ตรวจพบการถดถอยของคุณภาพภายในไม่กี่ชั่วโมงแทนที่จะเป็นหลายสัปดาห์

องค์ประกอบหลักของกระบวนการ

ไปป์ไลน์การประเมินอย่างต่อเนื่องมีองค์ประกอบห้าอย่าง ได้แก่ ชุดข้อมูลทดสอบ (คำถามที่คัดสรรพร้อมผลลัพธ์ที่คาดหวัง) ตัวเรียกใช้ระบบ (เรียกใช้ไปป์ไลน์ LLM ของคุณกับคำถามทดสอบแต่ละข้อ) ผู้ตัดสิน (ให้คะแนนคำตอบแต่ละรายการ) ที่จัดเก็บผลลัพธ์ (ฐานข้อมูลหรือที่จัดเก็บข้อมูลอนุกรมเวลาสำหรับตัวชี้วัดในอดีต) และ ชั้นรายงาน (แดชบอร์ดและการแจ้งเตือน) แต่ละองค์ประกอบสามารถอัปเกรดได้อย่างอิสระ

# Pipeline architecture:
#
# test_dataset.json
#       |
#       v
# system_runner.py  --> calls your LLM pipeline
#       |
#       v
# judge.py          --> scores each (question, answer) pair
#       |
#       v
# results_db        --> stores timestamped metric history
#       |
#       v
# dashboard + alert --> Grafana / Slack notification

การจัดโครงสร้างชุดข้อมูลทดสอบ

จัดเก็บชุดทดสอบการประเมินของคุณเป็นไฟล์ JSON หรือ YAML ที่มีการจัดการเวอร์ชันไว้ในคลังของคุณ แต่ละรายการประกอบด้วยคำถาม หมวดหมู่ (ข้อเท็จจริง ขั้นตอนการปฏิบัติ หรือนอกขอบเขต) และคำตอบอ้างอิง (ถ้ามี) จัดการเวอร์ชันของชุดทดสอบแยกจากโค้ด — การเพิ่มกรณีทดสอบใหม่เป็นการเปลี่ยนแปลงที่เข้ากันได้แบบย้อนหลัง ขณะที่การลบกรณีทดสอบอาจทำให้มองไม่เห็นการถดถอย ตั้งเป้าให้มีกรณีทดสอบ 200–500 กรณี ครอบคลุมทุกหมวดหมู่ที่เกี่ยวข้อง

# eval/test_set_v3.json
# {
#   'version': '3.0',
#   'created': '2026-06-01',
#   'cases': [
#     {
#       'id': 'faq_001',
#       'category': 'factual',
#       'question': 'What is the cancellation policy?',
#       'reference': 'Cancellations must be made 24 hours in advance.',
#       'min_correctness': 4
#     },
#     ...
#   ]
# }

การเรียกใช้ชุดการประเมิน

ตัวเรียกใช้การประเมินจะเรียกระบบที่ใช้งานจริงของคุณ (หรือรุ่นสำหรับการทดสอบก่อนใช้งานจริง) กับกรณีทดสอบแต่ละรายการ และบันทึกคำตอบกับข้อมูลเมทาดาทา กำกับการเรียกใช้การประเมินแต่ละครั้งด้วย ID การเรียกใช้ที่ไม่ซ้ำกัน ค่า SHA ของคอมมิตที่เป็นต้นเหตุ เวลาประทับ และเวอร์ชันของชุดทดสอบ วิธีนี้ทำให้สามารถเปรียบเทียบการเรียกใช้แต่ละครั้งได้อย่างแม่นยำ และวินิจฉัยได้ว่าการเปลี่ยนแปลงโค้ดใดทำให้เกิดการถดถอย

import asyncio
import uuid
from datetime import datetime

async def run_eval_suite(system, test_set: list, commit_sha: str) -> dict:
    run_id = str(uuid.uuid4())
    results = []
    for case in test_set:
        response = await system.answer(case['question'])
        score = await judge(case['question'], response, case.get('reference'))
        results.append({
            'run_id': run_id,
            'commit_sha': commit_sha,
            'case_id': case['id'],
            'category': case['category'],
            'response': response,
            'score': score.model_dump(),
            'evaluated_at': datetime.utcnow().isoformat()
        })
    return {'run_id': run_id, 'results': results}

การจัดเก็บและสืบค้นตัวชี้วัดในอดีต

บันทึกผลลัพธ์ของการเรียกใช้การประเมินทุกครั้งลงในฐานข้อมูล ตาราง eval_results อย่างง่ายที่มีฟิลด์ run_id, commit_sha, case_id และ score ก็เพียงพอแล้ว สืบค้นคะแนนรวมตาม run_id เพื่อคำนวณตัวชี้วัดของการเรียกใช้แต่ละครั้ง เปรียบเทียบการเรียกใช้ปัจจุบันกับการเรียกใช้ครั้งล่าสุดที่สำเร็จบนสาขาหลักเพื่อตรวจจับการถดถอย ฐานข้อมูลอนุกรมเวลาอย่าง InfluxDB เหมาะสำหรับการตรวจสอบอย่างต่อเนื่อง

-- PostgreSQL schema
CREATE TABLE eval_runs (
    run_id UUID PRIMARY KEY,
    commit_sha TEXT NOT NULL,
    test_set_version TEXT NOT NULL,
    triggered_by TEXT,  -- 'ci', 'scheduled', 'manual'
    started_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE eval_results (
    id SERIAL PRIMARY KEY,
    run_id UUID REFERENCES eval_runs(run_id),
    case_id TEXT NOT NULL,
    category TEXT,
    correctness INT,
    overall INT,
    response TEXT
);

CREATE INDEX idx_run_id ON eval_results(run_id);

การตรวจจับการถดถอยโดยอัตโนมัติ

หลังการเรียกใช้การประเมินแต่ละครั้ง ให้เปรียบเทียบคะแนนรวมกับค่าพื้นฐาน (การเรียกใช้ครั้งล่าสุดจากสาขาหลักที่ได้รับการอนุมัติด้วยตนเอง) ให้ถือว่าเกิดการถดถอยเมื่อมิติของคะแนนใด ๆ ลดลงต่ำกว่าค่าพื้นฐานมากกว่า 5% หรือคะแนนเฉลี่ยของหมวดหมู่ใด ๆ ลดลงต่ำกว่าค่าขั้นต่ำที่กำหนดตายตัว การถดถอยควรทำให้การนำระบบไปใช้งานถูกระงับและส่งการแจ้งเตือนไปยังทีม ส่วนการปรับปรุงสามารถอนุมัติโดยอัตโนมัติได้

def detect_regression(current: dict, baseline: dict, threshold_pct: float = 5.0) -> dict:
    regressions = []
    for metric in ['correctness', 'helpfulness', 'clarity']:
        delta_pct = (current[metric] - baseline[metric]) / baseline[metric] * 100
        if delta_pct < -threshold_pct:
            regressions.append({
                'metric': metric,
                'baseline': baseline[metric],
                'current': current[metric],
                'delta_pct': round(delta_pct, 1)
            })
    return {'has_regression': len(regressions) > 0, 'regressions': regressions}

การผสานรวมกับ CI/CD

เพิ่มชุดการประเมินเป็นขั้นตอนหนึ่งของ CI ที่ทำงานกับคำขอผสานแต่ละรายการ ไปป์ไลน์ CI จะเรียกระบบสำหรับการทดสอบก่อนใช้งานจริง เรียกใช้ผู้ตัดสิน จัดเก็บผลลัพธ์ และตรวจสอบการถดถอย หากตรวจพบการถดถอย ขั้นตอน CI จะล้มเหลวและระงับการผสาน PR เพิ่มขั้นตอนนี้เป็นการตรวจสอบสถานะที่จำเป็นใน GitHub หรือ GitLab เพื่อไม่ให้ใครข้ามขั้นตอนได้ ลดเวลาการเรียกใช้การประเมินให้ต่ำกว่า 10 นาทีด้วยการใช้กรณีทดสอบย่อย 50–100 กรณีสำหรับการตรวจสอบ PR

# .github/workflows/eval.yml
# name: LLM Quality Evaluation
# on: [pull_request]
# jobs:
#   eval:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - name: Run eval suite
#         run: python eval/run_suite.py --commit $GITHUB_SHA --mode pr
#         env:
#           OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
#       - name: Check for regressions
#         run: python eval/check_regression.py --run-id $EVAL_RUN_ID

การเรียกใช้การประเมินแบบเต็มตามกำหนดเวลา

นอกเหนือจากการตรวจสอบ PR แล้ว ให้เรียกใช้ชุดการประเมินแบบเต็ม (กรณีทดสอบทั้งหมดกว่า 300 กรณี) กับระบบที่ใช้งานจริงตามกำหนดเวลารายวัน วิธีนี้ช่วยตรวจจับคุณภาพที่ค่อย ๆ เปลี่ยนแปลง ซึ่งไม่ได้เกิดจากการเปลี่ยนแปลงใดเพียงครั้งเดียว — ตัวอย่างเช่น เมื่อความสามารถในการค้นคืนของฐานข้อมูลเวกเตอร์ลดลงเมื่อมีการเพิ่มเอกสารมากขึ้น หรือเมื่อผู้ให้บริการ LLM อัปเดตรุ่นของตนโดยไม่แจ้งให้ทราบ การเรียกใช้แบบเต็มทุกวันจะสร้างอนุกรมเวลาคุณภาพที่ทำให้มองเห็นแนวโน้มได้

# Separate eval modes:
EVAL_CONFIGS = {
    'pr_check': {
        'test_cases': 'eval/test_set_core_100.json',
        'target': 'staging',
        'max_runtime_min': 8
    },
    'nightly': {
        'test_cases': 'eval/test_set_full_350.json',
        'target': 'production',
        'max_runtime_min': 30
    },
    'weekly_deep': {
        'test_cases': 'eval/test_set_full_350.json',
        'target': 'production',
        'include_pairwise': True,
        'max_runtime_min': 90
    }
}

การแจ้งเตือนเมื่อคุณภาพลดลง

กำหนดค่าการแจ้งเตือนเมื่อแนวโน้มของตัวชี้วัดข้ามเกณฑ์เตือนและเกณฑ์วิกฤต การที่ความถูกต้องเฉลี่ยลดลง 3% ในช่วง 7 วันที่ผ่านมาให้ส่งสัญญาณเตือน การลดลง 10% ภายในการเรียกใช้ครั้งเดียวให้ส่งการแจ้งเตือนทันที ส่งสัญญาณเตือนไปยังช่อง Slack ของทีม และส่งการแจ้งเตือนระดับวิกฤตไปยัง PagerDuty ในข้อความแจ้งเตือนทุกครั้ง ให้ใส่การวิเคราะห์การถดถอย ลิงก์ไปยังแดชบอร์ดการประเมิน และข้อมูล git blame สำหรับการเปลี่ยนแปลงล่าสุด

import httpx

def send_regression_alert(regression_report: dict, webhook_url: str):
    regressions = regression_report['regressions']
    blocks = [{
        'type': 'section',
        'text': {'type': 'mrkdwn', 'text': '*LLM Quality Regression Detected*'}
    }]
    for r in regressions:
        blocks.append({
            'type': 'section',
            'text': {'type': 'mrkdwn',
                     'text': f'*{r["metric"]}*: {r["baseline"]} -> {r["current"]} ({r["delta_pct"]}%)'}
        })
    httpx.post(webhook_url, json={'blocks': blocks})

การจัดการการขยายชุดทดสอบ

ขยายชุดทดสอบอย่างต่อเนื่องโดยอิงจากความล้มเหลวจริงในระบบที่ใช้งาน เมื่อผู้ใช้รายงานคำตอบที่ไม่ดี ให้เพิ่มคำถามนั้น (ทำให้ไม่สามารถระบุตัวบุคคลได้หากจำเป็น) ลงในชุดทดสอบ พร้อมคำตอบที่มนุษย์ตรวจสอบแล้ว วิธีนี้ทำให้มั่นใจได้ว่าชุดการประเมินสะท้อนความต้องการจริงของผู้ใช้ แทนที่จะเป็นกรณีสมมติ มองชุดทดสอบเป็นเอกสารที่มีการปรับปรุงอยู่เสมอ และทบทวนทุกไตรมาสเพื่อลบกรณีที่ล้าสมัย

def add_to_test_set(question: str, reference_answer: str, category: str,
                    source: str, test_set_path: str):
    import json, uuid
    with open(test_set_path, 'r') as f:
        test_set = json.load(f)
    test_set['cases'].append({
        'id': f'user_report_{uuid.uuid4().hex[:8]}',
        'category': category,
        'question': question,
        'reference': reference_answer,
        'source': source,  # 'user_report', 'regression', 'manual'
        'added': '2026-06-21'
    })
    with open(test_set_path, 'w') as f:
        json.dump(test_set, f, indent=2)

การแสดงภาพแนวโน้มคุณภาพตามเวลา

สร้างแดชบอร์ดคุณภาพอย่างง่ายที่แสดงตัวชี้วัดสำคัญตามเวลา ได้แก่ คะแนนความถูกต้องเฉลี่ย อัตราการพบข้อมูลในแคช เวลาแฝงเปอร์เซ็นไทล์ที่ 95 และค่าใช้จ่ายต่อการสืบค้น ใช้ค่าเฉลี่ยเคลื่อนที่รายสัปดาห์เพื่อลดสัญญาณรบกวนจากขนาดตัวอย่างที่เล็ก แผนภูมิแนวโน้มทำให้มองเห็นคุณภาพที่ค่อย ๆ ลดลงได้ทันที — การลดลง 3% อย่างต่อเนื่องในช่วงหกสัปดาห์อาจมองไม่เห็นจากรายงานการเรียกใช้แต่ละครั้ง แต่เห็นได้ชัดบนแผนภูมิอนุกรมเวลา Grafana หรือแม้แต่สคริปต์ Python ที่ใช้ matplotlib อย่างง่ายก็ใช้งานได้ดี

import matplotlib.pyplot as plt
import pandas as pd

def plot_quality_trend(eval_history: list):
    df = pd.DataFrame(eval_history)
    df['date'] = pd.to_datetime(df['evaluated_at'])
    df = df.sort_values('date')
    # 7-day rolling average
    df['score_ma7'] = df['mean_correctness'].rolling(window=7).mean()
    plt.figure(figsize=(12, 4))
    plt.plot(df['date'], df['mean_correctness'], alpha=0.3, label='Daily')
    plt.plot(df['date'], df['score_ma7'], label='7-day avg', linewidth=2)
    plt.axhline(y=4.0, color='r', linestyle='--', label='Min threshold')
    plt.legend()
    plt.title('LLM Answer Quality Over Time')
    plt.savefig('quality_trend.png')

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจของคุณเกี่ยวกับไปป์ไลน์การประเมินอย่างต่อเนื่องสำหรับแอปพลิเคชัน LLM

ทบทวนบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า ไปป์ไลน์การประเมินอย่างต่อเนื่อง จะตรวจสอบคุณภาพโดยอัตโนมัติในทุก PR และตามกำหนดเวลารายวันเพื่อจับการถดถอยตั้งแต่เนิ่น ๆ การตรวจจับการถดถอย จะเปรียบเทียบคะแนนปัจจุบันกับค่าพื้นฐานและระงับการนำระบบไปใช้งานหากคุณภาพลดลง และ การขยายชุดทดสอบจากความล้มเหลวจริง ช่วยให้ชุดการประเมินยึดโยงกับความต้องการจริงของผู้ใช้ บทถัดไป เราจะจำแนกรูปแบบความล้มเหลวของเอเจนต์และออกแบบกลยุทธ์การกู้คืน

คำถามที่พบบ่อย

บทเรียน “การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Engineering Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง”

ผสานการประเมินแบบ LLM-as-judge เข้ากับกระบวนการ CI/CD เพื่อให้ทุกการเปลี่ยนแปลงพรอมต์หรือโมเดลได้รับการประเมินโดยอัตโนมัติเทียบกับชุดการทดสอบการถดถอยก่อนนำไปใช้งาน คุณปฏิบัติ AI Engineering Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AI Engineering Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AI Engineering Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AI Engineering Academy นี้ได้ไหม

ได้ บทเรียน AI Engineering Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. รูปแบบ LLM ในบทบาทผู้ตัดสิน
  2. การประเมินแบบรายรายการและแบบจับคู่
  3. การปรับเทียบโมเดลผู้ตัดสินกับมนุษย์
  4. การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง
← กลับไปที่ AI Engineering Academy