เมื่อทีมต่างๆ ย้าย Retrieval-Augmented Generation (RAG) จากขั้นเดโมไปสู่บริการระดับโปรดักชัน พวกเขาต้องเผชิญกับการตัดสินใจหลายประการที่แยกแยะระหว่างผู้ช่วยที่มีประโยชน์กับผู้ช่วยที่สร้างแต่เสียงรบกวน การเลือกการออกแบบ 5 ประการ ได้แก่ การแบ่งส่วนข้อมูล (chunking), โมเดลการฝังตัว (embedding model), เวกเตอร์สโตร์ (vector store), การค้นหาแบบไฮบริด (hybrid search) และการประเมินผล (evaluation) คือปัจจัยที่ควบคุมความแม่นยำ (precision), การระลึกได้ (recall) และความหน่วง (latency) ที่ผู้ใช้งานจริงจะได้รับ

ทำไมการก้าวกระโดดจากต้นแบบไปสู่โปรดักชันจึงสำคัญ

บทช่วยสอนส่วนใหญ่มักจะทำให้ RAG pipeline ทำงานได้ด้วยโค้ดเพียงไม่กี่สิบ บรรทัด แต่แล้วก็หยุดลงเพียงแค่นั้น โดยไม่ได้คำนึงถึงความเข้มงวดทางวิศวกรรมที่จำเป็นสำหรับการรองรับทราฟฟิกจริง

1. กลยุทธ์การแบ่งส่วนข้อมูล (Chunking strategy) – ประตูควบคุมคุณภาพด่านแรก

ขนาดของ Chunk คือสิ่งที่สำคัญที่สุด Chunk ขนาดใหญ่จะทำให้สัญญาณข้อมูลถูกกลบด้วยข้อความที่ไม่เกี่ยวข้อง ในขณะที่ Chunk ขนาดเล็กเกินไปจะทำให้สูญเสียบริบทแวดล้อมที่โมเดลจำเป็นต้องใช้ในการสร้างคำตอบที่สอดคล้องกัน ส่วนการแบ่งแบบกำหนดขนาดตายตัว (Fixed-size splitting) ก็มักจะละเลยโครงสร้างตามธรรมชาติของเนื้อหาต้นฉบับ

หลักการปฏิบัติเบื้องต้น

  • แบ่งตามขอบเขตทางตรรกะ: เช่น หัวข้อในเอกสาร, การขึ้นย่อหน้าใหม่ในบทความ หรือการนิยามฟังก์ชันในโค้ด
  • รักษาขนาด Chunk ให้เล็กพอสำหรับการสืบค้นที่แม่นยำ แต่ยังคงรักษาเนื้อหาส่วนหลัก (parent section) ที่ใหญ่กว่าไว้สำหรับขั้นตอนการสร้างคำตอบของ LLM รูปแบบ "parent-child" นี้ช่วยให้ตัวสืบค้น (retriever) สามารถดึงข้อมูลส่วนที่เจาะจงออกมาได้ ในขณะที่ตัวสร้างคำตอบ (generator) ยังคงเห็นบริบทที่เพียงพอเพื่อให้ข้อมูลที่ถูกต้องตามข้อเท็จจริง

2. โมเดลการฝังตัว (Embedding models) – การตัดสินความคล้ายคลึง

โมเดลการฝังตัวจะเปลี่ยนข้อความให้เป็นเวกเตอร์เพื่อให้เครื่องมือค้นหาความคล้ายคลึงนำไปเปรียบเทียบ โมเดลอเนกประสงค์ที่แข็งแกร่ง เช่น text-embedding-3-large ของ OpenAI ให้เกณฑ์มาตรฐานที่ดีสำหรับโดเมนส่วนใหญ่ หากคลังข้อมูลของคุณอยู่ในสาขาที่มีความเฉพาะทางสูง เช่น ความเห็นทางกฎหมาย, บันทึกทางการแพทย์ หรือข้อกำหนดทางเทคนิค ให้ทดสอบโมเดลเฉพาะทาง (domain-specific model) แต่ควรทำหลังจากที่คุณวัดผลการพัฒนาที่จับต้องได้จากข้อมูลของคุณเองแล้วเท่านั้น

เมื่อไหร่ที่ควรเปลี่ยน

  • เปลี่ยนก็ต่อเมื่อคุณเห็นการเพิ่มขึ้นของคะแนนความเกี่ยวข้อง (relevance scores) ที่ส่งผลต่อแอปพลิเคชันของคุณอย่างชัดเจน (เช่น ค่า context precision ที่สูงขึ้น)

3. ฐานข้อมูลเวกเตอร์ (Vector database) – การขยายขนาดการจัดเก็บ

เลือกเวกเตอร์สโตร์ที่เหมาะสมกับโครงสร้างพื้นฐานเดิมของคุณและจำนวนเวกเตอร์ที่คาดการณ์ไว้

  • pgvector ทำงานภายใน PostgreSQL และสามารถจัดการเวกเตอร์ได้ถึงประมาณหนึ่งล้านตัวได้อย่างสบายๆ เหมาะสำหรับทีมที่ใช้งานฐานข้อมูลเชิงสัมพันธ์อยู่แล้วและต้องการโซลูชันที่ดูแลรักษาง่าย
  • Qdrant โดดเด่นในช่วง 1 ล้าน ถึง 100 ล้านเวกเตอร์ โดยให้ปริมาณงาน (throughput) ที่สูงกว่าและความหน่วงที่ต่ำกว่าสำหรับคลังข้อมูลขนาดใหญ่
  • Pinecone ให้บริการแบบ Managed Cloud เต็มรูปแบบ ช่วยลดภาระด้านการปฏิบัติการในการดูแลเซิร์ฟเวอร์ด้วยตนเอง

4. การค้นหาแบบไฮบริดและการจัดลำดับใหม่ (Hybrid search and reranking) – การสร้างสมดุลระหว่างความหมายและความแม่นยำ

การค้นหาแบบเวกเตอร์เพียงอย่างเดียวโดดเด่นในเรื่องความคล้ายคลึงทางความหมาย (semantic similarity) แต่อาจพลาดการจับคู่คำสำคัญ (keyword) ที่ตรงเป๊ะตามที่ผู้ใช้คาดหวัง การค้นหาแบบไฮบริดจะวางดัชนีคำสำคัญแบบ BM25 แบบดั้งเดิมทับลงบนดัชนีเวกเตอร์ จากนั้นจึงรวมรายการผลลัพธ์ทั้งสองเข้าด้วยกัน โดยใช้เทคนิค Reciprocal Rank Fusion (RRF) เพื่อกำหนดคะแนนให้แต่ละตัวเลือกตามลำดับของมันในทั้งสองรายการและนำมารวมกัน ซึ่งจะช่วยส่งเสริมรายการที่ปรากฏอยู่ในลำดับสูงของรายการใดรายการหนึ่ง

การจัดลำดับใหม่ (Reranking) ทำหน้าที่เป็นตัวกรองความแม่นยำขั้นสุดท้าย หลังจากสืบค้นแบบไฮบริดแล้ว ให้ส่งตัวเลือก Top-N (โดยทั่วไปคือ 50) ไปยัง cross-encoder ซึ่งเป็นโมเดลที่ให้คะแนนคู่คำถาม-เอกสารร่วมกัน คะแนนจาก cross-encoder จะถูกนำมาใช้แทนที่ตัวเลขความคล้ายคลึงเดิม ช่วยให้คุณเลือก Chunk ที่เกี่ยวข้องที่สุดก่อนจะส่งต่อไปยัง LLM ขั้นตอนนี้มักจะช่วยให้คุณภาพของคำตอบเพิ่มขึ้นอย่างเห็นได้ชัด โดยเฉพาะอย่างยิ่งสำหรับคลังข้อมูลที่มีเนื้อหายาวหรือมีข้อมูลรบกวนมาก

5. การประเมินผลและการปฏิเสธที่จะตอบ (Evaluation and abstention) – การวัดผลในสิ่งที่สำคัญ

คุณไม่สามารถปรับปรุงระบบที่คุณไม่ได้วัดผลได้ กรอบการทำงาน RAGAS เสนอตัวชี้วัด 4 ประการที่ช่วยสะท้อนสุขภาพของ RAG pipeline ได้แก่:

  • Context Precision – สัดส่วนของ Chunk ที่สืบค้นมาได้ซึ่งมีคำตอบอยู่จริง
  • Context Recall – สัดส่วนของ Chunk ที่เกี่ยวข้องทั้งหมดที่ถูกสืบค้นมาได้
  • Faithfulness – ระดับที่คำตอบที่สร้างขึ้นสอดคล้องกับบริบทที่สืบค้นมา เพื่อหลีกเลี่ยงอาการหลอน (hallucinations)
  • Answer Relevance – คำตอบสุดท้ายตอบสนองต่อคำถามต้นฉบับได้ดีเพียงใด

ควรติดตามตัวชี้วัดเหล่านี้ด้วยชุดทดสอบแบบหมุนเวียน (rolling test set) ที่จำลองทราฟฟิกจริงจากโปรดักชัน

มาตรการป้องกันสุดท้ายที่มักถูกมองข้ามคือ การปฏิเสธที่จะตอบ (abstention) แทนที่จะบังคับให้โมเดลตอบทั้งที่มีความเชื่อมั่นต่ำ ให้กำหนดเกณฑ์ (threshold) ของคะแนน faithfulness หรือ relevance เพื่อกระตุ้นให้ตอบว่า “ฉันไม่ทราบ” ผู้ใช้มักชอบการยอมรับความไม่แน่นอนอย่างชัดเจนมากกว่าคำตอบที่ดูมั่นใจแต่ผิดพลาด และการมีทางเลือกสำรองนี้ยังช่วยลดค่าใช้จ่ายในการสนับสนุน (support costs) ในภายหลังด้วย

หากคุณปฏิบัติกับทั้ง 5 ด้านนี้ในฐานะ "จุดตัดสินใจ" แทนที่จะเป็นเพียง "การตั้งค่าแล้วลืมไป" คุณจะสามารถเปลี่ยน RAG จากเดโมที่ดูน่าตื่นตาตื่นใจ ให้กลายเป็นบริการระดับโปรดักชันที่เชื่อถือได้ ผลลัพธ์ที่ได้คือระบบที่ตอบคำถามได้อย่างรวดเร็ว ตรงประเด็น และรู้ว่าเมื่อใดควรจะเงียบ