<!– WordPress SEO Article Title (Exactly 55 characters

Kỹ Thuật RAG Chunking: Semantic Splitting & Eval-Driven

1. Vấn Nạn “Garbage In, Garbage Out” Trong Hệ Thống RAG & Cạm Bẫy Fixed Chunking

Khi một hệ thống Tạo sinh Tăng cường Truy xuất (Retrieval-Augmented Generation – RAG) trả về câu trả lời sai lệch, ảo giác (hallucination) hoặc bỏ sót thông tin quan trọng, phản xạ tự nhiên của hầu hết các kỹ sư là đổ lỗi cho mô hình ngôn ngữ lớn (LLM) hoặc mô hình nhúng (Embedding Model). Họ vội vàng chuyển từ GPT-4 sang Claude 3.5 Sonnet, thử nghiệm các reranker đắt đỏ, hoặc tinh chỉnh prompt hàng chục lần.

Tuy nhiên, phân tích thực nghiệm từ hàng nghìn truy vấn sản xuất cho thấy: Hơn 70% thất bại của RAG bắt nguồn từ tầng tiền xử lý dữ liệu — cụ thể là chiến lược phân đoạn văn bản (Chunking Strategy) nghèo nàn.

Đa số các dự án bắt đầu bằng phương pháp cắt cố định ngây thơ (Fixed-size Character/Token Chunking) có sẵn trong các framework như LangChain hoặc LlamaIndex:

Cách tiếp cận này xem văn bản như một chuỗi byte vô hồn. Thuật toán mù quáng đếm đủ 500 ký tự và chém ngang tài liệu, bất chấp vị trí đó đang nằm ở giữa một khối mã nguồn (code block), xé đôi một hàng trong bảng biểu tài chính, hoặc cắt rời một điều kiện logic if-else quan trọng. Khi vector database lưu trữ những phân đoạn què cụt này, quá trình truy xuất tương đồng cosine (Cosine Similarity) sẽ thu về những “mẩu rác ngữ nghĩa”. Khi đưa dữ liệu đầu vào khiếm khuyết vào LLM, kết quả nhận được không thể nào chính xác.

2. Vì Sao Cắt Đoạn Theo Số Lượng Token Làm Hỏng Tài Liệu Kỹ Thuật?

Tài liệu kỹ thuật (Technical Documentation), tài liệu API, hợp đồng pháp lý và báo cáo tài chính sở hữu cấu trúc thông tin phi tuyến tính và có tính liên kết phụ thuộc cực kỳ cao. Khi áp dụng kỹ thuật cắt token mù quáng, hệ thống sẽ gặp phải 3 “căn bệnh” chí mạng:

• Mất ngữ cảnh tiền đề (Loss of Premise): Một đoạn văn mô tả tham số API bị tách khỏi tiêu đề chứa tên endpoint (`POST /v1/payments/refund`). Đoạn chunk chỉ chứa các dòng tham số rời rạc, khiến vector embedding không thể liên kết với câu hỏi tìm kiếm về phương thức hoàn tiền.
• Phá hủy cấu trúc bảng và mã lệnh (Code & Table Severance): Một bảng Markdown 5 cột bị cắt ngang ở hàng thứ 3. Nửa dưới của bảng mất hoàn toàn dòng tiêu đề (Header row), biến các con số thống kê thành dữ liệu vô nghĩa. Tương tự, một hàm Python bị cắt đôi khiến LLM không hiểu biến số được khai báo từ đâu.
• Nhiễm bẩn không gian Vector (Vector Space Dilution): Một chunk quá lớn chứa cùng lúc 4 ý tưởng khác nhau sẽ tạo ra một vector trung bình mờ nhạt, trôi về tâm không gian và mất khả năng so khớp chính xác với các truy vấn cụ thể. Ngược lại, chunk quá nhỏ lại thiếu ngữ cảnh để LLM suy luận.

3. Phân Tách Theo Cấu Trúc (Structure-Aware & Markdown Splitting)

Giải pháp nền tảng đầu tiên trước khi dùng tới các mô hình AI là tôn trọng cấu trúc tự nhiên của định dạng tài liệu. Hầu hết tài liệu hiện đại đều được tổ chức dưới dạng Markdown, HTML hoặc cấu trúc phân cấp Header (H1 > H2 > H3 > Paragraph):

• MarkdownHeaderTextSplitter: Sử dụng các thẻ tiêu đề `#`, `##`, `###` làm ranh giới phân tách tự nhiên. Mỗi phân đoạn sinh ra sẽ tự động thừa hưởng toàn bộ chuỗi tiêu đề cha mẹ (Breadcrumb Metadata) được gắn thẳng vào trường metadata.
• Code Block Protection: Áp dụng biểu thức chính quy (Regex) để nhận diện các khối mã lệnh được bao bọc bởi triple backticks (“`). Tuyệt đối không bao giờ cho phép thuật toán cắt ngang giữa một khối mã nguồn.
• Table Enclosure Preservation: Tách toàn bộ bảng Markdown hoặc bảng HTML thành một đơn vị độc lập. Nếu bảng quá dài vượt ngưỡng token, kỹ thuật chuẩn là nhân bản dòng tiêu đề (Header row) vào đầu mỗi chunk con để duy trì tính toàn vẹn ngữ nghĩa của từng ô dữ liệu.

4. Kỹ Thuật Semantic Splitting & Hợp Nhất Cửa Sổ Trượt (Sliding Window Merging)

Khác với việc dựa vào các ký tự phân tách tĩnh (`nn` hay dấu chấm câu), Semantic Splitting (Phân tách theo ngữ nghĩa) sử dụng chính mô hình nhúng (Embedding Model) để phát hiện các bước chuyển đổi chủ đề (Topic Drift) trong nội dung văn bản.

Nguyên lý vận hành của kỹ thuật Cửa sổ trượt kết hợp Hợp nhất ngữ nghĩa (Sliding Window Semantic Merging) bao gồm 3 bước:

1. Tạo các cửa sổ trượt nhỏ (Micro-windows): Chia tài liệu thành các cửa sổ từ nhỏ (ví dụ 100 từ với độ chồng lấp 20 từ). Các cửa sổ này đủ nhỏ để đảm bảo tính thuần nhất về mặt chủ đề.
2. Nhúng và đo độ tương đồng Cosine lân cận: Tính toán vector embedding cho từng cửa sổ. Sau đó, tính khoảng cách cosine giữa hai cửa sổ liền kề liên tiếp: sim = cosine_similarity(E_i, E_{i+1}).
3. Ngưỡng hợp nhất thích ứng (Adaptive Merge Threshold): Nếu độ tương đồng cosine lớn hơn hoặc bằng ngưỡng thiết lập (thường dao động từ 0.60 đến 0.75), hai cửa sổ này đang bàn về cùng một luận điểm và sẽ được gộp lại. Khi gặp một vị trí mà độ tương đồng sụt giảm đột ngột (Cosine Similarity Drop), thuật toán sẽ chốt hạ ranh giới chunk tại điểm rơi đó.

5. Kiến Trúc Parent-Child Chunks: Chiến Lược “Small-to-Big Retrieval”

Trong thiết kế RAG truyền thống, có một mâu thuẫn cơ bản không thể dung hòa:

• Để tầng Truy xuất Vector (Vector Search) hoạt động hiệu quả nhất: Chunk cần phải nhỏ và tập trung cao độ (khoảng 100 – 200 tokens) để vector embedding có độ sắc nét tối đa, khớp chính xác với câu hỏi của người dùng.
• Để tầng Tạo sinh (LLM Generation) suy luận chính xác nhất: LLM cần một ngữ cảnh rộng lớn và toàn diện (khoảng 800 – 2,000 tokens) để hiểu bối cảnh xung quanh và không đưa ra kết luận phiến diện.

Kiến trúc Parent-Child Chunks (Tài liệu Cha – Con), hay còn gọi là chiến lược Small-to-Big Retrieval, là lời giải triệt để cho bài toán này:

Khi người dùng đặt câu hỏi, Vector Store so khớp và tìm thấy Child Chunk c_02. Nhưng thay vì nạp đoạn con nhỏ xíu đó cho LLM, hệ thống tra cứu bảng tham chiếu và gửi toàn bộ nội dung của Parent Chunk p_04 vào cửa sổ ngữ cảnh. Kết quả: Tỷ lệ tìm kiếm chính xác cực cao kết hợp với bối cảnh suy luận hoàn hảo.

6. Vật Lý Học Chunk Overlap: Giữ Ngữ Cảnh Đường Biên Không Nhiễm Bẩn Vector

Độ chồng lấp (Chunk Overlap) là số lượng ký tự hoặc token được lặp lại giữa hai phân đoạn liền kề. Tại sao chúng ta cần overlap? Nếu không có overlap, một mệnh đề nằm ngay điểm cắt (ví dụ: “Do đó, hệ thống bắt buộc phải sử dụng giao thức TLS 1.3…”) sẽ bị mất chủ ngữ ở chunk sau, khiến cả hai chunk đều trở nên mù mờ.

Tuy nhiên, lạm dụng overlap là một cái bẫy nguy hiểm:

• Overlap quá nhỏ (< 5%): Không đủ để bảo toàn các liên từ phụ thuộc, cụm từ danh từ ghép hoặc điều kiện tiền đề nằm sát mép cắt.
• Overlap quá lớn (> 30%): Gây lãng phí tài nguyên tính toán nhúng, làm trùng lặp kết quả trả về trong danh sách Top-K, và khiến LLM đọc đi đọc lại cùng một câu chữ trong prompt.
• Tỷ lệ vàng thực nghiệm: Đối với tài liệu kỹ thuật, mức overlap tối ưu nhất luôn dao động trong khoảng 10% đến 15% tổng kích thước chunk (ví dụ: chunk 500 tokens sẽ có overlap 50 – 75 tokens).

7. Tinh Chỉnh Dựa Trên Đánh Giá Thực Nghiệm (Eval-Driven Tuning Với Ragas)

Sai lầm phổ biến nhất của các nhóm phát triển RAG là “đoán mò” kích thước chunk: “Tôi nghĩ 512 tokens nghe có vẻ vừa vặn!”. Trong kỹ thuật AI chuyên nghiệp, không có một con số thần kỳ nào áp dụng chung cho mọi tập dữ liệu. Cách duy nhất để tìm ra kích thước chunk tối ưu là vận hành theo triết lý Eval-Driven Tuning (Tinh chỉnh dựa trên dữ liệu đánh giá).

Quy trình xây dựng bộ kiểm thử định lượng bao gồm:

1. Xây dựng tập dữ liệu vàng (Golden Testset): Thu thập từ 50 đến 100 cặp Câu hỏi – Câu trả lời đối soát (Ground Truth Question-Answer pairs) phản ánh đúng nhu cầu thực tế của người dùng.
2. Thiết lập ma trận thử nghiệm (Experiment Matrix): Chạy song song nhiều cấu hình:
   • Cấu hình A: Fixed 256 tokens / 25 overlap.
   • Cấu hình B: Fixed 512 tokens / 50 overlap.
   • Cấu hình C: Markdown Header Splitting + Recursive 512.
   • Cấu hình D: Parent-Child (Child 200 / Parent 1000).
   • Cấu hình E: Semantic Splitting (Threshold 0.65).
3. Đo lường 4 chỉ số cốt lõi của RAG Triad (sử dụng Ragas / TruLens):
   • Context Precision: Các chunk được truy xuất có thực sự liên quan và đặt ở thứ hạng đầu hay không?
   • Context Recall: Hệ thống có truy xuất đủ toàn bộ thông tin cần thiết để trả lời câu hỏi không?
   • Faithfulness (Tính trung thực): Câu trả lời của LLM có hoàn toàn dựa trên context truy xuất được hay bị ảo giác?
   • Answer Relevance: Câu trả lời có đúng trọng tâm câu hỏi của người dùng không?

8. Bảng Đối Soát Thực Nghiệm Benchmark: Hit Rate, MRR & Latency

Dưới đây là bảng dữ liệu thực nghiệm đo lường trên tập dữ liệu gồm 1,200 trang tài liệu kỹ thuật phức tạp (gồm văn bản mô tả, bảng thông số và mã nguồn API):

Kết quả chứng minh rõ ràng: Chuyển từ Fixed Chunking thô sơ sang kiến trúc Parent-Child kết hợp nhận biết cấu trúc giúp tăng tỷ lệ Hit Rate từ 61.4% lên 94.2% và đưa độ chuẩn xác ngữ cảnh (Context Precision) từ mức trung bình 0.54 lên mức xuất sắc 0.91, trong khi độ trễ truy xuất chỉ tăng thêm một khoảng không đáng kể (~70 ms).

9. Mã Nguồn Pipeline Triển Khai Semantic Splitting Chuẩn Thực Chiến

Dưới đây là đoạn mã Python hoàn chỉnh minh họa cách triển khai pipeline phân tách kết hợp: Nhận biết cấu trúc tài liệu, tính toán độ tương đồng cosine giữa các cửa sổ văn bản và xuất ra các chunk ngữ nghĩa tối ưu:

import re
import numpy as np
from typing import List, Dict

def sliding_window_tokens(text: str, window_size: int = 150, step_size: int = 100) -> List[str]:
    """Tách văn bản thành các cửa sổ trượt nhỏ để đo ngữ nghĩa."""
    tokens = text.split()
    windows = []
    for i in range(0, len(tokens), step_size):
        window = " ".join(tokens[i : i + window_size])
        if window:
            windows.append(window)
    return windows

def cosine_similarity(vec_a: np.ndarray, vec_b: np.ndarray) -> float:
    """Tính toán khoảng cách góc cosine giữa hai vector embedding."""
    dot_prod = np.dot(vec_a, vec_b)
    norm_a = np.linalg.norm(vec_a)
    norm_b = np.linalg.norm(vec_b)
    if norm_a == 0 or norm_b == 0:
        return 0.0
    return float(dot_prod / (norm_a * norm_b))

def semantic_merge_pipeline(
    windows: List[str], 
    embeddings: List[np.ndarray], 
    similarity_threshold: float = 0.65
) -> List[str]:
    """
    Hợp nhất các cửa sổ lân cận nếu chúng chia sẻ ngữ nghĩa tương đồng cao.
    Ngắt chunk khi phát hiện sự sụt giảm độ tương đồng dưới ngưỡng.
    """
    if not windows or len(windows) != len(embeddings):
        return []

    merged_chunks = []
    current_chunk = windows[0]

    for i in range(1, len(windows)):
        sim = cosine_similarity(embeddings[i - 1], embeddings[i])
        
        # Nếu hai cửa sổ liền kề cùng chủ đề -> Hợp nhất
        if sim >= similarity_threshold:
            current_chunk += " " + windows[i]
        else:
            # Phát hiện ranh giới chủ đề mới -> Lưu chunk cũ và mở chunk mới
            merged_chunks.append(current_chunk.strip())
            current_chunk = windows[i]

    merged_chunks.append(current_chunk.strip())
    return merged_chunks

# Ví dụ vận hành thực tế
if __name__ == "__main__":
    sample_doc = "Kiến trúc RAG bao gồm tầng truy xuất và tạo sinh... Tầng nhúng tính toán vector..."
    raw_windows = sliding_window_tokens(sample_doc, window_size=120, step_size=80)
    print(f"Tổng số cửa sổ trượt được tạo: {len(raw_windows)}")

Pipeline này cho phép hệ thống tự động co giãn kích thước phân đoạn theo đúng dòng chảy ý tưởng của tác giả, loại bỏ hoàn toàn tình trạng câu văn bị ngắt ngang xương hay ý tưởng bị chia đôi giữa hai chunk khác nhau.

10. Thiết Bị & Công Cụ Phần Cứng Tối Ưu Cho Kỹ Sư AI & RAG

Để phục vụ quá trình nhúng dữ liệu quy mô lớn (Embedding generation), chạy các mô hình Reranker cục bộ và lưu trữ vector database tốc độ cao trên máy trạm, dưới đây là những trang thiết bị phần cứng được các kỹ sư Machine Learning khuyên dùng:

11. Tài Liệu & Nguồn Trích Xuất Tham Khảo

Nội dung phân tích thực nghiệm và các kỹ thuật tối ưu hóa trong bài viết được trích xuất và tổng hợp từ các nguồn dữ liệu chuyên môn sau (ở định dạng văn bản thuần):

• medium.com/data-science-collective/rag-chunking-that-works-semantic-splitting-overlap-and-eval-driven-tuning-530fbb25b613
• pub.towardsai.net/semantic-chunking-vs-fixed-chunking-why-your-rags-retrieval-quality-starts-before-the-query-f22050a8e898
• docs.ragas.io/en/stable/concepts/metrics
• github.com/run-llama/llama_index