Từ 20 Triệu Bản Ghi/Ngày Đến AI Agents: Những Gì Backend Engineer Thường Hiểu Sai Về LLM

Tôi dành ba năm đầu tại Parcel Perform xây dựng data pipelines: file ingestion stacks, Kafka producers và consumers, Apache Flink streaming jobs, notification systems đẩy 20M+ bản ghi mỗi ngày. Công việc engineering vững chắc và chuẩn mực. Rồi cuối năm 2025, tôi chuyển sang lead GenAI product và nhận ra rằng gần như mọi thứ tôi đã nội tâm hóa về cách build các hệ thống đáng tin cậy cần được xem xét lại.

Đây không phải bài viết về việc LLM là phép thuật. Đây là về các mental model mismatch cụ thể khiến các backend engineers có kinh nghiệm vấp ngã khi lần đầu build với LLM — và cách tái hiệu chỉnh.

Mental Model Mismatch #1: Latency

Trong backend systems, 100ms là chậm. Chúng ta tối ưu query plans, thêm Redis caching layers, tune Kafka consumer throughput. Mục tiêu là low-latency, high-throughput, response time có thể dự đoán.

LLM calls tốn 1-10 giây. Đó không phải bug — đó là baseline. Lỗi đầu tiên tôi mắc phải là cố áp dụng latency optimization kiểu pipeline vào LLM workflow. Tôi mất một tuần điều tra xem có thể batch prompt calls để giảm overhead không. Bottleneck thực sự không phải batching overhead — mà là 3 giây inference đơn giản là sàn tối thiểu.

Tái hiệu chỉnh: thiết kế UX và SLA quanh LLM latency từ đầu. Dùng streaming responses khi có thể. Chuyển synchronous LLM calls thành async background jobs cho mọi thứ không phải user-facing real-time. Chấp nhận rằng draft email bán hàng 5 giây là ổn nếu nó tốt hơn những gì con người tạo ra trong 30 phút.

Mental Model Mismatch #2: Retry Logic

Trong Kafka consumers, chúng ta có dead-letter queues, exponential backoff, và exactly-once semantics. Retry được hiểu rõ ràng: nếu một message thất bại, retry với cùng input và cuối cùng nó thành công hoặc vào DLQ.

LLM retries khác. LLM call thất bại do rate limiting? Retry là ổn. LLM call tạo ra output tệ (dữ liệu hallucinated, sai format, nội dung lệch)? Retry với cùng prompt sẽ có khả năng tạo ra output tệ tương tự. Chiến lược retry phải bao gồm biến thể prompt, điều chỉnh temperature, hoặc fallback model.

Chúng tôi triển khai two-stage retry: retry đầu tiên giống hệt (bắt transient errors), retry thứ hai với prompt được tinh chỉnh nêu rõ những gì sai với output trước. Điều này cắt giảm 60% email drafts "thất bại vĩnh viễn".

Mental Model Mismatch #3: Throughput vs Quality

Tư duy high-throughput pipeline: đẩy nhiều records per second hơn. Tối ưu cho volume. Dùng parallelism để scale.

Tư duy LLM: chất lượng mỗi inference quan trọng hơn throughput. Một batch 10.000 email AI chất lượng thấp sẽ tổn hại thương hiệu của bạn. Một batch 1.000 email chất lượng cao mới thúc đẩy pipeline. Tôi phải hoàn toàn định nghĩa lại success metric từ "records processed" sang "quality score × volume".

Thực tế: chúng tôi thêm bước LLM-as-judge scoring sau mỗi email draft. Draft dưới ngưỡng chất lượng được regenerate hoặc gắn cờ để human review thay vì gửi đi. Điều này làm chậm throughput 20% và cải thiện campaign reply rate 3 lần.

Prompt Versioning: Bài Học Tôi Học Quá Muộn

Trong backend systems, code được version, deploy, và có thể rollback. Thay đổi prompt cảm thấy nhẹ nhàng — chỉ edit một string. Chúng tôi coi prompt như config values, không phải code.

Ba tháng sau, một thay đổi prompt cho subject line template khiến email open rate giảm 40%. Chúng tôi không có cách nào nhanh chóng xác định *thay đổi prompt nào* gây ra vì chúng không được version. Chúng tôi xây dựng lại toàn bộ prompt versioning system trong một emergency sprint.

Cách đúng từ ngày đầu: lưu prompts trong database với version IDs, liên kết mỗi agent run với prompt version nó dùng, và coi thay đổi prompt như deployment — với review và staged rollout. Chúng tôi giờ dùng field prompt_version_id trong mỗi LangSmith trace và ELK log entry.

# Prompt versioning pattern we settled on
class PromptVersion(BaseModel):
    version_id: str          # e.g. "subject-v2.3"
    template: str
    model: str
    temperature: float
    created_at: datetime
    active: bool

# Every agent run records which version was used
run_metadata = {
    "prompt_version_id": prompt.version_id,
    "campaign_id": campaign_id,
    "model": prompt.model,
}

ELK Cost Monitoring: Track Chi Phí LLM Như Query DB

Chúng ta theo dõi database query performance một cách ám ảnh — slow query logs, explain plans, index coverage. LLM inference tốn tiền theo token, nhưng hầu hết teams coi nó như line item mờ đục cho đến khi hóa đơn AWS đến.

Chúng tôi instrument mỗi LLM call với input tokens, output tokens, model ID, và campaign ID, rồi ship lên ELK. Điều này cho chúng tôi: chi phí mỗi campaign, chi phí mỗi email draft, chi phí theo model version, và quan trọng nhất — cost anomaly detection. Khi thay đổi prompt khiến input tokens tăng vọt (thường do bug trong context construction), chúng tôi phát hiện trong vài giờ, không phải cuối tháng.

Mental Model Đúng Cho LLM Systems

Sau một năm làm việc ở cả hai đầu — pipeline 20M records/ngày và production AI agents — đây là cách tôi giờ nghĩ về LLM systems: chúng là probabilistic services với calls đắt tiền, chậm, nơi chất lượng output biến đổi và failures thường là semantic, không chỉ technical.

Điều đó có nghĩa: tối ưu cho quality hơn throughput, instrument mọi thứ (tokens, latency, quality scores, cost), version prompts như code, thiết kế retry strategies tính đến semantic failure, và chấp nhận rằng một phần trăm outputs sẽ cần human review — đó không phải bug trong hệ thống của bạn, mà là bản chất của công nghệ.

Kết Luận

Các kỹ năng khiến tôi trở thành backend engineer giỏi — systems thinking, fault tolerance design, observability, clean interfaces — đều chuyển sang AI agent work. Nhưng các intuitions được xây dựng từ nhiều năm làm việc với hệ thống microsecond-latency, high-throughput, deterministic sẽ dẫn bạn sai đường nếu áp dụng mà không có sự thích nghi. Các engineers làm tốt việc này không phải là những người quên kinh nghiệm backend của họ — mà là những người biết khi nào nên áp dụng và khi nào cần tái hiệu chỉnh.