Chiến Lược Chunking, Metadata Enriched Và Query Transformation cho RAG system

Sự bùng nổ của các mô hình ngôn ngữ lớn (LLM) đã biến kiến trúc Kiến tạo Tăng cường Truy xuất (Retrieval-Augmented Generation - RAG) thành tiêu chuẩn công nghiệp cho các ứng dụng quản trị tri thức và chatbot doanh nghiệp. Tuy nhiên, chất lượng phản hồi của RAG phụ thuộc trực tiếp vào độ chính xác của giai đoạn truy xuất. Khi xử lý tập dữ liệu khổng lồ, phức tạp và đa dạng về cấu trúc trong doanh nghiệp, các phương pháp RAG truyền thống (Naive RAG) thường thất bại do hiện tượng mất ngữ cảnh, phân mảnh thông tin, hoặc độ nhiễu cao. Báo cáo này phân tích chuyên sâu các phương pháp tốt nhất từ thiết kế chunking, làm giàu metadata, xử lý đa ngôn ngữ, tối ưu hóa chiều vector embedding đến chiến lược biến đổi truy vấn và tìm kiếm kết hợp (hybrid search).

1. Phương Pháp Luận Chunking Dữ Liệu Doanh Nghiệp Quy Mô Lớn

Chunking là quá trình chia nhỏ tài liệu thành các đơn vị văn bản có kích thước phù hợp trước khi nhúng (embedding) và lưu trữ vào cơ sở dữ liệu vector. Việc lựa chọn sai chiến lược chunking là nguyên nhân hàng đầu dẫn đến suy giảm chất lượng truy xuất trong môi trường doanh nghiệp.

Các Chiến Lược Chunking Hiện Đại

Fixed-size Chunking chia văn bản theo một số lượng token nhất định kèm theo một đoạn đệm gối đầu (overlap). Mặc dù đơn giản và chi phí tính toán thấp, phương pháp này dễ làm đứt gãy câu, chia cắt các đoạn văn mang tính logic và làm suy giảm đáng kể ý nghĩa ngữ nghĩa ở các ranh giới cắt.

Sentence-Window Chunking chia nhỏ văn bản thành từng câu đơn lẻ để mã hóa thành vector truy xuất. Tuy nhiên, khi chuyển ngữ cảnh sang cho LLM, hệ thống sẽ mở rộng cửa sổ xung quanh câu đó bằng cách lấy thêm các câu phía trước và phía sau. Cách làm này giúp duy trì kích thước tìm kiếm vector nhỏ gọn nhưng đảm bảo ngữ cảnh liền mạch cho mô hình sinh.

Semantic Chunking sử dụng mô hình embedding để tính toán khoảng cách ngữ nghĩa giữa các câu liên tiếp. Khi độ chênh lệch ngữ nghĩa vượt quá một ngưỡng nhất định, hệ thống sẽ tạo một điểm ngắt đoạn. Phương pháp này tạo ra các chunk tự nhiên theo chủ đề nhưng đòi hỏi chi phí tính toán cao trong quá trình nạp dữ liệu.

Parent-Child Chunking (hay Hierarchical Chunking) là mô hình chuẩn mực cho doanh nghiệp. Hệ thống chia tài liệu thành hai tầng: các chunk con (Child chunks) có kích thước nhỏ để tối ưu hóa độ chính xác khi tìm kiếm vector, và mỗi chunk con được liên kết với một chunk cha (Parent chunk) có kích thước lớn hơn hoặc toàn bộ phần tài liệu. Khi truy xuất, vector search tìm trúng chunk con, nhưng hệ thống sẽ trả về chunk cha cho LLM để tổng hợp câu trả lời.

Xử Lý Cấu Trúc Đặc Thù: Bảng Biểu Và Dữ Liệu Có Cấu Trúc

Tài liệu doanh nghiệp chứa khối lượng lớn bảng biểu ở định dạng Markdown hoặc HTML. Việc chia cắt bảng biểu theo token thông thường sẽ phá hủy hoàn toàn cấu trúc hàng/cột và tính quan hệ của dữ liệu.

Về nguyên tắc xử lý, bảng biểu không nên bị chia cắt nếu kích thước bảng nằm gọn trong context window của mô hình. Mỗi bảng biểu cần được trích xuất thành một đơn vị chunk riêng biệt, chuẩn hóa về định dạng Markdown Table hoặc HTML Table. Đối với các bảng biểu quá khổ vượt quá dung lượng chunk, hệ thống áp dụng chiến lược phân tách theo hàng độc lập kèm theo dòng Tiêu đề Cột (Header Row) ở đầu mỗi chunk con, hoặc sử dụng LLM để chuyển đổi bảng thành các đoạn tóm tắt ngữ nghĩa (textual narrative summary) trước khi nhúng vector.

2. Xác Định Kích Thước Chunk Tiêu Chuẩn Cho Dữ Liệu Gốc

Không tồn tại một con số cố định duy nhất cho kích thước chunk tối ưu, vì thông số này phụ thuộc vào bản chất của tập tài liệu, mô hình embedding và câu hỏi của người dùng. Tuy nhiên, các thử nghiệm thực nghiệm trong môi trường doanh nghiệp đã xác định các khoảng dung lượng tiêu chuẩn.

Kích Thước Chunk Tiêu Chuẩn Cho Dữ Liệu Doanh Nghiệp

Mức từ 256 đến 512 tokens (tương đương khoảng 200–400 từ tiếng Anh hoặc 300–600 từ tiếng Việt) được coi là điểm cân bằng tối ưu cho các mô hình embedding hiện đại như OpenAI text-embedding-3, Cohere Embed, hay BGE. Cùng với đó, hệ thống cần duy trì tỷ lệ gối đầu (overlap) từ 10% đến 20% kích thước chunk (ví dụ: gối đầu 50 tokens cho chunk 512 tokens). Đoạn gối đầu ngăn ngừa việc các thực thể quan trọng hoặc câu trả lời nằm đúng ranh giới cắt bị đứt đoạn ngữ nghĩa.

Phương Pháp Xác Định Kích Thước Chunk Bằng Đánh Giá Định Lượng

Thay vì chọn ngẫu nhiên, các hệ thống enterprise RAG bắt buộc phải trải qua quy trình đánh giá tự động sử dụng các khung như RAGAS hoặc LlamaIndex Evaluation. Thí nghiệm được thực hiện bằng cách tạo một tập hợp câu hỏi-đáp mẫu từ dữ liệu thực tế.

Sau đó, hệ thống thực hiện truy xuất trên các cấu hình chunk khác nhau (128, 256, 512, 1024 tokens) và đo lường chỉ số Context Recall (tỷ lệ thông tin đúng được lấy ra) cùng Context Precision (tỷ lệ thông tin không nhiễu trong các chunks được trả về). Cấu hình đạt tổng điểm cao nhất trên bộ dữ liệu kiểm thử sẽ được chọn làm thông số triển khai sản xuất.

3. Kiến Trúc Metadata Cho Chunk Nhằm Tối Ưu Hóa Khả Năng Truy Xuất

Metadata (siêu dữ liệu) gắn kèm với từng chunk đóng vai trò là cầu nối giữa tìm kiếm ngữ nghĩa (semantic search) và tìm kiếm có điều kiện (filtered search), giúp loại bỏ nhiễu ngữ cảnh và tăng tốc độ truy xuất.

Phân Loại Metadata Bắt Buộc Đối Với Chunk Doanh Nghiệp

• Metadata Cấu Trúc Và Định Danh (Structural Metadata): Bao gồm doc_id, chunk_id làm định danh duy nhất; source_url hoặc file_path chỉ định đường dẫn gốc; page_number chỉ rõ số trang cụ thể; và section_hierarchy (Breadcrumbs) lưu trữ cấu trúc tiêu đề phân cấp của đoạn văn (ví dụ: Chương 3 > Mục 3.2 > Điều khoản A) giúp giữ vững vị trí của chunk trong toàn bộ văn bản.
• Metadata Phân Quyền Và Bảo Mật (Access Control & Multi-Tenancy Metadata): Bao gồm tenant_id định danh tổ chức trong hệ thống SaaS đa người dùng, department_access quy định khối/phòng ban được phép truy cập, và clearance_level thể hiện mức độ bảo mật thông tin. Các trường này cho phép thực hiện lọc trước (pre-filtering) ở cấp độ cơ sở dữ liệu vector, đảm bảo người dùng chỉ tìm kiếm trong phạm vi dữ liệu được phân quyền.
• Metadata Thời Gian Và Loại Văn Bản (Temporal & Domain Metadata): Bao gồm created_at, updated_at ghi nhận thời gian cập nhật, effective_date thể hiện ngày có hiệu lực của văn bản quy phạm, và doc_type phân loại kiểu tài liệu.

Bổ Sung Ngữ Cảnh Bằng Phương Pháp Contextual Retrieval

Thách thức của RAG truyền thống là một chunk khi đứng độc lập có thể mất đi ý nghĩa do chứa các đại từ thay thế hoặc thiếu thông tin chủ thể. Để khắc phục hiện tượng này, phương pháp Contextual Retrieval do Anthropic đề xuất áp dụng quy trình xử lý tiền nhúng.

Trước khi tạo vector embedding, hệ thống sử dụng một LLM nhỏ, tốc độ cao để tạo ra một đoạn giải thích ngắn (50–100 từ) tóm tắt vị trí và bối cảnh toàn cục của chunk trong toàn bộ tài liệu. Đoạn bối cảnh này được chèn trực tiếp vào đầu phần văn bản của chunk trước khi nhúng thành vector. Cấu trúc của một chunk hoàn chỉnh sau khi làm giàu sẽ bao gồm phần Header Metadata lưu trữ các thuộc tính phân quyền và cấu trúc, tiếp theo là phần Contextual Embedding Prefix chứa tóm tắt bối cảnh toàn cục, và cuối cùng là phần Original Chunk Text chứa nội dung gốc. Thực nghiệm cho thấy phương pháp này giảm tỷ lệ thất bại khi truy xuất lên đến 35–40% do giải quyết triệt để sự mơ hồ về mặt ngữ nghĩa của các chunk ngắn.

4. Xử Lý Đa Ngôn Ngữ Và Đặc Thù Tiếng Việt, CJK

Khi triển khai RAG cho các doanh nghiệp đa quốc gia hoặc phục vụ thị trường nội địa với dữ liệu song ngữ (Việt - Anh, CJK - Anh), các vấn đề về Tokenization và Lệch Không Gian Vector (Vector Space Mismatch) trở thành rào cản lớn.

Thách Thức Tokenization Đối Với Tiếng Việt Và CJK

Mô hình Tokenizer của đa số các LLM và Embedding models được tối ưu hóa cho tiếng Anh. Đối với tiếng Việt, đây là ngôn ngữ đơn lập có ranh giới từ không trùng với ranh giới dấu khoảng trắng. Tokenizer tiếng Anh thường cắt các từ ghép tiếng Việt thành các sub-words không có nghĩa, dẫn đến biểu diễn vector kém chính xác và thuật toán BM25 bị lỗi khi khớp từ khóa. Do đó, hệ thống bắt buộc phải sử dụng các thư viện tách từ chuyên dụng cho tiếng Việt (như PyVi, Underthesea, hoặc VnCoreNLP) trước khi đưa văn bản vào bộ chỉ mục BM25, đồng thời nối các từ ghép bằng dấu gạch dưới để giữ nguyên cấu trúc ngữ nghĩa.

Đối với CJK (Tiếng Trung, Nhật, Hàn), do chữ viết không sử dụng khoảng trắng giữa các từ, việc đếm token dựa trên khoảng trắng hoàn toàn thất bại. Vì dung lượng ngữ nghĩa của 1 ký tự CJK lớn hơn rất nhiều so với 1 ký tự Latin, kích thước chunk tính theo ký tự cho dữ liệu CJK phải được điều chỉnh giảm xuống còn 1/2 hoặc 1/3 so với chuỗi văn bản Latin để đạt cùng một mức độ cô đọng ngữ nghĩa.

Đánh Giá Các Mô Hình Embedding Đa Ngôn Ngữ

Việc lựa chọn mô hình embedding phải ưu tiên các kiến trúc được huấn luyện đặc nhiệm cho nhiệm vụ truy xuất đa ngôn ngữ và tìm kiếm xuyên ngôn ngữ.

Kiến Trúc Truy Xuất Xuyên Ngôn Ngữ (Cross-Lingual Retrieval Architecture)

Doanh nghiệp có thể áp dụng hai chiến lược chính khi xử lý bài toán truy vấn bằng tiếng Việt nhưng tài liệu gốc được lưu trữ bằng tiếng Anh:

Chiến lược thứ nhất là ứng dụng không gian vector đa ngôn ngữ đồng nhất (Cross-Lingual Dense Space). Bằng cách sử dụng các mô hình embedding đa ngôn ngữ chất lượng cao như BGE-M3 hoặc Cohere Embed 5, hệ thống biểu diễn câu hỏi tiếng Việt và đoạn văn bản tiếng Anh về cùng một không gian vector đa chiều mà không cần qua bước dịch thuật ngữ pháp.

Chiến lược thứ hai là xây dựng đường ống dịch truy vấn (Query Translation Pipeline). Hệ thống sử dụng một mô hình LLM nhỏ, tốc độ cao để dịch câu hỏi của người dùng sang ngôn ngữ chính của tập cơ sở dữ liệu trước khi thực hiện truy xuất BM25 hoặc Vector. Phương pháp này đạt hiệu quả vượt trội khi tìm kiếm các từ khóa chính xác, mã sản phẩm hoặc thuật ngữ kỹ thuật chuyên ngành.

5. Tối Ưu Hóa Số Chiều Vector Embedding

Số chiều của vector embedding đóng vai trò quyết định đến độ chính xác của biểu diễn ngữ nghĩa, chi phí lưu trữ cơ sở dữ liệu vector và độ trễ của phép tìm kiếm láng giềng gần nhất.

Xu Hướng Học Biểu Diễn Matryoshka (Matryoshka Representation Learning - MRL)

Các thế hệ mô hình embedding mới được huấn luyện bằng kỹ thuật Matryoshka Representation Learning (MRL). Kỹ thuật này ép các thông tin ngữ nghĩa quan trọng nhất dồn vào những chiều đầu tiên của vector. Do đó, hệ thống có thể cắt giảm (truncate) số chiều của vector từ 3072 xuống 1024 hoặc 256 mà không làm suy giảm nghiêm trọng độ chính xác. Lưu ý rằng sau khi cắt giảm chiều của vector Matryoshka thủ công, hệ thống bắt buộc phải chuẩn hóa lại vector về độ dài đơn vị (L2 Normalization) trước khi tính toán Cosine Similarity.

Kiến Trúc Truy Xuất Hai Giai Đoạn (Two-Stage Coarse-to-Fine Retrieval)

Để tối ưu hóa đồng thời tốc độ truy xuất và độ chính xác, các hệ thống enterprise tiên tiến triển khai quy trình hai giai đoạn tận dụng đặc tính MRL.

Ở giai đoạn 1 (Fast Coarse Search), hệ thống sử dụng chỉ mục HNSW với vector đã cắt giảm xuống 256 hoặc 512 chiều để quét nhanh toàn bộ cơ sở dữ liệu khổng lồ, lọc ra Top-100 đến Top-500 ứng viên tiềm năng với tốc độ cao.

Ở giai đoạn 2 (Accurate Fine Reranking), hệ thống lấy danh sách ứng viên đã rút gọn và sử dụng vector đầy đủ 1024 hoặc 3072 chiều để tính toán lại điểm số tương đồng chính xác, chọn ra Top-10 kết quả cuối cùng truyền cho LLM.

6. Chiến Lược Query Transformation, Rewrite Và Hybrid Search

Câu hỏi ban đầu của người dùng thường ngắn, thiếu ngữ cảnh, chứa lỗi ngữ pháp hoặc không trùng khớp về mặt từ khóa với tài liệu chuyên ngành. Việc đưa trực tiếp truy vấn thô vào cơ sở dữ liệu vector sẽ dẫn đến độ chính xác truy xuất kém.

Các Kỹ Thuật Biến Đổi Truy Vấn (Query Transformation Layer)

Multi-Query Expansion sử dụng LLM để viết lại câu hỏi gốc của người dùng thành 3 đến 5 phiên bản khác nhau bằng cách sử dụng các từ đồng nghĩa và cấu trúc câu đa dạng nhưng giữ nguyên ý định. Hệ thống thực hiện tìm kiếm song song cho tất cả các phiên bản này rồi gộp kết quả, giúp khắc phục hiện tượng truy vấn bị lệch góc nhìn ngữ nghĩa.

Sub-Query Decomposition áp dụng cho các câu hỏi phức tạp chứa nhiều bước logic. Tầng biến đổi sẽ tách câu hỏi đa ý thành các truy vấn con độc lập, sau đó tổng hợp kết quả truy xuất của từng câu hỏi con trước khi đưa vào prompt của LLM.

Step-Back Prompting tạo ra một câu hỏi mang tính khái quát ở mức độ cao hơn từ câu hỏi cụ thể của người dùng. Kỹ thuật này giúp hệ thống lấy được các nguyên lý nền tảng hoặc ngữ cảnh rộng hơn nếu thông tin chi tiết không có sẵn trong tài liệu.

Hypothetical Document Embeddings (HyDE) yêu cầu LLM giả lập tạo ra một đoạn văn bản câu trả lời hư cấu nhưng có vẻ hợp lý. Sau đó, hệ thống lấy vector embedding của câu trả lời hư cấu này để đi tìm các chunk tài liệu thật có ngữ nghĩa tương đồng. HyDE chuyển bài toán từ tìm tài liệu tương đương với câu hỏi sang tìm tài liệu tương đương với câu trả lời, giúp nâng cao độ chính xác khi vector matching.

Kiến Trúc Tìm Kiếm Kết Hợp (Hybrid Search) Và RRF Fusion

Truy xuất vector thuần túy (Dense Search) thường thất bại đối với các từ khóa chính xác, mã định danh, số hợp đồng, hoặc tên riêng. Do đó, kiến trúc chuẩn mực cho enterprise RAG là sự kết hợp song song giữa Dense Vector Search và Sparse Lexical Search (BM25).

Do điểm số của BM25 (không giới hạn dương) và Cosine Similarity của Dense Search (từ 0.0 đến 1.0) nằm trên hai thang đo hoàn toàn khác nhau, việc cộng trực tiếp điểm số sẽ làm sai lệch kết quả. Thuật toán Reciprocal Rank Fusion (RRF) giải quyết vấn đề này bằng cách chỉ quan tâm đến thứ hạng ($r$) của tài liệu trong từng danh sách kết quả, loại bỏ hoàn toàn sự phụ thuộc vào điểm số thô.

Công thức tính điểm RRF cho một tài liệu $d$ được biểu diễn như sau:

$$ RRF_Score(d) = \sum_{m \in M} \frac{1}{k + r_m(d)} $$

Trong đó $M$ là tập hợp các thuật toán tìm kiếm (BM25 và Dense Vector), $r_m(d)$ là thứ hạng của tài liệu $d$ trong thuật toán $m$, và $k$ là hằng số làm mịn (thông lệ công nghiệp đặt $k = 60$). Tài liệu xuất hiện ở vị trí cao trong cả hai danh sách tìm kiếm sẽ có điểm RRF vượt trội và được đưa lên đầu danh sách tổng hợp.

Tối Ưu Hóa Kết Quả Bằng Cross-Encoder Reranking

Sau khi RRF tổng hợp danh sách Top-K từ Hybrid Search, giai đoạn cuối cùng là đưa danh sách này qua một mô hình Cross-Encoder Reranker (như Cohere Rerank v3 hoặc BGE-Reranker-v2).

Khác với mô hình embedding thông thường tạo vector độc lập cho query và document, Cross-Encoder đưa cả query và document vào mô hình cùng một lúc để tính toán điểm số tương quan ngữ nghĩa chuyên sâu. Kết quả Reranking giúp chọn ra Top-5 đến Top-10 chunk có chất lượng cao nhất, loại bỏ hoàn toàn thông tin nhiễu trước khi truyền bối cảnh cho LLM sinh câu trả lời.

7. Kết Luận Và Khuyến Nghị Triển Khai Cho Doanh Nghiệp

Xây dựng một hệ thống RAG quy mô doanh nghiệp đòi hỏi sự phối hợp chặt chẽ giữa kỹ thuật xử lý dữ liệu đầu vào và các tầng truy xuất thông minh. Việc áp dụng một giải pháp Naive RAG đơn giản không còn đủ đáp ứng độ chính xác khắt khe trong môi trường vận hành thực tế.

Doanh nghiệp nên áp dụng mô hình Parent-Child Chunking làm mặc định cho các tài liệu phức tạp, chia nhỏ chunk con ở mức 150–200 tokens để truy xuất vector chính xác và liên kết với chunk cha 512–1024 tokens để cung cấp ngữ cảnh hoàn chỉnh cho LLM. Bắt buộc gắn thông tin phân quyền, vị trí phân cấp và áp dụng kỹ thuật Contextual Retrieval để nâng cao khả năng định vị thông tin.

Bên cạnh đó, cần thực hiện tách từ bằng thư viện chuyên dụng đối với dữ liệu tiếng Việt trước khi đánh chỉ mục BM25, đồng thời sử dụng các mô hình embedding đa ngôn ngữ mạnh mẽ như BGE-M3 hoặc Cohere Embed 5. Về cấu hình vector, mức 1024 dimensions đại diện cho điểm cân bằng tối ưu giữa độ chính xác và chi phí bộ nhớ. Cuối cùng, việc kết hợp tầng biến đổi truy vấn, tìm kiếm lai Hybrid Search (BM25 + Dense) qua thuật toán RRF, và đánh giá lại thứ hạng bằng Cross-Encoder Reranker sẽ đảm bảo tối đa hóa độ chính xác và trải nghiệm người dùng trong các ứng dụng chatbot doanh nghiệp.