多模态RAG实战：文档解析与视觉检索的工程落地指南

1. 多模态 RAG 到底在解决什么问题

1.1 从纯文本 RAG 的天花板说起

做过 RAG 项目的人大概都有过这种体验：文本知识库跑得挺顺，召回率、命中率都还看得过去，结果一遇到 PDF 扫描件、产品手册、财报图表、工程图纸，整条链路立刻趴窝。原因不复杂——传统 RAG 的检索单元是文本块，而现实世界里大量高价值信息压根就不是纯文本形态存在的。

我去年接手过一个招投标场景的知识库项目，客户丢过来三千多份文件，里面混杂着扫描版合同、带复杂表格的报价单、带页眉页脚的实施方案、还有一堆带流程图的附件。最开始我用常规的文本抽取加切分方案，跑出来的效果惨不忍睹：表格被拆成乱序的字符流，章节标题和正文混在一起，页码信息全丢，检索出来的片段根本没法定位到原文。这就是纯文本 RAG 的天花板——它假设信息是线性的、连续的、可无损转成字符串的，但真实文档不是这样。

多模态 RAG 要解决的核心问题，就是让检索系统能够理解并利用文档的视觉结构信息。这里的"多模态"不是指花哨的图片生成，而是指把文本、版面布局、图像区域、表格结构这些不同模态的信息统一纳入检索和生成流程。文档解析负责把非结构化文档转成结构化表示，视觉检索负责在向量空间里同时匹配文字语义和视觉特征，两者配合才能把 RAG 的召回质量拉上一个台阶。

1.2 文档解析与视觉检索的分工边界

很多人会把文档解析和视觉检索混为一谈，觉得上了 OCR 就等于做了多模态。实际上这两件事的职责完全不同，我习惯用一个类比来解释：文档解析像是把一本纸质书拆解成带目录、带页码、带图表标注的电子版，视觉检索像是给这本书建一个既能按关键词查、又能按"长得像什么"查的索引系统。

文档解析的输出目标是一份结构化文本，它要保留页码、章节层级、段落边界、表格行列关系、图片位置这些元信息。视觉检索的目标是构建多路召回能力，既能在文本 embedding 空间里找语义相近的段落，也能在视觉 embedding 空间里找版面相似的页面或图表。两者是上下游关系：解析质量决定了检索的上限，检索策略决定了生成阶段能拿到多少有效上下文。

我见过不少团队一上来就堆视觉模型，结果解析层输出的文本本身就是乱的，再强的检索也救不回来。所以我的建议永远是：先把文档解析做扎实，再考虑视觉检索的增强。这个顺序反了，投入产出比会非常难看。

1.3 适合谁来参考这套方案

这篇内容适合三类人：一是正在做企业知识库、合同审查、招投标文件处理的工程师，你们大概率已经被复杂文档折磨过；二是做 RAG 应用但对多模态还没系统下手的开发者，想搞清楚从哪切入；三是技术负责人，需要评估多模态 RAG 的落地成本和收益边界。

前置知识方面，你至少得懂基本的 RAG 流程（切分、embedding、向量检索、重排、生成），用过至少一个向量数据库，对 OCR 有概念性的了解。不需要你精通视觉模型训练，因为工程落地阶段大部分工作是解析管线和检索策略的调优，而不是从头训模型。

2. 文档解析：把非结构化文档变成可检索的结构化文本

2.1 解析管线的整体设计思路

一条完整的文档解析管线，我通常拆成五个阶段：格式识别、版面分析、内容抽取、结构重建、质量校验。每个阶段都有坑，而且坑和坑之间会互相放大。

格式识别阶段要判断输入是原生 PDF、扫描 PDF、图片、Office 文档还是混合体。这个判断直接决定后续走哪条路径——原生 PDF 可以直接抽文本层，扫描件必须走 OCR，Office 文档走专门的解析库。我踩过的一个坑是：有些 PDF 前几页是原生文本，后面夹着扫描页，如果整份文件按一种策略处理，扫描页会直接变成空白。

版面分析阶段要做的是识别页面上的区域类型：正文、标题、表格、图片、页眉页脚、页码。这一步的准确性直接决定结构重建的质量。传统做法是用规则加投影分析，现在更稳的是用版面检测模型，比如基于 LayoutLM 系列或者 DocLayNet 训练出来的检测器。我实测下来，纯规则方案在规整文档上够用，但一遇到多栏排版、跨页表格就开始崩。

内容抽取阶段，文本区域走 OCR 或文本层抽取，表格区域走专门的表格识别，图片区域可以选择性地做图像描述生成。这里有个关键决策：图片要不要转成文字描述。我的经验是，对于流程图、架构图这类信息密度高的图，生成描述是有价值的；对于装饰性图片，生成描述反而会引入噪声，不如直接保留图片引用。

结构重建阶段是把抽取出来的碎片按阅读顺序拼回带层级的文档树。这一步最容易被忽视，但它恰恰是后续检索能定位到"第 3 章第 2 节第 4 段"的关键。质量校验阶段则是用规则或小模型检查解析结果，比如检测空段落比例、表格行列数异常、页码连续性等。

2.2 OCR 选型：本地方案与云服务的取舍

OCR 选型是文档解析里最纠结的一环。我把常见方案列个表对比一下，这些都是我在实际项目里用过的。

我个人的选择逻辑是这样的：如果数据敏感度不高、预算充足、且需要抽取固定模板票据的关键字段（比如合同里的金额、单位、时间），云 OCR 的模板能力确实省事。但如果是通用文档、数据不能出内网，我会优先选 PaddleOCR，中文场景下它的综合表现最均衡。

Tesseract 我一般只在两种情况下用：一是需要快速验证流程，二是目标文档是印刷体英文。它的中文识别在复杂版面上掉点很明显，尤其是竖排文本和带背景噪声的扫描件。Umi-OCR 有个"竖排/纵向阅读顺序"开关，处理古籍或者竖排排版时挺方便，但它的定位更偏向桌面工具，做批量管线要额外封装。

提示：OCR 选型不要只看单字识别率，版面分析能力往往比识别率更影响最终效果。一个识别率 98% 但阅读顺序全乱的方案，实际可用性远不如识别率 95% 但结构完整的方案。

2.3 结构化输出的字段设计

文档解析的输出到底该长什么样，这个设计决定了后面检索和生成的便利程度。我推荐的最小字段集是这样的：

{ "doc_id": "contract_2024_001", "page_num": 3, "block_type": "paragraph", "section_path": ["第三章", "3.2 付款条款"], "content": "甲方应在合同签订后三十日内支付首期款项...", "bbox": [120, 340, 560, 420], "table_data": null, "image_ref": null }

这里几个字段值得展开说。section_path是章节层级路径，它让检索结果能直接告诉用户"这段话出自第三章第二节"，而不是只给一个孤立的文本块。bbox是文本块在页面上的坐标，视觉检索和结果高亮都靠它。block_type区分段落、标题、表格、图片，生成阶段可以据此决定怎么组织上下文。

表格数据我建议单独存成二维数组或者 HTML 表格字符串，不要硬塞进content字段。因为表格的检索逻辑和段落不一样，段落靠语义相似度，表格往往靠表头关键词匹配。混在一起会让两边的效果都变差。

页码信息千万别丢。我见过太多解析方案把页码当噪声过滤掉，结果检索出来的内容无法定位原文，用户根本没法核对。页码、章节、段落这三层定位信息，是多模态 RAG 相比纯文本 RAG 的核心优势之一。

2.4 解析质量的校验与兜底

解析管线跑通只是开始，真正难的是保证质量稳定。我一般会设几道校验关卡。

第一道是空内容检测：如果某页解析出来的文本长度低于阈值（比如 50 字符），大概率是 OCR 失败或者版面分析漏检，需要标记出来人工复核或走备用解析路径。

第二道是阅读顺序校验：检查解析出的文本块顺序是否符合从上到下、从左到右的常规阅读逻辑。多栏排版最容易在这里出问题，我遇到过双栏 PDF 被解析成左右交错的情况，读起来完全不通。

第三道是表格完整性校验：检查表格的行列数是否合理，有没有出现某行单元格数量突变的情况。跨页表格是重灾区，需要专门的合并逻辑。

第四道是页码连续性校验：如果解析结果里页码跳号或者重复，说明页面处理环节有问题。

兜底策略上，我会准备两条解析路径：主路径用效果最好的方案，备用路径用更保守但更稳的方案。主路径失败时自动切换，同时记录失败样本用于后续优化。这个设计在实际生产里救过我好几次，尤其是遇到格式特别刁钻的文档时。

3. 视觉检索：让检索系统看懂版面

3.1 视觉检索要解决的核心痛点

纯文本检索有个根本性缺陷：它把文档当成一袋词，丢掉了版面信息。但很多检索需求恰恰依赖版面。比如用户想找"那份带流程图的实施方案"，或者"表格里有报价明细的那一页"，纯文本检索根本无从下手，因为这些特征不在文字里。

视觉检索的价值就在这里。它通过视觉 embedding 把页面的版面特征编码成向量，让"找长得像某类版面的页面"成为可能。同时，视觉特征还能辅助文本检索做重排——当两个文本块语义相似度接近时，版面位置、字体大小、是否在表格内这些视觉信号可以帮助判断哪个更相关。

我做过一个对比实验：在招投标文件检索场景下，纯文本检索的 Top-5 命中率大概在 62%，加入视觉特征重排后提升到 78%。提升主要来自两类查询：一类是定位特定章节（视觉上标题层级明显），一类是找特定表格（视觉上表格结构明显）。

3.2 视觉 embedding 的构建方式

视觉 embedding 的构建有几种主流思路，我按落地难度从低到高排一下。

最简单的是页面截图 + 通用视觉模型。把每页渲染成图片，用 CLIP 这类模型编码成向量。优点是实现快，缺点是粒度粗，一页里可能混着多个主题，检索精度有限。

进阶一点的是区域截图 + 视觉模型。结合文档解析的 bbox，把每个文本块或表格区域单独截图编码。粒度细了，但计算量上去了，而且区域切分的质量直接影响效果。

再进一步是版面特征 + 文本特征融合。除了视觉 embedding，还把版面特征（位置、大小、类型）编码成结构化向量，和文本 embedding 拼接或加权融合。这种方式效果最好，但工程复杂度也最高。

我实际项目里用得最多的是第二种，因为它在效果和成本之间比较平衡。具体做法是：文档解析阶段输出的每个 block，根据 bbox 从页面渲染图里裁出对应区域，缩放到统一尺寸，过视觉编码器得到向量，存进向量库时和文本向量并列存储。

注意：视觉 embedding 的维度通常比文本 embedding 高，存储和检索成本要提前算清楚。如果文档量在十万页级别，全量存视觉向量对向量库的压力不小，需要考虑降维或者分层索引。

3.3 多路召回与融合排序

视觉检索不是替代文本检索，而是和它配合。我常用的架构是三路召回加融合排序。

第一路是文本语义召回：用文本 embedding 在段落级别检索，这是基础盘。

第二路是视觉相似召回：用视觉 embedding 在区域级别检索，补充版面相关的查询。

第三路是关键词召回：用 BM25 或类似算法做精确匹配，兜住那些语义模型搞不定的专有名词、编号、代码。

三路召回的结果合并后，过一层重排模型。重排模型我一般用交叉编码器，输入是查询和候选片段的文本加视觉特征，输出相关性分数。融合策略上，我倾向于给文本语义召回较高权重，视觉召回作为补充信号，关键词召回作为精确匹配的保障。

这里有个实操细节：不同召回路径的分数尺度不一样，不能直接相加。我通常先对每路分数做归一化，再用加权求和或者学习排序的方式融合。权重需要根据业务场景调，没有万能值。

3.4 视觉检索的存储与索引设计

存储设计上，我建议文本向量和视觉向量分开存，但用同一个 doc_id 和 block_id 关联。这样检索时可以灵活组合，也方便单独优化某一路。

索引结构上，如果向量库支持多向量字段，可以直接在一个 collection 里存两种向量。如果不支持，就建两个 collection，检索时分别查再合并。我实测下来，分开存的可维护性更好，因为两路向量的更新频率和重建成本不一样。

分层索引是个值得考虑的优化。对于超大规模文档库，可以先用一个粗粒度的页面级索引做初筛，再用细粒度的区域级索引做精排。这样能把检索延迟控制在可接受范围内。我做过一个测试，百万级页面的库，不分层检索延迟在秒级，分层后能压到百毫秒级。

4. 实操落地：从零搭一条多模态 RAG 管线

4.1 环境准备与依赖选型

我按最小可跑通的配置来列，这套组合我在多个项目里验证过，稳定性和效果都还行。

# 文档解析核心 pip install paddleocr paddlepaddle pip install pdfplumber pymupdf pip install python-docx openpyxl # 向量与检索 pip install sentence-transformers pip install chromadb pip install rank-bm25 # 视觉编码 pip install open_clip_torch pip install pillow # 生成与编排 pip install langchain pip install ollama

选型理由说一下。PaddleOCR 负责 OCR 和版面分析，中文场景综合表现最好。PyMuPDF 负责原生 PDF 的文本层抽取和页面渲染，速度比 pdfplumber 快不少，两者可以互补——PyMuPDF 抽文本和渲染图，pdfplumber 处理复杂表格。ChromaDB 作为向量库，轻量、易部署，适合中小规模验证。OpenCLIP 做视觉编码，开源、可离线、模型选择多。Ollama 跑本地生成模型，避免依赖外部服务。

如果你要上生产，向量库可以换成 Milvus 或 Qdrant，生成模型可以换成更大参数量的本地模型或者走内部推理服务。但验证阶段，上面这套足够跑通全流程。

4.2 文档解析的完整实现

先写解析主流程。核心思路是：先判断文档类型，再走对应解析路径，最后统一输出结构化 block 列表。

import fitz # PyMuPDF from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang='ch', show_log=False) def parse_pdf(pdf_path): doc = fitz.open(pdf_path) blocks = [] for page_idx, page in enumerate(doc): text = page.get_text().strip() if len(text) > 50: # 原生文本层可用，直接抽取 page_blocks = extract_native_blocks(page, page_idx) else: # 扫描页，走 OCR pix = page.get_pixmap(dpi=200) img_path = f"/tmp/page_{page_idx}.png" pix.save(img_path) page_blocks = extract_ocr_blocks(img_path, page_idx) blocks.extend(page_blocks) return blocks

extract_native_blocks用 PyMuPDF 的get_text("dict")拿到带 bbox 的文本块，再根据字体大小和位置推断标题层级。extract_ocr_blocks调 PaddleOCR，拿到文本、置信度和 bbox，再按 y 坐标排序还原阅读顺序。

阅读顺序还原这块有个细节：PaddleOCR 返回的结果是按检测顺序排的，不一定是阅读顺序。我的做法是先按 bbox 的 y 中心聚类成行，行内按 x 排序，行间按 y 排序。多栏排版需要先做栏检测，这个可以用 PaddleOCR 的版面分析能力，或者自己写个基于 x 坐标分布的简单聚类。

表格处理单独走一条路径。PyMuPDF 有find_tables()方法，能识别一部分表格结构。识别不了的，用 PaddleOCR 的表格识别模型。表格输出成二维数组，同时保留 bbox 和所在页码。

4.3 向量化与索引构建

解析完拿到 block 列表，接下来做向量化。文本向量和视觉向量分开处理。

from sentence_transformers import SentenceTransformer import open_clip import torch from PIL import Image text_model = SentenceTransformer('BAAI/bge-large-zh-v1.5') clip_model, _, preprocess = open_clip.create_model_and_transforms( 'ViT-B-32', pretrained='laion2b_s34b_b79k' ) def build_index(blocks, page_images): text_vectors = [] visual_vectors = [] metadatas = [] for block in blocks: # 文本向量 tv = text_model.encode(block['content']) text_vectors.append(tv) # 视觉向量：从页面图裁出 bbox 区域 page_img = page_images[block['page_num']] x0, y0, x1, y1 = block['bbox'] crop = page_img.crop((x0, y0, x1, y1)) crop_tensor = preprocess(crop).unsqueeze(0) with torch.no_grad(): vv = clip_model.encode_image(crop_tensor) visual_vectors.append(vv.squeeze().numpy()) metadatas.append({ 'doc_id': block['doc_id'], 'page_num': block['page_num'], 'section_path': ' > '.join(block['section_path']), 'block_type': block['block_type'] }) return text_vectors, visual_vectors, metadatas

文本模型我选 BGE 系列，中文语义检索效果稳。视觉模型选 ViT-B-32，参数量适中，编码速度快，精度够用。如果对视觉检索精度要求更高，可以换 ViT-L-14，但编码成本会上去。

存进 ChromaDB 时，文本向量和视觉向量分别建 collection，用 block_id 关联。检索时两路分别查，再按 block_id 合并。

4.4 检索与生成的串联

检索阶段，我实现一个三路召回加融合的函数。

def hybrid_retrieve(query, top_k=10): # 文本语义召回 text_results = text_collection.query( query_embeddings=[text_model.encode(query)], n_results=top_k * 2 ) # 视觉召回（查询本身是文本时，用文本编码器近似） query_visual = clip_model.encode_text( open_clip.tokenize([query]) ).detach().numpy() visual_results = visual_collection.query( query_embeddings=query_visual, n_results=top_k * 2 ) # 关键词召回 bm25_results = bm25_index.get_top_n(query, top_k * 2) # 融合排序 merged = merge_and_rerank( text_results, visual_results, bm25_results, query ) return merged[:top_k]

融合排序我用一个简单的加权方案起步：文本语义 0.5，视觉 0.3，关键词 0.2。这个权重不是拍脑袋，是我在几个项目里调出来的经验值。文本语义是主力，视觉补充版面信号，关键词兜精确匹配。实际项目里可以根据业务反馈微调。

生成阶段，把检索到的 Top-K 片段按章节路径和页码排序，拼成上下文，加上系统提示词，丢给生成模型。提示词里我会明确要求模型引用来源，格式是"根据第 X 页第 Y 节"。这样用户能核对，也方便后续做引用溯源。

def build_prompt(query, retrieved_blocks): context_parts = [] for block in retrieved_blocks: header = f"[来源：第{block['page_num']}页 {block['section_path']}]" context_parts.append(f"{header}\n{block['content']}") context = "\n\n".join(context_parts) prompt = f"""基于以下文档内容回答问题，引用时请标注来源页码和章节。 文档内容： {context} 问题：{query} """ return prompt

5. 常见问题与排查技巧实录

5.1 解析阶段的典型故障

问题一：扫描件 OCR 后文本乱序。这是最常见的。排查思路是先看 OCR 返回的 bbox 是否正常，如果 bbox 正常但顺序乱，说明是排序逻辑的问题。多栏排版需要先做栏检测，我一般用 x 坐标的直方图找栏边界，再按栏内排序。如果 bbox 本身就乱，说明 OCR 的检测环节有问题，可能需要换模型或者调整检测参数。

问题二：表格被拆成散乱文本。检查解析时有没有走表格专用路径。如果走了还乱，看表格识别模型是否支持跨页合并。跨页表格需要根据表头重复出现或者列对齐关系做合并，这个逻辑得自己写。

问题三：页码信息丢失。检查解析时有没有把页眉页脚当噪声过滤掉。页码通常在页面边缘，容易被版面分析误判为页眉页脚。我的做法是单独识别页码区域，保留其文本和位置，不参与正文排序但存入元数据。

问题四：章节层级识别错误。标题层级靠字体大小和加粗判断，但有些文档标题和正文的字体差异不明显。这种情况我会结合编号模式（如"第一章""1.1""（一）"）做辅助判断，规则加模型双保险。

5.2 检索阶段的典型故障

问题一：视觉检索召回结果和查询不相关。先检查视觉 embedding 的质量。如果区域截图裁得不准，视觉向量就是噪声。检查 bbox 是否正确，裁剪时有没有留足边距。另外，通用 CLIP 模型对文档版面的理解有限，如果效果持续不好，可以考虑用文档版面数据微调，或者换用专门针对文档训练的视觉模型。

问题二：多路召回融合后排序不合理。检查各路分数的归一化是否正确。不同召回路径的分数分布差异很大，直接加权会出问题。我一般用 min-max 归一化，或者用排名倒数作为融合依据，后者更鲁棒。

问题三：检索延迟过高。视觉向量维度高，检索慢是正常的。优化方向有三个：降维（PCA 或量化）、分层索引（先粗筛再精排）、限制视觉召回的候选数量。我实测下来，把视觉召回候选数控制在文本召回的 1.5 倍以内，延迟能明显下降，效果损失很小。

问题四：专有名词检索不到。这是语义模型的通病。关键词召回就是兜这个的。如果 BM25 也兜不住，检查分词是否正确，专有名词有没有被切碎。必要的话建一个专有名词词典，检索时做同义词扩展。

5.3 生成阶段的典型故障

问题一：模型编造来源。提示词里明确要求引用来源，但模型还是可能编。解决办法是在后处理阶段校验引用，如果引用的页码或章节在检索结果里不存在，就标记为可疑。更严格的做法是只允许模型从给定片段里摘录，不允许改写来源信息。

问题二：上下文超长导致截断。多模态 RAG 检索回来的片段往往比纯文本多，容易超上下文窗口。我的做法是按相关性排序后截断，同时保证每个章节至少保留一个片段，避免信息断层。表格片段优先保留，因为表格信息密度高。

问题三：生成内容与原文不符。这是幻觉问题。除了提示词约束，我还会在生成后做一次事实校验，用检索结果和生成内容做比对，标出可能不一致的地方。这个校验可以用小模型做，也可以用规则做。

5.4 常见问题速查表

5.5 几条踩坑换来的经验

第一条，解析质量决定一切。我见过太多团队在检索和生成上花大力气，结果解析层输出的文本本身就是错的，后面怎么调都白搭。建议把至少一半的优化精力放在解析上。

第二条，视觉检索不是万能的。它对版面相关的查询有效，对纯语义查询帮助有限。不要指望加了视觉检索就能解决所有召回问题，该做关键词召回还得做。

第三条，权重需要按业务调。我给的 0.5/0.3/0.2 只是起步值。合同审查场景可能关键词权重更高，技术文档场景可能语义权重更高。上线后一定要根据实际查询日志调权重。

第四条，保留原始文档的定位信息。页码、章节、bbox 这些信息在生成阶段可能用不上，但在用户核对和问题排查时价值巨大。别为了省存储把这些丢了。

第五条，小步验证，别一上来就全量。先拿几百份文档跑通全流程，验证效果和性能，再逐步扩量。我见过一上来就处理百万文档，结果解析管线有 bug，返工成本极高。

6. 多模态 RAG 的扩展方向

6.1 从文档解析到知识图谱

文档解析输出的结构化文本，其实可以直接喂给知识图谱构建管线。章节层级天然就是树结构，表格里的实体关系可以抽成三元组，图片描述可以挂到对应节点上。这样检索时就不只是向量匹配，还能走图查询，对复杂推理类问题帮助很大。

我试过把合同文档解析后构建成知识图谱，节点是条款、金额、时间、主体，边是引用、依赖、冲突关系。检索"哪些条款和付款相关"这类问题时，图查询比向量检索精准得多。当然，图谱构建的成本也高，适合高价值场景。

6.2 多模态融合的进阶玩法

现在的方案里，文本和视觉向量是分开存、分开查、后期融合。更进阶的做法是训练一个多模态融合编码器，把文本和视觉特征在编码阶段就融合。这样检索时只需要一路查询，效率和效果都可能更好。但训练成本高，需要标注数据，适合有条件的团队。

另一个方向是引入版面图结构。把文档页面表示成图，节点是文本块和图像区域，边是空间邻接和阅读顺序关系。用图神经网络编码，能更好地捕捉版面语义。这个方向学术界研究挺多，工程落地还不多见。

6.3 与 Agent 结合的可能性

多模态 RAG 和 Agent 结合是个有意思的方向。Agent 可以根据查询类型动态选择检索策略：语义查询走文本检索，版面查询走视觉检索，精确查询走关键词检索。甚至可以让 Agent 多轮检索，第一轮粗筛，第二轮针对性地深入某个章节。

我最近在试的一个玩法是让 Agent 先判断查询意图，再决定要不要触发视觉检索。这样能避免不必要的视觉编码开销，也能提升检索精度。实测下来，对于明确的语义查询，跳过视觉检索能省 40% 左右的延迟，效果几乎无损。

文档解析这块后续还可以扩展的方向包括：手写体识别、公式识别、多语言混排处理。视觉检索可以扩展的方向包括：跨页版面匹配、图表内容理解、版面相似度聚类。这些方向都有实际需求，但落地难度和成本需要单独评估。

我个人在实际操作中的体会是，多模态 RAG 的价值不在于技术多炫，而在于它能不能解决纯文本 RAG 解决不了的实际问题。如果你的业务场景里复杂文档占比高、检索需求依赖版面信息，那这套方案值得投入。如果文档本身就很规整、查询也很简单，那可能纯文本方案就够了，没必要为了多模态而多模态。技术选型永远要回到业务价值上，这是我做了这么多项目最深的感受。