ทำไมการดึงข้อมูลจากใบแจ้งหนี้ถึงเป็นเรื่องปราบเซียนสำหรับโปรแกรมเมอร์
เวลาเราเริ่มฝึกเขียนโปรแกรม หลายคนมักตื่นเต้นกับตัวอย่างในเน็ตที่สั่งให้ API (ช่องทางเชื่อมต่อระหว่างซอฟต์แวร์) ดึงข้อมูลใบแจ้งหนี้ออกมาแล้วจบที่การแสดงผล JSON (รูปแบบข้อมูลตัวอักษรที่อ่านง่ายสำหรับคอมพิวเตอร์) แต่ในชีวิตการทำงานจริงของโปรแกรมเมอร์ Azure AI Document Intelligence ไม่ได้จบแค่นั้นครับ การดึงข้อมูลออกมาได้แค่ 20% ของงานทั้งหมดเท่านั้นเอง
ปัญหาที่แท้จริงจะเกิดขึ้นเมื่อคุณต้องรับมือกับใบแจ้งหนี้ใบที่ 400 ที่พนักงานส่งแฟกซ์ลายมือยุ่งเหยิงมาให้ หรือเอกสารที่สแกนมาแบบเอียงจนระบบอ่านค่าผิดเพี้ยนไปหมด หากเราเขียนโปรแกรมให้ดึงข้อมูลแล้วบันทึกลงระบบบัญชีทันทีโดยไม่ตรวจสอบก่อน ความผิดพลาดระดับหลักล้านอาจเกิดขึ้นได้ง่ายมาก
บทความนี้จะพาคุณไปทำความเข้าใจการสร้าง Pipeline (ขั้นตอนการทำงานอัตโนมัติ) แบบมืออาชีพ ที่ไม่ได้แค่ดึงข้อมูล แต่มีการกรองความถูกต้องและตัดสินใจว่าเอกสารใบไหนควรผ่าน หรือใบไหนต้องให้คนช่วยตรวจสอบก่อน การเรียนรู้วิธีจัดการกับความผิดพลาดในงานจริง คือทักษะที่แยกโปรแกรมเมอร์มือสมัครเล่นออกจากมืออาชีพครับ
วางโครงสร้างระบบให้ฉลาดก่อนเริ่มเขียนโค้ด
หัวใจสำคัญของการทำระบบอัตโนมัติคือการวางแผนว่าเอกสารแต่ละใบจะเดินทางไปที่ไหนบ้าง เราต้องมองระบบเป็น 5 ขั้นตอนหลัก ได้แก่ การรับไฟล์ (Ingest) การจำแนกประเภท (Classify) การดึงข้อมูล (Extract) การคัดแยกตามความแม่นยำ (Route) และการบันทึกข้อมูล (Post)
หลายคนพลาดตรงที่พยายามยัดทุกอย่างเข้าโมเดลเดียวกันหมด แต่ความจริงคือคุณควร Classify (จัดหมวดหมู่เอกสาร) ก่อนเสมอ ไม่ใช่เอกสารทุกใบที่ส่งเข้าอีเมลจะเป็นใบแจ้งหนี้ บางครั้งอาจเป็นใบวางบิลหรือเอกสารแนะนำตัวคู่ค้า ถ้าเราเอาเอกสารผิดประเภทไปยัดใส่โมเดลอ่านใบแจ้งหนี้ ผลลัพธ์ที่ได้จะเป็นขยะที่ดูน่าเชื่อถือ ซึ่งอันตรายกว่าการที่ระบบแจ้งเตือนว่าอ่านไม่ได้เสียอีก
การออกแบบที่ดีต้องมี "ด่านตรวจ" เสมอ โดยเฉพาะในขั้นตอนที่ 4 ซึ่งเป็นส่วนที่วิศวกรซอฟต์แวร์ต้องใส่ตรรกะ (Logic) เข้าไปเพื่อตัดสินใจ หากระบบมั่นใจว่าข้อมูลถูกต้องจึงให้ผ่านไปบันทึกในระบบบัญชี แต่ถ้าค่าความมั่นใจต่ำ ระบบต้องส่งไปให้คนตรวจสอบ (Review) แทนการปล่อยให้ข้อมูลผิดพลาดหลุดรอดไปได้
เลือกโมเดลให้ถูกจุด เพื่อประหยัดเวลาและงบประมาณ
เครื่องมือตัวนี้มีตัวเลือกหลักให้เราใช้ 3 แบบ ถ้าเลือกผิดอาจเสียเวลาแก้ระบบเป็นสัปดาห์ได้เลยครับ ตัวเลือกแรกคือ prebuilt-invoice ซึ่งเป็นโมเดลสำเร็จรูปที่เหมาะกับใบแจ้งหนี้มาตรฐานทั่วไป ไม่ต้องสอน (Train) ระบบเพิ่มและใช้งานได้ทันที แต่ข้อจำกัดคือคุณแก้ไขโครงสร้างข้อมูลที่มันดึงมาไม่ได้
ตัวเลือกที่สองคือ Custom extraction model หรือการสร้างโมเดลเองสำหรับเอกสารที่มีรูปแบบเฉพาะตัว เช่น ใบสั่งซื้อของบริษัทคุณเองที่ฟอร์มไม่เหมือนใคร แบบนี้คุณต้องเตรียมเอกสารตัวอย่างอย่างน้อย 5 ใบเพื่อให้ระบบเรียนรู้จุดที่ข้อมูลวางอยู่ และตัวเลือกสุดท้ายคือการใช้ตัวจำแนกประเภทร่วมกับโมเดลหลายตัว ซึ่งเหมาะกับงานที่มีเอกสารหลากหลายปนกันในช่องทางเดียว
คำแนะนำสำหรับมือใหม่คือ ให้เริ่มจาก prebuilt-invoice ในเวอร์ชันล่าสุดเสมอ เพราะรองรับหลายภาษาและครอบคลุมฟิลด์ข้อมูลสำคัญครบถ้วน อย่าเพิ่งรีบสร้างโมเดลเองจนกว่าคุณจะพบว่าฟิลด์ที่ต้องการไม่มีอยู่ในระบบสำเร็จรูป การทำแบบนี้จะช่วยให้คุณเห็นภาพรวมและลดความซับซ้อนของโปรเจกต์ลงได้มากครับ
// ตัวอย่างการเรียกใช้ Azure AI Document Intelligence ผ่าน Power Automate
// เราจะใช้ Action ชื่อ Analyze Document v4.x
{
"modelId": "prebuilt-invoice",
"document": "base64_encoded_file_content"
}
// การตั้งค่า modelId เป็น prebuilt-invoice จะสั่งให้ระบบใช้โมเดลมาตรฐาน
// ส่วน document คือไฟล์ที่ถูกแปลงเป็นรหัสตัวอักษรเพื่อส่งเข้า API
ในโค้ดตัวอย่างด้านบน เรากำลังบอกระบบว่าให้ใช้โมเดลสำเร็จรูปสำหรับใบแจ้งหนี้ โดยส่งไฟล์ที่เข้ารหัสแบบ Base64 (รูปแบบการเก็บข้อมูลไฟล์เป็นตัวอักษร) เข้าไปในขั้นตอนการวิเคราะห์ ผลลัพธ์ที่ได้จะเป็นโครงสร้างข้อมูล JSON ที่ระบุค่าในแต่ละช่องของใบแจ้งหนี้พร้อมค่าความมั่นใจ (Confidence Score) มาให้เราตรวจสอบต่อ
อย่าสับสนระหว่างความแม่นยำกับค่าความมั่นใจ
นี่คือจุดตายที่โปรแกรมเมอร์มือใหม่มักพลาดบ่อยที่สุด คือการมองว่า Accuracy (ความแม่นยำในการทำนายของโมเดล) กับ Confidence (ค่าความมั่นใจของระบบต่อข้อมูลหนึ่งชุด) คือเรื่องเดียวกัน ทั้งที่จริงแล้วมันคือคนละเรื่องและใช้ตัดสินใจคนละจังหวะเวลาครับ
ค่าความมั่นใจจะถูกส่งกลับมาพร้อมกับข้อมูลทุกครั้งที่ระบบอ่านเอกสาร มันคือตัวเลข 0 ถึง 1 ที่บอกว่าระบบ "คิดว่า" ค่าที่อ่านได้นั้นถูกต้องแค่ไหน ส่วนความแม่นยำคือค่าที่ได้ตอนเราทดสอบระบบว่าโมเดลเก่งแค่ไหนก่อนจะนำไปใช้งานจริง เราใช้ความแม่นยำเพื่อตัดสินใจว่า "โมเดลนี้ดีพอจะเอาไปใช้ไหม" แต่เราใช้ค่าความมั่นใจเพื่อตัดสินใจว่า "เอกสารใบนี้เชื่อถือได้หรือไม่"
การตั้งค่าเกณฑ์ตัดสินใจ (Gate) ต้องอิงตามผลกระทบทางธุรกิจเสมอครับ หากเป็นข้อมูลยอดเงิน คุณควรตั้งค่าความมั่นใจไว้สูงมาก เช่น 0.95 ขึ้นไป แต่ถ้าเป็นข้อมูลวันที่หรือหมายเลขใบกำกับภาษี อาจลดระดับความเข้มงวดลงมาได้เล็กน้อย การตั้งค่าแบบเหมาเข่งที่ 0.80 ทุกฟิลด์คือความเสี่ยงที่โปรแกรมเมอร์ไม่ควรทำครับ
สร้างด่านตรวจข้อมูลด้วยตรรกะที่รัดกุม
เมื่อเราได้ข้อมูลมาแล้ว อย่าเพิ่งรีบเชื่อใจมันเด็ดขาด ให้เราสร้างขั้นตอนการตรวจสอบด้วย Expression (ชุดคำสั่งคำนวณใน Power Automate) เพื่อดึงค่าความมั่นใจของแต่ละฟิลด์ออกมาตรวจสอบแยกกัน วิธีนี้ช่วยให้เราคัดกรองได้ละเอียดว่าฟิลด์ไหนที่ระบบไม่มั่นใจและควรส่งให้คนตรวจสอบ
ตัวอย่างการดึงค่าความมั่นใจของยอดรวมใน Power Automate สามารถเขียนได้ดังนี้ครับ:
// ดึงค่า confidence จากผลลัพธ์ของฟิลด์ InvoiceTotal
body('Analyze_Document_v4')?['analyzeResult']?['documents']?[0]?['fields']?['InvoiceTotal']?['confidence']
// ผลลัพธ์ที่ได้จะเป็นตัวเลข เช่น 0.98 หมายถึงระบบมั่นใจ 98%
// ถ้าค่านี้ต่ำกว่า 0.95 เราจะสั่งให้ระบบส่งงานไปที่โฟลเดอร์ Review ทันที
บรรทัดแรกเป็นการเข้าถึงข้อมูลในรูปแบบ JSON Path (เส้นทางเข้าถึงข้อมูลในโครงสร้างซ้อนกัน) เพื่อหยิบค่าความมั่นใจของยอดรวมออกมา ถ้าหากฟิลด์นั้นไม่มีข้อมูล ระบบจะคืนค่าว่าง (Null) ออกมา ซึ่งโปรแกรมเมอร์ต้องเขียนดักไว้เสมอเพื่อป้องกันไม่ให้ Flow (ขั้นตอนการทำงาน) พังกลางคันตอนตีสองครับ
นอกจากค่าความมั่นใจแล้ว การทำ Arithmetic check (การตรวจสอบความถูกต้องทางคณิตศาสตร์) ก็สำคัญมาก เช่น ลองเอา ยอดก่อนภาษี + ภาษี ดูว่าเท่ากับยอดรวมจริงไหม ถ้าไม่เท่ากันแม้แต่บาทเดียว ให้ตีตกหรือส่งไปตรวจสอบทันที เพราะบ่อยครั้งที่ระบบอ่านเลขถูกทุกตัว แต่ตัวเลขในเอกสารต้นฉบับเองนั่นแหละที่คำนวณมาผิด
สรุป: การสร้างระบบที่ไว้ใจได้
การสร้าง Pipeline สำหรับดึงข้อมูลใบแจ้งหนี้ไม่ใช่แค่การเขียนโค้ดเรียก API ให้ทำงานสำเร็จ แต่คือการสร้างระบบที่ "รู้ตัวเมื่อผิดพลาด" โปรแกรมเมอร์ที่เก่งจะให้ความสำคัญกับ Failure modes (รูปแบบความผิดพลาดที่อาจเกิดขึ้น) มากกว่าการทำให้ระบบทำงานได้ในสภาวะปกติ เพราะในโลกจริง ข้อมูลมักจะไม่สมบูรณ์เสมอครับ
จำไว้ว่าเป้าหมายของเราคือการลดภาระงานของคน ไม่ใช่การทำให้อัตโนมัติจนเกิดความเสียหาย หากคุณสร้างระบบที่แยกแยะได้ว่า "ใบไหนมั่นใจให้ผ่าน" และ "ใบไหนไม่มั่นใจให้คนช่วยดู" คุณจะได้ระบบที่คุ้มค่าและลดความผิดพลาดได้จริง การเริ่มฝึกจากจุดเล็กๆ เช่น การตั้งค่าเงื่อนไขตรวจสอบยอดเงิน จะช่วยให้คุณก้าวสู่การเป็นนักพัฒนาที่มีมุมมองแบบวิศวกรมากขึ้นครับ
ลองนำแนวคิดนี้ไปปรับใช้กับโปรเจกต์ของคุณดูครับ เริ่มจากการทดสอบกับไฟล์ตัวอย่าง 10-20 ใบ แล้วลองทำให้ระบบแยกแยะเอกสารที่มีความมั่นใจต่ำออกมาให้ได้ก่อน แล้วคุณจะพบว่าการเขียนโปรแกรมเพื่อแก้ไขปัญหาในโลกธุรกิจนั้นสนุกและท้าทายกว่าที่คิดเยอะเลยครับ
ที่มา: Building an Invoice Extraction Pipeline with Azure AI Document Intelligence and Power Automate — DEV Community
