AI ฝ่ายบริการลูกค้า Anthropic ลดต้นทุนเหลือ 1 ใน 5 แม่นยำ 90.5%

กรณีศึกษา AI ฝ่ายบริการลูกค้าของ Anthropic พบว่าความแม่นยำในการตอบเพิ่มขึ้นจาก 78.6% เป็น 90.5% ขณะที่ต้นทุนต่อรายการลดลงเหลือประมาณ 1 ใน 5 ของเดิม

Anthropic เปิดเผยเมื่อวันที่ 28 กันยายนผ่านบล็อกสำหรับนักพัฒนาว่าได้เพิ่มคำสั่ง ‘build-eval’ และ ‘hillclimb’ ในสกิล ‘claude-api’ ที่ใช้กับ Claude Code โดย build-eval จะสร้างชุดประเมินจากบันทึกการใช้งานจริงและทิกเก็ตฝ่ายบริการลูกค้า ส่วน hillclimb จะปรับพรอมต์ โมเดล และพารามิเตอร์ทีละรายการตามผลการประเมิน

การประเมินฝ่ายบริการลูกค้าครั้งนี้ใช้ทิกเก็ตทั้งหมด 44 รายการ แบ่งเป็น 30 รายการสำหรับกระบวนการปรับแต่ง และอีก 14 รายการเก็บไว้ตรวจสอบผลลัพธ์ขั้นสุดท้าย

จุดเริ่มต้นคือ Opus 4.8 ที่ใช้ระดับการให้เหตุผลสูง โดยมีความแม่นยำด้านการตัดสินใจ 74.4% จากทิกเก็ตสำหรับการปรับแต่ง และมีต้นทุนโทเค็น 4.6 เซนต์ต่อรายการ หรือประมาณ 62 วอน

Claude เริ่มจากตรวจสอบพรอมต์และนำขั้นตอนเรียกใช้เครื่องมือแบบบังคับ ขั้นตอนร่างคำตอบ และกฎที่ขัดแย้งกันออก จากนั้นจึงใช้ Opus 5.5 ที่มีระดับการให้เหตุผลต่ำกว่า ทำให้ความแม่นยำเพิ่มเป็น 87.8% และลดต้นทุนเหลือ 1.9 เซนต์ต่อรายการ หรือประมาณ 26 วอน

ราคาขาเข้าและขาออกของโทเค็น Opus 5.5 ต่ำกว่า Opus 4.8 อยู่ 20% ขณะที่ต้นทุนการอ่านแคชลดลง 60% Anthropic ระบุว่าการเปลี่ยนโมเดลและการจัดระเบียบพรอมต์ต่างมีส่วนช่วยลดต้นทุน

Anthropic ยังทดสอบ Sonnet 5 ซึ่งมีราคาถูกกว่า โดย Sonnet 5 ที่ใช้ระดับการให้เหตุผลต่ำมีความแม่นยำประมาณ 88.9% และลดต้นทุนเหลือประมาณ 1 เซนต์ต่อรายการ หรือประมาณ 14 วอน

เมื่อเพิ่มกฎการจัดหมวดหมู่คำถามและขั้นตอนตรวจสอบวงเงินคืนเงินแบบไขว้ลงในพรอมต์ ความแม่นยำของทิกเก็ตสำหรับการปรับแต่งเพิ่มขึ้นเป็น 98.9% ส่วนทิกเก็ตตรวจสอบ 14 รายการที่แยกไว้ให้ผลลัพธ์ 90.5% สำหรับการตั้งค่าขั้นสุดท้าย สูงกว่าการตั้งค่าเดิมที่ 78.6%

หัวใจของ hillclimb คือการใช้ข้อเสนอเปลี่ยนแปลงเพียงรายการเดียวในแต่ละครั้ง หลังแบ่งชุดประเมินเป็นชุดปรับแต่งและชุดตรวจสอบ ระบบจะอ่านเฉพาะผลจากชุดปรับแต่งแล้วเสนอการแก้ไข หากคะแนนชุดปรับแต่งเพิ่มขึ้นแต่คะแนนชุดตรวจสอบไม่เปลี่ยนแปลง จะถือว่าเกิดการปรับเข้ากับข้อมูลมากเกินไปและย้อนการเปลี่ยนแปลงนั้น

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

build-eval จะตรวจสอบบันทึกการสนทนาในสภาพแวดล้อมจริงเป็นลำดับแรก จากนั้นจึงใช้รายงานข้อผิดพลาดและทิกเก็ตฝ่ายบริการลูกค้า ตามด้วยกรณีศึกษาที่นักพัฒนาเขียนขึ้นเอง 5-10 กรณี และกรณีสังเคราะห์จากโค้ด โดยนักพัฒนาจะตรวจสอบข้อมูลนำเข้าแต่ละรายการก่อนนำไปใช้ในการประเมิน

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

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

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

Anthropic ยังใช้วิธีเดียวกันกับสกิล claude-api โดยอัตราผ่านการประเมินเพิ่มจาก 66% เป็นประมาณ 88% กระบวนการนี้ช่วยค้นหาและแก้ไขฟังก์ชันที่ขาดหาย ข้อผิดพลาดในเอกสารของแต่ละภาษาโปรแกรม และกรณีที่โจทย์ไม่สอดคล้องกับเกณฑ์การให้คะแนน

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