OCR

OCR ย่อมาจาก optical character recognition คือการอ่านตัวอักษรที่ฝังอยู่ในภาพให้กลายเป็นข้อความจริงที่คอมพิวเตอร์ค้นหา คัดลอก และประมวลผลต่อได้ มันเป็นงานสาขาหนึ่งของ computer-vision ที่โฟกัสเฉพาะเรื่องตัวหนังสือ จุดที่คนทำงานควรจับให้ได้คือไฟล์ PDF ในองค์กรมีสองพันธุ์ที่หน้าตาเหมือนกันบนจอแต่ต่างกันคนละโลก พันธุ์แรกคือไฟล์ที่ export ออกมาจากโปรแกรมโดยตรง ข้างในมีชั้นข้อความอยู่แล้วจึงกด Ctrl+F เจอทันที พันธุ์ที่สองคือไฟล์ที่ได้จากเครื่องสแกนหรือกล้องมือถือ ข้างในมีแค่รูปภาพ ค้นหาอย่างไรก็ไม่เจอแม้แต่คำเดียว

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

ในระดับองค์กรมีบริการที่ทำงานนี้เป็นเรื่องเป็นราวอยู่หลายเจ้า ฝั่ง Google คือ Document AI ที่เอกสารทางการอธิบายว่าเป็นแพลตฟอร์มซึ่งเปลี่ยนข้อมูลไร้โครงสร้างในเอกสารให้กลายเป็นข้อมูลมีโครงสร้างที่พร้อมลงฐานข้อมูล และระบุว่าสร้างอยู่บน vertex-ai โดยแบ่ง processor เป็นสามกลุ่มคือ Digitize ที่มี Enterprise Document OCR สำหรับดึงข้อความและ layout, กลุ่ม Extract ที่มี Form Parser สำหรับดึงตารางและคู่ key-value จากแบบฟอร์ม กับ Layout Parser ที่ดึงองค์ประกอบอย่างข้อความ ตาราง และรายการ ออกมาเป็นชิ้นเนื้อหาที่รู้บริบท, และกลุ่ม Classify สำหรับแยกประเภทหรือหั่นเอกสารหลายฉบับที่อยู่ในไฟล์เดียว ฝั่ง Microsoft คือ Azure Document Intelligence ที่เอกสารทางการปัจจุบันขึ้นชื่อเต็มว่า Azure Document Intelligence in Foundry Tools และอธิบายตัวเองในหน้าภาพรวมว่าเป็นบริการบนคลาวด์สำหรับสร้างระบบ intelligent document processing โดยมีโมเดล prebuilt-read ที่ดึงทั้งข้อความพิมพ์และลายมือเขียน และเอกสารระบุว่า read คือเครื่องยนต์ OCR ที่อยู่เบื้องหลังโมเดลตัวอื่นอย่าง layout, invoice, receipt และ ID document อีกทีหนึ่ง ผลลัพธ์ที่ได้จากบริการพวกนี้จึงมาพร้อมพิกัดตำแหน่งและโครงสร้างตารางติดมาด้วย ซึ่งช่วยให้ขั้นตอน chunking ต่อจากนั้นตัดเนื้อหาได้ตรงย่อหน้าจริงแทนที่จะตัดกลางตาราง

เรื่องภาษาไทยเป็นคำถามแรกที่คนไทยถามเสมอ คำตอบตามหน้ารายการภาษาของผู้ให้บริการคือรองรับ โดย Google ระบุ Thai รหัส th สคริปต์ Thai ไว้ในตารางภาษาของ Enterprise Document OCR และ Layout Parser บน Document AI รวมถึงในรายการภาษาที่ Cloud Vision รองรับ ข้อควรระวังคือการรองรับไม่ได้เท่ากันทุก processor เพราะตารางภาษาของ Form Parser ไม่มีแถว Thai อยู่ด้วย ส่วน Azure ระบุ Thai รหัส th ไว้ทั้งในตารางข้อความพิมพ์และตารางลายมือเขียนของโมเดล read เวอร์ชัน v4.0 ข้อควรระวังคืออย่าเพิ่งแปลว่าอ่านได้แม่นทุกแบบ การรองรับในเอกสารบอกแค่ว่าบริการนั้นอ่านสคริปต์ไทยได้ แต่ไม่ได้ระบุระดับความแม่นยำไว้ จึงไม่ได้แปลว่าจะอ่านลายมือหมอ ใบเสร็จหมึกจาง หรือแบบฟอร์มที่มีตราครุฑทับตัวหนังสือได้เท่ากัน เอกสารของ Azure ยังเตือนไว้ด้วยว่าโมเดลออกแบบมาให้ตรวจจับภาษาเองโดยไม่ต้องระบุรหัสภาษา และถ้าไปบังคับระบุรหัสทั้งที่ไม่แน่ใจ บริการอาจคืนข้อความที่ไม่ครบหรือไม่ถูกต้องกลับมา

ช่วงหลังมีอีกทางเลือกที่เปลี่ยนวิธีคิดของทีมงานไปพอสมควร คือการส่งภาพหรือ PDF เข้าโมเดล multimodal ให้อ่านตรงๆ โดยไม่ผ่านขั้นตอน OCR แยกต่างหาก เอกสารของ gemini ระบุว่าโมเดลประมวลผล PDF ด้วย native vision เพื่อเข้าใจบริบทของเอกสารทั้งฉบับ รองรับไฟล์ขนาดไม่เกิน 50MB หรือไม่เกิน 1000 หน้า และคิดหนึ่งหน้าเอกสารเท่ากับ 258 token ข้อดีคือถามได้เลยว่าสัญญาฉบับนี้มีเงื่อนไขปรับกี่เปอร์เซ็นต์ แทนที่จะต้องแปลงเป็นข้อความก่อนแล้วค่อยเขียนโปรแกรมไปตามหา และโมเดลเห็นแผนภูมิกับตารางไปพร้อมกับตัวหนังสือ สิ่งที่หายไปคือค่าความมั่นใจรายคำ ซึ่ง OCR แบบเดิมคืนมาให้เป็นฟิลด์มาตรฐาน และทีมงานใช้ตั้งเกณฑ์ได้ว่าคำไหนต้องส่งคนตรวจซ้ำ

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

ตัวอย่างจากบทสนทนาจริง

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

ทีม IT: "เพราะไฟล์ที่สแกนมาเป็นภาพล้วนครับ ระบบเห็นเป็นรูปไม่ได้เห็นเป็นตัวหนังสือ ต้องรัน OCR ทับอีกชั้นก่อนถึงจะ index ได้ ผมขอตัวอย่างสัก 50 ใบไปลองก่อน จะได้ดูว่าใบเสร็จที่หมึกจางกับที่มีตราประทับทับตัวเลข ระบบอ่านรอดกี่เปอร์เซ็นต์"

ฝ่ายบัญชี: "แล้วที่ผมลองโยน PDF ที่ export จากระบบเข้า notebooklm แล้วมันตอบได้เลยล่ะ ทำไมของเราต้องยุ่งขนาดนี้"

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

ระวังสับสนกับ

• computer-vision : เป็นสาขาใหญ่ที่ครอบคลุมการทำความเข้าใจภาพทุกแบบ ตั้งแต่นับจำนวนคนในกล้องวงจรปิดไปจนถึงตรวจรอยร้าวบนชิ้นงาน ส่วน OCR คืองานย่อยที่เจาะจงเฉพาะการอ่านตัวอักษรออกมาเป็นข้อความ
• multimodal : เป็นคุณสมบัติของโมเดลที่รับอินพุตได้หลายชนิดรวมถึงภาพ ไม่ใช่ชื่อขั้นตอนแปลงภาพเป็นข้อความ โมเดล multimodal ใช้แทน OCR ได้ในหลายงาน แต่ไม่ได้คืนค่าความมั่นใจรายคำมาให้เหมือนบริการ OCR โดยเฉพาะ ส่วนพิกัดกรอบนั้นสั่งให้โมเดลตอบออกมาได้ (เอกสารของ Gemini อธิบายวิธีให้โมเดลคืนกรอบวัตถุในภาพเป็นพิกัด [ymin, xmin, ymax, xmax] แบบ normalize ช่วง 0 ถึง 1000) แต่เป็นคำตอบที่โมเดลกำเนิดขึ้น ไม่ใช่ฟิลด์รายคำที่บริการ OCR รับประกันให้
• chunking : เป็นขั้นตอนที่เกิดหลัง OCR คือการหั่นข้อความยาวเป็นชิ้นก่อนนำไปทำดัชนี ถ้า OCR อ่านผิดตั้งแต่ต้น การหั่นให้ดีแค่ไหนก็ช่วยอะไรไม่ได้