การเพิ่ม Agent อีกตัวมีประโยชน์เมื่อช่วยแบ่งงานได้ชัด เช่น แยกค้นหลักฐานคนละชุด แยกบริบทเฉพาะทาง หรือทำงานที่ไม่ต้องรอกัน แต่ถ้าแต่ละตัวเพียงคิดเรื่องเดิมซ้ำแล้วส่งสรุปยาว ๆ ต่อกัน ระบบอาจซับซ้อนขึ้นโดยงานไม่ได้ดีขึ้นตาม
คำถามของธุรกิจจึงควรเป็น งานส่วนไหนจะแม่นขึ้น เร็วขึ้น หรือดูแลต่อได้ง่ายขึ้นเมื่อแยก และประโยชน์นั้นคุ้มกับการประสานงานหรือไม่ Agent ตัวเดียวก็เรียกได้หลายเครื่องมือและทำได้หลายขั้นตอนอยู่แล้ว
ตรวจว่างานส่วนนี้ต้องให้ Agent เลือกทางเองหรือไม่
การรับใบแจ้งหนี้ ตรวจช่องข้อมูลที่จำเป็น แล้วส่งเข้าคิวอนุมัติ อาจเป็นงานที่มีเส้นทางแน่นอน ระบบ Workflow ปกติควบคุมลำดับได้ และเรียกโมเดลเฉพาะจุดที่ต้องตีความ โดยไม่ต้องให้โมเดลกำหนดกระบวนการทั้งหมด
Building effective agents ของ Anthropic แยก Workflow ที่มีเส้นทางกำหนดไว้จากระบบที่โมเดลเลือกขั้นตอนถัดไปเอง พร้อมแนะนำให้เพิ่มความซับซ้อนเมื่อมีเหตุผลรองรับ การแยกแบบนี้ช่วยออกแบบได้มากกว่าการเรียกทุกครั้งที่ใช้โมเดลว่าเป็น Agent
ลองวงจุดที่ยังไม่แน่นอนในงานจริง หากขั้นต่อไปตัดสินได้จากสถานะหรือกฎชัดเจน โค้ดปกติอาจเหมาะกว่า แต่หากต้องสำรวจหลักฐานและปรับแนวค้นตามสิ่งที่พบ จึงค่อยพิจารณา Agent สำหรับส่วนนั้นอย่างมีขอบเขต
ใช้งานประเมินผู้ขายเป็นตัวอย่าง
สมมติทีมจัดซื้อต้องการรายงานที่รวมความสามารถผู้ขาย เงื่อนไขในใบเสนอราคา และเอกสารสินค้า หลักฐานเหล่านี้อาจแยกค้นได้พร้อมกัน ถ้าทุกส่วนอ้างถึงผู้ขาย สินค้า และคำขอชุดเดียวกัน
ทางหนึ่งคือใช้ Agent ตัวเดียวกับเครื่องมือที่อธิบายชัด ให้ดึงใบเสนอราคา ตรวจเอกสารสินค้า แล้วเตรียมรายงาน อีกทางคือแบ่งหน้าที่ค้นหลักฐานให้ผู้ช่วยหลายตัว และมีส่วนกลางรวบรวมสิ่งที่พบพร้อมจัดการข้อขัดแย้ง ทั้งสองแบบไม่ควรออกใบสั่งซื้อเพียงเพราะรายงานเสร็จแล้ว
ควรเริ่มจากแบบตัวเดียวเพื่อมีผลตั้งต้นให้เทียบ ตรวจว่าปัญหาคือหลงบริบท เลือกเครื่องมือผิด หรือต้องเสียเวลาค้นสิ่งที่ทำพร้อมกันได้จริง หากต้นเหตุคือรหัสผู้ขายไม่ครบ การเพิ่ม Agent อาจทำให้ความผิดเดียวกันกระจายไปหลายจุดแทน
เอกสาร Multi-agent ของ LangChain ระบุเหตุผลอย่างการแยกบริบทเฉพาะทาง การดูแลแต่ละส่วนแยกกัน และงานขนาน พร้อมชี้ว่า Agent ตัวเดียวที่มีเครื่องมือเหมาะสมก็อาจเพียงพอ เหตุผลเหล่านี้นำมาทดลองได้ แต่การที่บริษัทมีหลายแผนกยังไม่ใช่เหตุผลว่าต้องมี Agent ตามจำนวนแผนก
เลือกขอบเขตงานแล้วกำหนดสิ่งที่ต้องส่งต่อ
| ความต้องการที่พบ | โครงสร้างที่น่าทดลอง | สิ่งที่ต้องพิสูจน์ก่อนใช้ต่อ |
|---|---|---|
| งานเดียวมีขอบเขตและเครื่องมือไม่มาก | Agent ตัวเดียว | ทำงานถูกและจัดบริบทได้ |
| ค้นหลักฐานหลายด้านที่ไม่ต้องรอกัน | ตัวประสานงานกับผู้ช่วยค้นข้อมูล | ครบขึ้นหรือใช้เวลารวมน้อยลงหลังตรวจรวม |
| ลำดับแน่นอนแต่มีจุดตีความ | Workflow ที่เรียกโมเดลบางขั้น | สถานะชัดและกู้จากข้อผิดพลาดได้ |
| ใช้ความรู้เฉพาะบางครั้ง | โหลดบริบทหรือความสามารถตามงาน | เลือกเครื่องมือถูกขึ้นโดยไม่แบ่งงานเกินจำเป็น |
| บริการแยกทีมดูแล | ข้อตกลงรับส่งข้อมูลชัด และใช้ Agent เฉพาะส่วนที่เหมาะ | เจ้าของชัด ผลลัพธ์เข้ากัน และรับมือเมื่อล้มเหลวได้ |
โครงสร้างเหล่านี้ใช้ร่วมกันได้ คำว่า Multi-agent บอกวิธีแบ่งหน้าที่ แต่ไม่ได้ตอบว่าข้อมูลสถานะเก็บที่ใด ใครมีสิทธิ์ยืนยันคำสั่งจริง หรือระบบตรวจสิทธิ์อย่างไร
การส่งงานควรระบุเป้าหมาย ตัวตนที่กำลังตรวจ แหล่งข้อมูลที่ใช้ได้ รูปแบบผลลัพธ์ สิ่งที่อยู่นอกขอบเขต และเงื่อนไขหยุด อย่าส่งเพียงว่า “ช่วยดูผู้ขายรายนี้” ให้แต่ละตัวคืนแหล่งอ้างอิง จุดที่ขัดกัน และส่วนที่ยังทำไม่เสร็จด้วย มิฉะนั้นสรุปที่อ่านเรียบร้อยอาจซ่อนหลักฐานที่ขาดอยู่
ให้จุดเดียวรับผิดชอบการเปลี่ยนข้อมูลร่วม
ผู้ช่วยค้นข้อมูลส่งข้อค้นพบได้ แต่การให้ทุกตัวแก้ระเบียนปลายทางเดียวกันสร้างปัญหาอีกแบบ เช่น เขียนทับข้อสรุปของกันและกัน แนบหลักฐานผิดรุ่น หรือถือว่าผลบางส่วนหมายถึงงานทั้งชิ้นเสร็จแล้ว
ในงานประเมินผู้ขาย ควรเก็บผลแต่ละตัวแยกพร้อมรหัสงานและรุ่นแหล่งข้อมูล จากนั้นให้ขั้นรวบรวมที่กำหนดไว้รวมเป็นรายงานร่าง ตรวจชื่อผู้ขายหรือหน่วยสินค้าที่ขัดกันก่อนเสนอคำแนะนำ และคงข้อสงสัยไว้ ไม่เฉลี่ยคำตอบที่มีความหมายไม่ตรงกันให้กลายเป็นข้อสรุปเดียว
สิทธิ์ต้องบังคับที่แอปและเครื่องมือ การตั้งชื่อ Agent ว่า “นักค้นข้อมูล” ไม่ได้ทำให้มีสิทธิ์อ่านอย่างเดียวโดยอัตโนมัติ และคำสั่งคนละชุดก็ไม่ใช่ขอบเขตความปลอดภัย ให้แต่ละส่วนใช้เฉพาะคำสั่งที่จำเป็น และให้ระบบจัดซื้อตรวจสิทธิ์ของตนเอง ส่วนที่เตรียมคำแนะนำไม่ควรขอสิทธิ์ซื้อผ่านผู้ช่วยอีกตัวได้
เพิ่มตัวตรวจไม่ได้แปลว่าตัดข้อผิดพลาดร่วมออกแล้ว
การตรวจอีกรอบอาจพบสิ่งตกหล่น แต่การที่หลายโมเดลเห็นตรงกันยังไม่ใช่หลักฐานว่าถูก หากทุกตัวได้รับนโยบายเก่าหรือตารางที่อ่านผิดเดียวกัน ก็อาจยืนยันความผิดนั้นอย่างมั่นใจเหมือนกันทั้งหมด
ให้ผู้ตรวจมีเกณฑ์ชัดและเปิดดูหลักฐานต้นทางได้ ใช้การตรวจแบบกฎแน่นอนกับรหัส ช่องข้อมูลจำเป็น และการคำนวณที่ทำได้ หากเป็นข้อยกเว้นทางการค้าที่ไม่อยู่ในกฎ ควรมีจุดให้ผู้รับผิดชอบตัดสิน ผู้ตรวจต้องบอกว่าตรวจอะไรได้แล้วและหลักฐานส่วนใดยังหาไม่ได้
Anthropic เล่าการทำระบบค้นคว้าแบบ Multi-agent ทั้งประโยชน์จากการสำรวจพร้อมกันและภาระการประสานงานกับทรัพยากร นั่นเป็นหลักฐานของระบบค้นคว้ารูปแบบหนึ่ง ไม่ใช่คำรับรองว่าระบบรับคำสั่งซื้อจะได้ผลเท่ากัน ต้องทดลองกับงานที่จะเปิดใช้จริง
ทดสอบตอนประสานงานพลาดด้วย
ชุดทดสอบควรมีผู้ช่วยหมดเวลา ผลสองชุดขัดกัน ผลที่มาถึงหลังยกเลิก และข้อความงานที่ส่งซ้ำ กำหนดว่าระบบจะรอ ส่งรายงานที่ระบุชัดว่ายังไม่ครบ หรือหยุดให้คนตรวจ ผู้ช่วยที่ไม่ตอบไม่ควรหายไปจากเงื่อนไขสำเร็จของงานเฉย ๆ
กำหนดขีดจำกัดการแตกงาน จำนวนงานพร้อมกัน และการลองใหม่ เก็บรหัสงานแม่กับงานลูกให้ผู้ดูแลตามได้ว่าคำขอยังค้างเพราะอะไร เมื่อยกเลิกควรหยุดงานที่ไม่จำเป็นต่อ แต่คำสั่งภายนอกที่เกิดผลไปแล้วต้องตรวจสถานะแยก ไม่ถือว่าการหยุด Agent ย้อนผลนั้นให้เอง
เทียบอัตรางานที่รับได้ ความครบของหลักฐาน จำนวนครั้งที่คนต้องช่วย เวลารวม และการใช้ทรัพยากรกับแบบที่ง่ายกว่า รวมถึงความสะดวกในการดูแล เช่น เปลี่ยนผู้ช่วยหนึ่งส่วนแล้วผลลัพธ์ส่วนรวมยังทำงานต่อได้หรือไม่ การสาธิตที่เร็วขึ้นไม่เพียงพอ หากทุกครั้งที่แก้คำสั่งต้องไล่ตรวจระบบใหม่ทั้งหมด
สำหรับตัวอย่างจัดซื้อ ควรเก็บ Multi-agent ไว้เมื่อช่วยให้รายงานดีขึ้นภายใต้เกณฑ์ตรวจเดียวกัน และแยกการสั่งซื้อเป็นขั้นตอนที่ควบคุมต่างหาก อ่านต่อเรื่องAI ช่วยเทียบข้อเสนอผู้ขาย และสิทธิ์กับจุดอนุมัติของ Agent
Talvyn Labs ช่วยทดลองระบบตั้งต้นแบบ Agent เดียว แล้วพัฒนาส่วนประสานงานเท่าที่ผลิตภัณฑ์ต้องใช้จริง นำกระบวนการหนึ่งงานพร้อมแหล่งข้อมูลและกรณีผิดพลาดมาประเมิน เพื่อเลือกโครงสร้าง กำหนดผู้รับผิดชอบ และสร้าง AI Product ที่อธิบายได้ว่าทุกส่วนเพิ่มเข้ามาเพื่ออะไร
สร้าง Agent เท่าที่งานต้องใช้ และพิสูจน์ผลก่อนเพิ่มความซับซ้อน
ให้ Talvyn Labs ทดลองงานจริงแบบ Agent เดียว เทียบการแบ่งหน้าที่ แล้วพัฒนาระบบที่มีเจ้าของข้อมูลและจุดตรวจชัดเจน
ประเมินและพัฒนาระบบ Agent