
Gemini 2.5 Flash vs Claude 3.7 Sonnet: 4 hạn chế về sản xuất đã đưa ra quyết định cho tôi
Gemini 2.5 Flash vs Claude 3.7 Sonnet: 4 Production Constraints That Made the Decision for Me
Đánh giá mô hình Gemini 2.5 Flash và Claude 3.7 Sonnet cho động cơ tác nhân. Tôi có một quy tắc đơn giản khi chọn LLM cho Ozigi: không chọn dựa trên bảng xếp hạng điểm chuẩn. Sau khi ra mắt v2, trong...
Đánh giá về mô hình đèn flash Gemini 2.5 và Claude 3.7 Sonnet cho động cơ đại lý.
Tôi có một quy tắc đơn giản khi chọn LLM cho Ozigi: không chọn dựa trên bảng xếp hạng điểm chuẩn. Sau khi tôi ra mắt phiên bản v2, khi nhận được phản hồi, một người dùng đã đề xuất tôi sử dụng mô hình Claude vì chúng tốt hơn cho việc tạo nội dung so với Gemini. Mặc dù đề xuất nghe có vẻ hấp dẫn nhưng tôi phải chọn một mô hình dựa trên bốn hạn chế mà quy trình sản xuất của tôi không thể giải quyết được.
Hầu hết các so sánh "Gemini và Claude" đều đánh giá các khả năng có mục đích chung như viết mã, lý luận và viết sáng tạo. Điều đó hữu ích nếu bạn đang xây dựng một sản phẩm có mục đích chung.
Tôi đã không.
Ozigi là một công cụ nội dung. Bạn cung cấp cho nó một URL, một bản PDF hoặc ghi chú thô. Nó trả về một chiến dịch truyền thông xã hội có cấu trúc kéo dài 3 ngày dưới dạng tải trọng JSON mà giao diện người dùng ánh xạ trực tiếp vào thẻ giao diện người dùng.
Tính đặc thù đó khiến việc đánh giá dễ dàng hơn tôi mong đợi: Hai mô hình, Bốn ràng buộc. Một người chiến thắng rõ ràng trong ba hạn chế.
Đây là bài đăng thứ ba trong Loạt bài về Ozigi Changelog. Nếu bạn muốn biết lý do tại sao Ozigi tồn tại, hãy bắt đầu với cách tôi mã hóa công cụ nội bộ để trở thành công cụ đó và nhật ký thay đổi v2 đã giới thiệu kiến trúc mô-đun mà quyết định này được xây dựng dựa trên đó.
Đây là Bản ghi Quyết định Kiến trúc đầy đủ.
Thiết lập: Đường ống thực sự làm gì
Tuyến API cốt lõi trong Ozigi thực hiện điều này:
- Chấp nhận tải trọng
multipart/form-datachứa URL, văn bản thô và/hoặc tệp (PDF hoặc hình ảnh) - Tạo lời nhắc với các ràng buộc biên tập nghiêm ngặt được đưa vào ở cấp hệ thống
- Gửi mọi thứ tới LLM thông qua Vertex AI Node.js SDK
- Trả về phản hồi văn bản thô trực tiếp cho khách hàng
Giao diện người dùng sau đó thực hiện điều này:
const được phân tích cú pháp = JSON.parse(responseText);
setCampaign(được phân tích cú pháp.chiến dịch);
Không có phần mềm trung gian. Không có xác nhận lược đồ. Không có lỗi phục hồi trong đường dẫn hạnh phúc. Phân tích cú pháp thô, chuyển thẳng sang trạng thái React.
Dòng duy nhất đó là lý do tại sao việc lựa chọn mô hình lại quan trọng.
Ràng buộc 1: So sánh mô hình Gemini và Claude về độ ổn định đầu ra JSON
Yêu cầu: Mô hình phải trả về một đối tượng JSON hợp lệ — mọi lúc, không gói nó trong hàng rào mã đánh dấu, không thêm lời mở đầu hội thoại và không gây ảo giác về dấu phẩy ở cuối làm đứt JSON.parse().
Lược đồ đích trông như thế này:
{
"chiến dịch": [
{ "ngày": 1, "x": "...", "linkedin": "...", "bất hòa": "..." },
{ "ngày": 2, "x": "...", "linkedin": "...", "bất hòa": "..." },
{ "ngày": 3 , "x": "...", "linkedin": "...", "discord": "..."
]
Nó hiển thị chín bài đăng trên ba nền tảng trong khoảng thời gian ba ngày, với mọi trường đều bắt buộc.
Giao diện người dùng hiển thị từng trường thành một thẻ riêng biệt với các hành động chỉnh sửa, sao chép và xuất bản. Khóa bị thiếu không gây ra lỗi hiển thị — nó âm thầm hiển thị một thẻ trống.
Sự so sánh này đặc biệt giữa Gemini với việc thực thi responseSchema và Claude với JSON được nhắc chứ không phải giữa mức trần đầu ra cấu trúc của mỗi mô hình. Công cụ của Claude sử dụng với tool_choice: {type: "tool" thực thi lược đồ ở lớp giải mã và có thể đạt được độ tin cậy tương đương. Hạn chế có liên quan ở đây là cơ chế thực thi nào có sẵn và thiết thực trong ngăn xếp hiện có của tôi. Thông tin thêm về điều đó bên dưới.
Tôi đã chạy 500 thế hệ thử nghiệm tự động đối với cả hai mô hình nhắm mục tiêu lược đồ này, đo lường phần trăm phản hồi mà JSON.parse() chấp nhận mà không có ngoại lệ.
Khoảng cách 11,5% ánh xạ trực tiếp đến trạng thái giao diện người dùng bị hỏng đối với người dùng thực. Điều đó không được tôi chấp nhận đối với tính năng cốt lõi.
Việc sử dụng responseSchema của Gemini sẽ hoàn thành việc này. Theo Tài liệu về thế hệ được kiểm soát của Google, tính năng này sẽ ngăn mô hình trả về kết quả đầu ra không phù hợp với lược đồ của bạn. Đây không phải là hướng dẫn ở cấp độ nhắc nhở mà được thực thi ở lớp giải mã. Đây là cách triển khai sản xuất của Ozigi: lược đồ được xác định một lần ở đầu tuyến và được đính kèm trực tiếp vào cấu hình mô hình:
const sơ đồ phân phối = {
loại: "ĐỐI TƯỢNG" as const ,
thuộc tính: {
chiến dịch: {
loại: "ARRAY" as const,
mô tả: "Danh sách 3 bài đăng hàng ngày trên mạng xã hội.",
mục: { loại: "ĐỐI TƯỢNG" as const,
thuộc tính: {
ngày: { loại: "INTEGER" as const, description: " Số ngày (1, 2 hoặc 3)" },
x: { type: "STRING" as const, description: "Nội dung dành cho X/Twitter." },
linkedin: { loại : "STRING" as const, mô tả: "Nội dung dành cho LinkedIn." },
bất hòa: { loại: "STRING" as const, mô tả : "Nội dung dành cho Discord." },
},
bắt buộc: ["ngày", "x", "linkedin", "bất hòa"],
},
},
},
bắt buộc: ["chiến dịch"],
};
const mô hình = vertex_ai.getGenerativeModel({
model: "gemini-2.5-flash",
thế hệConfig: {
responseMimeType: "application/json",
Schema phản hồi: Schema phân phối,
},
});
JSON.parse() không thể bị lỗi ở trường bị thiếu, dấu phẩy ở cuối hoặc lời mở đầu cuộc hội thoại — mô hình bị ngăn cản về mặt vật lý trong việc tạo ra chúng.
Việc sử dụng công cụ và gọi hàm của Claude có thể đạt được sự đảm bảo tương tự, nhưng nó đòi hỏi một kiến trúc tích hợp khác biệt một cách có ý nghĩa. Với Vertex SDK, đây là một khối cấu hình.
Người chiến thắng: Song Tử.
Ràng buộc 2: So sánh Gemini và Claude về độ trễ trên Sandbox công khai trực tiếp
Yêu cầu: Ozigi có hộp cát miễn phí, chưa được xác thực. Bất kỳ ai cũng có thể tạo chiến dịch kéo dài 3 ngày đầy đủ mà không cần đăng ký.
Điều đó thay đổi hoàn toàn tính kinh tế của việc lựa chọn mô hình. Người dùng trả phí sử dụng gói cao cấp sẽ chấp nhận thời gian chờ 20 giây nếu chất lượng đầu ra phù hợp với điều đó. Một người dùng ẩn danh đã tìm thấy sản phẩm thông qua nỗ lực tiếp thị mạnh mẽ của tôi sẽ không tìm thấy. Thật đáng buồn là họ sẽ đóng tab sau 10 giây và có thể không quay lại.
Tôi đã đo điểm chuẩn của cả hai mô hình với tải trọng đầu vào 10.000 mã thông báo tiêu chuẩn thông qua các chức năng không có máy chủ của Vercel (môi trường sản xuất của tôi):
Phương pháp: N=100 yêu cầu trên mỗi mô hình, được đo lường từ đầu đến cuối từ lệnh gọi hàm Vercel đến phản hồi đầy đủ. Kết quả phụ thuộc vào môi trường và nhằm mục đích so sánh định hướng chứ không phải là điểm chuẩn tuyệt đối.
Khoảng cách tồn tại ở các kích thước tải trọng. Gemini Flash liên tục xuất hiện trong vòng dưới 10-15 giây. Claude 3.7 Sonnet luôn vượt quá 20 giây trên cùng một đầu vào, trong cùng một môi trường.
Khoảng cách này sẽ thu hẹp đáng kể khi phát trực tuyến: nhận mã thông báo đầu tiên trước mặt người dùng trong vòng 2-3 giây. Truyền trực tuyến thay đổi hoàn toàn thời gian chờ đợi được nhận thức của người dùng. Tuy nhiên, đây là hạng mục kiến trúc v4 đang được thực hiện. Đối với quy trình không phát trực tuyến có hộp cát công khai, mức chênh lệch độ trễ 3,5 lần là quyết định về sản phẩm chứ không chỉ là quyết định về mặt kỹ thuật.
Người chiến thắng: Gemini Flash — và nó không phù hợp với các hộp cát công cộng không phát trực tuyến.
Ràng buộc 3: So sánh Gemini và Claude về việc sử dụng đa phương thức bản địa
Yêu cầu: Người dùng có thể tải trực tiếp các tệp PDF và hình ảnh lên dưới dạng ngữ cảnh. Quy trình cần xử lý chúng mà không cần thực hiện bước tiền xử lý bên ngoài.
Với Gemini thông qua Vertex AI Node.js SDK, toàn bộ quy trình PDF là:
// /app/api/generate/route.ts
if (tệp && tệp.kích thước > 0) {
const arrayBuffer = đang chờ tệp.arrayBuffer();
const base64Data = Bộ đệm.từ(arrayBuffer).toString("base64 ");
các bộ phận.đẩy({
inlineData: {
dữ liệu: base64Data,
mimeType: tệp.loại, // "application/pdf", "image/jpeg", v.v.
},
});
const kết quả = await model.generateContent({
nội dung: [{ vai trò: "người dùng", các bộ phận: các bộ phận }],
});
Bạn có thể thấy SDK xử lý bộ đệm một cách tự nhiên. Gemini đọc tệp PDF trực tiếp như một phần của yêu cầu nhiều phần cùng với lời nhắc văn bản — không có bước OCR, không xử lý trước, không có cuộc gọi dịch vụ riêng biệt. Tài liệu đa phương thức của Google xác nhận rằng Gemini được thiết kế ngay từ đầu để xử lý các bộ đệm hình ảnh và PDF một cách tự nhiên thông qua inlineData.
Phiên bản trước của bài viết này tuyên bố rằng Claude yêu cầu bước OCR bên ngoài để nhập PDF. Điều đó đã sai. API Tin nhắn của Claude hỗ trợ việc nhập PDF base64 trực tiếp thông qua khối nội dung tài liệu — không cần xử lý trước OCR, không có dịch vụ bên ngoài. Mẫu này có cấu trúc tương tự như InlineData của Vertex AI, chỉ khác tên trường.
Hạn chế thực sự ở đây là hệ sinh thái chứ không phải năng lực. Tôi đã đánh giá Claude 3.7 Sonnet có sẵn trong Google Model Garden trong thiết lập Vertex AI hiện tại của tôi. Việc chuyển sang chế độ nhập PDF gốc của Claude có nghĩa là chuyển hoàn toàn sang Anthropic Messages API — một nhà cung cấp khác, SDK khác, cách thanh toán khác. Đường dẫn AI của Vertex đơn giản hơn đối với ngăn xếp mà tôi đang chạy.
Người chiến thắng: Gemini — cho ngăn xếp này. Cả hai mô hình đều hỗ trợ nhập đa phương thức gốc mà không cần OCR bên ngoài. Ưu điểm ở đây là sự phù hợp với hệ sinh thái chứ không phải sự khác biệt về năng lực cơ bản.
Ràng buộc 4: So sánh Google Gemini và Claude về Kỹ thuật giai điệu
Yêu cầu: Các bài đăng trên mạng xã hội được tạo ra phải giống như do con người viết chúng. Cụ thể, họ phải vượt qua khả năng phát hiện nội dung của AI và tránh các mẫu nhịp có thể dự đoán được khiến bản sao do AI tạo ra có thể được nhận dạng ngay lập tức.
Đây là hạn chế khiến Claude giành chiến thắng hoàn toàn dựa trên thành tích cơ bản.
Các đánh giá A/B mù nội bộ của chúng tôi về 50 bài viết kỹ thuật (được chấm điểm dựa trên cấu trúc câu thực dụng và không có thuật ngữ AI) đã mang lại cho Claude 3.7 Sonnet "điểm chất lượng nhịp điệu của con người" là 9,5/10. Điểm cơ bản của Gemini Flash là 5,5/10.
Đó là một khoảng cách đáng kể. Và chính tính năng này là tuyên bố giá trị cốt lõi của Ozigi.
Tại sao nên sử dụng Gemini cho Kỹ thuật giai điệu?
Bởi vì khoảng cách có thể được xử lý.
Chúng tôi đã xây dựng Từ điển bị cấm - một ràng buộc có lập trình được đưa vào ở cấp độ nhắc của hệ thống nhằm trừng phạt rõ ràng các mẫu từ vựng khiến bản sao AI có thể bị phát hiện. Bạn có thể đọc cách triển khai đầy đủ trong Tài liệu về Ozigi:
Từ vựng bị cấm: Bạn bị nghiêm cấm sử dụng
những từ sau đây hoặc các biến thể của chúng: delve, di chúc, tấm thảm,
quan trọng, quan trọng, phong cảnh, vương quốc, mở khóa, siêu nạp, cách mạng hóa,
mô hình, liền mạch, điều hướng, mạnh mẽ, tiên tiến, có thể thay đổi cuộc chơi.
Kết hợp với kỹ thuật nhịp rõ ràng:
BURSTINESS (CADENCE): Viết với tốc độ bùng nổ cao. không sử dụng
câu có độ dài trung bình, cân bằng hoàn hảo. Trộn cực kỳ ngắn,
câu mạnh mẽ (2-4 từ) với lời giải thích dài hơn, chi tiết hơn.
BẤT NGỜ: Tránh dùng những tính từ có thể đoán trước được. Sử dụng động từ mạnh mẽ, tích cực
và danh từ cụ thể. Nói chuyện như một chuyên gia về chủ đề thực tế
giải thích một khái niệm cho mọi người chứ không phải một nhà tiếp thị bán sản phẩm.
HẠN CHẾ ĐỊNH DẠNG: Bạn bị giới hạn TỐI ĐA 1 biểu tượng cảm xúc cho mỗi
bài viết. Sử dụng tối đa 2 hashtag có liên quan cao cho mỗi bài đăng.
Khi những hạn chế này được kích hoạt, điểm nhịp điệu con người của Song Tử tăng từ 5,5 lên 9,2 — nằm trong phạm vi chấp nhận được so với cơ sở 9,5 của Claude.
Thông tin chi tiết quan trọng: Lợi thế về giọng điệu của Claude là lợi thế mặc định, không phải là tuyệt đối một. Kết quả đầu ra của Song Tử dễ uốn nắn hơn dưới những ràng buộc kịp thời. Đối với trường hợp sử dụng trong đó khả năng kiểm soát âm sắc là toàn bộ sản phẩm, tính linh hoạt đó có giá trị hơn mức cơ bản cao hơn.
Người chiến thắng: Song Tử + những hạn chế về mặt kỹ thuật. Khoảng cách âm thanh có thể thu hẹp lại. Không có khoảng trống về độ trễ và độ ổn định của JSON đối với các ràng buộc khác.
Người mẫu Gemini vs Claude: Thực tế chi phí
Ở giai đoạn này, khi Ozigi là một hộp cát công khai, mỗi lần tải trang ẩn danh có thể kích hoạt một thế hệ đều là một lệnh gọi API có tính phí được sản phẩm hấp thụ. Ozigi đang ở giai đoạn tiền doanh thu nên điều này rất quan trọng.
Giá được lấy từ Giá AI của Google Cloud Vertex và Giá API Anthropic.
Mẹo chuyên nghiệp:Xác minh giá hiện tại trước khi quyết định sản xuất — cả hai đều đã thay đổi nhiều lần trong năm qua.
Chi phí đầu vào chênh lệch là 40 lần. Chênh lệch chi phí đầu ra là 50 lần. Đối với sản phẩm cấp miễn phí không có doanh thu, khả năng chạy hộp cát công cộng một cách bền vững là sự khác biệt giữa việc có kênh chuyển đổi và không có kênh chuyển đổi.
Ozigi sẽ đi đâu và nó sẽ thay đổi sự lựa chọn hình mẫu của tôi như thế nào, tiến về phía trước
Đây là một ADR trung thực. Đây là điều sẽ thay đổi câu trả lời của tôi.
Khi Ozigi cuối cùng cũng vượt qua được tường phí, độ trễ và chi phí trở thành mối lo ngại thứ yếu. Người dùng đã đăng nhập trên gói trả phí có nhiều khả năng đợi 20 giây để có đầu ra cao cấp là một phép tính UX khác với người dùng ẩn danh trên bản demo miễn phí. Trong bối cảnh đó, chất lượng âm cơ bản của Claude trở nên hấp dẫn hơn nhiều. Tôi sẽ đánh đổi kinh tế học để lấy đường cơ sở sản lượng và giao dịch này có thể có giá trị.
Khi tính năng phát trực tuyến được triển khai, lập luận về độ trễ chống lại Claude sẽ giảm đi đáng kể. Mã thông báo theo thời gian đầu tiên của Claude 3.7 Sonnet thông qua phát trực tuyến có tính cạnh tranh. Người dùng nhìn thấy bài đăng đầu tiên xuất hiện sau 2-3 giây sẽ trải nghiệm sản phẩm rất khác so với người dùng nhìn chằm chằm vào thanh tiến trình trong 21 giây. Phát trực tuyến đang có lộ trình.
Để có cái nhìn sâu hơn về cách chúng tôi thử nghiệm quy trình đưa ra những quyết định này, hãy xem cách chúng tôi E2E thử nghiệm tác nhân AI với Playwright trong Next.js.
Ma trận quyết định
Song Tử đã thắng năm trong sáu lĩnh vực. Claude đã giành chiến thắng nhờ một — giai điệu cơ bản — và khoảng cách đó có thể thu hẹp nhờ kỹ thuật nhanh chóng.
Bốn câu hỏi cần hỏi trước khi chọn mô hình LLM cho dự án/ứng dụng đại lý của bạn
Nếu bạn đang xây dựng thứ gì đó tương tự như Ozigi thì đây là những ràng buộc bạn nên xem xét trước khi chọn API và bắt đầu xây dựng:
**1. Giao diện người dùng của bạn có phụ thuộc vào kết quả đầu ra có cấu trúc không? Nếu giao diện người dùng của bạn gọi JSON.parse() trên phản hồi mô hình thô, bạn cần thực thi lược đồ cấp API — chứ không phải yêu cầu hướng dẫn cụ thể. responseSchema thông qua Vertex AI, công cụ của Claude sử dụng với tool_choice bắt buộc hoặc kết quả đầu ra có cấu trúc thông qua OpenAI đều thực thi ở lớp giải mã. Câu hỏi không phải là mô hình nào hỗ trợ nó — hầu hết đều hỗ trợ — mà là đường dẫn thực thi nào phù hợp với ngăn xếp hiện tại của bạn.
2. Bạn có cấp miễn phí hay hộp cát công khai không? Nếu có, độ trễ và chi phí là các quyết định về sản phẩm ảnh hưởng đến chuyển đổi chứ không chỉ các quyết định về cơ sở hạ tầng ảnh hưởng đến lợi nhuận.
**3. Trường hợp sử dụng của bạn có yêu cầu đầu vào đa phương thức không? Hầu hết các mô hình chính hiện nay đều hỗ trợ nhập hình ảnh và PDF gốc mà không cần xử lý trước bên ngoài. Hãy vạch ra hình thức tích hợp trong nhà cung cấp API hiện tại của bạn trước khi cho rằng bạn cần chuyển đổi hoặc thêm cơ sở hạ tầng
4. Đâu là điểm yếu nhất của mô hình cơ sở và khoảng cách đó có thể xử lý được không? Lợi thế về giọng điệu của Claude là có thật. Đó cũng không phải là con đường duy nhất để có được bản sao giống con người. Những hạn chế về mặt kỹ thuật ở cấp độ nhanh chóng có thể thu hẹp những khoảng trống mà bạn cảm thấy không thể vượt qua khi chỉ nhìn vào điểm chuẩn cơ bản.
Mô hình tốt nhất cho sản phẩm của bạn hiếm khi là mô hình có điểm tổng hợp cao nhất. Đó là cách ít thất bại nhất đối với những ràng buộc mà bạn thực sự không thể giải quyết được.
- Cấu trúc Ozigi đầy đủ — bao gồm lộ trình tạo API, triển khai Lexicon bị cấm và cấu hình Vertex AI — là nguồn mở trên GitHub.
- Công cụ ngữ cảnh trực tiếp có tại ozigi.app.
- Phiên bản tương tác của ADR này với hình ảnh trực quan của Chart.js về từng điểm chuẩn.
- Ozigi hiện đang tìm kiếm Người kiểm tra trải nghiệm người dùng để đưa ra Phản hồi trung thực về trải nghiệm của họ khi sử dụng sản phẩm và các lĩnh vực cần cải thiện.
- Chúng tôi có một số vấn đề mở trên Github rất hoan nghênh sự đóng góp của cộng đồng. ps, cho đến nay, ứng dụng này đã được mã hóa hoàn toàn theo cảm xúc, vì vậy chúng tôi cũng hoan nghênh những đóng góp được mã hóa theo cảm xúc!
- Kết nối với tôi trên LinkedIn
- Gửi email cho tôi theo địa chỉ okolodumebi@gmail.com.
- Xây dựng osmething tuyệt vời? Hãy nói về nó trong phần bình luận!
Tác giả: Dumebi Okolo



