- แม้จะมีความคาดหวังว่า กระแส AI Agent จะมาแรงอย่างมากในปี 2025 แต่ในสภาพแวดล้อมโปรดักชันจริงยังมีข้อจำกัดที่เป็นรูปธรรมอยู่
- ด้วยปัญหา การสะสมของข้อผิดพลาด และ ต้นทุนโทเค็น ทำให้การทำเวิร์กโฟลว์หลายขั้นตอนให้เป็นอัตโนมัติทั้งหมดนั้นยังเป็นไปไม่ได้ในตอนนี้
- ระบบเอเจนต์ที่ประสบความสำเร็จส่วนใหญ่จำเป็นต้องอยู่ใน โดเมนที่ถูกจำกัดอย่างเข้มงวด และต้องมี การอนุมัติจากมนุษย์ หรือกระบวนการตรวจสอบยืนยัน
- ความยากที่แท้จริงไม่ได้อยู่ที่ประสิทธิภาพของ AI เอง แต่อยู่ที่ การออกแบบเครื่องมือและระบบฟีดแบ็ก ที่เอเจนต์สามารถใช้งานได้ดี
- คาดว่าในปี 2025 สตาร์ตอัป/บริษัทที่ชู เอเจนต์อัตโนมัติเต็มรูปแบบ เป็นจุดขายหลัก จะต้องเผชิญอุปสรรคใหญ่ในการนำไปใช้จริงและการขยายระบบ
ทำไมผมจึงเดิมพันว่า AI Agent จะยังไม่มาถึงในปี 2025 (ทั้งที่ผมเองก็กำลังพัฒนา AI Agent อยู่)
- มีกระแสเกินจริงอย่างแพร่หลายว่าปี 2025 จะเป็น ปีแห่ง AI Agent
- ผู้เขียนได้ลงมือสร้าง ระบบ AI Agent หลากหลายรูปแบบ ที่ทำงานในสภาพแวดล้อมโปรดักชันจริงมาตลอด 1 ปีที่ผ่านมา
- จากประสบการณ์ทำงานจริงโดยตรง ผู้เขียนจึงมีมุมมองเชิงสงสัยต่อสิ่งที่ตลาดเรียกว่า "การปฏิวัติของเอเจนต์"
ประสบการณ์ในการสร้างระบบเอเจนต์หลากหลายแบบ
- Development Agent: สร้าง React component จากภาษาธรรมชาติ, รีแฟกเตอร์โค้ดเลกาซี, จัดการเอกสาร API อัตโนมัติ, สร้างฟังก์ชันจากสเปก เป็นต้น
- Data & Infrastructure Agent: จัดการคิวรีและการย้ายระบบที่ซับซ้อน, ทำ DevOps อัตโนมัติบนมัลติคลาวด์
- Quality & Process Agent: แก้ lint อัตโนมัติ, สร้างโค้ดทดสอบ, ทำ code review และ Pull Request แบบละเอียดโดยอัตโนมัติ
- แม้ระบบเหล่านี้จะสร้างคุณค่าและช่วยประหยัดเวลาได้จริง แต่ประสบการณ์นี้เองคือพื้นฐานของมุมมองวิพากษ์ต่อกระแสเกินจริง
สรุปแก่นสำคัญ: ความจริงอันเย็นชาสามข้อของ AI Agent
- อัตราความผิดพลาดสะสม: ยิ่งมีหลายขั้นตอน อัตราความสำเร็จจะ ลดลงแบบเอ็กซ์โพเนนเชียล ทำให้ยากจะผ่านเกณฑ์ระดับโปรดักชัน (99.9% ขึ้นไป)
- Context window และต้นทุน: ยิ่งบทสนทนายาวขึ้น ต้นทุนโทเค็นจะเพิ่มขึ้นแบบยกกำลัง จนความคุ้มค่าทางเศรษฐกิจพังลง
- ความยากของการออกแบบเครื่องมือและฟีดแบ็ก: สิ่งที่ท้าทายที่สุดไม่ใช่ข้อจำกัดทางเทคนิค แต่คือ การออกแบบเครื่องมือและระบบฟีดแบ็ก ที่เอเจนต์สามารถนำไปใช้ได้
ความจริงเชิงคณิตศาสตร์ของการสะสมข้อผิดพลาด
- เวิร์กโฟลว์อัตโนมัติหลายขั้นตอน ไม่อาจเกิดขึ้นได้จริงในระดับปฏิบัติการ เพราะ ข้อผิดพลาดสะสม
- ตัวอย่างเช่น แม้แต่ละขั้นจะมีความน่าเชื่อถือ 95% แต่ถ้ามี 20 ขั้นตอน อัตราความสำเร็จสุดท้ายจะเหลือเพียง 36% (ขณะที่โปรดักชันต้องการ 99.9% ขึ้นไป)
- ต่อให้สมมติว่ามีความน่าเชื่อถือสูงมาก เมื่อจำนวนขั้นตอนเพิ่มขึ้น ความน่าจะเป็นของความล้มเหลวก็จะพุ่งสูงขึ้นมาก
- ในงานจริงจึงไม่ได้ออกแบบให้ทุกกระบวนการเป็นอัตโนมัติเต็มรูปแบบ แต่จะออกแบบให้แต่ละขั้นมี จุดตรวจสอบและย้อนกลับได้อย่างอิสระ พร้อม การยืนยันจากมนุษย์
- แพตเทิร์นของระบบเอเจนต์ที่ประสบความสำเร็จ: บริบทที่ถูกจำกัดอย่างชัดเจน, งานที่ตรวจสอบได้, และให้มนุษย์มีส่วนตัดสินใจในจุดสำคัญ
โครงสร้างต้นทุนโทเค็นและข้อจำกัดทางเศรษฐกิจ
- ต้นทุนโทเค็นสำหรับการรักษา context window และประวัติการสนทนา กลายเป็น ความจริงที่ไม่คุ้มค่าเชิงเศรษฐกิจ เมื่อระบบขยายตัว
- เอเจนต์แบบสนทนาต้อง ประมวลผลประวัติการสนทนาทั้งหมดทุกครั้ง ทำให้ต้นทุนพุ่งขึ้นแบบกำลังสองเมื่อจำนวนรอบเพิ่มขึ้น
- การสนทนา 100 รอบอาจมีค่าโทเค็นสูงถึง 50~100 ดอลลาร์ และเมื่อใช้กับผู้ใช้จำนวนมาก ความคุ้มค่าจะพังทลาย
- ในทางกลับกัน เอเจนต์แบบ Stateless ที่เป็น single-slot และสร้างฟังก์ชันโดยไม่ต้องพึ่งบริบท จะได้เปรียบกว่าในด้านต้นทุนและการสเกล
- เอเจนต์โปรดักชันที่ประสบความสำเร็จที่สุด ในความเป็นจริงมักใกล้เคียงกับ "เครื่องมืออัจฉริยะที่มีเป้าหมายชัดเจน" มากกว่า "เอเจนต์แบบสนทนา"
กำแพงของการออกแบบเครื่องมือและระบบฟีดแบ็ก
- อุปสรรคที่แท้จริงของการพัฒนา เอเจนต์ที่ให้ผลิตภาพสูง คือ ความสามารถในการออกแบบเครื่องมือ ซึ่งหลายทีมประเมินต่ำเกินไป
- แม้ความแม่นยำของการเรียกใช้เครื่องมือจะดีขึ้นมากแล้ว แต่หัวใจสำคัญคือการออกแบบให้สามารถ สรุปสถานะและผลลัพธ์ที่ซับซ้อนแล้วส่งกลับเป็นฟีดแบ็กให้เอเจนต์ได้อย่างมีประสิทธิภาพ
- ตัวอย่าง:
- เมื่อมีงานที่สำเร็จเพียงบางส่วน ต้องตัดสินใจว่าควรให้ข้อมูลมากแค่ไหนและสรุปในรูปแบบใด
- เช่น ถ้าผลลัพธ์ของคิวรีมี 10,000 รายการ ก็จำเป็นต้องออกแบบการย่อเชิงนามธรรมเพื่อให้มองเห็นสถานะ เช่น "สำเร็จ, 10,000 รายการ, แสดงเฉพาะ 5 รายการแรก"
- เมื่อเครื่องมือล้มเหลว ต้องควบคุม ปริมาณข้อมูลเพื่อการกู้คืน และป้องกันไม่ให้บริบทปนเปื้อน
- หัวใจของ database agent ที่ประสบความสำเร็จจริง คือ การให้ structured feedback ที่เอเจนต์สามารถใช้ตัดสินใจได้จริง
- ในโลกจริง AI ทำงานอยู่ราว 30% ส่วน อีก 70% ที่เหลือคือทักษะวิศวกรรมแบบดั้งเดิม เช่น ฟีดแบ็กของเครื่องมือ การกู้คืน และการจัดการบริบท
ข้อจำกัดของการบูรณาการเข้ากับระบบจริง
- ต่อให้แก้ปัญหาเรื่องความน่าเชื่อถือและต้นทุนได้แล้ว ปัญหาการเชื่อมเข้ากับโลกจริง ก็ยังเป็นกำแพงอีกชั้นหนึ่ง
- ระบบขององค์กรในโลกจริงไม่ได้มี API ที่สม่ำเสมอ แต่แฝงด้วย ความซับซ้อนที่คาดเดาไม่ได้ เช่น ลักษณะของระบบเลกาซี, ข้อผิดพลาดเฉพาะกรณี, การยืนยันตัวตนที่เปลี่ยนไป, ข้อจำกัดที่แปรผัน, และข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ
- ตัวอย่างของ database agent ในโลกจริงยังต้องอาศัยการเขียนโปรแกรมแบบดั้งเดิมอย่างมาก เช่น การจัดการ connection pool, transaction rollback, การเคารพ read-only replica, query timeout, และ logging
- คำสัญญาที่ว่า "AI จะบูรณาการทุกสแตกได้อย่างอัตโนมัติเต็มรูปแบบ" มักชนเข้ากับกำแพงของความเป็นจริงเมื่อถึงเวลาสร้างระบบจริง
แพตเทิร์นของวิธีที่ใช้งานได้ผลจริง
- หลักร่วมกัน ของระบบเอเจนต์ที่ประสบความสำเร็จ
- UI generation agent: มนุษย์เป็นผู้ตรวจทานประสบการณ์ผู้ใช้ขั้นสุดท้าย (AI รับหน้าที่เฉพาะความซับซ้อนของการแปลงภาษาธรรมชาติ → React)
- Database agent: งานที่มีความเสี่ยงทำลายข้อมูลต้องให้มนุษย์ยืนยันเสมอ (AI ทำเพียงการแปลงเป็น SQL ส่วนการควบคุมการรักษาข้อมูลเป็นหน้าที่ของมนุษย์)
- Function generation agent: ทำงานภายในสเปกที่ชัดเจนและจำกัด (ไม่มี state, side effect หรือ integration ที่ซับซ้อน)
- DevOps automation: AI สร้าง infrastructure code ส่วนการ deploy, version control และ recovery ใช้ pipeline เดิม
- CI/CD agent: แต่ละขั้นถูกออกแบบให้มีเกณฑ์ความสำเร็จชัดเจนและมีกลไก rollback
- สรุปแพตเทิร์น: AI รับมือความซับซ้อน มนุษย์ยังคงถืออำนาจควบคุม และความน่าเชื่อถือได้มาจากวิศวกรรมแบบดั้งเดิม
มุมมองต่อทิศทางตลาดและการคาดการณ์
- เวนเจอร์สตาร์ตอัปที่ชู เอเจนต์อัตโนมัติเต็มรูปแบบ จะเจอ ปัญหาความสามารถในการทำกำไร ก่อนใคร
- เวิร์กโฟลว์ 5 ขั้นอาจทำเดโมได้ยอดเยี่ยม แต่บริษัทจริงต้องการมากกว่า 20 ขั้น และจะ ชนกับข้อจำกัดทางคณิตศาสตร์
- บริษัทที่เพียงแค่ เพิ่ม AI Agent เข้าไปในซอฟต์แวร์เดิม แบบตรงไปตรงมา มีโอกาสสูงที่จะ การยอมรับหยุดชะงัก เพราะการบูรณาการยังไม่สมบูรณ์
- ผู้ชนะตัวจริง คือทีมที่จำกัดโดเมนอย่างชัดเจน ใช้ AI กับงานที่ยากจริง ๆ และให้มนุษย์กับเงื่อนไขขอบเขตเข้ามาควบคุมการตัดสินใจสำคัญ
- ตลาดมีแนวโน้มจะเรียนรู้ความแตกต่างระหว่าง "AI ที่ทำเดโมได้ดี" กับ "AI ที่เชื่อถือได้จริง" ผ่าน ประสบการณ์ที่มีราคาแพง
หลักการในการสร้างระบบเอเจนต์ที่พึงประสงค์
- กำหนดขอบเขตให้ชัดเจน: นิยามบทบาทของเอเจนต์และช่วง handoff กับมนุษย์/ระบบเดิมให้ชัด
- ออกแบบโดยเผื่อความล้มเหลว: ต้องมีโครงสร้าง rollback และ recovery เมื่อ AI ทำผิดพลาด
- ตรวจสอบความคุ้มค่าทางเศรษฐกิจ: ออกแบบโครงสร้างโดยคำนึงถึงต้นทุนต่อ interaction และการขยายขนาด (แบบไม่เก็บ state คุ้มค่ากว่าแบบเก็บ state)
- ให้ความน่าเชื่อถือมาก่อนความอัตโนมัติ: ระบบที่ทำงานสม่ำเสมอย่อมสร้างความเชื่อมั่นได้มากกว่าระบบที่บางครั้งดูเหมือนเวทมนตร์
- สร้างบนฐานที่แข็งแรง: มอบเฉพาะส่วนที่ยาก (เช่น การตีความเจตนา, การสร้าง) ให้ AI ส่วนที่เหลือ (เช่น การรัน, การจัดการข้อผิดพลาด) ให้ซอฟต์แวร์แบบดั้งเดิมรับผิดชอบ
บทเรียนแท้จริงจากประสบการณ์ภาคสนาม
- ช่องว่างระหว่าง "ทำงานได้ในเดโม" กับ "ปฏิบัติการจริงในระดับใหญ่" นั้นใหญ่มาก
- ความน่าเชื่อถือของเอเจนต์, การปรับต้นทุนให้เหมาะสม, ความซับซ้อนของการบูรณาการ ฯลฯ ยังเป็น ปัญหาหลักที่ทั้งอุตสาหกรรมยังแก้ไม่ตก
- ประสบการณ์จริงจากการลงมือสร้างและการแบ่งปันอย่างซื่อสัตย์คือ หัวใจของการพัฒนาอุตสาหกรรม
- ยิ่งมีผู้มีประสบการณ์ภาคสนามมาพูดคุยถึงวิธีการที่สมเหตุสมผลและกรณีล้มเหลวที่เกิดขึ้นจริงมากขึ้นเท่าไร โอกาสความสำเร็จโดยรวมก็จะยิ่งเพิ่มขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เคยมีประสบการณ์ได้คุยกับวิศวกร AI ฝั่งโปรดักชันของ Amazon และเขาบอกว่าตอนนี้ไม่มีบริษัทไหนเลยที่ใช้ generative AI เพียงอย่างเดียวในจุดที่ต้องคุยกับลูกค้าโดยตรง ระบบตอบกลับอัตโนมัติทั้งหมดใช้เทคโนโลยีแบบ "เก่า" ที่ไม่ใช่ generative AI เพราะปัญหาเรื่องความน่าเชื่อถือของ generative AI ยังใหญ่เกินกว่าจะเอาชื่อเสียงขององค์กรไปเสี่ยง
เมื่อก่อนสนใจเอเจนต์ที่ผสานเทคนิค symbolic แบบ "AI ยุคเก่า" เข้ากับ machine learning แบบดั้งเดิมมาก แต่ส่วนใหญ่ได้ทำงานกับ neural network ยุคก่อนทรานส์ฟอร์เมอร์ สุดท้ายแล้วก็มักเริ่มจากสร้างระบบที่มีมนุษย์เข้ามาแทรกก่อน แล้วเก็บข้อมูลสำหรับการประเมินและการฝึก จากนั้นค่อยให้ระบบรับช่วงงานบางส่วนและช่วยยกระดับคุณภาพของส่วนที่เหลือ โดยเฉพาะงานที่มีความ 'อัตวิสัย' จำเป็นต้องประเมินแม้แต่ระบบ symbolic ด้วย ถ้าต้องฝึกระบบ ก็หลีกเลี่ยงการประเมินไม่ได้อยู่ดี
จริง ๆ แล้วหลายบริษัทเทคก็นำ generative AI ไปใช้กับแชตบอตบริการลูกค้าแบบเรียลไทม์แล้ว รู้จักที่อย่าง Sonder และ Wealthsimple ถ้า LLM ตอบคำถามไม่ได้ก็จะส่งบทสนทนาไปให้เจ้าหน้าที่มนุษย์ทันที
อีกประเด็นที่ยังไม่ได้คุยกันคือ context window มนุษย์ในสายงานที่เชี่ยวชาญสามารถจัดการบริบทได้แทบจะ "เกือบไร้ขีดจำกัด" โมเดลอาจบรรเทาข้อจำกัดนี้ได้บ้างด้วยข้อมูลฝึกที่ใหญ่และหลากหลายขึ้น แต่ผมไม่คิดว่านั่นคือคำตอบจริง ๆ ตอนนี้คนยังต้องย่อบริบทของตัวเองใส่ลงในพรอมป์ต และในภาษาที่ยืดหยุ่นอย่างภาษาอังกฤษ มันให้ความรู้สึกเหมือนท่องคาถาหรือเดาสุ่มมากกว่าวิศวกรรม แทนที่จะเป็นวิธีแบบกำหนดแน่นอน ผมรู้สึกว่าเรากำลังทำข้อมูลหายไปเป็นจำนวนมาก
มนุษย์ไม่ได้แยก "บริบท" กับ "น้ำหนัก" ออกจากกันแบบตายตัว ประสบการณ์และผลลัพธ์ตามกาลเวลาจะเปลี่ยน "น้ำหนัก" ของผมเองตลอดเวลา แต่ LLM ทำแบบนั้นไม่ได้เพราะในเชิงสถาปัตยกรรม น้ำหนักเป็นแบบอ่านได้อย่างเดียว
ยังสงสัยอยู่ว่ามนุษย์มี context window ใหญ่มหาศาลแบบนั้นจริงหรือ ผมเองชนกับข้อจำกัดของ "context window" แบบมนุษย์บ่อยมากเวลาพยายามแก้ปัญหาซับซ้อน เลยสงสัยว่ามีตัวอย่างจริงของเรื่องนี้ไหม
โดยรวมแล้วประสบการณ์ใช้เครื่องมือ AI ของผมค่อนข้างเป็นบวก มันช่วยรับงานชิ้นเล็ก ๆ ตอนที่ควรพัก หรือช่วยจัดระเบียบและเริ่มต้นงานได้มาก แต่เรื่องค่าใช้จ่ายก็โผล่มาเร็ว เช่น ใช้ Claude Code กับโค้ดเบสขนาดใหญ่จะเสียราว $25 ใน 1-2 ชั่วโมง ถ้ามีพวกการแก้ไขแบบอัตโนมัติเพิ่มด้วยก็ขึ้นไปถึง $50/hr มี trade-off ระหว่างความเร็ว ความแม่นยำ และต้นทุน เอเจนต์รุ่นใหม่ ๆ ตอนนี้ก็ยังไม่ชัดว่าตกอยู่ตรงไหนในสามเหลี่ยมนั้น เลยคิดว่าการทดลองต่าง ๆ น่าสนใจ แต่ก็ยังเสี่ยงอยู่
ถ้ามองแบบประชดหน่อย โครงสร้างที่ LLM คอย re-prompt ตัวเองไม่หยุดเพื่อแก้ข้อผิดพลาด และแนวทาง "ไม่ต้องใช้ RAG! แค่โยนโค้ดทั้งหมดใส่ context window 1m token ไปเลย" มันเข้ากับกรอบธุรกิจแบบ 'คิดเงินตามโทเค็น' ได้พอดีมาก
ไอเดียที่กำลังคิดอยู่ตอนนี้คือให้ AI สร้างร่าง commit หลายแบบตั้งแต่ต้น แล้วให้มนุษย์หรือระบบอัตโนมัติมากรองผลลัพธ์และเกลาภายหลัง ยิ่งงานใหญ่ ความเบี่ยงเบนเล็ก ๆ ตอนต้นก็ยิ่งมีโอกาสทำให้ผลลัพธ์รวมพังได้ ดังนั้นแม้แต่กับ SOTA ปัจจุบัน ถ้าให้เอเจนต์ลองหลายแนวทางแบบขนาน ก็จะช่วยลดเวลาที่ต้องมานั่ง refactor เองได้ ผมเคยเขียนเรื่องขั้นตอนที่เกี่ยวข้องไว้บน GitHub
อยากถามว่าเป็นบริการแบบ subscription ไหม
เวิร์กโฟลว์หลายขั้นของมนุษย์มักมีจุดตรวจสอบความถูกต้อง เพราะมนุษย์เองก็ไม่ได้แม่นเกิน 99% เสมอไป ในอนาคตเอเจนต์ก็น่าจะถูกออกแบบให้มีกระบวนการตรวจสอบผลลัพธ์และต้องผ่านก่อนจะไปขั้นต่อไป อาจมีการประเมินความเสี่ยงล่วงหน้าด้วยว่า "ตรงนี้ต้องแม่นเกิน 99%" เป็นต้น
Claude Code จะหยุดถามผู้ใช้ทุกครั้งก่อนเดินหน้าทำงาน และยังแสดงการเปลี่ยนแปลงที่เสนอไว้ล่วงหน้าด้วย ซึ่งช่วยลดการสิ้นเปลืองโทเค็นและป้องกันงานที่ไม่มีประสิทธิภาพได้
แอปพลิเคชันหลายตัวก็น่าจะต้องออกแบบใหม่ให้เข้ากับโครงสร้างแบบนี้ด้วย ผมคิดว่าสถาปัตยกรรม microservices เข้ากับ LLM ได้ดี และอาจกลับมาฮิตอีกครั้ง
เห็นด้วยกับประโยคที่ว่า "ปัญหาที่แท้จริงไม่ใช่ความสามารถของ AI แต่คือการออกแบบเครื่องมือและระบบฟีดแบ็กที่เอเจนต์จะใช้ได้อย่างมีประสิทธิภาพจริง" ตอนแรกผมได้แต่เฝ้ามองอยู่เพราะไม่แน่ใจว่าตลาดจะตอบรับยังไง ก่อนจะไปเข้าร่วมสตาร์ตอัปเล็กมากที่โฟกัสการสร้างเอเจนต์โดยเฉพาะ ผ่านไป 5 เดือนมุมมองผมเปลี่ยนจากสงสัย → คล้อยตาม → มั่นใจ พอจำกัดขอบเขตหัวข้อให้แคบมาก ๆ และโฟกัสเรื่อง tooling ให้โมเดลทำงานได้ ก็เห็นอัตราการทำงานสำเร็จที่สูง แม้หลายคนจะไม่ชอบความไม่กำหนดแน่นอนของมัน แต่ถ้ามี tooling ดีและสโคปที่แคบลงเรื่อย ๆ มันก็ใช้งานได้จริงพอสมควร ตัว tooling เองอาจดูยาก แต่ผมคิดว่าแก้ได้ดีพอ และมองอนาคตในแง่บวก
ผมคิดว่าทั้งหมดนี้เป็นปัญหาที่แก้ได้ เพียงแต่เพราะการแข่งขันเพื่อดัน ARR ให้โตเร็ว สตาร์ตอัปจำนวนมากเลยไม่โฟกัสเรื่องพวกนี้ ความเห็นที่ว่าเอเจนต์ใช้งานจริงไม่ได้ตามที่สัญญาไว้ก็มีเหตุผล แต่ในทางปฏิบัติมันเป็นปัญหาด้านวิศวกรรม ถ้าเข้าหาจากอีกมุมก็น่าจะทำให้ใช้ได้ผลได้ (ส่วนตัวผมเชียร์ฝั่ง RL มากกว่า) ตัวอย่างเช่น ต้องมี verifier ที่ดี งานหลายอย่างตรวจสอบได้ง่ายกว่าการลงมือทำเอง ถ้ามีผลลัพธ์ที่สร้างแบบขนาน 5 ชิ้นและแต่ละชิ้นแม่น 80% ก็มีโอกาส 99.96% ที่อย่างน้อยหนึ่งชิ้นจะถูกต้อง และ verifier ก็เลือกชิ้นนั้นได้ ในสถานการณ์หลายขั้นตอนก็ได้เปรียบในเชิงคณิตศาสตร์ด้วย เป็นแนวทางที่ต่างจากเดิม และในบทความก็พูดถึงพาราไดม์เวิร์กโฟลว์ 3-5 ขั้นตอนซึ่งเข้ากันได้ดีมาก ต่อจากนี้ควรมีโมเดลลักษณะนี้ออกมาอีกเยอะ
มีข้อโต้แย้งว่าในหลายงาน การตรวจสอบจริง ๆ ยากกว่าตัวงานเองไม่ใช่หรือ โดยเฉพาะในวงการ software QA ที่มักมีการปรับโครงสร้างด้วยตรรกะแบบนี้ และผลลัพธ์คือคุณภาพแย่ลง verifier กลายเป็นงานยากมากเพราะจำนวนการผสมกันของสถานะที่เป็นไปได้ของระบบและโลกภายนอกเพิ่มแบบทวีคูณ LLM น่าสนใจตรงที่ช่วยแทนงานซ้ำ ๆ จุกจิกอย่างการ mock dependency หรือ prefill ข้อมูลในสภาพแวดล้อมงานที่ซับซ้อนแบบนี้ แต่ถ้าจะให้การทดสอบตรวจสอบมีความหมาย ก็จะมีข้อกำหนดว่าต้องแม่น 100% เสมอ และสุดท้ายก็ต้องมี verifier สำหรับแต่ละ precondition อีก ถ้าทุกขั้นต้อง 100% จริง ความน่าจะเป็นสะสมก็จะยิ่งลดลง มนุษย์ส่วนมากแค่ทดสอบอย่างระมัดระวังเป็นกรณี ๆ ไป ไม่ได้ตรวจครบทุกกรณีแบบสมบูรณ์ (white-box test พบได้บ่อยกว่า black-box มาก) ถ้า LLM ผลิตโค้ดออกมาเยอะ สุดท้ายคนทำงานก็ต้องเข้าใจโค้ดทั้งหมดอยู่ดีถึงจะทำ white-box verification ได้ ซึ่งทำให้เวลาที่ประหยัดได้หายไปอีก ตอนนี้สำหรับผมคือ LLM สร้างแล้วผมก็ยังต้องตามแก้บั๊กเองทั้งหมด เลยยิ่งมั่นใจน้อยลงและเสียเวลามากขึ้น ในบางสถานการณ์อาจแก้ด้วยการออกแบบ interface ให้เข้ากับสิ่งที่ LLM คาดเดาได้ แต่ก็ไม่ใช่แนวทางทั่วไป และนอกโลกซอฟต์แวร์ไป การตรวจสอบมักเป็นไปไม่ได้เลย (เช่น "คัดเลือกเกมสตาร์ตอัปที่มีแววที่สุด 5 ราย") ถ้าปล่อยให้เครื่องรับผิดชอบเรื่องแบบนี้แบบไม่ยั้ง สุดท้ายอาจเก็บกวาดไม่ไหว
สงสัยว่าจะสมมุติได้หรือไม่ว่าการสร้างทั้งห้าครั้งเป็นอิสระต่อกันจริง ๆ
เห็นด้วย หลายเอเจนต์ช่วยกันลอง หลายรอบ ลองวิธีแก้หลายแบบ เป็นแนวทางที่ใช้ได้ผลจริง ผมเคยเจอกรณีที่วิธีหนึ่งโดนฟีดแบ็กลบ แล้วไปสำเร็จด้วยอีกแนวทางหนึ่ง
น่าแปลกใจที่คนคนเดียว (หรือทีมเล็กมาก) จะสร้าง AI agent ที่ใช้งานจริงในโปรดักชันได้มากกว่า 12 ตัว ครอบคลุมทั้งการพัฒนา DevOps และ data operations ดูจากอัตราความล้มเหลวของสตาร์ตอัปแล้ว แค่ทำผลิตภัณฑ์ดี ๆ ได้ "หนึ่ง" ตัวก็ยากมาก แต่นี่ทำได้ถึง 12 ตัวเลยน่าทึ่ง ฝั่งเรากว่าจะทำเครื่องมือแนว data stack + AI agent อย่าง Definite ให้ใช้ได้ดี ก็ใช้เวลา 2 ปี และเพิ่งโอเคจริง ๆ เมื่อราว 6 เดือนก่อน Definite
จริง ๆ ไม่ใช่ผลิตภัณฑ์อิสระ 12 ตัว แต่หมายถึงเครื่องมือ 12 ชิ้นที่มีเป้าหมายเฉพาะมากและสร้างไว้ใช้ในที่ทำงานตามความจำเป็น อย่างที่ทั้งบทความพูดไว้ ถ้าจะให้เอเจนต์มีประโยชน์จริง ต้องโฟกัสกับเป้าหมายที่ง่ายและชัดเจนมากเท่านั้น
การทำงานประจำเต็มเวลาอยู่ 3 ปีแล้วยังสร้างได้เกิน 12 ตัว ฟังดูแปลก ๆ อยู่เหมือนกัน
งานของผมก็คือพัฒนาเอเจนต์/ระบบอัตโนมัติด้วย AI จริง ๆ เอเจนต์เขียนโค้ดแบบ open-ended เป็นไอเดียที่งี่เง่ามาก จุดตรวจสอบโดยมนุษย์ พื้นที่ค้นหาที่เล็ก และคำถาม/พรอมป์ตที่เฉพาะมาก (เช่น อีเมลนี้มีใบแจ้งหนี้ไหม YES/NO) ต่างหากที่ใช้งานได้จริง ผมเข้าใจความอยากได้เอเจนต์อัตโนมัติเต็มรูปแบบ แต่เทคโนโลยียังไปไม่ถึงตรงนั้น ผมไม่แตะงานสร้างคอนเทนต์เลย ไม่ว่าจะเป็นข้อความ รูปภาพ หรือโค้ด เพราะสุดท้ายมันจะย้อนกลับมาทำร้ายคุณแน่
ผมเองก็ใช้ chat coding ร่วมกับ agent framework แล้วลดปริมาณงานได้ราว 50% ได้เห็นผลจริงจาก GPT แต่ก็ยังมีข้อผิดพลาดเกิดขึ้นประมาณ 1 ใน 10 ครั้ง และผมคิดว่าถ้าไม่เปลี่ยนสถาปัตยกรรม LLM แบบรากฐาน อัตราความผิดพลาดนี้คงไม่หาย ตอนนี้เพราะ hype ความเชื่อมั่นของนักพัฒนากำลังสั่นคลอน แต่ถ้าไม่ถึงขั้นพัง ผมมั่นใจว่าอนาคตจะมีระบบที่แข็งแรงกว่านี้มาก ผลิตภาพที่เพิ่มขึ้นชัดเจนจนทีมเรารับคนใหม่น้อยลงได้มากเมื่อเทียบกับก่อนหน้า เส้นโค้งการเรียนรู้ของหลายหัวข้อก็ลดลงแบบก้าวกระโดด เพราะ LLM มาชดเชยคุณภาพที่แย่ลงของ google search โครงสร้างที่สำคัญที่สุดคือ Orchestration Framework ที่ให้ LLM มารับบางส่วนของงานมนุษย์ในเวิร์กโฟลว์อัตโนมัติ โดยให้ LLM รายงานระดับความมั่นใจของตัวเองมาด้วย และถ้า confidence % ต่ำก็ส่งต่อให้มนุษย์ทันที ถ้ามีการทดสอบ guardrail ฯลฯ ดีพอ งานที่ไม่ใช่ภารกิจหลักก็น่าจะทดแทนมนุษย์ได้พอสมควร เป้าหมายไม่ใช่แทนคนทั้งหมด แต่คือทำงานให้เป็นอัตโนมัติเพื่อลดขนาดทีม ตัวอย่างเช่น งานที่มนุษย์ทำอยู่ในอีคอมเมิร์ซขนาดใหญ่ ไม่ว่าจะเป็นคำอธิบายสินค้า การตรวจภาพ การจับคำผิด หรือภาพไม่ตรงสินค้า ผมเชื่อว่าวันที่ LLM รับงานพวกนี้ได้จะมาถึงแน่
โดยรวมเห็นด้วย แต่ถ้าใช้แนวทางนั้น สิ่งที่เหลืออยู่สุดท้ายอาจเป็นแค่ "ระบบเวิร์กโฟลว์ราคาแพง" ก็ได้ เลยต้องถามว่ามีความจำเป็นจริงไหมที่ต้องใช้ LLM กับสิ่งที่เทคโนโลยีเก่าก็ทำได้อยู่แล้ว
ผมก็เห็นด้วย ตอนนี้จุดที่เหมาะกับเอเจนต์ที่สุดคือ "ขอบเขตแคบ ความเสี่ยงต่ำ งานซ้ำสูง และน่าเบื่อ" ตัวอย่างเช่นผมเคยใช้เอเจนต์ช่วยงานประกอบ dev-log แบบ Markdown และเขียนไว้ ที่นี่
แม้การให้มนุษย์ตรวจสอบจะน่าเชื่อถือที่สุดสำหรับทำ checkpoint แต่ก็ยังมีวิธีอื่นเสริมได้ เช่น unit test หรือการตรวจสอบเฉพาะกิจของทั้งระบบ
ผมกลับคิดว่าในความเป็นจริง ผู้เขียนควรมองโลกในแง่ดีต่อ autonomous agent มากกว่าตอนนี้เสียอีก 90% ของสิ่งที่ทำกันอยู่ทุกวันนี้เป็นเรื่องที่ต้นปี 2024 ยังทำไม่ได้เลย เราไม่ควรประเมินเส้นโค้งความก้าวหน้าต่ำเกินไป
ผมก็คิดเหมือนกัน มีบล็อกโพสต์ที่เกี่ยวข้องด้วย ความแตกต่างสำคัญคือการใช้ HITL(Human in the loop) เพื่อลดข้อผิดพลาดนั้นถูกทาง แต่ HOTL(Human out of the loop) กลับเป็นตัวสร้างปัญหา