State cho Jev

Cấu trúc hợp lệ

Trang state của Python khuyến nghị dùng đối tượng cho phần lớn yêu cầu để mỗi phần có tên mô tả. Một cuộc trò chuyện hỗ trợ, đơn hàng có hai khoản đã thu và chính sách hoàn tiền có thể nằm trong cùng một đối tượng. Đó vẫn là một state. Hãy đặt thông tin liên quan cạnh nhau khi quyết định cần so sánh các phần đó. Đừng giấu câu hỏi thứ hai trong tên trường.

TypeSafe chỉ chấp nhận văn bản. State phải là chuỗi, đối tượng JSON hoặc mảng các giá trị văn bản. Hình ảnh, âm thanh và video không được hỗ trợ. Tiếng Anh là ngôn ngữ huấn luyện chính; các ngôn ngữ khác, kể cả hệ chữ CJK, vẫn được chấp nhận nhưng có độ chính xác thấp hơn. Xem thẻ mô hình để biết lưu ý về ngôn ngữ và không đưa pixel vào yêu cầu; hãy chuyển chúng thành các trường trước.

Jev chỉ chấp nhận văn bản. State phải là chuỗi, đối tượng JSON hoặc mảng giá trị văn bản. Hình ảnh, âm thanh và video không được hỗ trợ. Tiếng Anh là ngôn ngữ huấn luyện chính; các ngôn ngữ khác, gồm cả hệ chữ CJK, vẫn được chấp nhận nhưng có độ chính xác thấp hơn. Xem ghi chú ngôn ngữ đó trong thẻ mô hình và đừng đưa pixel vào yêu cầu; trước tiên hãy chuyển chúng thành các trường.

Tách nội dung khỏi câu hỏi

State chứa nội dung và các dữ kiện hỗ trợ. Câu hỏi xác định các phán đoán. Hãy đặt yêu cầu hoàn tiền và chính sách trong state, rồi hỏi khách hàng có yêu cầu hoàn tiền hay không và chính sách có cho phép hay không. Nếu dán câu hỏi vào khối state, Jev vẫn trả lời trường instructions, còn bạn đã lặp lại prompt ở nơi tiêu tốn ngân sách 32k dành cho state cộng với câu hỏi dài nhất.

State lớn chứa đầy chi tiết không liên quan là một dạng lỗi đã được ghi nhận ở jev-1.13. Độ chính xác giảm khi nội dung không liên quan gây nhiễu, còn một khối dữ liệu phình to khiến việc xác định trường nào tạo ra câu trả lời sai trở nên khó hơn. Hãy lọc bằng mã trước. Chỉ gửi những trường câu hỏi cần. Khi không thể lọc, Noul có thể chấm mức liên quan của đoạn văn trước phán đoán chính, như trong cẩm nang phân loại đoạn RAG của TypeSafe.

Độ dài ngữ cảnh có giới hạn. Jev 1.13 cho phép 64k token cho toàn bộ yêu cầu và 32k cho trạng thái cộng với câu hỏi dài nhất. fan-out suy đoán ghép nhiều câu hỏi ngắn với một trạng thái gọn. Cách này rẻ và chính xác hơn so với đính kèm toàn bộ lịch sử phiếu hỗ trợ khi bạn chỉ cần tin nhắn gần nhất của khách hàng và hai dòng phí.

Dùng hồ sơ hỗ trợ làm trạng thái

Một đối tượng theo tài liệu gồm ticket.subject, ticket.messages dưới dạng các cặp from/text, order.id, order.charges với amount và status, cùng refund_policy là một câu. Khi đó, trường hợp tính phí trùng trở thành tập hợp các Noul và Choice trên đối tượng này, thay vì một cuộc trò chuyện phải nhắc lại chính sách. Mã của bạn đã biết các khoản tiền; Jev phán định xem ngôn từ có yêu cầu hoàn tiền hay không và câu chính sách có áp dụng hay không.

Với vòng lặp trò chơi như Doom, trạng thái là văn bản có cấu trúc mô tả thế giới, không phải khung hình. Demo của TypeSafe đưa văn bản đó vào với khoảng 10 truy vấn mỗi giây. Với Wikiracing, trạng thái gồm trang hiện tại và các liên kết ứng viên. Với trợ lý nhà thông minh, trạng thái gồm lời người dùng cùng danh sách thiết bị đang có sẵn trong bộ nhớ. Không demo nào gửi điểm ảnh tới Jev.

Khi một trường dữ liệu trong cơ sở dữ liệu là số, hãy gửi một nhóm có tên hoặc giá trị đã tính nếu cần phán định về ngữ nghĩa ("màu này có tạo cảm giác cảnh báo không"), còn phép tính mã hex thì để mã xử lý. jev-1.13 đọc bộ ba RGB và giá trị hex kém hơn tên màu tiếng Anh. Ngày tháng cũng nên xử lý tương tự: dùng Choice để trích xuất từng phần, rồi so sánh bằng mã.

Giới hạn và ngôn ngữ

Cửa sổ yêu cầu 64k bao gồm trạng thái và mọi câu hỏi. Cửa sổ 32k gồm trạng thái cộng với câu hỏi dài nhất. Nếu đổ một PDF chính sách 20k vào trạng thái, bạn sẽ còn rất ít chỗ cho bản đồ câu hỏi, đồng thời dễ gặp lỗi do chi tiết không liên quan. Hãy truy xuất trước, rồi chỉ gửi hai đoạn văn cần thiết cho phán định.

Tiếng Anh hiện cho độ chính xác cao nhất. Nếu phiếu hỗ trợ của bạn viết bằng tiếng Nhật hoặc tiếng Hàn, hãy chạy thử một mẫu, vẽ biểu đồ độ tin cậy của Noul và Choice, đồng thời giữ bước duyệt của con người cho đến khi các biểu đồ phân bố này tương tự dữ liệu tiếng Anh. Mô hình vẫn nhận văn bản và không âm thầm từ chối chữ CJK.

Mảng văn bản dành cho chuỗi, không phải để lách thêm một lược đồ thứ hai. Nếu cần các phần có tên, hãy dùng đối tượng. Nếu cần một khối duy nhất, hãy dùng chuỗi. Chèn URL ảnh vào chuỗi không giúp Jev có thị giác; nó chỉ đưa cho Jev một token URL dễ bị đọc sai. Hãy để các worker tải và mô tả ảnh, rồi gửi phần mô tả.

Nếu một trường dữ liệu chỉ phục vụ nhật ký của bạn, đừng đưa nó vào trạng thái. ID câu hỏi đã cung cấp khóa để liên kết dữ liệu. Trạng thái chỉ nên chứa bằng chứng mà một hội đồng con người sẽ đọc. Quy tắc này cũng giúp bạn không vượt giới hạn 32k cho trạng thái cộng với câu hỏi dài nhất khi luồng phiếu hỗ trợ quá dài.

Các trường có tên tốt hơn kiểu mã hóa cầu kỳ. order_id, charges[].status, refund_policy đều dễ đọc với cả bạn lẫn Jev. Gộp chính các dữ kiện đó vào một chuỗi duy nhất tuy hợp lệ nhưng kém hiệu quả hơn. Đối tượng phiếu hỗ trợ trong tài liệu là mẫu chuẩn: ticket, order, policy, rồi đến các câu hỏi tham chiếu những tên đó.

Hãy loại bỏ thông tin định danh cá nhân không cần thiết cho việc đánh giá. Jev không được huấn luyện bằng yêu cầu của khách hàng, nhưng nhật ký của chính bạn vẫn lưu chúng. Trạng thái nhỏ hơn vừa là cách khắc phục theo jaggedness, vừa là thói quen bảo vệ quyền riêng tư.

Mảng văn bản là một chuỗi, không phải tập hợp các ô có tên. Nếu cần tên, hãy dùng đối tượng.