ช่องว่างก่อนโปรดักชัน: ทำไม 80% ของโครงการ AI ระดับองค์กรถึงไม่เคยขึ้นจริง

ในทุกฝ่าย IT ขององค์กรขนาดใหญ่ มี "สุสานโครงการ" ซ่อนอยู่ที่ไหนสักแห่ง

มันเต็มไปด้วยเดโมที่ทำให้กรรมการตื่นเต้นกันในปี 2024, RAG prototype ที่ตอบคำถามที่เลือกมาแล้วได้ดีกว่า ChatGPT, และ AI copilot ที่ดูทรงพลังในสภาพแวดล้อม sandbox จากนั้นมีคนถามคำถามที่ยากจริง — จะปล่อยให้พนักงาน 4,000 คนใช้ได้ไหม? เชื่อมกับ ERP ของเราได้ไหม? ใช้กับข้อมูลลูกค้าจริงภายใต้การ audit และข้อกำหนด PDPA ได้ไหม? — แล้วโครงการนั้นก็เงียบหายไปใน "เฟส 2"

เฟส 2 ไม่เคยเริ่ม

รายงานในอุตสาหกรรมประเมินอัตราล้มเหลวของโครงการ AI ระดับองค์กรไว้ราว 70–85% ตัวเลขของเราเอง หลังจากทำ architecture review และ system integration ในด้าน cybersecurity, ERP, การผลิต และ ecommerce มากว่า 10 ปี ก็อยู่ในระดับเดียวกัน — ประมาณ 4 ใน 5 โครงการที่ลูกค้าเรียกเราเข้าไปช่วยกู้ ตั้งแต่แรกเริ่มก็ไม่เคยมีเส้นทางจริงที่จะขึ้นโปรดักชันได้

โพสต์นี้คือคู่มือภาคสนามที่เราอยากให้ CTO ทุกคนได้อ่านก่อนเซ็น SOW

ช่องว่างก่อนโปรดักชัน คืออะไร

ช่องว่างก่อนโปรดักชัน (Production Gap) คือระยะห่างระหว่าง เดโมที่ทำงานได้ กับ ระบบที่ทีม operations ของคุณรันได้ตอนตี 3 วันอาทิตย์ ปัญหานี้ไม่ค่อยมาจากตัว model แต่มักเป็นเรื่องของ สถาปัตยกรรม, ข้อมูล, และการดำเนินงาน

flowchart TD
    A["เดโม<br/>เลือก input เอง, รันบนเครื่อง dev"] --> B["POC<br/>ข้อมูลชุดเดียว, ผู้ใช้คนเดียว, ไม่มี SLA"]
    B --> C["ช่องว่างก่อนโปรดักชัน<br/>จุดที่โครงการส่วนใหญ่ติด"]
    C --> D["Pilot<br/>ผู้ใช้จริง, ข้อมูลจริง, ยังไม่มี on-call"]
    D --> E["โปรดักชัน<br/>SLA, observability, audit trail"]
    E --> F["Operate<br/>คุมต้นทุน, model drift, change management"]
    C -.->|"โครงการส่วนใหญ่จบที่นี่"| G["สุสานโครงการ"]

การข้ามช่องว่างนี้ต้องตอบคำถามที่อึดอัด 7 ข้อ ซึ่งแต่ละข้อสะท้อนรูปแบบความล้มเหลวที่เราเห็นซ้ำๆ

รูปแบบ 1: ไม่มีใครนิยามว่า "ถูกต้อง" คืออะไร

โครงการ AI ส่วนใหญ่เริ่มต้นด้วย "ลองดูซิว่ามันทำอะไรได้บ้าง" หกเดือนต่อมา คณะกรรมการขอตัวเลข accuracy แล้วทีมก็ผลิตไม่ได้ — เพราะไม่เคยมี evaluation set ที่ label ไว้ มีแต่ prompt เดโมไม่กี่ตัว

อาการ: ทีมเถียงกันว่า model "ดีพอ" หรือยังโดยใช้ความรู้สึก
วิธีแก้: สร้าง evaluation set ก่อน model คำถามที่เป็นตัวแทน 200–500 ข้อ พร้อมคำตอบที่คาดหวัง ให้คะแนนต่อเนื่อง ถ้าไม่มี คุณจะไม่มีเข็มทิศ ถ้ามี การเปลี่ยน model, ปรับ prompt, หรือปรับ retrieval จะกลายเป็นการตัดสินใจทางวิศวกรรมที่วัดได้ แทนที่จะเป็นการถกเถียงเชิงศาสนา

รูปแบบ 2: Retrieval ถูกมองข้าม

ในระบบ RAG, LLM คือส่วนที่ราคาถูก คุณภาพ retrieval คือตัวระบบ แต่โครงการส่วนใหญ่กลับใช้งบ 90% ไปกับ prompt engineering และ 10% กับ embedding, chunking, และ indexing strategy

อาการ: Model hallucinate ในคำถามที่เอกสารต้นทางตอบไว้ชัดเจน
วิธีแก้: ปฏิบัติกับ retrieval แบบเป็น engineering problem ระดับ first-class ใช้ embedding model หลายภาษาที่แข็งแรงสำหรับ corpus ที่ต้องการ (ค่า default ของเราคือ multilingual-e5-large สำหรับข้อมูลภาษาไทย ญี่ปุ่น และจีน) ทำ chunking ตาม โครงสร้างเชิงความหมาย — section, ตาราง, หัวข้อ — ไม่ใช่ตาม window 512 token วัด recall@k ของ retrieval แยกจากคุณภาพคำตอบ end-to-end ถ้า recall@5 ต่ำกว่า 90% บน eval set ของคุณ ปรับ prompt อย่างไรก็ไม่ช่วย

รูปแบบ 3: Identity, สิทธิ์, และขอบเขตข้อมูล "ค่อยทำทีหลัง"

ข้อมูลองค์กรไม่ใช่ corpus เดียว มันคือ corpus เป็นพันชุด แต่ละชุดมี ACL ของตัวเอง และมีกฎเกณฑ์กำกับต่างกัน ผู้อำนวยการฝ่ายการเงินไม่ควรได้คำตอบเรื่อง HR ผู้รับเหมาไม่ควรเห็นบันทึกกรรมการบริหาร และทั้ง พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA), พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562, และแนวปฏิบัติ AI Governance ของ ETDA ก็มีข้อกำหนดที่เกี่ยวข้องโดยตรง

อาการ: เดโมทำงานสวยบน dataset ที่ flatten แล้ว ฝ่ายกฎหมายเห็น production design แล้วเบรกโครงการ
วิธีแก้: ฝัง row-level access control เข้าไปใน retrieval layer ไม่ใช่ application layer แท็ก chunk ทุกชิ้นตอน ingest ด้วย ACL ต้นทาง กรอง ณ เวลา query โดยใช้ identity ของผู้ใช้ ก่อนที่ LLM จะเห็นข้อมูล นี่ยากกว่าที่ฟัง และไม่ใช่เรื่องที่จะข้ามได้

รูปแบบ 4: ไม่มี observability, ไม่มี audit trail

ถ้าคุณบอกไม่ได้ว่าระบบตอบอะไรไปเมื่อวันอังคารเวลา 14:30 ในคำถามว่า "นโยบายคืนเงินคืออะไร" คุณไม่ได้มีระบบโปรดักชัน คุณมีภาระทางกฎหมาย

อาการ: ผู้ใช้ร้องเรียนว่า AI ให้ข้อมูลผิด ทีมทำซ้ำไม่ได้ สืบสวนไม่ได้ และเรียนรู้จากเหตุการณ์ไม่ได้
วิธีแก้: Log ทุก retrieval, ทุก prompt, ทุก completion, ทุกต้นทุน พร้อม trace ID ที่คงทนข้าม service เหมือนที่ทีม SOC จัดการ security event — เปลี่ยนแปลงไม่ได้, query ได้, เก็บตามระยะเวลาที่ระเบียบของคุณกำหนด เราใช้ pattern observability เดียวกันที่เราใช้ใน SIEM ingestion ของงาน soc-integrator ของเรา: structured log, OpenSearch index, retention หลายชั้น

รูปแบบ 5: Cost model เป็นแค่ความหวัง

โครงการที่รัน 50 query ต่อวันไม่มีต้นทุนอะไร เปลี่ยน architecture เดียวกันให้พนักงาน 4,000 คนใช้ คนละเฉลี่ย 30 query พร้อม context retrieval ขนาดใหญ่ แล้วทันใดนั้น bill LLM รายเดือนของคุณสูงกว่าเงินเดือนทั้งทีมที่สร้างมัน

อาการ: ฝ่ายการเงินตัด budget สองเดือนหลังเริ่ม rollout
วิธีแก้: Model ต้นทุนต่อ useful action ไม่ใช่ต่อ token ตั้งแต่วันแรก Cache ให้ก้าวร้าว ส่งคำถามง่ายไป model เล็ก/ถูก สงวน frontier model ไว้ให้คำถามที่ยากจริง บีบ context retrieval — โครงการส่วนใหญ่ส่ง context 8,000 token เพื่อตอบคำถามที่ต้องการ 800 token วัด แล้วค่อย optimize Cost engineering คือ engineering

รูปแบบ 6: สร้างผูกกับ LLM provider รายเดียว

Model ที่ชนะ bake-off ของคุณใน Q1 อาจไม่ใช่ตัวที่ถูกที่สุด เร็วที่สุด หรือแม้แต่ใช้ได้ใน Q4 Provider lock-in คือฆาตกรเงียบของการลงทุน AI ระยะหลายปี

อาการ: การเปลี่ยนแปลงราคาหรือปัญหา availability ในภูมิภาคบังคับให้ต้อง re-platform ฉุกเฉิน
วิธีแก้: Abstract model boundary ตั้งแต่แรก สร้าง gateway บางๆ ภายในที่มี interface คงที่, model routing rules, และ fallback chain เหมือนที่คุณไม่ hard-code payment provider เดียวเข้าไปใน checkout อย่า hard-code LLM ตัวเดียวเข้าไปใน knowledge product ต้นทุนเล็กตอนเริ่ม แต่มูลค่าของทางเลือกใหญ่มาก

รูปแบบ 7: ไม่มีใครเป็นเจ้าของหลัง launch

โครงการ pilot เป็นของทีม innovation ระบบโปรดักชันต้องมีเจ้าของที่มี on-call rotation, runbook, และ budget สำหรับ model drift, การ refresh evaluation, และการ re-index retrieval รายไตรมาส

อาการ: หกเดือนหลัง launch accuracy ค่อยๆ ลดลงเงียบๆ เพราะเอกสารต้นทางเปลี่ยนแต่ไม่มีใคร re-index
วิธีแก้: ตัดสินใจว่าใครจะรันระบบนี้ ก่อน ที่จะ ship ระบบ AI ต้องการวินัยปฏิบัติการเหมือน production service อื่น — SLO, change management, incident response — บวกอีกสองสามอย่างที่ใหม่ (eval set re-run, drift monitoring, prompt versioning) ถ้าองค์กรของคุณยังไม่มี capability นี้ ก็สร้างหรือซื้อมา อย่า ship ก่อนมีมัน

รูปแบบที่อยู่เบื้องหลังรูปแบบทั้งหมด

สังเกตว่าอะไรที่ ไม่ได้ อยู่ในรายการนี้: การเลือก model, fine-tuning, ยี่ห้อ vector database, การเลือก agent framework สิ่งเหล่านี้คือคำถามที่ทีมอยากเถียงกันเพราะมันสนุก แต่ 7 คำถามด้านบนคือสิ่งที่ตัดสินว่าการลงทุนของคุณจะคืนทุนหรือไม่ — และมันน่าเบื่อ เป็นเชิงปฏิบัติการ และเชิงสถาปัตยกรรม

นี่คือบทเรียนเดียวกับที่เราเรียนรู้จากการสร้าง SOC platform (ที่ SIEM คือส่วนที่ราคาถูก — detection engineering กับการ tune คือตัวระบบ) และ ERP integration (ที่ connector คือส่วนที่ราคาถูก — data contract กับ reconciliation คือตัวระบบ) เทคโนโลยีใหม่ แต่ฟิสิกส์เดิม

ถ้าเป็นปัญหาของเรา เราจะทำยังไง

แผนปฏิบัติ 90 วันจาก pilot สู่โปรดักชัน:

ไม่หรูหรา แต่มันได้ผล

Simplico เข้ามาตรงไหน

เราใช้เวลาหนึ่งทศวรรษที่ผ่านมาส่งมอบระบบโปรดักชันให้ลูกค้าทั่วประเทศไทย ญี่ปุ่น จีน และภูมิภาคเอเชียแปซิฟิก — SOC platform สำหรับโครงสร้างพื้นฐานสำคัญ, ERP integration สำหรับโรงงานผลิต, ระบบ ecommerce, และล่าสุดคือระบบ RAG และ agentic ที่สร้างด้วยมาตรฐานเดียวกัน

ถ้าคุณมีโครงการ pilot ที่ติด หรือไม่อยากสร้างโครงการที่จะติดในอนาคต เรายินดีเข้าไปดูให้

นัด architecture review ฟรี →

คอลล์ 90 นาทีกับ architect ของเรา เราจะ map สถานะปัจจุบัน บอกตรงๆ ว่ามี production gap ตรงไหน และทิ้งแผน rollout หนึ่งหน้าไว้ให้คุณ ไม่มี slideware

หรือทักเราตรงๆ ผ่าน LINE: @iiitum1984

Simplico คือสตูดิโอวิศวกรรมจากกรุงเทพฯ ที่เชี่ยวชาญด้าน AI/RAG, cybersecurity, ERP integration, ecommerce, และ mobile delivery เราทำงานกับทีมระดับองค์กรในตลาดไทย ญี่ปุ่น จีน และภาษาอังกฤษ