ทีมของคุณไม่ต้องการโมเดล AI ที่ดีกว่านี้ในสัปดาห์นี้
ทีมของคุณไม่ต้องการโมเดล AI ใหม่ สิ่งที่พวกเขาต้องการคือเวิร์กโฟลว์ (workflows) ที่ดีกว่าเดิม
เลิกมองหาโมเดลล่าสุดได้แล้ว แต่จงเริ่มออกแบบการทำงาน (engineering your execution) ให้ดีขึ้น ทีมส่วนใหญ่เผชิญกับปัญหาแบบเดียวกัน Agent loops มักจะหยุดทำงานกลางคันขณะทำภารกิจ Prompt สำหรับการอนุมัติทำให้คนสับสน Context chains ขาดตอนระหว่างการลองใหม่ (retries) และมนุษย์ต้องเสียเวลาหลายชั่วโมงในการตามแก้ความผิดพลาดเพราะระบบอัตโนมัติสูญเสียสถานะ (state) ของมันไป
ปัญหาไม่ใช่เรื่องของความฉลาดอีกต่อไป แต่ปัญหาคือการลงมือทำ (execution)
เรากำลังเข้าสู่ยุคของ "ภาษีการจัดการ" (orchestration tax) หากคุณไม่วางแผนรับมือ คุณจะต้องจ่ายมันผ่านระบบที่ล่มหรือความล้มเหลวที่ตรวจจับไม่ได้ คุณต้องจ่ายมันเมื่อวิศวกรต้องมานั่งเฝ้าบอทจนดึกดื่น
ผลลัพธ์จาก AI แทบจะไม่ใช่ผลิตภัณฑ์ขั้นสุดท้าย แต่มันคือขั้นตอนกลางในระบบที่ใหญ่กว่า มันช่วยในการคัดกรองตั๋ว (ticket triage), การร่าง PR และการสร้างชุดทดสอบ (test generation)
คุณต้องตอบคำถามเหล่านี้ให้ได้:
- งานสามารถทำต่อได้ไหมหลังจากหมดเวลา (timeout)?
- เราสามารถตรวจสอบได้ไหมว่าใครเป็นผู้อนุมัติการเปลี่ยนแปลง?
- เราสามารถรันงานซ้ำได้โดยไม่ทำให้เกิดผลกระทบข้างเคียง (side effects) ซ้ำซ้อนหรือไม่?
- มนุษย์สามารถเข้ามาควบคุมงานระหว่างที่กำลังดำเนินการอยู่ได้โดยไม่ต้องเริ่มใหม่ตั้งแต่ต้นหรือไม่?
วิศวกรระดับอาวุโสรู้วิธีแก้ปัญหานี้อยู่แล้ว เราแก้ปัญหาเหล่านี้ในระบบการชำระเงินและงานเบื้องหลัง (background jobs) มานานหลายปีแล้ว เราใช้ idempotency keys, checkpoints และ transaction logs เพียงแต่ AI ทำให้ความล้มเหลวเหล่านี้เกิดขึ้นเร็วขึ้นเท่านั้น
คุณภาพของโมเดลเป็นเพียงส่วนหนึ่งของสมการเท่านั้น โมเดลที่ยอดเยี่ยมบนเวิร์กโฟลว์ที่พังจะนำมาซึ่งความวุ่นวาย แต่โมเดลที่พอใช้ได้บนเวิร์กโฟลว์ที่แข็งแกร่งจะสร้างมูลค่าได้
จงสร้างคู่มือการทำงาน (playbook) ที่ใช้งานได้จริง แทนที่จะวิ่งไล่ตามความรู้สึก (vibes):
แบ่งงาน AI ออกเป็นขั้นตอนที่ชัดเจน ใช้ขั้นตอนอย่าง
collect_context,propose_change, และrun_checksอย่าปล่อยให้ prompt ขนาดใหญ่เพียงอันเดียวรันกระบวนการทั้งหมดใช้ฐานข้อมูลเพื่อความคงทน (durability) เก็บสถานะเวิร์กโฟลว์และ event logs ไว้ในฐานข้อมูลอย่าง Postgres หาก worker พัง คุณจะสามารถกู้คืนจากสถานะ (state) แทนที่จะต้องเริ่มจากหน่วยความจำ (memory)
บังคับใช้ idempotency ทุกการกระทำที่เปลี่ยนข้อมูลจำเป็นต้องมีคีย์ที่คงที่ หากขั้นตอนหนึ่งถูกรันสองครั้ง ผลลัพธ์จะต้องยังคงเหมือนเดิม
จัดการสิทธิ์การเข้าถึงด้วยการแบ่งระดับ (tiers) อย่าขอการอนุมัติอยู่ตลอดเวลา ให้สร้างระดับสำหรับงานที่อ่านได้อย่างเดียว (read-only), งานเขียนที่มีความเสี่ยงต่ำ (low-risk writes) และการเปลี่ยนแปลงที่มีผลกระทบสูง (high-impact changes)
ติดตามตัวชี้วัดการดำเนินงาน (operational metrics) เลิกติดตามแค่ latency และต้นทุน แต่ให้ติดตามอัตราความสำเร็จในการลองใหม่ (retry success rates), จุดที่ต้องใช้มนุษย์เข้ามาแทรกแซง (human intervention points) และความถี่ในการย้อนกลับ (rollback frequency)
ทีม AI ที่เก่งที่สุดจะไม่โอ้อวดเรื่อง autonomous agents แต่พวกเขาจะสร้าง pipeline ที่มีความคงทนและตรวจสอบได้ (observable) จุดแข็งของพวกเขาจะไม่ใช่ magic prompts แต่จะเป็นวิศวกรรมระบบที่มีระเบียบวินัย (disciplined systems engineering)
โมเดลฉลาดขึ้นทุกเดือน แต่ความได้เปรียบของคุณมาจากการสร้างเวิร์กโฟลว์ที่ไม่ตื่นตระหนกเมื่อมีบางอย่างผิดพลาด
Source: https://dev.to/chrisbuildsonline/your-team-doesnt-need-a-better-ai-model-this-week-2og7
Optional learning community: https://t.me/GyaanSetuAi