ความลับสกปรกของ RAG: ทำไมการค้นหาแบบเวกเตอร์เพียงอย่างเดียวถึงไม่พอ

ทีมชุมชน BigGo
ความลับสกปรกของ RAG: ทำไมการค้นหาแบบเวกเตอร์เพียงอย่างเดียวถึงไม่พอ

หลังจากประมวลผลเอกสารไปแล้วกว่า 5 ล้านชิ้นทั่วทั้งแอปพลิเคชันด้านกฎหมายและการวิจัย นักพัฒนากำลังค้นพบว่าระบบ RAG ที่พร้อมสำหรับการใช้งานจริงต้องการมากกว่าแค่การค้นหาความคล้ายคลึงกันแบบเวกเตอร์ ฉันทามติของชุมชนที่เกิดขึ้นจากการอภิปรายล่าสุดเปิดเผยว่าการนำไปใช้ที่ประสบความสำเร็จต้องพึ่งพาชุดเทคนิคที่ซับซ้อนซึ่งทำงานได้ดีกว่าวิธีการพื้นฐานอย่างมาก

การปฏิวัติการจัดอันดับใหม่

สิ่งที่เริ่มต้นจากการค้นหาแบบเวกเตอร์ง่ายๆ ได้พัฒนากลายเป็นระบบการดึงข้อมูลแบบหลายขั้นตอนที่ซับซ้อน โดยการจัดอันดับใหม่ (reranking) ปรากฏออกมาเป็นอัพเกรดที่มีผลกระทบมากที่สุด นักพัฒนารายงานว่าการเพิ่มโมเดลเรียงลำดับใหม่แบบพิเศษ—ซึ่งจัดลำดับผลการค้นหาใหม่ตามความเกี่ยวข้องกับคำถามเฉพาะ—สามารถชดเชยข้อบกพร่องอื่นๆ มากมายในการตั้งค่า RAG การกำหนดค่าทั่วไปเกี่ยวข้องกับการป้อนข้อความย่อย (chunk) 50 รายการที่เป็นตัวเลือกเข้าสู่ตัวจัดอันดับใหม่ และรับกลับมาทั้งหมด 15 รายการที่เกี่ยวข้องที่สุด

บรรทัดโค้ด 5 บรรทัดที่มีมูลค่าสูงสุดที่คุณจะเพิ่ม ลำดับของข้อความย่อยเปลี่ยนไปมาก มากกว่าที่คุณคาดไว้

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

สิ่งที่สร้างผลลัพธ์ที่โดดเด่น (การจัดอันดับ ROI)

  1. Query Generation - LLM สร้างคำค้นหาหลายรูปแบบทั้งแบบความหมายและคีย์เวิร์ดเพื่อประมวลผลแบบขนาน
  2. Reranking - การนำเข้า 50 chunks และส่งออก 15 chunks ให้ผลลัพธ์ที่เหมาะสมที่สุด
  3. Chunking Strategy - ตรรกะที่กำหนดเองเพื่อให้แน่ใจว่าเป็นหน่วยที่มีเหตุผลโดยไม่ตัดกลางประโยค
  4. Metadata Injection - การเพิ่มชื่อเรื่อง ผู้แต่ง ฯลฯ เข้าไปใน context ของ LLM ช่วยปรับปรุงคำตอบ
  5. Query Routing - การตรวจจับคำถามที่ไม่ใช่ RAG เพื่อจัดการด้วยวิธีอื่น

ก้าวข้ามการแบ่งส่วนพื้นฐาน

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

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

การสร้างและขยายคำถาม

นักพัฒนาค้นพบว่าคำถามจากผู้ใช้มักไม่สามารถจับภาพบริบทเต็มที่ที่จำเป็นสำหรับการดึงข้อมูลที่มีประสิทธิภาพ วิธีแก้ไข: การใช้ LLM เพื่อสร้างรูปแบบความหมายและคำหลักที่หลากหลายของคำถามดั้งเดิม จากนั้นประมวลผลเหล่านี้แบบขนาน เทคนิคนี้ซึ่งรู้จักกันในชื่อการขยายคำถาม (query expansion) เพิ่มการครอบคลุมการดึงข้อมูลได้อย่างมีนัยสำคัญ โดยไม่ต้องพึ่งพาคะแนนการค้นหาแบบไฮบริดที่คำนวณได้

การนำไปใช้แบบหนึ่งสร้างตัวแปรคำถามที่แตกต่างกันสามแบบในการเรียก LLM ครั้งเดียว เพื่อให้แน่ใจในความหลากหลายแทนที่จะมีความคล้ายคลึงกัน ผลลัพธ์จากการค้นหาแบบขนานจะถูกรวมเข้าด้วยกันโดยใช้การหลอมรวมอันดับซึ่งกันและกัน (reciprocal rank fusion) สร้างชุดเอกสารตัวเลือกที่แข็งแกร่งซึ่งตอบคำถามจากหลายมุม

สแต็กการดึงข้อมูลแบบเต็ม

ชุมชนส่วนใหญ่ได้ก้าวข้ามแนวความคิดที่มองว่าคลังเก็บเวกเตอร์เป็นทางออกที่ครอบคลุม ซึ่งเคยครอบงำการนำ RAG ไปใช้ในยุคแรกๆ ระบบที่ใช้งานจริงในปัจจุบันโดยทั่วไปจะรวมเอา:

  • การค้นหาแบบไฮบริดที่รวมเวกเตอร์แบบหนาแน่น (dense vectors) และ BM25 แบบเบาบาง (sparse BM25) สำหรับคำศัพท์ทางเทคนิค
  • การฉีดเมตาดาต้าเพื่อให้เบาะแสตามบริบทแก่ LLM
  • การกำหนดเส้นทางคำถามเพื่อจัดการคำถามที่ไม่ใช่ RAG ผ่านวิธีการอื่นๆ
  • โมเดลการฝังตัวและกลยุทธ์การดึงข้อมูลหลายแบบ

ดังที่นักพัฒนาของ Microsoft คนหนึ่งระบุว่า มีนักพัฒนาไม่กี่คนที่ตระหนักว่าคุณต้องการมากกว่าแค่การค้นหาแบบเวกเตอร์ ดังนั้นฉันจึงยังคงใช้เวลาพูดคุยหลายครั้งเพื่อเน้นย้ำสแต็กการดึงข้อมูลแบบเต็มสำหรับ RAG ปัจจุบัน Azure AI Search และโซลูชันระดับองค์กรอื่นๆ ได้ผสมผสานความสามารถเหล่านี้ลงในแพลตฟอร์มของพวกเขาโดยตรงแล้ว

คอมโพเนนต์ของ Production RAG Stack

คอมโพเนนต์ ตัวเลือกเริ่มต้น ตัวเลือกสุดท้าย ข้อค้นพบสำคัญ
Vector Database Azure → Pinecone Turbopuffer ราคาถูก มีระบบค้นหาคีย์เวิร์ดในตัว
Reranker ไม่มี → Cohere 3.5 Zerank ไม่ค่อยมีคนรู้จักแต่มีประสิทธิภาพ
Embedding text-embedding-large-3 เหมือนเดิม ไม่ได้ทดสอบทางเลือกอื่น
Chunking Unstructured.io แบบกำหนดเอง สำคัญต่อประสิทธิภาพ
Query Processing คำค้นหาเดียว การสร้างคำค้นหาหลายรูปแบบ ประมวลผลแบบขนานพร้อมการจัดอันดับใหม่

คำถามที่ยังเปิดอยู่และทิศทางในอนาคต

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

ชุมชนยังกำลังทดลองกับแนวทางที่ซับซ้อนมากขึ้น เช่น การกำหนดเส้นทางคำถามไปยังโมเดลการฝังตัวที่แตกต่างกันตามประเภทของเนื้อหา และการใช้ตัวจัดอันดับใหม่หลายตัวแบบต่อเนื่องหรือแบบขนาน นักพัฒนาบางคนกำลังผลักดันไปไกลกว่า RAG แบบดั้งเดิม ไปสู่การค้นหาแบบเอเจนต์ (agentic search) ที่ใช้เครื่องมือเช่น grep และการค้นหาแหล่งข้อมูลแบบเรียลไทม์ควบคู่ไปกับการดึงข้อมูลแบบดั้งเดิม

วิวัฒนาการยังคงดำเนินต่อไป ในขณะที่ทีมต่างๆ หาจุดสมดุลระหว่างความต้องการที่ขัดแย้งกันของความแม่นยำ ความล่าช้า และต้นทุน ในสภาพแวดล้อมการทำงานจริงที่ผู้ใช้คาดหวังความเข้าใจใกล้เคียงมนุษย์จากระบบการดึงข้อมูลเอกสารของพวกเขา

อ้างอิง: Production RAG: what I learned from processing 5M+ documents