ความแม่นยำ AI-OCR: วิธีทำ PoC และตรวจรับเอกสารหลายภาษา

การเปรียบเทียบความแม่นยำ AI-OCR ด้วย “อัตราการรู้จำ” เพียงตัวเลขเดียวไม่เพียงพอสำหรับการตัดสินใจใช้งานจริง ตัวเลขจากชุดทดสอบของผู้ให้บริการไม่ได้บอกว่าระบบจะอ่านเอกสารภาษาญี่ปุ่น อังกฤษ ไทย และเวียดนามของบริษัทได้ดีเพียงใด โดยเฉพาะเมื่อมีวันที่ สกุลเงิน เลขประจำตัวผู้เสียภาษี รายการสินค้า ลายมือเขียนเพิ่มเติม และภาพสแกนคุณภาพต่ำ บทความนี้อธิบายวิธีติดตั้ง AI-OCR แบบเริ่มจาก PoC จนถึงการตรวจรับ โดยวัด precision, recall และ F1 ระดับฟิลด์ ความถูกต้องแบบตรงกันทุกตัวของฟิลด์สำคัญ อัตรา STP การหลุดรอดของข้อผิดพลาดสำคัญ อัตราประมวลผลล้มเหลว ความสามารถในการให้ผลซ้ำ และความแตกต่างเมื่อเปลี่ยนเวอร์ชัน

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

เหตุใดอัตราการรู้จำเพียงค่าเดียวจึงใช้เปรียบเทียบความแม่นยำ OCR ไม่ได้

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

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

เอกสารการประเมินอย่างเป็นทางการของ Google Document AI อธิบาย precision, recall, F1 และ confidence threshold รวมถึงประโยชน์ของ precision และ recall เมื่อต้องประเมินฟิลด์ที่มีหรือไม่มีก็ได้และรายการที่เกิดซ้ำ เอกสารด้านความโปร่งใสของ Microsoft Document Intelligence เน้นการทดสอบตามกรณีใช้งานจริง การใช้ confidence ประกอบการตัดสินใจ และการตรวจโดยมนุษย์ ส่วน Amazon Textract แสดง confidence ในช่วง 0–100 ขณะที่บริการอื่นอาจใช้ 0–1 ห้ามถือว่าคะแนนดิบเป็นความน่าจะเป็นมาตรฐานเดียวกัน เพราะการสอบเทียบต่างกันตามโมเดล processor เวอร์ชัน และกลุ่มข้อมูล

8 ตัวชี้วัดสำหรับความแม่นยำ OCR เอกสาร

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

สูตร precision คือ TP ÷ (TP + FP) และ recall คือ TP ÷ (TP + FN) โดย TP คือฟิลด์ที่ดึงได้ถูกต้อง FP คือค่าที่ไม่มีอยู่จริงหรือค่าผิดซึ่งระบบส่งออกเป็นคำตอบ และ FN คือค่าที่มีในคำตอบจริงแต่ระบบดึงไม่ออก ส่วน F1 คือ 2 × precision × recall ÷ (precision + recall)

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

วิธีสร้างชุดทดสอบสำหรับติดตั้ง AI-OCR

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

แบ่งชั้นตามภาษา ประเภทเอกสาร และคุณภาพภาพ

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

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

แยกข้อมูลปรับแต่งออกจากชุดตรวจรับ

ทีมติดตั้งอาจดู development set เพื่อปรับ preprocessing, schema, template หรือ prompt ได้ แต่ acceptance holdout ต้องไม่ถูกเปิดดูก่อนตรึงการตั้งค่า การใช้เอกสารเดียวกันทั้งปรับและตรวจรับทำให้การจำแม่แบบดูเหมือนเป็นการปรับปรุงทั่วไป ไฟล์ซ้ำ ภาพสแกนซ้ำจากต้นฉบับเดียวกัน และเอกสารเลขต่อเนื่องจากแม่แบบเดียวกันต้องอยู่ฝั่งเดียวกันของการแบ่งข้อมูล

ตรวจคุณภาพ ground truth

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

อย่านำไฟล์ที่ล้มเหลวออกจากตัวหาร

timeout, ผลลัพธ์ว่าง, PDF เข้ารหัส, เกินจำนวนหน้า, ไฟล์ถูกมองว่าเสีย และ API error ต้องไม่หายไปจากรายงาน “ถูกต้อง 96% ในเอกสารที่ประมวลผลสำเร็จ” ยังไม่ครบถ้าปริมาณงาน 5% เปิดไม่ได้ ควรแยกความล้มเหลวครั้งแรก งานที่กู้คืนได้หลัง retry งานที่ล้มเหลวถาวร และงานที่ส่งให้คนทำ

กติกา normalization สำหรับเอกสารสี่ภาษา

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

Unicode Standard Annex #15 กำหนด canonical equivalence และรูปแบบ normalization การใช้ NFC เป็นฐานอาจเหมาะกับหลายกรณี แต่ไม่ควรใช้ NFKC กับทุกฟิลด์โดยไม่มีการอนุมัติ เพราะ compatibility normalization อาจเปลี่ยนความแตกต่างบางอย่าง ต้องเก็บภาพต้นฉบับ ข้อความ OCR ดิบ และค่าหลัง normalization เพื่อให้ตรวจย้อนกลับได้

เอกสารที่มีหลายภาษาในหน้าเดียวควรเก็บภาษาของแต่ละฟิลด์ นอกเหนือจากภาษาหลักของเอกสาร เพื่อไม่ให้ข้อผิดพลาดของที่อยู่ภาษาไทยบนแบบฟอร์มอังกฤษถูกกลืนในค่าเฉลี่ย Microsoft เผยแพร่ข้อมูลการรองรับ OCR ที่รวมภาษาไทยและเวียดนาม แต่โมเดล ฟังก์ชัน ภูมิภาค เวอร์ชัน API และสถานะ preview หรือ general availability เปลี่ยนแปลงได้ เอกสารอ้างอิงในบทความนี้ตรวจเมื่อ 26 สิงหาคม 2026 และควรตรวจข้อกำหนดล่าสุดด้วยไฟล์จริงก่อนจัดซื้อ

ฟิลด์สำคัญต้องใช้ exact match และกฎธุรกิจร่วมกัน

ความคล้ายของตัวอักษรไม่เพียงพอสำหรับเงินหรือรหัส 1,000.00 และ 10,000.00 คล้ายกันในเชิงข้อความแต่ต่างกันมากในการจ่ายเงิน ฟิลด์ critical ควรใช้ exact match หลัง normalization ที่อนุมัติ และเสริมด้วยกฎ เช่น

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

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

กำหนด confidence threshold จากข้อมูลจริงและระดับความสำคัญ

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

อย่าหาค่าเดียวที่เรียกว่า “มาตรฐานอุตสาหกรรม” ให้เลือกจากต้นทุนความผิดพลาดและกำลังของผู้ตรวจ เลขบัญชีหรือยอดรวมอาจต้องใช้ threshold สูง กฎธุรกิจ และคนตรวจร่วมกัน ขณะที่หมายเหตุที่ไม่ถูกใช้ต่ออาจใช้ threshold ต่ำกว่าหรือไม่ต้องดึง ตามแนวทางการประเมินของ Google การขยับ threshold เปลี่ยน trade-off ระหว่าง precision กับ recall โดยทั่วไป threshold สูงขึ้นลดการผ่านอัตโนมัติและอาจเพิ่ม precision แต่ recall และ STP อาจลดลง

ขั้นตอนกำหนด threshold

1. แบ่งฟิลด์เป็น critical, controlled และ informational
2. ทดลอง threshold ทีละ 0.01 หรือช่วงที่เหมาะสม
3. คำนวณ precision, recall, F1, STP, leakage และจำนวนงานตรวจใหม่ทุกค่า
4. ดูชั้นข้อมูลที่แย่ที่สุดตามภาษา เอกสาร และคุณภาพภาพ
5. เทียบกับกำลังตรวจต่อวันและ SLA
6. บันทึกค่าที่เลือก เหตุผล ผู้อนุมัติ และเวอร์ชันโมเดล

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

ตัวอย่างคำนวณความแม่นยำ AI-OCR

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

สมมติชุดทดสอบมีสี่กลุ่มภาษา คือ ญี่ปุ่น อังกฤษ ไทย และเวียดนาม มีสามชั้นคุณภาพ คือ good, medium และ poor และแต่ละช่องมี 100 เอกสาร รวมเป็น 4 × 3 × 100 = 1,200 เอกสาร ground truth มีฟิลด์เป้าหมาย 9,600 รายการ สมมติผลคือ TP 9,024, FP 216 และ FN 576:

• Precision = 9,024 ÷ (9,024 + 216) = 97.66%
• Recall = 9,024 ÷ (9,024 + 576) = 94.00%
• F1 = 2 × 97.66% × 94.00% ÷ (97.66% + 94.00%) = 95.80% หลังปัดเศษ

หากฟิลด์สำคัญ 3,480 จาก 3,600 ตรงกันทุกตัวหลัง normalization ค่า critical-field exact match คือ 3,480 ÷ 3,600 = 96.67% หากเอกสาร 684 ฉบับมีฟิลด์บังคับถูกทั้งหมด ค่า document exact match คือ 684 ÷ 1,200 = 57.00% จึงเห็นว่าค่าระดับฟิลด์สูงไม่ได้แปลว่าเอกสารส่วนใหญ่ไม่ต้องแก้ไข

หาก 870 ฉบับผ่านโดยไม่ใช้คน STP คือ 870 ÷ 1,200 = 72.50% หากเอกสาร 9 จาก 870 ฉบับในกลุ่มที่ผ่านอัตโนมัติมีข้อผิดพลาดสำคัญอย่างน้อย 1 จุด leakage คือ 9 ÷ 870 = 1.03% หาก 18 ฉบับประมวลผลไม่ได้ failure rate คือ 18 ÷ 1,200 = 1.50% หากรันซ้ำแล้วเอกสาร 1,188 ฉบับให้ผลเหมือนเดิม repeatability คือ 1,188 ÷ 1,200 = 99.00%

สมมติการเทียบเวอร์ชันทำให้ผล 44 ฟิลด์จาก 9,600 เปลี่ยน version delta คือ 44 ÷ 9,600 = 0.46% โดยดีขึ้น 31 และแย่ลง 13 ซึ่งรวมเป็น 44 พอดี จำนวนดีขึ้นมากกว่าไม่ได้แปลว่าอนุมัติได้ทันที หาก 13 รายการที่แย่ลงเป็นยอดรวมและเลขภาษี การเปลี่ยนรุ่นยังอาจไม่ผ่าน

เปลี่ยนเกณฑ์ตรวจรับให้เป็น gate แยกกัน

ใน สมมติฐานเพื่ออธิบาย เดียวกัน กำหนด F1 ไม่น้อยกว่า 95.00% ความตรงกันของฟิลด์สำคัญไม่น้อยกว่า 99.50% STP ไม่น้อยกว่า 70.00% leakage ไม่เกิน 0.20% failure ไม่เกิน 1.00% และ repeatability ไม่น้อยกว่า 99.00%

ข้อสรุปไม่ควรเป็น “ค่าเฉลี่ยดีจึงอนุมัติ” แต่คือ พักการอนุมัติแบบมีเงื่อนไข แก้ไขแล้วทดสอบใหม่ เพราะข้อผิดพลาดฟิลด์สำคัญ การหลุดรอด และความล้มเหลวเกิน gate แยกงานแก้เป็น preprocessing สำหรับภาพคุณภาพต่ำ threshold ของฟิลด์สำคัญ การตรวจ master data การส่งคิวคน และ retry แล้วรัน holdout ที่ตรึงไว้ซ้ำ พร้อมเพิ่ม challenge case จาก root cause

รวม repeatability และ regression ระหว่างเวอร์ชันไว้ในการตรวจรับ

บริการ AI บนคลาวด์อาจปรับ processor โมเดล API และค่าเริ่มต้นภายใต้ชื่อผลิตภัณฑ์เดิม ควรตรวจ processor list ของ Google และหน้า What’s new ของ Microsoft รวมทั้งบันทึก model ID, API version, region, configuration และโค้ด preprocessing ที่ใช้ทดสอบทุกครั้ง อย่าอาศัยความจำเรื่องภาษา สถานะ preview หรือ general availability ให้ตรวจข้อมูลล่าสุดก่อนตัดสินใจจัดซื้อหรือ release

การทดสอบ repeatability ใช้ไฟล์เดียวกันประมวลผลหลายครั้งภายใต้การตั้งค่าเดียว แล้วเทียบค่าดิบ ค่าหลัง normalize, confidence, geometry และการจับคู่แถว แยกความต่างด้านรูปแบบที่ไม่กระทบงานออกจากความต่างของฟิลด์สำคัญ การเปลี่ยนเวอร์ชันต้องรันรุ่นเก่าและใหม่บน regression set เดียวกัน และตรวจ changed cases ทุกกรณี ไม่ดูเฉพาะค่าเฉลี่ย

หลักฐานขั้นต่ำควรประกอบด้วย:

• โมเดล processor เวอร์ชันโมเดล เวอร์ชัน API และ region
• hash ของไฟล์ เวอร์ชันชุดทดสอบ และเวอร์ชัน ground truth
• เวอร์ชัน preprocessing, normalization, schema, threshold และกฎธุรกิจ
• เวลารัน retry, error response และระยะเวลาประมวลผล
• ผลรวม ผลแยกชั้น รายการที่เปลี่ยน และบันทึกผู้อนุมัติ

NIST AI Risk Management Framework มองการวัด การเฝ้าระวัง การตอบสนองความเสี่ยง และการแบ่งบทบาทระหว่างคนกับ AI เป็นงานกำกับดูแลต่อเนื่อง คะแนน PoC จึงไม่ควรกลายเป็นคำรับรองถาวร ต้องมีการสุ่มตรวจหลังใช้งาน การติดตาม drift การทบทวนเหตุผิดพลาด และ regression gate ก่อนเปลี่ยนรุ่น

6 ระยะของ PoC สำหรับติดตั้ง AI-OCR

ระยะ 1: กำหนดเป้าหมายกระบวนการและต้นทุนข้อผิดพลาด

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

ระยะ 2: เขียนข้อตกลงการประเมิน

กำหนด matching, normalization, TP/FP/FN, การจับคู่ line item, วิธีนับ failure, การแบ่งชั้น, การทดลอง threshold และ acceptance gate ถามผู้ให้บริการว่าส่ง field value, raw text, confidence, bounding region, model/version และ error information ให้ evaluation script เดียวกันได้หรือไม่

ระยะ 3: สร้างเส้นทาง end-to-end ขนาดเล็ก

ยังไม่ควรส่งทุกเอกสารเข้า ERP อัตโนมัติ เริ่มจาก extraction, normalization, rule validation, หน้าจอผู้ตรวจ และ audit log ผู้ตรวจควรเห็นภาพต้นฉบับ ค่าที่ดึง confidence ความต่าง และตัวเลือก master data ในหน้าจอเดียว มิฉะนั้นเวลาตรวจอาจลบผลประโยชน์จากระบบอัตโนมัติ

ระยะ 4: วัด holdout

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

ระยะ 5: ทำ shadow operation

ใช้ข้อมูลจริงแต่ยังให้กระบวนการเดิมเป็นระบบอ้างอิง วัดปริมาณรายวัน STP candidate ภาระผู้ตรวจ leakage, failure, latency และค่า API ตรวจเรื่องข้อมูลอ่อนไหว สถานที่เก็บ สิทธิ์เข้าถึง อายุ log และการลบไปพร้อมกัน

ระยะ 6: ตรวจรับ ขยาย และติดตาม

อนุมัติ gate ข้อยกเว้น ความเสี่ยงคงเหลือ manual fallback, SLA ช่องทางเหตุขัดข้อง และการแจ้งเปลี่ยนโมเดล หลังเปิดใช้ยังต้องสุ่มตรวจกลุ่มผ่านอัตโนมัติ วิเคราะห์ root cause ของข้อผิดพลาดสำคัญ ดูตัวชี้วัดแยกชั้นรายเดือน และทำ regression test ก่อนเปลี่ยนรุ่น

คำถามสำหรับ RFP และการเปรียบเทียบความแม่นยำ OCR

1. ทดสอบเอกสารภาษาญี่ปุ่น อังกฤษ ไทย และเวียดนามที่กำหนดภายใต้เงื่อนไขเดียวกันได้หรือไม่
2. ส่ง field value, raw text, confidence, bounding region, page, processor และ version ได้หรือไม่
3. จับคู่และประเมิน optional field กับ repeating line item อย่างไร
4. confidence มีความหมายอย่างไร สอบเทียบอย่างไร และลูกค้ากำหนด threshold จากข้อมูลจริงได้อย่างไร
5. มีข้อจำกัดใดกับภาพคุณภาพต่ำ การหมุน หลายหน้า หลายภาษา ลายมือ และตราประทับ
6. จัดการ API error, partial extraction, timeout, retry และงานซ้ำอย่างไร
7. เงื่อนไขการเก็บ การใช้ฝึก การเข้ารหัส region, access log และการลบคืออะไร
8. มีการแจ้งอัปเดตโมเดล การตรึงเวอร์ชัน rollback และ regression test หรือไม่
9. วัดเวลาและค่าใช้จ่าย end-to-end รวมคนตรวจและ audit log อย่างไร
10. ผลส่งมอบ PoC รวมคำจำกัดความชุดทดสอบ evaluation code รายการข้อผิดพลาด และแบบการปฏิบัติงานหรือไม่

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

ข้อผิดพลาดที่พบบ่อยและวิธีป้องกัน

เปรียบเทียบเดโมจากเอกสารคมชัดเพียงสิบหน้า

เดโมช่วยให้เข้าใจหน้าจอ แต่ไม่ใช่หลักฐานตรวจรับเชิงสถิติ ต้องใช้ประชากรที่แบ่งชั้น holdout ที่ป้องกันการรั่วไหล และวัด processing failure ด้วย

ถือว่า confidence ของทุกผู้ให้บริการเป็นสเกลเดียวกัน

การคูณ 0–1 เป็น 0–100 ไม่ทำให้ calibration เหมือนกัน ต้องวัดความถูกต้องตามช่วงคะแนนของแต่ละตัวเลือกและกำหนด threshold แยกกัน

ตรวจเฉพาะเอกสารที่ถูกส่งให้คน

วิธีนี้ซ่อนข้อผิดพลาดในกลุ่มผ่านอัตโนมัติ ต้องสุ่มตรวจกลุ่ม confidence สูงและตรวจชั้นความเสี่ยงสูงเพิ่มเติมเพื่อวัด leakage

เก็บเฉพาะค่าหลัง normalization

จะติดตามข้อผิดพลาดของ Unicode และการแปลงได้ยาก ต้องเก็บต้นฉบับ raw output ค่าหลัง normalize และเวอร์ชันกติกา

อนุมัติหลายภาษาจากค่าเฉลี่ยเดียว

ภาษาที่มีจำนวนมากจะครองค่าเฉลี่ย ต้องกำหนด minimum gate แยกภาษา คุณภาพภาพ ประเภทเอกสาร และฟิลด์สำคัญ

FAQ เกี่ยวกับความแม่นยำ AI-OCR

ความแม่นยำ AI-OCR ต้องกี่เปอร์เซ็นต์จึงติดตั้งได้?

ไม่มีตัวเลขเดียวสำหรับทุกองค์กร เพราะขึ้นกับต้นทุนข้อผิดพลาด criticality กำลังคนตรวจ และกฎปลายทาง ควรใช้ F1, critical exact match, leakage, failure และ STP เป็น gate แยกบนเอกสารจริง

เปรียบเทียบความแม่นยำ OCR ควรเน้น precision หรือ recall?

เน้น precision เมื่อค่าผิดที่ถูกส่งต่อมีต้นทุนสูง และเน้น recall เมื่อข้อมูลตกหล่นมีต้นทุนสูง ในทางปฏิบัติใช้ F1 ร่วมกับต้นทุนความผิดพลาด และแยกฟิลด์สำคัญด้วย exact match

ช่องว่างที่ไม่บังคับควรนับอย่างไร?

ไม่ควรเพิ่ม accuracy ด้วยช่องที่ไม่มีอยู่จำนวนมาก ให้กำหนด TP, FP และ FN ชัดเจน และนับค่าที่ระบบสร้างขึ้นสำหรับฟิลด์ที่ไม่มีจริงเป็น FP

ประเมินภาษาญี่ปุ่น อังกฤษ ไทย และเวียดนามใน PoC เดียวได้หรือไม่?

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

confidence threshold มาตรฐานคือเท่าใด?

ไม่มี threshold กลางที่ใช้ข้ามผู้ให้บริการได้ ต้องทดลองค่าตาม criticality และวัด precision, recall, STP, leakage และภาระผู้ตรวจบนข้อมูลของบริษัท

PoC ต้องเชื่อมระบบจริงหรือไม่?

ไม่จำเป็นต้องเปิดใช้จริงทั้งหมด แต่การทดสอบ extraction อย่างเดียววัด STP และเวลาคนไม่ได้ ควรสร้างเส้นทางเล็กที่ผ่าน normalization กฎ การตรวจ และ audit log

สรุป: วัดความแม่นยำ AI-OCR เป็นข้อตกลงตรวจรับขององค์กร

อย่าเลือก AI-OCR ด้วยอัตราการรู้จำที่โฆษณาเพียงค่าเดียว ให้สร้าง holdout ที่แบ่งตามสี่ภาษา ประเภทเอกสาร และคุณภาพภาพ แล้ววัด precision, recall, F1, critical exact match, document exact match, STP, critical-error leakage, failure, repeatability และ version delta ตรึงกติกาวันที่ สกุลเงิน เลขภาษี Unicode และการจับคู่รายการ กำหนด confidence threshold จาก criticality และกำลังคนจริง หาก gate สำคัญไม่ผ่าน ให้พักการอนุมัติ แก้ root cause และทดสอบซ้ำภายใต้ข้อตกลงเดิม

TOMAS TECH สามารถช่วยตั้งแต่ช่วงกำหนดชุดข้อมูลหลายภาษา ground truth ตารางคะแนน PoC และ acceptance gate โดยยังไม่ต้องเลือกผลิตภัณฑ์ก่อน หากต้องการเปรียบเทียบด้วยเอกสารของบริษัทเอง สามารถ ติดต่อ TOMAS TECH เพื่อหารือได้

แหล่งอ้างอิง

• Google Cloud: Evaluate a processor
• Google Cloud: Shared.Types.Metrics
• Google Cloud: Processor list
• Microsoft: Transparency note for Document Intelligence
• Microsoft: OCR language support
• Microsoft: What’s new in Document Intelligence
• AWS: Amazon Textract best practices
• AWS: Responsible AI Service Card—Textract AnalyzeID
• Unicode Consortium: UAX #15 Unicode Normalization Forms
• NIST: Artificial Intelligence Risk Management Framework 1.0

การรองรับบริการ processor โมเดล เวอร์ชัน API ภูมิภาค และสถานะ preview หรือ general availability อาจเปลี่ยนแปลง เอกสารข้างต้นอ้างอิง ณ วันที่ 26 สิงหาคม 2026 โปรดตรวจข้อมูลทางการล่าสุดก่อนเลือกหรือทำสัญญา