Knowledge Bases¶
What Is a Knowledge Base?¶
A knowledge base is not another physical storage system, but a logical wrapper around Catalog. It hides the complexity of Catalog paths from agent developers, so agents do not have to connect directly to Catalog to browse data. Because it is a logical wrapper rather than a separate copy, the same Catalog data can be referenced by multiple knowledge bases. This is also why a knowledge base serves as a collaboration interface between data engineers and agent developers: one side governs the data, while the other passes processed content to agents, and both see the same underlying data.
The two roles focus on different things in the same knowledge base:
Perspective |
Primary concerns |
|---|---|
Agent developer |
Which file / table sources are available, whether processing is complete, whether retrieval and semantic configuration are accurate, and which agents are bound |
Data engineer |
Catalog paths corresponding to the data source list, processing job progress, semantic configuration accuracy, and the impact on associated agents |
Both sides see the same data and the same set of statuses. Any change either side makes to data sources, segments, or semantic configuration immediately affects the other side and all agents bound to the knowledge base.
Precisely because a knowledge base is a logical wrapper rather than a separate copy, it has two direct consequences:
A knowledge base is not an ordinary folder. Each knowledge base has a dedicated system-maintained data space in Catalog, with original material stored separately from processed output. The knowledge base itself manages associations between material and the knowledge base, processing status, and semantic configuration for structured data.
The same Catalog data can be referenced by multiple knowledge bases. Removing a data source from a knowledge base only removes this association. It does not affect the original file in Catalog or other knowledge bases that reference the same data.
File-based material and structured data can reside in the same knowledge base, but the system processes and uses them differently:
Data type |
Processing method |
Purpose |
|---|---|---|
File-based material (documents, spreadsheet files, images, audio, video) |
Content parsing, image-and-text understanding, audio and video transcription |
Retrieval and Q&A |
Structured data (data tables and their associated data) |
Semantic configuration (field meanings, metric definitions, business rules) |
Data Q&A and NL2SQL |
Position in the Product Flow¶
A knowledge base takes assets that have entered Catalog upstream (or have been uploaded locally), parses, segments, and semantically enriches them, and then makes them available to chat retrieval and agents:
Catalog files / tables, or local uploads
↓
Select as knowledge-base data sources
↓
Parsing · chunking · indexing · semantic configuration
↓
┌─────┴─────┐
↓ ↓
Chat and retrieval Bind to agents
For Catalog, a knowledge base is a downstream semantic processor; for agents and chat, it is an upstream knowledge provider. Changing data sources, segments, or semantic configuration affects all retrieval and agent answers that depend on the knowledge base. Before making changes, it is worth reviewing which agents are bound to the knowledge base (see Creation and Data Sources · Agent Associations).
Two Things to Understand Before Use¶
An ingested data source does not mean the content is available for Q&A. After a file is uploaded or associated with a knowledge base, it must still be processed. Only processed content can reliably participate in retrieval and Q&A. To confirm whether material has actually taken effect, check both its processing status and actual retrieval results rather than looking only at whether the original file still exists.
Knowledge base permissions do not replace permissions on the underlying data. Even if a user can use a knowledge base, their actual access to Catalog, databases, data tables, or original files remains subject to the corresponding underlying permissions. For authorization operations, see User Permissions.
Capabilities¶
The following list is grouped by the two perspectives above for reference as needed. “Ingestion and governance” and “Semantics and retrieval quality” are closer to the routine maintenance work of data engineers, while “Chat and binding” is what agent developers use first.
Ingestion and governance
Create, view, edit, delete, and search; maintain names and descriptions
Local upload (unstructured files; structured ingestion of CSV/XLS/XLSX), and ingestion of files and data tables from Catalog
Bind text Embedding at creation time (with optional image indexing)
Process file content and view processing status; enable or disable data sources and manage validity periods, tags, versions, and downloads
Semantics and retrieval quality
Maintain segments for text / images / tables / transcripts and more
Configure ten types of semantics for structured data and NL2SQL
Chat and binding
Knowledge base chat: multiple sessions, multiple selected knowledge bases, model selection, source citations, and streaming answers
Upload images in chat as part of a question; image retrievability depends on image indexing and parsing
View associated agents; bind knowledge bases within agents (an operation on the agent side)
Permissions
Role-based permissions to create, view, modify, delete, and use (see User Permissions for operations)
Currently excluded from the capability list:
Item |
Description |
|---|---|
Golden Set / knowledge-base-level evaluation and automatic optimization |
The product has no such page. Advanced Configuration contains only Data Sources, Semantic Configuration, and Agent Associations. “Quality evaluation / Hallucination evaluation” in chat are only controls for the current conversation, not separate evaluation capabilities |
Direct connection to an external database directory / federated source retention |
Neither the current product nor the Catalog selector supports this. Export external data before uploading it, or first add it to Catalog and then ingest it |
Analysis templates |
The UI marks these as temporarily unavailable / coming soon |
Recommended Getting Started Path¶
Confirm that the processing status is “Completed” in Data Content Management.
Maintain Segments and Semantics when needed.
Ask questions directly in Chat and Retrieval to validate the results.
To build a deliverable application, bind the knowledge base in Agents.
Pages in This Guide¶
Page |
Content |
|---|---|
Create / edit / delete; local and Catalog ingestion; data source list; agent associations |
|
Processing, status, and maintenance of unstructured / structured content (enablement, validity periods, versions, and so on) |
|
Intelligent segmentation; ten types of semantic configuration |
|
Multi-session Q&A, source citations, image questions |