BigQuery เปิด Observability ของ Data Agent แบบ GA วัด latency และต้นทุน

Google Cloud ระบุใน release notes วันที่ 2 พฤศจิกายน 2026 ว่าการติดตาม data agent และบทสนทนาด้วย Google Cloud Observability ใน BigQuery พร้อมใช้งานทั่วไปแล้ว ทีมที่ให้ผู้ใช้ถามข้อมูลด้วยภาษาธรรมชาติสามารถดูทั้งการใช้งาน ความเร็ว และต้นทุนของ agent แทนการประเมินจากตัวอย่างบทสนทนาไม่กี่รายการ ข่าวนี้แยกจากการเก็บ conversation log ลงตาราง BigQuery ซึ่งเป็นอีกความสามารถหนึ่ง: observability เน้นตัวชี้วัดระดับโปรเจกต์และ trace ของการทำงาน ส่วน conversation logging ใช้ดูเนื้อหาแต่ละรอบสนทนาเมื่อเปิดแยกต่างหาก

ตัวชี้วัดที่ใช้ตอบคำถามเชิงปฏิบัติการ

คู่มือ Google ระบุว่าดูจำนวน agent ที่ถูกใช้ จำนวนผู้ถาม จำนวนบทสนทนา agent ที่ตอบมากที่สุด แหล่งความรู้ที่ถูกใช้บ่อย engagement ของผู้ใช้ ปริมาณ token ที่คาดการณ์ และ latency ของคำตอบรายชั่วโมงได้ ตัวเลขเหล่านี้ช่วยแยกปัญหาคนละแบบ ถ้าจำนวนผู้ใช้เพิ่มแต่จำนวนบทสนทนาต่อคนลด อาจต้องดูคุณภาพคำตอบหรือการค้นพบ agent ถ้า latency เพิ่มเฉพาะบางช่วง ให้ดู trace ของ model call และ tool call ว่าจุดใดช้า ส่วน token usage ควรเทียบกับจำนวนคำถามที่ตอบสำเร็จเพื่อดูประสิทธิภาพ ไม่ตีความว่าการใช้ token มากเป็นความสำเร็จโดยตัวมันเอง

หลังเปิด agent observability ผู้ดูแลสามารถดู dashboard ชื่อ BigQuery Conversational Analytics ใน Cloud Monitoring และดู metric รายตัวจาก Metrics explorer คู่มือระบุหมวด metric ของ agent, model call, tool usage, health, latency และ token usage สำหรับการแก้ปัญหารายบทสนทนา Cloud Trace แสดงลำดับ span ของ model call กับ tool call ภายในหนึ่งรอบคำถาม ช่วยแยกว่าเวลาหายไปกับการเรียกโมเดล การอ่านแหล่งข้อมูล หรือการทำงานของเครื่องมือปลายทาง ควรเก็บตัวอย่าง trace ของกรณีช้าพร้อม query หรือแหล่งความรู้ที่เกี่ยวข้องในระดับที่ไม่เปิดเผยข้อมูลอ่อนไหว

สิทธิ์และการเก็บข้อมูลต้องตั้งใจเลือก

ก่อนเปิดใช้ต้องตรวจ Cloud Trace, Cloud Monitoring และ Cloud Logging API ตามคู่มือ การให้ทีมดู metric ไม่จำเป็นต้องให้สิทธิ์แก้ agent หรือเปิดข้อมูลทุกชุด ตัวอย่าง role สำหรับการอ่านมี Monitoring Viewer, Cloud Trace User และ Logs Viewer ส่วนการดู dataset ต้องมี BigQuery Data Viewer ตามขอบเขตที่จำเป็น ผู้ดูแลควรแยกคนที่ตั้งค่า observability ออกจากคนที่ดู dashboard และตรวจว่าข้อมูลใน trace หรือ log มีตัวระบุผู้ใช้หรือข้อความคำถามที่ต้องจำกัดสิทธิ์หรือไม่

Google ระบุว่า trace ใน observability dataset เก็บ 30 วัน หากต้องวิเคราะห์ย้อนหลังนานกว่านั้น คู่มือเสนอให้เชื่อม dataset ของ Cloud Trace กับ BigQuery แล้วคัดลอกข้อมูลเข้า dataset เก็บระยะยาวด้วย scheduled query การทำเช่นนี้เพิ่มต้นทุนและภาระจัดการข้อมูล จึงควรกำหนด retention, สิทธิ์อ่าน และการลบข้อมูลก่อนเริ่มเก็บทุก span ไม่ควรเปิดการส่งต่อระยะยาวโดยไม่มีวัตถุประสงค์วัดผลที่ชัดเจน

ใช้ข้อมูลเพื่อปรับ agent อย่างไร

เริ่มจากตั้ง baseline ของคำถามทั่วไปและคำถามยากในแต่ละ agent วัด latency, model call, tool call และ token ต่อคำตอบที่ถูกต้อง เมื่อมีการแก้คำสั่ง agent หรือเพิ่ม knowledge source ให้เทียบกับ baseline เดิม หาก metric ดีขึ้นแต่คำตอบผิดมากขึ้น การเปลี่ยนยังไม่ถือว่าสำเร็จ ทีมควรจับคู่ dashboard กับชุดประเมินความถูกต้องและ feedback จากผู้ใช้ โดยใช้ conversation logging เฉพาะเมื่อจำเป็นต้องวิเคราะห์เนื้อหารายคำถามและผ่านข้อกำหนดข้อมูลขององค์กร

ความพร้อมแบบ GA ของ observability ทำให้การดูแล data agent ใน BigQuery ใกล้เคียงการดูแลบริการซอฟต์แวร์อื่นมากขึ้น แต่ metric เป็นสัญญาณสำหรับตรวจ ไม่ใช่คำตัดสินว่าคำตอบถูกต้องเสมอ การวาง alert, trace และการประเมินคำตอบร่วมกันจะให้ภาพที่ใช้แก้ปัญหาได้จริง

แหล่งข่าว: Google Cloud release notes วันที่ 2 พฤศจิกายน 2026 และ คู่มือสร้างและติดตาม data agents