知识驱动型AI应用场景

在企业级AI智能体应用中，知识驱动型场景是一种常见的实施路径。该模式能充分利用大语言模型（LLM）的自然语言处理能力，结合特定领域的知识库，以相对独立的方式构建交互功能，从而为用户提供全新的服务体验。相较于需要深度集成企业核心业务系统或进行大规模流程再造的AI应用，知识驱动型智能体的部署流程通常更为简化，周期相对较短。落地该场景，能够在有限的资源投入下，有效提升企业用户对AI技术实际应用效果的认知与接受度。

核心原理

与知识驱动型场景相对应的是知识驱动型AI智能体。其中，知识库是知识驱动型AI智能体的核心组成部分。需要明确区分，这里的知识库与传统基于全文检索的知识库有着本质区别。我们可以将其类比为数据库管理软件，但存储和查询的对象发生了根本变化：存储的是相对静态的知识，而非像库存水平、银行账户余额、网站用户活动等动态数据。其次，查询方式也从基于精确匹配（如等于、不等于、大于、小于、包含等）转变为基于语义近似性的模糊查询。

举个例子，在传统数据库中，你无法通过关键词"喵喵"检索到包含"猫猫"的记录，因为它们在字面上不匹配。但在知识库中，这种查询成为可能。由于"喵喵"和"猫猫"在语义上存在关联，因此知识库能够识别到这种相似性并返回相关结果。

这种基于语义的查询之所以能够实现，其核心技术在于将文本（未来可能扩展到图片、视频、语音等多模态数据，目前以文本效果最佳且应用最广）转化为高维向量（或称矢量）。通过计算这些向量之间的距离或相似度，知识库就能找到语义上最接近的匹配项。整个转换与匹配的过程如图1所示。 （图1 Emdedding与知识库的语义检索能力 ）

正是这种基于语义相似性的分析能力，让知识库的检索能力发生了质的飞跃。它不再局限于字面上的精确匹配，而是能够理解词语背后的含义，从而找到语义上相关的信息。这种更智能的匹配方式，极大地扩展了信息获取的可能性，为用户带来了全新的交互体验，也成为了催生各种知识驱动型AI新场景的关键技术基础。

典型的知识驱动型场景包括：

• 知识问答：用户通过输入文字（或语音转文字）提出问题，系统查询知识库以提供相关的知识性答案。
• 文本合规性检查：将大段文本输入系统，与预设的知识规则或标准进行对比，评估其合规程度。

通常不被归类为知识驱动型AI的场景有：

• 图片识别：典型的图片识别任务，特别是像生产缺陷检查这类，更侧重于从图像中提取特征并进行模式匹配或分类。这属于计算机视觉（CV）的范畴，常用深度学习模型（如CNN）实现，这些模型可以看作是特定领域的判别式模型，其核心在于模式识别而非知识推理。
• 智能问数：智能问数（Query by Example, Q&A over databases）的核心挑战是将自然语言问题准确地转换为数据库查询语句（SQL）。对于需要实时、精确数据的情况，Text2SQL等直接转换方法效率最高。知识驱动型AI可以辅助处理自然语言理解的部分，比如识别实体、理解同义词等，但它通常不是整个"智能问数"流程的核心，特别是当涉及到精确、动态的数据库查询时。

| **实用技巧：**当任务规则模糊，需要理解语义时，知识驱动型AI效果更佳；反之，若规则清晰到可用IFTTT（如果这样就那样）来进行描述，则直接编写程序通常更高效。 | | ------------------------------------------------------------ |

检索增强生成（RAG）模式：知识库的实践范式

知识库的构建通常采用检索增强生成（Retrieval-Augmented Generation, RAG）这一相对成熟的技术范式，其基本流程如图2所示。RAG主要包含两大核心阶段：知识库的构建和知识库的使用，遵循先构建后使用的顺序。 （图2 RAG的基本流程，图片源于网络）

知识库构建：奠定基础

核心功能与技术原理：

1. 原始知识切片：

   将原始文件（如包含有特定领域知识的一个或多个文档、网页、数据库记录等）按照其内在结构拆解。每条切片作为数据库中的一行记录，包含：唯一ID、纯文本内容、原始记录（可含文本、图片、音视频等多模态信息）以及初始排序权重（高质量知识赋予更高权重），然后存入关系型数据库。

2. 知识扩充与整理（可选步骤）：

   基于知识切片进行二次加工，可以显著增强知识的完备性。一种典型且高效的做法是采用AI大模型针对知识切片创建问答对（T2Q-Text to Question）。具体而言，你可以提供章节内容，让模型针对特定节或切片生成问题及答案。这些问答对作为新的知识单元纳入切片，有助于填补信息空白，使知识更加系统化。这种做法在知识结构相对完整但内容不够丰富的场景尤为有效，例如技术文档或教育材料。通过T2Q技术，原本过于碎片化的知识得以融合，提升了知识的整体性和实用性，特别是在知识完备性不足、碎片化严重的参数手册等细分场景下，效果更为显著。具体做法参考：葡萄城AI搜索（开源，python实现）

3. 向量生成：

   利用向量生成领域的专用大模型（如阿里云百炼的"通用文本向量-v4"），将知识切片中的文本转换为高维向量（通常为浮点数数组），实现文本的向量化表示。

4. 存入向量库

   将生成的向量库及其对应的切片ID存入专门的向量数据库。这为后续基于语义的快速检索奠定了基础。

知识库使用：实现智能检索与生成

核心功能及技术原理：

1. 用户查询向量化：将用户输入的查询文本（或语音转文字结果）使用与知识架构阶段相同的向量生成模型，转换为查询向量。
2. 向量相似度查询：在向量数据库中，利用查询向量检索语义上最相似的向量。根据设定的相似度阈值和结果数量限制，筛选出若干最相关的知识切片ID。
3. 文本召回：根据上一步获取的ID，从存储原始知识切片的关系型数据库中，检索出对应的文本内容、原始记录信息及其初始权重。
4. 重新排序：这是提升检索精度的关键步骤。通常采用专用的重排序模型（如阿里百炼的"深度文本重排序"），结合用户原始查询，对找回的文本片段进行重新排序，以确定最相关的结果。排序过程可结合初始权重等预设规则进行微调，部分场景也可采用自定义规则进行排序。
5. 生成最终答案：排序靠前的知识内容拼接到预设的提示词模板中，连同用户原始查询一起，输入到大语言模型（LLM）中，进而生成最终的、信息丰富的回答。
6. 展示结果：在向用户展示LLM生成的答案时，通常还会附带相关的原始知识片段。这种做法不仅增强了答案的可信度，也提供了"为什么这么回答"的依据，满足了用户对结果可解释性的需求。

实践应用中需关注的要点

向量数据库的选择

向量数据库区别于传统数据库，其核心功能在于支持向量距离计算、排序与高效检索。按照部署方式来分，当前主流的选择主要有：

1) 独立运行型 ：以Qdrant为代表，其运行机制类似MySQL，在独立进程中执行，可部署于应用服务器之外。这种模式便于水平扩展，特别适合对性能要求较高的互联网场景。

2）嵌入式运行型 ：以Faiss为例，其运行机制类似Guava Cache，直接集成在应用程序进程的内存中。部署更为简单，通常更适用于对部署复杂度敏感、规模相对可控的企业内部场景。

当然，若预算充足且对数据合规性要求不高，可直接采用云服务商提供的SaaS版向量数据库服务（如阿里云的"向量检索服务DashVector"）也是一种便捷且常见的方案。

多模态向量融合 vs 仅采用文本向量

截止2025年，市面上已出现多种支持多模态的专用向量生成大模型，例如阿里云百炼的"通用多模态向量"，它们能够将文本与图片统一编码为向量。然而，实际测试表明，文本向量与图片向量在内在语义表征上存在显著差异。如果简单地将这两种来源的向量混合存储于同一向量库中，其向量距离将难以进行有效的跨模态比较，这会显著降低知识库检索结果的可预测性，增加不确定性。

因此，若要采用直接混合存储多模态向量模式，不仅需要对多模态模型进行极为精细的设计与训练，以确保其能生成具有良好跨模块可比性的向量，同时还需要对检索和排序算法进行专门定制。这种做法无疑会大幅提升系统的复杂度。

另一种更为成熟稳健的策略是：将所有非文本模态，如图像、音频、视频等，首先通过专用模型（例如视觉模型或特定多模态模型，如阿里云百炼的"通义千问VL-Plus"）转换为文本描述。随后，将这些生成的文本与原始文本数据统一编码为向量，并存储于向量数据库中执行检索。

此模式的核心优势在于其技术路径的成熟性与流程的清晰度。由于所有数据最终都投射到统一的文本向量空间，这使得检索逻辑得以简化，且检索结果的可预测性较高。同时，这种方法能够有效复用现有的文本向量检索框架及相关经验，降低了技术门槛。

当然，这种"转文检索"模式的一个潜在代价是可能存在信息损失。例如，图像中的细节、色彩、构图等视觉元素，在转化为文本描述后，其丰富性和精准性难免会打折扣。尽管存在一定的局限性，但对绝大多数基于RAG的应用场景，如知识问答、内容推荐等，特别是当交互主要围绕文本进行时，这种统一处理文本向量的方式通常被视为一种优选实践，能够提供稳定且可靠的效果。

知识质量：落地效果的关键

知识驱动型AI智能体的实际落地效果，其核心制约因素通常是知识质量。虽然排序策略等环节也存在优化空间，但往往并非决定性因素。

高质量的知识通常具备以下关键特征：

• 结构化强：知识应具备清晰的层级结构，相关内容需紧密关联，避免散乱分布。

• 文字化程度高：内容以文字为主，若涉及到图片或视频，均配有详尽的说明文字，确保信息完整传递。

• 无歧义、无冲突：文字表达精准，上下文完整。经人工核查，同一知识库内不存在明显的歧义或相互矛盾的内容。

  为了快速提升知识质量，实践中常采用以下几种策略：

1. 领域细分：根据业务实际，将大型知识库拆分为多个领域特定的子库。这能有效降低知识冲突的风险。避免多领域知识混杂是提升质量最直接有效的方法。不过，此做法通常要求用户在使用前选择特定领域，可能影响易用性。因此，这种做法在互联网服务中因可能影响用户体验而较少采用，反而在企业软件里更为常见，因为企业知识本身往往就具有强烈的领域特性。。
2. 知识治理：这项工作涉及投入人力对知识进行系统性的梳理与校对。基于原始知识切片，专业团队会修正文本及关联内容，以消除歧义与冲突。作为数据治理项目的重要组成部分，这项工作主要依赖人工操作和专业判断，虽然不涉及复杂技术，但却是保障知识准确性和一致性的基础性工作。
3. 人工扩充：在知识治理的过程中，针对内容缺失的部分可进行人工补充。但要注意，扩充内容同样需要满足高质量标准，此项工作通常在知识治理前完成，以确保基础知识的完整性。
4. 实时反馈：主要应用于知识问答场景。允许用户对AI生成的答案进行评价。对于用户认可的优质回答，可将其转化为"问答对"形式纳入知识库，实现知识库的动态更新与"常用常新"。值得注意的是，该模式需匹配定期人工审核机制，用以确保新增内容的准确有效。此外，该策略的适用性因场景而异。在互联网服务中，由于难以约束用户行为，存在恶意注入低质量知识的风险，因此通常不推荐采用。而在企业软件环境中，得益于操作记录的可追溯性以及内部管理制度的保障，该机制往往能更安全、有效地达成预期目标。

基于低代码技术构建知识驱动型AI智能体

为了直观展示RAG范式下知识驱动型AI智能体的落地，我们基于活字格低代码开发平台，构建了一个完整的知识库Demo及其配套的智能应用（架构如图3所示）。所有模块，包括知识库本身，均通过活字格实现，无需编码即可完成开发 。 （图3 基于活字格构建的知识库Demo架构简图）

方案设计：面向企业规章制度的RAG知识库

本方案专为处理企业中最常见的规章制度类场景而设计，其核心设计特征如下：

• 向量存储 ：采用嵌入式Faiss向量数据库，便于集成与管理。
• 文本分片 ：分片功能兼容主流大模型，例如百炼qwen-turbo-latest。
• 向量模型 ：使用百炼通用文本向量-v4，专注于纯纯文本向量处理，（当前版本暂不支持多模态向量）。
• 结果重排 ：集成百炼深度文本重排序技术，提升检索结果的相关性。
• 大模型接口 ： 兼容主流大语言模型方案，如百炼qwen-max-latest。
• 权限管理：用户权限基于活字格内置的RBAC（基于角色的访问控制）方案实现。
• 知识库扩充策略：
• 不包含AI自动扩充：本方案不基于文本切片自动生成问答对，此设计适用于知识质量本身较高的场景。
• 支持反馈驱动的自动扩充：用户标记"有用"后，系统会自动将当前优质问答对纳入知识库，适用于企业级应用场景。
• 实时更新：对知识库的维护操作，包括自动扩充，均可实时生效。

此外，本方案虽未直接包含，但在实际部署中通常需要考虑的关键设计要素有：

• 文档预处理：需要将PDF/Word等格式文档抽取为富文本（如Markdown、HTML）和纯文本。其中，图片内容可通过视觉理解服务（如百炼"通义千问VL-Max"）生成描述性文本。
• 富文本展示： 支持将富文本（含图片、文字混排的Markdown、HTML等）作为"原始内容"进行可视化展示。
• 重排序优化：可根据预设的业务权重对"重排序"逻辑进行进一步调优，以获得更精准的结果。

技术实现

本节将按模块划分，详细介绍关键技术的实现方式及其在活字格工程中的具体位置。

（图4 活字格中实现的知识库示例）

知识库

• **从知识库中查询：**服务端命令【query_with_rerank】，完整的知识库查询接口，接收需要查询的知识库ID（每个领域的知识存放在单独的知识库中，如需跨领域查询，可用逗号分隔）和用户查询文本，返回排序后的知识内容，含类型（文本切片/优选问答）、ID、原始内容、访问该原始内容的URL（配套知识展示页面使用）。
• 从知识库中查询（单一知识库、未重排） ：私有服务端命令【query】，查询功能集中在本服务端命令，包含RAG范式下 "用户查询向量化"、"向量查询"、"文本召回" 三个环节，以及作为基础的向量索引的加载、权限控制等功能。RAG范式的 "重新排序" 环节放在【query_with_rerank】中，以实现跨领域查询时的重排效果。

知识库维护侧

• 前端管理界面：页面下【知识库维护】文件夹中各页面，包含了知识库的创建、重命名与标记删除、知识库权限设置、文本切片的增删改查与重建、优选问答的删除与重置等功能。
• 后端业务逻辑：逻辑下【知识库】文件夹中除【query】外的各服务端命令，承载了前端管理界面的全部业务逻辑。

智能应用侧：知识问答

• 后端 ：逻辑下【知识问答】服务端命令。在该服务端命令中，先通过调用【query_with_rerank】从知识库中查询到排序后的相关知识，再通过"AI助手命令"完成RAG范式中的 "生成最终答案" 环节，对数组对象的形式返回。
• 前端 ：页面下【知识问答】页面、【show-evidence】页面和组件下全部组件，完成RAG范式中的 "展示结果" 环节，包括对话中展示摘要信息，并提供对应的"查看相关内容"按钮，展现知识库的原始内容。
• 优选问答：页面下【AI用-详情页按钮】组件中提供"有用"按钮，页面下【知识问答】页面中AI用-对话框组件的"点击有用"事件处理器中，通过调用【添加问答记录到知识库】服务端命令完成自动扩增。

智能应用侧：销售合同审核

• 后端 ：逻辑下【销售合同合规检查】服务端命令。在该服务端命令中，先通过调用【query_with_rerank】从知识库中查询到排序后的相关知识，再通过"AI助手命令"完成RAG范式中的 "生成最终答案" 环节，以JSON文本的形式返回。
• 前端 ：页面下【销售合同合规检查】页面、【show-text】页面和组件下全部组件，完成RAG范式中的 "展示结果" 环节，包括在右侧检查结果图文列表中展示摘要信息，并提供对应的"查看详情"按钮，展现知识库的原始内容。

效果展示

• 在线体验
• 工程文件

总结：方案对比

RAG范式是知识驱动型AI场景的典型实现路径。市面上存在多种技术方案可供选择。下表为多方案的对比，供读者根据实际需求进行选型参考。

| 方案 | 基于独立部署向量数据库开发 | 基于内嵌式的向量索引开发 | 调用第三方知识库服务（如dify等） | | -------------- | -------------------------------- | ------------------------------------------------ | ---------------------------------------------- | | 活字格是否支持 | √（通过发送HTTP请求插件） | √（通过Faiss插件） | √（通过发送HTTP请求插件） | | 性能上限 | 高 | 中 | 不定（依赖网络环境与服务方的负载） | | 部署复杂度 | 高（需额外部署矢量数据库） | 低 | 低 | | 安全合规风险 | 低 | 低 | 高（企业知识存放于第三方云服务） | | 精细化权限控制 | √ | √ | 不支持 | | 维护日志与审计 | √ | √ | 不支持 | | 定制化能力 | 高 | 高 | 低（缺乏精细化的业务逻辑、策略与界面控制能力） | | 典型场景 | 将AI作为核心业务场景的互联网公司 | 低成本投入下完成AI落地的企业客户及其信息化服务商 | 临时性的业务可行性验证（基于虚拟数据） |

不论选择哪种技术方案，开发者均可采用编码或低代码方式来完成。值得注意的是，当技术方案相同时，低代码与编码开发的最终成效几乎一致------真正的瓶颈在于知识质量而非开发模式。然而，低代码开发在效率上远超编码，并且无需Python等编程基础，这使得传统开发团队能够更便捷、快速地探索AI智能体开发。

扩展链接

基于QA-RAG的智能检索系统：

https://github.com/GrapeCity-AI/gc-qa-rag

https://gitee.com/grape-city-ai/gc-qa-rag