เปรียบเทียบ AI-OCR: คู่มือ RFP และ PoC สำหรับโรงงานไทย

การเปรียบเทียบ AI-OCR ไม่ควรตอบเพียงว่าผลิตภัณฑ์ใดอ่านข้อความบนเอกสารตัวอย่างที่สะอาดได้ดีที่สุด สำหรับโรงงานในไทยและอาเซียน คำถามจริงคือแนวทางใดส่งข้อมูลที่ต้องใช้จากใบแจ้งหนี้ ใบสั่งซื้อ ใบตรวจสอบ และใบส่งของเข้าสู่ระบบธุรกิจได้ถูกต้อง ส่งข้อยกเว้นกลับให้คนตรวจได้อย่างปลอดภัย และดำเนินงานต่อเนื่องด้วยต้นทุนที่เหมาะสม บทความนี้อธิบายวิธีเปรียบเทียบ 4 รูปแบบด้วยเอกสาร ชุดให้คะแนน RFP, PoC และหลักฐาน FAT/SAT ชุดเดียวกัน

สรุป: เปรียบเทียบ AI-OCR จากผลลัพธ์ทางธุรกิจ ไม่ใช่อัตราอ่านข้อความตัวเดียว

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

เปลี่ยนหน่วยที่นำมาเปรียบเทียบจาก “OCR engine” เป็นกระบวนการตั้งแต่รับเอกสาร อ่าน ตรวจสอบ ส่งให้คนทบทวน ส่งออก และเก็บหลักฐาน แล้วแบ่งทางเลือกอย่างน้อย 4 รูปแบบ:

1. OCR หรือการอ่านข้อความอย่างเดียว
2. โมเดลสำเร็จรูปสำหรับเอกสาร ฟอร์ม หรือตาราง
3. การดึงข้อมูลแบบกำหนดแน่นอนและปรับเฉพาะเอกสารลูกค้า
4. การเข้าใจเอกสารด้วย Generative AI หรือ multimodal พร้อม grounding และ human review

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

4 รูปแบบที่ต้องแยกเมื่อเปรียบเทียบ AI-OCR

คำว่า AI-OCR อาจหมายถึงบริการที่คืนคำและพิกัด โมเดลใบแจ้งหนี้สำเร็จรูป custom extractor หรือโมเดลสร้างเนื้อหาที่ตีความเอกสารหลากหลาย แม้อยู่ในใบเสนอราคาเดียวกัน แต่ผลลัพธ์ งานติดตั้ง พฤติกรรมเมื่อเอกสารเปลี่ยน และหลักฐานที่ตรวจสอบได้ไม่เหมือนกัน

รูปแบบ 1: รวมงาน downstream ในราคา OCR ที่อ่านข้อความอย่างเดียว

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

หน้า pricing สาธารณะของ Google Cloud ณ วันที่ 2 กันยายน 2026 ระบุ Enterprise Document OCR 0–1,000 หน้าแรกฟรี จากนั้น tier 1,000–5,000,000 หน้าอยู่ที่ USD 1.50 ต่อ 1,000 หน้า ตัวอย่างทางการของ AWS Textract ใน US West (Oregon) ระบุ Detect Document Text ที่ USD 0.0015 ต่อหน้า ตัวเลขเหล่านี้เป็นข้อมูลสาธารณะตามวันเข้าถึง ไม่ใช่ใบเสนอราคา ภูมิภาค tier ฟังก์ชัน สัญญา ภาษี และอัตราแลกเปลี่ยนอาจทำให้ต่างออกไป และยังไม่รวมงานบางส่วน เช่น classification, field mapping, review, storage และ integration

รูปแบบ 2: ทดสอบ “ฟิลด์ที่ต้องใช้” ไม่ใช่แค่ “ฟิลด์ที่มี”

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

คู่มือเลือกโมเดลของ Azure วางตำแหน่ง Document Intelligence สำหรับการดึงข้อมูลแบบกำหนดแน่นอนในปริมาณสูงจากเอกสาร structured/semi-structured และ Content Understanding สำหรับข้อมูลที่หลากหลายหรือ multimodal รวมถึงฟิลด์ที่อนุมานหรือสร้างขึ้น นี่คือแนวทางผลิตภัณฑ์จากผู้ขายเอง ไม่ใช่ benchmark อิสระ ใน RFP จึงต้องระบุโมเดล API version ภูมิภาค ภาษา และ output schema ของสิ่งที่เสนอจริง

รูปแบบ 3: วัดค่าบำรุงรักษา custom extraction และการทดสอบซ้ำ

Custom extraction ที่ใช้ข้อมูลติด label, template หรือ rule อาจให้ผลสม่ำเสมอกับใบตรวจ ป้าย หรือ PO ของ supplier ที่มีรูปแบบเฉพาะ แต่จะมีต้นทุนเมื่อรับ supplier ใหม่ เปลี่ยน version layout เปลี่ยนสภาพการถ่ายภาพ retrain และทำ regression test

คะแนน PoC ครั้งเดียวใช้ไม่ได้หากนำเอกสาร train มาปนกับ acceptance set ต้องแยกข้อมูล train, tuning และ final acceptance เก็บชุดสุดท้ายเป็น blind หรือ held-out ไม่ใช้ปรับระบบ ถามจำนวน label เวลา ผู้รับผิดชอบ การทดสอบหลังเปลี่ยนโมเดล และวิธีกลับสู่เวอร์ชันก่อน

รูปแบบ 4: กำหนด grounding และ review สำหรับ Generative AI

Generative AI หรือ multimodal ช่วยจัดประเภทเอกสารแปลกใหม่ ใช้บริบทจากหลายตำแหน่ง และเสนอค่าที่ชื่อ field ไม่คงที่ได้ แต่ต้องจัดการค่าที่ดูน่าเชื่อแต่ไม่มีหลักฐาน ความแกว่งของผล การเปลี่ยนโมเดล latency และความสามารถในการอธิบาย

ระบุให้ชัดว่าถ้าไม่พบข้อมูลต้องคืน null หรือเสนอค่าที่อนุมานได้ เชื่อมค่าที่สำคัญกับหน้า ตำแหน่ง และข้อความต้นฉบับ ตรวจ supplier, PO, currency, tax และ total กับ master data และสมการที่กำหนด หากหลักฐานไม่พอหรือขัดกับ rule ต้องส่งให้คนตรวจ ความสามารถด้านภาษาไม่เท่ากับสิทธิ์บันทึกเข้าระบบบัญชีโดยอัตโนมัติ

สร้างและแช่แข็งชุดทดสอบเอกสารที่เป็นตัวแทน

ความยุติธรรมของการเปรียบเทียบขึ้นกับ test set มากกว่า brochure หากให้ผู้ขายเลือกเฉพาะเอกสารที่ถนัดหรือ demo ด้วย PDF สะอาด อันดับย่อมเปลี่ยนได้ง่าย ต้องจัดชุดที่สะท้อนความหลากหลายจริง ใส่ version และ hash แล้วห้ามเปลี่ยนระหว่างการให้คะแนน

แบ่งชั้นตาม:

• ประเภท: ใบแจ้งหนี้ PO ใบส่งของ ใบตรวจ ใบรับ และป้ายสินค้า
• ผู้ออก: supplier หลัก รายย่อย รายใหม่ ลูกค้า และไซต์ภายใน
• ภาษา: ไทย อังกฤษ ญี่ปุ่น เวียดนาม และหลายภาษาในหน้าเดียว
• ช่องทาง: native PDF, scan, ภาพโทรศัพท์ และไฟล์แนบ e-mail
• หน้า: หน้าเดียว หลายหน้า มีหน้าต่อ ขาดหน้า และสลับลำดับ
• Layout: รุ่นปัจจุบัน รุ่นเก่า ตำแหน่งเลื่อน และตารางต่อหน้า
• การเขียน: ลายมือ ตราประทับ การแก้ไข หมายเหตุ ข้อความแนวตั้ง และสัญลักษณ์พิเศษ
• คุณภาพภาพ: เบลอ noise มืด ตัวอักษรจาง/เล็ก ถูกตัด แสงสะท้อน และเอียง

Google Enterprise Document OCR มี image-quality analysis แบบเลือกใช้ ให้คะแนน 0 ถึง 1 และ flag เช่น blur, noise, darkness, faint text, small text, cutoff และ glare เอกสารทางการระบุด้วยว่าอาจเกิด false positive และมีข้อจำกัดกับแสงสะท้อนเฉพาะจุด ค่านี้ไม่ใช่ความถูกต้องทางธุรกิจ แต่ช่วยแยกปัญหาการ capture ออกจากปัญหา extraction ได้

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

ตรวจ ground truth สองชั้น

หาก label คำตอบผิด ผลลัพธ์ที่ถูกจะถูกหักคะแนน ให้คนหนึ่งทำ label อีกคนตรวจเทียบต้นฉบับ และให้ process owner ตัดสินข้อขัดแย้ง Data dictionary ต้องนิยามชื่อ field ชนิดข้อมูล required/optional ค่าซ้ำ null และขอบเขตบรรทัด

กำหนด normalization ก่อนเห็นผล สำหรับ identifier ต้องตัดสินใจเรื่องเลขศูนย์นำหน้า ช่องว่าง ขีด และตัวพิมพ์ สำหรับจำนวนเงินกำหนดทศนิยม การปัด ตัวคั่น และค่าติดลบ สำหรับวันที่กำหนดวัน/เดือน พ.ศ./ค.ศ. และวันที่กำกวม หากเปลี่ยนกฎหลังเห็นคะแนนจะไม่สามารถทำซ้ำได้

วัดความแม่นยำ AI-OCR แยกตามฟิลด์และกระบวนการ

คำว่า “แม่นยำ 99%” ไม่บอก denominator เอกสารที่ใช้ เคสที่ตัดออก หรือจำนวนความผิดพลาดร้ายแรง ให้ character accuracy เป็นตัวช่วย และใช้ business-field กับ document-flow เป็นหลัก อ่านแนวคิดเพิ่มเติมได้ใน คู่มือวัดความแม่นยำ AI-OCR

อย่างน้อยต้องรายงาน exact match หรือ precision/recall ราย field, document straight-through-processing rate, false auto-accept rate, manual-review rate, unresolved rate, duplicate/export error rate และ end-to-end cycle time อย่าตัดเอกสารที่ประมวลผลล้มเหลวออกจาก denominator แล้วแสดงความแม่นยำเฉพาะค่าที่ตอบกลับ

คู่มือ accuracy/confidence ของ Azure อธิบาย confidence ว่าเป็น estimated probability และเสนอให้ส่ง field confidence ต่ำไป human review รวมทั้งให้ใส่ความแปรผันด้านภาพและ layout ในการ train/evaluate อย่างไรก็ตาม confidence 0.90 ของ vendor A ไม่จำเป็นต้องเท่ากับ 0.90 ของ vendor B ต้อง calibrate กับความถูกต้องจริงบน labelled set เดียวกันก่อนตั้ง threshold

ค่าผิดที่ confidence สูงอันตรายเพราะอาจผ่าน review ใช้ deterministic business rule ร่วมด้วย เช่น subtotal + tax = total, supplier และ currency ตรงกับ PO, ผลรวม line ตรงกับ header แม้โมเดลมั่นใจแต่ขัด rule ก็ต้องไม่ auto-post

ตรวจหลายภาษาในระดับโมเดลและฟังก์ชัน

รายการ processor ของ Google ระบุ Enterprise Document OCR เป็น GA รองรับมากกว่า 200 ภาษา รวม printed Japanese, Thai และ Vietnamese การอ่านตัวอักษรทั่วไปได้ไม่ได้พิสูจน์ว่าจะดึง field จากใบแจ้งหนี้ ลายมือ หรือตารางหลายภาษาของลูกค้าได้ ต้องใช้เอกสารจริงพิสูจน์

ข้อจำกัดทางการของ Amazon Textract ระบุภาษาสำหรับ text detection คือ English, French, German, Italian, Portuguese และ Spanish และ handwritten recognition รองรับ English เท่านั้น นี่เป็น fit gate สำคัญหาก scope มีไทย ญี่ปุ่น หรือเวียดนาม เอกสารเดียวกันระบุ synchronous PDF/TIFF ได้ 1 หน้าและ 10 MB ใน memory ส่วน asynchronous รองรับถึง 500 MB และ 3,000 หน้า ต้องทดสอบขนาด จำนวนหน้า latency และ integration จริง

หน้า What’s New ของ Azure Document Intelligence ระบุ Thai และ Vietnamese locale สำหรับ invoice model และ currency code ของไทย/เวียดนาม แต่ยังต้องยืนยันกับ model/API version และ region ที่เสนอ ห้ามสรุปจากคำว่า “รองรับหลายภาษา” ในระดับผลิตภัณฑ์รวม

เปลี่ยนราคา AI-OCR เป็น TCO รายเดือน

ราคา API เป็นเพียงส่วนหนึ่ง ใช้สูตรเดียวกันสำหรับทุกข้อเสนอ:

TCO รายเดือน = ค่า API/processor + capture/classification + storage/network + integration/monitoring + บำรุง model/template + human review + แก้ข้อผิดพลาด/reprocess + งาน security/compliance

ณ วันที่ 2 กันยายน 2026 หน้า Google ระบุ Form Parser และ Custom Extractor ที่ USD 30 ต่อ 1,000 หน้า สำหรับ 1 ล้านหน้าแรก และ Layout Parser ที่ USD 10 ต่อ 1,000 หน้า ตัวอย่าง Oregon ของ AWS ระบุ Forms ที่ USD 0.05 ต่อหน้า และ Tables ที่ USD 0.015 ต่อหน้าใน 1 ล้านหน้าแรก หากใช้ Forms + Tables ต้องรวมทั้งสองฟังก์ชัน ตัวเลขเหล่านี้ไม่ได้หมายถึง output scope เท่ากัน ระบุวันที่ region ฟังก์ชัน tier ภาษี และสมมติฐาน ห้ามแปลงเป็น THB โดยไม่ระบุอัตราแลกเปลี่ยน

ตัวอย่างคำนวณภายในแบบสมมติ

ต่อไปนี้เป็นตัวอย่างออกแบบ ไม่ใช่ค่าเฉลี่ยตลาดหรือใบเสนอราคาผู้ขาย

• 50,000 หน้า/เดือน
• งาน manual: 3 นาที/หน้า ที่ 180 THB/ชั่วโมง
• ค่าแรง manual: 50,000 × 3 ÷ 60 × 180 = 450,000 THB/เดือน
• ทางเลือก A: straight-through 60%; อีก 40% review ที่ 1.5 นาที/หน้า
• ค่าแรง review A: 50,000 × 40% × 1.5 ÷ 60 × 180 = 90,000 THB/เดือน
• ทางเลือก B: straight-through 80%; อีก 20% review ที่ 1.5 นาที/หน้า
• ค่าแรง review B: 50,000 × 20% × 1.5 ÷ 60 × 180 = 45,000 THB/เดือน
• ส่วนต่างค่าแรง review: 90,000 − 45,000 = 45,000 THB/เดือน

ถ้า error/rework และ risk เท่ากัน ค่า platform premium ของ B ที่ต่ำกว่า 45,000 THB/เดือนอาจสมเหตุผล แต่หาก B มี false auto-accept มากกว่า บำรุงแพงกว่า หรือช้าช่วง peak ต้องคำนวณใหม่ ตัวอย่างนี้ไม่ใช่คำรับรอง payback period แบบสากล

วัดเวลา review ตั้งแต่เปิดเคส เทียบต้นฉบับ แก้ และจัดการ ERP error หากเหลือแต่เคสยาก แม้จำนวน review ลด เวลาเฉลี่ยต่อเคสอาจเพิ่ม แยกค่า implementation, migration, training และ parallel run ออกจากค่า steady-state

แนบ scorecard ที่ทำซ้ำได้กับ RFP

คะแนนถ่วงน้ำหนักช่วยจัดการตัดสินใจ แต่ห้ามกลบความผิดพลาดร้ายแรงด้วยค่าเฉลี่ย ให้ใช้ mandatory gate ก่อน แล้วจึงให้คะแนนเฉพาะผู้ที่ผ่าน ตัวอย่างต่อไปนี้เป็น proposed acceptance design ไม่ใช่ external benchmark

ตัวอย่าง mandatory release gate

• ใน frozen acceptance set ไม่มี critical wrong auto-post แม้แต่ 1 เคส
• ทุก low-confidence หรือ business-rule conflict ถูกส่งเข้า review
• record ที่ export ย้อนกลับไป source page และ field evidence ได้
• ส่ง input ซ้ำแล้วไม่สร้าง record ซ้ำและตรวจ idempotency ได้
• ติดตาม human correction, model/configuration version และ retest ได้
• ผ่านเงื่อนไขภาษา ไฟล์ จำนวนหน้า และ region ที่บังคับ

คำว่า “0 เคส” ใช้กับชุด acceptance แบบจำกัดที่ลูกค้ากำหนดเท่านั้น ไม่ได้รับประกันว่าจะไม่มี defect ใน production จึงยังต้อง rollout ทีละขั้นและ monitor

ผูกคะแนนกับ test-case ID, log, หน้าจอ, API output และรายการราคา ไม่ใช่ข้อความขาย แปลง output ของแต่ละ vendor เป็น schema เดียวและเก็บ raw result เพื่อปรับน้ำหนักภายหลัง การแสดง unknown กับ disqualification ชัดเจนมีประโยชน์กว่าคะแนนทศนิยมที่ดูแม่นเกินจริง

สิ่งที่ต้องเขียนใน RFP สำหรับนำ AI-OCR มาใช้

1. Document inventory: ชนิด รุ่น ผู้ออก ภาษา volume peak และจำนวนหน้า
2. ช่องทาง input: e-mail, shared folder, scanner, phone และ API
3. Output schema: field, type, required, normalization, tolerance และ line
4. ระบบปลายทาง: ERP, accounting, purchasing, quality, DMS และขอบเขต
5. Exception flow: คนตรวจ หลักฐานที่เห็น วิธีแก้ และทางกลับ
6. Data: location, encryption, access, retention, deletion และ training use
7. Evidence: source, region, value, confidence, rule, correction และ export ID
8. Non-functional: throughput, peak, response, availability, monitoring, support
9. Change control: model/API version, notice, regression และ rollback
10. ราคา: หน่วยขั้นต่ำ add-on, support, review และค่า environment
11. PoC: frozen data, scorer, blind/held-out, ระยะเวลา deliverable และ gate
12. Exit: การคืนและลบ data, configuration, label และ log

ห้ามผู้ขายเลือกแต่เอกสารสะอาด และให้มี blind/held-out record ที่ลูกค้าเลือก แปลง output ทุกเจ้าเป็น JSON/CSV schema เดียวแล้วรัน scorer เดิม แนวทางนี้ทำซ้ำได้มากกว่าการให้คนต่างกลุ่มดู interface ของแต่ละเจ้า

เรื่องทีมงาน rollout ทีละขั้นและการปฏิบัติหลังเลือก ดู คู่มือการนำ AI-OCR มาใช้ และใช้ scorecard ในบทความนี้เป็น workstream ด้าน selection/acceptance

ให้ PoC แสดง failure ไม่ใช่เฉพาะ happy path

PoC ต้องพิสูจน์ว่าระบบหยุดอย่างปลอดภัย เก็บหลักฐาน และฟื้นตัวได้ ให้สาธิต:

• blur, cutoff, glare ถูกส่งกลับไป recapture
• unsupported language หรือ unknown layout ไม่ถูกบังคับใส่ field
• ตารางต่อหน้า หน้าเอกสารขาดหรือสลับลำดับ
• ส่งไฟล์เดิมซ้ำแล้วไม่ export ซ้ำ
• timeout, partial success, rate limit แล้ว retry อย่างปลอดภัย
• supplier, PO, currency หรือ total ขัดกันแล้วส่ง review
• เก็บค่าเดิม/ใหม่ เหตุผล ผู้แก้ และเวลา
• ใช้ frozen set เดิมหลังเปลี่ยน model/API version
• rollback ไปเวอร์ชันเดิมหรือ manual route เมื่อผลแย่ลง

Trace input ID, dataset version, model/configuration version, เวลา, output, rule result, review และ final record ID ภาพหน้าจออย่างเดียวทำซ้ำไม่ได้ ต้องรับ machine-readable output และ scoring result

แยก FAT กับ SAT

FAT ทดสอบ extraction, rule, API, evidence และ failure ในสภาพแวดล้อมควบคุม ส่วน SAT ทดสอบ identity, network, scanner/e-mail/file จริง, ERP/API integration, คน review, monitoring และ backup ในสภาพแวดล้อมลูกค้า

PDF เดียวกันอาจผ่าน FAT แต่ resolution เครื่องสแกน ชื่อไฟล์ latency สิทธิ์ service account, ERP master หรือเวลาทำงานของ reviewer ทำให้ SAT ต่างไป ทดสอบ peak, partial outage, งานกลางคืน และ manual fallback ด้วย

เก็บ frozen set หลังรับมอบ และ rerun เมื่อ model, template, rule, scanner หรือ ERP schema เปลี่ยน เอกสาร layout ใหม่ควรอยู่ใน review-only จนมีหลักฐานพอที่จะขยาย automation บันทึก version และผลที่อนุมัติการขยายทุกครั้ง

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

เปลี่ยนผลประเมินเป็นเอกสารอนุมัติและสัญญา

Scorecard ทางเทคนิคอย่างเดียวไม่พอให้ผู้บริหารตัดสินใจลงทุนหรือฝ่ายจัดซื้อกำหนดขอบเขตที่บังคับใช้ได้ ต้องเชื่อมรูปแบบที่เลือก ผลต่อธุรกิจ residual risk เจ้าของงาน สมมติฐานต้นทุน และ release condition ใน decision record เดียว

เริ่มจากเขียนขอบเขตหนึ่งประโยค เช่น “ดึง header และ line จากใบแจ้งหนี้ที่ supplier ที่กำหนดส่ง e-mail เข้าโรงงานไทย ตรวจ PO, supplier, currency และ amount แล้วส่งเฉพาะ record ที่ไม่ขัดกันไป ERP-ready queue โดยฝ่ายบัญชียังคงสิทธิ์ final posting” กำหนด denominator ของ automation ว่าเป็นไฟล์ที่รับทั้งหมด เอกสาร in-scope หรือเอกสารที่ข้อมูลครบ และรายงานสิ่งที่ตัดออกพร้อมเหตุผล

จากนั้นอนุมัติ severity ก่อนทดสอบ ใส่ตัวอย่าง minor, correctable, critical และ release-stopping ช่องว่างอาจเป็น minor แต่ผิดบริษัท ผิดสกุลเงิน record ซ้ำ หรือค่าที่ไม่มี source evidence อาจ critical ให้ business, accounting, quality, IT และ security owner อนุมัติ stop condition และกำหนดผู้ตัดสินเมื่อเห็นต่าง

สร้าง evidence register แยก vendor claim, การดู configuration, ผลวัด PoC, ข้อผูกพันในสัญญา และ unverified ภาษาที่อยู่ใน support list ไม่ใช่ field accuracy ของลูกค้า ปุ่ม delete ไม่ใช่เวลาลบตามสัญญาที่ครอบคลุม backup/log

จัด unverified แยกจากคะแนนต่ำ เพราะ “ทำไม่ได้” กับ “ยังไม่มีหลักฐาน” ต้องใช้ action ต่างกัน กำหนด owner และ due date สำหรับสิ่งที่ต้องปิดก่อน contract และสิ่งที่ปิดใน SAT

ทำ sensitivity analysis ด้วย Weight เป็นการสะท้อน priority ไม่ใช่ค่าคงที่ หากเปลี่ยน field accuracy จาก 25% เป็น 35% หรือ TCO 3 ปีจาก 15% เป็น 25% แล้วอันดับสลับ ให้เสนอแบบมีเงื่อนไข ไม่ใช่ประกาศผู้ชนะสากล คำนวณ low/base/high สำหรับ volume, review minute, exchange rate, supplier growth และ reprocessing

เก็บเหตุผลของทางเลือกที่ไม่เลือกด้วย ระบุ dataset version, field/gate ที่ไม่ผ่าน และเงื่อนไขกลับมาพิจารณา ใส่ข้อจำกัดในทางเลือกที่เลือก เช่น ใบแจ้งหนี้ไทยพิมพ์เข้าสู่ auto-post candidate ได้ ลายมือต้อง review เสมอ layout เวียดนามรุ่นเก่ายัง out of scope และ supplier ใหม่อยู่ review-only ช่วงสังเกต การเลือกอนุมัติเฉพาะ scope ที่ทดสอบ ไม่ใช่ผลิตภัณฑ์ทั้งหมด

สุดท้าย ผูก payment milestone กับ acceptance evidence และ deliverable ได้แก่ data dictionary, common schema, labelling policy, test-set version, scorer, ผลทั้งหมด, exception, operation procedure, monitoring, incident procedure และ regression method อย่าสร้างแรงจูงใจให้ overfit acceptance set ที่เปิดเผย ต้องยืนยัน processing rule เดียวกันกับ held-out record ด้วย ฝ่ายจัดซื้อ กฎหมาย และข้อมูลต้องตรวจเงื่อนไขสุดท้ายตามกฎที่ใช้

Scorecard จึงกลายเป็น decision record ระยะยาวว่าอนุมัติ scope ใด ใครอนุมัติ ด้วยหลักฐานอะไร และเหลืองานใด การเพิ่ม layout หรือการต่อสัญญาจะเป็น controlled change แทนการเริ่มถกใหม่ทั้งหมด

20 คำถามที่ต้องขอหลักฐานจากผู้ขาย

1. สิ่งที่เสนอเป็น read-only, prebuilt, custom หรือ generative?
2. Model, API version, region, language และ sync/async limit คืออะไร?
3. ทุกค่ากลับไปยังหน้าและ source region ได้หรือไม่?
4. เมื่อไม่พบค่าจะคืน null หรือค่าที่อนุมาน?
5. Confidence หมายถึงอะไรและ calibrate กับชุดเราอย่างไร?
6. Rule แบบ deterministic หยุดค่าผิดที่ confidence สูงได้หรือไม่?
7. จะทดสอบไทย ญี่ปุ่น อังกฤษ เวียดนามที่ปนกันอย่างไร?
8. เงื่อนไขของลายมือ ตรา การแก้ไข และตารางหลายหน้าคืออะไร?
9. แยก capture failure จาก extraction failure อย่างไร?
10. ยอมรับ blind/held-out record ที่ลูกค้าเลือกหรือไม่?
11. ใครเป็นเจ้าของ training data, label, configuration, prompt?
12. Supplier/layout ใหม่ใช้เวลาและราคาเท่าไร?
13. Retry หลัง partial success รักษา idempotency อย่างไร?
14. หน้า review แสดง source, value, evidence และ rule conflict พร้อมกันหรือไม่?
15. เก็บ correction เพื่อ regression test ได้หรือไม่?
16. เงื่อนไข storage, location, retention, deletion, training use, subprocessor คืออะไร?
17. Classification, storage, monitoring, support ใดอยู่นอก quote?
18. แจ้ง model/service change เมื่อใดและอย่างไร?
19. Manual fallback, recovery objective และ rollback เป็นอย่างไร?
20. ตอน exit คืน data, log, setting, label รูปแบบใด?

อย่ายอมรับคำว่า “รองรับ” โดยไม่มีโมเดล เงื่อนไข ผลทดสอบ ข้อจำกัด และราคา ฟังก์ชันอาจมีในผลิตภัณฑ์แต่ไม่มีใน plan หรือ region ที่เสนอ กำหนดไว้ก่อนว่า unanswered item คือ fail, 0 คะแนน หรือ action ใน PoC

FAQ การเปรียบเทียบ ราคา และความแม่นยำ AI-OCR

ก่อนเปรียบเทียบ AI-OCR ต้องเตรียมอะไร?

เตรียม document inventory, required-field schema, frozen test set, ground truth ที่ตรวจแล้ว, normalization, severity และ exception flow ก่อนรายชื่อ vendor มิฉะนั้นแต่ละเจ้าจะแสดงคนละตัวอย่างและ metric

AI-OCR ต้องแม่นยำกี่เปอร์เซ็นต์จึงใช้ production ได้?

ไม่มี threshold สากล วัด supplier, invoice number, currency, tax แยกกันและติดตาม false auto-accept การ review เฉพาะ low confidence ไม่จับ error ที่ confidence สูง จึงต้องมี business rule ด้วย

เปรียบเทียบราคา AI-OCR จาก API อย่างเดียวได้ไหม?

ไม่ได้ ต้องรวม capture, classification, storage, integration, monitoring, maintenance, human review, rework และ security operation หากแปลงสกุลเงินต้องระบุอัตราและวันที่ และตรวจว่า API ที่เปรียบเทียบให้ output scope เดียวกันหรือไม่

Generative document AI ดีกว่า OCR เดิมเสมอไหม?

ไม่เสมอ เหมาะกับเอกสารหลากหลายและบริบท แต่ prebuilt/custom/rule อาจคาดการณ์ง่ายกว่าสำหรับ schema คงที่ เปรียบเทียบ grounding, inference error, review, latency และ TCO บนชุดเดียวกัน

PoC เอกสาร OCR ต้องใช้กี่ใบ?

ไม่มีจำนวนเดียว ความครอบคลุม supplier ภาษา layout defect และข้อยกเว้นเสี่ยงสำคัญกว่ายอดรวม รายงาน uncertainty และเงื่อนไขที่ยังไม่ทดสอบ พร้อมเพิ่มข้อมูลใน strata ที่น้อย

Confidence สูงพอให้ auto-post หรือไม่?

ยังไม่พอจนกว่าจะ calibrate ด้วย labelled set เดียวกันและตรวจ critical error Confidence ไม่ใช่ business accuracy และเทียบตรงข้าม vendor ไม่ได้ ต้องใช้ master-data, arithmetic และ duplicate check

ระบุว่ารองรับภาษาไทย แปลว่าใช้กับใบแจ้งหนี้ไทยได้หรือไม่?

เป็นเพียงจุดเริ่ม Printed OCR, handwriting, invoice model, table และ mixed language อาจรองรับต่างกัน ต้องตรึง model, version, region และทดสอบ field บนเอกสารไทยจริง

FAT ต่างจาก SAT อย่างไร?

FAT ตรวจ extraction, rule, API และ evidence ใน controlled environment SAT ตรวจ identity, network, ช่องทางจริง, ERP, reviewer และ monitoring ที่ไซต์ลูกค้า ทั้งสองเชื่อม demo accuracy กับ production operation

สรุป: เอกสารเดียวกัน scorer เดียวกัน และ gate เดียวกัน

ศูนย์กลางของการเปรียบเทียบ AI-OCR คือเอกสารลูกค้าที่แช่แข็งและผลลัพธ์ end-to-end ไม่ใช่ recognition rate ใน brochure หรือค่า API ขั้นต่ำ เปรียบเทียบ OCR-only, prebuilt, custom และ generative จาก critical field, false auto-accept, review, unresolved, evidence, integration, change และ TCO รายเดือน

ใส่ common schema, blind/held-out set, mandatory gate, pricing assumptions, failure demonstration, FAT/SAT และ exit terms ใน RFP และระบุ threshold ภายในว่าเป็นค่าที่ออกแบบเฉพาะกระบวนการ ไม่ใช่ benchmark สากล ผลลัพธ์คือการจัดซื้อที่มีหลักฐานทำซ้ำได้แทนความประทับใจจาก PoC

TOMAS TECH ช่วยทีมโรงงานในไทยจัดทำ document inventory, comparison scorecard, RFP และ PoC acceptance package ก่อนเลือกผลิตภัณฑ์ได้ หากยังอยู่ในขั้นกำหนด required field และ exception flow สามารถ ติดต่อเรา เพื่อหารือการออกแบบการประเมิน

เอกสารอ้างอิง

• Google Cloud Document AI pricing (เข้าถึง 2 กันยายน 2026)
• AWS Textract pricing (เข้าถึง 2 กันยายน 2026)
• Azure Document Intelligence: Choose a model or feature
• Azure Document Intelligence: Accuracy and confidence
• Google Document AI processor and detail list
• Google Enterprise Document OCR
• Amazon Textract quotas and limits
• Azure Document Intelligence: What’s new