DeepSeek Flash đã sửa đổi: thiết kế trạng thái API trước khi viết mã

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-deepseek-v4-1-flash",
    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)

Lấy một tác vụ xuất báo cáo làm ví dụ

Một ứng dụng nhận yêu cầu xuất báo cáo rồi trả liên kết khi xong. Người dùng có thể đóng trang trước khi có liên kết, và công việc vẫn chạy phía máy chủ. Trước khi viết API, hãy phân biệt chưa gửi, đã nhận, đang xử lý, hoàn tất và thất bại có xác nhận. Không dùng một cờ đang tải để thay toàn bộ vòng đời.

Cho mô hình biết bên nào tạo mã công việc, dữ liệu nào được giữ và điều kiện được phép hủy. Nếu đây là hệ thống bạn đang thiết kế, có thể đề xuất cơ chế chống trùng của riêng hệ thống đó. Đừng nhầm đề xuất ấy với một tính năng đã tồn tại trên API công khai Dikaya; hợp đồng phải được triển khai và kiểm thử trước khi hứa.

Viết bảng sự kiện và điều kiện chuyển

Mỗi hàng nên có trạng thái trước, sự kiện, điều kiện, trạng thái sau và phản hồi cho máy khách. Với hoàn tất, nêu bằng chứng như báo cáo được lưu và bản ghi trạng thái được ghi cùng một quy tắc nhất quán. Với hủy, chỉ rõ yêu cầu hủy đã được nhận hay công việc đã thực sự dừng; hai mốc không được dùng thay nhau.

Yêu cầu chỉ ra chuyển trạng thái không hợp lệ và cách phản hồi khi sự kiện lặp. Ví dụ một thông báo hoàn tất đến sau yêu cầu hủy có thể cần quy tắc ưu tiên theo trạng thái đã xác nhận, không theo thứ tự giao diện hiển thị. Nếu hợp đồng chưa có đáp án, ghi câu hỏi cần quyết định thay vì tự chọn cách thuận tiện cho đoạn mã.

Đặt trạng thái chưa rõ vào thiết kế ngay từ đầu

Máy khách có thể biết đã gửi nhưng chưa biết máy chủ đã nhận. Đây là trạng thái quan sát, không phải kết luận công việc chưa tồn tại. Thêm đường đối chiếu bằng mã công việc hoặc cơ chế của chính ứng dụng bạn đang xây. Không tự biến timeout thành thất bại cuối rồi tạo công việc mới, vì việc cũ có thể đang hoàn tất.

Nguồn MDN giúp giải thích rằng Fetch trả Response cho mã HTTP lỗi, trong khi kết nối đứt có thể từ chối Promise. Abort cũng có thể xảy ra sau khi đã nhận tiêu đề nhưng trước lúc đọc xong thân. Các cơ chế này không tự nói gì về việc lưu dữ liệu hoặc chi phí; chính hợp đồng và trạng thái máy chủ mới cung cấp bằng chứng cần thiết.

Biến bảng trạng thái thành ca kiểm thử

Tạo kiểm thử cho gửi hai lần, nhận xác nhận chậm, mất phản hồi sau khi lưu, hủy khi đang chờ và hoàn tất đến sát lúc hủy. Mỗi ca phải nêu kết quả quan sát và bất biến cần giữ, chẳng hạn không tạo hai báo cáo cho cùng mã theo hợp đồng tự thiết kế. Chỉ tên ca kiểm thử đẹp không chứng minh cơ chế đó hoạt động.

Có thể yêu cầu DeepSeek đề xuất cách giả lập đồng hồ và sự kiện để kiểm thử cục bộ, nhưng mã phải được chạy trong môi trường của bạn. Không trình bày đoạn đầu ra minh họa như kết quả chạy thật. Chat và API không tự có quyền thực thi lệnh; công cụ IDE hoặc bộ chạy kiểm thử là thành phần tích hợp riêng cần được cho phép.

Giữ đúng ID và điều khiển của mô hình

Bản đã sửa đổi này công bố low, high và max. Đây là điều khiển effort, không phải ba mức bảo đảm đúng thiết kế. Đặt trần đầu ra để nhận được bảng chuyển và các câu hỏi còn thiếu; nếu xin cả triển khai lẫn mọi kiểm thử, hãy chia phần có ranh giới thay vì trông đợi ngữ cảnh lớn xóa hết giới hạn truyền dữ liệu.

Ảnh sơ đồ đi qua cầu nối thành văn bản tính phí riêng; chỉ seller-flash có ảnh trực tiếp trong phạm vi danh mục này. Kiểm tra lại tên nút và hướng mũi tên sau bước chuyển. Cũng đừng đổi sang seller-deepseek-v4-1-flash-1017 mà giữ nhãn đã sửa đổi, bởi 1017 là bản gốc Safeguards với danh tính công khai riêng.

Áp dụng chính kỷ luật trạng thái cho lời gọi mô hình

Đặt max_retries=0 trong SDK Python nếu không muốn nó tự gửi lại khi gặp một số lỗi. Ghi riêng phản hồi HTTP từ chối đã biết và mất xác nhận qua mạng; trường hợp sau chưa chứng minh không phát sinh chi phí hoặc không lưu kết quả. Kiểm tra lịch sử trước khi gửi tay một lần mới, không dùng vòng lặp thử lại để che sự không chắc chắn.

Nút chuyển nội dung sang chat không chạy mô hình. Kiểm tra bộ chọn đúng ID, quyền tài khoản và bản nháp cũ trước khi gửi; demo không mở mọi mô hình. Tìm kiếm rõ ràng trong chat trả phí khác khả năng Internet của API. Tài liệu SDK hỗ trợ giao thức, không chứng minh chất lượng DeepSeek hoặc trạng thái sẵn sàng tại thời điểm đọc.

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

Bản DeepSeek này có phải bản 1017 Safeguards không?

Không. seller-deepseek-v4-1-flash là bản đã sửa đổi, còn ID có hậu tố 1017 là bản gốc Safeguards riêng. Giữ ID chính xác khi cấu hình, ghi nhật ký và so sánh công việc; không chuyển thuộc tính của bản này sang bản kia.

Timeout có nên chuyển công việc sang thất bại cuối không?

Không phải lúc nào cũng vậy. Máy khách có thể hết thời gian chờ trong khi máy chủ đã lưu hoặc đang xử lý. Thiết kế cần một trạng thái chưa rõ và đường đối chiếu theo hợp đồng, thay vì tự tạo lại công việc hoặc tuyên bố chưa có tác động.

Mô hình có thể tự chạy bộ kiểm thử cho API của tôi không?

Một câu trả lời chat không tự thực thi lệnh trên máy bạn. Nó có thể đề xuất mã và lệnh, còn kết quả cần bộ chạy thật. Nếu IDE tích hợp công cụ thực thi, quyền và nhật ký của công cụ ấy phải được kiểm tra riêng.

Có thể thêm khóa chống trùng rồi mặc nhiên coi Dikaya hỗ trợ không?

Không. Một trường tự đặt không tạo ra bảo đảm phía máy chủ. Bạn có thể thiết kế chống trùng cho ứng dụng của mình, nhưng API công khai Dikaya không được bài viết này gán cơ chế ấy. Hãy dựa vào hợp đồng được tài liệu xác nhận thay vì giả định.

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