ออกแบบ AI workflows ให้ช่วยงานจริง แทนที่จะเป็นแค่ของตกแต่งโปรดักต์

เริ่มจากงานที่ต้องทำ ไม่ใช่เริ่มจากโมเดล

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

เลือก workflow ที่แคบที่สุดแต่เปลี่ยนผลลัพธ์ของงานได้ การวางกล่องแชตไว้ทุกหน้าอาจดูทันสมัย แต่ไม่ได้ช่วยให้งานเดินเร็วขึ้น ในทางกลับกัน ร่างข้อความที่ปรากฏก่อนขั้น review พอดีอาจลดเวลาทำงานได้โดยไม่แย่งสิทธิ์ตัดสินใจจากคน นิยามความสำเร็จด้วยภาษาของโปรดักต์ เช่น ลดการส่งต่องานที่ต้องทำมือ ทำให้ handoff ชัดขึ้น หรือทำให้ input ครบขึ้น ไม่ใช่เริ่มจากคะแนน benchmark ที่ผู้ใช้ไม่เคยสัมผัส

workflow runtime ในระบบนี้สะท้อนแนวคิดดังกล่าวได้ดี graph ที่บันทึกไว้จะถูก compile เป็นเส้นทางทำงานจาก manual, schedule หรือ webhook trigger ก่อนรัน ตัว compiler ปฏิเสธ ID ซ้ำ วงจร edge ที่ผิด branch ที่กำกวม และ target ที่ไปไม่ถึง นี่คือซอฟต์แวร์แบบกำหนดผลลัพธ์ได้กำลังตรวจโครงสร้างตามปกติ ส่วนที่ไม่แน่นอนไม่ควรมีสิทธิ์เปลี่ยนกติกาของกระบวนการ

ล้อมส่วนที่ไม่แน่นอนด้วยขอบเขตที่แน่นอน

มอง model call เป็นเพียงหนึ่งขั้นที่มีชนิดข้อมูลชัดเจน ไม่ใช่ระบบปฏิบัติการของทั้งฟีเจอร์ ให้โค้ดเป็นผู้กำหนด authentication, authorization, routing, deadline, เครื่องมือที่อนุญาต การบันทึกข้อมูล และ state transition ส่วนโมเดลมีหน้าที่เสนอเนื้อหาหรือตีความข้อมูลภายในกรอบนั้น

แต่ละขั้นควรมี contract ที่บอกให้ครบว่า:

• รับ input รูปแบบใดและใหญ่ได้แค่ไหน
• ต้องคืน output หน้าตาอย่างไร
• หมดเวลาและยกเลิกอย่างไร
• อนุญาต side effect แบบไหน
• prompt, schema และ workflow definition เป็นเวอร์ชันใด

execution runner ใน repository แสดงเหตุผลว่าทำไม version จึงสำคัญ เมื่อ worker รับงาน ระบบตรวจว่า workflow ไม่ได้เปลี่ยนหลังจากเข้าคิว และ stage ที่บันทึกไว้ยังตรงกับ graph ที่ compile แล้ว งานเก่าจะจบด้วยเหตุผลเฉพาะแทนการแอบรัน definition คนละชุด หลักเดียวกันใช้กับ prompt ได้ ถ้าไม่บันทึกว่า output ถูกสร้างจาก contract เวอร์ชันใด การแก้ปัญหาภายหลังแทบเป็นการเดา

side effect ควรผ่าน adapter ที่ตรวจสอบได้เสมอ หากข้อความที่สร้างขึ้นจะกลายเป็น HTTP request โค้ดต้องตรวจ method, URL, header, body และปลายทาง Credential ควรถูกอ้างอิงจากที่เก็บที่ป้องกันไว้ ไม่ฝังใน prompt หรือ graph ใน backend นี้ config ของ request จะปฏิเสธฟิลด์ที่ดูเหมือน secret, แยกขั้นตอน resolve credential, ปิดบังข้อมูลสำคัญก่อนบันทึก response และแทน output ที่ใหญ่เกินขอบเขตด้วย record ขนาดจำกัด กลไกเหล่านี้สำคัญกว่าการเขียน prompt ให้หวือหวา

ตรวจสอบเป็นหลายชั้น

Validation ไม่ใช่แค่ parse JSON หลังโมเดลตอบ ขั้นแรกต้องตรวจ input ของผู้ใช้ก่อนเสียเวลาเรียกโมเดล จากนั้นตรวจโครงสร้าง output, ฟิลด์บังคับ, enum, ความยาว และความสัมพันธ์ระหว่างข้อมูล สุดท้ายต้องตรวจ action ที่เสนอเทียบกับสถานะล่าสุดของโปรดักต์ คำตอบที่ syntax ถูกอาจอ้างถึง record ที่ลบไปแล้วหรือขัดกับ business rule ก็ได้

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

งานที่มีผลกระทบสูงควรให้โมเดลสร้างข้อเสนอ ไม่ใช่ลงมือทันที หน้าจอ review ต้องแสดงบริบทต้นทาง ผลลัพธ์ที่เสนอ warning จาก validation และบอกชัดว่ากดอนุมัติแล้วจะเกิด action ใด ผู้ตรวจควรแก้ไข อนุมัติ ปฏิเสธ หรือขอร่างใหม่ได้ ปุ่มยืนยันที่โผล่มาหลังระบบทำสิ่งสำคัญไปเกือบหมดแล้วไม่ถือเป็น human checkpoint

ออกแบบ failure ให้เป็นผลลัพธ์ชนิดหนึ่ง

Provider อาจ timeout, structured output อาจเปลี่ยนรูป, dependency อาจล้ม, worker อาจ restart และผู้ใช้อาจกดยกเลิก ทุกกรณีต้องมี error code ที่คงที่ ข้อความที่ปลอดภัย และ state transition ที่ระบุไว้ แยก transport failure ที่ retry ได้ออกจาก input ผิดหรือ policy ไม่ผ่าน และ retry เฉพาะ operation ที่ idempotent หรือมี idempotency key ป้องกัน

workflow runner แยกสถานะ execution เป็น queued, running, completed, failed, cancellation-requested และ cancelled โดยแต่ละ stage มีสถานะของตัวเอง หาก worker กลับมารับ lease หลัง external request อาจถูกส่งไปแล้ว ระบบจะหยุดแทนที่จะเสี่ยงทำ side effect ซ้ำ นี่เป็นจุดยืนที่ถูกต้อง ความไม่แน่ใจว่า write สำเร็จหรือยังไม่ใช่ใบอนุญาตให้ยิงซ้ำ

Fallback ที่ดีต้องรักษางานหลักไว้ ผู้ใช้ควรทำต่อด้วยมือ บันทึกร่าง หรือ retry เฉพาะขั้นที่พังได้ อย่าทำให้โปรดักต์ทั้งชิ้นใช้ไม่ได้เพราะโมเดลล่ม หาก AI เป็นตัวเร่งที่เลือกใช้ได้ เส้นทางที่ไม่พึ่ง AI ก็เป็นส่วนหนึ่งของฟีเจอร์ ไม่ใช่หนี้ทางเทคนิค

สังเกตทั้ง workflow ไม่ใช่ดูแค่ endpoint

HTTP 200 ไม่ได้บอกว่าผลลัพธ์มีคุณภาพ ควรตาม trace ตั้งแต่ workflow, execution, stage, model request, validation, review จนถึง action สุดท้าย ข้อมูลที่ควรมีได้แก่ version ของ workflow และ prompt, model ที่ใช้, เวลาในคิว, เวลาสร้างคำตอบ, ผล validation, จำนวน retry, การยกเลิก และสถานะสุดท้าย หลีกเลี่ยงการ log prompt หรือ output ดิบเมื่ออาจมีข้อมูลส่วนตัว ใช้ event แบบมีโครงสร้างและผ่านการปิดบังข้อมูลแล้ว

backend นี้เก็บ execution stage และ audit record พร้อมแยก public projection ที่ sanitize แล้วออกจากรายละเอียดสำหรับผู้มีสิทธิ์ SSE ส่ง snapshot เมื่อสถานะเปลี่ยน แต่ตัด input, output, metadata และรายละเอียด error ของ stage ออกจากมุมมองสาธารณะ นี่คือเส้นแบ่ง observability ที่เหมาะสม ฝ่ายปฏิบัติการต้องมีหลักฐานพอแก้ปัญหา ส่วน progress indicator สาธารณะต้องการข้อมูลน้อยกว่ามาก

อ่าน trace ในฐานะหลักฐานของโปรดักต์ด้วย ผู้ใช้แก้ร่างหนักตรงไหน กฎ validation ใดพังซ้ำ ขั้นใดกินเวลามากที่สุด workflow ที่ technically complete แต่ถูกทิ้งเป็นประจำไม่ถือว่าทำงานดี

ตั้งงบ latency และ cost ก่อนเปิดใช้

ทุก model step ใช้ทั้งเวลาและเงิน รวมถึง retry และ validation call ด้วย ตั้งงบต่อหนึ่ง user action ไม่ใช่ต่อ API request เท่านั้น นับตั้งแต่การประกอบ context, model call, tool call, retry, storage ไปจนถึงเวลาที่คนใช้ review เลือกโมเดลเล็กที่สุดที่ทำตาม contract ได้ ลด context ให้เหลือหลักฐานที่เกี่ยวข้อง cache ข้อมูลอนุพันธ์ที่ไม่เปลี่ยนบ่อย และรันงาน deterministic ที่ไม่พึ่งกันแบบขนาน

Latency ต้องสะท้อนใน UI งาน classify ที่เร็วอาจอยู่ inline แต่งานร่างที่นานควรเป็น job ชัดเจน มี progress, cancel และกลับมาทำต่อได้ Streaming ช่วยให้รู้สึกตอบสนองเร็วขึ้น แต่ไม่ได้แก้ workflow ที่ช้าหรือไม่น่าเชื่อถือ ทุก network step ต้องมี deadline ตัวอย่างเช่น HTTP node ของ Studio ตรวจ timeout ที่กำหนดได้และแยก error แบบ timeout ออกจาก transport failure

รู้ด้วยว่าเมื่อไรไม่ควรใช้ AI

อย่าใช้โมเดลเมื่อ rule, query, template หรือ search ปกติให้คำตอบที่น่าเชื่อถือกว่า หลีกเลี่ยง AI สำหรับเลขคำนวณที่ต้องตรง permission check, canonical ID, การตัดสินใจย้อนกลับไม่ได้ และงานที่ไม่มีทาง review หรือ rollback รวมถึงกรณีที่ส่งบริบทให้โมเดลอย่างปลอดภัยไม่ได้ หรือต้นทุนสูงกว่าคุณค่าของความคลุมเครือที่ลดลง

สถาปัตยกรรม AI ที่ดีมักมี AI น้อยกว่าร่างแรก เก็บงานที่ deterministic ให้ deterministic แยกขั้นที่ไม่แน่นอนออกมา และทำให้ข้อจำกัดมองเห็นได้ ผลลัพธ์อาจไม่ตื่นตาเท่าเดโม แต่จะช่วยโปรดักต์จริง ผู้ใช้ทำงานเสร็จ ฝ่ายปฏิบัติการอธิบาย failure ได้ และทีมปรับ workflow ต่อได้โดยไม่ต้องสร้างระบบทั้งก้อนรอบโมเดลใหม่