ZestBuyZestBuy

ทำไม AI Coding Agent พังในโปรดักชัน และสถาปัตยกรรมแบบไหนที่เอาอยู่

ทำไม AI Coding Agent พังในโปรดักชัน และสถาปัตยกรรมแบบไหนที่เอาอยู่
ความสนใจ|ซอฟต์แวร์คุณภาพดี

บทเรียนแรก: ปัญหาไม่ได้อยู่ที่โมเดล แต่อยู่ที่สถาปัตยกรรม

AI workflow คือลำดับของหลายขั้นตอนที่เชื่อมต่อกันเพื่อทำภารกิจหนึ่งให้เสร็จ โดยอย่างน้อยหนึ่งขั้นตอนเป็นการเรียกใช้ large language model (LLM) เพื่อประมวลผลหรือสร้างผลลัพธ์. ในห้องแล็บ เรามักตื่นเต้นเมื่อ agent ทำงานครบขั้นตอนครั้งแรก จากนั้นพอทำซ้ำได้ก็คิดว่า “พร้อมโปรดักชันแล้ว” แต่เมื่อปล่อยให้รันนับร้อย นับพันครั้ง ภาพจริงเริ่มปรากฏ: การตัดสินใจไม่คงเส้นคงวา เครื่องมือบางตัว timeout การค้นคืนข้อมูลเริ่มแย่ คอนเท็กซ์ปนเปื้อน ความหน่วงแหลมแบบเดายาก และ workflow แบบ multi-agent เกิด deadlock ใต้โหลด. สิ่งเหล่านี้ไม่ใช่เพราะเลือกโมเดลผิด แต่เป็นช่องโหว่ด้านสถาปัตยกรรมล้วนๆ. การกระโดดจากดีโมไปสู่โปรดักชันจึงไม่ใช่เรื่อง “ความฉลาดของ AI” เท่ากับ “ความเป็นระบบของสถาปัตยกรรม” ที่รองรับโลกจริง.

ทำไม AI Coding Agent พังในโปรดักชัน และสถาปัตยกรรมแบบไหนที่เอาอยู่

AI agents production reliability: ทำไมดีโมถึงไม่เท่ากับโปรดักชัน

ดีโมของ agent มักรันในสภาพแวดล้อมที่ควบคุมได้: API ตอบตามคาด คอนเท็กซ์เล็ก เครื่องมือพร้อมใช้ เซสชันสั้น และรูปแบบการโต้ตอบค่อนข้างคงที่. แต่ในโปรดักชัน agent ตัวเดียวอาจต้องตอบลูกค้านับพันพร้อมกัน หรือ workflow วิจัยอาจต้องเรียก API ภายนอกหลายสิบครั้งในหนึ่งรอบ. ฐานความรู้ก็เปลี่ยนตลอด ทำให้ retrieval แปรผัน และแต่ละ dependency เพิ่มโหมดการล้มเหลวใหม่เข้าไป. การพยายาม “แก้เอาทีหลัง” ด้วยการเพิ่ม retry dashboard หรือปรับ prompt จึงเท่ากับซ่อมผิวหน้า ระบบยังเปราะ เพราะความน่าเชื่อถือไม่ได้เป็นชั้นเคลือบ แต่คือคุณสมบัติหลักของสถาปัตยกรรม. ทีมที่พา agent เข้าสู่โปรดักชันได้เร็วคือทีมที่มอง orchestration การจัดการ state และ observability เป็นพลเมืองชั้นหนึ่งในระบบ ไม่ใช่ของเสริมตอนท้าย.

บทเรียนจาก distributed systems: persistence, idempotency และ observability

AI agent ที่รันนานไม่ต่างจาก distributed system ที่ต้องอยู่รอดท่ามกลาง deploy, crash และการย้ายงานข้าม worker พวกมันต้องรอดจากการรีสตาร์ต รันซ้ำได้แบบ idempotent และสเกลแนวนอนอย่างปลอดภัย. Durable execution จึงบังคับให้บันทึกผลลัพธ์ของทุกขั้นก่อนจะไปขั้นถัดไป เพื่อให้ engine สามารถ replay ประวัติแล้วกลับมาทำต่อจากจุดเดิมเมื่อ process ล้ม หรือถูกย้ายไป worker อื่น ทำให้ state อยู่ได้นานกว่า process ใดๆ. โลก distributed machine learning แสดงให้เห็นชัดว่า การสเกลจาก GPU เดียวไปสู่หลายร้อยหรือหลายพัน GPU ทำให้ต้องเจอปัญหาเรื่องการซิงก์ ความทนทานต่อความล้มเหลว ภาระการสื่อสาร และการจัดการ state แบบใหม่. ทีมในสาย distributed systems จึงเรียนรู้มานานแล้วว่าความน่าเชื่อถือ ต้องมองในระดับทั้งระบบ ไม่ใช่แค่ที่ component เดียว และ agentic systems ต้องใช้ความเข้มงวดแบบเดียวกัน.

agentic systems architecture: แยก logic ออกจาก runtime เพื่อสเกลทั้งโปรดักชันและการประเมิน

AI workflow ต้องตอบสองโจทย์ที่ขัดแย้งกัน: โปรดักชันต้องใช้ runtime แบบหนักที่ persistent และกระจาย state เพื่อให้รอดจาก crash และ deploy ในขณะที่การประเมินคุณภาพ LLM ต้องการ loop ที่เบา รันใน process เดียว แบบทิ้งได้ ไม่ต้อง persist หรือกระจายงาน. การเอา eval ทั้งหมดไปรันผ่าน workflow engine คือการจับงานผิดหมวด เพราะคุณแบก persistence, task queue และ semantics ของการ replay ติดมา ทั้งที่ loop แค่ต้องเร็วและถูกแยก dependency. ทางออกคือเลิกเขียน orchestration ผูกกับ runtime ใด runtime หนึ่ง แล้วเขียน orchestration logic ให้เรียกผ่าน interface กลางที่ runtime แต่ละตัวมาเติมเต็มแทน. เมื่อ workflow เป็น business logic ที่ไม่รู้เลยว่าตัวเองรันอยู่ที่ไหน ก็สามารถใช้ runtime หนักในโปรดักชัน และ runtime เบาใน eval โดยที่ logic ชุดเดียวกันถูกใช้ทั้งสองฝั่ง.

Runtime-agnostic AI workflows: สะพานเชื่อมระหว่างความทนทานและความเร็วในการปรับปรุง

Workflow engine แบบดั้งเดิมออกแบบมาสำหรับงานระยะยาวในระบบกระจาย: บันทึกทุกขั้น เก็บ state ให้รอดจาก crash และสเกลแนวนอน. แต่ loop สำหรับปรับ prompt หรือ branching decision ต้องรันซ้ำได้ร้อยครั้งต่อชั่วโมงแบบเบาๆ รันในเครื่องเดียว ไม่ต้องตั้ง cluster หรือคิวงาน และมัก mock dependency เพื่อแยกผลของ LLM ที่กำลังประเมิน. เมื่อใช้ runtime เดียวตอบทั้งสองโจทย์ คุณต้องเลือกอย่างใดอย่างหนึ่ง: ได้ durability แต่เสียความเร็ว หรือได้ความเร็วแต่เสียความทนทาน. รูปแบบ runtime-agnostic จึงเสนอให้เขียน workflow เป็น business logic เพียวๆ ที่ไม่รู้เรื่อง runtime แล้ว plug runtime เข้าไปทีหลัง เพื่อให้ logic เดียวกันทำงานได้ทั้งในโปรดักชันและ eval. เมื่อมี logic แค่เวอร์ชันเดียว เวอร์ชันที่ผ่านการประเมินก็ตรงกับเวอร์ชันที่ถูกนำขึ้นโปรดักชัน ช่วยตัดบั๊กทั้งคลาสที่เกิดจาก logic สองเวอร์ชันค่อยๆ แยกทางกันในเวลา.

ZestBuy ได้รับค่าคอมมิชชั่นเมื่อคุณช้อปผ่านลิงก์ของเรา โดยคุณไม่ต้องจ่ายเพิ่ม

You May Also Like

Comments
พูดอะไรบางอย่าง...
ยังไม่มีความคิดเห็น มาเป็นคนแรกที่แบ่งปันความคิดเห็นของคุณ!