การประเมินการตัดสินใจ
การวัดคุณภาพและต้นทุน
การประเมินการตัดสินใจ เป็นบทเรียน AI Prompt Engineering ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Prompt Engineering และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Prompt Engineering มีบทเรียนทั้งหมด 4 บทเรียน
คุณตัดสินใจไม่ได้หากวัดผลไม่ได้
การเลือกระหว่างพรอมป์ การปรับแต่ง และระบบไฮบริดจะดีได้เท่ากับ การประเมิน ที่อยู่เบื้องหลังเท่านั้น หากไม่มีชุดประเมินที่ตรึงไว้และแบบจำลองต้นทุน การเปรียบเทียบทุกครั้งก็เป็นเพียงความคิดเห็นจากประสบการณ์
- คุณภาพและต้นทุนเป็น สองแกน อย่ารวมทั้งสองอย่างให้เหลือเป็นตัวเลขเดียวเร็วเกินไป
- ชุดประเมินต้องเป็นข้อมูลที่กันไว้นอกการฝึก และคงที่สำหรับทุกแนวทางที่นำมาเปรียบเทียบ
- ผู้ชนะคือแนวทางที่อยู่บนจุดที่ดีที่สุดของเส้นพรมแดนคุณภาพ-ต้นทุนภายใต้ข้อจำกัดของคุณ
สร้างชุดประเมินคงที่ก่อน
ก่อนเปรียบเทียบสิ่งใด ให้สร้าง ชุดประเมินที่กันไว้นอกการฝึก ซึ่งไม่มีแนวทางใดใช้ฝึก ชุดนี้ต้องครอบคลุมการกระจายตัวจริง ได้แก่ กรณีทั่วไป กรณีขอบที่ทราบ และข้อมูลนำเข้าที่ออกแบบมาเพื่อทดสอบระบบ ในสัดส่วนใกล้เคียงกับการใช้งานจริง
ตรึงชุดนี้ไว้ ทุกแนวทาง ไม่ว่าจะเป็นใช้พรอมป์อย่างเดียว ปรับแต่ง หรือไฮบริด ต้องได้รับการให้คะแนนจากชุดเดียวกันทุกประการ หากชุดประเมินเปลี่ยนไประหว่างการเปรียบเทียบ ตัวเลขก็เปรียบเทียบกันไม่ได้และการตัดสินใจก็ไม่ถูกต้อง
def split_eval(labeled, holdout_ratio=0.2, seed=42):
import random
rng = random.Random(seed) # fixed seed = reproducible split
data = labeled[:]
rng.shuffle(data)
cut = int(len(data) * (1 - holdout_ratio))
train, frozen_eval = data[:cut], data[cut:]
return train, frozen_eval # eval never enters any training runเลือกตัวชี้วัดให้ตรงกับภารกิจ
ความแม่นยำทั่วไปอาจบดบังความล้มเหลวเฉพาะภารกิจ ให้เลือกตัวชี้วัดที่สะท้อนสิ่งสำคัญจริงดังนี้
- การตรงกันทุกประการ/ตรงกับสคีมา สำหรับผลลัพธ์ที่มีโครงสร้าง
- การให้คะแนนตามเกณฑ์โดย LLM ในบทบาทผู้ตัดสิน สำหรับคุณภาพแบบปลายเปิด พร้อมตัวอย่างที่มนุษย์ตรวจสอบแล้ว
- ตัวชี้วัดส่วนปลาย ได้แก่ กรณีแย่ที่สุดและ p95 ไม่ใช่ดูแค่ค่าเฉลี่ย
- อัตราความปลอดภัย/การปฏิเสธ ในฐานะเงื่อนไขบังคับ โดยให้คะแนนแยกจากคุณภาพ
คะแนนเฉลี่ยที่ซ่อนกรณีส่วนปลายอันเลวร้ายไว้จะทำให้คุณตัดสินใจผิด
ให้คะแนนผู้สมัครทุกตัวด้วยวิธีเดียวกัน
นำแนวทางใช้พรอมป์อย่างเดียว ปรับแต่ง และไฮบริด ผ่าน ตัวให้คะแนนเดียวกันบนชุดข้อมูลคงที่เดียวกัน บันทึกทั้งคุณภาพและเวกเตอร์ต้นทุนทั้งหมดของแต่ละแนวทาง เพื่อให้การเปรียบเทียบเป็นธรรม
def evaluate(candidate, frozen_eval, scorer):
results = []
for ex in frozen_eval:
out = candidate.run(ex['input'])
results.append(scorer(out, ex['label']))
mean = sum(results) / len(results)
p95 = sorted(results)[int(0.95 * len(results)) - 1]
return {'mean': mean, 'p95_worst': p95}
# Identical frozen_eval + scorer for prompt / tuned / hybridจำลองเวกเตอร์ต้นทุนทั้งหมด
ต้นทุนไม่ใช่ตัวเลขเดียว ให้เก็บทุกองค์ประกอบเพื่อให้การเปรียบเทียบสะท้อนความเป็นจริงในปริมาณการใช้งานของคุณ
- การอนุมานต่อการเรียกใช้: โทเค็นขาเข้า + ขาออก คูณด้วยราคา พรอมป์ยาวมีต้นทุนต่อการเรียกใช้สูงกว่า
- ต้นทุนการฝึกแบบเฉลี่ยถ่วงตามอายุการใช้งาน: กระจายต้นทุนการปรับแต่งไปตามปริมาณคำขอที่คาดไว้
- การบำรุงรักษา: กระบวนการข้อมูล การเรียกใช้การประเมิน และการปรับแต่งใหม่เมื่อโมเดลพื้นฐานเปลี่ยนแปลง
- เวลาแฝง: คิดราคาแยกต่างหากเมื่อมีผลต่อการเปลี่ยนผู้เข้าชมหรือต่อประสบการณ์ผู้ใช้
def monthly_cost(calls, in_tok, out_tok, price_in, price_out,
train_cost=0.0, months_amortized=12):
inference = calls * ((in_tok/1000)*price_in + (out_tok/1000)*price_out)
amortized_train = train_cost / months_amortized
return inference + amortized_train
# Long prompt-only: high in_tok, train_cost=0
# Tuned: low in_tok, train_cost>0 amortized over volumeวาดเส้นพรมแดนคุณภาพ-ต้นทุน
เมื่อมีคุณภาพและต้นทุนรายเดือนของผู้สมัครแต่ละรายแล้ว ให้วางตำแหน่งบน เส้นพรมแดน ผู้สมัครจะถูกครอบงำหากมีอีกรายที่มีทั้งคุณภาพสูงกว่าและต้นทุนต่ำกว่า ให้ตัดผู้สมัครที่ถูกครอบงำออก
ในกลุ่มที่ไม่ถูกครอบงำ การเลือกที่เหมาะสมขึ้นอยู่กับข้อจำกัดของคุณ ให้เลือกตัวเลือกที่ถูกที่สุดซึ่งผ่านเกณฑ์คุณภาพ หรือเลือกคุณภาพสูงสุดที่อยู่ภายในเพดานต้นทุน ตอนนี้การตัดสินใจจึงชัดเจนและมีเหตุผลรองรับ ไม่ใช่เรื่องของความชอบ
def non_dominated(candidates):
# candidate: {'name','quality','cost'} -- higher quality, lower cost better
keep = []
for c in candidates:
dominated = any(o['quality'] >= c['quality'] and o['cost'] <= c['cost']
and o != c for o in candidates)
if not dominated:
keep.append(c)
return keepนัยสำคัญทางสถิติ ไม่ใช่สัญญาณรบกวน
การเพิ่มขึ้นสองคะแนนจากชุดประเมิน 200 ตัวอย่างอาจเป็นเพียงสัญญาณรบกวน ก่อนประกาศผู้ชนะ ให้ตรวจสอบว่าช่องว่างด้านคุณภาพนั้น มีความหมายทางสถิติ เมื่อพิจารณาจากขนาดชุดประเมินของคุณ
ใช้การเปรียบเทียบแบบจับคู่ โดยส่งตัวอย่างเดียวกันผ่านผู้สมัครทั้งสองราย และคำนวณช่วงความเชื่อมั่นของผลต่าง หากช่วงดังกล่าวคร่อมศูนย์ แสดงว่ายังไม่มีการปรับปรุงที่แท้จริง และต้นทุนเพิ่มเติมของการปรับแต่งก็ไม่สมเหตุสมผล
def paired_diff_ci(scores_a, scores_b):
import statistics
diffs = [a - b for a, b in zip(scores_a, scores_b)]
mean = statistics.mean(diffs)
sd = statistics.pstdev(diffs)
se = sd / (len(diffs) ** 0.5)
return (mean - 1.96*se, mean + 1.96*se) # if it spans 0 -> not significantป้องกันการรั่วไหลของชุดประเมิน
วิธีที่เร็วที่สุดที่จะทำให้การปรับแต่งดูดีเกินจริงคือ การรั่วไหล ซึ่งเกิดจากตัวอย่างฝึกที่ทับซ้อนกับชุดประเมิน ชุดประเมินที่รั่วไหลจะให้รางวัลกับการจดจำ และทำให้คะแนนของผู้สมัครที่ปรับแต่งแล้วสูงเกินจริง
กำจัดข้อมูลซ้ำข้ามขอบเขตชุดฝึกกับชุดประเมิน ตรวจหาข้อมูลที่เกือบซ้ำกัน และเลือกชุดประเมินที่แยกตามเวลา หากเป็นไปได้ โดยกันข้อมูลตามวันที่ เพื่อให้โมเดลที่ปรับแต่งแล้วไม่เคยเห็นข้อมูลเหล่านั้นมาก่อน การรั่วไหลเป็นสาเหตุที่พบบ่อยที่สุดของการตัดสินใจปรับแต่งที่ล้มเหลวเมื่อนำไปใช้งานจริง
ติดตามผลหลังนำไปใช้งาน
การตัดสินใจยังไม่ถือเป็นที่สิ้นสุดเมื่อเปิดใช้งาน การกระจายตัวของข้อมูลจริงเปลี่ยนแปลงไป และโมเดลที่ปรับแต่งแล้วอาจเสื่อมคุณภาพอย่างเงียบ ๆ เมื่อข้อมูลเข้าเคลื่อนห่างจากการกระจายตัวของข้อมูลฝึก
- สุ่มตัวอย่างข้อมูลการใช้งานจริงและให้คะแนนด้วยเกณฑ์เดียวกัน
- แจ้งเตือนเมื่อคุณภาพลดลงและเมื่อต้นทุนต่อการเรียกใช้เพิ่มขึ้น
- เรียกใช้ชุดประเมินคงที่อีกครั้งทุกครั้งที่เวอร์ชันโมเดลพื้นฐานเปลี่ยน
ให้ถือว่าแนวทางที่เลือกเป็นสมมติฐานที่ต้องทดสอบอย่างต่อเนื่อง ไม่ใช่การตัดสินใจที่ปิดตาย
บันทึกการตัดสินใจ
บันทึกการเปรียบเทียบเป็น บันทึกการตัดสินใจ ที่เป็นลายลักษณ์อักษร โดยระบุชุดประเมินคงที่ คุณภาพและเวกเตอร์ต้นทุนของผู้สมัครแต่ละราย ผลการทดสอบนัยสำคัญ ปริมาณการใช้งานที่สมมติไว้ และจุดที่เลือกบนเส้นพรมแดนพร้อมเหตุผล
วิธีนี้ทำให้ตรวจสอบการเลือกได้และประเมินใหม่ได้ เมื่อปริมาณการใช้งานหรือโมเดลพื้นฐานเปลี่ยน ให้เปิดบันทึกอีกครั้งและเรียกใช้การประเมินใหม่ แทนที่จะถกเถียงจากความทรงจำ
ฟังก์ชันการตัดสินใจตั้งแต่ต้นจนจบ
เชื่อมทุกอย่างเข้าด้วยกัน ให้คะแนนผู้สมัครแต่ละรายบนชุดประเมินคงที่ เพิ่มต้นทุนของแต่ละราย ตัดตัวเลือกที่ถูกครอบงำออก กำหนดให้มีนัยสำคัญเหนือพื้นฐานที่ถูกที่สุด แล้วเลือกตามข้อจำกัดที่ผูกมัดคุณไว้
def decide(candidates, quality_bar, cost_ceiling):
frontier = non_dominated(candidates)
feasible = [c for c in frontier
if c['quality'] >= quality_bar and c['cost'] <= cost_ceiling]
if not feasible:
return 'NO_CANDIDATE_MEETS_CONSTRAINTS'
# cheapest option that clears the quality bar
return min(feasible, key=lambda c: c['cost'])['name']
# Prefer prompt-only on ties: lower maintenance TCOตรวจสอบอย่างรวดเร็ว
โมเดลที่ปรับแต่งแล้วได้คะแนนสูงกว่าการใช้พรอมป์ 2 คะแนนจากชุดประเมิน 150 ตัวอย่าง แต่ช่วงความเชื่อมั่นแบบจับคู่ของผลต่างคร่อมศูนย์ และยังมีต้นทุนรายเดือนสูงกว่า การตัดสินใจที่ถูกต้องคืออะไร
สรุปทบทวน
ตัดสินใจจากชุดประเมินคงที่และเวกเตอร์ต้นทุนที่ตรงไปตรงมา ไม่ใช่จากสัญชาตญาณ คุณภาพและต้นทุนเป็นสองแกน คำตอบคือจุดหนึ่งบนเส้นพรมแดนคุณภาพ-ต้นทุน ซึ่งเลือกตามข้อจำกัดที่ผูกมัดคุณไว้
- ตรึงชุดประเมินหนึ่งชุดไว้ และให้คะแนนผู้สมัครทุกตัวด้วยวิธีเดียวกัน
- เลือกตัวชี้วัดให้ตรงกับภารกิจ และติดตามผลส่วนปลาย ไม่ใช่ดูแค่ค่าเฉลี่ย
- จำลองเวกเตอร์ต้นทุนทั้งหมด และเฉลี่ยต้นทุนการฝึกตามปริมาณการใช้งานจริง
- กำหนดให้มีนัยสำคัญทางสถิติ ช่วงความเชื่อมั่นที่คร่อมศูนย์หมายถึงไม่มีการปรับปรุง
- ป้องกันการรั่วไหลของชุดประเมิน ซึ่งเป็นสาเหตุหลักของชัยชนะจากการปรับแต่งที่ลวงตา
- ติดตามผลหลังเปิดใช้งานและบันทึกการตัดสินใจ เพื่อให้เรียกใช้การประเมินใหม่ได้
คำถามที่พบบ่อย
บทเรียน “การประเมินการตัดสินใจ” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การประเมินการตัดสินใจ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Prompt Engineering ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Prompt Engineering มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การประเมินการตัดสินใจ”
การวัดคุณภาพและต้นทุน คุณปฏิบัติ AI Prompt Engineering ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AI Prompt Engineering หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน AI Prompt Engineering บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “การประเมินการตัดสินใจ” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน AI Prompt Engineering นี้ได้ไหม
ได้ บทเรียน AI Prompt Engineering ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- เมื่อการใช้พรอมต์ก็เพียงพอ
- เมื่อใดควรปรับแต่งละเอียด
- แบบผสม: พรอมต์และการปรับแต่งเล็กน้อย
- การประเมินการตัดสินใจ