State ของ Jev

จัดโครงสร้างเนื้อหาที่ Jev จะตัดสินให้เป็นสตริง ออบเจ็กต์ หรืออาร์เรย์ข้อความ

State คือเนื้อหาที่คุณขอให้โมเดล System One ประเมิน อาจเป็นข้อความขอความช่วยเหลือ ข้อความตอนหนึ่ง หรือสแนปช็อตปัจจุบันของแอปพลิเคชัน คุณส่งเนื้อหานี้ในฟิลด์ state ข้างคำถาม แต่ละคำขอจะประเมิน state หนึ่งรายการกับคำถามอย่างน้อยหนึ่งข้อ ทุกคำถามเห็น state เดียวกันและทำงานแยกกัน คุณสามารถผสม Choice, Score และ Noul ในแผนผังนั้นได้ อย่าใส่คำถามใน state และตัดทุกอย่างที่ไม่จำเป็นต่อการตัดสินออก

รูปแบบที่รองรับ

state แบบง่ายที่สุดคือสตริงธรรมดา: "บัตรของฉันถูกเรียกเก็บเงินสองครั้ง" ใช้สตริงเมื่อกรณีนั้นมีข้อความชิ้นเดียว ใช้ออบเจ็กต์ JSON เมื่อมีฟิลด์ที่ตั้งชื่อ ระเบียนที่เกี่ยวข้อง หรือ state ของแอปพลิเคชัน เช่น ข้อความพร้อมรหัสคำสั่งซื้อ ใช้อาร์เรย์ข้อความสำหรับลำดับข้อความหรือระเบียน ใน Python ให้ส่ง string, dict หรือ list ที่ตรงกันไปยัง client.system_one(state=...)

หน้า state ของ TypeSafe แนะนำให้ใช้ออบเจ็กต์กับคำขอส่วนใหญ่ เพื่อให้แต่ละส่วนมีชื่อบอกความหมาย บทสนทนากับฝ่ายสนับสนุน คำสั่งซื้อที่บันทึกการเรียกเก็บเงินสองครั้ง และนโยบายคืนเงิน สามารถอยู่ในออบเจ็กต์เดียวกันได้ ทั้งหมดยังคงเป็น state เดียว ให้รวมข้อมูลที่เกี่ยวข้องไว้ด้วยกันเมื่อการตัดสินต้องเปรียบเทียบส่วนเหล่านั้น และอย่าซ่อนคำถามที่สองไว้ในชื่อฟิลด์

Jev รับเฉพาะข้อความเท่านั้น State ต้องเป็นสตริง ออบเจ็กต์ JSON หรืออาร์เรย์ของค่าข้อความ ไม่รองรับรูปภาพ เสียง และวิดีโอ ภาษาอังกฤษเป็นภาษาหลักที่ใช้ฝึก ส่วนภาษาอื่นรวมถึงอักษร CJK ใช้งานได้แต่มีความแม่นยำต่ำกว่า โปรดดูหมายเหตุเรื่องภาษาในโมเดลการ์ด และอย่าใส่พิกเซลในคำขอ โดยแปลงเป็นฟิลด์ก่อน

Jev state shapes: string, named object, or array of text; no pixels — รูปแบบ Jev state ที่รองรับ: สตริง ออบเจ็กต์ที่ตั้งชื่อ หรืออาร์เรย์ข้อความ โดยไม่รองรับพิกเซล

แยกเนื้อหาออกจากคำถาม

State เก็บเนื้อหาและข้อเท็จจริงประกอบ ส่วนคำถามกำหนดสิ่งที่จะตัดสิน เก็บคำขอคืนเงินและนโยบายไว้ใน state แล้วถามว่าลูกค้าขอคืนเงินหรือไม่และนโยบายรองรับหรือไม่ หากวางคำถามลงในก้อนข้อมูล state, Jev ก็ยังตอบฟิลด์คำสั่งอยู่ ทำให้พรอมต์ซ้ำซ้อนในตำแหน่งที่กินงบ 32k สำหรับ state บวกคำถามที่ยาวที่สุด

state ขนาดใหญ่ที่เต็มไปด้วยรายละเอียดไม่เกี่ยวข้องเป็นรูปแบบความล้มเหลวที่มีการบันทึกไว้สำหรับ jev-1.13 ความแม่นยำจะลดลงเมื่อเนื้อหาที่ไม่เกี่ยวข้องรบกวนการตัดสิน และก้อนข้อมูลที่พองตัวยังทำให้ระบุได้ยากว่าฟิลด์ใดทำให้ตอบผิด ให้กรองในโค้ดก่อนและส่งเฉพาะฟิลด์ที่คำถามต้องใช้ หากกรองไม่ได้ Noul สามารถให้คะแนนความเกี่ยวข้องของข้อความแต่ละตอนได้ก่อนการตัดสินหลัก เช่นในคู่มือจำแนกข้อความ RAG ของ TypeSafe

ความยาวบริบทมีขีดจำกัด Jev 1.13 อนุญาต 64k โทเค็นสำหรับคำขอทั้งหมด และ 32k สำหรับ state รวมกับคำถามที่ยาวที่สุด fan-out แบบคาดการณ์ล่วงหน้าจะรวมคำถามสั้นหลายข้อไว้กับ state ที่กระชับ วิธีนี้ประหยัดกว่าและแม่นยำกว่าการแนบประวัติทิกเก็ตทั้งหมด เมื่อคุณต้องใช้เพียงข้อความล่าสุดของลูกค้าและรายการเรียกเก็บเงินสองแถว

เรกคอร์ดงานสนับสนุนในรูป state

ออบเจ็กต์ตามรูปแบบที่ระบุใช้ ticket.subject, ticket.messages ซึ่งประกอบด้วยคู่ from/text, order.id, order.charges ที่มี amount และ status รวมถึง refund_policy ซึ่งเป็นประโยคหนึ่ง จากนั้นกรณีเรียกเก็บเงินซ้ำจะกลายเป็นชุด Noul และ Choice บนออบเจ็กต์นี้ แทนที่จะเป็นแชตที่ต้องกล่าวนโยบายซ้ำ โค้ดของคุณทราบยอดเงินอยู่แล้ว ส่วน Jev จะตัดสินว่าข้อความนั้นขอคืนเงินหรือไม่ และประโยคนโยบายมีผลหรือไม่

สำหรับลูปเกมอย่าง Doom นั้น state คือข้อความมีโครงสร้างที่บรรยายโลก ไม่ใช่เฟรม เดโมของ TypeSafe ป้อนข้อความดังกล่าวที่ราว 10 คำขอต่อวินาที สำหรับ Wikiracing นั้น state คือหน้าเว็บพร้อมลิงก์ที่เป็นตัวเลือก ส่วนผู้ช่วยบ้านอัจฉริยะใช้ state เป็นคำพูดของผู้ใช้พร้อมรายการอุปกรณ์ที่มีอยู่ในหน่วยความจำ เดโมเหล่านี้ไม่มีตัวใดส่งพิกเซลไปยัง Jev

เมื่อฟิลด์ในฐานข้อมูลเป็นตัวเลข ให้ส่งช่วงที่มีชื่อหรือตัวเลขที่คำนวณแล้ว หากต้องตัดสินเชิงความหมาย ("สีนี้ดูเป็นสีเตือนหรือไม่") และให้โค้ดจัดการคณิตศาสตร์ของค่าเลขฐานสิบหก jev-1.13 อ่านชุดค่า RGB และค่าเลขฐานสิบหกได้ไม่ดีเท่าชื่อสีภาษาอังกฤษ คำแนะนำเดียวกันนี้ใช้กับวันที่ด้วย: แยกองค์ประกอบผ่าน Choice แล้วจึงเปรียบเทียบในโค้ด

ขีดจำกัดและภาษา

หน้าต่างคำขอ 64k ครอบคลุม state และคำถามทั้งหมด ส่วนหน้าต่าง 32k ครอบคลุม state กับคำถามเดี่ยวที่ยาวที่สุด หากเท PDF นโยบายขนาด 20k ลงใน state จะเหลือพื้นที่ให้แมปคำถามน้อย และยังกระตุ้นรูปแบบความล้มเหลวจากรายละเอียดที่ไม่เกี่ยวข้องด้วย ให้ค้นคืนข้อมูลก่อน แล้วส่งเพียงสองย่อหน้าที่จำเป็นต่อการตัดสิน

ปัจจุบันภาษาอังกฤษให้ความแม่นยำสูงสุด หากทิกเก็ตเป็นภาษาญี่ปุ่นหรือเกาหลี ให้ทดลองกับชุดตัวอย่าง พล็อตค่าความเชื่อมั่นของ Noul และ Choice และให้มนุษย์ร่วมตรวจสอบจนกว่าฮิสโตแกรมจะมีลักษณะเหมือนชุดภาษาอังกฤษ โมเดลยังคงรับข้อความเหล่านั้น และจะไม่ปฏิเสธอักษร CJK โดยไม่แจ้งให้ทราบ

อาร์เรย์ข้อความมีไว้สำหรับลำดับ ไม่ใช่ใช้ซ่อนสคีมาที่สอง หากต้องการส่วนประกอบที่มีชื่อ ให้ใช้ออบเจ็กต์ หากต้องการข้อมูลก้อนเดียว ให้ใช้สตริง การใส่ URL รูปภาพปนในสตริงไม่ได้ทำให้ Jev มองเห็นภาพ แต่ทำให้ Jev ได้โทเค็น URL ที่อาจอ่านผิด ให้เวิร์กเกอร์ดึงข้อมูลและบรรยายภาพก่อน แล้วจึงส่งคำบรรยาย

หากฟิลด์มีไว้ใช้ในบันทึกของคุณเท่านั้น ให้ตัดออกจาก state รหัสคำถามเป็นคีย์สำหรับเชื่อมข้อมูลให้อยู่แล้ว State ควรมีเฉพาะหลักฐานที่คณะผู้ตรวจซึ่งเป็นมนุษย์จะอ่าน วินัยนี้ยังช่วยให้คุณไม่เกินขีดจำกัด 32k ของ state รวมกับคำถามที่ยาวที่สุด เมื่อเธรดทิกเก็ตยาวมาก

ฟิลด์ที่มีชื่อดีกว่าการเข้ารหัสอันซับซ้อน order_id, charges[].status และ refund_policy อ่านเข้าใจได้ทั้งสำหรับคุณและ Jev การนำข้อเท็จจริงเดียวกันมาต่อเป็นสตริงเดียวทำได้ แต่แย่กว่า ออบเจ็กต์ทิกเก็ตงานสนับสนุนตามรูปแบบที่ระบุคือต้นแบบ: ticket, order, policy แล้วตามด้วยคำถามที่อ้างถึงชื่อเหล่านั้น

ลบข้อมูลระบุตัวบุคคลที่ไม่จำเป็นต่อการตัดสินออก Jev ไม่ได้นำคำขอของลูกค้าไปใช้ฝึก แต่ล็อกของคุณเองยังคงบันทึกข้อมูลเหล่านั้นอยู่ state ที่เล็กลงช่วยทั้งแก้ปัญหาเรื่อง jaggedness และสร้างนิสัยที่คำนึงถึงความเป็นส่วนตัว

อาร์เรย์ข้อความคือลำดับ ไม่ใช่ชุดช่องที่มีชื่อ หากต้องการชื่อ ให้ใช้ออบเจ็กต์

แหล่งที่มา