一次给 Gemini 多份文件，怎样防止不同文档的字段串在一起

一次给 Gemini 多份文件时，应给每份文件稳定编号，并要求每条结果带来源。文件上传顺序、显示名称和内容身份不是同一件事。本文用两份内容相似的合成通知设计反例测试，专门验收字段是否跨文档混用，不复述多模态接入代码。

故意做一组容易混淆的文件

D01 与 D02 都叫“活动通知”，同样有举办日期、地点和预算，但值不同。D01 设日期为11月1日、地点甲厅、预算1000元；D02 设日期为11月8日、地点乙厅、没有预算。缺失预算是关键反例：如果 D02 被填成1000元，说明来源归属可能已经污染。

文件编号	显示名	日期	地点	预算
D01	活动通知	11月1日	甲厅	1000元
D02	活动通知	11月8日	乙厅	原文缺失

在提交给模型的内容前后明确标示编号，保存本地路径、文件摘要和上传返回引用的映射。上传引用是服务中的文件身份，不代替你自己的长期内容摘要；文件重新上传或修改后需要更新映射。

输出合同要能表达“本文件没有”

结果至少含 document_id、字段名、原文片段、位置和提取值。提示中说明每份文件单独处理，不得从其他文件补字段；本文件缺失则输出 null 并注明缺失。即使输出结构完全合法，仍需检查 document_id 和引文是否匹配原文。

示例结果中，D02 预算应为缺失，而不是沿用上一个对象。批量程序也要防止复用同一个字典或缓存，让模型无辜背锅：先用固定合成响应测试解析器，确认两个文件结果不会因应用代码共享状态而串在一起。

做三个对照定位混淆来源

第一轮两份文件分别提取，得到单文件基线；第二轮一起提取；第三轮交换输入顺序再提取。比较同一文件的字段与来源是否保持一致。若单文件也错，先处理识别问题；若只有批量错，检查提示、上下文和归属逻辑；若交换顺序后错误跟着前一个对象走，重点查累计状态与邻近内容影响。

每轮保留输入编号顺序、提示版本、配置和完整脱敏结果。不同轮次不能悄悄改文件内容，否则无法判断是顺序作用还是内容变化。本文没有运行 Gemini，上述是可复做的验证设计，不是产品缺陷报告。

正式批量前给污染设阻断条件

关键字段必须能回指所属文件。发现跨文档引文、无来源值或对缺失字段的填补，就把相关记录隔离，不能用总准确率掩盖。必要时改为逐文件调用，再在应用中合并结果；这样可能增加请求数量，但归属更容易检查。

文件编号应由应用赋予，不让模型自行重新编号。结果排序可以改变，但编号到摘要的对应不变。合并结果时按编号连接，不能依赖“第一条就属于第一个文件”的隐含约定。

常见问题

文件名不同就不会混淆吗？ 不保证，仍需要稳定编号和来源字段。

单独提取都正确是否足以证明批量可用？ 不够，还要测组合与顺序变化。

缺字段能从别的文件补吗？ 只有业务明确要求跨文档关联且能给出关联证据时才可以，那应是另一条显式规则。

继续处理相关问题

相关入口：Gemini 接入基础。

官方依据与核对日期

核对日：2026-10-23。Gemini Files API：Files API 提供文件上传与引用机制；来源映射仍由应用保存。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。