Invoice template for OCR and AI proposal

อัปเดตเมื่อ 10 เม.ย. 2567

คำตอบที่ไม่เคยถูกถาม..

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

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

E-Tax Invoice

ย้อนกลับไปเล่าถึงงานล่าสุดเกี่ยวกับ E-Tax Invoice ที่พยายามหาวิธีสร้างไฟล์ PDF/A-3 แล้วก็ได้ไอเดียจากบทความหนึ่งที่แนะนำว่า เราสามารถสร้างบิลทั้งใบด้วย HTML แล้วแปลงให้รูปภาพเอาไปใส่ใน PDF แทนที่จะต้องใช้ชุดคำสั่งที่วางข้อความทีละข้อความโดยโปรแกรมต้องระบุตำแหน่งที่ต้องการบนพื้นที่ว่างที่เปรียบเสมือนกระดาษเปล่า ซึ่งยุ่งยากซับซ้อนกว่า ตัวอย่างเช่น

page.moveTo(2, 120);
page.drawText('TAX INVOICE');

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

ก่อนที่จะลงมือพัฒนาตามไอเดียนั้น เพื่อนของเราที่ช่วยค้นคว้าเรื่อง PDF/A-3 ก็เตือนมาว่า มีเงื่อนไขที่อาจทำให้ขาดคุณสมบัติเรื่องค้นหาและคัดลอก

PDF/A-3u ช่วยให้การค้นหา(search) และคัดลอก(copy) ข้อความที่เป็น Unicode บนเอกสารที่สร้างขึ้นแบบดิจิตอล รวมไปถึงเอกสารที่ได้จากการทำ OCR (optical character recognition) (อ้างอิง getinvoice.net)

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

หลังจากได้ปรึกษาเพื่อหาแนวทางกันหลายรอบ ผมจึงเสนอแนวทางว่า มาตรฐาน E-Tax Invoice นั้นกำหนดว่าต้องเป็นไฟล์ PDF/A-3 แต่ไม่ได้เจาะจงว่าต้องทำให้ได้ถึงมาตรฐาน PDF/A-3u หากขาดคุณสมบัติเรื่องค้นหาและคัดลอกข้อความ แต่ยังเป็น PDF/A-3 ที่แนบ XML ตามข้อกำหนดได้ก็น่าจะโอเค

ไม่มีใครตอบได้ จึงสรุปกันว่า "ลองดู" ทำเสร็จแล้วส่งไฟล์ไปตรวจสอบที่เว็บกรมสรรพากร ถ้าฟ้องว่าไม่ถูกต้องก็ค่อยหาทางกันใหม่

Optical Character Recognition (OCR)

ถึงแม้ว่าเทคนิค รูปภาพ + XML = PDF จะผ่านการตรวจได้ แต่ในใจก็รู้สึกว่ายังไม่เคลียร์ ตรงที่ไม่สามารถค้นหาหรือคัดลอกข้อความ ผมอยากจะคิดหาทางต่อไป หาเหตุผลดี ๆ ที่ต้องมีข้อความใน PDF มากกว่าแค่นั้น

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

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

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

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

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

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

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

Number-plate recognition

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

เทคนิคที่ทำให้ OCR สามารถอ่านป้ายทะเบียนรถได้ อยู่ที่ขั้นตอน regions detection หาขอบเขตพื้นที่ส่วนที่น่าจะเป็นป้ายทะเบียนรถให้ได้ก่อน หลังจากนั้นใช้ OCR อ่านตัวอักษรเฉพาะส่วนที่อยู่ในกรอบพื้นที่นั้น

image from pyimagesearch - https://pyimagesearch.com/2020/09/21/opencv-automatic-license-number-plate-recognition-anpr-with-python/

การที่ OCR ไม่สามารถอ่านบิลได้แม่นยำ อาจเป็นเพราะไม่สามารถทำ regions detection ว่าพื้นที่ส่วนไหนคือข้อมูลที่ควรอ่านเข้ามา

สมมติว่า เราสามารถตกลงมาตรฐานร่วมกันในรูปแบบเพิ่มเติมของใบกำกับภาษี ทั้งการภาพถ่ายและไฟล์ PDF ให้สามารถทำ regions detection ส่วนที่เป็นข้อมูลสำคัญ โดยออกแบบให้ใช้มีรูปแบบพิเศษช่วยให้ตรวจหาขอบเขตได้เหมือนกับกรณีกรอบป้ายทะเบียนรถได้ง่าย ๆ

Invoice template

เริ่มจากคิดหาทางทำ PDF/A-3u ให้สมบูรณ์ นึกภาพหากมีใครสักคนเปิดจอป้อนข้อมูลอยู่หน้าต่างซ้าย เปิดไฟล์ PDF หน้าต่างขวา ทำงานแบบคัดลอกข้อความจาก PDF ไปป้อนเข้าโปรแกรมจะต้องใช้ข้อความอะไรบ้าง ทำอย่างไรจึงจะคัดลอกได้สะดวก แล้วจินตนาการไปเชื่อมโยงกับปัญหาการทำงานของสำนักบัญชีที่เคยเจอ ปัญหาการทำ OCR ให้อ่านบิลอัตโนมัติ

ตัวอย่างใบกำกับภาษีที่ทำออกมา ใส่ข้อความเพิ่มเติมไว้ด้านล่างของฟอร์มบิล โดยใช้มาร์กขึ้นต้นและลงท้ายด้วยบรรทัดที่มีสัญญลักษณ์ *** ดังนี้

***
seller_taxid: 0105559161704 seller_br: 00000 seller: บริษัท บัญชี 4.0 จำกัด
buyer_taxid: 0123456789012 buyer_br: 00000 buyer: 0123456789 จำกัด
docno: XX230167-000001 date: 2024-01-23 vat: 349.65 amount: 5389.65
***

สำหรับมาตรฐาน PDF/A-3u ที่ติดค้าง เนื่องจากเป็นการใส่ข้อความจริงลงไป ไม่ใช่รูปภาพของฟอร์มบิล ทำให้มีคุณสมบัติครบ สามารถค้นหาและคัดลอกได้ตามสเปค

สำหรับ OCR บรรทัด *** ใช้เป็น Edge detection บอกให้รู้ว่าพื้นที่ในขอบเขตระหว่างสองบรรทัดนี้ เป็นข้อความที่สามารถอ่านไปใช้เป็นข้อมูล

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

สำหรับ AI เช่นเดียวกับ OCR โดยการทำ image segmentation ช่วย สามารถอ่านข้อความที่มี label กำกับ และเชื่อถือข้อมูลตรงส่วนนี้ได้ เดิม model ที่พยายามอ่านบิลต้องใช้เทคนิคซับซ้อน เช่น หากพบข้อความที่เป็นวันที่ภายในบิลมากกว่า 1 แห่ง ต้องตรวจสอบบริบทของข้อความในตำแหน่งใกล้เคียง เพื่อคาดเดาว่าวันที่ไหนกันแน่เป็น วันที่เอกสาร วันที่ไหนเป็นกำหนดชำระ ฯลฯ

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

ชื่อข้อมูลหรือ label ออกแบบให้ใช้สัญญลักษณ์ : ต่อท้าย เช่น seller_taxid ช่วยให้การเขียนโค้ดเพื่อตรวจแยกทำได้ไม่ยาก ขณะเดียวกันเป็นชื่อที่ใช้สื่อความหมายกับ Generative AI ได้

ค่าวันที่ตามตัวอย่างจะเห็นว่าเป็น ISO standard เพื่อไม่ให้ระบบอัตโนมัติต้องยุ่งยากตีความ ตรงนี้อาจมีปัญหาสำหรับการอ่านของมนุษย์บ้าง หากต้องอินพุทเข้าโปรแกรมที่รับแต่ปีพ.ศ. ผมคิดว่าในอนาคตโปรแกรมที่รับอินพุทวันที่ สามารถปรับปรุงให้รองรับการคีย์วันที่แบบ ISO standard เสริมเข้ามาได้ไม่ยาก

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

สมมติเล่น ๆ ถ้าบิลทุกใบมีข้อความส่วนเสริมเหมือนกัน ต่อไปก็ออกแบบโปรแกรมให้รองรับการทำงานแบบก๊อปวาง คัดลอกข้อความทั้งปึก 3–4 บรรทัดเอามาวางในโปรแกรม แล้วโปรแกรมก็คัดแยกมาเป็นข้อมูลภาษีซื้อหรือขายบันทึกเข้าระบบได้ เฟสแรกก็เท่ากับปลดล็อกใช้ใครมาทำก็ได้ โปรแกรมบัญชีใด ๆ ก็สามารถพัฒนาฟีเจอร์ให้รองรับวิธีการเช่นนี้ได้ เฟสต่อไปพัฒนา automation อาจใช้ RPA มาช่วยก๊อปวางแทน เฟสต่อไปก็ทำเป็น OCR หรือเขียน prompt ให้ AI โยนไฟล์รูปหรือ PDF เข้าโปรแกรมก็แปลงเป็นข้อมูลได้ทันที

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