เปิดตัว Mistral OCR 4

 (mistral.ai)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mistral OCR 4 ที่ Mistral AI เปิดตัว เป็นโมเดลทำความเข้าใจเอกสารที่ก้าวข้าม OCR แบบดึงเฉพาะข้อความ โดยสามารถส่งคืนทั้ง bounding box, การจัดประเภทบล็อก, และคะแนนความเชื่อมั่นแบบอินไลน์ได้พร้อมกัน
  • รองรับ 170 ภาษา ใน 10 กลุ่มภาษา และรองรับการ self-host บนคอนเทนเนอร์เดี่ยว จึงเหมาะกับไปป์ไลน์รวบรวมเอกสารขององค์กรที่ให้ความสำคัญกับ data sovereignty และ compliance
  • ในการประเมินความพึงพอใจของมนุษย์ ทำอัตราชนะเฉลี่ยได้ 72% และยังได้คะแนนสูงในการประเมินทั้งแบบสาธารณะและภายใน เช่น OlmOCRBench 85.20, OmniDocBench 93.07
  • อย่างไรก็ตาม คะแนน benchmark ควรพิจารณาควบคู่กับการประเมินเอกสารจริง เนื่องจากมี ข้อจำกัดด้านการให้คะแนน เช่น ความผิดพลาดของคำตอบอ้างอิง, การเขียนสูตรที่เทียบเท่ากัน, ลำดับการอ่านหลายคอลัมน์, และการจัดการ header/footer
  • API มีราคา $4 ต่อ 1,000 หน้า, Batch API $2, และ Document AI $5 โดยหากต้องการการดึงข้อมูลดิบ OCR 4 ก็เพียงพอ แต่ถ้าต้องการ structured JSON, image annotation หรือ custom prompt เส้นทาง Document AI จะเหมาะกว่า

การแสดงผลเอกสารแบบมีโครงสร้างที่ OCR 4 ส่งคืน

  • OCR 4 สามารถดึงและจัดโครงสร้างเนื้อหาจากเอกสารหลากหลายประเภท และไม่ได้หยุดอยู่แค่ข้อความสะอาดและการแปลงตารางแบบรุ่นก่อนหน้า แต่ยังให้ structured representation มาด้วย
  • แต่ละบล็อกมี bounding box, ประเภทบล็อก, และคะแนนความเชื่อมั่นแบบอินไลน์ในระดับหน้าและระดับคำ
    • ระบบ downstream สามารถใช้ได้ไม่เพียงแค่เนื้อหาเอกสาร แต่รวมถึงตำแหน่ง บทบาท และระดับความเชื่อมั่นของแต่ละองค์ประกอบด้วย
  • เวิร์กโฟลว์การใช้งานหลักมีดังนี้
    • semantic chunking สำหรับ RAG: ใช้บล็อกที่จัดระเบียบและจัดประเภทแล้วเป็นหน่วยค้นคืน
    • structured primitive สำหรับเอเจนต์: รองรับการกรอกฟอร์ม, การประมวลผลใบแจ้งหนี้, และการตรวจสอบ compliance
    • structured content สำหรับ connector: ให้เอาต์พุตชนิดข้อมูลที่สม่ำเสมอแก่ไปป์ไลน์รวบรวมและทำดัชนี

รูปแบบ, ภาษา, และวิธีการติดตั้งใช้งาน

  • รูปแบบอินพุตรองรับ enterprise document format ทั่วไป เช่น PDF, DOC, PPT และ OpenDocument
  • รองรับ 170 ภาษา ใน 10 กลุ่มภาษา รวมถึงภาษาวิชาชีพและภาษาทรัพยากรต่ำที่หลายระบบยังทำได้ไม่ดี
  • โมเดลมีขนาดเล็กพอที่จะ deploy ในคอนเทนเนอร์เดี่ยวได้ จึงเหมาะกับสภาพแวดล้อมที่ไวต่อค่าใช้จ่ายและต้องการ throughput สูง
  • รองรับการทำงานแบบ self-hosting เต็มรูปแบบ ดังนั้นองค์กรที่มีข้อกำหนดด้าน data sovereignty สามารถเก็บข้อมูลเอกสารไว้ในโครงสร้างพื้นฐานของตนเองได้
  • การติดตั้งใช้งานแบบ self-managed มีให้สำหรับลูกค้าองค์กร

ราคาและช่องทางการใช้งาน

  • นักพัฒนาสามารถผสานโมเดลผ่าน API ได้ และทีมงานสามารถใช้เอนจินเดียวกันในรูปแบบแอปพลิเคชัน no-code ผ่าน Document AI บน Mistral Studio
  • ราคามีดังนี้
    • OCR 4 API: $4 ต่อ 1,000 หน้า
    • เมื่อใช้ส่วนลด 50% ของ Batch API: $2 ต่อ 1,000 หน้า
    • Document AI: $5 ต่อ 1,000 หน้า
  • OCR 4 ถูกผสานเป็นคอมโพเนนต์สำหรับการรวบรวมข้อมูลใน Mistral Search Toolkit เพื่อป้อนอินพุตที่อ้างอิงได้ให้กับเวิร์กโฟลว์การรวบรวม ค้นคืน และประเมินผลสำหรับ RAG และการค้นหาระดับองค์กร

ผลการประเมินและข้อจำกัดของ benchmark

  • การประเมิน OCR 4 ดำเนินการโดยเปรียบเทียบกับโมเดล OCR แบบ AI-native, โมเดล frontier แบบทั่วไป, บริการเอกสารระดับองค์กร และ Mistral OCR 3
  • การประเมินความพึงพอใจของมนุษย์ถูกออกแบบให้สะท้อนการใช้งานจริง โดยใช้เอกสารมากกว่า 600 ฉบับในมากกว่า 12 ภาษา และให้ผู้ทำ annotation อิสระเปรียบเทียบเอาต์พุตของระบบคู่แข่งแต่ละรายกับ OCR 4 แบบ blind รายเอกสาร
    • ผู้ทำ annotation ชอบ OCR 4 มากกว่าในเอกสารส่วนใหญ่เมื่อเทียบกับทุกระบบที่ทดสอบ
    • อัตราชนะเฉลี่ยอยู่ที่ 72%
  • ใน OlmOCRBench แบบสาธารณะ ทำคะแนนรวมสูงสุดในบรรดาโมเดลที่ทดสอบที่ 85.20
  • ในการประเมินภายใน Crawl Multilingual evaluation ทำได้ .98 สูงกว่าทั้งโซลูชัน AI-native และระดับองค์กร
  • คะแนน OmniDocBench อยู่ที่ 93.07 แต่ทั้ง OlmOCRBench และ OmniDocBench ต่างก็มีข้อจำกัดที่ทราบกันอยู่แล้วในวิธีการให้คะแนนเอาต์พุตบางส่วน
  • ความไม่ตรงกันจำนวนมากที่ผ่านการตรวจสอบแล้วเกิดจากวิธีเปรียบเทียบของ benchmark มากกว่าจะเป็นความผิดพลาดของโมเดล
    • ข้อผิดพลาดของคำตอบอ้างอิง: annotation อ้างอิงอาจมีข้อความตกหล่นหรือเกินมา, การถอดข้อความจากส่วนที่ถูกบัง, หรือพิมพ์ผิด
    • การเขียนสูตรที่เทียบเท่ากัน: แม้ LaTeX จะเรนเดอร์ออกมาเหมือนกัน แต่ถ้าสตริงต่างกันก็จะถูกนับว่าไม่ตรงกัน
    • การแยกสูตร: การส่งออกเป็นสูตรเดียวหรือแยกเป็นหลายชิ้นแบบอินไลน์อาจทำให้การจับคู่กับคำตอบอ้างอิงคลาดเคลื่อน
    • ลำดับการอ่านหลายคอลัมน์: คำที่ถูกแยกตรงขอบคอลัมน์และสมมติฐานเรื่องลำดับคอลัมน์อาจทำให้การดึงที่ถูกต้องถูกให้คะแนนว่าล้มเหลวได้
    • การจัดประเภทบล็อก: แม้จะลบ header/footer ออกจากเอาต์พุตแล้ว การทดสอบก็ยังอาจตั้งธงผิดกับสตริงอย่างชื่อหน้ากระดาษได้
  • สิ่งเหล่านี้กระจุกตัวอยู่ในเอกสารคณิตศาสตร์ วิทยาศาสตร์ และหลายคอลัมน์ และมักลงโทษเอาต์พุตที่ถูกต้องบ่อยกว่าจะให้รางวัลกับเอาต์พุตที่ผิด
  • คะแนนของคู่แข่งทั้งหมดเป็นผลการทำซ้ำภายใน ดังนั้นก่อนนำไปใช้จริง การประเมินกับเอกสารของตัวเองโดยตรงจะปลอดภัยกว่า

ประสิทธิภาพหลายภาษา

  • ในการประเมินหลายภาษาภายใน OCR 4 นำหน้าในทั้ง 8 กลุ่มภาษา
    • English
    • Western Europe
    • Eastern Europe
    • Middle Eastern
    • Chinese
    • East Asian
    • Southeast Asian
    • ภาษาเฉพาะทาง เช่น Hindi, Japanese, Georgian, Bengali, Armenian, Hebrew, Greek, Gujarati, Tamil, Malayalam, Kannada, Telugu
  • ช่องว่างนี้มากที่สุดในภาษาวิชาชีพและภาษาทรัพยากรต่ำ และแม้ในพื้นที่ที่หลายระบบคู่แข่งมีประสิทธิภาพตกลงอย่างมาก OCR 4 ก็ยังรักษาความแม่นยำสูงไว้ได้

กรณีใช้งานที่แนะนำและขอบเขตที่ไม่ครอบคลุม

  • OCR 4 รองรับทั้งไปป์ไลน์ throughput สูงและเวิร์กโฟลว์เอกสารแบบโต้ตอบ
  • กรณีใช้งานที่แนะนำมีดังนี้
    • การพาร์สและดึงข้อมูลเอกสาร จากเอกสารหลายภาษาที่ซับซ้อน
    • สร้างเนื้อหาแบบมีโครงสร้าง, จัดประเภท, และอ้างอิงได้สำหรับ RAG
    • อินพุตให้กับไปป์ไลน์ค้นหาเมื่อใช้ร่วมกับ Search Toolkit
    • เวิร์กโฟลว์เอเจนต์ เช่น การกรอกฟอร์ม, การประมวลผลใบแจ้งหนี้, และการตรวจสอบ compliance
    • ไปป์ไลน์ข้อมูลแบบมีโครงสร้างที่อาศัยการตรวจสอบโดยมนุษย์โดยใช้คะแนนความเชื่อมั่น
    • คอมโพเนนต์แหล่งข้อมูลสำหรับการค้นหาระดับองค์กรและ knowledge base
  • ผู้ใช้ช่วงแรกกำลังนำ OCR 4 ไปใช้กับการแปลงฟิลด์แบบมีโครงสร้างในใบแจ้งหนี้, การดิจิไทซ์คลังเอกสารของบริษัท, การดึงข้อความสะอาดจากรายงานเทคนิคและวิทยาศาสตร์, และการค้นหาระดับองค์กร
  • OCR 4 เป็นโมเดลทำความเข้าใจเอกสาร ไม่ใช่ ผู้ตัดสินใจ
    • ไม่ได้ออกแบบมาสำหรับการวินิจฉัยทางการแพทย์, คำแนะนำหรือการตัดสินทางกฎหมาย, การตัดสินใจทางการเงินที่มีความเสี่ยงสูง, ระบบที่มีความสำคัญต่อความปลอดภัย, การประมวลผลแบบเรียลไทม์หรือไวต่อ latency, หรืออินพุตที่ไม่ใช่เอกสาร เช่น raw audio/video

เกณฑ์การเลือก OCR 4 API และ Document AI

  • OCR 4 ให้บริการผ่าน API endpoint เดียว และทุกคำขอจะรันโมเดล OCR พื้นฐานตัวเดียวกัน
  • ในการตอบกลับพื้นฐานจะมี extracted content, bounding box, ประเภทบล็อก, คะแนนความเชื่อมั่น, และข้อความโครงสร้างแบบ Markdown รวมอยู่เสมอ
  • โหมดดึงข้อมูลล้วน เหมาะกับกรณีต่อไปนี้
    • ฝังความสามารถดึงข้อมูลเอกสารที่รวดเร็วและแม่นยำลงในแอปพลิเคชัน, เอเจนต์, หรือ data pipeline โดยตรง
    • ใช้ raw response, bounding box, ประเภทบล็อก, และคะแนนความเชื่อมั่นโดยตรงเพื่อสร้างตรรกะ post-processing แบบกำหนดเอง
    • การรวบรวมข้อมูลแบบ throughput สูงหรือแบบ batch ที่ควบคุม throughput และต้นทุนผ่าน Batch API
    • self-hosting ที่สอดคล้องกับข้อกำหนดเข้มงวดด้าน data privacy, sovereignty, และ compliance
  • ความสามารถของ Document AI เปิดใช้งานได้โดยใส่พารามิเตอร์เพิ่มเติมใน endpoint เดียวกัน
    • หากส่ง JSON schema ไปพร้อมเอกสาร เอาต์พุต OCR จะถูกป้อนเข้า mistral-small-2603 เพื่อสร้าง structured JSON ตามสเปกที่กำหนด
    • หากส่ง image annotation schema ระบบจะเรียก vision-language model เพิ่มเติมต่อภาพที่ตรวจพบแต่ละภาพ เพื่อสร้าง structured JSON
    • สามารถใช้ custom prompt ร่วมกับ JSON schema เพื่อชี้นำการตีความหรือสรุป extracted content ของทั้งเอกสารได้
    • ผู้ใช้ธุรกิจ ทีมโซลูชัน และโครงการนำร่องสามารถสร้างผลลัพธ์แบบมีโครงสร้างได้โดยไม่ต้องมีตรรกะ parsing หลังประมวลผลแยกต่างหาก
  • หากต้องการ extracted content แบบดิบ ให้ใช้ OCR 4 ได้ตรง ๆ แต่ถ้าต้องการการแปลงเป็นรูปแบบมีโครงสร้างใหม่, การ annotation ฟิลด์เฉพาะโดเมน, หรือการประมวลผลตามคำสั่งแบบกำหนดเอง ให้เพิ่มพารามิเตอร์ของ Document AI

ช่องทางที่ให้บริการและวิธีเริ่มต้น

  • Mistral OCRv4 และ Document AI ที่ขับเคลื่อนด้วย OCRv4 ใช้งานได้ผ่าน API, Mistral Studio, Amazon SageMaker และ Microsoft Foundry
  • การรองรับ Snowflake Parse Document จะเปิดให้ใช้งานเร็ว ๆ นี้
  • สำหรับองค์กรที่ต้องเก็บข้อมูลอ่อนไหวไว้ภายในโครงสร้างพื้นฐานของตนเอง OCR 4 ยังมีตัวเลือก self-hosting ให้ด้วย
  • ทรัพยากรเริ่มต้นมีดังนี้
    • Getting Started with OCR 4 Cookbook: ครอบคลุมการดึงข้อมูลครั้งแรก, การทำงานกับ bounding box, และการจัดประเภทบล็อก
    • OCR4 in Production webinar: เดโมและ Q&A วันที่ 7 กรกฎาคม เวลา 18:00 CET
    • Contact Sales: สอบถามข้อมูลเพิ่มเติม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นใน Hacker News

  • US Postal Service ให้ความรู้สึกเหมือนปาฏิหาริย์ทางเทคนิคอยู่เสมอ
    แม้จะใช้เทคโนโลยีที่ดั้งเดิมกว่ามาก ก็ยังสามารถระบุและจัดเส้นทางจดหมายหลายพันล้านฉบับได้ แถมที่อยู่ในสหรัฐฯ ก็ไม่เป็นมาตรฐานแบบเหลือเชื่อ เขียนที่อยู่เดียวกันได้หลายแบบแต่ก็มักจะไปถึงที่เดียวกัน
    ความรู้ที่เปิดเผยในวงการนี้ก็คงมีมาก แต่พอเห็นว่ามันถูกทำได้ในสเกลแบบ USPS มานานหลายปี ทุกครั้งที่เห็นการประกาศเรื่อง OCR เลยรู้สึกเหมือนเป็นปัญหาที่ถูกแก้ไปแล้ว

    • พ่อของฉันเคยได้รับจดหมายจากแอลจีเรีย โดยบนซองมีแค่สามคำคือชื่อของเขา, “Créteil” (เมืองที่ตอนนั้นมีประชากรราว 100,000 คน), และ “France”
      ตอนนั้นเป็นช่วงทศวรรษ 1970 ยังไม่มีอินเทอร์เน็ตหรือฐานข้อมูลส่วนกลาง แต่ระบบไปรษณีย์ก็ส่งถึงได้สำเร็จ
      ส่วนหนึ่งเป็นเพราะพ่อทำงานสังคมสงเคราะห์อย่างแข็งขันและยังดูแลทีมฟุตบอลเยาวชนด้วย จนเป็นที่รู้จักพอสมควรในย่านนั้นจากแค่ชื่อก็พอ
      ทุกวันนี้หลายครั้งคนหาคนหรือหาสถานที่ไม่เจอถ้าไม่มีมือถือช่วย และบุรุษไปรษณีย์ก็ไม่ค่อยได้คุยกันแล้ว
      จดหมายแบบนั้นคงไม่ผ่านทั้งกระบวนการทางเทคนิค หรือแม้แต่ เครือข่ายของมนุษย์ ด้วยซ้ำ
    • ฉันเคยทำงานพาร์ตไทม์กับบริการไปรษณีย์เดนมาร์กมาก่อน ระบบคัดแยกอัตโนมัติทำได้ถึงแค่ระดับ รหัสไปรษณีย์
      พอจดหมายไปถึงที่ทำการไปรษณีย์ที่ถูกต้องแล้ว ที่เหลือบุรุษไปรษณีย์จะจัดการกันเองตอนเช้ามืด
      การเดาว่าที่อยู่หนึ่งหมายถึงอะไรค่อนข้างสนุก โดยเฉพาะพนักงานรุ่นเก่าที่มักรู้เรื่องราวว่าทำไมบางสถานที่ถึงถูกเขียนที่อยู่แบบนั้น หรือเดาที่อยู่ได้จากแค่ชื่อผู้อยู่อาศัย
    • Tom Scott มีวิดีโอที่ดีเกี่ยวกับเรื่องนี้: https://www.youtube.com/watch?v=XxCha4Kez9c
    • ที่อยู่ในสหรัฐฯ มีข้อยกเว้นแปลก ๆ เยอะมาก
      Carmel-by-the-Sea ไม่มีเลขถนน ส่วนที่อยู่ใน Florida Keys บางครั้งก็เป็นแค่หมายเลขหลักไมล์
      ที่ยังส่งได้ก็เพราะคนที่รับผิดชอบเส้นทางนั้นคุ้นเคยกับมัน
    • ถ้าเทียบกับมาตรฐานที่อยู่อินเดีย ความไม่เป็นมาตรฐานของที่อยู่อเมริกาก็ดูน่าขำไปเลย

  • สงสัยว่ามีโมเดลเปิดที่โฟกัสเรื่อง การรู้จำป้ายทะเบียนรถ โดยเฉพาะหรือเปล่า
    เจอโมเดลเก่า ๆ อยู่บ้าง แต่สงสัยว่ามีตัวใหม่ที่กำลังพัฒนาอยู่แบบโมเดล OCR พวกนี้ไหม
    อาจจะลองเอามาใช้กับงานนี้โดยตรงและดูประสิทธิภาพเองก็ได้

  • วิดีโอบนหน้าที่ลิงก์ไว้ไม่เหมือนที่คาด
    ฉันคิดว่า Mistral เป็นบริษัท AI ยุโรป แต่วิดีโอกลับถ่ายที่ San Francisco และคนทั้งสามที่ปรากฏก็ไม่ได้ดูเหมือนคนยุโรป เลยค่อนข้างแปลกใจ
    การเป็นองค์กรระดับโลกก็ดีอยู่หรอก แต่ฉันคาดว่าจะได้เห็นออฟฟิศในปารีสกับสำเนียงยุโรป

    • น่าเสียดายที่ลูกค้ายุโรปเป็นลูกค้าที่ทำเงินได้ยาก
      ถามเยอะแต่ควักกระเป๋าน้อยมาก ต่างจากคนอเมริกัน
    • ถ้าเป็นบริษัทเทคยุโรปที่มีขนาดพอตัว อย่างน้อยก็มักต้องมี ออฟฟิศฝั่งตะวันตกของสหรัฐฯ เพื่อการขาย
      น่าจะมีทีม sales engineering ด้วย
      เขตเวลาห่างกัน 8–10 ชั่วโมง จึงแทบหลีกเลี่ยงไม่ได้
      บริษัทเก่าที่ฉันเคยทำงานมีออฟฟิศที่ Vancouver แทน และอยู่ในเขตเวลาเดียวกัน
    • Blackmagic Design ก็คล้ายกัน
      แม้ฐานหลักส่วนใหญ่จะอยู่ออสเตรเลีย แต่ถ้าดูทั้งลำดับรายชื่อออฟฟิศและหน้าบริษัทที่ https://www.blackmagicdesign.com/company/offices ก็ทำให้ดูเหมือนเป็นบริษัทอเมริกัน
    • เท่าที่รู้ ทีมผู้ก่อตั้งส่วนใหญ่เริ่มอาชีพจาก บริษัทอเมริกัน อย่าง Meta และนักลงทุนหลักก็เป็น VC อเมริกัน
      ในแง่นั้นถือว่าใช้ข้อดีของทั้งเงินทุนอเมริกันและบุคลากรยุโรปได้อย่างฉลาด
    • ด้านหลังก็ยังแขวนธงชาติอเมริกันไว้อย่างเด่นชัดอีกด้วย

  • น่าสนใจว่าโมเดลนี้จะอยู่ระดับไหนเมื่อเทียบกับ https://github.com/baidu/Unlimited-OCR

  • 4 ดอลลาร์ต่อ 1,000 หน้า ถือว่าถูก แต่เวอร์ชันก่อน ๆ ล้วนประมาณว่า “ความแม่นยำ 98% จาก PDF benchmark ภายใน 4 ชุด” และในทางปฏิบัติก็ด้อยกว่าแทบทุกทางเลือกในตลาด เลยลังเลที่จะกลับไป benchmark อีกครั้ง
    รอบนี้ก็ยังชูตัวเลขจาก benchmark ภายใน พร้อมบอกว่า OlmOCRBench กับ OmniDocBench มี “ข้อจำกัดที่ทราบอยู่แล้ว”
    https://getomni.ai/blog/benchmarking-open-source-models-for-ocr

    • สรุปเหมือนกัน แต่พอลองรันกับตัวอย่างไม่กี่ชิ้นเอง ก็เห็นว่ามีการปรับปรุงจริงนับจาก เวอร์ชันธันวาคม 2025

  • ห้องแล็บ AI ทุกแห่งควรเลิกใช้ แกน y ที่ถูกตัด ในกราฟแท่ง benchmark ได้แล้วจริง ๆ
    https://mistral.ai/_astro/cm-engish_ZhlvoT.webp?dpl=6a3a94bd1f38530b2974c539

  • ลองทดสอบด้วย Malayalam แล้ว ลายมือแบบทั่วไปแม่นดี แต่ถ้าเป็นสไตล์ที่ต่างออกไปนิดหน่อยกลับถูกตรวจเป็น Kannada
    ถ้าต้องการฉันให้ตัวอย่างได้ และ Sarvam จัดการตัวอย่างเดียวกันได้แม่น 99% โดยพลาดตัวอักษรแค่ตัวเดียว

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

  • เมื่อเทียบกับ โมเดล OCR v3 ก่อนหน้าในเดือนธันวาคม แทบไม่มีการอธิบายความต่างนอกจาก bounding box แต่ราคากลับเพิ่มเป็นสองเท่า: https://mistral.ai/news/mistral-ocr-3/
    ตอนนั้นใช้ benchmark คนละชุด

  • “หมายเหตุเกี่ยวกับการใช้งานนอกขอบเขต OCR 4 เป็นโมเดลสำหรับทำความเข้าใจเอกสาร ไม่ใช่ผู้ตัดสินใจ ไม่ได้มีไว้สำหรับการวินิจฉัยทางการแพทย์ คำแนะนำหรือดุลยพินิจทางกฎหมาย การตัดสินใจทางการเงินความเสี่ยงสูง ระบบที่มีความสำคัญต่อความปลอดภัย งานประมวลผลแบบเรียลไทม์/ไวต่อเวลาแฝง หรืออินพุตที่ไม่ใช่เอกสาร (เสียงดิบ วิดีโอ ฯลฯ)”
    เริ่มคาดหวังได้เลยว่าจะมีผู้จัดการสาย “นวัตกรรม” เสนอในที่ประชุมครั้งหน้าว่า “โอเค แต่ถ้าเอาไปใช้ตัดสินใจทางการเงินความเสี่ยงสูง** จากอินพุตที่ไม่ใช่เอกสารอย่างรูปถ่ายจากมือถือจะเป็นยังไง?”
    กล้าพนันเลยว่าสัปดาห์หน้าคงมีคนมาโพสต์ “ไอเดีย” นี้ในคอมเมนต์บน HN

    • ไม่เข้าใจจริง ๆ ว่าทำไมต้องพยายามทำแบบนั้น
      มีโมเดลที่ทำได้ดีกว่านี้เป็นสิบ ๆ ตัว และเมื่อเทียบกันแล้วอันนี้น่าจะให้ผลลัพธ์แย่กว่าเยอะ
      นี่ไม่ใช่โมเดลสำหรับตอบคำถาม แต่เป็นโมเดลสำหรับ แปลงข้อความ
      ดูเหมือนแค่อยากฝืนหามุมต่อต้าน AI มากกว่า
    • บริษัท AI ทุกแห่งกำลังสร้าง โมเดลเฉพาะทาง ที่เก่งมากสำหรับงานใดงานหนึ่ง
      Mistral แค่พูดเรื่องนี้ตรงไปตรงมามากกว่า และอาจเป็นเพราะไม่จำเป็นหรือไม่ต้องการทำให้คนดูตื่นตาด้วยเครื่องมือผู้ใช้แบบอเนกประสงค์ (แชต) ที่ดูเหมือนเชี่ยวชาญไปหมดทุกอย่าง
      อันที่จริง เครื่องมือแบบนั้นก็มักเป็นการเอาโมเดลเฉพาะทางหลายตัวมาต่อกันอยู่แล้ว
      สิ่งที่ต้องการตรงนี้ทำได้ด้วย Python script ไม่กี่ตัว
      ใช้ Voxtral แปลง voice prompt เป็นข้อความ แล้วส่งต่อให้ Mistral Large 3 พร้อม system prompt เพิ่มเติมเพื่อให้สร้าง prompt สำหรับ OCR และ path ของไฟล์ จากนั้นวนลูปหาไฟล์ โยนเข้า OCR 3 แล้วส่งกลับไปให้ Mistral Large 3 ตีความและแปลงเป็นการตัดสินใจได้เลย
      สถาปัตยกรรมแบบนี้พบได้ทั่วไป และที่จริงแล้วแบบที่ให้โมเดลตัวเดียวทำทุกอย่างกลับพบได้น้อยกว่า
    • “ผมมอบการตัดสินใจทางการเงินสำคัญให้ซอฟต์แวร์ OCR แล้วคุณจะไม่เชื่อเลยว่าเกิดอะไรขึ้นต่อมา”

  • ไม่นานมานี้ผมลองใช้ Opus 4.8 ทำ OCR
    พูดตามตรงมันไม่ใช่เครื่องมือที่ถูกต้องนัก แต่สิ่งที่ต้องการมีแค่ดึงวันที่จากใบเสร็จ
    มันอ่านวันที่ผิดประมาณ 20% แต่กลับให้คะแนนทั้งหมดว่า “ความเชื่อมั่นสูง”
    น่าจะควรลองใช้ โมเดลที่ออกแบบมาสำหรับ OCR โดยเฉพาะ

    • การดึงวันที่จากใบเสร็จน่าจะเป็นปัญหาที่แทบถูกแก้ได้หมดแล้วตั้งแต่ราว 30 ปีก่อนหรือเปล่า
      จำได้ว่าแม้แต่เครื่องมือ OCR แบบแชร์แวร์ที่แถมมากับสแกนเนอร์ขาวดำสมัยก่อนก็น่าจะยังผิดน้อยกว่า 20%
    • ไม่แน่ใจเรื่อง Opus แต่ OCR ในผลิตภัณฑ์แบบสมัครสมาชิกของ Gemini ดูเหมือนจะไม่ได้ให้โมเดลทำเอง
      น่าจะใช้เครื่องมือ OCR แยกต่างหากแบบเก่า ๆ และผลทดสอบก็ออกมาแย่
      ในทางกลับกัน Gemini API ให้โมเดลทำ OCR เอง เลยแม่นยำกว่ามาก
    • Opus ทำ OCR ได้ดีมาก
      ดีกว่าโมเดล vision-language ขนาดเล็ก 1~4B มาก
      ถ้า Opus ยังพลาด โมเดลเล็กพวกนั้นส่วนใหญ่ก็น่าจะพลาดเหมือนกัน
    • เรื่องนี้ฟังดูเชื่อยาก
      ช่วงหลังผมสแกน PDF หลายร้อยไฟล์ที่มีลายมืออ่านยากสุด ๆ ด้วย Opus 4.8 และนอกจากบันทึกชิ้นหนึ่งที่แม้แต่ผมเองยังอ่านไม่ออกแล้ว มัน สำเร็จ 100%