Observability

Observability คือความสามารถในการเข้าใจว่าระบบทำอะไรอยู่ข้างใน โดยอาศัยข้อมูลที่ระบบพ่นออกมาข้างนอกเท่านั้น ไม่ต้องเข้าไปรื้อโค้ดดูทีละบรรทัด OpenTelemetry ซึ่งเป็นโครงการมาตรฐานกลางเรื่องการเก็บข้อมูลการทำงานของซอฟต์แวร์ อธิบายไว้ว่ามันคือการทำให้เราตั้งคำถามกับระบบได้โดยไม่ต้องรู้กลไกภายในของมัน หน่วยข้อมูลหลักที่ใช้ตอบคำถามพวกนั้นคือ trace ซึ่งบันทึกเส้นทางของคำขอหนึ่งครั้งตั้งแต่วิ่งเข้ามาจนวิ่งออกไป และ trace หนึ่งอันประกอบขึ้นจาก span ตั้งแต่หนึ่งอันขึ้นไป โดยแต่ละ span คืองานหนึ่งชิ้นที่เกิดขึ้นระหว่างทาง เช่น การเรียกโมเดลหนึ่งครั้ง การค้นเอกสารหนึ่งรอบ หรือการเรียกเครื่องมือหนึ่งตัว

สำหรับระบบ AI โดยเฉพาะ มาตรฐานกลางสำหรับเรื่องนี้คือ OpenTelemetry semantic conventions สำหรับ GenAI ซึ่งตอนนี้แยกไปอยู่ในคลังโค้ดของตัวเองชื่อ semantic-conventions-genai แล้ว (หน้าเดิมบนเว็บ opentelemetry.io ขึ้นประกาศไว้ว่าย้ายไปที่ใหม่และไม่ได้ดูแลต่อในที่เดิมอีก) หน้าที่ของมาตรฐานนี้คือทำให้เครื่องมือต่างยี่ห้อเรียกของชิ้นเดียวกันด้วยชื่อเดียวกัน มาตรฐานแบ่ง span ออกเป็นหลายประเภทตามงานที่ทำ เช่น การเรียกโมเดล การสร้าง embedding การค้นเอกสาร การจัดการหน่วยความจำ และการเรียกเครื่องมือ ทุกประเภทกำหนดให้ต้องมี gen_ai.operation.name ที่บอกว่า span นั้นเป็นงานแบบไหน โดย span ของการเรียกโมเดลใช้ค่าอย่าง chat หรือ text_completion ส่วน embeddings กับ execute_tool เป็นค่าของ span คนละประเภทกัน และ span ของการเรียกโมเดลต้องมี gen_ai.provider.name ด้วย (ใน span ประเภทค้นเอกสารและหน่วยความจำ gen_ai.provider.name ลดเป็นแบบจำเป็นตามเงื่อนไข) ส่วน gen_ai.request.model เป็นแบบจำเป็นตามเงื่อนไข และแนะนำให้ใส่ gen_ai.usage.input_tokens กับ gen_ai.usage.output_tokens เพื่อบันทึกจำนวน tokenที่ใช้จริงในคำขอนั้น ฝั่งตัวเลขสรุปมี gen_ai.client.token.usage ที่นับเป็นหน่วย token, gen_ai.client.operation.duration ที่นับเป็นวินาที, gen_ai.execute_tool.duration สำหรับเวลาที่หมดไปกับการเรียก toolแต่ละครั้ง และ gen_ai.invoke_agent.tool_calls ที่นับว่าagentเรียกใช้เครื่องมือไปกี่ครั้งในการทำงานหนึ่งรอบ นอกจากชุดกลางแล้ว มาตรฐานยังมีชุดเฉพาะของผู้ให้บริการแยกไว้ให้ openai, anthropic, Azure AI Inference และ AWS Bedrock ด้วย

เหตุผลที่ระบบ AI ต้องการ observability มากกว่าซอฟต์แวร์ทั่วไป อยู่ที่ความไม่คงที่ของผลลัพธ์ คำถามเดิมถามซ้ำอาจได้คำตอบคนละแบบ ทดสอบตอนพัฒนาผ่านหมดแล้วก็ยังพังได้ตอนผู้ใช้จริงถามในแบบที่ไม่มีใครคิดถึงมาก่อน เอกสารของ Langfuse ซึ่งเป็นเครื่องมือ tracing สาย open source พูดตรงกันว่าการไล่หาสาเหตุในระบบ AI โดยไม่มีเครื่องมือสังเกตการณ์นั้นแทบไม่ต่างจากการเดา และระบุว่า trace หนึ่งอันของเขาเก็บ prompt ที่ส่งออกไปจริง คำตอบที่ได้กลับมา จำนวน token ที่ใช้ เวลาที่หมดไป รวมถึงขั้นตอน tool และการค้นเอกสารที่แทรกอยู่ระหว่างกลาง ฝั่ง LangSmith ของ langchain ใช้คำต่างออกไปเล็กน้อยคือเรียกว่า run โดยนิยาม run ว่าเป็นงานหนึ่งชิ้นที่ agent ลงมือทำ และ trace คือกลุ่มของ run ที่อยู่ในงานเดียวกัน พร้อมบอกไว้ในเอกสารเองว่าถ้าคุ้นกับ OpenTelemetry อยู่แล้ว ให้คิดว่า run เทียบเท่า span ข้อมูลจำนวน token รายคำขอที่เครื่องมือกลุ่มนี้เก็บไว้ ยังเป็นวัตถุดิบตั้งต้นของการประเมินต้นทุนรวมด้วย เพราะมันตอบได้ว่าเงินหมดไปกับฟีเจอร์ไหนและผู้ใช้กลุ่มไหน

ข้อควรระวังข้อแรกคือสถานะของตัวมาตรฐานเอง เอกสาร GenAI semantic conventions ทั้งหน้า span และหน้า metric กำกับสถานะไว้ว่า Development ไม่ใช่ Stable และหน้าอธิบายระดับสถานะของ OpenTelemetry ที่เอกสารพวกนี้ลิงก์ไปหา ระบุว่าระดับ Development หมายถึงของที่ยังประกอบไม่ครบทุกส่วน ตัวเลือกการตั้งค่าอาจเปลี่ยนบ่อยตามทิศทางที่พัฒนาไป ไม่ควรนำไปใช้ในงานจริง และอาจถูกถอดออกได้โดยไม่แจ้งล่วงหน้า ในทางปฏิบัติแปลว่าถ้าองค์กรสร้างแดชบอร์ดหรือระบบแจ้งเตือนทับชื่อ attribute เหล่านี้ตรงๆ ต้องเผื่อแรงตามแก้เอาไว้ด้วย ข้อควรระวังข้อสองคือความเป็นส่วนตัว เพราะการเก็บข้อความเข้าออกทั้งก้อนลงใน span แปลว่าบทสนทนาของลูกค้าจะไปนั่งอยู่ในระบบ observability ด้วยอีกที่หนึ่ง ตัวมาตรฐานเองเตือนไว้ตรงๆ ว่า attribute ที่เก็บเนื้อหาข้อความมีโอกาสสูงที่จะมีข้อมูลส่วนบุคคลปนอยู่ องค์กรไทยที่อยู่ใต้pdpaจึงต้องตัดสินใจตั้งแต่วันแรกว่าจะเก็บข้อความเต็ม เก็บแบบปิดบังบางส่วน หรือเก็บแค่ตัวเลขสรุป

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

หัวหน้าฝ่ายบริการลูกค้า: "เมื่อวานบ่ายลูกค้าบอกว่าแชตบอตตอบเงื่อนไขประกันผิด เราย้อนดูได้ไหมว่ามันไปเอาข้อมูลมาจากไหน"

ทีมพัฒนา: "ได้ครับ เราเปิด tracing ไว้ ผมเปิดคำขอนั้นดูได้เลยว่าเรียกโมเดลตัวไหน ค้นเอกสารเจอกี่ชิ้น แล้วหยิบชิ้นไหนไปประกอบเป็นคำตอบ"

หัวหน้าฝ่ายบริการลูกค้า: "แล้วช่วงบ่ายที่คนบ่นว่ามันช้า เกิดจากอะไร"

ทีมพัฒนา: "อันนั้นดูจากเวลาของแต่ละ span ได้ครับ ถ้าเวลาส่วนใหญ่หมดไปกับ span ของการค้นเอกสารหรือการเรียก tool ไม่ใช่ span ของการเรียกโมเดล แปลว่าปัญหาอยู่ที่ระบบฝั่งเรา ไม่ใช่ที่ผู้ให้บริการโมเดล"

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

• evals : evals คือการวัดคุณภาพคำตอบด้วยชุดทดสอบที่เราเตรียมไว้ล่วงหน้า ส่วน observability คือการเฝ้าดูของจริงที่เกิดกับคำขอของผู้ใช้จริงหลังระบบขึ้นไปแล้ว ต้องมีคู่กันเพราะผ่าน eval ตอนพัฒนาไม่ได้แปลว่าจะไม่พังหน้างาน
• audit-log : audit log ตอบคำถามว่าใครทำอะไรเมื่อไหร่ เพื่องานตรวจสอบและกำกับดูแล ส่วน trace ตอบคำถามว่าระบบทำงานอย่างไรข้างใน เพื่องานแก้ปัญหาทางเทคนิค เก็บคนละชุดและใช้คนละงาน
• failure-attribution : failure attribution คือการชี้ว่าความผิดพลาดมาจากฝั่งไหน ตัวโมเดลเอง ระบบที่ครอบมันอยู่ เครื่องมือที่ต่อไว้ หรือชุดทดสอบเอง ส่วน observability คือชั้นที่เก็บร่องรอยของแต่ละขั้นตอนไว้ให้ ทำให้ชี้ต้นตอจากหลักฐานได้แทนการเดา