Hyper-Extract: RAG ที่เลิกหั่น chunk แล้วหันมาสกัดเอกสารเป็นความรู้มีโครงสร้าง

มีเครื่องมือโอเพนซอร์สใหม่ชื่อ Hyper-Extract กำลังถูกพูดถึง มันเปลี่ยนเอกสารยุ่ง ๆ (PDF, รายงาน, เปเปอร์) ให้กลายเป็น “ความรู้มีโครงสร้าง” อย่าง knowledge graph และ hypergraph ด้วยคำสั่งเดียว — แทนที่จะแค่หั่นเอกสารเป็นชิ้น ๆ (chunk) แล้วหวังว่าการค้นหาจะเจอ ที่น่าสนใจกว่าตัวเครื่องมือคือ มันสะท้อน เทรนด์ใหญ่ของ RAG ปี 2026 ที่กำลังขยับจาก “ค้นข้อความ” ไปสู่ “ให้เหตุผลบนความรู้ที่มีโครงสร้าง”

สรุปสั้น ๆ: RAG (การดึงข้อมูลของเราเองมาเสริมให้ LLM ตอบ) แบบเดิมหั่นเอกสารเป็น chunk แล้วค้นด้วยความคล้าย ซึ่งมองไม่เห็นความสัมพันธ์ระหว่างข้อมูล Hyper-Extract (CLI โอเพนซอร์ส ~308 ดาวบน GitHub) สกัดเอกสารเป็นกราฟ/ไฮเปอร์กราฟแทน รันในเครื่องได้ด้วย vLLM และต่อเข้า Claude ผ่าน MCP จุดที่ทำให้น่าเชื่อถือคือคนสร้างคือ Yifan Feng ผู้เขียนงานวิจัย Hyper-RAG ที่ตีพิมพ์ใน Nature Communications เอง — ไม่ใช่แค่ tool ตามกระแส

RAG แบบ “หั่น chunk” ติดเพดานตรงไหน

RAG ที่เราใช้กันส่วนใหญ่ทำงานแบบนี้ — เอาเอกสารมาหั่นเป็นชิ้นเล็ก ๆ (chunk) แปลงแต่ละชิ้นเป็นเวกเตอร์ (embedding) เก็บไว้ใน vector database พอผู้ใช้ถาม ก็ไปค้นชิ้นที่ “ความหมายใกล้เคียง” คำถามมากที่สุด แล้วยัดเข้าไปให้ LLM ตอบ (อยากเข้าใจกลไกเต็ม ๆ อ่าน RAG ทำงานอย่างไร)

วิธีนี้เร็วและใช้ได้ดีกับงานง่าย ๆ แต่มีจุดอ่อนที่ซ่อนอยู่ — มันมองไม่เห็น “ความสัมพันธ์” ระหว่างข้อมูล เพราะแต่ละ chunk เป็นก้อนข้อความที่ถูกตัดขาดจากกัน ตัวอย่างที่เห็นชัด: ถ้าคำตอบต้องเชื่อมข้อมูลจากหลายหน้า หลายเอกสาร หรือต้องรู้ว่า “บริษัท A เกี่ยวข้องกับคน B ผ่านดีล C ในปี D” การค้นแบบความคล้ายมักดึงมาไม่ครบหรือดึงผิดชิ้น ทำให้ LLM ตอบมั่ว (hallucination) เพราะได้บริบทไม่พอ

นี่คือเหตุผลที่วงการเริ่มมองหาวิธีที่ดีกว่าการหั่น chunk เฉย ๆ

สามเจเนอเรชันของ RAG: chunk → graph → hypergraph

วิธีคิดที่ช่วยให้เห็นภาพคือมอง RAG เป็นวิวัฒนาการสามขั้น:

• ขั้นที่ 1 — Standard RAG (หั่น chunk): ตัดเป็นชิ้น ค้นด้วยเวกเตอร์ ไม่สนใจโครงสร้างความสัมพันธ์เลย
• ขั้นที่ 2 — GraphRAG (กราฟความรู้): สกัดเอนทิตี (คน/บริษัท/สิ่งของ) และความสัมพันธ์ออกมาเป็นกราฟ ทำให้ตอบคำถามที่ต้องโยงข้อมูลได้ดีขึ้น แต่มีข้อจำกัดคือมันบังคับให้ความสัมพันธ์เป็นแบบ “คู่” (binary) เท่านั้น พอเจอข้อเท็จจริงที่โยงกันหลายฝ่าย (n-ary เช่น “หมอ X สั่งยา Y ให้คนไข้ Z ที่อาการ W”) ต้องถูกหั่นย่อยเป็นคู่ ๆ จนความหมายเพี้ยน
• ขั้นที่ 3 — Hypergraph RAG (ไฮเปอร์กราฟ): ใช้ “ไฮเปอร์เอดจ์” (เส้นเชื่อมหนึ่งเส้นที่โยงได้หลายโหนดพร้อมกัน) จึงเก็บความสัมพันธ์หลายฝ่ายไว้ได้ทั้งก้อนโดยไม่ต้องหั่น

ขั้นที่ 3 นี้แหละที่งานวิจัยล่าสุดชี้ว่าได้ผลจริง งานชื่อ Hyper-RAG (ตีพิมพ์ใน Nature Communications) รายงานว่าวิธีไฮเปอร์กราฟเพิ่มความแม่นยำเฉลี่ย 12.3% เมื่อเทียบกับการใช้ LLM ตรง ๆ และเหนือกว่า GraphRAG กับ LightRAG อยู่ราว 6.3% และ 6.0% ตามลำดับ (ทดสอบบนชุดข้อมูลทางการแพทย์กับ LLM 6 ตัว) ที่สำคัญคือมันยัง “นิ่ง” เมื่อคำถามซับซ้อนขึ้น ขณะที่วิธีอื่นเริ่มแย่ลง

จุดสำคัญที่ต้องจำ: เทรนด์ไม่ได้บอกว่า “chunk แย่” แต่บอกว่า “พอเอกสารมีความสัมพันธ์ซับซ้อน การเก็บเป็นโครงสร้างชนะการหั่นเป็นชิ้น” — เป็นเรื่องเลือกเครื่องมือให้ตรงงาน

Hyper-Extract ทำอะไรได้บ้าง

Hyper-Extract คือเครื่องมือ command-line (CLI) ที่เอาแนวคิดข้างบนมาทำให้ใช้งานได้จริงด้วยคำสั่งเดียว มันรับเอกสารดิบเข้าไป แล้วสกัดออกมาเป็นสิ่งที่ผู้เขียนเรียกว่า “Knowledge Abstract” — ความรู้ที่มีชนิดข้อมูลชัดเจน (strongly-typed) คาดเดาได้ ไม่ใช่ก้อนข้อความลอย ๆ

รายละเอียดที่ตรวจสอบจากหน้า repo และเอกสารทางการ:

• รองรับโครงสร้างข้อมูล 8 แบบ: ตั้งแต่ Model, List, Set ไปจนถึง Graph, Hypergraph, Temporal Graph (มีมิติเวลา), Spatial Graph (มิติพื้นที่) และ Spatio-Temporal Graph — เลือกได้ว่าจะสกัดเอกสารออกมาเป็นโครงสร้างแบบไหน
• มีอัลกอริทึมสกัดให้เลือกในตัว: KG-Gen, GraphRAG, LightRAG, Hyper-RAG และ Cog-RAG — เท่ากับรวมหลายแนวทางไว้ในเครื่องมือเดียว
• 80+ เทมเพลตสำเร็จรูป ครอบ 6 โดเมน เช่น การเงิน กฎหมาย การแพทย์ และทั่วไป — เช่นดึง “บริษัท/คน/ตัวเลข/ความเสี่ยง” ออกจากรายงานผลประกอบการ หรือเปลี่ยนเปเปอร์วิจัยเป็นกราฟความรู้
• ใช้งานผ่าน CLI ตรงไปตรงมา: ติดตั้งด้วย uv tool install hyperextract แล้วใช้คำสั่งอย่าง he parse (สกัดความรู้จากเอกสาร), he search (ค้นจากผลที่สกัด) และ he show (แสดงผล)

ตอนนี้มีดาวบน GitHub ราว 308 ดวง — ถือว่าเป็นโปรเจกต์ใหม่ที่เพิ่งเริ่มได้รับความสนใจ ไม่ใช่เครื่องมือที่สุกงอมระดับใช้ใน production วงกว้างแล้ว แต่จุดที่ทำให้ต่างจาก tool ตามกระแสทั่วไปคือ คนสร้าง (Yifan Feng) เป็นผู้เขียนหลักของงานวิจัย Hyper-RAG เอง เครื่องมือนี้จึงเป็นเหมือนการเอางานวิจัยมาทำให้คนทั่วไปใช้ได้จริง

รันในเครื่องตัวเอง + ต่อ Claude ผ่าน MCP

สองจุดที่ทำให้ Hyper-Extract เข้ากับโลกปี 2026 พอดี:

รันในเครื่อง (local) ด้วย vLLM — แทนที่จะส่งเอกสารไปให้ AI บนคลาวด์ประมวลผล Hyper-Extract ตั้งให้ชี้ไปที่โมเดลที่รันในเครื่องผ่าน vLLM ได้ (เช่นใช้ Qwen3.5-9B เป็นตัวคิด และ bge-m3 เป็นตัวทำ embedding บน localhost) ผลคือ ข้อมูลไม่ออกนอกเครื่อง เลย — เหมาะกับเอกสารอ่อนไหวมาก (ถ้ายังไม่คุ้นว่า Local AI คืออะไรและเหมาะกับใคร อ่าน ทำความรู้จัก Local AI และถ้าจะเลือกเครื่องมือรันเอง ดู คู่มือเลือก Ollama/LM Studio/llama.cpp)

ต่อเข้า Claude ผ่าน MCP — Hyper-Extract มี MCP server (he-mcp) ที่เปิดให้ผู้ช่วยที่รองรับ Model Context Protocol อย่าง Claude Desktop หรือ AI ใน IDE เข้ามา “ถาม” คลังความรู้ที่สกัดไว้ได้ (แบบอ่าน/ส่งออกเท่านั้น) MCP คือมาตรฐานเปิดปี 2026 ที่ให้ AI ต่อกับเครื่องมือ/ข้อมูลภายนอกแบบเดียวกันหมด ซึ่งกลายเป็นทักษะที่ AI Engineer ควรรู้ (เราพูดถึงไว้ใน โรดแมป AI Engineer)

ข้อควรระวังก่อนตื่นเต้น

• ยังเป็นของใหม่ (~308 ดาว) — เหมาะลองและเรียนรู้แนวคิด มากกว่าเอาไปวางใน production สำคัญทันที เช็ก repo/เอกสารล่าสุดก่อนใช้จริงเสมอ
• แพงกว่าและซับซ้อนกว่าการหั่น chunk — การสกัดเป็นกราฟต้องเรียก LLM หลายรอบ ใช้ compute มากกว่า และระบบกราฟ/ไฮเปอร์กราฟดูแลยากกว่า vector database ธรรมดา
• ไม่ใช่ทุกงานต้องใช้ — ถ้างานคือถามตอบจากเอกสารไม่กี่ไฟล์ที่ไม่ได้โยงกันซับซ้อน การหั่น chunk ก็เพียงพอและคุ้มกว่า
• ตัวเลขวิจัยมาจากชุดข้อมูลเฉพาะ (ส่วนใหญ่สายการแพทย์) ผลกับงานของคุณอาจต่างไป โดยเฉพาะกับเอกสารภาษาไทยที่ยังต้องทดสอบเอง

วิเคราะห์: เรื่องนี้สำคัญกับเรายังไง

กระทบนักพัฒนาและคนทำ RAG ทั่วไป

สัญญาณที่ชัดคือ “หั่น chunk แล้วจบ” ไม่ใช่มาตรฐานสูงสุดอีกต่อไปสำหรับเอกสารที่ซับซ้อน ถ้าคุณกำลังสร้างระบบที่ต้องตอบจากเอกสารที่ข้อมูลเชื่อมโยงกันเยอะ — รายงานการเงิน เอกสารวิจัย ระบบ compliance — การสกัดเป็นโครงสร้าง (กราฟ/ไฮเปอร์กราฟ) ให้ความแม่นยำที่ดีกว่าอย่างมีหลักฐานรองรับ

แต่ของแถมคือความซับซ้อนและต้นทุน วิธีคิดที่ถูกจึงไม่ใช่ “ย้ายไป graph RAG ทุกอย่าง” แต่คือ รู้ว่าเมื่อไรงานคุ้มที่จะลงทุนกับโครงสร้าง — เอกสารยิ่งสัมพันธ์กันซับซ้อนและความแม่นยำยิ่งสำคัญ ยิ่งคุ้ม

กระทบคนไทยและองค์กรไทยโดยเฉพาะ

จุดที่ตรงกับบริบทไทยมากคือ เรื่องข้อมูลและ PDPA องค์กรไทยจำนวนมากมีเอกสารอ่อนไหว (สัญญา ข้อมูลลูกค้า เวชระเบียน) ที่ส่งขึ้นคลาวด์ต่างประเทศไม่ได้ การที่ Hyper-Extract รันในเครื่องด้วย vLLM ได้หมายความว่าทำ knowledge extraction บนเอกสารพวกนี้ได้โดยข้อมูลไม่หลุดออกนอกองค์กร — ลดความเสี่ยง data residency ตรง ๆ

อีกมุมคือ งานเอกสารภาษาไทย ที่มักรกและไม่มีโครงสร้าง (PDF สแกน ฟอร์มหลายแบบ) การสกัดเป็นโครงสร้างมีศักยภาพช่วยได้ — แต่ต้องเผื่อใจว่าคุณภาพการสกัดภาษาไทยและเทมเพลตเฉพาะทางยังต้องทดสอบเอง ยังไม่การันตีเท่าภาษาอังกฤษ

ควรเตรียมหรือปรับตัวอะไร

• เข้าใจแนวคิด graph/structured RAG ไม่ใช่แค่ chunking — อย่างน้อยรู้ว่ามันคืออะไรและเมื่อไรควรใช้ จะคุยกับทีมและเลือกสถาปัตยกรรมได้
• ลองทดสอบกับงานจริง ถ้าเอกสาร RAG ของคุณเชื่อมโยงหลาย entity ลองเทียบ chunking เดิมกับ structured extraction บนเคสของตัวเอง
• งานอ่อนไหว → รันในเครื่อง (vLLM/Local) เก็บข้อมูลไว้กับองค์กร
• จับตา MCP — เครื่องมือฝั่ง knowledge เริ่มต่อเข้า Claude/IDE ผ่าน MCP มากขึ้นเรื่อย ๆ ใครทำสาย AI ควรเริ่มคุ้นกับมาตรฐานนี้
• อย่าเพิ่ง over-engineer — เริ่มจาก chunking ที่ง่ายและถูกก่อน ขยับไป structured เมื่อเจอเพดานจริง

โดยรวม Hyper-Extract ไม่ได้สำคัญเพราะตัวมันเองจะกลายเป็นมาตรฐาน แต่เพราะมันเป็นหมุดหมายที่ชัดว่า RAG กำลังโตจาก “ค้นหาในกองข้อความ” ไปสู่ “ให้เหตุผลบนความรู้ที่มีโครงสร้าง” ไม่ว่าคุณจะหยิบเครื่องมือตัวนี้ไปใช้หรือไม่ ทิศทางนี้คือสิ่งที่คนทำงานสาย AI ควรเข้าใจไว้ตั้งแต่วันนี้