mô hình

jev-latest

Markdown · JSON

jev-latest

Mô hình ra quyết định của TypeSafe: không viết văn bản mà trả lời câu hỏi có kiểu về văn bản hoặc JSON — chọn phương án, chấm điểm theo thang hoặc «có/không» kèm xác suất. Phù hợp cho định tuyến, phân loại yêu cầu, kiểm duyệt và chấm điểm; mọi câu hỏi trong một yêu cầu được đánh giá song song.

Về mô hình

Mô tả này trình bày khả năng của mô hình. Đầu vào, đầu ra và tùy chọn có trên Ailoot được liệt kê bên dưới cho phương thức đã chọn.

Jev là mô hình hàng đầu của TypeSafe và mô hình đầu tiên thuộc lớp mới System One. Mô hình không viết văn bản mà nhanh chóng ra quyết định để chương trình sử dụng ngay: bạn truyền trạng thái (state) — văn bản hoặc JSON — cùng tập câu hỏi, rồi nhận giá trị có kiểu với xác suất đã hiệu chuẩn.

Mô hình ngôn ngữ viết lời cho con người, còn Jev, theo TypeSafe, gần với mã hơn: câu trả lời lập tức ở dạng mã cần, tốc độ cao và không có giá trị ngoài những phương án đã đặt. Mô hình được thiết kế để trả lời ổn định khi lặp lại yêu cầu.

System One khác mô hình ngôn ngữ thế nào

  • Không tạo nội dung. Jev không viết câu trả lời cho người dùng, không viết mã hoặc giải thích tiến trình suy luận. Bạn đặt câu trả lời có thể có qua một trong ba loại câu hỏi.
  • Được huấn luyện để ra quyết định đã hiệu chuẩn. TypeSafe huấn luyện bằng RLCD (Reinforcement Learning for Calibrated Decisions): xác suất được điều chỉnh theo kết quả thực tế và phản ánh sự không chắc chắn. Trong nhiều câu trả lời có xác suất 0,8, khoảng 80% cần đúng. Hiệu chuẩn là đặc tính của mẫu lớn, không bảo đảm một câu trả lời riêng đúng.
  • Mục tiêu huấn luyện khác. Mô hình chat được huấn luyện để làm con người hài lòng (RLHF), và theo quan sát của TypeSafe, điều này khuyến khích chiều lòng người dùng cùng lỗi nghe có vẻ chắc chắn. Một trong những đồng tác giả RLHF, Diogo Almeida, là đồng sáng lập TypeSafe.

Tên gọi nhắc đến «Hệ thống 1» trong cuốn «Tư duy nhanh và chậm» của Daniel Kahneman: phán đoán trực giác nhanh đối lập với tư duy chậm, có cân nhắc của «Hệ thống 2». Jev được tạo cho phán đoán hẹp, nhanh.

Ba loại câu hỏi

Câu hỏi là một phán đoán về trạng thái; câu trả lời là giá trị để mã so với ngưỡng, sắp xếp hoặc truyền tiếp.

  1. Choice — chọn phương án. Bộ phận xử lý yêu cầu, danh mục sản phẩm, ngôn ngữ đoạn mã. Phương án là từ điển «phương án → mô tả», tối đa 255 mục. Câu trả lời có choice được chọn, probabilities cho mọi phương án (tổng bằng 1) và độ tin cậy confidence. Nếu danh sách có thể không bao quát hết trường hợp, hãy thêm «khác» hoặc «không có phương án nào ở trên».
  2. Score — chấm điểm theo thang. Vị trí trên thang có thứ tự do bạn mô tả: mức nghiêm trọng của lỗi, mức bực bội của khách hàng, trình độ kỹ năng. Từ 2 đến 10 mức, từ thấp đến cao; mô hình đánh giá từng mức riêng, không thấy số thứ tự và các mức bên cạnh. Câu trả lời có score (tổng của số thứ tự từng mức nhân với xác suất tương ứng, nên giá trị có thể nằm giữa các mức), legend với mô tả mức, probabilities và confidence.
  3. Noul — có hoặc không. Một phát biểu có đúng không. Câu trả lời noul là xác suất «có» từ 0 đến 1: gần 1 là «có» chắc chắn, gần 0 là «không» chắc chắn, gần 0,5 là mô hình còn phân vân. Không có confidence riêng: một số mô tả toàn bộ câu trả lời. criteria tùy chọn làm rõ thế nào được coi là «có», thế nào là «không».

Cách chọn: phương án đã biết không có thứ tự dùng choice; các bậc trên một phổ dùng score; «có/không» thuần túy mà chính xác suất quan trọng dùng noul. Noul 0,5 là cơ hội «có» và «không» ngang nhau, không phải «mức trung bình»: score đo mức độ. Trong hai loại phù hợp, chọn loại để mã hành động ngay: choice cho nhánh, score cho ngưỡng, noul cho if.

Có thể trộn các loại trong một yêu cầu. Câu trả lời luôn bị giới hạn bởi phương án của bạn và không phụ thuộc câu hỏi khác: có thể thêm, bỏ câu hỏi mà không thay đổi những câu trả lời còn lại.

Trạng thái

Trạng thái là thứ mô hình đánh giá: tin nhắn khách hàng, đoạn tài liệu, bản ghi cơ sở dữ liệu hoặc trạng thái ứng dụng.

  • Chuỗi — khi chỉ có một văn bản: tin nhắn, bài viết, đoạn trích.
  • Đối tượng — trường có tên, bản ghi liên quan, trạng thái ứng dụng. TypeSafe khuyên dùng đối tượng cho phần lớn yêu cầu: mỗi phần có tên rõ ràng.
  • Mảng — chuỗi tin nhắn hoặc bản ghi.

Chuẩn bị như tư liệu cho chuyên gia: đặt trao đổi, đơn hàng và quy tắc trả hàng cùng nhau nếu quyết định cần đối chiếu chúng. Giữ nội dung trong trạng thái, phán đoán trong câu hỏi. Nếu câu hỏi liên quan một phần trạng thái, nêu đường dẫn đến phần đó bằng dấu backtick, chẳng hạn ticket.messages[0].text.

Cách đặt câu hỏi

  • Một phán đoán nhanh cho mỗi câu hỏi. Câu hỏi tốt là câu người hiểu việc, có đủ ngữ cảnh có thể trả lời trong một giây: «Tin nhắn có thể hiện tính khẩn cấp không?». «Phân tích tin nhắn và quyết định cần làm gì» đã là suy luận chậm, cần chia thành câu hỏi đơn giản.
  • Toàn bộ câu hỏi nằm trong instructions. Khóa câu hỏi, chẳng hạn refund_requested, chỉ dành cho mã của bạn và không được truyền cho mô hình.
  • Mọi câu hỏi cho cùng trạng thái trong một yêu cầu. Mô hình đánh giá song song: theo TypeSafe, câu hỏi thêm hầu như không tăng thời gian trả lời và chỉ tốn token của chính nó. Câu hỏi «phòng khi cần» gần như miễn phí — mã tự quyết định cần câu trả lời nào.
  • Phán đoán phức tạp được chia phần. Thay vì «đánh giá hồ sơ startup», hỏi riêng quy mô thị trường, khả thi kỹ thuật và khác biệt với đối thủ, rồi tính kết quả trong mã theo trọng số. Ưu tiên thay đổi thì đổi trọng số, không viết lại câu hỏi.
  • Câu hỏi phụ thuộc nằm trong yêu cầu thứ hai. Câu trả lời cùng một yêu cầu không làm ngữ cảnh cho nhau. Chỉ cần yêu cầu thứ hai nếu không thể tạo nó khi thiếu câu trả lời trước: cần tải dữ liệu hoặc chọn phương án cho câu hỏi tiếp.
  • Câu hỏi dài dùng đối tượng. instructions và criteria thường là chuỗi, nhưng có thể là đối tượng hoặc mảng: câu hỏi trong một trường, dữ liệu ở trường khác. Cách này thuận tiện để đối chiếu CV với bản ghi cơ sở dữ liệu trong một câu hỏi.

Độ tin cậy

Với choice và score, confidence từ 0 đến 1 thể hiện xác suất tập trung vào một câu trả lời đến đâu: 1 là tất cả ở một phương án, 0 là chia đều cho mọi phương án. Với score, mức liền kề làm giảm độ tin cậy ít hơn mức xa. Với noul, độ tin cậy là chính giá trị: càng xa 0,5, câu trả lời càng chắc.

TypeSafe khuyến nghị ba khoảng:

  1. Độ tin cậy cao — hành động tự động.
  2. Trung bình — hành động thận trọng, chẳng hạn yêu cầu người dùng xác nhận.
  3. Thấp — chuyển trường hợp cho người xử lý, làm rõ yêu cầu hoặc dùng phương án dự phòng, chẳng hạn mô hình suy luận mạnh hơn.

Sai sót càng tốn kém, ngưỡng càng nghiêm: với hành động không thể đảo ngược, ngưỡng cao hơn đọc dữ liệu. Câu trả lời cho biết chọn gì, độ tin cậy cho biết có nên hành động không. Chọn ngưỡng trên dữ liệu của chính bạn, đối chiếu độ tin cậy với độ chính xác.

Cách xây dựng hệ thống quanh Jev

Jev hướng tới chương trình có mã điều khiển quy trình và mô hình trả lời câu hỏi ngữ nghĩa hẹp, thay vì tác nhân tự chọn bước tiếp theo và có thể lệch ở mỗi vòng. Tám bước thiết kế theo TypeSafe:

  1. Việc có thể làm bằng mã thì làm bằng mã — đáng tin cậy và rẻ.
  2. Trạng thái chỉ chứa thứ cần cho câu hỏi hiện tại; dữ kiện mới lấy từ kho kiến thức của bạn, không từ bộ nhớ mô hình.
  3. Cấu trúc trong trạng thái: JSON lồng nhau; câu hỏi dùng đường dẫn đến trường cần thiết trong dấu backtick nếu giảm được mơ hồ.
  4. Câu hỏi hẹp và cụ thể nhất — theo TypeSafe, có lẽ là quy tắc quan trọng nhất: câu hỏi rộng giấu nhiều phán đoán sau một câu trả lời.
  5. Cấu trúc trong câu hỏi: câu hỏi ngắn; giải thích, ví dụ và giá trị từ cơ sở dữ liệu nằm ở trường lân cận trong đối tượng instructions hoặc criteria, không trong một chuỗi dài.
  6. Nhiều câu hỏi độc lập cho cùng trạng thái trong một yêu cầu — nhiều giá trị hơn trên mỗi đô la.
  7. Mã kết hợp câu trả lời bằng quy tắc, tổng có trọng số hoặc làm đặc trưng cho mô hình học máy truyền thống.
  8. Phân nhánh theo độ tin cậy: trường hợp chưa chắc chuyển cho người hoặc mô hình suy luận.

Jev không phải chat hay mô hình hoàn thành mã, và không thể thay mô hình ngôn ngữ bằng Jev trong tác nhân lập trình. Tuy nhiên, tác nhân có thể viết mã cho bạn gọi Jev ở những chỗ cần câu trả lời nhanh, đã hiệu chuẩn.

Ứng dụng

  • Tự động hóa nền — quyết định được chạy một triệu lần mà không có người bên cạnh.
  • Thời gian thực — theo TypeSafe, phần lớn yêu cầu thực hiện trong khoảng 100 ms: đủ cho xử lý tức thời và giao diện.
  • Dữ liệu lớn — tìm kiếm trên tập dữ liệu khổng lồ, gắn nhãn nhật ký hoạt động tác nhân, tạo đặc trưng dự báo.
  • Kiểm tra mô hình khác — yêu cầu, trích xuất, suy luận, gọi công cụ: vượt giới hạn, lỗi trích dẫn, bịa đặt.
  • Tìm kiếm và xếp hạng — độ liên quan của cặp «truy vấn — ứng viên», xếp hạng lại, chọn ngữ cảnh.
  • Phân nhánh theo ý định — người dùng muốn gì, cần bộ xử lý nào: logic đơn giản, mô hình chuyên biệt hoặc con người; chủ đề, độ khó và rủi ro quyết định giao yêu cầu cho mô hình ngôn ngữ nào.
  • Kiểm tra bảo vệ — đầu vào, đầu ra và lệnh gọi công cụ của mô hình ngôn ngữ: chỉ dẫn chèn vào, vi phạm quy tắc, rò rỉ dữ liệu cá nhân.
  • Hỗ trợ — chủ đề và ý định yêu cầu, khẩn cấp, bực bội, nguy cơ rời bỏ, yêu cầu hoàn tiền, hàng đợi.
  • Kiểm duyệt — theo quy tắc nền tảng: độc hại, bắt nạt, spam, lừa đảo, lời khuyên nguy hiểm, dữ liệu cá nhân; tùy mức nghiêm trọng và độ tin cậy mà cho qua, cảnh báo, kiểm tra hoặc chặn.
  • Ngành — hồ sơ bảo hiểm, điều tra tài chính và KYC, hợp đồng, quảng cáo, thẻ sản phẩm, tuyển dụng, khách hàng tiềm năng, trò chơi, rủi ro, dự báo nhu cầu, đồ thị kiến thức, tổng quan khoa học, kiểm tra ngữ nghĩa mã trong CI.

Đặc tính

  • jev-latest — bí danh của phiên bản ổn định gần nhất, hiện là Jev 1.13; phiên bản trả lời nằm trong trường model, chẳng hạn jev-1.13.0. Khi có phiên bản mới, bí danh chuyển sang đó và câu trả lời có thể thay đổi dù bạn không sửa gì — theo dõi trường này nếu ngưỡng đã được chọn theo phiên bản.
  • Ngữ cảnh — 64K token cho mỗi yêu cầu: trạng thái và mọi câu hỏi cộng lại; trạng thái cùng câu hỏi dài nhất tối đa 32K. Mô hình đọc trạng thái một lần và kiểm tra mọi câu hỏi song song trên đó.
  • Đầu vào — chỉ văn bản: chuỗi, đối tượng JSON hoặc mảng văn bản. Ảnh, âm thanh và video chưa được hỗ trợ — chuyển thành văn bản trước.
  • Ngôn ngữ — ngôn ngữ huấn luyện chính là tiếng Anh, hiện có độ chính xác cao nhất. Mô hình nhận ngôn ngữ khác, gồm tiếng Trung, Nhật và Hàn, nhưng độ chính xác thấp hơn — cần kiểm tra trên dữ liệu của bạn.
  • Giá và cách tính phí trong Ailoot API — điều kiện phụ thuộc vào phương thức đã chọn và được ghi trên thẻ của phương thức đó.
  • Điều chỉnh — Jev không được tinh chỉnh trên dữ liệu khách hàng: tư liệu riêng nằm trong state, quy tắc lĩnh vực trong instructions và criteria.
  • Dữ liệu — TypeSafe cho biết Jev không được huấn luyện trên yêu cầu và câu trả lời của khách hàng.

Những điểm yếu đã biết của Jev 1.13

TypeSafe công khai liệt kê điểm yếu phiên bản hiện tại và hứa sửa nhiều điểm trong các phiên bản sau. Mô hình nhanh, đã hiệu chuẩn và phán đoán theo lẽ thường tốt, nhưng:

  1. Đọc theo nghĩa đen. Trả lời câu hỏi được viết, không phải điều hàm ý: hiểu sát ngoại lệ, phủ định và điều kiện ngầm. Viết điều kiện chính xác cùng trường hợp biên trong criteria; tách phần cần diễn giải thành hai câu hỏi theo nghĩa đen.
  2. Không phải máy tính. Đếm ký tự, lần lặp và phần tử danh sách không đáng tin cậy, sai số tăng theo kích thước — hãy đếm bằng mã, mỗi ứng viên một câu hỏi. Mô hình hiểu màu dạng hex hoặc RGB kém hơn tên màu. score phù hợp cho ngưỡng, không cho con số chính xác giữa các mức.
  3. Ngày và giờ. Ngày nào trước, cách nhau bao lâu, ngày có thuộc khoảng không — đều không đáng tin cậy, nhất là khi trộn định dạng và ngày tương đối. Trích các phần ngày bằng choice (có phương án «không nêu»), rồi so bằng mã.
  4. Gián tiếp. Phủ định kép và câu hỏi về thuộc tính của thuộc tính giảm độ chính xác. Viết trực tiếp, gọi tên các phần trạng thái.
  5. Thông tin thừa trong trạng thái. Văn bản không liên quan giảm độ chính xác. Lọc bằng mã; nếu không thể, loại phần không liên quan bằng câu hỏi noul.
  6. Văn bản đối kháng. Mặc định mô hình không chờ bẫy trong trạng thái: chỉ dẫn chèn vào hoặc văn bản tranh luận về cách tự phân loại có thể làm lệch câu trả lời. Viết tiêu chí chính xác và kiểm tra trường hợp ranh giới trước khi chạy.
  7. Mâu thuẫn. Nếu instructions và criteria yêu cầu khác nhau — chẳng hạn với noul, «có» được mô tả thành «không» — độ chính xác giảm. Tiêu chí là phần tiếp của câu hỏi.
  8. Thứ tự phương án. Đôi khi mô hình nghiêng về phương án choice đầu tiên. Đổi thứ tự và kiểm tra câu trả lời không thay đổi.
  9. Tạo nội dung. Jev không được huấn luyện để viết văn bản. Để trích xuất dữ liệu, tìm ứng viên bằng biểu thức chính quy hoặc mô hình tạo sinh, rồi để Jev chọn ứng viên đúng bằng choice.
Ailoot · System One POST /v1/systemone jev-latest

jev-latest

TypeSafe /jev-latest

Bắt đầu

Mô hình ra quyết định của TypeSafe: không viết văn bản mà trả lời câu hỏi có kiểu về văn bản hoặc JSON — chọn phương án, chấm điểm theo thang hoặc «có/không» kèm xác suất. Phù hợp cho định tuyến, phân loại yêu cầu, kiểm duyệt và chấm điểm; mọi câu hỏi trong một yêu cầu được đánh giá song song.

Đầu vào được chấp nhận
Văn bản
Kết quả
structured

Có trên Ailoot · đầu vào & phương thức

Ailoot · System One POST /v1/systemone
Đầu vào
text
Đầu ra
structured
Ngữ cảnh
64.000 tokens
Định dạng đầu ra
json
TrườngLoạiYêu cầuGiá trị & giới hạnMặc định
TrườngmodelLoạistringYêu cầuBắt buộcGiá trị & giới hạn
jev-latest
Mặc định—
TrườngstateLoạistring|object|arrayYêu cầuBắt buộcGiá trị & giới hạnMặc định—
TrườngquestionsLoạiobjectYêu cầuBắt buộcGiá trị & giới hạn
Số trường đối tượng tối thiểu: 1
Mặc định—
Trườngquestions.<id>.typeLoạistringYêu cầuBắt buộcGiá trị & giới hạn
noul, choice, score
Mặc định—
Trườngquestions.<id>.instructionsLoạistring|object|array|nullYêu cầuKhông bắt buộcGiá trị & giới hạnMặc định—
Trườngquestions.<id>.criteriaLoạiobject|array|nullYêu cầuKhông bắt buộcGiá trị & giới hạn
Điều kiện: noul: mô tả tùy chọn cho true/false, cho phép null; choice: đối tượng tiêu chí; score: mảng tiêu chí không rỗng
Mặc định—
TrườngstreamLoạiboolean|nullYêu cầuKhông bắt buộcGiá trị & giới hạn
false, null
Mặc định—
Tổ hợp tư liệu đầu vào

noul · Bắt buộc: state, questions.<id>.type=noul

choice · Bắt buộc: state, questions.<id>.type=choice, criteria object

score · Bắt buộc: state, questions.<id>.type=score, nonemptycriteriaarray

Tham số phương thức và vòng đời
Tham sốHợp đồng
Tham sốmaterial_typesHợp đồngtext
Tham sốrequiredHợp đồngmodel, state, questions
Tham sốoptional_controlsHợp đồngnull
Tham sốcontent_typeHợp đồngapplication/json

Vòng đời: exact retained published method

Cấu trúc phương thức và ID là chính xác; khả năng của nhà cung cấp tách biệt với việc cho phép tiếp nhận yêu cầu.

Bảng giá

Mức phí phương thức Ailoot

Ailoot System OnePOST /v1/systemone
Đầu vào
≈0,000084 US$ / 1K
Đầu ra
0,00 US$ / 1K

Ailoot tạm giữ một khoản ước tính trước yêu cầu. Sau khi có kết quả, phí cuối cùng được quyết toán theo mức sử dụng đo được. Việc quyết toán khi truyền luồng dùng bản ghi mức sử dụng cuối cùng. Cách hoạt động của cơ chế tạm giữ và quyết toán →

Ví dụ yêu cầu

Ailoot · System One

Ví dụ phân loại
set -eu
: "${AILOOT_API_KEY:?Set your Ailoot API key}"
: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 customer message}"
export AILOOT_TEXT_FILE
python3 - <<'PY_REQUEST'
import json,os
from pathlib import Path
p=json.loads('{"model": "jev-latest", "state": "", "questions": {"is_urgent": {"type": "noul", "instructions": "Does the supplied customer message express urgency?"}}}')
f=Path(os.environ["AILOOT_TEXT_FILE"])
if not f.is_file():raise SystemExit("Choose your actual UTF-8 source material")
text=f.read_text(encoding="utf-8")
if not text.strip():raise SystemExit("Source material must contain text")
p["state"]=text
Path("request.json").write_text(json.dumps(p,ensure_ascii=False))
PY_REQUEST
curl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \
  -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \
  --data-binary @request.json -D response-headers.txt -o result.json
python3 - <<'PY_RESULT'
import json
from pathlib import Path
print(json.dumps(json.loads(Path("result.json").read_text()),ensure_ascii=False,indent=2))
PY_RESULT

Nhận và lưu kết quả

Ailoot · System One

json

Lưu tất cả kết quả đã hoàn tất

Lưu mọi phản hồi hoàn chỉnh, tệp và phần nội dung được trả về.

Giữ lại mọi câu trả lời theo ID câu hỏi đã cung cấp, xác suất và chú giải; công thức độ tin cậy dùng n yêu cầu n>1 mà không khẳng định quy tắc API về số lựa chọn tối thiểu.

Trường phản hồi
TrườngLoại
Trườnganswers.<id>.typeLoạistring
Trườnganswers.<id>.noulLoạinumber
Trườnganswers.<id>.choiceLoạistring
Trườnganswers.<id>.scoreLoạinumber
Trườnganswers.<id>.confidenceLoạinumber
Trườnganswers.<id>.probabilitiesLoạiobject
Trườnganswers.<id>.legendLoạiobject
TrườngusageLoạiobject
Lỗi và bước tiếp theo
Phản hồiĐiều kiệnBước tiếp theo
Phản hồi400 · invalid_request_errorĐiều kiệnTrường bắt buộc, cách biểu diễn tài liệu hoặc giá trị tham số không hợp lệBước tiếp theoSửa các trường được chỉ ra trước khi gửi yêu cầu tạo mới.

Bí danh

Bí danh mô hình

Ailoot jev-latest

Bí danh đường dẫn phương thức

Dùng các đường dẫn phương thức hiển thị ở trên.

ID gọi liên quan

jev-latest

FAQ · jev-latest
Có những đầu vào và kết quả nào?

POST /v1/systemone · jev-latest: text → structured

Yêu cầu sử dụng những trường nào?

POST /v1/systemone · jev-latest: model, state, questions, stream

Áp dụng những giới hạn nào?

POST /v1/systemone · jev-latest: ctx: 64000

Xem thêm chi tiết

Kết nối Ailoot với Claude Code, OpenCode, Hermes hoặc ứng dụng của bạn.

Công ty và danh mục dự án của công ty

Công ty và danh mục dự án của công ty: hàng triệu khách hàng; doanh số hàng tỷ mỗi tháng.

Mua token với giá ưu đãi.

Ưu đãi thuê bao cho nhu cầu thường xuyên. Mã khuyến mãi giảm đến 50% khi mua token.

Thuê bao
Chọn gói ưu đãi cho các yêu cầu thường xuyên của bạn.
Mã giảm đến 50%
Nhập mã khi mua. Giá được tính lại theo chương trình đang áp dụng.
Chi phí trong lịch sử
Mô hình, token và số tiền được lưu cho mỗi yêu cầu.

Chọn gói thuê bao · Xem giá mô hình

Kết nối API vào sản phẩm bạn đang bán.

SaaS, ứng dụng và bot — theo đề nghị giao kết chính thức và thỏa thuận cấp phép Ailoot. Muốn bán lại, hãy yêu cầu giấy phép bán lại.

Ứng dụng thương mại
Tích hợp tạo văn bản, ảnh, video và âm thanh vào các tính năng trả phí của dịch vụ.
Giấy phép bán lại
Gửi mô tả dự án và cách cung cấp quyền truy cập. Yêu cầu điều khoản sử dụng và bán lại bằng văn bản.
Tài liệu trên website
Đề nghị giao kết, thỏa thuận cấp phép và chính sách xử lý dữ liệu có sẵn trước khi kết nối.

Yêu cầu giấy phép bán lại · Đề nghị giao kết và thỏa thuận cấp phép