- เมื่อความสามารถของ LLM ในด้านการให้เหตุผล มัลติโหมด และการใช้เครื่องมือพัฒนาขึ้น จึงเกิดระบบหมวดหมู่ใหม่อย่าง เอเจนต์ ซึ่งสามารถ ดำเนินเวิร์กโฟลว์ได้อย่างอิสระ แทนผู้ใช้
- เอเจนต์ประกอบด้วยองค์ประกอบหลัก 3 ส่วน ได้แก่ โมเดล (LLM), เครื่องมือ (API/ฟังก์ชันภายนอก) และคำสั่ง (แนวทางกำกับ) และสามารถออร์เคสเตรตได้ทั้งในรูปแบบเอเจนต์เดี่ยวหรือระบบหลายเอเจนต์
- การนำเอเจนต์มาใช้เหมาะกับเวิร์กโฟลว์ที่ต้องการการตัดสินใจซับซ้อน ระบบกฎที่บำรุงรักษายาก และ การประมวลผลข้อมูลที่ไม่มีโครงสร้าง
- Guardrails คือกลไกป้องกันหลายชั้นที่ช่วยปกป้องความเป็นส่วนตัวของข้อมูล ความปลอดภัยของเนื้อหา และ ความสอดคล้องของแบรนด์ ซึ่งเป็นองค์ประกอบจำเป็นในการนำเอเจนต์ไปใช้งาน
- กุญแจสำคัญของการนำไปใช้ให้สำเร็จคือ แนวทางแบบวนซ้ำ ที่เริ่มจากเอเจนต์เดี่ยว ตรวจสอบกับผู้ใช้จริง แล้วค่อย ๆ ขยายต่อ
ความหมายของเอเจนต์
- เอเจนต์คือระบบที่ ทำงานได้อย่างอิสระแทนผู้ใช้ โดยจัดการเวิร์กโฟลว์ต่าง ๆ เช่น แก้ปัญหางานบริการลูกค้า จองร้านอาหาร commit การเปลี่ยนแปลงโค้ด หรือสร้างรายงาน
- แอปพลิเคชันที่รวม LLM แต่ไม่ได้ควบคุมการทำงานของเวิร์กโฟลว์ เช่น แชตบอตทั่วไป, LLM แบบเทิร์นเดียว, ตัวจำแนกอารมณ์ ฯลฯ ไม่ถือเป็นเอเจนต์
- คุณลักษณะหลักของเอเจนต์:
- ใช้ LLM เพื่อ จัดการการดำเนินเวิร์กโฟลว์ และตัดสินใจ รับรู้ได้ว่าเมื่อใดเวิร์กโฟลว์เสร็จสิ้น และปรับการทำงานเชิงรุกเมื่อจำเป็น
- หยุดการทำงานเมื่อเกิดความล้มเหลวและคืนสิทธิ์ควบคุมให้ผู้ใช้
- เข้าถึง เครื่องมือที่หลากหลาย เพื่อโต้ตอบกับระบบภายนอก และเลือกใช้เครื่องมือที่เหมาะสมแบบไดนามิกตามสถานะปัจจุบันของเวิร์กโฟลว์ โดยทำงานภายใน guardrails ที่ชัดเจน
เมื่อใดควรสร้างเอเจนต์
- ต่างจากระบบอัตโนมัติแบบเดิม เอเจนต์เหมาะกับเวิร์กโฟลว์ที่แนวทางเชิงกำหนดตายตัวและอิงกฎแบบดั้งเดิมเริ่มถึงขีดจำกัด
- ตัวอย่างการวิเคราะห์การฉ้อโกงการชำระเงิน: เอนจินกฎแบบเดิมทำงานแบบ เช็กลิสต์ โดยติดธงธุรกรรมตามเกณฑ์ที่ตั้งไว้ล่วงหน้า ขณะที่เอเจนต์ LLM ทำหน้าที่เหมือน นักสืบผู้ชำนาญ ที่ประเมินบริบท พิจารณารูปแบบที่ละเอียดอ่อน และระบุกิจกรรมต้องสงสัยได้แม้ไม่มีการละเมิดกฎอย่างชัดเจน
- มี 3 ประเภทที่การใช้เอเจนต์เพิ่มคุณค่าได้อย่างชัดเจน:
- การตัดสินใจที่ซับซ้อน: เวิร์กโฟลว์ที่ต้องอาศัยการพิจารณาอย่างละเอียด ข้อยกเว้น และการตัดสินใจที่ไวต่อบริบท (เช่น การอนุมัติคืนเงินในงานบริการลูกค้า)
- กฎที่บำรุงรักษายาก: ระบบที่มีกฎจำนวนมากและซับซ้อน ซึ่งการอัปเดตมีต้นทุนสูงหรือเกิดข้อผิดพลาดได้ง่าย (เช่น การตรวจทานความปลอดภัยของผู้ขาย)
- สถานการณ์ที่พึ่งพาข้อมูลไม่มีโครงสร้างสูง: เช่น การตีความภาษาธรรมชาติ การดึงความหมายจากเอกสาร และการโต้ตอบกับผู้ใช้แบบสนทนา (เช่น การดำเนินการเคลมประกันที่อยู่อาศัย)
- หากไม่เข้าเกณฑ์เหล่านี้อย่างชัดเจน โซลูชันเชิงกำหนดตายตัวอาจเพียงพออยู่แล้ว
พื้นฐานการออกแบบเอเจนต์
-
องค์ประกอบหลัก 3 ส่วน
- โมเดล(Model): LLM ที่ขับเคลื่อนการให้เหตุผลและการตัดสินใจของเอเจนต์
- เครื่องมือ(Tools): ฟังก์ชันภายนอกหรือ API ที่เอเจนต์ใช้เพื่อดำเนินการ
- คำสั่ง(Instructions): แนวทางและ guardrails แบบชัดเจนที่กำหนดวิธีการทำงานของเอเจนต์
-
การเลือกโมเดล
- ไม่ใช่ทุกงานที่ต้องใช้โมเดลที่ทรงพลังที่สุด — งานง่ายอย่างการค้นหาหรือจัดประเภทเจตนาสามารถใช้ โมเดลขนาดเล็กที่รวดเร็ว ได้ ส่วนงานยากอย่างการตัดสินใจอนุมัติคืนเงินจะได้ประโยชน์จากโมเดลที่ทรงพลังมากกว่า
- แนวทางที่มีประสิทธิภาพคือ ในช่วง prototype ให้ ตั้ง baseline ประสิทธิภาพด้วยโมเดลที่ทรงพลังที่สุด ก่อน จากนั้นค่อยแทนที่ด้วยโมเดลที่เล็กลงเพื่อดูว่ายังได้ผลลัพธ์ที่ยอมรับได้หรือไม่
- หลักการเลือกโมเดล:
- ตั้งค่า eval เพื่อกำหนด baseline ประสิทธิภาพ
- มุ่งให้ถึงเป้าหมายด้านความแม่นยำด้วยโมเดลที่ดีที่สุดก่อน
- แทนที่ด้วยโมเดลที่เล็กลงในจุดที่ทำได้เพื่อ เพิ่มประสิทธิภาพด้านต้นทุนและ latency
-
การกำหนดเครื่องมือ
- เครื่องมือช่วยขยายความสามารถของเอเจนต์ผ่านการใช้ API ของแอปพลิเคชันหรือระบบพื้นฐาน
- หากระบบ legacy ไม่มี API ก็สามารถใช้ computer-use model เพื่อโต้ตอบกับเว็บและ UI ของแอปพลิเคชันได้โดยตรง
- เครื่องมือแต่ละชิ้นควรมี คำนิยามที่เป็นมาตรฐาน และรองรับความสัมพันธ์แบบ many-to-many อย่างยืดหยุ่นระหว่างเครื่องมือกับเอเจนต์
- เครื่องมือแบบใช้ซ้ำได้ที่มีเอกสารชัดเจนและผ่านการทดสอบอย่างรอบด้าน ช่วยให้ค้นหาได้ง่ายขึ้น จัดการเวอร์ชันได้ง่ายขึ้น และป้องกันคำนิยามซ้ำซ้อน
- ประเภทเครื่องมือ 3 แบบที่เอเจนต์ต้องใช้:
- ข้อมูล(Data): ดึงบริบทและข้อมูลที่จำเป็นต่อการทำเวิร์กโฟลว์ (เช่น query ฐานข้อมูลธุรกรรม, ระบบ CRM, อ่าน PDF, ค้นหาเว็บ)
- การกระทำ(Action): โต้ตอบกับระบบเพื่อเพิ่มข้อมูลลงฐานข้อมูล อัปเดตเรคคอร์ด ส่งข้อความ ฯลฯ (เช่น ส่งอีเมล/ข้อความ, อัปเดตเรคคอร์ด CRM, ส่งต่อทิกเก็ตบริการลูกค้าให้มนุษย์)
- ออร์เคสเตรชัน(Orchestration): เอเจนต์เองทำหน้าที่เป็นเครื่องมือของเอเจนต์อื่น (เช่น เอเจนต์คืนเงิน, เอเจนต์วิจัย, เอเจนต์เขียน)
-
การจัดองค์ประกอบของคำสั่ง
- คำสั่งคุณภาพสูงจำเป็นต่อทุกแอปที่ใช้ LLM แต่สำหรับเอเจนต์นั้น สำคัญเป็นพิเศษ
- คำสั่งที่ชัดเจนช่วยลดความกำกวมและทำให้การตัดสินใจของเอเจนต์ดีขึ้น ส่งผลให้การรันเวิร์กโฟลว์ราบรื่นขึ้นและเกิดข้อผิดพลาดน้อยลง
- แนวปฏิบัติที่ดีสำหรับคำสั่งของเอเจนต์:
- ใช้เอกสารที่มีอยู่เดิม: ใช้ขั้นตอนปฏิบัติงาน สคริปต์ซัพพอร์ต และเอกสารนโยบายที่มีอยู่เพื่อสร้าง routine ที่เหมาะกับ LLM (ในงานบริการลูกค้า routine จะสอดคล้องคร่าว ๆ กับเอกสารรายชิ้นใน knowledge base)
- prompt สำหรับแยกงานย่อย: แตกทรัพยากรที่หนาแน่นให้เป็นขั้นตอนเล็ก ๆ ที่ชัดเจนเพื่อลดความกำกวม
- กำหนดการกระทำให้ชัดเจน: ระบุให้ทุกขั้นตอนของ routine สอดคล้องกับการกระทำหรือผลลัพธ์เฉพาะ (เช่น ขอเลขคำสั่งซื้อ, เรียกร้อง API เพื่อดึงรายละเอียดบัญชี)
- ครอบคลุม edge case: คาดการณ์รูปแบบทั่วไป เช่น ผู้ใช้ให้ข้อมูลไม่ครบหรือถามคำถามที่ไม่คาดคิด และใส่วิธีจัดการผ่านขั้นตอนแบบมีเงื่อนไขหรือกิ่งการทำงาน
- ยังสามารถใช้โมเดลขั้นสูงอย่าง o1 หรือ o3‑mini เพื่อสร้างคำสั่งจากเอกสารเดิมโดยอัตโนมัติได้ด้วย
การออร์เคสเตรต
-
ระบบเอเจนต์เดี่ยว
- เอเจนต์เดี่ยวสามารถรองรับงานจำนวนมากได้โดยค่อย ๆ เพิ่มเครื่องมือเข้าไป ทำให้ จัดการความซับซ้อนได้ และทำให้การประเมินกับการบำรุงรักษาง่ายขึ้น
- ทุกแนวทางของการออร์เคสเตรตต้องมีแนวคิดเรื่อง 'run' ซึ่งโดยทั่วไปจะถูกทำเป็นลูปที่ให้เอเจนต์ทำงานจนกว่าจะถึงเงื่อนไขสิ้นสุด
- เงื่อนไขสิ้นสุดที่พบบ่อย: การเรียกเครื่องมือ, เอาต์พุตแบบมีโครงสร้างเฉพาะ, ข้อผิดพลาด, หรือถึงจำนวนเทิร์นสูงสุด
- ใน Agents SDK จะเริ่มเอเจนต์ด้วยเมธอด
Agents.run() และลูปจะสิ้นสุดเมื่อเกิด การเรียกเครื่องมือเอาต์พุตสุดท้าย หรือ การตอบกลับจากโมเดลที่ไม่มีการเรียกเครื่องมือ
- กลยุทธ์ prompt template: ใช้พรอมป์ต์พื้นฐานแบบยืดหยุ่นเพียงชุดเดียวที่รับตัวแปรนโยบาย แทนการใช้พรอมป์ต์แยกจำนวนมาก เพื่อปรับตามบริบทต่าง ๆ ได้ และลดภาระด้านการบำรุงรักษากับการประเมินอย่างมาก
-
เมื่อใดควรเปลี่ยนไปใช้ระบบหลายเอเจนต์
- คำแนะนำทั่วไปคือ เพิ่มขีดความสามารถของเอเจนต์เดี่ยวให้เต็มที่ก่อน
- แม้การมีเอเจนต์มากขึ้นจะช่วยแยกแนวคิดได้ชัดเจนขึ้น แต่ก็มาพร้อมความซับซ้อนและ overhead เพิ่มเติม ดังนั้นบ่อยครั้งเอเจนต์เดี่ยวที่มีเครื่องมือก็เพียงพอแล้ว
- แนวทางปฏิบัติในการแยกเอเจนต์:
- ตรรกะซับซ้อน: หากในพรอมป์ต์มีเงื่อนไขจำนวนมาก (กิ่ง if-then-else) และ prompt template ขยายต่อได้ยาก ให้แยกแต่ละส่วนของตรรกะเป็นเอเจนต์คนละตัว
- เครื่องมือมากเกินไป: ปัญหาไม่ใช่จำนวนเครื่องมือ แต่คือความคล้ายหรือซ้ำซ้อน — มีการใช้งานที่จัดการเครื่องมือที่แยกจากกันชัดเจนมากกว่า 15 ชิ้นได้สำเร็จ ขณะที่บางกรณีกลับมีปัญหาแม้มีเครื่องมือซ้ำซ้อนน้อยกว่า 10 ชิ้น
-
รูปแบบผู้จัดการ (ใช้เอเจนต์เป็นเครื่องมือ)
- LLM ส่วนกลางที่เป็น "ผู้จัดการ" จะออร์เคสเตรตเครือข่ายของเอเจนต์เฉพาะทางผ่านการเรียกเครื่องมือ
- ผู้จัดการสามารถมอบหมายงานให้เอเจนต์ที่เหมาะสมในเวลาที่เหมาะสมโดยไม่สูญเสียบริบทหรือการควบคุม และสังเคราะห์ผลลัพธ์เป็น ปฏิสัมพันธ์แบบรวมศูนย์
- เหมาะกับเวิร์กโฟลว์ที่มีเอเจนต์เพียงตัวเดียวที่ควบคุมการรันเวิร์กโฟลว์และเข้าถึงผู้ใช้ได้
- ตัวอย่าง: เอเจนต์แปลภาษาเรียกเอเจนต์ภาษาสเปน ฝรั่งเศส และอิตาลีเป็นเครื่องมือ
-
รูปแบบกระจายศูนย์ (handoff ระหว่างเอเจนต์)
- เป็นการสลับทางเดียวที่เอเจนต์ 'handoff' การรันเวิร์กโฟลว์ไปยังเอเจนต์อื่น
- ใน Agents SDK, handoff เป็นเครื่องมือหรือฟังก์ชันชนิดหนึ่ง โดยเมื่อเรียกฟังก์ชัน handoff จะส่งสถานะบทสนทนาล่าสุดไปด้วย และเริ่มรันทันทีในเอเจนต์ใหม่
- เหมาะที่สุดกับรูปแบบที่แต่ละเอเจนต์รับช่วงการทำงานและโต้ตอบกับผู้ใช้โดยตรง โดยไม่จำเป็นต้องมีเอเจนต์ตัวกลางคงการควบคุมหรือสังเคราะห์ผลลัพธ์ไว้
- ตัวอย่าง: เอเจนต์ triage ประเมินคำถามของผู้ใช้แล้ว route ไปยังเอเจนต์ฝ่ายซัพพอร์ตด้านเทคนิค ฝ่ายขาย หรือจัดการคำสั่งซื้อ
-
กราฟแบบประกาศชัดเจน vs ไม่ประกาศชัดเจน
- บางเฟรมเวิร์กกำหนดให้ต้องนิยามล่วงหน้าด้วยวิธี declarative ว่าทุกกิ่ง ลูป และเงื่อนไขจะอยู่ในกราฟที่ประกอบด้วยโหนด (เอเจนต์) และขอบ (handoff) — แม้จะชัดเจนในเชิงภาพ แต่จะยุ่งยากเมื่อเวิร์กโฟลว์มีความไดนามิกและซับซ้อนขึ้น และยังต้องเรียนรู้ภาษาสำหรับโดเมนเฉพาะเพิ่มเติม
- Agents SDK ใช้แนวทาง code-first ที่ให้แสดงตรรกะของเวิร์กโฟลว์ด้วยโครงสร้างการเขียนโปรแกรมที่คุ้นเคยโดยตรง ทำให้สร้างการออร์เคสเตรตเอเจนต์ที่ไดนามิกและปรับตัวได้มากกว่า โดยไม่ต้องกำหนดกราฟทั้งหมดไว้ล่วงหน้า
Guardrails
-
บทบาทของ guardrails
- ช่วยจัดการความเสี่ยงด้านความเป็นส่วนตัวของข้อมูล (เช่น ป้องกันการรั่วไหลของ system prompt) และความเสี่ยงด้านชื่อเสียง (เช่น บังคับให้โมเดลทำงานสอดคล้องกับแบรนด์)
- Guardrail เพียงตัวเดียวมักไม่เพียงพอสำหรับการป้องกันที่ดี จึงจำเป็นต้อง ใช้ guardrails เฉพาะทางหลายตัวร่วมกัน เพื่อสร้างเอเจนต์ที่ทนทานมากขึ้น
- แม้ guardrails จะเป็นองค์ประกอบสำคัญ แต่ก็ต้องใช้ร่วมกับโปรโตคอลการยืนยันตัวตนและการกำหนดสิทธิ์ที่แข็งแรง การควบคุมการเข้าถึงอย่างเข้มงวด และมาตรการความปลอดภัยซอฟต์แวร์มาตรฐาน
-
ประเภทของ guardrails
- Relevance classifier: ตรวจสอบว่าคำตอบของเอเจนต์อยู่ในขอบเขตที่ตั้งใจไว้หรือไม่ และติดธงคำถามนอกหัวข้อ (เช่น "ตึกเอ็มไพร์สเตตสูงเท่าไร?" จะถูกติดธงว่าอยู่นอกหัวข้อ)
- Safety classifier: ตรวจจับอินพุตที่ไม่ปลอดภัย เช่น jailbreak หรือ prompt injection ที่พยายามใช้ประโยชน์จากช่องโหว่ของระบบ
- PII filter: ป้องกันการเปิดเผยข้อมูลส่วนบุคคลที่ระบุตัวตนได้ (PII) โดยไม่จำเป็นในเอาต์พุตของโมเดล
- Moderation: ติดธงอินพุตที่เป็นอันตรายหรือไม่เหมาะสม เช่น hate speech การคุกคาม หรือความรุนแรง
- Tool safeguards: ให้ ระดับความเสี่ยงต่ำ/กลาง/สูง กับแต่ละเครื่องมือตามเกณฑ์อย่างการเข้าถึงแบบอ่านอย่างเดียวเทียบกับเขียน ความย้อนกลับได้ สิทธิ์บัญชีที่ต้องใช้ และผลกระทบทางการเงิน จากนั้นจึงทริกเกอร์การทำงานอัตโนมัติ เช่น หยุดเพื่อตรวจสอบ guardrails หรือส่งต่อให้มนุษย์ก่อนรันฟังก์ชันที่มีความเสี่ยงสูง
- Rules-based protections: ใช้มาตรการเชิงกำหนดตายตัวอย่างง่าย เช่น blocklist, ข้อจำกัดความยาวอินพุต, และตัวกรอง regex เพื่อป้องกันคำต้องห้ามหรือภัยคุกคามที่รู้จักกันดีอย่าง SQL injection
- Output validation: ใช้ prompt engineering และการตรวจสอบเนื้อหาเพื่อยืนยันว่าคำตอบสอดคล้องกับคุณค่าของแบรนด์
-
แนวทางการสร้าง guardrails
- เริ่มจากตั้ง guardrails สำหรับความเสี่ยงที่ระบุได้แล้ว และเพิ่มชั้นป้องกันเมื่อค้นพบช่องโหว่ใหม่
- heuristic ที่มีประสิทธิภาพ:
- โฟกัสที่ความเป็นส่วนตัวของข้อมูลและความปลอดภัยของเนื้อหา
- เพิ่ม guardrails ใหม่จาก edge case จริงและกรณีล้มเหลวจริง
- ปรับ guardrails ไปพร้อมกับการพัฒนาของเอเจนต์ โดยเพิ่มประสิทธิภาพทั้งด้านความปลอดภัยและประสบการณ์ผู้ใช้
- ใน Agents SDK, guardrails ถูกมองเป็น first-class concept และโดยค่าเริ่มต้นใช้แนวทาง optimistic execution — เอเจนต์หลักจะสร้างเอาต์พุตล่วงหน้าพร้อมกับที่ guardrails ทำงานไปพร้อมกัน และจะทริกเกอร์ exception หากมีการละเมิดข้อจำกัด
-
การวางแผนให้มนุษย์เข้ามาเกี่ยวข้อง
- การให้มนุษย์เข้ามาเกี่ยวข้องเป็น มาตรการความปลอดภัยสำคัญ ที่ช่วยปรับปรุงประสิทธิภาพจริงของเอเจนต์ได้โดยไม่ทำลายประสบการณ์ผู้ใช้
- มีความสำคัญอย่างยิ่งในช่วงแรกของการนำไปใช้ เพราะช่วยระบุความล้มเหลว ค้นพบ edge case และสร้างวงจรการประเมินที่แข็งแรง
- มี 2 ตัวกระตุ้นหลักที่ควรให้มนุษย์เข้ามาเกี่ยวข้อง:
- เกินเกณฑ์ความล้มเหลว: ตั้งข้อจำกัดสำหรับการ retry หรือการกระทำของเอเจนต์ และเมื่อเกินขีดจำกัด (เช่น ยังไม่สามารถเข้าใจเจตนาของลูกค้าได้แม้พยายามหลายครั้ง) ให้ส่งต่อให้มนุษย์
- การกระทำความเสี่ยงสูง: การกระทำที่อ่อนไหว ย้อนกลับไม่ได้ หรือมีผลกระทบสูง (เช่น ยกเลิกคำสั่งซื้อของผู้ใช้ อนุมัติคืนเงินจำนวนมาก หรือประมวลผลการชำระเงิน) ควรอยู่ภายใต้การกำกับของมนุษย์จนกว่าจะมั่นใจในเอเจนต์มากพอ
บทสรุป
- เอเจนต์คือยุคใหม่ของระบบอัตโนมัติเวิร์กโฟลว์ ที่สามารถให้เหตุผลกับความกำกวม ลงมือทำผ่านเครื่องมือ และจัดการงานหลายขั้นตอนด้วย ความเป็นอิสระสูง
- ต่างจากแอป LLM ทั่วไป เอเจนต์สามารถ รันเวิร์กโฟลว์แบบ end-to-end จึงเหมาะกับการตัดสินใจที่ซับซ้อน ข้อมูลไม่มีโครงสร้าง และระบบอิงกฎที่เปราะบาง
- เพื่อสร้างเอเจนต์ที่เชื่อถือได้: ต้องผสานโมเดลที่มีความสามารถ เครื่องมือที่นิยามชัดเจน และคำสั่งที่ชัดเจนมีโครงสร้าง พร้อมใช้รูปแบบการออร์เคสเตรตที่เหมาะกับระดับความซับซ้อน โดย เริ่มจากเอเจนต์เดี่ยวและขยายเป็นหลายเอเจนต์เมื่อจำเป็นเท่านั้น
- Guardrails มีความสำคัญในทุกขั้นตอน ตั้งแต่การกรองอินพุต การใช้เครื่องมือ ไปจนถึงการให้มนุษย์เข้ามาเกี่ยวข้อง เพื่อให้มั่นใจว่าเอเจนต์จะทำงานใน production ได้อย่างปลอดภัยและคาดการณ์ได้
- การนำไปใช้ให้สำเร็จไม่ใช่เรื่อง all-or-nothing แต่คือแนวทางแบบวนซ้ำที่ เริ่มเล็ก ตรวจสอบกับผู้ใช้จริง และค่อย ๆ เพิ่มขีดความสามารถตามเวลา
ยังไม่มีความคิดเห็น