ผู้เขียน: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev คือโมเดลสำหรับการตัดสินใจแบบมีชนิดข้อมูล (typed decisions) คุณส่งบริบทพร้อมกับชุดคำถามและตัวเลือกที่กำหนดไว้ตายตัวให้มัน แล้วมันจะคืนค่าเป็นตัวเลือก คะแนน และความน่าจะเป็นกลับมา แทนที่จะสร้างข้อความออกมา มันคือโมเดลแบบ “System One” นั่นเอง!
แต่การจำแนกประเภท (classification) ก็ไม่ใช่เรื่องใหม่ เช่นเดียวกับ structured outputs, โมเดลขนาดเล็ก หรือการอ่านค่าความน่าจะเป็นจาก logits ประวัติความเป็นมาเหล่านี้ช่วยอธิบายได้ว่าทำไมปฏิกิริยาตอบรับต่อ Jev ถึงแบ่งออกเป็นสองฝั่ง...
ฝ่ายที่กังขาก็มีเหตุผลอยู่เหมือนกัน แต่ Jev ก็มีที่ยืนของตัวเองในระบบนิเวศนี้อย่างแท้จริง เพื่อทำความเข้าใจให้ลึกซึ้งขึ้น เราควรกางพื้นที่ของโซลูชันทั้งหมดออกมาดูกันก่อน
แล้วมีทางเลือกอื่นอะไรบ้าง?
เมื่อระบบต้องการ label, คะแนน หรือคำตอบแบบใช่/ไม่ใช่ เรามีทางเลือกที่สมเหตุสมผลอยู่ 4 ทาง:
แนวทาง
เหตุผลที่ควรใช้
ข้อแลกเปลี่ยน
LLM อเนกประสงค์
Zero-shot, ยืดหยุ่นสูง และยังสามารถสร้างข้อโต้แย้งหรือคำอธิบายได้ด้วย อาจเรียกได้ว่าเป็น “ความฉลาดที่สูงกว่า” ผ่านการประมวลผลในช่วง inference (reasoning)
ต้องแลกกับ latency และต้นทุนของ autoregressive model เพียงเพื่อการตัดสินใจเล็ก ๆ น้อย ๆ
Open zero-shot classifier
ราคาถูก รันบนเครื่องตัวเองได้ และควบคุมได้ง่าย
คุณภาพไม่คงที่ คุณต้องรับผิดชอบเรื่องการเลือกโมเดลและการให้บริการเอง
Fine-tuned classifier
มักเป็นตัวเลือกที่ดีที่สุดสำหรับงานที่เสถียร มีปริมาณการใช้งานสูง และมี label ที่ดี
ต้องเก็บข้อมูล เทรน นำไปใช้งาน จัดการปัญหา data drift และ taxonomy ที่ยืดหยุ่นน้อยกว่า
Jev
ความยืดหยุ่นแบบ zero-shot ที่มาพร้อม API แบบ hosted ที่ใช้งานง่าย
คุณภาพขึ้นอยู่กับแต่ละงาน ไม่มีการสร้างข้อความ และต้องพึ่งพาผู้ให้บริการ
จุดเด่นของ Jev คือ ทีมสามารถเปลี่ยนคำถามและตัวเลือกได้โดยไม่ต้องไปเก็บชุดข้อมูลเทรนใหม่ และยังไม่ต้องปวดหัวกับการดูแลการให้บริการโมเดลให้ดีอีกด้วย ไม่มีใครควรมองข้ามข้อดีนี้ ประโยคที่ว่า “เราก็สร้างเองได้นะ” นั้นใช้ได้กับผลิตภัณฑ์ด้าน infrastructure เกือบทุกตัวอยู่แล้ว
โปรเจกต์โอเพนซอร์สที่ทำซ้ำขึ้นมาได้ช่วยดึงคำเคลมเรื่องความแปลกใหม่ลงมาสู่ความจริง การนำไปใช้งานด้วย Qwen และ SGLang, DiffusionGemma และ vLLM รวมถึง Kev สามารถจำลองรูปแบบ API หรือโครงสร้างโมเดลออกมาได้ใกล้เคียงมาก
85.7% สำหรับ Jev และ 79.6% สำหรับ Kev-8B บน n=764
ผลการทดสอบภายนอกของ Parallel ก็พบเช่นเดียวกันว่า Jev ทำผลงานแข่งขันได้ในงาน reranking ในขณะที่โมเดลเฉพาะทางยังคงเอาชนะไปได้ในงาน classification สองรายการ
สิ่งที่เราพบที่ Glean
นั่นจึงนำไปสู่คำถามเชิงปฏิบัติที่ว่า: เมื่อไหร่ที่การผสมผสานระหว่างความยืดหยุ่นแบบ zero-shot และ hosted inference ของ Jev จะดีกว่าทางเลือกอื่นจริง ๆ? เราได้ทดสอบการตัดสินใจแบบจำกัดขอบเขต 4 รายการที่ Glean ซึ่งเรามี baseline อยู่แล้ว และสามารถเปรียบเทียบคุณภาพระดับองค์กรจริงได้ baseline ส่วนใหญ่เป็นระบบที่ใช้ LLM ดังนั้นในการทดลองเหล่านี้ เรารู้ล่วงหน้าเลยว่าควรคาดหวังต้นทุนและ latency ที่ดีขึ้นราวสองอันดับขนาด (two orders of magnitude) ผลลัพธ์ที่ได้มีตั้งแต่แย่กว่าระบบ production อย่างเห็นได้ชัด ไปจนถึงทั้งเร็วกว่าและแม่นยำกว่า router ที่ใช้ LLM
Query classification
Query classification คือการจับคู่ request เข้ากับ task กว้าง ๆ ที่ระบบปลายทางจะนำไปใช้ต่อ นี่เป็น workload ที่เหมาะกับ Jev เป็นอย่างมาก เพราะแม้ในระดับแต่ละ request เราจะรู้ label space ล่วงหน้า แต่ taxonomy ก็สามารถเปลี่ยนแปลงได้เร็วกว่าการ retrain fine-tuned classifier เสมอ
ในการทดลองนี้ เราเน้นวัดระดับความสอดคล้อง (agreement) ของ Jev เทียบกับผลลัพธ์จากระบบ production / baseline ของเราซึ่งใช้ LLM เราคาดการณ์และสังเกตเห็นแล้วว่า throughput ในโหมด offline ของ Jev เร็วขึ้นมาก จึงใช้ค่า agreement เป็นตัวแทนในการวัดคุณภาพที่เข้าใจง่าย นอกจากนี้เรายังใช้ Laya ซึ่งเป็น decision model แบบ open-weight และ Laya ที่ผ่านการ fine-tune มาเป็น baseline ด้วย การ fine-tune นี้รันบนเครื่องโลคอลได้ภายในไม่กี่ชั่วโมง และโมเดลก็เล็กพอที่จะให้บริการบนเครื่องของนักพัฒนาได้เลย
การทดลอง
Broad Task Agreement
ประสิทธิภาพ
Jev zero-shot
66.8%
~
12 นาที (concurrency เท่ากับ 4
)
Base Laya
35.9%
~
90 วินาที (เครื่อง dev โลคอล)
Laya ที่ fine-tune แล้ว
74.5%
~
90 วินาที (เครื่อง dev โลคอล)
ในฐานะโมเดลสำเร็จรูปที่สะดวกและไม่ต้องเทรน Jev เอาชนะ Laya ได้อย่างชัดเจน แต่ก็ไม่เหนือความคาดหมายที่การ fine-tune จะทำให้ Laya โดดเด่นขึ้นมา โดยเฉพาะเมื่อดูจากตัวเลขด้านประสิทธิภาพ ข้อแลกเปลี่ยนคือความพยายามในการหา label ที่ดีและตั้งค่าการเทรน Jev จึงน่าจะยังเป็นตัวเลือกที่น่าสนใจกว่าเมื่องานนั้นเป็นเรื่องใหม่ หรือ label ยังมีการเปลี่ยนแปลงอยู่
Model routing: expert transfer
Model routing เป็นปัญหาที่เกี่ยวข้องกับ query classification ในที่นี้ เรามอง model routing เป็น expert transfer โดยระบบของเราจะเลือกว่า expert / โมเดลใดควรเป็นผู้จัดการ request นั้น baseline ระบบ production ปัจจุบันของเราจะให้ LLM ตัดสินใจเรื่องนี้โดยตรงใน agentic loop ของ harness แม้การทดสอบนี้จะเหมาะอย่างยิ่งต่อการดูว่า Jev สามารถแทนที่ generative call ด้วยการตัดสินใจแบบจำกัดขอบเขตได้หรือไม่ แต่ข้อจำกัดทางเทคนิคที่สำคัญคือ Jev จะ เพิ่ม การเรียกใช้งานเสมอในกรณีที่ไม่มีการ transfer ซึ่งต่างจาก baseline ในระบบ production ที่ในกรณีไม่มีการ transfer สามารถเริ่มงาน tool-calling ได้เลยจากการเรียก LLM ครั้งแรกเพียงครั้งเดียว
เราใช้เวอร์ชันย่อของ routing ในระบบ production ที่มี expert เพียง 3 ตัว นำ golden entries ที่เทียบเคียงได้ 751 รายการมารันผ่าน Jev router ตัวใหม่ แล้วเปรียบเทียบเส้นทางที่เลือกกับ router เดิมที่ใช้ prompt-based (ขับเคลื่อนด้วย LLM แบบดั้งเดิม) พร้อมวัดความแม่นยำเทียบกับ golden label
เรายังแยก 40 รายการที่เส้นทางเดิมมีการเรียก expert-transfer จริง ๆ (n น้อยลง) มาเพื่อเปรียบเทียบ call latency ในรายการเดียวกันด้วย
ความเร็วที่เพิ่มขึ้นต่อบันทึก (median per-entry speedup) อยู่ที่ 8.1× ซึ่งถือเป็นหนึ่งในผลลัพธ์ภายในที่แข็งแกร่งที่สุดของ Jev จนถึงตอนนี้: ในงาน routing แบบจำกัดขอบเขตนี้ Jev ทั้งแม่นยำกว่าและเร็วกว่าอย่างเห็นได้ชัด ขนาดของส่วนต่างนี้บ่งบอกว่า "ภาษี" ด้านการบล็อกที่เราต้องจ่ายไปกับ request ที่ไม่ได้ route ไปหา expert อาจเป็นการแลกเปลี่ยนที่คุ้มค่า โปรดทราบว่าการเปรียบเทียบนี้ยังทำบน golden-set แบบออฟไลน์อยู่ และตัวอย่าง latency มีแค่ 40 positive transfers ดังนั้นยังมีอะไรอีกมากที่ต้องลดความเสี่ยงและทดสอบเพิ่มเติม!
Reranking
ปัญหานี้เป็นเรื่องใกล้ตัวและสำคัญมากสำหรับ Glean! ด้านล่างนี้ baseline ระบบ production ของเราคือลำดับที่ได้จาก search stack ปัจจุบันของ Glean การทดลองนี้ได้ขอให้ Jev จัดเรียงผลลัพธ์สูงสุด 50 รายการใหม่
เราลองใช้วิธีแสดง "ความเกี่ยวข้อง" ผ่าน typed outputs ของ Jev ทั้งหมด 4 รูปแบบ:
รูปแบบ
วิธีการแสดงความเกี่ยวข้อง
Pointwise Noul
ถามคำถามความเกี่ยวข้องแบบใช่/ไม่ใช่แยกกันในแต่ละผลลัพธ์ แล้วเรียงตามความน่าจะเป็นของคำว่า “ใช่”
Shared-state Noul
แสดงชุดตัวเลือกทั้งหมดให้ Jev ดูเป็นบริบทร่วมกัน แล้วค่อยถามคำถามใช่/ไม่ใช่เดิมในแต่ละผลลัพธ์
Score
ให้ Jev กำหนดคะแนนความเกี่ยวข้องเป็นตัวเลขแก่ตัวเลือกแต่ละตัว
Choice
มองตัวเลือกทั้งหมดเป็นทางเลือกในการตัดสินใจครั้งเดียว แล้วจัดอันดับตามความน่าจะเป็นที่ได้
เรารันทดสอบนี้บน evalset ภายในที่ผู้ใช้ไม่สามารถเข้าถึง canonicals ทั้งหมดได้ ดังนั้นตัวเลขสัมบูรณ์จึงไม่ได้สะท้อนการจัดอันดับในระบบ production ของเรา แต่ตัวเลขเชิงเปรียบเทียบนั้นน่าสนใจมาก
Jev แบบ “Choice” เป็นรูปแบบที่แข็งแกร่งที่สุด เมื่อทดสอบแบบ paired control กับ search queries ที่บันทึกไว้ 4,855 รายการ โดยตัดการใช้ลำดับจาก production เพื่อตัดสินผลเสมอออกไป ผลลัพธ์ที่ได้คือ:
Jev Choice มีต้นทุนประมาณ $0.00044 ต่อ query และใช้เวลา 0.195 วินาทีที่ p50 ในการทดสอบแบบออฟไลน์ แต่มันกลับให้คะแนนเท่ากันถึงประมาณ 37 จาก 41 ตัวเลือกใน query เฉลี่ยหนึ่งรายการ การใช้ลำดับจาก production มาตัดสินผลเสมอดังกล่าวช่วยดัน Recall@6 จาก 40.2% ขึ้นไปเป็น 44.3% ทำให้ผลลัพธ์ที่ยังไม่ปรับแก้ดูแข็งแกร่งเกินกว่าที่คะแนนของ Jev เพียงอย่างเดียวจะทำได้ ตามปกติแล้วย่อมมีข้อควรระวังหลายประการ แต่โดยทิศทางแล้ว Jev คือ baseline ที่ราคาถูกและมีประสิทธิภาพ ไม่ใช่ตัวตายตัวแทนของ ranker ในระบบ production ของ Glean
Citation-support judging
การตัดสิน citation ตั้งคำถามที่เชื่อมโยงกันสองข้อ: คำกล่าวอ้างที่ต้องการหลักฐานมี citation ที่เพียงพอหรือไม่ (citation recall) และแหล่งข้อมูลที่อ้างอิงมานั้นสนับสนุนคำกล่าวอ้างตามที่ระบุไว้จริงหรือไม่ (citation precision)? มองเผิน ๆ เนื่องจาก output / label space มีขอบเขตจำกัด (คล้ายกับการตั้งค่า judge ส่วนใหญ่) งานนี้ดูเหมือนจะเหมาะกับ Jev อย่างชัดเจน อย่างไรก็ตาม rubric มีความซับซ้อน และอาจต้องแตกคำกล่าวอ้างออกเป็นส่วนย่อย ๆ นอกจากนี้ Jev ยังไม่สร้าง rationale ที่เรามักใช้ในการวิเคราะห์ข้อผิดพลาด จึงมีความเสี่ยงทั้งในด้านคุณภาพและความสะดวกในการใช้งาน
เราทดสอบ Jev กับ response จากระบบ production-eval ความยาว 1,448 คำของจริง โดยตรึง response และหลักฐาน citation ไว้คงที่ เราเปรียบเทียบรอบการตรวจ precision-and-recall ร่วมของมันกับ GPT-5.6 Luna ทั้งแบบไม่ใช้ reasoning และแบบ xhigh reasoning เพื่อลดความแปรปรวน เราให้ judge แต่ละตัวทำงานสามรอบ
Judge
เวลาที่วัดได้ต่อ response เดิม
ต้นทุนที่วัดได้ต่อ response เดิม
Jev
6.6 วินาที
$
0.014
GPT-5.6 Luna, ไม่ใช้ reasoning
81.3–85.5 วินาที
$
0.030–
$
0.047
GPT-5.6 Luna,
xhigh
227.4–259.7 วินาที
$
0.047–
$
0.060
โปรดทราบว่าเวลาที่ใช้เป็นตัวชี้วัดเชิงทิศทางมากกว่าแบบ end-to-end: Jev รายงาน sequential client wall time ในขณะที่แถวของ Luna เป็นการรวมระยะเวลาการเรียกโมเดล ต้นทุนที่แสดงรวมผลจาก caching ที่สังเกตได้แล้ว
เรายังเปรียบเทียบ ความสม่ำเสมอ ใน 28 ย่อหน้าเดียวกันด้วย รายการที่เปลี่ยนแปลงหมายความว่า judge เปลี่ยนคำตัดสินว่าย่อหน้านั้นมี citation ครอบคลุมเพียงพอหรือไม่ ในการรันอย่างน้อยหนึ่งรอบจากสามรอบที่ให้ input เหมือนกัน การนับความไม่ตรงกันแบบจับคู่ (pairwise disagreement) จะนับแต่ละย่อหน้าข้ามทั้งสามคู่ของการรัน รวมเป็น 84 การเปรียบเทียบต่อ judge หนึ่งตัว
Judge
ย่อหน้าที่คำตัดสิน recall เปลี่ยนแปลง
ความไม่ตรงกันของ recall แบบจับคู่
Jev
1 จาก 28 (3.6%)
2 จาก 84 (2.4%)
GPT-5.6 Luna, ไม่ใช้ reasoning
7 จาก 28 (25.0%)
15 จาก 84 (17.9%)
GPT-5.6 Luna,
xhigh
5 จาก 28 (17.9%)
10 จาก 84 (11.9%)
การเปลี่ยนแปลงเพียงอย่างเดียวของ Jev คือการนับว่าย่อหน้าหนึ่งจำเป็นต้องมี citation หรือไม่ โดยหมวดหมู่ recall ดิบของมันไม่ได้เปลี่ยนไปเลย ดังนั้นคำตัดสินเรื่องความครอบคลุมของ citation ระดับย่อหน้าของ Jev จึง ทำซ้ำได้สม่ำเสมอกว่า Luna ทั้งสองรูปแบบ
เราไม่ได้สรุปว่าสิ่งนี้ทำให้ Jev เป็น judge ที่แม่นยำกว่า (เพราะแต่ละระบบใช้เกณฑ์ support และตัวหารคะแนนที่ต่างกัน และเราไม่มีเวลามาทำ human labels อิสระ) แต่แม้จะใช้ xhigh reasoning (ซึ่งทำให้เวลาของโมเดล Luna เพิ่มขึ้นราวสามเท่า) มันก็ยังสม่ำเสมอน้อยกว่า Jev ผลลัพธ์นี้สนับสนุนว่า Jev เป็นวิธีที่รวดเร็ว ราคาถูก และทำซ้ำได้ค่อนข้างดี ในการนำนโยบาย citation แคบ ๆ ไปใช้งาน
สรุปผลการทดลองและคู่มือการใช้งานจริง
ในบางกรณี Jev โดดเด่นในฐานะทางเลือกที่ไร้แรงเสียดทานเมื่อเทียบกับทั้ง LLM แบบดั้งเดิมและ fine-tuned classifiers แต่เมื่อ baseline แข็งแกร่งอยู่แล้ว (reranking) หรือการ fine-tune โมเดลขนาดเล็กทำได้ง่าย (query classification) ข้อดีก็จะลดลง มีสัญญาณว่าคุณภาพดีขึ้นในบางงาน (model routing) รวมถึงความสม่ำเสมอและเสถียรภาพที่ดีกว่า (citation judge) และใน workload ที่สำคัญที่สุดบางส่วนของเรา มันก็มอบชัยชนะด้านต้นทุนและ latency ตามที่คาดไว้เมื่อเทียบกับ LLM แบบดั้งเดิม
ผลลัพธ์ข้างต้นให้ทิศทางที่ดีมาก และที่ Glean เราก็ตื่นเต้นกับ Jev สุด ๆ หลังจากจัดการขั้นตอนเพิ่มเติมอีกเล็กน้อย (ส่วนใหญ่เป็นเรื่องความพร้อมในการดำเนินงาน เช่น data residency และการรับประกันต่าง ๆ) เราวางแผนจะนำ Jev ไปใช้ใน use cases บางส่วนเหล่านี้ นอกจากนี้ Jev จะมีบทบาทสำคัญในงาน hackathon ภายในของเราสัปดาห์นี้ และเราตั้งตารอที่จะแชร์ผลลัพธ์เพิ่มเติม!
ขอทิ้งท้ายด้วยคำแนะนำทั่วไป – ถ้า output สามารถระบุไว้ล่วงหน้าได้ ให้ลอง benchmark Jev ดู ถ้า task และ label มีความเสถียรและมีปริมาณการใช้งานสูง ให้ benchmark fine-tuned classifier ด้วย และถ้าการเรียกใช้งานนั้นต้องสร้าง query, คำอธิบาย หรือข้อความไดนามิกอื่น ๆ ก็ให้เก็บ generative model ไว้ในระบบด้วย Tool calling เป็นตัวอย่างที่ดี: Jev ช่วยเลือก tool ได้ แต่เครื่องมือส่วนใหญ่ของ Glean ยังคงต้องการ argument ที่สร้างขึ้นแบบไดนามิก (เช่น search queries)
Jev ไม่ได้เปลี่ยนความจริงที่ว่า classifier มีอยู่แล้ว มันแค่ทำให้ zero-shot classifier ดี ๆ ใช้งานง่ายขึ้นมากเท่านั้น และนั่นก็เป็นผลิตภัณฑ์ที่แข็งแกร่งแล้ว แม้จะไม่ได้เป็นรากฐานใหม่สำหรับทุกระบบ AI ก็ตาม
