Chunking
Chunking functions in unstructured
use metadata and document elements detected with partition
functions to post-process elements into more useful “chunks” for uses cases such as Retrieval Augmented Generation (RAG).
Chunking Basics
Chunking in unstructured
differs from other chunking mechanisms you may be familiar with. Typical approaches start with the text extracted from the document and form chunks based on plain-text features, character sequences like "\n\n"
or "\n"
that might indicate a paragraph boundary or list-item boundary.
Because unstructured
uses specific knowledge about each document format to partition the document into semantic units (document elements), we only need to resort to text-splitting when a single element exceeds the desired maximum chunk size. Except in that case, all chunks contain one or more whole elements, preserving the coherence of semantic units established during partitioning.
A few concepts about chunking are worth introducing before discussing the details.
-
Chunking is performed on document elements. It is a separate step performed after partitioning, on the elements produced by partitioning. (Although it can be combined with partitioning in a single step.)
-
In general, chunking combines consecutive elements to form chunks as large as possible without exceeding the maximum chunk size.
-
A single element that by itself exceeds the maximum chunk size is divided into two or more chunks using text-splitting.
-
Chunking produces a sequence of
CompositeElement
,Table
, orTableChunk
elements. Each “chunk” is an instance of one of these three types.
Chunking Options
The following options are available to tune chunking behaviors. These are keyword arguments that can be used in a partitioning or chunking function call. All these options have defaults and need only be specified when a non-default setting is required. Specific chunking strategies (such as by_title
) may have additional options.
-
max_characters: int (default=500)
- the hard maximum size for a chunk. No chunk will exceed this number of characters. A single element that by itself exceeds this size will be divided into two or more chunks using text-splitting. -
new_after_n_chars: int (default=max_characters)
- the “soft” maximum size for a chunk. A chunk that already exceeds this number of characters will not be extended, even if the next element would fit without exceeding the specified hard maximum. This can be used in conjunction withmax_characters
to set a “preferred” size, like “I prefer chunks of around 1000 characters, but I’d rather have a chunk of 1500 (max_characters) than resort to text-splitting”. This would be specified with(..., max_characters=1500, new_after_n_chars=1000)
. -
overlap: int (default=0)
- only when using text-splitting to break up an oversized chunk, include this number of characters from the end of the prior chunk as a prefix on the next. This can mitigate the effect of splitting the semantic unit represented by the oversized element at an arbitrary position based on text length. -
overlap_all: bool (default=False)
- also apply overlap between “normal” chunks, not just when text-splitting to break up an oversized element. Because normal chunks are formed from whole elements that each have a clean semantic boundary, this option may “pollute” normal chunks. You’ll need to decide based on your use-case whether this option is right for you.
Chunking
Chunking can be performed as part of partitioning or as a separate step after partitioning:
Specifying a chunking strategy while partitioning
Chunking can be performed as part of partitioning by specifying a value for the chunking_strategy
argument. The current options are basic
and by_title
(described below).
Calling a chunking function
Chunking can also be performed separately from partitioning by calling a chunking function directly. This may be convenient, for example, when tuning chunking parameters. Chunking is typically faster than partitioning, especially when OCR or inference is used, so a faster feedback loop is possible by doing these separately:
Chunking Strategies
There are currently two chunking strategies, basic and by_title. The by_title
strategy shares most behaviors with
the basic strategy so we’ll describe the baseline strategy first:
“basic” chunking strategy
-
The basic strategy combines sequential elements to maximally fill each chunk while respecting both the specified
max_characters
(hard-max) andnew_after_n_chars
(soft-max) option values. -
A single element that by itself exceeds the hard-max is isolated (never combined with another element) and then divided into two or more chunks using text-splitting.
-
A
Table
element is always isolated and never combined with another element. ATable
can be oversized, like any other text element, and in that case is divided into two or moreTableChunk
elements using text-splitting. -
If specified,
overlap
is applied between chunks formed by splitting oversized elements and is also applied between other chunks whenoverlap_all
isTrue
.
”by_title” chunking strategy
The by_title
chunking strategy preserves section boundaries and optionally page boundaries as well. “Preserving” here means that a single chunk will never contain text that occurred in two different sections. When a new section starts, the existing chunk is closed and a new one started, even if the next element would fit in the prior chunk.
In addition to the behaviors of the basic
strategy above, the by_title
strategy has the following behaviors:
-
Detect section headings. A
Title
element is considered to start a new section. When aTitle
element is encountered, the prior chunk is closed and a new chunk started, even if theTitle
element would fit in the prior chunk. -
Respect page boundaries. Page boundaries can optionally also be respected using the
multipage_sections
argument. This defaults toTrue
meaning that a page break does not start a new chunk. Setting this toFalse
will separate elements that occur on different pages into distinct chunks. -
Combine small sections. In certain documents, partitioning may identify a list-item or other short paragraph as a
Title
element even though it does not serve as a section heading. This can produce chunks substantially smaller than desired. This behavior can be mitigated using thecombine_text_under_n_chars
argument. This defaults to the same value asmax_characters
such that sequential small sections are combined to maximally fill the chunking window. Setting this to0
will disable section combining.
Recovering Chunk Elements
In general, a chunk consolidates multiple document elements to maximally fill a chunk of the desired size. Information is naturally lost in this consolidation, for example which element a portion of the text came from and certain metadata like page-number and coordinates which cannot always be resolved to a single value.
The original elements combined to make a chunk can be accessed using the .metadata.orig_elements field on the chunk:
These elements will contain all their original metadata so can be used to access metadata that cannot reliably be consolidated, for example:
During serialization, .metadata.orig_elements
is compressed into Base64 gzipped format. To deserialize .metadata.orig_elements
, you can use the elements_from_base64_gzipped_json
. For example: