RAG Profiles

A RAG profile groups, under a reusable name, all the settings that drive how a knowledge base works: document chunking, retrieval method, result fusion, final selection, and optional AI features (contextualization, reranking, query decomposition). It's attached to a knowledge base from Manager → Knowledge Bases → Indexing → Advanced settings, or can be overridden for a specific RAG node in a pipeline (see the pipeline editor).

7 profiles ship by default: Generic (reproduces legacy behavior, no AI option enabled) and 6 business presets (Finance, Accounting, Legal, HR / Employment, Quality, Tenders), each pre-tuned for its domain. All 7 are directly editable from the RAG Profiles screen — no need to duplicate them before changing them. An Import a profile button lets you recreate a preset as it originally was, at any time, if your customized version has drifted too far.

note

A knowledge base with no profile attached (« — None — ») keeps its legacy behavior: chunking/extraction/embedding configured directly on the base, no advanced AI option (contextualization, reranking, decomposition) available.

Two distinct moments: indexing and query

This is the most important distinction for understanding a profile's cost:

• At indexing time (base creation or manual reindex) — chunking, contextualization and metadata extraction run once per document, when it's indexed or reindexed. One-off cost.
• At query time — every time an AI module needs context, retrieval, fusion, selection, reranking and query decomposition run again. And a "query" happens for every segment of the document being checked, not once per job: a 150-segment document queries the base 150 times. In chat mode, it's once per conversation turn — a rhythm much closer to what you'd expect from a typical RAG chatbot.

note

Options that cost an AI call at query time (reranking, decomposition) are therefore repeated for every segment. On a long verification document, that can mean dozens, even hundreds, of extra AI calls for a single job — weigh that against the precision gained before turning them on for a large knowledge base.

Chunking (indexing)

• Fragment size (chunk_size) — number of characters per fragment before vectorization. Default 900 (Generic). Larger: fewer fragments, more context per result, but less precise search and more expensive fragments once injected into the agent's prompt. Smaller: the opposite.
• Overlap (chunk_overlap) — characters repeated between two consecutive fragments, so information isn't lost at a boundary. Default 150.
• Parent/child ratio (parent_multiplier) — multiplier of chunk_size for the size of the "parent" section returned when small-to-big is active (see below), capped at 8000 characters. Default 4.
• Chunking strategy (chunking.strategy) — default (recursive) or structural (detects Article/Title/Clause markers, used by the Accounting/Legal/HR presets). Not editable from the RAG Profiles screen today — inherited from the source preset, kept as-is if you edit or duplicate the profile.

No direct AI-inference cost — this is mechanical text splitting.

Embedding model

The model that vectorizes each fragment (embedding_model_id, configured at the knowledge base level, not the profile). Every vectorization call is a real, billable network call:

• At indexing time — one call per batch of fragments (up to 64 at once). This is the only part of embedding whose cost is tracked and shown in Finances.
• At query time — one call per query (or per sub-question if decomposition is active). This cost is real but not tracked in Finances: it's considered negligible compared to a generation or reranking call.

Retrieval and fusion (query time, no AI cost)

Pure database search (pgvector + PostgreSQL full-text search) — no AI model call, whatever the setting.

• Hybrid search (hybrid) — combines vector search (meaning) and lexical search (exact words, useful for account numbers, references, technical terms). Enabled by default on every preset.
• Candidates examined (fetch_k) — number of candidates pulled before fusion/selection. Higher = broader search but slower (database load, not AI). From 30 (Generic) to 120 (Legal) depending on the preset.
• Semantic / lexical weight (w_dense / w_lexical) — weighting of each channel in the RRF fusion. A higher lexical weight favors exact matches.
• RRF constant (rrf_k) — parameter of the Reciprocal Rank Fusion algorithm. Fixed at 60 for every preset, not editable from the RAG Profiles screen today.

Selection

• Results returned (top_k) — number of fragments finally passed to the agent after fusion/selection. From 5 (Generic, Tenders) to 10 (Legal).
• Relevance threshold (min_score) — minimum score below which a result is dropped. Off (no threshold) by default, or around 0.35 on business presets.
• Excerpt length (candidate_char_limit) — truncation of each candidate in the reranking prompt (only affects reranking, not the text actually passed to the agent). Default 500 characters.
• Result diversity (use_mmr, Maximal Marginal Relevance) — keeps top_k from being monopolized by near-duplicate fragments, in favor of a more varied set. Purely algorithmic, computed on vectors already in memory — no AI-inference cost, regardless of its state.
• Return the parent section / small-to-big (use_parent_child) — returns the whole section a matched fragment came from, not the fragment alone. No extra AI call (the parent text is already stored at indexing time), but longer prompts for the downstream agent — so a higher, indirect generation cost.

Reranking — AI cost at query time

• AI reranking (use_reranking + the model picked right below it) — retrieves more candidates (fetch_k) then an AI model reclassifies them in a single listwise call to keep only the most relevant. Works with any already-configured model, including a free/local Ollama model.

note

This is not always a single call per segment. If the analyzed segment contains several distinct lines, each line queries the base — and therefore reranks — separately; same thing if query decomposition (below) produced several sub-questions. Reranking then runs once per line/sub-question, not once for the whole segment. This is exactly why reranking is off by default on every preset except Generic.

Query — decomposition and filters

• Query strategy (query_strategy) — default (no transformation) or decompose: one AI call that splits a complex question into up to 4 independent sub-questions, each searched separately then merged. Costs one more AI call per segment, however many sub-questions come out of it.
• Filtering by extracted metadata (extract_filters) — one AI call that tries to extract, from the question, a value for each field defined in enrichment (below — fiscal year, jurisdiction, version date…), to narrow the search to matching documents. Only has an effect if enrichment fields exist on the profile.

note

Decomposition and filter extraction share the same AI model (the profile's query.ai_model_id field) — but that field isn't exposed in the RAG Profiles screen yet: in practice, the base's own contextualization model (contextual_model_id) is always used for both options today.

Enrichment (indexing, AI cost)

• Metadata fields (enrichment.metadata_fields) — a preset can define fields to extract from every document at indexing time (e.g. fiscal year and currency for Finance; jurisdiction and version for Legal). One AI call per document, at indexing time — reuses the contextualization model. These fields also feed the metadata-based filtering above. Not editable from the RAG Profiles screen today — inherited from the source preset.

Chunk contextualization (indexing, AI cost)

• Contextualization at indexing time (use_contextual_retrieval + the model picked) — before indexing, an AI model writes a sentence situating each fragment within the document (helps when an isolated fragment loses its referent: "it", "this method", "in 2023"…). One AI call per batch of 8 fragments (not one per fragment), batches processed in parallel. Paid once per document at indexing time — except for a document indexed through the Document index node, rebuilt on every job run, where this cost is therefore paid on every run.

Executor — no direct AI cost

• Per-line cap (per_line_cap_single / per_line_cap_multi) and result budget (result_budget) — how many fragments, at most, actually get injected into the agent's prompt after all the processing above. Trigger no extra AI call, but reduce how many fragments are passed on — and therefore the downstream agent's generation cost. Default 10 / 3 / 10. Not editable from the RAG Profiles screen today.

Cost summary

Parameter	AI call?	When	Frequency
Chunking, RRF fusion, hybrid, fetch_k/top_k/min_score	No	—	—
Diversity (use_mmr)	No (vector computation)	—	—
Small-to-big (use_parent_child)	No (indirect cost: longer prompts)	—	—
Embedding model	Yes	Indexing (tracked) + query (untracked)	Per fragment batch / per query
Contextualization	Yes	Indexing	1 call / batch of 8 fragments / document
Enrichment (metadata)	Yes	Indexing	1 call / document
Query decomposition	Yes	Query	1 call / analyzed segment (or / chat turn)
Filtering by extracted metadata	Yes	Query	1 call / analyzed segment (or / chat turn)
Reranking	Yes	Query	1 call / line or sub-question — can multiply

See also

• Knowledge Bases
• AI Cost Tracking
• Embedding Models
• Document Index