我们继续上篇（详解Github 35K+项目：打通200+数据源，构建企业级AI的数据统一入口，支持MCP【上篇】）来学习MindsDB这款开源的AI数据引擎。上篇我们已经体验到MindsDB的两大集成能力：数据源（RDBMS、文件、向量库等）的集成与AI模型（传统ML模型、语言模型、嵌入模型等）的集成。其独特之处在于：让你用一种统一的SQL接口方式来查询所有的数据源与模型，并能够巧妙的融合。-
把数据表与LLM连接，输出批量推理结果（如生成文本字段的摘要）
- 把数据表与嵌入模型连接，再与向量库连接，创建某字段的向量索引
这里的第二种场景中，如果把一个文件映射成“表”，然后通过一个SQL，就可以直接给这个文件创建向量索引。比如：create table my_chromadb.collection_name
(
select m.embedding as embeddings,f.content,f.metadata
from files.table1 f join my_emb_openai m
)
现在你可以查询这个向量库中的“表”实现语义检索、拓展应用（如RAG）。尽管这个过程已经非常直观与友好，但是你仍然需要如下步骤：- 映射数据源（DB或者文件）：用来读取需要向量化的数据
- 重排序（可选）：对检索的内容通过Rerank模型重排序
为了简化这样的场景，MindsDB推出一种更高级的特性：知识库（Knowledge Base）。知识库就是融合嵌入模型、向量数据库、Rerank模型的能力，把上述多个数据组织步骤进一步简化的一种虚拟AI“表”。
下面通过具体的例子来演示其工作方式，并了解其背后的工作原理。以之前导入的一个包含若干FAQ问答的Word文档为例，这文档已经被映射成一个文件数据源，通过SQL可检索：select * from files.sales_questions
现在如果你想针对content（其实是源文件内容分割后的chunk）创建向量索引，就可以借助知识库（Knowledge Base）模块，首先创建一个知识库：create KNOWLEDGE_BASE my_sales_question_kb
using
content_columns = ['content'],
preprocessing = {
"text_chunking_config" : {
"chunk_size": 1000,
"chunk_overlap": 100
}
}
- 模型：包括嵌入和Rerank模型，这里使用config.json中的默认模型
- 向量库与数据源对应关系：这是用来指定向量数据库中的信息对应的数据源的列，包括id_column（标识唯一的向量）、metadata_columns（向量元数据的列，可以多列）、content_columns（需要生成向量的列，可以多列）
- 预处理参数：用来指定对content列预处理的参数，典型的如需要分割成的chunk大小(chunk_size，默认500)等
现在就可以直接向知识库中插入数据，无需指定列信息，MindsDB会自动根据知识库创建的参数映射：insertinto my_sales_question_kb
select * from files.sales_questions
MindsDB会自动完成创建嵌入模型、创建向量库、利用嵌入模型生成向量、将向量与Metadata等保存到向量库这一系列动作。在知识库创建完成后，你可以不带任何条件的查看其数据：select * from my_sales_question_kb
注意MindsDB知识库的结构是固定的，包括ID、chunk_id、chunk_content、metadata等列，这些数据正是根据你在创建时的参数从数据源生成：当然这样的检索并无实际意义。知识库最大的价值是可以进行语义检索，比如:select * from my_sales_question_kb
where content = '客户出一个超低价时怎么办？或者说：客户为什么会出"超低价"？'
relevance >=0.7 limit5
注意语义检索的字段必须是content。这里用SQL的方式完成了语义检索，相比其他的方式更直观与简单。- 使用relevance来限制语义相关度（或者distance）
由于MindsDB把知识库也当做了一种“表”，因此你也可以把它与其他数据源的做JOIN，从而实现更加复杂的向量+标量、结构化+非结构化的多条件混合检索场景。以之前在介绍OceanBase文章中提到的一个查询为例：推荐几款操作流畅的受女生喜欢的手机，苹果或者华为的，价格低于1万。如何在数据不离开RDBMS，而RDBMS自身又不支持向量的环境下做这个检索呢？或许借助MindsDB可以轻松实现。首先你需要参考上面的过程，针对产品（假设存放在Postgres数据源中，表名为products）创建一个可用来语义检索的知识库，比如名称为my_kb，ID列为product_id，Content列为手机的文本介绍。SELECT p.product_id,p.product_name,p.description
FROM my_kb as k join my_postgres.products as p
on k.id = p.product_id
WHERE k.content = '操作要流畅，受女生欢迎的手机'and relevance >= 0.5and
p.brand in (
'苹果','华为') and p.price 10000
limit5
这里首先利用知识库my_kb在content上做语义匹配找到相关产品，然后通过k.id = p.productid关联回原始产品表p，进一步在SQL层面按品牌和价格进行了过滤。最终结果返回的就是同时满足语义条件和结构化条件的产品列表。你甚至可以把两个知识库做JOIN，同时加入两个不同的语义检索条件。这种混合查询相信在很多企业应用场景非常有用，因为传统应用的高价值信息大多在RDBMS，需要结合AI时代的非结构化文本处理，借助MindsDB这种数据“中间件”，实现既简单又直观。由于知识库的背后有一个基于数据源创建的向量库，那么这个向量库与数据源之间如何同步呢？这也是很多新的“AI数据孤岛”常面临的麻烦。在MindsDB中你可以借助JOB这个机制（CREATE JOB）来实现定期、自动化的同步处理。这种同步可以是：这种同步机制非常类似于Oracle的JOB或MySQL的Event Scheduler机制，借助于ID列，可以轻松让知识库根据数据源定期同步：当然，如果你有更实时的同步需求，也可以考虑MindsDB的Trigger（触发器）机制，不过该机制存在数据库限制。知识库可以用来语义检索，那么就可以在此基础上快速构建一个RAG（Retrieval-Augmented Generation，检索增强生成）管道：无非是把检索出的内容输入给LLM，由于LLM在MindsDB中也是一种可以查询的“表”，所以你可以用“表”连接来查询RAG答案：
select answer
from (
SELECT '你是一个销售管理的专家。
请参考以下的上下文，适当的组织，回答销售提出的问题。
如果上下文无法解答，请表示歉意，不要编造。
直接给出答案，不要多余解释。使用Markdown格式。
'+group_concat(chunk_content)+'
------------
销售的问题是:
' + '客户出一个"超低"价时怎么办？或者说：客户为什么会出"超低价"？？'
as question
FROM `my_sales_question_kb`
WHERE content = '客户出一个"超低"价时怎么办？或者说：客户为什么会出"超低价"？'
limit 3) as prompt join my_llm_openai_answer这是一个有趣的SQL RAG管道！执行后可以直接得到答案：它包含了基础的语义检索、重新排序、相关性过滤、记录数限制，在召回若干chunk后，用group_concat函数合并；然后把它们组装成提示词，用“JOIN”的方式输入给LLM模型（把模型看做包含question和anser两列的“表”）。尽管在一些高级RAG特性上可能还不够强大（比如多模态、融合检索），但在一些简单的需要“嵌入式RAG”管道的场景中，却是一种技能要求最低的方式。不过这种方式仍然不够直观，在MindsDB的新版本中，提供了更加强大的 Data Agent（或者SQL Agent）模块。一个围绕特定数据集和模型、配置好技能的智能数据问答智能体。
通过指定Agent可以访问哪些表和知识库、使用哪个LLM模型来生成回答，以及一个提示模板来指导LLM回答，就可以完成一个Data Agent的创建。定义好后，Agent就能接受自然语言问题输入，自动在授权的数据源中检索信息，然后由LLM综合给出答案 。举个例子，假设想构建一个面向客服或销售的“产品咨询助手”。它可以访问产品库、客户和订单数据库，还能从产品描述知识库中获取语义信息，最终通过一个LLM生成答案。你可以这样配置 Agent：CREATE AGENT my_agent
CONFIGURE
engine = 'openai',
model = 'gpt-4o',
openai_api_key = ''
USING
knowledge_bases = ['my_kb'],
tables = [
'my_postgres.products',
'my_postgres.customers',
'my_postgres.orders',
'my_postgres.order_items'
],
prompt_template = '
- 知识库 my_kb：包含产品描述的语义向量索引，可用于理解产品特性；
- 表 my_postgres.products：产品的结构化信息（名称、品牌、价格等）；
- 表 my_postgres.customers：客户详细信息；
- 表 my_postgres.orders 与 order_items：历史订单及明细。'
;
- 用知识库my_kb以及四张Postgres表作为数据源
SELECT answer
FROM my_sales_question_agent
WHERE question = '';
此外还可以在客户端通过SDK来调用；甚至通过A2A协议调用这个Agent。MindsDB的Agent本质上是一个LangChain实现的服务端Agent，只是MindsDB自动完成了一些工作，包括工具的创建和提示词的设定等。内部架构如下：当用户提出问题时，Agent会借助它的两大技能完成数据检索，获得参考的上下文，最后组织答案并输出。- 知识库查询：对知识库执行语义检索，并返回相似的记录
- 文本到 SQL：自然语言转SQL查询，从数据源检索数据
Agent是MindsDB在其核心能力（数据源与模型的集成与统一访问）上层提供的应用侧模块。在一些特定场景下，比如客服自动化、即席数据查询、简单决策分析等，可以借助它来简化工作量。个人测试结果看，MindsDB Agent目前还不够完善，不适合在严格商业环境下的使用，Text2SQL、知识库工具出错概率较大（也和模型有一定关系）。MindsDB近期还支持了A2A以及MCP协议。这意味着可以将MindsDB中的融合数据查询、Agent等能力无缝集成到更大的智能体系统中，为企业构建复杂AI应用提供了极大的灵活性。作为一款开源产品，MindsDB是一个强大的企业数据层的智能“中间件”，它以“数据不出库，AI进库来”的模式，帮助解决企业AI应用落地中的数据环境复杂、遗留系统多、数据融合困难等难题。-
无需搬移数据就能跨源的数据访问，避免重复存储和时滞
- 无需复杂开发就能使用各种AI模型，用SQL降低了AI门槛
- 一种基于SQL扩展的融合数据访问方式，学习成本非常低
- JOB、触发器等机制帮助实现自动数据同步与模型训练
- 丰富的客户端开发接口，支持SDK、REST、MCP/A2A等
适合作为复杂企业环境中（比如多异构数据源或遗留系统）的“虚拟AI数据底座”，对上层应用提供融合与智能的统一数据访问接口。特别是希望以最低的学习成本，在传统企业技术栈的基础上引入与集成AI能力，可以考虑灵活应用。推荐学习本公众号最新出版的作品：
📘《MCP原理揭秘与开发指南——构建可扩展的AI智能体》
详情点击下方链接
识别以下名片
