เข้าใจ RAG ให้ตรงก่อนลงมือ: มันแก้ปัญหาอะไร
RAG หรือ Retrieval Augmented Generation คือสถาปัตยกรรมที่ผสานระบบการดึงข้อมูลกับโมเดลภาษา LLM เพื่อให้ตอบคำถามจากฐานความรู้ภายนอกได้ตรงและทันสมัย โดยระบบจะดึงชิ้นข้อมูลที่เกี่ยวข้องจากเอกสารหรือฐานข้อมูล แล้วส่งเป็นคอนเท็กซ์ประกอบให้โมเดลสร้างคำตอบ ลดปัญหาความรู้ล้าสมัยและข้อมูลส่วนตัวที่ไม่ได้อยู่ในโมเดล รวมถึงช่วยจำกัดการคาดเดาแบบไร้หลักฐานของโมเดลด้วยบริบทที่มีที่มาชัดเจน สำหรับคนที่อยากให้งานเอกสาร คู่มือ หรือโค้ดภายในองค์กรตอบได้แบบถามตอบภาษาไทยธรรมชาติ RAG คือคำตอบที่ใช้ได้จริงมากกว่าการพึ่ง LLM ทั่วไปเพียงอย่างเดียว
จากประสบการณ์ของหลายคน ขั้นตอนสร้างเดโม่ RAG ดูเหมือนง่ายมาก แค่แปลงเอกสารเป็นชิ้นข้อมูล ทำ embeddings ใส่ฐานเวกเตอร์ ดึง Top‑K แล้วส่งให้ LLM ก็ได้คำตอบ ความซับซ้อนอยู่ตรงที่ ถ้าต้องการให้ตอบแม่นสม่ำเสมอในงานโปรดักชัน เราต้องออกแบบตั้งแต่การแบ่งข้อมูล chunking ไปจนถึงการจัดอันดับผลการดึงข้อมูลและบริหารคอนเท็กซ์อย่างละเอียด ถ้า retrieval แย่ LLM จะเริ่มต้นจากข้อมูลผิด ถึงพยายามปรับ prompt เท่าไรคำตอบก็ไม่ดีขึ้น เพราะหัวใจของ RAG คือส่งข้อมูลที่ถูกต้อง ให้ถูกเวลาจริงๆ ไม่ใช่แค่ต่อ LLM เข้ากับฐานเวกเตอร์เท่านั้น
วางท่อข้อมูลให้พร้อม: แยก ingestion และ question pipeline ให้ชัด
ก่อนคิดถึง prompt หรือโมเดล ต้องจัดระเบียบท่อข้อมูลของ RAG ให้ดี หลักสำคัญคือแยกส่วนที่จัดการเอกสารออกจากส่วนที่ตอบคำถามอย่างชัดเจน การมี ingestion pipeline ที่แน่นช่วยให้ข้อมูลที่เก็บเข้าไปพร้อมสำหรับการค้นและลดปัญหาตามมาภายหลัง เช่น เอกสารอยู่คนละรูปแบบ หรือฝังไปแบบไม่สอดคล้องกัน เมื่อท่อข้อมูลนิ่งแล้ว ค่อยไปปรับ retrieval ranking และ context engineering ได้เต็มที่ โดยไม่ต้องมานั่งแก้ที่ปลายทางทุกครั้งที่คำตอบเพี้ยน
- เตรียม ingestion pipeline ทำ Text Extraction จากเอกสารทุกแบบ เช่น PDF หน้าเว็บ หรือโค้ด ให้กลายเป็นข้อความเดียวกัน
- ออกแบบการแบ่งข้อมูล chunking ให้เหมาะกับเอกสารแต่ละชนิด แบ่งเป็นบล็อกที่มีหัวข้อ เนื้อหา และส่วนอ้างอิงชัดเจน ไม่เล็กหรือใหญ่เกินไป
- สร้าง embeddings ให้แต่ละ chunk แล้วบันทึกลง vector database เพื่อให้ค้นแบบ semantic similarity ได้
- วาง question‑answering pipeline ตั้งแต่ทำ Query Embedding ค้น Similarity Search เลือก Top‑K chunks สร้าง Prompt + Context แล้วส่งให้ LLM แปลงเป็นคำตอบ
- เพิ่มเลเยอร์ logging เก็บ User Question Retrieved Chunks Similarity Scores Final Context และ LLM Prompt เพื่อใช้ประเมินและดีบักภายหลัง
ข้อควรระวังที่คนทำ RAG ใหม่มักพลาดคือกระโดดไปเล่นกับ prompt ก่อนทั้งที่ ingestion ยังไม่เข้าที่ หลายคนเปลี่ยนข้อความนำด้วยคำว่า คุณเป็นผู้ช่วยที่เชี่ยวชาญ แล้วเพิ่มเป็น คุณเป็นผู้ช่วยที่แม่นยำสูง ให้คำอธิบายยาวขึ้นเรื่อยๆ แต่คำตอบก็ยังหลุด เพราะปัญหาไม่ใช่สไตล์ของโมเดล แต่คือข้อมูลที่ดึงมาไม่ใช่หลักฐานที่ถูกต้อง เมื่อ pipeline แยกชัดและมี logging เราจะเห็นว่าแต่ละคำถามผิดเพราะ retrieval ranking context หรือ generation แล้วค่อยแก้ตรงจุด ลดอาการรู้สึกว่า AI ตอบมั่วโดยไม่รู้ว่าจะแก้ตรงไหน
การแบ่งข้อมูล chunking และการจัดอันดับ: จุดที่เดโม่พังเมื่อขึ้นโปรดักชัน
การแบ่งข้อมูล chunking คือจุดที่ RAG เดโม่ดูดีแต่พอใช้งานจริงกลับล้มเหลว เอกสารส่วนใหญ่ไม่ได้ถูกเขียนมาเพื่อ semantic search เราจึงไม่สามารถป้อนทั้งเอกสารเป็นชิ้นเดียวแล้วหวังให้ค้นได้ตรงคำถาม เช่น เอกสารเรื่อง Authentication ที่มีหัวข้อ Token Lifetime และ Refresh Tokens ต้องถูกแบ่งเป็นชิ้นย่อยเพื่อให้ค้นคำถามแบบ ระยะเวลาที่ access token ใช้ได้ ตรงกับบล็อก Token Lifetime โดยเฉพาะ ถ้าแบ่งผิด ระบบอาจดึง chunk ที่พูดถึงการใช้ token เพื่อ authenticate แต่ไม่ได้บอกว่าหมดอายุกี่นาที ผลคือโมเดลไม่มีคำตอบจริงแม้ข้อมูลดูเกี่ยวข้อง
การ chunking จึงเป็นสมดุลระหว่างชิ้นเล็กและชิ้นใหญ่ ชิ้นเล็กให้การดึงข้อมูลแม่นขึ้นแต่ขาดบริบท ชิ้นใหญ่ให้บริบทมากขึ้นแต่ปนข้อมูลที่ไม่เกี่ยวข้องและกินโทเคนเกินจำเป็น ไม่มีขนาด chunk กลางที่ใช้ได้ทุกฐานความรู้ ต้องดูตามโครงสร้างเอกสาร ประเภทคำถาม ความยาวเนื้อหา รูปแบบการจัดหน้า โมเดล retrieval ที่ใช้ ขนาด context window และ LLM ปลายทาง อีกชั้นคือการจัดอันดับ หาก chunk ที่ถูกต้องถูกดึงมาแต่ถูกจัดไว้ลำดับล่าง โมเดลอาจให้ความสำคัญกับชิ้นอื่นมากกว่า ทำให้คำตอบคลาดเคลื่อน การจัดลำดับและคัด context ให้สั้นแต่มีสาระจึงช่วยให้ตอบแม่นและประหยัดโทเคนพร้อมกัน
ดีบักความผิดพลาดและทำ context engineering ให้คุ้มโทเคน
เมื่อระบบขึ้นโปรดักชัน ปัญหาใหญ่ไม่ใช่แค่ตอบผิด แต่คือการตอบผิดแบบเงียบโดยไม่มีใครรู้ว่าเกิดอะไรขึ้น วิธีแก้คือแยกประเภทความล้มเหลวของ RAG ให้ชัดด้วยการตรวจทุกขั้นของ pipeline สำหรับแต่ละคำถาม เราอยากเห็นทั้ง User Question Retrieved Chunks คะแนน Similarity Final Context Prompt ที่ส่ง และคำตอบของ LLM จากนั้นจัดประเภทความผิดพลาดเป็น การดึงข้อมูลผิดอันดับ การจัดอันดับผิด คอนเท็กซ์มีส่วนเกิน หรือโมเดลตีความข้อมูลผิด ถ้าไม่แยกแบบนี้ ทุกปัญหาจะดูเป็นแค่ AI ตอบไม่ดี และเรามักไปแก้ด้วยการเปลี่ยนโมเดลหรือ prompt ทั้งที่ต้นเหตุอยู่ที่ retrieval
context engineering คือการเลือกว่า chunk ไหนควรเข้า context ในแต่ละคำตอบ และควรตัดตรงไหนเพื่อไม่ให้โมเดลถูกถมข้อมูลเกินความจำเป็น การดึงข้อมูลมากขึ้นไม่ได้ดีเสมอไป เพราะบริบทที่ไม่เกี่ยวข้องสามารถทำให้โมเดลสับสนและสิ้นเปลืองโทเคนโดยไม่เพิ่มคุณภาพคำตอบ เราจึงต้องออกแบบกลยุทธ์ เช่น อนุญาตเฉพาะหัวข้อที่สัมพันธ์โดยตรงกับคำถาม จำกัดจำนวน chunk ต่อคำถาม หรือใช้ reranker ที่เน้นความเป็นหลักฐานที่ตอบคำถามมากกว่าความคล้ายของข้อความเฉยๆ นี่สำคัญมากสำหรับงานแบบ agentic ที่ให้ระบบย่อยงานเป็นหลายซับเอเจนต์ หาก context ไม่คัดดี ทุกเอเจนต์จะเผาโทเคนและเวลาร่วมกันโดยไม่ให้ประโยชน์เพิ่ม
ใช้ LLM ในสภาพแวดล้อมท้องถิ่นร่วมกับ RAG อย่างปลอดภัยและคุ้มค่า
นอกจากเลือกโมเดลบนคลาวด์แล้ว ทางเลือกที่น่าสนใจคือ LLM ในสภาพแวดล้อมท้องถิ่น โดยเฉพาะงานที่มีโค้ดหรือข้อมูลภายในที่ไม่อยากออกนอกเครื่อง มีกรณีที่ใช้คอมพิวเตอร์ขนาดเล็กสองเครื่องรันโมเดลขนาดใหญ่เชื่อมกันด้วยหน่วยความจำรวม ทำให้รองรับ context window ระดับล้านโทเคนในหน่วยความจำราว 8.5 GiB ต่อหนึ่ง context window และยังคงสร้างโทเคนได้ราว 30–50 โทเคนต่อวินาที พร้อมความเร็วโหลด prompt ถึงหลักพันโทเคนต่อวินาที ผลคือฐานโค้ดทั้งโปรเจกต์ถูกโหลดขึ้นมาใน context ได้ในเวลาไม่นาน ช่วยให้เอเจนต์ตรวจสอบโค้ดครบภาพมากขึ้นโดยไม่ต้องส่งข้อมูลขึ้นคลาวด์
LLM ในสภาพแวดล้อมท้องถิ่นให้ข้อดีด้านความเป็นส่วนตัวและค่าใช้จ่ายระยะยาว เพราะไม่มีข้อมูลส่งออก ไม่ถูกบันทึกโดยผู้ให้บริการภายนอก และค่าใช้จ่ายประจำเปลี่ยนเป็นค่าไฟของเครื่องแทน ตัวอย่างการใช้งานที่มีประโยชน์คือเอเจนต์รีวิวโค้ดที่อ่านทั้ง repository แล้วส่งรายชื่อประเด็นที่พบภายในเวลาประมาณ 20–30 นาที ผู้ใช้เลือกเองว่าจะเปิดประเด็นไหนเป็น issue จากนั้นลงมือแก้ด้วยตัวเอง ผู้เขียนยังเน้นชัดว่า ผู้ช่วยท้องถิ่นแม้จะเก่งงานเชิงวิเคราะห์ แต่ไม่ควรปล่อยให้มันดำเนินการสำคัญแบบอัตโนมัติ เช่น push โค้ด รันสคริปต์ในโปรดักชัน โดยไม่มีคนตรวจ เพราะแม้จะเป็นผู้ช่วยที่มีประโยชน์มากแต่คำตอบก็ไม่สมบูรณ์แบบเสมอ
สรุปแล้ว การนำ RAG ระบบการดึงข้อมูลมารวมกับ LLM ในสภาพแวดล้อมท้องถิ่นทำให้ได้ผู้ช่วยที่อ่านทั้งฐานความรู้หรือโค้ดของเราได้ ปลอดภัยกว่าและควบคุมค่าใช้จ่ายได้ดี เหมาะกับงานรีวิวโค้ดและตอบคำถามจากคลังเอกสารภายใน เมื่อเดินตามขั้นตอนตั้งแต่ ingestion chunking retrieval ranking context engineering และการแยกประเภทความล้มเหลว RAG ที่เคยเป็นเดโม่โชว์ก็จะกลายเป็นระบบตอบคำถามที่พึ่งพาได้ในงานจริง แต่สิ่งที่ต้องระวังคืออย่าปล่อยให้ระบบทำการเปลี่ยนแปลงที่มีผลกระทบโดยไม่มีคนตรวจ และควรมีเฟรมเวิร์กประเมินผลสม่ำเสมอเพื่อจับข้อผิดพลาดก่อนผู้ใช้ปลายทางจะเป็นคนเจอ
