摘要本文是 VeapAI 企业 AI 知识库实战系列的第五篇聚焦 AI 资料处理与知识内容初始化。文章从「解析只是有原料、还不是有知识」切入讲解如何把页级片段加工成可溯源的知识点随后给出 ai_knowledge_entry 与 ai_knowledge_entry_source 两张核心表的设计说明知识点本体、来源映射、快照同步唯一键与审核开放状态再走读页面操作与源码入口重点剖析快照同步的 upsert 与物理删除逻辑以及大模型输出 sourceRefs 只能引用 segment_id 的硬约束最后给出复现步骤并预告下一篇「一键向量化」的工程要点。# 从零打通企业 AI 知识库全链路VeapAI 实战五AI 资料处理与知识内容初始化 关键词知识库构建、知识点生成、知识溯源 | 首发CSDN | 同步知乎 / 掘金![本系列 8 步流程总览当前⑤ AI 资料处理与知识内容初始化]## 解析完只是有原料还不是有知识第 4 篇的产物是页级片段是原料。这一步要把片段变成知识点一条知识点讲清楚一件事同时记住自己来自哪份文件的哪一页。后者就是知识溯源也是后面问答点回原文的地基。## 表设计知识点 来源映射ai_knowledge_entry 关键字段| 字段 | 说明 || ---- | ---- || topic_id | 归属主题standard_id 归属元数据标准 || code | 序号信息配合 (topicId, standardId, code) 做快照同步的唯一键 || title / content / summary / keywords | 知识点本体 || metadata | 元数据 JSON结构由 ai_metadata_field.schema_json 定义 || approval_status / open_status | 审核状态、开放状态默认 0 || external_ref | 向量化后回写的 Milvus 关联 ID |表格里没列的一个字段也值得知道semantic_template_id语义模板主键。第 2 篇提过语义模板的取值链路topic_code → 知识主题 → 元数据标准 → 元数据字段生成知识点正文时按模板拼装模板挂在主题和知识点上。知识点长什么样不是模型自由发挥是模板定好的骨架。ai_knowledge_entry_source 是溯源映射表字段几乎都是外键| 字段 | 说明 || ---- | ---- || knowledge_entry_id | 知识点 || file_data_id | 源附件 || doc_asset_id | 文档资产 || doc_content_id | 精确到片段 || page_from / page_to | 页码区间 || anchor_text / quote_text | 短锚文本、引用摘录 || locator_json | 打开预览的定位参数 || source_order | 1 表示主来源 |uk_entry_source_ref(tenant_id, knowledge_entry_id, doc_content_id) 保证一个知识点对同一个片段只有一条来源记录。知识点可以挂多个来源跨文件综合但每对关系唯一。![核心表关系 ER 图简化版只标关键属性与核心联动]## 页面操作![资料附件管理 - AI 处理]「AI 知识库 → 资料附件管理」里选资料配好 agent、元数据标准、提示词、模型点 AI 处理。ai_file_datas.ai_status 从待处理走到已处理。处理结果落在知识内容页views/ai/knowledgeEntry/每条知识点有标题、正文、元数据 JSON来源列能看到来自哪份文件第几页点开直接定位到预览页对应片段。## 源码走读入口com.veap.ai.controller.AiFileDatasControllerbasePath /aiFileDatas、AiKnowledgeEntryController/knowledgeEntry、AiKnowledgeEntrySourceController。知识内容的写入有一条重要的路快照同步。textPOST /knowledgeEntry/syncSnapshotAiKnowledgeEntry请求体{ topicId, standardId, entries: [...] }语义以 (topicId, standardId, code) 为唯一键 upsert数据库里存在但快照缺失的 code 会物理删除。前端保存命令 kbBuild.knowledgeEntry.syncSnapshot 构造 entries 时必须把 businessId / sourceType / sourceInfo / ext 带上后端 AiKnowledgeEntryServiceImpl.syncSnapshotAiKnowledgeEntry 负责原样入库。溯源字段的推荐口径在开发文档里写死了source_typeFILE_DATAsource_infofileDataIdbusiness_idaiFileId。三件套入库审计链条才完整。## 一处值得注意的约束大模型输出的 sourceRefs 只允许引用 ai_doc_content.segment_id。这是硬约束写在表注释里。意义在于模型输出的引用永远可验证——拿 segment_id 查片段、查页码、打开预览一步都不会断。不约束的后果就是模型自己编页码你还没法证伪。## 审核与开放两道闸ai_knowledge_entry 上有两个状态字段approval_status审核状态和 open_status开放状态默认都是 0。为什么 AI 生成的内容还要人工审政策问答这类场景答错要担责。模型生成的知识点可能有断章取义。语义模板执行服务里新生成的知识点是 setOpenStatus(0)——先不开放审核通过后由人工开放。生成、审核、开放分三步走每一步都在表上有状态可查。这层设计也可以理解成流程上的插件化现在审核是人工点按钮将来要接自动化审核规则比如来源页码校验换的是审核环节的实现不改知识内容的数据结构。## 复现把第 4 篇解析完的两份 PDF 走一遍 AI 处理检查知识内容页每条知识点都有来源记录page_from 与预览页一致locator_json 能打开预览定位。再试一次快照同步确认缺失的 code 被物理删除、新增的被 upsert。下一篇是整套链路里工程含量最高的一篇一键向量化job / run / item 三级审计和 etag 幂等怎么落地。仓库含表结构与设计文档https://gitee.com/mindock/veap
摘要本文是 VeapAI 企业 AI 知识库实战系列的第五篇聚焦 AI 资料处理与知识内容初始化。文章从「解析只是有原料、还不是有知识」切入讲解如何把页级片段加工成可溯源的知识点随后给出 ai_knowledge_entry 与 ai_knowledge_entry_source 两张核心表的设计说明知识点本体、来源映射、快照同步唯一键与审核开放状态再走读页面操作与源码入口重点剖析快照同步的 upsert 与物理删除逻辑以及大模型输出 sourceRefs 只能引用 segment_id 的硬约束最后给出复现步骤并预告下一篇「一键向量化」的工程要点。# 从零打通企业 AI 知识库全链路VeapAI 实战五AI 资料处理与知识内容初始化 关键词知识库构建、知识点生成、知识溯源 | 首发CSDN | 同步知乎 / 掘金![本系列 8 步流程总览当前⑤ AI 资料处理与知识内容初始化]## 解析完只是有原料还不是有知识第 4 篇的产物是页级片段是原料。这一步要把片段变成知识点一条知识点讲清楚一件事同时记住自己来自哪份文件的哪一页。后者就是知识溯源也是后面问答点回原文的地基。## 表设计知识点 来源映射ai_knowledge_entry 关键字段| 字段 | 说明 || ---- | ---- || topic_id | 归属主题standard_id 归属元数据标准 || code | 序号信息配合 (topicId, standardId, code) 做快照同步的唯一键 || title / content / summary / keywords | 知识点本体 || metadata | 元数据 JSON结构由 ai_metadata_field.schema_json 定义 || approval_status / open_status | 审核状态、开放状态默认 0 || external_ref | 向量化后回写的 Milvus 关联 ID |表格里没列的一个字段也值得知道semantic_template_id语义模板主键。第 2 篇提过语义模板的取值链路topic_code → 知识主题 → 元数据标准 → 元数据字段生成知识点正文时按模板拼装模板挂在主题和知识点上。知识点长什么样不是模型自由发挥是模板定好的骨架。ai_knowledge_entry_source 是溯源映射表字段几乎都是外键| 字段 | 说明 || ---- | ---- || knowledge_entry_id | 知识点 || file_data_id | 源附件 || doc_asset_id | 文档资产 || doc_content_id | 精确到片段 || page_from / page_to | 页码区间 || anchor_text / quote_text | 短锚文本、引用摘录 || locator_json | 打开预览的定位参数 || source_order | 1 表示主来源 |uk_entry_source_ref(tenant_id, knowledge_entry_id, doc_content_id) 保证一个知识点对同一个片段只有一条来源记录。知识点可以挂多个来源跨文件综合但每对关系唯一。![核心表关系 ER 图简化版只标关键属性与核心联动]## 页面操作![资料附件管理 - AI 处理]「AI 知识库 → 资料附件管理」里选资料配好 agent、元数据标准、提示词、模型点 AI 处理。ai_file_datas.ai_status 从待处理走到已处理。处理结果落在知识内容页views/ai/knowledgeEntry/每条知识点有标题、正文、元数据 JSON来源列能看到来自哪份文件第几页点开直接定位到预览页对应片段。## 源码走读入口com.veap.ai.controller.AiFileDatasControllerbasePath /aiFileDatas、AiKnowledgeEntryController/knowledgeEntry、AiKnowledgeEntrySourceController。知识内容的写入有一条重要的路快照同步。textPOST /knowledgeEntry/syncSnapshotAiKnowledgeEntry请求体{ topicId, standardId, entries: [...] }语义以 (topicId, standardId, code) 为唯一键 upsert数据库里存在但快照缺失的 code 会物理删除。前端保存命令 kbBuild.knowledgeEntry.syncSnapshot 构造 entries 时必须把 businessId / sourceType / sourceInfo / ext 带上后端 AiKnowledgeEntryServiceImpl.syncSnapshotAiKnowledgeEntry 负责原样入库。溯源字段的推荐口径在开发文档里写死了source_typeFILE_DATAsource_infofileDataIdbusiness_idaiFileId。三件套入库审计链条才完整。## 一处值得注意的约束大模型输出的 sourceRefs 只允许引用 ai_doc_content.segment_id。这是硬约束写在表注释里。意义在于模型输出的引用永远可验证——拿 segment_id 查片段、查页码、打开预览一步都不会断。不约束的后果就是模型自己编页码你还没法证伪。## 审核与开放两道闸ai_knowledge_entry 上有两个状态字段approval_status审核状态和 open_status开放状态默认都是 0。为什么 AI 生成的内容还要人工审政策问答这类场景答错要担责。模型生成的知识点可能有断章取义。语义模板执行服务里新生成的知识点是 setOpenStatus(0)——先不开放审核通过后由人工开放。生成、审核、开放分三步走每一步都在表上有状态可查。这层设计也可以理解成流程上的插件化现在审核是人工点按钮将来要接自动化审核规则比如来源页码校验换的是审核环节的实现不改知识内容的数据结构。## 复现把第 4 篇解析完的两份 PDF 走一遍 AI 处理检查知识内容页每条知识点都有来源记录page_from 与预览页一致locator_json 能打开预览定位。再试一次快照同步确认缺失的 code 被物理删除、新增的被 upsert。下一篇是整套链路里工程含量最高的一篇一键向量化job / run / item 三级审计和 etag 幂等怎么落地。仓库含表结构与设计文档https://gitee.com/mindock/veap
