วิศวกรที่ต้องซ่อม AI Feature ตอนตีสอง จะรู้ได้ยังไงว่าปัญหาอยู่ที่โมเดลหรือโค้ดตัวเอง
สรุปสั้น ๆ
LLM Observability คือการเก็บและวิเคราะห์ข้อมูลของทุกคำขอที่ระบบส่งไปยังโมเดลภาษา ทั้ง Latency ต้นทุนต่อคำขอ การเรียกใช้เครื่องมือ (Tool Calls) และอัตราความผิดพลาด เพื่อให้ทีมรู้ว่าเมื่อฟีเจอร์ AI ทำงานผิดปกติ ปัญหามาจากตัวโมเดลเอง จากข้อมูลที่ดึงมาผิด หรือจากโค้ดของทีมเอง แทนที่จะต้องเดาหรือไล่ทดสอบทีละจุดตอนเกิดปัญหาจริง
วิศวกรคนหนึ่งได้รับแจ้งเตือนตอนตีสองว่าฟีเจอร์แชทบอทตอบคำถามลูกค้าเริ่มตอบช้าผิดปกติ และมีบางคำขอตอบกลับมาเป็นข้อความว่างเปล่า ปัญหาคือระบบ Log ที่มีอยู่บันทึกแค่ว่า 'คำขอสำเร็จ' หรือ 'คำขอล้มเหลว' โดยไม่มีรายละเอียดว่าใช้เวลานานตรงขั้นตอนไหน โมเดลที่เรียกใช้เปลี่ยนพฤติกรรมหรือไม่ หรือระบบดึงข้อมูลที่ป้อนให้โมเดลผิดพลาดตั้งแต่ต้น วิศวกรคนนั้นต้องลองสร้างคำขอซ้ำด้วยมือหลายรอบกว่าจะเดาได้ว่าปัญหาน่าจะมาจากไหน ซึ่งกินเวลาไปเกือบชั่วโมงในช่วงที่ผู้ใช้จริงกำลังได้รับผลกระทบอยู่
สถานการณ์แบบนี้เป็นเหตุผลที่ทีมพัฒนาระบบ AI จำนวนมากเริ่มลงทุนกับ LLM Observability อย่างจริงจัง เพราะระบบที่มีโมเดลภาษาเป็นส่วนประกอบมีลักษณะต่างจากซอฟต์แวร์ทั่วไป การตรวจสอบแบบเดิมที่ดูแค่ว่าเซิร์ฟเวอร์ตอบสนองหรือไม่ (Uptime) ไม่เพียงพออีกต่อไป เพราะระบบอาจ 'ทำงานได้' ในแง่เทคนิค แต่คำตอบที่ได้ผิดพลาดหรือไม่ตรงประเด็น ซึ่งเป็นปัญหาคนละแบบที่เครื่องมือ Monitoring แบบดั้งเดิมมองไม่เห็น
บทความนี้จะพาดูว่า LLM Observability ควรวัดอะไรบ้าง ทั้ง Latency ต้นทุน การเรียกใช้เครื่องมือ และ Error เพื่อให้เมื่อเกิดปัญหาแบบในสถานการณ์ข้างต้น ทีมมีข้อมูลพอที่จะระบุสาเหตุได้เร็วขึ้น แทนที่จะต้องเดาและลองผิดลองถูกกลางดึกเหมือนก่อนหน้านี้
LLM Observability คืออะไร ต่างจาก Monitoring แบบเดิมตรงไหน
LLM Observability คือแนวทางการเก็บและวิเคราะห์ข้อมูลเชิงลึกของทุกคำขอที่ระบบส่งไปยังโมเดลภาษา ไม่ใช่แค่ตรวจว่าเซิร์ฟเวอร์ยังทำงานอยู่หรือไม่เหมือน Monitoring แบบดั้งเดิม แต่รวมถึงการรู้ว่าคำขอนั้นใช้เวลานานเท่าไรในแต่ละขั้นตอน ใช้ Token ไปเท่าไร เรียกใช้เครื่องมือภายนอกอะไรบ้างระหว่างทาง และคำตอบสุดท้ายมีลักษณะผิดปกติหรือไม่
ความต่างสำคัญจาก Monitoring แบบเดิมคือระบบที่มีโมเดลภาษาเป็นส่วนประกอบมีความไม่แน่นอนโดยธรรมชาติ (Non-determinism) คำถามเดียวกันอาจได้คำตอบที่ต่างกันเล็กน้อยในแต่ละครั้ง และ 'ความสำเร็จ' ของคำขอไม่ได้วัดแค่ว่าได้รับ HTTP Status 200 กลับมา แต่ต้องพิจารณาด้วยว่าคำตอบที่ได้มีคุณภาพเพียงพอหรือไม่ ซึ่งเป็นมิติที่ Monitoring แบบเดิมไม่ได้ออกแบบมาให้วัด
LLM Observability จึงต้องผสานสามมุมมองเข้าด้วยกัน คือมุมมองด้านประสิทธิภาพ (Latency และต้นทุน) มุมมองด้านพฤติกรรม (การเรียกใช้เครื่องมือและลำดับขั้นตอน) และมุมมองด้านคุณภาพ (ความถูกต้องของคำตอบ) การมีแค่มุมมองใดมุมมองหนึ่งไม่พอที่จะวินิจฉัยปัญหาได้ครบถ้วนเมื่อระบบเริ่มมีความซับซ้อนมากขึ้น
ควรวัดอะไรบ้างในระบบที่ใช้โมเดลภาษา
แต่ละมิติของการวัดตอบคำถามคนละแบบเมื่อเกิดปัญหา การมีครบทุกมิติช่วยให้วินิจฉัยสาเหตุได้แม่นยำกว่าการดูมิติเดียว
| มิติที่วัด | ตอบคำถามอะไร | สัญญาณผิดปกติที่ควรจับตา |
|---|---|---|
| Latency | คำขอใช้เวลานานตรงขั้นตอนไหน | เวลารวมหรือเวลาเฉพาะขั้นตอนใดขั้นตอนหนึ่งเพิ่มขึ้นผิดปกติ |
| Cost / Token Usage | คำขอนี้มีต้นทุนเท่าไร ใช้ Token มากผิดปกติไหม | จำนวน Token ต่อคำขอพุ่งสูงขึ้นโดยไม่มีเหตุผลชัดเจน |
| Tool Calls | โมเดลเรียกใช้เครื่องมือภายนอกอะไรบ้างระหว่างทาง | เรียกใช้เครื่องมือซ้ำวนไม่จบ หรือเรียกเครื่องมือผิดตัวจากที่ควรเป็น |
| Error Rate | คำขอล้มเหลวบ่อยแค่ไหน ล้มเหลวแบบไหน | อัตรา Error เพิ่มขึ้นเฉพาะบาง Provider หรือบางประเภทคำขอ |
ตามรอยคำขอหนึ่งครั้งตั้งแต่ต้นจนจบ (Tracing) ทำอย่างไร
- กำหนด Trace ID เดียวให้กับคำขอตั้งแต่จุดที่ผู้ใช้ส่งคำถามเข้ามา แล้วส่ง ID นี้ผ่านไปในทุกขั้นตอนที่คำขอนั้นเดินทางผ่าน
- บันทึกเวลาเริ่มต้นและสิ้นสุดของแต่ละขั้นตอนย่อย เช่น ขั้นตอนดึงข้อมูลจาก Vector Database ขั้นตอนเรียกโมเดลภาษา และขั้นตอนประมวลผลหลังได้คำตอบ
- บันทึกว่าขั้นตอนไหนมีการเรียกใช้เครื่องมือภายนอกบ้าง พร้อมพารามิเตอร์ที่ส่งไปและผลลัพธ์ที่ได้กลับมา เพื่อให้ตรวจสอบย้อนหลังได้ว่าการตัดสินใจของระบบเป็นไปตามที่คาดหวังหรือไม่
- รวบรวมข้อมูลทั้งหมดของ Trace เดียวกันไว้ในที่เดียว เพื่อให้เมื่อเกิดปัญหา ทีมสามารถดูภาพรวมของคำขอนั้นได้ทันทีโดยไม่ต้องไล่หา Log จากหลายระบบแยกกัน
- ตั้งค่าให้ Trace ที่มีลักษณะผิดปกติ เช่น ใช้เวลานานผิดปกติหรือมี Error เกิดขึ้น ถูกดึงมาแสดงเด่นในแดชบอร์ดโดยอัตโนมัติ แทนที่จะต้องค้นหาเองทุกครั้ง
ตรวจจับคุณภาพคำตอบที่แย่ลงแบบเงียบ ๆ (Silent Quality Drift)
ปัญหาที่อันตรายกว่า Error ที่มองเห็นชัดคือคุณภาพคำตอบที่ค่อย ๆ แย่ลงโดยไม่มี Error ใด ๆ ปรากฏให้เห็น เช่น ผู้ให้บริการโมเดลอัปเดตเวอร์ชันเบื้องหลังโดยไม่แจ้งล่วงหน้า ทำให้พฤติกรรมการตอบเปลี่ยนไปเล็กน้อย หรือข้อมูลในฐานความรู้ที่ระบบดึงมาใช้เริ่มล้าสมัยทีละนิดจนคำตอบเริ่มคลาดเคลื่อนสะสม กรณีแบบนี้ระบบจะยังคงรายงานว่า 'สำเร็จ' ทุกครั้งเพราะไม่มี Error ทางเทคนิคเกิดขึ้นเลย
การจับปัญหาประเภทนี้ต้องอาศัยการสุ่มตรวจคำตอบจริงเป็นระยะ หรือใช้ชุดคำถามทดสอบที่รู้คำตอบที่ถูกต้องอยู่แล้วมารันซ้ำตามรอบเวลาที่กำหนด แล้วเปรียบเทียบผลลัพธ์กับช่วงเวลาก่อนหน้าว่าคุณภาพเปลี่ยนไปหรือไม่ ทีมที่จริงจังกับเรื่องนี้มักมีกระบวนการที่เรียกว่า Regression Testing สำหรับฟีเจอร์ AI เช่นเดียวกับการทดสอบซอฟต์แวร์ทั่วไป เพียงแต่เกณฑ์ตัดสิน 'ผ่าน' หรือ 'ไม่ผ่าน' ซับซ้อนกว่าการเทียบผลลัพธ์แบบตรงตัว
สัญญาณทางอ้อมที่ช่วยจับปัญหานี้ได้เร็วขึ้นคือพฤติกรรมของผู้ใช้ เช่น อัตราที่ผู้ใช้พิมพ์คำถามซ้ำเพราะไม่พอใจคำตอบแรก หรืออัตราที่ผู้ใช้กดปุ่มรายงานปัญหาเพิ่มขึ้นผิดปกติในช่วงเวลาหนึ่ง สัญญาณเหล่านี้ควรถูกนำมารวมไว้ในระบบ Observability เดียวกัน ไม่ใช่แยกเก็บไว้คนละที่กับข้อมูลทางเทคนิค
ตั้งค่าแจ้งเตือนอย่างไรไม่ให้รบกวนทีมจนเกินไป
- ตั้งเกณฑ์แจ้งเตือนจากค่าเฉลี่ยและความผันผวนปกติของระบบเอง ไม่ใช่ใช้ตัวเลขตายตัวที่ยกมาจากระบบอื่นซึ่งมีลักษณะการใช้งานต่างกัน
- แยกระดับความรุนแรงของการแจ้งเตือน เช่น ปัญหาที่กระทบผู้ใช้ทันทีควรแจ้งเตือนแบบเร่งด่วน ส่วนแนวโน้มที่น่ากังวลแต่ยังไม่กระทบผู้ใช้ควรอยู่ในรายงานสรุปประจำวันแทน
- ทบทวนเกณฑ์แจ้งเตือนเป็นระยะ เพราะเมื่อปริมาณการใช้งานหรือลักษณะคำขอเปลี่ยนไป เกณฑ์เดิมอาจแจ้งเตือนถี่เกินไปจนทีมเริ่มเพิกเฉย หรือหลวมเกินไปจนพลาดปัญหาจริง
- เชื่อมการแจ้งเตือนเข้ากับข้อมูล Trace โดยตรง เพื่อให้เมื่อได้รับแจ้งเตือน ทีมสามารถคลิกเข้าไปดูรายละเอียดคำขอที่มีปัญหาได้ทันทีโดยไม่ต้องเริ่มค้นหาใหม่ตั้งแต่ศูนย์
ข้อผิดพลาดที่ทีมมักเจอเมื่อเริ่มทำ LLM Observability
- ทำแบบนี้แล้วพัง เพราะเก็บ Log แค่ว่าคำขอสำเร็จหรือล้มเหลว โดยไม่บันทึกรายละเอียดของแต่ละขั้นตอนย่อย ทำให้เมื่อเกิดปัญหาไม่สามารถระบุได้ว่าจุดไหนของกระบวนการที่ผิดพลาด
- ทำแบบนี้แล้วพัง เพราะวัดแค่ Latency และต้นทุน แต่ไม่มีกระบวนการตรวจสอบคุณภาพคำตอบเลย ทำให้พลาดปัญหาคุณภาพที่แย่ลงแบบเงียบ ๆ ไปนานกว่าจะมีคนสังเกตเห็น
- ทำแบบนี้แล้วพัง เพราะตั้งค่าแจ้งเตือนที่ไวเกินไปจนแจ้งเตือนบ่อยครั้งเกินจำเป็น ทำให้ทีมเริ่มเพิกเฉยต่อการแจ้งเตือนทั้งหมด รวมถึงครั้งที่เป็นปัญหาจริง
- ทำแบบนี้แล้วพัง เพราะเก็บข้อมูล Observability ไว้แยกกันคนละระบบตามแต่ละทีมที่สร้างฟีเจอร์ ทำให้ไม่มีภาพรวมทั้งบริษัทเมื่อต้องวิเคราะห์ปัญหาที่กระทบหลายฟีเจอร์พร้อมกัน
เริ่มวาง LLM Observability เข้าไปในระบบที่มีอยู่แล้วอย่างไร
จุดเริ่มต้นที่ง่ายที่สุดสำหรับทีมที่มี AI Gateway อยู่แล้วคือต่อยอดจาก Log ที่ชั้นกลางนี้เก็บไว้อยู่แล้ว เพราะข้อมูล Latency ต้นทุน และคำขอทุกครั้งถูกบันทึกไว้เป็นวัตถุดิบตั้งต้น สิ่งที่ต้องเพิ่มคือการวิเคราะห์เชิงคุณภาพและการเชื่อมโยงข้อมูลจากหลายขั้นตอนเข้าด้วยกันเป็น Trace เดียว โดยเฉพาะระบบที่ใช้ RAG ซึ่งมีหลายขั้นตอนต่อหนึ่งคำถาม ตั้งแต่การค้นคืนข้อมูลไปจนถึงการสร้างคำตอบ
สำหรับทีมที่กำลังสร้างฟีเจอร์ที่ใช้ AI Agent ซึ่งมีการตัดสินใจหลายขั้นตอนและเรียกใช้เครื่องมือหลายตัวต่อหนึ่งงาน ความซับซ้อนของการสังเกตการณ์จะเพิ่มขึ้นไปอีกระดับ ควรอ่านเพิ่มเติมที่ AI Agent Observability ซึ่งอธิบายว่าต้องเพิ่มมิติการวัดอะไรบ้างเมื่อระบบไม่ได้ตอบคำถามครั้งเดียวจบเหมือนแชทบอททั่วไป
สรุป
LLM Observability คือการเก็บและวิเคราะห์ข้อมูลของทุกคำขอที่ระบบส่งไปยังโมเดลภาษาอย่างละเอียด ทั้ง Latency ต้นทุน การเรียกใช้เครื่องมือ และอัตราความผิดพลาด เพื่อให้ทีมระบุสาเหตุของปัญหาได้เร็วขึ้นเมื่อฟีเจอร์ AI ทำงานผิดปกติ แทนที่จะต้องเดาหรือไล่ทดสอบทีละจุดตอนเกิดปัญหาจริง
จุดที่ทำให้ LLM Observability ยากกว่า Monitoring ทั่วไปคือความไม่แน่นอนของโมเดลภาษาและปัญหาคุณภาพที่แย่ลงแบบเงียบ ๆ โดยไม่มี Error ทางเทคนิคเกิดขึ้น ทีมที่จะทำเรื่องนี้ให้ได้ผลต้องผสานทั้งการวัดเชิงประสิทธิภาพและการตรวจสอบคุณภาพคำตอบเข้าด้วยกัน ไม่ใช่มองว่ามีแค่ Log เทคนิคก็เพียงพอแล้ว
- LLM Observability วัดสามมุมมองพร้อมกัน คือประสิทธิภาพ พฤติกรรม และคุณภาพของคำตอบ ไม่ใช่แค่ Uptime แบบเดิม
- การทำ Tracing ที่แยกแต่ละขั้นตอนของคำขอช่วยระบุได้ว่าปัญหามาจากโมเดล ข้อมูล หรือโค้ดของทีมเอง
- คุณภาพคำตอบที่แย่ลงแบบเงียบ ๆ ต้องอาศัยการสุ่มตรวจหรือชุดคำถามทดสอบเป็นระยะ เพราะไม่มี Error ทางเทคนิคให้เห็น
- ทีมที่มี AI Gateway อยู่แล้วต่อยอดทำ Observability ได้ง่ายกว่า เพราะมี Log พื้นฐานเป็นวัตถุดิบตั้งต้นอยู่แล้ว
คำถามที่พบบ่อย
LLM Observability ต่างจาก Application Performance Monitoring (APM) ทั่วไปอย่างไร
APM ทั่วไปเน้นวัดสุขภาพของระบบในเชิงเทคนิค เช่น Uptime, CPU และ Memory ส่วน LLM Observability เพิ่มมิติที่เฉพาะเจาะจงกับโมเดลภาษา เช่น Token Usage, การเรียกใช้เครื่องมือ และคุณภาพของคำตอบ ซึ่งเป็นข้อมูลที่ APM ทั่วไปไม่ได้ออกแบบมาให้เก็บ ทีมส่วนใหญ่จึงใช้ทั้งสองระบบควบคู่กันแทนที่จะเลือกอย่างใดอย่างหนึ่ง
ต้องเก็บ Log ทุกคำขอเลยหรือสุ่มเก็บพอ
ขึ้นกับปริมาณการใช้งานและงบประมาณด้านพื้นที่จัดเก็บ ระบบที่มีปริมาณคำขอไม่มากมักเก็บทุกคำขอได้สบาย ส่วนระบบที่มีปริมาณสูงมากอาจต้องสุ่มเก็บบางส่วนแบบละเอียด และเก็บข้อมูลสรุปของคำขอที่เหลือ แต่ควรเก็บคำขอที่มี Error หรือ Latency ผิดปกติแบบละเอียดเสมอ ไม่ว่าจะสุ่มเก็บส่วนอื่นแค่ไหนก็ตาม
วัดคุณภาพคำตอบแบบอัตโนมัติได้ไหมโดยไม่ต้องให้คนตรวจทุกครั้ง
ทำได้บางส่วนผ่านชุดคำถามทดสอบที่รู้คำตอบถูกต้องอยู่แล้ว หรือใช้โมเดลอีกตัวช่วยประเมินคำตอบเบื้องต้น แต่การตรวจสอบด้วยคนยังจำเป็นสำหรับกรณีที่ซับซ้อนหรือมีความเสี่ยงสูง การพึ่งการประเมินอัตโนมัติทั้งหมดโดยไม่มีการสุ่มตรวจด้วยคนเลยมีความเสี่ยงที่จะพลาดปัญหาที่ระบบประเมินเองมองไม่เห็น
LLM Observability ช่วยลดต้นทุนได้จริงหรือแค่ช่วยแก้บั๊กเร็วขึ้น
ช่วยได้ทั้งสองด้าน การเห็นข้อมูล Token Usage แบบละเอียดช่วยให้ทีมพบจุดที่ใช้ Token เกินความจำเป็น เช่น พรอมป์ต์ที่ยาวเกินไปหรือการเรียกโมเดลซ้ำโดยไม่จำเป็น ซึ่งนำไปสู่การปรับปรุงที่ลดต้นทุนได้โดยตรง ไม่ใช่แค่ช่วยวินิจฉัยปัญหาเร็วขึ้นเพียงอย่างเดียว
ทีมขนาดเล็กที่ยังไม่มีงบซื้อเครื่องมือ Observability เฉพาะทางควรเริ่มอย่างไร
เริ่มจากบันทึก Log พื้นฐานให้ครบก่อน คือเวลาที่ใช้ ต้นทุน Token และ Error ของแต่ละคำขอ ลงในระบบ Log ที่มีอยู่แล้ว แล้วสร้างรายงานสรุปง่าย ๆ เพื่อดูแนวโน้มรายวัน ไม่จำเป็นต้องใช้เครื่องมือเฉพาะทางราคาแพงตั้งแต่ต้น จนกว่าจะเห็นความจำเป็นชัดเจนจากปริมาณการใช้งานที่เพิ่มขึ้น
จะรู้ได้อย่างไรว่าปัญหามาจากโมเดลหรือมาจากโค้ดของทีมเอง
ต้องอาศัย Trace ที่แยกแต่ละขั้นตอนชัดเจน ถ้าเวลาที่ใช้ไปส่วนใหญ่อยู่ที่ขั้นตอนเรียกโมเดลและคำตอบที่ได้ผิดปกติ มักชี้ไปทางปัญหาของโมเดลหรือข้อมูลที่ป้อนเข้าไป แต่ถ้าเวลาที่ใช้ไปมากอยู่ที่ขั้นตอนประมวลผลก่อนหรือหลังเรียกโมเดล มักชี้ไปทางโค้ดของทีมเอง การมี Trace ที่แยกขั้นตอนละเอียดจึงสำคัญกว่าการดูแค่เวลารวมทั้งหมด
อ่านต่อแบบเจาะลึก
ทดลองวัดผลโฆษณาเข้า LINE ฟรี 14 วัน
สมัครแล้วสร้างโปรเจกต์ เชื่อม LINE ติดตั้ง Tracking แล้วเริ่มเห็น Funnel จาก Click ถึง Purchase ได้ทันที ไม่ต้องใช้บัตรเครดิต
เริ่มทดลองใช้ฟรี 14 วันบทความที่เกี่ยวข้อง
Agent ผ่าน Test Case ที่เตรียมไว้ครบทุกข้อ แล้วจะเอาไปใช้กับลูกค้าจริงได้เลยไหม
ทีมขนาดเล็กที่มี Agent เดียวทำงานง่าย ๆ จำเป็นต้องลงทุนกับ Observability เพิ่มไหม
