Fine-tune OCR ภาษาไทยจนใช้งานจริง: เทรนเต็ม 7 รอบแทบไม่ต่าง LoRA ที่ใช้งานได้จริง ตัวป้องกันที่พัฒนาคู่กัน และชุดทดสอบที่รั่ว

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

• คำนวณใหม่ จากไฟล์ผลดิบตอนเขียนบทความนี้ (กันยายน 2026)
• อ่านจากไฟล์ตั้งค่าหรือไฟล์ผลโดยตรง เช่น ขนาดชุดข้อมูลและค่าที่ใช้เทรน
• “ตามบันทึกตอนนั้น” คือยังไม่ได้คำนวณซ้ำ เราเขียนกำกับไว้ทุกจุด

บทนี้เล่าการ fine-tune โมเดล OCR ภาษาไทยแบบเปิดขนาด 2B ให้อ่านเอกสารธุรกิจไทย เช่น สมุดบัญชีเงินฝาก หนังสือเดินทาง งบการเงิน และแบบรายชื่อผู้ถือหุ้น ตั้งแต่ประเมินผลรอบแรกวันที่ 7 กรกฎาคม 2026 จนขึ้นใช้งานจริงวันที่ 15 กรกฎาคม 2026 รวมถึงความผิดพลาดที่เราเพิ่งพบตอนเตรียมบทความนี้

ถ้ายังไม่คุ้นกับคำว่า fine-tune, LoRA หรือชุดทดสอบ อ่านซีรีส์ Fine-tune โมเดลภาษาก่อนได้

1.1 โจทย์และวิธีวัด

ข้อมูล มีหน้าที่ใช้ได้ 12,218 หน้า จากงานที่ส่งเข้ามา 4,492 งาน แบ่งเป็นชุดเทรน 11,205 หน้า ชุดตรวจระหว่างเทรน 305 หน้า และชุดทดสอบอีกหลายชุด การแบ่งทำ ตามงาน คือหน้าจากงานเดียวกันอยู่ชุดเดียวกัน ชุดที่ใช้วัดทุกรอบของการเทรนเต็มคือ “หน้ายาก” 98 หน้า

ตัววัด มีสามตัว

• CER คือสัดส่วนตัวอักษรที่อ่านผิดเทียบกับเฉลย 0 คือตรงทุกตัว เรารายงานเป็นค่ามัธยฐานของทุกหน้า
• อัตราผิดของตัวยาก คือความผิดเฉพาะตัวที่มักอ่านพลาด ได้แก่ พยัญชนะที่ใช้น้อย เลขไทย และสระหรือวรรณยุกต์อย่าง ำ ุ ู ่ ้ ๊ ๋
• จำนวนหน้าที่พังหนัก คือหน้าที่ CER ตั้งแต่ 0.5 ขึ้นไป

บทเรียนแรก: เฉลยเองก็คลาดเคลื่อน

• เฉลยของ 98 หน้านี้ ให้โมเดล AI แก้ แล้วคนสุ่มตรวจ ไม่ได้ให้คนพิมพ์ใหม่ทั้งหมด
• เราให้โมเดล AI ถอดข้อความ 12 หน้าสองครั้งแยกกัน โดยแต่ละครั้งไม่เห็นผลของอีกครั้ง ผลสองชุดต่างกันที่ค่ามัธยฐาน CER 0.115 และเพราะทั้งสองครั้งเป็นโมเดลตัวเดียวกัน ความคลาดเคลื่อนจริงน่าจะสูงกว่านี้
• เกณฑ์ผ่านที่เราตั้งไว้คือมัธยฐาน CER ต่ำกว่า 0.10 ซึ่งเข้มกว่าที่เฉลยสองชุดตรงกันเองได้ ตัวเลขแถว 0.1 จึงบอกไม่ได้มากว่าโมเดลไหนอ่านถูกกว่า

1.2 เทรนเต็ม 7 รอบ

รอบ R1 ถึง R8 (ไม่มี R7 ที่เทรนจริง) เทรนส่วนภาษาของโมเดลทั้งหมด แต่ไม่แตะส่วนที่มองภาพ ใช้ learning rate 1e-5 และเทรน 2 ถึง 3 รอบข้อมูล (epoch)

รอบ	สิ่งที่เปลี่ยน	ผล
R1	ข้อมูลสังเคราะห์ 34% และข้อความที่โมเดลเดิมอ่านเอง 61%	ตามบันทึกตอนนั้น หลายหน้าถูกตัดจบกลางทาง มี 21 จาก 98 หน้าที่ CER เกิน 0.6
R2	ปรับข้อมูลสังเคราะห์ เช่น ตาราง HTML และช่องว่างในตาราง	ตามบันทึกตอนนั้น ดีขึ้นจาก R1
R2 + repetition_penalty	ตั้งค่าลงโทษคำซ้ำ 1.1 กับทุกหน้า	แย่ลงทุกตัววัด
R3	เพิ่มแบบฟอร์มที่สร้างเลียนแบบขึ้นมา 1,500 หน้า	แย่ลง บันทึกตอนนั้นวินิจฉัยว่าโมเดลจำแม่แบบที่สร้างขึ้น
R4	ใช้หน้าจริง 48 หน้าที่ให้โมเดล AI แก้เฉลยแล้วคนสุ่มตรวจ ใส่ซ้ำ 4 ครั้ง (ราว 4% ของชุดเทรน)	ดีกว่า R3 ชัดเจน
R5–R8	เพิ่มหน้าจริง ทำภาพเสียแบบสุ่ม (augmentation) ตัดหน้าที่เกือบซ้ำ	ขึ้นลงสลับกัน R8 ดีที่สุดในกลุ่มนี้
Soup	เอาน้ำหนักของ R4 กับ R5 มาเฉลี่ยกัน	ล้มเหลว แย่กว่าทั้ง R4 และ R5 บน 76 หน้าที่ไม่รั่ว (ข้อ 1.4)

checkpoint ระหว่างทางมักดีกว่าตอนจบ ใน R5 และ R6 checkpoint ที่บันทึกระหว่างเทรนได้ค่ามัธยฐานดีกว่าโมเดลตอนเทรนจบ ส่วน R8 checkpoint ดีกว่าที่อัตราผิดตัวยาก แต่ค่ามัธยฐานบน 98 หน้า โมเดลตอนจบดีกว่าเล็กน้อย (0.120 เทียบ 0.124) ทุกส่วนต่างเหล่านี้เล็กจนอาจเป็นความบังเอิญ บทเรียนคือเทรนนานขึ้นไม่ได้แปลว่าดีขึ้น

1.3 ชุดทดสอบรั่ว: สิ่งที่เราเพิ่งพบ

ตอนเตรียมบทความนี้ เราเทียบลายนิ้วมือไฟล์ (md5) ของรูปทุกหน้าในชุดทดสอบกับรูปทุกรูปในชุดเทรนทุกรอบ ผลคือ อย่างน้อย 22 จาก 98 หน้า มีไฟล์ที่เหมือนกันทุกไบต์อยู่ในชุดเทรนอย่างน้อยหนึ่งชุด

• สาเหตุ เราแบ่งชุดตามงาน แต่ไฟล์เดียวกันถูกส่งเข้ามาในหลายงาน จึงไปอยู่ทั้งฝั่งเทรนและฝั่งทดสอบ ชุดทดสอบ 98 รายการเองก็มีรูปที่ไม่ซ้ำกันเพียง 93 รูป
• ผลที่เห็นชัดที่สุด เราเคยสรุปว่า R8 “แก้ปัญหาลายน้ำได้แล้ว” จากหน้าปกสมุดบัญชีที่มีลายน้ำปูเต็มหน้า หน้านี้อยู่ในชุดทดสอบสองรายการที่เป็นภาพเดียวกัน และภาพนี้อยู่ในชุดเทรนของ R8 ถึง 4 สำเนา โมเดลเคยเห็นหน้านี้มาแล้ว
• รั่วแล้วไม่ได้ช่วยเสมอไป แบบฟอร์มที่มีช่องติ๊กว่างเป็นแถวสองหน้าอยู่ในชุดเทรนของ R4 ถึง R8 แต่ R8 checkpoint ระหว่างทางยังอ่านวนซ้ำจนพังบนสองหน้านี้ (CER 0.97) ขณะที่โมเดลเดิมอ่านได้ดีกว่ามาก (CER 0.50 และ 0.46)
• 22 คือค่าต่ำสุด เพราะเราตรวจเฉพาะไฟล์ที่เหมือนทุกไบต์ ภาพเดียวกันที่ถูกบันทึกใหม่เป็นไฟล์อื่นจะตรวจไม่เจอ
• ชุดวัดสาธารณะไม่รั่วเข้าชุดเทรนของเรา รูปทั้ง 140 รูปในชุดวัดสาธารณะที่ใช้ในข้อ 1.5 ไม่มีสักรูปอยู่ในชุดเทรนของเรา แต่เราบอกไม่ได้ว่าผู้สร้างโมเดลฐานเคยเทรนด้วยชุดนี้หรือไม่

ในบันทึกของโปรเจกต์เขียนไว้ว่าห้ามเทรนบนชุดทดสอบ กฎนี้ถูก แต่การแบ่งตามงานไม่ได้บังคับให้เป็นอย่างนั้นจริง

1.4 คำนวณใหม่บน 76 หน้าที่ไม่รั่ว

ตัวเลขในวงเล็บคือค่าเดิมบน 98 หน้า ทุกแถวใช้ตัวกันวนซ้ำและลองอ่านใหม่ (guards) แบบเดียวกันตอนอ่าน ยกเว้นแถว R2 + repetition_penalty ที่รันโดยไม่มี guards

รุ่น	มัธยฐาน CER	อัตราผิดตัวยาก	หน้าที่พังหนัก
โมเดลเดิม + guards	0.092 (0.124)	0.0365 (0.0648)	2 (10)
R2 + repetition_penalty ไม่มี guards	0.116 (0.169)	0.0906 (0.1617)	5 (18)
R3	0.118 (0.152)	0.0524 (0.1060)	2 (14)
R4	0.098 (0.132)	0.0645 (0.0792)	2 (5)
R6 checkpoint ระหว่างทาง	0.091 (0.132)	0.0363 (0.0543)	2 (4)
R8 ตอนจบ	0.089 (0.120)	0.0355 (0.0745)	0 (4)
R8 checkpoint ระหว่างทาง	0.087 (0.124)	0.0263 (0.0580)	0 (3)
Soup R4+R5	0.127 (0.135)	0.0997 (0.0977)	6 (6)

อ่านตารางนี้อย่างไร

• เทียบทีละหน้ากับโมเดลเดิม ไม่มีรอบไหนชนะเกินความบังเอิญ ที่ใกล้สุดคือ R6 checkpoint ดีกว่า 43 หน้า แย่กว่า 32 หน้า ส่วน R8 checkpoint ดีกว่า 36 หน้า แย่กว่า 37 หน้า และ R4 ดีกว่า 30 หน้า แย่กว่า 40 หน้า
• สิ่งที่ดูดีขึ้นมีสองอย่าง หน้าที่พังหนักลดจาก 2 เหลือ 0 และอัตราผิดตัวยากลดจาก 0.0365 เหลือ 0.0263 แต่ 2 กับ 0 เป็นจำนวนน้อยเกินจะสรุป และอัตราผิดตัวยากเป็นค่ารวมตัวเดียวที่เรายังไม่ได้ทดสอบว่าต่างเกินความบังเอิญหรือไม่
• ตัดหน้าที่รั่วออกก็ซ่อนจุดอ่อนไปด้วย หน้าที่พังหนัก 3 หน้าของ R8 checkpoint บน 98 หน้า อยู่ในกลุ่มที่รั่วทั้งหมด รวมถึงแบบฟอร์มช่องติ๊กสองหน้าในข้อ 1.3 ตาราง 76 หน้าจึงไม่เห็นว่าการ fine-tune สร้างอาการพังแบบใหม่ขึ้นมา บันทึกตอนนั้นสรุปไว้ว่าการ fine-tune “แลกอาการพังแบบหนึ่งกับอีกแบบ ไม่ได้ดีขึ้นอย่างเดียว”
• เทียบกับอะไรสำคัญมาก ตอนนั้นเราเคยสรุปว่า R4 ดีกว่าโมเดลเดิม 5 เท่า แต่นั่นเทียบกับโมเดลเดิมที่ ไม่มี guards พอให้โมเดลเดิมใช้ guards แบบเดียวกัน โมเดลเดิมกลับได้มัธยฐานดีกว่า (0.124 เทียบ 0.132 บน 98 หน้า)
• ข้อมูลสังเคราะห์มากไม่ได้ช่วย การเพิ่มแบบฟอร์มสังเคราะห์ 1,500 หน้าใน R3 ทำให้แย่ลง (0.118) ส่วนหน้าจริง 48 หน้าใน R4 ไม่ทำให้แย่ลง (0.098) ตัวเลขนี้ยังไม่ได้ทดสอบว่าต่างเกินความบังเอิญหรือไม่

1.5 เทรนเต็มแล้วลืมของเดิม

เราวัดความสามารถทั่วไปด้วยชุดวัด OCR ภาษาไทยสาธารณะ 7 งาน งานละ 20 ภาพ เทียบโมเดลเดิมกับ R8 checkpoint ระหว่างทาง โดยใช้ผลอ่านที่รันด้วยค่าตั้งเดียวกัน และให้คะแนนด้วยตัววัดเดียวกัน

• อ่านทั้งหน้า CER เฉลี่ยจาก 0.308 เป็น 0.597 แต่ R8 ดีกว่า 8 ภาพ แย่กว่า 12 ภาพ ค่าเฉลี่ยพุ่งเพราะมีไม่กี่ภาพที่พังหนัก
• ลายมือ อ่านครบ (recall) จาก 0.885 เหลือ 0.707 แย่ลง 14 ภาพ ดีขึ้น 2 ภาพ เป็นข้อที่ชัดที่สุด
• แยกโครงสร้างเอกสารและตาราง แย่ลงทั้งสองงาน
• ดึงข้อมูลสำคัญ เท่าเดิม ส่วนอีกสองงานดีขึ้นเล็กน้อยในระดับที่อาจเป็นความบังเอิญ

บันทึกตอนนั้นเขียนว่า “แย่ลง 5 จาก 7 งาน ไม่ดีขึ้นเลยสักงาน” พอคำนวณใหม่ด้วยตัววัดนี้ได้ แย่ลง 4 งาน เท่าเดิม 1 งาน ดีขึ้นเล็กน้อย 2 งาน ข้อสรุปใหญ่ยังเหมือนเดิม คือ งานของเราแทบไม่ดีขึ้น แต่ความสามารถทั่วไปหายไป เราจึงเปลี่ยนแนวทาง

1.6 เปลี่ยนมาใช้ LoRA (R9)

R9 ไม่แตะน้ำหนักเดิมของโมเดล แต่เทรน LoRA ขนาด rank 32 alpha 64 dropout 0.05 บนชั้น linear ทั้ง 7 ชนิดของส่วนภาษา ส่วนที่มองภาพยังแช่แข็งไว้ ใช้ learning rate 1e-4 และเทรน 2 epoch (ยกเว้น v1 ที่เทรน 1 epoch)

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

สัดส่วนข้อมูลเฉพาะทาง ชุดเทรนผสมหน้าทั่วไปกับหน้าเฉพาะทาง เช่น แบบรายชื่อผู้ถือหุ้นที่อ่านยาก

• v1 หน้าเฉพาะทางแค่ 5.4% (12 จาก 221 ตัวอย่าง) หน้าทดสอบเฉพาะทางไม่ดีขึ้นเลยสักหน้าจาก 6 หน้า และบางหน้าแย่ลง
• v2 เพิ่มเป็น 26.8% แต่ผลปนกัน ดีขึ้น 2 หน้า แย่ลง 2 หน้า สาเหตุคือเฉลยที่ให้โมเดลสร้างถูกจำกัดความยาวไว้ 1,536 โทเคน ทำให้เฉลย 67% ถูกตัดท้าย
• v3 สัดส่วนเท่าเดิม แต่สร้างเฉลยใหม่ด้วยเพดาน 4,096 โทเคน ดีขึ้น 4 จาก 6 หน้า ไม่มีหน้าไหนแย่ลง แต่เราเพิ่งพบว่า 2 ใน 6 หน้านั้นอยู่ในชุดเทรนของ v3 และทั้งสองหน้าอยู่ในกลุ่มที่ดีขึ้น ถ้าดูเฉพาะ 4 หน้าที่ไม่อยู่ในชุดเทรน ดีขึ้น 2 หน้า เท่าเดิม 1 หน้า และอีก 1 หน้าโมเดลเดิมอ่านได้ดีอยู่แล้ว

จำนวนตัวอย่างที่ไม่ซ้ำอาจสำคัญกว่าจำนวนครั้งที่ซ้ำ หนังสือเดินทางเป็นอีกงานเฉพาะทาง

• v5 ใช้หนังสือเดินทาง 5 เล่ม ซ้ำเล่มละ 4 ครั้ง (12.2% ของชุดเทรน) เล่มที่เทรนอ่านถูก 5 จาก 5 แต่เล่มที่ไม่เคยเห็นอ่านถูก 0 จาก 2 และแต่งคำตอบขึ้นมาเอง 1 ครั้ง คือโมเดลจำ ไม่ได้เรียน
• v7 ใช้ 15 เล่ม ซ้ำเล่มละ 2 ครั้ง (17.2% ของชุดเทรน) เล่มที่ไม่เคยเห็นดีขึ้น 2 จาก 4 เล่ม

จาก v5 ไป v7 ทั้งจำนวนเล่มที่ไม่ซ้ำและสัดส่วนเพิ่มขึ้นพร้อมกัน เราจึงแยกไม่ได้ว่าอะไรเป็นสาเหตุ และตัวอย่างทดสอบก็น้อยมาก (2 และ 4 เล่ม) ข้อนี้จึงเป็นแค่แนวโน้ม ไม่ใช่ข้อพิสูจน์

v7 ใช้ 174 ตัวอย่าง เทรน 22 step ใช้เวลา 17 นาที

v7 กับชุดวัดสาธารณะ เทียบกับโมเดลเดิมด้วยค่าตั้งและตัววัดเดียวกัน

• ไม่มีงานไหนแย่ลงเกินระดับความบังเอิญ
• ลายมือกับการดึงข้อมูลสำคัญดีขึ้นเล็กน้อย
• อ่านทั้งหน้า CER เฉลี่ยจาก 0.342 เป็น 0.294 แต่ v7 ดีกว่าแค่ 6 ภาพ และแย่กว่า 9 ภาพ จึงยังบอกไม่ได้ว่าดีขึ้นจริง

บันทึกตอนนั้นสรุปว่า “ผ่าน” ซึ่งถูกในความหมายว่า ไม่ถอยหลัง แต่ไม่ได้แปลว่า ดีขึ้นทุกด้าน ส่วนที่ v7 ดีกว่าชัดเจนคือเรื่องที่ชุดวัดนี้ไม่ได้วัด ดูข้อ 1.7

ก่อนขึ้นใช้งาน v7 กับโมเดลเดิมแยกประเภทเอกสารถูก 34 จาก 37 ฉบับเท่ากัน และตามบันทึกตอนนั้น ดึงฟิลด์ด้วยกฎถูก 31 จาก 51 เทียบ 30 จาก 51 ส่วนโมเดลเดิมอ่านวนไม่หยุด 4 ฉบับ (ดูข้อ 1.7)

หมายเหตุ: ผลอ่านชุดวัดสาธารณะในข้อ 1.5 กับข้อนี้มาจากการรันคนละครั้ง ใช้เพดานความยาวและตัวกันวนต่างกัน ค่าของโมเดลเดิมจึงไม่เท่ากัน (0.308 และ 0.342) ห้ามเอาตัวเลขข้ามสองชุดมาเทียบกัน

1.7 งานจริง: v7 อ่านจบ โมเดลเดิมมักอ่านไม่หยุด

ชุดวัดในข้อ 1.4 ถึง 1.6 วัดว่าอ่านตัวอักษรถูกแค่ไหน แต่ปัญหาใหญ่ของโมเดลเดิมในงานจริงคือ อ่านไม่หยุด โมเดลวนพิมพ์ข้อความเดิมซ้ำจนได้ขยะหลายหมื่นตัวอักษร ข้อความหน้านั้นเชื่อถือไม่ได้ และงานทั้งงานช้าลง เรื่องนี้ v7 ต่างจากโมเดลเดิมชัดเจน

• หนังสือเดินทาง 19 เล่ม โมเดลเดิมอ่านจบเองได้ 2 เล่ม v7 อ่านจบ 17 เล่ม ตามบันทึกตอนนั้น เมื่อเพิ่มตัวป้องกันแล้วอ่านจบครบ 19 เล่ม ข้อควรระวังคืออย่างน้อย 14 ใน 19 เล่มอยู่ในชุดเทรนของ v7 ส่วนเล่มที่ไม่เคยเห็น ตามบันทึกตอนนั้นดีขึ้น 2 จาก 4 เล่ม
• เอกสารจริง 37 ฉบับก่อนขึ้นใช้งาน ทั้งสองรุ่นแยกประเภทเอกสารถูก 34 ฉบับเท่ากัน แต่โมเดลเดิมอ่านวนจนได้ข้อความ 12,926 ถึง 44,097 ตัวอักษรใน 4 ฉบับ เป็นแบบรายชื่อผู้ถือหุ้น 2 ฉบับและหนังสือเดินทาง 2 ฉบับ v7 อ่านทั้ง 4 ฉบับได้ยาวปกติ (854 ถึง 3,800 ตัวอักษร) ข้อควรรู้คือการเทียบนี้ v7 มีตัวป้องกัน แต่โมเดลเดิมไม่มี ตามบันทึกตอนนั้นเพราะระบบจริงตั้งไว้แบบนั้น ตัวป้องกันทำงานแค่ 1 ใน 4 ฉบับ อีก 3 ฉบับ v7 อ่านจบได้เอง
• เอกสารจริง 25 ฉบับที่สุ่มมาหลังขึ้นใช้งาน เสร็จครบ 25 ฉบับ เมื่อยิงตรงโดยไม่มีตัวป้องกัน โมเดลเดิมอ่านไม่หยุดเกิน 20,000 ตัวอักษร 1 ฉบับ v7 ไม่มีเลย
• วันที่ระบบสลับกลับไปใช้โมเดลเดิมโดยไม่ตั้งใจ ตามบันทึกตอนนั้น ในเดือนกันยายน เทสต์ตัวหนึ่งเขียนค่าลงไฟล์ตั้งค่าของระบบจริง ทำให้ระบบอ่านด้วยโมเดลเดิมอยู่ 46 นาที ช่วงนั้นมีแต่งานทดสอบ ไม่มีงานลูกค้า หน้าปกติใช้เวลา 120 ถึง 150 วินาที จากปกติ 20 ถึง 30 วินาที และชุดทดสอบ 13 ไฟล์เสร็จ 11 ล้ม 2 พอสลับกลับเป็น v7 ด้วยโค้ดเดิมและไฟล์ชุดเดิม เสร็จครบ 13 ไฟล์ ไม่มีไฟล์ไหนหมดเวลาหรือถูกตัด แต่เหตุการณ์นี้ไม่ใช่การทดลองที่วางแผนไว้ ช่วงที่ใช้โมเดลเดิม GPU ทำงาน 94% ส่วนตอนรัน v7 GPU ว่าง จึงเป็นหลักฐานประกอบ ไม่ใช่ข้อพิสูจน์

สรุปคือ ในชุดวัดสาธารณะ v7 “ไม่ถอยหลัง” แต่ในงานจริง v7 อ่านจบในที่ที่โมเดลเดิมมักอ่านไม่หยุด และนั่นคือสิ่งที่ทำให้ระบบใช้งานได้ ตัวเลขความแม่นตัวอักษรเพียงอย่างเดียวจึงไม่พอสำหรับตัดสินว่าโมเดลไหนพร้อมใช้งาน

1.8 Merge แล้วขึ้นใช้งานจริง

ข้อนี้มาจากบันทึกตอนนั้นทั้งหมด

• Merge รวม LoRA เข้ากับโมเดลฐานเป็นโมเดลเดียว (ขั้นตอนเดียวกับบทที่ 5 ของซีรีส์ Fine-tune) แล้วรันด้วย vLLM
• เผื่อถอยกลับ เปิดโมเดลเดิมทิ้งไว้อีกตัว สลับกลับได้ทันที
• กับดัก ถ้าสั่งเปิด vLLM สอง container พร้อมกัน ทั้งคู่คำนวณพื้นที่แคชติดลบแล้วล้มทั้งคู่ ต้องเปิดทีละตัว
• แต่ “ไม่วนเลย” ผิด ในเดือนกันยายน v7 อ่านวนซ้ำบนสมุดบัญชีเล่มหนึ่งที่มีลายน้ำปูเต็มหน้า ทุกครั้งที่ลอง (3 จาก 3 ครั้ง ไฟล์เดียวกันที่ถูกส่งมา 3 ครั้ง) ซึ่งเป็นสมุดแบบเดียวกับหน้าที่เราเคยสรุปว่า “แก้ลายน้ำได้แล้ว” ในข้อ 1.3 ไม่พบปัญหาใน 25 ฉบับ จึงไม่ได้แปลว่าไม่มีปัญหา ข้อ 1.9 เล่าว่าเราแก้เรื่องนี้อย่างไร
• ตัวตรวจอื่นยังต้องอยู่ บันทึกของโปรเจกต์เองก็เขียนไว้ว่า v7 ช่วยให้อ่านได้ดีขึ้น แต่ไม่ได้ทำให้ตัดตัวตรวจความถูกต้องหรือตัวจับการแต่งข้อความทิ้งได้

1.9 ตัวป้องกันที่พัฒนาคู่กับ v7

v7 วนน้อยกว่าโมเดลเดิมมาก แต่ยังวนได้ งานส่วนที่สองจึงเป็นการพัฒนาตัวป้องกันต่อ โดยสร้างและวัดบน v7 เอง

จุดเริ่มต้น (กรกฎาคม) ตัวป้องกันชุดแรกทำไว้ตั้งแต่รอบเทรนเต็ม (ชุดเดียวกับที่ใช้ในตารางข้อ 1.4) คือตรวจว่าท้ายข้อความวนซ้ำหรือไม่ ถ้าวนหรืออ่านไม่จบ ให้ลองอ่านใหม่ด้วย temperature 0.2 และ 0.4 ตามบันทึกตอนนั้น ตัวตรวจการวนแบบเบากับการลองอ่านใหม่แบบนี้ ทำให้ v7 อ่านหนังสือเดินทางจบครบ 19 เล่ม

บทเรียนเดือนกันยายน: ตัวป้องกันต้องวัดบนโมเดลที่ใช้จริง ตามบันทึกตอนนั้น การสั่งอ่านซ้ำแบบเดิมมักวนซ้ำอีก หน้าหนึ่งอ่านสองรอบได้ 61,627 ตัวอักษรเท่ากันทุกตัว แม้บางครั้งผลจะเปลี่ยนเมื่อรันในชุดงานต่างกัน (ด้านล่าง อ่านซ้ำแล้วยังวน 2 จาก 4 หน้า) ส่วนตัวเลข “อ่านซ้ำแก้ได้ 9 จาก 9” ที่เคยบันทึกไว้ วัดบนโมเดลอ่านอีกตัวหนึ่ง ไม่ใช่ v7

ทางหนีที่วัดบนหน้าที่ v7 วน 4 หน้า (2 หน้าเป็นเอกสารเดียวกัน)

• อ่านใหม่ด้วยพรอมต์เดิม ยังวน 2 จาก 4 หน้า
• อ่านใหม่ด้วย temperature 0.3 ยังวน 2 จาก 4 หน้า
• จำกัดความยาว 1,536 โทเคน ไม่ยาวเกินแล้ว แต่แค่ตัดข้อความที่วนทิ้ง ไม่ได้แก้ ตามบันทึกตอนนั้น หน้าหนึ่งยังเป็นข้อความซ้ำ 83%
• อ่านใหม่ด้วยพรอมต์ที่ขอผลเป็นโครงสร้าง ได้ข้อความปกติทั้ง 4 หน้า

ตัวจับการวนแบบวลี ตัวตรวจเดิมจับแค่ตัวอักษรเดียวซ้ำหรือบรรทัดซ้ำ แต่ v7 บางครั้งวนทั้งประโยคอยู่ในบรรทัดเดียว เราจึงสร้างตัวจับใหม่ แล้ววัดกับ 9,032 หน้าจาก 5,254 งานก่อนเปิดใช้ ตามบันทึกตอนนั้น ตัวจับเจอ 51 หน้าที่สั้นกว่าเพดานความยาวเดิม เราเปิดดูครบทุกหน้า เป็นการวนจริงทั้งหมด ยกเว้น 2 หน้าที่ก้ำกึ่ง และหน้ารายการเดินบัญชีที่ดูซ้ำแต่เป็นข้อมูลจริง ไม่ถูกจับผิดเลย (0 จาก 12 หน้า)

หยุดอ่านต่อเมื่อเจอการวน เดิมเมื่อข้อความยาวเกินหนึ่งช่วง ระบบจะสั่งอ่านต่ออีกหลายช่วงแม้เนื้อหาวนอยู่ หน้าที่วนจึงใช้เวลา 700 ถึง 920 วินาทีแล้วถูกตัด ตามบันทึกตอนนั้น หลังแก้จุดนี้และแก้ต่ออีกข้อ (หน้าที่วนแบบวลีไม่ต้องลองอ่านใหม่ด้วย temperature) หน้าที่วนใช้ประมาณ 90 วินาที บวกเวลาอ่านใหม่ 30 ถึง 90 วินาที และไฟล์ที่เคยวน 13 ไฟล์ (เป็นเอกสารจริง 6 ฉบับ บางฉบับถูกส่งมาหลายครั้ง) เสร็จครบทั้ง 13 ไฟล์

repetition_penalty เฉพาะหน้าที่วน ในข้อ 1.2 การตั้งค่าลงโทษคำซ้ำกับทุกหน้าทำให้แย่ลงทุกตัววัด บน v7 เราลองใช้ค่าเดียวกันเฉพาะหน้าที่ตัวจับเจอว่าวน วัดบนหน้าวน 12 หน้าและหน้าปกติ 20 หน้า

• หน้าที่ยังวน: ไม่ใช้ค่าลงโทษ 5 หน้า ค่า 1.1 เหลือ 2 หน้า ค่า 1.2 เหลือ 1 หน้า
• เวลากลางของหน้าวน: 54 วินาที ลดเป็น 19 วินาทีที่ค่า 1.1
• ค่า 1.2 ทำให้ตารางในแบบรายชื่อผู้ถือหุ้นหายไปหลายช่อง ตามบันทึกตอนนั้น จึงเลือก 1.1

ระบบจริงจึงเป็นบันได คือเจอการวนแล้วอ่านใหม่ด้วยค่าลงโทษ 1.1 ถ้ายังวนใช้พรอมต์ขอโครงสร้าง ถ้ายังไม่ได้ให้ตัวอ่านสำรองอ่าน และถ้าทุกทางยังวน ให้ตัดส่วนที่วนทิ้ง ตามบันทึกตอนนั้น เมื่อลองกับไฟล์ที่เคยวนชุดเดิม ค่าลงโทษแก้ได้ 6 จาก 9 หน้า รวมถึงปกสมุดบัญชีที่มีลายน้ำในข้อ 1.8 พรอมต์โครงสร้างแก้อีก 3 หน้า เสร็จครบ 13 ไฟล์ งานหนึ่งเร็วขึ้นจาก 182 ถึง 209 วินาที เหลือ 105 ถึง 108 วินาที ส่วนหน้าที่ไม่วนยังส่งคำขอแบบเดิมทุกไบต์ จึงไม่ได้รับผลข้างเคียง

ที่ยังแก้ไม่ได้ ตามบันทึกตอนนั้น

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

1.10 เช็กลิสต์จากงานนี้

สิ่งที่ต้องทำ	บทเรียนจากข้อ
วัดความคลาดเคลื่อนของเฉลยก่อนตั้งเกณฑ์ผ่าน และบอกให้ชัดว่าใครหรืออะไรเป็นคนทำเฉลย	1.1
แยกชุดทดสอบด้วยเนื้อไฟล์ (hash) ไม่ใช่ตามงานหรือชื่อไฟล์ และตรวจซ้ำก่อนเชื่อผล	1.3
ตัดข้อมูลที่รั่วออกแล้ว ให้ดูด้วยว่าหน้าที่ตัดทิ้งซ่อนอาการพังแบบไหนไว้	1.3, 1.4
เทียบกับโมเดลเดิมที่ใช้ตัวช่วยตอนอ่านแบบเดียวกัน	1.4
ดูผลแบบจับคู่ทีละหน้า ไม่ใช่ดูแค่ค่ามัธยฐานหรือค่าเฉลี่ย	1.4, 1.5
วัดความสามารถทั่วไปทุกรอบ เพื่อจับการลืม	1.5
ระวังการเพิ่มข้อมูลสังเคราะห์จำนวนมาก	1.2, 1.4
ตรวจเฉลยที่ให้โมเดลสร้าง ว่าไม่ถูกตัดท้ายหรือผิดรูปแบบ	1.6
ดูจำนวนตัวอย่างที่ไม่ซ้ำกัน ไม่ใช่แค่สัดส่วน	1.6
วัดในงานจริงด้วย เช่น อ่านจบไหม ใช้เวลาเท่าไร ไม่ใช่ดูแค่ความแม่นตัวอักษร	1.7
หลังขึ้นใช้งานจริง ยังต้องดูเอกสารจริงต่อ ไม่ใช่หยุดที่ชุดแรก	1.8
พัฒนาและวัดตัวป้องกันบนโมเดลที่ใช้จริง และใช้การแก้แรง ๆ เฉพาะหน้าที่มีปัญหา	1.9

ที่มาของตัวเลข

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