การนำ Enterprise RAG ขึ้น Production — รูปแบบการ Implement Agentic RAG และ Hybrid Search ที่พิสูจน์แล้วจากแชทบอทภาษาลาว
ข้อความนำ
PoC ของ RAG ทำงานได้แล้ว แต่พอ deploy ขึ้น production environment ปุ๊บ ความแม่นยำกลับตก และผู้ใช้บอกว่า "ใช้ไม่ได้" — ถ้าคุณเคยเจอ pattern แบบนี้ บทความนี้เขียนขึ้นมาเพื่อปิด gap นั้นโดยเฉพาะ เราจะอธิบายแบบ step-by-step ตั้งแต่การใช้ Hybrid Search ที่ผสมผสาน Dense vector search กับ BM25 เพื่อเพิ่มความแม่นยำในการค้นหาขึ้น 15〜30% ไปจนถึงการสร้าง dynamic search pipeline ที่ตอบสนองต่อ intent ของ query ด้วย Agentic RAG รวมถึง implementation pattern และการออกแบบ evaluation metric ด้วย นอกจากนี้ยังจะพูดถึงความท้าทายเฉพาะของ low-resource language ที่บริษัทเราเผชิญตอนสร้าง RAG chatbot ภาษาลาว เพื่อช่วยจัดระเบียบ design decision ที่จำเป็นสำหรับการเปลี่ยนผ่านจาก PoC ไปสู่ production
เหตุใดจึงเกิดช่องว่างด้านความแม่นยำระหว่าง PoC และการใช้งานจริง?
ระหว่างสภาพแวดล้อม PoC และสภาพแวดล้อม Production มีความแตกต่างพื้นฐานในด้านคุณภาพ ปริมาณ และความหลากหลายของข้อมูล ใน PoC นั้นจะทำการตรวจสอบด้วย "ข้อมูลที่ทำงานได้ดี" แต่ใน Production จะมี query ที่ไม่คาดคิดหลั่งไหลเข้ามาเป็นจำนวนมาก ในส่วนนี้จะทำการวิเคราะห์โครงสร้างของช่องว่างด้านความแม่นยำ
3 กับดักที่มองไม่เห็นใน PoC
1️⃣ ประการแรกคือความเป็นเนื้อเดียวกันของข้อมูล ใน PoC นั้น เราทดสอบด้วยเอกสารภายในที่จัดรูปแบบเรียบร้อยแล้วเพียงหลักสิบถึงหลักร้อยรายการ แต่ในระบบ Production จะมีเอกสารหลักหมื่นรายการที่หลั่งไหลเข้ามา ทั้งในรูปแบบและโทนที่แตกต่างกันโดยสิ้นเชิง ไม่ว่าจะเป็น PDF, Markdown, HTML, รายงานการประชุม หรือ Chat Log เพียงแค่ขอบเขตของ Chunking คลาดเคลื่อน ก็อาจทำให้ Context ที่จำเป็นสำหรับการตอบคำถามหายไปได้
2️⃣ ประการที่สองคือความหลากหลายของ Query Query ที่ใช้ทดสอบใน PoC มักเป็น "คำถามที่รู้อยู่แล้วว่ามีคำตอบที่ถูกต้อง" ซึ่งเขียนขึ้นโดยนักพัฒนา แต่ผู้ใช้งานจริงใน Production จะส่งคำถามที่คลุมเครือ คำถามแบบผสมผสานหลายประเด็น รวมถึงคำถามที่อยู่นอกขอบเขตที่ RAG รับผิดชอบด้วย
3️⃣ ประการที่สามคือการขาดการประเมินผล ใน PoC อาจผ่านไปได้ด้วยความรู้สึกว่า "ดูเหมือนจะโอเค" แต่ใน Production หากไม่มีตัวชี้วัดเชิงปริมาณด้านความแม่นยำ ก็จะไม่สามารถสังเกตเห็นการเสื่อมประสิทธิภาพได้ ในครั้งที่บริษัทของเราสร้าง RAG ภาษาลาว ใน PoC นั้นเราตรวจสอบความแม่นยำด้วยการทดสอบแปลเอกสารภาษาอังกฤษเท่านั้น แต่ Query จริงของผู้ใช้ภาษาลาวกลับมีภาษาพูดและภาษาถิ่นปะปนอยู่ ทำให้คะแนนที่ได้แตกต่างจากตอน PoC โดยสิ้นเชิง
รูปแบบทั่วไปของการเสื่อมถอยความแม่นยำ
การเสื่อมถอยของความแม่นยำเกิดขึ้นใน 3 เลเยอร์หลัก
เลเยอร์การค้นหา (Search Layer) เผยให้เห็นข้อจำกัดของการค้นหาแบบ Dense เพียงอย่างเดียว คำศัพท์เฉพาะทางและชื่อเฉพาะอาจไม่ถูกจัดวางในตำแหน่งที่ใกล้เคียงกันใน Embedding Space ทำให้พลาดเอกสารที่มีความเกี่ยวข้องในเชิงความหมาย ในทางกลับกัน ก็อาจเกิดกรณีที่ระบบส่งคืน Chunk ที่มีความคล้ายคลึงกันในเชิงพื้นผิวแต่มีบริบทที่แตกต่างกันมาอยู่ในอันดับต้น ๆ
เลเยอร์การแบ่ง Chunk (Chunking Layer) ปัญหาคือการตัดข้อมูลที่ขาดความต่อเนื่องอันเกิดจากการแบ่งด้วยความยาวคงที่ ส่งผลให้เกิด Chunk ที่ถูกตัดกลางตาราง หรือกลางรายการ รวมถึง Chunk ที่ไม่สามารถเข้าใจความหมายได้หากขาดบริบทก่อนหน้าและหลังจากนั้น
เลเยอร์การสร้างข้อความ (Generation Layer) การส่งผลลัพธ์การค้นหาที่มีคุณภาพต่ำไปยัง LLM โดยตรง ทำให้เกิด Hallucination และคำตอบที่ไม่ตรงประเด็นมากขึ้น หากความแม่นยำในการค้นหาต่ำ ไม่ว่าจะใช้ LLM ที่มีประสิทธิภาพสูงเพียงใด ผลลัพธ์ก็ไม่อาจดีขึ้นได้ ความแม่นยำของ RAG ถูกกำหนดโดยการค้นหาเป็นอันดับแรก
สิ่งที่ต้องเตรียมล่วงหน้า — Tech Stack และความรู้พื้นฐาน
ในการนำขั้นตอนที่อธิบายในบทความนี้ไปใช้งาน จะต้องจัดเตรียมสภาพแวดล้อมและความรู้ที่จำเป็นให้พร้อม
สถาปัตยกรรมที่แนะนำ
| คอมโพเนนต์ | เทคโนโลยีที่แนะนำ | บทบาท |
|---|---|---|
| Vector DB | Qdrant / Weaviate / pgvector | จัดเก็บและค้นหา Dense Vector |
| การค้นหาแบบ Full-text | Elasticsearch / OpenSearch / pgvector + pg_bigm | การให้คะแนนด้วย BM25 |
| Embedding Model | OpenAI text-embedding-3-large / Cohere embed-v4 / โมเดลรองรับหลายภาษา | แปลงข้อความ → Vector |
| LLM | Claude / GPT | สร้างคำตอบและการอนุมานของ Agent |
| Orchestration | LangChain / LlamaIndex / Mastra | ควบคุม Pipeline |
| การประเมินผล | Ragas / DeepEval | Pipeline ประเมินผลอัตโนมัติ |
การใช้งาน pgvector + PostgreSQL เหมาะสำหรับการเริ่มต้นในขนาดเล็ก ในระบบ RAG ภาษาลาวของบริษัทเราเองก็เริ่มต้นด้วย pgvector เช่นกัน โดยใช้แนวทางพิจารณาย้ายไปยัง Vector DB เฉพาะทางตามความต้องการในการขยายขนาด
รายการตรวจสอบความรู้พื้นฐาน
หากคุณเข้าใจสิ่งต่อไปนี้ คุณจะสามารถดำเนินการตามขั้นตอนในบทความนี้ได้อย่างราบรื่น
- แนวคิดพื้นฐานของการค้นหาเชิงเวกเตอร์ (Embedding, Cosine Similarity, ANN)
- กลไกการทำงานของ BM25 (การให้คะแนนแบบ TF-IDF)
- การเรียกใช้ API ของ LLM (การออกแบบ Prompt, การจัดการ Token)
- ขั้นตอนพื้นฐานของ RAG (ค้นหา → ฉีด Context → สร้างผลลัพธ์)
หากคุณยังไม่มั่นใจในเรื่องเหล่านี้ แนะนำให้ศึกษาพื้นฐานจากคู่มือ RAG สำหรับ AI Chatbot ภาษาลาวก่อนเป็นอันดับแรก
ขั้นตอนที่ 1: ออกแบบกลยุทธ์การแบ่งข้อมูล (Chunking) สำหรับการใช้งานจริง
การแบ่งก้อนข้อมูล (Chunking) คือรากฐานของความแม่นยำใน RAG อย่าหยุดอยู่แค่การแบ่งแบบ "ขอไปที 500 token" ในขั้น PoC แต่ให้ออกแบบกลยุทธ์ที่สอดคล้องกับโครงสร้างของเอกสาร
การปรับขนาด Chunk และการทับซ้อนให้เหมาะสม
ไม่มีคำตอบที่ถูกต้องสากลสำหรับขนาด chunk แต่มีแนวทางปฏิบัติที่ใช้ได้จริง
- chunk สั้น (200–400 token): ความแม่นยำในการค้นหาสูงขึ้น แต่ context มักไม่เพียงพอ เหมาะสำหรับ FAQ หรือพจนานุกรมคำนิยาม
- chunk ยาว (800–1200 token): context อุดมสมบูรณ์ แต่ noise ก็เพิ่มขึ้นด้วย เหมาะสำหรับเอกสารทางเทคนิคหรือสัญญา
- overlap: การให้ chunk ซ้อนทับกัน 10–20% ช่วยลดการสูญหายของข้อมูลบริเวณรอยต่อระหว่าง chunk
จากประสบการณ์ของผู้เขียน วิธีที่มีประสิทธิภาพสูงสุดคือเริ่มต้นด้วย 400 token และ overlap 50 token จากนั้นค่อยปรับโดยดูจาก evaluation metric เคยเห็นโปรเจกต์ที่เสียเวลาไป 2 สัปดาห์เพียงเพื่อพยายามหาค่าที่เหมาะสมที่สุดตั้งแต่แรก แต่การ tuning ในขั้นตอนที่ยังไม่มี evaluation pipeline นั้นเป็นการเสียเวลาเปล่า
การออกแบบการกำหนดเมทาดาทาและการกรองข้อมูล
สิ่งที่ส่งผลอย่างมากต่อความแม่นยำของ RAG ในระบบ production คือการแนบ metadata เข้ากับ chunk
json
1{
2 "chunk_id": "doc-123-chunk-5",
3 "source": "社内規程_v3.2.pdf",
4 "section": "第4章 情報セキュリティ",
5 "page": 12,
6 "last_updated": "2026-01-15",
7 "department": "情報システム部",
8 "document_type": "policy"
9}เมื่อนำ pre-filtering ด้วย metadata มาใช้งาน จะสามารถจำกัดขอบเขตของข้อมูลที่ต้องการค้นหาก่อน แล้วจึงรัน Dense/BM25 search ได้ สำหรับ query อย่าง "ระเบียบภายในองค์กรล่าสุดเกี่ยวกับความมั่นคงปลอดภัยสารสนเทศ" การกรองด้วยเงื่อนไข document_type = "policy" และ section LIKE '%セキュリティ%' ก่อนทำการค้นหา จะให้ความแม่นยำสูงกว่าการค้นหาจาก chunk ทั้งหมดอย่างเห็นได้ชัด
ตัวอย่างการใช้งาน RAG ภาษาลาวของเรา
เมื่อบริษัทของเราสร้าง RAG chatbot ภาษาลาว ความท้าทายที่สุดในขั้นตอน chunking คือการตรวจจับขอบเขตของคำ ภาษาลาวเช่นเดียวกับภาษาไทยไม่ใช้ช่องว่างในการแบ่งคำ ดังนั้น tokenizer ที่ออกแบบมาสำหรับภาษาอังกฤษจึงตัด chunk boundary กลางประโยค
ในที่สุดเราได้ implement custom splitter ที่ใช้เครื่องหมายแบ่งประโยคของภาษาลาว (เทียบเท่ากับ 。) เป็น primary delimiter และใช้ความยาวเป็น byte เป็น secondary delimiter วิธีการนี้เพียงอย่างเดียวช่วยปรับปรุงความแม่นยำในการค้นหา (Hit Rate@5) จาก 0.42 เป็น 0.61 สำหรับภาษาที่มีทรัพยากรน้อย (low-resource language) หากใช้ chunking library ทั่วไปโดยตรงจะไม่สามารถให้ความแม่นยำที่ต้องการได้ การ preprocessing เฉพาะภาษาจึงเป็นข้อกำหนดเบื้องต้นสำหรับคุณภาพระดับ production
ขั้นตอนที่ 2: ใช้งาน Hybrid Search (Dense + BM25)
การค้นหาแบบ Dense vector นั้นมีความแข็งแกร่งในด้านความคล้ายคลึงเชิงความหมาย แต่อ่อนแอในการจับคู่แบบตรงทั้งในส่วนของชื่อเฉพาะและคีย์เวิร์ด ในขณะที่ BM25 นั้นตรงกันข้าม การค้นหาแบบ Hybrid ที่ผสมผสานทั้งสองวิธีเข้าด้วยกัน มีรายงานจาก benchmark หลายรายการว่าสามารถเพิ่มความแม่นยำได้ 15〜30% เมื่อเทียบกับการค้นหาแบบเดี่ยว
การเปรียบเทียบคุณสมบัติของ Dense Retrieval และ BM25
| คุณสมบัติ | Dense (การค้นหาเวกเตอร์) | BM25 (การค้นหาแบบ Full-text) |
|---|---|---|
| ความคล้ายคลึงเชิงความหมาย | แข็งแกร่ง | อ่อนแอ |
| การจับคู่คีย์เวิร์ด | อ่อนแอ | แข็งแกร่ง |
| คำศัพท์เฉพาะทาง | ขึ้นอยู่กับคุณภาพของ Embedding | แม่นยำหากตรงกันพอดี |
| รองรับหลายภาษา | รองรับได้ด้วย Embedding Model หลายภาษา | ต้องใช้ Analyzer แยกตามภาษา |
| ความสามารถในการขยายระบบ | รวดเร็วด้วย ANN | รวดเร็วด้วย Inverted Index |
ในการใช้งานจริง ประสิทธิผลที่รู้สึกได้ชัดเจนที่สุดคือเมื่อผู้ใช้ส่งคิวรีที่มีตัวระบุเฉพาะ เช่น รหัสสินค้าหรือหมายเลขมาตรา การค้นหาแบบ Dense เพียงอย่างเดียวอาจพลาด "ข้อกำหนดของรหัสสินค้า ABC-1234" แต่ BM25 สามารถค้นพบได้อย่างแม่นยำ ในทางกลับกัน สำหรับคิวรีที่คลุมเครือ เช่น "เอกสารที่มีเนื้อหาคล้ายกับแนวทางรับมือเหตุการณ์ด้านความปลอดภัยเมื่อปีที่แล้ว" การค้นหาแบบ Dense จะแสดงศักยภาพได้อย่างเต็มที่
การเลือกวิธีการรวมคะแนน (RRF vs การรวมเชิงเส้นแบบถ่วงน้ำหนัก)
การรวมคะแนนของ Hybrid Search มีอยู่ 2 วิธีหลัก
Reciprocal Rank Fusion (RRF) คือการรวมคะแนนโดยใช้เพียงลำดับของผลลัพธ์การค้นหาแต่ละรายการ ไม่จำเป็นต้องทำ normalization คะแนน จึงสามารถนำ search engine ที่มีการกระจายคะแนนแตกต่างกันมารวมกันได้ง่าย
RRF_score(d) = Σ 1 / (k + rank_i(d))
k มักถูกกำหนดไว้ที่ 60 ความเรียบง่ายนี้คือจุดแข็งของ RRF เนื่องจากมี tuning parameter น้อย จึงให้ผลลัพธ์ที่เสถียร
การรวมเชิงเส้นแบบถ่วงน้ำหนัก (Weighted Linear Combination) คือการนำคะแนนแต่ละตัวมาทำ normalization ก่อน แล้วจึงคำนวณค่าเฉลี่ยถ่วงน้ำหนัก
hybrid_score(d) = α × dense_score(d) + (1 - α) × bm25_score(d)
หลายกรณีมักกำหนด α ไว้ที่ประมาณ 0.7 (เน้น Dense) แต่ค่าที่เหมาะสมที่สุดจะแตกต่างกันไปตาม domain และประเภทของ query การใช้ grid search หา α ใน evaluation pipeline ถือเป็นแนวทางที่ปฏิบัติได้จริง
ผู้เขียนแนะนำให้เริ่มต้นด้วยการ implement ด้วย RRF เพื่อสร้าง baseline ด้านความแม่นยำก่อน แล้วจึงพิจารณาเปลี่ยนไปใช้การรวมเชิงเส้นแบบถ่วงน้ำหนักหากยังมีช่องทางปรับปรุงความแม่นยำได้อีก การใช้เวลา tune α ตั้งแต่แรกนั้นควรรอจนกว่าจะมีข้อมูลสำหรับการประเมินสะสมเพียงพอเสียก่อน
รูปแบบการนำไปใช้งานและผลลัพธ์การทดสอบประสิทธิภาพ
การค้นหาแบบ Hybrid ที่ครบวงจรใน PostgreSQL โดยใช้ pgvector + pg_bigm นั้นมีโครงสร้างอินฟราสตรักเจอร์ที่เรียบง่ายและต้นทุนการดำเนินงานต่ำ
sql
1-- Dense 検索（pgvector）
2SELECT id, 1 - (embedding <=> query_embedding) AS dense_score
3FROM chunks
4ORDER BY embedding <=> query_embedding
5LIMIT 20;
6
7-- BM25 検索（pg_bigm or pgroonga）
8SELECT id, ts_rank(to_tsvector(content), plainto_tsquery('検索クエリ')) AS bm25_score
9FROM chunks
10WHERE to_tsvector(content) @@ plainto_tsquery('検索クエリ')
11LIMIT 20;รวมคะแนนด้วย RRF แล้วส่งผลลัพธ์ 5〜10 อันดับแรกให้กับ LLM จากการทดสอบ Benchmark ภายในของบริษัท พบว่า Hit Rate@5 ของ Dense แบบเดี่ยวอยู่ที่ 0.72 ในขณะที่ Hybrid (RRF) ปรับปรุงขึ้นมาอยู่ที่ 0.87 โดยเฉพาะอย่างยิ่งสำหรับ Query ที่มีคำนามเฉพาะ มีการปรับปรุงอย่างเห็นได้ชัด จาก 0.58 → 0.84
ขั้นตอนที่ 3: สร้าง Dynamic Retrieval Pipeline ด้วย Agentic RAG
RAG แบบดั้งเดิมคือ pipeline แบบตายตัวในรูปแบบ "query → ค้นหา → สร้างผลลัพธ์" Agentic RAG ขยายแนวคิดนี้โดยให้ LLM agent ตัดสินใจกลยุทธ์การค้นหาแบบ dynamic Gartner ได้รับรองแนวทางนี้ว่าเป็น trend ที่น่าจับตามอง และช่วยยกระดับความแม่นยำในการรับมือกับ query ที่ซับซ้อนได้อย่างมีนัยสำคัญ
Agentic RAG คืออะไร? — ความแตกต่างจาก RAG แบบดั้งเดิม
ใน RAG แบบดั้งเดิม (Naive RAG) คำค้นหาของผู้ใช้จะถูกนำไปใช้เป็น search query โดยตรง อย่างไรก็ตาม สำหรับ query แบบผสม เช่น "เปรียบเทียบการรับมือกับ security incident ในปีที่แล้วกับมาตรการป้องกันในปีนี้" การค้นหาเพียงครั้งเดียวไม่สามารถครอบคลุมข้อมูลที่จำเป็นทั้งหมดได้
ใน Agentic RAG นั้น LLM agent จะตัดสินใจต่อไปนี้อย่างอิสระ
- Query Decomposition: แบ่ง query แบบผสมออกเป็น sub-query หลายรายการ
- การเลือก search strategy: ตัดสินใจสำหรับแต่ละ sub-query ว่าจะใช้ Dense / BM25 / metadata filter แบบใด
- การประเมินผลลัพธ์: ประเมินว่าผลการค้นหาเพียงพอหรือไม่ และหากไม่เพียงพอก็จะทำการค้นหาใหม่
- การสังเคราะห์คำตอบ: รวมผลการค้นหาหลายรายการเข้าด้วยกันเพื่อสร้างคำตอบสุดท้าย
นี่ไม่ใช่เพียงแค่การปรับปรุงทางเทคนิค แต่เป็นการเปลี่ยนแปลง architectural paradigm ของ RAG search pipeline เปลี่ยนจาก "สิ่งที่กำหนดตายตัวด้วยโปรแกรม" ไปสู่ "สิ่งที่ agent จัดรูปแบบตามสถานการณ์"
การออกแบบเครื่องมือของ Agent (การค้นหา · การสรุป · การค้นหาซ้ำ)
เอเจนต์ของ Agentic RAG จะถูกกำหนดให้มีเครื่องมือดังต่อไปนี้
typescript
1const tools = [
2 {
3 name: "hybrid_search",
4 description: "Dense + BM25 の Hybrid 検索を実行する",
5 parameters: { query: "string", filters: "object", top_k: "number" }
6 },
7 {
8 name: "metadata_filter",
9 description: "メタデータ条件でドキュメントを絞り込む",
10 parameters: { department: "string", doc_type: "string", date_range: "object" }
11 },
12 {
13 name: "summarize_results",
14 description: "検索結果を要約し、情報の充足度を評価する",
15 parameters: { chunks: "array", original_query: "string" }
16 },
17 {
18 name: "refine_query",
19 description: "検索結果が不十分な場合にクエリを書き換えて再検索する",
20 parameters: { original_query: "string", missing_info: "string" }
21 }
22];สิ่งสำคัญในการออกแบบเครื่องมือคือ การเขียน description ของแต่ละเครื่องมือให้ชัดเจนและเป็นรูปธรรม เนื่องจากเอเจนต์จะอ่าน description เพื่อเลือกใช้เครื่องมือ หากเขียนคำอธิบายที่คลุมเครือก็จะทำให้เกิดการเลือกเครื่องมือผิดพลาดบ่อยครั้ง ควรเขียนในลักษณะเช่น "รันการค้นหาแบบ Hybrid ด้วย Dense + BM25 และคืนค่ารายการ chunk พร้อม relevance score" แทนที่จะเขียนเพียงแค่ "ค้นหา"
ตัวอย่างการนำ Multi-Step Reasoning ไปใช้งาน
แสดงขั้นตอนการทำงานจริงของ Agentic RAG
ผู้ใช้: "จากมาตรการควบคุมใน ISO 27001
กรุณาแสดงรายการที่บริษัทเรายังไม่ได้ดำเนินการ"
การคิดของ Agent:
1. ต้องการรายการมาตรการควบคุมของ ISO 27001
→ metadata_filter(doc_type="standard", title="ISO 27001")
2. ต้องการสถานะการดำเนินการของบริษัท
→ hybrid_search("สถานะการดำเนินการ ความมั่นคงปลอดภัยสารสนเทศ มาตรการควบคุม")
3. นำผลการค้นหามาเปรียบเทียบเพื่อระบุรายการที่ยังไม่ได้ดำเนินการ
→ summarize_results(chunks, original_query)
4. ผลลัพธ์ไม่เพียงพอ (พบสถานะการดำเนินการเพียงบางส่วน)
→ refine_query("รายงานสถานะการดำเนินมาตรการความมั่นคงปลอดภัยแยกตามแผนก")
5. รวมผลลัพธ์เพิ่มเติมเพื่อสร้างคำตอบสุดท้ายดังที่เห็น Agentic RAG จะทำการค้นหาและประเมินผลซ้ำหลายครั้งโดยอัตโนมัติสำหรับ query เดียว ในขณะที่ pipeline แบบตายตัวของ PoC จะค้นหาด้วย "ISO 27001 มาตรการควบคุม ยังไม่ดำเนินการ" เพียงครั้งเดียวแล้วจบ แต่สามารถขยายเป็นการค้นหาแบบหลายขั้นตอนที่ปรับตามบริบทได้
อย่างไรก็ตาม การอนุมานแบบ multi-step จะเพิ่ม latency และต้นทุน ในการใช้งานจริง (Production) จึงจำเป็นอย่างยิ่งที่ต้องกำหนดจำนวนขั้นตอนสูงสุด (3〜5 ครั้ง) และตั้งค่า timeout (เช่น 30 วินาที)
ขั้นตอนที่ 4: ออกแบบตัวชี้วัดการประเมินและผนวกเข้ากับ CI/CD
ความท้าทายที่ยิ่งใหญ่ที่สุดของ RAG ในระบบ production คือ "การที่ไม่สามารถสังเกตเห็นได้เมื่อความแม่นยำเสื่อมลง" การผนวก evaluation pipeline เข้าไปใน CI/CD ช่วยสร้างกลไกในการตรวจจับความเสื่อมถอยของความแม่นยำก่อนที่จะทำการ deploy
ความซื่อสัตย์ / ความเกี่ยวข้อง / ความถูกต้องของคำตอบ
ตัวชี้วัดการประเมิน RAG จำเป็นต้องครอบคลุมทั้งด้านการค้นหาและการสร้างข้อความ
| ตัวชี้วัด | สิ่งที่วัด | ความหมาย |
|---|---|---|
| Context Relevance | การค้นหา | chunk ที่ดึงมานั้นเกี่ยวข้องกับ query หรือไม่ |
| Faithfulness | การสร้างข้อความ | คำตอบมีความซื่อสัตย์ต่อเนื้อหาของ chunk ที่ดึงมาหรือไม่ (การตรวจจับ hallucination) |
| Answer Correctness | การสร้างข้อความ | คำตอบตรงกับคำตอบที่ถูกต้องหรือไม่ |
| Hit Rate@K | การค้นหา | chunk ที่ถูกต้องอยู่ใน K อันดับแรกหรือไม่ |
| MRR（Mean Reciprocal Rank） | การค้นหา | ค่าเฉลี่ยของส่วนกลับของอันดับของ chunk ที่ถูกต้อง |
ตัวชี้วัดที่ผู้เขียนให้ความสำคัญมากที่สุดคือ Faithfulness สำหรับการใช้งานในระดับองค์กร (enterprise) นั้น hallucination (คำตอบที่ไม่ตรงกับข้อเท็จจริง) ถือเป็นความเสี่ยงสูงสุด และอาจทำให้สูญเสียความไว้วางใจจากผู้ใช้ได้ในทันที จึงได้กำหนดกฎไว้ว่าหาก Faithfulness ต่ำกว่า 0.95 จะบล็อกการ deploy ทันที
การสร้างไปป์ไลน์การประเมินผลอัตโนมัติ
ด้วย Ragas หรือ DeepEval สามารถสร้าง evaluation pipeline ได้ภายในระยะเวลาค่อนข้างสั้น
python
1from ragas import evaluate
2from ragas.metrics import faithfulness, context_relevancy, answer_correctness
3
4# test dataset (คำถาม + คำตอบที่ถูกต้อง + ผลการค้นหา + คำตอบที่สร้างขึ้น)
5result = evaluate(
6 dataset=test_dataset,
7 metrics=[faithfulness, context_relevancy, answer_correctness],
8)การสร้าง test dataset คือขั้นตอนที่ใช้ความพยายามมากที่สุด นอกจาก test case ที่ใช้ใน PoC แล้ว ควรเพิ่ม case ที่ผู้ใช้ให้ feedback ว่า "คุณภาพคำตอบต่ำ" จาก production log อย่างต่อเนื่อง หากมี test case อย่างน้อย 100 รายการ และในอุดมคติคือ 500 รายการขึ้นไป จะทำให้ได้การประเมินผลที่น่าเชื่อถือทางสถิติ
การตรวจจับความเสื่อมถอยของความแม่นยำโดยอัตโนมัติและการแจ้งเตือน
จุดสำคัญในการนำไปใช้กับ CI/CD คือการตั้ง threshold-based gate
- PR Merge Gate: บล็อกการ merge หาก Faithfulness < 0.95 หรือ Context Relevance < 0.80
- Batch Evaluation เป็นระยะ: รันการประเมินกับตัวอย่างข้อมูล production ทุกวัน
- Alert: แจ้งเตือนผ่าน Slack หากตัวชี้วัดลดลงมากกว่า 5% เมื่อเทียบกับสัปดาห์ก่อน
ในบริษัทของเรา ได้นำมาใช้ร่วมกับกลไก HITL (Human-in-the-Loop) โดยสร้าง flow ให้มนุษย์ review เคสที่การประเมินอัตโนมัติให้ผลต่ำกว่า threshold การประเมินอัตโนมัตินั้นไม่ใช่สิ่งที่ครอบคลุมทุกอย่าง แต่ในแง่ของการตรวจจับความเสื่อมถอยตั้งแต่เนิ่นๆ นั้น ทำได้รวดเร็วกว่าการ review โดยมนุษย์เพียงอย่างเดียวอย่างเห็นได้ชัด
ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข
ขอแนะนำ 3 รูปแบบความล้มเหลวที่พบเห็นซ้ำแล้วซ้ำเล่าในการเปลี่ยนผ่านจาก PoC ไปสู่ระบบ Production
1. ความผิดพลาดในการเลือก Embedding Model
การเลือก Embedding model โดยพิจารณาจากคะแนน benchmark ภาษาอังกฤษเพียงอย่างเดียว มักส่งผลให้ความแม่นยำต่ำเมื่อนำไปใช้กับเอกสารภาษาญี่ปุ่นหรือหลายภาษา ในกรณี RAG ภาษาลาวของบริษัทเรา พบว่า text-embedding-3-large ของ OpenAI มีประสิทธิภาพดีเยี่ยมสำหรับภาษาอังกฤษ แต่ในภาษาลาว โมเดลหลายภาษาของ Cohere กลับให้ค่า Hit Rate สูงกว่าถึง 12 คะแนน
วิธีแก้ไข: ควรทำ benchmark โดยใช้ข้อมูล domain ของบริษัทเองเสมอ benchmark สาธารณะ (เช่น MTEB เป็นต้น) ถือเป็นเพียงค่าอ้างอิงเท่านั้น และหากข้อมูลมีคำศัพท์เฉพาะ domain จำนวนมาก อันดับของโมเดลอาจเปลี่ยนแปลงได้อย่างมีนัยสำคัญ
2. ความแม่นยำที่ติดเพดานโดยไม่มี Reranker
การแทรก Reranker (Cross-Encoder) หลังจาก Hybrid Search สามารถเพิ่มความแม่นยำได้อีก 5〜15% อย่างไรก็ตาม มีบางโปรเจกต์ที่ตัดสินใจว่า "แค่ Hybrid ก็เพียงพอแล้ว" จนทำให้ความแม่นยำถึงจุดอิ่มตัว
Reranker คือโมเดลที่ทำการ re-scoring ผลลัพธ์การค้นหา 20〜50 อันดับแรกโดยจับคู่กับ Query แม้จะมีต้นทุนการคำนวณสูงกว่า Bi-Encoder (Embedding) แต่ความแม่นยำนั้นสูงกว่าอย่างเห็นได้ชัด โดย Cohere Rerank และ bge-reranker-v2 ถือเป็นตัวเลือกที่นำไปใช้งานได้จริง
แนวทางแก้ไข: กำหนดให้ใช้ pipeline 3 ขั้นตอนเป็นโครงสร้างมาตรฐาน ได้แก่ Hybrid Search → Reranker → ส่ง 5 อันดับแรกให้ LLM การเพิ่มขึ้นของ Latency อยู่ที่ประมาณ 100〜300ms ซึ่งอยู่ในระดับที่ยอมรับได้สำหรับการใช้งานระดับ Enterprise
3. การระเบิดของต้นทุนจากการขยายตัวของ Prompt
เมื่อเริ่มส่ง chunk จำนวนมากไปยัง LLM เพื่อเพิ่มความแม่นยำในการค้นหา การใช้ token จะพุ่งสูงขึ้นอย่างรวดเร็ว context ขนาด 10 chunk × 500 token = 5,000 token จะผลักดันต้นทุนต่อ 1 request ขึ้นไปในระดับเซนต์ และอาจสร้างความแตกต่างได้ถึงหลักพันดอลลาร์ต่อเดือน
วิธีแก้ไข: ใช้ reranker เพื่อคัดเลือกเฉพาะอันดับต้น และจำกัด chunk ที่ส่งให้ LLM ไว้ที่ 3〜5 รายการ นอกจากนี้ การสรุปเนื้อหา chunk (Abstractive Summarization) ภายใน search pipeline ก็เป็นวิธีที่มีประสิทธิภาพในการลดจำนวน token การปรับต้นทุนให้เหมาะสมจำเป็นต้องดำเนินการควบคู่ไปกับการปรับแต่งความแม่นยำ
คำถามที่พบบ่อย
Q1: การค้นหาแบบ Hybrid สามารถคาดหวังการปรับปรุงความแม่นยำได้มากเพียงใด?
ขึ้นอยู่กับโดเมนและลักษณะของข้อมูล แต่จากงานวิจัยทางวิชาการหลายชิ้นและการวัดผลจริงของเราพบว่า มีการปรับปรุง Hit Rate@5 ที่ 15〜30% เมื่อเทียบกับการใช้ Dense เพียงอย่างเดียว โดยเฉพาะอย่างยิ่ง query ที่มีคำนามเฉพาะหรือตัวเลขจะมีอัตราการปรับปรุงที่สูงกว่า อย่างไรก็ตาม ไม่ได้มีการปรับปรุงอย่างสม่ำเสมอในทุกประเภทของ query และสำหรับ query ที่มีความหมายคลุมเครือ อาจให้ผลลัพธ์ใกล้เคียงกับการใช้ Dense เพียงอย่างเดียว
Q2: Agentic RAG มีปัญหาเรื่อง Latency หรือไม่?
ซึ่ง RAG แบบดั้งเดิมจะตอบสนองภายใน 1〜3 วินาที แต่ Agentic RAG อาจใช้เวลาถึง 5〜15 วินาที แนวทางแก้ไขที่ใช้งานได้จริง ได้แก่ การใช้ streaming response เพื่อลดเวลารอที่รู้สึกได้จริง การกำหนดขีดจำกัดจำนวนขั้นตอน และการประเมินความซับซ้อนของ query ล่วงหน้าเพื่อ routing query ที่ง่ายไปยัง Naive RAG ไม่จำเป็นต้องทำให้ query ทุกรายการเป็นแบบ Agentic
Q3: RAG ยังคงใช้งานได้จริงสำหรับภาษาที่มีทรัพยากรน้อยหรือไม่?
ใช้งานได้จริง แต่ต้องการการปรับแต่งเพิ่มเติม จากประสบการณ์ RAG ภาษาลาวของเรา สิ่งที่สำคัญเป็นพิเศษมี 3 ประการ ได้แก่ การเลือก Embedding Model (จำเป็นต้องใช้ Model ที่รองรับหลายภาษา) การทำ Chunking ที่รองรับภาษา (การตรวจจับขอบเขตของคำ) และการจัดเตรียมข้อมูลสำหรับการประเมิน (การทำ Annotation โดยมนุษย์) ก่อนที่จะยอมแพ้ว่า "ความแม่นยำไม่เพียงพอ" จากการใช้เครื่องมือทั่วไปโดยตรง มีคุณค่าที่ควรลองทำ Preprocessing เฉพาะภาษาก่อน สามารถดูรายละเอียดเพิ่มเติมได้ที่คู่มือการสร้าง AI Chatbot ภาษาลาว
สรุป — รายการตรวจสอบการตัดสินใจออกแบบ RAG สำหรับระบบ Production
รวบรวมการตัดสินใจด้านการออกแบบที่ควรตรวจสอบในการเปลี่ยนผ่านจาก PoC สู่ Production
- Chunking ได้รับการปรับให้เหมาะสมกับ Domain และภาษาหรือไม่? มีการประนีประนอมด้วยการแบ่งแบบ Fixed-length หรือเปล่า?
- มีการ Implement Hybrid Search ร่วมกับ BM25 ไม่ใช่แค่ Dense Search เพียงอย่างเดียวหรือไม่?
- มีการใช้ Reranker เพื่อ Re-scoring ผลลัพธ์การค้นหาหรือไม่?
- มีการพิจารณานำ Agentic RAG มาใช้สำหรับ Composite Query หรือไม่?
- Pipeline การประเมิน Faithfulness / Context Relevance ถูกผนวกเข้าใน CI/CD หรือไม่?
- มีการตั้งค่า Monitoring และ Alert สำหรับต้นทุน (Token Consumption) หรือไม่?
การนำ RAG ขึ้น Production ไม่ใช่ปัญหาที่แก้ได้ด้วยเทคโนโลยีเดียว การสะสมการตัดสินใจด้านการออกแบบที่เหมาะสมในแต่ละ Layer ได้แก่ Chunking, การค้นหา, Reranking, การสร้างข้อความ และการประเมินผล จะช่วยลด Accuracy Gap ระหว่าง PoC กับ Production ได้ แนวทางที่มั่นคงที่สุดคือเริ่มต้นด้วยการนำ Hybrid Search และ Evaluation Pipeline มาใช้ก่อน จากนั้นจึงขยายไปสู่ Agentic RAG ตามความซับซ้อนของ Query
ข้อมูลผู้เขียน
Yusuke Ishihara
เริ่มเขียนโปรแกรมตั้งแต่อายุ 13 ปี ด้วย MSX หลังจบการศึกษาจากมหาวิทยาลัย Musashi ได้ทำงานพัฒนาระบบขนาดใหญ่ รวมถึงระบบหลักของสายการบิน และโครงสร้าง Windows Server Hosting/VPS แห่งแรกของญี่ปุ่น ร่วมก่อตั้ง Site Engine Inc. ในปี 2008 ก่อตั้ง Unimon Inc. ในปี 2010 และ Enison Inc. ในปี 2025 นำทีมพัฒนาระบบธุรกิจ การประมวลผลภาษาธรรมชาติ และแพลตฟอร์ม ปัจจุบันมุ่งเน้นการพัฒนาผลิตภัณฑ์และการส่งเสริม AI/DX โดยใช้ generative AI และ Large Language Models (LLM)
