LLM Routing และ Guardrails ต้องทำอย่างไร? ตัวอย่างการทำงานร่วมกันระหว่าง Jev กับโมเดลภาษาขนาดใหญ่

การเปิดเผยผลประโยชน์และหลักฐาน: PandaNpc กำลังพัฒนาเลเยอร์การตัดสินใจของ Agent ที่ใช้ Jev ด้านล่างนี้อ้างอิงเอกสารทางการของ TypeSafe, cookbook ทางการ และการเรียก Jev จริงกับงานปรับเทียบสถานการณ์สังเคราะห์ในคลังของเรา การปรับเทียบของเราใช้ LLM provider ปลอมแบบสคริปต์ จึงไม่สามารถแทนทราฟฟิกผู้ใช้จริงหรือประสิทธิภาพของ production pipeline แบบครบวงจรได้

LLM Routing สามารถทำได้แบบนี้: ให้ Jev ตัดสินก่อนว่าคำขอจัดอยู่ในประเภทใดและมีความเสี่ยงสูงแค่ไหน จากนั้นให้โค้ดตัดสินใจว่าจะส่งต่อให้ฟังก์ชันทั่วไป, LLM เฉพาะทาง หรือการตรวจทานโดยมนุษย์ Jev สามารถวางไว้ระหว่างการค้นคืนและการสร้างเพื่อองหลักฐาน หรือวางไว้หลังเอาต์พุตของ LLM เพื่อตรวจสอบผลลัพธ์ได้ สิ่งที่มันส่งคืนคือตัวเลือกแบบปิด, คะแนน และความน่าจะเป็น; ส่วนการตอบแบบเปิดกว้าง, การสร้างโค้ด และการให้เหตุผลยาว ๆ ยังคงเป็นหน้าที่ของ LLM คำอธิบายของ TypeSafe เกี่ยวกับ coding agents ระบุชัดเจนว่า Jev ไม่สามารถแทนที่โมเดลแชตที่อยู่เบื้องหลัง Claude Code หรือ Codex ได้โดยตรง

บทความนี้ใช้คำขอฝ่ายบริการลูกค้าหนึ่งรายการ, pipeline การถามตอบแบบ RAG หนึ่งชุด และบันทึกการปรับเทียบ Agent ของเรา เพื่ออธิบายว่าจุดส่งต่อของโมเดลสองประเภทอยู่ตรงไหน และเหตุใดผลลัพธ์ที่มีความเชื่อมั่นต่ำจึงต้องมีปลายทางที่ชัดเจน

Jev ตัดสินอะไรได้ และ LLM ยังรับผิดชอบอะไรต่อไป?

ณ วันที่ 23 กันยายน 2026 หน้า Models ของ TypeSafe ระบุโมเดลเสถียรเป็น jev-1.13.0 API รับ state หนึ่งรายการและชุด questions หนึ่งชุด ผ่าน POST /v1/systemone เพื่อคืน answers แบบมีโครงสร้างที่สอดคล้องกัน jev-latest ในวันนั้นชี้ไปที่ 1.13.0 แต่ alias จะเปลี่ยนตามเวอร์ชัน; ระบบที่ปรับเทียบ threshold แล้วควรตรึงเวอร์ชันและบันทึก model ID จริงใน response

Noul ไม่มีฟิลด์ confidence แยกต่างหาก; ไม่สามารถเขียนความน่าจะเป็นของ Noul เป็น “ความเชื่อมั่นของโมเดล” โดยตรงได้ Score ก็ไม่ควรนำมาใช้คำนวณจำนวนเงินที่แม่นยำ การคำนวณจำนวนเงิน, การเปรียบเทียบวันที่, โควตา และการตรวจสอบสิทธิ์ ควรอยู่ในโปรแกรมที่กำหนดผลได้แน่นอน ทางการได้ระบุขอบเขตเหล่านี้ของ Jev 1.13 ไว้แล้ว

รูปแบบการเรียกที่น้อยที่สุด

รูปแบบคำขอด้านล่างสอดคล้องกับเอกสารอ้างอิง API ทางการ คำถามตัวอย่างเป็นคอนฟิกูเรชันเชิงสาธิตที่สร้างขึ้นสำหรับบทความนี้ ไม่ได้ทดสอบออนไลน์ในบทความนี้

JSON ด้านล่างใช้ข้อความลูกค้าภาษาอังกฤษ ในภาษาไทยลูกค้าจะพูดว่า “คำสั่งซื้อของฉันถูกหักเงินซ้ำ กรุณาช่วยคืนเงินให้ฉันด้วย”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

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

ใช้ Jev ทำ LLM Routing: สามเส้นทางการส่งต่อ

ตัวอย่าง intent routing ทางการของ TypeSafe ส่งคำขอฝ่ายบริการลูกค้าให้ Jev ตัดสินเจตนาและความซับซ้อนก่อน จากนั้นให้โค้ดแยกเส้นทาง: การตรวจสอบสถานะคำสั่งซื้อไปที่ฟังก์ชันฐานข้อมูล; คำถามเกี่ยวกับผลิตภัณฑ์และการคืน/เปลี่ยนสินค้าแยกไปยัง LLM เฉพาะทางที่โหลดข้อมูลต่างกัน; ข้อร้องเรียนซับซ้อนหรือผลลัพธ์ที่ confidence ต่ำเข้าคิว human review นี่คือการทำงานร่วมกันระหว่าง Jev กับ LLM ที่เข้าใจง่ายที่สุด: ตัวแรกให้การตัดสินแบบมีโครงสร้าง ตัวออกมาเฉพาะเมื่อต้องสร้างคำอธิบายหรือบทสนทนา

เมื่อนำไปใช้จริง สามารถออกแบบตามลำดับด้านล่าง แทนที่จะปล่อยให้โมเดลตัดสินทุกการกระทำอย่างอิสระ:

1. กำหนดเส้นทางก่อน: ระบุให้ชัดว่าฟังก์ชันทั่วไป, LLM เฉพาะทางแต่ละตัว และ human review จัดการคำขอแบบใดได้ และเผื่อตัวเลือก other หรือตัวเลือกสำรองประเภทเดียวกันไว้สำหรับ Choice
2. ใส่ข้อเท็จจริงลงใน state: คำพูดต้นฉบับของผู้ใช้, สถานะบัญชี, บันทึกคำสั่งซื้อ แยกเป็นฟิลด์; อย่านำข้อความจากเว็บที่ไม่ทราบแหล่งที่มาไปเป็นคำสั่งของระบบ
3. ถามคำถามแคบ ๆ ทีละเรื่อง: เจตนาใช้ Choice, ความเสี่ยงหรือความเร่งด่วนใช้ Score, ข้อเท็จจริงจุดเดียวที่ต้องยืนยันใช้ Noul ทางการแนะนำว่าคำถามอิสระหลายข้อที่ใช้ state เดียวกันสามารถประเมินพร้อมกันในคำขอเดียวได้
4. ให้โค้ดเป็นผู้ตัดสินเส้นทางสุดท้าย: ตรวจสอบสิทธิ์และกฎตายตัวก่อน จากนั้นดูความน่าจะเป็นจาก Jev และ threshold ที่ปรับเทียบกับธุรกิจนี้; คำขอที่ confidence ต่ำหรือขาดหลักฐานให้ไปที่ human หรือถามเพิ่ม
5. บันทึกผลลัพธ์และตรวจทานซ้ำ: เก็บเวอร์ชันโมเดล, เวอร์ชันคำถาม, ความน่าจะเป็น, ปลายทางสุดท้าย และผลแก้ไขโดยมนุษย์ จึงจะตัดสินได้ว่า threshold เหมาะสมหรือไม่

ที่มาภาพ: TypeSafe AI《Introducing System One Models & Jev》, 2026-09-15 workflow ทั้งสี่สร้างโดย TypeSafe เอง ตัวชี้วัดถ่วงน้ำหนักเท่ากันตาม workflow; ดูวิธีประเมินได้ที่ TypeSafe workflow evals

ภาพทางการนี้ช่วยให้เข้าใจว่าเหตุใดจึงเน้น “การบรรจุการตัดสินแบบแคบ ๆ หลายรายการไว้ใน workflow ของโปรแกรม” แกนตั้งในภาพใช้ชื่อ “accuracy” ตามผู้ให้บริการ แต่คำตอบอ้างอิงมาจากความเห็นพ้องของความน่าจะเป็นที่โมเดลใหญ่สองตัวทำนาย ไม่ใช่คำตอบที่ถูกต้องเดียวที่ผ่านการตรวจสอบโดยมนุษย์; ต้นทุนและตัวชี้วัดยังขึ้นอยู่กับสี่ workflow นี้และวิธีการประเมินของผู้ให้บริการ จึงไม่สามารถแปลงเป็น “ประหยัดได้เท่าไรในทุกสถานการณ์”

Retrieval-Augmented Generation: Jev กรองหลักฐานก่อน LLM ตอบ

cookbook เรื่อง RAG passage ของ TypeSafe ให้ตัวอย่าง multi-model ที่เฉพาะเจาะจงกว่า: OpenAI embedding เรียกคืน paragraph ก่อน จากนั้น Jev ถาม Noul สี่ข้อกับแต่ละ “คำถาม + paragraph” — เกี่ยวข้องหรือไม่, มีหลักฐานที่ใช้ตอบได้หรือไม่, โต้แย้งสมมติฐานในคำถามหรือไม่, พยายามสั่งโมเดลที่ตอบหรือไม่ โค้ดประมวลผลความน่าจะเป็นทั้งสี่ตามลำดับ ตัดสินว่าจะใส่ paragraph นั้นในโซนหลักฐาน, โซนหลักฐานขัดแย้ง หรือทิ้ง; สุดท้าย Claude Sonnet 5 เขียนคำตอบ

ขั้นตอนนี้แก้ปัญหาที่พบบ่อย: paragraph ที่มี vector similarity สูงไม่จำเป็นต้องใช้งานได้ อาจใช้เพียงคำที่คล้ายกัน หรืออาจเป็นโพสต์ฟอรัมที่แอบแฝง prompt injection แบบ “ไม่ต้องสนใจข้อความก่อนหน้า” ตัวอย่างใน cookbook วางการตรวจ injection ไว้หน้าสุดของกฎ routing พร้อมเตือนว่า threshold เป็นจุดเริ่มต้นที่เลือกสำหรับ corpus ชุดนั้น ไม่ใช่ค่าเริ่มต้นของทุกแอป RAG ตัวเลขสาธิตมาจาก jev-1.12 เมื่อ 2026-08-27 จึงใช้เป็นผลการประเมินใหม่ของ jev-1.13.0 ปัจจุบันไม่ได้

หลังการสร้าง ยังสามารถตรวจสอบอีกชั้นได้ cookbook ตรวจสอบการอ้างอิงของ TypeSafe ใช้โปรแกรมหาข้อความต้นฉบับที่ถูกอ้างก่อน จากนั้นใช้ Jev ตัดสินว่าข้อความนั้นสนับสนุน, โต้แย้ง หรือไม่ได้กล่าวถึงข้อกล่าวอ้างที่สร้างขึ้น มันสามารถคัดการอ้างอิงที่ควรตรวจซ้ำออกมาได้; แต่การตัดสินของโมเดลเองก็ยังผิดพลาดได้ จึงไม่ควรเขียนว่า “ผ่านการตรวจสอบ” เป็นการรับประกันข้อเท็จจริง

การปรับเทียบ Agent ของเรา: การยกระดับเมื่อ confidence ต่ำจะติดตรงไหน?

ในคลัง PandaNpc, Jev client, คลังคำถาม และ orchestrator ใช้ Jev กับ Agent ในส่วนการรู้จำเจตนา, การให้คะแนน candidate modification, การตรวจสอบเงื่อนไขความสำเร็จ และการตัดสิน commit client ยังทำ retry อย่างจำกัดสำหรับ timeout, 429, 5xx และจำกัด request budget กับผลลัพธ์ที่หมดอายุ; สิทธิ์ในการดำเนินการอยู่ในมือ orchestrator และชั้นเครื่องมือที่ถูกควบคุม ไม่ได้ให้ Jev มอบให้โดยตรงจากการตัดสินเพียงประโยคเดียว

เมื่อ 2026-09-22 เราใช้ jev-1.13.0 กับ turn สังเคราะห์ 19 รายการ โดยรัน shadow หนึ่งครั้งและ enforce หนึ่งครั้งต่อรายการ รวม 38 รัน และบันทึกการตัดสินจริงของ Jev 165 รายการ รายงานการปรับเทียบภายในนี้และ response จากเครื่องจริงที่บันทึกไว้ใช้ LLM provider ปลอมแบบสคริปต์ ดังนั้นข้อมูลเหล่านี้บอกได้เพียงพฤติกรรมการตัดสินในสถานการณ์ที่ควบคุมเท่านั้น ไม่สามารถพิสูจน์อัตราความสำเร็จโดยรวม, สัดส่วนที่ประหยัดได้ หรือ latency แบบ end-to-end ภายใต้คำขอผู้ใช้จริงได้

สิ่งที่ค้นพบที่มีคุณค่าที่สุดไม่ใช่ความเร็วเฉลี่ย แต่เป็น threshold ที่ “ดูปลอดภัย” แล้วทำให้เกิดการติดขัด: ใน 19 turn ของ enforce มี 13 turn ที่ Q2 “ข้อมูลเพียงพอที่จะเริ่มแก้ไขหรือไม่” ถูกยกระดับเพราะความน่าจะเป็นของ Noul ตกในช่วงความไม่แน่นอน 0.15–0.85 ที่กำหนดไว้แต่แรก; LLM Worker ไม่มีโอกาสทำขั้นตอนถัดไป บันทึกการปรับเทียบแสดงว่าใน 34 การตัดสิน Q2 ที่ระบุว่าข้อมูลเพียงพอ มีหลายรายการที่มีความน่าจะเป็นอยู่ช่วงกลาง รายงานเสนอให้แยก Q2 ที่ซับซ้อนออกเป็นการตัดสินที่ย่อยกว่า หรือปรับกฎการยกระดับ; สิ่งเหล่านี้เป็นข้อเสนอ ไม่ใช่ threshold ที่นำไปใช้แล้ว

คลังคำถามของเราตัดสินทางเข้าออกเป็น answer_only, inspect, modify หรือ out_of_scope; บนเส้นทางการเขียน candidate modification ที่ Worker เสนอจะถูกจัดอันดับด้วย Score ก่อน จากนั้นเนื้อหาสุดท้ายและสรุปการแก้ไขจะผ่านการตรวจรับและการตัดสิน commit สิ่งเหล่านี้เป็นเพียงจุดตัดสินใจ: จะอ่าน/เขียนวัตถุได้จริงหรือไม่ ยังขึ้นอยู่กับ executor ที่ถูกควบคุมซึ่งให้สิทธิ์เป็นระยะ ๆ Jev ไม่มีสิทธิ์ผ่อนปรน allowlist ของเครื่องมือเอง และไม่สามารถข้ามการตรวจสอบความสอดคล้องก่อน commit ได้

ข้อมูลการปรับเทียบเผยให้เห็น trade-off อีกข้อ ในโหมด shadow, Jev จะให้คำตอบและการกระจายเต็ม แต่ไม่เปลี่ยนเส้นทางการทำงานเดิมของ Worker; ในโหมด enforce, คำตอบจะมีผลต่อการดำเนินการต่อ, การยกระดับ หรือการทิ้ง การนำ accuracy ของ shadow ไปใช้เป็น completion rate ของ enforce โดยตรงจะทำให้เข้าใจระบบผิด: การยกระดับที่ Q2 จะตัดงานไว้ก่อน ทำให้คำถามถัดไปเรื่องการให้คะแนน candidate, การตรวจรับ และการ commit ไม่มีโอกาสเกิดขึ้นเลย ดังนั้นรายงานนี้จึงอ่านการกระจายต่อคำถาม, ทิศทางการยกระดับ และสถานะสุดท้ายแยกจากกัน

ในการแก้ไขที่เป็น candidate มีการเปรียบเทียบที่เจาะจง: ใน turn เดียวกัน candidate ที่แก้ไขเป้าหมายอย่างแม่นยำได้ 2.94 คะแนน ขณะที่ candidate ที่ใช้การเขียนทับทั้งไฟล์ได้ 0.38 คะแนน; candidate ที่ได้คะแนนสูงถูกเลือก ตัวอย่างนี้อธิบายเพียงว่าในสถานการณ์สังเคราะห์นั้น คำถามแบบให้คะแนนแยกสองทางเลือกออกจากกัน ในทางกลับกัน candidate ที่หลักฐานถูกตัดทอนได้ 2.27 คะแนน จึงไม่ควรเพิกเฉยต่อ confidence ต่ำและเครื่องหมายถูกตัดทอนเพียงเพราะตัวเลขดู “พอใช้” โค้ดของเราทำเครื่องหมาย evidence ไม่ครบแยกต่างหาก เพื่อหลีกเลี่ยงไม่ให้โมเดลตัดสินการเขียนแบบแน่นอนจาก prefix ที่ถูกเก็บไว้เท่านั้น

เรายังแยก “เลือก candidate ไหน” กับ “อนุญาตให้มันเขียน” ออกเป็นสองขั้นตอนต่างกัน หลังจาก candidate ผ่านการให้คะแนนโดย Jev แล้ว executor ที่ถูกควบคุมจะเปิดเครื่องมือเขียนเฉพาะในระยะ ACT/modify; ticket ใช้ครั้งเดียวที่ออกให้ผูกกับ tool call ID, หมายเลข revision ปัจจุบัน, hash ของวัตถุเป้าหมาย และสรุปพารามิเตอร์ แม้ข้อความ candidate จะชักจูงโมเดลให้ “ไม่ต้องสนใจข้อจำกัด” ก็ไม่ได้รับสิทธิ์เครื่องมือที่ข้ามการตรวจสอบเหล่านี้ได้ นี่คือบทเรียนจากการผสานรวมในระดับโค้ดของเรา: การตัดสินจากความน่าจะเป็นกำหนดว่าเส้นทางไหนควรเดิน ส่วนสิทธิ์ที่มีผลข้างเคียงถูกกำหนดโดยเงื่อนไขของโปรแกรมที่ตรวจสอบซ้ำได้

เส้นทางความล้มเหลวก็ต้องออกแบบด้วย client จะ retry อย่างจำกัดเฉพาะ timeout, network error, 429 หรือ 5xx; คำตอบที่ถูกยกเลิกหรือเกิน deadline ของ turn จะถูกทิ้งทันที หาก Jev ใช้งานไม่ได้ในโหมด enforce จะดำเนินการต่อไม่ได้หากไม่ได้รับอนุญาตให้ degrade; เมื่อได้รับอนุญาตให้ใช้ llm_only executor จะล็อกเป็นอ่านอย่างเดียว หาก branch ถูกแก้ไขไปแล้วก่อนที่ Jev จะหายไป orchestrator จะทำเครื่องหมายทั้งรอบเป็นล้มเหลว แทนที่จะให้ LLM ถัดไปเขียนแทนในเมื่อขาดเลเยอร์การตัดสิน เส้นทางเหล่านี้มีต้นทุนต่อประสบการณ์ผู้ใช้ แต่ทำให้ “โมเดลใช้งานไม่ได้ชั่วคราว” ไม่แอบกลายเป็น “สิทธิ์เขียนยังเหมือนเดิม”

รายงานการปรับเทียบยังแยก “การยกระดับเมื่อ confidence ต่ำ” ออกจาก “การปฏิเสธการดำเนินการ” ตัวอย่างเช่น discard ที่ถูกต้อง หากความเชื่อมั่นไม่ถึง threshold รวม 0.85 จะถูกบันทึกว่าต้องรอ input จากผู้ใช้; ซึ่งไม่เท่ากับการปล่อยผ่านอย่างผิดพลาด รายงานจึงเสนอให้แยก threshold ของการ commit กับการ discard ออกจากกัน แต่ตอนนี้ยังเป็นข้อเสนอ เมื่อเขียน workflow ต้องแยกผลลัพธ์สามแบบให้ชัด: ปล่อยผ่านผิด, ปฏิเสธผิด และรอตรวจ มิฉะนั้นข้อมูลชุดเดียวกันอาจนำไปสู่ข้อสรุป threshold ที่ผิด

กรณีนี้บอกเราว่า การทำงานร่วมกันของ Jev กับ LLM ไม่ควรวาดเป็นเพียง “Jev ตัดสินก่อน แล้ว LLM ค่อยทำงาน” ทุกการตัดสินต้องถามว่า: ช่วงความไม่แน่นอนกว้างแค่ไหน? มันจะทำให้ processor ถัดไปไม่ได้รับงานตลอดไปหรือไม่? ถ้าหลักฐานอินพุตถูกตัดทอน จะยกระดับอย่างชัดเจนแทนการเดาได้หรือไม่? ในการใช้งานของเรา state builder จะบันทึก evidence_truncated และให้ผู้เรียกถือว่าเส้นทางที่ขาดหลักฐานเป็นความไม่แน่นอน; การคำนวณที่แน่นอน เช่น การนับและการจัดอันดับ ทำในโค้ดก่อน ไม่ปล่อยให้ Jev เดา ข้อจำกัดที่ทราบของ Jev 1.13 ทางการ ก็แนะนำให้เก็บการนับและเลขคณิตไว้ในโค้ด

ควรวาง LLM Guardrails ไว้ตรงไหน?

cookbook เรื่อง LLM guardrails ของ TypeSafe วาง Jev ไว้ทั้งสองฝั่งของอินพุตและเอาต์พุต LLM มันใช้ชุด Noul เพื่อระบุความเสี่ยงต่าง ๆ ใช้ Score วัดความรุนแรง จากนั้นโค้ดตัดสินตามนโยบายว่าจะปล่อยผ่าน, ให้มนุษย์ตรวจซ้ำ, บล็อก หรือส่งต่อฝ่ายสนับสนุน เอาต์พุตก็ต้องตรวจด้วย เพราะอินพุตธรรมดาก็ยังอาจได้ผลลัพธ์การสร้างที่ไม่เหมาะสม

ขอบเขตของ guardrails ประเภทนี้ก็ชัดเจนเช่นกัน: Jev ตรวจเนื้อหาตามคำถามที่เขียนไว้ล่วงหน้าได้ แต่ไม่ใช่หลักประกันความปลอดภัยแบบครอบจักรวาล เอกสารข้อจำกัดทางการ ระบุชัดว่าเนื้อหาอันตรายอาจส่งผลต่อการตัดสิน จึงต้องเขียน criteria ให้ชัดและทดสอบขอบเขต ในตัวอย่างสังเคราะห์ของเราเคยทำ injection probe กับพารามิเตอร์ candidate 16 ครั้ง บันทึกการพลิกอันดับได้ 0 ครั้ง; ตัวอย่างเล็กเกินไป จึงสรุปไม่ได้ว่า “แก้ปัญหา prompt injection ได้แล้ว” สิ่งที่กำหนดจริงว่าเครื่องมือทำอะไรได้ยังคงเป็น allowlist, การ gate ตามระยะ และการตรวจสอบก่อน commit ในโค้ด

เมื่อไรควรใช้ และเมื่อไรไม่ควรใช้?

เหมาะกับ Jev เมื่อ: ชุด candidate เป็นที่รู้จัก, คำถามสามารถแยกเป็นการตัดสินสั้น ๆ หลายข้อ, ซอฟต์แวร์ต้องการความน่าจะเป็นเพื่อตัดสินว่าจัดการอัตโนมัติหรือยกระดับให้มนุษย์ ตัวอย่างเช่น routing ฝ่ายบริการลูกค้า, การกรอง paragraph ใน RAG, การให้คะแนน candidate action ของ Agent, การตรวจสอบการอ้างอิงในผลลัพธ์ที่สร้าง หากงานต้องเขียนจดหมายตอบกลับ, แก้โค้ดบางส่วน หรืออธิบายกระบวนการให้เหตุผลซับซ้อน ให้ LLM รับช่วงไป หากงานคือคำนวณเงินให้แม่นยำ, เปรียบเทียบวันที่ หรือตรวจสอบ access control โปรแกรมควรคำนวณโดยตรง หน้า Models ยังระบุว่า Jev รับเฉพาะข้อความ และภาษาอังกฤษเป็นภาษาที่โมเดลฝึกมาแล้วทำได้ดีที่สุดในตอนนี้; สถานการณ์ภาษาจีนต้องประเมินด้วยข้อมูลของตัวเอง ไม่สามารถคัดลอก threshold จาก cookbook ภาษาอังกฤษมาใช้ได้

หากต้องการดูว่า Agent จริงจัดการสิทธิ์และการเรียกเครื่องมืออย่างไร สามารถเริ่มที่ PandaNpc Agent; เกี่ยวกับขอบเขตและสถานการณ์ใช้งานของ coding Agent สามารถดูได้ที่ การเปรียบเทียบ Claude Code กับ Codex

ผู้อ่านสามารถเริ่มจาก validation set เล็ก ๆ: เตรียมตัวอย่างสี่ประเภท “จัดการอัตโนมัติได้ชัดเจน”, “ควรปฏิเสธชัดเจน”, “ความหมายกำกวม”, “มีคำสั่งอันตราย”; กำหนด label โดยมนุษย์ก่อน จากนั้นบันทึกความน่าจะเป็นของแต่ละคำถาม Jev และผลการ routing เกณฑ์ความสำเร็จไม่ใช่ทุกข้อผ่านอัตโนมัติ แต่เป็นอัตราความผิดพลาดของเส้นทางจัดการอัตโนมัติและปริมาณการยกระดับให้มนุษย์ที่อยู่ในช่วงที่คุณยอมรับได้ หากตัวอย่างกำกวมติดที่คำถามเดียวกันจำนวนมาก ให้ตรวจก่อนว่าคำถามปนการตัดสินหลายอย่าง, state ยาวเกินไป หรือ threshold ยังไม่ได้ปรับเทียบกับข้อมูลท้องถิ่น

FAQ

Jev แทน Claude Code, Codex หรือโมเดลแชตได้หรือไม่? ไม่ได้ TypeSafe กำหนดตำแหน่งมันเป็นโมเดลตัดสินแบบมีโครงสร้างภายในซอฟต์แวร์; การแชต, การเขียน และการสร้างโค้ดยังต้องใช้ LLM

ถ้าประเภทผลลัพธ์คงที่ จะไม่ผิดพลาดเลยหรือไม่? ไม่ใช่ ประเภทคงที่ลดปัญหาการ parse และเอาต์พุตนอกขอบเขต แต่การจำแนก, การให้คะแนน และการตัดสินข้อเท็จจริงยังผิดพลาดได้ เส้นทางที่ confidence ต่ำและความเสี่ยงสูงควรเก็บ human review ไว้

คำขอเดียวถามได้กี่คำถาม? สามารถใส่ Choice, Score, Noul อิสระหลายข้อที่ใช้ state เดียวกันไว้ในคำขอเดียวได้ คำถามแต่ละข้อประเมินแยกกัน การตัดสินที่ซับซ้อนยังควรแยกออก แล้วให้โค้ดประกอบกลับ

ใช้ภาษาจีนได้ไหม? ทางการระบุว่ารองรับภาษาธรรมชาติรวมถึงตัวอักษรจีน ญี่ปุ่น และเกาหลี แต่ความแม่นยำภาษาอังกฤษดีที่สุดในตอนนี้ งานที่ใช้ภาษาจีนต้องตรวจสอบและปรับเทียบแยกต่างหาก