ใบแจ้งหนี้ระบุยอดรวม 10,700 บาท ระบบอ่านตัวเลขได้ตรง แต่เลขเอกสารเดียวกันเคยถูกบันทึกแล้ว หากนำยอดที่อ่านได้ไปตั้งเจ้าหนี้ทันที ความถูกต้องของการอ่านก็ยังทำให้เกิดรายการซ้ำได้
Cloudflare ประกาศ Clairic เมื่อ 19 ตุลาคม 2569 และเปิดให้ใช้แบบ preview บน Workers AI โมเดลนี้รับข้อมูลกับนิยามช่องที่ต้องการ แล้วคืนค่าเป็นชนิดข้อมูลที่กำหนด เช่น ข้อความ ตัวเลข หรือวันที่ สำหรับทีมบัญชี คำถามที่ควรเริ่มต้นคือจะให้โมเดลอ่านอะไร และจะหยุดรายการไว้ตรงไหนก่อนกระทบสมุดบัญชี อ่านประกาศ Cloudflare
บทความนี้ตรวจข้อมูล ณ วันที่ 21 ตุลาคม 2569 เสนอแนวทางประเมินด้วยเอกสารสมมติ ไม่ใช่รายงานว่า Enersys นำ Clairic ไปใช้แล้ว เอกสารที่อ้างอิงยังไม่ยืนยันความแม่นยำกับใบแจ้งหนี้ภาษาไทย ความถูกต้องด้านภาษีไทย หรือความพร้อมใช้งานจริงในองค์กร
เริ่มจากใบแจ้งหนี้หนึ่งใบที่ตรวจย้อนกลับได้
สมมติฝ่ายบัญชีได้รับใบแจ้งหนี้ INV-1021 จากผู้ขาย ก ระบุวันที่ 21 ตุลาคม 2569 อ้างอิงใบสั่งซื้อ PO-0042 มีสินค้า 10 ชิ้น ราคาชิ้นละ 1,000 บาท ยอดก่อนภาษี 10,000 บาท ภาษีที่พิมพ์ไว้ 700 บาท และยอดรวม 10,700 บาท วันที่ครบกำหนดบนเอกสารคือ 20 พฤศจิกายน 2569 ตัวเลขและภาษีนี้มีไว้สาธิตการตรวจยอด ไม่ใช่คำวินิจฉัยอัตราภาษีหรือสิทธิทางภาษีของธุรกรรมจริง
ภาพอธิบายจัดทำโดย Enersys จากกรณีสมมติในบทความ ไม่ใช่เอกสารลูกค้า หน้าจอผลิตภัณฑ์ หรือผลทดสอบ Clairic ยอดภาษีใช้สาธิตการตรวจเลขเท่านั้น
เก็บเอกสารต้นฉบับไว้กับรายการร่าง และให้ค่าที่ดึงได้ชี้กลับไปยังหลักฐานที่เจ้าหน้าที่เปิดดูได้ การรับไฟล์ การอ่านตัวอักษร และการดึงข้อมูลต้องแยกประเมิน เพราะภาพที่เอียง ตัวอักษรไม่ชัด หรือข้อความที่แปลงผิด อาจส่งความผิดพลาดต่อไปทุกขั้น
เอกสารโมเดลระบุว่ารับข้อความและภาพได้ และมีตัวอย่างข้อมูลข้อความจากใบแจ้งหนี้ที่ดึงเลขเอกสาร คำนวณวันครบกำหนด และคืนค่าเลข PO เป็น null เมื่อไม่พบข้อมูล นี่เป็นตัวอย่างการใช้งานของผู้พัฒนาโมเดล ยังไม่ใช่ผลรับรองว่าอ่านรูปแบบเอกสารของบริษัทเราได้ ดูข้อมูลโมเดลและตัวอย่างใบแจ้งหนี้
Clairic ต่างจากการขอให้แชตบอตอ่านเอกสารอย่างไร
ถ้าขอให้แชตบอต “ช่วยอ่านใบแจ้งหนี้นี้” คำตอบอาจมาเป็นย่อหน้าที่โปรแกรมต้องแยกข้อมูลอีกครั้ง แนวทางของ Clairic คือให้แอปพลิเคชันระบุช่องที่ต้องการและชนิดของคำตอบตั้งแต่ต้น เช่น เลขเอกสารเป็นข้อความ ยอดรวมเป็นตัวเลข และวันครบกำหนดเป็นวันที่ แล้วรับคำตอบแยกตามช่อง โมเดลจึงมีงานชัดเจนกว่าการเขียนคำอธิบายใบแจ้งหนี้ทั้งใบ
Cloudflare อธิบายว่า Clairic ประมวลผลครั้งเดียวโดยไม่สร้างโทเค็นคำตอบแบบ LLM และอาจคืน null เมื่อหาคำตอบไม่พบ พร้อมข้อมูลความมั่นใจ จุดที่ทีมทำระบบควรสนใจคือจะนำค่ากับความไม่แน่นอนเหล่านี้ไปจัดการต่ออย่างไร ชนิดข้อมูลที่ถูกต้องช่วยให้โปรแกรมรับค่าได้ แต่ยังต้องตรวจว่าค่านั้นตรงกับเอกสารหรือไม่ วิธีทำงานของโมเดลในประกาศ Cloudflare
กำหนดช่องให้ตรงกับข้อความบนเอกสาร
ในรอบประเมิน ควรขอให้ Clairic ดึงชื่อผู้ขาย เลขใบแจ้งหนี้ วันที่ออกเอกสาร เลข PO สกุลเงิน วันครบกำหนดที่พิมพ์ไว้ ยอดก่อนภาษี ยอดภาษี และยอดรวม แยกยอดแต่ละชนิดออกจากกัน อย่าใช้ช่องเดียวชื่อว่า “amount” แล้วปล่อยให้โมเดลตีความเอง
เลขใบแจ้งหนี้และเลขประจำตัวผู้เสียภาษีควรเก็บเป็นข้อความ เพื่อรักษาเลขศูนย์ด้านหน้า วันที่ต้องกำหนดวิธีแปลงปี พ.ศ. และ ค.ศ. ส่วนจำนวนเงินต้องแยกสกุลเงินและหน่วยให้ชัด การออกแบบช่องเหล่านี้เป็นข้อเสนอสำหรับการทดสอบ ไม่ใช่การยืนยันว่า Clairic รองรับแบบเอกสารไทยทุกชนิด
ถ้าไม่พบเลข PO ให้คงสถานะไม่พบข้อมูล แล้วส่งให้คนค้นหลักฐาน การคาดเดาเลขขึ้นมาเพื่อให้แบบฟอร์มครบทำให้รายการร่างดูน่าเชื่อถือเกินจริง เอกสาร Cloudflare แยกการดึงค่าที่มีอยู่ การคำนวณค่าจากข้อมูล และการประมาณค่าที่ยังไม่ทราบออกจากกัน จึงไม่ควรนำค่าประมาณ เช่น วันที่คาดว่าจะจ่าย มาแทนวันครบกำหนดตามเอกสาร หลักการ extraction และข้อจำกัด
ให้โปรแกรมตรวจยอดและกฎที่ตกลงไว้
สำหรับใบนี้ โปรแกรมควรคำนวณ 10 × 1,000 = 10,000 และ 10,000 + 700 = 10,700 ใหม่ด้วยการจัดการทศนิยมที่เหมาะกับเงิน แล้วเทียบกับค่าที่ดึงได้ หากยอดรวมถูกอ่านเป็น 10,100 บาท ต้องหยุดรายการเพื่อหาสาเหตุ ไม่แก้ตัวเลขเงียบ ๆ ให้สมการลงตัว
Cloudflare ระบุเองว่า Clairic รุ่นแรกยังมีข้อจำกัดเมื่อคำนวณหลายขั้นที่พึ่งพาผลจากขั้นก่อนหน้าและรวมข้อมูลหลายแถวในตาราง พร้อมแนะนำให้ใช้โค้ดคำนวณ การอ่านยอดรวมตรงจึงไม่ควรถูกใช้แทนการตรวจผลรวมของรายการสินค้า ข้อจำกัดในประกาศ preview
กฎที่กำหนดชัดควรตรวจผู้ขายกับทะเบียนที่อนุมัติ ตรวจเลขเอกสารซ้ำภายใต้ผู้ขายและบริษัทเดียวกัน ตรวจสกุลเงิน งวดที่เปิดรับรายการ และความต่างระหว่าง PO-0042 กับหลักฐานรับสินค้า ส่วนการตรวจภาษีต้องใช้กฎที่ฝ่ายบัญชีรับรองตามประเภทธุรกรรมและวันที่เกี่ยวข้อง ไม่ให้โมเดลเลือกอัตราจากตัวอย่าง 700 บาทเอง
การที่ยอดภาษีบวกกับยอดก่อนภาษีแล้วตรงยอดรวม พิสูจน์ได้เพียงความสอดคล้องทางเลขคณิต ยังไม่พิสูจน์ว่าใช้ประเภทภาษีถูก เอกสารถูกต้องตามกฎหมาย หรือมีสิทธิใช้ภาษีซื้อตามที่ตั้งใจ ประเด็นเหล่านี้ต้องอยู่ในขอบเขตตรวจของผู้รับผิดชอบบัญชีและภาษี
ลองเปลี่ยนข้อมูล แล้วดูว่ารายการหยุดตรงไหน
สมมติว่าอ่านข้อมูลจาก INV-1021 ได้ตรงทั้งหมด ผลที่ทีมอยากเห็นในรอบทดลองควรแสดงเหตุผลที่รายการเดินต่อหรือหยุด ไม่ใช่แสดงเพียงคำว่า “สำเร็จ” ตารางนี้เป็นผลที่คาดหวังจากกฎที่เสนอ ไม่ใช่คำตอบจากการเรียก Clairic จริง
| สิ่งที่พบในกรณีสมมติ |
สิ่งที่ระบบควรทำต่อ |
| อ่านยอดรวมได้ 10,700 บาท และคำนวณใหม่ตรง |
ผ่านเฉพาะการตรวจเลขคณิต ยังไม่อนุมัติบันทึก |
| ผู้ขายและเลข INV-1021 ตรงกับรายการที่มีอยู่ |
พักรายการร่าง พร้อมลิงก์เอกสารเดิมให้คนเปรียบเทียบ |
| ลบ PO-0042 ออกจากเอกสารทดสอบ |
คงค่าว่างหรือ null และส่งเข้าคิวค้นหลักฐาน ห้ามเติมเลขจากความคุ้นเคย |
| อ่านยอดรวมเป็น 10,100 บาท |
แจ้งยอดไม่ตรงและเปิดต้นฉบับให้ตรวจ ห้ามแก้เป็น 10,700 อัตโนมัติ |
กรณีที่สามมีประโยชน์มากในการทดสอบ เพราะทำให้เห็นว่าระบบรับมือกับข้อมูลที่ไม่มีอย่างไร การมีช่องว่างที่เห็นชัดช่วยให้คนตามงานต่อได้ ส่วนเลข PO ที่เดาขึ้นมาอาจพารายการไปผูกกับการซื้อผิดครั้ง
จุดที่ต้องให้คนตัดสินใจก่อนบันทึกบัญชี
เมื่อระบบพบ INV-1021 ซ้ำ เจ้าหน้าที่ต้องเปิดรายการเดิมกับเอกสารต้นฉบับเพื่อแยกว่าเป็นไฟล์ส่งซ้ำ เอกสารแก้ไข หรือคนละธุรกรรม แม้ทุกช่องมีคะแนนความมั่นใจสูงก็ยังตอบคำถามนี้จากตัวเลขเพียงอย่างเดียวไม่ได้
ผู้ตรวจยังต้องตัดสินเมื่อผู้ขายไม่ตรงทะเบียน ไม่มี PO รับสินค้าไม่ครบ มีการเปลี่ยนบัญชีธนาคาร หรือไม่ชัดว่าเป็นค่าใช้จ่ายหรือสินทรัพย์ ข้อความในใบแจ้งหนี้ที่สั่งให้เปลี่ยนผู้รับเงินหรือข้ามอนุมัติควรถูกมองเป็นเนื้อหาเอกสาร ไม่ใช่อำนาจสั่งระบบให้ทำตาม
คะแนน confidence และ p_null ใช้ช่วยจัดคิวข้อยกเว้นได้ แต่ต้องตรวจความหมายและความสัมพันธ์กับความผิดพลาดจากชุดทดสอบของเราเอง อย่าตั้งเกณฑ์อนุมัติจากคะแนนที่ดูสูงเพียงอย่างเดียว Cloudflare ระบุว่ารูปแบบคำตอบที่ถูกชนิดไม่ได้รับประกันความถูกต้อง และการกระทำที่มีผลสำคัญควรมีการตรวจข้ามหรือคนทบทวน คำแนะนำเรื่องความเสี่ยงและความไม่แน่นอน
ในการทดลองที่เสนอนี้ ผลลัพธ์หยุดที่รายการร่าง ผู้มีอำนาจตรวจหลักฐานและอนุมัติก่อนบันทึกบัญชี ส่วนการอนุมัติจ่ายเงินเป็นอีกสิทธิ์หนึ่ง ไม่ควรถูกรวมกับสิทธิ์อ่านเอกสาร เก็บค่าที่โมเดลส่งกลับ ผลตรวจ การแก้ไข ผู้อนุมัติ และเวลาที่ดำเนินการไว้ให้ตรวจย้อนหลังได้
ทดสอบกับความผิดพลาดที่ทีมยอมรับไม่ได้
เริ่มจากชุดเอกสารที่ได้รับอนุญาตให้ใช้ มีคำตอบอ้างอิงที่เจ้าหน้าที่ตรวจแล้ว และครอบคลุมรูปแบบที่ทีมพบจริง เช่น ภาษาไทยปนอังกฤษ ปี พ.ศ. เอกสารหลายหน้า ภาพไม่ชัด ส่วนลด เลข PO ที่หาย และไฟล์ส่งซ้ำ แยกเอกสารสำหรับปรับคำสั่งออกจากเอกสารวัดผล เพื่อไม่ให้ผลประเมินดีเพียงเพราะใช้ตัวอย่างเดิมซ้ำ
วัดความถูกต้องรายช่อง จำนวนรายการที่ถูกปล่อยผ่านทั้งที่ผิด จำนวนข้อยกเว้นที่คนต้องตรวจ และเวลาตั้งแต่รับเอกสารจนผู้ตรวจยอมรับรายการร่าง รวมต้นทุนการแปลงไฟล์ การแก้ข้อมูล และการตรวจคนด้วย ผลทดสอบของ Cloudflare กับงานอื่นไม่ใช่ผลของกระบวนการใบแจ้งหนี้ไทยนี้ จึงยังใช้สรุปผลประหยัดหรือความแม่นยำของเราไม่ได้
ก่อนส่งเอกสารจริงออกไปประมวลผล ให้ผู้รับผิดชอบตรวจสิทธิ์ใช้ข้อมูล เงื่อนไขบริการ การเก็บรักษา การเข้าถึง และที่ตั้งประมวลผลตามข้อกำหนดองค์กร เอกสารเปิดตัวโมเดลไม่ได้เป็นหลักฐานรับรอง PDPA หรือการเก็บข้อมูลในประเทศไทย การทดลองควรผ่านการอนุมัติขอบเขตข้อมูลก่อนเริ่ม
คำถามสำหรับประชุมบัญชีกับไอทีคือ หาก INV-1021 ผ่านการอ่านทุกช่อง แต่ซ้ำกับรายการเดิม ใครเป็นเจ้าของคิวตรวจ และหลักฐานอะไรทำให้อนุญาตบันทึกได้ เมื่อกำหนดคำตอบนี้แล้วจึงค่อยทดสอบว่า Clairic ช่วยเตรียมรายการร่างได้ดีพอหรือไม่
คำถามที่ทีมบัญชีมักต้องตอบ
Clairic รับประกันว่าอ่านใบแจ้งหนี้ไทยถูกหรือไม่
เอกสารที่ตรวจครั้งนี้ยังไม่ยืนยันความแม่นยำกับใบแจ้งหนี้ไทย ต้องประเมินกับเอกสารที่ได้รับอนุญาตและคำตอบอ้างอิงขององค์กรเอง สถานะบริการยังเป็น preview
อ่านยอดรวมถูกแล้วลง ERP ได้เลยหรือไม่
ในการทดลองที่เสนอ ยังต้องผ่านการตรวจยอด รายการซ้ำ ทะเบียนผู้ขาย หลักฐานซื้อและรับสินค้า รวมถึงการทบทวนบัญชีและภาษี ก่อนผู้มีอำนาจอนุมัติบันทึก
Enersys ใช้ Clairic ในระบบลูกค้าแล้วหรือยัง
บทความนี้เป็นการวิเคราะห์เอกสารสาธารณะและเสนอแนวทางประเมิน ไม่ได้ประกาศการติดตั้งหรือผลใช้งาน Clairic ของ Enersys
อ่านต่อ
