วิธีการสร้าง RAG ที่น่าเชื่อถือ: การสำรวจลึกเกี่ยวกับ 7 จุดล้มเหลวและเฟรมเวิร์กการประเมิน

การสร้างแบบจำลองที่เพิ่มการค้นหาข้อมูล (RAG) มีความสำคัญอย่างมากสำหรับสถาปัตยกรรม AI ในยุคปัจจุบัน โดยทำหน้าที่เป็นเฟรมเวิร์กที่จำเป็นสำหรับการสร้างตัวแทนการทำงานที่ตระหนักถึงบริบท

แต่การเปลี่ยนจากต้นแบบพื้นฐานไปสู่ระบบที่พร้อมใช้งานในระดับผลิตนั้น ต้องเผชิญกับอุปสรรคที่สำคัญในด้านการดึงข้อมูล การรวมบริบท และการสร้างคำตอบ

บทความนี้ให้การสำรวจลึกเกี่ยวกับจุดล้มเหลวที่พบบ่อย 7 จุดของ RAG และเมตริกการประเมินที่มีการใช้งานจริงพร้อมตัวอย่างโค้ด

การวิเคราะห์ความล้มเหลวของ RAG – 7 จุดล้มเหลว (FPs)

ตามที่นักวิจัย Barnett et al., ระบบ RAG ประสบกับจุดล้มเหลว 7 จุดที่เฉพาะเจาะจงตลอดทั้งกระบวนการ

แผนภาพด้านล่างแสดงถึงขั้นตอนเหล่านี้:

Figure A. ขั้นตอนการสร้างดัชนีและค้นหาที่จำเป็นสำหรับการสร้างระบบ RAG การสร้างดัชนีทำที่เวลาในการพัฒนา และการค้นหาทำที่เวลาในการทำงาน จุดล้มเหลวที่ระบุในงานศึกษานี้แสดงเป็นกล่องสีแดง (แหล่งที่มา)

มาทำความเข้าใจกับแต่ละจุดล้มเหลวที่จัดเรียงตามลำดับของกระบวนการ โดยเริ่มจากด้านบนซ้ายไปด้านล่างขวาใน Figure A

FP1. ข้อมูลที่หายไป

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

จุดล้มเหลวนี้เกิดขึ้นเมื่อ LLM ให้คำตอบที่ดูเป็นไปได้แต่ไม่ถูกต้อง แทนที่จะบอกว่า “ไม่รู้”

FP2. ไม่พบเอกสารอันดับต้นๆ

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

ดังนั้น ข้อมูลที่ถูกต้องจึงไม่ถึง LLM

FP3. ไม่อยู่ในบริบท (ข้อจำกัดของกลยุทธ์การรวม)

สถานการณ์นี้เกิดขึ้นเมื่อเอกสารที่ถูกต้องมีอยู่และถูกดึงออกมาจากดัชนีแบบเวกเตอร์ แต่ถูกตัดออกไประหว่างกระบวนการรวม

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

FP4. ไม่ได้นำออกมา

สถานการณ์นี้เกิดขึ้นเมื่อ LLM ล้มเหลวในการระบุข้อมูลที่ถูกต้องในบริบท แม้ว่าข้อมูลที่ถูกต้องจะอยู่ในดัชนีแบบเวกเตอร์และถูกดึงออกมา/รวมเข้าด้วยกันแล้วก็ตาม

สิ่งนี้เกิดขึ้นเมื่อบริบทมีความเสียงดังหรือมีข้อมูลที่ขัดแย้งกันซึ่งทำให้ LLM สับสน

FP5. รูปแบบที่ไม่ถูกต้อง

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

FP6. ความเฉพาะเจาะจงที่ไม่ถูกต้อง

การผลิตของ LLM มีอยู่ แต่ ไม่เจาะจงหรือซับซ้อนเกินไป เมื่อเทียบกับความต้องการของผู้ใช้

ตัวอย่างเช่น LLM สร้างคำตอบง่ายๆ สำหรับคำถามที่มีเป้าหมายทางวิชาชีพที่ซับซ้อน

FP7. คำตอบที่ไม่สมบูรณ์

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

ตัวอย่างเช่น เมื่อผู้ใช้ถามคำถามที่ซับซ้อน เช่น “จุดสำคัญในเอกสาร A, B และ C คืออะไร?” LLM ตอบเพียงหนึ่งหรือสองแหล่งเท่านั้น

วิธีที่ FPs อ่อนแอลงไปในประสิทธิภาพของ RAG Pipeline

จุดล้มเหลวแต่ละจุดมีผลกระทบต่อประสิทธิภาพของ RAG Pipeline:

ความสมบูรณ์ของข้อมูลและการล้มเหลวของความน่าเชื่อถือ

เมื่อมีข้อมูลที่หายไปหรือไม่ถูกต้อง ระบบจะไม่น่าเชื่อถืออีกต่อไป จุดล้มเหลวหลักๆ ได้แก่:

• FP1 (ข้อมูลที่หายไป): คำตอบไม่มีอยู่ในเอกสารตั้งแต่แรก
• FP4 (ไม่ได้นำออกมา): LLM ตัดสินใจที่จะเพิกเฉยต่อคำตอบที่ถูกต้องในเอกสาร
• FP7 (ไม่สมบูรณ์): LLM ให้คำตอบที่ไม่สมบูรณ์ โดยขาดชิ้นส่วนที่สำคัญ

การค้นหาที่ไม่มีประสิทธิภาพและการขาดประสิทธิภาพ

กระบวนการ RAG อาจไม่มีประสิทธิภาพเมื่อพลาดข้อมูลสำคัญในขั้นตอนการค้นหาและรวม จุดล้มเหลวหลักๆ ได้แก่:

• FP2 (ไม่พบเอกสารอันดับต้นๆ): โมเดลการฝังตัวล้มเหลวในการเลือกเอกสารอันดับต้นๆ
• FP3 (การรวม): สคริปต์ที่ตัดเอกสารให้พอดีกับข้อจำกัดของ LLM ลบส่วนที่สำคัญที่สุดออกไป

ความผิดพลาดด้านประสบการณ์ของผู้ใช้และการแสดงผล

แม้ว่าคำตอบจะถูกต้อง แต่การแสดงผลที่มีความอ่านยากหรือไม่ถูกต้องสามารถทำให้ผู้ใช้ไม่พอใจ จุดล้มเหลวหลักๆ ได้แก่:

• FP5 (รูปแบบที่ไม่ถูกต้อง): LLM ล้มเหลวในการปฏิบัติตามรูปแบบการแสดงผลที่เฉพาะเจาะจง เช่น JSON
• FP6 (ความเฉพาะเจาะจงที่ไม่ถูกต้อง): LLM สร้างคำตอบที่ยาวเกินไปสำหรับคำถามแบบใช่/ไม่ใช่ หรือสั้นเกินไปสำหรับคำถามที่ซับซ้อน

สแต็คการประเมิน: เฟรมเวิร์กในการบรรเทา FPs

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

เมตริกการประเมิน RAG ที่สำคัญ:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – การทดสอบหน่วยก่อนการนำไปใช้

DeepEval คำนวณคะแนนตามเกณฑ์ที่กำหนด

LLM ในฐานะ “ผู้ตัดสิน” (เช่น GPT-4o) ประเมินแต่ละเกณฑ์เทียบกับการผลิตของ LLM:

DeepEval ใช้ G-eval ซึ่งเป็นเฟรมเวิร์ก การคิดเป็นชุด ที่ใช้การประเมินแบบหลายขั้นตอน:

1. กำหนดเกณฑ์ ที่จะวัด (เช่น “ความสอดคล้อง” “ความคล่องแคล่ว” หรือ “ความเกี่ยวข้อง”)
2. สร้าง ขั้นตอนการประเมิน (โดยใช้ LLM ตัดสิน)
3. ปฏิบัติตามขั้นตอนการประเมินและวิเคราะห์ข้อมูลเข้าและผลิตของ LLM
4. คำนวณ ผลรวมถ่วงน้ำหนัก ของคะแนนแต่ละเกณฑ์

สถานการณ์ทั่วไปในทางปฏิบัติ

• สถานการณ์: โชว์หุ่นยนต์สำหรับเอกสารทางเทคนิคสำหรับผลิตภัณฑ์ซอฟต์แวร์ที่ซับซ้อนดูเหมือนจะทำงานทุกครั้งที่ทีมวิศวกรอัปเดตโค้ดเบส
• ปัญหา: ไม่มีหลักฐานเชิงปริมาณว่าหุ่นยนต์สามารถตอบคำถามของผู้ใช้ได้ (คุณแค่ “คิด” ว่ามันทำงาน…)
• วิธีแก้ปัญหา: รวมฟังก์ชัน PyTest เป็นชุดการถดถอยแบบ CI/CD เข้ากับ Github Action โดยที่ DeepEval ใช้ G-Eval และเมตริกอื่นๆ เหล่านี้:

• ผลลัพธ์ที่คาดหวัง: หากคะแนนของเมตริกใดๆ ต่ำกว่าเกณฑ์ (0.85) PyTest จะแสดง AssertionError – ทำให้การสร้าง CI ล้มเหลวและป้องกันการถดถอยแบบเงียบๆ ที่จะไปถึงการผลิต

หมายเหตุสำหรับนักพัฒนา – กรณีทดสอบสำหรับ DeepEval
ชุดของ LLMTestCase นิยามกรณีทดสอบที่ DeepEval ใช้

ในทางปฏิบัติ กรณีทดสอบนี้ควรประกอบด้วยคำถามของผู้ใช้ที่สำคัญที่สุดและผลลัพธ์ที่มีฉลากพร้อมด้วยบริบทที่ดึงออกมา

สิ่งเหล่านี้สามารถดึงมาจากไฟล์ JSON หรือ CSV ได้

RAGAS – ผู้เชี่ยวชาญในการค้นหาในกองฟาง

RAGAS มีจุดมุ่งหมายเพื่อประเมิน RAG โดยไม่ต้องใช้ชุดข้อมูลที่มีการทำเครื่องหมายโดยมนุษย์ โดยการสร้างชุดทดสอบสังเคราะห์

จากนั้นจึงคำนวณเมตริกหลัก:

Figure B. รูปสามเหลี่ยมการประเมิน RAGAS ที่เชื่อมต่อคำถาม บริบท และคำตอบผ่านเมตริกความแม่นยำ ความถูกต้อง ความน่าเชื่อถือ และความเกี่ยวข้อง (สร้างโดย Kuriko IWAI)

เมตริกหลักเหล่านี้แบ่งออกเป็นสามกลุ่ม:

• การค้นหาข้อมูล (เส้นตรง สีดำ Figure B): ความแม่นยำของบริบท ความถูกต้องของบริบท
• การสร้าง (เส้นประ สีดำ Figure B): ความน่าเชื่อถือ ความเกี่ยวข้องของคำตอบ
• ความจริง (กล่องสีแดง Figure B): ความคล้ายคลึงของคำตอบ ความถูกต้องของคำตอบ

สถานการณ์ทั่วไปในทางปฏิบัติ

• สถานการณ์: ระบบ RAG สำหรับสัญญาทางกฎหมายขาดข้อกำหนดสำคัญ คุณไม่แน่ใจว่าปัญหาอยู่ที่การค้นหา (ผู้ค้นหา) หรือการอ่าน (ผู้สร้าง)
• ปัญหา: ไม่มีแนวคิดเกี่ยวกับจำนวนชิ้นส่วนที่ดึงออกมาที่เหมาะสม (top-k)
• วิธีแก้ปัญหา: ใช้ RAGAS เพื่อสร้างชุดทดสอบสังเคราะห์พร้อมกับ 100 คู่ของคำถามและหลักฐาน จากนั้นจึงใช้ RAG Pipeline กับชุดทดสอบเพื่อคำนวณความถูกต้องของบริบทและความแม่นยำของบริบท:
• ผลลัพธ์ที่คาดหวัง: ขึ้นอยู่กับผลลัพธ์ของเมตริก คุณสามารถวางแผนการดำเนินการต่อไปได้ดังนี้:

ตาราง 1. แผนการดำเนินการ RAGAS – การแมปคะแนนไปสู่การปรับเปลี่ยนระบบ

TruLens – ผู้เชี่ยวชาญด้านวงจรป้อนกลับ

TruLens มุ่งเน้นไปที่กลไกภายในของกระบวนการ RAG มากกว่าแค่ผลลัพธ์สุดท้าย โดยใช้ ฟังก์ชันป้อนกลับ

มันใช้คะแนนของ LLM ที่สะท้อนถึงว่าคำตอบตอบสนองความตั้งใจของคำถามได้ดีเพียงใด โดยใช้มาตราส่วน Likert 4 จุด (0-3) ทำให้มีความเหนือกว่าในการ จัดอันดับคุณภาพ ของผลลัพธ์การค้นหาที่แตกต่างกัน

สถานการณ์ทั่วไปในทางปฏิบัติ

• สถานการณ์: หุ่นยนต์ให้คำปรึกษาทางการแพทย์ตอบคำถามของผู้ใช้อย่างถูกต้อง แต่เพิ่มคำแนะนำที่ไม่ได้อยู่ในฐานข้อมูล PDF ที่ตรวจสอบแล้ว
• ปัญหา: คำแนะนำที่เพิ่มอาจมีประโยชน์ แต่ไม่ได้มาจากแหล่งที่เชื่อถือได้
• วิธีแก้ปัญหา: ใช้ TruLens เพื่อใช้ฟังก์ชันป้อนกลับสำหรับการยึดมั่น โดยมีเกณฑ์ เช่น คะแนน > 0.8

• ผลลัพธ์ที่คาดหวัง: เมื่อ LLM สร้างคำตอบที่มีข้อมูลที่ไม่มีอยู่ในเอกสารที่ดึงออกมา TruLens ระบุบันทึกในแดชบอร์ดของคุณ

Arize Phoenix – แผนที่การล้มเหลวเงียบๆ

Arize Phoenix เป็นเครื่องมือการตรวจสอบและประเมินที่เปิดกว้างสำหรับการประเมินผลลัพธ์ของ LLM รวมถึงระบบ RAG ที่ซับซ้อน

สร้างขึ้นบน OpenTelemetry โดย Arize AI มุ่งเน้นไปที่การตรวจสอบโดยการรักษาการประเมิน LLM เป็นชุดย่อยของ MLOps

ในบริบทของการประเมิน RAG Phoenix มีความโดดเด่นในด้าน การวิเคราะห์การฝังตัว โดยใช้ การประมาณการแบบยูนิฟอร์มของแมนิโฟลด์ (UMAP) เพื่อลดการฝังตัวแบบเวกเตอร์สูงมิติลงเป็นพื้นที่ 2D/3D

การวิเคราะห์การฝังตัวนี้เปิดเผยโดยการคำนวณว่าคำถามที่ล้มเหลวถูกจัดกลุ่มเข้าด้วยกันทางพื้นที่语义 ซึ่งบ่งชี้ถึงช่องว่างในฐานข้อมูลเวกเตอร์

สถานการณ์ทั่วไปในทางปฏิบัติ

• สถานการณ์: หุ่นยนต์สนับสนุนลูกค้าทำงานได้ดีสำหรับการคืนเงิน แต่ให้คำตอบที่ไม่มีเหตุผลสำหรับการร้องเรียนการรับประกัน
• ปัญหา: ช่องว่างในฐานข้อมูลเวกเตอร์ (ไม่สามารถพบในบันทึก)
• วิธีแก้ปัญหา: ใช้ Arize Phoenix เพื่อสร้างการแสดงภาพ Umap Embedding (UEV) ซึ่งเป็นแผนที่ 3 มิติสำหรับฐานข้อมูลเวกเตอร์ – เพื่อซ้อนทับคำถามของผู้ใช้บนเอกสารชิ้นส่วน
• ผลลัพธ์ที่คาดหวัง: มองเห็นภาพรวมของคำถามของผู้ใช้ที่ลงจอดในพื้นที่ที่ไม่มีเอกสาร ซึ่งบ่งชี้ว่าเอกสารบางส่วนถูกละเว้นไม่ถูกอัปโหลดเข้าสู่ฐานข้อมูลเวกเตอร์

Braintrust – ตาข่ายความปลอดภัยสำหรับการถดถอยของคำสั่ง

Braintrust ได้รับการออกแบบสำหรับวงจรการวนซ้ำที่มีความถี่สูงโดยใช้ การเปรียบเทียบแบบข้ามโมเดล

สถานการณ์ทั่วไปในทางปฏิบัติ

• สถานการณ์: ทีมวิศวกรอัปเกรดคำสั่งจาก “ตอบคำถาม” (กรณี A) เป็นคำสั่งระบบที่ซับซ้อน 500 คำ (กรณี B)
• ปัญหา: การปรับปรุงคำสั่งสำหรับกรณี B อาจทำให้กรณี A ล้มเหลวโดยไม่ตั้งใจ
• วิธีแก้ปัญหา: ใช้ Braintrust เพื่อสร้างชุดข้อมูลทองคำพร้อมกับชุดตัวอย่างที่สมบูรณ์แบบ (เช่น N = 50) ให้ Braintrust ทำการเปรียบเทียบแบบข้างต่อข้างทุกครั้งที่ทีมวิศวกรอัปเดตคำสั่ง:

• ผลลัพธ์ที่คาดหวัง: รายงานความแตกต่างที่แสดงให้เห็นว่ากรณีใดดีขึ้นหรือเลวลงสำหรับชุดข้อมูลทองคำ (N = 50)

สรุป

เมื่อจัดการด้วยเฟรมเวิร์กการประเมินที่เหมาะสม RAG สามารถเป็นเครื่องมือที่มีประสิทธิภาพในการให้บริบทที่เกี่ยวข้องมากที่สุดแก่ผู้ใช้

ยุทธวิธีการนำไปใช้: การแมปเมตริกไปสู่จุดล้มเหลว

แม้ว่าจะไม่มีวิธีแก้ปัญหาแบบ “ใช้ได้ทุกกรณี” แต่ ตาราง 2 แสดงให้เห็นว่าควรใช้เมตริกการประเมินใดบ้างสำหรับแต่ละจุดล้มเหลวที่กล่าวถึงในบทความนี้:

ตาราง 2. เมตริกซ์การบรรเทาจุดล้มเหลว – เครื่องมือใดแก้ปัญหาใด

DeepEval และ RAGAS สามารถใช้เมตริกความน่าเชื่อถือเพื่อวัดความล้มเหลวของความสมบูรณ์ของข้อมูล (FP1, FP4, FP7)

TruLens ใช้ความแม่นยำของบริบทและความถูกต้องในการวัดความเกี่ยวข้องของบริบทกับผลลัพธ์ – ประเมิน FP2 ได้อย่างมีประสิทธิภาพ

Arize Phoenix ให้การแสดงภาพของกระบวนการค้นหา ทำให้เห็นได้ง่ายว่าเอกสารที่ดึงออกมาล้มเหลวระหว่างการรวม (FP3)

สำหรับความล้มเหลวของ UX DeepEval สร้างเมตริกแบบกำหนดเองเพื่อประเมินความล้มเหลวของ UX ในขณะที่ Braintrust มีความโดดเด่นในการเปรียบเทียบชุดข้อมูลที่มีมาตรฐาน