AI知识库不会做？使用低代码为AI提供四种范式的知识库查询MCP服务

引言

知识库是实现RAG方案的重要载体，是企业知识沉淀的通用方案，也是增强AI效果的重要手段。本文主要介绍使用低代码落地四种查询方式的AI知识库。借助不同类型的 AI 知识库，可以显著降低大模型在具体业务场景落地时的“幻觉问题”，让 AI 基于企业内部知识进行回答，从而真正把沉淀的知识用起来、发挥价值。

点击查看参考应用地址（葡萄城应用市场）：

一、为什么我们需要一个知识库

大模型火到现在，几乎每个技术团队都在琢磨同一件事：怎么让 AI 真正“读懂”自己的数据，并且回答靠谱、落地可维护？

但在动手之前，有一个更本质的问题需要先想清楚：我们为什么非要给大模型配个知识库？直接提问不行吗？

1. 模型的“记忆”只有7秒

大模型没有长期记忆，它的“脑子”只存在于一个叫“上下文窗口”的地方。一旦对话超长，或者模型本身就没被“喂”过你的私有数据，它就只能凭感觉“编”。你想让它回答“公司最新的差旅报销标准是啥？”，如果不给上下文，它大概率会给你生成一份看起来很专业、但完全不是你公司规定的文本——这就是所谓的模型幻觉。

2. 数据安全不能“裸奔”

企业的核心数据是命根子。ERP里的订单、客户信息、财务数据，不可能直接Copy给公网大模型去训练或推理。你需要一层“防火墙”，让模型在需要时能“问到”数据，但拿不走原始数据，这只有通过知识库的本地检索和工具调用才能实现。

3. “垃圾进，垃圾出”是铁律

原始文档本身就可能是过期的、混乱的、甚至自相矛盾的。如果直接把几百页PDF扔给大模型，它会被淹没在噪声里。知识库的核心价值不在于“存”，而在于“加工”——切片、清洗、向量化，把原始信息变成高密度的可计算知识。

4. 模型天生不擅长精确计算

大模型是“文科生”，不是“理科生”。让它写诗可以，让它统计“上个月18号之前A产品线的退货率”，它一旦去“算”，出错率极高。必须把它和数据库打通，让它把自然语言转成SQL，把计算交给数据库引擎。

5. 消除信息孤岛，需要统一“大脑”

你的文件服务器上有操作手册，Confluence里有技术方案，数据库里有经营报表。以前得人去各个系统里翻找，现在你需要一套能自动调度不同“检索方式”的混合智能——该查文件查文件，该跑SQL跑SQL，最后汇总成一个答案。

结论

正因为这些坑，知识库不再是“锦上添花”，而是企业落地AI的“入场券”。本文以葡萄城的AI驱动型企业级低代码开发平台活字格为例，介绍一下如何使用低代码落地知识库方案？这篇文章就从认知基础、底层技术策略，到四种范式实战，系统梳理一遍。

二、认知对齐：大模型的工程本质与MCP工具调用

1.1 LLM的本质：基于概率的“文本预测接龙”

很多人把LLM神化为“超级大脑”，但从工程角度看，大语言模型的本质就是一个基于概率的文本生成系统——通俗讲，就是“文本预测接龙”。

当你输入“活字格这个工具怎么样？”，模型内部并不是在思考，而是在做一道巨大的概率计算题：给定前面所有的文字，下一个词（Token）最可能是什么？

比如，在生成第一个回答词时，它计算出的概率分布可能是：

• “非常” → 30%
• “葡萄城” → 25%
• “上班” → 10%
• “吃饭” → 8%
• ……

模型按概率采样，选中了“非常”。然后把“非常”追加到上下文中，再算下一个词：

• “棒” → 30%
• “烂” → 25%
• “可乐” → 10%
• “手机” → 8%
• ……

最终生成“非常棒”。整个过程，模型就是在反复做一件事：给定上文，预测下文概率最高的那个词。

1.2 模型的“身体”与“思考过程”

这背后是什么在支撑？

• 模型的“身体”：一个巨大规模的高维张量（通俗理解为巨大多维数组），存储了从海量训练数据中学到的参数。
• 模型的“思考过程”：一系列大规模的线性代数计算，最常见的操作是矩阵乘法和向量点积。

1.3 Token：大模型处理信息的最小单位

值得注意的是，模型并不是按“字”来处理文本，而是按 Token（词元）。一个Token可以是完整汉字、部分词组、标点符号等。比如：

• “活字格这个工具怎么样？”
• → [14723, 41713, 69771, 34633, 25369]（Token ID序列）

不同的模型有不同的分词器，同样的文本在不同模型中的Token序列也不同。理解Token很重要，因为它直接关乎成本（按Token计费）、上下文窗口限制和检索策略设计。

1.4 模型“记忆”依赖上下文，而非长期存储

大模型没有长期记忆。它的“记忆”完全依赖于一个叫上下文窗口（Context Window）的东西——也就是单次对话中能塞进去的所有文本。

• 如果知识不在当前上下文里，模型就“看不见”它。
• 如果上下文超长，模型可能“遗忘”开头的信息（所谓的“Lost in the Middle”现象）。
• 上下文窗口虽然有越来越大的趋势（部分模型支持百万Token），但塞得越多，检索精度越差、成本越高、响应越慢。

这就是为什么不能把整本手册直接丢给模型，而需要知识库做精准检索——只把与问题最相关的片段注入上下文，让模型在有限的注意力资源内看到最重要的信息。

1.5 模型“没有手脚”，需要工具调用（Function Calling）

理解了大模型是“文本预测生成器”之后，会立刻发现一个致命问题：

模型只有“大脑”和“嘴”——它能理解问题、输出文字，但没有“手脚”去执行操作。

它无法：

• 查询数据库
• 访问文件系统
• 调用API
• 执行计算（内部做数值运算不可靠）

让它“能干事儿”的机制叫工具调用（Function Calling / Tool Use）。原理是：在对话中定义可用的工具（函数）签名，当模型判断需要调用工具时，它不自己生成最终答案，而是输出一个JSON格式的工具调用请求：

{

​ "tool": "query_database",

​ "参数": {

​ "城市": "西安",

​ "日期": "今天"

​ }

}

平台接收到请求后，真正去执行操作、拿到结果，再把结果塞回对话上下文，让模型基于真实数据生成最终回复。

1.6 MCP：连接模型与外部能力的标准接口

早期的工具调用存在严重问题：各家平台的接入规范不同。

• OpenAI有自己的Function Calling格式
• 国产大模型厂商又各自定义一套
• 每对接一个模型或工具，都需要做适配

MCP（Model Context Protocol）正是为解决这一问题而生。它是一种标准化的协议，定义了模型与外部工具、数据源之间的统一接入规范。有了MCP：

• 模型侧：只需按标准格式描述可用工具
• 平台侧：只需实现MCP服务，所有支持MCP的模型都能调用
• 工具侧：发布为MCP Tool后，可被任何兼容的Agent使用

活字格知识库的核心思路，正是基于MCP理念：把经过加工的知识查询能力（文件夹遍历、RAG检索、SQL执行）统一封装为MCP工具，让AI能按需调用。服务端命令也可以一键转化为标准MCP工具，大大降低了集成门槛。

小结一下

大模型是一个“基于概率的文本预测接龙系统”——它有幻觉、没有持久记忆、没有手脚。解决这些问题的路径高度一致：把外部知识封装成可被模型调用的标准化工具（MCP）。理解了这一点，再来看活字格的四种知识库范式，就会发现它们本质上做的是同一件事——用不同的方式把不同的知识形态封装成AI能使用的“工具”。

三、四种范式实战：从文件到数据库全打通

在深入实战之前，我们必须先搞清楚知识库的技术本质。知识库的本质是一个 ETL 系统：将原始信息（文档、数据表、网页）提取（Extract）、转换（Transform，如切片、向量化）、加载（Load）到可查询的索引中。面对海量信息资源，核心问题就两个：

• 怎么存？ 把原始知识变成结构化的、可检索的形态。
• 怎么查？ 把查询能力以工具形式交给模型，精确召回。

基于认知对齐中的分析，活字格的做法是四步走：构建知识库 → 封装查询接口 → 发布为 MCP 工具 → AI 对话中自动调用。我们所做的一切加工与封装工作，其本质目标都是将原始知识转化为一个可以被 AI 灵活调用的MCP工具。所有的技术选型与架构设计，始终围绕两个最底层的核心问题展开：“怎么存？” & “怎么查？”

下面来一一介绍下这四种范式

范式一：目录驱动型——让AI像人一样翻文件

适用于具有清晰结构化目录的文档，LLM 作为"图书管理员"：

• 典型场景：结构化帮助文档，技术手册。如企业文件服务器按层级（如“制度>人事>考勤”）存放的手册。
• 优势与局限：精度高、完全可追溯、低成本；但强依赖目录结构的规整度。活字格利用其文件读取插件与LLM结合，无需编写复杂代码即可自主实现此范式。
• 实现逻辑：模拟人类查阅逻辑。用户提问 → LLM分析意图 → 检索目录树层级 → 精准定位文档 → 召回内容生成答案。
• 具体实现方案
  • 知识怎么存？直接使用企业文件服务器中的按层级分类存储的制度，手册等文档 - 知识怎么查？使用活字格服务端命令构建目录检索和文档读取命令，并作为MCP服务工具供AI调用即可

范式二：向量查询 ——解决长文档的“大海捞针”

这是目前最主流的范式，也是很多市面产品（如Dify、RagFlow）的主战场。

• 典型场景：适用于非结构化文档、探索性问答。如企业内部长篇文档，产品手册，技术白皮书等
• 优势与局限：精能处理模糊查询、语义理解能力强；但可能召回噪音、成本较高。活字格利用其知识库伴侣插件与LLM结合，无需编写复杂代码即可自主实现此范式。
• 实现逻辑
  • 切片：将长文档语义分割为小块；
  • 向量化：将文本块转化为高维向量存入向量库；
  • 召回：用户提问向量化，进行相似度匹配检索；
  • 生成：LLM基于召回文本块生成精准答案。
• 具体实现方案

  • 知识怎么存？使用活字格内置的功能对用户上传的文件进行切片，向量化，知识库存储等操作。

  • 知识怎么查？使用活字格构建服务端命令实现用户问题向量化，向量库查询，文本重排序等操作，并作为MCP服务工具供AI调用即可

  • 当然，如果企业已经使用dify，cozi等工具构建了向量知识库，那在活字格里也支持直接对接，如图所示为使用活字格对接gc-qa-rag查询

范式三：Text-to-SQL（结构化数据查询）

适用于结构化存储的知识，LLM 生成 SQL 查询：

• 适合场景：ERP、财务、销售等业务数据查询、报表问答、数据分析等
• 优势与局限：
  • 优势：精确查询、支持聚合统计、结果可验证，兼顾了数据安全（数据不离开本地）和计算精确（让数据库做计算）
  • 劣势：需要用户问题能映射到数据库结构、SQL 生成可能出错，当数据库结构复杂时，需配合Rag技术做数据库结构的渐进式披露，另外细粒度数据权限控制实现复杂度较高(此处插播一条广告 Wyn智能问数方案已经全面实现数据库结构的渐进式披露和细粒度数据权限控制)。
  • 活字格利用LLM实现Text-to-SQL，然后使用内置执行sql命令进行数据查询。无需编写复杂代码即可自主实现此范式。
• 实现逻辑：用户问题 → LLM结合数据库Schema生成SQL → 本地安全执行 → 返回结果集 → LLM生成自然语言答复（可附带图表配置）。
• 具体实现方案

  • 知识怎么存？活字格连接多种类型的数据库，mysql，sqlserver，人大金仓等都支持，直接将业务系统的数据库连接进来即可，如果是活字格开发的应用，那就直接使用活字格的数据即可

  • 知识怎么查？使用活字格构建服务端命令实现用户问题转换为sql语句，执行sql语句等操作，并作为MCP服务工具供AI调用即可

    • 结合echart插件实现AI根据用户问题和sql查询结果生成合适图表

范式四：混合模式

• 适合场景：企业综合知识门户，用一个助手解决所有“问文档、问报表、问流程”的问题。比方用户在同一对话中既需要文档问答（如“休假政策是什么？”）又需要数据查询（如“我还有几天年假？”），单一范式无法满足。
• 优势与局限：覆盖面广，可根据问题类型自动选择最优检索范式，兼顾精度与灵活度；但系统复杂度显著上升，需要精心设计意图识别与路由机制，多智能体协作增加开发与维护成本。
• 实现逻辑：统一交互入口 → LLM分析问题类型 → 路由决策（目录驱动 / RAG / Text-to-SQL） → 分别调用对应服务 → 整合多路结果 → LLM生成统一答复。建议采用多智能体分工架构，各司其职。
• 具体实现方案

  • 知识怎么存？参考前三个范式的方案分别存储即可，使用知识库类型字段标注不同范式即可

  • 知识怎么查？使用提示词工程使用LLM实现路由决策，让AI选择前三个范式提供的查询MCP工具中合适的查询工具获取知识即可。

此方案已上线葡萄城市场，点击应用地址即可前往查看。除了实现四种范式的核心查找逻辑之外，配套的前台用户对话页面、后台知识库维护、提示词管理、日志查询等功能也已配置，欢迎点击查看。

写在最后

活字格这套方案给我最大的感受是：它没有试图用一个万能胶把什么都粘起来，而是在用分范式、分场景的策略，充分利用企业内各种各样的资料，实现知识库。这可能是目前企业落地AI成本最低、风险最小的路径之一。

如果你也在探索 AI 知识库的落地，不妨试试这个思路：先理清你的知识属于哪种形态，再选择恰当的范式去攻克它。存好知识、查准结果、封装成工具，然后交给 AI 统一调度。剩下的，就是在日志中持续优化。

如果本文对你有帮助，欢迎点赞、收藏、转发，也欢迎在评论区一起探讨你遇到的 AI 知识库落地难题。