เข้าใจ RAG ในแบบโปรดักชันก่อนลงมือ
RAG หรือ Retrieval Augmented Generation คือสถาปัตยกรรมที่นำการเรียกข้อมูล AI จากแหล่งภายนอกมาผสานกับการสร้างข้อความของโมเดลภาษา ทำให้ระบบตอบคำถามสามารถอ้างอิงเอกสารภายใน ฐานความรู้ หรือข้อมูลอัปเดตล่าสุดได้ ลดโอกาสหลงประเด็นและช่วยจัดการบริบทให้ตรงกับคำถาม โดยออกแบบให้แบ่งกระบวนการเป็นเส้นทาง ingest เอกสารและเส้นทางตอบคำถามที่ทำงานร่วมกันอย่างมีแบบแผน เพื่อให้ได้ RAG ระบบการสอบถามที่ใช้งานได้จริงในโปรดักชัน
สำหรับคนที่กำลังจะสร้างระบบถามตอบบนเอกสารบริษัท หากคุณเคยทำเดโม RAG แล้วพบว่าคำตอบไม่นิ่ง หลงเอกสาร หรือค่าใช้จ่ายโทเคนพุ่งโดยไม่รู้ต้นเหตุ บทความนี้จะเดินไปพร้อมคุณแบบเพื่อนร่วมทีม จุดสำคัญคืออย่าคิดว่าแค่ต่อ LLM เข้ากับเวกเตอร์ดาต้าเบสแล้วทุกอย่างจะดี เพราะประสบการณ์จริงแสดงให้เห็นว่าการเชื่อมต่อทำได้เร็ว แต่การทำให้ AI ความเชื่อถือได้ต้องจัดระเบียบการจัดการบริบท การจัดอันดับข้อมูล และกลไกตรวจสอบผลลัพธ์ในทุกขั้นของพายป์ไลน์
ก่อนลงมือ คุณควรมีอย่างน้อยสองพายป์ไลน์คือพายป์ไลน์จัดการเอกสารและพายป์ไลน์ตอบคำถามที่แยกจากกันชัดเจน เพื่อให้ดูแล ปรับปรุง หรือวัดผลแต่ละส่วนได้ง่ายขึ้น และในระดับแพลตฟอร์มสามารถเตรียมสภาพแวดล้อมให้ทีมพัฒนาเริ่มใช้ได้ทันทีผ่านตัวอย่างโค้ดที่ต่อกับหน่วยความจำ ระบบติดตาม และเลเยอร์จัดการบริบทโดยที่ตัวเอเจนต์ไม่ต้องรู้รายละเอียดภายใน การตั้งต้นแบบนี้คือข้อแม้สำคัญก่อนจะคาดหวังว่าระบบจะโตไปเป็นโปรดักชันอย่างมั่นคง
ออกแบบพายป์ไลน์ RAG ให้ดึงข้อมูลถูกต้อง
หัวใจของ RAG ระบบการสอบถามคือการแยกเส้นทาง ingest เอกสารและเส้นทางตอบคำถามชัดเจน ด้านเอกสาร คุณต้องเปลี่ยนไฟล์ดิบทุกแบบให้กลายเป็นชิ้นข้อมูลที่ค้นหาเชิงความหมายได้ ส่วนด้านคำถาม คุณต้องแน่ใจว่าระบบดึงชิ้นข้อมูลที่เกี่ยวข้องที่สุดไปประกอบบริบทก่อนส่งเข้าโมเดล หากส่วนใดสักส่วนทำงานพลาด โมเดลจะเริ่มจากข้อมูลผิด และต่อให้ prompt ดีแค่ไหน ผลลัพธ์ก็จะหลงทิศทาง
- สร้างพายป์ไลน์ ingest เอกสาร โดยรับ Documents ทำ Text Extraction แยกเป็น Chunking สร้าง Embeddings แล้วเก็บลง Vector Database
- สร้างพายป์ไลน์ตอบคำถาม โดยรับ User Question ทำ Query Embedding เรียก Similarity Search เลือก Top K Chunks แล้วประกอบเป็น Prompt พร้อม Context ส่งเข้า LLM เพื่อสร้างคำตอบ
- กำหนดให้เลเยอร์จัดการบริบทอยู่ชั้นใต้เอเจนต์ ให้เอเจนต์ตัดสินใจว่าจะทำอะไร ส่วนเลเยอร์ตัดสินใจว่าจะให้เห็นข้อมูลโลกมากแค่ไหน เพื่อให้เปลี่ยนกลยุทธ์บริบทได้ด้วยการอัปเดตเวอร์ชันแทนการเขียนใหม่ทั้งระบบ
- ติดตั้งระบบ tracing และ evaluation ตั้งแต่เริ่ม เพื่อให้ทุกคำถามมีข้อมูลเทเลเมทรีโทเคนและคุณภาพ ทำให้วิเคราะห์และปรับระบบเชิงหลักฐานแทนการเดา
- แยกอินเทอร์เฟซจัดการบริบทให้ต่อกับเอเจนต์โดยที่เอเจนต์ไม่ต้องรู้รายละเอียดภายใน ให้ทีมเปิดใช้ผ่านการตั้งค่ามากกว่าการเขียนโค้ดใหม่ ลดภาระแก้ไขเมื่อมีการปรับเลเยอร์บริบท
จุดหลอกตาที่พบบ่อยคือคิดว่าพอระบบสร้าง embedding และทำเวกเตอร์เสิร์ชได้ เท่ากับงานจบ ทั้งที่ความท้าทายใหญ่คือทำให้โมเดลได้รับข้อมูลที่ถูกและพอเพียงในเวลาที่เหมาะสม นอกจากนี้การปล่อยให้แต่ละทีมจัดการบริบทเอง เช่น ตัดประวัติ สนใจผลเครื่องมือ หรือเลือกสคีมาที่จะส่ง เป็นทางออกที่ดูง่ายแต่จะพังในภาพรวม เพราะทุกทีมแก้ต่างกันไปและไม่มีจุดกลางให้เปลี่ยนกลยุทธ์พร้อมกัน การดันเลเยอร์บริบทลงสู่ระดับแพลตฟอร์มจึงเป็นทั้งทางสร้างความเสถียรและลดงานดูแลระยะยาว
จัดการ chunking การเรียกข้อมูล และบริบทให้ลดหลงประเด็น
เมื่อพายป์ไลน์พื้นฐานพร้อม เรื่องต่อมาที่แยกเดโมออกจากโปรดักชันคือกลยุทธ์ chunking และการจัดการบริบทที่ดี เอกสารส่วนใหญ่ไม่ได้เขียนให้เหมาะกับการค้นหาเชิงความหมาย คุณจึงต้องตัดแบ่งเนื้อหาเป็นชิ้นเล็กพอจะค้น แต่ใหญ่พอมีบริบท ซึ่งไม่มีขนาดเดียวใช้ได้ทุกชุดข้อมูล กลยุทธ์ chunking ที่ดีต้องคำนึงถึงโครงสร้างเอกสาร ประเภทคำถาม ความยาวเนื้อหา รูปแบบ และโมเดลค้นหาที่ใช้คู่กัน
เมื่อดึงชิ้นข้อมูลมาแล้ว ต้องมีขั้นตอนจัดอันดับและกรองซ้ำก่อนใส่เข้า context เลเยอร์บริบทสามารถใช้การ reranking ให้คะแนนความเกี่ยวข้องของแต่ละชิ้นกับขั้นงานปัจจุบันแทนที่จะดูเฉพาะงานใหญ่ และใช้ clustering กลุ่มชิ้นข้อมูลที่สื่อสารเรื่องเดียวกันแล้วคงตัวแทนเพียงชิ้นเดียวเพื่อลดซ้ำซ้อน จากนั้นตั้งกฎให้โมเดลตอบโดยอ้างอิงเฉพาะข้อมูลใน context เช่น "ให้ตอบโดยใช้ข้อมูลที่ให้มาเท่านั้น ถ้าไม่มีข้อมูลเพียงพอให้ระบุว่าไม่ทราบ และอย่าคิดเติม" เพื่อเปลี่ยนค่าตั้งต้นจากการเดาเป็นการเคารพหลักฐาน
ความผิดพลาดที่พบเสมอคือรีบเปลี่ยน prompt เมื่อคำตอบ RAG ไม่ดี ทั้งที่ปัญหาอยู่ที่กระบวนการเรียกข้อมูลและบริบท อีกจุดคือปล่อยให้บริบทโตขึ้นเรื่อยๆ ไม่มีใครตัดประวัติหรือสรุปผล เครื่องมือจนทุกคำเรียกโมเดลต้องแบกข้อมูลเก่าไปตลอด ทำให้เสียโทเคนไปกับสิ่งที่โมเดลไม่ต้องใช้แล้ว แนวคิดสำคัญคือให้เลเยอร์บริบทตัดสินใจว่าส่วนไหนของโลกจำเป็นต่อขั้นงานนี้ แล้วสรุปหรือละสิ่งที่ปิดเคสไปแล้วออกจากบริบท
จัดงบโทเคนและการจัดการบริบทเพื่อควบคุมต้นทุน
เมื่อนำ RAG เข้าสู่โปรดักชัน ค่าใช้จ่ายโทเคนคือสิ่งที่คนมักเห็นช้าเกินไป วิธีคิดที่ช่วยได้คือมองงานของเอเจนต์เป็นคลาสที่รูปแบบคล้ายกัน และวางแผนงบโทเคนต่อคลาสงานก่อนรันจริง ไม่ใช่รอให้บิลออกแล้วค่อยมานั่งวิเคราะห์ภายหลัง โดยสำหรับแต่ละคลาส คุณสามารถประมาณว่าควรให้โควต้าบริบทเท่าใดกับคำสั่ง ระบบรู้ที่ดึงมา ประวัติการสนทนา และพื้นที่สำหรับคำตอบของโมเดล แล้วตั้งเป็นเพดานมากกว่าคำแนะนำ เพื่อให้ทุกคำเรียกโมเดลอยู่ในกรอบที่คาดเดาได้
| องค์ประกอบบริบท | เป้าหมายการใช้โทเคน | แนวทางจัดการ |
|---|---|---|
| คำสั่งและกฎระบบ | ให้ชัดแต่ไม่ซ้ำในทุกขั้น | สรุปหรืออ้างถึงคำสั่งเดิมแทนการส่งซ้ำ |
| ข้อมูลที่เรียกจากเอกสาร | ให้พอสำหรับตอบแต่ไม่เกินหน้าต่าง | ใช้การ rerank และ clustering ตัดชิ้นที่เกินและซ้ำ |
| ประวัติการสนทนา | พอให้โมเดลเข้าใจบริบทล่าสุด | ตัดหรือสรุปประวัติเก่าที่ปิดเคสแล้วออก |
| พื้นที่สำหรับคำตอบโมเดล | กันส่วนหนึ่งของหน้าต่างให้เสมอ | ใช้การพยากรณ์งบโทเคนต่อคลาสงานตั้งแต่ต้น |
เลเยอร์บริบทที่จัดงบโทเคนแบบนี้สามารถลดโทเคนอินพุตต่อคำเรียกโมเดลลงได้มากโดยไม่ไปยุ่งกับตรรกะของเอเจนต์หรือคุณภาพคำตอบ "ในเซสชันหลายขั้นจริง เลเยอร์ทั้งสี่ร่วมกันช่วยตัดอินพุตโทเคนต่อคำเรียกลงประมาณสามในสี่โดยไม่เปลี่ยนตรรกะเอเจนต์หรือคำตอบที่ได้" ข้อควรระวังคือเมื่อเลเยอร์ไม่สามารถจัดบริบทให้พออยู่ในงบ ควรให้ระบบรายงานว่าไม่สามารถมั่นใจในคำตอบดีกว่าตัดเนื้อหาเงียบๆ แล้วปล่อยให้โมเดลตอบอย่างมั่นใจทั้งที่ขาดหลักฐาน
ดีบัก วัดผล และตั้งค่า default ให้ AI เชื่อถือได้
แม้ RAG จะช่วยให้โมเดลมีหลักฐานภายนอก แต่อาการหลงประเด็นยังไม่หายไปทั้งหมด โมเดลยังอาจตีความบริบทผิด เอาข้อเท็จจริงไม่เกี่ยวมาปน คิดเติมข้อมูลที่ไม่มีในเอกสาร หรือเลือกเมินรายละเอียดสำคัญแล้วตอบแบบมั่นใจต่อไป สิ่งที่ช่วยได้คือการออกแบบกระบวนการดีบักและวัดผลตั้งแต่แรก ให้ทุกคำถามสามารถย้อนดูขั้นตอนกลางของพายป์ไลน์แทนการดูแค่คำตอบสุดท้าย
เวลาเจอคำตอบเพี้ยน ลองไล่ดูว่า User Question ไปเจอ Retrieved Chunks อะไร คะแนน Similarity เป็นอย่างไร Final Context ที่ส่งเข้าโมเดลมีสาระที่ควรมีหรือไม่ Prompt จริงที่ใช้กับ LLM เป็นแบบไหน แล้วคำตอบสุดท้ายออกมาอย่างไร มุมมองนี้ทำให้แยกออกว่าปัญหาอยู่ที่เวกเตอร์เสิร์ช การจัดอันดับ การตัดบริบท หรือการสร้างคำตอบ
เลเยอร์แพลตฟอร์มสามารถช่วยให้ทุกเอเจนต์มี tracing และ evaluation ติดตั้งตั้งแต่คอมมิตแรก ทำให้ข้อมูลเทเลเมทรีทั้งด้านโทเคนและคุณภาพคำตอบเกิดขึ้นโดยอัตโนมัติ ข้อมูลชุดนี้คือหลักฐานที่ให้คุณปรับงบโทเคนต่อคลาสงานตามจริงแทนการเดา และปรับกติกาบริบทให้ลดความเสี่ยงที่ระบบจะตอบผิดอย่างมั่นใจ สรุปแล้วการยกระดับ RAG จากเดโมสู่โปรดักชันไม่ใช่เรื่องเทคนิคขั้นสูงเสมอไป แต่คือการกำหนดขั้นตอนเรียบง่ายให้ทำได้อย่างมีวินัย ตั้งแต่จัดพายป์ไลน์ รีดบริบทให้พอดี ไปจนถึงดีบักและตรวจงานระบบเหมือนดูแลทีมงานคนหนึ่ง
