AI ในโปรดักชันคืออะไร และทำไมโมเดลถึงเป็นแค่ส่วนง่ายที่สุด
AI ในโปรดักชันคือการนำโมเดลปัญญาประดิษฐ์ที่เคยอยู่ในขั้นทดลองหรือเดโม ไปเชื่อมต่อกับระบบจริง ผู้ใช้จริง และข้อมูลจริง โดยต้องรับมือกับประเด็นด้าน latency ความสม่ำเสมอของผลลัพธ์ การจัดการคอนเท็กซ์ ความปลอดภัย ค่าโครงสร้างพื้นฐาน และเหตุขัดข้องที่มีผลต่อผู้ใช้จำนวนมาก ไม่ใช่แค่การทดสอบบนเบนช์มาร์กในสภาพแวดล้อมที่ควบคุมได้ ความเห็นตรงไปตรงมาคือ ทุกวันนี้ตัวโมเดลกลับกลายเป็นส่วนที่เปลี่ยนง่ายที่สุดในระบบ AI production deployment เราสามารถสลับผู้ให้บริการหรือรุ่นโมเดลได้ค่อนข้างเร็ว แต่สิ่งที่พังเมื่อมีผู้ใช้จริงคือโครงสร้างพื้นฐานลึกๆ ตั้งแต่ระบบจัดเส้นทางคำขอ โมเดลไหนรับเคสไหน ไปจนถึง memory layer ที่ต้องจำและดึงข้อมูลส่วนตัวกลับมาอย่างแม่นยำ และระบบ moderation ที่ต้องป้องกันไม่ให้เนื้อหาหลุดออกไปสร้างปัญหาในโลกจริง เมื่อผู้ใช้จำนวนมากเริ่มใช้งาน ปัญหาเล็กๆ ในเดโมจะขยายตัวอย่างทวีคูณ ความหน่วงเพียงเล็กน้อยกลายเป็นปัญหาประสบการณ์ผู้ใช้ ความผิดพลาดที่เกิดนานๆ ครั้งกลายเป็นพันเคสต่อวัน และคอนเท็กซ์ที่ยาวเกินจำเป็นกลายเป็นต้นทุนโครงสร้างพื้นฐานที่บานปลาย
การจัดเส้นทางโมเดล ความจำ และ latency: สิ่งที่ทีมส่วนใหญ่คิดช้าไปหนึ่งก้าว
เมื่อระบบยังอยู่ในห้องทดลอง นักพัฒนามักถามกันว่าโมเดลไหนคะแนนดีสุด แต่เมื่อเข้าสู่ AI production deployment คำถามสำคัญย้ายไปที่ model routing การจัดการความจำ และ model latency optimization ว่าระบบตอบสนองเร็วพอสำหรับผู้ใช้หรือไม่ ในระบบจริงหนึ่งคำตอบอาจต้องผ่านตัวจัดประเภท intent เลือกเวิร์กโฟลว์และโมเดลที่เหมาะสม ดึงประวัติจาก memory layer ตรวจ moderation เรียกเครื่องมือภายนอก และประมวลผลต่อ ทุกขั้นเป็น latency สะสมที่อาจทำให้ผู้ใช้รู้สึกว่า AI “ฉลาดน้อยลง” เมื่อรอคำตอบนานเกินไป มุมหนึ่งที่มักถูกมองข้ามคือ memory management ในระบบสนทนาอย่าง MyAnima ซึ่งให้บริการผู้ใช้หลายพันรายต่อวัน ทีมต้องคิดเป็น pipeline ตั้งแต่การสกัดข้อมูล การแทนข้อมูล การจัดอันดับ การดึงกลับมารวมเข้า context และแก้ความขัดแย้งของข้อมูล ก่อนใส่เข้าโมเดล ถ้าระบบลืมความชอบสำคัญ หรือดึงข้อมูลไม่ตรงสถานการณ์ การสนทนาจะหลุดโทนและเสียความต่อเนื่องทันที ในระดับโปรดักชัน การ optimize latency จึงไม่ใช่แค่เปลี่ยนไปใช้โมเดลเร็วขึ้น แต่ต้องออกแบบทั้งระบบใหม่ เช่น ทำงานบางส่วนแบบขนาน ใช้ prefix caching ลดการประมวลผลซ้ำ ย่อคอนเท็กซ์ หรือแม้แต่ตัดขั้นตอนที่ไม่จำเป็นต้องเรียก LLM ออกไปเลย
ค่าโครงสร้างพื้นฐานและเฟรมเวิร์กประเมินผล: ปัญหาที่โผล่เมื่อเริ่ม scale
ในเดโม เราสามารถใช้โมเดลใหญ่สุด แพงสุด โดยไม่รู้สึกอะไร แต่เมื่อ AI production deployment มีผู้ใช้จำนวนมาก enterprise AI costs จะกลายเป็นปัญหาหลักทันที ทีมหนึ่งเล่าชัดเจนว่า เมื่อระบบที่ใช้โมเดลคลาวด์ยอดนิยมกลายเป็นที่นิยมจนมีผู้ใช้ระดับหลักล้าน ทุกคำถามของผู้ใช้คือค่า inference ที่ต้องจ่าย กลายเป็นการเป็นเหยื่อของความสำเร็จของตัวเอง ในระบบสนทนา คอนเท็กซ์ที่ยาวโดยไม่จำเป็นไม่ใช่แค่ช้า แต่ยังกลายเป็นต้นทุนโครงสร้างพื้นฐานที่สูงขึ้นตามปริมาณคำขอ ข้อผิดพลาดเชิงกลยุทธ์คือการทุ่มเวลาหลายสัปดาห์เพื่อเปรียบเทียบโมเดล โดยไม่แตะสถาปัตยกรรมระบบที่มีผลต่อผู้ใช้มากกว่า โมเดลที่คะแนนดีในเบนช์มาร์กอาจเป็นตัวเลือกที่ผิดในโปรดักชัน ถ้ามันช้าเกินไป แพงเกินไป ไม่เสถียรกับโหลดจริง หรือดูแลด้าน moderation ยาก สิ่งที่จำเป็นคือเฟรมเวิร์กประเมินผลเป็นชั้นๆ ทั้งเทสแบบ deterministic สำหรับพฤติกรรมเชิงโครงสร้าง ชุดสนทนาทดสอบ regression แบบคัดเลือกเพื่อจับข้อผิดพลาดซ้ำๆ การรีวิวโดยมนุษย์สำหรับเคสคลุมเครือ และการใช้โมเดลช่วยประเมินคุณภาพในระดับกว้างแต่ต้อง calibrate อย่างระมัดระวัง
ทำไมการรัน AI ที่ขอบเครือข่ายจึงน่าคิดกว่าแค่โยนทุกอย่างขึ้นคลาวด์
โลกการพัฒนาแอปในวันนี้มักเลือกคลาวด์เป็นค่าเริ่มต้น เพราะง่าย โมเดลแรง และเป็นทางที่มีแรงต้านน้อยที่สุด แต่การคิดแค่คลาวด์ทำให้มองข้าม edge computing AI ที่รันโมเดลใกล้ผู้ใช้หรือบนเครื่องผู้ใช้เอง การรัน AI บนเซิร์ฟเวอร์มีด้านลบทั้งเรื่องความเป็นส่วนตัว สถานะอินเทอร์เน็ตต่ำหรือไม่มีเลย และข้อจำกัดเชิงเทคนิคบางอย่าง เช่น การแคชแบบ same-origin ในเบราว์เซอร์ที่ทำให้การใช้ทรัพยากรซ้ำทำได้ยาก ในหลายประเทศสัญญาณ WiFi ยังขาดๆ หายๆ ผู้ใช้ไม่ควรถูกบังคับให้มีอินเทอร์เน็ตตลอดเวลาเพื่อคุยกับ AI กลยุทธ์หนึ่งที่น่าสนคือการให้ผู้ใช้ “นำ AI มาเอง” ผ่านโมเดลที่รันบน WebGPU ในเบราว์เซอร์ เช่น แกนคิดของ WebLLM ที่ช่วยให้ inference เกิดบนเครื่องผู้ใช้ ลดการพึ่งพาคลาวด์และลดความซับซ้อนด้านปฏิบัติการ มีตัวอย่างแอปแบบ Electron ที่ใช้ HTML และ JavaScript ใน React เชื่อมกับโมเดลที่รันบน Apple Neural Engine ผสมโมเดลโลคัลหลายตัวเพื่อทำงานจริงบนขอบเครือข่าย เมื่อโมเดลขยับมาใกล้ผู้ใช้มากขึ้น latency ลดลง ความเป็นส่วนตัวดีขึ้น และต้นทุนคลาวด์ไม่บานไปตามจำนวนผู้ใช้
สถาปัตยกรรมข้อมูลองค์กร: สมรภูมิจริงของ AI เอเจนต์ระยะยาว
ในระดับองค์กร ปัญหาใหญ่ไม่ใช่ไม่มีข้อมูล แต่คือมีข้อมูลมากเกินไปและไม่มีส่วนไหนถูกเตรียมให้ AI agents เข้าถึงได้ ระบบหนึ่งที่ให้บริการโซลูชันองค์กรมานานกว่า 40 ปีบอกว่า ประมาณหนึ่งในสี่ของจีดีพีประเทศหนึ่งวิ่งผ่านระบบของเขา และเศรษฐกิจประเทศนั้นอยู่ในอันดับสิบของโลก แต่เมื่อเริ่มสร้าง AI agents ปัญหาคือข้อมูลในระบบทรานแซคชันถูกออกแบบมาเพื่อแอปดั้งเดิม ข้อมูลใน data lake ถูกออกแบบมาเพื่อทีมวิเคราะห์และแดชบอร์ด ไม่ใช่เพื่อ reasoning loop ที่หิวโทเคน แพ้ latency และสามารถยิงคำถามไม่คาดคิดเป็นร้อยคำถามในไม่กี่นาที คำถามสำคัญจึงไม่ใช่ว่าจะใช้ deterministic หรือ non-deterministic แต่คือจะขีดเส้นตรงไหนว่าฟังก์ชันใดต้องถูกดูแลโดยระบบเชิงกำหนดที่คาดเดาได้สูง และฟังก์ชันใดส่งให้ LLM ที่มีความเป็นความน่าจะเป็นดูแล โดยมีตัวแปรสามอย่างเป็นแกนคิดคือ precision ความปลอดภัย และต้นทุน ซึ่งทั้งหมดขึ้นกับวิธีที่องค์กรเตรียมและส่งข้อมูลเข้าไปในเอเจนต์ ประเด็นที่ไม่ควรมองข้ามคือระบบองค์กรคุ้นเคยกับความแม่นยำระดับ 99.99 ในทรานแซคชัน แต่เมื่อใช้ AI ผลลัพธ์จะไม่มีวันนิ่งขนาดนั้น ผู้ใช้ต้องถูกออกแบบให้รับมือกับความไม่แน่นอน และทีมต้องจัดสมดุลระหว่างระบบเดิมที่แม่นยำกับเอเจนต์ที่ยืดหยุ่นแต่ไม่กำหนดตายตัว
