RAG (retrieval-augmented generation) คืออะไร และเมื่อไหร่ที่คุณต้องการมัน?
RAG ให้โมเดลภาษาของคุณข้อมูลเอกสารในช่วงเวลาถาม แทนที่จะฝังข้อมูลเหล่านั้นไว้ในนพารามิเตอร์ นี่คือวิธีการทำงานของ pipeline, ทำไมความล้มเหลวของ RAG ส่วนใหญ่เป็นจากความล้มเหลวในการดึงข้อมูล, และเมื่อไหร่วิธีการที่ง่ายกว่าจะชนะ
คำตอบโดยย่อ
RAG (การสร้างข้อมูลโดยการสืบค้น) คืออะไร?
การสร้างข้อมูลโดยการสืบค้น (Retrieval‑augmented generation) เป็นรูปแบบหนึ่งที่ระบบค้นหาเอกสารของคุณเองเพื่อหาบทที่เกี่ยวข้องกับคำถาม แล้วใส่บทเหล่านั้นเข้าไปใน Prompt ของโมเดลและขอให้โมเดลตอบโดยใช้ข้อมูลนั้น ระบบน้ำหนักของโมเดลไม่เคยเปลี่ยนแปลง; ความรู้จะมาถึงในรูปแบบของบริบทเมื่อใดก็ตามที่มีการเรียกใช้
ประเด็นสำคัญ
- RAG คือการค้นหาและการสร้างคำสั่ง (prompting) หากการค้นหาให้ข้อมูลผิด ผลลัพธ์ของคำตอบก็ไม่สามารถช่วยได้โดยโมเดลใด ๆ
- การคำนวณความคล้ายคลึงของเวกเตอร์เพียงอย่างเดียวอ่อนแอต่อชื่อเฉพาะ โค้ด และคำพูดที่ตรงกัน — การใช้การค้นหาแบบผสมผสานระหว่างคีย์เวิร์ดและเวกเตอร์เป็นวิธีที่เป็นประโยชน์และเป็นมาตรฐานปัจจุบัน
- มันอัปเดตทันที: เปลี่ยนเอกสาร แล้วคำตอบถัดไปก็เปลี่ยนด้วย การฝึกปรับแต่งทำไม่ได้
- การให้แหล่งอ้างอิงเป็นสิ่งสำคัญ คำตอบที่เชื่อมโยงกับแหล่งข้อมูลสามารถตรวจสอบได้ในขณะที่การสร้างข้อความแบบดิบทำไม่ได้
โมเดลภาษาจะรู้เฉพาะสิ่งที่อยู่ในข้อมูลการฝึกอบรมของมันเท่านั้น และไม่มีอะไรอื่นอีก มันไม่รู้เงื่อนไขสัญญาของคุณ ตัวเลขของไตรมาสที่แล้ว หรือรายงานเหตุการณ์ที่ยื่นเมื่อวานนี้ Retrieval-augmented generation เป็นวิธีมาตรฐานในการปิดช่องว่างนั้นโดยไม่ต้องฝึกอบรมใหม่
ไปป์ไลน์ ตั้งแต่ต้นจนจบ
RAG มีสองระยะ ระยะแรกเกิดขึ้นล่วงหน้า
การทำดัชนี (ออฟไลน์)
- รวบรวมเอกสาร
- แบ่ง เอกสารออกเป็นส่วนๆ — โดยทั่วไปแล้ว แต่ละส่วนจะมีโทเค็นตั้งแต่ไม่กี่ร้อยถึงสองสามพันโทเค็น
- คำนวณ การฝัง สำหรับแต่ละส่วน: เวกเตอร์ของตัวเลขที่กำหนดตำแหน่งของข้อความนั้นในพื้นที่ที่ความหมายที่คล้ายกันอยู่ใกล้กัน
- จัดเก็บเวกเตอร์ ข้อความต้นฉบับ และข้อมูลเมตา (แหล่งที่มา ส่วน วันที่ สิทธิ์การเข้าถึง) ในดัชนี
การตอบคำถาม (ต่อคำขอ)
- รับคำถามของผู้ใช้และฝังในลักษณะเดียวกัน
- ดึง ส่วนที่ใกล้ที่สุด — มักจะรวมกับการค้นหาคำหลัก
- อาจจะ จัดอันดับใหม่ ผู้สมัครด้วยโมเดลที่เล็กกว่าซึ่งให้คะแนนความเกี่ยวข้องแม่นยำกว่าระยะห่างของเวกเตอร์ดิบ
- ประกอบพรอมต์: คำแนะนำ ส่วนที่ดึงมา คำถาม
- สร้างคำตอบ พร้อมคำแนะนำให้ระบุว่าแต่ละข้ออ้างมาจากส่วนใด
นั่นคือทั้งหมดของแนวคิด ความชาญฉลาดอยู่ที่ขั้นตอนการดึงข้อมูล ไม่ใช่ขั้นตอนการสร้าง
ความล้มเหลวส่วนใหญ่ของ RAG คือความล้มเหลวในการดึงข้อมูล
เมื่อระบบ RAG ให้คำตอบที่ผิด สัญชาตญาณคือการตำหนิโมเดล เกือบทั้งหมดคือการค้นหา
ก่อนที่จะเปลี่ยนแปลงสิ่งอื่นใด ให้ทำการตรวจสอบนี้: นำคำถามที่ล้มเหลวมาดูส่วนที่ถูกดึงมาจริง และถามว่ามนุษย์ที่รอบคอบสามารถตอบได้อย่างถูกต้องจากส่วนเหล่านั้นหรือไม่ หากไม่เป็นเช่นนั้น โมเดลก็ไม่เคยได้รับโอกาส
สาเหตุทั่วไป เรียงตามลำดับความถี่โดยประมาณ:
- การจับคู่คำศัพท์ไม่ตรงกัน ผู้ใช้ถามเกี่ยวกับ "การยกเลิก" สัญญาบอกว่า "การยกเลิก" การค้นหาเวกเตอร์ล้วนจัดการเรื่องนี้ได้ค่อนข้างดี การค้นหาคำหลักล้วนทำไม่ได้
- ตัวระบุที่แน่นอน ผู้ใช้ถามเกี่ยวกับใบแจ้งหนี้
INV-2024-8871การค้นหาเวกเตอร์ แย่ ในเรื่องนี้ — การฝังตัวระบุไม่มีความหมายเกือบทั้งหมด การค้นหาคำหลักพบได้ทันที นี่คือข้อโต้แย้งที่แข็งแกร่งที่สุดเพียงข้อเดียวสำหรับ การดึงข้อมูลแบบไฮบริด: ทำทั้งสองอย่าง รวมการจัดอันดับ - ขอบเขตส่วนที่แย่ คำจำกัดความอยู่ในส่วนหนึ่ง ข้อยกเว้นอยู่ในส่วนถัดไป และมีเพียงส่วนเดียวที่ถูกดึงมา
- ตัวกรองข้อมูลเมตาที่ขาดหายไป คำตอบมาจากเอกสารที่ผู้ใช้ไม่ได้รับอนุญาตให้ดู หรือจากเวอร์ชันที่ถูกแทนที่ กรองตามสิทธิ์และความถูกต้อง ก่อน ความคล้ายคลึง ไม่ใช่หลังจากนั้น
- ผลลัพธ์น้อยเกินไป การดึงสามส่วนมีประสิทธิภาพและเปราะบาง ดึงยี่สิบ จัดอันดับใหม่ เก็บห้าส่วนที่ดีที่สุด
เมื่อ RAG เป็นเครื่องมือที่ไม่เหมาะสม
RAG ไม่ได้ฟรี มันเพิ่มดัชนีที่ต้องบำรุงรักษา ปัญหาคุณภาพการดึงข้อมูลที่ต้องตรวจสอบ และความหน่วงเวลาสำหรับทุกคำขอ ข้ามไปเมื่อ:
- คลังข้อมูลมีขนาดเล็ก หากฐานความรู้ทั้งหมดของคุณมี 20 หน้า ให้ใส่ไว้ในพรอมต์ระบบและแคชไว้
- คำถามไม่ได้เกี่ยวกับเอกสาร การรวม — "มีคำสั่งซื้อกี่รายการที่จัดส่งล่าช้าเมื่อเดือนที่แล้ว?" — เป็นของ SQL ให้โมเดลมีเครื่องมือสร้างคำสั่งค้นหาแทนดัชนีเวกเตอร์
- งานเป็นเรื่องของสไตล์ ไม่ใช่ข้อเท็จจริง การทำให้โมเดลเขียนด้วยน้ำเสียงของบริษัทของคุณเป็นปัญหาพรอมต์หรือการปรับแต่ง
นอกจากนี้ยังมีเส้นทางกลางที่ควรทราบ: การดึงข้อมูลแบบเอเจนต์ ซึ่งโมเดลได้รับเครื่องมือค้นหาและออกคำสั่งค้นหาของตนเอง โดยปรับปรุงหลังจากเห็นผลลัพธ์ มีค่าใช้จ่ายในการขอเพิ่ม แต่จัดการกับคำถามแบบหลายขั้นตอน ("เปรียบเทียบนโยบายปี 2024 และ 2025") ที่การดึงข้อมูลครั้งเดียวพลาดไป
ทำให้คำตอบน่าเชื่อถือ
สามวิธีปฏิบัติส่วนใหญ่ทำงานได้:
กำหนดให้มีการอ้างอิง ขอให้โมเดลแนบตัวระบุแหล่งที่มากับแต่ละข้ออ้าง และแสดงสิ่งเหล่านั้นเป็นลิงก์ ผู้ใช้สามารถตรวจสอบได้ และคุณสามารถวัดได้ว่าส่วนที่อ้างอิงสนับสนุนประโยคนั้นบ่อยเพียงใด
อนุญาตให้ปฏิเสธ กำหนดอย่างชัดเจน: หากส่วนที่ดึงมาไม่สามารถตอบคำถามได้ ให้กล่าวว่าคุณไม่ทราบ หากไม่มีสิ่งนี้ โมเดลที่เป็นประโยชน์จะเติมเต็มช่องว่างจากความรู้ทั่วไปของตนเอง — ซึ่งอาจถูกต้อง ผิด หรือเกี่ยวกับบริษัทอื่นโดยสิ้นเชิง
ประเมินการดึงข้อมูลแยกต่างหาก สร้างชุดคู่คำถาม-ส่วนที่ถูกต้อง และติดตามการเรียกคืนที่ k ตัวเลขนี้จะบอกคุณว่าการดึงข้อมูลกำลังดีขึ้นหรือไม่ โดยไม่ขึ้นกับว่าคำตอบอ่านอย่างไร ทีมที่เพียงแค่มองคำตอบสุดท้ายจะปรับแต่งแบบตาบอด
สิ่งที่ดีเป็นอย่างไร
ระบบ RAG ที่สมบูรณ์มีความน่าเบื่อในลักษณะเฉพาะ: มันตอบจากเอกสารของคุณ ลิงก์ไปยังเอกสารเหล่านั้น ยอมรับเมื่อไม่พบสิ่งใด และแสดงพฤติกรรมเดียวกันในวันพรุ่งนี้เหมือนวันนี้ การไปถึงจุดนั้นส่วนใหญ่คือวิศวกรรมการค้นหา — การแบ่งส่วน การดึงข้อมูลแบบไฮบริด การจัดอันดับใหม่ ตัวกรอง — โดยโมเดลภาษากระทำการในขั้นตอนสุดท้ายที่เล็กที่สุด
หากคุณกำลังเลือกว่าจะใช้เวลาหนึ่งสัปดาห์ไปกับอะไร ให้ใช้ไปกับการดึงข้อมูล
คำถามที่พบบ่อย
- RAG ดีกว่าการ Fine-tuning หรือไม่?
- พวกเขาแก้ปัญหาที่แตกต่างกัน ราก (RAG) ให้ข้อเท็จจริงที่โมเดลไม่มี; การฝึกปรับแต่งสอนรูปแบบ โทน หรือทักษะเฉพาะ หากปัญหาของคุณคือมันไม่รู้ข้อมูลของเรา ให้ใช้ RAG หากเป็นมันไม่ตอบตามที่เราต้องการ ให้พิจารณาการฝึกปรับแต่ง
- การมีช่วงบริบทที่มากขนาดไหนทำให้ RAG กลายเป็นสิ่งที่ล้าสมัยหรือไม่?
- มันลดความกดดันแต่ไม่ได้กำจัดความจำเป็น การส่งทั้งชุดข้อมูลในแต่ละคำขอมีค่าใช้จ่ายและใช้เวลามาก ส่วนความแม่นยำก็ยังลดลงเมื่อข้อมูลยาวมาก การเรียกคืนข้อมูลทำให้แต่ละคำขอเล็กและตรงกับความต้องการ
- ทำไมระบบ RAG ของฉันยังหลอกต่อไป?
- ปกติแล้วเพราะการตรวจ索คืนข้อมูลไม่มีประโยชน์ ทำให้โมเดลตอบอยู่ดี การแก้ไขคือการให้คำสั่งชัดเจนและตรวจสอบ: หากข้อความที่ตรวจ索ไม่มีคำตอบ ให้บอกว่าไม่มีคำตอบ
- Chunking คืออะไรและทำไมจึงสำคัญ?
- การแยกส่วน (Chunking) คือวิธีการแบ่งเอกสารก่อนทำการจัดทำดัชนี ชิ้นส่วนที่เล็กเกินไปจะทำให้สูญเสียบริบทโดยรอบ; ชิ้นส่วนที่ใหญ่เกินไปจะทำให้การจับคู่ลดความแม่นยำ การแยกตามโครงสร้างของเอกสาร — เช่น ส่วนและหัวข้อ — มักจะให้ผลดีกว่าการแยกตามจำนวนอักขระที่กำหนดไว้ล่วงหน้า