Document AI 与 Gemini 实体提取对比实战基于 Google Cloud 双引擎解析 PDF 文档【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai本指南基于当前仓库中 gemini-and-documentai-for-entity-extraction 示例项目系统讲解如何利用 Google Cloud 的 Document AI 与 Gemini API 从 PDF 文档中提取实体并以前者结构化、后者语义化的双引擎并行结果为样本进行横向对比。读者将掌握 Document AI 在线/批量处理两种调用方式、Gemini 多模态 PDF 实体提取的提示词工程以及一套可复用的提取—上传—对比端到端流水线搭建方法。为什么要对比 Document AI 与 Gemini在从文档中提取有价值信息的场景里Document AI 与 Gemini 是两条技术路线截然不同、能力互补的工具。二者都具备实体提取能力但其定位、原理与适用边界差异显著。通过并排对比同一份 PDF 在两种 API 下的输出可以直观感知各自的优势与权衡从而在真实项目中做出正确的选型。Document AI面向特定文档类型的结构化抽取专家Document AI 是 Google Cloud 上专精于从多种业务文档发票、收据、合同等中抽取数据的服务。它基于先进的 OCR 与机器学习模型能够把非结构化文本转化为结构化数据——即识别并分类关键信息输出由字段类型与取值构成的实体列表。典型使用场景发票处理自动化高效抽取供应商信息、发票号、明细行与总金额缩短流程并减少人工错误合同分析提效识别合同中的关键条款、日期与当事方加快并提升法律文书审查的准确率医疗记录数字化从医疗表单与记录中提取患者信息、诊断、用药等关键细节支撑医疗行业的数据管理与分析。Gemini面向自然语言语义的通用大模型Gemini 是 Google 的大语言模型家族其强项在于自然语言的理解与生成擅长捕捉人类语言的细微语义可胜任摘要、翻译、问答乃至创意写作等任务。典型使用场景聊天机器人与虚拟助手借助其自然语言处理能力进行动态对话提供个性化客服或充当智能助手内容生成根据提示词起草邮件、撰写文章或创作故事复杂文档摘要将长文档提炼为简洁摘要节省阅读时间。协同与专业化二者如何各司其职Document AI适合从具有预定义 schema数据结构的特定文档类型中提取数据Gemini更适合从非结构化文本中理解语义并提取实体。对同一份文档分别用两种方式提取实体并对比输出可以获得结构化工具 vs 语义模型两种实现路径的一手认知。更重要的是两者可以组合出创新方案例如先用 Document AI 抽取结构化信息再交给 Gemini 基于抽取结果生成自然语言摘要或洞察。架构总览一次输入两条并行抽取链路下图展示了本项目的核心流程PDF 文件作为唯一输入同时进入 Document AI 与 Gemini 两条并行处理链路各自产出结构化实体字典{}格式最终汇总到 Combined Results 进行合并与对比。从实现层面看两条链路各有关键差异Document AI 链路PDF 直接以二进制内容或 GCS URI 形式提交给已训练的 Processor抽取器由服务端 OCR 定制模型产出带类型的实体Gemini 链路PDF 先上传到 Cloud Storage通过Part.from_uri以多模态输入注入 Gemini 模型再结合精心设计的提示词让模型以 JSON 形式输出实体。环境准备与依赖安装安装依赖本项目依赖三个 Google Cloud Python 包见 requirements.txtpip install --upgrade google-cloud-aiplatform pip install -q -U google-generativeai pip install -r requirements.txt其中google-cloud-documentai用于调用 Document AI 的 DocumentProcessorServiceClientgoogle-cloud-storage用于批量处理时读写 GCS 中间文件google-cloud-aiplatform则提供 Vertex AI 的GenerativeModel多模态能力。前置假设仓库文档明确指出运行本项目前需要完成两个前提完成官方 codelab已提供带测试文档的数据集已经创建好一个 Document AI 抽取器Processor。在此基础上还需要为批量处理额外创建两个 GCS bucket一个存放待处理的临时输入文件一个存放处理结果输出TEMP_BUCKET_URI fgs://documentai-temp-{PROJECT_ID}-unique gcloud storage buckets create {BUCKET_URI} --project {PROJECT_ID} --location {LOCATION} OUT_BUCKET_URI fgs://documentai-temp-{TEMP_BUCKET_URI}-unique gcloud storage buckets create {OUT_BUCKET_URI} --project {PROJECT_ID} --location {LOCATION}{LOCATION}建议与 Processor 所在区域一致如us或eubucket 名称需全局唯一。在线处理模式OnlineDocumentExtractor不需要这两个 bucket仅 Gemini 链路本身也需要一个 GCS 位置供Part.from_uri引用 PDF。账号与 API 启用确保 Google Cloud 项目已启用所需 APIDocument AI、Vertex AI 等本脚本默认处理单个 PDF 文件可按需改造以支持多文件或其他输入源实体提取的准确性与性能取决于文档复杂度与所选 API 参数脚本面向演示目的设计可在此基础上扩展集成到实际应用。代码结构与模块职责示例代码由 5 个 Python 模块加 1 个 Jupyter Notebook 组成实际仓库中编排脚本为 test_document_ai_gemini.ipynbREADME 中描述的test_doc_ai.py角色即由该 Notebook 承担模块职责extractor.py封装 Document AI 在线Online与批量Batch两种处理模式的客户端类entity_processor.py定义统一的实体提取抽象分别解析 Document AI 输出与 Gemini 响应prompts_module.py生成实体提取与结果对比两类 Gemini 提示词temp_file_uploader.py负责把本地文件上传到 GCS 临时位置并清理test_document_ai_gemini.ipynb端到端编排Document AI 提取 → Gemini 提取 → 结果对比深入源码Document AI 抽取层extractor.pyextractor.py 以抽象基类DocumentExtractor统一两种处理模式class DocumentExtractor: def __init__(self, project_id, location, processor_id, processor_version_idNone): self.client documentai.DocumentProcessorServiceClient( client_optionsClientOptions( api_endpointf{location}-documentai.googleapis.com ) ) self.processor_name self._get_proccessor_name()其中两个实现细节值得关注区域化 endpoint客户端按{location}-documentai.googleapis.com构造 API 地址location支持us、eu等区域处理器版本路径_get_proccessor_name()在提供processor_version_id时通过processor_version_path定位到具体版本否则退化为processor_path使用默认版本——批量处理要求显式指定版本这正是 Notebook 中processor_version_id processor-version-id # Optional for batch processing注释所指。在线处理OnlineDocumentExtractor在线模式同步、低延迟适合单文档快速抽取。process_document()将 PDF 读为字节流构造documentai.ProcessRequest提交request documentai.ProcessRequest( nameself.processor_name, raw_documentdocumentai.RawDocument(contentimage_content, mime_typemime_type), ) result self.client.process_document(requestrequest) return result.documentmime_type默认application/pdf返回的documentai.Document对象中携带entities列表。批量处理BatchDocumentExtractor批量模式适用于大批量文档属于异步任务先上传输入到 GCS再提交BatchProcessRequest轮询操作直至完成最后从输出 bucket 拉取 JSON 结果并反序列化回documentai.Document。关键链路extractor.pyoperation self.client.batch_process_documents(request) operation.result(timeoutself.timeout) # 默认超时 400 秒 metadata documentai.BatchProcessMetadata(operation.metadata) if metadata.state ! documentai.BatchProcessMetadata.State.SUCCEEDED: raise ValueError(fBatch Process Failed: {metadata.state_message})失败处理上代码捕获RetryError与InternalServerError并打印错误信息同时通过metadata.state二次校验任务是否真正成功。结果回收阶段通过正则rgs://(.*?)/(.*)解析每个子任务的输出 GCS 路径遍历 bucket 找到content_type application/json的 blob 作为最终文档——这印证了批量输出的实际存储形态是 JSON 文件而非内存对象。统一实体抽象entity_processor.pyentity_processor.py 通过抽象基类EntityExtractor把两种异构输出统一成Dict接口是后续对比能够直接str()拼接的前提。DocumentAIEntityExtractor结构化输出直读Document AI 的实体本身就带有类型标签因此解析极其直接def extract_entities(self) - Dict: entities {} for entity in self.document.entities: entities[entity.type_] entity.mention_text return entities即以entity.type_字段类型如 Employees Name为键、entity.mention_text原文提及文本为值构造{字段类型: 原文片段}的字典。注意这里取的是原始提及文本而非规范化值若需要normalized_value如日期、货币的标准格式可在此基础上扩展。ModelBasedEntityExtractorGemini 多模态 JSON 输出Gemini 侧封装了模型配置、PDF 注入与 JSON 解析三层逻辑。构造时的GenerationConfig是本示例的抽取质量关键参数entity_processor.py参数取值作用temperature0.0关闭采样随机性保证抽取结果可复现、确定性优先top_p0.8核采样阈值限制候选词集合top_k32仅从概率最高的 32 个 token 中采样candidate_count1只生成一个候选结果减少歧义max_output_tokens2048输出长度上限足以容纳 W-2 表单全字段 JSONresponse_mime_typeapplication/json强制模型输出 JSON 格式extract_entities()的核心调用pdf_file Part.from_uri(self.file_path, mime_typeapplication/pdf) contents [pdf_file, self.prompt] response self.model.generate_content(contents)其中file_path必须是 GCS URI由TempFileUploader上传获得且构造函数会通过mimetypes.guess_type校验本地文件扩展名非 PDF 直接抛出ValueError防止无效输入进入模型调用。值得注意的细节是响应清理逻辑cleaned_string response.text.replace(json\n, ).replace(\n, ) entities json.loads(cleaned_string)即模型即使输出了 Markdown 代码围栏fence也会被剥离后再json.loads解析——这是与引导输出 JSON配套的防御性处理避免围栏字符破坏json.loads。提示词工程prompts_module.pyprompts_module.py 提供两个函数分别对应 Gemini 的两个阶段任务。实体提取提示词以 W-2 税表为例get_extract_entities_prompt()以一个极具代表性的业务场景——W-2 税表——定义了待提取字段全集。任务目标要求从文档中识别并提取以下字段基础信息员工社保号SSN、雇主识别号EIN、员工姓名、雇主姓名、雇主地址、Control Number如有联邦薪资框Box 1-11工资/小费/其他补偿、联邦所得税预扣、社保工资、社保税预扣、医保工资与小费、医保税预扣、社保小费、分配小费、家属护理福利、非合格计划缴款州与地方信息Box 15-20州名、雇主州 ID、州工资、州所得税预扣、地方工资、地方所得税预扣、地方名称。提示词同时给出三条关键约束体现实体抽取型提示词的核心设计原则准确性优先无法自信提取的字段标记为 Not Found 等占位符防止模型编造容忍版式差异要求模型处理文档格式与布局的变化多表单支持若文档含多张 W-2要求逐张分别提取。并附上一份完整的 JSON 示例输出覆盖全部 23 个字段含***-**-****这类掩码示例为模型提供明确的输出格式锚点。对比提示词让 Gemini 充当评判者get_compare_entities_prompt()将 Document AI 与 Gemini 两套输出通过str.format注入模板要求模型列出相似点两个输出中都存在且取值一致的实体差异点仅存在于某一侧的输出或两侧都存在但取值不同。compare_prompt compare_prompt.format( docai_outputstr(docai_entities), gemini_outputstr(gemini_entities) ) model GenerativeModel(gemini-2.0-flash) docai_gemini_response_analysis model.generate_content(compare_prompt)这本质上是一种LLM-as-a-Judge的用法不依赖人工逐字段比对而是让 Gemini 自动归纳两侧提取结果的一致性与分歧把对比结论以自然语言呈现。临时文件管理temp_file_uploader.pytemp_file_uploader.py 解决 Gemini 链路与批量处理共有的文件必须位于 GCS前提。TempFileUploader解析gs://bucket/prefix形式的临时 URI将目标文件以UUID 命名{uuid4()}.{ext}上传避免并发或重复运行时文件名冲突file_id str(uuid.uuid4()) destination_blob_name f{self.temp_file_path_gcs}{file_id}.{file_extension}upload_file()返回可用的 GCS URIdelete_file()在处理完成后删除临时对象——这一用完即删的模式在 Notebook 中体现为显式调用temp_file_uploader.delete_file()避免在 bucket 中累积垃圾数据。端到端运行流程在 test_document_ai_gemini.ipynb 中完整流水线分为四步模型版本为gemini-2.0-flash第一步配置运行参数project_id project-id location us # Or other supported locations like eu processor_id processor-id processor_version_id processor-version-id # Optional for batch processing file_path test_file.pdf mime_type application/pdf gcs_output_uri gs://bucket-output gcs_temp_uri gs://bucket-temp第二步Document AI 在线抽取online_extractor OnlineDocumentExtractor( project_idproject_id, locationlocation, processor_idprocessor_id, # processor_version_idprocessor_version_id ) online_document online_extractor.process_document(file_path, mime_type) docai_entities DocumentAIEntityExtractor(online_document).extract_entities()第三步Gemini 抽取先上传 PDF 到 GCStemp_file_uploader TempFileUploader(gcs_temp_uri) gcs_input_uri temp_file_uploader.upload_file(file_path) model_extractor ModelBasedEntityExtractor( gemini-2.0-flash, get_extract_entities_prompt(), gcs_input_uri ) gemini_entities model_extractor.extract_entities() temp_file_uploader.delete_file()第四步提示词对比并输出分析结论compare_prompt get_compare_entities_prompt().format( docai_outputstr(docai_entities), gemini_outputstr(gemini_entities) ) response GenerativeModel(gemini-2.0-flash).generate_content(compare_prompt) print(response.text)运行完毕后你将同时获得Document AI 的{类型: 原文}字典、Gemini 的 23 字段 W-2 JSON以及 Gemini 生成的相似点/差异点对比结论。两份输出可以直接肉眼比对也可以作为后续评测数据集的原始素材。从源码看两条路线的本质差异结合源码可以得出几条可验证的工程结论schema 来源不同Document AI 的字段类型来自 Processor 训练时的预定义 schemaentity.type_即先定结构再抽取Gemini 的字段集合完全由提示词中的字段清单决定修改提示词即可灵活增删字段无需重新训练。多模态路径差异Document AI 链路全程使用documentai.Document类型Gemini 链路则通过vertexai.generative_models.Part.from_uri注入 PDF且要求文件先在 GCS——这也解释了 temp_file_uploader.py 存在的必要性。确定性保障手段不同Document AI 是纯确定性模型输出Gemini 侧则通过temperature0.0加response_mime_typeapplication/json双管齐下控制输出稳定性。对比环节复用 LLM最终对比由 Gemini 自动完成prompts_module.py无需为对比逻辑额外编写解析代码。局限与扩展方向脚本当前仅支持单个 PDF 且默认 PDF MIME 类型多文档处理可切换到BatchDocumentExtractor或循环调用在线接口DocumentAIEntityExtractor仅取mention_text如需要标准化数值金额、日期可读取entity.normalized_value提示词中的 W-2 字段清单面向税表场景其他领域发票、合同、医疗记录只需替换 prompts_module.py 中的字段与示例即可复用整套流水线对比结论目前以文本打印可进一步将docai_entities与gemini_entities落库量化一致性指标如字段级 F1形成可复现的评测基准。总体而言这个示例提供了一条清晰的实践路径以 W-2 税表为统一场景将 Document AI 的结构化确定性与 Gemini 的语义灵活性放在同一张工作台上对比让开发者基于实测结果而非直觉做出选型决策。【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Document AI 与 Gemini 实体提取对比实战：基于 Google Cloud 双引擎解析 PDF 文档
Document AI 与 Gemini 实体提取对比实战基于 Google Cloud 双引擎解析 PDF 文档【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai本指南基于当前仓库中 gemini-and-documentai-for-entity-extraction 示例项目系统讲解如何利用 Google Cloud 的 Document AI 与 Gemini API 从 PDF 文档中提取实体并以前者结构化、后者语义化的双引擎并行结果为样本进行横向对比。读者将掌握 Document AI 在线/批量处理两种调用方式、Gemini 多模态 PDF 实体提取的提示词工程以及一套可复用的提取—上传—对比端到端流水线搭建方法。为什么要对比 Document AI 与 Gemini在从文档中提取有价值信息的场景里Document AI 与 Gemini 是两条技术路线截然不同、能力互补的工具。二者都具备实体提取能力但其定位、原理与适用边界差异显著。通过并排对比同一份 PDF 在两种 API 下的输出可以直观感知各自的优势与权衡从而在真实项目中做出正确的选型。Document AI面向特定文档类型的结构化抽取专家Document AI 是 Google Cloud 上专精于从多种业务文档发票、收据、合同等中抽取数据的服务。它基于先进的 OCR 与机器学习模型能够把非结构化文本转化为结构化数据——即识别并分类关键信息输出由字段类型与取值构成的实体列表。典型使用场景发票处理自动化高效抽取供应商信息、发票号、明细行与总金额缩短流程并减少人工错误合同分析提效识别合同中的关键条款、日期与当事方加快并提升法律文书审查的准确率医疗记录数字化从医疗表单与记录中提取患者信息、诊断、用药等关键细节支撑医疗行业的数据管理与分析。Gemini面向自然语言语义的通用大模型Gemini 是 Google 的大语言模型家族其强项在于自然语言的理解与生成擅长捕捉人类语言的细微语义可胜任摘要、翻译、问答乃至创意写作等任务。典型使用场景聊天机器人与虚拟助手借助其自然语言处理能力进行动态对话提供个性化客服或充当智能助手内容生成根据提示词起草邮件、撰写文章或创作故事复杂文档摘要将长文档提炼为简洁摘要节省阅读时间。协同与专业化二者如何各司其职Document AI适合从具有预定义 schema数据结构的特定文档类型中提取数据Gemini更适合从非结构化文本中理解语义并提取实体。对同一份文档分别用两种方式提取实体并对比输出可以获得结构化工具 vs 语义模型两种实现路径的一手认知。更重要的是两者可以组合出创新方案例如先用 Document AI 抽取结构化信息再交给 Gemini 基于抽取结果生成自然语言摘要或洞察。架构总览一次输入两条并行抽取链路下图展示了本项目的核心流程PDF 文件作为唯一输入同时进入 Document AI 与 Gemini 两条并行处理链路各自产出结构化实体字典{}格式最终汇总到 Combined Results 进行合并与对比。从实现层面看两条链路各有关键差异Document AI 链路PDF 直接以二进制内容或 GCS URI 形式提交给已训练的 Processor抽取器由服务端 OCR 定制模型产出带类型的实体Gemini 链路PDF 先上传到 Cloud Storage通过Part.from_uri以多模态输入注入 Gemini 模型再结合精心设计的提示词让模型以 JSON 形式输出实体。环境准备与依赖安装安装依赖本项目依赖三个 Google Cloud Python 包见 requirements.txtpip install --upgrade google-cloud-aiplatform pip install -q -U google-generativeai pip install -r requirements.txt其中google-cloud-documentai用于调用 Document AI 的 DocumentProcessorServiceClientgoogle-cloud-storage用于批量处理时读写 GCS 中间文件google-cloud-aiplatform则提供 Vertex AI 的GenerativeModel多模态能力。前置假设仓库文档明确指出运行本项目前需要完成两个前提完成官方 codelab已提供带测试文档的数据集已经创建好一个 Document AI 抽取器Processor。在此基础上还需要为批量处理额外创建两个 GCS bucket一个存放待处理的临时输入文件一个存放处理结果输出TEMP_BUCKET_URI fgs://documentai-temp-{PROJECT_ID}-unique gcloud storage buckets create {BUCKET_URI} --project {PROJECT_ID} --location {LOCATION} OUT_BUCKET_URI fgs://documentai-temp-{TEMP_BUCKET_URI}-unique gcloud storage buckets create {OUT_BUCKET_URI} --project {PROJECT_ID} --location {LOCATION}{LOCATION}建议与 Processor 所在区域一致如us或eubucket 名称需全局唯一。在线处理模式OnlineDocumentExtractor不需要这两个 bucket仅 Gemini 链路本身也需要一个 GCS 位置供Part.from_uri引用 PDF。账号与 API 启用确保 Google Cloud 项目已启用所需 APIDocument AI、Vertex AI 等本脚本默认处理单个 PDF 文件可按需改造以支持多文件或其他输入源实体提取的准确性与性能取决于文档复杂度与所选 API 参数脚本面向演示目的设计可在此基础上扩展集成到实际应用。代码结构与模块职责示例代码由 5 个 Python 模块加 1 个 Jupyter Notebook 组成实际仓库中编排脚本为 test_document_ai_gemini.ipynbREADME 中描述的test_doc_ai.py角色即由该 Notebook 承担模块职责extractor.py封装 Document AI 在线Online与批量Batch两种处理模式的客户端类entity_processor.py定义统一的实体提取抽象分别解析 Document AI 输出与 Gemini 响应prompts_module.py生成实体提取与结果对比两类 Gemini 提示词temp_file_uploader.py负责把本地文件上传到 GCS 临时位置并清理test_document_ai_gemini.ipynb端到端编排Document AI 提取 → Gemini 提取 → 结果对比深入源码Document AI 抽取层extractor.pyextractor.py 以抽象基类DocumentExtractor统一两种处理模式class DocumentExtractor: def __init__(self, project_id, location, processor_id, processor_version_idNone): self.client documentai.DocumentProcessorServiceClient( client_optionsClientOptions( api_endpointf{location}-documentai.googleapis.com ) ) self.processor_name self._get_proccessor_name()其中两个实现细节值得关注区域化 endpoint客户端按{location}-documentai.googleapis.com构造 API 地址location支持us、eu等区域处理器版本路径_get_proccessor_name()在提供processor_version_id时通过processor_version_path定位到具体版本否则退化为processor_path使用默认版本——批量处理要求显式指定版本这正是 Notebook 中processor_version_id processor-version-id # Optional for batch processing注释所指。在线处理OnlineDocumentExtractor在线模式同步、低延迟适合单文档快速抽取。process_document()将 PDF 读为字节流构造documentai.ProcessRequest提交request documentai.ProcessRequest( nameself.processor_name, raw_documentdocumentai.RawDocument(contentimage_content, mime_typemime_type), ) result self.client.process_document(requestrequest) return result.documentmime_type默认application/pdf返回的documentai.Document对象中携带entities列表。批量处理BatchDocumentExtractor批量模式适用于大批量文档属于异步任务先上传输入到 GCS再提交BatchProcessRequest轮询操作直至完成最后从输出 bucket 拉取 JSON 结果并反序列化回documentai.Document。关键链路extractor.pyoperation self.client.batch_process_documents(request) operation.result(timeoutself.timeout) # 默认超时 400 秒 metadata documentai.BatchProcessMetadata(operation.metadata) if metadata.state ! documentai.BatchProcessMetadata.State.SUCCEEDED: raise ValueError(fBatch Process Failed: {metadata.state_message})失败处理上代码捕获RetryError与InternalServerError并打印错误信息同时通过metadata.state二次校验任务是否真正成功。结果回收阶段通过正则rgs://(.*?)/(.*)解析每个子任务的输出 GCS 路径遍历 bucket 找到content_type application/json的 blob 作为最终文档——这印证了批量输出的实际存储形态是 JSON 文件而非内存对象。统一实体抽象entity_processor.pyentity_processor.py 通过抽象基类EntityExtractor把两种异构输出统一成Dict接口是后续对比能够直接str()拼接的前提。DocumentAIEntityExtractor结构化输出直读Document AI 的实体本身就带有类型标签因此解析极其直接def extract_entities(self) - Dict: entities {} for entity in self.document.entities: entities[entity.type_] entity.mention_text return entities即以entity.type_字段类型如 Employees Name为键、entity.mention_text原文提及文本为值构造{字段类型: 原文片段}的字典。注意这里取的是原始提及文本而非规范化值若需要normalized_value如日期、货币的标准格式可在此基础上扩展。ModelBasedEntityExtractorGemini 多模态 JSON 输出Gemini 侧封装了模型配置、PDF 注入与 JSON 解析三层逻辑。构造时的GenerationConfig是本示例的抽取质量关键参数entity_processor.py参数取值作用temperature0.0关闭采样随机性保证抽取结果可复现、确定性优先top_p0.8核采样阈值限制候选词集合top_k32仅从概率最高的 32 个 token 中采样candidate_count1只生成一个候选结果减少歧义max_output_tokens2048输出长度上限足以容纳 W-2 表单全字段 JSONresponse_mime_typeapplication/json强制模型输出 JSON 格式extract_entities()的核心调用pdf_file Part.from_uri(self.file_path, mime_typeapplication/pdf) contents [pdf_file, self.prompt] response self.model.generate_content(contents)其中file_path必须是 GCS URI由TempFileUploader上传获得且构造函数会通过mimetypes.guess_type校验本地文件扩展名非 PDF 直接抛出ValueError防止无效输入进入模型调用。值得注意的细节是响应清理逻辑cleaned_string response.text.replace(json\n, ).replace(\n, ) entities json.loads(cleaned_string)即模型即使输出了 Markdown 代码围栏fence也会被剥离后再json.loads解析——这是与引导输出 JSON配套的防御性处理避免围栏字符破坏json.loads。提示词工程prompts_module.pyprompts_module.py 提供两个函数分别对应 Gemini 的两个阶段任务。实体提取提示词以 W-2 税表为例get_extract_entities_prompt()以一个极具代表性的业务场景——W-2 税表——定义了待提取字段全集。任务目标要求从文档中识别并提取以下字段基础信息员工社保号SSN、雇主识别号EIN、员工姓名、雇主姓名、雇主地址、Control Number如有联邦薪资框Box 1-11工资/小费/其他补偿、联邦所得税预扣、社保工资、社保税预扣、医保工资与小费、医保税预扣、社保小费、分配小费、家属护理福利、非合格计划缴款州与地方信息Box 15-20州名、雇主州 ID、州工资、州所得税预扣、地方工资、地方所得税预扣、地方名称。提示词同时给出三条关键约束体现实体抽取型提示词的核心设计原则准确性优先无法自信提取的字段标记为 Not Found 等占位符防止模型编造容忍版式差异要求模型处理文档格式与布局的变化多表单支持若文档含多张 W-2要求逐张分别提取。并附上一份完整的 JSON 示例输出覆盖全部 23 个字段含***-**-****这类掩码示例为模型提供明确的输出格式锚点。对比提示词让 Gemini 充当评判者get_compare_entities_prompt()将 Document AI 与 Gemini 两套输出通过str.format注入模板要求模型列出相似点两个输出中都存在且取值一致的实体差异点仅存在于某一侧的输出或两侧都存在但取值不同。compare_prompt compare_prompt.format( docai_outputstr(docai_entities), gemini_outputstr(gemini_entities) ) model GenerativeModel(gemini-2.0-flash) docai_gemini_response_analysis model.generate_content(compare_prompt)这本质上是一种LLM-as-a-Judge的用法不依赖人工逐字段比对而是让 Gemini 自动归纳两侧提取结果的一致性与分歧把对比结论以自然语言呈现。临时文件管理temp_file_uploader.pytemp_file_uploader.py 解决 Gemini 链路与批量处理共有的文件必须位于 GCS前提。TempFileUploader解析gs://bucket/prefix形式的临时 URI将目标文件以UUID 命名{uuid4()}.{ext}上传避免并发或重复运行时文件名冲突file_id str(uuid.uuid4()) destination_blob_name f{self.temp_file_path_gcs}{file_id}.{file_extension}upload_file()返回可用的 GCS URIdelete_file()在处理完成后删除临时对象——这一用完即删的模式在 Notebook 中体现为显式调用temp_file_uploader.delete_file()避免在 bucket 中累积垃圾数据。端到端运行流程在 test_document_ai_gemini.ipynb 中完整流水线分为四步模型版本为gemini-2.0-flash第一步配置运行参数project_id project-id location us # Or other supported locations like eu processor_id processor-id processor_version_id processor-version-id # Optional for batch processing file_path test_file.pdf mime_type application/pdf gcs_output_uri gs://bucket-output gcs_temp_uri gs://bucket-temp第二步Document AI 在线抽取online_extractor OnlineDocumentExtractor( project_idproject_id, locationlocation, processor_idprocessor_id, # processor_version_idprocessor_version_id ) online_document online_extractor.process_document(file_path, mime_type) docai_entities DocumentAIEntityExtractor(online_document).extract_entities()第三步Gemini 抽取先上传 PDF 到 GCStemp_file_uploader TempFileUploader(gcs_temp_uri) gcs_input_uri temp_file_uploader.upload_file(file_path) model_extractor ModelBasedEntityExtractor( gemini-2.0-flash, get_extract_entities_prompt(), gcs_input_uri ) gemini_entities model_extractor.extract_entities() temp_file_uploader.delete_file()第四步提示词对比并输出分析结论compare_prompt get_compare_entities_prompt().format( docai_outputstr(docai_entities), gemini_outputstr(gemini_entities) ) response GenerativeModel(gemini-2.0-flash).generate_content(compare_prompt) print(response.text)运行完毕后你将同时获得Document AI 的{类型: 原文}字典、Gemini 的 23 字段 W-2 JSON以及 Gemini 生成的相似点/差异点对比结论。两份输出可以直接肉眼比对也可以作为后续评测数据集的原始素材。从源码看两条路线的本质差异结合源码可以得出几条可验证的工程结论schema 来源不同Document AI 的字段类型来自 Processor 训练时的预定义 schemaentity.type_即先定结构再抽取Gemini 的字段集合完全由提示词中的字段清单决定修改提示词即可灵活增删字段无需重新训练。多模态路径差异Document AI 链路全程使用documentai.Document类型Gemini 链路则通过vertexai.generative_models.Part.from_uri注入 PDF且要求文件先在 GCS——这也解释了 temp_file_uploader.py 存在的必要性。确定性保障手段不同Document AI 是纯确定性模型输出Gemini 侧则通过temperature0.0加response_mime_typeapplication/json双管齐下控制输出稳定性。对比环节复用 LLM最终对比由 Gemini 自动完成prompts_module.py无需为对比逻辑额外编写解析代码。局限与扩展方向脚本当前仅支持单个 PDF 且默认 PDF MIME 类型多文档处理可切换到BatchDocumentExtractor或循环调用在线接口DocumentAIEntityExtractor仅取mention_text如需要标准化数值金额、日期可读取entity.normalized_value提示词中的 W-2 字段清单面向税表场景其他领域发票、合同、医疗记录只需替换 prompts_module.py 中的字段与示例即可复用整套流水线对比结论目前以文本打印可进一步将docai_entities与gemini_entities落库量化一致性指标如字段级 F1形成可复现的评测基准。总体而言这个示例提供了一条清晰的实践路径以 W-2 税表为统一场景将 Document AI 的结构化确定性与 Gemini 的语义灵活性放在同一张工作台上对比让开发者基于实测结果而非直觉做出选型决策。【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考