การเพิ่มประสิทธิภาพของ RAG คือชุดวิธีการที่ไม่ได้พึ่งพาเพียงแค่ Vector Search เท่านั้น แต่ยังรวมถึงการใช้ Full-text Search (BM25), Knowledge Graph และ Reranking เข้าด้วยกัน เพื่อลดอาการหลอน (Hallucination) และยกระดับคุณภาพของคำตอบให้ถึงระดับที่ใช้งานจริงได้ การที่ระบบตอบคำถามได้ดีในช่วง PoC แต่กลับมีความแม่นยำลดลงทันทีที่ต้องเผชิญกับปริมาณข้อมูลจริงและความหลากหลายของคำถาม เป็นอุปสรรคที่นักพัฒนา RAG แทบทุกคนต้องเจอ บทความนี้มุ่งเน้นไปที่นักพัฒนาและผู้รับผิดชอบด้าน AI ที่สร้าง RAG ในช่วงเริ่มต้นเสร็จสิ้นแล้ว โดยจะอธิบายถึงขั้นตอนการปรับปรุงในระดับการนำไปใช้งานจริง ตามลำดับคือ "การออกแบบตัวชี้วัดการประเมิน → การปรับปรุงการค้นหา → การควบคุมการสร้างคำตอบ" เพื่อให้ทราบว่าควรปรับแก้ส่วนใดและในลำดับใดจึงจะช่วยเพิ่มความแม่นยำได้จริง แทนที่จะสุ่มเพิ่มส่วนประกอบต่างๆ เข้าไป บทความนี้จะแสดงแนวทางการพัฒนาที่เน้นการตรวจสอบผลลัพธ์ด้วยตัวเลขควบคู่ไปกับการปรับปรุงอย่างเป็นระบบ

สาเหตุหลักที่ทำให้ RAG ซึ่งมีความแม่นยำสูงในระดับ PoC กลับล้มเหลวในการใช้งานจริง ไม่ใช่เพราะความฉลาดของโมเดล แต่เป็นเพราะ "ไม่สามารถดึงเอกสารที่จำเป็นสำหรับการค้นหา (Retrieval) ออกมาได้" ในส่วนนี้ เราจะมาสรุปเหตุผลเชิงโครงสร้างที่ทำให้ความแม่นยำไม่พัฒนา โดยพิจารณาจาก 2 มุมมอง ได้แก่ ขีดจำกัดของการค้นหาแบบเวกเตอร์ (Vector Search) และแหล่งที่มาของอาการประสาทหลอน (Hallucination)

การค้นหาแบบเวกเตอร์ (Vector Search) แม้จะมีความโดดเด่นในการจับความหมายเชิงบริบทของประโยค แต่ก็มักเกิดปัญหาข้อมูลตกหล่นเมื่อต้องใช้กับการค้นหาที่ต้องการความแม่นยำตรงกับคำสำคัญ (Keyword) โดยเฉพาะข้อมูลที่ "ตัวอักษรมีความสำคัญมากกว่าความหมาย" เช่น รหัสรุ่นสินค้า (Model Number), รหัสสินค้า, ชื่อบุคคล, เลขที่กฎหมาย หรือคำย่อเฉพาะภายในองค์กร ตัวอย่างเช่น เมื่อถามว่า "สเปกของรุ่น ABC-1200" เวกเตอร์ฝังตัว (Embedding Vector) อาจตัดสินว่า "ABC-1100" หรือ "สเปกของผลิตภัณฑ์ที่ใกล้เคียงกัน" มีความหมายใกล้เคียงกัน ทำให้ส่วนของข้อมูล (Chunk) ที่มีเลขรุ่นที่ถูกต้องจริงๆ ไม่ถูกจัดอยู่ในอันดับต้นๆ

อีกหนึ่งกับดักคือกรณีที่คำศัพท์ระหว่างคำถามกับเอกสารไม่ตรงกัน หากผู้ใช้พิมพ์คำว่า "เงินชดเชยการลาออก" (เงินเกษียณ) แต่ในระเบียบของบริษัทใช้คำว่า "ผลประโยชน์หลังเกษียณ" (ผลประโยชน์เมื่อออกจากงาน) แม้ความหมายจะเหมือนกันแต่หากเขียนต่างกัน คะแนนของโมเดลฝังตัวอาจไม่สูงขึ้น ทั้งนี้ขึ้นอยู่กับข้อมูลที่ใช้ฝึกสอนโมเดล ความไม่สอดคล้องกันของคำศัพท์ (Lexical gap) เหล่านี้สามารถแก้ไขได้ดีขึ้นด้วยการใช้การค้นหาแบบเต็มรูปแบบ (Full-text search) เช่น BM25 ซึ่งจะกล่าวถึงต่อไป การค้นหาเชิงความหมาย (Semantic search) และการค้นหาด้วยคำสำคัญ (Keyword search) ไม่ได้มีวิธีใดเหนือกว่าอีกวิธีหนึ่ง แต่เป็นความสัมพันธ์แบบเติมเต็มซึ่งกันและกันเนื่องจากมีจุดอ่อนในการเก็บข้อมูลที่แตกต่างกัน นี่คือมุมมองเชิงปฏิบัติที่ควรนำไปใช้

ใน RAG นั้น ปัญหาฮัลลูซิเนชัน (Hallucination - การสร้างข้อมูลที่ไม่เป็นความจริง) มักมีสาเหตุมาจากขั้นตอนก่อนหน้ามากกว่า "ระดับความขี้โกง" ของตัวโมเดลสร้างข้อความเอง หากแบ่งแยกปัญหาตามหน้างานจริง มักจะสรุปได้เป็น 3 ประเด็นหลักดังนี้

ประการแรกคือ กรณีที่การค้นหาล้มเหลว หากเอกสารที่เป็นหลักฐานในการตอบไม่ได้ถูกรวมอยู่ในผลลัพธ์การค้นหาตั้งแต่แรก โมเดลจะพยายามใช้ความรู้จากการเรียนรู้ล่วงหน้า (Pre-training) มาเติมเต็มช่องว่างนั้น ทำให้เกิดข้อมูลที่ผิดพลาดแต่ดูน่าเชื่อถือ ประการที่สองคือ กรณีที่ค้นหาได้แต่บริบทไม่เพียงพอ หาก Chunk มีขนาดเล็กเกินไปจนทำให้บริบทก่อนหน้าและถัดไปขาดหายไป หรือมีการส่งข้อมูลเพียงบางส่วนของตารางให้โมเดล โมเดลจะพยายามคาดเดาข้อมูลที่ขาดหายไปเพื่อเติมให้เต็ม ประการที่สามคือ การควบคุม Prompt ไม่เพียงพอ หากคำสั่งเรื่อง Grounding เช่น "หากไม่มีข้อมูลในผลลัพธ์การค้นหา ให้ตอบว่า 'ไม่ทราบ'" มีความอ่อนเกินไป โมเดลก็จะสร้างคำตอบขึ้นมาเองแม้จะไม่มีหลักฐานรองรับก็ตาม

สิ่งสำคัญคือ ทั้ง 3 กรณีนี้มีวิธีแก้ไขที่แตกต่างกันโดยสิ้นเชิง หากเป็นปัญหาการค้นหาล้มเหลวต้องใช้ Hybrid Search หรือ Reranking หากเป็นปัญหาบริบทไม่เพียงพอต้องปรับปรุงการออกแบบ Chunk และหากเป็นปัญหาการควบคุมไม่เพียงพอต้องปรับปรุง Prompt และข้อจำกัดของผลลัพธ์ หากไม่แยกแยะปัญหาเหล่านี้ก่อนลงมือแก้ไข เราก็จะเสียเวลาไปกับการปรับปรุงที่ไม่ตรงจุด การไม่เหมารวมว่า "ฮัลลูซิเนชันเยอะ" แต่จำแนกสาเหตุให้ชัดเจน คือจุดเริ่มต้นของการปรับปรุงที่มีประสิทธิภาพ

ก้าวแรกของการปรับปรุงความแม่นยำไม่ใช่การปรับปรุงการค้นหา (Search) หรือการสร้างเนื้อหา (Generation) แต่คือ "การทำให้วัดผลได้" หากไม่สามารถติดตามเป็นตัวเลขได้ว่าการแก้ไขสิ่งใดส่งผลให้ดีขึ้นมากน้อยเพียงใด การปรับปรุงก็จะกลายเป็นการพึ่งพาสัญชาตญาณ ในส่วนนี้จะอธิบายถึงการออกแบบตัวชี้วัด (Evaluation Metrics) โดยคำนึงถึงการใช้งานจริง และวิธีการผสมผสานระหว่างการประเมินอัตโนมัติ (Automated Evaluation) และการประเมินเชิงคุณภาพ (Qualitative Evaluation)

ในการประเมิน RAG เป็นหลักการทั่วไปที่จะต้องแยกวัดผลระหว่างการสร้างคำตอบ (Generation) และการสืบค้นข้อมูล (Retrieval) โดยมีตัวชี้วัดหลัก 3 ประการ ซึ่งแต่ละตัวจะช่วยตรวจจับปัญหาที่แตกต่างกัน ดังนี้:

Faithfulness แสดงถึงสัดส่วนที่ข้อความในคำตอบได้รับการสนับสนุนจากบริบทที่สืบค้นมาได้ หากค่านี้ต่ำ แสดงว่าเป็นสัญญาณว่าโมเดลกำลังพูดโดยไม่มีหลักฐานอ้างอิง Answer Relevancy วัดว่าคำตอบตรงประเด็นกับคำถามมากน้อยเพียงใด แม้บริบทจะถูกต้อง แต่หากคำตอบเยิ่นเย้อหรือคลุมเครือ ค่านี้ก็จะลดลง Context Recall แสดงถึงปริมาณข้อมูลที่จำเป็นต่อคำตอบที่สามารถดึงมาได้ในขั้นตอนการสืบค้น ซึ่งสะท้อนถึงคุณภาพของฝั่ง Retrieval โดยตรง

การแยกดูตัวชี้วัดทั้ง 3 ประการนี้ จะช่วยให้สามารถแยกแยะได้ว่า "ปัญหาอยู่ที่การสร้างคำตอบหรือการสืบค้นข้อมูลกันแน่" หาก Faithfulness สูงแต่ Context Recall ต่ำ ก็สามารถสรุปได้ว่าจุดที่ต้องปรับปรุงคือฝั่งการสืบค้น ไม่ใช่ฝั่งการสร้างคำตอบ การไม่รวบตัวชี้วัดให้เป็นคะแนนรวมเพียงค่าเดียว แต่แยกวิเคราะห์ตามสาเหตุของปัญหาถือเป็นสิ่งสำคัญอย่างยิ่ง

การให้คะแนนตามตัวชี้วัดข้างต้นด้วยมือทุกครั้งนั้นไม่ใช่เรื่องที่ทำได้จริง ดังนั้นจึงมีการใช้เฟรมเวิร์กการประเมินผลอัตโนมัติอย่างเช่น RAGAS เข้ามาช่วย โดยเฟรมเวิร์กเหล่านี้จะรับอินพุตเป็นคำถาม บริบทที่สืบค้นได้ และคำตอบที่สร้างขึ้น (รวมถึงคำตอบที่ถูกต้องหากจำเป็น) จากนั้นจะใช้ LLM ทำหน้าที่เป็นผู้ให้คะแนน (LLM-as-a-judge) เพื่อคำนวณคะแนนของแต่ละตัวชี้วัด

จุดเริ่มต้นที่มีประสิทธิภาพในการดำเนินงานคือการสร้าง ชุดข้อมูลสำหรับการประเมินผล (Golden Set) โดยรวบรวมคำถามที่คาดว่าจะพบในการใช้งานจริงประมาณ 50-100 ข้อ โดยให้ผสมคำถามที่เป็นตัวแทนทั่วไป คำถามที่เป็นกรณีขอบเขต (Edge cases) และคำถามที่เคยตอบไม่ได้ในอดีตเข้าไว้ด้วยกัน หากคุณเก็บคะแนนด้วยชุดข้อมูลนี้ทุกครั้งที่มีการเปลี่ยนวิธีการสืบค้นหรือขนาดของ Chunk คุณจะสามารถตัดสินได้เชิงปริมาณว่าการเปลี่ยนแปลงนั้นเป็นการปรับปรุงหรือทำให้แย่ลง

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

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

แนวทางที่ใช้งานได้จริงคือการดำเนินงานแบบรายสัปดาห์ โดยสุ่มตัวอย่างจากบันทึกการใช้งานจริง (Actual Usage Logs) จำนวนหลายสิบรายการ เพื่อให้ผู้รับผิดชอบทำการรีวิวว่าดีหรือไม่ดี ในการนี้ แทนที่จะเพียงแค่ทำเครื่องหมายถูกหรือผิด ควรจำแนกคำตอบที่ไม่ดีว่าเกิดจาก "การค้นหาที่แย่" "การสร้างคำตอบที่แย่" หรือ "ตัวคำถามเองที่กำกวม" เพื่อให้เห็นเป้าหมายในการปรับปรุงครั้งต่อไปได้อย่างชัดเจน

อีกวิธีที่มีประสิทธิภาพคือการสะสมผลตอบรับจากผู้ใช้ (ปุ่ม 👍/👎 หรือการเขียนข้อความอิสระ) และนำคำถามที่ได้รับปุ่ม 👎 เข้าสู่ชุดข้อมูลการประเมิน (Evaluation Dataset) เป็นลำดับแรก การใช้กลยุทธ์สองทางนี้ คือการเฝ้าติดตามแนวโน้มโดยรวมด้วยตัวชี้วัดเชิงปริมาณ และเจาะลึกความผิดพลาดเฉพาะจุดด้วยการประเมินเชิงคุณภาพ จะช่วยหลีกเลี่ยงสถานการณ์ที่ไล่ตามแต่คะแนนจนละเลยความรู้สึกจริงของผู้ใช้งานหน้างาน เราควรคิดว่าการประเมินไม่ใช่สิ่งที่ทำครั้งเดียวจบ แต่เป็นสินทรัพย์ที่ต้องคอยเรียนรู้จากกรณีความล้มเหลวเพื่อพัฒนาให้ดียิ่งขึ้นไป

ไฮบริดเสิร์ช (Hybrid Search) คือวิธีการที่ใช้การค้นหาด้วยคำหลัก (Keyword Search - BM25) ร่วมกับการค้นหาด้วยเวกเตอร์ (Vector Search) แล้วนำคะแนนจากทั้งสองวิธีมารวมกันเพื่อตัดสินผลลัพธ์การค้นหา สำหรับ RAG ส่วนใหญ่แล้ว นี่เป็นวิธีที่คุ้มค่าที่สุดในการยกระดับความแม่นยำของการค้นหา ในที่นี้จะกล่าวถึงกลไกการรวมคะแนน รวมถึงประเด็นสำคัญในการนำไปใช้งานจริง เช่น การออกแบบ Chunk และการรองรับหลายภาษา

BM25 (การค้นหาFull-textแบบดั้งเดิมที่อิงการตรงกันของ Keyword) และ Vector Search มีมาตรวัดคะแนนที่แตกต่างกันอย่างมาก คะแนนของ BM25 ไม่มีเพดานเชิงทฤษฎี ขณะที่ Cosine similarity ของ Vector Search มักอยู่ใกล้ช่วง 0-1 หากนำคะแนนดิบของทั้งสองมาบวกกันตรงๆ ผลลัพธ์จะถูกดึงไปตาม Scale ของฝั่งหนึ่งจนหมดความหมาย

วิธีที่ใช้กันแพร่หลายคือ RRF (Reciprocal Rank Fusion) RRF ทิ้งค่าสัมบูรณ์ของคะแนน แล้วใช้เพียง "อันดับ" ของผลลัพธ์ในแต่ละวิธีค้นหา โดยคำนวณ 1 / (k + อันดับ) สำหรับเอกสารแต่ละรายการในแต่ละวิธี แล้วรวมคะแนนเพื่อจัดอันดับสุดท้าย ค่า k เป็นค่าคงที่ที่ลดอิทธิพลของอันดับบนๆ และมักใช้ประมาณ 60

RRF มี Parameter น้อย และทำงานได้ค่อนข้างเสถียรไม่ว่าข้อมูลจะเหมาะกับ BM25 หรือ Vector Search มากกว่า จึงเหมาะเป็นวิธีรวมผลลัพธ์แรก เริ่มจาก RRF เป็นฐาน แล้วค่อยเพิ่ม Weighting หรือ Reranking หาก Dataset ประเมินผลชี้ว่ายังไม่พอ นี่คือลำดับที่มั่นคงกว่า

ขีดจำกัดของการค้นหาถูกกำหนดโดยการออกแบบ Chunk (หน่วยที่แบ่งจากเอกสาร) หาก Chunk ใหญ่เกินไป ข้อมูลที่ไม่เกี่ยวข้องจะปะปนเข้ามาจนกลายเป็นสัญญาณรบกวน (Noise) แต่หากเล็กเกินไป บริบทจะขาดหายไปจนทำให้ไม่สามารถสื่อความหมายได้ แม้จะไม่มีตัวเลขที่เป็นสูตรสำเร็จ แต่จุดเริ่มต้นที่เหมาะสมในทางปฏิบัติคือการตั้งค่าไว้ที่ ประมาณ 300–800 โทเค็นต่อ 1 Chunk แล้วจึงค่อยปรับจูนด้วยชุดข้อมูลประเมินผล (Evaluation Dataset)

การกำหนดให้ Chunk ที่อยู่ติดกันมีความซ้อนทับ (Overlap) กัน จะช่วยบรรเทาปัญหาข้อมูลถูกตัดขาดบริเวณรอยต่อของประโยคหรือย่อหน้าได้ โดยมีเกณฑ์อยู่ที่ประมาณ 10–20% อย่างไรก็ตาม ยิ่งเพิ่มความซ้อนทับมากเท่าใด ดัชนี (Index) ก็จะยิ่งบวมขึ้น และผลการค้นหาจะมีความซ้ำซ้อนเนื่องจากเนื้อหาเดียวกันถูกค้นพบหลายครั้ง จึงควรหลีกเลี่ยงการเพิ่มค่านี้โดยไม่จำเป็น

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

เมื่อเปรียบเทียบกับภาษาญี่ปุ่นหรือภาษาอังกฤษ ภาษาที่มีทรัพยากรจำกัด (low-resource languages) อย่างภาษาลาวหรือภาษาไทย มักมีข้อควรระวังบางประการที่ทำให้ความแม่นยำของ RAG ลดลง ประการแรกคือ การทำ Tokenization และการตัดคำ เนื่องจากภาษาไทยและภาษาลาวไม่มีการเว้นวรรคระหว่างคำ หากตัดคำผิดพลาด หน่วยในการสืบค้นจะเสียหาย ทำให้การจับคู่คำสำคัญ (keyword matching) ของ BM25 ทำงานได้ยาก ผลลัพธ์จะแตกต่างกันอย่างมาก ขึ้นอยู่กับว่ามีการใส่กระบวนการตัดคำที่รองรับภาษานั้นๆ ไว้ในขั้นตอนก่อนหน้าหรือไม่

ประการที่สองคือ ความครอบคลุมทางภาษาของ Embedding Model แม้ว่า Embedding Model จะระบุว่ารองรับหลายภาษา แต่สัดส่วนของภาษาในเอเชียตะวันออกเฉียงใต้ในข้อมูลที่ใช้ฝึกฝน (training data) มักมีน้อย ทำให้ความแม่นยำในการสืบค้นเชิงความหมาย (semantic search) อาจไม่ดีเท่าภาษาหลัก ดังนั้นก่อนนำไปใช้งานจริง จำเป็นต้องตรวจสอบคุณภาพการสืบค้นด้วยข้อมูลจริงของภาษานั้นๆ เสมอ

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

Graph RAG คือวิธีการที่ไม่ได้เพียงแค่แปลงเอกสารเป็นเวกเตอร์เท่านั้น แต่ยังเก็บข้อมูลเอนทิตี (เช่น บุคคล องค์กร ผลิตภัณฑ์) และความสัมพันธ์ระหว่างเอนทิตีเหล่านั้นไว้ในรูปแบบ Knowledge Graph เพื่อนำมาใช้ประกอบการสร้างคำตอบโดยการสืบค้นผ่านความสัมพันธ์ดังกล่าว แม้จะมีจุดเด่นในด้านการตอบคำถามที่ครอบคลุมหลายเอกสาร แต่ก็มีต้นทุนในการนำไปใช้งานที่สูง ในบทความนี้จะสรุปว่าในกรณีใดบ้างที่การลงทุนนี้จะคุ้มค่า

RAG ทั่วไปจะดึงข้อมูลแบบ Chunk ที่ใกล้เคียงกับคำถามมาทีละส่วน ด้วยเหตุนี้จึงมีจุดอ่อนใน "คำถามที่ไม่สามารถตอบได้หากไม่เชื่อมโยงความสัมพันธ์ข้ามเอกสารหลายฉบับ" ตัวอย่างเช่น คำถามที่ว่า "แผนกที่เกี่ยวข้องกับข้อบกพร่องของผลิตภัณฑ์ A และกรณีศึกษาที่คล้ายคลึงกันที่แผนกนั้นเคยจัดการในอดีตคืออะไร" จำเป็นต้องไล่เรียงความสัมพันธ์ของหลาย Entity ทั้งผลิตภัณฑ์, ข้อบกพร่อง, แผนก และกรณีศึกษา ซึ่งการค้นหาด้วยค่าความคล้ายคลึง (Similarity Search) แบบธรรมดาจะรวบรวมได้เพียงข้อมูลที่กระจัดกระจายเท่านั้น

Graph RAG จะสกัด Entity และความสัมพันธ์จากเอกสารเพื่อสร้าง Knowledge Graph และเมื่อทำการค้นหา ระบบจะไล่เรียงไปตามกราฟนั้น ทำให้สามารถรวบรวมข้อมูลที่กระจัดกระจายตามความสัมพันธ์ออกมาได้ ผลลัพธ์คือคุณภาพของคำตอบสำหรับคำถามเชิงกว้างหรือเชิงภาพรวม เช่น "จงสรุปภาพรวมทั้งหมด" หรือ "จงอธิบายความเกี่ยวข้องระหว่าง A และ B" มักจะสูงขึ้น

ในทางกลับกัน สำหรับคำถามประเภทตรวจสอบข้อเท็จจริงที่จบในเอกสารเดียว (เช่น "วันหมดอายุของระเบียบนี้คือเมื่อใด") ประโยชน์ของการทำเป็นกราฟจะมีน้อย ควรจำไว้ว่า "ความจำเป็นในการไล่เรียงความสัมพันธ์" คือจุดตัดสินว่า Graph RAG จะมีประสิทธิภาพหรือไม่

ข้อเสียของ Graph RAG คือเรื่องของต้นทุน เนื่องจากจำเป็นต้องมีขั้นตอนเพิ่มเติมในการดึงข้อมูลเอนทิตี (Entity) และความสัมพันธ์ออกจากเอกสาร (ซึ่งส่วนใหญ่ดำเนินการโดย LLM) ทำให้ต้นทุนในการดึงข้อมูลและเวลาในการสร้างกราฟเพิ่มขึ้นตามปริมาณของเอกสาร นอกจากนี้ การออกแบบสคีมา (Schema) ของกราฟและขั้นตอนการสร้างกราฟใหม่เมื่อมีการอัปเดตเอกสารยังเป็นภาระในการดำเนินงานอีกด้วย

ด้วยเหตุนี้ การกระโดดเข้าหา Graph RAG ตั้งแต่เริ่มต้นจึงมักไม่ใช่ทางเลือกที่ดีที่สุด ในแง่ของความคุ้มค่า ลำดับที่เป็นจริงมากกว่าคือการวางรากฐานด้วย Hybrid Search และ Reranking ก่อน และเมื่อถึงจุดที่ความแม่นยำเริ่มคงที่สำหรับ "คำถามที่ต้องอาศัยการสืบค้นความสัมพันธ์" จึงค่อยพิจารณาใช้ Graph RAG ในขอบเขตที่จำกัด

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

ในหน้างานที่ความแม่นยำของ RAG ไม่พัฒนาขึ้น มักจะมี "ขั้นตอนที่มักถูกละเลย" ที่เหมือนกันอยู่ ในที่นี้จะขอกล่าวถึงความผิดพลาดที่พบบ่อย 2 ประการ ได้แก่ การละเว้นการทำ Reranking และการปล่อยให้ Index ล้าสมัย พร้อมทั้งนำเสนอสาเหตุและแนวทางแก้ไขควบคู่กันไป

แม้จะมีการนำ Hybrid Search มาใช้แล้ว แต่ความแม่นยำกลับไม่เพิ่มขึ้น สาเหตุส่วนใหญ่มักมาจากการละเลยขั้นตอนการทำ Reranking (การจัดลำดับใหม่) หน้าที่ของ BM25 หรือ Vector Search คือการรวบรวม "รายการที่น่าจะเป็น" (candidates) อย่างรวดเร็ว ซึ่งไม่ได้การันตีว่าเอกสารที่เกี่ยวข้องจริงๆ จะอยู่ในลำดับต้นๆ เสมอไป

Reranking คือกระบวนการนำรายการที่น่าจะเป็นประมาณ 20-50 อันดับแรกที่รวบรวมมาได้จากการค้นหา มาให้คะแนนใหม่อีกครั้งด้วยโมเดลที่มีความละเอียดสูงกว่า (เช่น Cross-Encoder ที่ประเมินคำถามและเอกสารเป็นคู่) เพื่อดันเอกสารที่เกี่ยวข้องจริงๆ ขึ้นมาอยู่ในลำดับต้นๆ หากการค้นหาขั้นแรกคือการทำแบบ "กว้างและเร็ว" การทำ Reranking ก็คือการทำแบบ "แคบและแม่นยำ" การใช้โครงสร้างสองขั้นตอนเช่นนี้จะช่วยเพิ่มคุณภาพของบริบทที่จะนำไปใช้ในการสร้างคำตอบ (Generation) ได้อย่างมาก

สิ่งที่มักพบเห็นได้บ่อยคือการนำผลลัพธ์ 5 อันดับแรกจากการค้นหาไปใช้ในการสร้างคำตอบทันที ซึ่งอาจทำให้พลาดข้อมูลสำคัญไป ทั้งที่หากดึงมา 20 อันดับแรกอาจมีคำตอบที่ถูกต้องรวมอยู่ด้วย แต่กลับถูกคัดออกเพราะไม่ได้ทำ Reranking วิธีแก้ไขนั้นเรียบง่าย คือ ให้ดึงรายการที่น่าจะเป็นออกมาให้มาก (เน้น Recall) แล้วใช้ Reranking เพื่อรับประกันความแม่นยำ (เน้น Precision) ก่อนจะส่งต่อไปยังขั้นตอนการสร้างคำตอบ แม้จะทำให้ต้นทุนการคำนวณเพิ่มขึ้น แต่เนื่องจากเป็นขั้นตอนที่มีผลต่อความแม่นยำอย่างมาก จึงควรหลีกเลี่ยงการตัดขั้นตอนนี้ออก เว้นแต่จะเป็นทางเลือกสุดท้ายเท่านั้น

ปัญหาด้านความแม่นยำไม่ได้เกิดจากอัลกอริทึมการค้นหาเท่านั้น แต่ยังเกิดจากความสดใหม่ของข้อมูลด้วย หากเอกสารต้นฉบับมีการอัปเดตแต่ดัชนี (Index) ไม่ได้ปรับตาม RAG ก็จะตอบ "ข้อมูลเก่า" ออกมาอย่างมั่นใจ ซึ่งถือเป็นความผิดพลาดที่สร้างความเสียหายได้มาก โดยเฉพาะเมื่อต้องจัดการกับข้อมูลที่มีการเปลี่ยนแปลงอยู่เสมอ เช่น ราคา, ข้อมูลจำเพาะ, กฎระเบียบ หรือสต็อกสินค้า

วิธีแก้ไขคือการออกแบบไปป์ไลน์การอัปเดต (Update Pipeline) ให้เหมาะสมกับลักษณะของเอกสาร สำหรับข้อมูลที่มีความถี่ในการอัปเดตสูง ควรเตรียมกลไกที่ตรวจจับการเปลี่ยนแปลงและทำการ Re-index เฉพาะส่วนที่แก้ไข (Differential Update) เนื่องจากการสร้างดัชนีใหม่ทั้งหมดทุกครั้งมีต้นทุนสูงและมักเป็นสาเหตุที่ทำให้การอัปเดตล่าช้า

นอกจากนี้ ควรนำแนวทางปฏิบัติในการระบุแหล่งที่มา (ชื่อเอกสารต้นฉบับและวันที่อัปเดต) แนบไปกับคำตอบ เพื่อให้ผู้ใช้งานสามารถประเมินความสดใหม่ของข้อมูลได้ด้วยตนเอง ซึ่งจะช่วยลดความเสี่ยงจากการหลงเชื่อข้อมูลที่ล้าสมัย โครงสร้างที่ไม่สามารถระบุได้ว่า "เป็นข้อมูล ณ ช่วงเวลาใด" ถือว่ามีความเสี่ยงสูงในการใช้งานจริง ดังนั้น ควรให้ความสำคัญกับความสดใหม่ของดัชนีในฐานะปัจจัยที่ส่งผลต่อความน่าเชื่อถือในการดำเนินงาน ไม่น้อยไปกว่าอัลกอริทึมการค้นหา

สำหรับนักพัฒนาและผู้ดูแลด้าน AI ที่กำลังมุ่งเน้นการปรับปรุงความแม่นยำของ RAG ต่อไปนี้คือแนวทางในการตัดสินใจสำหรับ 2 คำถามที่มักได้รับคำปรึกษาบ่อยที่สุด

สรุปสั้นๆ คือ ในหลายกรณีควรลองปรับปรุง RAG ก่อน การทำ Fine-tuning (วิธีการเรียนรู้เพิ่มเติมให้กับตัวโมเดลเอง) นั้นมีประสิทธิภาพในการปรับ "พฤติกรรม" เช่น การกำหนดสไตล์การเขียน รูปแบบ หรือการจัดการคำศัพท์เฉพาะทาง แต่ไม่เหมาะสำหรับการแก้ปัญหา "การตอบข้อเท็จจริงล่าสุดให้ถูกต้อง" เนื่องจากความสดใหม่ของข้อมูลและการอ้างอิงแหล่งที่มาเป็นบทบาทของฝั่ง RAG

ควรเริ่มจากการจัดเตรียมตัวชี้วัด (Evaluation Metrics) และยกระดับคุณภาพการค้นหาด้วย Hybrid Search, Reranking และการออกแบบ Chunk หากยังคงมีปัญหาเรื่องโทนเสียงหรือรูปแบบของคำตอบค่อยพิจารณาทำ Fine-tuning ตามลำดับ ซึ่งเป็นลำดับที่ให้ความสมดุลระหว่างต้นทุนและผลลัพธ์ได้ดีที่สุด ทั้งสองวิธีนี้ไม่ใช่คู่แข่งกัน แต่ควรเข้าใจว่าเป็นวิธีการที่เสริมกันโดยแก้ปัญหาคนละส่วนกัน

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

หากจะกล่าวถึงความแตกต่างระหว่างโมเดล จะพบว่าแต่ละโมเดลมีจุดเด่นในด้านความซื่อตรงต่อคำสั่ง (เช่น การปฏิบัติตามเงื่อนไข "หากไม่มีในผลลัพธ์การค้นหา ไม่ต้องตอบ" ได้ดีเพียงใด) การจัดการบริบทที่ยาว และความเสถียรของผลลัพธ์ ในการทำงานจริง วิธีที่แน่นอนที่สุดคือการเปรียบเทียบหลายโมเดลภายใต้เงื่อนไขเดียวกันโดยใช้ชุดข้อมูลประเมินผล (Evaluation Dataset) ของคุณเอง แล้วเลือกจากคะแนน Faithfulness และความเกี่ยวข้องของคำตอบ (Answer Relevance) การคงโมเดลไว้แล้วมุ่งเน้นไปที่การปรับปรุงการค้นหาจะให้ความคุ้มค่าในการลงทุนเพื่อเพิ่มความแม่นยำได้มากกว่า ทั้งนี้ เนื่องจาก Generative Model มีการอัปเดตที่รวดเร็ว จึงขอแนะนำให้ตรวจสอบเวอร์ชันล่าสุด ณ เวลาที่ทำการคัดเลือกอีกครั้ง

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

• เริ่มจากการวัดผล：สร้างชุดข้อมูลประเมินผลโดยยึดหลัก Faithfulness, Answer Relevancy และ Context Recall เพื่อแยกแยะว่าจุดอ่อนอยู่ที่ขั้นตอนการค้นหา (Retrieval) หรือการสร้างคำตอบ (Generation)
• จากนั้นปรับปรุงการค้นหา：ยกระดับคุณภาพของบริบทที่ส่งไปยังขั้นตอนการสร้างด้วย Hybrid Search (BM25 + Vector, ผสานด้วย RRF) และการทำ Reranking นอกจากนี้ การออกแบบ Chunk และความสดใหม่ของ Index ก็ถือเป็นส่วนหนึ่งของคุณภาพการค้นหาเช่นกัน
• จัดโครงสร้างหากจำเป็น：หากมีคำถามที่ต้องอาศัยการสืบค้นความสัมพันธ์จำนวนมาก ให้พิจารณาใช้ Graph RAG แต่ควรตัดสินใจหลังจากทำ PoC ขนาดเล็กเพื่อตรวจสอบความคุ้มค่าก่อน
• สุดท้ายควบคุมการสร้างคำตอบ：ใช้คำสั่ง Grounding และการอ้างอิงแหล่งที่มาเพื่อลดการตอบคำถามที่ไม่มีหลักฐานรองรับ

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