AI Agent Observability: คู่มือ Monitoring, SLA และ RFP สำหรับโรงงาน

AI Agent Observability คือความสามารถในการสร้างเส้นทางของคำขอทางธุรกิจกลับขึ้นมาได้ ไม่ใช่เพียงตรวจว่าได้คำตอบหรือไม่ แต่ต้องเห็นว่าคำขอนั้นผ่านโมเดล ข้อมูล เครื่องมือ และการอนุมัติใดก่อนเกิดผลลัพธ์ในการปฏิบัติงาน สำหรับภาคการผลิต conversation log อย่างเดียวไม่พอ ต้องเชื่อมเครื่องจักร รหัสสินค้า lot, work order, กะ เวลาโรงงาน การเรียก tool การแก้ไขของพนักงาน และต้นทุนด้วย correlation ID เดียว แล้วเปลี่ยนเป็นหลักฐานสำหรับตรวจจับความผิดปกติ วิเคราะห์สาเหตุ ตรวจ SLA และปรับปรุง บทความนี้อธิบายการออกแบบ telemetry, RFP, แผนดำเนินงาน 90 วันแบบเสนอแนะ และการตรวจรับสำหรับหลายโรงงาน รวมถึงไซต์ในประเทศไทย

ข้อสรุปก่อน: ต้องสังเกตทั้ง business session ไม่ใช่เฉพาะโมเดล

เวลาตอบของ LLM API เพียงอย่างเดียวไม่บอกคุณภาพการทำงานของ AI Agent เพราะ agent ผสาน retrieval, planning, การเลือก tool, การอ่าน ERP/MES, การรออนุมัติ, retry และ handoff คำตอบสุดท้ายอาจดูถูกต้องทั้งที่ agent อ่านข้อมูลต้องห้าม เลือก asset ผิด ทำคำขอเดียวซ้ำสองครั้ง หรือทำให้ operator ต้องแก้แบบเดิมทุกครั้ง

หน่วยสังเกตขั้นต่ำจึงไม่ใช่ model call แต่เป็น session ที่มีวัตถุประสงค์ทางธุรกิจ ภายใต้ session มี trace หนึ่งรายการหรือมากกว่า และแทน model generation, retrieval, tool call, approval, guardrail, external API และ human intervention เป็น span เอกสารทางการของ OpenAI Agents SDK ก็อธิบาย trace ว่าเป็น end-to-end workflow ซึ่งประกอบด้วย span ที่มีเวลาเริ่ม/จบและความสัมพันธ์ parent-child นี่เป็นตัวอย่าง implementation ที่มีประโยชน์ ไม่ใช่ข้อบังคับให้คัดลอกรูปแบบของผู้ขายรายเดียวเป็นมาตรฐานภายใน

บทความนี้จำกัดขอบเขตที่ telemetry และการวัดผลปฏิบัติการ ส่วน การดำเนินงาน AI Agent API เน้น platform/API, การประเมินต่อเนื่องและ audit ของ AI Agent เน้น evaluation และ reapproval และ AI Agent incident response เน้น containment และ recovery หลังเหตุ Observability เป็นชั้นขวางที่ส่งหลักฐานตามเวลาให้ทุกส่วน

โมเดลพื้นฐานของ AI Agent tracing

Session: วัตถุประสงค์งานและบริบทผู้ใช้

Session ไม่ใช่แค่เวลาที่อยู่ในหน้าต่าง chat แต่คือเป้าหมายเช่น “หาสาเหตุ Line 3 หยุดและเตรียม maintenance request” หรือ “ระบุชิ้นส่วนขาดและส่ง purchase request ไปรออนุมัติ” ควรเก็บ business case ID, site, user role, เวลาเริ่ม/จบ, outcome, business date ของโรงงาน, data classification และ policy version

หากงานต่อเนื่องถึงวันถัดไป ให้เชื่อมด้วย business ID แม้ระบบสร้าง conversation ใหม่ หาก chat เดียวจัดการหลาย work order ให้แต่ละ work order มี trace ของตัวเอง การแยกหน่วยตาม UI ออกจากหน่วยหลักฐานช่วยให้วิเคราะห์ต้นทุน คุณภาพ และความรับผิดชอบได้จริง

Trace: เส้นทางการทำงานไปยังผลลัพธ์หนึ่งรายการ

Trace คือเส้นทางจากคำขอไปยังผลลัพธ์ ควรมี session ID, ผู้เริ่ม, agent version, model configuration, เวลาเริ่ม/จบ, status, outcome และ external transaction ที่เกี่ยวข้อง เมื่อส่งต่องานไป agent อื่น ให้ใช้ parent trace หรือ trace link เพื่อค้นเส้นทางทั้งหมดได้

ไม่ควรอ้างว่า trace แสดงเหตุผลภายในโมเดลทั้งหมด สิ่งที่สังเกตได้คือ input/output ที่ได้รับอนุญาต แหล่ง retrieval, tool request, policy decision, approval, external response, เวลา และ usage การแยกข้อเท็จจริงที่สังเกตได้ออกจากสมมติฐานเรื่องเหตุผลภายในทำให้ audit น่าเชื่อถือกว่า

Span: หน่วย operation สำหรับแยก delay, failure และ owner

Span คือ operation ที่มีต้นและจบ เช่น model generation, RAG retrieval, data transformation, tool execution, approval wait หรือ human override อย่างน้อยควรมี span ID, parent span ID, operation, timestamp, status, error type, attempt, service, site, tool/model และ reference ของ input/output

Span ละเอียดมากไม่ได้แปลว่าดีกว่าเสมอไป เพราะเพิ่ม storage และเวลาสืบสวน หากหยาบเกินไปก็หาสาเหตุไม่ได้ หลักแยกที่ใช้งานได้คือ เมื่อ service ที่รับผิดชอบเปลี่ยน วิธี recovery เปลี่ยน หน่วยคิดค่าใช้จ่ายเปลี่ยน หรือเกิด approval/external side effect

เชื่อมบริบทโรงงานเข้ากับหลักฐาน

บริบททางกายภาพทำให้การ monitor agent ในโรงงานต่างจาก chatbot ทั่วไป คำว่า “ผิดปกติ” มีความหมายต่างกันตาม asset, product, lot, recipe, machine mode, shift, ความสดของ sensor และ maintenance state ควรเชื่อม trace กับ:

• site, area, line และ asset ID
• work order, batch, lot และ product code
• shift, UTC, เวลาท้องถิ่นและ time zone
• recipe/version และ PLC/MES/ERP transaction ID
• sensor snapshot, เวลาเก็บ, quality flag และ missing-data state
• model, prompt, policy, tool, connector และ knowledge-base version
• operator ID หรือ pseudonymous ID, role และ approval ID
• final business outcome และ quality/downtime/delivery record ที่ใช้ยืนยันภายหลัง

ไม่ควรคัดลอก sensor data และเอกสารทั้งหมดลง trace store ให้เก็บ snapshot ใน evidence repository แล้ววาง hash, timestamp, schema version และ reference ที่ควบคุมสิทธิ์ไว้ใน trace วิธีนี้ไม่ทำให้ telemetry กลายเป็น confidential data lake ใหม่ แต่ยัง reconstruct เหตุการณ์ได้

คุณภาพของนาฬิกาก็สำคัญ หาก cloud, terminal, MES, PLC และ camera มีเวลาไม่ตรงกัน เหตุอาจดูเหมือนเกิดก่อนสาเหตุ ให้บันทึก time source และ synchronization state ใช้ UTC เป็นแกนร่วมและแสดง ICT ให้คนหน้างาน ความไม่แน่นอนที่ระบุชัดดีกว่าลำดับเวลาที่แม่นยำแบบผิด ๆ

ออกแบบ LLM observability metrics เป็นห้าชั้น

1. Usage: ใครใช้อะไรเพื่อวัตถุประสงค์ใด

นับ session, active user, business process, site, shift, agent version และ completion state ปริมาณมากไม่ใช่ความสำเร็จโดยตัวมันเอง ต้องดูพร้อม quality, elapsed time, human effort และ outcome การพุ่งขึ้นอาจมาจาก adoption หรือ retry loop/UI fault ก็ได้

2. Reliability: completion, error, retry และ duplicate

แยก error, timeout, retry, partial completion, duplicate side effect, dead letter, tool denial, fallback และ abstention การ abstain อย่างปลอดภัยไม่เหมือน system error อัตรา abstention ที่เพิ่มอาจเป็นสัญญาณแรกของข้อมูลหายหรือคำขอนอก scope

3. Responsiveness: แยกเวลาที่ผู้ใช้รอ

วัด end-to-end latency, time to first response, model, retrieval, tool, approval และ queue time ค่าเฉลี่ยซ่อน peak และ long tail จึงควรใช้ percentile และ distribution เป้าหมายต้องกำหนดตาม use case เพราะงานวิเคราะห์คุณภาพกับงานช่วง line หยุดยอมรับเวลารอไม่เท่ากัน

4. Human collaboration: override, approval และ handoff

บันทึก approval request/outcome, human handoff, operator edit, override reason, จำนวนการกรอกใหม่ และเวลาค้าง override สูงอาจมาจากโมเดล แต่ก็อาจเกิดจาก master data ไม่ดี สิทธิ์ไม่พอ หน้าจอตรวจยาก หรือศัพท์หน้างานไม่ตรง ควรเก็บ reason code และ structured diff ไม่ใช่ free text อย่างเดียว

5. Value and cost: เชื่อมค่าโมเดลกับผลทางธุรกิจ

จัดสรร input/output token, model call, retrieval, external API, telemetry storage, evaluation และเวลาคน review ไปยัง business case นอกจาก cost per session สามารถเสนอ cost per completed case, per approved action หรือ per avoided manual minute เป็นตัวชี้วัดภายในแบบเสนอแนะ ต้องกำหนด baseline และความหมายของ “avoided” ก่อน พร้อมแยก estimate กับ actual

OpenTelemetry GenAI semantic conventions มี attribute สำหรับ model, operation, token, response ID, finish reason, time to first chunk, retrieval และ tool call เป็นจุดเริ่ม interoperability แต่ registry มี version และ attribute อาจย้ายหรือ deprecated ดังนั้น RFP ควร pin semantic-convention version และส่ง mapping table ไปยัง canonical field ภายใน

แบ่ง AI Agent SLA เป็นสามชั้น

“Availability 99.9%” ไม่พิสูจน์ว่า agent ทำงานธุรกิจเสร็จ ควรจัด SLA/SLO เป็น:

1. Technical service level: API availability, trace ingestion, tool connection, queue processing, monitoring delay
2. Agent execution level: session completion, end-to-end latency, error, abstention, duplicate side effect, approval wait
3. Business outcome level: การผูก work order ถูกต้อง การแก้ของ operator, processing time, deadline และ quality result

ค่าต่อไปนี้เป็นตัวอย่างเพื่อการออกแบบ ไม่ใช่มาตรฐานสากล

ต้องเปลี่ยนตัวเลขตามความเสียหาย ปริมาณ เวลารอที่ยอมรับได้ และ supervision งานปริมาณน้อยควรรายงานทั้งจำนวนและอัตรา NIST AI 600-1 เตือนเรื่องการพึ่ง quantitative metric มากเกินไปโดยไม่เข้าใจ context และ limitation Dashboard เป็นจุดเริ่มของการตัดสินใจ ไม่ใช่คำตอบสุดท้าย

มอง tool call เป็นบัญชีของ side effect

หลักฐานที่สำคัญมักไม่ใช่สิ่งที่ agent พูด แต่คือสิ่งที่ทำ ในแต่ละ tool call ควรเก็บ tool name/version, caller, target, operation, argument reference, policy decision, approval, idempotency key, request/response state, external transaction, retry และ compensation

Tool argument อาจมี supplier, ราคา, asset, ข้อมูลส่วนบุคคลหรือ token อย่าเก็บ raw argument โดยไม่จำกัด ให้กำหนด allow, mask, hash, drop หรือ secure-reference ราย field เช่น asset ID ค้นได้, free-text comment อยู่ใน classified storage, secret ห้าม log และยอดซื้อจำกัด role ที่ดูได้

Approval ควรเป็น span แยกและเทียบ payload hash ตอนเสนอเข้ากับตอน execute หาก target, quantity หรือ asset state เปลี่ยนหลังอนุมัติ ห้ามใช้ approval เดิม การ reject ก็ควรเก็บเหตุผล เวลารอ และทางเลือก เพราะช่วยปรับ permission และ UI

อย่ารวม error, abstention และ override

สถานะปฏิบัติการควรแยก:

• system error: service, network, authentication หรือ schema failure
• task failure: งานธุรกิจไม่สำเร็จ
• policy denial: policy ปฏิเสธตามที่ออกแบบ
• abstention: agent งดตอบ/ทำเพราะหลักฐานไม่พอหรือนอก scope
• human override: คนแก้หรือยกเลิกข้อเสนอ
• user abandonment: ผู้ใช้ออกจากงานระหว่างรอ
• partial completion: ทำเสร็จเพียงบางส่วน

ถ้านับทั้งหมดเป็น failure การปฏิเสธอย่างปลอดภัยจะกลายเป็น KPI ที่แย่และทีมมีแรงจูงใจลดการปฏิเสธ แต่ถ้ามอง abstention ว่าปลอดภัยเสมอ agent ก็อาจซ่อนข้อจำกัดที่ทำให้งานไม่สำเร็จได้ ควรกำหนด expected range ตาม use case แล้วใช้ reason code คู่กับ sample review

ตัดสิน redaction, minimization และ retention ก่อน

เอกสาร OpenAI Agents SDK ระบุว่า generation span อาจเก็บ model input/output และ function span อาจเก็บ tool input/output พร้อมมี setting ปิด sensitive-data capture เอกสาร Microsoft Foundry ก็เตือนว่า input, output และ tool arguments/results อาจเป็นข้อมูลอ่อนไหว จึงแนะนำไม่ใส่ secret, redact/minimize ก่อนเข้า telemetry และใช้ access/retention แบบ production

ควบคุมสี่จุด:

1. ก่อนเก็บ: ไม่ส่ง secret ผ่าน prompt หรือ tool; inject ที่ broker เมื่อจำเป็น
2. ตอน ingest: ตรวจชื่อ ข้อมูลติดต่อ ลูกค้า ราคา credential pattern แล้ว drop หรือ tokenize
3. หลังเก็บ: encryption, tenant/site separation, role access, audit และ expiry
4. ตอนแสดง: operation ทั่วไปเห็น summary; รายละเอียดลับต้องขอสิทธิ์

หลีกเลี่ยง “เก็บทุกอย่างแล้วค่อยคิด” กำหนด retention ตาม investigation, contract, quality, privacy, cost และการนำไปเรียนรู้ เช่น ordinary span 30 วัน aggregate 13 เดือน และเก็บเฉพาะ serious case นานขึ้นเป็นเพียงข้อเสนอหนึ่ง ต้องปรับตามกฎหมาย/ที่ปรึกษาท้องถิ่น สัญญาลูกค้าและระเบียบบริษัท

เอกสาร OpenAI ระบุด้วยว่า built-in tracing ใช้ไม่ได้สำหรับองค์กรที่ใช้ OpenAI API ภายใต้ Zero Data Retention policy ต้องตรวจ contract, configuration และ exporter จริง หากใช้ไม่ได้ให้มี internal OpenTelemetry collector หรือ business-event ledger อย่าสมมติว่าเห็นใน dashboard แปลว่าหลักฐานถูกเก็บ

ปรับ sampling ตามความเสี่ยงและคุณค่าหลักฐาน

อัตราเดียวทำให้ success log มูลค่าต่ำกินพื้นที่ ขณะที่ failure สำคัญอาจหลุด ข้อเสนอหลายชั้นคือ:

• เก็บ prohibited action, write tool, approval, override, error, policy denial และ critical asset 100%
• เพิ่ม new release, first site หรือ night shift เป็น 100% ชั่วคราว
• เก็บ detailed trace ตัวอย่าง 10–20% ของ read-only success ปกติ แต่ metric นับทุกงาน
• ใช้ tail-based sampling เก็บ trace ที่ latency, token, cost หรือ span count ผิดปกติ
• รักษาตัวแทนของ process, language, site และ shift

เปอร์เซ็นต์เหล่านี้เป็นตัวอย่าง แม้ detail ถูก sample ออก ควรเหลือ case ID, result, main metric และ external-transaction reference ขั้นต่ำ และ version sampling rule เพื่ออธิบายได้ว่าทำไมเวลานั้นไม่มีรายละเอียด

สถาปัตยกรรม observability ที่ไม่ผูกผู้ขาย

โครงสร้างใช้งานได้คือ agent runtime ส่ง telemetry แบบ OpenTelemetry หรือเทียบเท่าไป collector เพื่อ normalize schema, redact, sample และ route ไป trace, metric และ log/evidence store แล้วเชื่อม business DB, MES, ERP และ quality system ด้วย transaction/case ID UI เดียวอาจรวมข้อมูลได้ แต่ควรแยก original evidence จาก aggregate

AWS AgentCore เป็นตัวอย่างที่เก็บ metrics, spans และ logs ใน CloudWatch พร้อม trace visualization, custom span metrics และ error breakdown Microsoft Foundry เป็นตัวอย่าง review ราย span และส่งเข้า Application Insights ทั้งสองไม่ใช่คำรับรองการเลือกผลิตภัณฑ์ RFP ควรกำหนด export format, schema, location/region, encryption, search, cost, outage behavior และ portability แบบเป็นกลาง

ต้องออกแบบ collector failure ด้วย สำหรับ write สำคัญ ต้องเลือกว่าหลักฐานหายแล้ว block, buffer ใน local หรือทำ degraded mode ทดสอบ buffer เต็ม, network loss, replay, duplicate ingestion และ clock skew และใช้ idempotency key คนละชุดสำหรับ business side effect กับ telemetry delivery

คำถามใน AI Agent observability RFP

Data model และ correlation

• เชื่อม session, trace, span, business case และ external transaction อย่างไร
• แสดง multi-agent handoff, parallel tool, retry และ long-running job อย่างไร
• site, line, asset, work order, lot, shift ใดเป็น field มาตรฐาน
• pin/migrate schema และ semantic-convention version อย่างไร

Collection และ confidentiality

• เก็บ model/tool input/output โดย default หรือไม่ และตัด field รายการได้หรือไม่
• redact ก่อนส่งหรือหลังเก็บ และเมื่อ redaction ล้มเหลว default behavior คืออะไร
• จัดการ residency, encryption, key, access, retention และ legal hold อย่างไร
• ใครอนุมัติการเพิ่ม capture เพื่อ debug และตั้งหมดอายุอัตโนมัติอย่างไร

Performance, cost และ availability

• วัด overhead ต่อ latency, CPU และ network อย่างไร
• peak ingestion, buffer, backpressure และ drop policy คืออะไร
• จัดสรร token, tool, storage, query, egress เป็นราย case ได้หรือไม่
• หยุด high-risk write เมื่อ observability ใช้ไม่ได้หรือไม่

Operations และ evidence

• จาก alert ไปถึง trace, tool, external transaction ใช้กี่ขั้นตอน
• ส่งมอบ raw export, API, schema, dashboard, runbook และ training หรือไม่
• audit การเปลี่ยน alert, redaction, sampling, dashboard ได้หรือไม่
• นำ evidence และ setting ออกแบบมาตรฐานเมื่อจบสัญญาได้หรือไม่

ประเมินด้วยหน้าจอ export sample, failure test, เวลา search และ responsibility ไม่ใช่ checkbox “supported” ใส่การทดสอบ telemetry loss, correlation, redaction, sampling และ cost reproduction ใน gate การทดสอบรับมอบ AI Agent สำหรับการเขียน OT ต้องตอบโจทย์ privilege, execution broker และ safety layer ใน คู่มือความปลอดภัย Industrial AI Agent แยกต่างหาก

Roadmap ดำเนินงาน 90 วันที่เสนอ

นี่คือกำหนดการตัวอย่าง ไม่ใช่กฎสากล

วัน 0–15: กำหนด business ID และคำถามปฏิบัติการ

เริ่มจากหนึ่ง process หนึ่ง site เขียนคำถามที่ผู้ดูแลต้องตอบ: ทำไมช้า, tool ไหนพัง, ใครแก้, หนึ่ง case ราคาเท่าไร, ERP transaction สำเร็จหรือไม่ สำรวจ log, data classification, clock, transaction ID และ owner แล้วกำหนด minimum session/trace/span schema

อย่าเริ่มจากตกแต่ง dashboard ถ้า case ID เชื่อม UI, agent, tool และ external system ไม่ได้ graph สวยก็สืบสวนไม่ได้

วัน 16–30: ทำ instrumentation, redaction และ time

เพิ่ม span ให้ model, retrieval, tool, approval และ handoff normalize เป็น internal schema ที่ collector ทำ field policy สำหรับ secret, personal data, customer และ price ตรวจ UTC/local time, clock source และแยก development, validation, production

วัน 31–45: เชื่อม metric และ alert กับ outcome

รวม latency, error, retry, abstention, override, approval, token และ tool cost แล้ว reconcile กับ ERP/MES completion เริ่ม threshold ที่ระบุว่าเป็นข้อเสนอ ปรับจาก baseline สองสัปดาห์ ให้ alert ทุกตัวมี owner, runbook, severity, acknowledge expectation และ close condition

วัน 46–60: inject failure และ reconstruct evidence

ทดสอบ tool timeout, auth หมดอายุ, schema mismatch, collector outage, buffer เต็ม, approval หมดอายุ, duplicate retry และ clock skew ตรวจว่าสุ่ม business case หนึ่งรายการแล้วตาม trace, span, external transaction และ operator action ได้ และใช้ negative test ยืนยันว่าข้อมูลลับไม่รั่วใน search/export

วัน 61–75: ปรับ SLO, sampling และ cost

เสนอ p95, error budget, override review และ cost anomaly ตาม use case แล้วอนุมัติจากค่าจริงและ loss impact ทดสอบ full capture สำหรับ high risk และ sample low-risk success ปรับ storage/query cost, network และ alert workload ให้สมดุลกับคุณค่าหลักฐาน

วัน 76–90: ตรวจรับและ handover

รวบรวมหลักฐานเทียบ FAT/SAT โดยใช้กะกลางวัน/กลางคืน input ไทย/อังกฤษ/ญี่ปุ่น สภาพ network จริง และการเปลี่ยนผู้รับผิดชอบ ตรวจว่า operation ค้นหา ตั้ง cause hypothesis ตรวจ redaction ปิด alert และ export ได้โดยไม่พึ่งผู้ขาย หากขาดเล็กน้อยให้ conditional acceptance พร้อม owner, deadline, workaround, retest; หากขาดหลักฐานสำคัญให้หยุด production

ทำหลักฐานรับมอบให้ทำซ้ำได้

อย่างน้อยควรมี case ต่อไปนี้:

1. ตามคำขอหนึ่งรายการจาก session ถึง external transaction
2. ความสัมพันธ์ parallel tool, handoff และ retry ไม่หาย
3. ระบุ model/tool version, policy และ knowledge snapshot ได้
4. แยก latency เป็น queue, model, retrieval, tool, approval ได้
5. จำแนก error, abstention, denial, override, abandonment ได้
6. เทียบ write argument, approval, idempotency และ result ได้
7. secret และ field ที่กำหนดไม่ปรากฏใน trace, log, dashboard, export
8. ตรวจ loss/duplicate หลัง collector outage/reconnect ได้
9. detail ที่ sample ออกยังมี case/result reference ขั้นต่ำ
10. คำนวณ cost ต่อ case ใหม่พร้อมหลักฐานได้
11. เชื่อม UTC/plant time, asset, work order และ lot ถูกต้อง
12. operator ใช้ runbook และเก็บ close reason ได้

เชื่อม requirement ID, test ID, trace ID, expected/actual, evidence, reviewer, defect และ retest เก็บ machine-readable export กับ query ไม่ใช่ screenshot อย่างเดียว และต้องรัน case เดิมได้หลังเปลี่ยน dashboard หรือ platform

ความต่างในการปฏิบัติงานที่ต้องตรวจในไซต์ไทย

แนวทาง Generative AI Governance ของ ETDA กล่าวถึงข้อจำกัดด้าน domain context, freshness, explainability และ output consistency พร้อมแนะนำ human participation และการติดตามเทคโนโลยี อีกทั้งแบ่ง adopter, customizer และ maker โรงงานที่ใช้ SaaS, โรงงานที่สร้าง RAG/tool เอง และองค์กรที่สร้างโมเดลจึงไม่ได้เป็นเจ้าของ telemetry scope เท่ากัน

ในไซต์ไทยควรรวมชื่อ/ตัวย่อเครื่องจักรท้องถิ่น กะ approver ในพื้นที่ เวลา ICT และ network condition ไม่ใช่เฉพาะ policy ภาษาญี่ปุ่น การเปรียบเทียบ abstention/override ตามภาษาโดยไม่ดู volume และ task difficulty จะผิด ควรให้คน review case ตัวแทนและจำแนกสาเหตุเป็น translation, master data, UI หรือ permission

สิทธิ์ดูควรต่างกันด้วย เช่นสำนักงานใหญ่ดู aggregate/cross-site เจ้าของไซต์ดูรายละเอียดไซต์ security ขอ trace ลับตามขั้นตอน และ supplier เห็นเฉพาะชุด pseudonymized นี่เป็นตัวอย่างการออกแบบ ต้องยืนยันด้วยสัญญา privacy และข้อกำหนดแรงงาน

ความผิดพลาดที่พบบ่อย

เก็บ conversation ทั้งหมดแล้วเรียกว่า monitor

Conversation ไม่แสดง tool side effect, approval หรือ external result แต่เพิ่มข้อมูลลับมาก ควรใช้ structured ID/event และลดเนื้อหา

ดูเฉพาะ average model API latency

ผู้ใช้รอ queue, retrieval, tool และ approval ด้วย ค่าเฉลี่ยซ่อน peak/long tail ต้องแสดง end-to-end และ span percentile

มี dashboard แต่ไม่กำหนดการตอบสนอง

กราฟแดงไม่ทำให้งานดีขึ้น ต้องมี owner, threshold, runbook, deadline, close condition ต่อ metric และการลบ alert ที่รบกวนก็เป็นงาน operation

เลือกระหว่างเก็บทั้งหมดกับ sample เท่ากันทั้งหมด

การปฏิบัติต่อ risky write กับ routine read เหมือนกันจะเสียหลักฐานหรืองบประมาณ ควรผสม risk-, tail- และ release-based sampling

ใช้ vendor UI เป็นหลักฐานอย่างเดียว

เมื่อยกเลิกสัญญา ระบบล่ม หรือเปลี่ยนผลิตภัณฑ์อาจดูไม่ได้ ต้องระบุ raw export, schema, query, setting, retention และ migration ในสัญญา

FAQ: AI Agent monitoring และ SLA

AI Agent Observability ต่างจาก monitoring ทั่วไปอย่างไร

เพิ่ม session, generation, retrieval, tool, approval, human correction, business outcome และ cost บน CPU, memory และ API availability เป็นการขยาย APM ไม่ใช่ทิ้ง APM

Tracing แสดง chain of thought ได้หรือไม่

ไม่จำเป็นต้องแสดงเหตุผลภายในทั้งหมด มันแสดง input/output, event, retrieval, tool, approval, policy, เวลา และ version ที่ตั้งใจเก็บ ต้องแยก observed fact จาก causal hypothesis

อะไรควรเก็บ 100%

ไม่มีคำตอบเดียว high-risk write, approval, prohibited action, error, override และ critical asset เป็นตัวเลือกสำหรับ structured evidence ครบ ไม่ได้หมายถึงเก็บ raw text ทั้งหมด

ตั้งตัวเลข AI Agent SLA อย่างไร

ใช้ business loss, volume, acceptable delay, human fallback และ data quality ทำ baseline แล้วตั้งสามชั้น technical, execution, business outcome แทนการคัด benchmark ภายนอก

ถ้า log แพง ควรลดอะไรก่อน

ลด duplicate content, success detail มูลค่าต่ำ และ retention ที่ยาวเกินไป เก็บ metric สำคัญกับ correlation ID และใช้ risk-based sampling, compression, tiered storage การลดก่อนเก็บช่วยทั้ง privacy และ cost

Observability ทำให้ agent ปลอดภัยหรือไม่

ไม่ มันช่วย detect, reconstruct และ learn ยังต้องมี permission, deterministic constraint, approval, safety PLC, incident response และ continuous evaluation แยกกัน อย่าสับสนระหว่างมองเห็นกับควบคุม

สรุป: ตามหนึ่ง business case ไปถึงหลักฐานและต้นทุน

หัวใจของ AI Agent Observability ไม่ใช่เพิ่ม log แต่คือเชื่อม session, trace และ span กับ business case, asset, work order, lot, tool, approval, human intervention, external transaction และ cost ให้ทีม operation reconstruct ได้ ต้องแยก error, abstention, override; แยก latency; ลดข้อมูลลับก่อนเก็บ; sample ตามความเสี่ยง ใน RFP ให้ตอบ schema, export, redaction, retention, outage behavior และ portability ด้วยหลักฐาน แล้วตรวจ correlation, fault injection, SLO และ handover ในแผน 90 วันที่เสนอ

TOMAS TECH สามารถช่วยจัด ID, permission และ log เดิมของโรงงานให้เป็น AI Agent Observability RFP, แผน 90 วัน และ acceptance case ก่อนเลือกผลิตภัณฑ์ หากต้องการเริ่มจากการกำหนดว่า process ใด หลักฐานใด และใครเป็น owner ติดต่อ TOMAS TECH

เอกสารอ้างอิง

• OpenAI Agents SDK, Tracing: https://openai.github.io/openai-agents-python/tracing/
• OpenTelemetry, GenAI semantic conventions attribute registry: https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/
• AWS, Amazon Bedrock AgentCore Observability: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html
• Microsoft, Set Up Tracing for AI Agents in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/trace-agent-setup
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, AI 600-1: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
• ETDA, Generative AI Governance Guideline for Organizations v2.0: https://www.etda.or.th/getattachment/6050a4b7-defd-4dba-8cbc-ff6a444a3d08/20241125-Generative-AI-Guideline_V2-0.pdf.aspx