- สำหรับการดึงข้อมูลจาก เอกสารที่ซับซ้อน วิธี OCR และการพาร์สแบบดั้งเดิมมักไม่สามารถรักษาความหมายไว้ได้อย่างครบถ้วน
- Morphik นำเสนอวิธี visual document embedding บนพื้นฐานของโมเดล ColPali ที่เข้าใจได้โดยตรงแม้แต่ตาราง แผนภูมิ และบริบทของเลย์เอาต์
- เมื่อเทียบกับไปป์ไลน์แบบเดิม วิธีนี้เหนือกว่ามากทั้งในด้าน ความแม่นยำและการคงอยู่ของข้อมูล โดยทำคะแนน ความแม่นยำสูงสุด 95.56% ในการทดสอบเบนช์มาร์ก
- นอกจากนี้ การนำ MUVERA และ Turbopuffer มาใช้ยังช่วย เพิ่มความเร็ว ในการค้นหาเอกสารขนาดใหญ่ได้อีกด้วย
- เป้าหมายต่อไปคือการทำ การให้เหตุผลข้ามหลายเอกสาร การผสานเข้ากับเวิร์กโฟลว์ และการตีความระดับผู้เชี่ยวชาญ เพื่อให้การทำงานเอกสารจริงเป็นอัตโนมัติ
ข้อจำกัดของการพาร์สเอกสารที่ซับซ้อนและความยากของ RAG
- เมื่อต้องการดึงข้อมูลจาก เอกสาร PDF ที่ซับซ้อน ซึ่งมีทั้งแผนภูมิ ไดอะแกรม และตารางผสมกัน มักเกิดปัญหาที่ไปป์ไลน์ OCR และการพาร์สทำข้อมูลที่ต้องการสูญหายอยู่บ่อยครั้ง
- ในสถานการณ์จริง เช่น ตารางซ้อน แผนภาพสำคัญ เอกสารเทคนิคที่มีคำอธิบายประกอบจำนวนมาก หรือแม้แต่คู่มือที่แทบไม่มีข้อความ จะเห็นข้อจำกัดของไปป์ไลน์แบบเดิมได้ชัดเจน
- ขั้นตอนของไปป์ไลน์แบบเดิม:
- ใช้ OCR กับ PDF (อาจอ่านตัวเลขหรือตัวอักษรผิด)
- พยายามแยกตาราง/แผนภาพด้วย โมเดลตรวจจับเลย์เอาต์ (มีโอกาสล้มเหลวสูง)
- กู้คืนลำดับการอ่าน (อาจพลาดลำดับการไหลเชิงภาพ)
- ตรวจจับคำบรรยายแผนภาพ (มักตกหล่นความหมายแฝง)
- แบ่งข้อความเป็นชังก์ (ข้อมูลที่เกี่ยวข้องกันอาจถูกแยกออกจากกัน)
- สร้างเวกเตอร์ embedding และเก็บใน vector DB (ทำให้ข้อมูลตำแหน่งและบริบทสูญหาย)
- ตัวอย่าง: แม้แต่ตารางง่าย ๆ ก็อาจอ่าน "1,000" เป็น "l,0O0" หรือแยกตารางออกจากหัวตารางจนคำนวณผลรวมล้มเหลวได้บ่อยครั้ง
- กรณีข้อมูลสูญหายในโลกจริงพบได้บ่อย เช่น ตีความ legend ของแผนภูมิเป็นเนื้อหาหลัก หรือทำให้ค่าเปอร์เซ็นต์กระจัดกระจายไปอยู่ผิดตำแหน่ง
แนวทางใหม่: เปลี่ยนสู่การทำความเข้าใจเอกสารด้วยภาพ
- ทีม Morphik พบจุดเปลี่ยนจากคำถามว่า "ถ้าเราเข้าใจเอกสารเป็นวัตถุเชิงภาพแบบที่มนุษย์มองล่ะ?"
- ด้วยงานวิจัยล่าสุด (ColPali) และความก้าวหน้าของ Vision Language Model (VLM) จึงสามารถทำ embedding จากภาพโดยตรงเพื่อรักษาทั้งบริบทของเอกสารและข้อมูลเชิงภาพไว้ได้ โดยไม่ต้องพาร์สหรือใช้ OCR
- แต่ละหน้าของเอกสารถูกประมวลผลเป็นภาพความละเอียดสูง แล้ว แบ่งเป็นหน่วย patch เพื่อสร้าง embedding ที่สะท้อนทั้งข้อมูลภาพและข้อความ
- SigLIP-So400m Vision Transformer สร้าง embedding ของ visual patch และโมเดลภาษา PaliGemma-3B ช่วยทำความเข้าใจโครงสร้างเอกสาร
- สำหรับคำค้นหา (เช่น "แนวโน้มรายได้ไตรมาส 3") ระบบจะดึงข้อมูลที่เกี่ยวข้องได้อย่างแม่นยำด้วยการค้นหาแบบ late interaction ที่รวมเบาะแสเชิงภาพหลากหลาย ทั้งข้อความ แผนภูมิ ตาราง และสี
- คงไว้ซึ่งตำแหน่งในเอกสาร เลย์เอาต์ สี การเปลี่ยนแปลงของกราฟ และข้อมูลเชิงภาพทุกอย่าง—ใกล้เคียงกับวิธีที่มนุษย์มองเอกสารโดยรวมในคราวเดียว
เปรียบเทียบการพาร์สแบบดั้งเดิมกับแนวทาง ColPali
- ไปป์ไลน์แบบพาร์สเดิมทำให้ข้อมูลสูญหายในแต่ละขั้นตอน และเมื่อแยก text embedding กับ image embedding ออกจากกัน ก็ไม่สามารถตีความ ความสัมพันธ์เชิงพื้นที่ ภายในเอกสารได้
- ในทางกลับกัน วิธีของ ColPali รวมข้อมูลทั้งหมดไว้ใน visual embedding space เดียว จึงรักษาความหมายและบริบทของเอกสารทั้งฉบับไว้ได้
- ในเบนช์มาร์กจริง (เน้นเอกสารการเงิน, ชุดข้อมูลสาธารณะ) Morphik (บนพื้นฐาน ColPali) ทำได้ ความแม่นยำสูงสุด 95.56% (ขณะที่ LangChain+OpenAI text-embedding แบบเดิมได้ 72% และ OpenAI file search ได้เพียง 13.33%)
- ใน ViDoRe benchmark วิธีแบบใช้ภาพมีประสิทธิภาพสูงกว่าวิธีพาร์สแบบเดิมมากกว่า 14 จุดเปอร์เซ็นต์ตามเกณฑ์ nDCG@5
การเพิ่มประสิทธิภาพและการใช้งานจริง
- ข้อเสียของแนวทางช่วงแรกคือ ความเร็วที่ลดลงจากภาระการคำนวณ เนื่องจากโครงสร้างต้องค้นหาเวกเตอร์สำหรับแต่ละ patch จึงไม่เหมาะกับคำค้นหาระดับหลายสิบล้านครั้งต่อวินาที
- โดยอ้างอิงงานวิจัย MUVERA จึงนำวิธีแปลงการค้นหาแบบ multi-vector ให้เป็นการค้นหาแบบ single-vector (fixed-dimensional encoding) มาใช้
- เมื่อผสานกับ vector DB ที่ออกแบบมาเฉพาะอย่าง Turbopuffer ความเร็วคิวรีจึงดีขึ้นจาก 3-4 วินาทีเหลือระดับ 30ms
- ส่งผลให้สามารถค้นหาเอกสารนับล้านรายการได้ด้วยความเร็วที่เหนือกว่าวิธีพาร์สข้อความแบบเดิมอย่างชัดเจน
ขอบเขตการใช้งานและ API ที่ใช้ง่าย
- รองรับการค้นหาความแม่นยำสูงโดยไม่สูญเสียโครงสร้างภาพและข้อมูลในเอกสารหลายประเภท
- เอกสารการเงิน ที่มีตารางและแผนภูมิซับซ้อนเป็นสาระสำคัญ
- คู่มือเทคนิค ที่เน้นแบบร่างหรือแผนภาพ
- การดึงข้อมูลตามเลย์เอาต์จาก ใบแจ้งหนี้และใบเสร็จ
- การทำความเข้าใจสื่อภาพ/ข้อมูลเชิงตัวเลขใน งานวิจัย
- การรับรู้ความสัมพันธ์ตามเลย์เอาต์ใน เวชระเบียน
- API มีโครงสร้างเรียบง่ายมาก: อัปโหลดเอกสารแล้วถามด้วยภาษาธรรมชาติได้เลย รองรับคำขออย่าง "แสดงสัญญาทั้งหมดที่มีเงื่อนไขค่าปรับเกิน 10,000 ดอลลาร์"
ทิศทางในอนาคต: ความฉลาดข้ามหลายเอกสารและความเข้าใจที่ลึกยิ่งขึ้น
- ความฉลาดหลายเอกสาร: กำลังพัฒนาความสามารถในการอ้างอิงข้ามหลายเอกสารและติดตามข้อมูลระหว่างกัน
- ก้าวข้ามจากการค้นหาในเอกสารเดียว ไปสู่การรองรับ การติดตามความสัมพันธ์และการให้เหตุผลระหว่างหลายเอกสาร (เช่น เชื่อมโยงจากข้อสัญญา → เอกสารกำกับดูแล → คู่มือปฏิบัติการ)
- ระบบความเข้าใจเชิงเอเจนต์: ไม่ใช่แค่ถามตอบในเอกสาร แต่รวมถึง การทำให้การให้เหตุผลเชิงตรรกะระหว่างชังก์เป็นอัตโนมัติ เช่น ดึงข้อกำหนด → ตรวจสอบกับเอกสารอื่น → cross-check รายละเอียด
- การผสานเข้ากับเวิร์กโฟลว์: ยกระดับความฉลาดด้านเอกสารอัตโนมัติให้สอดคล้องกับกระบวนการทำงานจริง เช่น การเปรียบเทียบเงื่อนไขระหว่างหลายสัญญา หรือการติดตามประวัติการตัดสินใจเชิงเทคนิค
ข้อจำกัดและเป้าหมายต่อจากนี้
- วิธีการปัจจุบันยังไปไม่ถึงระดับ การตีความแบบผู้เชี่ยวชาญและการตัดสินเชิงบริบท
- ส่วนที่ต้องอาศัยการวิเคราะห์เชิงลึกแบบผู้เชี่ยวชาญการเงินยังไม่สมบูรณ์ทางเทคนิค และยังต้องพัฒนาเพิ่มเพื่อรองรับความต้องการระดับองค์กร เช่น ความน่าเชื่อถือและการวัดปริมาณความไม่แน่นอน
- การผสานความเข้าใจเชิงภาพเข้ากับกราฟความรู้เฉพาะโดเมน การให้เหตุผลเชิงเหตุและผล และการนำเสนอตัวชี้วัดความน่าเชื่อถือ คือโจทย์สำคัญในอนาคต
บทสรุป
- เอกสารควรถูกปฏิบัติในฐานะ วัตถุความรู้เชิงภาพ และการทำความเข้าใจเอกสารจากภาพคือ แนวทางที่ดีกว่าสำหรับสภาพแวดล้อม RAG เมื่อก้าวข้ามข้อจำกัดของการพาร์ส
- Morphik ต้องการนำเสนอมาตรฐานใหม่ของการดึงข้อมูลจากเอกสาร และมุ่งสู่ระบบอัตโนมัติสำหรับเวิร์กโฟลว์เอกสารที่ซับซ้อนและการใช้งานจริงในงานธุรกิจ
- ทดลองใช้ฟีเจอร์เพิ่มเติมได้ที่ morphik.ai
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
มีปัญหาเชิงพื้นฐานหลายอย่างที่คนควรรู้
โดยทั่วไป LLM ถูกพรีเทรนด้วยโทเค็นข้อความราว 4k ก่อน แล้วค่อยขยายไปยัง context window ที่ยาวขึ้นภายหลัง (จาก 4000 ไป 4001 นั้นง่าย แต่ภาพใช้วิธี tokenization คนละแบบจึงทำแบบนั้นไม่ได้)
ผลคือมันหลุดออกจากการกระจายข้อมูลเดิม และเมื่อจัดการภาพเกินสองสามภาพ ปัญหา hallucination จะรุนแรงมาก
PDF ความละเอียด 1536×2048 ใช้โทเค็นมากกว่าข้อความ 3~5 เท่า ทำให้ต้นทุนการอนุมานสูงขึ้นและตอบช้าลง
ถ้าลดความละเอียดลง ภาพก็จะเบลอ
ตัวภาพเองก็มีขนาดใหญ่ ดังนั้นแค่ดาวน์โหลดภาพที่ต้องใช้ก็เพิ่ม latency ต่อคำขอแล้ว
ใน benchmark ขนาดเล็ก วิธีนี้ทำงานได้ดีกว่า text chunking แบบพื้นฐานอย่างชัดเจนสำหรับเอกสารการเงินที่มีกราฟและตารางเยอะ
ส่วนตัวอยากให้มีการใส่ annotation ภาพด้วย OCR แบบ Gemini แล้วลองเทียบผลดู
แนวทาง end-to-end แบบภาพล้วนมีเหตุผลในกรณีพิเศษ (สิทธิบัตร, ไดอะแกรมสถาปัตยกรรม ฯลฯ) แต่จริง ๆ แล้วควรเป็นทางเลือกสุดท้าย
ปัญหาคือ LLM มักสร้างข้อความที่ดูน่าเชื่อขึ้นมาในส่วนที่อ่านไม่ออก ซึ่งอาจทำให้ผลลัพธ์ยิ่งเละกว่าเดิม
ตัวอย่างเช่น GPT4.1 ทำงานได้สมบูรณ์กับสกรีนช็อตขนาด 1296×179 แต่พอย่อ 50% แล้วให้ที่ 650×84 มันส่งกลับ
Pdf's at 1536 × 2048 use 3 to 5X more tokensเป็นA PNG at 512x 2048 is 3.5k more tokensส่วนใหญ่จะทำได้ถูกต้อง แต่ต้องระวังว่ารายละเอียดเล็ก ๆ แบบนี้อาจถูกเปลี่ยนไป
คุณสมบัติที่น่าสนใจของตระกูล gemma3 คือ ถึงจะเพิ่มขนาดภาพนำเข้า ความต้องการหน่วยความจำในการประมวลผลก็ไม่เพิ่มขึ้น
เพราะตัวเข้ารหัสขั้นที่สองบีบอัดให้เป็นโทเค็นขนาดคงที่
ใช้งานได้มีประโยชน์มากทีเดียว
แต่ถ้าทำแบบนั้น ชุดเอกสารทั้งหมดที่ประมวลผลก็จะต้องผ่าน VLM ขนาดใหญ่เสมอ
ซึ่งอาจแพงและช้ามาก
ตรงนี้มี trade-off ชัดเจน
สำหรับกรณีส่วนใหญ่ วิธีปัจจุบันได้ผลดีที่สุด
บางคนชอบโยนทุกอย่างเข้า LLM แต่บางสถานการณ์ก็อาจไม่เหมาะ
ไม่จำเป็นต้องให้ LLM จัดการทุกอย่างเสมอไป
คิดว่าน่าจะขยายเป็นไอเดียเปลี่ยน RAG pipeline ได้
สำหรับแต่ละผลลัพธ์ RAG อาจให้โมเดลสกัดข้อมูลจากภาพที่เกี่ยวข้องกับคำถามของผู้ใช้โดยตรง แล้วรวบรวมผลลัพธ์นั้นในรูปข้อความมาเป็นอินพุตของการสร้างคำตอบสุดท้าย
แบบนี้จะเลี่ยงข้อจำกัดโทเค็นของหลายภาพพร้อมกัน และยังขนานขั้นตอนทำความเข้าใจภาพได้ด้วย
ผมกับเพื่อนร่วมงานเคยทำ implementation แบบนี้ให้หน่วยงานรัฐบาลฝรั่งเศสเมื่อ 6 เดือนก่อน
เปิดซอร์สไว้ที่นี่: https://github.com/jolibrain/colette
ไม่ใช่งานหลักของเรา แค่ปล่อยทิ้งไว้ แต่ปรับจูนอีกนิดก็ทำงานได้มีประสิทธิภาพพอสมควร
จุดเด่นจริง ๆ คือทำให้ทั้ง pipeline สามารถ differentiable ได้ทั้งหมด จึง fine-tune viz rag ให้เฉพาะกับ dataset บางชุดได้
ยังปรับแต่ง layout model ได้ด้วย เพื่อให้ทำความเข้าใจเอกสารได้ละเอียดแม่นยำ
โดยทั่วไปอุปสรรคใหญ่สุดคือจำเป็นต้องมีชุดประเมินผลคุณภาพสูง (ซึ่งมักเป็นอุปสรรคเสมอ)
เคยทำงานวิจัย benchmark หลายชิ้นเรื่อง OCR เทียบกับภาพ + LLM ทั่วไป: https://getomni.ai/blog/ocr-benchmark
ปัญหาใหญ่ที่สุดของแนวทางดึงข้อมูลจากภาพโดยตรงคือเอกสารหลายหน้า
สำหรับหน้าเดียว (OCR=>LLM vs Image=LLM) ภาพโดยตรงดีกว่าเล็กน้อย แต่พอเกิน 5 ภาพขึ้นไป ความแม่นยำจะตกลงอย่างรวดเร็วเมื่อเทียบกับแนวทาง OCR ก่อน
จริง ๆ แล้วแม้แต่ long-context recall ของข้อความก็ยังเป็นโจทย์ยาก แต่ LLM ถูกปรับให้เหมาะกับสิ่งนั้น ขณะที่ long-context recall ของภาพยังตามหลังอยู่มาก
การวางชั้นแปลงจากภาพไป LLM แบบเล็ก ๆ ไว้ตรงกลางก็ได้ผลดีพอสมควร (คือแทนที่จะ OCR ตรง ๆ ก็ส่งภาพ 5 หน้าเข้า vision model ขนาดเล็กพร้อมกัน แล้วดึงเฉพาะประเด็นสำคัญที่สุดของเอกสารออกมา)
ตอนนี้เรากำลังวิจัยการแก้ cache หรือ attention map ของ LLM เพื่อให้รองรับ batch ภาพขนาดใหญ่ได้ดีขึ้น
แนวทางอย่าง sliding window หรือ infinite retrieval ดูมีอนาคต
เดาส่วนตัวคือจากความเร็วในการพัฒนาของ multimodal model อีกไม่นาน long-context ของภาพก็คงไม่ใช่ปัญหาใหญ่
โพสต์บล็อกนี้มีข้อสังเกตที่ดีเกี่ยวกับการใช้ vision model สำหรับ retrieval แต่ผมอยากชี้ปัญหาบางอย่าง
document parsing คือการแปลงเอกสารให้เป็นข้อความแบบมีโครงสร้าง เช่น Markdown/JSON (หรือเวลาสกัดข้อมูลก็เป็น output ตาม schema)
RAG เป็นหนึ่งในกรณีใช้งานนั้น และยังมีกรณีใช้อื่นอีกมาก
ColPali ยอดเยี่ยมสำหรับ retrieval แต่ใช้กับ document parsing แบบล้วน ๆ ไม่ได้ (อย่างน้อยก็ไม่ใช่แบบ native)
ผู้เขียนพูดถึง benchmark ด้าน visual retrieval เป็นหลัก
หลายครั้งทำงานได้ดีกว่า OCR มาตรฐาน
a. แต่ก็ยังมีปัญหาความแม่นยำในเคส long tail
b. ขาด metadata อย่าง confidence score, bounding box ฯลฯ
c. ตัว pipeline สกรีนช็อตเองก็ต้องลงแรงไม่น้อยถ้าจะทำให้ซับซ้อนจริงจัง
image token มีพลังมากกว่าเยอะ แต่ text token มีต้นทุนจัดเก็บถูกกว่ามาก จึงสามารถ query ทั้งเอกสารตอน retrieval ได้ (ไม่ใช่แค่ระดับ chunk)
(เพื่อความโปร่งใส: ผมเป็น CEO ของ llamaindex และทำทั้ง parsing/retrieval ผ่าน LlamaCloud มุมมองนี้เป็นความเห็นทั่วไป)
ปีที่แล้วผมใช้เวลาไปเยอะกับการสร้างระบบวิเคราะห์เอกสารสิทธิบัตร
สิทธิบัตรมีคอนเทนต์หลากหลายมาก ทั้งไดอะแกรมเชิงนามธรรม สูตรเคมี สมการ ฯลฯ เลยทำให้การเตรียมข้อมูลให้เหมาะกับ LLM ยากมาก
วิธีที่ง่ายที่สุดที่ผมเจอคือแปลงแต่ละหน้าให้เหมือน “ถ่ายรูป” แล้วให้ LLM สร้าง JSON และ metadata ที่อธิบายเนื้อหา (เช่น หมายเลขหน้า จำนวนองค์ประกอบภาพ ฯลฯ)
ถ้าภาพซับซ้อนก็ให้โมเดลอธิบายมัน
แบบนี้ก็ embed JSON เข้า vector store ที่ต้องการได้ง่าย
เรื่องความคุ้มค่าต่อค่าใช้จ่ายประเมินยาก แต่แนวทางนี้ง่ายและมีประสิทธิภาพกว่าสิ่งที่ผู้เขียนเสนอ
ตัวอย่างเช่น แม้โมเดลจะดึงคู่ x, y จากกราฟได้เป็นส่วนใหญ่ แต่ถ้าผู้ใช้ถามเจาะจง x/y บางจุดก็อาจพลาดได้
หากแสดงภาพให้โมเดลดูโดยตรงในขั้นตอนอนุมาน มันจะตอบสิ่งที่ผู้ใช้ถามได้ตรงกว่า ดังนั้นแนวทางนี้จึงมีประสิทธิภาพกว่า
อุปสรรคจริง ๆ มีเพียงคุณภาพของ retrieval ซึ่งเป็นปัญหาที่ค่อนข้างเล็ก
กล่าวคือถ้าส่ง context ที่เหมาะสมได้ ที่เหลือ LLM จะจัดการให้เอง
ไม่เช่นนั้นปัญหาที่ต้องแก้จะเพิ่มขึ้นมาก ทั้ง OCR, parsing, การบรรยายภาพ ฯลฯ
แต่ก็แสดงให้เห็นว่าโอกาสของ LLM มักไปกระจุกตัวอยู่ที่การจัดหมวดหมู่/ประมวลผลคุณค่าที่มีอยู่แล้วใหม่ (เช่น เอกสารสิทธิบัตร)
ในยุค 90-00 บริษัทซอฟต์แวร์หลายแห่งประสบความสำเร็จจากการแปลงเอกสารกระดาษเดิมเข้า DB
การสร้าง dataset ใหม่ที่มีคุณค่าตั้งแต่ต้นยังคงต้องใช้การลงทุนและความพยายามสูงมาก
จากประสบการณ์ วิธีนี้ไม่ค่อยดี
ขึ้นอยู่กับฟอนต์ บางทีแยก o กับ 0 ได้ยาก
ถ้าแปลงเอกสาร (doc/xls/pdf/html) เป็นภาพ ก็จะสูญเสียข้อมูลที่ช่วยแยกความต่างแบบนั้นไป
อย่างเลขซีเรียล บางทีกระทั่งคนเองก็ดูแล้วแยกไม่ออก
เพราะงั้นสำหรับ PDF การเรนเดอร์เป็นภาพแล้วดึงข้อมูลออกมาก็สมเหตุสมผลทีเดียว
แต่สำหรับฟอร์แมตอื่น การ parse เอกสารโดยตรงดีกว่า
แต่ในงานจริงเวลาออกแบบหน้า การให้โมเดลเห็นภาพหน้าจริงจะช่วยดีบักได้ดีกว่าส่งแค่โค้ดมาก
ปัญหา 1 vs I, 0 vs O มีอยู่จริง แต่สำหรับเอกสารที่มีไดอะแกรม/กราฟเยอะ ผมมักพบว่าประมวลผลด้วยภาพอย่างเดียวง่ายกว่ามาก
(อาจมี selection bias ก็ได้)
ผมพยายามอยู่หลายนาทีจะคัดลอกตารางเวลาไปถาม Gemini แต่แม้เป็น HTML มันก็ยังทำได้ไม่ดี
สุดท้ายเลยแคปหน้าจอ ปิดส่วนที่ไม่ต้องการด้วยกล่องสีดำ แล้วใส่ภาพเข้าไป ปรากฏว่าใช้งานได้ดีมาก
เลยสงสัยว่า multimodal RAG น่าจะแก้ปัญหานี้ไปแล้วหรือเปล่า
ผมได้ผลการวิเคราะห์ภาพที่น่าพอใจมากจาก Flash 2.5, Sonnet 3.7 ฯลฯ
รู้สึกว่าบางทีให้ภาพกลับได้คำตอบดีกว่าให้ข้อความเสียอีก
https://www.youtube.com/watch?v=p7yRLIj9IyQ
เพียงแต่ multi-vector แบบตั้งต้น (รากฐานของ multimodal RAG) จัดการยากมากและการคำนวณ similarity ก็แพงมาก ทำให้ scale up ยาก
จึงต้องมีทั้ง quantization, การแปลงเป็นเวกเตอร์เดี่ยว (encoding มิติคงที่), การปรับแต่ง indexing ฯลฯ
นี่แหละคือสิ่งที่เราทำอยู่ที่ Morphik
ผมเองก็เคยลองสแกนใบแจ้งหนี้ทั้งหมดทีเดียว โดยดึงเฉพาะไฟล์แนบจากกล่องจดหมายแล้วรันสคริปต์อัปโหลดทีละไฟล์ ให้มันตอบว่า “invoice: yes/no” พร้อมดึงรายการ, ชื่อผู้ขาย, วันที่, เลข invoice ฯลฯ
สุดท้ายอัตราการอ่านออกมาค่อนข้างสูง และแม้ LLM call จะกินเวลาเกิน 3 ชั่วโมง แต่เป็นงานอัตโนมัติเลยไม่ได้สนใจ
หลังจากนั้นยังให้ LLM จับคู่กับ bank statement ต่อด้วย และมีเพียง invoice บางส่วนที่ไม่ถูกส่งมาเป็นไฟล์แนบเท่านั้นที่ตกหล่น
แต่การจับคู่ invoice กับ statement นี่ LLM ทำได้ค่อนข้างแย่ (ต่างกันไม่กี่ดอลลาร์ก็ยังตอบว่าใช่รายการนี้)
ดังนั้นระยะนี้คงยังต้องมีนักบัญชีอยู่
เรื่องค่าใช้จ่ายผมไม่ได้ประเมินไว้คร่าว ๆ และใช้โมเดลราคาถูกอย่าง Claude 3.7
ผมเข้าใจว่า ColPali ดูเข้าใจง่ายและทรงพลัง แต่กระบวนการประมวลผลเอกสารก็ยังมีข้อดีของมัน