โมเดลความคิดสำหรับการทดสอบ AI

สิ่งที่จะยังคงอยู่และสิ่งที่จะหายไป: การแมปความรู้เกี่ยวกับการทดสอบบนเว็บกับโลกใหม่ของ LLM

Maud Nalpas

แอปพลิเคชันตัวอย่าง

ThemeBuilder เป็นแอปพลิเคชันตัวอย่างตลอดทั้งชุดนี้ ThemeBuilder จะแสดงออบเจ็กต์ JSON ที่มีคำขวัญและชุดสีที่ LLM สร้างขึ้น

• คำขวัญและชุดสีต้องตรงกับชื่อแบรนด์ คำอธิบาย กลุ่มเป้าหมาย และโทนเสียงที่ป้อน
• คำขวัญต้องไม่เป็นพิษ และต้องสั้น (ไม่เกิน 6 คำ)
• คอนทราสต์ของชุดสีต้องเข้าถึงได้ตามที่กำหนดไว้ในหลักเกณฑ์ขั้นต่ำของ WCAG โดยมีอัตราส่วนคอนทราสต์ 4.5:1

การประเมินเชิงวัตถุประสงค์และเชิงอัตวิสัย

คุณจะทดสอบว่า ThemeBuilder ทำงานได้ตามที่ต้องการได้อย่างไร

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

การตรวจสอบบางอย่างเป็นแบบปรนัย โดยมีคำตอบแบบไบนารีว่าถูกต้องหรือไม่ถูกต้อง คำถามเกี่ยวกับรูปแบบข้อมูล อัตราส่วนคอนทราสต์ หรือคำถามอื่นๆ ที่มีคำตอบที่ชัดเจนจะเหมาะกับคำถามเหล่านี้มากที่สุด คุณสามารถใช้การทดสอบเหล่านี้กับโค้ดปกติแบบเป็นโปรแกรม ได้ ซึ่งเรียกว่า rule-based-evals หรือ exact evals

เช่น

// Example rule-based eval: data format
function evaluateFormat(appOutput) {
  // Check if JSON is valid, colors are hex, no empty strings, motto is 6 words or fewer
  // Use deterministic tools like zod for schema validation
  return "PASS"; // or "FAIL"
}

การตรวจสอบอื่นๆ เป็นแบบอัตนัย เช่น การจัดแนวแบรนด์และกลุ่มเป้าหมายสำหรับ คำขวัญและชุดสี แม้ว่าการตรวจหาความเป็นพิษจะเป็นงานจัดประเภท แต่ก็เป็นเรื่องที่ขึ้นอยู่กับความคิดเห็นส่วนบุคคลด้วยเนื่องจากต้องมีการตัดสิน

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

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

[ผู้พิพากษา LLM] ใช้งานง่าย รวดเร็ว และมีราคาค่อนข้างถูก [...] วิธีนี้ได้กลายเป็นหนึ่งในวิธีที่พบได้บ่อยที่สุด (หากไม่ใช่วิธีที่พบได้บ่อยที่สุด) ในการประเมินโมเดล AI ในการผลิต

—AI Engineering, Chip Huyen

เช่น

// Example LLM-as-a-judge eval for a subjective quality like brand fit
async function evalBrandFit(userInput, appOutput) {
  const brandPrompt = `You are an expert brand strategist. Evaluate the
  following generated motto for the company whose target audience is
  ${userInput.audience}, and who describes itself as
  ${userInput.companyDescription}: ${appOutput.motto}`
  // Call the LLM judge
  const evalResult = evalWithLLM(brandPrompt);
  // Return the consolidated results
  return {
    mottoBrandFit: evalResult,
  };
}

// Helper that communicates with the LLM API
async function evalWithLLM(prompt) {
  // ... Call LLM with the prompt ...
  // ... Parse the resulting judgement ("PASS" or "FAIL") + rationale
  return {
    status: "PASS",
    rationale: "This motto perfectly captures the brand and tone, because..."
  };
}

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

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

การประเมินประเภทอื่นๆ

คุณอาจต้องการใช้การประเมินที่อิงตามการอ้างอิงหรือการประเมินแบบเป็นคู่

อิงตามการอ้างอิง

ซึ่งจะวัดความคล้ายคลึงกับคำตอบสำหรับข้อมูลจากการสังเกตการณ์โดยตรง ใช้สำหรับงานต่างๆ เช่น การแปลหรือข้อเท็จจริงทางเทคนิคที่มีคำตอบดี

Pairwise

ผู้พิพากษาอาจให้คะแนน PASS แก่เวอร์ชันที่แตกต่างกัน 2 เวอร์ชัน แม้ว่าเวอร์ชันหนึ่งจะดีกว่าอีกเวอร์ชันหนึ่งก็ตาม การประเมินแบบเป็นคู่จะแก้ปัญหานี้ด้วยการให้เอาต์พุต 2 รายการ (A และ B) แก่ผู้ประเมินสำหรับอินพุตเดียวกัน และสั่งให้ผู้ประเมินเลือกผู้ชนะ

ตัวอย่างเช่น สมมติว่าคุณกำลังประเมินคำขวัญสำหรับคาเฟ่ที่เป็นมิตร

Input: "Friendly cafe"

Pointwise evaluation:
Output A: "Come get coffee." // PASS
Output B: "Your morning smile in a cup." // PASS
2 PASS. Unconclusive!

Pairwise evaluation:
Output B wins. It captures the "friendly" tone more effectively than the generic Output A.

ใช้การประเมินแบบเป็นคู่เพื่อเลือกเวอร์ชันของโมเดลที่จะ นําไปใช้ หรือเพื่อเปรียบเทียบพรอมต์ 2 แบบที่แตกต่างกัน

การทดสอบเว็บมาตรฐานเทียบกับการประเมิน AI

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

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

วางเลเยอร์การทดสอบ

โค้ดเบสที่สมบูรณ์ควรมีการทดสอบหลายเลเยอร์ ได้แก่ การทดสอบหน่วย การทดสอบการถดถอยและการทดสอบการผสานรวม และการทดสอบแบบครบวงจร นอกจากนี้ คุณควรจัดเลเยอร์การประเมินด้วย

• ใช้การประเมินตามกฎร่วมกับการประเมิน LLM ในฐานะผู้พิพากษาเพื่อทดสอบแอปพลิเคชัน AI โดยอัตโนมัติอย่างเต็มรูปแบบ วิธีนี้จะช่วยให้คุณพบปัญหาในการพัฒนาและ CI/CD ในแต่ละวัน รวมถึงทดสอบว่ารุ่นที่พร้อมเผยแพร่เป็นไปตามเกณฑ์คุณภาพของคุณหรือไม่
• เรียกใช้การทดสอบการผสานรวมและการทดสอบถดถอยเพื่อยืนยันคุณภาพในวงกว้าง
• ทำการประเมินด้วยตนเองโดยมนุษย์เป็นการทดสอบการยอมรับ

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

พัฒนาการประเมินอย่างต่อเนื่อง

Evals ควรเติบโตไปพร้อมกับแอปพลิเคชันของคุณ เมื่อโมเดลของคุณฉลาดขึ้น ให้อัปเดตการประเมินเก่า

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

การประเมินของคุณวัดอะไร

ก่อนออกแบบการประเมิน คุณควรทำความเข้าใจวิธีประเมินเอาต์พุต มีคำศัพท์บางคำที่คุณควรรู้

เกณฑ์คือกฎ ซึ่งเป็นมิติข้อมูลที่ต้องทดสอบ เช่น ความสอดคล้องของแบรนด์ ความเป็นพิษ และการเข้าถึง

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

คุณสามารถวัดเกณฑ์เดียวกันด้วยเมตริกประเภทต่างๆ ได้ เช่น สำหรับการปรับแบรนด์ให้สอดคล้องกัน

• "คำขวัญนี้สอดคล้องกับแบรนด์ไหม" เมตริกคือ PASS หรือ FAIL
• "ในระดับ 1-5 สโลแกนสอดคล้องกับแบรนด์มากน้อยเพียงใด" เมตริกเป็นจำนวนเต็มระหว่าง 1 ถึง 5

เครื่องมือประเมินคือโค้ดหรือโมเดลที่ให้คะแนนเกณฑ์ ผู้ประเมิน กำหนดเมตริก