Di chuyển AI Agent sản xuất lên GPT-5.6: Những gì hỏng và cách chúng tôi sửa
Việc Ploy chuyển từ Claude Opus sang GPT-5.6 Sol cho thấy việc chuyển đổi mô hình không đơn giản như cắm và chạy — lược đồ công cụ, bộ nhớ đệm và khung đánh giá đều cần làm lại.

AI agent của Ploy xây dựng và chỉnh sửa các trang web marketing thực tế — lên kế hoạch trang, đọc codebase, viết component, tạo hình ảnh và quyết định khi nào hoàn thành. Trong nhiều tháng, Claude Opus giữ vị trí mặc định. Sau đó GPT-5.6 Sol ra mắt, và những con số quá tốt để bỏ qua: các bản build hoàn thành trong chưa đầy một nửa thời gian thực tế, với chi phí thấp hơn 27%, với điểm chất lượng tương đương hoặc tốt hơn. Nhưng việc chuyển đổi mô hình, ngay cả với SDK LLM phổ quát như Vercel's AI SDK, hóa ra lại là một bãi mìn của các hành vi đặc thù theo nhà cung cấp.
Bước 0: Sửa khung đánh giá của bạn trước
Bộ đánh giá của Ploy chạy agent thực tế trên hàng trăm không gian làm việc fixture, chấm điểm các bản build dựa trên kiểm tra trực quan, kiểm tra nội dung và quỹ đạo công cụ. Chạy cùng một bộ trên hai họ mô hình đã tiết lộ một sự thật đau đớn: khung của bạn được tinh chỉnh cho mô hình hiện tại, và bạn không biết điều đó. Ngân sách gọi công cụ được thiết kế cho phong cách tuần tự của Opus đã bị vượt quá bởi các cuộc gọi song song của GPT-5.6. Trình thực thi đánh giá không hỗ trợ đọc tệp theo lô, điều mà GPT-5.6 sử dụng liên tục. Khoảng một phần ba các lỗi thô trong lần chạy chéo mô hình đầu tiên bắt nguồn từ các giả định của khung, không phải hành vi của mô hình. Phân loại dấu vết trước khi bạn tin vào tỷ lệ đậu.
Bước 1: Lược đồ gọi công cụ — Kẻ làm hỏng thầm lặng
Công cụ code của Ploy có 25 tham số cấp cao nhất, một bắt buộc và phần còn lại tùy chọn. Claude chỉ gửi hai hoặc ba tham số nó sử dụng. GPT-5.6 gửi tất cả 25, mỗi lần, phát minh ra các giá trị hợp lý cho những tham số không dùng: offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000". Vấn đề không phải là dài dòng — mà là một giá trị được phát minh không thể phân biệt với giá trị có chủ đích. offset: 0 khiến 52% đến 64% các lần đọc tệp trả về trống. Prompt không sửa được điều này; ngay cả với gợi ý "TÙY CHỌN, bỏ qua nếu không dùng" cho từng thuộc tính, GPT-5.6 vẫn gửi tất cả 25. Cách sửa: một biến đổi lược đồ tại ranh giới nhà cung cấp, viết lại mọi thuộc tính tùy chọn thành bắt buộc nhưng có thể null bằng cách sử dụng anyOf: [T, null], sau đó loại bỏ null trước khi xác thực. Các lần đọc tệp rỗng giảm từ 52% xuống 0%, và agent cần ít hơn khoảng 30% số lần gọi công cụ.
Bước 2: Xây dựng lại bộ nhớ đệm prompt
Bề ngoài, cả hai nhà cung cấp đều cung cấp "bộ nhớ đệm prompt," nhưng các triển khai hoàn toàn khác nhau. Agent của Ploy mở đầu bằng một tiền tố tĩnh 29K token được lưu trong bộ nhớ đệm trên toàn tổ chức trên Claude với tỷ lệ hit 92-96%. GPT-5.6 đã bỏ khớp tiền tố một phần; bộ nhớ đệm ngầm bây giờ chỉ tạo các mục toàn bộ prompt được khóa trên tin nhắn mới nhất. Một cuộc trò chuyện mới chia sẻ cùng tiền tố tĩnh đã lưu trong bộ nhớ đệm 0% của nó. Cơ chế dự định sử dụng các điểm đánh dấu prompt_cache_breakpoint rõ ràng cộng với một prompt_cache_key bắt buộc, và mỗi khóa ánh xạ tới một nút bộ nhớ đệm duy trì khoảng 15 yêu cầu mỗi phút trước khi lưu lượng truy cập chuyển sang bộ nhớ đệm lạnh. Điều đó biến "bật bộ nhớ đệm" thành một quyết định thiết kế thực sự về phạm vi khóa. Trước khi sửa điều này, GPT-5.6 trông đắt hơn khoảng 50% so với Opus — không phải do giá của mô hình, mà là do cấu hình bộ nhớ đệm.
Bài học rút ra
Câu chuyện di chuyển của Ploy là một lời nhắc nhở rằng "mô hình" thực sự là một tập hợp các hành vi đặc thù theo nhà cung cấp mà toàn bộ ngăn xếp của bạn đã chuyên biệt hóa một cách lặng lẽ. Điền đối số công cụ, bộ nhớ đệm prompt và phát lại lý luận đều khác nhau giữa các nhà cung cấp. Nếu bạn đang đánh giá một mô hình thách thức, hãy sửa khung của bạn trước, sau đó mong đợi thiết kế lại xung quanh những khác biệt này. Lợi ích về hiệu suất là có thật — nhưng chúng đi kèm với chi phí kỹ thuật.
Nguồn: Ploy
Thảo luận
0 bình luận
Hãy là người đầu tiên thảo luận.