Khi bản cập nhật Claude làm hỏng hệ thống: Bài học về quản lý "phạm vi ảnh hưởng" của AI trong production

Hệ thống của chúng tôi chỉ làm một việc và làm việc đó rất tốt: Biến các câu hỏi bằng ngôn ngữ tự nhiên thành các lệnh gọi API.

Người dùng của chúng tôi là các chuyên gia phân tích, quản lý tài khoản và trưởng bộ phận vận hành. Họ biết mình cần dữ liệu gì, nhưng việc tổng hợp thủ công đồng nghĩa với việc phải trích xuất dữ liệu từ bốn bảng điều khiển, hai công cụ BI và trình tạo báo cáo Salesforce. Với hệ thống của chúng tôi, họ chỉ cần nhập yêu cầu bằng tiếng Anh đơn giản. Một yêu cầu như "Tổng hợp báo cáo về doanh số bán hàng từ tháng 1 đến tháng 3 năm 2026 cho khu vực Đông Bắc, phân bổ theo thành phố" sẽ được dịch thành một lệnh gọi API mà hệ thống có thể thực thi:

{
  "description": "User requested sales volume for the given date range, here is the API call to get the response",
  "api_call": "/api/sales_volume",
  "post_body": {
    "start_date": "2026-01-01",
    "end_date": "2026-03-31",
    "region": "northeast"
  }
}

Phần còn lại của quy trình là kỹ thuật truyền thống. Hệ thống gửi lệnh gọi đến backend phù hợp — chúng tôi có tích hợp với các cổng báo cáo nội bộ, Salesforce và một số dịch vụ tự phát triển — áp dụng truy vấn JSON do Mô hình Ngôn ngữ Lớn (LLM) tạo ra để lọc và định hình phản hồi, sau đó gửi kết quả qua email, dưới dạng tài liệu trên Drive hoặc hiển thị dưới dạng biểu đồ trên trình duyệt.

Đến giữa năm 2025, hệ thống đang tạo ra vài trăm báo cáo mỗi tháng. Các báo cáo này được các nhà lãnh đạo và chuyên gia phân tích sử dụng và lưu hành cho các bên liên quan bên ngoài. Nó đã trở thành cách mặc định mà hầu hết các nhóm lấy dữ liệu ad-hoc.

Hợp đồng giữa LLM và phần còn lại của hệ thống là một đối tượng JSON có cấu trúc như trong ví dụ trên.

Chúng tôi xây dựng hệ thống trên Claude Sonnet 3.5 vào đầu năm 2025. Chúng tôi nâng cấp lên 3.7 không gặp sự cố, và lên 4.0 cũng không gặp sự cố. Đến khi Sonnet 4.5 ra mắt, chúng tôi đã trở nên chủ quan về sự ổn định và khả năng dự đoán của các LLM trong việc giải quyết những gì chúng tôi tin là một vấn đề đơn giản. Việc nâng cấp mô hình đã trở nên thường nhật, giống như việc tăng phiên bản phụ của một thư viện ngoan ngoãn.

Sau đó, chúng tôi triển khai 4.5. Đối với một tỷ lệ đáng kể các yêu cầu, mô hình bắt đầu gộp nội dung của post_body vào trường description. Hai chế độ lỗi đã theo sau đó.

Đầu tiên, các tham số lọc không bao giờ đến được API. Hệ thống của chúng tôi đọc post_body là nguồn chân thực cho tải trọng yêu cầu, và trường này trở về rỗng. Lệnh gọi API được thực hiện mà không có bộ lọc ngày tháng hoặc khu vực. Tùy thuộc vào API cụ thể được gọi, backend sẽ trả về doanh số cho mọi thời điểm hoặc mọi khu vực, hoặc trả về lỗi 500.

Thứ hai, mô hình bắt đầu đặt câu hỏi làm rõ trong phản hồi của nó. Đây là điều mới. Các phiên bản trước luôn tiếp cận yêu cầu mơ hồ theo cách "cố gắng hết sức" và trả về một đối tượng có cấu trúc. Sonnet 4.5, thận trọng hơn, đôi khi sẽ phản hồi bằng một câu hỏi thay thế. Hệ thống của chúng tôi không có đường xử lý cho việc này. Nó được xây dựng dựa trên giả định rằng mọi lần gọi mô hình sẽ dẫn đến một lệnh gọi API. Không có thành phần con người trong vòng lặp và không có trạng thái để giữ yêu cầu chưa hoàn thành. Điều này khiến các hệ thống hạ lưu bị hỏng theo nhiều cách.

Chúng tôi đã quay lại phiên bản 4.0. Việc đó khó khăn hơn mức cần thiết: Giữa các lần triển khai 4.0 và 4.5, nhóm của chúng tôi đã thêm các tích hợp API mới, tất cả đều được kiểm định trên 4.5. Hoàn nguyên mô hình đồng nghĩa với việc phải kiểm định lại từng cái trên 4.0 dưới áp lực thời gian.

Tại sao kỷ luật kỹ thuật truyền thống thất bại ở đây

Kỹ thuật phần mềm dựa trên khả năng giới hạn tác động của một thay đổi. Khi bạn nâng cấp trình điều khiển hoặc thư viện, bạn đọc ghi chú phát hành để xem liệu có nên mong đợi các thay đổi phá vỡ (breaking changes) hay không. Các bài kiểm tra đơn vị (unit tests) giới hạn những gì có thể đã thay đổi. Bạn có thể tận dụng thuộc tính sau: Hệ thống được thay đổi đủ xác định để hành vi của nó có thể dự đoán được, hoặc ít nhất là được lấy mẫu đủ dày để mang lại sự tự tin. Phạm vi ảnh hưởng (blast radius) bị giới hạn bởi cấu trúc.

Các hệ thống dựa trên LLM phá vỡ giả định này. Thành phần tạo ra đầu ra của bạn không nằm dưới sự kiểm soát của bạn. Bạn không thể so sánh sự khác biệt (diff) của việc nâng cấp mô hình từ phiên bản 4.0 lên 4.5. Đó là một sự thay thế toàn bộ chức năng mà hệ thống của bạn phụ thuộc vào.

Đây là những gì chúng tôi gọi là phạm vi ảnh hưởng vô hạn (infinite blast radius): một thay đổi mà các tác động hạ lưu không thể liệt kê trước được vì không gian đầu vào (ngôn ngữ tự nhiên) và các chế độ lỗi (bất cứ điều gì mô hình có thể làm khác nhau) đều không bị giới hạn.

Giải mã sự thất bại

Bản phân tích sau sự cố (post-mortem) cho thấy câu lệnh (prompt) của chúng tôi luôn được chỉ định thiếu sót. Chúng tôi đã yêu cầu mô hình trả về một đối tượng JSON với ba trường. Chúng tôi đã mô tả mục đích của từng trường. Chúng tôi không nêu rõ rằng mô tả phải là một chuỗi ngôn ngữ tự nhiên và không được chứa các biểu diễn tuần tự của các trường khác.

Các phiên bản trước của mô hình đã suy ra ràng buộc này từ ngữ cảnh. Sonnet 4.5, rõ ràng là tốt hơn trong việc "hữu ích" trong các lựa chọn định dạng của nó, đã quyết định rằng việc hỏi làm rõ hoặc cung cấp phần thân yêu cầu trong phần mô tả làm cho phản hồi hữu ích hơn. Từ góc nhìn của mô hình, đây là một cách giải thích hợp lý cho một chỉ thị mơ hồ. Tuy nhiên, nó đã vi phạm các giả định mà hệ thống của chúng tôi được xây dựng dựa trên đó.

Lỗi không nằm ở mô hình. Lỗi nằm ở giả định của chúng tôi rằng mô hình sẽ tiếp tục lấp đầy các khoảng trống trong thông số kỹ thuật của chúng tôi như trước đây. Ba lần nâng cấp thành công đã khiến chúng tôi tin rằng những khoảng trống đó là an toàn.

Các chế độ đầu ra có cấu trúc và API sử dụng công cụ sẽ bắt được lỗi cụ thể này ở cấp lược đồ (schema). Chúng tôi không sử dụng chúng vì các lý do kỹ thuật nằm ngoài phạm vi bài viết này. Nhưng các lược đồ chỉ giới hạn cú pháp, không phải ngữ nghĩa. Một lược đồ không thể quy định rằng một câu hỏi làm rõ không được xuất hiện trong một hệ thống không có đường xử lý làm rõ, hoặc rằng phạm vi ngày tháng không bao giờ được mặc định âm thầm thành mọi thời điểm. Các lược đồ giải quyết một nửa dễ hơn của vấn đề.

Kiến trúc ưu tiên đánh giá (Evals-first)

Kỷ luật để lấp đầy khoảng trống này là coi bộ đánh giá (evaluation suite) — chứ không phải câu lệnh (prompt) — là thông số kỹ thuật chính thức của hệ thống. Câu lệnh là sự triển khai của thông số kỹ thuật. Mô hình là trình thông dịch. Các bài đánh giá (evals) chính là thông số kỹ thuật, và bất kỳ thay đổi mô hình hay câu lệnh nào chỉ hợp lệ khi và chỉ khi nó vượt qua chúng.

Trong thực tế, một bài đánh giá là một bộ ba: Một đầu vào, một thuộc tính mà đầu ra phải thỏa mãn, và một hàm chấm điểm. Đối với hệ thống của chúng tôi, bài đánh giá sẽ bắt được sự thoái trào của 4.5 trông giống như sau:

def test_description_contains_no_serialized_payload(response):
    desc = response["description"].lower()
    forbidden = ["curl", "post_body", "{", "http://", "https://"]
    assert not any(token in desc for token in forbidden), \
        f"description leaked structured content: {response['description']}"

Một vài trăm thuộc tính như vậy, một số được viết thủ công cho các bất biến quan trọng đã biết, một số được tạo ra dưới dạng kiểm thử hồi quy từ lưu lượng sản xuất thực tế, một số được chấm điểm bởi LLM-within-the-role-of-judge (LLM đóng vai trò giám khảo) cho các phẩm chất mơ hồ hơn như ngữ điệu, sẽ trở thành một cổng kiểm soát. Việc nâng cấp mô hình và thay đổi câu lệnh nên được coi như các yêu cầu kéo (pull requests) phải biến bộ bài kiểm tra thành màu xanh lá cây trước khi hợp nhất.

Xây dựng và duy trì các bài đánh giá tốn kém. Chúng trôi đi khi sản phẩm của bạn thay đổi. Việc chấm điểm bằng LLM-giám khảo đưa ra sự biến động của riêng nó trong kết quả. Và bộ bài kiểm tra chỉ có thể bắt được các chế độ lỗi mà bạn đã nghĩ đến để chỉ định — bạn không thể đánh giá để đảm bảo an toàn trước một loại lỗi mà bạn chưa bao giờ tưởng tượng ra. Chúng tôi đã học bài học này theo cách khó khăn: Không ai trong nhóm chúng tôi từng viết một khẳng định nào nói rằng "trường mô tả không được chứa lệnh curl", vì không ai nghĩ rằng mô hình sẽ đưa nó vào đó.

Các bài đánh giá không phải là viên đạn bạc. Chúng mang lại cho bạn khả năng giới hạn phạm vi ảnh hưởng của một thay đổi theo cách duy nhất có sẵn khi chức năng cơ bản là một hộp đen: Bằng cách lấy mẫu dày đặc phản hồi đầu vào-đầu ra mà bạn thực sự quan tâm, và từ chối triển khai khi hành vi đó thay đổi.

Lộ trình phát triển

Cộng đồng kỹ thuật vẫn chưa phát triển một cơ sở kiến thức để viết các bài đánh giá hiệu quả. Không có tiêu chuẩn được chấp nhận rộng rãi nào cho ý nghĩa của "độ phủ" trong các không gian đầu vào ngôn ngữ tự nhiên. Các hệ thống CI/CD không được xây dựng để kiểm soát các kết quả kiểm thử xác suất. Khi các tác nhân đảm nhận nhiều công việc tự chủ hơn — viết mã, chuyển tiền, lập lịch thay đổi cơ sở hạ tầng — khoảng cách giữa "mô hình đã vượt qua các bài kiểm tra khói" và "chúng tôi biết hệ thống này sẽ làm gì trong sản xuất" sẽ trở thành vấn đề kỹ thuật trung tâm của vài năm tới.

Các nhóm sẽ lấp đầy khoảng trống này sẽ là những nhóm ngừng coi các bài đánh giá là một suy nghĩ sau của đảm bảo chất lượng và bắt đầu coi chúng là thông số kỹ thuật thực tế về những gì hệ thống của họ là.

Vijay Sagar Gullapalli là Founding AI Engineer tại Adopt AI và là một nhà phát minh được cấp bằng sáng chế của USPTO.

Sarat Mahavratayajula là Senior Software Engineer tại Sherwin-Williams.