RAG และ LLM ในปี 2026: Retrieval-Augmented Generation สำหรับสัมภาษณ์ Data Science

Retrieval-Augmented Generation (RAG) กลายเป็นสถาปัตยกรรมมาตรฐานสำหรับยึดผลลัพธ์ของ LLM ไว้กับข้อมูลที่เป็นข้อเท็จจริงและทันสมัย สำหรับการสัมภาษณ์งานสาย data science และวิศวกรรม AI ในปี 2026 คำถามเรื่อง RAG ปรากฏเคียงข้างหัวข้อ ML แบบดั้งเดิม โดยทดสอบทั้งการคิดเชิงออกแบบระบบและทักษะการลงมือพัฒนาจริง

ไปป์ไลน์ RAG ทำงานตั้งแต่ต้นจนจบอย่างไร

ระบบ RAG ทำงานสองเฟส: เฟสนำเข้าข้อมูล (ingestion) แบบออฟไลน์ ที่สร้างฐานความรู้ และ เฟสคิวรีแบบออนไลน์ ที่ดึงบริบทที่เกี่ยวข้องแล้วสร้างคำตอบ

ระหว่างการนำเข้า เอกสารดิบจะผ่านการทำความสะอาด การแบ่งชิ้น (chunking) และการฝัง (embedding) ก่อนจัดเก็บในฐานข้อมูลเวกเตอร์ ระหว่างการอนุมาน คิวรีของผู้ใช้จะเดินตามเส้นทางการฝังแบบเดียวกัน และการค้นหาเพื่อนบ้านใกล้สุดจะดึงชิ้นที่เกี่ยวข้องมากที่สุด ชิ้นเหล่านี้กลายเป็นส่วนหนึ่งของพรอมต์ LLM ยึดคำตอบที่สร้างขึ้นไว้กับเนื้อหาต้นทาง

# rag_pipeline.py
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough

# Offline: ingest documents into the vector store
def build_index(documents: list[str]) -> Chroma:
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=512,       # tokens per chunk
        chunk_overlap=64,     # overlap preserves context at boundaries
        separators=["\n\n", "\n", ". ", " "]
    )
    chunks = splitter.create_documents(documents)
    embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
    return Chroma.from_documents(chunks, embeddings)

# Online: retrieve + generate
def query(vectorstore: Chroma, question: str) -> str:
    retriever = vectorstore.as_retriever(
        search_type="mmr",    # Maximal Marginal Relevance for diversity
        search_kwargs={"k": 5, "fetch_k": 20}
    )
    prompt = ChatPromptTemplate.from_template(
        "Answer based on this context only:\n{context}\n\nQuestion: {question}"
    )
    chain = (
        {"context": retriever, "question": RunnablePassthrough()}
        | prompt
        | ChatOpenAI(model="gpt-4o", temperature=0)
    )
    return chain.invoke(question).content

ไปป์ไลน์นี้ครอบคลุมวงจรหลักของ RAG: แบ่งชิ้น ฝัง จัดเก็บ ดึง สร้าง พารามิเตอร์ search_type="mmr" รับประกันว่าชิ้นที่ดึงมานั้นทั้งเกี่ยวข้องและหลากหลาย ลดความซ้ำซ้อนในหน้าต่างบริบท

กลยุทธ์ Chunking ที่สำคัญจริง

Chunking กำหนดคุณภาพการดึงข้อมูลมากกว่าองค์ประกอบอื่นใด Chunking ที่ไม่ดีหมายความว่าตัวดึงข้อมูลคืนชิ้นส่วนที่ขาดบริบทหรือเจือจางสัญญาณด้วยเนื้อหาที่ไม่เกี่ยวข้อง

สามแนวทาง chunking ครองระบบใช้งานจริงในปี 2026:

Chunking ขนาดคงที่ แบ่งข้อความตามจำนวนโทเค็นที่กำหนด (โดยทั่วไป 256-512 โทเค็น) พร้อมการซ้อนทับ (overlap) นำไปใช้ง่าย แต่ตัดประโยคและความคิดกลางคัน

Semantic chunking ตรวจจับขอบเขตหัวข้อด้วยการวัดความคล้ายของการฝังระหว่างประโยคที่ต่อเนื่องกัน เมื่อความคล้ายลดต่ำกว่าเกณฑ์ ชิ้นใหม่จะเริ่มขึ้น แต่ละชิ้นจึงบรรจุความคิดที่ครบถ้วนแทนการตัดข้อความแบบสุ่ม

Late chunking ใช้โมเดลทรานส์ฟอร์มเมอร์กับเอกสารทั้งฉบับก่อน สร้างการฝังโทเค็นเชิงบริบท แล้วจึงแบ่งเป็นชิ้น วิธีนี้รักษาความสัมพันธ์ระยะไกลที่ chunking แบบดั้งเดิมทำลายไป

# semantic_chunking.py
import numpy as np
from sentence_transformers import SentenceTransformer

def semantic_chunk(text: str, threshold: float = 0.3) -> list[str]:
    """Split text where semantic similarity drops below threshold."""
    model = SentenceTransformer("all-MiniLM-L6-v2")
    sentences = text.split(". ")
    embeddings = model.encode(sentences)

    chunks, current_chunk = [], [sentences[0]]

    for i in range(1, len(sentences)):
        # Cosine similarity between consecutive sentences
        sim = np.dot(embeddings[i-1], embeddings[i]) / (
            np.linalg.norm(embeddings[i-1]) * np.linalg.norm(embeddings[i])
        )
        if sim < threshold:       # topic shift detected
            chunks.append(". ".join(current_chunk))
            current_chunk = [sentences[i]]
        else:
            current_chunk.append(sentences[i])

    chunks.append(". ".join(current_chunk))  # final chunk
    return chunks

ประเด็นสำคัญสำหรับการสัมภาษณ์: ขนาดชิ้นคือการแลกเปลี่ยนระหว่างความแม่นยำกับความครอบคลุม (precision-recall) ชิ้นเล็ก (100 โทเค็น) เพิ่มความแม่นยำในการดึงข้อมูลแต่ทำให้บริบทแตกกระจาย ชิ้นใหญ่ (1000 โทเค็น) รักษาบริบทแต่เจือจางความจำเพาะของการฝัง ระบบใช้งานจริงส่วนใหญ่ลงตัวที่ 256-512 โทเค็น พร้อมการซ้อนทับ 10-20%

ฐานข้อมูลเวกเตอร์และโมเดล Embedding ในการใช้งานจริง

ฐานข้อมูลเวกเตอร์จัดเก็บการฝังและรองรับการค้นหาเพื่อนบ้านใกล้สุดโดยประมาณ (ANN) ที่รวดเร็ว การเลือกชุดผสมระหว่างโมเดล embedding กับฐานข้อมูลเวกเตอร์ที่เหมาะสมส่งผลโดยตรงต่อความหน่วงและความแม่นยำในการดึงข้อมูล

โมเดล embedding ในปี 2026 รวมตัวอยู่ที่ตัวเลือกประสิทธิภาพสูงไม่กี่ตัว text-embedding-3-large ของ OpenAI (3072 มิติ) และทางเลือกโอเพนซอร์สอย่าง bge-m3 จาก BAAI หรือ embed-v4 จาก Cohere ให้การดึงข้อมูลหลายภาษาที่ทรงพลัง กระดานผู้นำ MTEB ยังคงเป็นเกณฑ์มาตรฐานในการเปรียบเทียบคุณภาพการฝัง

ฐานข้อมูลเวกเตอร์อย่าง Pinecone, Weaviate, Milvus, Qdrant และ pgvector ต่างก็มีการแลกเปลี่ยนที่ต่างกัน:

| ฐานข้อมูล | การทำดัชนี | บริการจัดการ | จุดแข็ง | |----------|----------|---------|----------| | Pinecone | กรรมสิทธิ์ | ใช่ | ความเรียบง่าย ขยายแบบ serverless | | Weaviate | HNSW | ใช่/โฮสต์เอง | การค้นหาแบบไฮบริด (เวกเตอร์ + BM25) | | Milvus | IVF, HNSW | ใช่/โฮสต์เอง | ชุดข้อมูลระดับพันล้าน | | Qdrant | HNSW | ใช่/โฮสต์เอง | การกรอง + จัดเก็บ payload | | pgvector | IVF, HNSW | โฮสต์เอง | การผสานกับ PostgreSQL |

สำหรับการอภิปรายในการสัมภาษณ์ ประเด็นสำคัญคือการเข้าใจอัลกอริทึม HNSW (Hierarchical Navigable Small World): มันสร้างกราฟหลายชั้นที่แต่ละโหนดเชื่อมกับเพื่อนบ้านใกล้สุด ทำให้ค้นหาได้ในระดับ O(log n) โดยแลกกับการใช้หน่วยความจำที่สูงขึ้น

การดึงข้อมูลแบบไฮบริด: ผสานการค้นหาแบบหนาแน่นและแบบเบาบาง

การค้นหาด้วยเวกเตอร์ล้วนล้มเหลวกับการจับคู่คีย์เวิร์ดแบบตรงตัวและคำหายาก การค้นหาเชิงคำศัพท์ล้วน (BM25) พลาดความคล้ายเชิงความหมาย การดึงข้อมูลแบบไฮบริดผสานทั้งสองเข้าด้วยกัน และในปี 2026 นี่คือค่าเริ่มต้นสำหรับระบบ RAG ใช้งานจริง

รูปแบบมาตรฐานใช้ Reciprocal Rank Fusion (RRF) เพื่อรวมผลลัพธ์ที่จัดอันดับแล้วจากตัวดึงข้อมูลทั้งสอง:

# hybrid_retrieval.py
from rank_bm25 import BM25Okapi
import numpy as np

def reciprocal_rank_fusion(
    dense_results: list[str],
    sparse_results: list[str],
    k: int = 60
) -> list[str]:
    """Merge dense (vector) and sparse (BM25) results using RRF."""
    scores: dict[str, float] = {}

    for rank, doc_id in enumerate(dense_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)

    for rank, doc_id in enumerate(sparse_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)

    # Sort by combined RRF score, highest first
    return sorted(scores.keys(), key=lambda d: scores[d], reverse=True)

การดึงข้อมูลแบบไฮบริดแก้ปัญหา "คำศัพท์ไม่ตรงกัน" เมื่อผู้ใช้ถามเรื่อง "การยกเลิกการสมัครสมาชิก" แต่เอกสารที่เกี่ยวข้องใช้คำว่า "นโยบายการยุติบัญชี" BM25 จับการซ้อนทับของคำที่ตรงกันแบบเป๊ะ ขณะที่การค้นหาด้วยเวกเตอร์จับความสัมพันธ์เชิงความหมาย

Reranking: ตัวกรองขั้นที่สอง

การดึงข้อมูลคืนรายชื่อผู้สมัคร Reranking จัดเรียงพวกมันตามความเกี่ยวข้องที่แท้จริง ตัวจัดอันดับใหม่แบบ cross-encoder อย่าง Cohere Rerank หรือ bge-reranker-v2.5-gemma2-lightweight ให้คะแนนแต่ละคู่คิวรี-เอกสารร่วมกัน สร้างคะแนนความเกี่ยวข้องที่แม่นยำกว่าความคล้ายแบบ bi-encoder อย่างมาก

ไปป์ไลน์การดึงข้อมูลสองขั้น — recall ขั้นแรกแบบกว้าง (ผู้สมัคร 50-100 อันดับแรกผ่านเวกเตอร์ + BM25) แล้วจัดอันดับใหม่อย่างแม่นยำ (5-10 อันดับแรกสำหรับพรอมต์) — เป็นมาตรฐานในการใช้งานจริง วิธีนี้คุมความหน่วงให้จัดการได้: ขั้นแรกใช้การค้นหา ANN ที่รวดเร็ว ขณะที่ cross-encoder ที่มีต้นทุนสูงประมวลผลเพียงชุดผู้สมัครเล็ก ๆ

Agentic RAG: ก้าวข้ามการดึงข้อมูลครั้งเดียวจบ

RAG แบบพื้นฐานดึงครั้งเดียวแล้วสร้าง Agentic RAG มอง LLM เป็นเอเจนต์ที่ใช้เหตุผล ตัดสินใจว่าเมื่อใดควรดึง ดึงอะไร และบริบทที่ดึงมาเพียงพอหรือไม่

ในปี 2026 agentic RAG เป็นรูปแบบหลักสำหรับคิวรีซับซ้อนที่ต้องใช้การให้เหตุผลหลายขั้น เอเจนต์สามารถ:

• ประเมินตนเอง: ประเมินว่าเอกสารที่ดึงมาตอบคำถามได้หรือไม่
• คิวรีใหม่: เรียบเรียงคิวรีค้นหาใหม่หากผลลัพธ์เริ่มต้นไม่เพียงพอ
• กำหนดเส้นทาง (routing): เลือกระหว่างแหล่งความรู้ต่าง ๆ (เวกเตอร์ DB, ฐานข้อมูล SQL, API)
• ตรวจสอบ: ตรวจสอบข้อเท็จจริงข้ามหลายข้อความที่ดึงมา

# agentic_rag.py
from langgraph.graph import StateGraph, END
from typing import TypedDict

class RAGState(TypedDict):
    question: str
    documents: list[str]
    generation: str
    retries: int

def retrieve(state: RAGState) -> RAGState:
    """Retrieve documents from vector store."""
    docs = vectorstore.similarity_search(state["question"], k=5)
    return {"documents": [d.page_content for d in docs]}

def grade_documents(state: RAGState) -> str:
    """Decide if documents are relevant enough to answer."""
    prompt = f"Are these documents relevant to: {state['question']}?\n"
    prompt += "\n".join(state["documents"])
    relevance = llm.invoke(prompt)  # returns 'relevant' or 'not_relevant'
    return "generate" if "relevant" in relevance.content else "rewrite"

def rewrite_query(state: RAGState) -> RAGState:
    """Reformulate the query for better retrieval."""
    new_query = llm.invoke(
        f"Rewrite this query for better search results: {state['question']}"
    )
    return {"question": new_query.content, "retries": state["retries"] + 1}

# Build the agent graph
workflow = StateGraph(RAGState)
workflow.add_node("retrieve", retrieve)
workflow.add_node("grade", grade_documents)      # conditional routing
workflow.add_node("rewrite", rewrite_query)
workflow.add_node("generate", generate_answer)

workflow.set_entry_point("retrieve")
workflow.add_edge("retrieve", "grade")
workflow.add_conditional_edges("grade", grade_documents,
    {"generate": "generate", "rewrite": "rewrite"})
workflow.add_edge("rewrite", "retrieve")          # retry loop
workflow.add_edge("generate", END)

รูปแบบนี้ — ดึง ให้คะแนน เลือกเรียบเรียงใหม่และลองอีกครั้ง — รู้จักกันในชื่อ Corrective RAG (CRAG) เฟรมเวิร์ก LangGraph จำลองเวิร์กโฟลว์เป็นกราฟวัฏจักรแบบมีทิศทางพร้อมการแตกกิ่งตามเงื่อนไข ทำให้เพิ่มขั้นตอนการตรวจสอบ จุดตรวจแบบ human-in-the-loop หรือการกำหนดเส้นทางหลายแหล่งได้ง่าย

Graph RAG: การดึงความรู้แบบมีโครงสร้าง

Graph RAG สกัดเอนทิตีและความสัมพันธ์จากเอกสารลงในกราฟความรู้ แล้วคิวรีทั้งกราฟและที่จัดเก็บเวกเตอร์ สถาปัตยกรรมนี้ลดอาการหลอน (hallucination) ในคิวรีเชิงข้อเท็จจริงด้วยการยึดคำตอบไว้กับความสัมพันธ์ของเอนทิตีที่ชัดเจนแทนความคล้ายของข้อความที่ไร้โครงสร้าง

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

Graph RAG โดดเด่นในคำถามที่ต้องให้เหตุผลหลายขั้น (multi-hop) เช่น "ทีมใดเป็นผู้นำโครงการที่ใช้เฟรมเวิร์กที่กล่าวถึงในเอกสาร X?" — คิวรีที่ต้องเชื่อมโยงข้อเท็จจริงข้ามหลายเอกสาร การค้นหาด้วยเวกเตอร์ล้วนทำได้ยากตรงนี้เพราะไม่มีชิ้นเดียวที่บรรจุคำตอบครบถ้วน

การประเมินระบบ RAG: เมตริกที่สำคัญ

การประเมิน RAG แบ่งเป็นเมตริกการดึงข้อมูลและเมตริกการสร้าง ทั้งสองต้องวัดแยกกันเพื่อวินิจฉัยจุดล้มเหลว

เมตริกการดึงข้อมูล:

• Recall@k: เอกสารที่เกี่ยวข้องปรากฏในผลลัพธ์ k อันดับแรกหรือไม่?
• MRR (Mean Reciprocal Rank): ผลลัพธ์ที่เกี่ยวข้องชิ้นแรกถูกจัดอันดับสูงเพียงใด?
• NDCG: การจัดอันดับตรงกับลำดับความเกี่ยวข้องในอุดมคติหรือไม่?

เมตริกการสร้าง:

• Faithfulness (ความซื่อตรง): คำตอบใช้เฉพาะข้อมูลจากบริบทที่ดึงมาหรือไม่? (วัดอาการหลอน)
• ความเกี่ยวข้องของคำตอบ: คำตอบตอบคำถามต้นฉบับหรือไม่?
• ความแม่นยำของบริบท: ชิ้นที่ดึงมาถูกใช้ในคำตอบจริงหรือไม่?

เฟรมเวิร์กอย่าง Ragas และ DeepEval ทำให้การประเมินเหล่านี้เป็นอัตโนมัติโดยใช้รูปแบบ LLM-เป็น-ผู้ตัดสิน (LLM-as-judge) คำถามสัมภาษณ์ data science ยอดนิยม นับวันยิ่งรวมการออกแบบการประเมิน RAG เข้าไป — เตรียมอธิบายวิธีวัดว่าระบบ RAG ทำงานถูกต้องหรือไม่

โหมดความล้มเหลวในการใช้งานจริงและการดีบัก

ระบบ RAG ล้มเหลวในแบบที่คาดเดาได้ การรู้รูปแบบเหล่านี้จำเป็นทั้งต่อการสัมภาษณ์และการใช้งานจริง

มลพิษในหน้าต่างบริบท เกิดขึ้นเมื่อชิ้นที่ดึงมามากเกินไปเจือจางสัญญาณที่เกี่ยวข้อง LLM ได้รับ 10 ชิ้นแต่มีเพียง 2 ชิ้นที่มีข้อมูลที่มีประโยชน์ วิธีแก้: ใช้ตัวจัดอันดับใหม่เพื่อกรอง และลดค่า top-k จากตัวดึงข้อมูล

สิ่งแปลกปลอมจาก chunking เกิดเมื่อการแบ่งขนาดคงที่ตัดประโยค ตาราง หรือบล็อกโค้ดกลางองค์ประกอบ ชิ้นที่ดึงมาไม่สมบูรณ์ทางไวยากรณ์และไร้ประโยชน์เชิงความหมาย Semantic chunking หรือการแบ่งที่รับรู้โครงสร้างเอกสาร (เคารพหัวข้อ ย่อหน้า code fence) แก้ปัญหานี้ได้

การเลื่อนไหลของ embedding (embedding drift) เกิดเมื่อโมเดล embedding ถูกอัปเดตแต่ที่จัดเก็บเวกเตอร์ยังบรรจุการฝังจากโมเดลเก่า คิวรีที่เข้ารหัสด้วยโมเดลใหม่จึงค้นหาในปริภูมิเวกเตอร์ที่สร้างโดยโมเดลเก่า ทำให้คุณภาพการดึงข้อมูลลดลง ทางแก้: ฝังคลังข้อมูลทั้งหมดใหม่หลังเปลี่ยนโมเดลทุกครั้ง

ดัชนีที่ล้าสมัย ส่งมอบข้อมูลที่ตกยุคเพราะไปป์ไลน์การนำเข้าตามหลังการอัปเดตเอกสาร ในระบบ machine learning สิ่งนี้คล้ายกับความเบี่ยงเบนระหว่างการฝึกกับการให้บริการ (training-serving skew) — ระบบดึงข้อมูลเห็นการกระจายของข้อมูลที่ต่างจากที่มีอยู่จริงในการใช้งาน

บทสรุป

• RAG ผสานการดึงข้อมูล (การค้นหาด้วยเวกเตอร์บนฐานความรู้) เข้ากับการสร้างของ LLM เพื่อให้คำตอบเชิงข้อเท็จจริงที่มีหลักฐานยึดโยงโดยไม่ต้องฝึกโมเดลใหม่
• กลยุทธ์ chunking มีผลต่อคุณภาพการดึงข้อมูลมากที่สุด — semantic chunking และ late chunking เหนือกว่าการแบ่งขนาดคงที่ในกรณีใช้งานส่วนใหญ่
• การดึงข้อมูลแบบไฮบริด (เวกเตอร์หนาแน่น + BM25 เบาบาง) พร้อม Reciprocal Rank Fusion เป็นค่าเริ่มต้นในการใช้งานจริง แก้ปัญหาคำศัพท์ไม่ตรงกันที่การค้นหาด้วยเวกเตอร์ล้วนจัดการไม่ได้
• ตัวจัดอันดับใหม่แบบ cross-encoder เพิ่มชั้นความแม่นยำหลังการดึงข้อมูลแบบกว้าง โดยประมวลผลเพียงชุดผู้สมัครเล็ก ๆ เพื่อคุมความหน่วงให้ยอมรับได้
• Agentic RAG (ดึง ให้คะแนน เรียบเรียงใหม่ ลองอีกครั้ง) และ Graph RAG (การสกัดความสัมพันธ์ของเอนทิตี) คือสองความก้าวหน้าทางสถาปัตยกรรมหลักของปี 2026 ที่รับมือคิวรี multi-hop ซับซ้อนซึ่ง RAG แบบพื้นฐานล้มเหลว
• การประเมินต้องแยกเมตริกการดึงข้อมูล (Recall@k, MRR) ออกจากเมตริกการสร้าง (faithfulness, ความเกี่ยวข้องของคำตอบ) เพื่อวินิจฉัยว่าไปป์ไลน์พังตรงไหน
• ความล้มเหลวในการใช้งานจริงที่พบบ่อยที่สุด — มลพิษในบริบท สิ่งแปลกปลอมจาก chunking การเลื่อนไหลของ embedding ดัชนีล้าสมัย — ล้วนมีทางแก้ที่ตรงไปตรงมาเมื่อระบุได้