จากพยากรณ์ยอดขายถึงใบสั่งซื้อด้วยเอเจนต์ AI: ให้ AI ตัดสินเฉพาะเรื่องที่ต้องใช้วิจารณญาณ ตามสถาปัตยกรรมของ AWS

ร้านค้าที่มีสินค้า 10,000 รายการเคยต้องสร้างโมเดลพยากรณ์ยอดขาย 10,000 ตัวแยกกัน แล้วยังต้องให้คนแปลงตัวเลขพยากรณ์เป็นใบสั่งซื้อผ่านสเปรดชีตอีกทอดหนึ่ง บทความจาก AWS Architecture Blog เมื่อวันที่ 11 กันยายน 2026 แสดงสถาปัตยกรรมที่ใช้โมเดลพยากรณ์สำเร็จรูปร่วมกับเอเจนต์ AI สี่ตัว ทำงานตั้งแต่อ่านข้อมูลยอดขายจนออกคำแนะนำการสั่งซื้อ หลักคิดที่ใช้ได้กับทุกระบบเอเจนต์คือ ให้ AI ทำเฉพาะงานที่ต้องใช้วิจารณญาณ ส่วนการคำนวณให้โค้ดทำ และเมื่อเงื่อนไขชนกันต้องถามคน ไม่ใช่ตัดสินเงียบ ๆ

ปัญหาเดิม: หนึ่งสินค้า หนึ่งโมเดล

ผู้จัดการคลังสินค้าต้องตัดสินใจทุกวันว่าจะสั่งของเท่าไร สั่งน้อยไปของขาด สั่งมากไปเงินจม วิธีดั้งเดิมคือสร้างโมเดลพยากรณ์อนุกรมเวลา เช่น ARIMA หรือ Holt-Winters แยกให้สินค้าแต่ละรายการ ร้านที่มีสินค้า 10,000 รายการจึงต้องดูแลโมเดล 10,000 ตัว และเมื่อได้ตัวเลขพยากรณ์แล้ว การแปลงเป็นใบสั่งซื้อก็ยังพึ่งกฎที่คนใส่ในสเปรดชีตซึ่งแต่ละคนใช้ไม่เหมือนกัน

พยากรณ์แบบ zero-shot คืออะไร

สถาปัตยกรรมนี้ใช้ Amazon Chronos2 ซึ่งเป็นโมเดล transformer ที่ฝึกกับข้อมูลอนุกรมเวลาจริงหลากหลายรูปแบบไว้ล่วงหน้า คำว่า zero-shot หมายความว่าใช้พยากรณ์สินค้าใหม่ได้ทันทีโดยไม่ต้องฝึกโมเดลเพิ่ม เพียงส่งประวัติยอดขายเข้าไป โมเดลก็เรียนรู้รูปแบบจากข้อมูลที่ได้รับในครั้งนั้นเอง นอกจากนี้ยังรับข้อมูลประกอบ (covariate) ได้ เช่น ช่วงโปรโมชัน การเปลี่ยนราคา และวันในสัปดาห์

จุดที่สำคัญต่อการสั่งซื้อคือผลลัพธ์เป็นแบบความน่าจะเป็น โมเดลให้ค่า P10, P50 และ P90 ซึ่งหมายถึงยอดขายที่มีโอกาสต่ำกว่าค่านั้น 10, 50 และ 90 เปอร์เซ็นต์ตามลำดับ ช่วงห่างระหว่าง P50 กับ P90 จึงบอกความไม่แน่นอน และนำไปคำนวณสต็อกสำรอง (safety stock) ตามระดับความเสี่ยงที่ธุรกิจยอมรับได้

เอเจนต์สี่ตัว หน้าที่ไม่ทับกัน

• Supervisor ตีความคำขอภาษาธรรมชาติ ควบคุมลำดับงาน และจัดการการลองใหม่เมื่อผลลัพธ์ชนข้อจำกัด
• Preprocessing โหลดข้อมูลยอดขาย สต็อก และค่าตั้งสินค้า แล้วตัดสินว่าจะใช้ข้อมูลประกอบตัวใดตามคุณภาพข้อมูล
• Forecasting เรียก Chronos2 ตีความความผิดปกติ คำนวณจำนวนสั่งซื้อด้วยสูตรตายตัว และตรวจข้อจำกัด
• Reporting สร้างกราฟพยากรณ์ บันทึกการตัดสินใจ และเขียนสรุปสำหรับฝ่ายธุรกิจ

เอเจนต์แต่ละตัวส่งผลลัพธ์เป็น JSON ที่กำหนดโครงสร้างไว้ให้ตัวถัดไป ไม่ใช่ข้อความอิสระ ข้อดีคือตรวจย้อนได้ว่าแต่ละขั้นตัดสินใจอะไร และแต่ละตัวใช้ context เท่าที่จำเป็น บทความประเมินขนาดไว้ที่ราว 2,000 token สำหรับ Supervisor, 5,000 สำหรับ Preprocessing, 3,000 สำหรับ Forecasting และ 2,000 สำหรับ Reporting ต่างจากการใช้เอเจนต์ตัวเดียวแบกข้อมูลดิบทั้งหมด ซึ่ง context จะโตตามจำนวนสินค้าไปเรื่อย ๆ

AI ตัดสิน โค้ดคำนวณ

หลักออกแบบที่บทความเน้นคือ LLM รับหน้าที่ใช้วิจารณญาณ ส่วนเครื่องมือแบบกำหนดผลตายตัวรับหน้าที่คำนวณ ตัวอย่างคือจำนวนสั่งซื้อคำนวณจากสูตร max(0, ความต้องการช่วงรอของ + สต็อกสำรอง - สต็อกปัจจุบัน) และมีจำนวนสั่งขั้นต่ำกำกับ สูตรนี้ถูกเขียนเป็นเครื่องมือ ไม่ปล่อยให้โมเดลภาษาคิดเลขเอง ขณะที่การตีความว่า "สุดสัปดาห์นี้มีโปรโมชัน" ควรส่งผลต่อการพยากรณ์อย่างไร เป็นงานของเอเจนต์

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

เครื่องมือตัวไหนต้องผ่านด่านตรวจสิทธิ์

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

เครื่องมือที่ผ่าน Gateway ถูกกำกับด้วยนโยบายภาษา Cedar ตัวอย่างในบทความคืออนุญาตให้บันทึกการตัดสินใจได้เฉพาะตัวตนของขั้นตอน Reporting และปฏิเสธการบันทึกทุกครั้งที่ใช้งบเกิน 50,000 ดอลลาร์ ส่วน Supervisor ซึ่งตีความคำขอและตัดสินทางแยก ทำงานหลัง Amazon Bedrock Guardrails ที่กรองเนื้อหาและตรวจว่าคำตอบอิงผลลัพธ์จากเครื่องมือจริง

เมื่อข้อจำกัดชนกัน ต้องถามคน

ตัวอย่างที่บทความยกมาคือระบบแนะนำให้สั่งซื้อมูลค่า 9,412.50 ดอลลาร์ แต่งบที่ตั้งไว้คือ 500 ดอลลาร์ ระบบไม่ตัดจำนวนสั่งให้พอดีงบแบบเงียบ ๆ ซึ่งจะทำให้ของขาดครั้งใหญ่ แต่ Supervisor เสนอทางเลือกสามทางให้ผู้ใช้ตัดสิน คือเพิ่มงบ ยอมรับของขาดแล้วเร่งการส่งของ หรือเลื่อนโปรโมชันออกไป ก่อนถึงจุดนั้นระบบลองปรับพารามิเตอร์แล้วคำนวณใหม่ได้สูงสุด 3 รอบ

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

วัดผลสองชั้น เพราะความผิดพลาดมีสองแบบ

ชั้นแรกวัดความแม่นของการพยากรณ์ด้วยโค้ด โดยใช้ WAPE หรือความคลาดเคลื่อนสัมบูรณ์ถ่วงน้ำหนักเป็นเปอร์เซ็นต์ของยอดขายจริง ผลกับสินค้า 50 รายการในช่วง 4 สัปดาห์ได้ค่ามัธยฐาน 12.3 เปอร์เซ็นต์ เกณฑ์ที่ตั้งไว้คือต่ำกว่า 15 เปอร์เซ็นต์ถือว่าแม่น ต่ำกว่า 25 เปอร์เซ็นต์ถือว่ารับได้ และตั้งเป้าให้ยอดขายจริงตกอยู่ในช่วง P10 ถึง P90 ราว 75 ถึง 85 เปอร์เซ็นต์ของเวลา

ชั้นที่สองวัดพฤติกรรมด้วย LLM ที่ทำหน้าที่เป็นผู้ตัดสิน ให้คะแนน 1 เมื่อระบบละเมิดข้อจำกัดโดยไม่บอก 2 เมื่อละเมิดแต่แจ้งผู้ใช้ และ 3 เมื่อทำตามข้อจำกัดครบ โดยตั้งเป้าให้ได้ 2 ขึ้นไปใน 95 เปอร์เซ็นต์ของการใช้งาน เหตุผลที่ต้องมีสองชั้นคือ ระบบอาจทำตัวถูกต้องแต่พยากรณ์ผิด หรือพยากรณ์แม่นแต่ละเมิดข้อจำกัดเงียบ ๆ ชั้นเดียวจับได้ไม่ครบทั้งสองกรณี

บทเรียนสำหรับธุรกิจไทย

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

ทีมงาน Smart Cyber Tech รับเขียนโปรแกรมและพัฒนาซอฟต์แวร์สั่งทำ รวมถึงระบบ ERP ที่เชื่อมข้อมูลคลังสินค้าเข้ากับการพยากรณ์และการอนุมัติของคน โดยออกแบบให้ AI ช่วยในจุดที่คุ้มค่าและตรวจสอบย้อนหลังได้ทุกขั้น ปรึกษาได้ที่ แบบฟอร์มติดต่อ