จากแชตบอตพร้อมเครื่องมือสู่เอเจนต์ AI: ชั้นควบคุมที่ขาดหายไป

• ทีม AI ส่วนใหญ่ที่ต้องการเพิ่มประสิทธิภาพของเอเจนต์มักเลือกวิธีเดิมๆ ได้แก่ หน้าต่างบริบทที่ใหญ่ขึ้น เอกสารมากขึ้น และพรอมต์ที่ฉลาดขึ้น บทความนี้เสนอว่าสัญชาตญาณดังกล่าวผิดทางโดยสิ้นเชิง ส่วนผสมที่ขาดหายไปไม่ใช่ข้อมูลที่มากขึ้น แต่คือการควบคุม ชั้นควบคุมที่ออกแบบมาอย่างดีคือสิ่งที่แยกเอเจนต์ที่ทำงานได้เฉพาะในการสาธิตออกจากเอเจนต์ที่ใช้งานจริงได้

• การเพิ่มหน่วยความจำ เอกสาร หรือหน้าต่างบริบทให้เอเจนต์ AI ไม่ได้ทำให้ฉลาดขึ้น มีแต่ทำให้ช้าลงและแพงขึ้น ผลลัพธ์ที่ดีขึ้นอย่างแท้จริงมาจากการสอนให้เอเจนต์เลือกสิ่งที่ต้องใช้ในเวลาที่ต้องใช้ แทนที่จะรับทุกอย่างพร้อมกัน

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

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

เมื่อวานคุณกินอะไรเป็นมื้อกลางวัน?

คุณคงไม่ได้ย้อนดูทุกความทรงจำที่เคยมีจนพบ “เมื่อวาน + มื้อกลางวัน” แต่เข้าถึงส่วนของประสบการณ์ที่มีแนวคิดเหล่านั้นอยู่โดยตรง นี่คือกรอบความคิดที่มีประโยชน์ต่อการสร้างเอเจนต์:

• หน้าต่างบริบทขนาดใหญ่ไม่ใช่หน่วยความจำ

• กองเอกสารที่ดึงมาไม่ใช่ความเข้าใจ

• การให้เหตุผลแบบเป็นลำดับขั้นที่ยาวไม่ใช่ความน่าเชื่อถือ

สิ่งเหล่านั้นเป็นเพียงส่วนผสม แต่สิ่งที่ทำให้เอเจนต์ดูเป็นเอเจนต์ คือสิ่งเดียวกับที่ทำให้สมองของคุณไม่ต้องไล่ค้นประวัติทั้งชีวิตแบบลองทุกทาง นั่นคือการควบคุม

บทสำรวจล่าสุดเรื่อง Agentic Reasoning for Large Language Models สรุป (และตั้งชื่อให้) การเปลี่ยนแปลงที่พวกเราหลายคนสัมผัสได้ระหว่างการสร้างระบบไว้อย่างยอดเยี่ยม นั่นคือ จากการให้เหตุผลภายในโมเดล สู่การให้เหตุผลผ่านการโต้ตอบ โพสต์นี้ไม่ใช่บทสรุปของงานวิจัยดังกล่าว แต่เป็นความพยายามถ่ายทอดการเปลี่ยนแปลงนี้ให้เป็นการออกแบบระบบที่นำไปใช้ได้จริง:

หากคุณสร้างเอเจนต์เหมือนแชตบอตพร้อมเครื่องมือ คุณก็จะพบความล้มเหลวแบบแชตบอตต่อไป เพียงแต่ความผิดพลาดมีราคาแพงขึ้น

ช่วงหนึ่ง แนวทางมาตรฐานในการ “ทำให้โมเดลฉลาดขึ้น” ของเราคือใช้พรอมต์ที่ดีขึ้น การให้เหตุผลแบบเป็นลำดับขั้น ความสอดคล้องในตัวเอง/การปรับปรุงด้วยการสุ่มตัวอย่าง และอาจเพิ่มการค้นหาบ้าง

ReAct เป็นจุดเปลี่ยนสำคัญ เพราะทำให้ “ความคิด → การกระทำ → การสังเกต” ดูเป็นธรรมชาติ แต่สังเกตข้อจำกัดที่แฝงอยู่: หลายอย่างยังลงเอยเป็น “การอนุมานแบบ one-shot แต่ใช้โทเค็นมากขึ้น” กรอบของบทสำรวจชัดเจนกว่า โดยการให้เหตุผลแบบเอเจนต์เน้นการขยายการโต้ตอบขณะทดสอบ เปลี่ยนการอนุมานให้เป็นกระบวนการวนซ้ำที่มีโมเดล หน่วยความจำ และสภาพแวดล้อมอยู่ในลูปเสมอ

หากคุณเคยสร้าง (หรือใช้) เอเจนต์ที่ดูน่าประทับใจในการสาธิต แต่เปราะบางในเวิร์กโฟลว์จริง เนื้อหานี้เหมาะสำหรับคุณ

ผมขออธิบายรูปแบบที่พบเห็นบ่อย (และยอมรับว่าเคยสร้างหลายเวอร์ชันด้วยตัวเอง):

1. เริ่มจากโมเดลแชตที่ดี

2. เพิ่มเครื่องมือสองสามอย่าง (ค้นหา คิวรีฐานข้อมูล และอาจเรียกใช้โค้ด)

3. เพิ่ม RAG

4. เพิ่มพรอมต์ระบบว่า “you are an autonomous agent”

5. ครอบทั้งหมดด้วย while-loop จนกว่าจะหยุดหรือหมดเวลา

ยินดีด้วย คุณได้วัตถุทรงเอเจนต์แล้ว แต่มันมักล้มเหลวในแบบที่คาดเดาได้:

• บริบทพองโต: ทุกสิ่งที่สังเกตได้ถูกต่อท้าย พรอมต์จึงทับถมเป็นชั้นราวกับแหล่งโบราณคดี

• ใช้เครื่องมือสะเปะสะปะ: “เลือกเครื่องมือผิดอย่างมั่นใจ” กลายเป็นรูปแบบความล้มเหลวโดยปริยาย

• ไม่มีเงื่อนไขหยุด: ระบบทำต่อเพียงเพราะทำได้ ไม่ใช่เพราะควรทำ

• ไม่มีวินัยด้าน grounding: ระบบไม่รู้ตัวว่าผิด เว้นแต่คุณจะบังคับให้ตรวจสอบ

• หน่วยความจำ = ประวัติแชต: ซึ่งแทบไม่ต่างจากการเขียนบันทึกเหตุการณ์แล้วเรียกสิ่งนั้นว่าการเรียนรู้

นี่คือเหตุผลที่ “เอเจนต์” มักดูมหัศจรรย์ในการสาธิต แต่ยุ่งเหยิงเมื่อใช้งานจริง ประสบการณ์ของเราในการนำระบบแบบเอเจนต์ไปใช้งานจริงก็สะท้อนเรื่องนี้ เมื่อสิ่งที่คุณประเมินไม่ใช่โมเดลแต่เป็นระบบ รูปแบบความล้มเหลวย่อมรวมถึงการนำทาง สุขอนามัยในการใช้เครื่องมือ การตัดแต่งบริบท และการออกแบบการประเมิน ไม่ใช่แค่ “โมเดลตอบถูกหรือไม่”

คำถามจึงกลายเป็นว่า เอเจนต์ที่ออกแบบอย่างตั้งใจควรเป็นแบบไหน?

เพื่อให้เห็นภาพมากขึ้น ลองดูเวิร์กโฟลว์ตัวอย่างง่ายๆ ที่คนส่วนใหญ่นึกภาพออก: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”

การใช้งานที่ “ดูคล้ายเอเจนต์” โดยทั่วไปมีลักษณะดังนี้:

• ดึงเอกสารนโยบายสายการบิน/การเดินทางจำนวนมากทันที (แม้ตอนนั้นยังไม่จำเป็นต้องใช้เลยก็ตาม)

• เรียกเครื่องมือค้นหา วางรายการผลลัพธ์ยาวเหยียดลงในพรอมต์ แล้ว “เลือกมาหนึ่งรายการ”

• รีบจองก่อนตรวจสอบข้อจำกัด (เวลาถึงปลายทาง / สัมภาระ / ที่นั่ง / นโยบาย)

• หากล้มเหลว ระบบจะลองใหม่ด้วยวิธีที่ต่างออกไปเล็กน้อย แต่ไม่รู้ชัดว่าอะไรเปลี่ยนไปหรือเรียนรู้อะไรมา

สาเหตุของความล้มเหลวไม่ใช่โมเดลให้เหตุผลไม่ได้ แต่เป็นเพราะระบบไม่ได้ควบคุมเวิร์กโฟลว์

เวอร์ชันที่เป็นเอเจนต์มากขึ้นจะมองงานเป็นกระบวนการโต้ตอบที่มีสถานะและการตรวจสอบชัดเจน:

• วางแผน: ทวนข้อจำกัด + ระบุข้อมูลที่ขาด (เช่น “which airport preference?” / “is 1 stop ok?”)

• ลงมือทำ: เรียกใช้การค้นหาเที่ยวบินด้วยคำค้นแบบมีโครงสร้าง (ช่วงวันที่ ข้อจำกัดเวลาถึง และงบประมาณ)

• สังเกต: เก็บผลลัพธ์ไว้ในออบเจ็กต์สถานะแบบกระชับ (ตัวเลือกที่ดีที่สุด 5 รายการพร้อมราคา เวลาถึง และจำนวนครั้งที่ต่อเครื่อง) แทนการวางข้อมูลก้อนมหึมา

• อัปเดต: ปรับคำค้นหากไม่ตรงตามข้อจำกัด (เช่น “arrival before 6pm is too strict—widen time window or raise budget?”)

• ตรวจสอบยืนยัน: เรียกใช้ตัวตรวจสอบ (“arrival < 18:00,” “price ≤ £900,” “policy compliant,” “seat selection available”)

• หยุด: เมื่อ API การจองส่งการยืนยันกลับมาและผ่านตัวตรวจสอบทั้งหมดแล้วเท่านั้น

สิ่งที่เปลี่ยนไปดูละเอียดอ่อนแต่มีผลชี้ขาด การดึงข้อมูลมีเงื่อนไข (ไม่ใช่การตอบสนองอัตโนมัติ) มีการจัดการบริบท (สถานะมีโครงสร้าง ไม่ใช่สะสมไปเรื่อยๆ) และมีการตรวจสอบยืนยันอยู่ในลูป (ไม่ปล่อยให้ผู้ใช้เป็นคนทำ) ลองเปลี่ยน “การจองเที่ยวบิน” เป็น “การสร้างใบสั่งซื้อ” “การคืนเงิน” “การเปลี่ยนค่ากำหนดของระบบใช้งานจริง” หรือ “การส่ง PR” เรื่องราวก็ยังเหมือนเดิม เมื่อเอเจนต์ลงมือทำได้ ลูปย่อมสำคัญกว่าพรอมต์

บทสำรวจที่กล่าวถึงข้างต้นแบ่งการให้เหตุผลแบบเอเจนต์เป็นสามชั้น ได้แก่ พื้นฐาน (การวางแผน/ใช้เครื่องมือ/ค้นหา) พัฒนาตนเอง (ฟีดแบ็ก + หน่วยความจำ) และรวมกลุ่ม (การประสานงานของหลายเอเจนต์)

แต่แนวคิดที่ลึกกว่านั้นคือ การให้เหตุผลกลายเป็นหลักในการจัดระเบียบการวางแผน การตัดสินใจ และการตรวจสอบยืนยัน ไม่ใช่แค่การสร้างการให้เหตุผลแบบเป็นลำดับขั้นที่ฟังดูเป็นไปได้ เรื่องนี้ฟังดูเป็นนามธรรม จนกว่าคุณจะเชื่อมโยงเข้ากับสิ่งที่เปลี่ยนแปลงในสถาปัตยกรรมของคุณ มีประเด็นหลักสามข้อที่ควรจำ:

เอเจนต์ที่ดีไม่ควรมองว่าการดึงข้อมูลเป็นสิ่งที่ “ต้องทำเสมอ” การดึงข้อมูลคือการตัดสินใจ ไม่ใช่การตอบสนองอัตโนมัติ

หลักง่ายๆ ที่ใช้ได้จริงมีดังนี้:

หากระบบดึงข้อมูลทุกรอบ คุณไม่ได้สร้างระบบดึงข้อมูล แต่สร้างภาษีบริบทขึ้นมา

เรื่องนี้พบได้ตลอดเวลาในการทำงานจริง เมื่อดีบักเหตุขัดข้องในระบบใช้งานจริง คุณไม่ได้เทบันทึกเหตุการณ์ทั้งหมดลงในบริบท แต่ตัดสินใจว่าจะดึงเมตริกหรือบันทึกใดต่อไปตามสมมติฐานปัจจุบัน นั่นคือ “การดึงข้อมูลแบบเอเจนต์” และนี่คือรูปแบบที่เป็นรูปธรรมมากขึ้น:

1. ตัดสินใจก่อนว่าต้องดึงข้อมูลหรือไม่

2. หากต้องดึง: ร่างคำค้น ดึงข้อมูล อ่านคร่าวๆ แล้วสกัดสาระ

3. หากหลักฐานขัดแย้งกัน: ดึงข้อมูลอีกครั้ง

4. จากนั้นจึงสังเคราะห์คำตอบ

นี่คือจุดที่ “RAG แบบเอเจนต์” เริ่มแตกต่างจาก RAG แบบเดิม: การดึงข้อมูลกลายเป็นขั้นตอนการให้เหตุผลที่ทำโดยเจตนา ไม่ใช่ขั้นเริ่มต้นที่ทำเป็นค่าเริ่มต้นในไปป์ไลน์

ทันทีที่คุณเลิกประเมิน “โมเดล” แล้วหันมาประเมิน “ระบบ” การติดตามสถานะและการสืบย้อนก็เริ่มมีความสำคัญ

สิ่งหนึ่งที่วงการให้ความสำคัญอย่างชัดเจนขึ้นในตอนนี้คือความสามารถในการสังเกตการณ์เวิร์กโฟลว์ของเอเจนต์ ตัวอย่างเช่น Agents SDK ของ OpenAI มาพร้อมการสืบย้อนในตัวและแดชบอร์ด Traces ที่บันทึกการทำงานของเอเจนต์ (การสร้างผลลัพธ์ การเรียกใช้เครื่องมือ การส่งต่องาน กลไกป้องกัน และเหตุการณ์ที่กำหนดเอง) เพื่อให้คุณดีบักและตรวจสอบสิ่งที่เกิดขึ้นทีละขั้นได้โดยเฉพาะ

นั่นไม่ใช่แค่สิ่งที่ “มีก็ดี” แต่คือความแตกต่างระหว่างระบบที่ดีบักได้กับระบบที่ทำได้เพียงประเมินจากความรู้สึก

ในความเห็นของผม ส่วนที่นำไปใช้ได้จริงที่สุดของบทสำรวจคือการกล่าวถึงฟีดแบ็กอย่างตรงไปตรงมา บทสำรวจแบ่งฟีดแบ็กเป็นสามรูปแบบ ได้แก่ ฟีดแบ็กแบบไตร่ตรอง (สร้าง → วิจารณ์ → แก้ไข) การปรับพารามิเตอร์ (เรียนรู้ผ่านการปรับแต่งโมเดล / RL) และฟีดแบ็กที่ขับเคลื่อนด้วยตัวตรวจสอบ (ลองใหม่จนกว่าจะผ่านตัวตรวจสอบ)

ทีมส่วนใหญ่ควรเริ่มจากฟีดแบ็กที่ขับเคลื่อนด้วยตัวตรวจสอบ เพราะถึงจะดูธรรมดาแต่ได้ผล หากคุณเขียนตัวตรวจสอบได้ไม่ว่าแบบใดที่ทำยูนิตเทสต์ ตรวจสอบ Schema กำหนดกฎ/ข้อจำกัดทางธุรกิจ (“ห้ามคืนเงินเกิน X โดยไม่ส่งต่อให้ผู้มีอำนาจ”) หรือยืนยันข้อเท็จจริง (“ต้องมีแหล่งอ้างอิง”) คุณก็เปลี่ยนผลลัพธ์ที่ไม่แน่นอนของโมเดลให้เป็นสิ่งที่เชื่อถือได้จริง

การเปลี่ยนแปลงอย่างหนึ่งที่เราไม่รู้ด้วยซ้ำว่าตนไม่รู้มีหลักง่ายๆ คือ ในโลกของเอเจนต์ ความน่าเชื่อถือมักมาจากลูปมากกว่าโมเดล

นี่คือวินัยในการทำงานแบบวนลูปที่เล็กที่สุดเท่าที่ผมพบว่าสามารถปรับปรุงพฤติกรรมได้อย่างสม่ำเสมอโดยไม่ต้องฝึกโมเดล:

• ทำงานเป็นขั้น: วางแผน → ลงมือทำ → สังเกต → อัปเดต

• หลังลงมือทำแต่ละครั้ง ให้สรุปสิ่งที่สังเกตได้เป็น 1–3 ข้อ

• หยุดเมื่อผ่านเกณฑ์ความสำเร็จหรือใช้งบถึงขีดจำกัด แล้วส่งคืนผลลัพธ์ที่ดีที่สุดเท่าที่ทราบพร้อมความไม่แน่นอนที่ยังเหลืออยู่

เป้าหมายไม่ใช่การทำให้โมเดลตอบยืดยาว แต่คือการทำให้ระบบเข้าใจได้ และบังคับให้ “ตรวจสอบกับความเป็นจริง” ในทุกขั้น ตัวอย่างที่วิศวกรคุ้นเคยเป็นอย่างดีคือ grounding แบบวงจรปิดในสไตล์ CI:

• วางแผน: เสนอรายการเปลี่ยนแปลง

• ลงมือทำ: รันการทดสอบ / lint

• สังเกต: แยกวิเคราะห์ข้อผิดพลาด

• อัปเดต: แพตช์แล้วลองใหม่

คำถามต่อไปนี้มักเผยให้เห็นการออกแบบที่กลายเป็นเอเจนต์โดยไม่ตั้งใจ:

“เอเจนต์ของฉันเลือกสิ่งที่จะดึงข้อมูลเอง หรือฉันดึงข้อมูลทุกครั้ง?”

หากดึงข้อมูลโดยไม่มีเงื่อนไข คุณจะต้องแลกด้วยความหน่วง ต้นทุน บริบทที่เจือจาง และความเสี่ยงที่ขยะเข้าก็ได้ขยะออกสูงขึ้น

“เอเจนต์ของฉันรู้ตัวได้ไหมว่ากำลังทำผิด?”

หากสัญญาณฟีดแบ็กเดียวของเอเจนต์คือ “ผู้ใช้เริ่มหงุดหงิด” คุณก็กำลังทำ RL โดยใช้ความทุกข์ของมนุษย์ ลูปการลองใหม่ที่ขับเคลื่อนด้วยตัวตรวจสอบคือวิธีที่เรียบง่ายที่สุดในการให้เอเจนต์ตรวจสอบกับความเป็นจริง

“หน่วยความจำเขียนข้อมูลได้ไหม และพัฒนาขึ้นตามกาลเวลาหรือไม่?”

หาก “หน่วยความจำ” ของคุณมีไว้เพียงต่อท้ายประวัติแชต สิ่งที่คุณทำก็แทบไม่ต่างจากการเขียนบันทึกเหตุการณ์ กรอบแนวคิดเรื่องหน่วยความจำของบทสำรวจมีความสำคัญ กล่าวคือ หน่วยความจำจะกลายเป็นบริบทที่เติบโตอย่างต่อเนื่องและได้รับการปรับปรุงจากเอเจนต์เมื่อเวลาผ่านไป ไม่ใช่แค่บทถอดความ

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

จุดเริ่มต้นที่ใช้ได้จริงคือตาราง “บทเรียนที่ได้รับ” ขนาดเล็ก โดยใช้ประเภทงาน เครื่องมือ และรูปแบบความล้มเหลวเป็นคีย์ ส่วนค่าคือสิ่งที่ได้ผลและสิ่งที่ควรหลีกเลี่ยง เป้าหมายไม่ใช่การสร้างกราฟความรู้ที่สมบูรณ์แบบ เป้าหมายคือสร้างพฤติกรรมที่ต่อยอดทบต้นได้: หน่วยความจำ + ฟีดแบ็กจะเปลี่ยนเอเจนต์จาก “ผู้ช่วยไร้สถานะ” ให้เป็นระบบที่พัฒนาขึ้นตามกาลเวลา

เราอาจอยากเพิ่มเอเจนต์เพื่อแก้ปัญหา แต่บ่อยครั้งวิธีนี้กลับทวีภาระในการประสานงาน รูปแบบ “ทีมขั้นต่ำที่ใช้งานได้” ที่ดีมีดังนี้:

• ผู้ประสานงาน: แบ่งงาน + มอบหมาย

• ผู้ปฏิบัติงาน: เรียกใช้เครื่องมือ / ดำเนินการเปลี่ยนแปลง

• ผู้วิจารณ์/ผู้ประเมิน: ตรวจสอบความถูกต้อง/ความเสี่ยง

• ผู้ดูแลหน่วยความจำ: บันทึก/คัดสรรบทเรียน

หากอธิบายไม่ได้ว่าเอเจนต์แต่ละตัวรับผิดชอบอะไร คุณก็คงยังไม่จำเป็นต้องใช้หลายเอเจนต์

หากเรายอมรับการเปลี่ยนกระบวนทัศน์นี้จริง เราก็คงเลิกยัดทุกอย่างลงในพรอมต์ เลิกมองความล้มเหลวเป็นผลลัพธ์สุดท้าย และเลิกประเมินเอเจนต์เหมือนแชตบอต แล้วเริ่มมองเอเจนต์ตามความเป็นจริง นั่นคือระบบซอฟต์แวร์ที่ใช้ภาษาเป็นระนาบควบคุม และมีความน่าเชื่อถือมาจากลูป

ก่อนเพิ่มโมเดลอีกตัว ให้เพิ่มลูปการประเมินอีกหนึ่งรอบ ก่อนดึงข้อมูลทุกอย่าง ให้กำหนดเงื่อนไขเสียก่อน ส่งตัวตรวจสอบหนึ่งตัวขึ้นใช้งานก่อนส่งทีเดียวสิบตัว มองหน่วยความจำเป็นการตัดสินใจเชิงนโยบาย ไม่ใช่ฐานข้อมูล และเมื่อจะใช้หลายเอเจนต์ ให้เริ่มจากสองตัว ไม่ใช่ยี่สิบตัว สิ่งเหล่านี้ไม่ใช่กฎ แต่เป็นรูปแบบที่ผ่านบทพิสูจน์จากการใช้งานจริง