企业多模态知识库搭建实战：RAG、向量检索与部署调优

1. 为什么企业知识库必须走向多模态

过去几年，我帮不少企业搭过知识库，从最早的文件夹加全文检索，到后来的 Elasticsearch 做关键词匹配，再到现在的向量检索加 RAG。路径很清晰，但有个问题一直卡在那里：企业的知识资产，真的不只是文字。

一份设备维修手册里，除了操作步骤的文字说明，还有爆炸图、电路图、维修现场的照片和视频；一个产品研发项目里，除了 Word 和 PDF，还有 CAD 图纸、会议录屏、测试报告里的波形截图、客户反馈里的语音记录。传统知识库把这些东西拆得七零八落——文字进搜索系统，图片扔进附件库，视频干脆没人管。结果就是搜得到文档标题，但搜不到文档里的那张关键截图；搜得到一段文字描述，但没办法让系统理解“图中红圈标注的那个零件”到底指什么。

“可搜索”这个词，其实已经不能满足企业的真实需求了。搜索的本质是“你问我答、命中即走”，但它不理解上下文，不理解实体之间的关系，更没办法把一段零散的资料组织成一份可用的答案或报告。而“可理解、可生成”才是知识库该有的状态：系统能读懂一张图片里的图表含义，能听懂一段培训视频里讲的关键操作，能把散落在文档、表格、图片中的信息汇总成一段逻辑完整的方案，甚至直接生成一份合同草案、一个故障排查指引。

这就是多模态知识库的定位。它不是给文档库加一个图片预览功能，而是把文本、图像、音频、视频统一纳入知识抽取和理解流程，让企业知识真正变成一个可以被 AI 消化、重组、再输出的资产池。这篇文章我会把搭建思路、技术选型、数据处理的坑、模型部署的注意点，以及真实跑通的案例流程完整写出来，给正在做这块的同学一个可参考的路径。

2. 整体设计与技术选型思路

2.1 多模态知识库的核心架构分层

我习惯把多模态知识库分成五层来看：数据接入层、预处理层、知识抽取层、存储与索引层、应用服务层。很多人一上来就盯大模型选型，其实容易踩坑，真正的难点往往在前三层。

数据接入层解决的是“数据怎么进来”的问题。企业里的数据源很杂，有本地文件服务器上的 Office 文档，有 NAS 里的图片视频，有 OA/CRM 里的业务数据，有钉钉飞书里的聊天记录和会议纪要。这一层不需要炫技，稳定同步就行，推荐用成熟的同步工具或者写定时任务拉取，关键是记录好文件的元数据，比如来源、时间、归属部门、权限范围。

预处理层负责清洗。对于文本要做 OCR 纠错、格式统一、敏感信息脱敏；对于图片要做清晰度筛选、角度校正；对于视频要做抽帧、去重、关键片段提取。这一层最容易被低估，但它的质量直接决定后面的抽取效果。多模态数据的预处理不像纯文本那样干净，坏图、花屏视频、扫描歪斜的 PDF 到处都是。

知识抽取层是核心，要把非结构化数据变成结构化的“知识碎片”。文本部分走文档解析加实体抽取，图片部分走视觉模型做场景理解、OCR、图表解析，视频部分走抽帧加多模态理解。这一层的产出会是一批带类型标签的“知识片段”，比如“操作规程”“设备参数”“异常现象”“人员信息”等等。

存储与索引层要承担两类负载：一类是结构化数据的存储，比如知识片段之间的关系、标签、来源引用；另一类是向量索引，供语义检索使用。现在主流方案是选一个支持多模态数据的数据库，或者用传统数据库加独立的向量索引组件。

应用服务层就是对外提供的能力了——语义搜索、智能问答、报告生成、辅助决策。这块需要和大模型深度结合，通过 RAG 或者 Agent 方式组织知识流。

2.2 关键组件选型：模型、向量库、框架

先说模型。多模态知识库的主力模型至少需要三个能力：图文理解、文本向量化、文本生成。图文理解现在可选的开源方案已经很多，常见的多模态模型都能做视觉问答和图片内容描述，部署成本在可控范围内。文本向量化模型负责把文本片段转成向量，目前中文场景下推荐用中文本地化训练效果好的向量模型。文本生成模型负责最后的问答和报告生成，如果对数据隐私要求高，可以本地部署中小规模模型，再通过量化降低显存压力。

再说向量库。如果只是做 PoC，单机用轻量级方案没问题；如果知识规模到了百万级向量以上，建议直接上分布式向量数据库，支持索引分片和水平扩展。选型时我比较看重三点：是否支持混合检索（向量加关键词）、是否支持标量过滤（比如按部门、按时间范围过滤）、生态是否完整（有没有现成的 SDK）。

最后是框架。搭建多模态知识库不建议全部手撸，可以使用成熟的 RAG 框架做基础，再针对多模态场景做一些二次开发。这样省事，而且社区维护的文档解析器、向量库对接组件往往比自己写的更健壮。

2.3 为什么不能照搬纯文本 RAG 方案

很多人把多模态知识库理解为“PDF 解析后丢进 RAG 流程”，实际上这是个误区。纯文本 RAG 的流程是：切分、向量化、存库、检索、喂给大模型。但多模态数据光靠文本切分解决不了问题，一张图表的含义、一段视频里的操作手势、一份扫描 PDF 里混排的图文关系，都是独立于文本的信息维度。

我见过一个真实的失败案例：某制造企业把设备手册里的插图直接丢弃，只把文字部分做进知识库，结果一线维修人员在问答系统里问“液压系统压力异常的常见原因有哪些”时，系统只会列出文字条目，但无法结合原理图指出哪几个部件最可能失效。后来他们把插图接入多模态模型做理解，将图片的语义描述和文本知识一起存入向量库，效果立刻不一样了。

所以在设计时，要把多模态知识抽取做为一个独立环节，而不是事后补丁。视频需要抽帧再理解，图表需要专门解析，扫描文档需要 OCR 加版面分析。只有把“多模态内容”真正变成“可检索的知识片”，后续的检索和生成才有意义。

3. 数据接入与预处理实践

3.1 多模态数据的接入路径设计

数据接入最忌讳的是“什么都收，但什么都不理”。建议第一步先做数据盘点，按模态、数据源、更新频率、敏感级别打标。我常用的做法是列一张摸底表，把每个数据源的 ownership、格式、体量、更新方式、权限要求填清楚，再决定用哪种方式接入。

接入方式分三类：批式导入适用于历史数据迁移，用脚本或者 ETL 工具一次性处理；增量同步适用于日常新产生的内容，可以使用文件系统监听、消息队列触发或者定时轮询；接口对接适用于 OA、CRM、IM 这类系统，走 API 拉取或者 webhook 接收。企业里最常见的是“历史数据批处理 + 新增数据增量同步”的组合，这样既能快速填充知识库，又能保证内容新鲜度。

权限问题要提前想清楚。知识库如果不同步企业的人员权限，后续很容易出现敏感信息泄露。方案上可以在知识片段层级打权限标签，检索时通过用户身份做过滤。这块做在前期比后期补要容易得多。

3.2 文本类数据：OCR、版面分析与清洗

文本数据处理看起来最简单，实际上最琐碎。

PDF 和 Office 文档要区分处理。文本型 PDF 直接抽取文字；扫描型 PDF 必须走 OCR。现在开源的 OCR 工具识别中文印刷体效果已经很不错，但手写体、低分辨率扫描件仍然需要人工复核，或者接入更高精度的商用 OCR 接口。图片型 PDF 还要做版面分析，识别标题、正文、表格、图注，因为后续切分逻辑要依赖版面信息。

Word 文档的处理有个隐蔽的坑：格式样式混乱，比如标题不是用“标题1”“标题2”样式而是手动调字号，目录是纯文本不是自动目录。这会导致文档解析时抓不到结构。我的习惯是先做一步文档结构清理，把常见样式映射到统一模板，再走抽取流程。Excel 文件建议转成表格结构再入库，而不是按单元格零散存储。

清洗环节还要处理噪音。页眉页脚、水印、超链接、无意义符号统统要剔除。敏感信息替换要做好，身份证号、手机号、银行卡号这类数据要么脱敏要么过滤，视企业合规要求而定。

3.3 图片与视频：抽帧、去重与语义理解

图片数据比文本麻烦的地方在于信息密度不固定。同样一张图，有人物照、设备照、图表截图、文档扫描页，处理策略完全不同。

我有一个通用的四步处理流程：清晰度过滤、方向校正、内容分类、语义抽取。清晰度过滤直接删掉模糊图片，不然送去理解就是浪费算力；方向校正解决手机拍摄的歪斜照片，用图像旋转模型处理；内容分类判断这张图是什么类型——如果是纯文字截图就做 OCR，如果是图表就做图表解析，如果是场景照片就做目标识别和描述生成；最后一步才是真正的语义抽取，产出图片的理解文本。

视频处理稍微复杂一点。视频不能整段丢进模型，先按场景做抽帧。抽帧频率要看内容类型：培训课程 1~2 秒抽一帧就够了，操作演示类要更密一点，监控视频反而要稀疏。抽完帧后，相邻帧做相似度计算，去掉重复帧。然后对关键帧做多模态理解，生成语义描述。结合语音识别，把讲的内容和时间轴对齐，这样视频知识就有了“文本侧”和“视觉侧”两条语义线。

做这一步时我对团队的叮嘱永远是：不要指望一个模型解决所有图片和视频问题，不同内容类型用不同策略组合，效果会稳定得多。

4. 知识抽取与存储实现

4.1 文本切分策略：为什么不能按字符硬切

纯文本 RAG 里惯用的定长切分（每 500 字切一段，重叠 50 字）在知识库里效果其实一般，因为语义完整性没有保证。企业文档里一个操作规程可能跨好几页，硬切会把步骤拆得七零八落，检索时经常只命中其中一段。

更合理的切分策略是“结构优先，长度适配”。先按文档结构切：章、节、条、段、表格、图注。每个结构块都有相对完整的语义。如果结构块太长，再按段落或语义边界二次切开，同时保证知识片段之间保留关联关系。这里可以用 markdown 格式的标题层级辅助做结构划分，识别准确性比较高。

切分完还要做“父子片段”关联：父片段是章节级别，子片段是段落级别。检索命中子片段时，可以返回父片段的完整内容作为上下文，回答效果会好很多。

另外，有条件的话建议做一个简单的事前分类——这一段是什么类型：参数类、步骤类、原理类、案例类。不同类型在向量化时可以加不同的前缀提示，让检索匹配更精准。

4.2 向量化与混合检索的设计

向量化这个环节，很多人以为就是把文本扔进 embedding 模型拿到一个向量。实际有讲究：一是要分字段做向量，比如标题向量、正文向量、图片语义描述向量各自独立；二是向量模型要在目标领域微调或者至少做领域适配测试；三是中文企业文档里大量存在中英混排、专业缩写，通用向量模型往往表现不稳定，需要自己准备一些困难样本去测。

存储层面，我认为“向量 + 全文索引”的混合检索是最稳定的组合。向量解决语义相关问题，全文索引保证关键词精确命中。比如搜“设备型号 XYZ-2000 的维修记录”，关键型号必须精确匹配，纯向量检索可能会给出相似型号，这不是用户想要的。混合检索分两路召回，再做一个重排序，效果才是可用的。

重排序模型值得投入，它可以结合语义相关度、关键词命中程度、知识片段的时效性、权威性做综合打分。现阶段的开源重排序模型对中文支持已经不错，直接用就好。

知识图谱要不要做？很多文章会把知识图谱讲得很玄。我的建议是：如果企业内部实体关系复杂，比如人员、项目、设备、客户之间有多层关联，那值得做轻量级图谱，把实体抽取出来建边。如果知识库只是文档资料库，图谱的意义没那么大，强行做反而增加维护成本。

4.3 向量数据表的字段设计经验

设计向量存储的表结构时，我推荐把元数据字段做宽一些，后面过滤、权限控制都靠它。常用的字段包括：唯一ID、知识类型（文本/图片/视频/表格）、来源文件ID、所属部门、权限级别、创建时间、更新时间、标签数组、标题、正文原文、语义描述文本、向量字段。

权限控制字段必须在一开始就设计好。知识片段打上权限标签后，检索时把用户身份映射成权限集合，在向量检索阶段做标量过滤，这样既保证安全又不会大幅增加响应耗时。

这里给一个示例建表思路（伪代码方式）：

-- 知识片段表 CREATE TABLE knowledge_chunks ( id BIGINT PRIMARY KEY, source_file_id VARCHAR(64), chunk_type VARCHAR(16), -- TEXT / IMAGE / VIDEO / TABLE title TEXT, content TEXT, -- 原始内容或语义描述 dept VARCHAR(64), -- 所属部门 permission_level INT, -- 权限级别 tags JSON, created_at TIMESTAMP, updated_at TIMESTAMP, embedding VECTOR(1024) -- 向量字段 ); -- 创建向量索引 CREATE INDEX idx_knowledge_embedding ON knowledge_chunks USING HNSW (embedding vector_cosine_ops);

如果你使用的是向量数据库产品，直接在控制台里建 Collection 和对应的字段映射就行，原理类似。

5. RAG 与生成链路搭建

5.1 检索增强生成的基础流程搭建

搭建检索增强生成的链路，本质上是把“检索”和“生成”串成一个闭环。

流程是这样的：用户提问 → 改写和意图理解 → 多路检索 → 重排序 → 上下文组装 → 大模型生成 → 返回引用来源。

很多人会忽略第一步“改写和意图理解”。用户的问题往往很短，比如“那个故障怎么处理”，如果不补充上下文，检索效果很差。我的做法是维护一个对话记忆模块，先判断这个问题是否需要结合历史对话，如果需要的话，系统自动叠加上文信息生成一个完整的检索 query，再去做多路检索。

多路检索分三路并行：一路是向量语义检索，一路是全文关键词检索，还有一路是元数据过滤后的精确检索（比如按设备型号、文档编号查）。三路结果合并，去重，再送入重排序模型打分，取 Top-K 个知识片段。

上下文组装要控制长度，否则大模型容易“迷失在长上下文中”。一个实用的做法是把知识片段按照重排序分数倒序排好，截断到模型能接受的长度以内，并且明确标注每段知识的来源文件名、页码、时间。这样大模型生成时能准确引用来源，用户在阅读时也方便溯源。

5.2 多模态问答的上下文组装技巧

多模态问答和纯文本问答最大的不同是：检索结果里会混着图片和视频片段。有两种组装策略：一是把图片的语义描述文本直接拼进上下文，这种方式对大模型兼容性最好，推荐优先使用；二是把图片链接或视频关键帧地址作为特殊标记传入，适用于支持视觉输入的多模态大模型，效果好但有额外的部署要求，需要模型本身具备视觉理解能力。

我在实际项目里是两种策略混用：默认流程走第一种，保证回答稳定性；当用户明确问“这张图说明了什么”这类涉及具体视觉内容的问题时，切换到第二种，把图像原图直接传给多模态模型。要控制好切换条件，避免频繁切换到多模态模型导致成本上升。

引用来源的呈现不能省。知识库系统如果不给用户提供出处，信任度会大打折扣。每个回答后面附上“参考来源”，列出命中的文档名、页码、时间戳。甚至可以在前端做一个“点击跳转到原文对应位置”的交互，体验会好很多。

5.3 从问答走向生成：自动报告与方案输出的实现

问答只是知识库的初级形态，真要给企业带来价值，还得做自动生成。我做过一个售后知识库项目，用户可以输入故障现象，系统直接生成一份包含“故障分析、排查步骤、所需工具、备件清单”的维修工单草案。这就是把 RAG 从“回答问题”升级到“组织知识并产出文档”。

实现的额外工作在于输出结构约束。生成时在提示词里明确指定输出模板的章节结构，模型按照模板填入知识片段里的关键信息。为了稳定输出格式，我建议用 output format 约束或者直接写一个结构化输出的解析器，把生成结果再解析成 JSON，前端按模板渲染。

自动生成不能替代人工审核。我在系统里加了一个“人工确认”节点，AI 生成的内容在未确认前标记为“草稿”，只有工程师确认后才会变成正式工单。这个设计看起来多了一步流程，但实际上省了很多返工——AI 偶尔会脑补出错误内容，一个人工确认机制的性价比非常高。

增强生成的稳定性还有一个技巧：对知识片段做“上下文精简”。大段的原文直接塞进提示词容易模糊重点，先让摘要模型把检索结果压缩成一个结构化的要点列表，再让回答模型基于要点生成完整内容。两层模型配合，产出质量会明显提升，响应时间也不会太差。

6. 部署落地与调优实录

6.1 本地化部署的硬件选型与模型量化

企业知识库的数据往往涉及内部资料，不适合全部上传到公网服务，本地化部署通常是刚需。很多人看到“本地化”就紧张，其实现在门槛已经降得很低了：一张 24GB 显存的消费级显卡就能同时跑起向量模型、重排序模型和一个 7B~14B 的量化生成模型，硬件成本大概相当于一台中高端工作站。

模型量化是部署的关键环节。生成模型用 INT4 或 INT8 量化，显存占用能降为原来的四分之一到三分之一，推理速度也更快。实际测试下来，14B 模型量化后生成质量相对于 FP16 损失很小，但部署成本大幅下降。

内存方面，建议至少 64GB 起步。知识库的索引和数据都要常驻内存，加上模型推理的临时显存交换，内存太小会发生频繁换页，导致接口响应忽快忽慢。SSD 要在 1TB 以上，因为视频和图片文件的存储空间消耗远大于纯文本。

推理框架方面，推荐用兼容性比较好的推理引擎，例如 vLLM 或 TensorRT-LLM。用 vLLM 的时候吞吞吐吐指数是有上限的，在一些高并发场景下需要配好显存池。

6.2 知识更新、索引重建与增量同步策略

知识库最怕的不是搭不起来，而是搭完就“死”了——内容不更新，索引不重建，过了三个月就没人用了。

增量同步要设计好。文件上传后立刻触发解析和入库，这个流程可以做成异步任务队列：上传 → 解析 → 抽取 → 向量化 → 写入存储。每一步都有状态记录，失败可以重试。更新周期按数据源区分，有的文档每日全量同步，有的实时增量。

向量索引的重建有全量重建和增量追加两种。全量重建适合大规模 schema 调整，或者换向量模型的时候；日常更新直接用增量追加，维护好文档和知识片段的映射关系。特别注意：当变更文档对应的向量已经存在时，要先把旧向量删除再写入新向量，否则会出现检索到“旧版本内容”的问题。

我是用监控面板来跟踪这些指标的，包括每日新增知识片段数、检索失败率、模型推理耗时、向量索引大小。做得好的知识库，一定是可以被量化观察的。

6.3 检索质量调优：从召回、排序到提示词

搭建好系统只是第一步，真正的功夫在调优。我做过一个模拟企业知识库的测试集，300 条真实业务问题，每条问题标注了理想答案的知识片段集合。每次调优后跑一遍测试集，对比命中率和排名位置，变化非常直观。

召回调优有一个常用技巧：多路召回时不要只依赖向量相似度，关键词权重也很重要。比如设备型号“XYZ-2000”，嵌入模型对这类字符串的语义把握不可靠，但全文索引命中一次就够准了。可以让混合检索里关键词匹配的权重调高一点，或者在向量召回之外固定跑一路“型号精确匹配”。

排序调优比较容易忽略的是“时间因子”。技术手册更新后，旧版本内容应该排后面。在重排序打分公式里加上基于更新时间的衰减系数，正确答案的排名会稳定很多。

提示词调优也很关键。同一个模型，提示词写得清不清楚，回答质量的差距很大。经验是：明确角色、明确输出格式、强调“没有把握时不要编造”并用知识片段内容为准。多测试几轮，找到性价比最高的写法就行。

6.4 踩过的坑和优化记录

第一个坑：OCR 直接用了通用模型，结果专业文档里的表格和公式识别错乱。后来换了版面分析加表格识别组合方案，正确率才上来。这块的经验是：扫描件多的场景，版面分析不是一个可选项，是必须项。

第二个坑：把生成模型的上下文长度设得过高。一开始图省事，把所有检索结果都塞进上下文，结果模型回答的内容发散，还频繁引用无关片段。后来限制了上下文长度，增加摘要中间层，输出稳定了很多。

第三个坑：向量索引参数没有按数据规模调整。数据量少问题不大，但到了几十万向量以后，召回延迟明显上升。重新调整了索引参数之后，检索耗时就稳定在可接受范围了。这里想多说一句：参数要按实际数据规模来设计，不能靠“默认配置打天下”。

7. 项目实战：一套设备维修知识库的搭建全记录

7.1 项目背景与目标拆解

去年我带团队给一家装备制造企业搭了一套多模态知识库。客户的原始资料包括三类：设备技术手册（PDF，部分为扫描版，图文混排）、历年维修工单（Word 和 Excel，含故障描述和处置过程）、维修现场照片和短视频（由工程师用手机拍摄，质量参差不齐，模糊和反光的照片不少）。

业务目标是让维修人员和技术支持人员通过自然语言提问，快速获得故障排查建议，并能追溯到原始文档和照片。要求数据不出内网。

拆解下来，核心交付物是三项：一套多模态知识抽取流水线、一个支持混合检索的知识库后台、一个对话式问答前端（支持输入文字、输出带图片引用的回答）。

7.2 数据梳理与预处理实施细节

先做数据摸底。技术手册约 400 份，合计 12 万页，扫描版占 30%；维修工单共 6 年，23000 多条记录，Excel 格式为主；现场照片 8000 多张、短视频 200 多个，分散在工程师个人电脑和公司 NAS 上。

摸底完成后，按之前说的三路接入：历史 PDF 走批处理脚本，Excel 工单走 ETL 管道，新增照片和视频落地监听到 NAS 目录的增量同步。

预处理环节花了两周。扫描版 PDF 全部走 OCR 加版面分析，表和图的识别准确率提升明显。视频先抽帧，再用相似度去掉重复画面，最后对关键帧跑目标检测，把“设备型号”“损坏部位”这类实体识别出来。

中间遇到一个很麻烦的问题：工程师手机拍的照片里有大量 EXIF 信息，其中包含 GPS 位置和拍摄时间。因为是在工厂内拍摄，这些信息涉及现场位置暴露风险。后来写脚本统一剥离 EXIF 再入库，这条提醒大家做知识库时一定要考虑。

7.3 检索问答效果与调优过程

第一版系统上线后问题不少。一是“维修工单”类知识因为历史写法不规范，实体抽取做得不好；二是现场照片的描述生成质量一般，直接导致检索到照片时，上下文里只有一句很泛的描述，回答帮不上忙。

针对第一点，我们在抽取流程里增加了工单的规则模板解析：先按工单的标准字段做结构化，再来做向量化。针对第二点，为照片理解单独微调了一个小的图像描述模型，让它更聚焦在设备外观、损伤程度、操作位置这些细节上，而不是泛泛地描述“一个工人正在检修设备”。

调优后的对比很直接：内部测试集的命中率从 KG 级的准确率升到了接近 86%。维修人员实测反馈，原来查一本手册要找半天，现在直接提问就能定位到具体章节和对应图片，效率提升非常明显。

这个项目做完后我的最大体会是：多模态知识库能不能落地，取决于对“企业真实数据有多脏”的认知。把数据摸清楚、流程做扎实，比选多牛的模型重要得多。

8. 搭建过程中的高频问题与排查指南

8.1 常见报错及解决方案速查表

8.2 检索效果不佳的排查思路

先确认是不是“数据进库”这步出了问题。随机挑 20 个知识片段，直接在数据库里搜它们的原文，如果搜不到，大概率是解析入库流程有 bug；如果搜得到但回答时没用上，那就是检索逻辑的问题。

检索链路逐段排查。先看召回：单独调用向量检索，看 Top-20 结果里有没有正确答案；如果有，问题在重排序；如果没有，问题在查询改写或向量模型。再把重排序后的 Top-5 打印出来人工检查，确认是否合理。最后看上下文组装：把给模型的完整上下文保存下来，检查是否太长、是否顺序混乱、是否把不相关内容填进去了。

这里要特别提醒：生成模型的“幻觉”不要都归到检索上。很多时候检索完全正确，但模型在生成时把知识片段里的信息露掉，自己脑补了一段。排查时把“纯检索指标”和“端到端回答质量”分开评估，否则永远找不到真正的堵点。

8.3 部署资源与性能瓶颈的优化记录

优化性能时我会看两个指标：端到端响应时间和知识入库吞吐量。响应时间主要受模型推理影响。实测下来，量化后的 7B 模型生成 300 字回答约需 4~8 秒（单卡），14B 模型要视具体硬件情况再翻倍。如果要求秒开，只能考虑蒸馏小模型，或者做流式输出让用户先看到回答的第一批字。

入库吞吐量的瓶颈通常在视频抽帧和图片理解。视频抽帧是很吃 CPU 的任务，可以扩容；图片理解是 GPU 密集任务，建议做成批处理，晚高峰时离线跑。不要和在线问答抢 GPU，推荐把抽取队列和在线推理分别部署。

大文件处理也不能忽略。几十页的 PDF 解析其实还好，但几个 GB 的视频文件抽帧会占满内存和临时盘。可以在任务调度器里限制视频任务的文件大小上限，超过部分先转码或切分，不要原地处理过大的文件。

9. 踩过多次坑之后的实操心得

多模态知识库看起来是个技术项目，做到最后会发现是个“数据工程 + 系统工程”的混合项目。模型选型和框架搭建只占了三成精力，剩下的工作量全都在数据治理、流程设计和踩坑修复上。

我觉得最重要的一条经验是：先做小规模的端到端试点，不要一口气全量铺开。选一个业务场景、一批真实数据，把从数据接入、知识抽取到问答生成的链路完整跑通，再决定是否全面推广。试点的时候把效果量化出来，比如检索命中率、回答引用准确率、用户使用频次，这些数据比任何技术方案都有说服力。

第二条经验是：不要让 AI 直接面对用户输出“不确定”的答案。知识库系统里加一个人工审核或反馈机制，用户可以对 AI 的回答点“有帮助/没帮助”，这些反馈对后续调优非常宝贵。不采集反馈的多模态知识库，基本就是一次性项目。

第三条经验是：知识库的更新机制比搭建本身更重要。我见过太多系统刚上线时很好用，三个月后内容过期了，用户问新问题答不上来，慢慢就没人用了。增量同步、版本管理、过期内容淘汰，这些机制在一开始就要设计好，因为后面补的代价很大。

最后再分享一个具体而微的技巧：给知识片段生成描述时，把“来源文件名 + 章节 + 页码”一起拼进描述文本。这样不光是检索时有额外信号，大模型生成时也会自动带上这些信息，用户看到的回答自带出处，信任度会高非常非常多。这个小改动几乎不需要额外成本，收益却很直观。

如果你在搭建过程中遇到的坑和我写的不一样，只要大方向没跑偏，基本都是可以解决的。先跑通一条最小的真实链路，再逐步加能力，这条路我走过很多次，确实是最稳的。