Đây là heuristic. Ký tự / 3.8 cho văn bản kiểu tiếng Anh và 1 token cho mỗi ký tự CJK. ±5-10% cho văn xuôi, tệ hơn cho văn bản nặng code hoặc có cấu trúc. Tại sao không tokenizer thật? tiktoken ~1 MB WASM, quá nặng chỉ để chunk-sizing. Nếu model downstream của bạn có giới hạn token cứng trên chunk (một số có, ví dụ cohere/embed-v3 giới hạn 512), build với biên độ an toàn hoặc chạy tokenizer thật trong pipeline. Cho sizing thì ổn. Số token chính xác của mỗi chunk không quan trọng lắm cho chất lượng RAG — model embedding cắt input quá khổ dù sao. Quan trọng là tính nhất quán: cùng heuristic cho chunking và cho budgeting prompt downstream.

Bộ chia chunk văn bản cho RAG

Chia văn bản thành các chunk theo kích thước token để chuẩn bị RAG / embeddings. Nhiều chiến lược: recursive char, sentence-aware, semantic boundaries. Overlap có thể cấu hình. Tất cả trong trình duyệt.

Paste your document

RAG (Retrieval-Augmented Generation) is a technique that pairs an LLM with an external knowledge base. Instead of relying only on the model's parametric memory, the system retrieves relevant passages at query time and concatenates them into the prompt.

The retrieval step depends on a vector store. Documents are split into chunks, each chunk gets an embedding vector, and those vectors are stored in a database that supports approximate nearest-neighbour search.

# Chunk size matters

Chunks that are too small lose context — a single sentence might not contain enough information to answer the question. Chunks that are too large dilute relevance — the embedding becomes an average of many unrelated topics, and retrieval gets noisy.

A common starting point is 500 tokens per chunk with 50 tokens of overlap. Overlap lets a chunk see a bit of context from its neighbours, which helps when a relevant span happens to fall across a chunk boundary.

# Strategy choice

Recursive character splitting is the most general: it tries paragraph breaks first, then line breaks, then sentence boundaries, then spaces. This is the default in most frameworks and works well for prose.

Sentence-aware splitting respects sentence boundaries and never breaks mid-sentence. It produces cleaner chunks for QA over articles and books, at the cost of more variable chunk sizes.

Paragraph chunking treats each paragraph as its own chunk (subject to the size limit). This is useful for structured documents like documentation or knowledge-base articles where each section is already a coherent unit.

Semantic chunking goes one step further: it tries to keep semantically related content together by respecting headings and topic boundaries, even when those don't align with paragraph breaks.

Chunk size (tokens): 500

Overlap (tokens): 50

Strategy

Cái này để làm gì?

Retrieval-Augmented Generation (RAG) và tìm kiếm dựa trên embedding đều phụ thuộc vào việc tách một corpus thành các chunk: những mảnh nhỏ được embed riêng lẻ và lưu trong vector DB. Việc tách xảy ra trước bất kỳ máy móc AI nào, nhưng chất lượng retrieval của bạn thầm lặng phụ thuộc vào nó nhiều hơn hầu hết mọi người nhận ra. Chunk quá nhỏ mất ngữ cảnh; quá lớn pha loãng độ liên quan; chunk cắt giữa câu retrieve kém vì embedding rơi vào điểm ngữ nghĩa kỳ lạ. Công cụ này là một playground nhanh trong trình duyệt để thử nghiệm với kích thước chunk, overlap và chiến lược trước khi commit pipeline với lựa chọn.

Bốn chiến lược

recursive-char (mặc định). Cố gắng tách theo paragraph trước, rồi line break, rồi ranh giới câu (. ), rồi khoảng trắng. Mỗi mảnh được pack tham lam đến budget kích thước. Chỉ fallback sang tách cứng theo ký tự khi không có gì khác fit. Mặc định trong LangChain, LlamaIndex và hầu hết stack RAG production; điểm khởi đầu hợp lý cho gần như mọi corpus văn xuôi.
sentence. Tách ở ranh giới câu và không bao giờ trong câu — ngay cả khi câu ngắn hơn budget, vẫn giữ nguyên. Tốt hơn recursive-char khi chunk sẽ được trích làm bằng chứng (QA, citations) vì không có chunk nào kết thúc giữa suy nghĩ. Kích thước chunk thay đổi nhiều hơn, vì độ dài câu thay đổi.
paragraph. Coi mỗi paragraph như một đơn vị. Hai paragraph ngắn liền kề có thể được pack cùng nhau, nhưng paragraph dài không bao giờ bị tách. Hữu ích cho tài liệu, bài KB và long-form được format tốt nơi mỗi paragraph là một suy nghĩ mạch lạc.
semantic. Thêm phát hiện heading lên trên paragraph: các dòng bắt đầu với #, ## v.v., hoặc các dòng ngắn toàn chữ hoa, được xử lý như ranh giới section mới. Tốt cho tài liệu kỹ thuật nơi ranh giới section quan trọng hơn khoảng cách paragraph trực quan.

Overlap — tại sao và bao nhiêu

Tại sao. Nếu một span liên quan rơi đúng vào ranh giới giữa hai chunk, cả hai sẽ retrieve kém vì mỗi cái chỉ có một nửa. Overlap sao chép N token cuối của chunk trước vào đầu chunk sau, cho cả hai cơ hội bắt được span.
Bao nhiêu. 10-20% kích thước chunk là quy tắc. Cho chunk 500 token, 50-100 token overlap. Mặc định ở đây là 50, hoạt động tốt trong thực tế.
Đánh đổi. Nhiều overlap hơn = nhiều embedding tổng hơn (nhiều storage hơn, nhiều chi phí hơn, build index chậm hơn, nhiều candidate retrieval hơn). Đừng vượt quá 30% không có lý do cụ thể; phí tiền mà không cải thiện retrieval nhiều.

Ước tính token

Đây là heuristic. Ký tự / 3.8 cho văn bản kiểu tiếng Anh và 1 token cho mỗi ký tự CJK. ±5-10% cho văn xuôi, tệ hơn cho văn bản nặng code hoặc có cấu trúc.
Tại sao không tokenizer thật? tiktoken ~1 MB WASM, quá nặng chỉ để chunk-sizing. Nếu model downstream của bạn có giới hạn token cứng trên chunk (một số có, ví dụ cohere/embed-v3 giới hạn 512), build với biên độ an toàn hoặc chạy tokenizer thật trong pipeline.
Cho sizing thì ổn. Số token chính xác của mỗi chunk không quan trọng lắm cho chất lượng RAG — model embedding cắt input quá khổ dù sao. Quan trọng là tính nhất quán: cùng heuristic cho chunking và cho budgeting prompt downstream.

Bẫy thường gặp

Đừng chunk dữ liệu có cấu trúc (JSON, CSV) với text chunker. Ranh giới chunk rơi giữa record và embedding trở nên vô nghĩa. Tách theo ranh giới record trước, hoặc dùng cách tiếp cận RAG đặc thù cho tool.
Đừng chunk code với prose chunker. Cho retrieval code, ranh giới function mới quan trọng, không phải số ký tự. Chunker dựa trên tree-sitter có cho việc này.
Whitespace và BOM. Văn bản dán có thể mang whitespace ẩn làm sai lệch ước tính token. Trim và normalize trước khi dán nếu quan trọng.
Quyền riêng tư. Mọi thứ chạy trong trình duyệt. Tài liệu dán ở đây không bao giờ rời trang; bạn có thể dùng cho tài liệu mật hoặc chứa PII giống như dùng script local.