เจาะลึก
AI / ML
Elastic ทิ้ง eval แบบชุ่ยๆ แล้วสร้างกรอบประเมิน AI agent ระดับโปรดักชัน
จาก eval กระจัดกระจายไม่มีระเบียบ สู่ระบบเดียวที่ผสาน LLM-as-a-judge เข้ากับกฎตายตัว
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ต่อให้โมเดลเก่งแค่ไหน ถ้าไม่มีระบบประเมินที่ดีพอ คุณก็ไม่รู้เลยว่ามันพังตอนไหน
ถ้าคุณเคยลองสร้าง AI agent จริงจังสักตัว คุณจะรู้ว่าสิ่งที่โหดที่สุดไม่ใช่ตอนเขียนโค้ดให้มันทำงานได้ แต่คือตอนที่ต้องตอบให้ได้ว่ามัน "ทำงานได้ดีแค่ไหน" ต่างหาก และนั่นคือโจทย์ที่ Elastic เอามาเล่าในงานนำเสนอของ Susan Chang ว่าพวกเขาย้ายตัวเองจากจุดที่แต่ละทีมทำ eval แบบต่างคนต่างทำ ไม่มีมาตรฐานกลาง ไปสู่กรอบประเมินระดับโปรดักชันที่ใช้ร่วมกันทั้งบริษัทได้ยังไง
ฟังดูเหมือนเรื่อง interno ของบริษัทเดียว แต่จริงๆ มันสะท้อนปัญหาที่แทบทุกทีมที่ทำ agentic AI กำลังเจอเหมือนกันหมด นั่นคือพอระบบมันซับซ้อนขึ้น พอมี RAG มี workload ด้าน cybersecurity มีหลายขั้นตอน วิธีประเมินแบบเดิมที่เขียนสคริปต์ทดสอบง่ายๆ เอาไม่อยู่แล้ว
จุดตั้งต้นของ Elastic คือสิ่งที่ Chang เรียกว่า eval แบบ siloed และ ad-hoc คือแต่ละทีมมีวิธีวัดของตัวเอง ต่างคนต่างเขียน ต่างคนต่างรัน พอจะดูภาพรวมว่าคุณภาพของ agent เป็นยังไงจริงๆ กลับตอบไม่ได้ เพราะไม่มีอะไรเชื่อมกันเลย พอระบบโตขึ้น ปัญหานี้ก็ยิ่งชัด
ทางออกที่พวกเขาเลือกคือสร้างกรอบประเมินแบบ unified ที่ใช้ร่วมกันได้ทั้งองค์กร และทำให้มันพร้อมใช้ในระดับโปรดักชัน ไม่ใช่แค่ notebook ทดลองในห้องแล็บ
หัวใจของกรอบนี้คือการหาจุดสมดุลระหว่างสองวิธีที่ต่างกันคนละขั้ว ฝั่งหนึ่งคือ LLM-as-a-judge ที่ให้โมเดลตัวหนึ่งมาช่วยตัดสินคุณภาพคำตอบของอีกตัว ข้อดีคือยืดหยุ่น จับ nuance ได้ดี แต่ก็มีข้อเสียเรื่องความไม่แน่นอนและต้นทุน อีกฝั่งคือ deterministic rules คือกฎตายตัวที่ให้คำตอบเดิมทุกครั้ง ตรวจสอบได้ ชัดเจน แต่ก็แข็งทื่อเกินไปสำหรับงานที่คำตอบไม่มีถูกผิดตายตัว
การเอา two อย่างนี้มาอยู่ด้วยกันไม่ใช่เรื่อง trivial คุณต้องรู้ว่าเมื่อไหร่ควรใช้ตัวไหน ตรงไหนให้กฎตัดสิน ตรงไหนปล่อยให้โมเดลช่วยประเมิน นี่คือส่วนที่ทีมที่ทำ eval เองจะเข้าใจว่ามันกินเวลาคิดมากกว่ากินเวลาเขียนโค้ด
อีกประเด็นที่ Chang พูดถึงคือการเชื่อม eval ที่เขียนใน Python ซึ่งเป็นภาษาที่สาย data science ถนัด เข้ากับโค้ดโปรดักชันที่เขียนใน TypeScript ฟังดูเป็นเรื่องเทคนิคจืดๆ แต่จริงๆ มันคือ pain point ใหญ่ของหลายทีม เพราะฝั่งที่ทำ data science กับฝั่งที่ทำ production มักพูดกันคนละภาษา ทั้งในแง่เครื่องมือและในแง่วิธีคิด ถ้าไม่เชื่อมให้ดี eval ที่สวยหรูใน notebook ก็จบแค่ใน notebook
ส่วนที่ผมคิดว่าน่าสนใจที่สุดคือ deep tracing ที่ใช้ดัก regression ในงานที่ซับซ้อนอย่าง RAG และ cybersecurity พูดง่ายๆ คือพอ agent ทำงานหลายขั้นตอน การจะรู้ว่ามันเริ่มเพี้ยนตั้งแต่ step ไหนมันต้องมี tracing ที่ลงลึกพอ ไม่ใช่แค่ดูผลลัพธ์ปลายทางว่าโอเคหรือไม่โอเค
และที่สำคัญคือการรักษา domain context เอาไว้ เพราะงานอย่าง cybersecurity มันประเมินด้วยเกณฑ์กลางๆ ไม่ได้ ต้องเข้าใจบริบทของโดเมนนั้นจริงๆ ถึงจะบอกได้ว่าคำตอบไหนใช้ได้ คำตอบไหนใช้ไม่ได้ นี่คือจุดที่กรอบ eval สำเร็จรูปจากที่อื่นมักพัง
Unified framework
เลิกทำ eval แบบต่างคนต่างทำ รวมเป็นกรอบเดียวที่ใช้ร่วมกันทั้งองค์กร
LLM-as-a-judge + deterministic rules
ผสมความยืดหยุ่นของโมเดลตัดสิน กับความแน่นอนของกฎตายตัว
Python + TypeScript
เชื่อมงาน eval ฝั่ง data science เข้ากับโค้ดโปรดักชันจริง
Deep tracing
ดัก regression ในงาน RAG และ cybersecurity ที่ซับซ้อนหลายขั้นตอน
เรื่องนี้ไม่มีคำตอบสำเร็จรูป แต่มันเตือนว่าการทำ AI agent ให้เวิร์กจริงไม่จบที่ตัวโมเดล กรอบประเมินต่างหากคือสิ่งที่แยกระบบที่เชื่อถือได้ออกจากของเล่น ทีมไหนยังทำ eval แบบชุ่ยๆ อยู่ ถึงเวลาต้องจริงจังแล้ว
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...