เพิ่ม AI Agents หลายตัวแก้ปัญหาซัพพอร์ต ผลลัพธ์เท่าเดิม
การทดลองสร้างระบบ AI ซัพพอร์ตแบบ Multi-Agent เผยผลลัพธ์ว่าประสิทธิภาพและคะแนนความปลอดภัยไม่ต่างจากระบบ Single Agent แม้ซับซ้อนขึ้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- นักพัฒนาทดลองสร้างระบบ AI ซัพพอร์ตแบบ Multi-Agent เปรียบเทียบกับระบบเดิม
- ผลการทดสอบผ่านชุด eval suite พบว่าคะแนนทุกด้านเท่ากันทั้งหมด 100% ไม่มีส่วนไหนเปลี่ยนแปลง
- ต้นทุนที่เพิ่มขึ้นคือจำนวนไฟล์ โค้ดที่ยาวขึ้น และขั้นตอนการเรียกใช้งานที่ซับซ้อนกว่าเดิม
- ระบบสถาปัตยกรรมแบบแยกส่วนถูกเก็บไว้ใน repo เพื่ออ้างอิงและทดสอบอัตโนมัติในการบิลด์ทุกครั้ง
ในแวดวงสถาปัตยกรรมซอฟต์แวร์ ประโยคที่ว่าเราพิจารณาระบบ Multi-Agent แล้วแต่ปฏิเสธเพราะความซับซ้อน มักเป็นคำพูดที่ผู้พูดรู้สึกพึงพอใจในตัวเองมากที่สุด และเนื่องจากมันพิสูจน์ความเท็จได้ยาก จึงทำให้แนวคิดนี้ได้รับความนิยมสูงในการถกประเด็นทางเทคนิค
ด้วยเหตุนี้ นักพัฒนาจึงตัดสินใจลองลงมือสร้างระบบ Multi-Agent ขึ้นมาจริงๆ ตามซีรีส์บทความตอนที่ 12 ของการสร้าง LLM-powered support agent โดยแบ่งบทบาทออกเป็น เอเจนต์คัดกรองคำขอ (triage agent), ผู้เชี่ยวชาญด้านการคืนเงิน (refund specialist) ที่ดูแลเครื่องมือคำสั่งซื้อและประตูอนุมัติ, ผู้เชี่ยวชาญด้านความรู้ (knowledge specialist) ที่ตอบคำถามจากฐานข้อมูล และเอเจนต์ผู้ประสานงาน (coordinator) ที่คอยควบคุมภาพรวมทั้งหมด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ระบบทั้งสองเวอร์ชันถูกออกแบบให้ใช้งานอินเทอร์เฟซเดียวกัน เพื่อให้ชุดทดสอบประเมินผล (eval suite) สามารถให้คะแนนได้โดยไม่รู้ว่าระบบไหนคือต้นฉบับหรือระบบใหม่ โดยผลลัพธ์จากการรันคำสั่งเปรียบเทียบสถาปัตยกรรมแสดงตัวเลขที่น่าสนใจ
เมื่อดูจากตัวเลขการประเมิน ปรากฏว่าไม่มีสถานการณ์ทดสอบใดเลยที่เปลี่ยนคำตัดสิน และไม่มีคุณสมบัติข้อใดขยับแม้แต่เศษเสี้ยวเดียว ต้นทุนที่ต้องแลกมาจากการวัดผลในซอร์สโค้ดคือ ประเภทข้อมูลในระบบการผลิตเพิ่มขึ้นจาก 1 กลายเป็น 5 ส่วน บรรทัดโค้ดเพิ่มจาก 91 บรรทัดเป็น 127 บรรทัด และขั้นตอนการประสานงานเพิ่มจาก 1 ฮอปเป็น 2 ฮอป ซึ่งบนสถาปัตยกรรมที่ขับเคลื่อนด้วย LLM หมายความว่าการร้องขอหนึ่งครั้งจะต้องเรียกโมเดลเพิ่มขึ้นอย่างน้อยสองเท่า
การวิเคราะห์เพิ่มเติมชี้ให้เห็นว่า ในงานประเภท Single-turn ที่มีข้อความจากลูกค้าหนึ่งข้อความ ช่องทางเดียว ใช้เวลาทำงานไม่ถึงวินาที และชุดเครื่องมือขนาดเล็ก การมอบหมายงานต่อกัน (Delegation) จะกลายเป็นการส่งต่อภาระที่ไม่มีเนื้อหาให้ส่งต่ออย่างแท้จริง ต่างจากระบบย่อยที่ต้องประมวลผลไฟล์นับสิบไฟล์ซึ่งการทำงานแบบขนานจะช่วยให้เห็นผลลัพธ์คุ้มค่าทันที
การตัดสินใจเรื่องการกำหนดเส้นทาง (routing) คือการจำแนกเจตนาของผู้ใช้งาน ซึ่งระบบ Single Agent ทำงานส่วนนี้มาตั้งแต่ตอนที่ 6 แล้ว และเมื่อจัดเส้นทางเสร็จ เอเจนต์ผู้เชี่ยวชาญเหล่านี้ก็ยังคงเรียกใช้การตรวจสอบขอบเขตเดิม เอเจนต์นโยบายเดิม และประตูความเสี่ยงเดิม ในลำดับขั้นตอนเดียวกันเป๊ะๆ ไม่ใช่เพราะการคัดลอกโค้ด แต่เพราะลำดับนั้นคือข้อกำหนดทางธุรกิจที่ไม่สามารถประเมินสิทธิ์ก่อนยืนยันคำสั่งซื้อได้
สถาปัตยกรรมแบบ Multi-Agent ที่สร้างขึ้นนี้ไม่ใช่เอเจนต์อิสระที่ต่างฝ่ายต่างเรียกโมเดลและเจรจากันเองแบบรันタイム ซึ่งแนวทางนั้นจะช่วยซื้อฟีเจอร์จริงอย่างพรอมต์เฉพาะบทบาท เครื่องมือเฉพาะบทบาท หรือการรันแบบคู่ขนาน แต่ก็แลกมาด้วยการเรียกโมเดลที่เพิ่มขึ้น ค่าความหน่วง (latency) และความเสี่ยงที่เอเจนต์สองตัวจะเข้าใจความต้องการของลูกค้าไม่ตรงกัน
เพื่อป้องกันไม่ให้การตัดสินใจกลายเป็นเรื่องของรสนิยม ทีมงานจึงได้บันทึกข้อตัดสินใจทางสถาปัตยกรรม (ADR) พร้อมทั้งสร้างชุดทดสอบ MultiAgentEquivalenceTest ที่จะรันสถาปัตยกรรมทั้งสองแบบในทุกๆ บิลด์ เพื่อยืนยันว่าความแตกต่างของผลลัพธ์คือศูนย์ หากวันใดที่การทดสอบนี้พังลง การตัดสินใจดังกล่าวจะถูกหยิบขึ้นมาทบทวนผ่านผลลัพธ์จากชุดทดสอบแทนที่จะเป็นการถกเถียงด้วยคำพูด
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น