ผู้คนยังคงเขียนคำไว้อาลัยให้แก่ RAG คุณคงได้เห็นพาดหัวข่าวเหล่านั้นแล้ว ไม่ว่าจะเป็นเรื่องหน้าต่างบริบทขนาดใหญ่ (long context windows) ที่เข้ามาฆ่ามัน หรือเอเจนต์ (agents) ที่เข้ามาแทนที่ หรือแม้แต่การบอกว่ารูปแบบทั้งหมดนี้ล้าสมัยไปแล้ว แต่ความจริงนั้นแคบกว่าและมีประโยชน์กว่ามาก RAG ไม่ได้ตายลง สิ่งที่พังทลายลงจริงๆ คือภาพลวงตาอันแสนสบายที่ว่าคุณสามารถแบ่งกองเอกสารออกเป็นส่วนๆ (chunks) แล้วป้อนพวกมันลงในฐานข้อมูลเวกเตอร์ จากนั้นคุณก็จะมี AI ที่เชื่อถือได้และพูดความจริงทันที
เมื่อไม่กี่ปีก่อน ข้อเสนอนั้นดูเย้ายวนด้วยความเรียบง่าย เพียงแค่ฝังข้อมูลความรู้ของคุณ (Embed your knowledge base) เชื่อมต่อมันเข้ากับ LLM ถามคำถาม แล้วเฝ้าดูโมเดลตอบโดยใช้เพียงข้อมูลที่คุณดึงมา สำหรับการสาธิตที่ควบคุมได้หรือบอทตอบคำถาม (FAQ) ขนาดเล็ก วิธีนี้ใช้งานได้จริงอย่างน่าประหลาด เช่น คู่มือช่วยเหลือความยาว 20 หน้า หรือวิกิภายในองค์กรที่จัดระเบียบมาอย่างดี บอทจะสามารถอ้างอิงย่อหน้าที่ถูกต้องได้เกือบทั้งหมด และผู้บริหารก็จะอนุมัติโครงการนำร่องนั้น แต่โครงการนำร่องไม่ใช่การใช้งานจริงในระบบโปรดักชัน และต้นแบบก็ไม่ได้มีร่องรอยความยากลำบากจากการดำเนินธุรกิจจริง
ข้อมูลในระบบโปรดักชันนั้นยุ่งเหยิง มันประกอบด้วยบันทึกการแก้ไขปัญหาแบบเดียวกันที่ถูกคัดลอกไว้ในไฟล์นับสิบไฟล์ ซึ่งแต่ละไฟล์มีเวลาที่ต่างกันเล็กน้อยและมีป้ายกำกับสถานะที่ขัดแย้งกัน มันมีตารางที่ซับซ้อนซึ่งล้นข้ามหน้า ทำให้ข้อมูลกลายเป็นเรื่องไร้สาระเมื่อตัวแบ่งส่วน (splitter) ตัดแบ่งมันตรงกลางพอดี นอกจากนี้มันยังเก็บรักษาความขัดแย้งไว้โดยไม่มีการแก้ไข คู่มือโยบายปี 2023 บอกอย่างหนึ่ง แต่ฉบับแก้ไขเดือนมีนาคม 2024 บอกอีกอย่างหนึ่ง และไฟล์ PDF เก่าก็ไม่เคยถูกเก็บเข้ากรุ รูปแบบที่ไร้เดียงสาอย่างการแบ่งส่วน (chunk), จัดเก็บ (store) และดึงข้อมูล (retrieve) นั้นปฏิบัติกับทุกย่อหน้าเหมือนเป็นเกาะที่แยกขาดจากกัน มันไม่มีความเข้าใจเรื่องลำดับชั้น ประวัติเวอร์ชัน หรือการแก้ไขความขัดแย้ง โมเดลเกิดอาการหลอน (hallucinate) ไม่ใช่เพราะ LLM เสีย แต่เพราะบริบทที่ได้รับนั้นกระจัดกระจาย ขาดตอน หรือผิดพลาดโดยสิ้นเชิง
นักสังเกตการณ์บางคนอ้างว่าหน้าต่างบริบทขนาดล้านโทเคนทำให้การดึงข้อมูลกลายเป็นเรื่องไม่จำเป็น ข้อโต้แย้งของพวกเขานั้นตรงไปตรงมา คือแค่โยนข้อมูลทั้งหมดลงใน prompt แล้วปล่อยให้โมเดลอ่านทั้งหมดเสีย ฟังดูเป็นวิธีที่สง่างาม แต่มันก็เป็นการมองโลกในแง่ดีที่อันตรายเกินไป โมเดลอาจจะมีความสามารถทางเทคนิคในการรับข้อมูลปริมาณมหาศาลเทียบเท่ากับนวนิยายขนาดสั้น แต่การค้นหาข้อกำหนดเฉพาะเพียงข้อเดียวท่ามกลางข้อมูลมหาศาลนั้นเป็นทักษะที่แตกต่างออกไปโดยสิ้นเชิง เข็มยังคงหลงทางอยู่ในกองฟาง หน้าต่างบริบทขนาดใหญ่ช่วยขยายพื้นที่บนผืนผ้าใบที่มีให้ใช้ แต่ไม่ได้ช่วยแก้ปัญหาการทำงานที่ยากลำบากในการตัดสินใจว่าสิ่งใดควรค่าแก่การอยู่บนผืนผ้านั้น ปัญหาไม่เคยเป็นเรื่องของการดึงข้อมูลเพียงอย่างเดียว แต่มันคือการประกอบบริบท (context assembly) มาโดยตลอด
จากการดึงข้อมูลแบบพื้นฐาน สู่การวิศวกรรมบริบท (Context Engineering)
ในปี 2026 สาขานี้กำลังเติบโต เรากำลังก้าวข้ามผ่านยุคที่ RAG ถูกปฏิบัติเหมือนเป็นท่อส่งข้อมูลเส้นตรงเส้นเดียว ไปสู่สถาปัตยกรรมที่ปฏิบัติกับบริบทในฐานะผลิตภัณฑ์ที่ผ่านการวิศวกรรมมาอย่างตั้งใจ
การค้นหาแบบไฮบริดเหนือกว่าการใช้ความหมายเชิงอรรถศาสตร์เพียงอย่างเดียว (Hybrid search over pure semantics). ความคล้ายคลึงเชิงอรรถศาสตร์ (Semantic similarity) นั้นยอดเยี่ยมในการทำความเข้าใจเจตนา แต่กลับขาดความแม่นยำเมื่อต้องจัดการกับตัวระบุที่เฉพาะเจาะจง หากวิศวกรสอบถามรหัสข้อผิดพลาดที่เฉพาะเจาะจงอย่าง ERR_CONNECTION_REFUSED หรือเวอร์ชันของซอฟต์แวร์อย่าง v3.2.1 การค้นหาด้วยเวกเตอร์เพียงอย่างเดียวอาจทำให้ผลลัพธ์ที่ตรงเป๊ะถูกเจือจางไปในทะเลของผลลัพธ์ที่คล้ายคลึงกันในเชิงแนวคิดแต่ไม่เกี่ยวข้องในทางปฏิบัติ วิวัฒนาการในจุดนี้จึงตรงไปตรงมา ระบบสมัยใหม่จะผสมผสานการดึงข้อมูลด้วยเวกเตอร์แบบหนาแน่น (dense vector retrieval) เข้ากับการค้นหาด้วยคำสำคัญ (keyword search) โดยใช้วิธีอย่าง BM25 หรือ inverted indexes ควบคู่ไปกับ embeddings ชื่อที่ถูกต้อง รหัสข้อผิดพลาด ข้อความเวอร์ชัน และรหัสผลิตภัณฑ์จะถูกดักจับโดยเลเยอร์คำสำคัญ ในขณะที่ความละเอียดอ่อนเชิงแนวคิดจะถูกจัดการโดยเลเยอร์เวกเตอร์
การจัดลำดับใหม่ก่อนการสร้างคำตอบ (Reranking before generation). โดยธรรมชาติแล้ว การดึงข้อมูลมักจะเอนเอียงไปทางความครอบคลุม (recall) คุณจะดึงข้อมูลมาสัก 40 หรือ 50 ส่วน เพราะคุณกลัวว่าจะพลาดย่อหน้าทองคำเพียงย่อหน้าเดียว แต่การป้อนข้อมูลขยะทั้งหมดนั้นเข้าสู่โมเดลขนาดใหญ่เป็นการสิ้นเปลืองโทเคนและทำให้สัญญาณสำคัญถูกกลบ การจัดลำดับใหม่ (Reranking) แก้ปัญหานี้ด้วยการใช้โมเดลที่สองซึ่งมักจะมีขนาดเล็กกว่า เพื่อให้คะแนนความเกี่ยวข้องของแต่ละตัวเลือกเทียบกับคำถามที่เฉพาะเจาะจง จากนั้นจะเลือกเฉพาะเนื้อหา 5 อันดับแรกที่ผ่านเกณฑ์ ส่วนที่เหลือจะถูกคัดออก มันทำหน้าที่เป็นตัวกรองความแม่นยำระหว่างการดึงข้อมูลและการสร้างคำตอบ เพื่อให้มั่นใจว่าโมเดลการใช้เหตุผลที่มีราคาแพงจะอ่านเฉพาะสิ่งที่สำคัญจริงๆ เท่านั้น
การดึงข้อมูลเชิงบริบทที่รักษาความหมายไว้ (Contextual retrieval that preserves meaning). การแบ่งส่วนข้อมูล (Chunking) เปรียบเสมือนการกระทำที่รุนแรง ตัวแบ่งส่วนอาจตัดย่อหน้าออกจากหัวข้อหลัก ตัดออกจากคำอธิบายตาราง ตัดออกจากข้อความปฏิเสธความรับผิดชอบทางกฎหมายที่อยู่ล้อมรอบ หรือแม้แต่ตัดออกจากเชิงอรรถที่ช่วยขยายความหมายของมัน การดึงข้อมูลเชิงบริบทช่วยบรรเทาปัญหานี้โดยการเพิ่มความสมบูรณ์ให้กับเศษเสี้ยวข้อมูลก่อนที่มันจะส่งไปถึงโมเดล คุณสามารถเพิ่ม metadata ที่ระบุแหล่งที่มาไว้ข้างหน้า เช่น: ข้อความนี้มาจากรายงานอุบัติการณ์ไตรมาส 3 ปี 2024, ส่วนการขัดข้องของฐานข้อมูล, ระดับความรุนแรง: วิกฤต โมเดลจึงไม่ได้เห็นเพียงแค่ประโยคที่ลอยไปมา แต่เห็นข้อมูลที่มีบริบทและตำแหน่งที่ชัดเจน เศษเสี้ยวข้อมูลนั้นจะกลับมามีทิศทางที่ถูกต้องอีกครั้ง
การกำหนดเส้นทางแบบโมดูลาร์ตามเจตนา (Modular routing by intent) ไม่ใช่ทุกคำถามที่ควรจะอยู่ใน vector store ที่เต็มไปด้วยเอกสาร ผู้ใช้ที่ถามวิธีรีเซ็ตรหัสผ่านน่าจะต้องการบทความช่วยเหลือ ส่วนผู้ใช้ที่ถามว่าทำไมรายได้ในภาคตะวันออกเฉียงเหนือถึงลดลงในไตรมาสที่แล้ว ต้องการการใช้ SQL กับ data warehouse ไม่ใช่ย่อหน้าที่คล้ายคลึงกันในเชิงความหมายเกี่ยวกับกลยุทธ์การขายระดับภูมิภาค ระบบที่พัฒนาแล้วในปัจจุบันจะกำหนดเส้นทางคำถามตามเจตนา โดยเลือกเครื่องมือที่เหมาะสม เอกสารสำหรับขั้นตอนการทำงาน, ฐานข้อมูลเชิงสัมพันธ์ (Relational databases) สำหรับการวิเคราะห์ข้อมูลที่มีโครงสร้าง, Log aggregators สำหรับการตรวจสอบข้อผิดพลาด (trace debugging) และ APIs สำหรับสถานะแบบเรียลไทม์ เลเยอร์การดึงข้อมูล (retrieval layer) จึงกลายเป็นตัวจัดสรร (dispatcher) ไม่ใช่ระบบที่มีรูปแบบเดียว (monoculture)
ลูปการใช้เหตุผลแบบเอเจนต์ (Agentic reasoning loops) บางคำถามไม่สามารถตอบได้ด้วยการค้นหาเพียงขั้นตอนเดียว แต่ต้องมีการปรับเปลี่ยนรูปแบบคำถามใหม่ คำถามเริ่มต้นที่คลุมเครือจะได้รับการทำให้ชัดเจนขึ้น ข้ออ้างที่ดึงมาได้จะถูกตรวจสอบย้อนกลับกับแหล่งข้อมูลที่สอง หากเอกสารขัดแย้งกับข้อกำหนดของ API ระบบจะแจ้งเตือนความขัดแย้งนั้น แทนที่จะสร้างคำตอบที่กึ่งกลางขึ้นมาเอง โมเดลจะเป็นผู้ตัดสินใจเองว่าเมื่อใดควรค้นหาใหม่ เมื่อใดควรปรับปรุงคำถาม และเมื่อใดที่มีหลักฐานเพียงพอที่จะตอบคำถามได้ นี่ไม่ใช่การดึงข้อมูลแบบครั้งเดียวจบ (one-shot retrieval) แต่เป็นการใช้เหตุผลที่มีโครงสร้างซึ่งใช้การค้นหาเป็นเพียงขั้นตอนย่อย (subroutine)
GraphRAG สำหรับคำถามเชิงความสัมพันธ์ คำถามทางธุรกิจบางอย่างเป็นเรื่องของความเชื่อมโยง ไม่ใช่แค่ประโยค ความล้มเหลวของส่วนประกอบใดที่กระตุ้นการแจ้งเตือนปลายน้ำ (downstream alerts) ตัวไหน? ซัพพลายเออร์รายใดส่งสินค้าให้โรงงานไหน และเส้นทางสำรองคืออะไร? ใครในองค์กรที่มีสิทธิ์ตัดสินใจเกี่ยวกับงบประมาณส่วนนี้? การแบ่งข้อความเป็นส่วนๆ (flat text chunks) ทำให้ความสัมพันธ์เหล่านี้แบนราบ เพราะมันไม่ได้ถูกออกแบบมาเพื่อรักษาโครงสร้างเชิงพื้นที่ (topology) แต่ Knowledge graphs ทำได้ เมื่อคำถามเกี่ยวข้องกับอิทธิพล, สายลำดับ (lineage), รูปแบบ (patterns) หรือโครงสร้างเครือข่าย การท่องไปในกราฟ (traversing a graph) จะให้บริบทที่การดึงข้อมูลแบบย่อหน้าไม่สามารถเลียนแบบได้
คำถามที่สำคัญจริงๆ
บทสนทนาเกี่ยวกับ RAG จำเป็นต้องเปลี่ยนไป เลิกถามว่าจะสร้าง RAG pipeline แบบทั่วไปได้อย่างไร แต่เริ่มถามว่าโมเดลต้องแก้ปัญหาเฉพาะเจาะจงอะไร ข้อมูลที่แน่นอนแบบไหนที่จำเป็นเพื่อให้เกิดความแม่นยำ และคุณจะตรวจสอบได้อย่างไรว่าบริบทที่รวบรวมมานั้นเพียงพอแล้ว คำถามเหล่านี้จะผลักดันให้คุณกลับไปพิจารณาเรื่องคุณภาพข้อมูล, การออกแบบ schema, ลูปการตรวจสอบ และที่มาของแหล่งข้อมูล (source provenance) สิ่งเหล่านี้จะเผยให้เห็นว่าฐานความรู้ของคุณเหมาะสมสำหรับการนำไปใช้งานแบบอัตโนมัติหรือไม่
RAG ไม่ใช่กระบวนการเชิงเส้นแบบขั้นตอนเดียวที่คุณติดตั้งครั้งเดียวแล้วลืมไปได้อีกต่อไป แต่มันคือศาสตร์แห่งการรวบรวมบริบทที่ถูกต้องเพื่อให้โมเดลสามารถใช้เหตุผลได้อย่างมีประสิทธิภาพ นั่นหมายถึงการมองว่าการดึงข้อมูลเป็นปัญหาด้านการออกแบบระบบ ไม่ใช่แค่การนำเข้าไลบรารี (library import)
เครื่องมือต่างๆ กำลังเฉียบคมขึ้น การค้นหาเป็นแบบ hybrid การกำหนดเส้นทางมีความชาญฉลาด การดึงข้อมูลมีการจัดลำดับ (ranked), การเพิ่มข้อมูล (enriched) และการตรวจสอบ (verified) ภาพลวงตาที่เรียบง่ายในปี 2022 ต้องพังทลายลง เพื่อให้สิ่งที่ใช้งานได้จริงเข้ามาแทนที่ งานของคุณในตอนนี้ไม่ใช่แค่การดึงข้อความจากฐานข้อมูล แต่คือการสร้างระบบที่รู้ว่าโมเดลต้องการอะไร ก่อนที่โมเดลจะเริ่มคิดเสียด้วยซ้ำ
หากคุณกำลังสร้างสรรค์ในสายงานนี้ ชุมชนแห่งการเรียนรู้ของ GyaanSetu เป็นสถานที่สำหรับแลกเปลี่ยนความรู้เชิงปฏิบัติกับผู้คนที่กำลังแก้ปัญหาแบบเดียวกัน: https://t.me/GyaanSetuAi