RAG里向量数据库到底存什么？只存文本还是也能存图片？

图片得走多模态embedding，把图表单独抽出来向量化存进去，不然纯文本检索肯定瞎。

图表不处理等于白搭，建议试试CLIP那类模型，图文一起编码，查询时直接匹配。

图片这块确实容易忽略，我之前也踩过坑。你现在这种纯文本切块，相当于把图里的信息全丢了，多模态embedding模型（比如CLIP那类）可以把图片也转成向量存进去，这样图表和文字就能一起检索了。不过得注意，PDF里的图得先抽出来单独处理，不能直接整个页面丢进去，不然位置信息会很乱。另外要是担心多模态模型成本高，也可以先给图片生成一段描述文字再存，但效果肯定不如直接存图向量好。

图片得走多模态embedding，或者单独提取图表描述文本存进去，不然视觉信息就彻底丢了。

我之前也踩过这坑，后来把图表转成文字摘要和向量一起存，效果立竿见影。

图片得单独走多模态embedding，或者用视觉模型抽描述文本再存，不然柱状图趋势真没法查。

光存文本确实漏得厉害，图表信息得靠多模态模型转成文字描述再入向量库，不然等于瞎了一半。

我之前也踩过这个坑，只处理文本确实会漏掉图表信息。现在主流做法是给图片单独生成多模态embedding，比如用CLIP这类模型，然后和文本向量一起存进Milvus，查询时再加个类型过滤。不过PDF里的图得先抽出来，可以用paddleocr或pdfplumber试试，效果还行。另外柱状图趋势这种问题，光靠向量检索可能不够，还得配合结构化描述，比如把图表标题、坐标轴标签也存进去，不然语义匹配容易偏。

图片得走多模态embedding，或者先把图表转成文字描述再入库，不然纯文本检索肯定抓瞎。

试试把图片用视觉模型抽成结构化文本，跟正文一起切块存，效果比直接丢图片好使。

说实话你这问题我当初也踩过坑，光存文本确实只能答文字相关的内容。图片得单独走多模态embedding模型，把图表转成向量跟文本向量放同一个collection里，查询时才能一起召回。不过Milvus本身不解析图片，你得先用OCR或者视觉模型把图表里的关键信息抽出来，再跟文本块关联存储。我最近做法是图表生成描述文本后跟原始图片路径一起存，效果比纯丢图片向量好不少。

巧了，我上个月也踩过这个坑。图片不是不能存，但得走多模态embedding模型（比如CLIP那种），把图表转成向量跟文本一起塞进去，不然纯文本检索肯定答非所问。不过就算存了，PDF里图表的位置信息也容易丢，最好是解析时把图表单独截出来，跟它附近的文字绑定成一个chunk，这样查“柱状图趋势”才能同时召回图片和上下文。你用的什么解析库？很多工具其实能抽图，但默认没开。

图表得走多模态embedding，或者单独抽成文本描述存进去，不然光靠文字向量确实答不了图。

图片也得转成向量存进去，你试试用CLIP那类模型，把图和文字映射到同一空间再查。

图里的信息确实得单独处理，视觉模型生成描述再embedding，不然多模态问题永远答不上。

其实图片这块完全不管的话确实会漏掉很多信息，尤其PDF里图表占比高的时候。我之前是把图表单独抽出来，用类似CLIP或专门的多模态模型生成向量，再和文字块一起存进Milvus，查询的时候统一检索，效果比纯文字好不少。不过这样存储和召回逻辑会复杂一些，得额外维护一个图文映射关系。你那边如果只是柱状图趋势这种问题，也可以考虑在文本块里加一段对图表的文字描述，算是低成本过渡方案。

图表这块确实容易被忽略，我之前也踩过同样的坑。向量库本身不挑内容类型，关键是你得先用多模态embedding模型把图片或图表转成向量，再和文本向量放同一个collection里，检索时按模态过滤或者混合召回。像你这种PDF里的柱状图，可以先用视觉模型生成一段文字描述再embed，或者直接上CLIP类的模型。不然只存文字chunk，问图里的趋势肯定答不出来。

向量库本身不挑内容，存的就是一串数字，关键是前面怎么把图和文变成同一语义空间里的向量。图片可以走CLIP或者多模态embedding单独编码，再跟文本块通过同一个doc_id关联起来，检索时两边一起召回。我之前做报表问答就是这么干的，图表先转成描述文本再embedding，效果比直接扔图片好不少。纯文本切块肯定答不了柱状图趋势这种问题，得把图的内容也喂进去。

图片也可以embedding啊，用CLIP这类多模态模型把图表转成向量存进去，检索时就能命中。