ขั้นตอนการประเมิน OCR ใบแจ้งหนี้หลายภาษา: วิธีตรวจสอบข้อมูลเฉลย การคำนวณความแม่นยำ และการเชื่อมต่อระบบบัญชี

การประเมิน OCR ใบแจ้งหนี้หลายภาษาในอุตสาหกรรมการผลิต คือการตรวจสอบกระบวนการตั้งแต่การดึงตัวอักษรและรายการข้อมูลจากใบแจ้งหนี้ที่ได้รับ ไปจนถึงการตรวจสอบ แก้ไข และส่งข้อมูลเข้าสู่ระบบบัญชี โดยใช้ข้อมูลที่ถูกต้อง (Ground Truth) ของบริษัทเอง สิ่งที่ผู้รับผิดชอบด้านบัญชีและ DX ในอุตสาหกรรมการผลิตต้องการตัดสินใจ ไม่ใช่แค่จำนวนตัวอักษรที่อ่านได้จากการสาธิต (Demo) เท่านั้น แต่ยังรวมถึงความสามารถในการหยุดยั้งความผิดพลาดของยอดเงินหรือสกุลเงิน และการลดภาระงานที่รวมถึงขั้นตอนการตรวจสอบด้วย บทความนี้จะเริ่มต้นด้วยการกำหนดสิ่งที่ต้องตัดสินใจและสิ่งที่ต้องคงไว้ก่อนการประเมิน จากนั้นจะแสดงวิธีการแบ่งเอกสารจริงออกเป็นชุดสำหรับปรับแต่งและชุดสำหรับประเมินผลขั้นสุดท้าย เพื่อกำหนดผู้รับผิดชอบด้านบัญชี ข้อมูลที่ถูกต้อง และกฎการตรวจสอบความถูกต้อง พร้อมทั้งอธิบายขั้นตอนการออกแบบสิ่งนี้ให้เป็น PoC ของ OCR หลายภาษาในระดับย่อย

การประเมินจะดำเนินการโดยกำหนดเอกสารเป้าหมายและข้อมูลที่ถูกต้องไว้เป็นมาตรฐาน โดยแบ่งลำดับขั้นตอนดังนี้: (1) การรู้จำตัวอักษร (2) การดึงข้อมูลรายการ (3) การเชื่อมต่อกับระบบบัญชี และ (4) การดำเนินงานและค่าใช้จ่าย โดยจะอธิบายโดยสมมติสถานการณ์ที่ต้องจัดการกับภาษาญี่ปุ่น อังกฤษ ไทย และลาว พร้อมทั้งใช้ตัวอย่างการคำนวณและตารางการตัดสินประกอบ ทั้งนี้ ไม่มีการกำหนดเกณฑ์ผ่านที่เป็นมาตรฐานสำหรับทุกบริษัท แต่จะขึ้นอยู่กับเงื่อนไขความผิดพลาดที่บริษัทรับได้และการตรวจสอบด้วยคน ตัวเลขในบทความนี้เป็นข้อมูลสมมติเพื่อใช้ประกอบการอธิบายการคำนวณเท่านั้น สำหรับการตัดสินความเหมาะสมด้านการจัดการภาษีและการจัดเก็บเอกสารตามกฎหมาย โปรดตรวจสอบกับหัวหน้าฝ่ายบัญชีหรือผู้เชี่ยวชาญในแต่ละประเทศที่เกี่ยวข้อง

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

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

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

เอกสารที่เตรียมไว้ควรแบ่งออกเป็นชุดสำหรับปรับแต่งการตั้งค่า กฎการสกัดข้อมูล และเกณฑ์การตรวจสอบ (Threshold) กับชุดข้อมูลคงที่สำหรับใช้ในการตัดสินขั้นสุดท้าย โปรดจัดการโดยใช้หน่วยของเอกสารต้นฉบับ เพื่อไม่ให้ไฟล์ PDF ของใบแจ้งหนี้เดียวกัน ภาพถ่าย หรือเอกสารที่ซ้ำซ้อนกันเกือบทั้งหมดปรากฏอยู่ในทั้งสองชุด หากมีการปรับแต่งโดยดูคำตอบจากชุดข้อมูลสุดท้าย ให้ทำการประเมินใหม่ด้วยเอกสารอื่นที่ยังไม่ได้ใช้งาน คำอธิบายการแบ่งข้อมูลของ Google ก็ได้กล่าวถึงการแยกชุดข้อมูลสำหรับการเรียนรู้ การปรับแต่ง และการทดสอบ การกำจัดข้อมูลที่ซ้ำซ้อน และการใช้ชุดข้อมูลทดสอบที่เป็นตัวแทนของข้อมูลจริงเช่นกัน

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

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

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

แต่ละรายการต้องประกอบด้วยค่าจากต้นฉบับ ค่าสำหรับการประมวลผลด้วยเครื่อง และกฎการแปลงข้อมูล ตัวอย่างเช่น เลขที่ใบแจ้งหนี้ต้องเป็นสตริงที่คงเลขศูนย์นำหน้าไว้ จำนวนเงินต้องเป็นรูปแบบที่จัดการเป็นเลขทศนิยมได้อย่างแม่นยำ และสกุลเงินต้องแยกเป็นอีกรายการหนึ่ง หากวันที่เป็น "03/04/2026" ให้พักการแปลงข้อมูลไว้จนกว่าจะสามารถยืนยันการตีความได้จากภูมิภาคหรือเงื่อนไขการทำธุรกรรมในเอกสาร อย่าตัดสินลำดับวันที่หรือสกุลเงินโดยดูจากภาษาเพียงอย่างเดียว

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

ข้อมูลรายละเอียด (Line items) ต้องมีการจับคู่ด้วย "ID เอกสาร, หน้า, ID บรรทัดเฉลย, รหัสสินค้า, จำนวน, หน่วย, ราคาต่อหน่วย, ภาษี/ส่วนลด, จำนวนเงินต่อบรรทัด" หากพึ่งพาลำดับบรรทัดเพียงอย่างเดียว จะทำให้บรรทัดทั้งหมดที่ตามหลังบรรทัดที่ขาดหายไปเกิดการจับคู่ผิดพลาด ต้องกำหนดให้ชัดเจนตั้งแต่ต้นว่าจะจัดการกับบรรทัดที่ต่อเนื่องข้ามหน้า, สินค้าเดียวกันที่อยู่คนละบรรทัด และยอดรวมย่อยของแต่ละหน้าอย่างไร

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

การรู้จำตัวอักษร (Character Recognition) จะเปรียบเทียบข้อความที่ถูกต้องกับข้อความที่ส่งออกโดยใช้กฎเดียวกัน CER และ WER เป็นดัชนีที่ใช้ตรวจสอบแนวโน้มของข้อผิดพลาด แม้ว่าค่าโดยรวมของแบบฟอร์มจะอยู่ในเกณฑ์ดี แต่อาจยังคงมีข้อผิดพลาดเพียงหนึ่งตัวอักษรในยอดเงินที่เรียกเก็บได้ ดังนั้นรายการที่มีความสำคัญต่อการดำเนินงานจึงต้องได้รับการประเมินแยกต่างหากใน Step 2

CER คืออัตราความผิดพลาดของตัวอักษร (Character Error Rate) และ WER คืออัตราความผิดพลาดของคำ (Word Error Rate) โดยจะทำการจับคู่ระหว่างคำตอบที่ถูกต้องกับผลลัพธ์ที่ได้ด้วยระยะการแก้ไขที่น้อยที่สุด (Minimum Edit Distance) แล้วนับจำนวนการแทนที่ (Substitution) การลบ (Deletion) และการแทรก (Insertion) ตามนิยามของ ข้อกำหนดการประเมินผลของ OCR-D การคำนวณจะเป็นดังนี้:

CER = (จำนวนตัวอักษรที่แทนที่ S + จำนวนตัวอักษรที่ลบ D + จำนวนตัวอักษรที่แทรก I) ÷ จำนวนตัวอักษรที่ถูกต้อง N

WER = (จำนวนคำที่แทนที่ S + จำนวนคำที่ลบ D + จำนวนคำที่แทรก I) ÷ จำนวนคำที่ถูกต้อง N

ตัวอย่างการคำนวณเพื่ออธิบาย หากคำตอบที่ถูกต้องคือ "AB1234" และผลลัพธ์ที่ได้คือ "AB1284" จะมีการแทนที่ 1, ลบ 0, แทรก 0 และเนื่องจากมีตัวอักษรที่ถูกต้อง 6 ตัว CER จึงเท่ากับ 1÷6 = ประมาณ 16.7% หากเป็น "AB12345" จะถือว่ามีการแทรก 1 ตัว ในกรณีที่มีการแทรกจำนวนมาก CER อาจเกิน 100% ได้ ดังนั้นจึงไม่สามารถสรุปได้ว่า "100% ลบด้วย CER จะเท่ากับอัตราการจดจำตัวอักษร" ในกรณีที่คำตอบที่ถูกต้องเป็นพื้นที่ว่าง ตัวหารจะเป็นศูนย์ ดังนั้นเราจะบันทึกจำนวนตัวอักษรที่ไม่จำเป็นแยกต่างหากจาก CER ปกติ

ตัวอย่างการคำนวณ WER คือกรณีที่คำตอบที่ถูกต้องคือ "TOTAL USD 100" และผลลัพธ์คือ "TOTAL USD 1000" โดยแบ่งเป็น 3 คำด้วยช่องว่าง เนื่องจากมีการแทนที่คำ 1 คำ WER จึงเท่ากับ 1÷3 = ประมาณ 33.3% ค่านี้จะเปลี่ยนแปลงไปตามกฎการตัดคำ หากต้องการเปรียบเทียบภาษาญี่ปุ่น ภาษาไทย และภาษาลาวด้วยวิธีเดียวกัน โปรดกำหนดตัวตัดคำ พจนานุกรม และเวอร์ชันให้คงที่ ในกรณีที่นับด้วยตัวอักษร ให้บันทึกการทำ Unicode Normalization, หน่วยของตัวอักษรที่รวมถึงอักขระผสม (Combining Characters) และการจัดการช่องว่างกับขึ้นบรรทัดใหม่ไว้ด้วย ใน OCR-D จะใช้ Grapheme Cluster ที่ผ่านการทำ NFC Normalization แล้ว

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

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

ในการสกัดข้อมูล (Item Extraction) ระบบจะไม่เพียงแค่ดึงค่าออกมาเท่านั้น แต่ยังตรวจสอบด้วยว่า "เป็นค่าที่อยู่ในเอกสารฉบับใด และเป็นของรายการหรือบรรทัดรายละเอียดใด" การแยกการวัดค่าความแม่นยำ (Precision), ค่าความระลึก (Recall) และค่า F1 ของรายการหลัก ออกจากสัดส่วนของเอกสารที่มีรายการสำคัญครบถ้วน จะช่วยให้ตรวจพบข้อผิดพลาดของจำนวนเงินและสกุลเงินที่มักถูกบดบังด้วยค่าเฉลี่ยได้ง่ายขึ้น

ก่อนอื่นต้องกำหนดเงื่อนไขการตรวจสอบความถูกต้อง ในการออกแบบการประเมินของบทความนี้ เราจะกำหนดให้ผลลัพธ์ที่ ID เอกสาร ชื่อรายการ และบรรทัดรายละเอียดที่จำเป็นตรงกัน และมีค่าตรงกับคำตอบที่ถูกต้อง คือ TP (การสกัดข้อมูลที่ถูกต้อง) ส่วนผลลัพธ์ที่ไม่ตรงกับคำตอบที่ถูกต้องคือ FP (การสกัดข้อมูลเกินหรือผิดพลาด) และคำตอบที่ถูกต้องที่ดึงข้อมูลมาไม่ได้คือ FN (การตกหล่น) หากมีการแสดงค่าที่ผิดพลาดออกมาหนึ่งค่า จะถือเป็นทั้ง FP (ผลลัพธ์ที่ผิด) และ FN (ไม่สามารถดึงข้อมูลที่ถูกต้องออกมาได้) ทั้งสองอย่าง การตรวจสอบความถูกต้องจะเป็นแบบหนึ่งต่อหนึ่ง โดยจะไม่ให้ผลลัพธ์หลายรายการตรงกับรายการคำตอบที่ถูกต้องเดียวกัน ผลลัพธ์ที่ซ้ำกันซึ่งเหลืออยู่จะถูกนับเป็น FP วิธีการนับนี้เป็นวิธีเดียวกับที่ใช้ใน คำอธิบายการประเมินผลของ Google Document AI

Precision (ความแม่นยำ) = TP ÷ (TP + FP)

Recall (ความสามารถในการเรียกคืน) = TP ÷ (TP + FN)

F1 = 2TP ÷ (2TP + FP + FN)

ตัวอย่างการคำนวณ สมมติว่ามีรายการคำตอบที่ถูกต้อง 100 รายการ แต่ระบบแสดงผลออกมา 98 รายการ โดยในจำนวนนั้นมี 95 รายการที่ถูกต้อง 3 รายการเป็นค่าที่ผิด และอีก 2 รายการที่เหลือไม่ได้แสดงผลออกมา จะได้ TP = 95, FP = 3, FN = 5 ค่า Precision จะเท่ากับ 95 ÷ 98 = 96.94%, Recall เท่ากับ 95 ÷ 100 = 95.00% และ F1 เท่ากับ 190 ÷ 198 = 95.96% ตัวเลขเหล่านี้มีไว้เพื่ออธิบายวิธีการเท่านั้น ไม่ใช่ค่าที่วัดได้จริงจากผลิตภัณฑ์ การตัดสินว่าตัวหารเป็นศูนย์หรือไม่นั้นจะพิจารณาแยกตามดัชนีแต่ละตัว หากมีคำตอบที่ถูกต้องแต่ไม่มีผลลัพธ์ออกมา ค่า Precision จะคำนวณไม่ได้ ส่วน Recall และ F1 จะเป็น 0 หากไม่มีทั้งคำตอบที่ถูกต้องและผลลัพธ์ จะถือว่าคำนวณไม่ได้ทั้งหมดและจะไม่ให้คะแนนเต็ม

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

ตารางการตัดสินจะถูกจัดทำในรูปแบบที่สามารถอ่านข้อผิดพลาดของรายการสำคัญได้ก่อน

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

ในการทดสอบการเชื่อมต่อ (Integration Test) ให้ตรวจสอบความถูกต้องระหว่างการตอบกลับเมื่อส่งข้อมูลสำเร็จกับเนื้อหาที่ถูกบันทึกไว้ในฝั่งระบบบัญชี โดยให้เชื่อมต่อกับสถานประกอบการและสภาพแวดล้อมสำหรับการทดสอบ และติดตามผลตั้งแต่ขั้นตอนการจดจำข้อมูลไปจนถึงการลงทะเบียนด้วย Document ID ทั้งนี้ แม้จะยังไม่ได้กำหนดค่า OCR ให้เสร็จสมบูรณ์ แต่คุณสามารถตรวจสอบข้อกำหนดการเชื่อมต่อล่วงหน้าได้โดยใช้ข้อมูลนำเข้าที่สร้างจากข้อมูลที่ถูกต้อง (Ground Truth)

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

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

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

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

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

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

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

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

ภาระงานของคนไม่สามารถวัดได้เพียงแค่จำนวนรายการที่แก้ไขหลังผ่าน OCR เท่านั้น แต่ต้องรวมเวลาที่ใช้ในการตรวจสอบแต่ละเอกสาร การแก้ไข การตรวจสอบกรณีข้อยกเว้น การส่งใหม่ และการตรวจสอบกับฝั่งบัญชี แล้วนำไปเปรียบเทียบกับเวลาที่ใช้ในการประมวลผลแบบฟอร์มเดียวกันด้วยขั้นตอนแบบเดิม ในตัวอย่างการคำนวณเพื่ออธิบาย หากใช้เวลาตรวจสอบและแก้ไข 60 นาที ตรวจสอบข้อยกเว้น 20 นาที และตรวจสอบความถูกต้อง 10 นาที ภาระงานของคนจะรวมเป็น 90 นาที โดยจะไม่นำจำนวนรายการที่แก้ไขไปคูณกับเวลาที่รวมไว้แล้วอีกครั้ง นอกจากนี้ ให้แยกค่าใช้จ่ายเริ่มต้นในการตั้งค่าและการสร้างคำตอบที่ถูกต้อง ออกจากค่าธรรมเนียมการใช้งานรายเดือนและภาระงานในการตรวจสอบ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ขั้นแรก ให้สร้างบัญชีรายชื่อและคำจำกัดความของรายการสำหรับใบแจ้งหนี้ที่ได้รับจริง จากนั้นกรอกเงื่อนไขของบริษัทคุณลงในตารางการตัดสินใจของบทความนี้ หากนำขอบเขตการประมวลผลพื้นฐานจาก คู่มือการนำ AI-OCR และการประมวลผลเอกสารอัจฉริยะมาใช้ และการออกแบบงานตรวจสอบจาก พื้นฐานของระบบอัตโนมัติที่มีมนุษย์เข้ามามีส่วนร่วม (Human-in-the-loop) มาใช้ร่วมกัน จะช่วยให้คุณสามารถกำหนดรายละเอียดการดำเนินงานหลังการประเมินได้ชัดเจนยิ่งขึ้น