[]
本页面重点介绍基于语义检索的知识问答应用在活字格低代码平台中的实现方案，该方案遵循了主流的RAG（检索增强生成）范式。
推荐阅读：使用活字格的低代码开发者。
知识驱动型AI应用场景式企业级AI智能体的常见抓手。该类型的场景能充分利用大语言模型的自然语言处理能力，相对独立的提供全新的用户体验。落地该场景，可以在有限的预算内大幅提升企业用户对AI技术的信心。
知识驱动型场景对应的是知识驱动型AI智能体，其核心是知识库（注意与传统的基于全文检索的知识库做区分）。知识库类似于数据库管理软件，只不过这里的数据换成了相对静态的知识，查询也从等于、不等于、大于、小于、包含等明确的查询条件，变成了基于语义近似性的模糊查询。如在数据库管理软件中，我们无法通过“喵喵”查询到包含有“猫猫”的记录；但在知识库中，这两词因为存在一定的语义相似性，就可以被查询到了。
这种查询方式的本质是计算这些文本间的“距离”，其核心技术在2011年由Hervé Jégou等人提出，从文本（也可以是图片、视频、语音等多模态文件，但目前效果最好、最常用的是文字）中提取特征，然后将这些特征组成一个多维向量（文本的每个特征可以看做是这个矢量中某一个维度的值），通过计算两个向量的距离，通过特征距离简单推断出两段文本在语义上的相似度，从而实现“找到与一段文本语义近似的文本”的目的。整个过程如图1所示。
（图1 Emdedding与知识库的语义检索能力）
凭借着语义相似性分析能力，知识库大幅扩充了“检索”的范围，从精确匹配变成了更智能的匹配方式，从而为用户带来了更多新体验，催生出了更多知识驱动型AI场景。
典型的知识驱动型场景有：
文本合规：输入大段文本，检查其与相关知识内容的匹配程度。如合同合规、处方审核等。
模糊查找：先为每个被查找的对象配上文字描述，然后像知识问答一样找出与用户输入文字最接近的文字描述，再反查到与之对应的对象。如智能导购、物料匹配等。
通常不被纳入知识驱动型的场景有：
图片识别：如基于计算机视觉的生产缺陷检查，此类场景推荐采用判别式AI（特定领域的小模型）实现
智能问数：如通过输入文字从数据库中查询高实时性的数据，此类场景推荐采用“插槽填充”、Text2SQL等范式实现，必要时可引入一个或多个知识驱动型AI智能体承担同近义词分析功能（类似知识问答）
实用技巧：规则越模糊，知识驱动型AI越容易获益；规则清晰到满足IFTTT（如果这样就那样），直接将其固化为软件通常是更高效的方案。
知识库通常采用检索增强生成（RAG）范式来实现，如图2所示，技术相对成熟。
（图2 RAG的基本流程）
在RAG中，我们可以将知识库分为两大板块，分别为知识库的构建和知识库的使用（图2中粉色现况中的区域），先构建再使用。
构建阶段的主要工作是将原始知识转换为向量，分片存储到向量库中。相当于关系型数据库开发中的INSERT。
原始知识切片：按照知识源文件（包含有特定领域知识的一个或多个文件、网页或数据库中的记录）中内容本身的结构，将其拆解为多条包含有id、文本（仅包含文本内容）、原始内容（包含有文本、图片、音视频等格式的原始记录）和排序权重（质量更高的知识，初始权重通常更高一些）的数据记录并存入关系型数据库，每一个记录通常是存储在数据库中的一行。切片工作可以通过预先设定的规则完成，或引入AI大模型来完成。
知识扩充与整理（可选）：基于知识切片进行二次加工。典型的做法是采用AI大模型针对知识切片创建问答对。如向AI提供整章内容，要求其生成针对某一节、某一个切片的问答对，将这些问答一样，纳入知识切片，从而将过于碎片化的知识进行一定程度的融合。这种做法被称为T2Q（Text2QA），在知识完备性不足、碎片化严重的参数手册等细分场景下效果最佳，典型案例如葡萄城AI搜索（开源，python实现）；模糊查找场景下受限于文本描述本身不够全面，通常也推荐引入T2Q，具体做法参考：AI导购（葡萄城市场，活字格实现）。
向量生成：利用向量生成领域的专用大模型（如通义千问3-Embedding-开源向量化模型），将知识切片中的文本转换为向量（形式为float数组），即文本向量化embedding。
存入向量库：将向量和对应的负载（payload，考虑到性能，通常仅存储数据记录的id，如文本切片的ID或QA的ID）一起存入专门的向量数据库中。
使用阶段可以分为两个阶段，即检索阶段和生成阶段。检索阶段简单的理解为在向量库中查询的过程。相当于关系型数据库开发中的SELECT；生成阶段则是将检索阶段的结果与用户查询一起提交给大模型来生成内容。
用户查询转换（可选）：为了提升匹配准确性，通常根据知识库中的内容特点与颗粒度，对用户输入信息（或语音转的文字）进行转换处理，确保其语义存在可比性，最终生成用户查询文本。如AI简历初筛场景中，我们需要先利用AI大模型将简历提炼为“既往工作的岗位特征”，再将其与向量库中的岗位要求进行比对，而不是用“简历”查询“岗位要求”。具体做法参考：AI筛简历（葡萄城市场，活字格实现）
用户查询向量化：类似于构建版块，我们需要将用户查询文本采用同样的方法转换为向量。查询用的向量需要跟构建阶段采用相同的算法，且保持相同的维度数量。
向量查询：使用上一步转换的向量在向量数据库中查询，获取符合要求（向量距离不超过阈值、总数量不超过阈值）的若干个id。
文本召回：使用这些id，在文本切片的数据库中查询对应的文本（切片和QA对）、原始内容和权重。
重新排序：向量查询环节是基于特征的排序，需将其转换为基于语义的排序，才能提供给AI大模型生成使用，所以这个环节被称为重排序。重排序的主流做法是利用重排序领域的专用大模型（如通义千问3-Reranker开源文本近似模型），基于用户输入的原始文字，对文本召回的文本或原始内容进行重新排序。在排序过程中，也可以加入更多预设规则，如针对数据库中存储的权重对专用大模型返回的结果进行二次调整。对于部分特定场景，也可以自己编写基于规则来完成重新排序。需要注意的是，如果用户查询需要横跨多个知识领域，重新排序时需要考虑将源于多个领域的知识切片合并在一起进行排序。
生成最终答案：将排序后的原始内容拼接到提示词模板中，与用户输入的文字一起交给大模型，接收AI的返回结果。
展示结果：在结果展示阶段，知识驱动场景通常需要在展示AI返回结果的同时，展示相关的知识片段，即原始内容，提升可解释性，满足用户需求。
向量数据库不同于传统数据库，需要提供包括向量距离计算、排序、检索等功能。目前主流的向量数据库有两个主要“门派”：
独立运行的Qdrant，类似于MySQL，在独立的进程中运行，可以部署到应用服务器以外，更方便扩展。
嵌入式运行的Faiss，类似于Guava Cache，运行在当前进程的内存中，内存占用量为向量数维度数据类型，如3500个切片、512维度的IndexFlatL2默认配置，内存增量大约为100MB-200MB。
前者通常适用于对扩展性和性能上限要求高的互联网场景；后者因为部署更简单，更适用于企业场景，尤其是模糊查找等轻量级RAG场景。
此外，如果预算充裕、合规性要求相对较弱，采购云平台提供的SaaS版向量数据服务（如阿里云的“向量检索服务 DashVector”）也是一种常见的做法。
2025年夏，多个厂家已经推出了支持多模态的向量生成专用大模型（如阿里云百炼的“通用多模态向量”），可以将文本与图片一同生成向量。但从实际测试效果上看，针对文本生成的向量与针对图片生成的向量间存在较大差异，如果一个矢量库中同时有两种来源的向量，两者的向量距离并不能做横向对比，这对于整个知识库的表现将带来更大的不确定性。
基于当前的技术水平，我们不推荐在同一个知识库中同时包含图片向量和文本向量。而是建议采用图片理解领域专用大模型（如阿里云百炼的“通义千问VL-Plus”）先将图片转为文字后，再将其融入某个知识切片或作为单独的知识切片处理。
该类型场景的实际落地效果主要受知识质量的影响，排序等策略也会存在一定的优化空间，但通常不会成为主要因素。
高质量的知识通常具备以下特征：
结构化强：知识有明确的“章节”特征，相关性强的内容聚集在一起，而不是分散在多处的碎片化。
文字化程度高：知识以文字为主，如果涉及到图片或视频，均配套了详细的说明文字对其进行介绍，或图片、视频易于被AI理解，能通过AI将其转成文字描述（如Qwen2.5-VL开源视觉模型）。
无歧义、无冲突：文字表达精确，上下文完整。在同一个领域（知识库）内，经过人工检查，没有明显的歧义或冲突内容。
为了快速提升知识的质量，常见的做法如下：
领域细分：根据业务实际情况，将一个知识库拆分为若干个知识库，从而降低发生冲突的风险。尽量避免多领域的知识混在在同一个知识库中，是提升知识质量最简单有效的方案。不过这通常意味着用户需要在使用问答前选择一个或多个领域，体验上打一些折扣，互联网服务通常不会做出这种妥协，但企业软件中这是常态，因为企业中的知识和场景天生具备较强的领域性。
知识治理：投入人力对知识进行梳理和校对，在原始知识切片的基础上，对切片中的文本和原始内容进行修改，避免歧义和冲突。该项工作通常作为数据治理项目的一个环节，由专门的公司或团队完成，属于技术含量较低的人力密集型工作。
人工扩充：在知识治理过程中，对于缺失的知识内容，可人工进行扩充。需要注意的是，扩充的知识仍然需要满足对知识的质量要求，通常会安排在知识治理工作之前完成。
实时反馈：主要应用在知识问答场景。与人工扩充类似，在使用的过程中，允许用户对AI返回的结果进行打分，对于哪些用户认可的回答，可将其以“问答对”的形式纳入知识库中，实现常用常新的效果。这种模式下，通常需要配套定期的人工检查机制，确保这些新纳入的问答对是正确、有效的。互联网服务中不推荐这么做，因为我们无法约束和管理用户的行为，可能会出现恶意注入低质量知识的风险；企业软件中，因为记录存在可追溯性，在管理制度的保障下，通常会达到预期的效果。
为了充分展现RAG范式下的知识驱动型AI场景落地，我们使用活字格低代码开发平台构建了一个相对完成的知识库Demo和配套的智能应用：知识问答，架构如图3所示。全部模块，包含知识库在内均采用活字格实现，无需编码开发。
（图3 活字格知识库Demo架构简图）
本方案的场景为面向客户的知识问答，主题为“低代码转型”，具有以下设计特征：
向量数据库采用嵌入式方案，Faiss。
文本切片调用兼容主流大模型，如百炼qwen-turbo-latest。
提供AI自动扩增，调用主流大模型，基于文本切片和全文生成问答对。
向量模型采用百炼通用文本向量-v3（支持单纯文本向量，暂不支持多模态向量）。
文本重排采用百炼深度文本重排序，为QA命中与文本切片命中设置不同的排序权重。
大语言模型兼容主流方案，如百炼qwen-max-latest。
提供支持异步处理的知识库维护界面和问答记录查询界面。
本方案中不包含，但通常需要提供的设计有：
将PDF/Word等格式的问题抽取为富文本（包含但不限于md格式或html格式）和文本（由图片理解服务，如百炼“通义千问VL-Max”生成图片的描述信息）。
精细化权限控制，通常会精细化到知识领域一级，提供用户访问和API访问两种控制机制，前者基于角色设计，后者则通过访问秘钥来控制（如存放于HTTP HEAD中Authentication标头的字符串）。
展示原始内容，因为版权等原因，本应用没有将知识原文展示给最终用户。多数企业场景中，智能体需要在对话框中提供“查看详情”按钮，展示文本切片以及导航到原始资源展示或下载页面的链接，以提升用户的信赖感。
在线体验：跨领域知识问答
接下来，我们将按照模块，逐个介绍关键技术实现在活字格工程中所在的位置。
（图4 活字格中实现的知识库示例）
数据库中存储了应用运行所需的全部数据，包含持久化后的向量集合。
核心数据：
知识领域：本应用中唯一领域为“低代码咨询”。
原始资源：对应了一份知识文档中的全部文本，通常是一个pdf文件、网页或书籍的一个章节。原始资源是知识领域的子表。
向量文本：从原始资源拆解出来的文本切片和基于文本切片生成的问答对。向量文本是原始资源的子表。
向量索引：Faiss向量索引的持久化数据，确保服务器停止不会造成向量数据丢失，如图5所示。向量索引是知识领域的子表。
知识库管理：
知识库维护记录：记录对知识库中内容的增删操作，审计用。
资源任务处理表：对原始资源进行创建、删除和重置等操作时，系统会将对应的任务插入这张表，在执行这些任务时，会更新该表的记录，确保异步任务的有序执行。
应用层：
问答历史：记录知识问答的记录，审计用。
提示词版本管理相关：
提示词模板：不同场景下使用的提示词模板，本应用中包含AI切片、T2Q、知识问答（应用层）三个场景。
提示词示例：提示词模板的历史版本，方便对比与快速回滚。
（图5 持久化到数据库中的FAISS向量索引）
从知识库中查询：服务端命令【queryCrossDomain】，完整的知识库查询接口，接收需要查询的知识库ID（每个领域的知识存放在单独的知识库中，如需跨领域查询，可用逗号分隔）和用户查询文本，返回排序后的知识内容，含类型（文本切片/优选问答）、id、原始内容、访问该原始内容的URL（配套知识展示页面使用）。该服务端命令将遍历传入的知识领域，分别调用【query】服务端命令，然后综合在一起进行重排序并返回。
从知识库中查询（单一知识领域）：服务端命令【query】，查询功能集中在本服务端命令，包含RAG范式下 “用户查询向量化”、“向量查询”、“文本召回”、“重新排序” 4个环节，以及作为基础的向量索引的加载、权限控制等功能，调用了queryVector、recall和rerank三个私有化服务端命令。具体工作流程如图6所示。
（图6 从知识库中查询的流程）
用户查询向量化+向量查询：私有化服务端命令【queryVector】，从特定知识领域的两个向量索引（文本切片索引和问答对索引，两者分开查询是为了避免干扰，在原始文本质量较高时，推荐采用这个设计）中分别查询与用户输入的文本query语义特征近似的ID列表，如图7所示。
文本召回：私有化服务端命令【recall】，基于语义特征距离查询出的文本切片和问答对ID列表，从文本数据库中查询到对应的内容，并组织成“文本切片-问答对”的树形数据结构，为重排序做准备。
重排序：私有化服务端命令【rerank】，基于文本召回的结果和用户原始输入query，首先调用大模型基于语义相关性做重排序，然后再结合问答对与原始文本切片的权重进行二次计算和重排序，输出知识库的查询结果。
（图7 知识库查询的活字格实现）
知识库维护相关的服务端命令集中在【知识库管理】文件夹内。其中关键的服务端命令为【手动执行任务】，该命令调用了【processResource】私有化服务端命令，其中实现了**“原始知识切片”、“知识扩充与整理”、“向量生成”和“存入向量库”**4个环节，如图8所示。因为该操作涉及到多轮次AI操作，耗时较长，所以将其从原始资源的增删中独立出来，支持异步执行。
（图8 从原始资源到向量库）
原始知识切片+知识扩充与整理：私有化服务端命令【知识预处理】。先进行大文本切割（本应用中将大于9500字的原始资源文本切割为尺寸为9500、重叠度为200字的片段），然后将片段交给大语言模型执行基于语义的切分，尽量确保同一个切片内的内容较为完整，最后再调用大语言模型分别就各个文本切片进行问答对生成，其中问题来源于切片，而答案则来源于全文（不超过9500字的片段），完成预处理工作。
向量生成+存入向量库：逻辑位于【processResource】中，分别将预处理完成的文本切片和问答对生成向量（调用【生成向量（阿里云百炼）】私有化服务端命令），最后批量添加到向量库（调用【添加向量（FAISS）】私有化服务端命令）。
应用层采用典型的前后端分离架构，后端服务为服务端命令【知识问答】，接受参数为知识领域、当前轮次问题和会话内的问答历史记录。本应用考虑到匿名访问的特点，采用了“短会话模式”，即用户每次刷新页面视同为一个新的会话。
【知识问答】实现了生成最终答案环节，如图9所示。
（图9 应用层先查询知识再调用大模型生成内容）
面向最终客户的页面仅有【ai】一个页面，其中使用到了两个组件：
AI用-对话框组件：封装了“AI对话单元格”，提供对接服务端命令实现workflow的能力
AI用-链接列表组件：展现【知识问答】服务端命令返回的“相关问题”，增强用户体验
AI运维后台均位于【后台功能】文件夹下，主要页面如下：
召回测试：【test】页面，可直接输入文本，调用【queryCrossDomain】，查看知识库的召回结果。通常用于上线前的测试或上线后的问题诊断，用来排查是知识库端的问题还是应用层的问题。
异步任务管理：【task】页面，列出所有维护任务的执行状态，对于可执行的，提供点击按钮执行的功能。任务在服务器端执行，关闭页面不会影响正在执行中的任务。
知识问答记录：【查询问答记录】页面，从应用层的角度，列出用户的问题和AI的回复。
知识库维护日志：【查看维护日志】页面，查询对知识库的所有维护操作，审计用。
知识领域的管理和配置：【知识领域】子文件夹
原始资源的管理：【原始资源】子文件夹
如果您已经部署了第三方的知识库服务，如gc-qa-rag，也可以通过【发送HTTP请求】命令完成对接，相当于将RAG范式中“重新排序”及以前的环节放在该知识库中实现，仅在活字格中完成 “生成最终答案”和“展示结果” 两个环节。
RAG范式是知识驱动型AI逻辑场景的典型实现方案，市面上存在多种方案可供选择。下表为多方案的对比，建议您根据实际情况选择合适的技术方案。
方案 | 编码开发 | 低代码开发 | 零代码配置 |
|---|---|---|---|
开发技术 | Python/Java | 活字格 | coze、MaxKB等（AI workflow） + Python/Java等（业务逻辑） |
性能上限 | 高 | 中 | 不定（依赖平台的成熟度） |
知识库部署复杂度 | 高（需自行部署） | 低（随应用部署） | 低（随应用部署） |
安全合规风险 | 高 | 低 | 不定（依赖平台的成熟度） |
技术门槛 | 高（需要编码） | 中（不涉及编码） | 高（需要编码） |
技术管理复杂度 | 低 | 低 | 高（同时采用多技术栈） |
开发效率 | 低 | 高 | 中-高（取决于编码开发占比） |
定制化能力 | 高 | 中 | 中-低（取决于编码开发占比） |
典型场景 | 将AI作为核心业务场景的互联网公司 | 低成本投入下完成AI落地的企业客户及其信息化服务商 | 临时性的业务可行性验证（基于虚拟数据） |
值得一提的是，上述对比结论与传统意义上的企业软件开发高度近似。我们预测，编码、低代码和零代码三足鼎立的场景，在AI智能体和知识型AI智能体中依然会延续。
