ระบบเว็บทั่วไปอาจเริ่ม monitor จาก availability, latency และ error rate แต่ AI workflow มี failure ที่ไม่ทำให้ server ล้ม เช่น retrieval ได้เอกสารผิด model สรุปเกินหลักฐาน หรือ tool สำเร็จด้วยผลลัพธ์ว่าง

จากมุมของ HTTP ทุกอย่างอาจดูปกติ:

POST /answer 200 OK
latency: 1.8s
body: "คำตอบที่อ่านเข้าใจง่าย"

แต่ status 200 บอกเพียง request สำเร็จตาม protocol ไม่ได้บอกว่า reasoning, evidence หรือ business outcome ถูกต้อง

HTTP 200 ไม่ได้แปลว่า AI workflow healthy

Observability ต้องเชื่อมตั้งแต่ infra และ model ไปถึง retrieval, tools, outcome, drift และ human escalation

จาก monitoring สู่ AI observability

Monitoring มักถามว่า service ยังทำงานหรือไม่ Observability ช่วยให้เราอธิบายได้ว่าทำไมผลลัพธ์จึงเป็นแบบนั้น สำหรับ AI ควรเชื่อมสัญญาณหลายชั้น:

  • request: latency, error, timeout และ request size
  • model: model version, token usage, cost และ output validation
  • retrieval: query, top-k, relevance, freshness และ permission filter
  • tools: tool name, arguments ที่ผ่านการปกปิด, duration, result status และ retry
  • outcome: groundedness, citation coverage, refusal และ human escalation
  • data: schema drift, null rate, freshness และ distribution shift

ไม่ใช่ทุก field ต้องถูกเก็บแบบ raw โดยเฉพาะข้อมูลส่วนตัวหรือเอกสารลับ ควรกำหนด retention, redaction และ access control ตั้งแต่เริ่มออกแบบ trace

Trace หนึ่งเส้นควรเล่าเรื่องได้

ตัวอย่าง trace ที่มีประโยชน์อาจหน้าตาประมาณนี้:

trace_id: 8f2a
  request                  40ms
  retrieve policy-v4      180ms  relevance=0.91 freshness=2d
  permission filter         4ms  allowed=3
  model.generate          920ms  tokens=1840
  answer.validation         8ms  citations=2 grounded=true
  final                    12ms  status=answered

ถ้า user report ว่าคำตอบผิด เราควรย้อนดูได้ว่าระบบค้นอะไร ส่ง context ใด และ validation ผ่านเพราะเงื่อนไขอะไร โดยไม่ต้องเก็บเนื้อหาลับทั้งหมดไว้ใน log

Metric ที่ดีต้องผูกกับคำถามการตัดสินใจ

อย่าเพิ่ม metric เพราะเก็บได้ง่าย ถามก่อนว่า metric นี้จะช่วยให้ใครตัดสินใจอะไร เช่น:

  • retrieval relevance ต่ำลง: ต้องปรับ index หรือ query strategy หรือไม่
  • citation coverage ลดลง: ต้องหยุดตอบหรือส่งต่อคนหรือไม่
  • tool retry สูงขึ้น: dependency มีปัญหาหรือ input เปลี่ยน
  • escalation rate สูงขึ้น: policy ใหม่ทำให้ระบบไม่มั่นใจ หรือ threshold เข้มขึ้น
  • token usage สูงขึ้น: context ใหญ่เกินและกำลังกลบหลักฐานสำคัญหรือไม่

evaluation score จากชุดทดสอบเป็นสัญญาณสำคัญ แต่ไม่ควรแทนที่ production evidence เพราะข้อมูลจริงและรูปแบบคำถามอาจเปลี่ยนไป

Drift มักมาก่อน incident

ระบบอาจยังตอบได้ แต่ distribution ของคำถามเปลี่ยน ผู้ใช้เริ่มถาม entity ใหม่ เอกสารอัปเดตถี่ขึ้น หรือ tool version เปลี่ยน ถ้าเราดูแค่ error rate จะไม่เห็นสัญญาณเหล่านี้

การเก็บ baseline แบบไม่เปิดเผยข้อมูล เช่น สัดส่วนประเภทคำถาม อายุของ source และจำนวนครั้งที่ไม่มีหลักฐาน ช่วยให้เห็นการเปลี่ยนแปลงโดยไม่ต้องอ่านข้อความทุกคำตอบ

สรุป

AI observability ไม่ใช่การเก็บ prompt และ response ทุกอย่าง แต่คือการทำให้เส้นทางจาก input ไปสู่ outcome อธิบายได้ ปลอดภัย และนำไปแก้ปัญหาได้

สิ่งที่ควรจำมีสามข้อ:

  1. HTTP 200 ไม่ได้แปลว่า AI workflow ถูกต้อง
  2. trace ต้องเชื่อม model, retrieval, tool, validation, evidence และ outcome
  3. metric ที่มีค่า คือ metric ที่ทำให้เราตัดสินใจเปลี่ยนระบบหรือส่งต่อให้คนได้

References

  • OpenTelemetry — Observability primer: ความสัมพันธ์ของ traces, metrics และ logs สำหรับอธิบายระบบ
  • OpenTelemetry — GenAI semantic conventions: สัญญาณสำหรับ model spans, agent spans, metrics และ events
  • Google for Developers — Production ML systems: Monitoring pipelines: การติดตาม data, model quality และ real-world metrics
  • Google SRE — Monitoring distributed systems: แยก symptom กับ cause และออกแบบสัญญาณที่ช่วยให้คนแก้ปัญหาได้