ROI tính một lần rồi để đó sẽ nhanh lỗi thời. Bạn cần instrument (gắn đo lường) vào chính agent để dữ liệu ROI chảy về liên tục. Bài này hướng dẫn thiết lập.
Ba nhóm sự kiện cần log
- Hoạt động: mỗi lần agent chạy — input, output, token dùng, độ trễ.
- Can thiệp của người: khi nào con người review, sửa, override.
- Kết quả: tác vụ thành công/thất bại, có bị làm lại không.
Ví dụ cụ thể: schema sự kiện
{
"event": "agent_run",
"run_id": "r_10293",
"use_case": "refund_review",
"tokens_in": 1820,
"tokens_out": 460,
"cost_vnd": 190,
"latency_ms": 3400,
"human_reviewed": true,
"human_edit_minutes": 2,
"outcome": "approved",
"was_corrected": false,
"timestamp": "2026-06-27T09:12:00Z"
}
Mỗi trường ánh xạ trực tiếp vào công thức chi phí/giá trị ở Bài 3–4. Đây là điểm mấu chốt: thiết kế log theo công thức ROI, không log bừa.
Các bước instrument
- Bắt đầu từ công thức ROI, liệt kê biến cần đo (tokens, review_minutes, error_rate...).
- Gắn emit sự kiện tại 3 điểm: khi agent chạy xong, khi người can thiệp, khi biết kết quả cuối.
- Chuẩn hóa đơn vị (tiền = VND, thời gian = phút) ngay khi ghi.
- Gắn
use_casevàrun_idđể truy vết và nhóm theo luồng. - Đẩy vào kho phân tích (bảng SQL, warehouse) chứ không để trong log text.
- Dựng truy vấn ROI chạy định kỳ.
Đoạn pseudocode gắn đo
def run_agent(task):
t0 = now()
result = llm_call(task) # gọi model
usage = result.usage
emit("agent_run", {
"run_id": task.id,
"use_case": task.use_case,
"tokens_in": usage.input,
"tokens_out": usage.output,
"cost_vnd": to_vnd(usage),
"latency_ms": now() - t0,
"outcome": result.status,
})
return result
def on_human_review(run_id, minutes, corrected):
emit("human_touch", {
"run_id": run_id,
"human_edit_minutes": minutes,
"was_corrected": corrected,
})
Truy vấn ROI mẫu (SQL)
SELECT use_case,
COUNT(*) AS runs,
SUM(cost_vnd) AS token_cost,
SUM(human_edit_minutes)/60.0*300000 AS review_cost,
AVG(CASE WHEN was_corrected THEN 1 ELSE 0 END) AS error_rate
FROM agent_events
WHERE ts >= date_trunc('month', now())
GROUP BY use_case;
Checklist instrument đạt chuẩn
- [ ] Mỗi biến trong công thức ROI có nguồn log tương ứng?
- [ ] Có ghi lại can thiệp của con người?
- [ ] Có trường xác định kết quả đúng/sai?
- [ ] Đơn vị tiền/thời gian đã chuẩn hóa?
- [ ] Dữ liệu vào được kho truy vấn, không kẹt trong log?
Sai lầm thường gặp
- Chỉ log token và latency (dễ lấy) rồi tưởng đủ — thiếu human và outcome là thiếu 2/3 bức tranh.
- Không gắn
use_case, khiến nhiều agent trộn số, không quy được ROI riêng. - Đo
was_correctedbằng cảm tính thay vì cơ chế rõ ràng (nút "sửa", diff output). - Log dạng text tự do, sau này không truy vấn được, phải parse thủ công.
Đo kết quả khi nó đến muộn (attribution trễ)
Một thách thức thực tế: kết quả không phải lúc nào cũng biết ngay khi agent chạy. Agent gợi ý sản phẩm hôm nay, nhưng khách mua sau 3 ngày. Agent duyệt hoàn tiền hôm nay, nhưng ca gian lận lộ ra sau 2 tuần. Nếu chỉ log tại thời điểm chạy, bạn sẽ bỏ sót outcome.
Giải pháp: thiết kế bảng liên kết trễ — lưu run_id và cập nhật trường outcome/was_corrected khi kết quả thật đến, qua job nền hoặc webhook. Đặt một cửa sổ chốt (ví dụ 14 ngày) sau đó mới tính ROI kỳ đó, để đủ thời gian outcome trễ về.
-- cập nhật outcome trễ
UPDATE agent_events
SET was_corrected = TRUE, outcome = 'reversed'
WHERE run_id = 'r_10293';
Nguyên tắc thiết kế: log để tính, không log để nhìn
Khác biệt giữa telemetry vận hành (dành cho debug) và telemetry ROI (dành cho tính tiền) rất quan trọng. Log debug quan tâm stack trace, prompt đầy đủ. Log ROI quan tâm số quy được ra tiền. Hãy tách hai luồng: đừng để log debug khổng lồ làm nghẽn kho phân tích, và đừng để log ROI thiếu trường vì mải log kỹ thuật.
Một mẹo kiểm tra nhanh: cầm công thức ROI ở Bài 4, chỉ vào từng biến và hỏi "trường log nào cấp số này?". Nếu có biến không trỏ được về trường nào, instrument của bạn còn lỗ hổng.
Có dòng dữ liệu này, Bài 6 sẽ dạy phân biệt vanity metrics với chỉ số thật sự phản ánh giá trị.