การสร้าง AI Agent ที่มีประสิทธิภาพ

 (anthropic.com)
8 คะแนน โดย GN⁺ 2025-06-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากประสบการณ์ภาคสนามของ Anthropic พบว่า LLM agent ที่ประสบความสำเร็จมักเริ่มจาก แพตเทิร์นที่เรียบง่ายและประกอบเข้าด้วยกันได้ มากกว่าเฟรมเวิร์กที่ซับซ้อน
  • ระบบแบบ agentic แบ่งได้เป็น workflow ที่ทำตามเส้นทางโค้ดที่กำหนดไว้ และ agent ที่ LLM ตัดสินใจแบบไดนามิกเกี่ยวกับขั้นตอนและการใช้เครื่องมือ
  • แอปพลิเคชัน LLM จำนวนมากเพียงพอแล้วด้วยการเรียก LLM ครั้งเดียวที่เสริมด้วยการค้นหาและตัวอย่างในบริบท และควรเพิ่มความซับซ้อนก็ต่อเมื่อการประเมินยืนยันว่าได้ผลจริง
  • เฟรมเวิร์กช่วยให้เริ่มต้นได้เร็ว แต่ ชั้น abstraction ที่บดบัง prompt และ response อาจทำให้การดีบักยากขึ้น
  • autonomous agent เก่งกับปัญหาแบบปลายเปิด แต่มีความเสี่ยงเรื่อง ต้นทุนที่เพิ่มขึ้น และการสะสมของข้อผิดพลาด จึงต้องมีการทดสอบใน sandbox, guardrail และการออกแบบเครื่องมือที่ชัดเจน

การแบ่งประเภทพื้นฐานของระบบแบบ agentic

  • ระบบแบบ agentic เป็นคำที่ใช้กว้าง ตั้งแต่ระบบอัตโนมัติเต็มรูปแบบที่ทำงานได้เองเป็นเวลานาน ไปจนถึงการ implement ที่ทำตาม workflow ที่กำหนดไว้ล่วงหน้า
  • Anthropic มองรูปแบบย่อยเหล่านี้ทั้งหมดว่าเป็นระบบแบบ agentic แต่แบ่งตามสถาปัตยกรรมออกเป็นสองแบบ
    • workflow: LLM และเครื่องมือถูก orchestrate ตามเส้นทางโค้ดที่กำหนดไว้ล่วงหน้า
    • agent: LLM สั่งการและควบคุมวิธีทำงาน ขั้นตอน และการใช้เครื่องมือแบบไดนามิก

เกณฑ์ในการตัดสินใจว่าเมื่อใดควรใช้ agent

  • แอปพลิเคชัน LLM ควรเริ่มจาก วิธีแก้ปัญหาที่เรียบง่ายที่สุด เท่าที่เป็นไปได้ แล้วค่อยเพิ่มความซับซ้อนเมื่อจำเป็นเท่านั้น
  • ระบบแบบ agentic เป็นโครงสร้างที่แลก latency และต้นทุนกับประสิทธิภาพการทำงานที่ดีขึ้น ดังนั้นต้องตรวจสอบก่อนว่าการแลกนี้จำเป็นจริงหรือไม่
  • แม้ในกรณีที่ต้องการความซับซ้อน เกณฑ์การเลือกก็แตกต่างกัน
    • สำหรับงานที่กำหนดชัดเจน workflow ให้ความคาดเดาได้และความสม่ำเสมอ
    • สำหรับงานที่ต้องการความยืดหยุ่นสูงและการตัดสินใจที่ขับเคลื่อนโดยโมเดล agent จะเหมาะกว่า
  • แอปพลิเคชันจำนวนมากเพียงพอแล้วด้วยการ optimize การเรียก LLM ครั้งเดียวโดยใช้การค้นหาและตัวอย่างในบริบท

เกณฑ์การใช้เฟรมเวิร์ก

  • เครื่องมือสำหรับ implement ระบบแบบ agentic ที่ถูกแนะนำ ได้แก่ Claude Agent SDK, Strands Agents SDK by AWS, Rivet, Vellum
  • เฟรมเวิร์กเหล่านี้ทำให้งานมาตรฐานระดับต่ำ เช่น การเรียก LLM การนิยามและ parsing เครื่องมือ และการเชื่อมต่อการเรียกต่าง ๆ ง่ายขึ้น จึงช่วยให้เริ่มต้นได้เร็ว
  • อย่างไรก็ตาม ชั้น abstraction เพิ่มเติมอาจบดบัง prompt และ response จริง ทำให้ดีบักยากขึ้น
    • แม้ในสถานการณ์ที่โครงสร้างเรียบง่ายก็เพียงพอแล้ว ก็อาจชักนำให้เพิ่มความซับซ้อนที่ไม่จำเป็น
  • นักพัฒนาควรเริ่มจากการใช้ LLM API โดยตรงก่อนจะดีกว่า
    • หลายแพตเทิร์นสามารถ implement ได้ด้วยโค้ดเพียงไม่กี่บรรทัด
    • แม้ใช้เฟรมเวิร์ก ก็ควรเข้าใจการทำงานของโค้ดภายใน
    • สมมติฐานที่ผิดเกี่ยวกับการทำงานภายในเป็นสาเหตุที่พบบ่อยของข้อผิดพลาดจากลูกค้า
  • ดูตัวอย่างการ implement ได้ใน cookbook

building block พื้นฐาน: LLM ที่เสริมความสามารถแล้ว

  • building block พื้นฐานของระบบแบบ agentic คือ augmented LLM ที่เสริมด้วยความสามารถอย่างการค้นหา เครื่องมือ และหน่วยความจำ
  • โมเดลปัจจุบันสามารถใช้ความสามารถเหล่านี้ได้อย่าง主动โดยสร้าง query สำหรับค้นหาเอง เลือกเครื่องมือที่เหมาะสม และตัดสินใจว่าจะเก็บข้อมูลใดไว้
  • ตอน implement ควรโฟกัสสองเรื่อง
    • ปรับความสามารถให้เหมาะกับ use case
    • จัดเตรียม interface ที่มีเอกสารชัดเจนและใช้งานง่ายสำหรับ LLM
  • หนึ่งในวิธี implement ที่ถูกแนะนำคือ Model Context Protocol
    • นักพัฒนาสามารถผสานรวมกับ ecosystem ของเครื่องมือ third-party ผ่าน client implementation แบบง่าย ๆ ได้

แพตเทิร์น workflow

  • prompt chaining

    • prompt chaining คือวิธีแบ่งงานออกเป็นขั้นตอนต่อเนื่อง โดยการเรียก LLM แต่ละครั้งจะประมวลผล output ของการเรียกก่อนหน้า
    • สามารถใส่การตรวจสอบเชิงโปรแกรมในแต่ละขั้นตอนกลาง เพื่อยืนยันว่ากระบวนการยังอยู่บนเส้นทางที่ถูกต้อง
    • เหมาะเมื่อสามารถแยกงานออกเป็นงานย่อยที่คงที่ได้อย่างเป็นระเบียบ
    • trade-off สำคัญคือยอมรับ latency ที่เพิ่มขึ้น เพื่อเพิ่ม ความแม่นยำ โดยลดความยากของการเรียก LLM แต่ละครั้ง
    • ตัวอย่าง
      • สร้างข้อความการตลาดแล้วแปลเป็นภาษาอื่น
      • เขียน outline เอกสาร ตรวจสอบว่าตรงตามเกณฑ์หรือไม่ แล้วเขียนเอกสารจาก outline

  • routing

    • routing คือวิธีจำแนก input แล้วส่งต่อไปยังงานถัดไปที่เชี่ยวชาญเฉพาะด้าน
    • ช่วยแยก concern และสร้าง prompt ที่เฉพาะทางมากขึ้นได้
    • หากไม่มีโครงสร้างนี้ การ optimize สำหรับ input ประเภทหนึ่งอาจทำให้ประสิทธิภาพของ input อื่นลดลง
    • เหมาะเมื่อหมวดหมู่ต่าง ๆ เหมาะกับการประมวลผลแยกกัน และ LLM หรือโมเดล/อัลกอริทึมจำแนกแบบดั้งเดิมสามารถจำแนกได้อย่างแม่นยำ
    • ตัวอย่าง
      • ส่ง query ฝ่ายบริการลูกค้า เช่น คำถามทั่วไป คำขอคืนเงิน และการสนับสนุนทางเทคนิค ไปยังกระบวนการ prompt และเครื่องมือที่แตกต่างกัน
      • route คำถามที่ง่ายหรือทั่วไปไปยังโมเดลที่เล็กกว่าและคุ้มค่ากว่า เช่น Claude Haiku 4.5 และ route คำถามที่ยากหรือผิดปกติไปยังโมเดลที่ทรงพลังกว่า เช่น Claude Sonnet 4.5

  • parallelization

    • parallelization คือวิธีให้ LLM ประมวลผลงานหนึ่งพร้อมกัน และรวม output ด้วยโปรแกรม
    • มีสองรูปแบบหลัก
      • sectioning: แบ่งงานออกเป็นงานย่อยที่เป็นอิสระแล้วรันแบบขนาน
      • voting: รันงานเดียวกันหลายครั้งเพื่อให้ได้ output ที่หลากหลาย
    • มีประสิทธิภาพเมื่อสามารถแบ่งงานย่อยเพื่อเพิ่มความเร็วได้ หรือเมื่อต้องการหลายมุมมองหรือหลายความพยายามเพื่อให้มีความน่าเชื่อถือสูงขึ้น
    • ในงานที่ซับซ้อน หากให้แต่ละประเด็นพิจารณาถูกจัดการโดยการเรียก LLM แยกกัน ก็จะโฟกัสกับแต่ละด้านได้มากขึ้น
    • ตัวอย่าง
      • guardrail ที่ instance หนึ่งของโมเดลประมวลผล query ของผู้ใช้ และอีก instance ตรวจสอบเนื้อหาหรือคำขอที่ไม่เหมาะสม
      • ในการประเมินประสิทธิภาพ LLM การเรียกแต่ละครั้งประเมินคนละด้านของประสิทธิภาพโมเดล
      • prompt หลายชุดตรวจสอบช่องโหว่ของโค้ด และ flag หากพบปัญหา
      • ในการประเมินความไม่เหมาะสมของเนื้อหา ใช้ prompt หลายชุดและเกณฑ์ threshold จาก voting เพื่อปรับสมดุลระหว่าง false positive และ false negative

  • orchestrator-worker

    • orchestrator-worker คือวิธีที่ LLM ส่วนกลางแยกงานแบบไดนามิก มอบหมายให้ worker LLM แล้วสังเคราะห์ผลลัพธ์
    • เหมาะกับงานซับซ้อนที่ไม่สามารถคาดการณ์งานย่อยที่จำเป็นล่วงหน้าได้
    • แม้อาจดูคล้าย parallelization แต่ความแตกต่างหลักคือ ความยืดหยุ่น
      • parallelization มีงานย่อยที่กำหนดไว้ล่วงหน้า
      • orchestrator-worker ให้ orchestrator ตัดสินใจงานย่อยตาม input
    • ตัวอย่าง
      • ผลิตภัณฑ์เขียนโค้ดที่ต้องแก้ไขหลายไฟล์อย่างซับซ้อนในแต่ละครั้ง
      • งานค้นหาที่รวบรวมและวิเคราะห์ข้อมูลที่อาจเกี่ยวข้องจากหลายแหล่ง

  • evaluator-optimizer

    • evaluator-optimizer คือโครงสร้างแบบ loop ที่การเรียก LLM หนึ่งสร้างคำตอบ และอีกการเรียก LLM หนึ่งให้การประเมินและ feedback
    • มีประสิทธิภาพเป็นพิเศษเมื่อมีเกณฑ์ประเมินชัดเจน และการปรับปรุงซ้ำ ๆ ให้คุณค่าที่วัดได้
    • สัญญาณว่ามันเหมาะมีสองอย่าง
      • เมื่อมนุษย์ให้ feedback ได้ชัดเจน คำตอบของ LLM ดีขึ้นจริง
      • LLM สามารถให้ feedback แบบนั้นได้
    • คล้ายกระบวนการเขียนซ้ำ ๆ ที่นักเขียนมนุษย์ใช้เพื่อสร้างเอกสารที่ขัดเกลาแล้ว
    • ตัวอย่าง
      • การแปลวรรณกรรมที่ evaluator LLM วิจารณ์ nuance ที่ translation LLM อาจพลาดในครั้งแรก
      • งานค้นหาที่ซับซ้อนซึ่ง evaluator ตัดสินว่าจำเป็นต้องค้นหาเพิ่มเติมหรือไม่

autonomous agent

  • agent เริ่มถูกใช้ใน production เมื่อ LLM มีความสามารถในการเข้าใจ input ที่ซับซ้อน การให้เหตุผลและวางแผน การใช้เครื่องมืออย่างเสถียร และการกู้คืนจากข้อผิดพลาด
  • งานเริ่มจากคำสั่งหรือบทสนทนาของมนุษย์
    • เมื่อภารกิจชัดเจนแล้ว agent จะวางแผนและทำงานอย่างอิสระ
    • หากต้องการข้อมูลเพิ่มเติมหรือการตัดสินใจ agent อาจกลับมาถามมนุษย์ได้
  • ระหว่างการทำงาน สิ่งสำคัญคือการได้รับ สัญญาณยืนยันจริง จากสภาพแวดล้อมในแต่ละขั้นตอน
    • เช่น ผลลัพธ์จากการเรียกเครื่องมือ ผลลัพธ์จากการรันโค้ด
    • ใช้สิ่งเหล่านี้เพื่อประเมินความคืบหน้า
  • agent สามารถหยุดที่ checkpoint หรือเมื่อเจอสถานการณ์ติดขัด เพื่อรอ feedback จากมนุษย์ได้
  • งานมักจบเมื่อเสร็จสมบูรณ์ แต่เพื่อรักษาการควบคุม ก็มักกำหนด เงื่อนไขหยุด เช่น จำนวนรอบสูงสุด
  • ตัว implementation เองมักเรียบง่าย
    • agent โดยทั่วไปคือ LLM ที่ใช้เครื่องมือใน loop โดยอาศัย feedback จากสภาพแวดล้อม
    • ดังนั้นต้องออกแบบชุดเครื่องมือและเอกสารประกอบให้ชัดเจนและรอบคอบ
  • เงื่อนไขการใช้งาน
    • ปัญหาแบบปลายเปิดที่คาดการณ์จำนวนขั้นตอนที่จำเป็นได้ยากหรือเป็นไปไม่ได้
    • งานที่ไม่สามารถ hardcode เส้นทางคงที่ได้
    • สถานการณ์ที่ LLM สามารถทำงานได้หลาย turn และต้องมีความเชื่อถือในระดับหนึ่งต่อการตัดสินใจ
  • ข้อจำกัด
    • ความเป็นอิสระมาพร้อมต้นทุนที่สูงขึ้นและความเป็นไปได้ที่ข้อผิดพลาดจะสะสม
    • แนะนำให้ทดสอบอย่างกว้างขวางในสภาพแวดล้อม sandbox และมี guardrail ที่เหมาะสม
  • ตัวอย่าง

การผสมแพตเทิร์นและการปรับแต่ง

  • building block ที่นำเสนอไม่ใช่สูตรตายตัว แต่เป็น แพตเทิร์นทั่วไป ที่นักพัฒนาสามารถปรับและผสมผสานให้เหมาะกับ use case ได้
  • กุญแจสู่ความสำเร็จ เช่นเดียวกับความสามารถของ LLM โดยรวม คือการวัดประสิทธิภาพและปรับปรุง implementation แบบวนซ้ำ
  • ควรเพิ่มความซับซ้อนก็ต่อเมื่อผลลัพธ์ดีขึ้นจริงเท่านั้น

หลักการ implement

  • ความสำเร็จในโลก LLM ไม่ได้อยู่ที่การสร้างระบบที่ซับซ้อนที่สุด แต่อยู่ที่การสร้าง ระบบที่ถูกต้อง ตามความต้องการ
  • ลำดับที่แนะนำคือ
    • เริ่มจาก prompt ที่เรียบง่าย
    • optimize prompt ด้วยการประเมินที่ครอบคลุม
    • เพิ่มระบบแบบ agentic หลายขั้นตอนก็ต่อเมื่อวิธีที่เรียบง่ายยังไม่เพียงพอ
  • เมื่อ implement agent มีหลักการสำคัญสามข้อ
    • รักษา ความเรียบง่าย ของการออกแบบ
    • ให้ความสำคัญกับ ความโปร่งใส โดยแสดงขั้นตอนการวางแผนของ agent อย่างชัดเจน
    • ออกแบบ agent-computer interface หรือ ACI อย่างรอบคอบ ด้วยเอกสารเครื่องมือและการทดสอบอย่างละเอียด
  • เฟรมเวิร์กช่วยให้เริ่มต้นได้เร็ว แต่เมื่อย้ายไป production ก็อาจจำเป็นต้องลดชั้น abstraction และสร้างจากองค์ประกอบพื้นฐาน

พื้นที่การใช้งานจริง

  • การสนับสนุนลูกค้า

    • การสนับสนุนลูกค้าผสาน interface แชตบอตที่คุ้นเคยเข้ากับการขยายความสามารถผ่านการผสานเครื่องมือ
    • มีเหตุผลที่เข้ากับ agent แบบปลายเปิดได้อย่างเป็นธรรมชาติ
      • ปฏิสัมพันธ์ด้าน support เป็นไปตาม flow การสนทนา ขณะเดียวกันต้องเข้าถึงข้อมูลและการดำเนินการภายนอก
      • เครื่องมือสามารถผสานเพื่อดึงข้อมูลลูกค้า ประวัติคำสั่งซื้อ และเอกสาร knowledge base
      • งานอย่างการดำเนินการคืนเงินหรืออัปเดต ticket สามารถจัดการด้วยโปรแกรมได้
      • ความสำเร็จสามารถวัดได้ชัดเจนจากการแก้ปัญหาตามที่ผู้ใช้กำหนด
    • หลายบริษัทแสดงให้เห็นความเป็นไปได้ของแนวทางนี้ด้วยโมเดลราคาแบบคิดตามการใช้งานที่เรียกเก็บเฉพาะเคสที่แก้สำเร็จ

  • coding agent

    • ด้านการพัฒนาซอฟต์แวร์แสดงศักยภาพสูงเมื่อความสามารถของ LLM วิวัฒนาการจาก code completion ไปสู่การแก้ปัญหาอย่างอิสระ
    • เหตุผลที่ agent มีประสิทธิภาพ
      • วิธีแก้ปัญหาในโค้ดสามารถตรวจสอบได้ด้วย automated test
      • agent สามารถใช้ผลการทดสอบเป็น feedback เพื่อปรับปรุงวิธีแก้ปัญหาแบบวนซ้ำ
      • problem space ถูกกำหนดและมีโครงสร้างดี
      • คุณภาพของ output สามารถวัดได้อย่างเป็นวัตถุวิสัย
    • ใน implementation ของ Anthropic agent สามารถแก้ GitHub issue จริงใน benchmark SWE-bench Verified ได้จากคำอธิบาย pull request เพียงอย่างเดียว
    • แม้ automated test จะช่วยตรวจสอบฟังก์ชันได้ แต่การ review โดยมนุษย์ยังคงสำคัญเพื่อยืนยันว่าวิธีแก้ปัญหาสอดคล้องกับความต้องการของระบบที่กว้างขึ้น

prompt engineering สำหรับเครื่องมือ

  • ในระบบแบบ agentic ใด ๆ เครื่องมือมีแนวโน้มจะเป็นองค์ประกอบสำคัญ
  • Tools ทำให้ Claude โต้ตอบกับบริการภายนอกและ API ได้
    • ระบุโครงสร้างและ definition ที่แน่นอนใน API
    • เมื่อ Claude วางแผนเรียกเครื่องมือ response จาก API จะมี tool use block
  • definition และ specification ของเครื่องมือควรได้รับความใส่ใจด้าน prompt engineering เทียบเท่ากับ prompt ทั้งหมด

  • การเลือก format ของเครื่องมือ

    • งานเดียวกันสามารถกำหนดได้หลายวิธี
      • การแก้ไฟล์อาจเขียนเป็น diff หรือกำหนดให้เขียนไฟล์ทั้งหมดใหม่ก็ได้
      • structured output สามารถส่งกลับเป็นโค้ดใน Markdown หรือโค้ดใน JSON ได้
    • จากมุมมองวิศวกรรมซอฟต์แวร์ ความต่างของ format อาจแปลงไปมาได้โดยไม่สูญเสียข้อมูล แต่สำหรับ LLM บาง format เขียนยากกว่ามาก
      • การเขียน diff ต้องรู้ว่ามีกี่บรรทัดที่เปลี่ยนใน chunk header ก่อนเขียนโค้ดใหม่
      • การเขียนโค้ดใน JSON ต้อง escape ขึ้นบรรทัดใหม่และเครื่องหมายคำพูดเพิ่มเติม
    • เมื่อเลือก format ของเครื่องมือ ต้องไม่ให้โมเดลติดอยู่กับภาระของ format ที่ไม่จำเป็น
      • ให้ โทเคนสำหรับคิด เพียงพอก่อนเข้าสู่ format ทางตัน
      • รักษาให้ใกล้กับ format ที่โมเดลเคยเห็นตามธรรมชาติในข้อความบนอินเทอร์เน็ต
      • ตัด overhead ด้าน format เช่น การนับจำนวนบรรทัดที่แน่นอนของโค้ดหลายพันบรรทัด หรือการ escape สตริงโค้ด

  • การออกแบบ ACI

    • ควรลงทุนกับการออกแบบ agent-computer interface (ACI) เทียบเท่ากับความพยายามที่ใช้กับ human-computer interface (HCI)
    • definition ของเครื่องมือที่ดีมักมีตัวอย่างการใช้งาน edge case ข้อกำหนดรูปแบบ input และขอบเขตที่ชัดเจนเมื่อเทียบกับเครื่องมืออื่น
    • ชื่อ parameter และคำอธิบายควรปรับให้โมเดลเข้าใจได้ง่ายขึ้น
      • คล้ายกับการเขียน docstring ที่ยอดเยี่ยมสำหรับ junior developer ในทีม
      • สำคัญเป็นพิเศษเมื่อมีเครื่องมือที่คล้ายกันหลายตัว
    • ต้องทดสอบการใช้เครื่องมือของโมเดล
      • รัน input ตัวอย่างจำนวนมากใน workbench เพื่อตรวจหาความผิดพลาดของโมเดลและปรับปรุงแบบวนซ้ำ
      • แนะนำให้ออกแบบเครื่องมือด้วยแนวทาง Poka-yoke โดยปรับ argument ให้ทำผิดพลาดได้ยาก
    • ตอนสร้าง agent สำหรับ SWE-bench ใช้เวลากับการ optimize เครื่องมือมากกว่า prompt ทั้งหมด
      • เคยมีปัญหาที่ agent ทำผิดพลาดกับเครื่องมือที่ใช้ path ไฟล์แบบ relative หลังจากย้ายออกนอก root directory
      • เมื่อเปลี่ยนให้เครื่องมือต้องใช้ path ไฟล์แบบ absolute เสมอ โมเดลก็ใช้วิธีนี้ได้โดยไม่เกิดข้อผิดพลาด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-18
ความคิดเห็นบน Hacker News

  • ผมมองว่าบทความนี้ยังคงเป็นหนึ่งในบทความที่ดีในหัวข้อนี้ โดยเฉพาะชอบที่ช่วงต้นนิยามไว้อย่างชัดเจนว่าใช้คำว่า AI Agent ในความหมายใด
    ในที่นี้นิยามว่าเป็น “ระบบที่ LLM กำกับกระบวนการประมวลผลและการใช้เครื่องมือของตนเองแบบไดนามิก พร้อมทั้งยังคงควบคุมวิธีบรรลุงานไว้”
    อีกทั้งยังชอบวิธีที่แยกความต่างระหว่าง “Agent” กับ “workflow” และอธิบายรูปแบบ workflow ที่มีประโยชน์หลายแบบ
    ตอนที่บทความนี้ออกมาใหม่ ๆ ผมเคยจดโน้ตเกี่ยวกับบทความนี้ไว้: https://simonwillison.net/2024/Dec/20/building-effective-age...
    บทความที่ใหม่กว่าของ Anthropic คือ https://www.anthropic.com/engineering/built-multi-agent-rese... — “How we built our multi-agent research system” ซึ่งก็น่าสนใจมากเช่นกัน ผมจึงสรุปโน้ตไว้: https://simonwillison.net/2025/Jun/14/multi-agent-research-s...

    • หนึ่งในผู้เขียน Building Effective Agents เคยมาที่ AIE และบรรยายโดยอิงจากบทความนี้ด้วย ซึ่งได้รับเสียงตอบรับดี: https://www.youtube.com/watch?v=D7_ipDqhtwk
    • บทความเรื่อง ระบบวิจัยแบบ multi-agent ยอดเยี่ยมมาก แต่ผมไม่เห็นด้วยกับคำแนะนำในบทความ Building Effective AI Agents ที่บอกให้สร้างระบบช่วงแรกโดยไม่ใช้ framework
      ถ้าเพื่อการเรียนรู้ก็ดูดี แต่ข้อดีแรกของ framework ที่ดีคือช่วยให้ทดลอง LLM จากผู้ให้บริการต่าง ๆ ได้ง่าย
    • ผมมองว่า นิยามของ workflow ในบทความนี้ไม่แม่นยำ เอนจิน workflow สมัยใหม่ไม่ได้วิ่งตามเส้นทางโค้ดที่กำหนดไว้ล่วงหน้าเท่านั้น และในกรณีแบบนี้ก็แทบไม่ต่างจาก Agent
      ดูเหมือนเป็นความพยายามนิยาม workflow ใหม่เพื่อแยกความแตกต่าง แต่ Agent ส่วนใหญ่ก็เป็นแค่ workflow แบบวนซ้ำที่เรียกบางอย่างแบบไดนามิกตามคำตอบของ LLM เท่านั้น เอนจิน workflow สมัยใหม่มีความไดนามิกมาก
    • มีใครรู้ไหมว่า Anthropic ใช้ AI Agent framework ตัวไหน? ดูเหมือนยังไม่ได้เปิดเผย framework ของตัวเอง

  • ผมคิดว่าคำแนะนำที่ว่า “มันทำให้เริ่มต้นได้ง่ายขึ้นด้วยการทำให้งานระดับต่ำมาตรฐาน เช่น การเรียก LLM, การนิยามและ parse เครื่องมือ, การเชื่อมการเรียกต่าง ๆ ง่ายขึ้น แต่บ่อยครั้งก็มักสร้างชั้น abstraction เพิ่มเติมที่บดบัง prompt และ response พื้นฐาน ทำให้ debug ยากขึ้น และชวนให้เพิ่มความซับซ้อนแม้การประกอบแบบง่ายกว่าก็เพียงพอแล้ว แนะนำให้นักพัฒนาเริ่มจากการใช้ LLM API โดยตรง” เป็นส่วนที่ดีที่สุดของบทความทั้งชิ้นอย่างชัดเจน
    โดยแก่นแล้ว การใช้ framework ขนาดมหึมากับงานที่แทบจะเป็นการส่ง array ของ string ไปยัง web service นั้นไม่สมเหตุสมผล
    ในโปรเจกต์ของบริษัท เราก็ถอด LangChain และ LangGraph ออก เพราะจริง ๆ แล้วไม่ได้มีคุณค่า แค่เพิ่มความซับซ้อน ต้องคอยจัดการ boilerplate ของ framework จนกลับต้องเขียนโค้ดมากกว่าตอนไม่ใช้เสียอีก

    • langflow ก็น่าจะอยู่ในหมวดนี้ด้วย แต่ผมก็คิดว่ามันมีประโยชน์ชัดเจนสำหรับการจัดระเบียบ flow หลาย ๆ แบบให้อยู่ในรูปแบบร่วมกัน
      คุณอาจรันทุกขั้นตอนการสร้างภาพด้วย Stable Diffusion หรือเขียนโค้ด shader เองโดยตรงก็ได้ แต่ถ้ามี flow หรืองานมากกว่าหนึ่งอย่างและกำลังทดลองอยู่ การใช้ comfy-UI หรือ shader graph จะช่วยให้เป็นระเบียบกว่ามาก

  • ผ่านมาครึ่งปีแล้ว ซึ่งในวงการ AI ให้ความรู้สึกว่าเป็นเวลานานพอสมควร ผมอ่านบทความนี้ซ้ำ ๆ เมื่อไม่กี่เดือนก่อน แต่ตอนนี้ การพัฒนา Agent ดูเหมือนจะมาถึงคอขวดอย่างชัดเจนแล้ว
    แม้แต่ Gemini รุ่นล่าสุดก็ดูเหมือนถดถอย

    • ถ้ารัน Agent หลายตัว ต้นทุนจะแพงขึ้น ทำให้ ROI ต่ำลง Agent แบบ DeepSearch สำหรับหุ้นใช้ Agent 6 ตัว และมีค่าใช้จ่ายประมาณ 2 ดอลลาร์ต่อ query
      การ orchestrate แบบ multi-agent ควบคุมได้ยาก และยิ่งประสิทธิภาพของโมเดลดีขึ้น ความจำเป็นของ multi-agent ก็ยิ่งลดลง ในทางกลับกัน ยิ่งประสิทธิภาพโมเดลต่ำ AI ที่มีขอบเขตแคบก็ยิ่งสมเหตุสมผลทางธุรกิจมากกว่า
    • ถดถอยเพราะอะไรกันแน่? ผมสงสัยว่าทำไมถึง fork ตัวเองเป็นฝูง ทำงานขนานกันตลอด 24 ชั่วโมง ตรวจสอบผลลัพธ์ แล้วพัฒนาต่อไปเรื่อย ๆ ไม่ได้
    • กำลังเจอความยากในการแก้ปัญหา prompt injection และนั่นก็เป็นหนึ่งในคอขวด

  • มีตัวอย่างเอเจนต์ที่ใช้งานจริงในโปรดักชัน ช่วยประหยัดค่าใช้จ่ายของบริษัทและทำงานที่มีคุณค่าจริงไหม? หมายถึงกรณีที่ไม่ใช่แค่เขียนข้อความมาเติมพื้นที่ว่างบนถุงมันฝรั่งทอด

    • ChatIPT ดีมาก แก้ปัญหาจริงในข้อมูลความหลากหลายทางชีวภาพ แม้จะไม่ได้ใช้คำว่า “เชิงเอเจนต์” แต่ก็ชัดเจนว่าเขียนและรันโค้ด Python
      https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
      ตอนนี้ยังเป็นเบต้า
      ตามข่าวประชาสัมพันธ์ แชตบอตของ Rukaya Johaadien ให้ความช่วยเหลือแบบสนทนาแก่ นักศึกษา·นักวิจัยที่มีข้อมูลความหลากหลายทางชีวภาพ แต่เพิ่งเริ่มหรือไม่ค่อยได้เผยแพร่ข้อมูล ช่วยจัดระเบียบและทำให้สเปรดชีตเป็นมาตรฐาน สร้างเมทาดาทาพื้นฐาน และแนะนำให้เผยแพร่ชุดข้อมูลที่มีโครงสร้างดีเป็น Darwin Core Archive บน GBIF.org
      จนถึงตอนนี้ การเผยแพร่ข้อมูลคุณภาพสูงจากงานวิจัยระดับปริญญาเอก·โท หรือการศึกษาความหลากหลายทางชีวภาพขนาดเล็กในวงกว้างเป็นเรื่องยาก เพราะการทำข้อมูลให้เป็นมาตรฐานมักต้องมีความรู้ด้านภาษาโปรแกรม เทคนิคการจัดการข้อมูล และซอฟต์แวร์เฉพาะทาง
      กระบวนการเข้าถึง Integrated Publishing Toolkit(IPT) ซึ่งเป็นแอปหลักสำหรับการแบ่งปันข้อมูลของเครือข่าย GBIF ก็ยากสำหรับมือใหม่เช่นกัน เวลาของผู้ดูแลโหนดและทรัพยากรมีจำกัด และผู้ใช้ที่ใช้นาน ๆ ครั้งมักลืมขั้นตอนและรายละเอียดที่ถูกต้องในแต่ละปี จึงบอกว่าการอบรมอย่างเดียวไม่พอจะข้ามอุปสรรคด้านโลจิสติกส์และภาษาได้
      เขาอธิบายว่า “การทำข้อมูลให้เป็นมาตรฐานเป็นเรื่องยาก และนักชีววิทยาไม่ได้มาเป็นนักชีววิทยาเพราะชอบโค้ดหรือ Excel ดังนั้นข้อมูลที่อาจมีคุณค่าจำนวนมากจึงถูกทิ้งไป เมื่อเห็นว่าโมเดลภาษาขนาดใหญ่เก่งมากขึ้นในการสร้างโค้ดและทำงานกับข้อมูล จึงสร้างเครื่องมือที่ช่วยแนะนำผู้ใช้ที่ไม่ใช่สายเทคนิคด้วยคำถามในชีวิตประจำวัน จัดการข้อมูลยุ่ง ๆ ให้ได้มากที่สุด แล้วเผยแพร่ไปยัง GBIF ได้อย่างรวดเร็วและอัตโนมัติ”
    • ที่ louie.ai ใช้ เอเจนต์และการให้เหตุผลเชิงเอเจนต์ เพื่อทำงานสืบค้นที่ผู้ใช้ทำทุกวันให้เป็นอัตโนมัติ
      สำหรับทุกการแจ้งเตือนหรือทิกเก็ตที่เข้ามา เอเจนต์จะทำการสืบค้นล่วงหน้ากับ API, ฐานข้อมูล ฯลฯ ที่เกี่ยวข้อง เพื่อระบุ false positive และให้บริบทเพิ่มเติมกับปัญหาจริง ช่วยลดเวลาของคนและเพิ่มความเร็วในการจัดการ
      ยังใช้การให้เหตุผลเชิงเอเจนต์แบบเดียวกันกับงานสำรวจด้วย โดยไปไกลกว่า text-to-SQL ธรรมดา ให้ LLM ใช้เวลา 2~10 นาทีตรวจสอบ Splunk, Databricks ฯลฯ แทน
      ภายในมีเครื่องมืออย่าง semantic layer เหนือฐานข้อมูล และตัววิเคราะห์ล็อก·ข้อความ·ดาต้าเฟรมขนาดใหญ่

  • เคยลองใช้ n8n workflow ที่สร้างเองด้วยโครงสร้างแทบเหมือนในบทความนี้ การจะได้คำตอบสำหรับคำถามง่าย ๆ ใช้เงิน 3 ดอลลาร์และอย่างน้อย 3 นาที
    ช่วงนี้คงใช้การค้นหาทั่วไปต่อไปก่อน

  • บทความนี้ช่วยเตือนสติได้ดีว่าให้เริ่มจากสิ่งที่ง่ายที่สุดที่ใช้งานได้จริง แล้วค่อยเพิ่มความซับซ้อนเฉพาะเมื่อจำเป็นจริง ๆ
    แค่มีการเรียก LLM ที่นิยามชัดเจนไม่กี่ครั้งกับ logic เชื่อมเบา ๆ ก็มักได้ระบบที่เสถียรกว่า ดีบักง่ายกว่า และค่าใช้จ่ายในการรันถูกกว่ามาก เอเจนต์ที่หวือหวาและฟีเจอร์เยอะมักสร้างปัญหามากกว่าปัญหาที่มันแก้ได้

  • ในฐานะคนที่ทำงานในบริษัทที่มีเอเจนต์จริงในโปรดักชัน ไม่ใช่เวิร์กโฟลว์ ผมไม่เห็นด้วยเลยกับประโยคแรกตรงนี้ที่ว่า “ให้ใช้เฟรมเวิร์กเอเจนต์อย่าง LangGraph”
    เราก็ทำแบบนั้นเป๊ะ แล้วต้องทิ้งทั้งหมดภายในหนึ่งเดือน จากนั้นสร้างใหม่ตั้งแต่ต้น และตอนนี้ได้ระบบที่สเกลได้ค่อนข้างดี
    หากพูดอย่างเป็นธรรม อาจมีพื้นที่ให้ใช้เฟรมเวิร์กเอเจนต์อยู่บ้าง แต่สายเอเจนต์ยังอยู่ในช่วงต้นเกินกว่าจะมีเฟรมเวิร์กที่ดีพอ
    ผมก็มีความคิดในทางตรงข้ามอยู่บ้าง คือคิดว่าวงการเอเจนต์เคลื่อนไหวเร็วเกินไป จนอาจ ไม่มีเฟรมเวิร์กที่ดีพอออกมาเลยก็ได้

    • ฟังดูเหมือนคุณเห็นด้วยกับบทความมากกว่า ในต้นฉบับก็บอกว่า หลังจากทำงานกับทีม LLM agent ในหลายอุตสาหกรรมตลอดปีที่ผ่านมา การใช้งานที่ประสบความสำเร็จที่สุดไม่ได้สร้างด้วยเฟรมเวิร์กซับซ้อนหรือไลบรารีเฉพาะทาง แต่สร้างด้วย แพตเทิร์นที่เรียบง่ายและประกอบกันได้
      เฟรมเวิร์กช่วยให้เริ่มต้นง่าย แต่ชั้น abstraction เพิ่มเติมอาจบดบังพรอมป์และคำตอบ ทำให้ดีบักยาก และอาจเพิ่มความซับซ้อนแม้ในตอนที่โครงสร้างที่ง่ายกว่าก็เพียงพอแล้ว ดังนั้นจึงแนะนำว่าแพตเทิร์นจำนวนมากทำได้ด้วยโค้ดไม่กี่บรรทัด ให้เริ่มจากการใช้ LLM API โดยตรงก่อน
    • ตอนนี้กำลังย้ายจากโปรโตไทป์ที่ทำด้วยเครื่องมือเอเจนต์ของ N8N ไปเป็นระบบจริงที่โฮสต์เองได้
      เห็นคอมเมนต์เยอะว่าทีมที่เน้นใช้งานจริงส่วนใหญ่ทิ้งของอย่าง LangChain, LangGraph, Haystack, Crew แล้วไปใช้โค้ดภายในที่เรียบง่ายกว่า แต่ยังไม่ค่อยจับภาพได้ว่าในความเป็นจริงส่วนอย่างการเรียกใช้เครื่องมือถูก implement กันอย่างไร
      ถ้ามีลิงก์หรือเอกสารที่ใช้เป็นฐานในการทำงาน ช่วยแชร์ได้ไหม
    • เอเจนต์นั้นทำงานอะไร?

  • เป็นบทความเดือนธันวาคม 2024 แต่แปลกที่รู้สึกเหมือนนานมากแล้ว

    • ถึงอย่างนั้น ส่วนตัวคิดว่ามันยังยืนระยะได้ดีมากจนถึงตอนนี้ ผมยังใช้บทความนี้เป็นเอกสารอ้างอิงอยู่เรื่อย ๆ และไม่ได้รู้สึกว่าล้าสมัย
      เป็นบทความที่ทำให้มอง Anthropic ใหม่ว่าเป็น “พาร์ตเนอร์สายปฏิบัติจริง” ในการพัฒนาเครื่องมือ AI
    • “ไม่เอาน่า ต้องกลับมาใช้สมองอีกแล้ว แถมต้องเขียนโค้ดเอง 100% เหมือนมนุษย์ถ้ำเดือนธันวาคม 2024 อีกเหรอ”
      https://news.ycombinator.com/item?id=44260988

  • ตอนนี้ดูเหมือน กระแส hype เรื่องเอเจนต์ จะซาลงไปบ้างแล้ว

  • คำว่า “ใช้ แพตเทิร์นที่เรียบง่ายและประกอบกันได้” ฟังแล้วสบายใจอย่างประหลาด
    ชอบที่สุภาษิต “ทำสิ่งเดียวให้ดี” ยังใช้ได้อยู่แม้ผ่านมาหลายสิบปี ความสามารถในการประกอบกันได้ดีที่สุด