Vectorising and tagging

Much of a RAG’s quality is decided before the first question: how documents are chunked, what information each chunk carries and which model computes its vectors. This page walks through the ingestion flow step by step.

File → text → chunks (+ context) → tags → vectors → vector database

1. Where documents come from

Source	Component	How to get the text
Your NappAI storage	Storage Files	Operation Get File with Content Text. It returns the text and the file’s data (name, path, type, date).
PDFs reaching the flow	PDF Extractor	Returns the text in order, with headings and tables.
Google Drive	Drive File Manager	Operation Get with Process File Content on.
Web pages	URL	Reads the text of the addresses you give it.

If your documents are in NappAI storage, upload them once from the dashboard (see Storage) and the ingestion flow reads them when you run it.

2. Splitting into chunks

An agent cannot read a whole manual for every question, and the vector of a long document mixes too many topics. That is why the text is split into chunks of a few hundred characters. All splitters are in the Text Splitters category.

Splitter	How it cuts	When to use it
Recursive Character Text Splitter	By paragraphs; if a paragraph is too long, by lines and then by words.	The default choice for manuals, policies and FAQs.
Contextual Text Splitter	Like the previous one (or by sentences, with Split Method), and a model also adds a sentence of context to each chunk.	Documents whose sections do not repeat what they are about. See step 3.
CharacterTextSplitter	By a fixed separator you choose.	Texts with a clear mark between blocks, for example a --- line between product sheets.
Semantic Text Splitter	By meaning: it cuts where the topic changes, using a vector model.	Long unstructured texts, such as transcripts.
Natural Language Text Splitter	Respecting sentence endings in the language you choose.	Running text where you do not want sentences split.
Language Recursive Text Splitter	Respecting the structure of a programming language.	Source code or technical documentation with a lot of code.

Size and overlap. Chunk Size is the maximum size of each chunk, and Chunk Overlap is the text two consecutive chunks share, so that an idea cut in half is whole in one of them.

Setup	Chunk Size	Chunk Overlap	Result
Splitters’ defaults	1000	200	A good starting point.
Our measurements	800	150	9 documents gave 80 chunks of about 620 characters on average.
The advanced RAG video	700	100	Shorter chunks for a manual with short sections.

As a guide: between 500 and 1000 characters, with an overlap of 10 to 20 %. Smaller chunks give more precise results with less context; larger ones, the opposite.

3. Adding context to every chunk

Many chunks do not say what they are about. In a coffee machine manual, the section on an error can start with “This code means the probe is not responding” without naming the machine. That chunk is hard to find, and if three machines have an E07 error, the search cannot tell which is which.

Contextual Text Splitter solves it: a model reads the whole document and writes one or two sentences for each chunk that place it. For example:

	Text
Chunk	”This code means the temperature probe is not responding. Check its resistance with a multimeter…”
Context it adds	”From the Q90 espresso machine technical manual, error codes section: error E07.”

The stored chunk carries the context in front (the text field), plus the context and chunk fields separately, together with the original document’s data.

What you get (measured on 17 October 2026, 9 documents and 40 questions, in Spanish):

• With basic search, the right answer was among the first five results for 93 % of the questions, against 83 % without context.
• With context, hybrid search and Local Rerank, the answer was the first result for 80 % of the questions about documents and among the first five for all of them (measured again on 18 October).

What it costs. One model call per chunk, only at ingestion: questions cost nothing extra. Each call sends the whole document, so the cost grows with document size. In our measurements, 80 chunks meant 80 calls and about 1,800 input tokens per chunk, and took 23 seconds with 5 requests in parallel (Parallel Requests). A fast, cheap model is enough; the video uses DeepSeek.

4. Choosing the vector model

The vector model (embeddings) turns every chunk and every question into a vector. It has the biggest influence on the quality of basic search.

Option	Component	Advantages	Keep in mind
Local, on the platform	FastEmbed Embeddings (Local)	No API key, no per-use cost, your texts do not leave NappAI.	It takes a few seconds to load the model the first time.
Provider	OpenAI Embeddings, Cohere, Mistral, Google, Azure OpenAI, Amazon Bedrock…	Each provider’s models, no initial load.	Needs its credential, costs per use and texts are sent to the provider.
Your model server	Ollama Embeddings	The models in your Ollama.	You need that server running.

What we measured with Spanish texts (result: right answer among the first five results):

Model	Component	Hits	Speed per question	Comment
jinaai/jina-embeddings-v2-base-es (default)	FastEmbed Embeddings (Local)	83 %	10 ms	The best balance of quality and speed. Spanish and English. 768 dimensions.
intfloat/multilingual-e5-large	FastEmbed Embeddings (Local)	87 %	30 ms	One question more than the previous one, but 3 times slower per question, 3.5 times larger and 2.4 times slower to store.
Snowflake/snowflake-arctic-embed-l-v2.0	FastEmbed Embeddings (Local)	83 %	22 ms	The one that most often put the answer first (70 % against 60 % for the default). As heavy and slow as the previous one: measured together, both took 22 ms. 1024 dimensions.
sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2	FastEmbed Embeddings (Local)	63 %	6 ms	The lightest, but built to compare sentences, not to search.
bge-m3	Ollama Embeddings	73–80 %	20 ms	Fine, without beating the default.
nomic-embed-text	Ollama Embeddings	53–57 %	13 ms	Built for English: it finds codes, but misses half of the questions phrased in other words in Spanish.

In short: keep the default model of FastEmbed Embeddings (Local) unless you have a reason, and avoid English-only models if your documents are in Spanish or another language.

Always the same model

Store and search with the same model. If you change it, run the ingestion of all documents again. In Neo4j, the vector index is also created with the model’s dimensions (768 for the default model).

5. Tagging the chunks

Tags are data on each chunk (machine, topic, brand, month…) that searches can later filter by. Metadata Tagger fills them in with a model that reads every chunk.

In Metadata Schema you describe the fields with the schema editor: for each one, its name, its type and what it means. If a field only takes certain values, write them in the description. It is the same format SelfQueryRetriever uses to filter, so you can copy the schema from one component to the other.

This is the schema from the English video:

Name	Type	Description
machine	string	Machine the text is about: Q90, DL5, M7, or general if none.
topic	string	One of: fault, maintenance, warranty, rates, questions.
codes	array	Error or alarm codes that appear, such as E07 or A2.

The possible types are string (text), integer (whole number), number (number with decimals), boolean (yes or no) and array (a list of values).

A lesson from the measurements: one value or several

In our test, an “error code” field declared as text got a single code on a chunk that discussed three. Filters on that field found the wrong chunks, and questions needing a filter scored lower with tags (50 %) than without them (83 %, using each document’s own data). So:

• If a field can have several values in the same chunk, declare it as array.
• The fields that filter best are single-valued by nature: document type, brand, model, month.

Useful options: Overwrite Existing Values (off by default) keeps the value the document already had; Instructions adds guidance, for example how to write product names. Cost: one short call per chunk; in our measurements, about 330 input tokens per chunk and 15 seconds for 80 chunks.

6. Keep each document’s data

Besides tags, every chunk inherits its document’s data: Storage Files provides the file’s name, path and type, and both Contextual Text Splitter and Metadata Tagger keep them. Store with every chunk at least:

• The source (file name), so the agent can say where the answer comes from.
• The document type (manual, policy, report, FAQ).
• The brand or product, if your documents cover several.
• The period (month or year), if you have reports that repeat with the same structure.

With that document-level data, SelfQueryRetriever got 83 % of the questions that needed a filter, against 33 % for search without filters.

Next step

With the chunks stored, choose how to search them: Retrieval techniques.