文章核心观点 - 检索增强生成（RAG）技术正从处理单一文本片段，向系统化组织多模态知识形态、业务边界和证据位置演进，以构建更智能的企业级知识检索基础设施[1] - 以Google Gemini API File Search为代表的产业进展，其核心在于重写“检索对象”，将PDF页面、图表、表格、截图等多模态证据单元作为基本处理单元，以提升企业知识库的利用率和回答的可核验性[2][5][6] - 企业RAG部署的关键挑战从“检索什么”扩展到“在哪里检索”，涉及如何结合结构化过滤（如部门、版本、权限）来控制召回范围，确保检索的准确性与适用性[2][7] 多模态RAG为什么要重写检索对象 - 传统RAG方案将检索对象简化为切碎的文本段落，导致PDF页面、图表、表格结构、版本状态和权限边界等信息难以进入召回逻辑，降低了企业知识库的实际利用率[4][5] - 企业知识库中大量PDF、表格、截图、图表等材料难以稳定转化为模型可用上下文，仅依赖文本chunk和全库向量相似度搜索易出现“维度灾难”，导致召回不准、排序不稳和检索成本上升[3] - Google Gemini API File Search将RAG处理对象扩展到PDF页面、图表、截图、图片和表格区域等多模态证据单元，并整合文件导入、切片、向量化、索引和检索全流程至平台层，降低了企业自行拼接RAG管线的工程成本[2][5] - 多模态RAG需联合解析页面文本、图像内容、表格结构与版式信息，并同步维护向量表征、证据定位和引用关系，使模型在生成答案时能使用更完整的业务上下文，并支持回到具体页面、图像片段或表格位置进行核验[6] - 产业侧如Amazon Nova、Cohere Embed 4、Voyage等能力正将文本、表格、图像、幻灯片和复杂商业文档放入统一向量空间；研究侧如DSE、ColPali等工作则致力于保留页面布局、表格、图像、字体等视觉结构，使文档页面成为可索引、可召回的知识单元[7] 「在哪里检索」才是RAG面对企业知识库的关键挑战 - 企业知识库中的合同、制度、产品资料和客户文件通常按部门、版本、地区、权限等业务维度组织，因此检索质量不仅取决于语义相似度，更取决于召回范围是否正确，“在哪里检索”成为关键工程问题[2][7] - 系统需要结合客户、版本、权限、时间、文件类型等业务边界来控制召回范围，以提升召回适用性与生成结果的可核验性[2]