Một thay đổi tham số AI khiến tôi tốn $54/tháng

Tôi tin tưởng Claude giúp chuyển từ AWS Lambda sang Google Cloud Run. Quá trình chuyển diễn ra hoàn hảo — service deploy, workflow thực thi, người dùng hài lòng. Rồi tôi kiểm tra hóa đơn API và suýt ngã khỏi ghế.

*Đây là phần 3 của series kỹ thuật DIALØGUE. Nếu bạn bỏ lỡ: [Phần 1: Giới thiệu DIALØGUE] và [Phần 2: Từ quảng cáo đến kỹ thuật] cover nền tảng.*

Đây là câu chuyện về chuyện gì xảy ra khi bạn để AI viết code production mà không rõ ràng về ràng buộc production. Spoiler: "làm cho nó hoạt động" và "làm cho nó sẵn sàng production" là hai yêu cầu rất khác.

Quá trình chuyển đổi suôn sẻ quá mức

Sau nhiều tháng vật lộn với AWS Lambda (cold starts, giới hạn layer, đủ thứ), tôi quyết định chuyển mọi thứ sang Google Cloud Run. Là developer thực dụng (đọc: lười), tôi nhờ Claude làm pair programmer.

"Giúp tôi chuyển các Lambda functions sang Cloud Run," tôi nói. "Đây là code hiện tại."

Claude giao hàng xuất sắc. Dockerfile sạch, cấu hình service đúng, Cloud Workflows hoạt động. Quá trình chuyển chỉ mất một ngày thay vì nhiều tuần như dự kiến. Tôi phấn khích!

Mọi thứ deploy trơn tru. Service khởi động nhanh. Người dùng tạo podcast không vấn đề gì. Thành công, đúng không?

Rồi tôi nhận thấy điều kỳ lạ trong log:

```
[ERROR] Segment generation failed: Unexpected token in JSON
[RETRY] Attempting segment generation again...
[SUCCESS] Segment generated successfully
```

Khoảng 30% AI call thất bại lần đầu nhưng thành công khi retry. Không phải tận thế — retry logic hoạt động! Người dùng không nhận thấy vấn đề. Nhưng các API call thêm cộng dồn.

Điều tra: Đổ lỗi cho quá trình chuyển?

Suy nghĩ đầu tiên là có gì đó sai trong quá trình chuyển. Có thể môi trường Cloud Run mới khác? Vấn đề mạng container? Tôi dành hàng giờ so sánh cấu hình AWS và GCP.

Mọi thứ trông giống hệt. Cùng prompt, cùng retry logic, cùng error handling. Vậy tại sao đột nhiên nhận JSON response bị lỗi?

Rồi tôi bắt đầu so sánh code thực tế. Đây là thứ tôi tìm thấy:

Phiên bản AWS Lambda (hoạt động tốt nhiều tháng):

```python
response = anthropic.messages.create(
      model="claude-3-7-sonnet-20250219",
      temperature=0,  # Deterministic cho JSON
      response_format={"type": "json_object"},  # JSON mode
      system="You are a JSON generation assistant. Output only valid JSON.",
      messages=[{"role": "user", "content": prompt}]
)
```

Phiên bản GCP Cloud Run (migration của Claude):

```python
response = anthropic.messages.create(
    model="claude-3-7-sonnet-20250219",
    temperature=0.7,  # <-- Khoan, cái gì?
    messages=[{"role": "user", "content": prompt}]
)
```

Đấy. Temperature 0.7.

"Nhưng đó là default hợp lý mà!" bạn có thể nói. Và bạn đúng. Cho viết sáng tạo, khám phá, brainstorm — 0.7 hoàn toàn hợp lý. Nhưng cho JSON có cấu trúc? Đó là thảm họa.

Bằng chứng: JSON sáng tạo

Sau khi thêm logging chi tiết để nắm bắt response AI thực tế, tôi tìm thấy chính xác chuyện gì đang xảy ra. Đây là thứ Claude trả về ở temperature 0.7:

```
Here's the podcast segment you requested:

{
  "title": "The Rise of AI Podcasting",
  "content": "Welcome back, listeners! Today we're diving into something really fascinating...",
  "duration": 120
}

I hope this segment captures what you were looking for!
```

Thấy vấn đề chưa? Claude đang sáng tạo với format response. Đôi khi chỉ JSON, đôi khi JSON với bình luận hữu ích, đôi khi JSON bọc trong markdown code blocks. Ở temperature 0.7, nó đang ứng tác như nhạc sĩ jazz khi tôi cần máy đếm nhịp.

Điểm mù của AI Pair Programming

Chuyện là thế này về làm việc với AI như pair programmer: nó cực kỳ giỏi làm code hoạt động, nhưng không nhất thiết tối ưu cho production trừ khi bạn yêu cầu cụ thể.

Khi tôi nói "chuyển Lambda function này sang Cloud Run," Claude tập trung vào yêu cầu chuyển đổi:

- ✅ Làm nó chạy trên Cloud Run

- ✅ Xử lý cùng input và output

- ✅ Duy trì cùng chức năng

- ❌ Tối ưu cho hiệu suất production

Claude chọn temperature 0.7 vì đó là "default hợp lý" cho ứng dụng AI. Và đúng vậy! Cho hầu hết trường hợp, 0.7 cho bạn cân bằng tốt giữa sáng tạo và nhất quán.

Nhưng đây là bài học: AI không biết ràng buộc production cụ thể của bạn trừ khi bạn nói.

Code AWS gốc dùng temperature 0 VÀ JSON mode vì tôi đã học (theo cách khó) rằng tạo JSON cần cả output xác định và format rõ ràng. Nhưng trong quá trình chuyển, tôi không bao giờ nói rõ "đây là cho tạo dữ liệu có cấu trúc" hay "duy trì tất cả tối ưu đặc thù JSON."

Nên Claude viết code hoàn toàn chức năng với default hợp lý. Vấn đề không phải AI — mà yêu cầu chưa đầy đủ của tôi.

Sửa lỗi: Cụ thể với AI

Khi xác định vấn đề, tôi quay lại Claude với yêu cầu tốt hơn:

"Giúp tôi sửa code này. Nó dùng cho tạo JSON trong production. Tôi cần 100% tin cậy, không sáng tạo. Dùng temperature 0 và mọi tối ưu khác cho dữ liệu có cấu trúc."

Claude ngay lập tức đề xuất:

```python
response = anthropic.messages.create(
    model="claude-3-5-sonnet",
    temperature=0,  # Output xác định
    response_format={"type": "json_object"},  # JSON mode
    system="You are a JSON generation assistant. Output only valid JSON.",
    messages=[{"role": "user", "content": prompt}]
)
```

Khoan, Claude bỏ JSON mode chúng tôi có! (Đây là chuyện xảy ra khi bạn không đề cập rõ ràng mọi yêu cầu production trong quá trình chuyển!)

Tỷ lệ thành công nhảy từ 70% lên 99.9%. 0.1% còn lại? Timeout mạng. Không thể đổ lỗi Claude cho điều đó.

Khác biệt? Lần này tôi rõ ràng về ràng buộc production. Tôi không chỉ yêu cầu chuyển đổi — tôi yêu cầu code tối ưu cho production, tập trung vào độ tin cậy.

Chi phí thực của default "hợp lý"

Hãy phân tích cài đặt temperature "hợp lý" này thực sự tốn bao nhiêu:

- Tạo podcast hàng ngày: ~200

- Tỷ lệ thất bại: 30% cần retry

- API call thêm mỗi ngày: 60 call thất bại cần retry

- Lãng phí hàng tháng: ~1.800 API call không cần thiết

- Giá Claude 3.7 Sonnet: $3 input + $15 output mỗi triệu token

- Token trung bình mỗi call: ~2.000 input + 1.500 output

- Chi phí mỗi retry: ~$0.03 mỗi lần thất bại

- Vượt chi hàng tháng: ~$54 API call lãng phí

Nhưng chi phí thực không chỉ $54/tháng. Mỗi retry thêm 3-5 giây vào thời gian tạo. Người dùng đợi lâu hơn, Cloud Run instance khởi động thường xuyên hơn, và tôi dùng quota nhanh hơn.

Điểm mấu chốt? Tất cả vì tôi tin AI đưa quyết định production mà không cho nó context production. Trường hợp kinh điển "nó hoạt động" vs "nó hoạt động hiệu quả."

Tôi học được gì về AI Pair Programming

1. Rõ ràng về yêu cầu production

"Làm cho nó hoạt động" cho bạn code chức năng. "Làm cho nó hoạt động hiệu quả trong production với những ràng buộc này" cho bạn code tối ưu. AI giỏi giải quyết vấn đề bạn mô tả, không phải vấn đề bạn nghĩ trong đầu.

2. AI dùng default "hợp lý", không phải "tối ưu"

Temperature 0.7 hợp lý cho hầu hết ứng dụng AI. Nhưng hệ thống production thường cần tối ưu cụ thể như temperature 0 VÀ JSON mode. AI không bảo tồn những thứ này trừ khi bạn đề cập rõ ràng.

3. Code review áp dụng cho code AI tạo ra

Chỉ vì AI viết không có nghĩa sẵn sàng production. Tôi nên bắt được điều này trong code review, nhưng quá tập trung vào liệu migration có hoạt động mà không audit các tham số.

4. Context quan trọng hơn bạn nghĩ

Code AWS gốc có temperature 0 VÀ JSON mode vì lý do chính đáng — học qua trải nghiệm đau thương. Trong quá trình chuyển, context đó mất vì tôi không đề cập rõ ràng. Giờ tôi document "tại sao" đằng sau mọi tham số và tính năng.

Workflow AI Pair Programming mới

Giờ khi làm việc với AI trên code production, tôi rõ ràng hơn nhiều về ràng buộc:

Trước:

"Chuyển Lambda function này sang Cloud Run"

Giờ:

"Chuyển Lambda function này sang Cloud Run. Đây là cho tạo JSON production — ưu tiên độ tin cậy hơn sáng tạo. Dùng temperature 0, JSON mode nếu có, và mọi tối ưu khác cho output dữ liệu có cấu trúc."

Đây là config tối ưu production Claude giúp tôi xây:

```python
def get_ai_json_response(prompt: str) -> dict:
    """Tạo JSON tối ưu production với AI"""
    response = anthropic.messages.create(
        model="claude-sonnet-4-20250514",
        temperature=0,  # Không sáng tạo cho dữ liệu có cấu trúc
        response_format={"type": "json_object"},  # Bắt buộc JSON mode
        system="You are a JSON generation assistant. Output only valid JSON.",
        messages=[{
            "role": "user",
            "content": f"{prompt}\n\nRespond with valid JSON only."
        }]
    )

    # Xử lý lỗi rõ ràng cho production
    try:
        return json.loads(response.content[0].text)
    except json.JSONDecodeError as e:
        logger.error(f"JSON parse failed: {e}")
        logger.error(f"Raw response: {response.content[0].text}")
        raise
```

Khác biệt? Tôi cho AI context cần thiết để tối ưu cho trường hợp cụ thể.

Kết quả

Giảm 30% chi phí API, tạo nhanh hơn 40%. Tất cả từ một cuộc trò chuyện khi tôi thực sự cụ thể về "sẵn sàng production" nghĩa là gì.

Điều buồn cười? Ngay cả tạo đối thoại "sáng tạo" cũng dùng temperature 0. Hóa ra xác định không có nghĩa nhàm chán — mà nghĩa là đáng tin cậy. Cuộc trò chuyện vẫn nghe tự nhiên vì prompt và nghiên cứu nội dung cung cấp sự đa dạng, không phải biến động temperature ngẫu nhiên.

Hóa ra AI pair programming hoạt động tốt khi bạn nhớ đó vẫn là lập trình — chính xác trong yêu cầu mang lại chính xác trong kết quả.

Bạn đã bao giờ có trợ lý AI đưa lựa chọn "hợp lý" mà hóa ra hoàn toàn sai cho trường hợp của bạn? Tôi rất muốn nghe câu chuyện chiến tranh của bạn — tôi nghi tất cả chúng ta đều từng bị default hợp lý cắn :)

Thân mến, Chandler

Muốn tạo podcast AI riêng với JSON hợp lệ đảm bảo? Thử DIALØGUE — 2 credit miễn phí để bắt đầu! :P

Phần 3 của DIALØGUE Engineering Series. Vẫn đang học rằng "làm cho nó hoạt động" và "làm cho nó hoạt động hiệu quả" là hai yêu cầu hoàn toàn khác. Theo dõi thêm cuộc phiêu lưu AI pair programming tại chandlernguyen.com.

Tiếp theo trong series: Khoảng 7 ngày nữa — "Từ 3 phút xuống 500ms: Bug đăng ký vô nghĩa"