การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง
ผสานการประเมินแบบ 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 ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- รูปแบบ LLM ในบทบาทผู้ตัดสิน
- การประเมินแบบรายรายการและแบบจับคู่
- การปรับเทียบโมเดลผู้ตัดสินกับมนุษย์
- การสร้างกระบวนการประเมินผลอย่างต่อเนื่อง