Bài 7 — Vận hành ROI theo thời gian: scale, drift và quyết định dừng

ROI không phải con số chốt một lần. Khi agent chạy thật, quy mô tăng, model đổi, chất lượng trôi (drift). Bài này dạy vận hành ROI như một chỉ số sống và biết khi nào nên dừng.

Ba lực làm ROI thay đổi

• Scale: volume tăng → token và review tăng tuyến tính, nhưng chi phí build đã cố định → ROI thường cải thiện khi scale (nếu chất lượng giữ).
• Drift: model đổi phiên bản, dữ liệu đầu vào đổi, prompt cũ kém đi → error_rate tăng âm thầm → chi phí sửa lỗi ăn mòn ROI.
• Học nghề (maturity): đội tin agent hơn → giảm giám sát → giảm chi phí ẩn.

Ví dụ cụ thể: ROI trôi vì drift

Agent phân loại ticket, tháng 1 error_rate 5%, Net +10 triệu/tháng. Tháng 4 nhà cung cấp cập nhật model; error_rate lặng lẽ lên 14%. Chi phí sửa lỗi và review tăng:

Tháng 1: net = value - (token + 5%*fix) = +10 triệu
Tháng 4: net = value - (token + 14%*fix) = +2 triệu

Không ai đổi gì rõ ràng, nhưng ROI rơi 80%. Nếu không giám sát error_rate (leading metric ở Bài 6), sẽ không ai phát hiện tới khi hóa đơn phình.

Các bước vận hành ROI liên tục

• Chạy lại truy vấn ROI định kỳ (tuần/tháng) từ dữ liệu instrument (Bài 5).
• Theo dõi leading metrics — error_rate, % human intervention — với ngưỡng cảnh báo.
• So với baseline đóng băng, không so với tháng trước (tránh trôi từ từ không nhận ra).
• Đặt guardrail chi phí: cảnh báo khi cost/task vượt X.
• Định kỳ tái đánh giá giả định (đơn giá lao động, volume dự báo).
• Ra quyết định: mở rộng, giữ, tối ưu, hay dừng.

Khung quyết định 4 cửa

Net dương & đang tăng      -> SCALE (mở rộng use case)
Net dương & đang giảm       -> INVESTIGATE (drift? sửa prompt/model)
Net âm nhưng cải thiện được  -> OPTIMIZE (giảm review, cắt token)
Net âm & không lối thoát     -> SUNSET (dừng, ghi nhận bài học)

Quyết định dừng không phải thất bại — dừng đúng lúc bảo vệ nguồn lực cho use case tốt hơn.

Cấu hình cảnh báo mẫu

alerts:
  - metric: error_rate
    threshold: 0.10        # vượt 10% thì cảnh báo
    window: 7d
  - metric: cost_per_success_vnd
    threshold: 15000
    window: 7d
  - metric: net_monthly_vnd
    threshold: 0           # chạm 0 -> họp review
    direction: below

Checklist review ROI định kỳ

• [ ] Net kỳ này so baseline đóng băng ra sao?
• [ ] Leading metric nào vượt ngưỡng?
• [ ] Chi phí nào tăng nhanh hơn giá trị?
• [ ] Giả định nào đã lỗi thời?
• [ ] Đang ở cửa nào trong khung 4 cửa?

Sai lầm thường gặp

• Đo ROI một lần rồi quên, bỏ lỡ drift âm thầm.
• So với tháng trước thay vì baseline, khiến suy giảm từ từ không lộ ra.
• Không có guardrail chi phí, phát hiện lỗ khi đã lỗ nhiều tháng.
• Ngại dừng vì đã đầu tư (sunk cost), tiếp tục đổ tiền vào use case âm.

Scale không phải lúc nào cũng cải thiện ROI

Trực giác nói scale luôn tốt vì trải chi phí build ra nhiều đơn vị hơn. Nhưng scale có thể phá ROI nếu:

• Mở sang loại tác vụ khó hơn — agent giỏi ca dễ, khi ép nó làm ca phức tạp thì error_rate và chi phí review tăng vọt.
• Vượt ngưỡng gói giá — nhà cung cấp LLM đổi bậc giá, hoặc bạn phải nâng hạ tầng theo nấc.
• Chi phí giám sát không giảm kịp — volume tăng gấp đôi nhưng đội review không tự động hóa được, chi phí ẩn tăng tuyến tính.

Vì vậy trước khi mở rộng, hãy chạy lại phép tính ROI cho phân khúc mới, đừng giả định ROI phân khúc cũ áp dụng được. Mở rộng có kiểm soát: thử một tập nhỏ của loại tác vụ mới, đo, rồi mới nhân rộng.

Guardrail: tự động hóa cả việc phát hiện suy giảm

Đừng dựa vào con người nhớ mở dashboard. Hãy để hệ thống tự cảnh báo. Ba guardrail tối thiểu: error_rate vượt ngưỡng, cost_per_success vượt ngưỡng, và net_monthly chạm 0. Khi một guardrail kích hoạt, nó buộc một cuộc họp review — biến ROI từ báo cáo bị động thành cơ chế phòng vệ chủ động. Đây là khác biệt giữa một dự án agent được quản trị và một dự án âm thầm ngốn tiền.

Bài 8 sẽ đóng gói tất cả thành một business case ROI trình bày được cho lãnh đạo.