การประเมินผล การนำไปใช้งาน และการทบทวนหลังดำเนินการ
เรียกใช้ชุดเครื่องมือประเมินผลฉบับเต็ม ซึ่งรวมเมตริกการค้นคืน คะแนนคุณภาพแบบ LLM-as-judge และการทดสอบโหลด นำระบบไปใช้งานกับผู้ให้บริการคลาวด์ และเขียนรายงานทบทวนบทเรียนที่ได้รับ
การประเมินผล การนำไปใช้งาน และการทบทวนหลังดำเนินการ เป็นบทเรียน AI Engineering Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Engineering Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน
ขั้นตอนสุดท้าย: ประเมินก่อนเปิดใช้งาน
ระบบยังไม่พร้อมเปิดใช้งานจนกว่าจะได้รับการประเมินตั้งแต่ต้นจนจบภายใต้เงื่อนไขใกล้เคียงการใช้งานจริง ขั้นตอนการประเมินสุดท้ายจะรวมเทคนิคทั้งหมดที่เรียนมาในบทนี้ ได้แก่ ตัวชี้วัดการค้นคืนเพื่อยืนยันว่ากระบวนการ RAG ค้นพบส่วนเนื้อหาที่ถูกต้อง คะแนนจาก LLM ในบทบาทผู้ตัดสินเพื่อยืนยันคุณภาพคำตอบ การทดสอบภาระงานเพื่อยืนยัน SLA ด้านเวลาแฝง และการตรวจสอบความปลอดภัยเพื่อยืนยันการเสริมความแข็งแกร่ง ทุกอย่างต้องผ่านก่อนเริ่มการนำไปใช้งาน
เรียกใช้ชุดเครื่องมือประเมินทั้งหมด
เรียกใช้ชุดการประเมินทั้งหมดกับสภาพแวดล้อมเตรียมใช้งาน โดยใช้ตัวอย่างคำค้นที่เป็นตัวแทนของคำค้นในระบบจริง บันทึกตัวชี้วัดทั้งหมด ได้แก่ อัตราการพบผลลัพธ์ที่ต้องการ MRR และ NDCG สำหรับการค้นคืน ความเที่ยงตรงและความเกี่ยวข้องของคำตอบสำหรับการสร้าง ต้นทุนต่อคำค้น และเวลาแฝง p50/p95/p99 เปรียบเทียบตัวชี้วัดทุกตัวกับเกณฑ์ความสำเร็จที่กำหนดไว้ในระยะสถาปัตยกรรม อย่านำระบบไปใช้งานจนกว่าจะผ่านค่าขั้นต่ำที่กำหนดไว้ทั้งหมด
async def final_evaluation(system_url: str, test_set_path: str) -> dict:
test_cases = load_test_set(test_set_path)
results = []
for case in test_cases:
start = time.perf_counter()
response = await query_system(system_url, case['question'])
latency_ms = (time.perf_counter() - start) * 1000
judge_score = await judge(case['question'], response['answer'], case.get('reference'))
hit = any(case['relevant_doc'] in s for s in response.get('sources', []))
results.append({'latency_ms': latency_ms, 'score': judge_score, 'hit': hit, 'cost': response.get('cost_usd', 0)})
return compute_final_metrics(results)ทดสอบภาระงานของระบบใช้งานจริง
เรียกใช้การทดสอบภาระงานที่จำลองปริมาณการใช้งานจริงก่อนเปิดให้บริการ ใช้เครื่องมืออย่าง Locust หรือ k6 เพื่อเพิ่มจำนวนผู้ใช้พร้อมกันจนถึงระดับสูงสุดที่คาดไว้ เช่น ผู้ใช้พร้อมกัน 50 คน และวัดว่าเวลาแฝงเปลี่ยนแปลงอย่างไรเมื่อภาระงานเพิ่มขึ้น ตรวจสอบว่า circuit breaker ไม่ทำงานภายใต้ภาระงานปกติ ตัวจำกัดอัตราการใช้งานส่งการตอบกลับ 429 อย่างถูกต้องเมื่อมีคำขอพุ่งสูง และอัตราการพบข้อมูลใน Semantic Cache ยังคงสูงกว่าเป้าหมาย แก้ไขการถดถอยทั้งหมดก่อนดำเนินการต่อ
# Locust load test (locustfile.py)
from locust import HttpUser, task, between
import random
QUESTIONS = [
'What is the return policy?',
'How do I cancel my subscription?',
'Where are you located?',
]
class AIUser(HttpUser):
wait_time = between(1, 3) # realistic think time
@task
def query(self):
self.client.post(
'/query',
json={'question': random.choice(QUESTIONS), 'tenant_id': 'load_test'},
headers={'Authorization': 'Bearer test_token'}
)
# Run: locust -f locustfile.py --headless -u 50 -r 5 --run-time 5mนำไปใช้งานจริง
นำระบบไปใช้งานโดยใช้ การนำไปใช้งานแบบ blue-green เปิดใช้งานเวอร์ชันใหม่ (green) ควบคู่กับเวอร์ชันเดิม (blue) เรียกใช้การทดสอบเบื้องต้นกับ green จากนั้นค่อย ๆ ย้ายปริมาณการใช้งานจาก blue ไปยัง green เริ่มส่งปริมาณการใช้งาน 5% ไปยัง green ตรวจสอบอัตราข้อผิดพลาดและเวลาแฝงเป็นเวลา 10 นาที จากนั้นเพิ่มเป็น 25% แล้ว 50% และ 100% วิธีนี้ช่วยให้ย้อนกลับไปยัง blue ได้ทันทีหากเกิดปัญหา โดยไม่ทำให้บริการหยุดชะงัก
# Deployment steps (pseudocode for AWS ECS or K8s):
# 1. Build and push new Docker image
# docker build -t qa-assistant:v2.0 . && docker push ...
#
# 2. Deploy green (new) version alongside blue (current)
# kubectl apply -f deploy/green.yaml
#
# 3. Run smoke tests against green
# pytest tests/smoke/ --base-url https://green.internal
#
# 4. Canary traffic shift (ALB weighted routing)
# 5% -> green (monitor 10min)
# 25% -> green (monitor 10min)
# 50% -> green (monitor 10min)
# 100% -> green
#
# 5. Decommission blue after 24h stabilityการติดตามตรวจสอบหลังการนำไปใช้งาน
หลังนำระบบไปใช้งาน ให้ติดตามตัวชี้วัดสำคัญอย่างใกล้ชิดในช่วง 2 ชั่วโมงแรก ตรวจสอบอัตราข้อผิดพลาด (เป้าหมาย <1%) เวลาแฝง p95 (เป้าหมาย <8s) อัตราการพบข้อมูลในแคช (เป้าหมาย >20%) และต้นทุนต่อคำค้น (เป้าหมาย <$0.05) ตั้งช่อง Slack สำหรับห้องประสานงานฉุกเฉิน โดยให้วิศวกรเวรทุกคนเข้าร่วมในช่วงการนำไปใช้งานครั้งแรก หากตัวชี้วัดใดข้ามเกณฑ์คำเตือน ให้เริ่มตรวจสอบ หากข้ามเกณฑ์วิกฤต ให้ย้อนกลับไปยัง blue ทันที
# Post-deploy monitoring dashboard queries:
# (Assuming Grafana + Prometheus)
# Error rate (last 5 min):
# rate(http_requests_total{status=~'5..'}[5m]) / rate(http_requests_total[5m])
# p95 latency (last 5 min):
# histogram_quantile(0.95, rate(query_duration_seconds_bucket[5m]))
# Cache hit rate:
# rate(cache_hits_total[5m]) / rate(queries_total[5m])
# Average cost per query:
# rate(llm_cost_usd_total[5m]) / rate(queries_total[5m])เขียนบททบทวนสถาปัตยกรรม
หลังจากระบบเปิดใช้งานมาแล้วหนึ่งสัปดาห์ ให้เขียน เอกสารบททบทวน ที่บันทึกว่าอะไรได้ผล อะไรไม่ได้ผล และคุณจะทำสิ่งใดแตกต่างออกไป บททบทวนที่ดีควรซื่อตรงเกี่ยวกับความล้มเหลวและระบุบทเรียนที่ได้อย่างชัดเจน ผู้อ่านในอนาคต รวมถึงตัวคุณในอีกหกเดือนข้างหน้า จะได้รับประโยชน์จากการเข้าใจเหตุผลเบื้องหลังการตัดสินใจภายใต้แรงกดดันด้านเวลาและอุปสรรคที่ไม่คาดคิด
# RETROSPECTIVE.md structure:
#
# ## What Worked Well
# - Hybrid retrieval improved hit rate from 71% to 89%
# - Semantic cache reduced average cost by 31%
# - LangSmith tracing saved 2 days of debugging
#
# ## What Did Not Work
# - Semantic chunking was 4x slower than recursive chunking
# with only 3% hit rate improvement -- not worth it
# - Cohere reranker had 400ms latency -- too slow for p95 target
# Switched to BGE-reranker-v2 running locally
#
# ## What We'd Do Differently
# - Start with pgvector, not Pinecone (migration cost 3 days)
# - Add semantic cache BEFORE building the agent, not afterจัดทำคู่มือปฏิบัติการ
เขียน คู่มือปฏิบัติการ สำหรับการแจ้งเตือนทุกประเภทที่อาจเกิดขึ้นในระบบจริง คู่มือปฏิบัติการคือแนวทางทีละขั้นตอนสำหรับวินิจฉัยและแก้ไขการแจ้งเตือนเฉพาะรายการ คู่มือนี้ควรตอบคำถามว่า การแจ้งเตือนนี้หมายถึงอะไร สาเหตุที่เป็นไปได้คืออะไร จะวินิจฉัยอย่างไร และจะแก้ไขอย่างไร คู่มือปฏิบัติการช่วยลดเวลาเฉลี่ยในการแก้ไข (MTTR) จากหลายชั่วโมงเหลือไม่กี่นาที โดยไม่ต้องเสียเวลาคิดขั้นตอนการวินิจฉัยระหว่างเกิดเหตุการณ์ที่กดดัน
# runbooks/latency.md
# ## Alert: p95 Latency > 8000ms
#
# ### Likely Causes
# 1. OpenAI API degraded (check status.openai.com)
# 2. Cohere reranker slow (check Cohere status page)
# 3. pgvector query slow (check DB CPU in CloudWatch)
# 4. Redis cache full (check Redis memory usage)
#
# ### Diagnosis
# curl https://api.openai.com/v1/models -H 'Authorization: Bearer $KEY'
# Check LangSmith traces for which step is slow
# SELECT mean(duration) FROM traces GROUP BY step
#
# ### Fixes
# - If OpenAI slow: circuit breaker should auto-failover to Claude
# - If Cohere slow: disable reranking temporarily (env SKIP_RERANK=1)
# - If DB slow: increase pgvector ef_search from 40 to 20วัดผลกระทบทางธุรกิจ
หลังจากใช้งานในระบบจริงเป็นเวลาหนึ่งเดือน ให้ประเมินผลกระทบทางธุรกิจของระบบนอกเหนือจากตัวชี้วัดทางเทคนิค สำหรับผู้ช่วยถาม-ตอบ ให้พิจารณาว่า จำนวนคำร้องขอการสนับสนุนจากลูกค้าลดลงเท่าใด คะแนนความพึงพอใจของผู้ใช้ต่อคำถามที่ปัญญาประดิษฐ์เป็นผู้ตอบอยู่ที่เท่าใด และระบบรองรับคำถามได้กี่รายการซึ่งก่อนหน้านี้ต้องให้เจ้าหน้าที่สนับสนุนเป็นผู้ดำเนินการ ตัวชี้วัดทางธุรกิจเหล่านี้ช่วยยืนยันความคุ้มค่าของการลงทุน และใช้กำหนดลำดับความสำคัญในอนาคตระหว่างการปรับปรุงคุณภาพกับการเพิ่มความสามารถใหม่
# Business impact metrics (month 1):
# Technical:
# - 12,847 queries served, 11,439 (89%) answered without human
# - Avg query cost: $0.031 (within $0.05 budget)
# - System uptime: 99.94%
#
# Business:
# - Support tickets: 1,840/month -> 1,203/month (-35%)
# - Avg resolution time: 4.2h -> 23 seconds for AI-answered
# - User CSAT on AI answers: 4.1/5.0
# - Cost per resolved query: $12 (human) -> $0.031 (AI)
# - ROI: 157% in month 1 at current volumesการวางแผนรอบการพัฒนาถัดไป
ระบบที่เปิดใช้งานแล้วไม่มีวันถือว่าเสร็จสมบูรณ์ — ระบบเป็นรากฐานสำหรับการปรับปรุงอย่างต่อเนื่อง ให้ใช้ข้อมูลการประเมิน ความคิดเห็นของผู้ใช้ และบทเรียนจากการทบทวนหลังการดำเนินงานเพื่อวางแผนรอบการพัฒนาถัดไป ให้ความสำคัญกับการปรับปรุงที่ส่งผลกระทบสูงสุดต่อตัวชี้วัดที่สำคัญที่สุด หากอัตราการค้นคืนข้อมูลที่ตรงกับความต้องการเป็นปัจจัยจำกัด ให้ลงทุนกับการแบ่งข้อมูลเป็นส่วนย่อยที่ดีขึ้นหรือแบบจำลองการฝังเวกเตอร์แบบอื่น หากความพึงพอใจของผู้ใช้ต่ำแม้การค้นคืนข้อมูลจะทำได้ดี ให้ลงทุนกับคุณภาพของคำสั่ง
# Next iteration priorities (based on first month data):
NEXT_SPRINT = [
# High impact / high confidence
{
'feature': 'Sentence-window retrieval',
'expected_impact': 'Hit rate 89% -> 93%',
'effort': 'medium',
'evidence': '11% of failures due to answer split across chunks'
},
# High impact / medium confidence
{
'feature': 'Query decomposition for multi-hop questions',
'expected_impact': 'Multi-hop correctness 61% -> 78%',
'effort': 'high',
'evidence': '23% of failures are multi-hop questions'
},
# Low effort quick win
{
'feature': 'Extend cache TTL from 1h to 24h',
'expected_impact': 'Cache hit rate 31% -> 38%',
'effort': 'trivial',
'evidence': 'Same questions asked daily by different users'
}
]การแบ่งปันความรู้และการจัดทำเอกสาร
จัดทำเอกสารสำหรับการตัดสินใจด้านการนำไปใช้งานที่สำคัญและไม่ชัดเจนในระบบ ซึ่งรวมถึงเหตุผลที่เลือกขนาดส่วนย่อยโดยเฉพาะและผลการทดลองที่แสดงให้เห็น วิธีปรับเทียบค่าขีดจำกัดความคล้ายคลึงของแคชเชิงความหมาย รูปแบบการแทรกคำสั่งที่ตัวกรองตรวจจับได้ในปัจจุบันและรูปแบบที่ตรวจจับไม่ได้ ตลอดจนวิธีเพิ่มเครื่องมือใหม่ให้ตัวแทน เอกสารภายในที่ดีช่วยลดเวลาในการเริ่มงานของผู้ร่วมพัฒนารายใหม่ และป้องกันไม่ให้ผู้ที่ไม่ทราบเหตุผลเบื้องหลังเปลี่ยนแปลงการตัดสินใจเหล่านี้กลับโดยไม่ได้ตั้งใจ
# INTERNALS.md — key non-obvious decisions:
#
# ## Chunk Size: 800 tokens with 100 token overlap
# We tested 400, 600, 800, 1200 tokens.
# 800 tokens maximizes hit rate (89%) while keeping context
# small enough for 5 chunks to fit comfortably in 4096 token prompt.
# Larger chunks improved recall but degraded precision.
#
# ## Cache Similarity Threshold: 0.92
# Tested 0.85, 0.90, 0.92, 0.95.
# 0.92 gives 31% hit rate with <2% incorrect cache hits.
# 0.85 gives 41% hit rate but 8% incorrect hits (too aggressive).
#
# ## Reranker Top-N: 3 (from initial 10)
# More than 3 chunks causes context stuffing without quality gain.สิ่งที่คุณสร้างขึ้น
ลองทบทวนระบบทั้งหมดที่คุณสร้างขึ้นในโครงงานสรุปนี้ ได้แก่ กระบวนการ RAG แบบผสมที่ผสานการค้นคืนข้อมูลแบบหนาแน่นและแบบกระจัดกระจายเข้ากับการจัดอันดับใหม่ ตัวแทนแบบสตรีมที่รองรับการเรียกใช้ฟังก์ชันและมีกลไกป้องกันความปลอดภัย แคชเชิงความหมายที่ช่วยลดค่าใช้จ่ายลง 30% ตัวตัดวงจรที่ช่วยให้สลับไปใช้ระบบสำรองโดยอัตโนมัติ การประเมิน LLM ในบทบาทผู้ประเมินที่ทำงานอย่างต่อเนื่องในกระบวนการผสานรวมและส่งมอบอย่างต่อเนื่อง และ กลไกป้องกันการแทรกคำสั่งที่ป้องกันข้อมูลนำเข้าที่มุ่งโจมตี นี่คือวิศวกรรมปัญญาประดิษฐ์สำหรับระบบจริง
# System capabilities summary:
SYSTEM_CAPABILITIES = {
'retrieval': 'Hybrid BM25+dense with Cohere reranking, 89% hit rate',
'generation': 'GPT-4o with Claude fallback, circuit breaker, streaming',
'caching': 'Semantic cache (Redis+embeddings), 31% cache hit rate',
'security': 'Injection filter (2-stage) + output scanning + tenant isolation',
'observability': 'LangSmith traces + Prometheus metrics + PagerDuty alerts',
'evaluation': 'Automated LLM-as-judge in CI, daily full suite, LangSmith evals',
'reliability': '99.94% uptime, circuit breakers, graceful degradation ladder',
'cost': '$0.031/query average, model routing saves 67% vs GPT-4o only',
}ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจของคุณเกี่ยวกับการนำระบบปัญญาประดิษฐ์ไปใช้งานจริงและการประเมินระบบ
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า การประเมินขั้นสุดท้ายต้องผสานตัวชี้วัดการค้นคืนข้อมูล คะแนนจากการประเมิน LLM ในบทบาทผู้ประเมิน การทดสอบปริมาณงาน และการตรวจสอบความปลอดภัย ก่อนเริ่มการนำระบบไปใช้งานใด ๆ การนำระบบแบบสีน้ำเงิน-สีเขียวไปใช้งานโดยค่อย ๆ เปลี่ยนเส้นทางปริมาณการใช้งาน ช่วยให้ย้อนกลับไปใช้ระบบเดิมได้ทันทีโดยไม่ต้องหยุดให้บริการ และ การทบทวนหลังการดำเนินงานกับคู่มือปฏิบัติการช่วยบันทึกองค์ความรู้ขององค์กร ซึ่งลดเวลาในการแก้ไขเหตุการณ์ในอนาคต ขอแสดงความยินดีที่เรียนจบเส้นทางวิศวกรรมปัญญาประดิษฐ์: LLM, RAG และตัวแทน!
คำถามที่พบบ่อย
บทเรียน “การประเมินผล การนำไปใช้งาน และการทบทวนหลังดำเนินการ” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การประเมินผล การนำไปใช้งาน และการทบทวนหลังดำเนินการ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Engineering Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การประเมินผล การนำไปใช้งาน และการทบทวนหลังดำเนินการ”
เรียกใช้ชุดเครื่องมือประเมินผลฉบับเต็ม ซึ่งรวมเมตริกการค้นคืน คะแนนคุณภาพแบบ LLM-as-judge และการทดสอบโหลด นำระบบไปใช้งานกับผู้ให้บริการคลาวด์ และเขียนรายงานทบทวนบทเรียนที่ได้รับ คุณปฏิบัติ 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 ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง
- การพัฒนาความสามารถหลักของ RAG และเอเจนต์
- การเสริมความแข็งแกร่ง: ความปลอดภัย การแคช และความน่าเชื่อถือ
- การประเมินผล การนำไปใช้งาน และการทบทวนหลังดำเนินการ