> ## Documentation Index > Fetch the complete documentation index at: https://docs-eos.fpt.ai/llms.txt > Use this file to discover all available pages before exploring further. # Quick start > From uploading documents to connecting an agent - Step by step in the Enterprise Data Platform UI. This page follows the order you will work in: Put documents into a source, group them into a knowledge base, test retrieval, and only then hand the KB to an agent. Every step is done in the UI - No code required. ## Sign in and find your way around **1. Sign in** Open the platform URL from your administrator and click **Login with FPT**, or sign in with email and password. **2. Pick a workspace** The box at the top of the sidebar shows your current workspace and role (*Workspace owner*, *Member*). Click it to switch. The main function groups in the sidebar: | Group | Items | Used to | | - | - | - | | Ingest & process | Data sources | Bring documents into the platform | | Knowledge | Knowledge bases | Group documents into something agents can search | | Quality | Retrieval test · Quality evaluation | See what agents receive, measure with numbers | | Administration | Data governance · Members & roles | Metadata schema, users | **Overview** is the page to check every morning: How many sources are ready, how many documents are indexed, ingestion volume over the last 14 days, and **Needs attention**, which lists anything hurting answer quality - Such as a document that failed processing. The **Lineage** diagram at the bottom shows which source flows into which KB and which KBs agents are calling; click a node to open it. ## Step 1: Create a data source Every document enters the platform through a source. Today, sources are created by uploading files and folders. **1. Open the wizard** Go to **Data sources** → **Add data source** → select **Upload files & folders** → **Continue**. **2. Drop in files or whole folders** Drag a document folder into the box, or click *choose files* / *choose folder*. The queue on the right shows file count and size. **3. Name it and choose options** Give it a recognizable **Source name**, e.g. *Accounting Procedures 2026*. Two options worth turning on: * **Keep folder tree** - Folder names become metadata for filtering at retrieval time. * **Store only one copy of identical documents** - Stops the same text being returned twice. **4. Create** Review the **Source summary** and click **Create source**. Upload starts; you can close the dialog and keep working. > [!NOTE] > > The two options in step 3 are fixed at creation and cannot be changed later. ### Managing files in a source The source detail page has these tabs: | Tab | Used to | | - | - | | Browse files | Browse folders, create, rename, move, delete; filter *Ingested* / *Missing required metadata*; **Edit in Excel** for bulk metadata | | Upload log | See each upload batch and which files failed or were skipped, to re-upload | | Trash | Deleted files stay here 30 days, already removed from the index so agents no longer see them | | Settings | Rename the source, see which KBs use it, set **folder metadata rules**, delete the source | Each file's **⋯** menu has **Download**, **Rename**, **Move**, **Metadata**, **Delete**. **Folder metadata rules** save you from tagging files one by one: Set *muc\_do\_mat = 2* on the *Contracts/2026* folder and every file dropped in picks it up. Sub-folders inherit the parent rule; a value set manually on a file always wins. ## Step 2: Create a knowledge base The knowledge base is what agents actually search. Reading, chunking and embedding all happen in the KB, not in the source - So one source can feed several KBs processed differently. **1. Select data** Go to **Knowledge bases** → **Create knowledge base**. Tick one or more sources; expand the tree to pick only certain folders or files. Under **System sources** there is a ready-made *Legal documents* index, updated daily. **2. Choose a pipeline** Keep the default **Automatic per file** - The screen shows how each file type will be processed. **3. Name it and describe it for agents** Make the **Description for the agent** specific - Agents read it to decide when to call this KB. Add **KB managers** if others share responsibility. **4. Review and create** Check everything and create the KB. Processing and indexing start. The **Automatic per file** pipeline works like this: | File type | Processing | | - | - | | DOCX | Split by headings | | PDF | Extract text directly; OCR automatically for scans | | XLSX / CSV | Split by rows, keep column headers | | HTML | Strip menus, keep content | A good KB description, for example: > *"Internal accounting procedures for 2026: payments, advances, settlements, vouchers. Call this KB when users ask about procedures, required documents or processing deadlines."* ### Monitoring and tuning a KB | Tab | Used to | | - | - | | Documents | See each document's status (*Processed*, *Processing error*); **Edit scope** to change what is taken from the source | | Needs review | Work queue: files that failed, missing required metadata, user-reported errors, conflicts with the source | | Settings | Change pipeline, retrieval method, Top-K, score threshold, metadata fields used as filters | | Connect | MCP / REST URLs, tool name, API keys, authorized apps, call log | Pick the retrieval method by question type: | Method | Best for | | - | - | | Vector only | Free-form questions; fastest | | Full-text (BM25) | Document numbers, names, codes | | Hybrid + rerank | Both combined, then reranked - Default 70% vector, 30% BM25 | Three switches worth considering per document type: **Expand to parent chunk** (search small passages, return the whole Article), **Only return documents in effect**, and **Automatic metadata filtering** (infers department and time range from the question). ## Step 3: Test retrieval before handing the KB to an agent Wrong answers usually come from the agent receiving the wrong passages, not from the model. **Retrieval test** shows exactly what the agent will receive. **1. Pick KB and method** Open **Retrieval test**, choose the **Knowledge base** and **Query method**. **2. Add filters if needed** The **Metadata filter** box takes several conditions separated by `;`, with operators `=`, `!=` or `~` (contains). Example: `muc_do_mat=1;ten_tep~Luat`. **3. Ask a real question** Type a question real users would ask, adjust **Top-K** and **Similarity threshold**, click **Retrieve**. **4. Read the diagnosis** Review the returned chunks and the automatic **Diagnosis**. ## Step 4: Connect an agent Each KB has its own endpoints in the **Connect** tab, so you give each agent exactly the KB it needs and revoke independently. | Item | Format | | - | - | | MCP URL | `https:///api/mcp/kb/` | | REST URL | `https:///api/v1/kb//retrieve` | | MCP tool name | Generated from the KB name, e.g. `search_accounting_procedures` | | Exposed tools | `search_…` (search the KB), `get_document` (read a full document), `submit_feedback` (agent rates a passage) | **OAuth (recommended)** No key needed. Paste the MCP URL into an MCP client; on first connect the client opens a browser to sign in and click **Allow**. The agent reads the KB with that user's own permissions, revocable at any time under **Authorized apps**. ```json theme={null} { "mcpServers": { "search_accounting_procedures": { "type": "http", "url": "https:///api/mcp/kb/" } } } ``` **API key** Click **Issue new key for this KB**, then send it as `Authorization: Bearer ` or `X-API-Key: `. Turn on **MCP accepts OAuth only** to force agents to sign in (REST still accepts keys). **REST API** ```http theme={null} POST https:///api/v1/kb//retrieve Authorization: Bearer Content-Type: application/json { "query": "what documents are needed to settle an advance", "top_k": 6, "rerank": true, "include_citations": true } ``` The **Connect** tab has ready-made snippets for Claude Code, VS Code and Cursor - Click **Copy**. ## Monitor quality In **Quality evaluation**, add important questions to the **Golden question set** to check the KB regularly, and look at the **Live quality** tab to see what agents are asking that the KB cannot answer yet. Details on the [Quality evaluation](https://docs-eos.fpt.ai/en/screens/evaluation.md) page. ## Administration | Item | Used to | | - | - | | Data governance | Define the workspace metadata schema; export / import it as JSON; view change history | | Members & roles | Invite members, change roles, **Transfer ownership** | The metadata schema has two kinds of fields: *System fields*, always present and read-only (source, path, file name, format, size, uploader, upload date, page count…), and *Workspace fields* you create - e.g. *muc\_do\_mat* (picklist), *ngay\_hieu\_luc* (date, required). ## Current limits | Item | Limit | | - | - | | File formats | PDF, DOCX, XLSX, PPTX, TXT, MD, HTML | | Size | Up to 200 MB per file, 2 GB per upload | | Trash | Kept 30 days, then permanently deleted; no manual purge | | Workspace metadata fields | Up to 40 | | MCP tool name | Starts with a lowercase letter; lowercase, digits and underscores only; up to 64 characters; editable only while the KB has no API keys | | Deleting a source | Not allowed while a KB still uses it | ## Things to keep in mind > [!WARNING] > > **Note:** There are no document-level permissions yet - Every workspace member can read uploaded files, and anyone with a KB's API key can query the whole KB. Do not upload confidential documents. > [!NOTE] > > **Note:** Metadata field codes cannot be changed after creation. Labels can be renamed freely, but codes go straight into MCP tool parameters and CSV columns - Changing a code breaks every running integration. > [!NOTE] > > **Note:** The embedding model is locked once the KB is created, and every source in a KB shares one model. Changing it means re-embedding every chunk. > [!TIP] > > **Note:** Before removing someone who has left, transfer the sources and KBs they manage. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.