เจาะลึก RAG Architecture ที่ไม่ใช่แค่การทำ DEMO หรือ PoC: จากปัญหา PDF ภาษาไทย สู่สถาปัตยกรรมระดับเข้มข้นสำหรับการใช้งานจริง Production
การ implement ต่อ LLM เข้ากับแอปพลิเคชันเพื่อทำเดโม RAG สั้นๆ เป็นเรื่องที่ง่ายสุดๆ ครับ
แต่มันจะกลายเป็นเรื่องที่ยากและปวดหัวจริงๆ เมื่อเริ่มทำกับเอกสารต้นทาง ที่ไม่ใช่ก้อน String สวยๆ ที่เรา mock หรือทำตัวอย่างขึ้นมาใน Array แต่เป็นเอกสารจริงในการทำงาน ตามสถานการณ์ต่างๆ
ผมได้บทเรียนนี้ตอนที่ลองนำ PDF ท่องเที่ยวภาษาไทยเข้าสู่ Document Pipeline เพื่อทำ RAG --> อ่านได้ที่บทความนี้ "Why Markdown Is the Ultimate AI-Native File Format A War Story from Building NEXT4I" หรือ "ทำไมไฟล์ Markdown (.md) ถึงคือที่สุดในยุค AI บทเรียนจากสงคราม PDF ของผม" https://www.next4i.com/dev-notes/th/markdown-the-ultimate-ai-native-dev-th
พอใช้เครื่องมือสกัดข้อความจาก PDF โดยตรง ตัวอักษรที่มีหัวแบบ ก ถ ภ บนพื้นหลังสีสดกลับกระจัดกระจาย สระลอย วรรณยุกต์อยู่ผิดตำแหน่ง วรรคตอนหายไป พอเปลี่ยนมาแปลงทั้งหน้าเป็นรูปภาพเพื่อรัน OCR สีพื้นหลังกับลายน้ำก็กลบข้อความจนอ่านไม่ออก ครั้นจะแปลงเป็นภาพขาวดำเพื่อให้ตัวหนังสือคมชัดขึ้น บริบทในแผนภาพ กราฟ และรูปถ่ายก็หายไปอีก เมื่อลองใช้ AI หลายโมเดลมาช่วยอ่าน ข้อความที่ได้จากแต่ละตัวก็ไม่ตรงกัน สุดท้ายต้องให้คนมาตรวจซ้ำและยังเจอคำสะกดผิดอยู่ดี
ให้ลองนึกภาพเวลาเราทำ OCR ถ่ายรูปหน้าเราคู่กับบัตรประชาชนสิครับ แล้วระบบเอาข้อมูลบัตรประชาชนมากรอกใส่ฟอร์มให้เรา บางทีระบบยังต้องเปิด Field ให้เรากรอกหรือแก้ไขข้อมูลให้ถูกต้องเลย การนำข้อมูลเข้าระบบเนี่ย เพิ่งแค่ step แรกเองนะครับของการทำ RAG และนี่แหล่ะคือ Real-World ของจริง
ประสบการณ์ต่างๆนั้นทำให้มุมมองที่ผมมีต่อ RAG (Retrieval-Augmented Generation) เปลี่ยนไปโดยสิ้นเชิง
RAG ไม่ใช่แค่การทำงานของฝั่ง Prompt Engineering แต่มันคือ ระบบ Data Engineering และ Information Retrieval ขนาดใหญ่ ที่มี LLM นั่งรอรับบริบทอยู่ที่ปลายทาง
บทความนี้จะพาทุกท่านผ่าสถาปัตยกรรม RAG ผ่านประเด็นต่อไปนี้ครับ:
การแยก Pipeline ฝั่ง Ingestion ออกจาก Query อย่างเด็ดขาด
การสกัดเอกสารและการเลือก Chunking Strategy
ความเป็นจริงของ Embeddings และ Vector Space
Dense Search, Sparse Search (BM25) และ Hybrid Retrieval
การผูกระบบ Authorization เข้ากับขั้นตอน Retrieval
ขอบเขตการวัดผล (Evaluation Boundaries)
ตัวอย่างโค้ดกลไกจำลองด้วย Python
โค้ดในบทความนี้ถูกปรับให้เป็นแบบ Generic และ Sanitized เพื่ออธิบายกลไกเชิงแนวคิด ไม่ใช่โปรดักชันแอปพลิเคชันที่พร้อมใช้ทันที สำหรับชื่อ Provider, Model ID, SDK Calls และการต่อเข้ากับระบบจริง จำเป็นต้องตรวจสอบกับเอกสารทางการของเวอร์ชันที่คุณใช้งานก่อนเสมอ
3 ข้อจำกัดของ Model AI ที่ทำให้เราต้องใช้ RAG
เมื่อเรานำ LLM มาใช้งานโดยไม่เชื่อมต่อกับระบบภายนอก เราจะเจอกำแพงสำคัญ 3 ด้าน:
1. ขอบเขตความรู้สิ้นสุดตามรอบเทรน (Knowledge Cutoff)
โมเดลไม่รู้เหตุการณ์ที่เพิ่งเกิดขึ้น ไม่ทราบนโยบายภายในบริษัท และไม่เห็นเอกสารที่เพิ่งอัปเดตเมื่อวาน
2. ขีดจำกัดของ Context Window และต้นทุน
การยัดเอกสารทั้งคลังเข้าไปใน Prompt ทุกครั้งทำไม่ได้จริง ทั้งในแง่ของต้นทุน Token ค่าความหน่วง (Latency) และอาการที่โมเดลให้ความสำคัญกับเนื้อหาตรงกลางลดลง (Lost in the Middle)
3. ขาดความสามารถในการตรวจสอบที่มา (Non-verifiability)
คำตอบที่โมเดลสร้างขึ้นมาด้วยความมั่นใจ ไม่ได้เป็นหลักฐานยืนยันความถูกต้องในตัวเอง หากผู้ใช้งานไม่สามารถคลิกย้อนกลับไปดูเอกสารต้นทางที่ได้รับอนุญาตได้ ความมั่นใจนั้นก็ไม่มีประโยชน์
RAG เข้ามาแก้ปัญหาเหล่านี้ด้วยการค้นหาเฉพาะท่อนข้อความที่เกี่ยวข้อง แล้วนำมาประกบเข้ากับคำถามก่อนส่งให้โมเดลตอบ วิธีนี้ช่วยให้คำตอบอิงอยู่บนหลักฐาน (Grounding) และตรวจสอบที่มาได้ แต่ไม่ได้แปลว่าผลลัพธ์จะถูกต้อง 100% หรือมีความปลอดภัยในตัวเองโดยอัตโนมัติ
RAG คือ 2 Pipeline ที่แยกออกจากกัน ไม่ใช่การทำจบในขั้นตอนเดียว (Ingestion Pipeline, Query Pipeline)
ภาพจำลองสถาปัตยกรรมที่ถูกต้อง ควรแบ่งการทำงานออกเป็น 2 กระบวนการที่ไม่ผูกติดกัน (Decoupled):
[ Ingestion Pipeline (ทำงานเบื้องหลัง / Offline) ]
เอกสารดิบ (PDF, Markdown, Database)
|
v
สกัดข้อความและทำความสะอาด (Extract & Clean)
|
v
ตัดแบ่งเป็นก้อนข้อความ (Chunking)
|
v
สร้าง Embeddings และแนบ Metadata
|
v
จัดเก็บลงใน Searchable Index / Vector Store
[ Query Pipeline (ทำงานเมื่อมีคำขอ / Online) ]
คำถามจากผู้ใช้
|
v
ตรวจสอบตัวตนและขอบเขตสิทธิ์ (Identity & Permission Scope)
|
v
ค้นหาก้อนข้อความที่เกี่ยวข้อง (Retrieve Candidate Chunks)
|
v
กรองสิทธิ์และจัดอันดับซ้ำ (Filter & Optional Rerank)
|
v
ประกอบ Prompt พร้อมแหล่งอ้างอิง (Context + Citations)
|
v
ให้ LLM สรุปและเรียบเรียงคำตอบ (LLM Generation)
|
v
ส่งคืนคำตอบพร้อมจุดอ้างอิงที่ตรวจสอบได้
เหตุผลที่เราต้องแยกสองฝั่งนี้ออกจากกัน เพราะเอกสารมีการอัปเดตตามรอบของมันเอง ส่วนคำถามของผู้ใช้เข้ามาตลอดเวลา ความผิดพลาดในการสกัดข้อความควรถูกจัดการตั้งแต่ฝั่ง Ingestion ไม่ใช่ปล่อยให้ระบบมาเจอปัญหาระหว่างที่ผู้ใช้กำลังรอคำตอบ และการเปลี่ยนสิทธิ์การเข้าถึงข้อมูล ก็ไม่ควรต้องส่งผลให้เราไปทำ Ingestion ใหม่
คุณภาพฝั่ง Ingestion คือตัวกำหนดคุณภาพของการค้นหา
คำว่า "Garbage In, Garbage Out" อธิบายโลกของ RAG ได้ตรงที่สุดครับ
เอกสารที่คนเปิดอ่านแล้วดูปกติ อาจกลายเป็นข้อมูลขยะสำหรับระบบค้นหาได้ทันทีหลังผ่านการสกัด เช่น:
Header และ Footer ซ้ำๆ ที่ติดมาทุกหน้า
ตารางข้อมูลที่ถูกแปลงเป็นข้อความแบนราบจนอ่านไม่รู้เรื่องว่าคอลัมน์ไหนคู่กับแถวไหน
ข้อความที่ถูกเก็บเป็นพิกัดตัวอักษรแทนที่จะเป็นประโยคที่ต่อเนื่องกัน
ลายน้ำหรือกราฟิกที่แทรกเข้ามาปนกับเนื้อหา
แผนภาพที่ความหมายทั้งหมดขึ้นอยู่กับรูป ไม่ได้มีคำอธิบายเป็นตัวอักษร
เอกสารเก่าและเอกสารใหม่ถูกเก็บปนกันโดยไม่มีเวอร์ชันกำกับ
ระบบ Ingestion ที่ดีจึงต้องเก็บมากกว่าแค่ข้อความดิบๆ แต่ต้องเก็บ Metadata ที่ชัดเจน เช่น Document ID, Version, หมายเลขหน้า, ชื่อหัวข้อ, วันที่อัปเดต, Tenant ID และระดับสิทธิ์การเข้าถึง
ความท้าทายของการตัด Chunk ในภาษาไทย
ตัวอย่างการตัด Chunk ส่วนใหญ่มักออกแบบบนภาษาอังกฤษที่ใช้การเคาะวรรคหรือเครื่องหมายจุดในการแบ่งคำและประโยค แต่ภาษาไทยไม่ได้มีโครงสร้างแบบนั้น
1. การเว้นวรรคที่เปลี่ยนความหมาย (Ambiguous Boundaries)
ลองดูตัวอย่างข้อความนี้ครับ:
ตากลมนั่งมองตากลม
หากระบบตัดคำหรือแบ่งท่อนผิด:
ท่อนหนึ่งอาจหมายถึง "ตา / กลม" (ดวงตากลมโต)
อีกท่อนหนึ่งอาจหมายถึง "ตาก / ลม" (นั่งรับลม)
เมื่อความหมายของ Chunk เพี้ยน ค่า Vector Embedding ก็จะพาความหมายหลงทางไปคนละทิศละทาง ผู้ใช้ถามเรื่องการพักผ่อนตากลม แต่ระบบอาจไปดึงเรื่องเกี่ยวกับดวงตามาตอบ
2. ประโยคเงื่อนไขที่ข้อความอยู่ห่างกันมาก (Long-dependency)
ข้อมูลจำพวกระเบียบของบริษัท ข้อมูลกฎหมายหรือสัญญาภาษาไทย ประโยคเงื่อนไขมักเขียนยาวต่อเนื่องกันหลายบรรทัด:
"พนักงานที่ไม่ปฏิบัติตามมาตรการความปลอดภัยขั้นต้น และส่งผลให้เกิดความเสียหายต่อทรัพย์สินของบริษัทที่มีมูลค่าเกินหนึ่งแสนบาทขึ้นไป จะถูกลงโทษทางวินัยโดยการพักงาน" ถ้าใช้การตัดแบบกำหนดความยาวตายตัว (Fixed-size Chunking) โดยไม่ดูโครงสร้าง ประโยคอาจถูกหั่นครึ่ง ท่อนแรกมีแต่การกระทำแต่ไม่ทราบบทลงโทษ ส่วนท่อนหลังมีบทลงโทษแต่ไม่รู้ว่าใครทำอะไร เมื่อมีคำถามเข้ามา ระบบค้นหาอาจดึงไปได้เพียงท่อนเดียว ทำให้ข้อมูลที่ส่งให้ AI ไม่สมบูรณ์
3. เครื่องหมายจุด (.) ที่ไม่ใช่การจบประโยค
ในภาษาไทย เครื่องหมายจุดมักใช้กับคำย่อ ยศ ตำแหน่ง และเวลา:
ศ.ดร.สมชาย ... พ.ร.บ. ... อ.เมือง จ.เชียงใหม่ ... 09.00 น.
ถ้าใช้ Text Splitter ทั่วไปที่สั่งให้ตัดเมื่อเจอเครื่องหมายจุด ระบบจะหั่นข้อความออกมาเป็นก้อนเล็กๆ ที่ไร้ความหมาย เช่น เหลือแค่คำว่า "ดร.สมชาย" หรือ "พ.ร.บ." ซึ่งเปลืองทั้ง Token และทำให้ระบบ Index ทำงานแย่ลง
แนวทางที่ช่วยลดปัญหานี้เช่น:
ใช้ Semantic Chunking ที่คอยดูการเปลี่ยนบริบทของเนื้อหา
ใช้เครื่องมือตัดคำภาษาไทย เช่น PyThaiNLP ร่วมกับ Custom Dictionary สำหรับคำเฉพาะและคำย่อ
กำหนด Overlap ระหว่างรอยต่อของ Chunk เพื่อไม่ให้ความหมายของประโยคขาดออกจากกัน
ใช้โครงสร้างแบบ Parent-Child Chunks
ทั้งนี้ ค่าพารามิเตอร์ที่เหมาะสมขึ้นอยู่กับลักษณะเอกสารของแต่ละระบบ การกำหนดขนาด Chunk หรือเปอร์เซ็นต์ Overlap ต้องผ่านการทดสอบกับชุดคำถามจริง ไม่ควรคัดลอกตัวเลขมาใช้ หรือใช้ค่าตายตัวโดยไม่วัดผล
กลยุทธ์การตัด Chunk และข้อดีข้อเสีย
Fixed-size Chunking with Overlap
การตัดตามจำนวนตัวอักษรหรือ Token ที่กำหนดและมีส่วนซ้อนทับกัน ข้อดีคือทำง่ายและคาดเดาได้ แต่ข้อเสียคืออาจตัดผ่ากลางประโยคหรือโครงสร้างสำคัญ
Recursive Character Text Splitting
พยายามตัดตามลำดับชั้นของโครงสร้างเอกสาร เช่น ย่อหน้า (\n\n) -> บรรทัด (\n) -> การเว้นวรรค วิธีนี้ให้ผลลัพธ์ที่ดี แต่เอกสารต้นทางต้องมีโครงสร้างที่ชัดเจน
Semantic Chunking
ใช้ Embedding คำนวณระยะห่างของความหมายระหว่างประโยค เมื่อทิศทางของเนื้อหาเปลี่ยนเกินเกณฑ์ที่ตั้งไว้จึงค่อยขึ้น Chunk ใหม่ วิธีนี้มีข้อดีคือรักษาความหมายได้ดี แต่ต้องแลกกับค่าใช้จ่ายและเวลาในการประมวลผลที่สูงขึ้น
Parent-Child Chunking
ค้นหาด้วย Chunk ลูกขนาดเล็กเพื่อให้ได้ความแม่นยำสูง แต่ส่ง Chunk แม่ขนาดใหญ่ที่มีบริบทแวดล้อมครบถ้วนไปให้ LLM อ่าน วิธีนี้ตอบโจทย์เรื่องความลึกของเนื้อหา แต่การออกแบบระบบจัดเก็บและการประกอบ Prompt จะซับซ้อนขึ้น
การตัด Chunk ควรถูกมองเป็นการตัดสินใจด้านการค้นหา ไม่ใช่แค่การจัดหน้าข้อความ เพราะขนาดของ Chunk จะเป็นตัวกำหนดหลักฐานที่ AI จะได้เห็น
Embeddings คือพิกัด ไม่ใช่ข้อเท็จจริง
การทำ Text Embedding คือการแปลงข้อความให้อยู่ในรูปเวกเตอร์ตัวเลข ข้อความที่มีความหมายใกล้เคียงกันจะมีพิกัดอยู่ใกล้กันใน Vector Space
กลไกนี้ช่วยให้เราค้นหาด้วยความหมายได้ แต่เวกเตอร์ไม่ได้เป็นตัวพิสูจน์ความจริง และตัวมันเองไม่รู้ว่าเอกสารชุดไหนเป็นเอกสารเก่าที่ยกเลิกไปแล้ว เว้นแต่ระบบของเราจะมี Metadata และตรรกะการกรองข้อมูลคอยกำกับ
ตัวอย่าง Implementation ด้วย Python (In-Memory Retrieval & Query Pipeline)
เพื่อให้เห็นภาพการทำงานจริงของ Query Pipeline ในจุดเดียว ตัวอย่างโค้ด Python ด้านล่างนี้จำลองตั้งแต่การคำนวณ Cosine Similarity, การคัดกรองขอบเขตสิทธิ์ (Permission Filtering) ของผู้ใช้ก่อนค้นหา, การคัดเลือก Top-K Chunks ไปจนถึงการประกอบ Prompt ส่งให้ LLM สร้างคำตอบ:
import math
def cosine_similarity(vec_a, vec_b):
"""คำนวณ Cosine Similarity ระหว่างเวกเตอร์ 2 ตัว"""
if len(vec_a) != len(vec_b) or len(vec_a) == 0:
raise ValueError("ขนาดของเวกเตอร์ต้องเท่ากันและไม่เป็นศูนย์")
dot_product = sum(a * b for a, b in zip(vec_a, vec_b))
norm_a = math.sqrt(sum(a * a for a in vec_a))
norm_b = math.sqrt(sum(b * b for b in vec_b))
if norm_a == 0 or norm_b == 0:
raise ValueError("ไม่สามารถคำนวณ Cosine Similarity กับเวกเตอร์ที่เป็นศูนย์ได้")
return dot_product / (norm_a * norm_b)
def answer_with_rag(question, user, knowledge_base, top_k=2, create_embedding=None, generate_answer=None):
"""จำลองขั้นตอนการทำงานของ RAG Query Pipeline แบบครบวงจร"""
# 1. แปลงคำถามของผู้ใช้เป็น Query Vector
query_vector = create_embedding(question)
# 2. คัดกรองสิทธิ์ (Permission & Tenant Scope) ก่อนทำการค้นหา
# หัวใจสำคัญคือ AI ต้องไม่เห็นข้อมูลที่ผู้ใช้คนนั้นไม่มีสิทธิ์เข้าถึง
authorized_chunks = [
chunk for chunk in knowledge_base
if chunk["tenant_id"] == user["tenant_id"] and user["role"] in chunk["allowed_roles"]
]
# 3. Retrieval: คำนวณความคล้ายคลึงและจัดอันดับ Top-K
ranked_chunks = [
{**chunk, "score": cosine_similarity(query_vector, chunk["embedding"])}
for chunk in authorized_chunks
]
ranked_chunks.sort(key=lambda item: item["score"], reverse=True)
selected_chunks = ranked_chunks[:top_k]
# 4. Augmentation: ประกอบ Context พร้อมจุดอ้างอิง (Citations)
context_text = "\n\n".join([f"[ID: {c['id']}] {c['content']}" for c in selected_chunks])
# 5. Generation: ส่งต่อให้ LLM ตอบตามหลักฐานจริง
instruction = "คุณคือ AI ผู้ช่วย จงตอบคำถามโดยอิงจาก Context ที่ให้เท่านั้น หากไม่มีข้อมูลให้ตอบว่าไม่พบข้อมูล"
answer = generate_answer(
instruction=instruction,
question=question,
context=context_text
)
return {
"answer": answer,
"sources": [{"id": c["id"], "score": round(c["score"], 4)} for c in selected_chunks]
}
หัวใจสำคัญของตัวอย่างนี้คือ การคัดกรองขอบเขตสิทธิ์ (Permission Scope) ต้องทำก่อนที่ก้อนข้อความจะถูกส่งไปเป็น Context ของ AI ในระบบจริงระดับองค์กร เราจะใช้ Row-Level Security (RLS), Policy Engine, Document ACL หรือ Metadata Filtering บน Vector Database แทนการวนลูปในหน่วยความจำครับ
Dense Search อย่างเดียวอาจไม่พอ (ทำไมต้อง Hybrid Search?)
การค้นหาด้วยเวกเตอร์ (Dense Search) ถนัดเรื่องการจับความหมายที่คล้ายคลึงและคำพ้องความหมาย (Synonyms)
แต่สำหรับข้อมูลที่มีความเฉพาะเจาะจงสูง เช่น รหัสสินค้า (SKU), หมายเลข Serial Number, เลขมาตราทางกฎหมาย, รหัส Error Code หรือชื่อเฉพาะ การค้นหาแบบ Dense มักจะสู้การค้นหาด้วยคีย์เวิร์ดตรงๆ ไม่ได้
รูปแบบที่นิยมใช้จริงในงาน Production จึงมักประกอบด้วย:
Dense Retrieval: เด่นเรื่องความหมายและบริบทที่ใกล้เคียง
Sparse Retrieval (เช่น BM25): เด่นเรื่องคำค้นที่เจาะจงและตรงตัว
Hybrid Retrieval: ดึงผลลัพธ์จากทั้งสองระบบมารวมกัน แล้วจัดอันดับความแม่นยำใหม่ด้วยเทคนิค Reciprocal Rank Fusion (RRF) หรือ Cross-Encoder Re-ranker
กลไกการ Re-rank ไม่ได้การันตีว่าจะดีขึ้นเสมอไปในข้อมูลทุกประเภท จึงจำเป็นต้องทดสอบวัดผลและคำนึงถึง Latency ด้วย
5 จุดทดสอบสำคัญก่อนนำ RAG ขึ้น Production
1. ความเข้ากันได้ของภาษากับ Embedding Model
อย่าเพิ่งสรุปว่าโมเดล Embedding ที่ได้คะแนนดีบน benchmarks ภาษาอังกฤษจะให้ผลดีกับเอกสาร อื่นๆสำหรับภาษาไทยเสมอไป ควรนำโมเดลมาวัดผลกับข้อมูลจริง จะแม่ยำมากกว่า
2. คุณภาพการสกัดข้อมูลและ version ของเอกสาร
ควรมีระบบมอนิเตอร์ การสกัดข้อความที่ไม่ผ่าน หรือข้อมูลต้นฉบับเป็นตาราง แล้วสกัดโครงสร้างพัง และตรวจเช็กให้แน่ใจว่าระบบไม่อ่านเอกสาร version เก่า เพราะระบบค้นหาไม่สามารถกู้เนื้อหาที่กระบวนการ Ingestion ทำตกหล่นไปได้
3. ปัญหาความกำกวมใน Context (Context Pollution)
การดึงข้อความมาเยอะๆ (High Top-K) ไม่ได้แปลว่าดีเสมอไป บริบทที่รกเกินไปอาจรบกวน บริบท หรือ ความแม่นยำของโมเดล เพิ่มต้นทุน Token และทำให้ตอบหลงประเด็น ควรทดสอบเพื่อหาจำนวน Chunk ที่ให้ข้อมูลครบถ้วนโดยไม่ ส่งข้อมูลหลากหลายนัยะหรือ บริบทจนเกินไป
4. ความปลอดภัยและการแยกสิทธิ์ข้อมูล (Security & Isolation)
ระบบคัดกรองสิทธิ์ต้องอยู่นอกตัวโมเดลและทำงานตั้งแต่ขั้นตอน Retrieval ควรทดสอบกรณีการเข้าถึงข้าม Tenant, ผู้ใช้ถูกลดสิทธิ์, ข้อมูลถูกลบ และเช็คว่าแหล่งอ้างอิงของคำตอบไม่ได้เอาข้อมูล หรือข้อความที่ผู้ใช้ไม่มีสิทธิ์อ่าน
5. กลยุทธ์การวัดผล (Evaluation Strategy)
ใช้คำถามหลัก 3 ข้อในการประเมิน:
Context Relevance: เอกสารที่ดึงมา ตรงกับสิ่งที่ถามจริงหรือไม่
Groundedness / Faithfulness: คำตอบที่ LLM สร้างขึ้น อยู่ในกรอบหรือข้อมูลของเอกสารที่ส่งให้ไป หรือโมเดลแต่งเรื่องเพิ่ม
Answer Relevance: คำตอบตรงกับความต้องการของผู้ใช้หรือไม่
สรุปบทเรียนที่ผมได้รู้
RAG เป็นเหมือนเครื่องมือ หรือสะพานเชื่อมระหว่างความสามารถในการใช้เหตุผลของ LLM กับข้อเท็จจริงในโลกภายนอก แต่ระบบจะดีได้หรือไม่นั้น ขึ้นอยู่กับสถาปัตยกรรมที่เราออกแบบรอบๆ
DEMO สั้นๆ บนเครื่องของเราอาจดูง่ายเพราะเราใช้ข้อมูลตัวอย่างที่สะอาดและตัดทอนมาแล้ว แต่โลกการทำงานจริงจะบังคับให้เราต้องเผชิญหน้ากับทั้งเรื่องคุณภาพเอกสาร การจัดการสิทธิ์ เวอร์ชันของข้อมูล และการวัดผล
สำหรับผม งานส่วนใหญ่ของ RAG จึงเริ่มตั้งแต่ก่อนจะเขียน Prompt:
จัดการและคุมเวอร์ชันของคลังข้อมูลให้เป็นระเบียบ
เลือกวิธีตัดแบ่งข้อความที่รักษาความหมายได้อย่างถูกต้อง
ออกแบบระบบค้นหาที่รองรับทั้งความหมายและคีย์เวิร์ดเฉพาะ
กรองสิทธิ์การเข้าถึงข้อมูลก่อนจะนำมาสร้าง Context
ถ้าเป็นไปได้ควรแนบจุดอ้างอิงที่มนุษย์สามารถตรวจสอบกลับได้เสมอ
ให้แยกวัดผลขั้นตอนค้นหากับขั้นตอนสร้างคำตอบออกจากกัน
Model AI มีหน้าที่เรียบเรียงคำตอบในขั้นตอนสุดท้าย แต่ข้อมูลที่มันจะได้เห็น ถูกตัดสินด้วย Pipeline ทั้งหมดที่เราสร้างขึ้นมาก่อนหน้านั้นแล้วครับ
ขอบคุณที่อ่านมาถึงตรงนี้ครับ
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
