GLM 5.3 trên Dikaya: giữ hợp đồng nhiều tệp và kiểm soát đầu ra

Ví dụ API tối thiểu

Mã Python minh họa, không phải phản hồi mô hình đã chạy. Khóa lấy từ môi trường, tự động thử lại đã tắt. Mất kết nối có thể khiến kết quả và chi phí đều chưa rõ: đừng gửi lại mù quáng.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-glm-5-3",
    max_tokens=512,
    messages=[{"role": "user", "content": "Lập danh sách kiểm tra cho nhiệm vụ của tôi. Tách dữ kiện nguồn khỏi giả định."}],
)
print(response.choices[0].message.content)

Biến yêu cầu mơ hồ thành hợp đồng liên tệp

Giả sử một biểu mẫu đổi tên trường từ mã kho sang mã điểm nhận. Thay đổi chạm giao diện, bộ kiểm tra đầu vào, kiểu dữ liệu và bộ chuyển đổi phản hồi. Trước khi xin mã, lập bảng mỗi trường đi từ đâu tới đâu, ai sở hữu phép chuyển và dữ liệu cũ phải được hiểu thế nào. Việc này giúp tránh sửa tên ở một nơi rồi bỏ quên nơi khác.

Yêu cầu mô hình chỉ ra hợp đồng chưa rõ: trường có bắt buộc không, giá trị rỗng nghĩa gì, phản hồi có giữ tên cũ hay không. Người phụ trách phải trả lời những câu hỏi đó trước bản vá. Không để một mặc định do mô hình tự chọn âm thầm trở thành quyết định sản phẩm, đặc biệt khi những máy khách cũ vẫn dùng định dạng trước.

Gửi tệp với ranh giới và phiên bản rõ ràng

Gắn đường dẫn cho từng đoạn mã và nói tệp nào là nguồn chuẩn của kiểu dữ liệu. Nếu chỉ gửi một phần tệp, đánh dấu chỗ bị lược bỏ để mô hình không giả định phần còn lại trống. Tách mã hiện tại khỏi diff đề xuất, bởi trộn hai bản vào cùng một khối dễ tạo ra bản vá dựa trên trạng thái không tồn tại.

Với ảnh sơ đồ, ID này không nhìn ảnh trực tiếp mà dùng cầu nối văn bản có tính phí riêng. Những mũi tên hoặc nhãn nhỏ cần được kiểm tra lại trong bản mô tả. Tốt hơn hãy bổ sung danh sách quan hệ bằng văn bản để hợp đồng không phụ thuộc hoàn toàn vào việc giải thích một ảnh có thể thiếu chi tiết.

Chọn effort theo câu hỏi, không theo cảm giác

low, high và max là các mức effort được công bố cho mô hình này. Chúng không phải chứng nhận bản vá đúng, cũng không phải lời hứa về thời gian chờ. Có thể bắt đầu bằng một câu hỏi hẹp như tìm nơi dùng trường cũ, rồi quyết định có cần phân tích sâu hơn; mỗi lần gửi vẫn là một yêu cầu riêng cần cân nhắc.

Đặt trần đầu ra phù hợp với sản phẩm cần nhận: bảng hợp đồng, danh sách tệp và diff có giới hạn. Không yêu cầu vừa giải thích toàn hệ thống vừa viết mọi tệp trong một đầu ra quá ngắn. Nếu kết quả bị cắt, ghi chưa hoàn tất và xác minh trạng thái; tăng effort không tự mở rộng giới hạn byte của yêu cầu hay lịch sử chat.

Kiểm thử theo đường đi của dữ liệu

Tạo ca kiểm thử từ biểu mẫu qua bộ kiểm tra tới phản hồi cuối. Thêm trường hợp máy khách cũ gửi tên cũ, cả hai tên xuất hiện và trường bị thiếu. Với mỗi trường hợp, ghi rõ chấp nhận, chuyển đổi hay từ chối. Những đáp án này phải được xác nhận bằng hợp đồng, không lấy từ hành vi hiện tại nếu chính hành vi đó đang cần sửa.

Yêu cầu bản vá chỉ sửa các tệp đã thống nhất và liệt kê chỗ còn cần xem. Sau khi áp dụng, chạy lệnh kiểm thử trong môi trường riêng và đọc diff để phát hiện thay đổi ngoài phạm vi. Mã trong câu trả lời không tự chạy; tính năng công cụ của IDE phụ thuộc ứng dụng tích hợp, không phải quyền thực thi lệnh gốc của API.

Giữ nguyên ý nghĩa của lỗi và lần gửi

SDK Python có cơ chế gửi lại mặc định; đặt max_retries=0 nếu muốn mỗi quyết định gửi đều rõ ràng. Phân loại lỗi trạng thái HTTP và lỗi kết nối thay vì gộp thành không thành công. MDN cũng chỉ rõ Fetch không tự từ chối Promise cho mọi mã HTTP lỗi; ứng dụng phải kiểm tra trạng thái trước khi diễn giải nội dung.

Mạng đứt sau khi máy chủ nhận việc có thể để kết quả và chi phí ở trạng thái chưa rõ. Không tuyên bố chưa lưu, chưa chạy hay không mất phí chỉ vì máy khách không nhận phần cuối. Giữ bản ghi thời điểm và nội dung phiên bản, đối chiếu trạng thái rồi mới gửi thêm; không tự bịa một cơ chế chống trùng cho API công khai.

Đọc nguồn và bàn giao thay đổi

Danh mục và bảng giá Dikaya mô tả cấu hình, còn tài liệu SDK và Fetch giải thích giao thức; không nguồn nào trong hai tài liệu giao thức chứng minh mô hình tốt hơn hay luôn sẵn sàng. Bảng giá công khai cũng không thay thế biểu phí của tài khoản hoặc trạng thái kiểm tra giá tại thời điểm yêu cầu. Giữ hai loại bằng chứng riêng trong ghi chú tích hợp.

Khi chuyển câu hỏi sang chat, kiểm tra seller-glm-5-3 có được chọn thật và có quyền sử dụng. Demo không hứa quyền ID này, bản nháp cũ có thể được ưu tiên, và thao tác chuyển không tự gửi. Tìm kiếm trong chat trả phí là lựa chọn rõ ràng; không suy rằng API tự tra Internet để bổ sung các tệp bạn chưa gửi.

Câu hỏi và trả lời

Mức max có bảo đảm sửa đúng hợp đồng nhiều tệp không?

Không. Effort là điều khiển được công bố, không phải kết quả kiểm chứng. Vẫn phải cung cấp hợp đồng rõ, đọc diff và chạy kiểm thử. Một câu trả lời dài hơn có thể vẫn bỏ sót máy khách cũ hoặc một đường chuyển dữ liệu.

Có thể dùng tên Pro 2 thay cho ID này trong cấu hình không?

Không nên làm vậy. seller-glm-5-3 và seller-pro-2 là hai ID công khai khác nhau dù Pro 2 được phép mô tả có nền tảng GLM-5.3 đã sửa đổi. Cấu hình, quyền và nhật ký cần giữ ID chính xác mà bạn định gửi.

Ngữ cảnh lớn có giữ toàn bộ mọi tệp của cuộc trò chuyện không?

Không thể suy ra điều đó. Ngữ cảnh mô hình, giới hạn lịch sử trình duyệt, thân JSON và trần đầu ra là những lớp khác nhau. Hãy lập danh mục tệp thực được đưa vào yêu cầu và đánh dấu những phần chỉ được nhắc tên nhưng chưa gửi.

Tài liệu SDK có chứng minh mô hình luôn sẵn sàng không?

Không. Tài liệu SDK chỉ hỗ trợ cách cấu hình, phân loại lỗi và gửi lại. Khả năng dùng một ID còn phụ thuộc cấu hình, quyền tài khoản và kiểm tra biểu phí hiện hành. Đừng dùng một ví dụ cú pháp làm bằng chứng đã chạy inference thành công.

Nguồn

Nội dung được biên soạn với sự hỗ trợ của AI. Ví dụ mang tính minh họa, không phải câu trả lời thực tế hay thử nghiệm so sánh. Nguồn bên ngoài không thay thế điều khoản dịch vụ.

• Dikaya: danh mục mô hình và điều kiện truy cập
  dikaya.cc
• Dikaya: hướng dẫn API và giới hạn yêu cầu
  dikaya.cc
• Dikaya: bảng giá công khai cần đối chiếu
  dikaya.cc
• OpenAI Python SDK: lỗi kết nối và tắt gửi lại tự động
  github.com
• MDN: trạng thái HTTP, đọc phản hồi và hủy Fetch
  developer.mozilla.org