อธิบาย Jev อย่างชัดเจน

เราใช้ LLM เหมือนค้อนสำหรับทุกปัญหา AI แม้แต่การตัดสินใจง่ายๆ Jev จัดการการตัดสินใจเหล่านั้นในมิลลิวินาทีด้วยต้นทุนเพียงเศษเสี้ยว มาทำความเข้าใจกันว่ามันทำงานอย่างไรและเหมาะกับการใช้งานแบบไหน

TypeSafe AI เปิดตัว Jev เมื่อ 15 กันยายน 2026 และได้รับกระแสตอบรับที่รุนแรงอย่างผิดปกติ สำหรับโมเดลที่ไม่สามารถสนทนา เขียนโค้ด หรือสร้างย่อหน้าที่มีประโยชน์ได้แม้แต่ประโยคเดียว

ข้อจำกัดนั้นคือจุดประสงค์ของมัน

ซอฟต์แวร์ส่วนใหญ่ไม่ต้องการแชทบอทอีกตัว มันต้องการทำการตัดสินย่อยๆ หลายพันครั้ง เช่น: ตั๋วนี้เร่งด่วนไหม? โมเดลไหนควรจัดการคำขอเหล่านี้? คำสั่ง shell นี้เป็นอันตรายไหม? ข้อความที่ดึงมาตอบคำถามได้หรือไม่?

ทีมต่างๆ มักส่งการตัดสินแต่ละครั้งไปยัง LLM อเนกประสงค์ โมเดลจะสร้างคำตอบทีละ token แอปพลิเคชันต้องวิเคราะห์ ตรวจสอบ และลองใหม่เมื่อรูปแบบผลลัพธ์ไม่ถูกต้อง วิธีนี้ได้ผล แต่ช้าและมีราคาแพงสำหรับการตัดสินใจที่มีตัวเลือกคำตอบเพียงห้าแบบ

Jev ถูกสร้างขึ้นเพื่อการตัดสินใจเหล่านั้นโดยเฉพาะ TypeSafe เรียกมันว่า System One model: รับสถานะที่ไม่มีโครงสร้างเข้าไป แล้วได้คำตอบที่มีประเภทข้อมูลชัดเจนและความน่าจะเป็นออกมา

มาแยกแยะความหมายของสิ่งนั้น ดูว่ามันเข้ากับตรงไหน และตรงไหนที่การตลาดควรลดความโอ้อวดลงบ้าง

ก่อนอื่น ปัญหาที่ Jev กำลังแก้ไข

LLM กลายเป็นสิ่งที่เชื่อมต่อกับซอฟต์แวร์ได้ง่ายขึ้นมากเมื่อมีการเรียกใช้เครื่องมือ (tool calling) และผลลัพธ์ที่มีโครงสร้าง (structured outputs) เข้ามา

Tool calling ช่วยให้โมเดลขอฟังก์ชันในรูปแบบที่คาดเดาได้ Structured outputs ช่วยให้มันส่งคืน JSON ที่ปฏิบัติตาม schema ทั้งสองอย่างช่วยลดความเปราะบางในการวิเคราะห์ข้อมูล (parsing) ลงอย่างมาก

แต่โมเดลพื้นฐานยังคงเป็นแบบ Generative แม้คำตอบจะเป็นแค่คำเดียวเช่น "billing" มันก็ยังสร้าง token ทีละตัว คุณจ่ายค่า input รอการสร้าง output และมักจ่ายค่า output แพงกว่า

ลองนึกภาพสิ่งนี้ภายใน agent loop

1while not done:
2    action = llm(context)
3    result = run_tool(action)
4    context += result

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

Jev มุ่งเป้าไปที่การเรียกใช้เหล่านั้น

เดิมพันของมันเรียบง่าย: การสร้างภาษาเป็นอินเทอร์เฟซที่ผิดเมื่อโค้ดรู้คำตอบที่เป็นไปได้ทั้งหมดอยู่แล้ว

Jev คืออะไรจริงๆ

คำอธิบายที่สั้นและถูกต้องที่สุดคือ เครื่องยนต์ตัดสินใจเชิงความหมาย (semantic decision engine)

คุณส่งสองสิ่งให้ Jev:

• State: ข้อความหรือ JSON ที่อธิบายสถานการณ์ปัจจุบัน
• Questions: การตัดสินใจที่คุณต้องการให้มันทำเกี่ยวกับ state นั้น

ทุกคำถามจะประกาศรูปแบบคำตอบล่วงหน้า Jev รองรับ primitives สามแบบ:

• Choice เลือกหนึ่งตัวเลือกจากรายการที่คุณกำหนด และคืนค่าความน่าจะเป็นสำหรับทุกตัวเลือก
• Score วางอินพุตบนมาตราส่วนเรียงลำดับที่คุณกำหนด เช่น low, medium, high
• Noul ตอบคำถามใช่หรือไม่ใช่ โดยคืนค่าความน่าจะเป็นว่าเป็นจริง

Noul เป็นชื่อที่ TypeSafe ใช้สำหรับ primitive แบบ Boolean ชื่อแปลกๆ นั้นสำคัญน้อยกว่าผลลัพธ์ (ตัวเลขระหว่าง 0 ถึง 1 ที่โค้ดของคุณนำไปใช้งานได้)

1{
2  "model": "jev-latest",
3  "state": "The deploy failed twice and customers are seeing 500s.",
4  "questions": {
5    "urgent": {
6      "type": "noul",
7      "instructions": "Does this need attention right now?"
8    },
9    "owner": {
10      "type": "choice",
11      "instructions": "Which team should handle this?",
12      "criteria": {
13        "engineering": "Product failures and outages",
14        "billing": "Charges, invoices, and refunds",
15        "sales": "Pricing and new accounts"
16      }
17    }
18  }
19}

การตอบกลับประกอบด้วยค่าความน่าจะเป็นของความเร่งด่วนและการกระจายความน่าจะเป็นของทีมทั้งสาม ไม่มีย่อหน้าให้อธิบาย และไม่มีทีมที่สี่ให้โมเดลคิดค้นขึ้นมา

โปรแกรมของคุณยังคงควบคุมทุกอย่าง:

1if urgent > 0.9 and owner == "engineering":
2    page_on_call()
3elif confidence < 0.6:
4    send_to_human_review()
5else:
6    add_to_queue(owner)

นี่คือเหตุผลที่ผู้คนยังคงเรียก Jev ว่า smart switch statement วลีนี้อาจฟังดูเป็นการดูถูก แต่มันจับใจความสำคัญของดีไซน์ที่เป็นประโยชน์ โค้ดทั่วไปเป็นเจ้าของสาขา (branches) ส่วนโมเดลทำหน้าที่ให้การตัดสินใจแบบคลุมเครือ (fuzzy judgment) ที่โค้ดทั่วไปไม่สามารถคำนวณได้อย่างเชื่อถือได้

ความแตกต่างที่สำคัญจาก LLM

LLM แบบดั้งเดิมและ Jev สามารถจำแนกตั๋วสนับสนุนได้ทั้งคู่ พวกมันไปถึงคำตอบด้วยวิธีที่แตกต่างกันและมีประโยชน์ในส่วนต่าง ๆ ของระบบ

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

บริษัทรายงาน latency ตั้งแต่ต้นจนจบระหว่าง 70 ถึง 500 มิลลิวินาที และราคา $0.042 ต่อ million input tokens โดย output ฟรี ข้อเคลมหลักอ้างว่าเร็วกว่าประมาณ 200 เท่าและถูกกว่า 400 เท่าเมื่อเทียบกับเวิร์กโฟลว์ LLM ที่คล้ายคลึงกัน

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

ทำไมความน่าจะเป็นจึงสำคัญ

คำตอบที่มีประเภทข้อมูลชัดเจนแก้ปัญหาได้เพียงครึ่งเดียว

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

1{
2  "choice": "billing",
3  "probabilities": {
4    "billing": 0.52,
5    "technical": 0.46,
6    "sales": 0.02
7  },
8  "confidence": 0.18
9}

การส่งต่อตั๋วนี้โดยอัตโนมัติอาจเป็นการกระทำที่ประมาท Billing ชนะ แต่ชนะเฉียดฉิว คำตอบที่มีความมั่นใจต่ำควรกระตุ้นสาขาอื่น

สิ่งนี้มอบแพทเทิร์นที่ใช้งานได้จริงให้กับนักพัฒนา:

• ความมั่นใจสูง: ดำเนินการอัตโนมัติเมื่อผลกระทบเล็กน้อย
• ความมั่นใจปานกลาง: ขอการยืนยันหรือเรียกใช้โมเดลที่ทรงพลังกว่า
• ความมั่นใจต่ำ: ส่งเคสให้มนุษย์หรือรวบรวมข้อมูลเพิ่มเติม

เกณฑ์ (thresholds) ควรอยู่ในโค้ด เพื่อให้ตรวจสอบและเปลี่ยนแปลงได้ ป้ายกำกับบนแดชบอร์ดอาจทนต่อการทำนายที่อ่อนแอได้ แต่คำสั่งที่ลบข้อมูลควรมีมาตรฐานที่สูงกว่ามาก

TypeSafe ฝึก Jev โดยใช้ Reinforcement Learning for Calibrated Decisions หรือ RLCD เป้าหมายคือให้ความมั่นใจสะท้อนความแม่นยำทั่วทั้งการทำนายจำนวนมาก หากโมเดลให้คำตอบชุดหนึ่งด้วยความน่าจะเป็น 90 เปอร์เซ็นต์ คำตอบประมาณ 90 เปอร์เซ็นต์นั้นควรถูกต้อง

ข้อเคลมเรื่อง Hallucination ต้องการความแม่นยำ

TypeSafe บอกว่า Jev ไม่สามารถ hallucinate ได้ คำกล่าวนี้เป็นจริงเฉพาะภายใต้คำนิยามที่แคบเท่านั้น

Jev ไม่สามารถส่งคืนตัวเลือกนอก schema ได้ หากคุณกำหนด billing, technical และ sales การตอบกลับไม่สามารถคิดค้น legal ขึ้นมาได้ นอกจากนี้มันยังไม่สามารถสร้างข้อความที่ผิดรูปเมื่อโค้ดของคุณคาดหวังป้ายกำกับ

แต่มันสามารถเลือกตัวเลือกที่ถูกต้องตาม schema แต่ผิดในความเป็นจริงได้อย่างมั่นใจ

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

ประโยคที่ปลอดภัยกว่าคือ "Jev ไม่สามารถทำลาย output schema ที่ประกาศไว้ได้ แต่มันยังสามารถตัดสินใจผิดได้"

ตำแหน่งของ Jev ภายใน Agent

Jev ทำงานได้ดีที่สุดเมื่อใช้ร่วมกับ LLM แทนที่จะแทนที่มัน

LLM จัดการงานที่ต้องการภาษาหรือการให้เหตุผลที่ลึกซึ้งกว่า มันวางแผน เขียน อธิบาย และใช้เครื่องมือ Jev จัดการการตัดสินใจบ่อยๆ รอบๆ งานเหล่านั้น

ตำแหน่งการใช้งานสามแห่งน่าสนใจเป็นพิเศษ

Model Routing

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

1route = jev.choice(
2    state=user_request,
3    options={
4        "fast": "Lookups, extraction, and small local edits",
5        "powerful": "Architecture, ambiguity, and high-stakes work",
6    },
7)
8
9model = fast_model if route == "fast" else powerful_model

Router ไม่ได้ตอบคำขอ มันตัดสินใจว่าโมเดลไหนควรตอบ

Tool Risk Gating

ก่อนที่ agent จะรันคำสั่ง shell Jev สามารถจำแนกมันว่าเป็น read-only, reversible หรือ destructive คำถามแยกต่างหากสามารถตรวจสอบว่ามันลบไฟล์ เปลี่ยนประวัติ Git สัมผัส production หรือออกจาก repository หรือไม่

การกระทำแบบ read-only ที่มีความมั่นใจสูงสามารถดำเนินการต่อได้ การกระทำที่ destructive หรือมีความไม่แน่นอนสามารถหยุดรอการอนุมัติจากมนุษย์ได้ การรวม Jev เข้ากับ LangChain นำแพทเทิร์นนี้มาใช้ผ่าน middleware ที่ตรวจสอบ tool call ก่อนการประมวลผล

Verification and Supervision

Agent อาจอ้างว่างานเสร็จแล้วในขณะที่เทสต์ยังล้มเหลว Jev สามารถตรวจสอบ state และตอบคำถามที่มีขอบเขตชัดเจน: เทสต์ผ่านไหม? Agent กำลังทำซ้ำการกระทำเดิมไหม? ผลลัพธ์ปฏิบัติตามนโยบายไหม? ควรตรวจสอบผลลัพธ์นี้ไหม?

มันจะไม่แทนที่ hard test เมื่อมีอยู่ มันเพิ่มการตรวจสอบเชิงความหมายในจุดที่กฎขึ้นอยู่กับความหมาย

ปัญหาที่ Jev แก้ไขได้ในปัจจุบัน

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

Support and Operations

• จำแนกเจตนา ความเร่งด่วน แผนก สแปม และความหงุดหงิดของลูกค้า
• ส่งต่อเงินคืนและข้อยกเว้นนโยบายผ่านการตรวจสอบย่อยหลายขั้นตอน
• จัดอันดับ logs และ incidents ตามความรุนแรงเชิงความหมายก่อนที่มนุษย์จะอ่าน

คำขอเดียวสามารถถามคำถามทั้งหมดเหล่านี้เกี่ยวกับตั๋วเดียวกันได้ จากนั้นโค้ดจะรวมคำตอบเข้าด้วยกันตามนโยบายการส่งต่อของบริษัทจริง

Search and Retrieval

• จัดอันดับข้อความที่ดึงมาใหม่โดยพิจารณาว่าพวกมันตอบ query ได้หรือไม่
• ตรวจสอบว่าการอ้างอิงสนับสนุนข้อกล่าวอ้างหรือไม่
• กรอง chunks ที่ไม่เกี่ยวข้องก่อนส่ง context ไปยัง LLM ที่มีราคาแพง

Embeddings ดีเยี่ยมในการค้นหาข้อความที่เกี่ยวข้องเชิงความหมาย Jev สามารถทำการตัดสินใจที่แคบกว่าว่าข้อความเฉพาะเจาะจงนั้นมีประโยชน์สำหรับคำถามนี้หรือไม่

Quality and Safety

• คัดกรอง prompts เพื่อหา jailbreaks หรือ prompt injection
• ตรวจสอบเนื้อหาที่สร้างขึ้นเทียบกับนโยบายหรือเกณฑ์
• ทำธงเตือนการเปลี่ยนแปลงโค้ดหรือ tool calls ที่เสี่ยงก่อนการประมวลผล

การตรวจสอบเหล่านี้ควรวางคู่กับ controls แบบ deterministic ตัวจำแนกเชิงความหมายมีประโยชน์สำหรับความเสี่ยงที่คลุมเครือ ในขณะที่ permissions, sandboxes และ tests บังคับใช้กฎที่ซอฟต์แวร์สามารถตรวจสอบได้อย่างแม่นยำ

High Volume Classification

• ติดป้ายเอกสาร งานวิจัย รายการสินค้า หรือข้อความจากลูกค้า
• แปลงข้อความอิสระให้เป็น features สำหรับโมเดล machine learning แบบดั้งเดิม
• ให้คะแนนทุกรายการใน corpus ขนาดใหญ่โดยใช้เกณฑ์เดียวกัน

นี่คือจุดที่ต้นทุนต่อครั้งต่ำกลายเป็นมากกว่าตัวเลข benchmark การตัดสินใจที่เคยแพงเกินกว่าจะรันทุกแถวสามารถย้ายเข้าสู่ data pipeline ปกติได้

Real Time Interfaces

• เลือกการกระทำถัดไปในเบราว์เซอร์จากองค์ประกอบหน้าเว็บที่รู้จัก
• ให้คะแนนโทนเสียงหรือความชัดเจนขณะบุคคลกำลังเขียน
• เลือกการกระทำจาก state ของเกมหรือ simulator ที่มีโครงสร้าง

Jev รองรับเฉพาะข้อความในปัจจุบัน ดังนั้นระบบเหล่านี้ต้องแปลงสภาพแวดล้อมเป็นข้อความหรือ JSON ก่อน มันไม่ได้มองหน้าจอหรือเล่นจากพิกเซล

จุดที่ Jev เป็นตัวเลือกที่ผิด

Jev มีประโยชน์น้อยลงทันทีที่พื้นที่คำตอบไม่ใช่สิ่งที่ทราบล่วงหน้า

• มันไม่สามารถเขียนคำตอบ สรุปเอกสาร สร้างโค้ด หรืออธิบายเหตุผลของมันได้
• มันไม่น่าเชื่อถือสำหรับการคำนวณเลข นับจำนวน เปรียบเทียบวันที่ หรือจัดการสตริงแบบแม่นยำ เก็บปฏิบัติการเหล่านั้นไว้ในโค้ด
• มันลำบากเมื่อการตัดสินใจต้องการขั้นตอนการให้เหตุผลซ่อนเร้นหลายขั้น แบ่งการตัดสินใจออกเป็นคำถามย่อยๆ หรือใช้ reasoning model
• มันไม่สามารถสกัดค่าที่ไม่รู้จักโดยตรงได้ ค้นหา candidate values ก่อน แล้วให้ Jev เลือกจากบรรทัดนั้น
• Context ที่ไม่เกี่ยวข้องสามารถลดความแม่นยำได้ ส่งเฉพาะ state ที่จำเป็นสำหรับการตัดสินใจเท่านั้น
• น้ำหนักปิด (closed weights), early access, อินพุตแบบข้อความล้วน และข้อมูล calibration อิสระที่จำกัด ทำให้เร็วเกินไปที่จะไว้วางใจโดยไม่ตรวจสอบ

ยังมีกฎที่ง่ายกว่า: ถ้าโค้ด deterministic แก้ปัญหาได้ถูกต้องอยู่แล้ว ก็เก็บโค้ดนั้นไว้ if statement ธรรมดาเร็วกว่า ถูกกว่า และทดสอบง่ายกว่าโมเดลใดๆ

วิธีใช้ Jev โดยไม่สร้าง failure mode ใหม่

โมเดลราคาถูกอาจยังแพงอยู่ถ้าความผิดพลาดของมันทำให้เกิด retries, manual review หรือ production incidents วัดเวิร์กโฟลว์ทั้งหมด ไม่ใช่แค่ราคา token

การ rollout ที่สมเหตุสมผลมีลักษณะดังนี้:

1. เลือกการตัดสินใจที่มีขอบเขตชัดเจนและมีความเสี่ยงต่ำหนึ่งอย่างพร้อมคำตอบที่เป็นไปได้ที่ชัดเจน
2. เขียนเกณฑ์ (rubric) ก่อนเรียกใช้โมเดล กำหนดว่าอะไรอยู่ในทุกตัวเลือก
3. รวบรวมตัวอย่างที่เป็นตัวแทนพร้อมคำตอบที่คาดหวัง รวมถึงกรณีคลุมเครือและ adversarial cases
4. รัน Jev ใน shadow mode ข้างๆ เวิร์กโฟลว์ปัจจุบันโดยไม่ปล่อยให้มันเปลี่ยนพฤติกรรม
5. พล็อตความแม่นยำเทียบกับความมั่นใจ และตั้ง thresholds จากข้อมูลของคุณ
6. อัตโนมัติสาขาที่ปลอดภัยที่สุดก่อน และเก็บมนุษย์หรือโมเดลที่ทรงพลังกว่าไว้สำหรับกรณีที่แน่นอน
7. Pin หรือ log เวอร์ชันโมเดล คำถาม เกณฑ์ และ thresholds เพื่อให้สามารถ replay การเปลี่ยนแปลงเทียบกับ evaluation set เดิมได้

คำถามเป็นส่วนหนึ่งของโปรแกรม ปฏิบัติต่อมันเหมือนโค้ด: versioning, review และทดสอบทุกครั้งเมื่อโมเดลหรือเกณฑ์เปลี่ยนแปลง

การเปลี่ยนแปลงที่แท้จริง

Jev ไม่น่าสนใจเพราะมันชนะ LLM ในการเขียน มันปฏิเสธที่จะเขียน

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

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

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

นั่นคือหมวดหมู่ที่ Jev พยายามสร้าง

จุดเริ่มต้น

อย่าเริ่มด้วยการสร้าง agent ใหม่รอบๆ Jev หาการตัดสินใจหนึ่งอย่างที่ต้องการ LLM call ช้าๆ หรือ regex ที่พังบ่อยๆ

ให้ state ขั้นต่ำแก่ Jev กำหนดคำตอบที่เป็นไปได้ และ log ความน่าจะเป็นของมันข้างๆ ผลลัพธ์ปัจจุบัน ปล่อยให้มันพิสูจน์ว่าสมควรได้หนึ่ง branch ก่อนที่คุณจะมอบเวิร์กโฟลว์ทั้งหมดให้มัน

mental model ที่มีประโยชน์ที่สุดยังคงเป็นแบบที่เรียบง่ายที่สุด → Jev เพิ่มการตัดสินใจในจุดที่ if statement ธรรมดาเข้าใจค่าแต่ไม่เข้าใจความหมาย

Sources and further reading

• TypeSafe AI: Introducing System One Models and Jev
• LangChain: Building a Harness with Jev
• Flavio Copes: A deep dive into Jev

หวังว่าคุณจะสนุกกับการอ่าน

พบกันใหม่ตอนหน้า

Cheers! :)