จิ๊กซอว์ชิ้นที่หายไปในการสนทนาเรื่อง AI
ทุกคนกำลังพูดถึง AI agents หากคุณเลื่อนดูฟีดข่าวเทคโนโลยีใดๆ คุณจะพบกับการสาธิตนับสิบรายการที่แสดงให้เห็นโมเดลภาษาขนาดใหญ่ (LLM) กำลังจองเที่ยวบิน, เขียนโค้ด หรือตอบตั๋วสนับสนุน (support tickets) ในการสนทนาที่น่าตื่นตาตื่นใจเพียงครั้งเดียว ข้อความแฝงนั้นดูเหมือนจะชัดเจนว่า: หากคุณเชื่อมต่อผู้ใช้เข้ากับ LLM สิ่งมหัศจรรย์ก็จะเกิดขึ้น
ภาพลวงตานั้นทำงานได้อย่างยอดเยี่ยมสำหรับการสาธิตเพียงห้านาที แต่มันจะพังทลายลงทันทีเมื่อผู้ใช้จริง ข้อมูลจริง และเงินจริงเข้ามาเกี่ยวข้อง ในการใช้งานจริง (production) ความสัมพันธ์ไม่ได้เป็นเพียง User ↔ LLM เท่านั้น แต่มันคือ User ↔ ระบบที่ซับซ้อนซึ่งมี LLM เป็นส่วนประกอบหนึ่ง ส่วนหนึ่งของระบบที่ไม่มีใครพูดถึงคือ harness — โครงสร้างที่ทำหน้าที่เลือก, กำหนดเส้นทาง (route), ป้องกัน และจัดการ (orchestrate) ทุกอย่างรอบๆ โมเดล หากไม่มีมัน คุณจะไม่มีผลิตภัณฑ์ แต่คุณจะมีเพียงแค่ต้นแบบ (prototype)
ทำไมลูปแบบง่ายๆ ถึงพัง
การสาธิตคือสภาพแวดล้อมที่ถูกควบคุมไว้ คำสั่ง (queries) นั้นสั้น บริบท (context) มีจำกัด และความเสี่ยงก็ต่ำ นักพัฒนาทำการเรียก API เพียงครั้งเดียว ได้รับการตอบกลับที่ลื่นไหล และผู้ชมก็ปรบมือให้ แต่การใช้งานจริงนั้นวุ่นวาย ผู้ใช้ถามคำถามต่อเนื่องที่กำกวม API ของบุคคลที่สามหมดเวลา (timeout) โมเดลที่เคยสร้าง JSON ได้อย่างสมบูรณ์แบบเมื่อวาน กลับพ่น markdown ออกมาแทน หน้าต่างบริบท (context windows) เต็ม และการจำกัดอัตราการใช้งาน (rate limits) ก็เริ่มทำงานในจังหวะที่แย่ที่สุด
ลูป prompt-response แบบดิบๆ ไม่มีคำตอบสำหรับเรื่องเหล่านี้เลย มันไม่รู้ว่าควรใช้โมเดลเวอร์ชันไหนจัดการงานที่ได้รับมา มันจำไม่ได้ว่าเกิดอะไรขึ้นเมื่อสามขั้นตอนก่อนหน้า มันไม่สามารถลองใหม่ (retry) เมื่อการเรียกใช้งานล้มเหลว ไม่สามารถจำกัดความเร็ว (throttle) ของคำขอเมื่อค่าใช้จ่ายพุ่งสูง หรือทำความสะอาด (sanitize) ผลลัพธ์ก่อนจะบันทึกลงฐานข้อมูล สิ่งเหล่านี้ไม่ใช่กรณีพิเศษ (edge cases) แต่มันคือลักษณะเฉพาะของซอฟต์แวร์ในโลกความเป็นจริง และการจัดการสิ่งเหล่านี้คือหน้าที่ของ harness
สิ่งที่ harness ทำจริงๆ
ให้คิดว่า harness คือเลเยอร์ทางวิศวกรรมที่เปลี่ยนโมเดลภาษาจากเครื่องสร้างข้อความที่ชาญฉลาด ให้กลายเป็นส่วนประกอบบริการที่เชื่อถือได้ ความรับผิดชอบของมันนั้นเป็นรูปธรรมและไม่หวือหวา ซึ่งนั่นคือเหตุผลว่าทำไมมันจึงมักถูกมองข้าม
การเลือกโมเดลสำหรับงานที่ได้รับ ไม่ใช่ทุกการโต้ตอบที่ต้องการโมเดลพื้นฐาน (foundation model) ที่ทรงพลังที่สุด บางงานต้องการพลังการใช้เหตุผลล้วนๆ ในขณะที่บางงานต้องการเพียงความเร็วและต้นทุนต่ำ harness ที่สร้างมาอย่างดีจะกำหนดเส้นทางคำขออย่างชาญฉลาด ตัวอย่างเช่น เอเจนต์สนับสนุนลูกค้าอาจใช้โมเดลที่รวดเร็วและราคาถูกเพื่อจำแนกเจตนา (intent) ของข้อความที่ส่งเข้ามา เช่น คำขอคืนเงิน เทียบกับคำถามเรื่องการจัดส่ง หากเจตนาบ่งชี้ถึงข้อพิพาทด้านนโยบายที่ซับซ้อน harness จะส่งต่องานไปยังโมเดลที่มีพลังการใช้เหตุผลสูงกว่า แต่ถ้าผู้ใช้แค่ต้องการลิงก์ติดตามสถานะ โมเดลขนาดเล็กจะตอบกลับทันทีและช่วยให้คุณควบคุมอัตราการใช้จ่าย (burn rate) ได้อย่างเหมาะสม
การจัดการการไหลของข้อมูล แอปพลิเคชันจริงไม่ได้ทำงานอย่างโดดเดี่ยว AI agent มักต้องดึงเอกสารจาก vector store, สอบถามข้อมูลจาก CRM, อ่านกิจกรรมล่าสุดของผู้ใช้ และสังเคราะห์ข้อมูลทั้งหมดนั้นให้เป็นคำตอบที่สอดคล้องกัน harness จะจัดการการนำเข้าข้อมูลนั้น มันจะดึงส่วนของบริบท (context chunks) ที่ถูกต้อง ตรวจสอบว่าข้อมูลเหล่านั้นอยู่ในขีดจำกัดของ token โดยไม่เสียความเกี่ยวข้อง จัดโครงสร้างข้อมูลสำหรับโมเดล และส่งผลลัพธ์ต่อไปยังระบบถัดไปในสายงาน หากไม่มีการจัดการ (orchestration) นี้ โมเดลอาจจะขาดบริบทหรือจมกองข้อมูลที่ไร้สาระ
การจัดการข้อผิดพลาด LLM ล้มเหลวในรูปแบบที่บริการแบบดั้งเดิมไม่เป็น พวกมันสร้างข้อมูลที่ไม่มีอยู่จริง (hallucinate) ในรูปแบบโครงสร้างข้อมูล พวกมันส่งคำตอบที่ว่างเปล่า หรือละเมิดคำสั่งการจัดรูปแบบทันทีที่เวอร์ชันของโมเดลเปลี่ยนไปเพียงเล็กน้อย harness จะมองว่าความล้มเหลวเหล่านี้เป็นพฤติกรรมที่คาดการณ์ได้มากกว่าจะเป็นเรื่องน่าตกใจ มันจะตรวจสอบ schema, ดักจับการตอบกลับที่ผิดรูปแบบ, ใช้ตรรกะการลองใหม่แบบ exponential backoff และสลับไปใช้ผู้ให้บริการสำรองหรือผลลัพธ์ที่แคชไว้เมื่อ endpoint หลักมีปัญหา และเมื่อทุกอย่างล้มเหลว มันจะส่งต่องานให้เจ้าหน้าที่ที่เป็นมนุษย์ แทนที่จะส่งข้อมูลไร้สาระให้กับลูกค้าที่จ่ายเงินมาเงียบๆ
การรับประกันความน่าเชื่อถือของระบบ การใช้งานจริงหมายถึงผู้ใช้ที่ใช้งานพร้อมกัน, การจำกัดงบประมาณ และความหน่วง (latency) ที่คาดเดาไม่ได้ harness จะบังคับใช้ rate limits, จัดการ connection pooling และใช้ระบบ circuit breakers เพื่อไม่ให้ผู้ให้บริการโมเดลที่ทำงานช้าเพียงรายเดียวทำให้แอปพลิเคชันทั้งหมดของคุณค้าง มันจะบันทึก (log) ทุกการโต้ตอบเพื่อให้คุณสามารถตรวจสอบได้ว่าทำไมเซสชันนั้นๆ ถึงผิดพลาด และมีการทำเวอร์ชันของ prompt เพื่อไม่ให้การปรับใช้ (deployment) ไปเปลี่ยนบุคลิกของเอเจนต์โดยไม่มีประวัติการตรวจสอบ (audit trails)
โมเดลเดียวกัน แต่ผลลัพธ์ต่างกันอย่างสิ้นเชิง
สิ่งนี้อธิบายปรากฏการณ์ที่สร้างความสับสนให้กับทีมผลิตภัณฑ์หลายทีม บริษัทสองแห่งสามารถเริ่มต้นด้วย Foundation model เดียวกันทุกประการ—ค่าน้ำหนัก (weights) เดียวกัน, context window เดียวกัน, และ training cutoff เดียวกัน—แต่กลับส่งมอบประสบการณ์ที่แตกต่างกันอย่างสิ้นเชิง ฝั่งหนึ่งให้ความรู้สึกเปราะบาง ช้า และขี้ลืมอย่างน่าประหลาด ในขณะที่อีกฝั่งให้ความรู้สึกรวดเร็ว ฉับไว สม่ำเสมอ และน่าเชื่อถือ
ความแตกต่างไม่ได้อยู่ที่ตัวโมเดลเลย แต่อยู่ที่ระบบที่ห่อหุ้มมันไว้ ทีมหนึ่งปฏิบัติกับโมเดลเหมือนเป็นผลิตภัณฑ์ทั้งหมด แต่อีกทีมหนึ่งปฏิบัติกับมันในฐานะเพียงส่วนประกอบหนึ่งภายใต้สถาปัตยกรรมที่มีระเบียบวินัย Harness หรือระบบควบคุมนี่เองคือที่ที่ระเบียบวินัยนั้นดำรงอยู่
การเปลี่ยนผ่านจาก Prompts ไปสู่ Architecture
ในช่วงแรกของการพัฒนา AI การทำ prompt engineering คือหัวใจสำคัญ การปรับแต่งคำพูด การเพิ่มตัวอย่าง และการใส่คำสั่งแบบสวมบทบาทสามารถปรับปรุงคุณภาพของผลลัพธ์ได้อย่างมหาศาล ทักษะนี้ยังคงมีความสำคัญ แต่เริ่มให้ผลตอบแทนที่ลดน้อยลง (diminishing returns) ในแง่ของการเป็นปราการทางธุรกิจ คุณไม่สามารถใช้แค่การเขียน prompt เพื่อแก้ปัญหาการขาดนโยบายการลองใหม่ (retry policy) หรือท่อข้อมูล (data pipeline) ที่พันกันยุ่งเหยิงจนทำให้ข้อมูลส่วนตัวรั่วไหลไปยังคำตอบที่เปิดเผยต่อสาธารณะได้
การเปลี่ยนแปลงที่แท้จริงที่กำลังเกิดขึ้นในขณะนี้คือการเปลี่ยนผ่านไปสู่สถาปัตยกรรมซอฟต์แวร์ (software architecture) วิศวกรกำลังออกแบบ state machines, กำหนด interface ที่เข้มงวดระหว่างโมเดลและตรรกะของแอปพลิเคชัน (application logic), และจัดการกับความไม่แน่นอน (non-determinism) ในฐานะประเด็นทางวิศวกรรมที่สำคัญ พวกเขากำลังตั้งคำถามแบบระบบกระจายตัว (distributed systems): สถานะ (state) จะคงอยู่ได้อย่างไรในการสนทนาหลายรอบ? จะเกิดอะไรขึ้นเมื่อเครื่องมือปลายทาง (downstream tool) ไม่พร้อมใช้งาน? เราจะทดสอบระบบที่มีส่วนประกอบหลักเป็นแบบความน่าจะเป็น (probabilistic) ได้อย่างไร? คำถามเหล่านี้คือสิ่งที่แยก "ของเล่น" ออกจาก "เครื่องมือ"
การสร้างเพื่อใช้งานจริง: Observability และ Control
หากคุณจริงจังกับการส่งมอบผลิตภัณฑ์ Harness จำเป็นต้องมีสองคุณสมบัติเหนือสิ่งอื่นใด นั่นคือ observability และ orchestration
Observability หมายความว่าคุณสามารถมองเห็นได้ว่าโมเดลได้รับอะไรมา ส่งอะไรกลับไป และแต่ละขั้นตอนใช้เวลานานเท่าใด มันหมายถึงการติดตามวงจรการตัดสินใจของ agent ผ่านการเรียกใช้เครื่องมือ (tool calls) ถึงสิบสี่ครั้ง และระบุได้ว่ามันเริ่มวนลูปหรือออกนอกลู่นอกทางที่จุดไหน หากปราศจากความสามารถในการมองเห็นนี้ การดีบั๊ก (debugging) ระบบ AI ก็ไม่ต่างจากการซ่อมเครื่องยนต์รถยนต์ในความมืด
Orchestration หมายความว่าตรรกะทางธุรกิจ (business logic) ของคุณต้องแยกออกจากชั้นการโต้ตอบกับโมเดล (model interaction layer) มันหมายถึงการทำ versioning ให้กับ prompt เหมือนที่คุณทำกับ code เพื่อไม่ให้การ deploy ใหม่เปลี่ยนพฤติกรรมของระบบไปโดยไม่รู้ตัว มันหมายถึงการทดสอบรูปแบบความล้มเหลว (failure modes) อย่างตั้งใจ—เช่น การตัดการเชื่อมต่อ API ระหว่างการร้องขอ, การป้อนผลลัพธ์จากเครื่องมือที่ผิดรูปแบบ, หรือการจำลองสถานการณ์ context window เต็ม—เพื่อดูว่า harness ยังสามารถรักษาความเสถียรของระบบไว้ได้หรือไม่ ไม่ว่าเฟรมเวิร์กจะมาแล้วก็ไป และไม่ว่าคุณจะใช้ orchestration library สำเร็จรูปหรือสร้างขึ้นเอง วินัยในการจัดการสำคัญกว่าชื่อแบรนด์
บทสรุปที่แท้จริง
Foundation models จะพัฒนาขึ้นเรื่อยๆ พวกมันจะเร็วขึ้น ถูกลง และมีความสามารถมากขึ้น แต่เครื่องยนต์ที่ทรงพลังขึ้นไม่ได้ช่วยซ่อมโครงรถ (chassis) ที่พัง ทีมที่จะชนะในอีกไม่กี่ปีข้างหน้าไม่ใช่ทีมที่มีสิทธิ์เข้าถึงโมเดลที่ล้ำสมัยที่สุด แต่จะเป็นทีมที่สร้าง harness ที่เชื่อถือได้, ตรวจสอบได้ (observable), และมีการประสานงาน (orchestrated) ที่ดี พวกเขาจะสามารถเปลี่ยนโมเดลได้โดยไม่ต้องเขียนแอปพลิเคชันใหม่ พวกเขาจะควบคุมต้นทุนได้เพราะ harness เป็นตัวควบคุมทุก token และพวกเขาจะนอนหลับได้อย่างสนิทในตอนกลางคืนเพราะระบบของพวกเขาสามารถจัดการกับความล้มเหลวได้อย่างราบรื่น (fail gracefully)
เลิกหมกมุ่นอยู่กับโมเดลเพียงอย่างเดียว แต่เริ่มหมกมุ่นกับระบบที่รันโมเดลนั้นแทน อนาคตเป็นของวิศวกรที่สร้างระบบที่ชาญฉลาดขึ้นรอบๆ โมเดลที่ชาญฉลาด
บทความนี้อ้างอิงแนวคิดที่พูดถึงโดย Abdulaziz Zos ใน "Beyond The Model".
สำหรับการพูดคุยเพิ่มเติมเกี่ยวกับการวิศวกรรม AI และการออกแบบระบบ สามารถเข้าไปดูได้ที่ GyaanSetu learning community.