AI知识库设计：文档、网页、代码、表格、多模态资料的统一治理
摘要
AI 知识库不是把资料切块后写入向量库，而是把组织知识变成可检索、可授权、可引用、可更新、可评测的证据系统。本文以文档、网页、代码、表格和多模态资料为对象，讨论资料模型、解析、分块、元数据、权限过滤、混合索引、增量同步、引用生成和质量评测之间的关系。文章强调向量相似度只是召回手段之一，知识库的可靠性最终取决于资料结构是否保真、权限是否前置、答案是否能回到来源，以及更新后旧索引和缓存是否失效。
关键词
AI 知识库；RAG；文档解析；分块策略；元数据；权限过滤；混合检索；引用；评测
研究问题与方法
本文研究的问题是：为什么很多知识库在演示时能回答，在生产中却难以承担组织记忆。方法上采用证据链分析，把资料从接入到回答的过程拆成结构保真、片段选择、权限约束和引用校验四个环节，并用召回质量与治理质量共同评价设计，而不是只看 embedding 模型效果。
图中最重要的是权限与版本在检索前参与，而不是回答后再由模型判断。若候选片段本身越权，模型生成得再谨慎也已经让风险进入上下文。评价知识库时，本文使用一个复合指标理解质量来源。
代表召回覆盖， 代表权限正确性， 代表引用可核验程度， 代表资料新鲜度。任一项接近零，最终答案都不应被视为可靠。
AI 知识库不是把文件上传到向量库，也不是给聊天框接一个检索插件。真正可用的知识库是一套资料治理系统：它知道资料从哪里来，谁有权看，如何解析，怎样切分，索引何时更新，回答引用哪一段证据，资料删除后索引是否同步失效，模型回答错了以后该追到哪一层。只把文档变成 embedding，最多得到一个能搜索的片段仓库；把文档、网页、代码、表格和多模态资料统一治理，才有可能得到一个能长期服务业务和学习的知识系统。
知识库设计的难点来自资料类型差异。PDF 有页眉页脚、目录、表格、图片和扫描件；网页有正文、导航、评论、广告、动态加载和更新时间；代码有文件路径、函数、类、依赖、提交记录和语义边界；表格有行列、公式、口径、单位和时间粒度；图片、音频、视频又需要视觉理解、转写、字幕、镜头和对象描述。把这些资料统一切成固定长度文本，会丢掉大量结构。RAG 系统表面能回答，实际可能把表格行列对错、把代码函数切断、把网页旧版本当新依据、把图片说明和原图脱节。
面向生产的知识库要同时满足四个目标。第一，资料可信：每个片段都能回到原始来源和版本。第二，检索准确：能根据问题找到相关、完整、当前用户有权访问的证据。第三，回答可核验：生成结果带有明确引用，读者可以追溯。第四，系统可维护：资料新增、修改、删除、权限变化和索引重建都有稳定流程。四个目标缺一不可。只有检索准确但没有权限控制，会泄漏资料；只有权限控制但没有版本和引用，会让用户无法判断答案依据；只有引用但没有增量同步，会引用过期内容；只有向量库但没有原文和元数据，会让故障排查无从开始。
引言：先定义知识库边界
知识库设计首先要回答一个问题：这里的“知识”到底指什么。企业文档、产品手册、网页教程、代码仓库、数据库表、工单记录、会议纪要、图纸、截图、视频课程，都可以成为知识来源，但它们的可信等级和使用方式不同。产品官网上的公开说明可以给外部用户引用，内部设计文档只能给授权成员使用，代码注释适合辅助开发者理解，客户工单更适合统计问题和生成客服建议，不能直接当作公开事实。
边界不清的知识库会出现两个极端。一种极端是资料太少，用户问什么都答不上来，系统只能靠模型常识补全。另一种极端是资料太杂，把所有文件、网页和聊天记录全部塞进去，召回结果看似丰富，答案却混入旧政策、草稿、个人意见和重复内容。知识库不是越大越好，而是要有清晰来源、清晰用途和清晰责任人。
设计时可以把资料分成五层。第一层是权威资料，例如正式文档、发布说明、制度、合同模板、接口文档和经过评审的教程。第二层是过程资料，例如会议纪要、工单、讨论帖和需求记录。第三层是运行资料，例如日志摘要、监控说明、故障复盘和用户反馈。第四层是代码资料，例如源代码、配置、测试用例和提交记录。第五层是多媒体资料，例如截图、图表、录音、视频和图纸。每一层都要有不同的解析策略、检索策略、引用规则和权限规则。
还要区分“面向回答的知识库”和“面向行动的知识库”。前者主要帮助模型回答问题、总结内容、查找依据；后者还会支持工具调用、流程决策和业务动作。例如客服知识库回答“如何退款”时，引用制度即可；退款助手真正执行退款时，还要读取订单状态、用户身份、支付记录和审批规则。回答型知识库可以容忍一定延迟，行动型知识库必须和业务系统状态严格对齐。
资料模型比向量模型更重要
很多教程从 embedding 开始讲知识库，但实际工程更应该先设计资料模型。向量只是索引层，资料模型才是知识库的骨架。一个可治理的资料对象至少要包含来源、类型、所有者、权限、版本、生命周期、解析状态、索引状态、可引用位置和删除策略。没有这些字段，后面所有检索质量和安全控制都会变成补丁。
可以把知识库拆成五类实体。源是资料入口，例如一个网页站点、一个 Git 仓库、一个文件夹、一个对象存储桶、一个 Notion 空间或一个数据库视图。文档是一次可管理的资料单元，例如一份 PDF、一篇网页、一张表、一段视频、一个代码文件。版本是文档在某个时间点的内容快照。片段是可检索的最小文本或多模态单元。引用是片段指回原文的位置，例如页码、标题层级、网页锚点、代码行号、表格坐标、视频时间段。
这五类实体不能混在一起。文档会更新，片段会重建，版本要保留，引用要稳定。向量库里的一个点只适合作为检索索引，不应该承担全部业务事实。若只保存向量和片段文本，用户问“这段话来自哪份文档第几页”时就答不上来；资料删除后，也很难保证所有残留片段被清掉；重新切分时，旧答案里的引用也会失效。
资料模型还要记录处理链路。一个片段是由哪个解析器、哪个切分策略、哪个 embedding 模型、哪个清洗规则产生的。回答质量下降时，问题可能来自新文档质量，也可能来自 PDF 解析失败、表格被压平、分块过短、embedding 模型替换、重排器失效或权限过滤错误。没有处理链路记录，团队只能盲目调提示词。
接入层：文件、网页、代码、表格和多媒体
文件接入要保持原文优先。用户上传 Word、PDF、PPT、Markdown、图片或压缩包时，系统应先保存原始文件和元数据，再进入解析队列。原文件是唯一可靠事实来源，解析结果和向量索引都可以重建。文件哈希、大小、格式、上传人、上传时间、归属空间、可见范围、保留期限都应记录。对重复文件，可以用内容哈希去重，但不要因为内容相同就合并权限不同的文档。
网页接入要关注变化和噪声。网页不是静态文件，同一 URL 的内容会更新，页面中还有导航、侧栏、广告、脚注、评论和相关推荐。抓取时要保存抓取时间、规范化 URL、标题、正文提取结果、站点规则、HTTP 状态、内容哈希和上次更新时间。对于官方文档站，应优先保留标题层级、代码块、表格和页面锚点；对于社区帖子，应区分主帖、回复、时间和作者。网页知识库最怕把旧页面、重复镜像和无关导航一起索引。
代码接入不能按普通文本处理。代码文件的语义边界是包、模块、类、函数、接口、配置项、测试用例和调用关系。一个函数被切成两半，检索就会丢失参数、返回值和错误处理；一个类和它的注释、测试分离，模型就难以理解真实意图。代码知识库应记录仓库、分支、提交、路径、语言、符号、依赖和行号。对常见语言，可以利用语法树或语言服务器提取符号结构，再与文本检索结合。
表格接入要保留结构。Excel、CSV、数据库导出、财务表和运营报表不能只按行拼成段落。表格里的表名、列名、单位、币种、日期粒度、公式、筛选条件、合并单元格和注释都可能影响含义。检索时，用户可能问“华东区三季度毛利率为什么下降”，答案需要同时定位相关行、列、指标解释和口径说明。表格知识库要保存单元格坐标、行列标题、表级摘要、字段类型和计算口径，必要时还要把表格转成结构化查询而不是纯文本片段。
多媒体接入要拆成多种证据。图片可以有 OCR 文本、视觉描述、对象标签、图表数据、原图位置和缩略图；音频可以有转写文本、说话人、时间戳和摘要；视频可以有字幕、镜头切分、关键帧、画面描述和时间段。多模态资料的治理重点不是把它们强行转成一段描述，而是同时保留原始媒体、机器提取信息和可回看的时间或区域引用。用户需要核验时，应该能跳到图片区域或视频时间段，而不是只看到一句模型描述。
解析层：先还原结构，再生成片段
解析不是把文件读成字符串。好的解析会尽量还原原始结构，包括标题、段落、列表、表格、代码块、脚注、图片、页码和层级关系。Unstructured 文档把 partitioning 描述为从原始非结构化文件中提取结构化元素，这个思路很适合知识库：先把资料变成元素，再决定每类元素如何进入检索，而不是一上来就按长度切分。
PDF 是最典型的解析难题。数字 PDF 可以提取文字，但多栏排版、页眉页脚、脚注和表格可能打乱阅读顺序；扫描 PDF 需要 OCR，识别错误会进入索引；带图表的报告如果只提取文字，图中关键数据会消失。工程上要把 PDF 解析结果和原页进行抽查，特别是财务、法律、医疗、工程图纸等高风险资料。解析失败的文件不应该悄悄进入知识库，而应进入待处理状态。
网页解析要做正文提取和链接规范化。页面标题、正文标题、发布时间、更新时间、面包屑、代码块和表格都要保留。导航栏、页脚、广告和推荐链接通常不应进入正文片段。对于文档站点，内部链接可以帮助构建知识图谱，例如“安装指南”链接到“配置参考”，“接口说明”链接到“错误码”。这些链接关系可以在召回或回答中提供上下文。
代码解析要兼顾符号和自然语言。函数签名、注释、文档字符串、调用关系、测试名称、错误处理和配置键都值得索引。代码本身也需要摘要，但摘要不能替代源码引用。一个实用方式是保留两类片段：细粒度符号片段用于精确检索，文件级或模块级摘要用于理解上下文。用户问“这个参数在哪里生效”，细粒度片段能定位；用户问“这个模块负责什么”，摘要片段更适合。
表格解析要避免丢失标题上下文。许多表格的第一行不是字段名，而是报表标题；字段单位可能在表外说明；合并单元格会影响多个行列；公式单元格需要保存公式和计算结果。表格可以生成行级片段、列级说明、表级摘要和指标字典。对于经常被查询的表，最好建立结构化字段映射，让模型先判断查询意图，再用受控查询读取数据。
多媒体解析要记录不确定性。OCR 有置信度，语音转写有听错风险，视觉描述可能遗漏细节。知识库不能把所有提取结果都当作同等可靠事实。可以给每个提取元素打上来源类型和置信等级：原始文字、OCR、转写、视觉描述、人工标注、模型摘要。回答时引用原始文字和人工标注的可信度通常高于自动视觉描述。
分块策略：按语义和证据边界切分
分块的目标不是满足 embedding 输入长度，而是让每个片段既可召回，又能作为回答证据。片段太短，会丢失定义、条件和例外；片段太长，召回噪声上升，模型上下文被浪费。分块要根据资料类型和问题类型调整。
普通教程和说明文档适合按标题层级切分。一级标题和二级标题提供主题，段落提供论述，列表和代码块提供细节。切分时应把标题路径带入片段元数据，例如“安装 > 数据库配置 > 连接池”。这样用户问“连接池怎么配置”时，片段不只包含几行参数，还能告诉模型它属于哪个章节。
制度、合同和规范适合按条款切分。条款编号、适用范围、例外条件、审批要求和生效时间必须保留。不能把“适用条件”和“例外条款”切开，否则模型可能给出过度简化的建议。法律、财务、人事和合规资料还应保留原文引用位置，回答中尽量引用条款而不是自由改写。
代码适合按符号切分，同时保留文件和模块上下文。函数、类、接口、配置块、测试用例是自然边界。对于长函数，可以按逻辑块继续拆分，但要保留函数签名、所在类、依赖导入和行号范围。代码问答经常需要精确定位，所以引用行号比普通文本引用更重要。
表格适合多视角切分。行级片段适合回答某个对象的属性，例如某个产品价格；列级片段适合解释指标含义，例如“留存率怎么算”；表级摘要适合回答整张表用途；单元格片段适合精确引用。固定字数切表格最容易出错，因为同一行的多个字段必须一起理解。
多媒体适合按时间、区域和主题切分。视频可以按字幕段落、镜头和章节切分；图片可以按 OCR 区块、图表区域和整体描述切分；音频可以按说话人和时间段切分。多模态片段要能回到原始媒体位置，否则引用难以核验。
分块策略最好版本化。每次调整片段长度、重叠比例、标题继承、表格展开方式或代码解析方式，都应记录版本并允许重建。否则同一问题在不同时间答案不同，团队无法判断是资料变了还是分块变了。
元数据和权限：检索前就要过滤
知识库权限不能靠提示词约束。模型看到不该看的片段后，再要求它“不要泄漏”是不可靠的。正确做法是检索前按用户身份、组织、角色、项目、文档状态和资料级别过滤，模型上下文里只放当前用户有权访问的内容。向量库的 payload filter、数据库查询条件和应用权限系统要一起工作。
元数据是权限和检索的共同基础。每个片段至少应有文档 ID、版本 ID、来源类型、来源 URL 或文件路径、标题路径、创建时间、更新时间、作者或责任人、可见范围、语言、内容类型、引用位置、索引版本和删除状态。对企业知识库，还要有租户、团队、项目、密级、数据域和保留期限。没有元数据，检索只能按语义相似度排序，权限和治理都会变得脆弱。
权限有几种常见模式。公开资料所有人可见；团队资料按组织可见；项目资料按成员可见；个人资料只本人可见；敏感资料需要额外授权或审批；过期资料默认不参与回答但可在历史查询中使用。权限变化要触发索引可见性更新。员工离职、项目归档、文档密级调整、客户数据删除，都不能等下次全量重建才生效。
多租户场景要特别谨慎。不同客户或团队的资料不能混在同一个无过滤索引里随意召回。即使向量距离很近，也必须先保证租户隔离。小规模系统可以在关系数据库里做权限过滤后再查向量；规模变大后，可以按租户或数据域拆 collection，也可以使用向量库的 payload 过滤。选择哪种方式取决于数据量、隔离要求、查询延迟和运维成本。
元数据还可以提升检索质量。用户问“最新版接口参数”，系统应优先召回更新时间新的正式文档，而不是三年前的讨论帖；用户问“这个报错在代码里哪里产生”，应优先代码和日志资料；用户问“某份合同条款”，应按文档 ID 限定范围。语义相似度不是唯一排序依据，资料权威性、时间、类型和用户上下文都应参与排序。
索引设计：全文、向量、结构化和图关系一起用
单一向量检索解决不了所有问题。向量检索擅长语义相近问题，例如“如何让知识库只回答有依据的内容”；全文检索擅长精确词、错误码、函数名、产品型号和条款编号；结构化查询擅长表格和数据库；图关系擅长依赖、引用、上下游和章节关联。一个成熟知识库通常需要组合索引。
向量索引适合自然语言问答。用户表达和原文不同，但含义相近时，embedding 能找到相关片段。RAG 论文提出把预训练生成模型和可检索的非参数记忆结合，用检索到的文档辅助生成。这个基本思想至今仍然有效：模型不应只依赖参数记忆，而应在回答时读取外部证据。
全文索引适合精确匹配。错误码、接口名、SKU、法规编号、函数名、配置键、中文简称和英文缩写，往往不需要语义理解，而需要精确命中。很多向量模型会把相似词拉近，却不保证精确词一定靠前。知识库如果只用向量检索，用户搜“ERR_AUTH_401”反而可能召回一堆认证概念文档。
混合检索把向量和全文结合起来。Qdrant、Weaviate、Milvus 等向量数据库都在文档中强调过滤、混合搜索或重排能力。实际系统可以先用全文和向量分别召回候选，再用融合算法合并；也可以按问题类型选择检索器。用户问定义、流程、原因时偏向向量；用户问编号、路径、代码符号时偏向全文；用户问指标时偏向结构化查询。
结构化索引适合表格和业务数据。很多问题不应该从文本片段里猜答案，而应该查询表格或数据库。例如“上月各渠道转化率最高的是哪个”需要聚合计算；“某用户是否有权限访问这个项目”需要权限表；“某个订单是否能退款”需要订单状态。知识库可以把结构化数据的字段说明、口径文档和查询工具结合起来，让模型理解问题，再由受控查询返回结果。
图关系适合上下文扩展。一个文档引用另一个文档，一个函数调用另一个函数，一个产品版本依赖某个配置，一个制度条款关联审批流程。这些关系不能完全靠相似度捕捉。知识图谱不一定要做成庞大工程，最小也可以从文档链接、标题层级、代码调用、表格外键和来源关系开始。检索到一个片段后，系统可以扩展父标题、相邻条款、被引用页面或调用方函数。
增量同步：知识库必须跟着来源变化
资料更新是知识库长期运行中最常见的风险。源文档改了，索引没更新；文档删了，片段还在；权限收紧了，旧索引仍可召回；网页改版了，抓取器继续抓导航；代码分支切换了，答案引用旧行号。增量同步不是性能优化，而是正确性要求。
增量同步有几种来源。文件系统可以用哈希和修改时间判断变化；对象存储可以监听上传、覆盖和删除事件；网页可以定时抓取并比较内容哈希、ETag、Last-Modified 和站点地图；Microsoft Graph 这类平台提供 delta query，用状态令牌获取新增、更新和删除；GitHub Webhooks 可以在 push、分支删除和标签变化时通知系统。不同来源的同步方式不同，但目标相同：用最小代价捕捉真实变化。
同步流程应包含发现、拉取、解析、差异比较、索引更新和可见性切换。不要在新索引未完成时直接删除旧索引。更稳的做法是为文档创建新版本，解析和索引成功后再把活跃版本切换过去；如果解析失败，旧版本仍可服务，并把文档标记为待处理。删除则要进入软删除流程，先让资料不可召回，再按保留策略清理原文和索引。
代码知识库要按提交处理。仓库每次 push 后，系统可以只解析变更文件，更新相关符号索引，并保留提交号。回答引用代码时，必须说明对应提交或分支，否则用户很容易在当前代码里找不到引用。对主分支和发布分支，索引策略也可以不同：主分支适合开发问答，发布分支适合用户文档和线上问题排查。
网页知识库要处理删除和重定向。页面 404、301、canonical 改变、标题变化、正文变化都需要记录。旧 URL 的历史版本可以保留，但默认回答应优先当前版本。若一个页面从公开改为登录可见，抓取和权限也要随之变化。
增量同步还要考虑批量重建。embedding 模型升级、分块策略调整、权限模型变化、解析器升级，都可能需要重建索引。重建时要有任务队列、进度、失败重试、资源上限和版本切换。不能因为重建索引就让知识库长期不可用。
引用和证据：回答必须能回到原文
知识库问答的核心承诺是“有依据”。引用不是装饰，而是用户判断答案可信度的入口。一个好的引用应包含来源标题、位置、版本或更新时间、片段摘要和可打开链接。文件资料引用页码或章节，网页资料引用 URL 和标题锚点，代码资料引用仓库、提交、文件路径和行号，表格资料引用表名、行列或筛选条件，多媒体资料引用时间段或区域。
引用要和生成过程绑定，而不是事后装配。模型回答中的关键结论应能对应到检索片段。OpenAI File Search 文档提到文件检索可以返回 file citation 注解，这说明“引用作为输出结构的一部分”已经成为知识库应用的重要能力。自建系统也应把引用作为回答对象的一等字段，而不是把链接拼在文末。
引用还要区分直接证据和背景资料。直接证据支撑具体结论，例如“退款需在七日内申请”来自制度条款；背景资料只帮助理解，例如“退款流程属于售后政策”。如果把所有检索片段都列为参考，用户看不出哪些是真正依据。更好的方式是每个关键结论后附一到两个直接证据，文末再列延伸资料。
引用位置必须稳定。PDF 页码、网页锚点、代码行号和表格坐标都会随版本变化。系统需要记录引用对应的文档版本。如果当前版本已经变化，用户查看旧回答时应知道当时依据的是哪个版本。对高风险场景，最好保留引用快照，避免原文更新后旧答案无法核验。
答案中没有证据时要明确说明。知识库不是万能搜索引擎，找不到依据时应回答“未在当前资料中找到明确说明”，并给出可能的下一步，例如建议查看某类资料、联系责任人或补充文档。不要让模型凭常识编造制度、接口和数字。对于教程类知识库，可以允许模型解释通用概念，但必须区分“资料中明确写到”和“基于通用原理的解释”。
评测：不要只看模型回答是否顺眼
知识库评测要覆盖检索、证据、生成、权限和同步。只让人工看几条回答是否自然，不足以判断系统可靠。RAGAS 文档中的 faithfulness、answer relevancy、context precision、context recall 等指标，提供了一个有用方向：回答是否忠实于上下文，答案是否相关，召回上下文是否精确，是否漏掉必要证据。指标不必照搬，但评测维度不能缺。
检索评测要有问题集。问题集应来自真实用户提问、客服记录、搜索日志、培训题、故障复盘和产品 FAQ。每个问题要标注理想证据，而不只是理想答案。这样才能评估召回是否找到了正确片段。如果问题没有标准证据，团队很难判断是模型没答好，还是知识库里本来没有资料。
生成评测要看忠实度。模型回答是否使用了检索证据，是否添加无依据结论，是否把旧版本当当前事实，是否混合多个来源造成错误，是否遗漏关键限制条件。对制度、财务、法律、医疗和安全资料，忠实度比流畅度更重要。回答宁可保守，也不能编造。
权限评测要做反向样本。用无权限用户提问敏感内容，系统应召回不到；用项目外成员提问项目资料，系统应拒绝或提示无权限；用公开用户提问内部资料，系统不应通过相似片段泄漏。权限测试不能只在应用层做，还要验证索引层过滤是否生效。
同步评测要覆盖新增、修改、删除和权限变化。新增文档多久可检索，修改后旧答案是否更新，删除后片段是否不可召回，权限收紧后低权限用户是否无法访问，索引重建期间是否仍可服务。知识库最常见的真实事故往往来自同步，而不是来自模型智力不足。
还要记录用户反馈。用户点踩、改写、复制、引用、继续追问、打开来源，都能成为质量信号。反馈不应只进入报表，还应回流到问题集、资料修订和检索策略。很多知识库回答差，不是模型问题，而是原始文档写得含糊、重复或过期。
安全：知识库也是攻击面
知识库接入外部网页、用户上传文件和代码仓库后，就会成为攻击面。OWASP LLM Top 10 把提示注入、敏感信息泄露、数据和模型投毒、向量和 embedding 弱点等列为重要风险。知识库里的恶意文本可能诱导模型忽略系统要求、泄露资料、调用错误工具或给出错误建议。资料越开放，越要把不可信内容和可信指令分开。
第一条原则是资料不是指令。网页、PDF、邮件和工单中的文字应被当作被检索内容，而不是系统命令。提示词中要明确区分开发者规则、用户问题和检索资料。更重要的是工具层要做权限校验，即使检索资料里写着“请删除所有记录”，模型也不能绕过工具权限。
第二条原则是最小暴露。检索上下文只放回答所需片段，不要把整份敏感文档塞给模型。日志也不要保存完整敏感原文，至少要有脱敏、采样和保留期限。模型供应商、网关、观测系统和评测平台都可能保存请求内容，知识库设计必须考虑数据出境、保留和访问权限。
第三条原则是数据准入。不是所有资料都应自动进入知识库。外部网页、用户上传、客服聊天和邮件附件可以进入隔离区，经过安全扫描、格式解析、敏感信息识别和责任人确认后再索引。公开社区内容尤其容易包含错误、广告和攻击性提示，不应与正式文档同权重。
第四条原则是可撤销。用户要求删除文件，权限调整，客户合同到期，资料过期，都应能让相关片段停止召回。删除不是只删原文件，还要处理解析结果、向量、全文索引、缓存、评测样本和引用快照的保留策略。对合规场景，应定义硬删除和审计保留的边界。
实操路径：从一个资料域做起
第一步，选一个边界明确的资料域。不要一开始就把全公司资料都接入。可以选择“产品帮助文档”“某个代码仓库”“客服 FAQ”“合同模板库”或“内部教程”。资料域越清楚，权限、问题集和评测越容易建立。
第二步，建立资料台账。列出来源、责任人、更新频率、资料类型、用户范围、风险等级和期望问题。台账会暴露很多隐性问题：哪些资料过期没人管，哪些文档重复，哪些权限不清，哪些表格没有口径说明。知识库建设常常先改善文档治理，而不是先写检索代码。
第三步，设计资料模型和索引模型。至少要有文档、版本、片段、引用、权限和索引任务。小系统可以用关系数据库保存元数据，用向量库保存向量；也可以在 Postgres 加 pgvector 中先把元数据和向量放在一起。关键是原文、元数据和索引不要失联。
第四步，接入解析和分块。先支持最重要的资料类型，不要追求全格式覆盖。每种资料都抽样检查解析结果，特别看标题层级、表格、代码块、页码、图片文字和链接。解析质量差的资料要先修入口，而不是让模型硬答。
第五步，做混合检索和引用输出。向量检索解决语义问题，全文检索解决精确词问题，元数据过滤解决权限和范围问题。回答必须带引用，引用可以打开或定位。没有引用的关键结论应被视为低可信。
第六步，建立评测集。先从三十到一百个真实问题开始，标注应该出现的证据和不能出现的敏感资料。每次改解析、切分、检索、重排、模型或提示词，都跑评测。小评测集比没有评测强得多。
第七步，做增量同步和运维。新增、修改、删除、权限变化、重建索引都要有状态和日志。索引任务失败要能重试，资料解析失败要展示给责任人，删除要保证不可召回。知识库上线后，治理工作才真正开始。
典型案例：产品文档、代码和表格的统一问答
假设一个团队要为开发者提供产品技术知识库，资料包括官网文档、SDK 代码仓库、API 错误码表、更新日志和演示视频。用户会问“上传文件接口为什么返回 413”“Python SDK 怎么设置超时”“最新版是否支持流式输出”“某个示例代码和文档不一致怎么办”。这个场景很适合展示统一治理。
官网文档按页面和标题层级接入，保留 URL、更新时间、版本和锚点。SDK 仓库按提交和符号解析，保留文件路径、函数、类、行号和测试。错误码表按结构化表格接入，保留错误码、含义、触发条件、建议处理和版本。更新日志按版本切分，保留发布日期和影响范围。视频先做转写和章节摘要，关键操作保留时间戳。
用户问 413 错误时，系统应优先精确匹配错误码表，再扩展到上传接口文档和相关更新日志。如果文档中写了上传大小限制，回答引用接口文档和错误码表；如果代码仓库里常量值和文档不同，回答应指出版本差异，并引用代码行号和文档版本。用户问 SDK 超时时，系统应召回 Python SDK 的配置函数、示例代码和文档说明，而不是只给出通用 HTTP 超时概念。
这个知识库的关键不是用了哪个向量库，而是所有资料有统一 ID、版本、权限、引用和更新机制。官网页面更新后索引自动重建；SDK push 后只更新变更文件；错误码表改字段后结构化索引更新；视频转写失败不会污染正式资料；回答中的每个关键结论都能打开来源。这样的系统才能成为开发者真正愿意依赖的知识入口。
常见误区
第一个误区是把向量库当知识库。向量库只是索引，知识库还包括原文、版本、权限、解析、引用、同步、评测和治理。没有这些，检索再快也不可靠。
第二个误区是固定长度切所有资料。文档、代码、表格和视频有不同结构。统一按字数切分会破坏条款、函数、表格行列和视频时间线。分块必须尊重资料本身的证据边界。
第三个误区是先追求全量接入。资料越多，噪声、权限和过期问题越多。更稳的路线是先选一个资料域，把引用、评测和同步做通，再扩展来源。
第四个误区是把权限放在回答后处理。模型不该看到的资料，就不应进入上下文。权限过滤要发生在检索前或检索中，而不是生成后再要求模型自律。
第五个误区是只看答案流畅度。知识库回答要看是否找到正确证据、是否忠实于证据、是否引用当前版本、是否符合用户权限、是否能追溯。流畅但无依据的回答是风险。
第六个误区是忽视删除和过期。资料删除后索引仍能召回，是知识库事故。资料过期后仍被高权重引用，会让用户做错决策。生命周期管理必须从第一天设计。
第七个误区是把多模态资料压成一句摘要。图片、音频、视频需要原始媒体、提取文本、时间段、区域和置信度。摘要可以帮助检索，但不能替代可核验的原始证据。
检查清单
- 是否定义了资料源、文档、版本、片段、引用和索引任务的关系？
- 是否保存原始文件或原始网页快照，并能从片段回到来源？
- 是否按文档、网页、代码、表格和多媒体分别设计解析策略？
- 是否为片段保存标题路径、来源位置、更新时间、权限和索引版本？
- 是否在检索前按租户、团队、项目、角色和密级过滤？
- 是否同时使用向量检索、全文检索、结构化查询或图关系，而不是只依赖一种索引？
- 是否支持新增、修改、删除、权限变化和索引重建的增量同步？
- 是否能把回答中的关键结论映射到具体引用？
- 是否有真实问题集评估召回、忠实度、引用、权限和同步？
- 是否能处理解析失败、OCR 低置信度、表格结构丢失和代码版本变化？
- 是否区分权威资料、过程资料、用户上传资料和外部网页资料的可信等级？
- 是否定义了资料过期、软删除、硬删除、缓存清理和审计保留策略？
运营角色和责任边界
知识库不是一次性项目，还需要清楚的运营角色。资料责任人负责内容准确性和更新时间，平台负责人负责解析、索引、权限和服务稳定性，应用负责人负责回答体验和业务流程，安全负责人负责数据等级、保留策略和外部模型使用边界，评测负责人负责问题集和质量回归。角色可以由同一批人兼任，但责任不能消失。
在实际团队里，很多知识库失败不是因为向量模型差，而是没有人负责资料生命周期。过期文档没人下架，重复文档没人合并，制度更新没人通知索引重建，用户反馈没人回到文档修订。知识库治理要建立固定节奏：每周查看高频无答案问题，每月清理过期资料，每次产品发布同步更新文档和代码引用，每次重大策略变化重新跑评测集。这样知识库才会随着业务成长，而不是上线后慢慢失真。
运营还要区分“修资料”和“修系统”。如果用户经常问不到某个答案，可能是检索策略问题，也可能是原文根本没有写清楚。若引用正确但回答难懂，可能要改生成提示；若引用不对，可能要改分块、重排或元数据；若无权限用户看到了片段，则是权限过滤事故。把问题归因到正确层级，知识库才能持续改进。
结语
AI 知识库的本质是让模型在正确权限下读取正确资料，并把答案绑定到可核验的证据。文档、网页、代码、表格和多模态资料统一治理后，知识库才不只是一个搜索入口，而是一个持续更新、可追溯、可评测、可维护的知识基础设施。
设计知识库时，先把资料模型、权限、引用和同步想清楚，再选择向量库、embedding 模型和应用框架。技术组件会变化，但治理原则稳定：原文要保留，结构要还原，片段要可追溯，权限要前置，索引要增量更新，回答要有证据，质量要靠评测闭环。做到这些，知识库才能从演示走向长期可用。
参考资料
- Lewis et al.：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks https://arxiv.org/abs/2005.11401
- LlamaIndex Docs：Ingestion Pipeline https://docs.llamaindex.ai/en/stable/module_guides/loading/ingestion_pipeline/
- LangChain Docs：Retrievers https://api.python.langchain.com/en/latest/langchain/retrievers.html
- Unstructured Docs：Partitioning https://docs.unstructured.io/concepts/partitioning
- Qdrant Docs：Search, Filtering and Hybrid Queries https://qdrant.tech/documentation/search/
- Qdrant Docs：Text Search and Hybrid Search https://qdrant.tech/documentation/guides/text-search/
- OpenAI Docs：File Search https://platform.openai.com/docs/guides/tools-file-search/
- Microsoft Learn：Use delta query to track changes in Microsoft Graph data https://learn.microsoft.com/en-us/graph/delta-query-groups
- GitHub Docs：Webhook events and payloads https://docs.github.com/en/webhooks/webhook-events-and-payloads
- RAGAS Docs：RAG evaluation metrics https://docs.ragas.io/
- OWASP：Top 10 for LLM Applications 2025 https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
- pgvector：Open-source vector similarity search for Postgres https://github.com/pgvector/pgvector
写作日期：2026-05-22