External Knowledge Base plugin
In NocoBase, a External Knowledge Base plugin extends the RAG retrieval sources available to AI employees. For most use cases, a Local knowledge base is enough. You only need an external knowledge base plugin when documents, vector data, or retrieval logic are already maintained by an external system.
An external knowledge base plugin does not participate in document upload, segmentation, vectorization, or deletion in NocoBase. It only receives retrieval requests during AI employee conversations and returns matching document segments.
- Knowledge base overview - Understand the boundaries of Local, Readonly, and External knowledge bases
- Plugin - Understand server-side plugin lifecycle and
this.app.pm - i18n - Prepare translations if the plugin provides a configuration form
Use cases
External knowledge bases are suitable for these cases:
- You already have an independent RAG service, such as an internal knowledge base service or a third-party retrieval API
- You need to connect to a vector database that NocoBase does not support out of the box
- You need to process business rules before or after retrieval, such as permission checks, tenant isolation, reranking, or deduplication
- The document lifecycle is fully maintained by an external system, and NocoBase only reads retrieval results during conversations
If you only want to upload files in NocoBase, split documents automatically, and generate vector indexes, use a Local knowledge base by default.
Extension point
External knowledge bases are registered through the vectorStoreProvider extension point provided by @nocobase/plugin-ai. The server side needs to implement two objects:
providerName is the unique identifier of an external knowledge base provider. The provider selected or entered when creating an External knowledge base must match the providerName registered on the server side.
Register the Provider
In src/server/plugin.ts, get the AI plugin instance and register your VectorStoreProvider:
The load() stage is suitable for registering extension points. You do not need to connect to the external vector database here, and retrieval requests should not be executed here. Put the actual connection and query logic in VectorStoreService.
External knowledge base plugins always depend on @nocobase/plugin-ai-knowledge-base. It is recommended to check the dependency in beforeEnable():
This gives users a clear error message if the required plugin has not been enabled.
Implement the Provider
The Provider only needs to provide providerName and create a service based on the knowledge base configuration.
vectorStoreProps comes from the external knowledge base configuration form, such as API endpoint, API key, Embedding model, tenant identifier, and similar parameters. NocoBase passes these values to the Provider when running retrieval.
Implement the Service
The Service is the core retrieval logic. For an External knowledge base, it usually only needs to convert external retrieval results into the DocumentSegmentedWithScore[] format required by NocoBase.
Key points:
query- The question that the AI employee needs to retrieve againsttopK- The expected number of returned segmentsscore- The score threshold configured in the AI employee knowledge base settingsvectorStoreProps- Parameters filled in through the external knowledge base configuration form
The VectorStoreService interface includes getVectorStore(). An External knowledge base is only responsible for retrieval and does not let NocoBase manage the underlying vector store, so the example throws an error directly.
Return retrieval results
search() must return DocumentSegmentedWithScore[]:
Where:
contentis the document segment content passed to the large language modelmetadatastores source, document title, URL, permission information, and other metadatascoreis the retrieval score. It is recommended to normalize it so that a larger value means higher relevanceididentifies the external document segment, which helps with troubleshooting and deduplication
If the external service uses a different score meaning, such as smaller distance meaning higher relevance, convert it to a consistent relevance score before returning it to NocoBase.
Configure external knowledge base parameters
The server side can read vectorStoreProps directly, but these parameters usually need to be filled in when users create an External knowledge base. Therefore, the configuration form needs to be registered in the plugin frontend entry. After registration, NocoBase displays the corresponding fields in the knowledge base creation form and passes the values to the server side during retrieval.
Frontend form configuration is optional. If your external knowledge base does not require custom parameters from users, you do not need to register vectorStorePropForm.
For simple cases, use defaultVectorStorePropForm() by default. It receives an array of fields, creates one form item for each field, and uses an input that supports selecting NocoBase variables:
Register the configuration form in the plugin frontend entry:
The name here must match the server-side providerName. The key is the field name used when saving the parameter and passing it to the server side. The server side can read the value from vectorStoreProps with the same key.
Custom configuration form
Besides using defaultVectorStorePropForm(), you can also pass a custom React component to vectorStorePropForm:
Example plugin structure
An external knowledge base plugin can be organized as follows:
Where:
plugin.tsregistersVectorStoreProviderprovider.tsdeclaresproviderNameand creates the serviceservice.tsimplementssearch()and converts external retrieval results toDocumentSegmentedWithScore[]client/index.tsxregisters the external knowledge base configuration form
At this point, the external knowledge base plugin can be called by AI employees. After users create an External knowledge base and select the corresponding Provider, AI employee conversations can retrieve document segments through your search().
Related links
- Knowledge base overview - Boundaries of Local, Readonly, and External knowledge bases
- Plugin - Server-side plugin lifecycle and
this.app.pm - i18n - Plugin frontend and server-side translations
- Client plugin development overview - Client entry, components, and context capabilities

