iApp OCR หรือ Typhoon OCR: เอกสารไทยคนละแบบเปลี่ยนผู้ชนะ

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

ถ้าหน้ามีลายมือ หรือระบบปลายทางต้องการข้อความที่คงโครงสร้างเป็น Markdown ให้พิจารณา Typhoon OCR 1.5 ตามเอกสาร OCR ของ Typhoon รุ่นนี้เป็นโมเดลขนาด 2B รับภาพ PNG, JPEG และเอกสาร PDF โดยตัวช่วยประมวลผลคืน Markdown ที่รักษาเค้าโครงไว้ ความต่างที่มีผลต่อการเลือกจึงอยู่ทั้งที่สิ่งซึ่งอ่านได้ รูปแบบผลลัพธ์ และงานที่ต้องทำต่อหลัง OCR; คะแนนรวมเพียงค่าเดียวตอบแทนเงื่อนไขเหล่านี้ไม่ได้

งานพิมพ์: ข้อความที่ถูกต้องต้องอยู่ในไฟล์ที่ใช้ต่อได้

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

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

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

ลายมือ: ความสามารถของผลิตภัณฑ์ต้องมาก่อนอันดับทดสอบ

แบบฟอร์มที่มีช่องกรอกด้วยปากกาทำให้เงื่อนไขเปลี่ยนทันที เพราะบริการเอกสารทั่วไปของ iApp ระบุขอบเขตไว้ที่ข้อความพิมพ์ ส่วน Typhoon OCR 1.5 มีผลประเมินบนลายมือ: รายงานวิจัยของ Paxa Labs ให้ค่ามัธยฐานความผิดพลาดระดับอักขระ 19.36% บนชุดลายมือของรายงาน และ 6.2% บนชุดงานอ่านที่คัดจาก ThaiOCRBench ค่า CER ยิ่งต่ำยิ่งดี แต่ตัวเลขสองค่านี้มาจากเอกสารคนละกลุ่ม จึงไม่ใช่อัตราความผิดพลาดที่คาดว่าจะเกิดกับแบบฟอร์มทุกชนิด

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

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

ตารางและเค้าโครง: ต้องรักษาความสัมพันธ์ ไม่ใช่แค่อักขระ

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

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

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

คะแนนใดเปรียบเทียบกันได้

ในการประเมินThaiOCRBench Small ของ Scholarity เมื่อ 25 กุมภาพันธ์ 2026 คะแนนรวมของ iApp OCR อยู่ที่ 0.491 และ Typhoon OCR ที่ 0.452 แต่ผลแยกประเภทเปลี่ยนภาพ: งาน OCR เต็มหน้าได้ 0.933 เทียบกับ 0.881 ตามลำดับ ขณะที่งานดึงข้อความลายมือ Typhoon ได้ 0.331 เทียบกับ iApp 0.321 คะแนนเหล่านี้เป็นผลของระบบที่โครงการเรียกใช้ในวันทดสอบ ไม่ใช่การรับรองว่าบริการ iApp รุ่นปัจจุบันรองรับลายมือ

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

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

การติดตั้งและที่อยู่ของข้อมูลเปลี่ยนต้นทุนอีกชั้น

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

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

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

ตัวอย่าง 1,000 หน้า: ราคา OCR กับเวลารอไม่ใช่ตัวเลขเดียวกัน

สมมติว่ามีเอกสารพิมพ์ 1,000 หน้าและทุกหน้าคิดค่าบริการตามอัตราที่ประกาศไว้ การขอข้อความล้วนจาก iApp เป็น 49 IC ส่วนการขอผลลัพธ์แบบเค้าโครงหรือไฟล์ที่สร้างใหม่ทุกหน้าเป็น 150 IC ต่างกัน 101 IC หากมีเพียง 200 หน้าที่ต้องเก็บเค้าโครง และอีก 800 หน้าต้องการข้อความล้วน ค่า OCR ตามสมมติฐานจะเป็น 69.2 IC การแยกประเภทหน้าจึงลดค่าเรียกใช้ได้โดยไม่ต้องลดรายละเอียดในหน้าที่จำเป็น

ตัวเลขดังกล่าวเป็นค่าประมวลผลตามหน้า ยังไม่รวมการตรวจแก้ การจัดเก็บ และการแปลงไฟล์หลัง OCR เวลามัธยฐานต่อหน้าของ iApp ก็ไม่ใช่เวลาที่รับประกันว่าจะปิดงานทั้งชุดได้ เพราะการส่งไฟล์ การเข้าคิว และชนิดเอาต์พุตมีผลต่อเวลารวม สำหรับ Typhoon endpoint ขีดจำกัดที่เผยแพร่คือ 20 คำขอต่อนาที; หากสมมติให้ตัวช่วยเรียกหนึ่งหน้าต่อหนึ่งคำขอ งาน 1,000 หน้าจะติดเพดานอย่างน้อย 50 นาที ก่อนบวกเวลาประมวลผลและการลองใหม่ นี่เป็นขอบล่างของสถานการณ์สมมติ ไม่ใช่เวลาทำงานที่วัดได้

จึงยังแปลง Typhoon เป็นราคา IC ต่อหน้าเพื่อเทียบตรงกับ iApp ไม่ได้จากข้อมูล endpoint ที่ใช้ในที่นี้ ขีดจำกัดคำขอเป็นเรื่องกำลังรับงาน ไม่ใช่ราคาต่อหน้า และต้นทุนรันเองขึ้นกับเครื่องที่จัดหา หากงานมีหน้าลายมือมาก ค่าใช้จ่ายตรวจทานอาจสำคัญกว่าค่าเรียก OCR; หากงานเป็นหน้าพิมพ์จำนวนมากที่ต้องค้นหาอย่างเดียว รูปแบบข้อความล้วนและราคาต่อหน้าจะมีน้ำหนักสูงกว่า

เมทริกซ์เลือกตามเอกสารและผลลัพธ์

• หน้าพิมพ์ชัดที่ต้องทำดัชนีค้นคำ: iApp ช่องทางข้อความล้วนตรงกับงานและมีต้นทุนต่อหน้าที่ระบุชัด ตรวจเพิ่มเฉพาะหน้าที่มีหลายคอลัมน์หรือภาพสแกนคุณภาพต่ำ
• เอกสารพิมพ์ที่ต้องส่งต่อเป็น Word, Excel หรือ PDF ค้นหาได้: iApp มีช่องทางสร้างไฟล์เหล่านี้โดยตรง แต่ต้องดูความถูกต้องของตารางและย่อหน้าในไฟล์ที่ได้
• แบบฟอร์มที่มีลายมือ หรือคลังความรู้ที่ต้องการ Markdown พร้อมตาราง HTML: Typhoon OCR 1.5 สอดคล้องกับชนิดข้อมูลและรูปแบบผลลัพธ์มากกว่า โดยควรแยกตรวจชื่อ ตัวเลข และช่องที่มีผลทางธุรกิจ
• ข้อมูลที่ต้องอยู่ในเครือข่ายองค์กร: เปรียบเทียบเงื่อนไขติดตั้งภายในของ iApp กับการรันน้ำหนัก Typhoon เอง พร้อมนับค่าเครื่อง การดูแลระบบ และงานตรวจแก้

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