Đây là bài tổng kết (capstone) của module 10 và của toàn bộ khóa học. Chúng ta sẽ đi qua toàn bộ vòng đời tối ưu token — từ đo baseline (đường cơ sở), xác định cơ hội, triển khai từng optimization, đo lại kết quả, đến dựng monitoring (giám sát) lâu dài — trên một case study xuyên suốt duy nhất: một pipeline agentic thực tế dùng để review pull request (PR) trên GitHub.

Mọi con số, đoạn code, và ID optimization (OPT-001 đến OPT-006) trong bài này được thiết kế để nhất quán từ đầu đến cuối. Bạn có thể dùng chính bài viết này như một audit template (mẫu kiểm toán) cho hệ thống agentic của riêng mình.

The Scenario: The PR Review Pipeline

Đội ngũ nền tảng (platform team) tại một công ty SaaS quy mô trung bình (khoảng 140 kỹ sư) đã xây dựng một agentic workflow tên là PR Reviewer Agent. Mỗi khi có PR mới được mở trên GitHub, agent này sẽ:

1. Lấy diff (phần thay đổi code) của PR qua GitHub API.
2. Truy xuất context liên quan bằng RAG (Retrieval-Augmented Generation — sinh nội dung có truy xuất tài liệu): coding convention của team, kiến trúc module liên quan, các PR tương tự đã review trước đó.
3. Gửi toàn bộ context + diff cho một LLM (Large Language Model) để sinh review: liệt kê bug tiềm ẩn, vấn đề style, đề xuất refactor, và điểm rủi ro bảo mật.
4. Post comment review trở lại GitHub PR.

Pipeline này chạy production được 5 tháng. Số lượng PR trung bình: 1.100 PR/tháng. Chi phí LLM tháng gần nhất: $4.360, đứng thứ hai trong toàn bộ chi phí AI của công ty, chỉ sau chatbot hỗ trợ khách hàng. Latency (độ trễ) trung bình từ lúc mở PR đến khi có comment review: 38 giây — engineer bắt đầu phàn nàn vì thời gian chờ quá lâu khi cần merge gấp.

Ban lãnh đạo kỹ thuật giao nhiệm vụ: audit toàn diện pipeline này, tìm mọi chỗ đang lãng phí token, tối ưu mà không làm giảm chất lượng review, và dựng cơ chế giám sát để chi phí không âm thầm phình to trở lại như đã từng xảy ra với pipeline chatbot hỗ trợ khách hàng trước đó.

Mẹo: Trước khi động vào bất kỳ dòng code nào, hãy xác định rõ metric thành công cuối cùng ("chi phí/PR giảm X%, latency giảm Y%, chất lượng review không đổi") và viết nó ra thành văn bản, gửi cho stakeholder đồng thuận trước. Một audit không có mục tiêu rõ ràng dễ biến thành chuỗi tối ưu ngẫu hứng, không ai đo được thành công thật sự.

Phase 1: Establishing the Baseline

Không thể tối ưu cái mình không đo được. Trước khi đề xuất bất kỳ thay đổi nào, việc đầu tiên là gắn instrumentation (đo đạc) vào pipeline hiện tại và thu thập dữ liệu baseline trong ít nhất một đến hai tuần chạy thực tế — không phải dữ liệu giả lập.

Step 1.1: Deploy Instrumentation

Pipeline PR Reviewer Agent được viết bằng Python, dùng LangChain-style orchestration gọi tới OpenAI GPT-4o. Điểm vào (entry point) là hàm review_pull_request(). Chúng ta thêm một decorator/wrapper ghi log token ở từng bước, không sửa logic nghiệp vụ:

import time
import json
import logging
from dataclasses import dataclass, asdict
from datetime import datetime, timezone

logger = logging.getLogger("token_audit")

@dataclass
class StepUsage:
    step_name: str
    input_tokens: int
    output_tokens: int
    cached_tokens: int
    latency_ms: int
    model: str

@dataclass
class PipelineRunRecord:
    pr_id: str
    repo: str
    diff_lines: int
    started_at: str
    steps: list
    total_input_tokens: int
    total_output_tokens: int
    total_cached_tokens: int
    total_latency_ms: int
    estimated_cost_usd: float

PRICE_INPUT_PER_M = 2.50
PRICE_OUTPUT_PER_M = 10.00
PRICE_CACHED_INPUT_PER_M = 1.25  # cached input tokens billed at 50%

def estimate_cost(input_tokens, output_tokens, cached_tokens):
    billable_input = max(input_tokens - cached_tokens, 0)
    cost = (
        billable_input / 1_000_000 * PRICE_INPUT_PER_M
        + cached_tokens / 1_000_000 * PRICE_CACHED_INPUT_PER_M
        + output_tokens / 1_000_000 * PRICE_OUTPUT_PER_M
    )
    return round(cost, 5)

def instrumented_step(step_name, model):
    def decorator(fn):
        def wrapper(*args, **kwargs):
            start = time.perf_counter()
            result, usage = fn(*args, **kwargs)
            elapsed_ms = int((time.perf_counter() - start) * 1000)
            step = StepUsage(
                step_name=step_name,
                input_tokens=usage.get("input_tokens", 0),
                output_tokens=usage.get("output_tokens", 0),
                cached_tokens=usage.get("cached_tokens", 0),
                latency_ms=elapsed_ms,
                model=model,
            )
            _CURRENT_RUN_STEPS.append(step)
            return result
        return wrapper
    return decorator

_CURRENT_RUN_STEPS = []

def review_pull_request(pr_id, repo, diff_text):
    global _CURRENT_RUN_STEPS
    _CURRENT_RUN_STEPS = []
    run_start = datetime.now(timezone.utc)

    context = fetch_rag_context(pr_id, diff_text)      # instrumented
    review = generate_review(pr_id, diff_text, context)  # instrumented
    post_comment_to_github(pr_id, review)

    total_input = sum(s.input_tokens for s in _CURRENT_RUN_STEPS)
    total_output = sum(s.output_tokens for s in _CURRENT_RUN_STEPS)
    total_cached = sum(s.cached_tokens for s in _CURRENT_RUN_STEPS)
    total_latency = sum(s.latency_ms for s in _CURRENT_RUN_STEPS)

    record = PipelineRunRecord(
        pr_id=pr_id,
        repo=repo,
        diff_lines=diff_text.count("\n"),
        started_at=run_start.isoformat(),
        steps=[asdict(s) for s in _CURRENT_RUN_STEPS],
        total_input_tokens=total_input,
        total_output_tokens=total_output,
        total_cached_tokens=total_cached,
        total_latency_ms=total_latency,
        estimated_cost_usd=estimate_cost(total_input, total_output, total_cached),
    )
    logger.info(json.dumps(asdict(record)))
    return review

Mỗi bản ghi (PipelineRunRecord) được đẩy vào một bảng pipeline_runs trong data warehouse (qua log shipper có sẵn), để sau này truy vấn bằng SQL. Chúng ta bật instrumentation này và để chạy tự nhiên trong 14 ngày, không đổi bất kỳ logic nào của pipeline.

Step 1.2: Analyze the Baseline Data

Sau 14 ngày, thu được 1.512 bản ghi run (tương ứng ~1.512 PR được mở/review trong giai đoạn này, cao hơn trung bình tháng vì có một đợt release lớn). Truy vấn tổng hợp:

Phân rã input token theo bước (breakdown theo step_name):

Con số RAG context chiếm 60,2% ngay lập tức là điểm nghi vấn số một. Đào sâu hơn, phát hiện thứ hai — nghiêm trọng hơn — nằm ở dòng "Conversation history": 583 token/PR trung bình, nhưng khi vẽ phân phối (distribution) thì có một nhóm PR với history token tăng dần theo thời gian trong ngày, có PR lên tới 6.200 token history. Kiểm tra code phát hiện session ID được cache theo repo thay vì theo pr_id — nghĩa là lịch sử hội thoại của PR trước bị "dính" sang PR sau trong cùng repo (đây sẽ là OPT-001, mô tả chi tiết ở Phase 3).

Vẽ thêm biểu đồ phân phối token theo diff_lines cho thấy quan hệ gần tuyến tính giữa số dòng diff và output token — hợp lý, PR to thì review dài hơn — nhưng có một cụm PR rất nhỏ (dưới 15 dòng thay đổi, ví dụ sửa version string, cập nhật changelog) vẫn tốn input token gần bằng PR trung bình, vì RAG context và system prompt không co giãn theo độ phức tạp của PR. Đây gợi ý cơ hội model routing (OPT-006).

Mẹo: Khi phân tích baseline, đừng chỉ nhìn số trung bình (mean) — luôn vẽ thêm percentile (p50/p90/p99) và phân phối theo một biến độc lập có ý nghĩa nghiệp vụ (ở đây là diff_lines). Bug OPT-001 gần như vô hình nếu chỉ nhìn số trung bình, vì đa số PR vẫn có history bằng 0; nó chỉ lộ ra khi nhìn vào đuôi phân phối (tail).

Phase 2: Identifying and Prioritizing Optimization Opportunities

Có dữ liệu baseline rồi, bước tiếp theo là biến quan sát thành danh sách hành động cụ thể, sau đó xếp hạng để biết làm cái nào trước.

Step 2.1: Build the Opportunity Map

Từ phân tích Phase 1, nhóm audit lập ra opportunity map (bản đồ cơ hội tối ưu) gồm 6 mục, mỗi mục gán một ID để theo dõi suốt phần còn lại của dự án:

Mẹo: Luôn tách rõ hai loại "tiết kiệm": tiết kiệm số token (giảm input/output tokens thực) và tiết kiệm chi phí trên mỗi token (caching, model routing). Hai loại này cộng dồn khác nhau và không nên gộp chung một cột trong bảng ưu tiên, kẻo tính trùng lợi ích.

Step 2.2: Prioritize by Impact × Risk

Nhóm dùng ma trận Impact × Risk (Effort) đơn giản để xếp thứ tự triển khai — impact tính theo % giảm chi phí ước tính, risk tính theo khả năng ảnh hưởng chất lượng review:

1. OPT-001 (Impact: thấp-trung, Risk: rất thấp) — làm ngay lập tức, đây là bug thật, không cần A/B test, chỉ cần fix và merge.
2. OPT-003 (Impact: trung bình về chi phí, Risk: rất thấp) — làm ngay sau OPT-001, prompt caching gần như không có downside kỹ thuật.
3. OPT-002 (Impact: cao, Risk: trung bình) — cần A/B test vì rút gọn system prompt có thể làm review sót lỗi.
4. OPT-005 (Impact: trung bình, Risk: thấp-trung) — A/B test nhanh, độc lập với các optimization khác.
5. OPT-004 (Impact: cao nhất về số token, Risk: trung bình) — cần A/B test kỹ nhất vì đụng tới RAG, ảnh hưởng trực tiếp đến "nguyên liệu" mà LLM dùng để review.
6. OPT-006 (Impact: cao về chi phí cho nhóm PR nhỏ, Risk: cao nhất) — làm sau cùng, cần eval set (bộ dữ liệu đánh giá) đầy đủ để đảm bảo model rẻ hơn không làm giảm chất lượng review trên PR nhỏ.

Thứ tự này không phải ngẫu nhiên: các optimization rủi ro thấp, không cần A/B test đi trước để "ăn điểm nhanh" (quick win) và giảm nhiễu dữ liệu; các optimization có rủi ro chất lượng cao được xếp cuối và đo độc lập, tránh nhiều thay đổi chồng lên nhau khiến không biết cái nào gây ra vấn đề nếu có sự cố.

Mẹo: Khi xếp ưu tiên, luôn hỏi thêm "nếu optimization này sai, mức độ rollback (hoàn tác) dễ tới đâu?". OPT-001 và OPT-003 rollback trong vài phút (revert 1 file). OPT-006 nếu sai thì hậu quả là review chất lượng thấp bị post công khai lên PR của người khác — rollback code dễ, nhưng "rollback" uy tín thì khó, nên cần eval set chặt trước khi ship, không chỉ dựa vào A/B test nhanh.

Phase 3: Implementing the Optimizations

Từng optimization được triển khai theo đúng thứ tự ưu tiên ở Phase 2, có đo lường trước/sau (before/after) riêng cho từng bước để cô lập tác động.

Step 3.1: Ship OPT-001 — Fix the History Bug

Nguyên nhân gốc: session key được tạo bằng repo name, nên mọi PR trong cùng repo share chung lịch sử hội thoại với LLM. Với repo có nhiều PR mở liên tiếp trong ngày, history tích lũy dần đến khi bị dọn theo TTL (time-to-live).

def get_session_key(repo, pr_id):
    return f"session:{repo}"  # BUG: no pr_id — history leaks across PRs

def generate_review(pr_id, diff_text, context):
    session_key = get_session_key(repo="acme/billing-service", pr_id=pr_id)
    history = session_store.get(session_key, default=[])
    messages = [SYSTEM_PROMPT] + history + [
        {"role": "user", "content": build_review_prompt(diff_text, context)}
    ]
    response = llm_client.chat(messages=messages, model="gpt-4o")
    history.append({"role": "user", "content": diff_text})
    history.append({"role": "assistant", "content": response.text})
    session_store.set(session_key, history, ttl_seconds=3600)
    return response

def get_session_key(repo, pr_id):
    return f"session:{repo}:{pr_id}"  # scoped to the individual PR

def generate_review(pr_id, diff_text, context):
    session_key = get_session_key(repo="acme/billing-service", pr_id=pr_id)
    history = session_store.get(session_key, default=[])
    messages = [SYSTEM_PROMPT] + history + [
        {"role": "user", "content": build_review_prompt(diff_text, context)}
    ]
    response = llm_client.chat(messages=messages, model="gpt-4o")
    # A PR review is a single-turn interaction — no need to persist history
    # unless a human explicitly replies asking the bot to re-review.
    session_store.set(session_key, [], ttl_seconds=1800)
    return response

Thực ra, sau khi phân tích kỹ workflow, nhóm nhận ra pipeline không cần giữ lại history giữa các lượt gọi cho từng PR — mỗi PR chỉ được review một lần khi mở, và review lại (nếu có commit mới) nên là một lượt độc lập, không cần model "nhớ" review trước để tránh review cũ ảnh hưởng đánh giá review mới. Vì vậy quyết định cuối: bỏ hẳn history, không chỉ scope theo pr_id.

Kết quả đo được sau 3 ngày chạy song song (canary 10% traffic):

Tiết kiệm trung bình khiêm tốn (~450 token, ~2,4%), nhưng p99 giảm mạnh (~24%) — đúng như dự đoán, vì bug này chủ yếu gây hại ở đuôi phân phối. Không phát hiện thay đổi bất lợi nào về chất lượng review (bug fix thuần túy, không đổi nội dung prompt).

Mẹo: Bug loại "context/history leak" như OPT-001 thường không xuất hiện rõ ở số trung bình mà ở p99/p999 và ở chi phí biến động theo giờ trong ngày. Nếu dashboard của bạn chỉ hiển thị trung bình theo ngày, hãy thêm biểu đồ theo giờ để bắt được các bug tích lũy dần này.

Step 3.2: Enable Prompt Caching (OPT-003)

Phần "tĩnh" của prompt — system prompt, coding convention của team, mô tả kiến trúc module — lặp lại giống nhau ở mọi request, chỉ có diff và RAG context là thay đổi theo PR. Đây là ứng viên lý tưởng cho prompt caching (đưa vào cache để lần gọi sau tính phí input thấp hơn).

def build_messages(diff_text, context):
    return [
        {"role": "system", "content": STATIC_SYSTEM_PROMPT},       # cached
        {"role": "system", "content": STATIC_CODING_CONVENTIONS},  # cached
        {"role": "user", "content": f"PR diff:\n{diff_text}\n\nContext:\n{context}"},
    ]

response = llm_client.chat(
    messages=build_messages(diff_text, context),
    model="gpt-4o",
)

response = anthropic_client.messages.create(
    model="claude-sonnet-5",
    system=[
        {
            "type": "text",
            "text": STATIC_SYSTEM_PROMPT + "\n\n" + STATIC_CODING_CONVENTIONS,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        {"role": "user", "content": f"PR diff:\n{diff_text}\n\nContext:\n{context}"}
    ],
)

Vì pipeline hiện tại dùng GPT-4o, nhóm dùng cơ chế OpenAI Prompt Caching (tự động, không cần đổi cấu trúc code nhiều, chỉ cần đảm bảo phần static đứng đầu và ổn định). Sau khi tách rõ STATIC_SYSTEM_PROMPT khỏi phần động, và đảm bảo request tới liên tục (khoảng cách giữa các PR review trong giờ làm việc thường dưới 5 phút, đủ để cache còn "nóng"):

Lưu ý quan trọng: caching không giảm số token gửi đi, nó giảm chi phí của phần token trùng lặp (billed ở mức 50% giá input thường với OpenAI). Vì phần cache-hit hiện tại mới chỉ là system prompt (1.847 token, sẽ giảm tiếp sau OPT-002), impact còn khiêm tốn — nhưng đây là bước đệm quan trọng để các optimization sau (đặc biệt OPT-004 khi coding convention cũng được cache) nhân đôi hiệu quả.

Mẹo: Đặt phần static prompt ở đúng vị trí đầu tiên trong messages và giữ nội dung byte-for-byte giống nhau giữa các lượt gọi — chỉ một khoảng trắng thừa hoặc timestamp chèn vào system prompt cũng làm cache miss toàn bộ. Kiểm tra cache hit rate qua field cached_tokens trong response usage mỗi ngày để phát hiện sớm nếu có thay đổi vô tình làm hỏng cache.

Step 3.3: Run A/B Test for System Prompt Compression (OPT-002)

System prompt gốc (1.847 token) được viết qua nhiều lần chỉnh sửa bởi nhiều người trong 5 tháng, tích tụ nhiều đoạn hướng dẫn trùng lặp và ví dụ dài dòng. Nhóm viết lại từ đầu, giữ nguyên ý định nghiệp vụ nhưng nén cấu trúc.

You are an expert senior software engineer performing a thorough code
review on a pull request. Your job is extremely important because...
[3 đoạn văn giải thích tầm quan trọng của code review, lịch sử tại sao
 team áp dụng automated review, và triết lý review của công ty]

When reviewing, you should consider the following categories of issues:
1. Bugs and logic errors — please look very carefully for...
   [đoạn dài 180 token giải thích khái niệm "off-by-one error" bằng ví dụ]
2. Security vulnerabilities — including but not limited to SQL injection,
   XSS, insecure deserialization... [đoạn dài 210 token liệt kê OWASP Top 10
   đầy đủ kèm định nghĩa từng loại]
3. Code style — please refer to our style guide which states that...
   [dán nguyên 340 token coding convention, lặp lại nội dung đã có ở
   phần RAG context riêng]
... (tiếp tục 4 category nữa, mỗi category có ví dụ dài)

Please format your response as a friendly, encouraging code review comment,
remembering that the developer put effort into this PR and may feel
discouraged by criticism, so always start with something positive...
[đoạn hướng dẫn tone/văn phong dài 150 token]

You are a senior code reviewer. Review the PR diff and RAG context below.
Report findings in these categories, in order of severity:
1. Bugs/logic errors  2. Security issues  3. Style violations (see
   provided conventions — do not restate them)  4. Missing tests
   5. Performance concerns

Rules:
- Cite specific line numbers from the diff.
- Skip a category entirely if there is nothing to report — do not write
  "No issues found" filler.
- Tone: direct, constructive, no filler praise. One positive note max,
  only if genuinely warranted.
- Output format: structured list per category, max 2 sentences per finding.

Thiết kế A/B test: 50% traffic dùng CONTROL (prompt gốc), 50% dùng TREATMENT (prompt nén), chạy trong 9 ngày, tổng 1.348 PR (674 mỗi nhóm — traffic thấp hơn baseline vì giai đoạn này không trùng đợt release lớn). Đánh giá chất lượng bằng hai cách: (1) LLM-judge chấm điểm review trên thang 1-5 dựa trên rubric cố định (độ chính xác, độ đầy đủ, tính hữu ích), (2) lấy mẫu 60 PR mỗi nhóm cho 2 senior engineer review chéo, chấm độc lập không biết review nào thuộc nhóm nào (blind).

Kết quả: TREATMENT không chỉ ngang bằng mà còn nhích cao hơn một chút ở điểm human review — vì bỏ được filler ("no issues found", lời khen sáo rỗng) khiến review đọc gọn và đúng trọng tâm hơn. Nhóm quyết định roll out TREATMENT cho 100% traffic. Giảm 1.133 token/PR ở phần system prompt (phần này còn được nhân thêm lợi ích nhờ OPT-003, vì phần cache-hit giờ nhỏ hơn nhưng tỷ lệ cache-hit trên tổng vẫn giữ nguyên).

Mẹo: Khi A/B test việc rút gọn prompt, luôn có ít nhất một kênh đánh giá con người song song với LLM-judge. LLM-judge có thể tự thiên vị theo văn phong (ví dụ ưu ái review dài, "có vẻ chuyên nghiệp") mà không phản ánh đúng cảm nhận thực của dev nhận review.

Step 3.4: A/B Test Output Format Constraints (OPT-005)

Output gốc thường có các đoạn diễn giải dư: mở đầu bằng lời chào, kết thúc bằng tóm tắt lặp lại nội dung đã nói, và với mỗi finding thường viết 3-4 câu thay vì 1-2 câu súc tích. TREATMENT system prompt ở Step 3.3 đã có một phần ràng buộc format ("max 2 sentences per finding"), nhưng nhóm muốn đo tách riêng tác động của chỉ ràng buộc format, không trộn với việc nén toàn bộ system prompt, nên chạy A/B test riêng: giữ system prompt TREATMENT (714 token) cố định ở cả hai nhóm, chỉ khác nhau ở việc có thêm constraint output cứng (yêu cầu trả JSON theo schema cố định với field max_length cho mỗi finding) hay không.

Chạy 7 ngày, 1.190 PR (595 mỗi nhóm). Ép output theo JSON schema có severity, line_number, finding (giới hạn độ dài qua hướng dẫn trong prompt, kiểm tra hậu kỳ bằng script cắt bớt nếu vượt), sau đó render lại thành markdown comment khi post lên GitHub. Giảm 221 token output/PR (~36%), đồng thời cải thiện luôn trải nghiệm đọc — ép format buộc model phải chọn lọc thông tin quan trọng nhất thay vì viết dài dòng.

Mẹo: Ràng buộc output đừng chỉ nói "ngắn gọn" trong prompt bằng lời — hãy cụ thể hóa bằng schema (JSON Schema, hoặc ví dụ few-shot có độ dài mẫu) và validate hậu kỳ. Model tuân theo cấu trúc cụ thể tốt hơn nhiều so với chỉ dẫn mơ hồ như "please be concise".

Step 3.5: A/B Test RAG Relevance Filtering (OPT-004)

Đây là cơ hội lớn nhất về số token tuyệt đối. Bước retrieval hiện tại lấy top-15 chunk có điểm similarity cao nhất từ vector store (chứa coding convention, tài liệu kiến trúc, và các PR review cũ), nhưng không lọc theo ngưỡng liên quan — nhiều chunk có similarity thấp (0.3-0.45 trên thang 0-1) vẫn được nhồi hết vào prompt, chiếm chỗ mà không đóng góp giá trị.

Giải pháp: thêm bước lọc theo ngưỡng similarity, và giảm top-k xuống động theo độ phức tạp diff, thay vì cố định 15 chunk cho mọi PR.

CONTROL: giữ nguyên top-15, không lọc ngưỡng. TREATMENT: lọc ngưỡng similarity ≥ 0.62, tối đa 8 chunk, và loại bỏ chunk trùng lặp nội dung >80% với chunk đã chọn (dedupe). Chạy 12 ngày (RAG là phần rủi ro cao nhất nên cần thời gian dài hơn để đủ tin cậy thống kê), 1.780 PR (890 mỗi nhóm).

Kết quả cho thấy giả thuyết ban đầu đúng: phần lớn RAG context bị nhồi vào không giúp gì, thậm chí đôi khi khiến model "lạc đề" dẫn ra quy tắc không liên quan tới diff đang review. Giảm được 5.590 token/PR (~50% phần RAG) mà chất lượng human-rated còn nhích lên. Nhóm rollout TREATMENT 100%, đồng thời thêm log riêng theo dõi % PR có similarity cao nhất của chunk retrieved dưới 0.62 (dấu hiệu vector store thiếu tài liệu liên quan cho loại PR đó, cần bổ sung).

Mẹo: Khi lọc RAG theo ngưỡng similarity, đừng chọn ngưỡng theo cảm tính — vẽ histogram similarity score của toàn bộ chunk được retrieve trong baseline, tìm điểm "gãy" tự nhiên trong phân phối (ở case này, phần lớn chunk hữu ích rơi vào 0.6-0.9, phần lớn chunk nhiễu rơi dưới 0.5) để chọn ngưỡng có cơ sở dữ liệu, không phải đoán.

Step 3.6: A/B Test Model Routing for Small PRs (OPT-006)

Từ Step 1.2, nhóm biết ~22% PR có diff dưới 20 dòng (sửa version, changelog, comment, config nhỏ) nhưng vẫn tốn input token gần với PR trung bình. Ý tưởng: route các PR này sang GPT-4o-mini (rẻ hơn ~85% token input, ~94% token output so với GPT-4o) thay vì GPT-4o.

Rủi ro lớn nhất: model rẻ hơn có thể bỏ sót bug tinh vi dù diff nhỏ (một dòng sửa off-by-one hay đổi dấu so sánh có thể gây hậu quả lớn dù diff chỉ 3 dòng). Vì vậy bước validate chất lượng phải nghiêm ngặt hơn các optimization trước, không chỉ dựa vào A/B test traffic thật.

results = {"gpt-4o": [], "gpt-4o-mini": []}

for pr in eval_set:  # 200 small PRs, includes 34 known "regretted merges"
    for model_name in ["gpt-4o", "gpt-4o-mini"]:
        review = generate_review(pr.id, pr.diff, pr.rag_context, model=model_name)
        caught_known_bug = (
            pr.has_known_bug and bug_matches_review(pr.known_bug_desc, review)
        )
        results[model_name].append({
            "pr_id": pr.id,
            "has_known_bug": pr.has_known_bug,
            "caught_known_bug": caught_known_bug,
            "judge_score": llm_judge_score(review, pr.rubric),
        })

def summarize(model_name):
    rows = results[model_name]
    known_bug_rows = [r for r in rows if r["has_known_bug"]]
    recall = sum(r["caught_known_bug"] for r in known_bug_rows) / len(known_bug_rows)
    avg_score = sum(r["judge_score"] for r in rows) / len(rows)
    return {"bug_recall": recall, "avg_judge_score": avg_score}

Kết quả eval set (200 PR nhỏ, gồm 34 "known regretted merges"):

Recall 79,4% của GPT-4o-mini thấp hơn GPT-4o (88,2%) — chênh lệch 8,8 điểm phần trăm, tương đương khoảng 3 PR trong 34 case có thể bị bỏ sót bug nếu route toàn bộ PR nhỏ sang model rẻ. Nhóm coi đây là rủi ro không thể chấp nhận cho toàn bộ 22% PR nhỏ, nhưng nhận thấy phần lớn bug bị bỏ sót rơi vào PR đụng tới logic nghiệp vụ (business logic) dù diff ngắn, còn PR thuần "sửa văn bản" (đổi version, changelog, comment, docstring, config format) — chiếm khoảng 14% trong 22% PR nhỏ — thì cả hai model đạt recall 100% (không có known bug nào thuộc nhóm này trong 5 tháng qua).

Quyết định cuối: thu hẹp phạm vi routing — chỉ route sang GPT-4o-mini khi diff dưới 20 dòng và không chạm vào file code thực thi (.py, .js, .go, v.v., xác định qua extension và path pattern, loại trừ file test/docs/config được liệt trong allowlist riêng: CHANGELOG.md, *.md, version bump file, .github/workflows không tính là "chạm code thực thi" theo định nghĩa hẹp này — trừ khi thay đổi step logic). Với phạm vi thu hẹp này (14% tổng PR, không phải 22%), rerun eval set con (49 PR thuộc nhóm này, không có known bug case) cho kết quả recall N/A (không có ground truth bug) nhưng judge score 4.09 (GPT-4o-mini) so với 4.12 (GPT-4o) — chênh lệch không đáng kể, được coi là an toàn để rollout.

Mẹo: Model routing dựa trên "kích thước" (số dòng diff) không đủ — hãy kết hợp thêm tiêu chí loại thay đổi (code thực thi vs. văn bản/config/docs). Một PR 3 dòng sửa logic thanh toán nguy hiểm hơn nhiều một PR 80 dòng chỉ đổi câu chữ trong README, dù diff dài hơn. Luôn giữ lại một eval set có "known regretted merges" thực tế — đây là ground truth đáng tin cậy nhất để đo recall của model rẻ hơn.

Phase 4: Measuring the Cumulative Impact

Sau khi rollout đủ 6 optimization (OPT-001 đến OPT-006), nhóm chạy lại đúng phương pháp đo ở Phase 1 trong 14 ngày để có baseline "after" so sánh táo với táo.

Cumulative Results Dashboard

Đóng góp của từng optimization vào tổng mức giảm chi phí (ước tính phân bổ theo thứ tự triển khai, không cộng tuyến tính do tương tác giữa các bước):

Tổng mức giảm chi phí 69,8% vượt cả mục tiêu ban đầu ban lãnh đạo đề ra (giảm 50%), đồng thời latency giảm 43,5% (giải quyết luôn phàn nàn của engineer về thời gian chờ) và chất lượng review — đo bằng cả LLM-judge và con người — không những không giảm mà còn nhích lên nhẹ, vì loại bỏ được nhiễu (filler text, RAG context không liên quan) giúp model tập trung vào tín hiệu thật.

Mẹo: Khi trình bày cumulative dashboard cho stakeholder không rành kỹ thuật, luôn dẫn đầu bằng ba số: % giảm chi phí, % giảm latency, và xác nhận chất lượng không đổi/tốt hơn (kèm nguồn đo — LLM-judge và con người). Bảng phân rã đóng góp theo từng OPT-xxx là để nội bộ team kỹ thuật học lại, không cần đưa hết vào slide cho lãnh đạo.

Phase 5: Establishing Ongoing Monitoring

Chi phí giảm 69,8% là vô nghĩa nếu 6 tháng sau nó lại âm thầm phình to trở lại — đúng như đã xảy ra với pipeline chatbot hỗ trợ khách hàng trước đây, khi không ai theo dõi. Vì vậy bước cuối cùng của bất kỳ audit token nào là dựng cơ chế giám sát liên tục.

Monitoring Configuration

"""
Chạy mỗi giờ qua cron/scheduler, đọc dữ liệu 24h gần nhất từ bảng
pipeline_runs, so sánh với benchmark đã thiết lập sau audit, và bắn alert
qua Slack webhook nếu vượt ngưỡng.
"""
import requests

BENCHMARKS = {
    "avg_input_tokens_per_pr": 6210,
    "avg_output_tokens_per_pr": 391,
    "avg_cost_per_pr_usd": 0.0159,
    "cache_hit_rate_min": 0.08,   # cảnh báo nếu cache hit rate tụt dưới 8%
    "p99_input_tokens": 12500,
}

ALERT_THRESHOLDS = {
    "avg_input_tokens_per_pr": 1.15,   # cảnh báo nếu vượt 115% benchmark
    "avg_output_tokens_per_pr": 1.20,
    "avg_cost_per_pr_usd": 1.15,
    "p99_input_tokens": 1.25,
}

SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/T000/B000/XXXX"

def fetch_last_24h_stats():
    # Query thật trỏ vào data warehouse; ở đây minh họa cấu trúc kết quả
    return query_warehouse("""
        SELECT
            AVG(total_input_tokens)  AS avg_input_tokens_per_pr,
            AVG(total_output_tokens) AS avg_output_tokens_per_pr,
            AVG(estimated_cost_usd)  AS avg_cost_per_pr_usd,
            AVG(total_cached_tokens * 1.0 / NULLIF(total_input_tokens, 0))
                                      AS cache_hit_rate,
            PERCENTILE_CONT(total_input_tokens, 0.99) AS p99_input_tokens
        FROM pipeline_runs
        WHERE started_at >= NOW() - INTERVAL '24 hours'
    """)

def check_and_alert():
    stats = fetch_last_24h_stats()
    breaches = []

    for metric, threshold_ratio in ALERT_THRESHOLDS.items():
        benchmark = BENCHMARKS[metric]
        actual = stats[metric]
        if actual > benchmark * threshold_ratio:
            breaches.append(
                f"- `{metric}`: actual={actual:.2f} vs benchmark={benchmark:.2f} "
                f"(+{(actual/benchmark - 1) * 100:.1f}%)"
            )

    if stats["cache_hit_rate"] < BENCHMARKS["cache_hit_rate_min"]:
        breaches.append(
            f"- `cache_hit_rate`: actual={stats['cache_hit_rate']:.1%} "
            f"below minimum {BENCHMARKS['cache_hit_rate_min']:.1%} "
            f"— possible cache-breaking change in system prompt"
        )

    if breaches:
        send_slack_alert(breaches)

def send_slack_alert(breaches):
    message = (
        ":rotating_light: *PR Reviewer Agent — Token Budget Alert*\n"
        + "\n".join(breaches)
        + "\n\nRunbook: <link tới Reusable Audit Template ở Phase 6>"
    )
    requests.post(SLACK_WEBHOOK_URL, json={"text": message}, timeout=10)

if __name__ == "__main__":
    check_and_alert()

Script này chạy mỗi giờ qua cron job, so sánh dữ liệu 24h gần nhất với benchmark cố định (chốt ngay sau audit), và bắn alert vào channel Slack #platform-ai-costs nếu vượt ngưỡng 15-25% (tùy metric). Ngưỡng cache_hit_rate_min đặc biệt quan trọng — nó là "cảm biến sớm" phát hiện nếu có ai vô tình sửa system prompt (thêm timestamp, đổi một ký tự) làm hỏng cache mà không ai để ý, vì chi phí chỉ tăng dần chứ không tăng đột ngột.

Mẹo: Đặt ngưỡng alert dựa trên benchmark sau audit, không phải baseline trước audit — nếu không, hệ thống sẽ không bao giờ báo động cho tới khi chi phí vượt hẳn mức cũ, tức là đã mất hết thành quả tối ưu mà không ai biết.

Monthly Benchmark Review

Ngoài alert theo giờ, nhóm thiết lập một buổi review hàng tháng, dùng template cố định để không bỏ sót góc nhìn nào và để người mới join team cũng review được ngay:

## Monthly Token Optimization Review — PR Review Pipeline

**Tháng:** _____  **Người thực hiện:** _____  **Ngày:** _____

### Benchmark Targets (set post-optimization)

- Input token trung bình/PR: ≤ 6.210 (chấp nhận dao động ±15%)
- Output token trung bình/PR: ≤ 391 (chấp nhận dao động ±20%)
- Chi phí trung bình/PR: ≤ $0,0159 (chấp nhận dao động ±15%)
- Cache hit rate: ≥ 8%
- % PR nhỏ được route sang GPT-4o-mini: 12-16% (nếu lệch mạnh, kiểm tra
  logic phân loại diff có đang hoạt động đúng không)
- Điểm chất lượng review (LLM-judge, lấy mẫu 50 PR/tháng): ≥ 4.00

### Review Process (Monthly)

1. Pull dashboard 30 ngày gần nhất, so sánh với Benchmark Targets ở trên.
2. Với mọi metric lệch >15% so với target, xác định nguyên nhân: thay đổi
   trong pipeline code? thay đổi giá của provider? thay đổi hành vi PR
   (ví dụ đợt release lớn làm diff dài hơn bình thường)?
3. Lấy mẫu ngẫu nhiên 50 PR trong tháng, chấm lại bằng LLM-judge với cùng
   rubric đã dùng trong audit — theo dõi trend điểm chất lượng theo thời
   gian, không chỉ nhìn một tháng đơn lẻ.
4. Rà soát log alert Slack trong tháng — có alert nào bị bỏ qua/snooze mà
   chưa xử lý gốc rễ không?
5. Cập nhật Benchmark Targets nếu có thay đổi hợp lý về baseline (ví dụ
   provider tăng giá, hoặc pipeline có thêm bước mới hợp lệ) — nhưng phải
   ghi rõ lý do thay đổi, không lặng lẽ nới ngưỡng để né alert.
6. Ghi biên bản ngắn gọn (3-5 dòng) vào kênh lưu trữ chung, để lịch sử
   review có thể tra cứu lại khi cần.

Mẹo: Đừng để buổi review hàng tháng trở thành hình thức "xem dashboard rồi thôi". Bắt buộc bước 3 (lấy mẫu chấm lại chất lượng) mỗi tháng, vì chi phí có thể ổn định trong khi chất lượng đang từ từ tụt do model provider thay đổi hành vi model ngầm (model version cập nhật) mà không ai báo trước.

Phase 6: Capstone Retrospective and Reusable Artifacts

Lessons Learned

Nhìn lại toàn bộ audit trên PR Reviewer Agent, một vài bài học có giá trị áp dụng cho bất kỳ pipeline agentic nào khác:

• Bug âm thầm (OPT-001) dễ bị số trung bình che giấu. Nếu chỉ nhìn chi phí trung bình hàng ngày, sẽ không bao giờ phát hiện session leak — nó chỉ lộ ra khi phân tích theo percentile và theo thời gian trong ngày.
• RAG là nơi lãng phí token lớn nhất trong hầu hết pipeline dùng retrieval — không riêng gì trường hợp này. Top-k cố định mà không lọc theo ngưỡng liên quan gần như luôn nhồi thêm "rác" vào context.
• Prompt caching là bước rẻ tiền nhưng cần làm sớm và làm đúng trật tự — hiệu quả của nó tăng lên khi các optimization giảm token khác được ship sau, vì tỷ trọng phần tĩnh trong tổng token có thể tăng tương đối.
• Rút gọn prompt/output không đồng nghĩa giảm chất lượng — trong cả OPT-002 và OPT-005, việc bỏ filler giúp điểm human-rated tăng nhẹ, vì filler che mờ tín hiệu quan trọng chứ không phải bổ sung giá trị.
• Model routing là optimization rủi ro cao nhất, cần eval set với ground truth thật (known regretted merges), không thể chỉ dựa vào A/B test traffic thật hoặc LLM-judge đơn thuần khi rủi ro là bug lọt qua review.
• Không có monitoring, mọi thành quả audit sẽ trôi dần về 0. Đây là bài học từ chính sự cố cũ ở pipeline chatbot hỗ trợ khách hàng, và là lý do Phase 5 không phải là bước "tùy chọn".

Mẹo: Lưu lại đúng bộ dữ liệu baseline gốc (trước audit) trong một bảng/tệp riêng biệt, không xóa hoặc ghi đè. Sáu tháng sau, khi ai đó hỏi "audit này thực sự tiết kiệm được bao nhiêu", bạn cần dẫn chứng số liệu trước/sau thật, không phải ước tính lại từ trí nhớ.

Reusable Audit Template

Toàn bộ quy trình 6 phase ở trên có thể đóng gói thành một template dùng lại cho pipeline agentic khác trong tổ chức:

## Token Optimization Audit Template

### 1. Instrumentation (Week 1)
- Xác định entry point chính của pipeline.
- Thêm logging per-step: input/output/cached tokens, latency, model, chi
  phí ước tính — không đổi logic nghiệp vụ.
- Đẩy log vào data warehouse/observability platform có sẵn, đảm bảo có
  thể truy vấn bằng SQL/dashboard.

### 2. Baseline Collection (Weeks 1-2)
- Thu thập dữ liệu tối thiểu 10-14 ngày chạy thực tế (không phải giả lập),
  đủ để bao gồm biến động theo ngày trong tuần.
- Tính trung bình, p90, p99 cho từng metric; breakdown token theo từng
  bước trong pipeline (system prompt, RAG, history, output...).
- Vẽ phân phối theo ít nhất một biến nghiệp vụ có ý nghĩa (ví dụ: kích
  thước input, độ phức tạp task).

### 3. Opportunity Identification (Week 2)
- Với mỗi điểm bất thường/lãng phí phát hiện ở bước 2, lập một dòng trong
  opportunity map, gán ID riêng (OPT-XXX) để theo dõi suốt dự án.
- Phân loại rõ: tiết kiệm số token thô, hay tiết kiệm chi phí/token
  (caching, routing) — không gộp chung.

### 4. Prioritization
- Xếp theo Impact × Risk × Effort.
- Optimization rủi ro thấp, không cần A/B test đi trước.
- Optimization ảnh hưởng trực tiếp tới chất lượng output (rewrite prompt,
  đổi RAG, đổi model) phải qua A/B test hoặc eval set trước khi rollout
  100%, không rollout thẳng dựa trên cảm tính.

### 5. Execution (Weeks 3-6)
- Ship từng OPT-XXX độc lập, đo trước/sau riêng cho từng cái, tránh ship
  chồng nhiều thay đổi cùng lúc khiến không cô lập được nguyên nhân.
- Với optimization có rủi ro chất lượng, luôn có eval set với ground
  truth thật (không chỉ LLM-judge) trước khi mở rộng traffic.
- Ghi lại kết quả từng bước theo cùng format bảng trước/sau để dễ tổng
  hợp ở bước cumulative dashboard.

### 6. Monitoring Setup
- Chốt benchmark ngay sau khi audit hoàn tất (không dùng benchmark cũ
  trước audit).
- Alert tự động (theo giờ/theo ngày) khi vượt ngưỡng % so với benchmark.
- Review định kỳ hàng tháng, bắt buộc có bước chấm lại chất lượng bằng
  mẫu thực tế, không chỉ nhìn số chi phí.
- Lưu trữ dữ liệu baseline gốc và kết quả từng OPT-XXX như tài liệu tham
  chiếu lâu dài.

Mẹo: Khi áp dụng template này cho pipeline khác (ví dụ chatbot hỗ trợ khách hàng, agent tự động viết test), giữ nguyên cấu trúc 6 bước nhưng thay nội dung — đừng bỏ qua bước Instrumentation dù pipeline đó "nhìn đơn giản hơn" PR Reviewer Agent. Chính pipeline "đơn giản" lại thường là nơi không ai từng đo đạc, nên khả năng có bug lãng phí kiểu OPT-001 ẩn giấu càng cao.

Summary

Case study PR Reviewer Agent minh họa toàn bộ vòng đời tối ưu token: từ một pipeline chạy production 5 tháng không ai đo đạc, tốn $4.360/tháng và 38,4 giây/PR, nhóm audit đã đo baseline có hệ thống, phát hiện 6 cơ hội cụ thể (OPT-001 đến OPT-006), triển khai từng cái với A/B test hoặc eval set tương ứng mức độ rủi ro, và đạt kết quả cuối: giảm 69,8% chi phí (từ $4.360 xuống ~$1.317/tháng), giảm 43,5% latency, trong khi điểm chất lượng review — đo bằng cả LLM-judge và con người — không giảm mà còn nhích lên nhẹ.

Bài học cốt lõi xuyên suốt: bug lãng phí âm thầm dễ ẩn trong số trung bình (OPT-001); RAG không lọc là nguồn lãng phí token lớn nhất trong pipeline dùng retrieval (OPT-004, đóng góp ~38,7% tổng mức giảm); rút gọn prompt/output đúng cách không đánh đổi chất lượng mà đôi khi còn cải thiện nó (OPT-002, OPT-005); prompt caching và model routing (OPT-003, OPT-006) là công cụ giảm chi phí/token hiệu quả nhưng cần validate cẩn trọng theo mức rủi ro tương ứng. Và quan trọng không kém mọi optimization: không có monitoring liên tục (Phase 5), mọi thành quả tối ưu sẽ âm thầm trôi dần trở lại điểm xuất phát.

Template audit 6 bước ở Phase 6 — Instrumentation, Baseline Collection, Opportunity Identification, Prioritization, Execution, Monitoring Setup — không chỉ riêng cho PR Reviewer Agent, mà là quy trình lặp lại được cho bất kỳ hệ thống agentic nào trong tổ chức bạn. Đây chính là năng lực cốt lõi mà toàn bộ khóa học này hướng tới: khả năng nhìn vào một agentic workflow đang chạy, đo đúng, tối ưu đúng thứ tự, và giữ nó tối ưu lâu dài — không chỉ tối ưu một lần rồi bỏ quên.