Meta Superintelligence, REFRAG งานวิจัยชิ้นแรกอันน่าทึ่ง เพิ่มประสิทธิภาพ RAG ได้ 30 เท่า

 (paddedinputs.substack.com)
8 คะแนน โดย GN⁺ 2025-10-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Meta Superintelligence(MSI) เผยผลงานวิจัยชิ้นแรก REFRAG ซึ่งเป็นแนวทางใหม่ที่ยกระดับสถาปัตยกรรม RAG(Retrieval-Augmented Generation) แบบเดิมอย่างมาก จนทำให้ ความเร็วในการตอบสนองเพิ่มขึ้น 30 เท่า
  • แกนสำคัญคือการแปลงชิ้นส่วนเอกสารจากโทเค็นให้เป็นรูปแบบ 'Chunk Embedding' ที่ LLM เข้าใจได้โดยตรง และเพิ่ม policy network ที่จะกู้คืนเฉพาะบางส่วนเมื่อจำเป็น
  • วิธีนี้ช่วย ลดต้นทุน KV cache และ attention ลงอย่างมาก พร้อมลด ความหน่วงก่อนโทเค็นแรก(TTFT) เพื่อปรับปรุง UX และลดต้นทุนการดำเนินงานไปพร้อมกัน
  • งานวิจัยนี้ไม่ได้เน้นนวัตกรรมที่ระดับโครงสร้างโมเดล แต่เน้น ประสิทธิภาพในชั้นระบบและแอปพลิเคชัน โดยชี้ทิศทางเทคโนโลยีที่ สร้าง ROI ได้ทันที
  • สิ่งนี้แสดงให้เห็นถึงศักยภาพในการ หลบเลี่ยงข้อจำกัดด้านประสิทธิภาพและปัญหาต้นทุนของโมเดลขนาดใหญ่ และอาจนิยามใหม่ด้านความคุ้มค่าทางเศรษฐศาสตร์ของผลิตภัณฑ์ AI ในอนาคต

เบื้องหลังการเปิดเผยงานวิจัยชิ้นแรกของ MSI

  • ห้องวิจัย Meta Superintelligence(MSI) ได้รับความสนใจอย่างมากจากการดึงดูดบุคลากรระดับแนวหน้าของอุตสาหกรรมและเงินเดือนระดับสูงอย่างมาก
  • การที่ MSI เลือกหัวข้อ RAG(retrieval-augmented generation) ที่เน้นการใช้งานจริงเป็นงานวิจัยชิ้นแรกถือว่าไม่ธรรมดาอย่างมาก
  • เดิมทีอุตสาหกรรมคาดว่า MSI จะมุ่งไปที่ การเพิ่มประสิทธิภาพของ foundation model หรือการพัฒนาสถาปัตยกรรมใหม่ แต่กลับเลือกหัวข้อที่ ใช้งานได้จริงและให้ผลทางเศรษฐกิจทันที ซึ่งน่าประหลาดใจ
  • RAG เป็น องค์ประกอบหลักของบริการเชิงพาณิชย์ เช่น AI agent, การค้นหา, การสนับสนุนลูกค้า, และการสรุปเนื้อหา โดยความหน่วงของการตอบสนองและต้นทุนส่งผลโดยตรงต่อโมเดลธุรกิจ
  • งานวิจัยนี้นำเสนอวิธีลด ต้นทุนและเวลาแฝง ของผลิตภัณฑ์ AI ที่อิง RAG ได้อย่างมหาศาล ทำให้สร้าง ROI(ผลตอบแทนจากการลงทุน) ได้ทันที
    • พลิกปัญหาหน้างานจริงด้วยผลลัพธ์ ความเร็วในการตอบสนองที่เร็วขึ้น 30 เท่า
    • งานวิจัย : REFRAG: Rethinking RAG based Decoding

โครงสร้างทางเทคนิคของ REFRAG

  • 1. วิธี RAG แบบเดิมจะค้นหาเอกสารที่เกี่ยวข้อง(ชังก์)จาก vector DB แล้วให้ LLM ประมวลผลทุกชังก์ในรูปแบบโทเค็นเต็มทั้งหมด
  • 2. ใน REFRAG เอกสารจะถูก แบ่งเป็นชังก์(ประมาณ 128 โทเค็น) จากนั้น encoder ขนาดเบา จะแปลงแต่ละชังก์เป็นเวกเตอร์เดี่ยวแบบ embedding แล้วฉายเข้าไปยัง embedding space ของ LLM
    • embedding นี้สามารถ คำนวณล่วงหน้าและแคชไว้ได้
  • 3. เมื่อผู้ใช้ส่งคำถาม ระบบจะค้นหาชังก์ที่เกี่ยวข้อง
      - ชังก์ส่วนใหญ่จะถูกส่งให้ LLM ในรูป embedding และ
      - จะมีเพียงชังก์ส่วนน้อยมากที่ RL-based policy network เลือกเท่านั้น ที่ถูกขยายกลับเป็น ลำดับโทเค็นเต็ม แล้วส่งต่อ
  • 4. policy network นี้ถูกปรับให้เหมาะสมด้วยเป้าหมายแบบ RL(การเรียนรู้แบบเสริมกำลัง) เพื่อเลือกชังก์ที่ควรขยายภายใต้งบประมาณที่จำกัด
    • ฝึกด้วย reward function ที่ลด perplexity โดยยังคงคุณภาพการสร้างข้อความไว้
  • 5. LLM จะนำลำดับโทเค็นที่รับเข้า(คำถาม+ชังก์ที่ขยายแล้ว) มารวมกับ placeholder แบบเวกเตอร์เดี่ยวหลายตัว(ชังก์ที่ถูกบีบอัด) แล้วสร้างข้อความ
  • สุดท้ายแล้ว LLM สามารถรับ “คำถาม + โทเค็นบางส่วนที่กู้คืน + เวกเตอร์ embedding หลายตัว” และ สร้างผลลัพธ์เดิมได้ด้วยอินพุตที่สั้นลง
  • ด้วยโครงสร้างนี้ การใช้แคช, ปริมาณการคำนวณ attention, และเวลาเริ่มตอบสนอง จึงลดลงอย่างมาก

ความหมายทางเทคนิคและข้อสังเกตสำคัญ

  • แกนหลักของงานวิจัยคือ policy network สามารถ บีบอัดชังก์ที่สำคัญน้อยกว่าได้อย่างมีประสิทธิภาพ ภายในกระบวนการ RAG และใช้ นโยบายที่คลายเฉพาะส่วนสำคัญเท่านั้น
  • อินไซต์สำคัญที่ซ่อนอยู่ยิ่งกว่านั้นคือ “ถ้า embedding ถูกสร้างขึ้นอยู่แล้วภายในเลเยอร์ของ LLM ก็ไม่จำเป็นต้องคลายกลับเป็นภาษาธรรมชาติอีก แต่ส่ง embedding เข้าไปได้โดยตรง”
  • กล่าวคือ ระบบ ประมวลผลข้อมูลโดยตรงใน representation space ที่ LLM เข้าใจอยู่แล้ว จึงตัดขั้นตอนการบีบอัดซ้ำซ้อนออก และ เพิ่มความเร็วอย่างมากโดยไม่สูญเสียความแม่นยำ
  • แนวคิดนี้สรุปได้ว่า ไม่ใช่การปรับแต่งโทเค็นให้ดีขึ้น แต่คือ การเปลี่ยนความหมายของคำว่าโทเค็นไปเลย

ความสำคัญใน value chain ของ AI ปัจจุบัน

  • เปรียบเทียบสองแกนนวัตกรรมในวงการ LLM
    • นวัตกรรมระดับโมเดล: สถาปัตยกรรมใหม่, โมเดลขนาดใหญ่ขึ้น, การ pre-train แบบใหม่
      • ความเสี่ยงสูง, ผลตอบแทนสูง, ใช้เวลานาน, ต้องใช้เงินทุนมาก
    • ประสิทธิภาพระดับแอปพลิเคชัน/ระบบ: การปรับแต่ง inference, เทคนิค retrieval, orchestration
      • ความเสี่ยงต่ำ, ได้ ROI ทันที, สร้างรายได้โดยตรงได้
  • REFRAG อยู่ในทิศทางหลัง โดยให้ ROI ที่ชัดเจนในรูปของ throughput ต่อ GPU ที่เพิ่มขึ้น, ต้นทุนการดำเนินงานที่ลดลง, และ UX ที่ดีขึ้น
  • ทีมองค์กรและผลิตภัณฑ์สามารถทดสอบผลของ throughput ต่อ GPU ที่เพิ่มขึ้น, ต้นทุนโครงสร้างพื้นฐานที่ลดลง, และ UX ที่แข็งแรงขึ้น ได้ทันทีผ่านการนำแนวทาง REFRAG ไปใช้จริง
  • วิธีนี้สามารถ ผสานแบบอิสระ กับ retriever และ reranker ได้ ทำให้ประยุกต์ใช้กับ RAG pipeline เดิมได้อย่างยืดหยุ่น
  • โดยเฉพาะในช่วงที่ การแข่งขันในตลาด vector DB รุนแรงขึ้น พร้อมกับความผันผวนของอุตสาหกรรม เช่นข่าวลือเรื่องการขายกิจการของ Pinecone การปรับปรุง ประสิทธิภาพของ RAG จึงเป็นหัวข้อวิจัยที่เหมาะกับจังหวะเวลาอย่างยิ่ง

ข้อจำกัดที่คาดไว้

  • ความซับซ้อนด้านการฝึกและวิศวกรรม
    • ต้องเพิ่ม encoder + projection และฝึกให้ LLM เข้าใจ embedding(ทั้ง reconstruction pre-training + SFT)
    • นโยบายการเลือกแบบเลือกเฉพาะเป็นปัญหา RL ที่มีเสถียรภาพ แต่เพิ่มความซับซ้อนในการพัฒนา
  • ข้อจำกัดของการบีบอัด
    • การบีบอัดอย่างหนักเกินไปย่อมทำให้คุณภาพปลายทางลดลงในที่สุด
    • มี trade-off ระหว่างขนาด embedding กับความถี่ในการขยายกลับ
  • ปัญหาความสดใหม่ของข้อมูล
    • chunk embedding ที่คำนวณล่วงหน้าเหมาะกับ corpus แบบคงที่
    • หากข้อมูลเปลี่ยนบ่อย ต้องมี pipeline สำหรับคำนวณ embedding ใหม่ หรือพึ่งกลยุทธ์แบบ hybrid
  • ข้อพิจารณาตามลักษณะการใช้งาน
    • การสรุปเป็นงานที่ค่อนข้างหยาบ และงานที่ต้องการความแม่นยำเฉพาะทางสูง(เช่น การให้เหตุผลทางกฎหมาย, การอ้างอิงที่ถูกต้อง, ข้อเท็จจริงทางการแพทย์ที่อ่อนไหว) ต้องประเมินอย่างระมัดระวัง
    • ในกรณีเหล่านี้อาจต้องใช้งบประมาณการบีบอัดที่ต่ำกว่า

บทสรุปและนัยสำคัญ

  • คำถามหลักของงานวิจัยนี้คือ: "แทนที่จะพยายามปรับต้นทุนของโทเค็นให้เหมาะสม จะเป็นอย่างไรถ้าเราใช้โทเค็นคนละชนิดไปเลย?"
  • REFRAG เสนอ นวัตกรรมเชิงปฏิบัติที่เปลี่ยนโครงสร้างต้นทุนต่อหน่วยของผลิตภัณฑ์ AI โดย "นิยามใหม่ว่าโทเค็นที่ LLM อ่านคืออะไร" ซึ่งช่วยบรรเทาข้อจำกัดเชิงโครงสร้างของ RAG
  • ความเป็นไปได้ในการต่อยอดในอนาคต
    • ถ้าในด้าน READ นั้น LLM สามารถเป็น embedding-native ได้ แล้วในด้าน WRITE ก็จะเป็น embedding-native ได้เช่นกันหรือไม่ และจะเร่งความเร็วของ agent ทั้งระบบได้ 30 เท่าหรือไม่?
    • ต้นทุนต่อโทเค็นของ embedding model แทบเป็นศูนย์ — นี่คือการย้ายไปสู่สถาปัตยกรรมแบบอื่นเพื่อลดราคาโทเค็นลงอย่างมากหรือไม่? แล้วข้อเสียคืออะไร?
  • REFRAG เตือนให้เห็นว่า ไม่ใช่นวัตกรรมทุกอย่างจะต้องมาจากโมเดลที่ใหญ่ขึ้นเสมอไป
    • การทำให้ RAG ถูกลงและเร็วขึ้นในระดับขนาดใหญ่คือคันโยกที่ส่งผลโดยตรงต่อเศรษฐศาสตร์ของผลิตภัณฑ์
    • อุตสาหกรรมจะให้รางวัลกับทีมที่สามารถนำชัยชนะลักษณะนี้ไปใช้งานจริงในระดับปฏิบัติการได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-12
ความคิดเห็นจาก Hacker News

  • บทความนี้ไม่ได้เกี่ยวข้องกับ superintelligence และอธิบายว่าเป็นบทความที่ทีมซึ่งทำวิจัยมาก่อนการปรับโครงสร้างองค์กร นำมาตีพิมพ์หลังจากเปลี่ยนชื่อแล้ว หลายคนคาดว่า Meta จะไม่ตีพิมพ์บทความอีกต่อไปและจะกลายเป็นเหมือน OpenAI แต่ Meta ยังเดินหน้าตีพิมพ์บทความและปล่อยโมเดลแบบ open-weight อย่างรวดเร็วอยู่

    • ย้ำว่าสิ่งที่ Meta เปิดเผยนั้นไม่ใช่ open-source แต่เป็นโมเดลแบบเปิดน้ำหนัก และแม้แต่น้ำหนักเหล่านี้ก็ยังเผยแพร่ภายใต้ไลเซนส์ที่เข้มงวดกว่า Apache 2

    • ย้ำว่า MSL (ทีมนั้น) ไม่ได้ประกอบไปด้วยคนดังเพียงไม่กี่คนเท่านั้น

  • รู้สึกสับสนกับการที่คำว่า RAG (Retrieval-Augmented Generation) ถูกใช้ในความหมายที่หลากหลาย ในมุมมองของฉัน RAG คือระบบที่สร้าง vector embedding ให้กับแต่ละส่วนของเอกสารในคลังเอกสารที่กำหนดไว้ล่วงหน้า แล้วดึงเฉพาะส่วนที่จำเป็นมาใส่ในบริบทตามต้องการ หรือเป็นฟีเจอร์ในอินเทอร์เฟซแชต LLM ที่ค้นเว็บด้วยคีย์เวิร์ดและใส่เฉพาะเอกสารที่เกี่ยวข้องลงในบริบทชั่วคราว อยากรู้ว่าถ้ารองรับ context window ที่ยาวมากจะเกิดอะไรขึ้น หากใส่ข้อมูลทั้งหมดลงในบริบทพร้อมกันก็กลัวว่าความหลากหลายจะลดลง และถึงแม้จะช่วยเรื่องความสอดคล้อง ก็ยังคิดว่าในท้ายที่สุดการตัดสินใจว่าจะเก็บหรือทิ้งข้อมูลไหนก็น่าจะยังเป็น RAG อยู่ดี อยากฟังคำอธิบายจากผู้เชี่ยวชาญ

    • ในเชิงเทคนิค RAG คือทุกเทคนิคที่ช่วยการสร้างด้วยการค้นคืนจากภายนอก แต่โดยทั่วไปมักใช้ในความหมายที่แคบลงว่าเป็นวิธีที่ใช้ vector DB การใส่ข้อมูลทั้งหมดลงใน context window ขนาดใหญ่เป็นเรื่องไม่คุ้มค่า ใช้เวลาประมวลผลมากขึ้น และเมื่อข้อมูลมากเกินไป โมเดลก็จะหาข้อมูลที่ต้องการได้ยากขึ้น สุดท้ายแล้วเมื่อจำเป็นต้องมี latency ต่ำหรือมีข้อจำกัดด้านหน่วยความจำ วิธี RAG แบบ “ดั้งเดิม” ก็ยังมีประโยชน์อยู่

    • หัวใจสำคัญคือความสามารถในการปรับตัว ความแตกต่างหลักระหว่าง RAG และ non-RAG คือ ตอนสร้างดัชนีนั้นรู้คำถามอยู่แล้วหรือไม่ และมีความสามารถในการเปรียบเทียบข้ามเอกสารที่ดึงมา รวมถึงการแยกย่อยคำถามหรือไม่ Non-RAG ใช้วิธีอย่าง non-causal transformer หลายชั้นเพื่อดูคำถามและเอกสารพร้อมกัน จึงมีความทั่วไปมากกว่าและปรับให้เหมาะกับ deep learning ได้ง่ายกว่า ขณะที่ RAG เร็วและถูกกว่า แต่เพราะใช้เครื่องมือภายนอกจึงฝึกแบบ end-to-end ได้ยากกว่า (ต้องอาศัยการเรียนรู้จากรางวัลอย่าง RL) RAG ถือว่าเอกสารเป็นอิสระต่อกัน และไม่รู้คำถาม ณ เวลาที่ทำดัชนี นอกจากนี้ยังมีรูปแบบไฮบริดที่เอาผลลัพธ์จาก RAG ไปป้อนให้ non-RAG เพื่อผสานกันได้ด้วย Non-RAG ต้องการชุดข้อมูลขนาดใหญ่ แต่หากฝึกกับข้อมูลระดับทั้งเว็บ ประสิทธิภาพก็จะดีขึ้นเรื่อย ๆ การปรับปรุงประสิทธิภาพในกรณีเฉพาะกลับทำได้ง่ายกว่า RAG มีจุดแข็งด้านการควบคุมอินพุตและข้อมูลที่มีโครงสร้าง และเหมาะกับการป้องกันกรณีแย่ที่สุด แต่การยกระดับ best case ทำได้ยาก

    • คิดว่าเราไม่สามารถใส่ข้อมูลได้ไม่สิ้นสุดลงไปในบริบท จากประสบการณ์ของฉัน GPT-5 เริ่มสับสนอย่างรวดเร็วหลังผ่านไปไม่กี่หน้า ต่อให้ใส่ข้อมูลมากขนาดนั้นก็จำไม่ได้อยู่ดี

    • ไม่คิดว่ามีใครพูดจริง ๆ ว่า “RAG ตายแล้ว” การใส่อินเทอร์เน็ตทั้งหมดเข้าไปในบริบทของ LLM เป็นไปไม่ได้ และยิ่งใส่มากต้นทุนก็ยิ่งสูงขึ้น

  • Meta มีคนฝีมือระดับท็อปอยู่มาก แต่ดูเหมือนจะยังใช้ศักยภาพเหล่านั้นได้ไม่เต็มที่ ในมุมมองของฉัน หากไม่หมกมุ่นกับตัวชี้วัดผลงานมากเกินไปและให้อิสระกับนักวิจัยมากขึ้น ก็อาจนำหน้าในสนามแข่งขัน AI ได้มากกว่านี้ ทีมที่เพิ่งเข้ามาใหม่ให้ความรู้สึกว่ามีคนที่เก่งด้านการทำให้เป็นระบบ และคนที่สนใจเรื่องเงินมากกว่าเป็นแกนหลัก อันที่จริงแนวโน้มแบบนี้มีอยู่ชัดเจนในแล็บของบิ๊กเทคแทบทุกแห่ง องค์กรเหล่านี้หลีกเลี่ยงความเสี่ยงมากเกินไป ในอดีต การให้อิสระแก่นักวิจัยคือหนึ่งในเหตุผลที่ทำให้ซิลิคอนแวลลีย์กลายเป็นอย่างทุกวันนี้ สำหรับฉันรวมถึงนักวิจัย ML อีกหลายร้อยคน หากได้รับทั้งอิสระและทรัพยากร เราก็พร้อมทำงานแม้ได้เงินเดือนน้อยกว่านี้มาก Meta เองก็ควรกระจายการใช้เงินลงทุนในตอนนี้ให้หลากหลายขึ้น และย้อนกลับไปมองหลักการที่ทำให้ซิลิคอนแวลลีย์เติบโต

    • ฉันคิดว่ายิ่งมีคู่แข่งมากขึ้น ก็ยิ่งเกิดปรากฏการณ์ที่คนซึ่งเก่งในการเล่นตามระบบจะอยู่รอดบนสุด มากกว่าคนที่ “เก่งจริง” ดูได้จากกรณีการสมัครงาน GAFAM หรือแม้แต่ Tinder

    • การที่แล็บของบริษัทให้อิสระกับนักวิจัย ดูเหมือนจะไม่ได้ช่วยธุรกิจจริงมากนัก ดูจากกรณีอย่าง Bell Labs หรือ Microsoft Research ก็เห็นว่ามีงานวิจัยยอดเยี่ยมมากมาย แต่แทบไม่เชื่อมโยงกับธุรกิจหลักของบริษัท ประเด็นคือ งานวิจัย AI ไม่ได้สร้างรายได้หรือความสามารถในการแข่งขันให้ Meta อย่างเป็นรูปธรรม แต่ช่วยเพิ่มพูนความรู้ของส่วนรวมมากกว่า ซึ่งในมุมของบริษัท วิธีแบบนี้ไม่ค่อยเหมาะนัก ยิ่งไปกว่านั้น หากจะเป็นนักวิจัย ตอนนี้ในสายวิชาการเองก็ยุ่งกับการดูแลนักศึกษาและการประชุมมากอยู่แล้ว

    • มีข้อสงสัยกับคำกล่าวที่ว่าความก้าวหน้าของ AI ช้าลง วัดจากอะไรจึงพูดเช่นนั้น หากเป็นคนที่ติดตามวงการจริง ๆ ก็น่าจะเห็นด้วยได้ยาก

    • ท่ามกลางแรงกดดันของ Meta ฉันมักสงสัยเสมอว่านักคณิตศาสตร์ที่ได้รับเงินเดือนมหาศาลเหล่านั้นจะยังมีเวลาคิดอย่างอิสระจริงหรือไม่

    • การตัดสินใจของ Alex Wang น่าสนใจ มี CEO ของสถาบันวิจัย AI ที่ยอดเยี่ยมอยู่มาก และถึง Wang จะมีจุดเด่นอยู่บ้าง แต่ในความเป็นจริงก็แทบทั้งหมดมาจาก MTurk และจังหวะของตลาด เขาไม่น่าเหมาะจะเป็น CEO ที่จะนำไปสู่ AGI

  • ค่อนข้างแปลกใจที่หัวข้อของบทความแรกจากแล็บใหม่เป็นเรื่อง RAG ที่เน้นการใช้งานจริงและสมจริง ปกติแล้วแล็บใหม่มักจะตีพิมพ์บทความจากหัวข้อที่แต่ละคนทำอยู่ก่อนสักไม่กี่ชิ้นในช่วงแรก แล้วเมื่อมี teamwork และ synergy มากพอจึงค่อยมีงานวิจัยเชิงนวัตกรรมออกมาอย่างจริงจัง หากให้ความหมายกับ “บทความแรก” มากเกินไป อาจยิ่งเพิ่มแรงกดดันตั้งแต่เริ่มต้น

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

  • สงสัยว่าบทความจากทีม superintelligence ของ Meta นี้เป็นงานที่วางแผนโดยทีมดังกล่าวโดยตรง หรือเป็นงานที่คนซึ่งทำอยู่เดิมย้ายทีมแล้วค่อยนำมาตีพิมพ์ เดาว่าแบบแรกมีความเป็นไปได้มากกว่า

    • ตามความเห็นอีกด้านหนึ่ง ระบุว่าเป็นแบบหลัง (เป็นบทความที่ตีพิมพ์ตามการปรับโครงสร้างองค์กร) อ้างอิง

  • แชร์สรุปวิดีโออธิบายบน YouTube เกี่ยวกับบทความ RAG นี้ ลิงก์วิดีโอ

  • จากกราฟและตารางในบทความ ยังไม่เห็นการเปรียบเทียบกับเทคนิคการบีบอัดบริบทแบบสถิติที่ง่ายและดั้งเดิม เช่น TF-IDF หรือการนับคำซ้ำแบบง่าย ๆ อย่างชัดเจน ในภาคอุตสาหกรรม วิธีเรียบง่ายแบบนี้สำคัญมาก เพราะให้ประสิทธิภาพแทบไม่ต่างกันแต่ลดปริมาณข้อมูลได้ถึง 10 เท่า

  • เคยคิดและลงมือทำแนวคิดที่คล้ายกันมาก่อน ต่อไปน่าจะต้องมีเฟรมเวิร์กที่ทำให้ LLM จัดการกับรูปแบบ embedding ที่หลากหลายได้ง่ายขึ้น และช่วยทำให้เรื่องนี้เรียบง่ายลง

  • แนะนำลิงก์โปรเจกต์ open-source ที่เกี่ยวกับ RAG REFRAG

  • อยากได้พาดหัวที่ให้ข้อมูลมากกว่านี้และไม่ชวนคลิกเกินไป เพราะชื่อบทความดูเร้าอารมณ์เกินไป

    • อยากรู้ว่าถ้าใช้ถ้อยคำหลักของบทความเอง ควรตั้งชื่อแบบไหนถึงจะให้ข้อมูลมากขึ้นและเร้าอารมณ์น้อยลง