การประเมินคุณภาพผลลัพธ์ของ LLM ใน Production

ในเดือนมีนาคม 2023 GPT-4 ระบุจำนวนเฉพาะด้วยความแม่นยำ 97.6% แต่พอถึงเดือนมิถุนายน 2023 โมเดลเดิมกลับมีความแม่นยำลดลงเหลือเพียง 2.4% โดยที่ไม่มีใครเปลี่ยนโค้ด และไม่มีใครเปลี่ยน Prompt เลย โมเดลเพียงแค่เปลี่ยนไปเอง

นี่คือปัญหาหลักของการใช้ LLM ใน production คุณไม่ได้เป็นคนควบคุมโมเดล แต่มันคือ dependency ที่มีการ drift หากคุณไม่วัดผล ผู้ใช้งานจะเป็นคนบอกคุณเองว่ามันพัง

คุณไม่สามารถพึ่งพาแค่ความรู้สึกหรือคำว่า "ดูเหมือนจะดีนะ" ได้ คุณต้องการสัญญาณที่สามารถวัดซ้ำได้ (repeatable signals)

ซอฟต์แวร์แบบดั้งเดิมนั้นเป็นแบบ deterministic (อินพุตเดิมจะได้เอาต์พุตเดิมเสมอ) แต่ LLM ทำลายกฎนี้ เพราะพวกมันเป็นแบบ non-deterministic และคำว่า "ถูกต้อง" มักจะมีความคลุมเครือ

เพื่อจัดการเรื่องนี้ คุณต้องมีการประเมิน 3 ระดับ:

  • Offline evals: รันชุดทดสอบที่กำหนดไว้ทุกครั้งที่มีการเปลี่ยนแปลงเพื่อตรวจจับการถดถอยของประสิทธิภาพ (regressions)
  • Reference-free checks: ใช้สัญญาณอย่างการตรวจจับการหลอน (hallucination detection) เมื่อคุณไม่มีคำตอบที่ "ถูกต้อง" แน่นอน
  • Production monitoring: เฝ้าดูทราฟฟิกจริงเพื่อตรวจหาการ drift และคุณภาพที่ลดลง

รากฐานสำคัญคือ Golden Dataset อย่าใช้การสุ่มตัวอย่าง แต่ให้ใช้ชุดข้อมูลที่คัดสรรมาแล้วซึ่งเป็นกรณีที่ยากๆ เช่น อินพุตที่ว่างเปล่า, กรณีขอบ (edge cases) ที่แปลกประหลาด และ adversarial prompts ตัวอย่างที่เฉียบคมเพียง 80 ตัวอย่าง มีค่ามากกว่าการสุ่มมา 8,000 ตัวอย่าง

เมื่อใช้ LLM เป็นผู้ตัดสิน (judge) ให้ระวังอคติ (biases) เหล่านี้:

  • Position bias: ผู้ตัดสินมักจะเอนเอียงไปทางคำตอบแรกที่เห็น แก้ไขได้โดยการเปรียบเทียบสลับลำดับกัน
  • Verbosity bias: ผู้ตัดสินมักให้คะแนนคำตอบที่ยาวกว่า แม้ว่ามันจะชัดเจนน้อยกว่าก็ตาม
  • Self-enhancement bias: โมเดลชอบข้อความที่มาจากตระกูลเดียวกัน แก้ไขได้โดยการใช้โมเดลต่างตระกูลกันในการตัดสินผลลัพธ์

สำหรับการตรวจสอบแบบเรียลไทม์ ให้ใช้ RAG Triad เพื่อตรวจสอบ:

  • Faithfulness: คำตอบยึดตามบริบท (context) หรือไม่?
  • Answer relevance: คำตอบตรงประเด็นกับคำถามหรือไม่?
  • Context relevance: ระบบดึงเอกสารที่ถูกต้องมาหรือไม่?

เลิกมองว่าคุณภาพของโมเดลเป็นคุณสมบัติที่คงที่ แต่ให้มองเหมือนกับ latency หรืออัตราข้อผิดพลาด (error rates) มันมีการเปลี่ยนแปลง หน้าที่ของคุณคือสังเกตให้ได้ว่าเมื่อไหร่ที่มันเริ่มไม่ดี

เริ่มจากจุดเล็กๆ เขียน golden examples ขึ้นมา 20 ตัวอย่าง แล้วใช้พวกมันเป็นเกณฑ์ในการ deploy จากนั้นค่อยเพิ่ม heuristics ใน production ที่ราคาถูกลงในภายหลัง

ทีมที่นอนหลับได้อย่างสนิทไม่ใช่ทีมที่มีโมเดลที่ฉลาดที่สุด แต่คือทีมที่รู้ได้ภายในหนึ่งชั่วโมงว่าโมเดลของพวกเขากำลังโง่ลงหรือไม่

Source: https://dev.to/nazar_boyko/evaluating-llm-output-quality-in-production-39an

Optional learning community: https://t.me/GyaanSetuAi