Apple ปล่อยน้ำหนัก LensVLM-9B — อ่านเอกสารยาวเป็น "ภาพหน้ากระดาษย่อ" แล้วซูมเฉพาะหน้าที่เกี่ยว ได้แม่นใกล้การป้อนข้อความเต็มที่อัตราบีบอัด 4.3 เท่า แต่ใบอนุญาตใช้ได้แค่งานวิจัย

Apple อัปโหลด LensVLM-9B ขึ้น Hugging Face เมื่อ 21 ก.ย. 2026 (แก้ไขครั้งล่าสุด 22 ก.ย.) และเปิดรีโป apple-aiml-research/ml-lensvlm บน GitHub ในวันเดียวกัน หลังจากนั้นโมเดลก็ขึ้นหน้าแรก Hacker News เมื่อวันที่ 23 ก.ย. ตัวเปเปอร์ออกบน arXiv ตั้งแต่ 7 พ.ค. แต่เพิ่งปล่อยน้ำหนักครั้งนี้ โพสต์นี้จึงเป็นข่าวย้อนหลังราว 3 วัน

แนวคิดหลักคือ แทนที่จะแปลงเอกสารยาวเป็นโทเคนข้อความทั้งหมด ให้ เรนเดอร์ข้อความเป็นภาพหน้ากระดาษขนาดเล็ก แล้วให้ VLM ดูภาพรวมเพื่อหาว่าหน้าไหนน่าจะมีคำตอบ จากนั้นเรียกทูลเพื่อขยายเฉพาะหน้านั้นกลับมาเป็นข้อความเต็ม วิธีนี้คล้ายการกวาดตาดูสารบัญแล้วเปิดอ่านเฉพาะหน้าที่ต้องการ

ทำงานอย่างไร

• ต่อยอดจาก Qwen3.5-9B-Base (ใน config.json สถาปัตยกรรมยังเป็น Qwen3_5ForConditionalGeneration) โดยเพิ่ม post-training ทั้ง SFT และ RL เพื่อสอนให้เลือกหน้าที่จะขยาย
• ข้อความถูกเรนเดอร์เป็นภาพหน้ากระดาษที่อัตราบีบอัด 3 ระดับ คือ 5x, 10x และ 15x ซึ่ง vision encoder จะแปลงเป็น visual token 72, 48 หรือ 24 ตัวต่อภาพตามลำดับ ทั้งหมดนี้ใช้ policy เดียว
• ขณะอนุมาน โมเดลคิดใน <think> แล้วเรียก read_page เพื่อดึงข้อความเต็มของหน้าที่เลือก (ตามตัวอย่างใน README ของรีโป) โดยตั้งงบไว้ไม่เกิน 6 turn
• เปเปอร์วัดผลด้วย ECR (effective compression rate) ซึ่งนับโทเคนที่โมเดลต้องประมวลผลจริงทั้งหมด รวมหน้าที่ขยายกลับมาด้วย จึงยุติธรรมกว่าการดูแค่อัตราบีบอัดของภาพ

ตัวเลขจากเปเปอร์ (Table 11)

ค่าเฉลี่ยจาก 7 benchmark ได้แก่ NQ, HotpotQA, MuSiQue, HELMET, RULER, Qasper และ LongBench ทุกวิธีในตารางใช้ reader ตัวเดียวกันคือ Qwen3.5-9B-Base:

วิธี	ICR 5x	ICR 10x	ICR 15x
ป้อนข้อความเต็ม (เพดานบน)	72.4	72.4	72.4
ภาพบีบอัดเฉย ๆ	31.3	21.0	18.1
LLMLingua-2	47.2	37.6	33.0
ColPali (ค้นด้วยภาพ)	56.1	46.6	41.9
BGE-M3 (RAG ข้อความ)	65.1	57.1	51.9
LensVLM	68.9 (ECR 4.3x)	62.1 (ECR 7.4x)	52.1 (ECR 10.1x)

จุดที่ควรรู้คือ ระยะห่างจาก RAG แบบข้อความธรรมดาไม่ได้กว้างมาก ที่ 5x LensVLM ชนะ BGE-M3 อยู่ 3.8 จุด ที่ 10x ชนะ Jina-v4 อยู่ 4.2 จุด แต่ที่ 15x คะแนนเฉลี่ย 52.1 เท่ากับ Jina-v4 พอดี และสูงกว่า BGE-M3 แค่ 0.2 จุด นอกจากนี้ทุกการทดสอบใช้เอกสารที่ยาว ไม่เกิน 32K text token ส่วนผู้ตัดสินคำตอบคือ LLM (Qwen3.5-397B) ไม่ใช่ exact match จึงยังไม่รู้ว่าวิธีนี้ทำงานได้ดีแค่ไหนกับเอกสารระดับหลายแสนโทเคน ซึ่งเป็นกรณีที่การบีบอัดน่าจะคุ้มที่สุด

เปเปอร์ยังทดสอบงานโค้ด (RepoQA) และ document QA แบบภาพจริง และพบว่าสำหรับเอกสารที่ layout มีความหมาย การซูมภาพความละเอียดสูงให้ผลดีกว่าการดึงข้อความ

ใช้งานได้แค่ไหน

• ขนาด: safetensors ไฟล์เดียวแบบ bf16 ขนาด 18.8GB พอรันบน GPU 24GB ได้โดยไม่ต้องควอนต์ (ถ้า context ไม่ยาวมาก) แต่ตอนนี้ยังไม่มี GGUF หรือ MLX อย่างเป็นทางการ
• โค้ด: python scripts/run_demo.py --model apple/LensVLM-9B หรือ demo.py --text_file ... --compression 10x ส่วนการ eval ต้องตั้ง judge server ที่เข้ากันได้กับ OpenAI แยกต่างหาก
• ใบอนุญาต: น้ำหนักใช้ Apple Machine Learning Research Model License ซึ่งจำกัดการใช้และงานต่อยอดไว้ที่ “Research Purposes” คือ งานวิจัยที่ไม่ใช่เชิงพาณิชย์ เท่านั้น ส่วนโค้ดใช้ Apple Sample Code License แยกต่างหาก ดังนั้นแม้ base model อย่าง Qwen3.5 จะเป็น Apache-2.0 แต่ LensVLM ใส่ในผลิตภัณฑ์ไม่ได้

มุมมอง AI Curator

LensVLM น่าสนใจเพราะเสนอ ทางเลือกที่สามระหว่าง “ยัดทั้งเอกสารเข้า context” กับ “ทำ RAG” โมเดลเห็นภาพรวมของทุกหน้าในราคาถูก (24–72 token ต่อหน้า) แล้วตัดสินใจเองว่าจะอ่านหน้าไหนเต็ม ๆ ซึ่งแก้จุดอ่อนของ RAG ที่ retriever เลือกชิ้นผิดแล้ว LLM ไม่มีทางรู้ตัว ผลที่ชัดที่สุดอยู่ที่ MuSiQue ซึ่งเป็นคำถามหลายขั้น ที่ 5x ได้ 69.6 สูงกว่าการป้อนข้อความเต็ม (68.7) ด้วยซ้ำ และทิ้ง BGE-M3 (59.0) ไปกว่า 10 จุด

แต่ถ้าดูตามจริง ข้อได้เปรียบเฉลี่ยเหนือ RAG ธรรมดามีแค่ 4 จุด และหายไปที่ 15x ส่วนการทดสอบก็จำกัดอยู่ที่ 32K token สำหรับทีมที่ทำ RAG เอกสารราชการหรือสัญญาภาษาไทย คำถามที่สำคัญกว่าคือ ภาษาไทยที่ย่อจนตัวเล็กมาก วรรณยุกต์และสระบนล่างยังอ่านออกหรือไม่ เปเปอร์ทดสอบแค่ภาษาอังกฤษ และระบุเองว่าความแม่นตกเร็วเมื่อ “ตัวอักษรเล็กกว่าความละเอียดที่ encoder มองเห็นได้” อักษรไทยที่ซ้อนกันหลายชั้นน่าจะเจอปัญหานี้ก่อนภาษาอังกฤษ

อีกเรื่องที่ต้องย้ำคือใบอนุญาต Apple AMLR ปิดทางใช้เชิงพาณิชย์ LensVLM จึงเหมาะเป็น แบบร่างของ recipe มากกว่าโมเดลสำหรับใช้งานจริง ข่าวดีคือเทคนิคนี้ (SFT + RL บนทูล read_page กับภาพเรนเดอร์) ไม่ได้ผูกกับน้ำหนักของ Apple ใครจะลองทำซ้ำบน Qwen3.5-9B ตัวต้นฉบับ ซึ่งรับภาพได้ในตัวและใช้ Apache-2.0 ก็ทำได้ ส่วนความเป็นไปได้ที่ Apple จะนำแนวคิดนี้ไปใช้กับการอ่านเอกสารยาวบนอุปกรณ์ของตัวเองนั้น ตอนนี้ยังเป็นแค่การคาดเดา

แหล่งข่าว

• apple/LensVLM-9B — Hugging Face (model card + LICENSE)
• apple-aiml-research/ml-lensvlm — GitHub
• LensVLM: Selective Context Expansion for Compressed Visual Representation of Text (arXiv 2605.07019)