RAG Architecture
Follow the complete path from document parsing and indexing to hybrid retrieval and Customize Model responses.
UnieAI Studio's RAG (Retrieval-Augmented Generation) pipeline has two main stages: it first turns documents into searchable chunks, then retrieves relevant content and adds it to a Customize Model request when a user asks a question.
Knowledge-base queries currently use Hybrid Search. The public search flow does not select a separate semantic-only or full-text-only mode for each query.
1. Document parsing and asset storage
Documents do not all pass through the same VLM or OCR pipeline. Processing is selected by file format:
| Document type | Main processing path |
|---|---|
| PDF and images | Extract page text, layout, page images, and recognizable figure information; use VLM or OCR when needed |
| Plain text and source code | Decode the original text while preserving its structure |
| Office documents such as Word and PowerPoint | Convert and organize text, headings, pages, or slides |
| Tables such as CSV and Excel | Preserve sheets, column names, and row relationships for table-oriented retrieval |
The parsed output retains document, page, source kind, MIME type, title, and image metadata so a retrieved result can be traced to its source.
2. Chunk creation
Chunking follows the shape of the content instead of applying one fixed character window to every file:
- Tabular documents are grouped by sheet and row range, with column headers retained in each chunk.
- Page-based documents can use page, line-range, and paragraph structure.
- General text can be split by headings, paragraphs, semantic boundaries, and size.
- Recognized figures can become standalone figure chunks linked to their image assets.
- If an advanced chunking model is unavailable, the system uses an available rule-based or semantic result so that one failed step does not necessarily block the entire document.
3. Contextual Retrieval
After chunking, the system attempts to generate a short document-locating prefix for each text chunk when a KB Chunking Task Model is configured. The prefix is prepended to both the stored content and the embedding input, so Dense Search and BM25 can benefit from it.
Contextual Retrieval is best-effort:
- It is skipped when no usable model is configured.
- If generation fails for one chunk, the original chunk is retained and document indexing continues.
- Figure chunks are already self-contained and do not receive an additional contextual prefix.
4. Milvus index
Each chunk is stored as one Milvus entity. The principal fields are:
| Field | Purpose |
|---|---|
chunk_id | Unique chunk identifier |
knowledge_base_id, document_id | Parent knowledge base and source document |
page_index, chunk_index | Page location and order within the document |
content | Displayed and BM25-analyzed text; includes the contextual prefix when generation succeeds |
embedding | Dense embedding vector |
sparse_embedding | BM25 sparse embedding generated by Milvus from content |
source_kind, mime_type | Source and file format |
document_title, section_title | Document and section titles |
page_image_key, figure_image_key | Page-image and figure-image references |
The embedding model is configurable by platform administrators; the architecture is not tied to one local model. Its output dimension must match the Milvus collection configuration.
5. Hybrid Search
Every query runs two searches:
- Dense Search converts the query into an embedding and uses COSINE similarity to find semantically related chunks.
- BM25 Search queries
sparse_embeddingfor matching keywords, identifiers, names, and exact terms.
The current implementation does not use Milvus advanced_search or server-side RRF. Dense and BM25 searches run separately. The application normalizes BM25 scores within the query, unions candidates from both searches, and calculates:
finalScore = vectorScore × 0.82 + lexicalScore × 0.18 + exactMatchBoostA small boost is added when the complete query string appears in the content. If BM25 is disabled or temporarily unavailable, dense candidates can still use application-side keyword overlap as their lexical signal. The resulting Hybrid Score is then used for minimum-score filtering, ordering, and the result limit.
6. Cross-knowledge-base merge
When a Customize Model links multiple knowledge bases, Runtime:
- Fetches candidates from each knowledge base.
- Merges and deduplicates chunks.
- Sorts all candidates across knowledge bases by score.
- Applies the configured global Top K only after the merge.
Top K is therefore the total result count after all linked knowledge bases compete, not a separate quota for every knowledge base. Knowledge-base, document, page, and source metadata are attached before the results become model context.
7. Runtime RAG
Linking a knowledge base enables retrieval even when Agentic RAG is disabled:
- Non-Agentic RAG searches linked knowledge bases with the original question and generated retrieval keywords, organizes the results, and adds them to the model request.
- Agentic RAG can repeatedly plan, search, and accumulate evidence within the maximum iteration count. It can also use configured API, SQL, MCP, or skill tools before producing the final answer.
If chunk retrieval fails, or when no explicit minimum-score rule would be bypassed, Runtime can fall back to page-level content. Fallback results are marked with their retrieval source and are not presented as Milvus Hybrid Search matches.
RAG supplies relevant context; it does not guarantee a correct answer. Test parsing, chunks, minimum score, and Top K with representative questions, and direct users to verify important claims against the original source.
Related documentation
Uploading Documents
Review supported formats, upload limits, and processing states.
Chunking Strategies
Learn how different kinds of content become chunks.
Search Strategies
Understand Hybrid Search, minimum score, Limit, and Top K.
RAG Setup
Link knowledge bases to a Customize Model and configure Runtime RAG.