จาก Prototype สู่ Production: อะไรทำให้ AI Project ไม่จบแค่ Demo

Prototype ที่ตอบคำถามตัวอย่างได้หนึ่งครั้งมีคุณค่า มันช่วยให้ทีมเห็นภาพและค้นพบคำถามใหม่ แต่ prototype ยังไม่ใช่ production เพียงเพราะ model ตอบดีหรือ demo ดูน่าประทับใจ

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

Production readiness เป็นหลายมิติที่ต้องตรวจร่วมกัน

Problem framingใครตัดสินใจอะไร และผลกระทบอยู่ตรงไหน

Data qualityfreshness · schema · owner · permission

Workflow boundariesstate · validation · timeout · stop condition

Evaluationsuccess · refusal · evidence · real cases

Observabilitytrace · retrieval · tool · outcome

Securityleast privilege · side effects · audit trail

Human oversightfallback · escalation · accountable owner

Production readiness เป็นวงจรใช้มิติเหล่านี้ตรวจ ทดสอบ และย้อนกลับมาปรับเมื่อหลักฐานจากการใช้งานจริงเปลี่ยน

เริ่มจากปัญหาและผลกระทบ

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

ถ้าผลลัพธ์ไม่ได้เปลี่ยนการตัดสินใจ การเพิ่ม model อาจเป็นเพียงการเพิ่มความซับซ้อน

ทำให้ข้อมูลและหลักฐานตรวจได้

ข้อมูลต้องมี owner, freshness, schema และ permission ที่ชัด คำตอบที่ดีควรบอกได้ว่ามาจาก source ใด และเมื่อไรควรถือว่าหลักฐานหมดอายุ

ถ้า context ว่างหรือขัดแย้ง ระบบควรมีทางเลือกในการไม่ตอบหรือส่งต่อ ไม่ควรปล่อยให้ภาษาเติมช่องว่างแทนข้อมูล

ออกแบบ workflow ไม่ใช่แค่ prompt

แยก deterministic step เช่น validation, permission และ side-effect control ออกจาก probabilistic step เช่น classification หรือ summarization กำหนด retry budget, timeout, state และ stop condition ให้เห็นตั้งแต่ต้น

workflow ที่อ่านง่ายมักดูธรรมดา แต่ความธรรมดานี้ช่วยให้ทีมทดสอบและแก้ปัญหาได้

ประเมินกรณีที่ควรตอบและไม่ควรตอบ

ชุด evaluation ควรมีคำถามจริง ตัวอย่างที่ข้อมูลไม่พอ source ขัดแย้ง และผู้ใช้ไม่มีสิทธิ์เห็นข้อมูล รวมถึงตรวจเส้นทาง retrieval, tool call, evidence และ output ไม่ใช่ดูคำตอบสุดท้ายอย่างเดียว

การเพิ่มคะแนนเฉลี่ยโดยทำให้ระบบกล้าตอบทุกเรื่องอาจเป็น regression ถ้าระบบควรยอมรับว่าไม่รู้ในบางกรณี

ทำให้ความผิดพลาดมองเห็น

เก็บสัญญาณที่ช่วยอธิบาย workflow: latency, token, tool calls, retrieval quality, validation, source age, escalation และ drift โดยปกป้องข้อมูลส่วนตัวด้วยการ redact และกำหนด retention

ระบบที่มี error rate เป็นศูนย์แต่ไม่มี evidence หรือ trace อาจไม่ได้ reliable ขึ้น แต่อาจกำลังซ่อน failure ที่นิยามไม่ดี

กำหนด security และ permission เป็น boundary

อย่าให้ model เป็นผู้ตัดสินสิทธิ์ และอย่าให้ agent มี tool access กว้างกว่าที่งานต้องใช้ คำสั่งที่มี side effect ควรมี idempotency, audit trail และ approval ตาม risk

การรักษาความปลอดภัยไม่ใช่ขั้นตอนท้ายสุดก่อน deploy เพราะ permission ที่ออกแบบผิดจะเปลี่ยนความหมายของทั้ง workflow

วาง human oversight และความเรียบง่าย

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

และเมื่อมีทางเลือกสองแบบที่ให้ผลใกล้กัน ให้เลือกแบบที่มี component, state และ dependency น้อยกว่า ความเรียบง่ายเป็น operational advantage ไม่ใช่การลดความสามารถแบบน่าเสียดาย

Checklist ก่อนเรียกตัวเองว่า production

[ ] ปัญหาและผู้รับผลกระทบชัด
[ ] ข้อมูลมี freshness, schema, owner และ permission
[ ] workflow มี validation, timeout, retry และ stop condition
[ ] evaluation ครอบคลุม success, refusal และ evidence
[ ] trace อธิบาย retrieval, model, tool และ outcome ได้
[ ] side effect มี security boundary และ audit trail
[ ] human fallback มีเหตุผลและ owner รับช่วงต่อ

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

คำถามสุดท้ายก่อนเปิดใช้จริง

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

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

คำตอบของคำถามนี้มักบอกความพร้อมของระบบได้มากกว่าคำตอบจาก demo ที่ดีที่สุด

สิ่งที่ควรจำมีสามข้อ:

1. production readiness เริ่มจากปัญหา ข้อมูล และผลกระทบ ไม่ใช่จากชื่อ model หรือจำนวน agent
2. workflow ที่มี evidence, observability, security boundary และ human fallback ทำให้ failure จัดการได้
3. ความเรียบง่ายที่ทีมอธิบาย ทดสอบ และกู้คืนได้ คือคุณสมบัติของระบบที่พร้อมใช้งานจริง

References

• NIST — AI Risk Management Framework (2023): กรอบ govern, map, measure และ manage สำหรับความเสี่ยง AI
• Google for Developers — Production ML systems: Monitoring pipelines: data validation, live quality และ monitoring ใน production
• OWASP GenAI Security Project — Securing Agentic Applications Guide 1.0 (2025): security boundary และแนวทางลดความเสี่ยงของ agentic workflows
• OpenTelemetry — GenAI semantic conventions: โครงสร้าง trace และ metrics สำหรับ model, agent และ tool-adjacent operations
• Anthropic — Building effective agents (2024): เหตุผลที่ควรเริ่มจากระบบเรียบง่ายและเพิ่ม autonomy เมื่อจำเป็น