หลังจากประมวลผลเอกสารไปแล้วกว่า 5 ล้านชิ้นทั่วทั้งแอปพลิเคชันด้านกฎหมายและการวิจัย นักพัฒนากำลังค้นพบว่าระบบ RAG ที่พร้อมสำหรับการใช้งานจริงต้องการมากกว่าแค่การค้นหาความคล้ายคลึงกันแบบเวกเตอร์ ฉันทามติของชุมชนที่เกิดขึ้นจากการอภิปรายล่าสุดเปิดเผยว่าการนำไปใช้ที่ประสบความสำเร็จต้องพึ่งพาชุดเทคนิคที่ซับซ้อนซึ่งทำงานได้ดีกว่าวิธีการพื้นฐานอย่างมาก
การปฏิวัติการจัดอันดับใหม่
สิ่งที่เริ่มต้นจากการค้นหาแบบเวกเตอร์ง่ายๆ ได้พัฒนากลายเป็นระบบการดึงข้อมูลแบบหลายขั้นตอนที่ซับซ้อน โดยการจัดอันดับใหม่ (reranking) ปรากฏออกมาเป็นอัพเกรดที่มีผลกระทบมากที่สุด นักพัฒนารายงานว่าการเพิ่มโมเดลเรียงลำดับใหม่แบบพิเศษ—ซึ่งจัดลำดับผลการค้นหาใหม่ตามความเกี่ยวข้องกับคำถามเฉพาะ—สามารถชดเชยข้อบกพร่องอื่นๆ มากมายในการตั้งค่า RAG การกำหนดค่าทั่วไปเกี่ยวข้องกับการป้อนข้อความย่อย (chunk) 50 รายการที่เป็นตัวเลือกเข้าสู่ตัวจัดอันดับใหม่ และรับกลับมาทั้งหมด 15 รายการที่เกี่ยวข้องที่สุด
บรรทัดโค้ด 5 บรรทัดที่มีมูลค่าสูงสุดที่คุณจะเพิ่ม ลำดับของข้อความย่อยเปลี่ยนไปมาก มากกว่าที่คุณคาดไว้
วิธีการนี้พิสูจน์แล้วว่ามีประสิทธิภาพมากกว่าการพึ่งพาเพียงความคล้ายคลึงกันโคไซน์ระหว่างการฝังตัว (embeddings) อย่างมีนัยสำคัญ เนื่องจากตัวจัดอันดับใหม่เข้าใจความเกี่ยวข้องตามบริบท แทนที่จะเป็นเพียงความคล้ายคลึงกันทางความหมาย
สิ่งที่สร้างผลลัพธ์ที่โดดเด่น (การจัดอันดับ ROI)
- Query Generation - LLM สร้างคำค้นหาหลายรูปแบบทั้งแบบความหมายและคีย์เวิร์ดเพื่อประมวลผลแบบขนาน
- Reranking - การนำเข้า 50 chunks และส่งออก 15 chunks ให้ผลลัพธ์ที่เหมาะสมที่สุด
- Chunking Strategy - ตรรกะที่กำหนดเองเพื่อให้แน่ใจว่าเป็นหน่วยที่มีเหตุผลโดยไม่ตัดกลางประโยค
- Metadata Injection - การเพิ่มชื่อเรื่อง ผู้แต่ง ฯลฯ เข้าไปใน context ของ LLM ช่วยปรับปรุงคำตอบ
- 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
