LLMOps

LLMOps ย่อมาจาก Large Language Model Ops คือชื่อรวมของงานที่ทีมต้องทำเพื่อดูแลระบบที่มี LLM อยู่ข้างใน ครอบคลุมตั้งแต่ช่วงทดลองและเตรียมของก่อนขึ้นใช้งานจริง ไปจนถึงการดูแลต่อเนื่องหลังระบบเปิดใช้งานแล้ว Databricks นิยามคำนี้ไว้ในหน้าคำศัพท์ของตัวเองว่าเป็น "the practices, techniques and tools used for the operational management of large language models in production environments" คือวิธีทำงาน เทคนิค และเครื่องมือสำหรับบริหารจัดการ LLM ในสภาพแวดล้อมที่ให้บริการจริง และเนื้อความในหน้าเดียวกันอธิบายว่า LLMOps ทำให้ deploy เฝ้าดู และดูแลรักษา LLM ได้อย่างมีประสิทธิภาพ พร้อมไล่องค์ประกอบของงานไว้ตั้งแต่การสำรวจข้อมูล การเตรียมข้อมูลและการทำ prompt engineering การ fine-tune การตรวจสอบและกำกับดูแล การให้บริการ inference ไปจนถึงการเฝ้าดูผลลัพธ์โดยมีคนคอยให้ feedback ส่วน Microsoft เรียกงานชุดเดียวกันว่า GenAIOps โดยเขียนกำกับไว้ในเอกสาร Azure Machine Learning ว่า "sometimes called LLMOps" แล้วอธิบายต่อว่าหมายถึงแนวปฏิบัติและกลยุทธ์สำหรับดูแล LLM ในการใช้งานจริง ข้อควรระวังคือคำนี้ถูกหยิบไปใช้เป็นคำโฆษณาบ่อยมาก เวลาเจอที่ไหนควรดูก่อนว่าใครเป็นคนนิยาม เพราะขอบเขตที่แต่ละเจ้าวาดไว้ไม่ได้ตรงกันทุกข้อ

เหตุผลที่งานนี้ไม่เหมือนการดูแลซอฟต์แวร์ทั่วไปอยู่ที่ธรรมชาติของตัวโมเดลเอง เอกสาร Well-Architected Framework ของ Microsoft เขียนไว้ว่างาน AI มีลักษณะ nondeterministic โดยเนื้อแท้ และโมเดลจำนวนมากมีแนวโน้มตอบคำถามเดิมออกมาไม่เหมือนกันในแต่ละครั้งตอน inference หน้าเดียวกันจึงแนะนำให้ใส่ qualitative test เข้าไปใน release pipeline และระบบ monitoring ไม่ใช่ทดสอบแค่ว่าโค้ดผ่านหรือไม่ผ่าน เอกสารฉบับนั้นยังจัด GenAIOps เป็นส่วนย่อยเฉพาะทางของ MLOps ที่เล็งไปที่งาน generative AI และระบุว่าจุดต่างหลักคือน้ำหนักย้ายจากการ training ไปอยู่ที่การเลือกโมเดลให้ถูกตัว การทำ prompt engineering และการเติมความรู้เฉพาะทางเข้าไปด้วย fine-tuning หรือ RAG ฝั่ง Google Cloud มีคู่มือว่าด้วยการ deploy และดูแลแอป generative AI ที่ให้แนวปฏิบัติเป็นข้อๆ ไว้ว่าให้มองว่า prompt เป็น artifact ที่สำคัญที่สุดในบรรดาผลผลิตของการทดลอง จึงต้องทำ versioning กับทุกชิ้นส่วนที่แก้ไขได้ โดยคู่มือเขียนไว้ว่าถ้าไม่ได้ใช้เครื่องมือจัดการ prompt โดยเฉพาะ ให้ใช้เครื่องมือ version control ตามรอยเวอร์ชันของ prompt-template ให้จัดการ chain ทั้งชุดเป็น artifact เดียวที่มีประวัติการแก้ไขของตัวเอง ให้ทำ evaluation แบบอัตโนมัติเพราะคู่มือระบุว่าได้ประโยชน์สองอย่างคือทำงานได้เร็วขึ้นและผลการประเมินน่าเชื่อถือขึ้น และให้ log กับ monitor แอปแบบ end-to-end รวมถึง input และ output โดยรวมด้วย ซึ่งเป็นงานฝั่ง observability ตรงตัว ตัวชี้วัดที่คู่มือนั้นแนะนำให้จับมีทั้ง drift ที่มองหาความเปลี่ยนแปลงของ input data ซึ่งเป็นสัญญาณเดียวกับที่คนเตือนกันเรื่อง model-drift และ skew ที่วัดโดยเทียบการกระจายตัวของข้อมูลที่เคยใช้ประเมินกับ input จริงที่ไหลเข้ามาใน production

เรื่องที่คนทำงานมักไม่ทันคิดคือวันที่ผู้ให้บริการเลิกรุ่นโมเดล Azure Architecture Center เขียนคำเตือนไว้ตรงๆ ว่าสำหรับบริการแบบ model as a service ซึ่งรวมถึงโมเดลที่ deploy ผ่าน azure-openai นั้น deployment ของโมเดลที่ retired ไปแล้วจะตอบกลับมาเป็น HTTP error และถ้าไม่ย้ายไปใช้โมเดลที่ยังรองรับ แอปจะทำงานไม่ได้อย่างที่ควรเป็น ส่วนโมเดลที่อยู่ในสถานะ deprecated นั้นสร้าง deployment ใหม่ไม่ได้แล้ว แต่ deployment เดิมยังทำงานต่อไปได้จนกว่าจะถึงวันที่ถูก retired จริง หน้าเดียวกันเขียนต่อว่าถ้าเลือก self-host หรือใช้ managed compute เอง จะควบคุมได้เต็มที่และไม่ถูกบังคับให้อัปเดตโมเดล แต่ก็อาจอยากทำวงจรอัปเดตของตัวเองอยู่ดีเพื่อประโยชน์ที่โมเดลรุ่นใหม่ให้ได้ เพราะแบบนี้ model-deprecation จึงเป็นเรื่องที่ต้องมีคนตามในทุกองค์กรที่ใช้ AI ผ่านผู้ให้บริการ คำแนะนำอื่นในหน้านั้นใช้ได้กับทีมทั่วไปเช่นกัน คือทุกการเปลี่ยนแปลงของ model version, prompt, configuration, orchestration logic และวิธีดึง grounding knowledge ต้องถูกทดสอบก่อนนำไปใช้จริง โดยให้เทียบผลกับ baseline เดิมผ่าน pipeline อัตโนมัติ ซึ่งก็คือ regression-testing ในเวอร์ชันของงาน AI นั่นเอง และชุดที่ทดสอบผ่านแล้วต้องถูกผูกติดกันตอน deploy เอกสารใช้คำว่า pinned together พร้อมเตือนว่า a-b-testing การทำ load balancing และ blue-green deployment ต้องไม่สลับชิ้นส่วนข้ามชุดจนผู้ใช้เจอคู่ผสมที่ยังไม่เคยถูกทดสอบ เอกสารยังแนะนำให้เลี่ยงฟีเจอร์ของแพลตฟอร์มที่อัปเกรดโมเดลใน production เป็นรุ่นใหม่อัตโนมัติโดยไม่เปิดโอกาสให้ทดสอบก่อน สำหรับ Azure OpenAI ให้ตั้ง deployment ไม่ให้อัปเกรดเวอร์ชันอัตโนมัติ ซึ่งเอกสารฉบับนั้นเรียกว่า No Auto Upgrade ส่วนเอกสาร Foundry ฉบับปัจจุบันเรียกตัวเลือกนี้ว่า Opt out of automatic model version upgrades สำหรับโค้ดที่ทำหน้าที่ orchestration นั้นหน้า Azure Architecture Center ยกตัวอย่างทางเลือกไว้ เช่น Microsoft Agent Framework, Semantic Kernel หรือ langchain ที่ host อยู่บน Azure การย้ายรุ่นก็ไม่ได้เกิดจากการถูกบังคับอย่างเดียว คู่มือของ Google Cloud เขียนว่านักพัฒนาปรับ foundation model กันตลอดเวลา ทั้งด้วยเทคนิคการเขียน prompt การสลับไปใช้รุ่นใหม่ หรือแม้แต่ผสมหลายโมเดลเข้าด้วยกัน เพื่อให้ได้ประสิทธิภาพที่ดีขึ้น ต้นทุนที่คุ้มขึ้น หรือ latency ที่ต่ำลง การคุมค่าใช้จ่ายจึงเป็นงานประจำของ LLMOps และเป็นตัวแปรหนึ่งใน total-cost-of-ownership ของระบบ AI ทั้งก้อน

ตัวอย่างจากบทสนทนาจริง

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

ทีม IT: ตัวนี้ไม่จบครับ งานที่เหลือเรียกรวมว่า LLMOps สิ่งที่ต้องทำทุกเดือนคือวัดคุณภาพคำตอบด้วยชุดทดสอบ ดูว่าคำถามที่ลูกค้าถามเข้ามาเปลี่ยนไปจากตอนที่เราทดสอบไว้หรือยัง แล้วก็ดูค่าใช้จ่ายต่อการใช้งานหนึ่งครั้ง

หัวหน้าฝ่ายบริการลูกค้า: แล้วมีอะไรที่ถ้าไม่ทำแล้วระบบพังเลยไหมคะ

ทีม IT: มีครับ ผู้ให้บริการมีกำหนดปลดระวางโมเดลรุ่นที่เราใช้อยู่ เอกสารของเขาเขียนไว้ว่าพอถึงวันนั้น การเรียกโมเดลรุ่นเดิมจะได้ error กลับมา ระบบจะตอบลูกค้าไม่ได้ทันที เราจึงต้องย้ายไปรุ่นใหม่ก่อนถึงกำหนด และพอย้ายรุ่นแล้วต้องเอา prompt ชุดเดิมมาทดสอบใหม่ทั้งหมด เพราะ prompt กับ configuration ถูกออกแบบมาให้เข้ากับโมเดลรุ่นที่ระบุไว้เท่านั้น

ระวังสับสนกับ

• MLOps : MLOps คือแนวปฏิบัติสำหรับดูแลระบบ machine learning โดยรวม ส่วนเอกสาร Well-Architected Framework ของ Microsoft จัดให้ GenAIOps ที่บางคนเรียกว่า LLMOps เป็นส่วนย่อยเฉพาะทางของ MLOps ซึ่งเล็งไปที่งาน generative AI จุดต่างที่เอกสารระบุคือน้ำหนักย้ายจากการ training ไปอยู่ที่การเลือกโมเดล การทำ prompt engineering และการเติมความรู้เฉพาะทางด้วย fine-tuning หรือ RAG
• evals : evals คือวิธีวัดว่าคำตอบของโมเดลดีหรือไม่ดี เป็นหนึ่งในงานที่อยู่ภายใต้ LLMOps ไม่ใช่คำที่ใช้แทนกันได้ เพราะ LLMOps ยังรวมการจัดการ prompt การ deploy การเฝ้าดูระบบ และการย้ายรุ่นโมเดลเข้าไปด้วย
• DevOps : เอกสารของ Microsoft อธิบายว่า DevOps ดูแลวงจรการพัฒนาแอปทั้งหมดผ่าน pipeline อัตโนมัติและการ monitoring ส่วนที่งานฝั่ง LLM เพิ่มเข้ามาคือความไม่แน่นอนของคำตอบ ทำให้ต้องมี qualitative test ใน release pipeline ไม่ใช่แค่การทดสอบแบบผ่านหรือไม่ผ่านอย่างเดียว