这两年做企业知识管理绕不开一个词AI知识库。但真去试用一圈就会发现市面上大多数知识库本质上还是“关键词搜索文档列表”企业里那些藏在产品截图、会议录音、PPT图表里的知识根本搜不出来。我最近带团队把内部知识库从纯文本RAG升级成了多模态知识库最大的感受是知识终于从一个“搜索工具”变成了“能理解、能生成的同事”。这篇就来复盘完整搭建路径多模态技术选型怎么定、图片和音视频怎么进知识库、Dify这类平台怎么落地以及我们从演示环境走到生产环境时踩过的一堆坑。适合正在做知识中台、想在企业内部落地AI应用的工程师和产品经理参考。1. 多模态知识库到底解决什么问题1.1 传统知识库为什么“中看不中用”先讲一个我们内部真实的场景。产品经理手里有一套完整的PRD里面包含流程图截图、竞品分析表格、需求评审会的录音以及几版修改过的原型图。他每天要花大量时间把这些“经验”讲给研发、测试、新人听。我们当时的搜索平台建得很好文档索引、标签体系、权限控制都齐全但问题在于截图里的流程图、录音里的讨论结论这些“知识”从来没有进入过索引体系。传统知识库本质上是文本检索系统的延伸它默认知识长在文档里。可现实是一个企业里真正值钱的知识大量寄生在图片、音视频、扫描件、PPT里。你搜“这个季度的客户反馈结论”搜出来的是一堆PPT文件名而不是PPT里那张趋势图背后的分析逻辑。搜索只能返回“提到关键词的文档”无法告诉你“这段内容到底在说什么”。另一个问题是检索方式。传统搜索靠关键词匹配用户需要知道准确的说法才能查到。但企业内部的表达五花八门同一个人在不同文档里可能把“退款流程”叫“退费流程”“售后补偿流程”系统不会自动把这些说法关联起来。所以知识库里躺着大量内容却一直处于“知道有、找不到、用不上”的状态。我们真正需要的不是“更好的搜索框”而是让知识库理解内容本身知道一张图在表达什么知道一段录音里的结论是什么然后把相关内容组织起来回答你的问题。这就是多模态知识库的出发点。1.2 “可理解、可生成”意味着什么“可理解”这个阶段好理解系统不再把文档当字符串处理而是通过大模型理解语义把不同表达方式归到同一层语义空间里。你和知识库说“上次那个客户投诉是怎么处理的”它能理解你在问售后流程而不是傻傻去匹配“投诉”两个字。“可生成”则是更进一步。知识库不仅给你找材料它能把找到的材料组织成答案、总结、行动建议。你问“这个迭代的核心风险和应对方案”它能综合阅读十几份文档、几张流程图生成一份有逻辑的总结。这个过程不是把原文拼在一起而是真正“读懂了再说话”。多模态带来的“可理解”还多一层系统能够跨模态理解内容。一张故障照片、一段现场录音、一份设备维修记录本质上都在描述同一个事件。多模态知识库可以把这些不同形态的信息关联起来回答“这个设备目前到底什么状态”这种靠单一文本回答不了的问题。“可生成”在多模态场景下还意味着输出形态的丰富。知识库不只生成文字还可以生成图片流程图、音频摘要、可视化报表。我们后文会展开说怎么实现。1.3 多模态知识库的典型应用场景售后客服知识库是最好切入的场景。客户发来一张产品故障照片传统知识库只能搜说明书文本多模态知识库可以直接识别照片里的故障表现再结合维修工单和录音记录自动判断故障类型和处置方案。农业领域也很典型。植保站遇到农户拿着带病虫害的作物叶片来问诊知识库里存的是植保手册文本和大量病虫害图片。多模态知识库可以把图片特征和文本防治方案关联起来实现“拍个照→识别病害→给出防治建议”的闭环。制造和研发场景同样有价值。设备点检记录、图纸、维修视频散落在不同系统里出了问题老师傅能立刻想到“三年前那次故障是怎么处理的”但新人翻遍系统也找不到那段维修视频。多模态知识库把视频里的关键操作片段转写成可索引的内容新人检索后直接看视频片段就能上手。这些场景有一个共同点知识本身是跨模态存在的靠单一模态的文本索引一定会有信息死角。我们的结论是凡是“图纸文档”“语音纪要”“图片报告”混在一起同时又高频使用的业务就值得考虑上多模态知识库。2. 多模态知识库的整体设计思路2.1 一套通用的系统架构我们最终跑通的架构分成六层每一层都有明确职责。数据接入层负责对接各种内容系统包括文档库、工单系统、视频平台、IM记录。多模态处理层负责把非文本内容转成机器可处理的形态OCR识别扫描件和图片中的文字语音识别把录音和视频转成文本视觉模型把图片内容转成文字描述。向量化层负责把处理完的内容变成向量文本走文本Embedding图片既可以用视觉模型生成描述后再向量化也可以用多模态模型直接做图文对齐。存储层通常是一个向量数据库加一个关系型数据库的组合向量库负责相似度检索关系库负责权限、来源、版本等元数据。召回层做混合检索和重排序把关键词匹配、向量检索、元数据过滤的结果合并起来再用重排序模型精选。生成层调用大模型或者多模态大模型基于召回的上下文生成回答还可以通过Agent调用其他工具。这个架构本质上就是RAG流水线的多模态扩展。纯文本RAG里的“文档切块→向量化→召回→生成”流程依然保留多模态知识库只是在前面增加了一个“内容理解”步骤让图片、音视频也能进入后面的索引和召回链路。如果你不想从零搭建平台完全可以借助Dify这类开源工具的知识库流水线它会帮你把数据接入、分段、向量化、检索、生成这些环节串起来。我们实践下来平台工具适合快速验证但如果要做深度的权限控制和多模态自定义处理还是建议平台加自研脚本结合。2.2 文本、图片、音视频分别怎么处理不同类型的内容处理策略差异很大。我把我们团队的实际方案整理成了下面的对照表。素材类型预处理策略向量化方案存储方式文本/Word/Markdown清洗段落、去页眉页脚、正则处理文本Embedding向量库原文备份PPT/PDF含图片OCR提取文字逐页截图片文本Embedding图片描述向量库原图路径扫描件/合同版面分析OCR保留阅读顺序文本Embedding向量库PDF路径图片截图、图纸、照片视觉模型生成文本描述、OCR关键文字文本Embedding为主CLIP辅助向量库缩略图录音/视频ASR转写说话人分离章节摘要文本Embedding分段向量库时间戳索引表格/Excel转成Markdown或JSON保留结构文本Embedding结构化存储图片处理是这里面最需要重点说的。我们试过两条路线一条是CLIP这类多模态模型直接把图片和文本做语义对齐另一条是“图转文”路线先用视觉大模型生成图片的文字描述再对描述做文本Embedding。第一条听起来更“多模态”但实际落地效果并不稳定尤其面对中文企业物料里的截图、复杂表格、专业图纸时CLIP的区分度不够召回结果经常让人摸不着头脑。第二条路线感知上有点土但极其稳视觉模型生成的描述质量直接决定检索效果而且这些描述可以重新编辑相当于给图片做了人工标签。两条路线我们最后是叠加用的。检索时先走“图转文”的主索引拿高精度结果再用CLIP算一遍图片相似度做辅助召回两者做加权融合。生产环境里CLIP更像一个策略补充而不是主力。音视频处理的核心是ASR转写质量。我们用的Whisper和FunASR做中英双语转写转写后不能直接把全文塞进向量库而是要做分段和摘要。会议录音转写出来的文本噪声很大夹杂语气词、重复语句直接切块会让检索命中碎片化。我们现在的做法是先做说话人分离再按语义窗口生成段落摘要优先存摘要和结论把原始转写作为明细数据保留。2.3 工具选型Dify、向量库、开源模型怎么搭配工具选型直接决定了知识库是走通还是走死。我们这个项目早期最大的误区就是什么都想用最新的模型后来才想明白一个道理知识库是系统工程不是单靠一个强模型就能解决问题的。先看平台层。Dify是目前我们把知识库流水线落地最顺畅的开源平台它把数据接入、分段策略、Embedding、检索、Agent工作流转发这些环节都做成了可视化流程我们给非开发背景的运营同学培训后他们也能自己维护知识库内容。豆包这类开箱即用的国产AI平台我们也用来做过快速验证跑通链路的速度很快适合原型期试错但企业一旦涉及私有化数据、细粒度权限这些需求最终还是绕不开自建一套处理脚本。再看模型层。Embedding模型我们选了国产BGE系列中文语料上的效果明显好于通用模型实测BGE-M3在混合同义词和长尾表达上的表现远超预期。生成模型我们大部分场景用Qwen系列开源模型小部分复杂场景调用在线大模型。至于LLaMA这类海外开源模型技术能力没问题但国内企业用在中文知识库问答上性价比不高中文分词、指令跟随、上下文习惯都需要额外适配维护成本反而上去了。向量数据库主要在Milvus和Elasticsearch之间选。数据量小时Chroma也够用但企业级场景我们建议上Milvus分布式部署、混合检索、标量过滤这些能力都是刚需。如果团队已经有ES运维经验也可以直接拿ES做混合检索少维护一套组件。顺便提一句如果后续要做音视频知识库的在线播放和切片可以关注MOQ这类基于QUIC的传输协议它把多模态媒体数据的传输延迟压得很低算是一个值得关注的方向但不是当前阶段的核心。3. 实操搭建从零搭一套最小可用多模态知识库3.1 环境准备现有硬件下的组件组合很多人一听多模态就以为需要A100级别的显卡我们实测下来验证阶段用一台跑起来Qwen2.5-VL-7B的机器就够用了。这套最小可用组合是这样的一台带推理卡的Ubuntu服务器或者本地工作站、Docker、Ollama、Dify社区版、Milvus或者是Dify自带的向量库插件再准备两个开源模型——BGE-M3做EmbeddingQwen2.5-VL-7B做视觉理解和生成。如果你不想一开始就被部署细节缠住可以先在GPU机器上通过Ollama拉模型命令行验证模型能不能正常跑起来ollama pull qwen2.5-vl:7b ollama pull bge-m3 ollama list模型跑通之后再启动Dify。Dify的docker部署比较成熟官方仓库拉下来后配置好环境变量就行。等Dify起来之后在模型供应商页面填入Ollama的接口地址就能在平台里调用本地视觉模型和Embedding模型了。这一步的关键在于确认一张图片能否通过Ollama接口返回正确的描述文本。你在终端里随便找一张产品截图让它生成一段文字描述。如果这一步的输出质量不行后面的图片知识库全是废的。我们当时跳过这一步直接配知识库结果图片召回效果极差排查半天才发现是视觉模型输出格式不对教训就是基础验证做扎实再往上搭。3.2 在Dify里配置知识库分段与索引策略Dify创建知识库后上传文件时要注意它区分文本类和图片类。文本类直接走分段和嵌入流程图片类则要在配置里开启视觉理解相关选项。我们一般把图片和文字分开建知识库因为它们的检索逻辑和召回判定方式不同混在一起容易互相干扰。分段策略是很多人忽略的重点。默认分段长度和重叠参数对中文场景并不友好我们测试下来中文技术文档把块大小设置在400到600字、重叠50字左右时效果最好。太长的块会让语义混杂太短的块会切碎逻辑。如果你处理的是代码注释和接口文档块大小建议更小200到300字就够了。索引方式选择高质量模式它会多消耗一点算力去保留更多语义细节但检索准确率能明显提升。上传几张图片做测试。图片上传后Dify会调用视觉模型生成图片内容描述这些描述会作为向量化的依据。建议你在知识库后台检查一下生成的描述质量Dify允许手工编辑这些自动生成的描述这是我们强烈推荐的做法。自动描述有时候太泛“一个产品界面截图”这种描述检索时基本没用改成“订单列表页包含筛选、导出、批量退款按钮”之后召回效果完全不同。3.3 多模态索引流水线图片入库的代码路径Dify可视化界面能覆盖标准流程但生产环境里大量存量图片需要批量入库我们写了独立的处理脚本。核心逻辑很简单读图片→视觉模型生成描述→清洗描述→调用Embedding接口→写入向量库。下面是一段流程示意重点看步骤组合不要直接抄。import requests from openai import OpenAI # 1. 视觉模型生成图片描述 client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) def generate_caption(image_path): response client.chat.completions.create( modelqwen2.5-vl:7b, messages[{ role: user, content: [ {type: image, image: image_path}, {type: text, text: 描述这张图的业务内容包括界面元素、文字信息、逻辑关系。} ] }] ) return response.choices[0].message.content # 2. 清洗描述去掉模型凑字数的废话 def clean_caption(caption): stop_phrases [这是一张, 如图所示, 从上图可以看出] for phrase in stop_phrases: caption caption.replace(phrase, ) return caption.strip() # 3. 调用Embedding接口生成向量 def embed_text(text): response client.embeddings.create(modelbge-m3, inputtext) return response.data[0].embedding这里我特别强调清洗描述这个步骤。视觉模型生成描述时会带很多与业务无关的套话比如“这是一个美丽的产品界面”这种。这些套话会稀释向量里的有效信息。我们后来的做法是给视觉模型提供上下文提示词让它只输出业务要素不许输出评价再加一道清洗规则去掉描述性和修饰性词汇。这一优化把图片检索的命中率提升了接近一倍。整个流水线的调度用Python脚本加定时任务完成就行。新增一批图片跑一遍脚本增量写入向量库。这里要注意增量更新时的去重逻辑不要对同一张图片生成两次向量否则知识库里的重复内容会干扰召回的排序。3.4 让知识库真正“可回答、可生成”知识库配置完成后剩下的问题是对话效果。Dify里可以在应用设置中把多个知识库挂到同一个对话应用上用户提问时会先做召回再让大模型基于召回结果生成答案。对于多模态问答我们需要在提示词里告诉大模型你是一个熟悉公司业务的知识助手回答时要结合图片描述、录音转写、文档片段并注明信息来源。我们做的第一个端到端业务场景是“故障照片问答”。客服上传一张设备故障照片知识库需要识别设备型号、故障现象、历史维修记录再给出处理建议。实际跑通后发现光靠照片描述是不够的历史维修记录是文本两者都在知识库里但检索时未必同时被召回。解决办法是把流程拆成两步先用图片检索召回相关故障描述再拿这些描述里的设备型号和故障关键词二次检索文本知识库最后把两批结果拼在一起给大模型生成最终答案。这里就是Agent能发挥作用的地方了。Dify的Agent工作流可以编排这些检索步骤第一步调用图片识别工具第二步调用知识库检索工具第三步调用生成模型汇总。多模态知识库和Agent结合之后不再是简单的一问一答而是像一个能“看一眼再查资料再回答”的助手。这是我们觉得多模态知识库最有价值的部分知识本身仍然是那些资料但系统具备了跨模态整合和任务拆解能力。4. 常见问题与排查技巧实录4.1 图片知识检索不到根源往往在起点图片检索效果差九成问题出在起点也就是“图转文”这一步。如果你的系统里根本没有为图片生成可检索的描述后面任何优化都无从谈起。我们早期在知识库里传了几千张图片发现很多图片召回不到翻后台一看不少图片的描述是空的或者是“图片”两个字因为视觉模型处理超时流水线直接把这条记录跳过了。排查时先做两件事第一检查图片描述生成覆盖率有没有大比例入库图片缺少描述第二抽查描述质量描述里有没有关键业务词。修复方法前文提过给视觉模型加严格的提示词模板把业务要素、禁止输出评价这类约束写进去。覆盖率低于95%的情况不要贸然谈检索优化先把基础数据补齐。4.2 向量召回不准确重排序不是可选项向量检索的问题在于它按语义相似度排序但语义相似不等于问题答案。用户问“退款周期多长”向量库里可能召回了“退款周期过长导致投诉”的内容因为语义相近。这时候需要重排序模型做二次精排。我们用的BGE-Reranker效果很稳可以把向量检索召回的Top50结果重排到Top10准确率提升非常明显。如果没有重排序环节只靠向量相似度直接扔给大模型几乎是必然出现答非所问。另外要检查Embedding模型是否和生成模型匹配有些团队Embedding用英文模型做中文内容召回结果自然一塌糊涂。中文知识库场景Embedding模型的选择优先级极高建议预算和算力向Embedding和重排序模型倾斜而不是一味追求更大的生成模型。4.3 中文场景下的特殊问题中文知识库有一个隐藏问题检索的时候用户说的是口语化表达库里存的是书面语。比如用户问“那个表怎么导出来”文档里写的是“数据导出功能操作说明”。语义是一致的但向量表示上有差距。我们靠两条路缓解一是Embedding模型选中文优化过的二是把常见口语说法做成检索扩展词在召回阶段同时用原词和扩展词去检索。中文长文档还有一个切分合理性难题。默认按字数硬切会把背景介绍、方案细节、结论拆到不同的块里回答时上下文不全。我们试过几种切分策略按Markdown标题和段落结构切分的效果远好于纯字数切分。如果文档没有良好的标题结构AI先把它整理成一个带章节的框架再按章节切块效果会稳定很多。4.4 部署性能与资源开销的注意点多模态知识库比纯文本RAG耗资源主要贵在视觉模型推理和向量化两个环节。批量图片入库时如果不限制并发显卡很容易被打满显存爆掉后进程直接崩溃。脚本里要控制并发数经验是一次只跑两到四张图片宁可慢一点也不要让推理进程崩溃。另一个注意点是向量化算力。大量图片生成描述之后要一并Embedding这个阶段纯CPU也能跑但速度极慢。我们实测一批一万张图片纯CPU跑要几个小时GPU跑只需要几十分钟。建议向量化阶段预留GPU资源生产环境的定时任务安排在半夜跑错开在线问答高峰。故障现象可能原因解决建议图片库里检索结果为空图片未生成描述或超时跳过检查描述覆盖率重新跑流水线检索返回的内容牛头不对马嘴Embedding模型不适合中文换BGE-M3等中文专用模型长文档回答缺少结论切块策略破坏了原文结构按标题层级切块而非纯字数切块检索结果相关但不够精准缺重排序环节加BGE-Reranker精排批量入库导致显卡崩溃并发数过高限制并发增加防崩溃重试机制4.5 从演示到生产别忽略权限和数据更新演示环境里知识库往往只有几百条测试数据权限、更新这些问题完全不会暴露。一旦放上生产立刻要面对三个问题谁能看什么内容、数据多久更新一次、更新错了能不能回滚。权限方面多模态知识库比文本知识库更敏感图片和录音里包含的信息密度远高于文字。我们的做法是每一张图片、每一条语音转写都打上业务域标签检索时根据用户权限过滤标签。向量数据库加标量过滤字段是最常见的实现方式Milvus天然支持这种向量加属性的联合过滤。数据更新方面建议做成全量重建加增量更新的组合。全量重建适合第一次上线或数据结构调整时增量更新负责日常新文档、新图片入库。更新频率按业务需求定我们目前是文本库每天增量同步一次图片库每周重扫一次新增目录。5. 落地后的维护与下一步扩展5.1 别急着上大模型先梳理你的多模态素材从我们的经验来看推进多模态知识库最大的阻力往往不在技术而在素材盘点。很多团队把系统搭好了才发现自己的数据散落在不同的网盘、个人电脑、邮箱里压根没统一归档过。建议项目启动阶段花一周时间做素材盘点列出哪些内容形态最常用、最痛先只处理这几种不要一开始就追求全模态覆盖。我们第一个月只处理了产品截图和会议录音这两类知识几乎占了团队日常咨询的七成效果立竿见影。排版精美的PPT、存量视频、历史工单等内容是逐步补进去的。这个思路尤其适合预算和人力有限的团队。5.2 从问答到生成把知识库变成“生产力出口”知识库接入多模态后答案形式也可以摆脱纯文字。我们目前在生产环境跑通了两个“生成式”扩展第一个是自动生成复盘材料知识库综合团队周报、会议录音和项目文档输出结构化复盘报告第二个是自动给故障处理生成处理流程图知识库从历史处理记录中提取步骤再用模型把步骤转成流程图描述文本。这里用到的是“先理解、再重组、再输出”的能力本质上是RAG加生成模型的组合。知识库的价值不再停留在“告诉你有这个资料”而是“帮你把资料变成了能用的东西”。建议团队在走通问答稳定之后再往生成方向扩展毕竟问答稳定性都还没解决时谈生成用户只会觉得系统不够靠谱。5.3 小模型还是大模型够用就好最后聊一个我们在技术选型时反复纠结过的问题知识库底层模型要不要追求最强。有不少研究者提过一个观点知识检索这类任务考验的是数据密度和检索精确度不是模型参数规模。我们的实测也验证了这一点在召回和精排环节小模型配合好的策略完全能达到生产要求生成环节才需要大模型。一套组合拳下来Embedding用BGE-M3重排用BGE-Reranker视觉理解用Qwen2.5-VL的7B版本最终的答案生成阶段用在线大模型。这套组合的算力开销不大效果却超过了原来“一切交给大模型”的笨方案。降低生成模型的压力让检索环节多干活这才是知识库工程的正解。我个人这段做下来体会很深一开始迷信CLIP、迷信大模型觉得“多模态”就得靠高级模型硬扛后来被现实教育了一遍才明白工程上最稳的路径永远是“让图片变成清晰的文本再让文本进入成熟的检索体系”。多模态这件事不是模型炫技而是把资料整理成人能用、机器也能用的形态。建议你落地时也从最高频的那个场景切入别贪多先把一种模态打通再逐步扩展。等你把“找得到、看得懂”做扎实了自然会发现知识库变成了团队里那个随叫随到、能看能说的同事。