type
status
date
slug
summary
tags
category
icon
password
引言
在快速发展的生成式人工智能领域，检索增强生成（RAG）已成为一种常见模式，使大型语言模型能够回答基于从文档存储中检索的数据的特定领域用户查询。对于许多企业用例，这些文档包含文本和图像内容，如照片、图表或网页截图：这引入了多模态RAG的概念，它在LLM用于回答问题的上下文中整合了多种输入模态，可以通过多种设计模式来实现。
作为最近一个项目的一部分，我们的团队通过采用多模态RAG模式来解决这种情况，该模式利用多模态LLM（如GPT-4V或GPT-4o）有效地将图像内容转换为文本格式，生成每张图像的详细描述。这种转换使文本内容和图像的文本描述能够存储在同一个向量数据库空间中，然后可以通过标准RAG管道流程检索并用作LLM的上下文。我们的目标是通过详细的实验来提高搜索精确度和相关性，同时确保对用户查询的LLM生成响应有意义；这篇博文分享了我们的方法、见解和从实验过程中获得的实际发现。
我们认识到，我们的结论是基于为特定客户场景定制的设置。因此，尽管我们对我们的结果和学习感到兴奋，但我们鼓励读者进行自己的实验，以验证我们的见解对其独特环境的适用性。让我们一起深入探讨Azure AI Search、Azure AI Services和Azure OpenAI Service的复杂性，并探索如何微调多模态RAG管道以获得最佳性能，特别是在处理增强视觉的查询时。
我们将从端到端工作流程和实验方法开始。
实验背景
我们的工作流程由以下组件组成：知识构建流程、丰富流程（知识构建的一个子流程）和推理流程。我们将在下面详细讨论这些内容，同时提供有关我们实验过程、数据集和用于评估的指标的额外信息。
知识构建流程
为了增强处理与图像相关的用户查询的能力，我们决定在构建源文档的文本的同时也处理图像描述。最初，我们考虑使用多模态 Embedding 例如 CLIP，但由于其在捕捉详细视觉信息方面的局限性而未使用。此外，大多数 CLIP 模型不允许超过 70-77个词 。这些 Embedding 通常只提供对物体和形状的一般洞察，而不提供详细解释。
相反，我们选择了一个多模态大语言模型（MLLM）来解释文本和视觉数据。我们专注于确保文档中的所有信息，包括图像，都通过MLLM，从而生成详细的图像描述，并转化为文本，从而实现更全面的知识处理过程。这种方法允许对图像进行更丰富和准确的理解，相比LLM仅依赖同一文档集的文本数据，能够更有效地响应与图像相关的查询。
然而，请注意，这种离线预处理仅依赖于包含在多模态LLM 提示中的指令来生成描述（强依赖于用 LLM 理解图片时的 Prompt）；它无法捕捉用户可能询问的每一个细节，在某些情况下，可能需要用户查询提供的额外指导性上下文来从图像中提取相关细节并制定适当的响应（自适应 Prompt 或定制化 Prompt、以及在线问答时直接加载原始图像）。这种离线上下文无关图像处理和在线上下文感知图像处理之间的权衡，以及这些技术如何协同工作，将在下面的部分中探讨。
丰富流程
图像丰富是知识构建流程的一个可配置子组件。作为丰富过程的一部分，如果源文档中的图像被认为可能与文档主题相关，则会被MLLM生成的文本描述所替代。我们使用Azure计算机视觉图像分析中的图像标记功能来实现这一目的。 — 判断图片是否与主题有关（判断图片的价值性）。 我们不会为被分类为logo的图像（基于可配置的置信度分数阈值）或不包含任何文本的图像生成描述。
这个逻辑是基于我们源文档的性质和通常用于回答问题的图像类型而开发的，目的是减少知识构建过程中的成本和延迟。分类器实现可以并且应该根据您的特定场景进行定制。
推理流程
最终用户提交查询以从AI系统获得有意义的响应。以下流程图说明了用于评估用户查询的结构化方法。在接收到查询后，系统利用Azure AI Search检索初始的相关数据块。这些数据块可以选择性地进行重新排序处理，以提高搜索结果的精确度。最终的数据块然后作为上下文传递给Azure OpenAI LLM，以生成基于相关源信息的用户查询答案，最终形成对用户查询的LLM生成响应和相关引用。
对于有兴趣为类似的基于视觉的用例运行RAG实验的人，这个Azure-Samples仓库提供了入门代码和评估流程。
实验方法论
我们通过系统地测试不同的方法来进行实验，每次调整一个配置设置，并评估其对预定基线的影响。性能评估使用下面列出的特定检索和生成指标。对这些指标的详细分析为我们决定是否用新配置更新基线或保留现有配置提供了依据。
问答评估数据集
为了在实验过程中进行准确评估，精心策划一组多样化的问答对至关重要。这些问答对应涵盖一系列文章，包含各种数据格式、长度和主题。这种多样性确保了全面的测试和评估，有助于获得可靠的结果和洞察。以下是可以考虑的问答数据集示例。
ID | 文档标题 | 问题 | 文本答案 | 图片链接 | 类型 | 来源 |
1 | 知识构建流程 | RAG中知识构建流程的步骤是什么 | 分块文档、丰富文档、嵌入分块和持久化数据 | 视觉 | ||
2 | KNN | 应该为哪些类型的数据集使用穷举KNN？ | KNN可用于小型到中型数据集，但不适用于大型数据集。 | 视觉+文本 |
我们确保我们的问答数据集包含了仅文本、图像和文本以及仅图像衍生的问题的均衡组合。同时也确保问题分布在各种源文档中。
我们的评估集相对较小，但我们通过包含广泛的边缘案例确保其多样性。我们的分析始于一个全面的探索性数据分析（EDA），我们从中提取了诸如文本的文章长度、表格长度和表格数量，以及图像的图像类型、分辨率和数量等特征。然后，我们仔细地将评估集分布在这些特征上，以实现对特征空间的全面表示和强大覆盖。此外，该系统支持同一问题的替代来源和图像。
评估指标
在我们的实验设置中，我们专注于以下两种主要评估类型指标，以评估Azure AI Search（检索指标）和LLM对用户查询的响应（生成指标）的性能：
检索指标
指标 | 说明 | 行级指标值 |
源召回率@k% ** | 在前'k'个块中找到至少一个标记为良好来源的文档的问答对的百分比 | 如果第一个源块索引 < k 则为1，否则为0 |
所有图像召回率@k% ** | 成功检索到所有预期图像的问答对的百分比 | 如果检索到所有真实图像则为1，否则为0 |
图像召回率@k_平均值 | 平均图像召回率 | 介于0和1之间（在k个块中检索到的URL与真实值中预期URL的召回率） |
图像召回率@k_中位数 | 中位数图像召回率 | 介于0和1之间（在k个块中检索到的URL与真实值中预期URL的召回率） |
图像精确率@k_平均值 | 平均图像精确率 | 介于0和1之间（在k个块中检索到的URL与真实值中预期URL的精确率） |
图像精确率@k_中位数 | 中位数图像精确率 | 介于0和1之间（在k个块中检索到的URL与真实值中预期URL的精确率） |
相似性搜索时间（秒）_平均值 | 平均AI搜索块检索时间（秒） | 时间（秒） |
相似性搜索时间（秒）_中位数 | 中位数AI搜索块检索时间（秒） | 时间（秒） |
源块数量_总和 | 所有问答对的所有真实检索块的计数 | 介于0和k之间 |
图像块数量_总和 | 所有问答对的所有真实检索图像块的计数 | 介于0和k之间 |
- k = 10,5,3
生成指标
指标 | 解释 | 行级指标值 |
所有被引用图像召回率% | LLM引用了所有预期图像的真实问答对的百分比 | 如果LLM引用了所有真实图像则为1，否则为0 |
被引用图像召回率_平均值 | 平均被引用图像召回率 | 介于0和1之间（生成答案中的URL与真实值中预期URL的召回率） |
被引用图像召回率_中位数 | 中位数被引用图像召回率 | 介于0和1之间（生成答案中的URL与真实值中预期URL的召回率） |
被引用图像精确率_平均值 | 平均被引用图像精确率 | 介于0和1之间（生成答案中的URL与真实值中预期URL的精确率） |
被引用图像精确率_中位数 | 中位数被引用图像精确率 | 介于0和1之间（生成答案中的URL与真实值中预期URL的精确率） |
被引用图像F1值_平均值 | 平均被引用图像F1值 | F1 = 2 *被引用图像召回率* 被引用图像精确率 / (被引用图像召回率 + 被引用图像精确率) |
被引用图像F1值_中位数 | 中位数被引用图像F1值 | F1 = 2 *被引用图像召回率* 被引用图像精确率 / (被引用图像召回率 + 被引用图像精确率) |
聊天查询时间（秒）_平均值 | 平均端到端响应时间（秒） | 时间（秒） |
聊天查询时间（秒）_中位数 | 中位数端到端响应时间（秒） | 时间（秒） |
推理提示词令牌数_总和 | 输入到LLM的令牌数 | 推理提示词令牌数 |
推理完成令牌数_总和 | LLM用于回答的输出令牌数 | 推理完成令牌数 |
视觉提示词令牌数_总和 | 输入到增强服务的令牌数 | 视觉提示词令牌数 |
视觉完成令牌数_总和 | 输出到增强服务的令牌数 | 视觉完成令牌数 |
GPT正确性得分>3% | 正确性指标得分高于3的真实问答对的百分比 | ㅤ |
GPT正确性得分_平均值 | 平均正确性得分 | GPT正确性得分（1-5） |
GPT正确性得分_中位数 | 中位数正确性得分 | GPT正确性得分（1-5） |
上述描述的指标为系统各个部分的有效性提供了有价值的洞察。分别衡量系统的搜索能力和生成部分至关重要，这样您就能了解实验对每个组件的影响。
经验总结
在整个客户合作过程中，我们的目标是提高基于图像的查询性能，同时保持基于文本查询的效率。我们着手寻找能够实现这种平衡的功能，并通过严格的实验来测试我们的想法。
让我们深入了解我们实验中的关键见解，看看它们如何指导我们优化图像和文本查询性能的方法。
提示工程
我们的旅程始于创建两个专门的提示：一个用于知识构建，另一个用于推理。这种方法旨在准确提取图像描述并增强查询响应。
图像丰富的提示
对于图像丰富的提示，我们对源图像进行了全面分析，以了解其内容和我们文档存储中常见的图像类别。基于这种分类，我们定制了提示，以确保大语言模型专注于每种图像类型包含的相关信息。这种方法确保我们的系统能够处理各种各样的图像，并提供所需的精确响应。
以下是我们在知识构建管道中用于图像描述提取的提示示例。虽然这个提示是专门为我们的用例定制的，但它提供了一个如何处理不同图像类型的思路。根据源数据中的图像，您可能需要调整提示以确保其有效性。
你是一位助手，你的工作是提供将用于检索图像的图像解释。请遵循以下指示：
- 如果图像包含任何气泡提示，则仅解释气泡提示。
- 如果图像是设备图，则详细解释所有设备及其连接。
- 如果图像包含表格，尝试以结构化方式提取信息。
- 如果图像是设备或产品，尝试描述该设备的所有与形状和设备上文字相关的细节。
- 如果图像包含截图，尝试解释高亮的步骤。如果图像中的确切文字只是步骤的示例，请忽略它并专注于步骤。
- 否则，全面解释图像上最重要的项目及其所有细节。
推理提示
我们还开发了一个专门用于生成用户查询响应的提示，该提示根据客户需求进行了定制，以确保相关和准确的答案。这个提示指示语言模型返回引用的图像，使我们能够收集引用指标并评估响应的质量。
以下是我们用于生成用户查询响应的提示示例。与摄取提示一样，可能需要根据预期的响应调整此示例以确保其有效性。
你是一位有帮助的AI助手，你的主要目标是帮助维护和改进公司通信基础设施的技术人员。根据： 上下文：{context}， 回答以下问题： 问题：{question}。如果是程序性问题，请提供逐步说明。如果提供的上下文为空，请不要尝试回答。而是要求他们详细说明问题。输出必须采用json格式，其中一个属性将是答案，另一个属性将是image_citation，即可能对用户有用的图像url。在上下文中，所有图像url将采用以下格式：（图像url）。 输出格式示例： {”answer”：”是的，你可以更换电缆”，”image_citation”：”图像url”}
我们面临的一个挑战是模型并不总是返回可解析的JSON格式。有时它会中断，但我们能够提取URL用于引用指标。我们没有投入太多精力改进JSON格式，因为这不是客户的要求，但可以通过OpenAI API的结构化输出等方法解决。
元数据的影响
如上所述，我们工作的目标之一是优化检索性能：我们希望从文档存储中识别出最相关的内容，以帮助大语言模型准确回答用户查询。除了原始文档内容外，我们还可以利用可用的文档级元数据 - 通常包括文档标题、作者、创建日期、摘要、关键词和目标受众等字段 - 来使用 Azure AI Search 提高搜索结果的相关性。字符串化的元数据内容可以包含在搜索索引中以供查询，并且可以将特定字段添加到 Azure AI Search 的语义排序功能配置中，通过提升语义上最相关的结果来进一步改善搜索性能。
出于这些原因，我们进行了一项实验，以量化在我们的用例中包含文档级元数据对检索的好处，结果如下：
从这个表格中，我们可以看到在摄取过程中将结构化元数据与非结构化内容一起整合，导致源召回性能有统计学上显著的改善，因此我们选择继续采用这种方法。
单独的图像块与内联块的对比
在构建源文档中的图像描述和文本时，如何包含这些图像注释的方法对于在搜索过程中有效利用信息起着至关重要的作用。我们使用以下格式对图像数据进行注释，并观察到这种方法在我们的用例中效果良好：
然后我们面临一个决定：我们是应该将描述作为单独的块存储，而主文本块只包含URL引用，还是将图像描述与主文本整合并进行分块？为了找出答案，我们两种方法都尝试了，目标是发现在检索指标和生成指标方面的最佳方法。
让我们首先看看内联与单独图像块数据会是什么样子，使用从这里提取的Azure文档示例图像
从增强服务提取的这个示例图像的描述将如下所示：
该图像显示了一组三个圆形进度图表，每个图表代表与存储和索引相关的不同类型的数据指标。
- 左侧的第一个图表标记为"存储"，显示进度为1.8%。图表下方有两行信息：当前使用量列为"459.63 MB"，配额为"25 GB"。这些行下方有一个标记为"查看规模"的链接或按钮。
- 中间的图表标记为"向量索引大小"，显示进度为3%。该图表下方的数据显示当前使用量为"93 MB"，配额为"3 GB"。与第一个图表类似，下方有一个标记为"查看索引"的链接或按钮。
- 右侧的第三个图表标记为"索引"，显示的进度要大得多，为48%。当前计数为"24"，配额为"50"。这个图表下方也有一个"查看索引"链接或按钮。
每个图表都有一个彩色段表示已使用的百分比，剩余的灰色图表区域代表未使用的配额部分。在OCR文本中无法看到这些段的颜色，但在图像中可以看到："存储"为蓝色，"向量索引大小"为浅蓝色，"索引"为深蓝色。
以下是一个内联块示例，针对2100个字符的文本块，考虑到我们样本的块大小为510个标记：
以下截图显示了一个配置了一个分区和一个副本的S1服务。这个特定服务有24个小型索引，平均每个索引有一个向量字段，每个字段由1536个嵌入组成。第二个磁贴显示了向量索引的配额和使用情况。向量索引是为每个向量字段创建的内部数据结构。因此，向量索引的存储始终只占索引整体使用存储的一小部分。其他非向量字段和数据结构占用了剩余部分。 向量索引限制和估算在另一篇文章中有详细介绍，但需要强调的两点是：最大存储容量因服务层级而异，并且取决于搜索服务创建的时间。较新的同级服务对向量索引有显著更大的容量。出于这些原因，请采取以下行动：*
单独的块样本将遵循定义的注释，实际的文本块将如下所示，其中仅包含图像URL：
以下截图显示了配置有一个分区和一个副本的S1服务。这个特定服务有24个小型索引，平均每个索引有一个向量字段，每个字段由1536个嵌入组成。第二个磁贴显示了向量索引的配额和使用情况。向量索引是为每个向量字段创建的内部数据结构。因此，向量索引的存储始终只占索引整体使用存储的一小部分。其他非向量字段和数据结构占用了剩余部分。(https://learn.microsoft.com/en-us/azure/search/vector-store/*.png) 向量索引限制和估算在另一篇文章中有详细介绍，但需要强调的两点是：最大存储容量因服务层级而异，并且取决于搜索服务创建的时间。较新的同级服务对向量索引有显著更大的容量。出于这些原因，请采取以下行动：
现在让我们来看看实验结果。以下是对实验运行的高层次观察：
根据我们的实验运行，我们观察到使用单独的图像注释块在源文档和图像检索指标方面都产生了显著的统计改进。在搜索延迟方面没有变化。特别是对于与视觉相关的查询，单独的块在准确检索正确的源文档以及正确的源图像方面proved更加有效；除了改善传递给LLM的上下文外，如果应用程序UI选择在响应中包含这些内容，这还将有利于提高引用准确性。
为了进一步探索这个加载器和块结构的配置，我们测试了几个其他假设：第一个是将这些图像注释作为元数据包含在源文档块上是否会提高检索质量。然而，我们没有观察到这种配置在检索准确性方面有统计学上的显著改进。另一个实验涉及查看我们是否可以通过在推理聊天时增强传递给LLM的上下文来提高生成答案的质量，这个上下文包含从AI Search检索的文档块中缺失的任何图像信息。然而，这种方法并没有改善图像引用质量，反而增加了整体token使用量，所以我们选择不继续这种实现。
分类器的影响
首先，让我们了解一下内容丰富流程中的分类器组件。我们引入了一个分类器层来区分图像，确保只有相关图像才会由丰富流程处理。这是通过使用Azure AI的视觉标记端点实现的。通过根据客户的具体兴趣和用例文档存储中包含的图像类型配置标签和置信度水平，我们能够有效地对图像进行分类并简化处理工作流程。这种方法旨在提高数据集构建的效率。
在我们客户的用例中，源文档包含各种图像，包括应用程序标志和文本较少的图像。为了优化数据处理，这些信息量较少的图像被排除在详细提取之外。相反，只有图像URL引用被添加到数据块中，确保了文档处理的简化和高效。
我们着手评估排除信息量较少的图像（如标志和抽象视觉）的影响，以减少噪音并提高整体系统性能。具体而言，我们的目标是确保这种排除不会对召回率产生不利影响，同时改善摄取延迟。
以下是探讨这一假设的实验结果的高层次概述。
引入分类器显著优化了我们的数据构建过程。我们在源文档和图像召回方面都达到了统计上相似的结果，同时大幅减少了数据构建的时间。通过过滤掉信息量较少的图像，我们简化了数据构建流程，提高了系统效率，而不影响检索准确性。
对于我们客户的用例，我们的分析强烈支持启用阈值为0.8的分类器，尽管延迟比0.9时略高。这种配置有效地过滤掉了非必要的图像，减少了潜在的噪音，并专注于为最相关的图像生成描述。
包含周围文本对图像丰富化的影响
最终用户在审查单独由GPT-4V生成的描述时注意到一个反复出现的问题：关键细节如应用程序和设备名称——通常出现在图像前面的标题或说明中——经常缺失。这一观察引发了一个关键问题：
在文档中包含周围的文本是否能帮助GPT-4V提供更好的图像描述，从而增强搜索结果和聊天回复？
为了增强图像描述，我们可以使用自定义加载器动态提取文档中图像前后的文本，并在丰富化过程中将其作为上下文提供给多模态LLM模型，目的是生成更好的图像描述。对于这个实验，我们更新了数据构建的 prompt，在末尾包含以下额外文本：
图像取自文档，我们将提供图像前后的部分文本。如果有用的话，请使用该上下文为图像提供更多信息。前文：\n（N个字符之前）后文：\n（M个字符之后）
让我们回到之前使用的示例图像，但现在让我们考虑它在周围文本的上下文中：
根据我们实验的参数，我们更新了图像丰富化 Prompt ，以包含以下额外的周围文本给多模态大语言模型（N=600，M=300）：
该图像取自文档，我们将提供图像前后的部分文本。使用该上下文来捕捉截图应用程序或设备名称。前文：<图像前的段落文本，来自上面的截图> 后文：<图像后的段落文本，来自上面的截图>
我们观察到，在进行这一更改后，得到的图像描述在很大程度上相似，但在开头增加了一个特别指出截图所来自应用程序名称的额外句子：
该图像似乎是Azure门户的截图，突出显示了S1搜索服务的配置和使用指标。
初步结果很有希望，因此我们进行了完整的实验运行。以下是探索周围文本是否有助于提高检索指标的实验结果的高层次概述：
我们对通过包含周围文本来增强图像描述的调查得出了一些有价值的见解。虽然添加上下文确实提高了图像描述的质量，但对检索指标的影响并不如预期的那么显著。
经过进一步分析，我们发现源文件中的周围文本经常重复了图像中已经存在的信息，这使得图像更像是一个参考而不是独特的数据源。此外，文档中的URL经常包含关键细节，如设备或工具名称，这些对于有效的信息检索至关重要。基准数据集中也只有有限数量的需要额外上下文的纯视觉查询，这进一步限制了改进描述的效果。
总之，虽然周围文本确实提高了图像描述的质量，但由于内容冗余和数据集的限制，其对检索指标的影响是有限的。然而，在图像包含独立信息且周围文本为图像描述提供额外上下文的场景中，这个功能可能会证明是有价值的。要充分证明这种方法的合理性，需要使用不同的源数据进行进一步的实验来验证其有效性。
使用多模态LLM进行推理
我们正在比较两种处理系统中图像的方法。第一种方法涉及在知识构建时进行丰富化，我们使用多模态LLM提取图像描述并将这些描述存储在向量数据库中。这使我们能够在聊天或搜索过程中检索和利用这些描述。第二种方法涉及在推理时进行丰富化，我们在查询时将前10个图像字节连同检索到的文本块一起发送给多模态LLM。LLM同时处理图像和文本以生成响应。
我们的目标是比较两种不同的方法：
- 在知识构建时时进行丰富化，推理时仅发送检索到的文本。
- 跳过初始丰富化，而是通过多模态LLM进行推理，这涉及同时发送文本和相关图像。
以下是实验结果的概述：
正如预期的那样，我们观察到源和图像检索指标出现下降，这也影响了引用图像的指标。理解图像对于检索来说至关重要，尤其是对于仅图像的问题。在推理过程中启用多模态LLM进行丰富化（发送文本+图像字节）作为一种权宜之计，在管理大量图像语料库时可能是有利的，特别是在知识构建过程完全完成之前。
我们的下一步是探索在知识构建时进行丰富化与在推理时使用多模态LLM相结合的好处，并评估同时进行这两项操作能获得多大收益。
我们观察到正确性评分有所提高，答案在纯视觉和一些视觉-文本查询中变得更加精确。然而，启用多模态LLM所引入的额外6秒延迟可能无法证明其使用的合理性，特别是在已经检索到有效图像的情况下。
GPT 3.5 vs GPT 4 vs GPT 4o 推理场景中的对比
为了确定最适合我们客户的GPT模型，我们探索了各个方面，如生成指标、成本和延迟。主要焦点是从多个角度理解更改GPT模型的影响，包括引用图像的精确度、召回率、F1分数和GPT正确性分数。
我们首先比较了GPT-3.5和GPT-4在推理中的表现，特别是要看GPT-4-32k是否能更好地处理从检索到的图像丰富化块中得到的响应。
结果显示，GPT-4凭借其32K的上下文大小，在引用图像方面表现优于16K上下文大小的GPT-3.5。正确性得分也有所提高。尽管GPT-4速度较慢且成本更高，但在生成图像引用和基于视觉的问题方面表现更佳，表明其答案更加准确和完整。
我们因性能提升而转向使用GPT 4-32K。后来当GPT 4o推出并且我们发现其成本更低时，我们想评估GPT-4o是否能在我们的用例中表现同样出色。
GPT-4o，拥有128K的上下文，在图像引用召回率和正确性评分方面显示出显著改进，但图像精确度略有下降。这些差异是由于GPT-4o提供了内联URL引用、突出显示关键词，并提供更详细的响应，有时URL引用比必要的更多。尽管精确度略有下降，这些详细的答案并不会造成harm，反而可能很有用，特别是考虑到在客户门户中显示的是顶部搜索图像链接，而不是LLM引用。
虽然GPT-4o使用了更多的完成令牌，但运行GPT-4-32k的成本超过六倍。正如预期的那样，GPT-4o在延迟方面也表现更好。
基于这些结果，GPT-4o似乎是非视觉推理的正确选择，在质量、速度和成本方面都有所改进。
GPT 4 vs GPT 4o 在知识构建中的对比
我们的实验旨在确定较新的GPT-4o是否可以替代原始的GPT-4v用于文档摄取。
结果表明，GPT-4o不适合该客户，因为它在几个搜索指标上的表现比GPT-4v差，导致引用图像召回率的结果更差。尽管GPT-4o的成本较低，但性能下降并不值得这种成本优势。
GPT-4v（视觉预览版）在生成图像摘要方面表现更好，提高了召回指标。然而，GPT-4o在回答问题方面表现更佳。因此，我们建议在丰富化过程中使用GPT-4v，而在推理过程中使用GPT-4o，以充分利用它们各自的优势来满足我们客户的用例需求。
最终结论
我们与客户的合作之旅涉及深入优化他们的RAG应用，特别关注通过整合文本和图像信息来回答问题。我们分享的见解只是我们为精细调整图像处理和检索所做的大量工作的一瞥。
一切始于理解数据、实际最终用户将提出的问题类型，以及能帮助用户高效完成工作的答案。在开始实验之前，我们通过开发一个健壮的基准数据集和构建允许我们进行实验的功能来确保坚实的基础，包括一个可配置的实验框架，允许我们运行实验并保存结果以供共享参考和分析。这些准备工作使我们能够有条不紊地测试和分析各种策略，最终得出这些经验。重要的是要记住，像任何产品一样，解决方案需要根据生产中真实用户提供的反馈以及不断发展的技术/模型进行持续调整。
我们希望这篇博文能突出强调坚实实验基础的重要性，并为任何从事专注于图像的RAG应用的人提供有用的见解。我们的经验强调了为特定用例量身定制解决方案和进行彻底测试以实现最佳结果的重要性。
查看RAG with Vision存储库，它提供了一个基于Python的检索增强生成（RAG）管道的应用框架，可以利用MHTML文档中的文本和图像内容来回答用户查询，以及一个样本评估框架和详细的指南。
相关资源
致谢
特色图片由必应图像创造器生成。使用条款可在此处查看。