สวัสดีครับเพื่อนๆ ผมจินเฉินมา (Jin Chenma) ครับ
ขอเริ่มด้วยคำถามหนึ่งข้อ: ในแง่ของเนื้อหาที่ประมวลผล โมเดล AI ขนาดใหญ่ที่เราพบเจอโดยทั่วไปมีรูปแบบอะไรบ้าง?
คนส่วนใหญ่คงคุ้นเคยกับข้อความ รูปภาพ เสียง และวิดีโอ ในช่วงไม่กี่ปีที่ผ่านมา ผู้ให้บริการต่างๆ ได้แข่งขันและพัฒนารุ่นใหม่อย่างต่อเนื่องในทิศทางเหล่านี้ ทำให้ความสามารถแข็งแกร่งขึ้นและการแข่งขันดุเดือดมากขึ้น
หลังจากเห็นการอัปเดตมากมาย ผมก็อดสงสัยไม่ได้ว่า: นอกจากการทำโมเดลที่มีอยู่ให้เก่งขึ้นแล้ว จะมีรูปแบบโมเดลใหม่ๆ เกิดขึ้นหรือไม่?
เมื่อไม่นานมานี้ มีโมเดลชื่อ Jev เริ่มเป็นที่พูดถึงอย่างกว้างขวาง ตอนแรกผมคิดว่า: นี่เป็นแค่บริษัทอื่นที่ปล่อย Large Language Model ตัวใหม่ออกมาหรือเปล่า?
แต่พอเจาะลึกเข้าไป ผมพบว่าโมเดลนี้มีความน่าประทับใจจริงๆ
เบื้องหลังมันคือ TypeSafe AI ที่เสนอแนวคิดเรื่องโมเดลประเภทหนึ่งที่เรียกว่า System One Models ซึ่งออกแบบมาโดยเฉพาะสำหรับงานตัดสิน (Judgment Tasks) ในซอฟต์แวร์ โดย Jev คือโมเดลสาธารณะตัวแรกของพวกเขา
หมวดหมู่ก่อนหน้า (ข้อความ, รูปภาพ, เสียง, วิดีโอ) ถูกแบ่งตามประเภทของเนื้อหา; แต่ครั้งนี้ พวกเขาเปลี่ยนมุมมอง: โดยยก "การตัดสินใจ" ให้เป็นงานเฉพาะทางและออกแบบโมเดลรอบๆ มัน
ผมคิดว่าทิศทางนี้อาจส่งผลกระทบอย่างลึกซึ้งต่อการพัฒนาและการแบ่งหน้าที่ของโมเดล AI ในอนาคต
ในบทความนี้ ผมจะอธิบายให้ชัดเจนว่า Jev คืออะไร แตกต่างจาก LLM มาตรฐานอย่างไร สามารถนำไปใช้ได้ที่ไหน และเริ่มต้นใช้งานอย่างไร
เริ่มด้วยการเปรียบเทียบกับ QR Code
เราจะเข้าใจ Jev ได้อย่างไร? ลองนึกภาพว่าคุณต้องการสร้าง QR Code
ปกติแล้ว คุณจะใช้เครื่องมือสร้าง QR Code แต่สมมติว่าคุณจ้างศิลปินที่วาดรูปได้ทุกอย่าง มาขอให้เขาวาด QR Code ทีละพิกเซล
แน่นอน ศิลปินคนนี้เก่งมากและทำได้ แต่การสร้าง QR Code มีเครื่องมือเฉพาะทางอยู่แล้ว คุณแค่ต้องการ QR Code ที่ใช้งานได้ ไม่ใช่ทิวทัศน์สวยๆ ที่มาพร้อมกัน
เช่นเดียวกัน เมื่อเปรียบเทียบ Jev กับ Large Language Models:
LLMs สามารถเขียนบทความ เขียนโค้ด และอภิปรายปัญหาซับซ้อนได้ ถ้าคุณสั่งให้ LLM อ่านคอมเมนต์และตัดสินอารมณ์ของผู้ใช้ มันทำได้แน่นอน
แต่ถ้างานนั้นต้องการเพียงการเลือกหรือให้คะแนน ลองพิจารณาว่า: เราสามารถสร้างโมเดลที่เร็วกว่า ถูกกว่า และเข้าถึงได้ผ่านโปรแกรมได้ง่ายกว่า สำหรับงานลักษณะนี้โดยเฉพาะได้ไหม?
นี่แหละคือสิ่งที่ Jev ทำ
มันละทิ้งการสร้างสรรค์ข้อความแบบอิสระ เพื่อมุ่งเน้นความเชี่ยวชาญในการตัดสินที่มีขอบเขตคำตอบชัดเจน ตัวอย่างเช่น ถ้าคุณให้ตัวเลือกสี่ข้อ—"พอใจ", "ไม่พอใจ", "ผสมผสาน", "ไม่ระบุ"—มันจะเลือกหนึ่งข้อและให้ความน่าจะเป็นของแต่ละตัวเลือก
เหมือนที่ QR Code มีเครื่องมือเฉพาะทาง งานที่ต้องการเพียงการเลือกและให้คะแนนก็สามารถจัดการได้ด้วยโมเดลเฉพาะทาง ตามข้อมูลทางการ การปรับแต่งของ Jev สำหรับงานตัดสินเหล่านี้ช่วยลดเวลาตอบสนองและต้นทุนการเรียกใช้งาน
ตัวอย่างเช่น การกรองคอมเมนต์อีคอมเมิร์ซจำนวนมหาศาลในแต่ละวัน ต้องมีการตัดสินอารมณ์ ความเร่งด่วน และวิธีการจัดการ การตัดสินที่เร็วและถูกกว่าช่วยลดเวลารอคอยรวมและต้นทุน โปรแกรมจะได้รับผลลัพธ์และดำเนินการต่อด้วยการจัดหมวดหมู่หรือส่งต่อให้มนุษย์
จุดกำเนิดของ Jev
ใครเป็นผู้สร้าง Jev? ทำไมต้องสร้างโมเดลสำหรับการตัดสินเท่านั้น?
Jev มาจาก TypeSafe AI ก่อตั้งโดย Diogo Almeida ซึ่งเคยทำงานวิจัยด้านโมเดลแชทที่ OpenAI มาก่อน
เขาโฟกัสไปที่ปัญหาหนึ่ง: AI เก่งเรื่องการคุย แต่ทำไมการนำความสามารถเหล่านี้ไปบูรณาการเข้ากับซอฟต์แวร์เพื่อทำงานอัตโนมัติถึงไม่ใช่เรื่องง่าย?
ซอฟต์แวร์เก่งเรื่องการปฏิบัติตามกฎเกณฑ์ที่ชัดเจน ถ้าเข้าเงื่อนไข A ให้ทำ B แต่การตัดสินใจในโลกจริงหลายอย่างยากที่จะกำหนดกฎล่วงหน้า
เหมือนการอ่านคอมเมนต์ คำพูดแบบไหนคือการบ่น? แบบไหนคือการล้อเล่น? แบบไหนดูเหมือนบวกแต่แฝงคำวิจารณ์? ยากที่จะครอบคลุมรูปแบบการพูดของผู้ใช้ทั้งหมดด้วยกฎเพียงไม่กี่ข้อ
TypeSafe ต้องการทำให้การตัดสินเชิงความหมายกลายเป็นส่วนประกอบที่เรียกใช้ได้ เมื่อโปรแกรมต้องทำความเข้าใจข้อความหรือเลือกขั้นตอนถัดไป มันจะมอบหมายงานย่อยนี้ให้โมเดล รับผลลัพธ์ แล้วดำเนินการต่อ
พวกเขาเรียกโมเดลเหล่านี้ว่า System One โดยยืมแนวคิดมาจากหนังสือ Thinking, Fast and Slow (คิดเร็ว คิดช้า) นึกถึงมันว่าเป็นส่วนของการตัดสินที่รวดเร็วและเป็นสัญชาตญาณ
ชื่อ Jev มาจากนักเศรษฐศาสตร์ Jevons ทีมงานมีความคาดหวังตรงไปตรงมา: ยิ่งต้นทุนของการเรียกใช้ความฉลาดต่ำลงเท่าไหร่ คนก็จะยิ่งนำไปใช้ในหลายสถานที่มากขึ้นเท่านั้น
บางขั้นตอนที่เคยรู้สึกว่าแพงเกินไปสำหรับการเรียก AI เพียงครั้งเดียว หากการตัดสินนั้นเร็วและถูกพอ ก็คุ้มค่าที่จะพิจารณาใหม่
Jev ต่างจาก LLM อย่างไร?
การทำให้ซอฟต์แวร์เรียกใช้ AI สำหรับการตัดสินถูกลงและง่ายขึ้นเป็นจุดเริ่มต้นที่ดี แต่ LLM ที่มีอยู่ก็ตัดสินและส่งผลลัพธ์ที่มีโครงสร้างได้เช่นกัน ทำไมต้องสร้าง Jev?
ก่อนอื่น เรามาดูกันว่า LLM ส่งผลลัพธ์การตัดสินให้โปรแกรมอย่างไร
LLMs รองรับ Output แบบมีโครงสร้าง (Structured Output) ซึ่งหมายความว่าคำตอบจะอยู่ในช่องที่กำหนดไว้ล่วงหน้า เช่น ช่องหนึ่งสำหรับอารมณ์ อีกช่องสำหรับความเร่งด่วน อีกช่องสำหรับวิธีการจัดการ โปรแกรมจะรู้ว่าแต่ละตำแหน่งหมายถึงอะไร
คุณอาจรู้จัก JSON ซึ่งเป็นรูปแบบทั่วไปสำหรับข้อมูลที่มีโครงสร้าง นักพัฒนาสามารถจำกัด Output ของ LLM ให้ปฏิบัติตามรูปแบบเฉพาะได้
ดังนั้น หากดูแค่ว่าผลลัพธ์สุดท้ายเป็นข้อความหรือ JSON อาจไม่เห็นความแตกต่างหลักระหว่าง Jev กับ LLM
ความแตกต่างอยู่ที่วิธีที่โมเดลสร้างผลลัพธ์
Generative LLMs มาตรฐานมักสร้างคำตอบทีละ Token Tokens คือชิ้นส่วนเล็กๆ ของข้อความที่โมเดลประมวลผล แม้ว่าคุณจะขอข้อมูลที่รูปแบบตายตัว มันมักจะสร้างผลลัพธ์ออกมาทีละขั้น
Jev ใช้วิธีการ Output เฉพาะทางสำหรับงานตัดสิน โดยให้การตัดสินหลายรายการและความน่าจะเป็นแบบขนาน คุณสามารถถามหลายคำถามเกี่ยวกับคอมเมนต์เดียวกันและรับผลลัพธ์ทั้งหมดได้ในคำขอเดียว
ความแตกต่างของ Output นี้เกี่ยวข้องกับความเร็วและต้นทุนที่กล่าวถึงข้างต้น ซอฟต์แวร์ที่ประมวลผลข้อมูลมหาศาลในแต่ละวันมีต้นทุนสูงแม้จะเป็นขั้นตอนเล็กๆ Agents ซึ่งเรียกใช้เครื่องมือและทำงานต่อเนื่อง ต้องตัดสินใจซ้ำๆ ว่าขั้นตอนถัดไปคืออะไร ความเร็วในการตอบสนองและต้นทุนการเรียกใช้ส่งผลโดยตรงต่อการออกแบบซอฟต์แวร์ ค่าใช้จ่ายในการดำเนินงาน และประสบการณ์ผู้ใช้ บางขั้นตอนที่เคยข้ามไปเพราะช้าหรือแพง ตอนนี้สามารถใส่การตัดสินด้วย AI เข้าไปได้แล้ว
นอกจากนี้ยังมีความเสถียรของ Output เรายิงชุดตัวเลือกเข้าไป และมันจะส่งผลลัพธ์ภายในขอบเขตนั้น ซึ่งช่วยให้โปรแกรมปลายทางประมวลผลได้ง่าย
3 คุณสมบัติใหม่ของ Jev
หัวใจของ Jev อยู่ที่คุณสมบัติใหม่ 3 อย่าง ตรรกะการออกแบบของมันน่าสนใจและควรค่าแก่การศึกษา
สรุปสั้นๆ คือ Choice ใช้สำหรับการเลือกจากตัวเลือกที่ให้มา; Score ใช้สำหรับการให้คะแนนตามเกณฑ์; Noul ใช้สำหรับการตัดสินความน่าจะเป็นที่ประโยคจะเป็นจริง
ที่นี่ ผมจะใช้ Playground อย่างเป็นทางการสาธิตคุณสมบัติเหล่านี้ด้วยตัวอย่างจริง
ลองใช้กรณีการจัดการคอมเมนต์อีคอมเมิร์ซ สมมติว่าคุณเป็นเจ้าของร้านออนไลน์ที่ได้รับรีวิวจากลูกค้าทุกวัน คุณต้องวัดระดับความพึงพอใจ ระบุปัญหาที่ต้องติดตาม กำหนดวิธีการจัดการ และจัดลำดับความสำคัญของเคสด่วน
เราจะส่งคอมเมนต์นี้ไปยัง Jev:
"สินค้าดี แต่จัดส่งนานสิบวัน และฝ่ายบริการลูกค้าไม่ตอบกลับ"
เราจะใช้ทั้งสามคุณสมบัติเพื่อตัดสินคอมเมนต์นี้และดูผลลัพธ์
Choice: การเลือกตัวเลือก
ก่อนอื่น ถามว่า: อารมณ์โดยรวมคืออะไร?
ตัวเลือกที่ให้: พอใจ, ไม่พอใจ, ผสมผสาน, ไม่ระบุ
ผลลัพธ์: "ผสมผสาน"
เข้าใจง่าย ผู้ใช้ชมสินค้าแต่บ่นเรื่องโลจิสติกส์และบริการ การเลือกแค่ "พอใจ" หรือ "ไม่พอใจ" จะสูญเสียความหมายบางส่วนไป
ในทำนองเดียวกัน เราสามารถถามว่า: ควรจัดการคอมเมนต์นี้อย่างไรต่อไป?
ตัวเลือก: "ส่งต่อให้มนุษย์", "ตอบกลับอัตโนมัติ", "ไม่ต้องตอบกลับ" เพิ่มกฎ: ข้อร้องเรียนบริการที่ยังไม่แก้ไขต้องให้มนุษย์ติดตาม
ผลลัพธ์: "ส่งต่อให้มนุษย์"
สังเกตว่า เนื้อหาของคำถามแบบเลือกตอบสามารถเปลี่ยนแปลงได้ อารมณ์ แผนก การกระทำถัดไป—ทั้งหมดสามารถวางในรูปแบบนี้ได้ ตัวเลือกถูกกำหนดโดยเรา; Jev ตัดสินจากข้อมูลและข้อกำหนด
Score: การให้คะแนน
ต่อมา ถามว่า: คอมเมนต์นี้เร่งด่วนแค่ไหน? ต้องติดตามเร็วเพียงใด?
ก่อนให้คะแนน กำหนดมาตรฐาน ตั้งไว้ 3 ระดับ:
- 0: รีวิวทั่วไปหรือสอบถามง่ายๆ ไม่มีข้อร้องเรียนที่ยังไม่แก้ไข
- 1: ข้อร้องเรียนด้านโลจิสติกส์หรือบริการที่ยังไม่แก้ไข แต่ไม่มีปัญหาด้านความปลอดภัย ความเสียหายใหญ่หลวง หรือเส้นตายที่กระชั้นชิด
- 2: ปัญหาด้านความปลอดภัยที่ชัดเจน ความเสียหายใหญ่หลวง หรือเส้นตายที่กระชั้นชิด
Jev คืนค่า 1 บ่งบอกถึงความเร่งด่วนปานกลางตามมาตรฐานนี้
คะแนนขึ้นอยู่กับมาตรฐานที่คุณกำหนดอย่างมาก คุณสามารถเปลี่ยนไปประเมินคุณภาพการตอบกลับหรือความเกี่ยวข้อง แต่คุณต้องนิยามว่าอะไรคือดีหรือไม่ดี
มันยังสามารถคืนค่าคะแนนเป็นทศนิยมระหว่างระดับ ไม่ใช่แค่จำนวนเต็ม
Noul: การตัดสินความจริงของประโยค
สุดท้าย ให้ประโยคแก่โมเดล:
"ผู้ใช้ขอเงินคืนอย่างชัดเจนในคอมเมนต์"
ประเภทนี้จะคืนค่าความน่าจะเป็นระหว่าง 0 ถึง 1 แสดงถึงโอกาสที่ประโยคนั้นจะเป็นจริง
ผลลัพธ์: 0.03 (3%)
ผู้ใช้ไม่พอใจ แต่ไม่ได้ขอเงินคืนอย่างชัดเจน ดังนั้น โมเดลจึงให้ความน่าจะเป็นต่ำต่อ "การขอเงินคืนอย่างชัดเจน"
เมื่อมองผลลัพธ์ทั้งหมดร่วมกัน ภาพรวมจะชัดเจนขึ้น:
คำถามสี่ข้อนี้ถูกส่งพร้อมกัน ได้ผลลัพธ์ทั้งหมดในครั้งเดียว API รายงานเวลาการประเมินของโมเดลประมาณ 85 มิลลิวินาที
ตอนนี้ โปรแกรมมีข้อมูลที่ใช้งานได้: หมวดหมู่ความรู้สึก เป้าหมายการจัดเส้นทาง ระดับความสำคัญ และความตั้งใจขอเงินคืน สามารถดำเนินการต่อได้ตามผลลัพธ์เหล่านี้
Jev ใช้ทำอะไรได้บ้าง?
เราประมวลผลคอมเมนต์หนึ่งฉบับ บนแพลตฟอร์มอีคอมเมิร์ซที่มีปริมาณมหาศาลต่อวัน การใช้งานนี้ขยายออกไปได้อีก
ประการแรก สถิติ
ผู้ใช้คนไหนพอใจ? ใครบ่นเรื่องโลจิสติกส์? ปัญหาไหนต้องให้ฝ่ายบริการลูกค้าดูแล? โมเดลตัดสินความหมาย; โปรแกรมรวบรวมจำนวนและแสดงหมวดหมู่
ประการที่สอง การกรองเบื้องต้นเพื่อตัดสินใจว่าอะไรต้องประมวลผลลึกขึ้น
รีวิวทั่วไปเข้าสู่สถิติ รายการที่ไม่ต้องตอบกลับข้ามการตอบรายบุคคล ปัญหาที่ยังไม่แก้ไขส่งให้มนุษย์ การตอบกลับอัตโนมัติที่เหมาะสมกับการสร้างโดย LLM จะถูกส่งต่อให้โมเดลที่ใหญ่กว่าพร้อมบริบท
ก่อนหน้านี้ การให้ LLM ทั่วไปราคาแพงคัดกรองทุกอย่างตั้งแต่แรกมีต้นทุนเริ่มต้นสูง ตอนนี้ Jev ดูแลการคัดกรองด่านหน้า ทิ้งการประมวลผลเชิงลึกไว้ให้ LLMs
การใช้ Keyword Filtering ได้ไหม?
ได้บางส่วน แต่ Keywords พลาดบริบท
ตัวอย่าง:
"คุณภาพเยี่ยมมากเลย พังในวันเดียว"
การจับคู่คำว่า "คุณภาพเยี่ยม" อาจจำแนกผิดว่าเป็นเชิงบวก การอ่านทั้งประโยคเผยให้เห็นความประชดประชัน
Jev ยังคงรับ Input เป็นภาษาธรรมชาติและเข้าใจความหมายเต็มรูปแบบ ความเชี่ยวชาญของมันอยู่ที่ประเภทงานและรูปแบบ Output ไม่ใช่แค่การจับคู่ Keywords
การเปลี่ยนผลลัพธ์เป็นการกระทำต้องใช้โปรแกรมภายนอก
คืนค่า "ส่งต่อให้มนุษย์" โปรแกรมจะเข้าคิวเพื่อการตรวจสอบด้วยมือ คืนค่า "ตอบกลับอัตโนมัติ" โปรแกรมจะเรียก LLM เพื่อสร้างคำตอบ การกระทำถูกดำเนินการโดยกฎเวิร์กโฟลว์และเครื่องมือ
ใน Agents ระบบภายนอกที่จัดระเบียบการเรียกโมเดล เครื่องมือ และเวิร์กโฟลว์ มักเรียกว่า Harness Jev เหมาะกับตำแหน่งการตัดสินภายใน Harness ช่วยเลือกขั้นตอนถัดไป
ดังนั้น ผมเชื่อว่า Jev และ LLMs เสริมกัน ไม่ได้ขัดแย้งกัน
โดยเฉพาะอย่างยิ่ง ใช้ Jev แทน LLMs สำหรับการจำแนกประเภทและให้คะแนน จากนั้น สำหรับการเขียนคำโปรย โค้ด หรือการให้เหตุผลหลายขั้นตอนที่ซับซ้อน ให้พึ่งพา LLMs
ด้วยวิธีนี้ ระบบสามารถใช้โมเดลต่างกันสำหรับแต่ละขั้นตอน รวมความสามารถได้อย่างลงตัว
ทดลองใช้ Jev อย่างไร?
วิธีที่ตรงที่สุดคือเปิด TypeSafe Playground
ล็อกอิน วางข้อความที่ต้องการวิเคราะห์ใน State (ข้อมูลสำหรับการตัดสิน) ตั้งคำถามใน Questions เลือกประเภทการตัดสิน กรอกตัวเลือกหรือเกณฑ์การให้คะแนน คลิก Run เพื่อดูผลลัพธ์
ลองใช้คอมเมนต์ก่อนหน้าหรือสลับเป็นรีวิวเชิงบวกเพื่อดูการเปลี่ยนแปลง
หากต้องการบูรณาการเข้ากับซอฟต์แวร์ของคุณ ให้ใช้ API
API ช่วยให้ซอฟต์แวร์หนึ่งเปิดเผยความสามารถให้อีกซอฟต์แวร์หนึ่ง รับ API Key จากคอนโซล โปรแกรมของคุณส่งข้อมูลและคำถามพร้อมสิทธิ์นี้ รับผลลัพธ์ และดำเนินการตรรกะถัดไป
มี Official SDKs ให้ด้วย ห่อหุ้มฟังก์ชันอินเทอร์เฟซทั่วไปเพื่อความสะดวกของนักพัฒนา
ราคา: $0.042 ต่อล้าน Input Tokens, Output ฟรี Input รวมถึงข้อมูล คำถาม และเกณฑ์ การกรองคอมเมนต์ปริมาณมากสามารถใช้โมเดลจ่ายตามการเรียกใช้นี้ในเวิร์กโฟลว์ที่มีอยู่
อนาคตของโมเดลตัดสินเฉพาะทาง
หลังจากศึกษา Jev ผมรู้สึกประทับใจ: ควรมีใครทำสิ่งนี้นานแล้ว แต่ไม่มีใครทำ
ผมคิดว่าแนวทางนี้ถูกต้อง ในขณะที่ทุกคนแข่งกันเพิ่มประสิทธิภาพโมเดลขนาดใหญ่ TypeSafe AI เปิดสนามใหม่ สร้างโมเดลปรับแต่งเองสำหรับสถานการณ์ข้อมูลที่มีโครงสร้าง การตัดสินเชิงความน่าจะเป็น การเลือก และการตัดสินใจ
ประโยชน์ด้านต้นทุนและความเร็วเป็นมิตรกับ Agents การรอโมเดลขนาดใหญ่ตอบช้าๆ ไม่เกิดประสิทธิภาพในบางบริบท
ผมเชื่อว่าผู้ให้บริการรายอื่นน่าจะเดินตามเทรนด์นี้ สร้างโมเดลเฉพาะทางสำหรับขั้นตอนการตัดสินของ Agents
Agent สามารถมีโมเดลสำหรับการตัดสินอย่างรวดเร็ว โมเดลอื่นสำหรับการคิด/เขียน/โค้ดที่ซับซ้อน รวมถึงโมเดลรูปภาพ/เสียง/วิดีโอ ทำงานร่วมกัน
เมื่อการตัดสินเร็วและถูกพอ เราสามารถวาง AI ไว้ในหลายจุดที่เคยคิดว่าไม่คุ้มที่จะเรียกใช้ สำหรับผม นี่คือส่วนที่น่าตื่นเต้นที่สุดในทิศทางของ Jev
