เอเจนต์คืออะไร?
- คำจำกัดความของเอเจนต์มีได้หลายแบบ แต่แบ่งได้เป็น 2 ประเภท:
- เวิร์กโฟลว์ (Workflows): LLM และเครื่องมือถูกประสานงานผ่านเส้นทางโค้ดที่กำหนดไว้ล่วงหน้า
- เอเจนต์ (Agents): LLM ควบคุมการทำงานและการใช้เครื่องมือแบบไดนามิก
- Anthropic จัดทั้งสองแบบนี้ไว้ในกลุ่ม ระบบเชิงเอเจนต์ (Agentic Systems) แต่มีความแตกต่างสำคัญในด้านความยืดหยุ่นและความเป็นอิสระ
ควรใช้เอเจนต์เมื่อใด?
- หากมีทางออกที่เรียบง่ายกว่าได้ การลดความซับซ้อนให้น้อยที่สุดคือสิ่งสำคัญ
- เวิร์กโฟลว์: มีประโยชน์เมื่อจัดการงานที่คาดการณ์ได้ และให้ความสม่ำเสมอกับความเสถียร
- เอเจนต์: เหมาะเมื่อจำเป็นต้องมีความยืดหยุ่นในระดับใหญ่และการตัดสินใจที่ขับเคลื่อนโดยโมเดล
- ในกรณีส่วนใหญ่ เพียงแค่ปรับการเรียกใช้ LLM ให้เหมาะสม หรือใช้ตัวอย่างในคอนเท็กซ์ก็เพียงพอแล้ว
แนวทางการใช้เฟรมเวิร์ก
- เฟรมเวิร์กตัวอย่าง:
- ข้อดีของเฟรมเวิร์ก:
- ทำให้การเรียก LLM, การกำหนดเครื่องมือ และเชนการเรียกใช้ง่ายขึ้น
- ข้อเสีย:
- อาจเพิ่มความซับซ้อนหรือทำให้ดีบักได้ยากขึ้น
- คำแนะนำ: เริ่มจาก LLM API โดยตรง และแม้จะใช้เฟรมเวิร์กก็ควรเข้าใจโค้ดพื้นฐานที่อยู่ข้างใต้
องค์ประกอบของระบบเอเจนต์
Augmented LLM
- คุณลักษณะ: เพิ่มความสามารถด้านการค้นหา การใช้เครื่องมือ และหน่วยความจำ
- วิธีนำไปใช้:
- สามารถผสานรวมกับเครื่องมือของบุคคลที่สามโดยใช้ Model Context Protocol
- มีอินเทอร์เฟซที่เรียบง่ายและมีเอกสารกำกับชัดเจน
แพตเทิร์นเวิร์กโฟลว์หลัก
- การเชื่อมพรอมป์ต์เป็นลำดับ (Prompt Chaining)
- แบ่งงานออกเป็นขั้นตอนย่อยคงที่และประมวลผลตามลำดับ
- กรณีใช้งาน:
- สร้างข้อความการตลาดแล้วค่อยแปล
- ร่างเอกสารแล้วค่อยตรวจทาน
- การจัดเส้นทาง (Routing)
- จัดประเภทข้อมูลนำเข้าแล้วส่งต่อไปยังงานที่เหมาะสม
- กรณีใช้งาน:
- จัดประเภทคำถามฝ่ายสนับสนุนลูกค้า (คำถามทั่วไป, คำขอคืนเงิน, ฝ่ายสนับสนุนทางเทคนิค)
- คำถามง่ายส่งไปยังโมเดลขนาดเล็ก ส่วนคำถามซับซ้อนส่งไปยังโมเดลที่ทรงพลังกว่า
- การทำงานแบบขนาน (Parallelization)
- แยกงานออกจากกันหรือรันงานเดียวกันหลายครั้ง
- กรณีใช้งาน:
- ใช้หลายพรอมป์ต์ในการตรวจสอบช่องโหว่ของโค้ด
- แยกข้อมูลนำเข้าจากผู้ใช้เพื่อกรองและตอบกลับ
- Orchestrator-Workers
- LLM ส่วนกลางแยกย่อยงาน มอบหมายให้ worker LLM และสรุปรวมผลลัพธ์
- กรณีใช้งาน:
- แก้ไขไฟล์ในงานเขียนโค้ดที่ซับซ้อน
- งานค้นหาข้อมูลหลายชุด
- Evaluator-Optimizer
- ประเมินคำตอบของ LLM และให้ฟีดแบ็กเพื่อปรับปรุงแบบวนซ้ำ
- กรณีใช้งาน:
- ปรับปรุงคุณภาพการแปลในงานแปลวรรณกรรม
- งานค้นหาและวิเคราะห์หลายรอบ
เอเจนต์
- เอเจนต์สามารถวางแผนงานและดำเนินการได้อย่างอิสระ พร้อมโต้ตอบกับมนุษย์เมื่อจำเป็น
- คุณลักษณะ:
- ใช้เครื่องมือเพื่อรับ "ความจริง" จากสภาพแวดล้อมและประเมินความคืบหน้า
- สามารถกำหนดจุดตรวจสอบและเงื่อนไขการหยุดระหว่างงานได้
- กรณีใช้งาน:
- เอเจนต์เขียนโค้ดที่ซับซ้อน
- การใช้งานที่ Claude ลงมือทำงานบนคอมพิวเตอร์
การผสานแพตเทิร์นและการปรับแต่ง
- แพตเทิร์นข้างต้นสามารถปรับและผสานรวมให้เหมาะกับสถานการณ์เฉพาะได้
- ควรเพิ่มความซับซ้อนก็ต่อเมื่อพิสูจน์ได้แล้วว่าช่วยให้ผลลัพธ์ดีขึ้น
สรุป
- ความสำเร็จในโลกของ LLM ไม่ได้ขึ้นอยู่กับการสร้างระบบที่ซับซ้อนที่สุด แต่ขึ้นอยู่กับการสร้าง ระบบที่เหมาะกับความต้องการ
- ควรเริ่มจาก พรอมป์ต์แบบง่าย ปรับให้เหมาะสมผ่านการประเมิน และพิจารณาเพิ่มระบบเอเจนต์หลายขั้นตอนเฉพาะเมื่อโซลูชันที่เรียบง่ายไม่เพียงพอ
- หลักการสำคัญในการนำเอเจนต์ไปใช้
- รักษาความเรียบง่าย: ออกแบบเอเจนต์ให้เรียบง่าย
- ให้ความสำคัญกับความโปร่งใส: แสดงขั้นตอนการวางแผนของเอเจนต์ให้ชัดเจน
- ปรับปรุงคุณภาพของ ACI (Agent-Computer Interface): จัดทำเอกสารเครื่องมือและทดสอบอย่างรอบคอบ
- การใช้เฟรมเวิร์กและกลยุทธ์การพัฒนา
- เฟรมเวิร์กมีประโยชน์ต่อการเริ่มต้นพัฒนา แต่ก็ควรพิจารณาสร้างระบบด้วย องค์ประกอบพื้นฐานโดยลดชั้นของ abstraction ลงด้วย
- หากทำตามหลักการข้างต้น ก็จะสามารถสร้างเอเจนต์ที่ทรงพลัง เชื่อถือได้ และดูแลรักษาได้ง่าย
กรณีศึกษาจากลูกค้า: การใช้เอเจนต์ในงานจริง
- A. ฝ่ายสนับสนุนลูกค้า
- มอบทางออกที่มีประสิทธิภาพผ่านการสนทนาที่เป็นธรรมชาติและการผสานรวมข้อมูลภายนอก
- ข้อดี:
- วัดผลได้จากอัตราการแก้ปัญหาสำเร็จ
- สามารถใช้โมเดลราคาตามการใช้งานได้
- B. เอเจนต์เขียนโค้ด
- โซลูชันด้านโค้ดสามารถตรวจสอบความถูกต้องได้ด้วยการทดสอบอัตโนมัติ
- ข้อดี:
- ใช้ผลการทดสอบเป็นฟีดแบ็กได้
- พื้นที่ของปัญหาชัดเจนและมีโครงสร้าง
- C. การออกแบบและปรับแต่งเครื่องมือ
- ออกแบบโดยคำนึงถึงวิธีที่ LLM ใช้งานเครื่องมือ
- แนวทางที่แนะนำ:
- ใช้ชื่อพารามิเตอร์ที่เข้าใจง่ายและกระชับ
- ทดสอบและปรับปรุงแบบวนซ้ำ
- ใส่ตัวอย่างและกรณีขอบในคำจำกัดความของเครื่องมือ
2 ความคิดเห็น
ดูเหมือนว่าจะเอาแนวคิดที่ทำให้ low-code ใช้งานได้ง่ายมาปรับใช้ แต่ถ้าไม่มี data schema และการจัดการเวอร์ชัน ก็คงติดตามการเปลี่ยนแปลงไม่ได้
จากประสบการณ์ที่ยังตื้น ๆ มันให้ความรู้สึกเหมือนการประกอบฟังก์ชันของการเขียนโปรแกรมเชิงฟังก์ชันแค่ภายนอก แต่เป็นการเขียนโปรแกรมที่สับสนวุ่นวายเพราะไม่รู้ว่า I/O ของฟังก์ชันนั้น (พารามิเตอร์, ชนิดค่าที่คืนกลับ) จะออกมาเป็นอะไร?..
ระหว่างทำก็อดคิดไม่ได้ตลอดว่า จำเป็นต้องทำสิ่งนี้จริง ๆ ไหม..? ต้องรองรับไปไกลขนาดนี้เลยหรือ..
จนถึงตอนนี้ก็ยังไม่ค่อยรู้สึกชัดเจนว่าสาขาไหนกันแน่ที่จำเป็นต้องใช้ระบบแบบ agentic