โปรแกรม OCR ด้วย AI: ทำงานเอกสารอัตโนมัติสำหรับทีมการเงินในไทย

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

ข้อแรกคือความสามารถในการรับมือกับเอกสารที่ไม่เคยเห็น OCR แบบดั้งเดิมต้องฝึกหรือตั้งค่าแยกตามเลย์เอาต์ของเอกสารแต่ละแบบ เพียงซัพพลายเออร์เปลี่ยนรูปแบบใบแจ้งหนี้ ระบบก็ใช้งานไม่ได้ ขณะที่ AI OCR ใช้โมเดลภาษาภาพ (Vision-Language Model หรือ VLM) อ่านหน้าเอกสารโดยตรง และรับข้อมูลประกอบเป็นภาษาพูดได้ เช่น "เอกสารประเภทนี้ เลขที่สัญญาขึ้นต้นด้วย HT-" จึงรับมือกับเลย์เอาต์ที่ไม่เคยผ่านการฝึกมาก่อนได้ ข้อที่สองคือ AI นำสิ่งที่อ่านได้ไปทำงานต่อ หากป้อนไฟล์ PDF หนึ่งไฟล์ที่มีภาพสแกนเช็คธนาคารเขียนด้วยลายมือ 48 ใบ ระบบจะคืนไฟล์ Excel หนึ่งไฟล์ที่แสดงเลขที่เช็ค จำนวนเงิน และวันที่ครบกำหนดของทั้ง 48 ใบ แม้แต่ละธนาคารจะวางเลย์เอาต์เช็คต่างกันก็ตาม ในขณะที่ OCR แบบดั้งเดิมจะคืนข้อความกระจัดกระจายมาให้ 48 หน้า

สำหรับทีมการเงินในประเทศไทย ความต่างนี้ชี้ขาดเรื่องเดียว คือผลลัพธ์ที่ได้จะเป็นข้อความที่ยังต้องมีคนมานั่งอ่านอีกรอบ หรือเป็นไฟล์ที่นำไปใช้งานและบันทึกเข้าระบบ ERP ได้ทันที Yangshu พัฒนาโซลูชัน AI OCR ให้กับองค์กรในประเทศไทย และในโครงการที่ผ่านมา ความต้องการนี้มักมาพร้อมกับงานบัญชีเจ้าหนี้ (AP) เสมอ เพราะเป็นจุดที่เอกสารกระดาษกองรวมกันมากที่สุดและมีการคีย์ข้อมูลด้วยมือหนาแน่นที่สุด บทความนี้เขียนสำหรับผู้จัดการฝ่ายการเงินและหัวหน้าฝ่ายบัญชี ครอบคลุมว่า AI OCR ทดแทนงานส่วนใดได้จริง เหตุใดเอกสารภาษาไทยจึงยากกว่าที่คิด ควรใช้เกณฑ์ใดในการเลือกโซลูชัน และข้อมูลที่อ่านได้จะเข้าสู่ระบบที่องค์กรใช้อยู่ได้อย่างไร

AI OCR คืออะไร และต่างจาก OCR แบบดั้งเดิมอย่างไร

ความต่างอยู่ที่สิ่งที่ได้ออกมา OCR แบบดั้งเดิมให้ผลลัพธ์เป็นข้อความ ส่วน AI OCR ให้ผลลัพธ์เป็นฟิลด์ข้อมูล

OCR แบบดั้งเดิม (Optical Character Recognition) ตอบคำถามเดียว คือกลุ่มพิกเซลนี้เป็นตัวอักษรใด ระบบเปลี่ยนไฟล์สแกนให้เป็นข้อความ แต่ไม่รับรู้โครงสร้างของข้อความนั้น หัวเรื่อง ตาราง หัวกระดาษ และตราประทับ ล้วนเป็นเพียงสายอักขระในสายตาของมัน ผลลัพธ์ที่ได้จึงมักเป็นข้อความยาวต่อเนื่องทั้งหน้า ตารางถูกยุบจนแถวเหลื่อมกัน และยังต้องมีคนอ่านอีกรอบก่อนจะบันทึกเข้าระบบได้

AI OCR เพิ่มขึ้นมาอีกสามชั้น

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

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

หากต้องการทำความเข้าใจหลักการเบื้องหลังโมเดลเหล่านี้ก่อน อ่านได้ที่บทความAI ในวันนี้คืออะไรกันแน่

เหตุใดองค์กรไทยจึงต้องการ AI OCR ในเวลานี้

เพราะในประเทศไทย เอกสารกระดาษและ PDF จะยังไม่หายไปในอีกหลายปีข้างหน้า เนื่องจากใบกำกับภาษีอิเล็กทรอนิกส์ยังเป็นระบบสมัครใจ

ระบบ e-Tax Invoice & e-Receipt ของกรมสรรพากรเปิดใช้งานมาหลายปีแล้ว แต่จนถึงกลางปี 2569 ประเทศไทยยังไม่มีกฎหมายบังคับใช้ใบกำกับภาษีอิเล็กทรอนิกส์แบบ B2B และยังไม่มีกำหนดการบังคับใช้ในปี 2569 และ 2570 (VATupdate, กรกฎาคม 2026) ภาครัฐใช้มาตรการจูงใจแทนการบังคับ โดยการลงทุนใน e-Tax Invoice, e-Receipt และ e-Withholding ที่เข้าเงื่อนไข สามารถหักรายจ่ายได้ 200% และเมื่อเดือนมิถุนายน 2569 คณะรัฐมนตรีได้อนุมัติขยายมาตรการจูงใจนี้ถึงสิ้นปี 2570 โดยพระราชกฤษฎีกาและกฎกระทรวงที่เกี่ยวข้องยังอยู่ระหว่างดำเนินการในขณะนั้น ภายใต้กรอบเดียวกันนี้ มีเพียงการยื่นภาษีหัก ณ ที่จ่าย (e-Withholding) เท่านั้นที่บังคับใช้ทางอิเล็กทรอนิกส์เต็มรูปแบบตั้งแต่เดือนมกราคม 2568

สำหรับฝ่ายการเงิน เรื่องนี้มีความหมายสามประการ

1. ซัพพลายเออร์จะไม่เปลี่ยนเป็นดิจิทัลพร้อมกับองค์กรของท่าน บริษัทขนาดใหญ่อาจส่ง XML แบบมีโครงสร้างมาแล้ว แต่ซัพพลายเออร์รายเล็กส่วนใหญ่ยังส่ง PDF ไฟล์สแกน หรือเอกสารกระดาษ ตราบใดที่ซัพพลายเออร์บางส่วนยังไม่เปลี่ยน ฝ่ายบัญชีเจ้าหนี้ก็ต้องดูแลสองช่องทางไปพร้อมกัน
2. ข้อกำหนดการเก็บรักษาเอกสารกระดาษยังคงอยู่ ทั้งเช็ค บัตรประจำตัว สัญญา เอกสารพิธีการศุลกากร และเอกสารขนส่ง ล้วนยังหมุนเวียนในรูปแบบภาพ
3. การบังคับใช้ไม่ใช่จุดสิ้นสุด แม้ในอนาคตจะมีกฎหมายบังคับ เอกสารที่สะสมไว้เดิม ทั้งสัญญาและเอกสารทางบัญชีย้อนหลัง ก็ยังคงมีอยู่ในรูปไฟล์สแกนเท่านั้น

การคีย์ข้อมูลด้วยมือไม่เพียงใช้เวลานาน แต่ยังผิดพลาดในลักษณะที่มักปรากฏช้า คือไปโผล่ตอนกระทบยอดแทนที่จะเห็นตั้งแต่ตอนคีย์ ตัวอย่างจากงานจริงของเรา คือ XCMG Leasing (Thailand) Co., Ltd ซึ่งต้องจัดการเช็คธนาคารแบบกระดาษราว 1,600 ใบต่อเดือน การอ่านและคีย์เข้าระบบด้วยมือทั้งหมดใช้เวลามากและเกิดข้อผิดพลาดได้ง่าย เราจึงพัฒนาโซลูชัน AI OCR ที่อ่านเลขที่เช็ค จำนวนเงิน และวันที่ของเช็คแต่ละใบ แล้วใช้โมเดลภาษาภาพตรวจทานผลการอ่านอีกชั้นก่อนรับเข้าระบบ ผลลัพธ์ถูกนำเข้าสู่ Flows ERP โดยอัตโนมัติ และช่วยลดงานกระทบยอดลงได้ประมาณ 3 วันทำงานของพนักงาน 1 คนต่อเดือน

เอกสารภาษาไทยยากตรงไหน

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

สาเหตุมีสี่ประการ

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

เรื่องนี้ไม่ใช่ความเห็นส่วนตัว ThaiOCRBench ที่เผยแพร่โดยทีม Typhoon และ SCB DataX เป็นเกณฑ์มาตรฐานชุดแรกสำหรับประเมินความเข้าใจเอกสารภาษาไทยของโมเดลภาษาภาพ ประกอบด้วยตัวอย่างที่ผ่านการตรวจสอบโดยมนุษย์ 2,808 รายการ ครอบคลุม 13 ประเภทงาน และผลงานวิจัยได้รับการตอบรับให้ตีพิมพ์ในงาน IJCNLP-AACL 2025 (ThaiOCRBench) ข้อสรุปคือ การอ่านข้อความในระดับรายละเอียดเป็นงานประเภทที่ยากที่สุด โดยวรรณยุกต์ไทยและตัวอักษรไทย-อังกฤษที่รูปร่างใกล้เคียงกันทำให้ความแม่นยำลดลงอย่างเห็นได้ชัด โมเดลทำงานได้แย่ที่สุดกับลายมือและเอกสารหลายคอลัมน์ และมีรูปแบบความผิดพลาดที่เกิดซ้ำสามลักษณะ ได้แก่ ผลลัพธ์เบี่ยงไปเป็นภาษาอังกฤษ โครงสร้างคลาดเคลื่อนเมื่อแปลผลตารางและแบบฟอร์ม รวมถึงการสร้างเนื้อหาที่ไม่มีอยู่จริงหรืออ่านตกหล่นระหว่างการประมวลผล

ควรเริ่มทำ AI OCR กับเอกสารประเภทใดก่อน

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

เรียงจากง่ายไปยากในการนำไปใช้จริง

บริการ AI OCRของ Yangshu ครอบคลุมเอกสารกลุ่มนี้โดยตรง ทั้งใบแจ้งหนี้และใบเสร็จ (ผู้ขาย จำนวนเงิน วันที่ รายการสินค้า) เช็คธนาคาร (ผู้รับเงิน จำนวนเงิน วันที่ เลขที่บัญชี) ข้อมูลที่มีโครงสร้างจากบัตรประชาชนไทย หนังสือเดินทาง และเลขประจำตัวผู้เสียภาษี รวมถึงเงื่อนไขสำคัญจากสัญญาและแบบฟอร์ม โดยประมวลผลเอกสารเป็นชุดได้ และส่งออกผลลัพธ์เป็น JSON, CSV หรือ XLSX หรือบันทึกเข้าสู่ Flows ERP โดยตรง

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

จาก OCR ทั่วไปสู่ AI OCR ระดับองค์กร ควรใช้เกณฑ์ใดในการเลือก

ตัดสินใจก่อนว่าโจทย์คือ "อ่านเอกสารเป็นครั้งคราว" หรือ "ประมวลผลหลายร้อยฉบับทุกเดือนและนำเข้าระบบ" เพราะเป็นคนละปัญหากัน และต้นทุนต่างกันหลายเท่าตัว

หากเป็นกรณีแรก โปรแกรมบนเครื่องก็เพียงพอ เราได้นำเอนจิน AI OCR ของเราเองมาทำเป็นโปรแกรม Windows ที่ใช้งานฟรีชื่อ OCRScribe การอ่านเอกสารทำงานแบบออฟไลน์บนเครื่องของผู้ใช้เอง ไม่มีการอัปโหลดไฟล์ รองรับ 109 ภาษา และส่งออกเป็นไฟล์ Word ที่แก้ไขได้ PDF ที่ค้นหาได้ และ Excel เหมาะกับงานอย่างฝ่ายกฎหมายที่ต้องค้นสัญญาฉบับเก่า หรือฝ่ายธุรการที่ต้องจัดระเบียบเอกสารรับรองจำนวนหนึ่ง โดยไม่ต้องตั้งโครงการและไม่ต้องใช้งบประมาณ

หากเป็นกรณีที่สอง ความแม่นยำเป็นเพียงข้อแรกในหลายข้อที่ต้องประเมิน เรียงตามลำดับความสำคัญ

1. ความถูกต้องระดับฟิลด์ ไม่ใช่ระดับตัวอักษร เมื่อถามผู้ให้บริการว่าความแม่นยำเท่าใด คำตอบที่ได้มักเป็น 99% แต่ในระดับตัวอักษร 99% หมายความว่าเลขที่ใบแจ้งหนี้ 13 หลักจะมีตัวเลขผิดหนึ่งตัวโดยเฉลี่ยทุก ๆ 8 ฉบับ ควรขออัตราความถูกต้องทั้งฟิลด์เฉพาะฟิลด์ที่สำคัญแทน คือสัดส่วนของเอกสารที่เลขที่ใบแจ้งหนี้ จำนวนเงิน และวันที่ ถูกต้องครบทั้งสามรายการ
2. พฤติกรรมเมื่อระบบไม่แน่ใจ เมื่ออ่านไม่ชัด ระบบทำเครื่องหมายไว้ หรือเดาแล้วเติมค่าลงไป ข้อนี้ข้อเดียวกำหนดว่าต้องใช้คนตรวจทานมากน้อยเพียงใด ระบบที่บอกได้ว่า "จุดนี้ไม่แน่ใจ เพราะตราประทับบังหลักที่สี่ของวันที่" ปลอดภัยกว่าระบบที่ความแม่นยำสูงกว่าหนึ่งเปอร์เซ็นต์แต่สร้างค่าขึ้นมาเองอย่างเงียบ ๆ
3. วงจรการตรวจทานปิดอย่างไร เมื่อมีจุดที่ถูกทำเครื่องหมายแล้ว ใครเป็นผู้แก้ไข แก้ที่ใด และการแก้ไขนั้นกลับเข้าสู่กระบวนการหลักได้อย่างไร
4. การไหลของข้อมูลและการปฏิบัติตามกฎหมาย เอกสารเหล่านี้มีข้อมูลซัพพลายเออร์ เลขที่บัญชีธนาคาร และเลขบัตรประชาชนของพนักงาน การใช้ API บนคลาวด์สาธารณะหมายความว่าภาพเหล่านี้ออกจากเครือข่ายขององค์กร กรณีที่เกี่ยวข้องกับข้อมูลส่วนบุคคลควรประเมินตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) และเลือกการติดตั้งในองค์กรหรือคลาวด์ส่วนตัวหากจำเป็น
5. อินเทอร์เฟซ ไม่ใช่หน้าจอ หน้าจออัปโหลดเอกสารเป็นชุดที่ดูดีตอนสาธิตมีค่าไม่มากนัก สิ่งที่ชี้ขาดว่าจะใช้งานได้จริงหรือไม่คือระบบขององค์กรเรียกใช้งานได้หรือไม่ และเขียนผลลัพธ์กลับได้หรือไม่
6. ต้นทุนการดูแลเมื่อเลย์เอาต์เปลี่ยน เมื่อเพิ่มซัพพลายเออร์รายใหม่หรือมีการปรับรูปแบบใบแจ้งหนี้ เป็นเพียงการตั้งค่า หรือผู้ให้บริการต้องฝึกโมเดลใหม่และเรียกเก็บค่าดำเนินการอีกครั้ง

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

ข้อมูลที่อ่านได้เข้าสู่ระบบ ERP อย่างไร

มีสามเส้นทาง และเส้นทางที่เหมาะสมขึ้นอยู่กับว่าระบบ ERP มีอินเทอร์เฟซเปิดหรือไม่ และองค์กรแก้ไขระบบนั้นได้หรือไม่

• เส้นทางที่หนึ่ง บันทึกเข้าโดยตรง หากระบบ ERP ปรับแต่งได้ เช่น แพลตฟอร์ม Flows ของ Yangshu เอง AI OCR สามารถบันทึกผลลัพธ์เป็นเอกสารเจ้าหนี้ที่รออนุมัติได้ทันที คนเหลือเพียงหน้าที่ยืนยัน เส้นทางนี้สั้นที่สุด แต่มีเงื่อนไขว่าระบบ ERP ต้องอยู่ในขอบเขตที่องค์กรควบคุมได้
• เส้นทางที่สอง ส่งต่อผ่านไฟล์ที่มีโครงสร้าง ส่งออกเป็น JSON หรือ CSV แล้วให้ฟังก์ชันนำเข้ามาตรฐานของ ERP รับไป เหมาะกับระบบที่มีเทมเพลตนำเข้าที่สมบูรณ์อยู่แล้ว และเป็นแนวทางที่แก้ไขระบบน้อยที่สุด โดยแลกกับขั้นตอนประมวลผลเป็นชุดเพิ่มขึ้นหนึ่งขั้นและการกระทบยอดอีกหนึ่งชั้น
• เส้นทางที่สาม ใช้ RPA ปิดช่วงสุดท้าย หากระบบ ERP เป็น SAP, Oracle หรือระบบเดิมภายในองค์กรที่ไม่มี API ซึ่งแก้ไขไม่ได้และไม่ได้รับอนุญาตให้แก้ไข ก็ใช้หุ่นยนต์ซอฟต์แวร์กรอกข้อมูลตามเส้นทางเดียวกับที่คนทำ ซึ่งเป็นสิ่งที่บริการ RPA อัตโนมัติของ Yangshu ทำอยู่ คือเชื่อมต่อโดยไม่รุกล้ำและไม่แก้ไขระบบเดิม สำหรับแนวทางเลือกกระบวนการแรกที่ควรทำอัตโนมัติ อ่านได้ที่ควรเริ่มทำอัตโนมัติจากตรงไหน

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

ตั้งความคาดหวังเรื่องความแม่นยำให้ถูกต้องก่อนขึ้นระบบ

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

แนวทางการทดสอบก่อนรับมอบที่ใช้ได้จริง

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

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

มุมมองของ Yangshu

ต่อไปนี้คือข้อสรุปที่เราได้จากประสบการณ์ส่งมอบงานในประเทศไทย

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

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

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