การถกเถียงที่เพิ่มขึ้นเกี่ยวกับเฟรมเวิร์กสำหรับการพัฒนา Retrieval-Augmented Generation (RAG) ได้จุดประเด็นการอภิปรายอย่างกว้างขวางในชุมชนนักพัฒนา โดยผู้เชี่ยวชาญจำนวนมากสนับสนุนให้ใช้วิธีการที่เรียบง่ายโดยไม่พึ่งพาเฟรมเวิร์ก แทนที่จะใช้โซลูชันยอดนิยมอย่าง LangChain
เหตุผลที่ต่อต้านการพึ่งพาเฟรมเวิร์ก
ความคิดเห็นที่โดดเด่นจากชุมชนนักพัฒนาชี้ให้เห็นว่า แม้ LangChain จะทำให้การพัฒนา RAG เข้าถึงได้ง่ายขึ้น แต่อาจสร้างความซับซ้อนที่ไม่จำเป็นสำหรับการพัฒนาในระยะยาว นักพัฒนาจำนวนมากขึ้นสนับสนุนให้ใช้วิธีการที่เรียบง่ายและตรงไปตรงมามากกว่า โดยใช้เครื่องมือพื้นฐานอย่าง FastAPI, numpy และ redis สำหรับการพัฒนา RAG
ผมขอแนะนำอย่างยิ่งว่าไม่ควรเรียนรู้จาก LangChain มันเป็นนรกแห่งการซ้อนทับของแอบสแตรกชัน และจะทำให้คุณเสียเวลาพัฒนาไปหลายพันชั่วโมงทันทีที่คุณต้องการทำอะไรที่แตกต่างออกไป RAG จริงๆ แล้วเป็นเรื่องที่ง่ายมาก แต่มีเงินทุนจาก VC มากเกินไปในวงการนี้และมีคนที่ชอบสร้างความซับซ้อนโดยไม่จำเป็น
ชุดเครื่องมือทางเลือกที่นิยมใช้ในการพัฒนา RAG:
- FastAPI
- numpy
- redis/pgVector
- Postgres (สำหรับการขยายระบบ)
ความกังวลเกี่ยวกับความเสถียรและวุฒิภาวะของเฟรมเวิร์ก
แม้ว่านักพัฒนาบางคนจะรายงานว่า LangChain มีความเสถียรดีขึ้นในช่วงหลายเดือนที่ผ่านมา แต่ยังคงมีความกังวลเกี่ยวกับการจัดการการพึ่งพาและความซับซ้อนของแอบสแตรกชัน การพัฒนาอย่างรวดเร็วของเฟรมเวิร์กนี้ทำให้เอกสารประกอบแสดงวิธีการพัฒนาหลายรูปแบบ สร้างความสับสนเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุด อย่างไรก็ตาม ทีม LangChain กำลังแก้ไขปัญหาเหล่านี้อย่างจริงจัง โดยเฉพาะในเรื่องความขัดแย้งของเวอร์ชันแพ็คเกจ
ความท้าทายหลักในการใช้งาน RAG:
- การประมวลผลเอกสาร PDF (สารบัญ, ส่วนหัว, ส่วนท้าย)
- ความเข้าใจความหมายระหว่างภาษา
- การจัดการโครงสร้างคลังข้อมูล
- การจัดการการเปลี่ยนแปลงเวอร์ชัน
- ความขัดแย้งของการพึ่งพาระหว่างไลบรารี
ทางเลือกอื่นที่ได้รับความนิยมเพิ่มขึ้น
นักพัฒนากำลังศึกษาทางเลือกในการพัฒนามากขึ้น โดยบางคนสนับสนุนการใช้โมเดลแบบเปิดที่ทำงานในเครื่องและเฟรมเวิร์กที่เบากว่า เครื่องมืออย่าง txtai และการพัฒนาแบบกำหนดเองโดยใช้เทคโนโลยีพื้นฐานกำลังได้รับความสนใจมากขึ้นเพราะความเรียบง่ายและความยืดหยุ่น การเปลี่ยนแปลงนี้สะท้อนให้เห็นถึงการเคลื่อนไหวในวงกว้างที่มุ่งสู่โซลูชัน RAG ที่ควบคุมและบำรุงรักษาได้ดีกว่า
ความท้าทายเฉพาะในการพัฒนา RAG
นอกเหนือจากการถกเถียงเรื่องเฟรมเวิร์ก นักพัฒนากำลังเผชิญกับความท้าทายทางเทคนิคเฉพาะในการพัฒนา RAG โดยเฉพาะในการจัดการเอกสาร PDF และคลังโค้ด ปัญหาต่างๆ เช่น การคัดแยกสารบัญ การจัดการส่วนหัว/ส่วนท้าย และการรักษาเลขหน้าสำหรับการอ้างอิง ได้กลายเป็นจุดที่สร้างความปวดหัวทั่วไป นำไปสู่การพัฒนาโซลูชันต่างๆ โดยชุมชนที่ผสมผสาน OCR, โมเดลการมองเห็น และวิธีการเฉพาะที่กำหนดเอง
การอภิปรายนี้ชี้ให้เห็นถึงการตระหนักที่เพิ่มขึ้นว่า แม้เฟรมเวิร์กอย่าง LangChain จะมีประโยชน์ในการสร้างต้นแบบอย่างรวดเร็วและการเรียนรู้ แต่การพัฒนา RAG ในระดับการผลิตอาจได้ประโยชน์จากวิธีการที่เบาและปรับแต่งได้มากกว่า ซึ่งให้ความสำคัญกับความเรียบง่ายและการบำรุงรักษาได้มากกว่าการซ้อนทับของแอบสแตรกชัน
อ้างอิง: Advanced RAG Cookbooks