Trả lời ngắn: Tối ưu AI system là giảm cost hoặc latency trong các ràng buộc quality, safety và trải nghiệm đã định trước. Case support copilot dùng baseline, budget, quality floor, routing, caching và canary. Một thay đổi chỉ được nhận khi metric chính tốt hơn mà không làm slice quan trọng tụt dưới gate.

Đọc xong, bạn sẽ hiểu:

  • Vì sao cost, latency và quality thường tạo trade-off chứ không có một lựa chọn thắng mọi mặt.
  • Cách đặt baseline, budget và quality floor trước khi tối ưu.
  • Khi nào routing, caching, context trimming hoặc model tier là đòn bẩy phù hợp.
  • Cách dùng experiment, canary và rollback để tối ưu có kiểm soát.

Lưu ý giáo dục: Metrics, request và ID trong bài là dữ liệu giả. Không đưa production spend, token, prompt riêng hoặc customer data vào bài tập. Cost, threshold và quality floor phải được đo lại theo hệ thống, risk và chính sách của tổ chức.

1. Cost, latency và quality là ba trục nào?

Một support copilot route request vào queue. Có người muốn giảm hóa đơn, người khác muốn response nhanh, còn người vận hành giữ quality và high-impact handoff. Nếu chỉ tối ưu một trục, bạn có thể chuyển chi phí sang retry, chuyển latency sang lỗi, hoặc chuyển quality thành rủi ro.

Cost là tài nguyên tiền hoặc compute cho một request/flow, gồm model call, retrieval, tool, retry và storage liên quan. Latency là thời gian từ request đến response; p50 có thể đẹp nhưng p95/p99 vẫn làm người dùng chờ. Quality là output đúng, hữu ích, grounded và phù hợp mục tiêu. Quality nên xem theo slice: clear ticket, mixed-language, high-impact, tool-call và fallback.

Trục Câu hỏi Ví dụ metric giả
Cost Một request và một flow tốn gì? cost bucket, retry count
Latency Chặng nào làm người dùng chờ? p50/p95, timeout
Quality Output có đúng và an toàn không? routing accuracy, correction
Safety Có floor nào không được hy sinh? handoff, policy flag

Hình 1 — Không có một lựa chọn thắng mọi trục; quality và safety floor là ràng buộc trước khi nói đến “rẻ hơn”.

Hãy coi đây là constrained optimization: tìm phương án nằm trong cost/latency budget nhưng vẫn đạt quality floor. Quality floor là ngưỡng thấp nhất không được vượt qua theo hướng xấu; ví dụ high-impact handoff phải giữ 100% trong fixture. Đây không phải con số mặc định cho mọi sản phẩm.

2. Baseline, budget và quality floor

Trước khi đổi model hoặc prompt, ghi baseline cùng một evaluation set và traffic slice. Case giả có baseline: cost bucket C-01, p95 2,4 giây, routing accuracy 91%, mixed-language 86%, high-impact handoff 100%, retry 1,2%. Những số này chỉ để luyện cách đọc, không phải claim production.

Budget là giới hạn cost, latency hoặc error được chấp nhận. Đặt budget theo request class, vì request đơn giản và request cần retrieval dài không cùng profile. Quality floor cần có owner và action khi fail. Nếu metric quality chưa đáng tin, trạng thái đúng là NOT_VERIFIED, không tự gọi là pass.

Field Baseline giả Budget/floor Owner và action
Cost/request 1,00 unit ≤ 0,75 unit Finance/ops xem retry và tier
p95 latency 2,4s ≤ 2,2s Ops xem tail, timeout
Clear routing 91% ≥ 90% Quality replay
Mixed-language 86% ≥ 84% Review slice, không che average
High-impact handoff 100% = 100% Safety owner, block nếu fail

Hình 2 — Baseline card ghi cả metric chính, floor, owner và action; thiếu một ô thì quyết định tối ưu chưa đủ context.

Đo hidden cost: retries, fallback model, retrieval query, tool calls, cache miss và human review. Một dashboard chỉ tính model call có thể làm cost nhìn rẻ giả. Đo hidden latency tương tự: queue, network, retrieval, tool và post-processing. Khi version bundle thay đổi, ghi bundle ID để so cùng nền.

3. Chọn đòn bẩy tối ưu trong case support copilot

Case OPT-23 có năm đòn bẩy. Không bật tất cả cùng lúc; mỗi dòng là một hypothesis cần test.

Đòn bẩy Hypothesis Rủi ro cần giữ
Routing Request rõ đi model tier nhẹ sẽ giảm cost Mixed-language/high-impact bị route nhầm
Caching Policy giống nhau dùng cache sẽ giảm latency Cache stale hoặc scope sai
Context trim Bỏ context dư sẽ giảm token và latency Mất evidence grounding
Batching Gom work phù hợp sẽ tăng throughput Queue delay và tail latency
Fallback Khi timeout chuyển path an toàn sẽ giảm failure Fallback không ghi reason/version

Routing cần rule observable: request class, confidence, risk và reason. Không route high-impact sang tier rẻ chỉ vì confidence trung bình. Caching phải có freshness, scope, invalidation và fallback khi policy đổi. Context trimming cần test xem evidence quan trọng có còn không. Fallback là đường lui có điều kiện, không phải âm thầm đổi model.

Model tier cũng là một đòn bẩy, nhưng model name không nói hết behavior, quota, tool support hay provider drift. OpenAI model selection nhấn mạnh việc chọn model theo task và trade-off; quyết định cuối vẫn cần eval của workload thật. Azure AI architecture patterns đặt reliability, performance efficiency, security và operational excellence trong cùng bức tranh thay vì xem cost tách rời. Azure AI architecture patterns

4. Pareto trade-off, rollout và rollback

Pareto frontier là nhóm lựa chọn mà bạn không thể cải thiện một trục nếu không hy sinh trục khác. Candidate A rẻ hơn nhưng quality thấp hơn; B nhanh hơn nhưng cost cao hơn; C giữ quality nhưng chậm hơn. Không chọn bằng cảm giác. Chọn theo constraint và risk.

Thí nghiệm OPT-23-CANARY giữ prompt, eval set và safety rule; chỉ đổi routing cho clear requests. So candidate với baseline ở cost, p95, clear, mixed-language, high-impact, cache freshness và fallback rate. Nếu cost giảm 22% nhưng mixed-language giảm dưới floor, candidate bị block. Nếu cost giảm 8%, latency giảm 12%, quality giữ trong confidence phù hợp và handoff vẫn đạt, mới chuyển canary nhỏ.

Rollout gate:

  1. Baseline: snapshot metric, bundle và data slice.
  2. Experiment: đổi một lever, ghi hypothesis và observation riêng.
  3. Canary: traffic nhỏ hoặc fixture cohort, monitor tail và safety.
  4. Decision: approve, hold, iterate hoặc block theo floor.
  5. Rollback: trở về known-good nếu regression hoặc evidence thiếu.

Hình 3 — Optimization loop chỉ mở rộng khi cost/latency tốt hơn mà quality và safety gate vẫn đạt.

Rollback không chỉ là đổi tên model. Cần giữ routing rule, prompt/model/tool/retrieval bundle, cache policy, evaluator và runbook. Nếu cache đã chứa policy cũ, rollback phải nói cache nào invalidate. Nếu candidate tạo output không reproduce được, ghi NOT_REPRODUCIBLE và giữ rollout ở hold.

Azure AI observability mô tả việc nối signals để hiểu reliability và operations; theo đó, optimization nên có đo lường chứ không chỉ là chỉnh config. Azure AI observability

5. Sai lầm, giới hạn và fallback

  • Cost-only: giảm model tier rồi giấu quality slice. Fallback: quality floor, safety floor và fixed eval.
  • Average-only: p50 đẹp nhưng p95 timeout tăng. Fallback: percentile, slice và tail budget.
  • Quality gaming: đổi eval set để candidate pass. Fallback: frozen set, holdout và reviewer độc lập.
  • Cache stale: response nhanh nhưng policy đã đổi. Fallback: freshness/version check và invalidate.
  • Hidden retries: cost/latency thật bị đẩy vào child span không báo. Fallback: trace retry và budget per flow.
  • Unsafe cheap path: request rủi ro chạy model rẻ không có handoff. Fallback: route theo risk và block khi safety floor fail.
  • Vendor drift: model ID giữ nguyên nhưng behavior thay đổi. Fallback: canary, re-eval và change log.
  • No rollback: candidate tốt trên average nhưng không có known-good artifact. Fallback: giữ baseline immutable.

Tối ưu cũng có giới hạn kinh tế: cache có storage/invalidating cost, batching có queue delay, routing có classifier cost, quality review có human capacity. Vì vậy “tối ưu” là quyết định nhiều constraint, không phải săn một con số nhỏ nhất. NIST AI RMF nhấn mạnh quản trị và đo lường risk theo vòng đời; không nên hy sinh risk evidence để đạt một budget ngắn hạn. NIST AI RMF Core

6. Practice Bridge 15 phút

Mở Notes hoặc Google Sheets miễn phí, tạo cột experiment_id, baseline, lever, cost, p95, quality_floor, safety_floor, risk, owner, gate, rollback. Dùng số giả; không gọi model thật.

Mẫu đối chiếu đã điền

Experiment Lever và observation Gate / decision
OPT-01 Routing clear request; cost -12%, p95 -9%, quality giữ Canary 5%, monitor mixed-language
OPT-02 Cache policy; p95 -30%, freshness chưa kiểm HOLD, kiểm version/invalidation
OPT-03 Context trim; token -20%, handoff slice giảm BLOCKED, rollback trim
OPT-04 Model tier nhẹ; cost -25%, high-impact floor chưa chứng minh NOT_VERIFIED, chưa rollout

Trong 15 phút, thêm một hypothesis, một metric không được hy sinh, một owner và điều kiện rollback. Stop condition: nếu không có baseline, quality floor hoặc evidence cache freshness, giữ decision là HOLD, không gọi đó là optimization pass.

7. Tổng kết: tối ưu có ràng buộc

a. Năm ý chính

  • Cost, latency, quality và safety tạo trade-off; không có một metric đủ để chọn candidate.
  • Baseline, budget và quality floor phải được ghi trước khi thay đổi.
  • Routing, caching, context trim, batching và fallback đều cần hypothesis, visibility và risk check.
  • Pareto, canary, recovery gate và rollback giúp tối ưu theo evidence thay vì cảm giác.
  • Quality thiếu evidence, cache stale hoặc safety floor fail là lý do hold/block, dù cost đã giảm.

b. Câu hỏi tự kiểm tra

  • Vì sao cost giảm chưa chắc là hệ thống tốt hơn?
  • Quality floor khác budget cost thế nào?
  • Caching cần kiểm tra những điều kiện nào?
  • Khi nào candidate phải rollback hoặc giữ hold?

c. Gợi ý đáp án

Xem gợi ý câu 1

Cost có thể giảm do dùng model nhẹ nhưng quality, safety hoặc hidden retry lại xấu đi. Xem lại mục 1 và mục 5.

Xem gợi ý câu 2

Budget giới hạn tài nguyên; quality floor là ngưỡng behavior/safety thấp nhất không được hy sinh. Xem lại mục 2.

Xem gợi ý câu 3

Kiểm freshness, scope, version, invalidation và response có còn grounded không. Xem lại mục 3 và mục 5.

Xem gợi ý câu 4

Rollback hoặc hold khi quality/safety floor fail, evidence thiếu, regression xuất hiện hoặc known-good artifact chưa sẵn sàng. Xem lại mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Cost Tài nguyên tiền hoặc compute dùng cho request/flow.
Latency Thời gian từ request đến response, nên xem cả p95.
Quality Mức output đúng, hữu ích, grounded và phù hợp mục tiêu.
Quality floor Ngưỡng quality/safety thấp nhất không được vượt qua.
Budget Giới hạn cost, latency hoặc error được chấp nhận.
Routing Chọn model/tool/path theo request hoặc risk.
Caching Dùng lại kết quả khi freshness và scope cho phép.
Pareto frontier Các lựa chọn không cải thiện một trục mà không hy sinh trục khác.
Fallback Đường lui khi path chính không đạt điều kiện.
Rollback Quay về baseline/known-good khi candidate gây regression.

e. Nguồn tham khảo

Bài trước là AI Observability và Incident Response #22. Bài tiếp theo là Production AI Operating System #24.

Lưu ý giáo dục: Giảm cost chỉ là thành công khi quality và safety floor vẫn đạt, cache còn fresh, fallback có lý do và rollback còn artifact. Nếu evidence chưa đủ, giữ HOLD hoặc NOT_VERIFIED.