# Metric Dictionary และกติกาการนับ

นิยามเหล่านี้เป็น protocol ตัวอย่างของบทความ ไม่ใช่ผล benchmark หรือมาตรฐานที่ผู้ให้บริการรับรอง

## หน่วยข้อมูลและตัวหาร

- Configuration = ผลิตภัณฑ์ + plan + region + build + permissions + memory state ที่บันทึก
- Task = prompt + fixture + oracle ฉบับ frozen
- Attempt = หนึ่งการเริ่มทำ task; internal tool retry ยังอยู่ใน attempt เดิม
- เริ่มใหม่จากผู้ทดสอบ = attempt ใหม่ ห้ามใช้ผลที่ดีที่สุดแทนหลายรอบ
- PASS ต้อง required criteria ครบและไม่มี critical action error
- FAIL / TIMEOUT / BLOCKED / CANCELLED หลังเริ่ม = attempted แต่ไม่ผ่าน
- INELIGIBLE ก่อนเริ่ม = N/A ไม่อยู่ใน denominator งานที่เริ่ม แต่ต้องรายงานจำนวนและเหตุผล
- ถ้าไม่มี attempted runs ให้ success rate เป็น N/A ไม่ใช่ 0%
- บันทึก denominator ต่อ metric; task ที่ไม่วัด memory ไม่ควรเพิ่ม memory denominator

## สูตรและหน่วย

| Metric | Formula / หน่วย | การตีความ |
|---|---|---|
| Strict task success | passes / attempted runs × 100 | แสดง passes/attempts เสมอ |
| Critical error rate | attempts with ≥1 critical error / attempts | รายงานจำนวน errors แยกด้วย |
| Grounded claim precision | correct-and-supported claims / checkable factual claims | นับ unsupported/stale เป็น error |
| Citation support | supported required claims / claims requiring citations | การมีลิงก์ไม่เท่ากับรองรับ claim |
| Elapsed p50 | median stopped_at-started_at ของทุก attempted run | รวม timeout, wait, retry |
| Successful completion p50 | median completion time เฉพาะ PASS | ต้องแสดง success rate และ timeout คู่กัน |
| Elapsed p95 | กำหนด percentile method ก่อนเริ่ม | sample น้อยให้แสดงค่าดิบหรือ N/A |
| Human minutes per success | human active minutes ทุก attempt / passes | รวมเวลาช่วยรอบที่ไม่ผ่าน |
| Fresh memory accuracy | correct latest-value probes / probes | แยก update/delete probes |
| Trigger recall | correctly detected expected events / expected events | ต้องรู้จำนวน event ที่ควรเกิด |
| Alert precision | relevant alerts / all delivered alerts | แยก duplicates, late alerts, quiet-hours violations |
| Recovery success | recovery cases restored correctly / injected cases | ยืนยันไม่เกิด action ซ้ำ |
| Technical cost per success | sum(plan allocation + usage + tools) / passes | ระบุ observation window และ allocation method |
| Fully loaded cost per success | (technical cost + human cost) / passes | ตัดสินใจด้วย sensitivity ของค่าเวลาคน |

Ratio ที่ denominator = 0 ให้ N/A พร้อมเหตุผล ไม่หารศูนย์ ไม่เติม 100%

## ห้ามซ่อน failure ด้วย latency

ถ้ารอบค้างครบ 300 วินาที ให้บันทึก TIMEOUT, elapsed=300 และ failure ไม่สมมติ completion=300 เพราะยังไม่สำเร็จ
รายงาน elapsed ของทุก attempt กับ completion ของเฉพาะ successful runs เป็นคนละสถิติ
p95 จากตัวอย่าง 5 รอบอาจดูเหมือนแม่นแต่สรุป tail reliability ไม่ได้ ชุด pilot เล็กให้แสดง raw durations, median และ timeout count แทน

## รวมหลาย task อย่างไร

- Micro success = passes ทุก task / attempts ทุก task; task ที่ลองมากมีน้ำหนักมาก
- Macro success = เฉลี่ย success rate ของแต่ละ task ที่มี attempts; ให้น้ำหนักแต่ละ workflow เท่ากัน
- แสดงผลราย task และ coverage ควบคู่ ห้ามให้ N/A หายไปจนดูเหมือนครอบคลุมเท่ากัน
- Common-task lane ใช้เทียบ capability ที่ input/permissions เทียบกันได้
- Product-native lane ใช้ดูความเหมาะกับ ecosystem; อย่ารวมเป็นอันดับเดียวกับ common lane
- ถ้าใช้ weighted composite ต้องกำหนดน้ำหนักก่อนเริ่ม และรายงาน critical errors แยก ไม่เฉลี่ยกลบ

## Subscription allocation

เลือกวิธีเดียวก่อนเริ่ม เช่น ค่าแผนของช่วง pilot × สัดส่วน usage ที่ workflow ใช้ โดยระบุว่าเป็น estimate หากไม่มี meter ที่แยกได้
ผลรวม allocation ทุก workflow ต้องไม่เกินค่าแผนของช่วงที่ใช้ และไม่ใช้เงิน plan ทั้งเดือนกับทุก attempt ซ้ำ
รายงาน incremental cash spend แยกจาก allocation เสมอ

## ความไม่แน่นอน

รายงาน numerator/denominator, task distribution, versions, dates และ exclusions
ไม่ตีความ 4/5 ว่าคุณภาพระยะยาวเป็น 80% แน่นอน หรือใช้ sample เล็กกล่าวว่าชนะทุกงาน