คำว่า "agent" กำลังสูญเสียความหมาย ลองสแกนประกาศเปิดตัวผลิตภัณฑ์ใดก็ได้ในตอนนี้ แล้วคุณจะพบว่าฟีเจอร์ AI ทุกอย่างต่างก็อ้างว่าเป็น agent ทั้งนั้น วิดเจ็ตที่เป็นมิตรซึ่งช่วยร่างอีเมล? Agent. บอทสนับสนุนลูกค้าที่อ่านฐานความรู้ของคุณ? Agent. สคริปต์ที่เรียกใช้ API และส่งคืนค่า JSON? ก็เป็น agent เช่นกัน นี่ไม่ใช่แค่การตลาดที่สะเพร่า แต่มันคือการออกแบบที่อันตราย เมื่อคุณเรียกทุกอย่างว่าเป็น agent คุณจะเริ่มไม่เข้าใจว่าจริงๆ แล้วคุณกำลังสร้างอะไรอยู่ คุณพยายามจะใช้สถาปัตยกรรมที่ซับซ้อนก่อนที่จะนิยามหน้าที่ของมันเสียด้วยซ้ำ ผลลัพธ์ที่ได้คือโค้ดที่เปราะบาง ค่า token ที่พุ่งสูงเกินควบคุม และระบบที่แสดงพฤติกรรมในแบบที่คุณไม่สามารถอธิบายหรือทำซ้ำได้
Chatbot ทำได้เพียงรอ แต่ไม่ได้ลงมือทำ
Chatbot จัดอยู่ในระดับที่ง่ายที่สุด พวกมันเป็นแบบตอบสนอง (reactive) เมื่อผู้ใช้พิมพ์คำถาม โมเดลจะสร้างคำตอบ และการสนทนาก็จบลงตรงนั้น เว้นแต่จะมีคำสั่ง (prompt) จากมนุษย์เข้ามาอีกครั้ง ระบบเหล่านี้ไม่ได้ตัดสินใจที่จะตรวจสอบปฏิทินของคุณ อัปเดตบันทึกในฐานข้อมูล หรือหยุดเพื่อขอคำอธิบายเพิ่มเติม ลองพิจารณาวิดเจ็ตช่วยเหลือที่ฝังอยู่ในหน้าแผนราคาของ SaaS ดู มันตอบคำถามเกี่ยวกับรอบการเรียกเก็บเงินและข้อจำกัดของฟีเจอร์ แต่มันไม่สามารถคืนเงินให้ลูกค้า อัปเกรดแผนการใช้งาน หรือแจ้งเตือนบัญชีที่น่าสงสัยได้ มันไม่มีเครื่องมือ ไม่มีสถานะที่คงอยู่ (persistent state) นอกเหนือจากหน้าต่างแชท และไม่มีเป้าหมายอื่นใดนอกจากการสร้างประโยคที่เกี่ยวข้อง นั่นแหละคือ chatbot มันตอบสนอง แต่ไม่ได้ลงมือทำ
Assistant ช่วยเหลืออยู่ภายในกรอบที่กำหนด
Assistant เพิ่มความซับซ้อนโดยไม่ได้เพิ่มอำนาจในการตัดสินใจ (agency) พวกมันใช้ system prompt เพื่อสวมบทบาท (persona) และรักษาบริบท (context) ไว้ได้ในการสนทนาที่ยาวขึ้น พวกมันอาจสรุปเอกสารที่คุณอัปโหลด หรือเขียนย่อหน้าของคุณใหม่ด้วยน้ำเสียงที่ต่างออกไป ผู้ช่วยงานเขียนที่ตรวจสอบไวยากรณ์และแนะนำการใช้คำที่ชัดเจนขึ้นนั้นมีประโยชน์ มันจำได้ว่าคุณชอบการสะกดแบบอังกฤษ แต่ตัวมันเองไม่ได้ลงมือทำอะไรแทนคุณ มันไม่ได้ตัดสินใจส่งอีเมลหาบรรณาธิการของคุณ กำหนดเส้นตาย หรือค้นหาเว็บโดยที่คุณไม่ได้สั่ง มันช่วยคุณอยู่ภายในกรอบที่คุณกำหนดไว้ มันไม่ได้เป็นคนขับรถ แต่มันช่วยแนะนำเส้นทางที่ดีกว่าในขณะที่คุณยังคงจับพวงมาลัยอยู่
Workflow ทำตามแผนผังที่คุณวาดไว้
Workflow อยู่ในระดับกลาง ซึ่งเป็นระดับที่ระบบ AI ที่ใช้งานจริงส่วนใหญ่สังกัดอยู่ ในระดับนี้ คุณเป็นคนกำหนดเส้นทาง คุณสร้างลำดับขั้นตอน เช่น ดึงวันที่ในใบแจ้งหนี้, ค้นหา ID ของผู้ขาย, เปรียบเทียบยอดเงินกับใบสั่งซื้อ, อัปเดตสเปรดชีตบัญชี, ส่งการแจ้งเตือนไปยังฝ่ายการเงินหากตัวเลขไม่ตรงกัน โมเดลอาจจะอ่านใบแจ้งหนี้หรือจำแนกความคลาดเคลื่อน แต่สิ่งสำคัญคือมันทำตามกราฟ (graph) ที่คุณวางไว้ คุณจะรู้แน่ชัดว่าจะเกิดอะไรขึ้นเพราะคุณเป็นคนวาดแผนผังนั้นเอง
Workflow ทดสอบได้ง่ายกว่า คุณสามารถทำ unit-test แต่ละขั้นตอนแยกกันได้ คุณสามารถบันทึก (log) อินพุตและเอาต์พุตในทุกๆ โหนด (node) เมื่อมีบางอย่างผิดพลาด คุณจะรู้ว่าสาขา (branch) ไหนที่ล้มเหลวโดยไม่ต้องไปไล่ดูสายธารความคิด (chain of thought) ที่คลุมเครือ การสังเกตการณ์ (observability) นั้นตรงไปตรงมาเพราะระบบจะไม่ทำให้คุณประหลาดใจด้วยการออกนอกเส้นทาง หากกระบวนการทางธุรกิจของคุณมีกฎที่ชัดเจนและมีข้อยกเว้นที่ทราบกันอยู่แล้ว Workflow มักจะเป็นผู้ชนะ คุณจะได้ทั้งความเร็ว ความน่าเชื่อถือ และต้นทุนที่ต่ำกว่า โดยไม่ต้องแสร้งทำเป็นว่าเครื่องจักรมีความตั้งใจ
Agent เป็นผู้เลือกเส้นทางเอง
Agent นั้นแตกต่างออกไป พวกมันมีความยืดหยุ่น (dynamic) คุณแค่ให้เป้าหมายแก่พวกมัน แล้วพวกมันจะหาวิธีไปให้ถึงเป้าหมายนั้นเอง Agent จะได้รับงาน วิเคราะห์สิ่งที่ต้องทำ เลือกเครื่องมือ ลงมือทำ สังเกตผลลัพธ์ และตัดสินใจว่าอะไรควรทำเป็นลำดับถัดไป วงจรนั้น—คิด, ทำ, สังเกต, แล้วคิดใหม่—คือสิ่งที่แยก agent ออกจากหมวดหมู่อื่นๆ ทั้งหมด
ลองพิจารณาระบบที่จัดการคำขอคืนเงิน Workflow อาจจะตรวจสอบเงื่อนไขสามประการแล้วอนุมัติหรือปฏิเสธตามกฎที่กำหนดไว้ แต่ Agent เมื่อได้รับเป้าหมายว่า "ดำเนินการคืนเงินนี้อย่างยุติธรรมพร้อมกับตรวจสอบการทุจริต" มันอาจจะไปสอบถามประวัติการซื้อของลูกค้า, ตรวจสอบนโยบายการคืนสินค้าสำหรับหมวดหมู่สินค้านั้น, ตรวจสอบกิจกรรมล่าสุดของบัญชี, สร้างตั๋วสนับสนุน (support ticket) เพื่อให้คนตรวจสอบหากรูปแบบดูผิดปกติ และจากนั้นจึงร่างอีเมลอธิบายการตัดสินใจของมัน มันเป็นผู้เลือกเองว่าจะใช้เครื่องมือใดและใช้ในลำดับไหน โดยอิงจากรายละเอียดเฉพาะของกรณีนั้นๆ
Agent คือระบบ ไม่ใช่แค่โมเดล
Agent ไม่ใช่แค่โมเดลที่รันอยู่ในหน้าต่างแชท แต่มันคือระบบที่สมบูรณ์ ซึ่งประกอบด้วย:
- โมเดล (Models) เพื่อการใช้เหตุผลและสร้างภาษา
- คำสั่ง (Instructions) ที่กำหนดขอบเขตการทำงาน
- เครื่องมือ (Tools) ที่มีโครงสร้าง (schema) ที่เข้มงวดเพื่อโต้ตอบกับโลกภายนอก
- บริบท (Context) เกี่ยวกับงานและสภาพแวดล้อมในปัจจุบัน
- สถานะ (State) เพื่อให้จดจำได้ว่าอยู่ในขั้นตอนใดของกระบวนการที่มีหลายขั้นตอน
- การตรวจสอบความถูกต้อง (Validations) เพื่อเช็กข้อมูลนำเข้าก่อนเข้าสู่เครื่องมือ และเช็กข้อมูลส่งออกก่อนถึงมือผู้ใช้
- ข้อจำกัด (Limits) ด้านงบประมาณ, จำนวนขั้นตอน หรือขอบเขต เพื่อป้องกันพฤติกรรมที่ควบคุมไม่ได้
- ความสามารถในการสังเกตการณ์ (Observability) เพื่อให้คุณสามารถย้อนรอยได้ว่าทำไมมันถึงเลือกเส้นทาง A แทนที่จะเป็นเส้นทาง B
หากระบบของคุณขาดสิ่งเหล่านี้ส่วนใหญ่ คุณไม่ได้มี "เอเจนต์" (agent) แต่คุณมีเพียงโมเดลที่มีการเรียกใช้ API เพิ่มเติมเท่านั้น
ความเป็นอิสระที่ปราศจากการควบคุม คือความเสี่ยง
หากเอเจนต์ของคุณสามารถคิวรีฐานข้อมูลโปรดักชัน สร้างเรคคอร์ดใน CRM หรือส่งข้อความหาผู้ใช้ได้ มันก็สามารถทำให้ข้อมูลเสียหาย สร้างข้อมูลซ้ำซ้อน หรือส่งสแปมหาลูกค้าได้เช่นกัน สถาปัตยกรรมเอเจนต์ที่ดีต้องเตรียมพร้อมรับความล้มเหลว มันต้องขออนุญาตก่อนดำเนินการที่อาจก่อให้เกิดความเสียหาย ต้องมีการตรวจสอบความถูกต้องก่อนบันทึกผลลัพธ์ และต้องแสดงกระบวนการคิด (reasoning) เพื่อให้มนุษย์สามารถเข้ามาแทรกแซงได้เมื่อมีต้นทุนหรือความเสี่ยงสูง
หากคุณข้ามข้อจำกัดเหล่านี้เพียงเพราะตัวเดโมดูน่าตื่นเต้น คุณจะต้องใช้เวลาช่วงวันหยุดสุดสัปดาห์ไปกับการไล่แก้บั๊ก (debugging) ว่าทำไมเอเจนต์ถึงสร้างตั๋วสนับสนุน (support tickets) ถึงสี่ร้อยใบในชั่วข้ามคืน หรือคืนเงินคำสั่งซื้อที่ไม่ควรจะไปแตะต้อง ความไม่แน่นอนที่คุณเคยกลัวในระบบแบบ Black-box จะกลายเป็นเรื่องจริงทันทีที่คุณมอบทั้งเป้าหมายและชุดเครื่องมือที่ไม่มีการควบคุมให้กับ AI
เริ่มต้นที่ปัญหา ไม่ใช่ที่เทคโนโลยี
อย่าเริ่มที่เอเจนต์ แต่ให้เริ่มที่ปัญหา (pain point) บางครั้งการแก้ไขอาจเป็นเพียงการเขียน Prompt ให้ดีขึ้น บางครั้งอาจเป็นฟังก์ชันแบบ Deterministic ใน Backend เดิมของคุณ หรือบางครั้งอาจเป็นเวิร์กโฟลว์ที่มีขั้นตอน AI เพียงขั้นตอนเดียวและมีการเรียกใช้ API แบบดั้งเดิมอีกห้าขั้นตอน
จะใช้เอเจนต์ก็ต่อเมื่องานนั้นจำเป็นจริงๆ ดังนี้:
- หลายขั้นตอนที่มีความเกี่ยวเนื่องกัน
- การตัดสินใจแบบไดนามิกในระหว่างขั้นตอนเหล่านั้น
- การโต้ตอบกับเครื่องมือภายนอก
- การใช้เหตุผลเหนือผลลัพธ์ระหว่างทางที่คุณไม่สามารถวางแผนล่วงหน้าได้อย่างสมบูรณ์
หากเส้นทางนั้นชัดเจนอยู่แล้ว ให้สร้างเวิร์กโฟลว์ (workflow) หากการโต้ตอบนั้นเรียบง่าย ให้สร้างแชทบอทหรือผู้ช่วย (assistant) อย่าเพิ่มความเป็นเอเจนต์ (agency) เพียงเพราะคำนี้ฟังดูทันสมัย
สร้างความสมบูรณ์แบบ ไม่ใช่ความซับซ้อน
เมื่อเอเจนต์เป็นสิ่งที่เหมาะสมจริงๆ ให้สร้างมันเป็นชั้นๆ เริ่มจากเครื่องมือเพียงชิ้นเดียวและการตัดสินใจแบบ Hardcoded เพิ่มการทดสอบเพื่อตรวจสอบว่าเครื่องมือถูกเรียกใช้ด้วยอาร์กิวเมนต์ที่ถูกต้อง เพิ่มการบันทึก Log เพื่อให้คุณเห็นร่องรอย (trace) ทั้งหมด เพิ่มการจัดการสถานะ (state management) เพื่อให้ระบบรู้ว่าค้างไว้ที่ตรงไหน เพิ่มการตรวจสอบความถูกต้องในทุกจุดเชื่อมต่อ เพิ่มแดชบอร์ดสำหรับการสังเกตการณ์ (observability dashboards) เพื่อให้ทีมของคุณสามารถเฝ้าดูพฤติกรรมได้แบบเรียลไทม์ และสุดท้าย จึงค่อยๆ เพิ่มความเป็นอิสระ (autonomy)—นั่นคืออิสระในการเลือกจากตัวเลือกต่างๆ อย่าทำย้อนศร เพราะความเป็นอิสระที่วางทับอยู่บนความวุ่นวายจะสร้างอุบัติเหตุที่มีราคาแพง
บทสรุปที่แท้จริง
คำพูดกำหนดรูปแบบของระบบ จงสงวนคำว่า "เอเจนต์" (agent) ไว้สำหรับสถาปัตยกรรมที่คู่ควรเท่านั้น: คือต้องมุ่งเน้นเป้าหมาย ใช้เครื่องมือเป็น และปรับตัวได้อย่างไดนามิก แต่ต้องอยู่ภายใต้ข้อจำกัดที่เข้มงวดและการกำกับดูแลโดยมนุษย์ ส่วนอย่างอื่นนั้นเป็นเพียงแชทบอท ผู้ช่วย หรือเวิร์กโฟลว์ จงสร้างสิ่งที่เรียบง่ายที่สุดที่สามารถแก้ปัญหาได้ แล้ว Log ในโปรดักชัน ทีมการเงิน และตัวคุณในอนาคตจะขอบคุณคุณเอง
Source: https://dev.to/leandrolayerle/no-todo-chatbot-es-un-agente-de-ia-3oec
Join the GyaanSetu learning community: https://t.me/GyaanSetuAi