สมมติว่าคุณมีระบบอ่านใบเสร็จกับใบกำกับภาษีใช้อยู่แล้ว ทุกเดือนมีบิลที่ถ่ายจากมือถือเข้ามาเป็นร้อยใบ แล้ววันหนึ่งก็มีโพสต์ประกาศโมเดลใหม่โผล่มาในฟีด Typhoon OCR v2 โมเดล OCR (อ่านตัวอักษรจากภาพ) ภาษาไทยแบบเปิดให้ดาวน์โหลด คะแนนอ่านหน้าเอกสารไทยขึ้นจาก 64.3 เป็น 81.3 ทิ้งรุ่นก่อนไป 17 จุด
คำถามที่ตามมาแทบทันทีคือ ควรเปลี่ยนไหม คะแนนขึ้นขนาดนี้ บิลที่เคยอ่านพลาดก็น่าจะหายไปเยอะ
Productize ทดสอบ Typhoon OCR v2 กับบิลภาษาไทยจริง 189 ใบ ชุดเดียวกับที่ใช้ทดสอบทุกโมเดลก่อนหน้า แล้วนับทีละใบเทียบกับ v1.5 ว่าโมเดลอ่านยอดรวม เลขผู้เสียภาษี และเลขที่เอกสารออกมาถูกหรือเปล่า
ช่วงที่ 1เกณฑ์ที่ใช้ตัดสิน: เลขถูก และอยู่ถูกช่อง
พอซอฟต์แวร์บัญชีอ่านบิลหนึ่งใบ สิ่งที่ต้องได้จริงๆ มีไม่กี่ช่อง คือยอดรวม เลขประจำตัวผู้เสียภาษีของผู้ขาย เลขที่เอกสาร วันที่ ต่อให้โมเดลอ่านภาษาไทยทุกคำบนบิลออกมาได้ครบ แต่ถ้าเอายอดภาษีไปใส่ในช่องยอดรวม บิลใบนั้นก็ใช้ไม่ได้อยู่ดี
ส่วน benchmark หลักที่ Typhoon ใช้ประกาศผล อย่าง MDPBench กับ olmOCR-bench ให้คะแนนการถอดหน้า คือดูว่าข้อความทั้งหน้าที่โมเดลอ่านออกมาตรงกับเฉลยแค่ไหน เหมือนวัดพนักงานพิมพ์ดีดจากความครบของการพิมพ์ทั้งหน้า ทั้งที่ร้านต้องการคนที่ชี้ได้ว่าเลขไหนคือยอดที่ต้องจ่าย
เราจึงให้คะแนนได้ 2 แบบ
- ให้คะแนนรายช่อง ค่าในแต่ละช่องต้องถูก และต้องอยู่ถูกช่อง แบบนี้ตรงกับงานจริงที่สุด แต่ต้องมีขั้นจัดค่าลงช่องก่อนจะตรวจได้
- คัดกรองแบบหลวม ดูแค่ว่าค่าที่ถูกโผล่อยู่ที่ไหนสักแห่งในข้อความที่โมเดลอ่านออกมาไหม ไม่จัดลงช่อง ไม่ตรวจทาน ทำได้เร็วและต้นทุนต่ำ
รอบนี้เราใช้แบบที่ 2 เพราะอยากรู้ก่อนว่า v2 "มองเห็น" ตัวเลขที่ต้องใช้มากขึ้นไหม ถ้าโมเดลหาเลขไม่เจอตั้งแต่ขั้นนี้ ให้คะแนนรายช่องก็ไม่มีทางผ่าน แต่หาเจอไม่ได้แปลว่าจะกรอกถูกช่อง ผลทดสอบรอบนี้จึงบอกว่าโมเดลเห็นเลขกี่ใบ ไม่ได้บอกว่ากรอกถูกกี่ใบ พอใช้งานจริง ความแม่นจะเท่านี้หรือต่ำกว่า ไม่มีทางสูงกว่า
ช่วงที่ 2โมเดลที่ลงทดสอบ และวิธีทดสอบ
เราวางโมเดล 3 ตัวไว้ข้างกัน ตัวเอกคือ Typhoon OCR v2 ที่เพิ่งออก คู่เทียบตัวแรกคือ Typhoon OCR 1.5 รุ่นก่อนหน้าของมันเอง ทั้งคู่ขนาด 2B คือมี 2 พันล้านพารามิเตอร์ เล็กพอจะรันบนการ์ดประมวลผล (GPU) รุ่นเล็กได้ ถ้า v2 เก่งขึ้นจริง ต้องเห็นจากการเทียบกับรุ่นพี่ตัวนี้ก่อน คู่เทียบอีกตัวคือ Qwen3-VL ขนาด 4B โมเดลอ่านภาพทั่วไปที่เราเคย fine-tune (ฝึกต่อกับข้อมูลของงานเฉพาะ) ด้วยบิลของเราเอง ตัวนี้ไม่ได้ทำมาเพื่อภาษาไทยโดยเฉพาะ แต่ผ่านบิลจริงมาแล้ว เลยใช้เป็นไม้บรรทัดว่าโมเดลภาษาไทยสำเร็จรูปตามทันหรือยัง ผลของมันมาจากการทดสอบรอบก่อน
ของใหม่ใน v2 ที่คนทำงานกับบิลน่าจะสนใจมี 2 เรื่อง เรื่องแรกคือ v2 บอกตำแหน่งของข้อความแต่ละก้อนบนหน้ามาด้วย (bounding box) ถ้าระบบต้องรู้ว่ายอดรวมอยู่ตรงไหนของบิล ข้อมูลนี้อาจช่วยได้ เรื่องที่สองคือสัญญาอนุญาต ตัวหลักเป็น Apache-2.0 แต่มีเงื่อนไขของ OpenTyphoon กำกับอยู่ด้วย ใครจะเอาไปใช้ในเชิงพาณิชย์ควรอ่านเงื่อนไขนี้ก่อน ส่วนคนที่ไม่อยากเช่า GPU ก็มีรุ่นเล็ก 0.8B กับรุ่น GGUF และ MLX ที่ทำไว้รันบนคอมพิวเตอร์ทั่วไป
ก่อนลงมือ เราเปิดดูคะแนนของ v1.5 กับ v2 ในการ์ดโมเดล (หน้าคำอธิบายที่ผู้พัฒนาเผยแพร่คู่กับโมเดล) ตามตารางข้างล่าง ยิ่งสูงยิ่งดี MDPBench กับ olmOCR-bench เป็นชุดข้อสอบถอดหน้าเอกสาร ส่วน ThaiOCRBench เป็นชุดข้อสอบภาษาไทยหลายงาน รวมถึงงานดึงข้อมูลสำคัญออกจากเอกสาร
| benchmark (ตามการ์ดโมเดล) | v1.5 | v2 | ขึ้น |
|---|---|---|---|
| MDPBench หน้าเอกสารภาษาไทย | 64.3 | 81.3 | +17.0 |
| ThaiOCRBench | 40.5 | 59.9 | +19.4 |
| olmOCR-bench | 62.0 | 84.7 | +22.7 |
จากนั้นเราให้ v2 อ่านบิลจริงชุดเดิม 189 ใบที่ใช้กับทุกโมเดลที่เคยลอง มีทั้งรูปถ่ายและไฟล์สแกน ภาพทุกใบปรับให้ขนาดเท่ากันเหมือนทุกรอบ รันบน GPU ที่เช่ามาตัวเดียว และตั้งค่าตามที่การ์ดโมเดลบอกทุกอย่าง
ช่วงที่ 3Typhoon OCR v2 อ่านบิลดีกว่า v1.5 แค่ไหน?
ดีกว่าทั้ง 3 ช่องที่วัด แต่ส่วนต่างอยู่ที่ 3 ถึง 6 ใบในทุก 100 ใบ ไม่ได้ใกล้ 17 จุดอย่างที่ benchmark บอกเลย
ตัวเลขในตารางคือจำนวนบิลที่ค่าที่ถูกโผล่อยู่ในข้อความที่โมเดลอ่านออกมา (คัดกรองแบบหลวม) เช่น ยอดรวม v2 หาเจอ 166 จาก 189 ใบ มากกว่า v1.5 อยู่ 7 ใบ คิดเป็น 3.7 จุด (บนบิล 100 ใบ ทุก 1 จุดคือหาเจอเพิ่มราว 1 ใบ)
| ช่องที่หา (คัดกรองแบบหลวม) | v1.5 | v2 | ต่างกัน |
|---|---|---|---|
| ยอดรวม | 159/189 (84.1%) | 166/189 (87.8%) | +7 ใบ (+3.7 จุด) |
| เลขผู้เสียภาษีของผู้ขาย | 160/189 (84.7%) | 172/189 (91.0%) | +12 ใบ (+6.3 จุด) |
| เลขที่เอกสาร | 107/188 (56.9%) | 112/188 (59.6%) | +5 ใบ (+2.7 จุด) |
ช่องที่ขึ้นมากที่สุดคือเลขผู้เสียภาษี 12 ใบจาก 189 ส่วนเลขที่เอกสาร (นับจาก 188 ใบ) ทั้ง 2 รุ่นหาเจอแค่ราว 6 ใน 10 ใบ และอย่าลืมว่านี่คือเกณฑ์แบบหลวม พอต้องวางเลขลงช่องจริง ตัวเลขจะเท่านี้หรือต่ำกว่า
ลูปซ้ำ: 11 ใบจาก 189
บิล 11 ใบ หรือ 5.8% ทำให้ v2 พิมพ์ตัวอักษรชุดเดิมซ้ำไม่จบ เราตัดสินว่าเป็นลูปเมื่อตัวอักษร 1 ถึง 6 ตัวชุดเดียวกันซ้ำติดกันเกิน 30 รอบ เช่น "1111…" ใบที่หนักที่สุดใช้เวลาไป 278 วินาที ราว 10 เท่าของบิลทั่วไป
เราเอาตัวตรวจเดียวกันไปไล่ข้อความที่ v1.5 อ่านจากบิลชุดเดียวกัน ปรากฏว่า v1.5 ติดลูปแค่ 3 ใบ ลูป 11 ใบของ v2 จึงเป็นความเสี่ยงที่มาพร้อมรุ่นใหม่ ส่วนเรื่องคะแนน ใบที่ติดลูปไม่ได้โดนหักเพิ่ม เราตรวจข้อความทั้งหมดที่โมเดลพิมพ์ออกมา ถ้าค่าที่ถูกโผล่มาก่อนเข้าลูป ใบนั้นก็ยังนับว่าหาเจอ
การ์ดโมเดลเขียนไว้เองว่าทีมผู้พัฒนาฝึกโมเดลรอบท้ายเพื่อลดลูปบนรูปถ่ายเอกสารโดยเฉพาะ และแนะนำให้ขยายภาพที่ด้านยาวไม่ถึง 1600 พิกเซลก่อนส่งเข้าโมเดล เพราะภาพเล็กทำให้เกิดลูปง่าย ภาพของเราใหญ่กว่าเกณฑ์นั้นอยู่แล้ว ลูปราว 6% ที่เราเจอจึงไม่น่าจะมาจากภาพเล็ก แต่น่าจะมาจากบิลจริงบางแบบที่ยังพาโมเดลหลุดได้อยู่ดี
ความเร็วและค่าใช้จ่าย
บิลครึ่งหนึ่งอ่านเสร็จภายใน 27 วินาที (ค่ามัธยฐาน) แต่เวลาเฉลี่ยอยู่ที่ 48 วินาทีต่อใบ เพราะบิลที่ติดลูปลากค่าเฉลี่ยขึ้นไป ถ้าจะประเมินว่าวันหนึ่งอ่านได้กี่ใบ ให้ใช้ตัวเลขเฉลี่ย ไม่ใช่มัธยฐาน
ค่าใช้จ่ายทั้งรอบราว 2 ดอลลาร์สหรัฐ คิดจาก GPU รุ่น L4 ชั่วโมงละ 0.80 ดอลลาร์ กับเวลาเฉลี่ย 48 วินาทีต่อใบ ก็ตกใบละราว 1 เซนต์ ถูกพอจะลองกับบิลของตัวเองได้โดยไม่ต้องขออนุมัติงบจากใคร
ช่วงที่ 4ทำไมคะแนนขึ้น 17 จุด แต่อ่านบิล ดีขึ้นนิดเดียว?
เพราะ benchmark ให้คะแนนการถอดหน้าเอกสาร ส่วนงานอ่านบิลให้คะแนนว่าเลขที่ถูกไปอยู่ในช่องที่ถูกหรือเปล่า สองเรื่องนี้เกี่ยวกัน แต่ไม่ใช่เรื่องเดียวกัน
การถอดหน้าให้คะแนนทุกตัวอักษรบนหน้า ทั้งย่อหน้า หัวเรื่อง ตาราง ส่วนบิลหนึ่งใบมีส่วนที่ต้องอ่านให้ถูกจริงๆ แค่ตัวเลขไม่กี่ชุด กับป้ายกำกับสั้นๆ ข้างตัวเลข โมเดลที่ถอดย่อหน้าภาษาไทยได้ดีขึ้นมาก จึงอาจได้คะแนนพุ่ง โดยที่ยอดรวมบนบิลไม่ได้อ่านเจอเพิ่มขึ้นมากตามไปด้วย
การ์ดโมเดลเองก็บอกเรื่องนี้ไว้ ใน ThaiOCRBench งานที่ใกล้กับการดึงค่าออกจากบิลที่สุดคืองานดึงข้อมูลสำคัญ (key-information extraction) ได้ 21.0 คะแนน ต่ำที่สุดในทุกงานของชุดนั้น ทีมผู้พัฒนาเขียนเตือนไว้ด้วยว่าให้ตรวจข้อมูลที่ดึงออกมาก่อนเอาไปใช้ต่อ
เราเจอเรื่องเดียวกันมาแล้วตั้งแต่รอบก่อน ตอนกรกฎาคม 2026 ที่ให้คะแนนรายช่องแบบเต็มกับบิลชุดเดียวกันนี้ Typhoon OCR 1.5 ได้ 51.9% ส่วนโมเดลอ่านภาพทั่วไปที่เรา fine-tune กับบิลได้ 71.8% และ Typhoon ยังช้ากว่าด้วย (43.1 เทียบกับ 38.7 วินาทีต่อใบ) ตอนนั้นเราสรุปได้ว่า โมเดลที่ทำมาเพื่อภาษาไทยโดยเฉพาะไม่ได้เปรียบในงานนี้ เพราะงานจริงคือการอ่านตัวเลข
คำถามที่ควรถามจึงเปลี่ยนจาก "โมเดลไหนอ่านภาษาไทยเก่งที่สุด" เป็น "โมเดลไหนวางเลขถูกช่องบนบิลแบบของเรา"
v2 จะปิดช่องว่างราว 20 จุดนั้นได้ไหม ตอนนี้เรายังตอบไม่ได้ เพราะยังไม่ได้ให้คะแนนรายช่องกับ v2 สิ่งเดียวที่รู้คือ ในเกณฑ์แบบหลวม v2 ขยับจาก v1.5 แค่ 3 ถึง 6 จุด
ช่วงที่ 5งานไหนควรใช้ตัวไหน และต้องระวังอะไร
ถ้าถามเราจากที่เห็นในรอบนี้ คำตอบขึ้นกับว่าคุณจะเอาไปทำงานแบบไหน
| งานของคุณ | ตัวที่เหมาะ | เหตุผล |
|---|---|---|
| ถอดเอกสารภาษาไทยทั้งหน้าเป็นข้อความหรือตาราง เช่น สัญญา รายงาน เอกสารเก่า | Typhoon OCR v2 | งานนี้ตรงกับสิ่งที่ benchmark วัด คะแนนขึ้นชัด ตารางออกมาเป็น HTML พร้อมตำแหน่งบนหน้า |
| ใช้ v1.5 อ่านบิลอยู่แล้ว | เปลี่ยนเป็น v2 ได้ ถ้ารับมือเรื่องลูปได้ | ดีกว่าทุกช่องที่เราวัด แต่ดีกว่าไม่มาก อย่าคาดหวังว่าบิลที่อ่านพลาดจะหายไปเกือบหมด และ v2 ติดลูป 11 ใบ ขณะที่ v1.5 ติดแค่ 3 ใบ ก่อนเปลี่ยนจึงต้องตั้งเวลาสูงสุดต่อใบไว้ |
| ดึงยอดรวม เลขผู้เสียภาษี เลขที่เอกสาร จากบิลเป็นงานหลัก | โมเดลที่ชนะการทดสอบรายช่องบนบิลของคุณเอง | รอบก่อนโมเดลทั่วไปที่ fine-tune กับบิล ชนะ v1.5 ห่างราว 20 จุด ส่วน v2 ยังไม่ได้วัดรายช่อง |
| อยากรันบนเครื่องเล็ก ไม่มี GPU ใหญ่ | รุ่น 0.8B หรือ GGUF และ MLX | มีให้ใช้ แต่เรายังไม่ได้ทดสอบกับบิล |
| ใช้เป็นตัวอ่านที่สอง คืออ่านบิลใบเดียวกันคู่กับโมเดลหลักแล้วเทียบผล | ยังตอบไม่ได้ | bounding box อาจช่วยหาตำแหน่งเลขที่เอกสาร ซึ่งเป็นช่องที่ทั้ง v1.5 และ v2 หาเจอน้อยที่สุด เรายังไม่ได้ทดสอบ |
ไม่ว่าจะเลือกตัวไหน ระบบที่อ่านบิลก็ควรรู้ตัวเวลาอ่านพลาด เช่น เช็กว่ายอดก่อนภาษีบวกภาษีแล้วเท่ากับยอดรวมไหม ถ้าไม่เท่าก็ส่งให้คนดู เราเล่าเรื่องนี้ไว้แยกอีกบทความ
ก่อนเอา v2 ไปรันจริง
สิ่งแรกที่ต้องเตรียมคือเพดานต่อใบ บิลที่ติดลูปหนักที่สุดในรอบนี้กินเวลาไป 278 วินาที ตลอดเวลานั้นค่าเช่า GPU ก็เดินไปกับตัวอักษรชุดเดิมที่ไม่มีใครเอาไปใช้ได้ ระบบจริงจึงควรกำหนดเวลาสูงสุดและความยาวสูงสุดของคำตอบไว้ ใบไหนชนเพดานก็นับว่าอ่านไม่ได้แล้วส่งให้คนดู ถ้าย้ายมาจาก v1.5 ที่แทบไม่ติดลูป ส่วนนี้คืองานที่ต้องทำเพิ่ม
บิลแบบนี้ยังถ่วงเวลาทั้งคิวด้วย ถ้าวางแผนจาก 27 วินาทีของบิลที่อ่านง่าย งานจะช้ากว่าที่คิด เพราะใบแบบ 278 วินาทีแทรกมาเป็นระยะ ตัวเลขที่ควรใช้คือค่าเฉลี่ย 48 วินาทีต่อใบบน L4
อีกสองเรื่องอยู่ที่การตั้งค่า เรื่องแรกคือรุ่นของ vLLM (โปรแกรมโอเพนซอร์สสำหรับรันโมเดลบน GPU) การ์ดโมเดลให้ใช้ 0.30.0 ขึ้นไป ถ้าต้องใช้รุ่นเก่ากว่า ให้เปิดโหมด eager (สั่งให้ vLLM ไม่คอมไพล์โมเดลล่วงหน้า) เพราะบน vLLM 0.27.1 ทีมผู้พัฒนาวัดโหมดปกติได้ 70.8 คะแนน โหมด eager ได้ 80.0 ทั้งที่เป็นโมเดลตัวเดียวกัน รอบนี้เราใช้ 0.33.0 เรื่องที่สองคือขนาดภาพ ภาพที่ด้านยาวไม่ถึง 1600 พิกเซลต้องขยายเองก่อนส่ง ตัวโมเดลไม่ขยายให้
ท้ายสุดคือเงื่อนไขการใช้ นอกจาก Apache-2.0 ยังมีเงื่อนไขของ OpenTyphoon กำกับอยู่ ถ้าจะใช้ในงานเชิงพาณิชย์ อ่านให้ครบก่อน
ช่วงที่ 6ทดสอบกับบิล ของคุณเอง แบบเล็กๆ
คะแนน benchmark บอกว่าโมเดลอ่านหน้ากระดาษของคนอื่นเก่งขึ้นแค่ไหน ส่วนจะอ่านบิลของคุณถูกแค่ไหน วิธีที่ตรงที่สุดคือลองกับบิลของคุณเอง ไม่ต้องทำใหญ่ด้วย รอบนี้ของเราใช้เงินแค่ราว 2 ดอลลาร์
เริ่มจากเก็บบิลจริงมาสักร้อยกว่าใบ ให้มีทั้งรูปถ่าย ไฟล์สแกน ใบที่ซีด ใบที่ยับ ปนกันแบบที่เข้ามาจริงในแต่ละเดือน แล้วจดค่าที่ถูกของช่องที่สำคัญกับงานไว้ 3 ถึง 5 ช่องก็พอ เช่น ยอดรวม เลขผู้เสียภาษี เลขที่เอกสาร ใส่ลงตารางใน Excel หรือ Google Sheets ใบละแถว ช่องละคอลัมน์ ตารางนี้คือเฉลยที่ใช้ตรวจทุกโมเดล
จากนั้นรันทุกโมเดลด้วยเงื่อนไขเดียวกัน ภาพขนาดเดียวกัน GPU เดียวกัน ตั้งค่าตามการ์ดโมเดลของแต่ละตัว ไม่อย่างนั้นจะเทียบกันไม่ได้ ถ้ายังไม่เคยเช่า GPU รันโมเดล เราเล่าวิธีที่ใช้กับ Modal (บริการเช่า GPU ที่คิดเงินตามเวลาที่ใช้จริง) ไว้แล้ว
ได้ผลมาแล้ว ให้คัดกรองแบบหลวมก่อน ตัวไหนหาเลขไม่เจอตั้งแต่ขั้นนี้ ตัดออกได้เลย ตัวที่เหลือค่อยให้คะแนนรายช่อง ทางที่ง่ายที่สุดคือสั่งให้โมเดลตอบค่าของแต่ละช่องออกมาตรงๆ แล้วเทียบกับเฉลยทีละช่อง ถ้าโมเดลให้ได้แค่ข้อความทั้งหน้า ก็ต้องมีขั้นจัดค่าลงช่องก่อน จะใช้โมเดลอีกตัวหรือกฎที่เขียนเองก็ได้ ระหว่างนี้นับลูป เวลาเฉลี่ย และค่าใช้จ่ายต่อใบไปด้วย
เรื่องสุดท้ายเราได้มาจากรอบนี้เอง รอบแรกเน็ตของโน้ตบุ๊กที่ใช้สั่งงานหลุดกลางคัน บิลหายไป 54 ใบ ที่ไม่ต้องเริ่มใหม่ทั้งชุดก็เพราะสคริปต์บันทึกผลทีละใบ พอสั่งรันอีกรอบ มันก็เติมเฉพาะ 54 ใบที่ขาด ไม่ต้องจ่ายค่า GPU ซ้ำ ถ้าจะเขียนสคริปต์ทดสอบเอง ให้บันทึกผลทีละใบแบบนี้ตั้งแต่แรก
รอบหน้าเราจะลองให้ v2 เป็นตัวอ่านที่สองข้างโมเดลหลัก ดูว่า bounding box ช่วยหาเลขที่เอกสารได้จริงไหม และให้คะแนน v2 แบบรายช่องเต็มรูปแบบ ผลออกมาเมื่อไรจะกลับมาเติมในบทความนี้
ส่วนตอนนี้ ถ้าคุณมีบิลกองอยู่ในลิ้นชักสักร้อยใบ นั่นก็เป็นข้อสอบที่บอกอะไรคุณได้มากกว่า benchmark ชุดไหนๆ แล้ว
วิธีที่เรารัน ใครอยากรันตาม นี่คือค่าที่เราใช้ทั้งหมด เรารันบน GPU รุ่นเล็กของ NVIDIA ชื่อ L4 ตัวเดียว เช่าผ่าน Modal (บริการเช่า GPU ที่คิดเงินตามเวลาที่ใช้จริง) ภาพทุกใบย่อหรือขยายให้ด้านยาวเท่ากันที่ 1800 พิกเซล ใช้ vLLM รุ่น 0.33.0 ตั้ง temperature เป็น 0 ให้โมเดลตอบแบบเดิมทุกครั้งไม่สุ่ม และใช้ prompt อ่านโครงหน้า (ข้อความสั่งให้โมเดลถอดทั้งหน้าออกมา) ตัวเดียวกับที่การ์ดโมเดลให้มา
- การ์ดโมเดล Typhoon OCR v2 2B (คะแนน benchmark, สถาปัตยกรรม Qwen3.5 ที่ fine-tune ต่อจาก Infinity-Parser2-Flash, คำเตือนเรื่อง vLLM และขนาดภาพ, คะแนนงานดึงข้อมูลสำคัญ 21.0): huggingface.co/typhoon-ai/typhoon-ocr2-2b
- ผลทดสอบ v2 กับ v1.5 แบบคัดกรองหลวม บนบิลจริง 189 ใบ: การรันของเราเอง 9 พฤศจิกายน 2026
- ผลให้คะแนนรายช่อง v1.5 เทียบกับโมเดลทั่วไปที่ fine-tune กับบิล: การรันของเราเอง 13 กรกฎาคม 2026 บิลชุดเดียวกัน
อ่านต่อ: OCR accuracy ไม่ได้อยู่ที่โมเดลอ่านเก่ง แต่อยู่ที่ระบบรู้ตัวว่าอ่านผิด
Modal GPU รัน AI แบบจ่ายตามจริง ทำระบบ OCR ได้ทั้งระบบ
อ่าน LLM benchmark ยังไงไม่ให้โดนหลอก