数据湖和数据仓库最大的区别就是“什么都能放”图片、PDF、日志、音视频、表格、半结构化 JSON。但能放不代表能用。过去很多团队把多模态原始文件堆进对象存储真正要检索和问答时还是靠文件名、标签和关键词结果大量数据一直沉睡。把数据湖里的多模态数据做向量化再交给 AI 通过语义检索和 RAG 来“理解”是目前比较务实的一条落地路线。这篇文章适合正在做数据平台、AI 应用开发或者想把本地数据湖变成可检索知识库的工程师。最值得关注的不是“怎么跑通向量化”而是不同模态的数据分别怎么处理、入库之后怎么查、效果怎么判断。1. 数据湖里的多模态数据为什么一直“沉睡”1.1 数据湖里放的是什么数据湖的典型形态是对象存储或 HDFS 上加一层表结构再辅以消息队列、离线任务和 API 接口。里面既有格式化数据也有大量非结构化、半结构化文件。常见的多模态数据包括文本合同、说明文档、工单、日志、Json 里的 message 字段。图片产品图、监控截图、扫描件、设计稿。音频客服录音、会议录音、语音笔记。视频教学视频、监控视频、宣传素材。混合文档PDF、Word、PPT里面同时有文字、表格和图片。这些文件进入数据湖时通常只记录了对象路径、大小、上传时间这类元数据。真正的内容语义并没人抽取过。1.2 传统检索为什么接不住多模态传统做法是给文件打标签、建索引靠关键词匹配。问题是一张图片里的产品型号、场景、人物用文件名根本表达不全。PDF 里的扫描图不做 OCR 的话关键词搜不到。一段音频的核心意思可能和标题完全无关。用户提问的表达方式和文档里的原文可能完全不一样。关键词系统擅长“字面命中”不擅长“语义命中”。用户问“上季度退货率为什么升高”如果数据湖里只有一份叫“客诉统计2024Q3.xlsx”的文件传统搜索也能靠“退货”命中。但如果是“用户最近对物流时效的抱怨集中在哪个环节”传统搜索就几乎无能为力。1.3 向量化让 AI 可以“读”这些数据了向量化做的事情是把图片、文本、音频片段、视频抽帧等输入转换成一组固定长度的数字也就是 embedding 向量。语义相近的内容向量距离也更近。有了向量之后AI 应用就可以对一句话做向量去湖里找回最相似的图片、文档、音频片段。把召回片段作为上下文交给大模型生成答案。完成跨模态检索比如用文字描述找到对应图片用图片找到相关文档。这个过程的本质是给原本无法被结构化查询的多模态数据补了一层“语义索引”。数据还是那些数据但 AI 有办法定位到它、读取它、理解它。2. 向量化改造不等于把所有文件变成一个向量2.1 先按数据类型拆处理链路很多团队最开始的误区是想着“找个多模态模型把所有文件统一转成一个向量”。实际落地时不同模态的处理链路差别很大。以我自己的项目为例通常拆成四条线文本和文档拆段落、清洗、直接走文本 embedding。图片判断是需要“图像语义 embedding”还是需要“OCR 抽取文字后再 embedding”。产品图适合前者截图和扫描件通常需要 OCR。音频先做语音转写得到文字稿再走文本 embedding。必要时才需要对音频本身做声纹或音频事件向量。视频先抽帧、抽字幕、提取音轨转写把视觉部分和语音部分分别处理最终统一成文本和图像向量。这条链路看起来麻烦但好处是每一步都可调试、可替换。某一类文件效果不好可以单独调整不影响整体流程。2.2 多模态 embedding 模型的选型要点选模型时不是参数越大越好。多模态向量化的常见选择包括 CLIP 类模型、SigLIP/SigLIP2 这类图像文本对齐模型以及中文本地化做得比较好的 embedding 模型。看几个关键点输入分辨率是否支持你实际图片的尺寸。是否支持中英文混合描述。embedding 输出维度是多少向量库是否兼容。模型是否容易在目标硬件上加载CPU、GPU、ARM64 环境分别是什么表现。是否需要量化量化后准确率下降多少。我看到一些热搜里提到“siglip2向量化”和“部署7b向量化模型”。这里要说清楚向量化任务选 7B 级模型通常很慢收益不一定明显。embedding 模型一般是 0.1B 到 0.5B 量级真正需要 7B 的通常是文本生成模型两者职责不同。如果你只是给数据湖里的文档和图片建语义索引优先选轻量 embedding 模型而不是直接上生成式大模型。2.3 统一向量空间是跨模态理解的前提跨模态检索的关键是让文本和图片被编码到同一个向量空间。比如 CLIP 类模型训练时就是让“文字描述”和“对应图片”的向量靠近这样用户输入一句话就能在图片向量里做最近邻查找。如果项目里既有中文文本又有图片建议用同一个多模态模型来编码或者明确不同模型之间的对齐关系。不要出现“文本用一个模型、图片用另一个模型、最后维度还对不齐”的情况否则相似度计算没有意义。实际踩过的坑是文本用了文本 embedding 模型图片用了 CLIP两套向量维度不同检索时才发现没法直接算距离。最后只能重新统一模型重跑全量数据。所以项目启动阶段先确认好统一向量空间比先调参重要。3. 跑通最小闭环环境、依赖和单条样本3.1 建议的硬件和软件组合先别追求全量数据一次跑完先搭最小闭环。硬件方面纯文本 embedding几千个文件普通 8 核 16G 内存的 CPU 机器可以跑就是慢一点。图片和视频抽帧建议有一张 8G 显存以上显卡能明显加速。如果只有 CPU可以选择量化后的小模型把 batch size 调小。软件方面常见组合Python 3.9 以上。PyTorch 或 ONNX Runtime。transformers 或 sentence-transformers。向量数据库Chroma、Qdrant、Milvus、pgvector 按规模选。可选 LangChain4j、Spring AI 这类 Java 侧框架方便和现有服务整合。注意这里不要一上来就开最大并发先用一条样例确认输入、输出和日志都正常。3.2 依赖安装顺序依赖的安装顺序我一般按这个顺序走先装 Python 基础环境。再装深度学习框架确认 CPU 或 GPU 版本正确。然后装向量化库、向量数据库客户端。最后装项目自身的工具库比如文件解析库。为什么要这个顺序因为深度学习框架和系统 CUDA、CPU 指令集的关系最复杂。如果先装了一堆业务库再回头换 torch 版本很容易出现依赖冲突排起来很费时间。国产信创环境要特别注意如果系统是麒麟、硬件是 ARM64很多预编译 wheel 不一定直接可用。先确认 torch、onnxruntime、numpy 是否有对应 ARM64 版本再确认向量数据库服务端是否支持该架构。这部分不是模型能力问题而是编译链问题。3.3 用一条样本验证 embedding 输出跑全量之前先写一个最小验证脚本。以文本 embedding 举例流程类似from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-small-zh-v1.5) text 用户反馈物流时效太慢希望平台改进配送体验 vec model.encode(text) print(vec.shape) print(vec[:8])注意这里只是示例实际模型名和版本要以你的环境能正常加载为准。验证输出时重点看三件事向量维度是否固定。同一句话多次编码结果是否稳定。相关句子的相似度是否高于不相关句子。如果相关句子相似度都不高先检查是不是模型不支持中文或者输入被截断。图片验证同理取一张样例图用多模态模型编码再用一句与之匹配的文字查询看能不能在图片集合里召回它。3.4 向量入库前的检查清单单条验证通过后不要急着全量入库。先检查每条记录是否保留了原始文件路径和数据湖里的唯一标识。是否补齐了业务元数据如时间、来源、部门、文件类型。是否记录向量化模型名称和版本方便以后模型升级后重跑。是否有主键策略避免重复入库。相似度度量方式是否统一是余弦、欧氏还是内积。这些信息后面排查问题非常重要。没有业务元数据向量检索只能告诉你“像”不能告诉你“能不能用”。4. 从单条到全量批量处理数据湖文件4.1 任务队列和文件枚举全量处理的第一步是枚举数据湖目录。这里不要把“扫描文件”和“向量化”写在一个循环里。更稳妥的做法是扫描数据湖生成待处理任务列表。任务列表按目录、文件类型、优先级切分。分批消费每批结束后记录处理进度。失败任务进入重试队列。任务列表字段至少包含文件路径、文件大小、修改时间、文件类型、目标向量库 collection、处理状态、重试次数、错误信息。如果数据量达到几十万级建议把任务状态放到数据库或消息队列里不要放在进程内存里。进程一重启内存里的队列就没了断点续跑根本无从谈起。4.2 图片、文档、音视频各自的处理流程不同文件类型处理细节不一样。图片类的流程读取图片检查格式和分辨率。小图直接编码超大图先缩放或切片。如果图片里文字多先 OCR把识别文本和图像 embedding 一起入库。记录图片的宽高、主色调等元数据方便筛选。文档类的流程按段落分块保留章节标题和页号。每块文本独立 embedding。表格单独提取转成 Markdown 或 JSON 文本后再 embedding。文档里的插图可以用图像模型编码与文档 ID 关联。音频视频类的流程音频先转写视频先抽帧和抽字幕。转写文本按说话人、时间戳切片。关键帧图片做图像 embedding。视频原始文件不直接向量化而是向量化“抽出来的内容”。这样做的原因是生成模型和检索引擎对长内容的处理能力有限。切块既能控制向量维度又能提高检索精度。4.3 批次、并发和资源控制批量处理最容易出问题的是并发失控。模型推理、OCR、文件下载都消耗资源并发一高内存和显存马上爆。我给一个保守的起步配置文本 embeddingbatch size 从 8 开始。图片编码batch size 从 4 开始。OCR进程数先设为 1后续看 CPU 占用再加。整体并行数小机器 2 到 4大机器 8 到 16。判断标准不是“没报错”而是观察 CPU、内存、显存的占用是否稳定任务处理速度是否随并发增加而线性提升。如果并发加到 8 之后速度不增反降说明已经到瓶颈了调回去。低配机器不是不能跑但要把分辨率、批量数和并发数降下来。先用小样本跑通再逐步加量。4.4 失败重试和断点续跑批量任务一定会遇到失败。常见失败包括文件损坏、编码异常。网络超时、下载失败。模型推理偶发 OOM。向量库写入冲突。处理策略是单条失败先记录错误不阻塞整批任务。重试 2 到 3 次仍然失败就进入 dead letter后续人工或脚本处理。每处理完一个任务把状态更新到任务表。这样即使中途停了重新启动后可以从上次位置继续。我通常会给每个任务加一个“处理时间”字段这样如果某个文件每次处理都要几十秒可以单独排查是不是文件过大或格式有问题。5. 向量库设计入库容易查得准才难5.1 向量库选型对比不同规模的场景选型差别很大。向量库适合规模部署方式适用阶段Chroma万级到十万级嵌入式进程内原型验证、个人项目pgvector十万到百万级依赖 PostgreSQL已有数据库体系想减少组件Qdrant百万级以上独立服务生产级检索、高并发Milvus千万级以上独立服务集群大规模数据湖、企业级平台选择标准不是“哪个最新”而是几个问题现有技术栈是什么数据量级多少查询并发多高团队能不能维护独立服务。如果只是做验证Chroma 够用如果要把数据湖整体做成知识库建议从 Qdrant 或 Milvus 起步。5.2 collection、分区和元数据字段向量库里的 collection可以理解为表和业务域的边界。比如data_lake_document_v1文档向量。data_lake_image_v1图片向量。data_lake_audio_slice_v1音频转写切片。版本号建议放在 collection 名称里。这样模型升级后可以新建新版本 collection保留旧的查询路径不用停机重导。每条记录除了向量还要包含id与源文件唯一标识一致。source_path数据湖中的原始路径。file_type文件类型。biz_meta业务元数据如部门、项目、时间。chunk_index文本切片序号。model_version向量化模型版本。有了这些字段才能在查询时加过滤条件。例如“只看 2024 年合同类型的文档”不需要对所有向量做全量扫描。5.3 相似度度量和 topK常见相似度度量有三种余弦相似度最常用对向量长度不敏感适合文本。内积适合模型归一化后的向量公式简单性能好。欧氏距离数值越小越相似适合某些图向量场景。落地时先看模型训练时用的是什么度量。CLIP 类模型通常使用余弦相似度文本 embedding 模型也常用余弦。设置向量索引参数时必须和实际查询方式一致否则返回结果可能乱。topK 的取值我一般从 5 开始。查询场景如果只是给答案找依据topK 3 到 5 够了如果要做“相似推荐”会取 10 到 20。取回的候选多不代表效果好还要看排序和过滤。5.4 混合检索关键词加向量再加元数据过滤实际生产环境里纯向量检索不一定最好。常见做法是混合检索对查询做关键词召回保证精确的人名、编号、型号能命中。对查询做向量召回保证语义相似的内容能命中。两路结果合并再用元数据过滤和重排。典型查询是“找出 2025 年 3 月物流投诉里和‘配送慢’相关的录音转写”。这里“2025 年 3 月”靠元数据过滤“物流投诉”靠关键词或分类字段“配送慢”靠向量语义。任何单一手段都很难同时满足三个条件组合起来才稳定。6. 让 AI 真正“理解”数据语义检索和 RAG 问答6.1 语义检索最小实现向量入库完成后查询侧先实现一个最小接口用户传入一句话返回最相似的若干条记录。流程是用同一个 embedding 模型编码用户查询。查询向量库加上元数据过滤。返回候选记录的文本、图片路径、来源文档和时间。在前端或接口里展示这些候选内容。这个接口的价值是让业务团队先能看到“东西被找到了”。比如输入“售后流程里有没有提到换货时效”返回对应的合同条款、客服手册片段、培训视频转写片段这就已经比关键词搜索好用。6.2 RAG 问答的链路和上下文组装检索做好之后再做问答就相对简单。RAG 的基本链路是用户提问。向量检索召回候选片段。把候选片段拼接成上下文。把上下文和提问一起发给大模型。大模型基于上下文生成回答并附上引用来源。关键在上下文组装。不要把所有候选片段全塞给模型因为模型上下文有长度限制而且噪声越多回答越容易跑偏。我的做法是先按相似度排序。再按文档来源去重。每个来源最多保留 2 到 3 个切片。总长度控制在模型上下文的一半以内。如果使用 Java 技术栈可以关注 LangChain4j 和 Spring AI 这类框架它们对本地向量模型、本地大模型的接入有现成封装。但要注意框架解决的是链路问题不解决模型质量问题和数据质量问题。6.3 多模态查询场景怎么处理多模态数据不是只能做纯文本问答可以分几种场景。场景一用文字找图片。用户描述“一张包含工厂流水线和蓝色安全帽的现场照片”系统用文本编码去找图片向量返回图片。场景二用图片找文档。用户上传一张产品图系统用图像编码找到关联的产品说明书、检测报告。场景三音频和视频内容问答。先把音视频转写成文字做切片向量化用户提问时在转写切片里检索返回视频片段时间戳。场景四让多模态大模型直接理解召回的图片或视频帧。做法是检索到图片路径后把图片传给一个支持图像输入的大模型由它生成描述或回答问题。这时候检索保证“找到对的图片”多模态大模型保证“看懂图片内容”两者是配合关系。6.4 给业务方看什么结果才算落地很多项目停留在“能跑通 Demo”但没有真正被业务使用。判断落地有几个标准业务人员能用自然语言提问不需要学 SQL 或关键词规则。返回结果里有原文引用能跳转到数据湖原始文件。对同一类问题多次回答的结果基本稳定。有权限控制不同角色只能访问对应范围的文档和图片。有日志记录知道用户查了什么、结果是什么、效果如何。如果只有检索结果没有溯源和权限业务方很难放心使用。这也是为什么前面反复强调要有 source_path、biz_meta、collection 版本这些字段。7. 效果评估和常见坑位排查7.1 怎么判断向量化效果好不好向量化不能只靠“看起来像”。我建议用一批测试问题做评估。比如准备 50 个真实业务问题每个问题标记出正确答案对应的文档 ID。系统召回结果后看三类指标召回率正确答案是否出现在 topK 里。排序质量正确答案是否排在前列。可用性业务人员看结果时是否能直接判断这个结果对还是不对。如果召回率不高先检查分块粒度。分块太大语义被稀释分块太小上下文不完整。文本 200 到 500 字一个块是比较常见的起点但也要具体看文档类型。7.2 性能看哪些指标性能评估需要分开看“离线向量化”和“在线查询”两个阶段。离线阶段关注单文件平均处理耗时。每小时处理文件数。失败率和重试比例。资源占用峰值。在线查询阶段关注单次查询延迟常见目标在几百毫秒到 2 秒之间取决于数据量和索引。并发查询时的 P99 延迟。索引构建和增量更新延迟。如果查询很慢不要第一时间怪向量库。先确认向量索引是否真的创建过滤字段是否走了索引查询语句是否在扫描全量集合。7.3 优先排查顺序输入、依赖、资源、参数、工具遇到问题我按这个顺序排查先看输入。文件格式、编码、路径、文件大小是否正常是否读取时截断了。再看依赖。torch、transformers、onnxruntime 版本是否兼容模型是否下载完整。再看资源。CPU 是否打满、内存是否不够、显存是否溢出、磁盘是否写满。再看参数。batch size 是否过大、并发是否过高、超时时间是否过短、向量维度是否匹配。最后看工具本身。向量库版本、模型版本、框架封装是否有已知限制。很多问题表面上是“向量化失败”实际是文件权限不对或者路径里有特殊字符。先看日志和输入别急着改模型。注意任务卡住时先看资源占用和输出目录再决定是不是要调并发或重试。7.4 什么时候不该上向量化最后说边界。不是所有数据都适合向量化。如果数据本身是结构化表格有明确的维度、指标和唯一键直接走 SQL 聚合更快更准。比如“各区域销售额对比”不需要向量。如果查询都是精确匹配比如订单号、身份证号、设备 ID关键词或数据库索引就够了向量化反而增加延迟和成本。如果多模态文件本身就是临时缓存、测试数据、重复备份向量化只会放大存储和计算成本。我见过不少项目为了造“AI 知识库”把数据湖里所有文件无差别向量化结果大量无用数据占满索引查询质量反而下降。合理做法是先评估数据价值按业务主题分批次向量化优先处理高价值、高频查询的数据域。真正常用的链路是数据湖治理做支撑按业务域圈定范围做分类、分块、元数据补齐再向量化入库最后通过语义检索和 RAG 提供能力。这样即使模型以后升级也只是重跑对应 collection不会动到整个数据湖。如果只是学习验证默认配置加一个 10 万级文件子集足够跑通完整链路。如果要长期生产使用日志、输出目录、任务队列、权限和模型版本管理都要在设计阶段提前想好。先把单条链路跑稳再逐步扩大范围会比一次性全量清洗稳妥很多。