LLM Wiki กับ RAG ต่างกันอย่างไร: ผลทดสอบจริงชี้แบบไหนดีกว่า
ผลทดสอบเปรียบเทียบระหว่าง LLM Wiki และ RAG บนไลบรารี Python ขนาด 1,176 บรรทัด เผยวิกิอาจช้าและแพงกว่า แต่ชนะเมื่อต้องตอบเรื่องที่ไม่มีในซอร์สโค้ด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- LLM Wiki คือโฟลเดอร์หน้า Markdown ที่เอเจนต์เขียนและอัปเดตพร้อมการอ้างอิง
- RAG ดึงข้อมูลจากคลังเอกสารมาใส่ในพรอมต์โดยไม่มีการเขียนกลับ
- บนโค้ดเบสขนาดเล็ก 1,200 บรรทัด การใช้ Wiki ช้ากว่าและแพงกว่าแบบไม่ใช้ Wiki
- Wiki จะได้เปรียบก็ต่อเมื่อต้องตอบคำถามเกี่ยวกับการตัดสินใจที่ไม่มีอยู่ในซอร์สโค้ด
ในแวดวงพัฒนาซอฟต์แวร์ หลายคนมักมองว่าระบบ "LLM Wiki" และ "RAG" เป็นสองวิธีในการทำงานแบบเดียวกัน แต่ในความเป็นจริงแล้วระบบทั้งสองมีความแตกต่างกันอย่างสิ้นเชิง โดยมีผู้พัฒนาได้ทำการทดลองสร้างวิกิขึ้นมาสำหรับโค้ดเบสจริง และทดสอบตั้งคำถามชุดเดียวกันทั้งแบบที่มีวิกิและไม่มีวิกิ ผลลัพธ์ที่ได้ชี้ให้เห็นว่าการไม่มีวิกิให้ผลลัพธ์ที่เร็วกว่า ประหยัดกว่า และมีความถูกต้องไม่แพ้กัน ยกเว้นในคำถามข้อที่ห้าที่คำตอบไม่เคยปรากฏอยู่ในซอร์สโค้ดต้นทางเลย ซึ่งนี่คือจุดแบ่งแยกสำคัญระหว่างสองแนวทางนี้
เพื่อให้เห็นภาพชัดเจน เรามาทำความรู้จักกับคำนิยามของแต่ละระบบ RAG หรือ Retrieval-Augmented Generation เป็นกระบวนการที่ตัวดึงข้อมูลจะค้นหาชิ้นส่วนเอกสารที่เกี่ยวข้องที่สุดจากคลังเอกสารเมื่อมีคำถามเข้ามา แล้วนำไปแปะลงในพรอมต์เพื่อให้โมเดลตอบคำถามจากชิ้นส่วนนั้น โดยคลังเอกสารจะเป็นสำเนาของแหล่งข้อมูลที่ถูกซอยย่อย และไม่มีการเขียนข้อมูลใดย้อนกลับไป ส่วนการดึงข้อมูลแบบ Agentic Retrieval คือวิธีที่เอเจนต์เขียนโค้ดใช้งานจริงในปัจจุบัน โดยไม่มีดัชนีเวกเตอร์ แต่เอเจนต์จะรันคำสั่งค้นหา เปิดไฟล์ และอ่านวนซ้ำจนกว่าจะหาคำตอบได้ ซึ่งเป็นวิธีที่เครื่องมืออย่าง Claude Code ใช้บนโค้ดเบสเปล่า
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในฝั่งของ LLM Wiki จะอยู่ในรูปแบบของโฟลเดอร์หน้าเพจ Markdown ที่เอเจนต์เขียนและดูแลรักษา โดยมีหน้าเพจสำหรับแต่ละแนวคิด การตัดสินใจ หรือโมดูล พร้อมทั้งอ้างอิงแหล่งที่มาและเชื่อมโยงกันด้วยระบบลิงก์วิกิ เมื่อเอเจนต์ไม่สามารถหาคำตอบจากหน้าเพจเหล่านี้ได้ เอเจนต์จะเข้าไปอ่านซอร์สโค้ดต้นทางแล้วเขียนสิ่งที่เรียนรู้กลับลงไป เพื่อให้คำถามถัดไปไม่ต้องกลับไปอ่านซอร์สโค้ดซ้ำอีก โดยมีการทดสอบเปรียบเทียบบนไลบรารี pallets/itsdangerous ซึ่งเป็นไลบรารีการลงนามใต้เซสชันของ Flask ที่มีโค้ด Python จำนวน 1,176 บรรทัด แบ่งเป็น 8 โมดูล, ไฟล์ CHANGES.rst 292 บรรทัด และเอกสารประกอบ 7 หน้า
การทดสอบเริ่มต้นด้วยคำถามสี่ข้อที่นักพัฒนาที่ผสานรวมไลบรารีนี้มักจะถาม โดยจำกัดให้เอเจนต์ตอบคำถามจากซอร์สโค้ดเท่านั้น ผลปรากฏว่าทั้งสี่ข้อให้คำตอบที่ถูกต้องและอ้างอิงบรรทัดที่มีอยู่จริง จากนั้นจึงดำเนินการสร้างวิกิด้วยคำสั่งเริ่มต้นและคำสั่งสร้างหน้าสถาปัตยกรรมต่อโมดูล ซึ่งการสร้างวิกิบนคอมมิตเดียวกันในเวลาที่ต่างกันเคยให้ผลลัพธ์ถึง 21 หน้า ความยาว 8,441 คำ และมีค่าใช้จ่าย 4.08 ดอลลาร์สหรัฐ สะท้อนให้เห็นว่าการสร้างวิกิไม่ได้ให้ผลลัพธ์ที่เหมือนเดิมทุกครั้ง
"RAG retrieves what was written. A wiki also records what was decided."
Vellum Labs
การวิเคราะห์เพิ่มเติมแสดงให้เห็นว่า บนโค้ดเบสขนาดเล็กประมาณ 1,200 บรรทัด ระบบวิกิทำหน้าที่เป็น RAG ที่แย่กว่าการไม่ใช้ RAG เลย เนื่องจากรอบแรกของการค้นหามีความช้ากว่าถึง 55% และมีต้นทุนแพงกว่า 34% ต่อคำถาม แม้กระทั่งหลังจากเขียนข้อมูลกลับแล้ว คำถามซ้ำก็ยังมีค่าใช้จ่ายใกล้เคียงกับการอ่านซอร์สโค้ดแบบสดๆ ทำให้จุดคุ้มทุนในการสร้างวิกิไม่เกิดขึ้นกับโค้ดเบสขนาดนี้
อย่างไรก็ตาม จุดเปลี่ยนที่สำคัญเกิดขึ้นในคำถามข้อที่ห้า ซึ่งเกี่ยวข้องกับการตัดสินใจของทีมหลังการตรวจสอบโค้ด เช่น การกำหนดให้แอปพลิเคชันเก็บคีย์ลับไว้ในรายการได้สูงสุดสามคีย์และปลดคีย์ที่เก่าที่สุดทุกๆ 30 วัน ซึ่งการตัดสินใจลักษณะนี้ไม่มีบันทึกอยู่ในซอร์สโค้ด ไฟล์ประวัติการเปลี่ยนแปลง หรือเอกสารใดๆ การมีวิกิที่สามารถบันทึกข้อตัดสินใจผ่านคำสั่งสั้นๆ จึงเป็นตัวกำหนดความแตกต่างระหว่างระบบที่สามารถตอบคำถามนี้ได้กับระบบที่ไม่สามารถตอบได้เลย
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น