摘要：由于 PDF 内容的多样性，在检索增强生成 (RAG) 系统中处理 PDF 带来了独特的挑战。许多文档将文本与图像、图表、图表和其他非文本元素结合在一起，这对于充分理解材料至关重要。传统的 RAG 系统通常专注于使用 OCR 或 PyPDFLoader 等工具
由于 PDF 内容的多样性，在检索增强生成 (RAG) 系统中处理 PDF 带来了独特的挑战。许多文档将文本与图像、图表、图表和其他非文本元素结合在一起，这对于充分理解材料至关重要。传统的 RAG 系统通常专注于使用 OCR 或 PyPDFLoader 等工具提取和索引文本。虽然这适用于文本密集型文档，但这些系统在处理图像和其他非文本数据时会遇到困难，导致响应不完整或意义不大。
我提出了一种利用 Gemini 1.5 Flash 的方法，这是一种能够处理文本、图像和其他类型媒体的多模态模型。通过标记包含非文本元素的页面、嵌入文本和图像，并将整个 PDF 页面的 Base64 编码版本存储在矢量数据库中，此方法保留了文本和视觉效果的完整上下文。这可以为文档摘要、问答和数据提取等任务提供更准确的响应——尤其是当内容包含重要的视觉元素时。
传统纯文本 RAG 在 PDF 处理中，面临如下的挑战：
纯文本焦点：当前的 RAG 系统仅从 PDF 中提取和索引文本，而忽略了图像、图表和插图等基本非文本元素。这在文档中是一个重大限制，因为这些元素对于传达含义至关重要。例如，在科学论文中，图形和图表等视觉辅助工具通常是理解复杂过程或结果的关键，而仅靠文本提取无法捕捉到这一点。空间关系的丧失：文本和图像在页面上的位置通常具有至关重要的意义。在技术手册或研究论文中，放置在段落旁边的图表通常会解释或补充文本。当文本和视觉效果在 RAG 管道中分开存储时，这种空间关系及其提供的额外含义就会丢失。因此，系统无法完全理解上下文，导致响应不够连贯或有用。非文本数据的上下文有限：当 RAG 系统仅索引文本时，模型无法访问文档的完整上下文。视觉元素通常携带文本本身无法完全传达的信息。忽略这些元素可能会导致答案不正确或不完整，尤其是在视觉数据对于理解文档至关重要的情况下。2、解决方案为了应对这些挑战，检测和标记包含非文本内容（如图像、插图或图表）的 PDF 页面非常重要。
步骤 1：识别非文本元素：第一步涉及识别哪些页面包含视觉元素。这可以通过使用文本提取工具（如 PyPDFLoader）的组合来完成，用于文本内容，并使用其他图像识别模型来扫描非文本元素。根据文档的性质，可以采用多模型方法对这些页面进行分类和细分。步骤 2：使用多模型方法：由于不同类型的数据需要不同的方法，因此灵活性是关键。可以使用各种工具来检测非文本内容，包括同时处理图像和文本的模型。具体方法取决于数据及其结构。对于某些文档，可能需要将整个页面作为一个单元进行索引，而其他文档可能需要将内容分成更小的块。在数据集上测试不同的技术对于找到最佳方法至关重要。步骤 3：标记元数据存储：一旦识别，包含非文本元素的页面将在索引阶段被标记为特殊处理。这涉及嵌入内容（文本和视觉内容）并准备将其增强存储在矢量数据库中。一旦识别并标记了非文本元素，就需要以保留文本和视觉内容的方式存储它们。
嵌入文本和视觉元素：与传统 RAG 系统一样，文本嵌入并索引在矢量数据库中。如果文档同时包含文本和视觉内容，则视觉元素要么直接嵌入（如果模型支持）要么作为附加上下文引用。这些嵌入允许系统在查询时检索相关内容。将 Base64 编码的页面存储为元数据：除了标准文本嵌入之外，此方法还通过将整个 PDF 页面作为 Base64 编码的字符串存储在矢量数据库的元数据中来添加额外的层。这可确保在检索页面时，系统可以访问其原始布局中的视觉和文本内容。将整个页面存储为 Base64 可让系统保持完整的视觉上下文，包括图表、图像和元素之间的空间关系。替代方案：直接存储单个 PDF 页面：如果 Base64 编码的存储由于数据库空间而成为限制或资源限制，更有效的方法是将每个单独的 PDF 页面存储为文件，而不是对其进行编码。然后，矢量数据库将存储文件的位置，而不是实际的 Base64 数据。这种方法减少了数据库容量的压力，同时仍允许系统检索完整页面并在需要时显示它们。数据库空间注意事项：将非文本数据与传统嵌入一起存储会占用大量存储空间。必须评估矢量数据库是否有能力处理大量 Base64 编码数据或外部 PDF 文件。如果担心空间问题，将 Base64 编码的页面存储在外部并简单地将文件路径保存在矢量数据库中可以提供更具可扩展性的解决方案。利用 Gemini 1.5 Flash 的多模态功能Gemini 1.5 Flash 是一个多模态模型，这意味着它可以同时处理文本和图像，并在上下文中理解它们。在推理过程中，当系统检索文档或页面时，它不仅可以将 OCR 提取的文本发送到模型，还可以发送整个 Base64 编码的页面或单个 PDF 页面。这使模型能够从整体上理解文档，包括文本和视觉元素之间的关系。
以下是实际操作示例：
import vertexaiimport base64from vertexai.generative_models import GenerativeModel, Part, GenerationConfig# When running on Colabfrom google.colab import authauth.authenticate_userPROJECT_ID = ""REGION = ""vertexai.init(project = PROJECT_ID , location = REGION)prompt = """Explain the illustration on the page."""file_url = ""with open(file_url, "rb") as pdf_file:pdf_data = pdf_file.readpdf_data_base64 = base64.b64encode(pdf_data).decode('utf-8')document = Part.from_data(data=pdf_data, mime_type="application/pdf")model = GenerativeModel("gemini-1.5-flash-001")generation_config = GenerationConfig(max_output_tokens=8192,temperature=0,top_p=0.95,)responses = model.generate_content([document, prompt],generation_config=generation_config,)print(responses.text)提高答案质量通过为模型提供完整的文档上下文（文本和视觉效果），系统能够生成更丰富、更有意义的响应。无论是总结技术文档、回答复杂问题还是执行实体提取，视觉数据的加入都使模型能够做出更明智的决策。例如，模型可以引用图表及其附带的段落，以提供更准确、更有见地的解释。
实际考虑因素：
页面分块与整页存储：根据文档类型，您可能需要将内容拆分成更小、更易于管理的块。如果需要分块，则将完整的 Base64 编码页面存储在每个块中可确保即使拆分文本也能保留视觉上下文。这种方法在图像和文本紧密相关的大型、图像密集型文档中特别有用。数据库空间管理：存储 Base64 编码数据或外部 PDF 页面会很快消耗存储空间，因此评估矢量数据库是否可以处理该容量至关重要。如果空间有限，请考虑将文件存储在外部并在数据库元数据中引用它们。这在高效存储和在需要时检索整页数据的能力之间取得了平衡。通过增强 RAG 管道以捕获 PDF 中的文本和非文本内容并利用 Gemini 1.5 Flash 的多模态功能，该方法显著提高了文档理解的质量。将整页数据以 Base64 编码形式或作为单个页面存储在矢量数据库中可保留文本和图像之间的关系，从而产生更丰富、更准确的模型响应。无论目标是文档摘要、问答还是实体提取，这种方法都能确保模型能够访问文档的全部范围，从而提高其输出的整体质量。
来源：尚法频道