Quá trình chuyển AI agent production sang GPT-5.6 nhanh hơn 2,2 lần và rẻ hơn 27%

 (ploy.ai)
1 điểm bởi GN⁺ 7 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Ploy đã chuyển agent lập kế hoạch, xây dựng và kiểm chứng website marketing production từ Claude Opus 4.8 sang GPT-5.6 Sol và đặt đây làm model mặc định cho mọi workspace
  • Sau khi sửa các giả định theo từng model trong bộ khung đánh giá, thời gian chạy trung bình của tác vụ dựng lại trang chủ giảm từ 8 phút xuống 3 phút 42 giây, chi phí giảm 27% từ $3.06 xuống $2.22, đồng thời điểm số thị giác tăng lên 0.970
  • GPT-5.6 đã tự điền toàn bộ 25 tham số tùy chọn trong lệnh gọi công cụ bằng các giá trị bịa ra, khiến 52~64% lượt đọc file trả về kết quả rỗng; nhưng khi đổi các trường tùy chọn thành bắt buộc·nullable, tỷ lệ đọc rỗng giảm về 0% và số lần gọi công cụ cũng giảm khoảng 30%
  • Do khác biệt về phạm vi cache và cấu trúc thông lượng giữa OpenAI và Anthropic, ban đầu GPT-5.6 bị đo là đắt hơn khoảng 50%, nhưng sau khi áp dụng cache key theo workspace và breakpoint theo tầng, tỷ lệ hit ở lần gọi đầu tăng từ 0% lên 83.7% và số input token không cache giảm 28%
  • Chi phí và hiệu năng khi thay model không chỉ phụ thuộc vào bản thân model mà còn bị chi phối bởi ngân sách đánh giá, schema công cụ, cấu trúc cache và cách phát lại suy luận, nên cần tìm và sửa trước các giả định theo từng nhà cung cấp đang được tối ưu cho model cũ thì mới có thể so sánh đáng tin cậy và vận hành ổn định

GPT-5.6 Sol thay thế Claude Opus

  • Agent của Ploy lập kế hoạch các trang cho website marketing production, đọc codebase, tạo component và hình ảnh, kiểm tra kết quả bằng screenshot rồi tự đánh giá xem công việc đã hoàn tất hay chưa
  • Trong nhiều tháng không có model nào đạt đủ tiêu chuẩn để thay thế Claude Opus, và model mặc định đã giữ lần lượt Opus 4.7 rồi 4.8 trong suốt 4 tháng
  • GPT-5.6 Sol là model đầu tiên vượt Opus trong đánh giá đối đầu 1-1 trên cùng tác vụ và trở thành model mặc định cho mọi workspace của Ploy
  • Ngay từ đánh giá ban đầu, thời gian chạy của các bản build hoàn tất đã dưới một nửa, chi phí thấp hơn 27%, và điểm số bằng hoặc cao hơn model cũ, tạo cơ sở để tiến hành migration
  • Ploy dùng Vercel AI SDK, nhưng trong quá trình chuyển model đã phát hiện các giả định theo từng nhà cung cấp về cấu trúc tham số công cụ, prompt caching và phát lại suy luận giữa các lượt vẫn còn tồn tại xuyên suốt toàn bộ stack
  • Migration được thực hiện bằng cách sửa lần lượt bộ khung đánh giá, schema công cụ, prompt caching và phát lại suy luận

Sửa bộ khung trước khi tin vào số liệu đánh giá

  • Bộ đánh giá chạy agent production trên các workspace kiểm thử cố định, bao phủ hàng trăm trường hợp từ việc dựng lại trang chủ từ đầu đến việc xác định liệu có thể thực thi an toàn một yêu cầu sao chép hay không
  • Trong các trường hợp build, bộ chấm điểm thị giác sẽ so sánh với thiết kế chuẩn và thực hiện 10 phép kiểm tra nhị phân
    • Kiểm tra xem khu vực hero có phải là một cảnh ảnh phủ toàn bộ chiều rộng màn hình hay không
    • Xác nhận CTA chính là hình chữ nhật bo góc chứ không phải dạng pill
  • Đồng thời cũng kiểm tra nội dung, đường đi thực thi công cụ và các khẳng định về file; khi thất bại thì xem lại toàn bộ dấu vết thực thi gồm cả lệnh gọi công cụ và văn bản model tạo ra

  • Các ràng buộc được điều chỉnh theo cách gọi của model cũ

    • Ngân sách lệnh gọi công cụ cũ được điều chỉnh theo cách gọi tuần tự của Opus, nhưng GPT-5.6 dùng gọi song song nên vượt ngân sách ngay cả ở các trường hợp giải đúng bài toán
    • Bộ thực thi đánh giá không hỗ trợ đọc file theo lô, tính năng mà Opus gần như không dùng nhưng GPT-5.6 lại dùng thường xuyên
    • Khoảng một phần ba số lỗi thô ở lần chạy đầu không đến từ hành vi model mà từ các giả định của bộ khung, và chúng cũng không phân bố đều giữa các model
    • Nếu không phân loại dấu vết thực thi của model thách thức và model hiện tại trước, thì model mới sẽ bị đánh giá có lợi hơn khi nó hành xử càng giống model cũ

  • Ngưỡng điểm ngầm định

    • Dataset thiếu minScore sẽ âm thầm kế thừa giá trị mặc định 1.0 mà không có cảnh báo
    • Vì vậy GPT-5.6 nhận điểm hero 0.98 nhưng vẫn bị đánh trượt, và Opus cũng bị chấm thất bại trong trường hợp đã vượt qua mọi phép kiểm tra riêng lẻ
    • Cả hai kết quả đều là những thiết kế có thể chấp nhận được, nhưng bị loại vì ngưỡng ngầm định chứ không phải do model

Kết quả benchmark sau khi chỉnh sửa

  • Sau khi sửa bộ khung, nhóm đã chạy lại bộ đánh giá dựng lại homepage thương hiệu theo thiết kế chuẩn
Trung bình trên mỗi build hoàn tất Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
Chi phí $3.06 $2.22
Thời gian chạy 8 phút 00 giây 3 phút 42 giây
Input token 2,6 triệu 1,7 triệu
Output token 33,000 17,100
Điểm thị giác 0.936 0.970
  • GPT-5.6 hoàn tất trang nhanh hơn 2,2 lần, chi phí thấp hơn 27%, và cũng chỉ dùng khoảng một nửa số output token
  • Lượng mã được sinh ra cũng ít hơn
    • Trong một cặp ví dụ đối chiếu, Opus tạo ra 174 biến CSS và globals.css dài 17.957 ký tự, bao gồm cả các dải màu hầu như không được dùng đến
    • GPT-5.6 chỉ dùng 45 biến CSS và 2.508 ký tự nhưng vẫn cho kết quả render tương đương hoặc tốt hơn

  • Chất lượng và độ nhất quán thiết kế

    • GPT-5.6 mạnh ở layout gọn gàng, lưới dày, nhưng có xu hướng hội tụ về phong cách này nếu không được dẫn hướng mạnh
    • Trong bộ khung cũ được thiết kế cho Opus 4.8, model này thường tạo ra kết quả gọn gàng nhưng tầm thường và bỏ qua design system hiện có
    • Sau khi đội thiết kế và kỹ thuật cải thiện cách dẫn hướng model, kết quả đã đạt tiêu chuẩn tuân thủ thương hiệu cần cho production

Cách xử lý tham số tùy chọn trong lệnh gọi công cụ

  • Công cụ code của agent có 25 tham số cấp cao nhất; chỉ action là bắt buộc, còn lại đều là tùy chọn
  • Claude chỉ gửi 2~3 tham số thực sự dùng đến, nhưng GPT-5.6 ở mỗi lần gọi đều gửi đủ cả 25 tham số, kể cả các trường không dùng cũng được điền bằng các giá trị có vẻ hợp lý như offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"
  • Cùng một mẫu hình cũng xuất hiện trong dấu vết thực thi production của code(read) thu thập trong 3 ngày
Model Số lần gọi Lần gọi chứa đủ cả 25 thuộc tính
gpt-5.6 6,635 6,635 lần, 100%
claude-opus-4.8 2,898 4 lần, 0.1%
claude-sonnet-5 1,933 0 lần

  • Nguyên nhân phát sinh đọc file rỗng

    • Vấn đề không chỉ nằm ở chỗ tham số quá dài dòng, mà ở việc phần triển khai đọc file không thể phân biệt giữa giá trị model tự bịa ra và giá trị người dùng thực sự mong muốn
    • Triển khai coi offset: 0 là tham số thật, khiến 52~64% lượt đọc file của GPT-5.6 trả về kết quả rỗng
    • Công cụ trả về success: true cho cả lượt đọc hợp lệ lẫn đọc rỗng, nên model không nhận ra rằng mình đang đọc file rỗng
    • Việc tăng số lần gọi để bù cho kết quả rỗng còn khiến chất lượng đầu ra giảm thêm

  • Prompt và strict mode không giải quyết được vấn đề

    • Thêm chỉ dẫn trong mô tả công cụ yêu cầu bỏ qua các tham số không dùng vẫn không ngăn được việc sinh đủ 25 trường
    • Gắn OPTIONAL, omit if unused vào từng thuộc tính cũng không làm hành vi thay đổi
    • Ngay cả strict mode của OpenAI cũng cho kết quả tương tự; hơn nữa muốn dùng nó thì phải loại bỏ pattern, format và kiểm tra kích thước mảng khỏi mọi schema
    • Vì hành vi này xuất phát từ cách model tạo function calling, nên nhóm đã đổi schema thay vì sửa prompt

  • Chuyển đổi schema ở ranh giới theo nhà cung cấp

    • Với các model họ OpenAI, mọi thuộc tính tùy chọn được viết lại thành các thuộc tính bắt buộc·nullable dạng anyOf: [T, null]
    • Model sẽ điền null tường minh cho các tham số không dùng, sau đó null được loại bỏ trước khi xác thực ở ranh giới gọi công cụ dùng chung
    • Không thay đổi phần triển khai công cụ, chỉ cho phép schema dành cho model biểu diễn được giá trị không dùng
    // Trước thay đổi: cả 25 khóa đều được điền bằng giá trị bịa ra
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// Sau thay đổi: gửi 4 giá trị thật và 21 giá trị null, rồi loại null trước khi thực thi công cụ
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • Sau thay đổi, tỷ lệ đọc file rỗng giảm từ 52% xuống 0%
    • Số lần gọi công cụ cần cho cùng một tác vụ cũng giảm khoảng 30% vì không còn lặp lại việc đọc kết quả rỗng

Prompt caching được điều chỉnh theo cách của OpenAI

  • Cả hai nhà cung cấp đều hỗ trợ prompt caching, nhưng cách triển khai khác nhau
  • Trước khi phản ánh khác biệt này, GPT-5.6 trông có vẻ đắt hơn Opus khoảng 50%, nhưng nguyên nhân là cấu hình cache chứ không phải giá model

  • Cache cấp tổ chức của Anthropic

    • Prompt của agent bắt đầu bằng một tiền tố tĩnh khoảng 29.000 token gồm schema công cụ và prompt hệ thống cốt lõi, giống nhau trong mọi cuộc hội thoại
    • Trên Claude, cache_control được dùng để đánh dấu breakpoint cache và tiền tố này được chia sẻ trên toàn tổ chức
    • Bất kỳ cuộc hội thoại nào trong bất kỳ workspace nào cũng có thể dùng cùng một mục chia sẻ, và cũng không có giới hạn thông lượng theo key
    • Tỷ lệ cache hit đạt 92~96%

  • Hành vi cache thay đổi trên GPT-5.6

    • Các model GPT trước đây ngầm cache khớp tiền tố từng phần, nhưng GPT-5.6 đã loại bỏ khớp tiền tố từng phần
    • Vì cache ngầm tạo mục toàn prompt dựa trên tin nhắn mới nhất, nên ngay cả các cuộc hội thoại mới cùng chia sẻ tiền tố tĩnh 29.000 token cũng có tỷ lệ hit 0% ở lần gọi đầu
    • Kết quả là toàn bộ tiền tố lại bị tính phí như input không cache ở mỗi cuộc hội thoại
    • Dù ứng dụng có dùng cache hay không, GPT-5.6 vẫn áp dụng phụ phí ghi cache 1,25 lần cho mọi prompt không cache

  • Ràng buộc của cache key tường minh

    • Cache tường minh yêu cầu prompt_cache_breakpoint và prompt_cache_key bắt buộc
    • Bản thân key cũng là một phần của danh tính cache, nên cùng một prompt nhưng khác key thì sẽ không hit
    • Mỗi key được ánh xạ tới một node cache xử lý khoảng 15 request mỗi phút; nếu vượt quá mức này, OpenAI sẽ phân tán lưu lượng sang node khác có cache lạnh riêng
    • Vì vậy việc chọn đơn vị gán key là quyết định thiết kế quan trọng
    • Key theo hội thoại: hội thoại mới không thể hit tiền tố dùng chung, nên tỷ lệ hit ở lần gọi đầu là 0%
    • Một key toàn cục: mọi request bị hash vào một node, và khi lưu lượng production vượt 15 rpm thì bị dồn sang node lạnh
    • Key theo workspace: mọi hội thoại của workspace khách hàng cùng chia sẻ mục cache, trong khi lưu lượng trên mỗi key vẫn thấp

  • Cache phân tầng theo workspace

    • Cấu hình thực tế dùng key theo workspace dạng ws:{workspaceId} và chia system prompt thành các tầng breakpoint
    • Mục A chứa công cụ và tiền tố tĩnh để giảm chi phí cho lần gọi đầu của phiên
    • Mục B thêm ngữ cảnh workspace vào tiền tố tĩnh
    • Mục C là toàn bộ chuỗi prompt theo từng phiên kéo dài từ lượt đầu đến tin nhắn mới nhất
    • Khi bộ nhớ workspace thay đổi, mục B có thể trượt nhưng mục A vẫn hit, nên chỉ phần ngữ cảnh thay đổi mới phải ghi lại thay vì toàn bộ 29.000 token
    • Mục C tận dụng chuỗi toàn prompt ngầm của OpenAI trong một phiên vì prompt có cấu trúc append-only nghiêm ngặt
    • Do cơ chế phân vùng key của OpenAI, không thể chia sẻ tiền tố tĩnh giữa các workspace
    • Trong khi đó Anthropic dùng cache cấp tổ chức không phân vùng key nên có thể chia sẻ tiền tố
    • Với GPT-5.6, mỗi workspace sẽ thực hiện một lần ghi lạnh 29.000 token trong mỗi khoảng idle, với chi phí khoảng $0.18
    • Chi phí này bị giới hạn về phạm vi và có thể dự đoán được

  • Kết quả sau khi sửa cache

    • Tỷ lệ hit cache ở lần gọi đầu tăng từ gần 0% lên 83.7%
    • Tổng số input token không cache giảm 28%
    • Chi phí trên mỗi bộ đánh giá của GPT-5.6 đã thấp hơn Opus, và toàn bộ chênh lệch chi phí ban đầu đến từ cấu hình cache sai
    • So sánh chi phí giữa các model khi chỉ một model bắt đầu từ cache lạnh là không hợp lệ

Chuyển phát lại suy luận sang dạng tự chứa

  • Responses API của GPT-5.6 mặc định phát lại suy luận từ lượt trước bằng tham chiếu tới mục phía server, và trong hội thoại production thỉnh thoảng phát sinh lỗi Item 'rs_...' not found
  • Khi đặt store: false, SDK sẽ yêu cầu nội dung suy luận được mã hóa và phát lại một blob tự chứa thay vì con trỏ trỏ đến trạng thái phía server
  • Ngay cả khi byte mà ứng dụng gửi đi có cấu trúc append-only, trạng thái suy luận phía server vẫn có thể làm thay đổi prompt hợp lệ
  • Sau khi sửa toàn bộ bộ khung đánh giá, schema công cụ, prompt cache và phát lại suy luận, GPT-5.6 Sol hiện đang được vận hành làm model mặc định production của Ploy

Bài viết liên quan

1 bình luận

 
GN⁺ 7 giờ trước
Ý kiến trên Hacker News

  • Những câu kiểu “với con số như vậy thì mô hình thực sự đáng để migration” nghe quá lố bịch. Giá mà người nhờ viết bài ít nhất cũng chỉnh lại cái văn phong LLM điển hình thì tốt hơn
    Cách nối các cụm ngắn bằng dấu hai chấm, dấu phẩy và dấu chấm cũng tệ và gây khó chịu. Có những insight hay, như việc cache khớp tiền tố một phần đã biến mất trong GPT-5.6, nhưng đây không phải bài dễ đọc

    • Vì vậy bên cạnh AGENTS.md hay CLAUDE.md tôi luôn đặt thêm WRITING.md. Phần lớn mọi người chỉ nói cho mô hình biết cần tạo ra cái gì, còn gần như không nói phải viết như thế nào, nhưng LLM tuân theo chỉ dẫn rõ ràng về văn phong tốt đến đáng ngạc nhiên
      Tôi viết các quy tắc để tránh dấu hai chấm không cần thiết, dấu gạch ngang dài, các mảnh câu giả làm nhấn mạnh và những lỗi ngữ pháp tôi hay mắc; đồng thời đưa Brian Kernighan và Rob Pike — với lối viết kỹ thuật rõ ràng, có tính đối thoại và không khoe mẽ — làm mẫu tham khảo. Tài liệu không chỉ cần dễ đọc mà còn phải khiến người ta muốn đọc
      Nếu bạn thường xuyên tạo tài liệu, rất đáng để cho agent tham chiếu WRITING.md. Khả năng đọc thường cải thiện nhiều hơn hẳn so với việc đổi sang mô hình mới nhất, và bạn có thể giữ văn phong nhất quán ngay cả khi thay mô hình
    • Đặc biệt nếu là công ty AI thì trông còn tệ hơn. Điều đó chỉ có thể nghĩa là họ không dùng mô hình đủ nhiều nên không nhận ra văn phong đặc trưng, hoặc không ý thức được chuyện đó quan trọng, hoặc không hiểu bối cảnh chung, hoặc không tôn trọng độc giả; hướng nào cũng chẳng hay
    • Bạn đang đọc sai cách rồi. Chỉ cần bảo LLM đọc và tóm tắt theo sở thích văn phong của mình là được. Xa hơn nữa, đừng tự đọc gì cả, hãy để agent chuyển nó thành skill file để tham khảo về sau
    • Nếu nghi một bài được viết bằng LLM, tôi lập tức dừng đọc và dùng công cụ LLM của mình để tóm tắt hoặc viết lại. Như vậy ít nhất tôi còn kiểm soát được phần nào văn phong đầu ra
    • Trong claude.md tôi đang dùng, tôi đã cấm cụm “load-bearing”, và Claude thật sự ghét điều đó. Nó thích cụm này quá mức, đến nỗi đôi khi còn trêu trong chú thích kiểu “load-be…most specific”

  • Tôi từng chuyển nhiều workflow nhỏ, đơn giản chạy trên 5.4-nano và mini sang 5.6, và nhìn chung mức cải thiện nằm trong khoảng bài viết nêu; một số tác vụ phân loại còn cải thiện cả chất lượng
    Ở nhiều công ty, kiểu nâng cấp mô hình này thực chất chỉ là đổi một dòng code. Với các workflow cốt lõi thì chúng tôi dùng kiến trúc router mô hình rất tốt, nhưng không đáng cấu hình như vậy cho các tác vụ đơn giản, và cũng phải cân nhắc vấn đề ổn định

    • Trọng tâm của bài này là việc nâng cấp mô hình không phải là đổi một dòng code
    • Bạn dùng SDK nào? Hay tự triển khai?
    • Mục đích ban đầu khi dùng Sol là đánh giá 5.6 trong workflow của chúng tôi. Trước đây, chất lượng của các mô hình đơn giản không đủ nên chúng tôi dùng 5.5 cho mọi tác vụ; hiện giờ chúng tôi phân tích cả văn bản lẫn hình ảnh để trích xuất dữ liệu có cấu trúc, cả tường minh lẫn ngầm định, từ dữ liệu nguồn rất lộn xộn
      Nhìn chung nó hoạt động đúng như quảng cáo. Hiện tại chúng tôi chuyển phần lớn tác vụ sang terra, nhờ vậy chi phí giảm một nửa và thời gian phản hồi cũng cải thiện 50%. luna được dùng để bổ sung cho kết quả phát hiện của OpenCV; tính năng rất hạn chế nhưng nhanh và gần như miễn phí. Sol chỉ nhỉnh hơn terra một chút trong tác vụ của chúng tôi
      Sol ultra cũng thực hiện phần đánh giá rất tốt. Nó tạo ra một bộ tài liệu lớn gồm các khuyến nghị hợp lý, danh sách output cần tự kiểm tra và so sánh, dữ liệu gốc và dữ liệu đã xử lý, cùng CPM theo từng truy vấn. Ngoài phí thuê bao Pro, chúng tôi không tốn thêm gì; sau vài giờ chạy, chi phí chuẩn giảm 50% và throughput tăng 100%

  • Trải nghiệm của tôi cũng tương tự. Các dịch vụ quảng bá failover như OpenRouter hầu như vô dụng ngoài thử nghiệm sandbox. Trong production, các mô hình thực tế không thể thay thế lẫn nhau; môi trường thực thi cho các tác vụ agent nghiêm túc phụ thuộc vào nhiều đặc tính riêng của từng mô hình hơn tưởng tượng rất nhiều
    Ngay cả khi một mô hình khác hoạt động không lỗi, hiệu năng và hiệu quả là chuyện riêng. Có những mô hình như dòng Claude cần điều chỉnh system prompt cho phù hợp với cách diễn đạt mà nó đã quen trong quá trình huấn luyện, trong khi mô hình khác lại hoạt động tốt hơn với delimiter khác. Nếu hiệu năng tối ưu là quan trọng, cần xem môi trường thực thi, prompt và mô hình như một hệ thống duy nhất, không nên nghĩ rằng có thể tự do thay thế như các linh kiện

    • Cần xây dựng kế hoạch failover đúng nghĩa trong LLMOps, kiểm tra đầy đủ các đường thực thi công cụ, v.v. Khi đó bạn có thể xếp các mô hình đủ tốt theo thứ tự từ rẻ đến đắt để triển khai failover mong muốn
      Tôi từng thấy có người tạo bảng ánh xạ dạng model -> {{prompts}, {tools descriptions}, ...}, nhưng như vậy quá cực đoan. Đến một thời điểm nào đó, mô hình phải thích nghi với prompt của chúng ta; mô hình nào không làm được thì loại khỏi danh sách failover và không gửi API request đến nó
    • OpenRouter không failover sang mô hình khác, mà chuyển sang nhà cung cấp khác có cùng mô hình

  • Thật mỉa mai khi dưới một bài đầy insight sâu về hạ tầng, một nửa bình luận lại chỉ phê phán văn phong gượng gạo. Dù Claude có giúp trau chuốt câu chữ đi nữa, nếu bài viết chứa một blueprint có thể áp dụng ngay để giảm 30% ngân sách API và sửa lỗi đọc file rỗng, chẳng phải điều đó quan trọng hơn sao

    • Có thể có người ghét bất cứ thứ gì liên quan đến AI nên bắt bẻ, nhưng cũng có người thật sự không chịu nổi văn phong đó nên chỉ bám vào nó
      Cá nhân tôi thấy việc càm ràm về văn phong khá buồn cười. Có lẽ vì tôi yếu ngữ pháp và chính tả nên tôi tập trung vào nội dung cốt lõi như khái niệm, sự kiện và lập luận hơn là cách truyền đạt. Ngữ pháp và chính tả chỉ là cái cây; khu rừng mới là trọng tâm
      Bài viết của tôi không có quá nhiều lỗi là nhờ đọc chính tả và các phím tắt tự tạo. Chúng lấy đoạn văn bản được chọn, sửa bằng LLM cục bộ rồi thay thế lại; không có công cụ nào cải thiện chất lượng sống và chất lượng viết của tôi nhiều như hai thứ này

  • “Từ hôm nay, agent Ploy dùng GPT-5.6 Sol được công bố sáng nay” — vậy là họ chuyển đổi chỉ sau nửa ngày thử nghiệm thôi sao? Công ty này do đám thiếu niên điều hành à?

    • Thực ra đội ngũ nhân sự gần với cấp Staff và Senior Staff hơn. Thông qua quan hệ với YC, họ đã thử nghiệm mô hình preview GPT-5.6 trong khoảng một tuần và cung cấp phản hồi
      Công việc đánh giá chạy trên GitHub CI, và có thể chạy hết một bộ đánh giá hơn 115 tác vụ về thiết kế web/marketing — lĩnh vực ploy.ai chuyên về — trong khoảng 15 phút. Sau khi bật mô hình bằng feature flag của PostHog, họ chủ động giám sát các lỗi
      Họ đang cố chuyển tối đa kiến thức từ việc vận hành Webflow, nền tảng hỗ trợ hơn 1% Internet, sang Ploy để hỗ trợ phần Internet lớn hơn nữa
    • Rất có khả năng họ đã được cấp một mức quyền truy cập sớm nhất định để có thể đánh giá và viết bài như thế này
    • Giờ đây việc tạo đánh giá và benchmark rồi chạy trên các mô hình mới nhất đã khá dễ. LLM dễ thay thế, nên một bộ đánh giá tốt rất hữu ích; đôi khi mức cải thiện rõ ràng đến mức thậm chí không cần đánh giá
    • Có thể họ có một dataset dựa trên production để so sánh mô hình mới

  • Dù agent Ploy được nói là tạo và chỉnh sửa website marketing thật, lập kế hoạch, đọc codebase, viết component, tạo ảnh, tự chụp kết quả và phán đoán đã hoàn tất hay chưa, thì ngay cả khi chưa kiểm thử nghiêm ngặt, tôi vẫn dự đoán Fable sẽ làm website marketing tốt hơn Opus rất nhiều. Với việc tạo tài liệu thuyết trình thì chắc chắn tốt hơn hẳn

    • Về thiết kế, GPT-5.6 tốt hơn Fable rất nhiều
    • 4.7 có xu hướng làm theo chỉ dẫn quá sát nghĩa, nên kết quả trong bài gốc cũng khá hợp lý

  • Cách xử lý chỉ riêng với các mô hình dòng OpenAI là biến mọi thuộc tính tùy chọn thành bắt buộc nhưng cho phép null bằng anyOf: [T, null] nghe có mùi sai sai. Tôi mới chỉ dùng một dạng MCP đã được biến đổi, nhưng không rõ tại sao định nghĩa kiểu TypeScript lại ảnh hưởng đến JSON Schema mà agent gửi cho backend suy luận
    Trong đặc tả MCP có trường thể hiện tham số tùy chọn một cách rõ ràng, nên có vẻ có lỗi ở đâu đó giữa tầng TypeScript và phần mô tả công cụ thực sự được truyền đi. Cũng có thể backend suy luận đã chuyển từ “tạo phản hồi công cụ hợp lệ” sang “tạo phản hồi hợp lệ theo JSON Schema không có tham số tùy chọn”, nhưng nếu không xem request thực tế thì không thể kết luận

    • Đây không phải lỗi sinh schema hay lỗi TypeScript, mà là cách hoạt động nội bộ của OpenAI function calling. Các trọng số được fine-tune cho việc dùng công cụ có xu hướng xuất ra cấu trúc dữ liệu đầy đủ nhất có thể. Khi mô hình thấy tên tham số trong ngữ cảnh system prompt, nó sẽ cố điền giá trị dù tham số đó không nằm trong mảng required
    • Các mô hình frontier mới nhất, gồm Fable, Opus và 5.6, khá lỏng lẻo khi gọi công cụ và thường không tuân thủ schema chính xác. Có thể xem ví dụ các mô hình Claude bịa ra thuộc tính không tồn tại trong lệnh gọi công cụ edit/replace của Pi tại https://lucumr.pocoo.org/about/
      Một phần nguyên nhân có vẻ liên quan đến hiện tượng constrained decoding làm giảm trí thông minh. Tính hợp lệ của schema được đảm bảo, nhưng năng lực giảm mạnh, nên có thể ổn cho phân loại, tóm tắt, cải thiện prompt, còn với các vòng lặp agent thì cần cẩn thận
      Các môi trường chạy như Claude Code thực hiện rất nhiều tiền xử lý, khôi phục, dọn dẹp, v.v. nhưng thường không lộ ra ngoài. Trong thực tế, thay vì giả định và cưỡng ép độ chính xác hoàn hảo, việc làm môi trường chạy lỏng hơn để thích nghi với đặc tính từng mô hình thường dễ hơn và tốt hơn. Mô hình cũng thay đổi mỗi một hai tháng. Đây chính là AI ứng dụng được xây bằng cảm giác

  • Tôi muốn biết con số ước chừng chi phí thực tế để tạo một site bằng Opus và bằng Sol lần lượt là bao nhiêu

  • Khi chuyển workflow sang Reasonix và tận dụng cache hit trên DeepSeek, chi phí request gần như miễn phí dù dùng nhà cung cấp Mỹ không được trợ giá

    • Bạn dùng thiết lập nào, và so với Pi thì thế nào?

  • Thay vì mặc định dùng GPT-5.6 Sol cho mọi workspace của Ploy, có thể cân nhắc Luna cho một số tác vụ xử lý công cụ thực tế. Nó giỏi và nhanh đến đáng ngạc nhiên
    Sol rất mạnh trong việc trò chuyện với con người và điều phối các lệnh gọi agent, nhưng quá đắt để dùng cho mọi việc. Với giá một lần chạy Sol có thể chạy Luna năm lần, và về mặt thống kê, khác biệt giữa một mẫu và năm mẫu là khá lớn

    • Nếu mỗi bước của lần chạy Luna đúng với xác suất 90%, thì xác suất cả năm bước đều đúng là 0.9^5 = 0.59, tức 59%. Độ chính xác của một lần chạy Sol có thể vào khoảng 95%. Số liệu thực tế sẽ khác, nhưng có thể rẻ hơn nếu cuối cùng dùng Sol để kiểm chứng
    • Sub-agent luôn gặp vấn đề là chúng bị cô lập với nhau. Điều này có ưu điểm là giữ ngữ cảnh nhỏ và tập trung, nhưng để tiếp tục việc được giao, mỗi sub-agent lại phải tự điều tra lại, nên thường tiêu tốn token không được cache
      Tùy vào việc dùng bao nhiêu agent cho tác vụ nào, chi phí có thể tăng mà kết quả lại còn tệ hơn