> # TL;DR
>
> - การสร้าง LLM/AI agent ควร
> - ยึดความเรียบง่ายเป็นหลักการพื้นฐานเสมอ และเพิ่มความซับซ้อนเมื่อจำเป็นเท่านั้น
> - "ทำความเข้าใจเฟรมเวิร์กอย่างลึกซึ้งก่อนนำมาใช้", "ผสมผสานและทดสอบ workflow·agent pattern (เช่น chaining, routing, parallelization, evaluator-optimizer ฯลฯ) ให้เหมาะกับสภาพแวดล้อมจริงและเป้าหมาย พร้อมออกแบบเครื่องมือ (API) เอกสารประกอบ และการทดสอบอย่างรอบคอบ"
1. หลักการออกแบบ LLM agent ที่ประสบความสำเร็จ
- โฟกัสที่ความเรียบง่าย: การนำไปใช้ที่ประสบความสำเร็จมักพึ่งพาแพตเทิร์นที่เรียบง่ายและประกอบต่อยอดได้ (compoundable) มากกว่าจะพึ่งเฟรมเวิร์กที่ซับซ้อน
- เพิ่มความซับซ้อนเมื่อจำเป็นเท่านั้น: ควรออกแบบโครงสร้างพื้นฐานให้เรียบง่ายที่สุด และนำความซับซ้อนเข้ามาเฉพาะเมื่อจำเป็นจริง ๆ เท่านั้นจึงจะมีประสิทธิภาพ
- (ต้นฉบับ: "การนำไปใช้ที่ประสบความสำเร็จที่สุดไม่ได้พึ่งไลบรารีเฉพาะทางหรือเฟรมเวิร์กที่ซับซ้อน... แต่สร้างขึ้นบนพื้นฐานของแพตเทิร์นที่เรียบง่ายและประกอบเข้าด้วยกันได้")
2. แยกความแตกต่างระหว่าง Workflow กับ Agent
- Workflow: LLM และเครื่องมือทำงานตามเส้นทางที่กำหนดไว้ล่วงหน้า (code path)
- Agent: LLM จัดการงานและการใช้เครื่องมือแบบไดนามิกด้วยตัวเอง (LLM เป็นผู้ตัดสินใจหลัก)
- (ต้นฉบับ: "workflow คือการประสาน LLM และเครื่องมือตาม code path ที่กำหนดไว้ล่วงหน้า... ส่วน agent คือการที่ LLM สั่งการกระบวนการและวิธีใช้เครื่องมือของตัวเองแบบไดนามิก")
3. เกณฑ์ในการตัดสินใจใช้ Agent
- เริ่มจากวิธีง่าย ๆ → ค่อยเพิ่มความซับซ้อนเมื่อจำเป็น: เริ่มจากการเรียกใช้ LLM แบบง่าย ๆ หรือการค้นหาก่อน แล้วค่อยนำ Workflows/Agents เข้ามาแบบค่อยเป็นค่อยไปหากยังไม่เพียงพอ
- เมื่อความคาดเดาได้/ความสม่ำเสมอสำคัญ → เหมาะกับ workflow
- เมื่อจำเป็นต้องมีความยืดหยุ่นในวงกว้าง·การตัดสินใจที่ขับเคลื่อนโดยโมเดล → agent เหมาะกว่า
4. หลักการนำเฟรมเวิร์กมาใช้
- มีเครื่องมือ/เฟรมเวิร์กหลากหลาย เช่น LangGraph, Bedrock, Rivet, Vellum
- แต่แนะนำให้ เริ่มจากการใช้ LLM API โดยตรง ก่อน และค่อยนำเฟรมเวิร์กมาใช้เมื่อจำเป็น
- เมื่อใช้เฟรมเวิร์ก ต้องมี ความเข้าใจเชิงลึกต่อการทำงานภายใน (เพราะ abstraction อาจทำให้แก้ปัญหาได้ยากขึ้น)
- (ต้นฉบับ: "แนะนำให้นักพัฒนาเริ่มจากการใช้ LLM API โดยตรงก่อน")
5. Workflow ตามแพตเทิร์นที่ใช้จริงและตัวอย่าง
- Augmented LLM: เพิ่มความสามารถเสริมในตัว เช่น การค้นหา การเชื่อมต่อเครื่องมือ หน่วยความจำ ฯลฯ (การออกแบบอินเทอร์เฟซและเอกสารประกอบอย่างละเอียดเป็นสิ่งสำคัญ)
- Prompt Chaining: แบ่งงานหนึ่งงานออกเป็นหลายการเรียกใช้ LLM (หลายขั้นตอน) เพื่อให้ได้ความชัดเจนและความแม่นยำ
- ตัวอย่าง: สร้างข้อความการตลาด→แปล, ร่างเอกสาร→ตรวจทาน→เขียน
- Routing: จัดหมวดหมู่อินพุตก่อน แล้วแยกไปยังขั้นตอนประมวลผลหรือเครื่องมือที่เหมาะสม
- ตัวอย่าง: routing คำถามลูกค้าตามประเภท, ส่งต่อเฉพาะคำถามยากไปยังโมเดลสมรรถนะสูง
- Parallelization:
- Sectioning: แยกงานเป็นหลาย subtask เพื่อประมวลผลพร้อมกัน
- Voting: ลองทำงานเดียวกันหลายครั้งเพื่อตัดสินผลลัพธ์ที่ดีที่สุด
- ตัวอย่าง: ตรวจสอบช่องโหว่ของโค้ด, ทำงานอัตโนมัติด้านการประเมิน LLM
- Orchestrator-Workers: agent หลักกระจายและรวมงานย่อย
- ตัวอย่าง: ในงานเขียนโค้ดที่ซับซ้อน กระจายเฉพาะส่วนที่จำเป็นแบบเรียลไทม์, รวบรวม/บูรณาการข้อมูลหลายแหล่ง
- Evaluator-Optimizer: LLM หนึ่งตัวสร้างคำตอบ และอีกตัวประเมิน/ให้ feedback เพื่อปรับปรุงแบบวนซ้ำ
- ตัวอย่าง: ปรับปรุงผลการแปลแบบวนซ้ำ, การรวบรวมข้อมูลที่ซับซ้อน
6. กรณีใช้งานจริงในอุตสาหกรรม
- ฝ่ายสนับสนุนลูกค้า: ผสานแชตบอต+เครื่องมือ เพื่อทำงานอัตโนมัติด้านข้อมูลลูกค้า/คำสั่งซื้อ/การคืนเงิน โดยมีเกณฑ์ความสำเร็จเรื่อง "การแก้ปัญหา" ที่ชัดเจน และมีตัวอย่างจากองค์กรที่ใช้การคิดค่าบริการแบบ usage-based จริง
- Coding agent: ทำซ้ำและปรับปรุงจาก feedback ของการทดสอบอัตโนมัติ ซึ่งพิสูจน์แล้วใน SWE-bench เป็นต้น โดยเป็นโดเมนที่วัดปัญหาและคุณภาพผลลัพธ์ได้ชัดเจน อย่างไรก็ตาม ยังจำเป็นต้องมีมนุษย์ตรวจทานขั้นสุดท้ายเสมอ
7. เคล็ดลับด้าน tool prompt engineering (ภาคผนวก 2)
- แนะนำให้ใช้ ฟอร์แมตที่ LLM ใช้งานได้สะดวก และจัดสรรโทเค็นอย่างเพียงพอ
- อธิบายเครื่องมือให้ชัดเจน (usage, ตัวอย่าง, edge case, การกำหนดขอบเขต ฯลฯ)
- ทดสอบรูปแบบการใช้งานจริงของโมเดลแล้ว ปรับปรุงต่อเนื่อง (เช่น ใช้ workbench)
- ออกแบบแบบ poka-yoke เพื่อช่วย ป้องกันความผิดพลาดเล็กน้อย
- (ต้นฉบับ: "นิยามเครื่องมือที่ดีควรรวมตัวอย่างการใช้งาน, edge case, ข้อกำหนดรูปแบบอินพุต และขอบเขตที่ชัดเจนกับเครื่องมืออื่น ๆ")
8. หลักการสำคัญ
- รักษาความเรียบง่าย (Keep it simple)
- ความโปร่งใสของกระบวนการวางแผน (Planning) ของ agent เป็นสิ่งจำเป็น
- เอกสารประกอบและการทดสอบของเครื่องมือ·อินเทอร์เฟซต้องชัดเจน
- เฟรมเวิร์กช่วยเพิ่มความเร็วในช่วงเริ่มต้นได้ แต่ควร ลด abstraction ให้เหลือน้อยที่สุด และแนะนำให้ควบคุมโดยตรง
ยังไม่มีความคิดเห็น