Skip to main content
AI & Technology

Jev ช่วยคัดแยกงานก่อนเข้า Odoo ได้อย่างไร และงานไหนยังต้องให้คนตรวจ

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

21 ก.ย. 202610 นาทีTypeSafe AI / Vercel AI Gateway
JevTypeSafe AIOdooERPAI ClassificationHuman Review

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

ถ้าโยนทุกอย่างให้โมเดลเดียว โมเดลจะถูกขอให้ทำทั้งงานภาษาและงานควบคุมระบบในครั้งเดียว ทางเลือกที่ปลอดภัยกว่าคือให้ AI ตอบเฉพาะคำถามเชิงความหมาย แล้วให้โค้ด Odoo และคนรับผิดชอบตัดสินตามสถานะจริง

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

บทความนี้เสนอขั้นตอนการทำงานสำหรับทดลอง แนวทางนี้ยังไม่ใช่กรณีใช้งาน Jev ในโครงการลูกค้าของ Enersys

แยกความหมายออกจากอำนาจเปลี่ยนข้อมูล

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

  • ข้อความนี้อยู่ในกลุ่มเปลี่ยนที่อยู่ ติดตามพัสดุ ยกเลิกคำสั่งซื้อ หรือเรื่องอื่น
  • ระดับความเร่งด่วนตามเกณฑ์ที่ทีมกำหนดอยู่ระดับใด
  • ข้อความมีเงื่อนไขที่ต้องตรวจสถานะก่อนตอบหรือไม่

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

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

Choice, Score และ Noul ใช้คนละงาน

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

Choice เลือกหนึ่งคำตอบจากตัวเลือกที่กำหนด เหมาะกับการเลือกคิว เช่น change_address, track_delivery, cancel_order, other ผลลัพธ์มีตัวเลือกที่เลือก การกระจายความน่าจะเป็น และค่า confidence

Score ให้ระดับตามเกณฑ์ที่เรียงลำดับ เหมาะกับการแบ่งความเร่งด่วนตั้งแต่ “รอตามรอบได้” ถึง “ต้องตรวจก่อนตัดรอบขนส่ง” แต่ละระดับต้องมีคำอธิบายที่คนหน้างานเข้าใจตรงกัน ไม่ควรใช้ Score เพื่อคำนวณจำนวนเงิน ส่วนลด หรือจำนวนสินค้า

Noul ตอบคำถามใช่หรือไม่ใช่เป็นค่าระหว่าง 0 ถึง 1 เช่น “ข้อความนี้มีเงื่อนไขขึ้นกับสถานะจัดส่งหรือไม่” Noul ไม่มีฟิลด์ confidence แยกต่างหาก จึงไม่ควรนำเกณฑ์ของ Choice ไปใช้กับ Noul โดยตรง

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

Confidence ช่วยจัดคิว ไม่ได้ยืนยันว่ารายการหนึ่งถูก

สำหรับ Choice และ Score ค่า confidence คำนวณจากรูปทรงของการกระจายความน่าจะเป็น หากน้ำหนักกระจุกที่คำตอบเดียว ค่าจะสูงกว่าเมื่อหลายคำตอบใกล้กัน TypeSafe อธิบายวิธีอ่านค่านี้ เพื่อให้โค้ดเลือกว่าจะทำต่อ ขอข้อมูลเพิ่ม หรือส่งให้คนตรวจ

การปรับเทียบ (calibration) อธิบายพฤติกรรมของกลุ่มคำตอบจำนวนมาก ไม่ได้ค้ำประกันว่ารายการที่ confidence 0.9 รายการหนึ่งจะถูกแน่นอน AI primer ของ TypeSafe ระบุขอบเขตนี้ไว้โดยตรง

ดังนั้นทีมไม่ควรคัดลอกเกณฑ์ตัดสิน (threshold) จากตัวอย่างในเอกสารมาใช้กับงานจริง เกณฑ์ของคิว “ติดตามพัสดุ” อาจผ่อนกว่างาน “แก้ที่อยู่หลังออกใบส่งของ” เพราะต้นทุนเมื่อส่งผิดคิวต่างกัน และเกณฑ์ของข้อความภาษาไทยต้องมาจากผลทดสอบภาษาไทยขององค์กรเอง

งานที่ยังควรอยู่ในโค้ดและ Odoo

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

งานต่อไปนี้ควรใช้กติกาที่ทดสอบได้ในโค้ดหรือค่าจาก Odoo

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

Jev ยังรับข้อมูลเป็น text เท่านั้นตาม หน้ารุ่นโมเดล หากลูกค้าส่งภาพฉลาก เสียง หรือ PDF ต้องมีขั้นตอนแปลงเป็นข้อความก่อน อาจใช้ OCR หรือโมเดลภาษาเมื่อจำเป็น แต่ถ้าข้อมูลต้นทางเป็นข้อความอยู่แล้ว ไม่ควรเพิ่มโมเดลอีกตัวโดยไม่มีเหตุผล

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

โครงการทดลองที่เล็กพอจะรู้ว่าควรไปต่อหรือไม่

โจทย์เริ่มต้นที่เหมาะคือ “คัดข้อความหลังการขายเข้าคิว” เท่านั้น ยังไม่ให้ Jev แก้ข้อมูล อนุมัติคืนเงิน หรือเปลี่ยนสถานะเอกสารใน Odoo

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

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

เปรียบเทียบอย่างน้อย 3 ทางบนข้อมูลเดียวกัน

  1. กติกาคำค้นหรือรูปแบบข้อความที่ทีมดูแลเอง
  2. โมเดลภาษาขนาดเล็กที่คืนหมวดตามรูปแบบเดียวกัน
  3. Jev ที่ใช้ Choice, Score หรือ Noul เท่าที่โจทย์ต้องการ

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

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

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

การเชื่อมต่อและข้อมูลที่ต้องตกลงก่อนทดลอง

ทีมที่ใช้ Vercel AI SDK มีช่องทางเรียก Jev ผ่านฟังก์ชัน experimental_evaluate และโมเดล typesafe-ai/jev ตาม เอกสาร AI Gateway คำว่า experimental หมายความว่าทีมควรล็อกรุ่น ทดสอบการเปลี่ยนแปลง และเตรียมทางย้อนกลับ ไม่ควรผูก workflow สำคัญกับพฤติกรรมที่ยังไม่ได้ตรวจในระบบของตน

ด้านข้อมูล นโยบายความเป็นส่วนตัวของ TypeSafe ระบุว่าบริการอยู่บนโครงสร้างพื้นฐานในสหรัฐอเมริกา เก็บข้อมูลที่ผู้ใช้ส่งเข้าไป ไม่ใช้ข้อมูลดังกล่าวฝึกหรือปรับแต่งโมเดล และเก็บข้อมูลส่วนบุคคลเท่าที่จำเป็นต่อบริการหรือวัตถุประสงค์ทางธุรกิจของผู้ให้บริการ ส่วน หน้า Legal ระบุว่าบริการไม่เก็บข้อมูลเลย (zero data retention) มีสำหรับลูกค้าองค์กร จึงไม่ควรสมมติว่าเปิดเป็นค่าปริยาย การวาง Odoo บน cloud ในไทยไม่ได้ทำให้ข้อมูลที่ส่งต่อไปยัง Jev อยู่ในประเทศไทยตามไปด้วย

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

Enersys เคยทำงานเชื่อม Odoo กับข้อมูลจาก Shopee และ TikTok และเคยทำโครงการ Odoo ในธุรกิจการผลิตที่ครอบคลุมผู้ใช้ 156 คนพร้อมการเชื่อม MES ประสบการณ์เหล่านี้ทำให้เห็นว่ารายการผิดปกติ เจ้าของข้อมูล และจุดส่งต่อสำคัญกว่าการเลือกโมเดลเพียงอย่างเดียว แต่ไม่ได้หมายความว่า Jev ถูกใช้ในโครงการดังกล่าว

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

แหล่งข้อมูลหลัก

อ่านแนวทางเชื่อม Shopee และ TikTok เข้า Odoo

อ่านบทเรียนการเตรียม Odoo สำหรับผู้ใช้ 156 คนและ MES

คุยกับทีม Enersys เรื่อง workflow สำหรับ Odoo และ AI

บทความที่เกี่ยวข้อง

AEO + SEO — คู่มือเอาตัวรอดเมื่อ AI กลืนกิน Google Search

Gartner ทำนาย Search Volume จะลด 25% ภายในปี 2026 และ 50% ภายในปี 2028 — Zero-click search พุ่ง 65% เว็บไซต์ที่ไม่ปรับตัวจะหายไปจากสายตาลูกค้า บทความนี้คือคู่มือฉบับสมบูรณ์สำหรับธุรกิจไทย

AEO vs GEO — เจาะลึกสองกลยุทธ์ที่ตัดสินว่า AI จะ "เห็น" หรือ "ข้าม" เว็บไซต์คุณ

Web Mentions สัมพันธ์กับ AI Citations สูงกว่า Backlinks ถึง 3 เท่า, AI referral traffic โต 527% YoY, เว็บที่มี Schema มีโอกาสถูก AI อ้างอิงมากกว่า 2.5 เท่า — คู่มือเชิงลึก AEO vs GEO พร้อมวิธีตรวจสอบและปรับเว็บไซต์

Agentic AI ในองค์กร — จาก 5% สู่ 40% ภายในปี 2026: โอกาสและความเสี่ยงที่ผู้บริหารต้องรู้

ตลาด Agentic AI โตจาก $1B สู่ $9B+ ใน 2 ปี Gartner คาด 40% ของแอปองค์กรจะมี AI Agent ภายในสิ้นปี 2026 แต่กว่า 40% ของโปรเจกต์อาจถูกยกเลิก — บทความนี้วิเคราะห์โอกาส ความเสี่ยง และกลยุทธ์สำหรับองค์กรไทย

"Empowering Innovation,
Transforming Futures."

บอกเราว่างานส่วนไหนที่คุณต้องการปรับ